Most teams don't plan their Azure landing zone — it just accumulates. Someone spins up a subscription for a project, then another for a different team, then a "shared services" one nobody quite owns. Eighteen months later there's no consistent naming, no clear cost ownership, and nobody's confident which subscription a given resource is even supposed to live in.

None of that is a technology problem. It's a structure problem, and it's much cheaper to solve before you have 40 subscriptions than after.

1. Decide your subscription hierarchy first, not your resource groups

Resource groups are where most teams start thinking about organization, but subscriptions are the real boundary — they're where billing, access control, and policy actually get enforced. Before creating anything, decide:

  • How many subscriptions do you actually need? A common, defensible starting point: one for platform/shared services (networking, identity), one per environment tier (prod, non-prod), and separate ones for any workload with genuinely different compliance or billing requirements. Don't create one per team "just in case" — that's how sprawl starts.
  • Who owns each one? Not "the cloud team" generically — a named owner accountable for cost and access review.
  • How do management groups reflect this? Management groups should mirror how you actually make decisions (by environment, by business unit, by compliance boundary) — not an org chart that will be reorganized next year.

2. Naming and tagging: decide once, enforce automatically

A naming convention that lives in a wiki page nobody reads is not a naming convention. The two things that actually work:

  • Keep the naming pattern boring and short. Something like {workload}-{env}-{region}-{resource-type} beats anything clever. Clever naming conventions get abandoned under deadline pressure; boring ones survive.
  • Enforce tags with Azure Policy, not a checklist. If cost-center, owner, and environment tags aren't enforced at creation time via policy, they won't exist consistently six months from now. This is a 30-minute setup that saves weeks of later cleanup.

3. Network topology: hub-and-spoke earns its complexity, but only above a certain size

Hub-and-spoke networking is the right answer for most growing environments — centralized egress, shared services like DNS and firewalls in the hub, workloads isolated in spokes. But if you're a five-person team with two workloads, a simpler flat topology is genuinely fine, and hub-and-spoke's overhead isn't worth it yet.

The mistake we see most often isn't picking the wrong topology — it's not documenting the decision, so nobody two years later understands why it's structured the way it is, and every change becomes archaeology before it becomes engineering.

4. Governance guardrails belong at the management group level

Azure Policy assignments made at the subscription level get missed the moment someone creates subscription number six. Assign your baseline guardrails — allowed regions, required tags, disallowed public IP exposure, whatever matters for your compliance posture — at the management group level so every new subscription inherits them automatically. This is the single highest-leverage governance decision in the entire landing zone.

5. Decide identity architecture before you have technical debt to migrate

Are workload identities using managed identities everywhere, or are there going to be service principals with long-lived secrets scattered around? Is Privileged Identity Management (PIM) enforced for anything with elevated access, or is standing access the default? These are much easier decisions to make on day one than to retrofit once fifteen applications already depend on the old pattern.

This is exactly the kind of structural work we do for the Cloud Foundation domain — whether you're setting this up for the first time or untangling something that's already grown organically. Get a scoped consultation →

The short version

If you only do five things: decide your subscription hierarchy deliberately, enforce naming and tags with policy instead of documentation, pick a network topology sized to your actual scale (and document why), push governance guardrails to the management group level, and settle your identity architecture before technical debt accumulates around it. Everything else is easier to fix later than these five.