A landing zone is the foundation every workload sits on. Get it right and teams move quickly within safe boundaries. Get it wrong and every project reinvents its own answers. This is a sample post showing the format; replace it with your own content.

Start with the decisions that are hard to change

Some choices are expensive to reverse later:

  1. Identity model. How you structure tenants, groups and privileged access.
  2. Subscription and management group hierarchy. This is where policy and cost boundaries live.
  3. Network topology. Hub-and-spoke, virtual WAN, or something simpler for a smaller estate.
  4. Naming and tagging. Small on day one, painful to retrofit.

Put guardrails in code

Policy should be declared, not remembered. A baseline might include:

- Require approved regions only
- Deny public IP addresses on workload subnets
- Require diagnostic settings on key resources
- Enforce mandatory tags (owner, cost centre, environment)

Expressing these as infrastructure-as-code policy definitions means they are reviewable, versioned and repeatable across environments.

Make the secure path the easy path

Teams push back on controls that slow them down. Provide a pipeline template, a pre-approved architecture pattern and a clear exception process. The aim is that doing the right thing takes less effort than doing the wrong one.

Measure whether it works

Track a few simple signals: time to provision a new subscription, number of policy exceptions, and how often teams need help with the baseline. If those numbers do not improve, the landing zone is probably too rigid or too poorly documented.