Azure landing zones for engineering teams, not just for auditors

A landing zone is the foundation a cloud workload is deployed into: subscriptions, identity, networking, policy, logging and the guardrails that keep all of it consistent. Most landing zone conversations are driven by governance teams, and the result is often a set of constraints engineers experience as friction. We think a landing zone should be designed for the engineering teams that live in it. Done well, it is the thing that lets a team ship a new service in an afternoon instead of a month.

What "for engineering teams" means

The test is simple. A team with a new workload should be able to get a subscription or resource group, an identity for their pipeline, network connectivity, logging and a deployment path without filing a ticket that waits on a human. Everything they inherit should be correct by default. Everything they must decide should be documented with a recommended answer.

The layers, briefly

Identity

Workload identities for pipelines and services, with federated credentials so no secrets are stored in the pipeline platform. Role assignments at the right scope, usually resource group, with a small set of custom roles that match how teams actually work. Break-glass accounts exist and are audited; day-to-day access goes through just-in-time elevation.

Networking

A hub-and-spoke or virtual WAN topology where each workload gets a spoke with private endpoints to platform services. DNS resolution works without anyone thinking about it. Egress goes through a firewall with a known policy. Teams do not design networks; they get one.

Policy

Azure Policy enforces the non-negotiables: allowed regions, required tags, no public storage, encryption settings, diagnostic settings on every resource. The important design choice is the effect. Use deny for things that must never happen and deployIfNotExists for things that should always exist, so the platform fixes gaps rather than blocking teams.

Observability

A central Log Analytics workspace (or a few, by region or sensitivity) that every resource sends diagnostics to via policy. Standard dashboards and alert rules that a workload gets on day one. Teams add their own signals; they never build the plumbing.

Delivery

Pipeline templates that know how to deploy into the landing zone: which identity to use, where to put infrastructure code, how to promote between environments. Infrastructure as code (Bicep or Terraform) is the only way resources are created. Portal changes are drift, and drift is detected and reverted.

Kubernetes in a landing zone

For teams running containers, the landing zone provides the cluster platform: AKS with workload identity, private API server, a managed ingress, image scanning, and namespaces provisioned per team with quotas and network policies. Teams deploy applications; they do not operate clusters. The distinction keeps the platform team's surface manageable and the application teams' cognitive load low.

Guardrails versus gates

A gate is a human who must approve before you proceed. A guardrail is a system that makes the wrong thing impossible or the right thing automatic. Both have a place, but most organizations have too many gates and too few guardrails. Every time a landing zone review finds a manual approval step, we ask whether a policy, a template default or a test could replace it. Usually one can.

Evolving it

A landing zone is a product with users. Version it, publish changes, gather feedback from the teams inside it, and measure the metric above. Auditors get what they need from the policy and logging layers as a by-product. Engineers get a platform that makes the right thing the easy thing. That is the point.