Azure Landing Zones Are Not Just Subscriptions

A lot of Azure environments start simple: one subscription, a few resource groups, some virtual machines, maybe a storage account and a virtual network. At the beginning, this works. But over time, more workloads appear, more people need access, networking becomes harder to understand, and nobody is fully sure which rules are actually enforced.

That is the point where Azure stops being “just cloud infrastructure” and starts needing a platform.

An Azure landing zone is not only a place where resources live. It is the foundation that defines how workloads are deployed, connected, secured, monitored, and operated. Done well, it gives teams freedom without losing control. Done poorly, it becomes a collection of subscriptions that slowly turn into technical debt.

What an Azure platform needs to provide

For me, an Azure platform should answer a few basic questions before the first production workload is deployed:

Who is allowed to do what?

• How are workloads connected?

• Which security rules are enforced by default?

• Where do logs, alerts, and security findings go?

• How are environments deployed and changed over time?

• How do teams get enough freedom to work without bypassing governance?

These questions matter more than the individual resources. A virtual machine, storage account, app service, or Kubernetes cluster can always be created later. The harder part is building the foundation around them in a way that stays maintainable.

The design areas that matter

1. The first area is identity. Azure is controlled through Entra ID, RBAC, groups, privileged access, and managed identities. If access is assigned manually to individual users everywhere, the environment becomes difficult to audit. A clean platform should use groups, least privilege, Privileged Identity Management for sensitive roles, and managed identities wherever possible.

2. The second area is networking. Most real Azure environments eventually need private connectivity, DNS, firewalls, routing, private endpoints, VPNs, or ExpressRoute. This is where many designs become messy. A good landing zone should make network flows understandable. Teams should know how traffic enters, leaves, and moves between workloads.

3. The third area is governance. Azure Policy, management groups, naming conventions, tagging, allowed regions, diagnostic settings, and security baselines should not be afterthoughts. Governance should not exist to slow teams down. It should make the secure and supportable path the default path.

4. The fourth area is operations. A platform is not finished when the deployment succeeds. Logs, metrics, alerts, backups, update processes, Defender for Cloud recommendations, cost alerts, and incident handling are part of the design. If nobody can operate the environment after deployment, the architecture is incomplete.

5. The fifth area is automation. A landing zone should be reproducible. Whether the tooling is Bicep, Terraform, GitHub Actions, or Azure DevOps, the important part is that the environment can be reviewed, versioned, deployed, and improved over time.

My practical checklist

Before I would call an Azure environment production-ready, I would want clear answers to these points:

• Management groups and subscriptions follow a clear structure.
• Privileged access is controlled through groups and just-in-time activation.
• Core networking is documented, including DNS, routing, and firewall paths.
• Public exposure is intentional, not accidental.
• Required tags and baseline policies are enforced.
• Diagnostic logs are collected for important resources.
• Security findings have an owner and a process.
• Infrastructure changes are made through code where possible.
• Naming conventions are understandable.
• Cost visibility exists before costs become a surprise.

This checklist is not perfect, and it will change depending on the organization. But that is the point: a landing zone is not one fixed template. It is a set of decisions that should be made consciously.

Closing thoughts

The best Azure environments are not necessarily the most complex ones. They are the ones where the important decisions are visible, documented, and repeatable.

A good Azure platform should make it easy for teams to deploy securely, operate reliably, and understand the environment they are working in. That is what turns a subscription into a platform.

This blog is where I will document how I think through those decisions: Azure architecture, networking, identity, governance, security, operations, and platform engineering in practice.