A pragmatic Azure landing zone gives SMBs governance without overkill

Whenever "Azure landing zone" comes up, particularly in connection with Microsoft best practices, I often watch people's eyes glaze over, and that's especially true in small and midsize organisations. The official documentation is thorough (see the Cloud Adoption Framework landing zone guidance), but if you try to implement all of it at once, you will get stuck in the complexity. Most tenants I review either have no structure at all or a tangle of resources managed ad hoc until nobody can keep track anymore. Fortunately, a handful of sensible decisions is enough to lay a solid governance foundation, and you don't have to solve everything on day one.

A simple management group hierarchy is enough for most organisations

I always start with a clear management group structure. For almost every SMB customer I suggest a plain hierarchy. A "Platform" group holds central and shared resources such as networking or identity, a "Landing Zones" group holds production workloads (often split into "Corp" and "Online" or something similar), a "Sandbox" area is there for experiments, and a "Decommissioned" group takes retired subscriptions. This is roughly what it looks like:

flowchart TD
    root["Root"]
    platform["Platform"]
    landingzones["Landing Zones"]
    corp["Corp"]
    online["Online"]
    sandbox["Sandbox"]
    decomm["Decommissioned"]

    root --> platform
    root --> landingzones
    root --> sandbox
    root --> decomm
    landingzones --> corp
    landingzones --> online

Figure: Example management group hierarchy for an Azure landing zone.

With this hierarchy you can assign policies and permissions cleanly and keep central services separate from business workloads. In many of my projects, the split between platform and landing zones is what kept things organised as the environment grew. If you want more background, Microsoft has a good introduction to management groups.

Subscriptions should be planned for scale rather than for today

I hear this one a lot: "We only need one subscription, right?" That can work at first, but even small organisations are better off with at least two, one for platform resources and one for workloads. Once you want sandboxes, separate billing or isolated teams or environments, multiple subscriptions start paying for themselves. Subscriptions are also the only hard boundary for quotas and cost management. Thinking about this a little early saves you trouble later.

Azure Policy at the management group level sets guardrails without handcuffs

Azure Policy gets overlooked a lot, even though it does a great job of keeping things consistent, particularly when you assign it at the management group level. As a pragmatic starting point I usually suggest these:

• Limit allowed regions
• Require key tags (like "Owner" or "CostCenter")
• Deny public IPs where exposure isn’t justified
• Audit or enforce diagnostic logging on core resources

The built-in policies handle most of this. Keep the initial set small, since custom policies can always come later. Because the assignment sits at the management group level, new subscriptions and resources fall under governance from the moment they're created. The Azure Policy Overview goes into more depth.

This sample definition restricts resource locations:

{
  "if": {
    "not": {
      "field": "location",
      "in": ["westeurope", "northeurope"]
    }
  },
  "then": {
    "effect": "deny"
  }
}

Group-based RBAC and Defender for Cloud make baseline security the default

For permissions, I always use group-based assignments with Entra ID groups and turn on Privileged Identity Management (PIM) for high-privilege roles like Owner or Contributor. Assigning roles directly to users turns into a mess as soon as the team grows or people leave. On the security side, a basic Defender for Cloud setup already gets you a lot, even without full automation or every premium feature switched on. Begin with posture management, vulnerability scanning and threat monitoring. If you also want to keep Azure costs in check while rolling this out, have a look at my post on Azure cost control with budgets, tags and Advisor.

Pro tip: Write down your initial RBAC and policy setup clearly. The first time a new colleague joins or takes over a resource group, you'll be glad you did.

A simple naming convention lets you grow into the framework later

Naming standards sound dull, but a few months in they decide whether you have order or spaghetti. I prefer a plain scheme like "[Org]-[Env]-[Type]-[Number]" (for example, "contoso-prd-vm-001"). A simple rule that people actually follow beats a 12-page naming bible that everyone ignores. For most SMBs, the full Cloud Adoption Framework landing zone blueprint is too heavy at the start, but your basic conventions should make it easy to move towards it as requirements change.

A landing zone should be built to scale, not to impress

After many projects, my view is that setting up an Azure landing zone foundation shouldn't turn into a second career in governance design. Clear management groups, a few targeted policies, clean RBAC and baseline Defender for Cloud monitoring are what you're after. Build what you need now, document it properly and extend it when new requirements appear. In my experience that's the quickest way to a healthy Azure environment that won't get in your way when you need to scale or automate.