CloudRunbook | Practical Cloud Engineering
Azure Landing Zones: the practical guide (secure-by-default, engineer-friendly)
A hands-on walkthrough of Azure Landing Zones (ALZ): what they are, why they matter, and a runbook-style path to deploying a secure platform foundation.
A practical understanding of Azure Landing Zones (ALZ), the platform vs workload split, and a runbook-style path to deploying a secure foundation that scales.
Why landing zones exist (and why Azure estates regret skipping them)
If you have ever inherited an Azure tenant where subscriptions were created ad-hoc, RBAC is inconsistent, logs are not centralized, and every team built their own networking pattern, you have already met the problem landing zones were created to solve.
An Azure landing zone is not a single template. It is a repeatable platform foundation and operating model that lets you deploy workloads consistently with predictable governance, security and operations.
Landing zones are how you avoid “one-off” decisions becoming permanent debt.
What is an Azure Landing Zone (ALZ) in plain English?
A landing zone is an “approved destination” for workloads, built on a standardized platform foundation.
A good landing zone is:
- Secure by default (prevent obvious foot-guns)
- Consistent (every subscription looks the same operationally)
- Scalable (new teams and workloads do not require redesign)
- Automated (infrastructure as code and pipelines)
- Observable (logs and signals are present from day 0)
If you cannot create a new subscription for a team in minutes and have it compliant immediately (RBAC, policy, logging), you do not yet have an effective landing zone.
Platform landing zone vs application landing zones (this split matters)
Platform landing zone
This is the shared foundation that the platform team owns. It commonly includes:
- Management groups and governance structure
- Subscription creation and lifecycle (vending)
- Policy guardrails and compliance posture
- Logging and monitoring baseline
- Shared networking and connectivity patterns (when used)
- Security baseline and security operations integration
Application landing zones
These are workload subscriptions (or subscription sets) where product teams deploy application resources. They should inherit your governance and integrate with platform services where appropriate.
If platform changes require manually fixing every subscription, you are not running a landing zone. You are running a collection of snowflakes.
The big decisions you should make early
Landing zones are a set of choices you want to make once so every workload benefits later.
The “big rocks” are:
- Management group hierarchy
- Subscription strategy and vending
- Identity and privileged access model (PIM, break-glass)
- Policy guardrails and compliance approach
- Networking topology and DNS strategy
- Logging and monitoring baseline
- Security operations baseline
- Update process (how you keep ALZ current)
Runbook: build an Azure Landing Zone you can scale
- Define the minimum viable landing zone (MVLZ)
Start smaller than “everything everywhere”, but do not skip the fundamentals.
Minimum baseline:
- Management groups (even if simple)
- A subscription vending process (how new subscriptions are created)
- RBAC model and privileged access (PIM for admin roles)
- Policy baseline (deny obvious foot-guns, audit the rest initially)
- Central logging destination and a plan for diagnostic settings
- Choose an implementation style and commit to it
For a platform foundation, infrastructure as code is not optional.
Pick one primary approach:
- Bicep-first
- Terraform-first
Then treat landing zone changes like product releases:
- Versioned
- Peer reviewed
- Tested
- Rolled out predictably
- Build a management group hierarchy aligned to operations
Do not model your org chart in minute detail on day 1. Keep it operational.
A common pattern:
- Root (under tenant root)
- Platform
- LandingZones (workloads)
The goal is:
- Platform subscriptions are owned by the platform team and controlled tightly
- Workload subscriptions inherit guardrails and can be delegated safely
- Root (under tenant root)
- Put privileged access on rails (PIM, separation, break-glass)
Identity is the control plane.
Practical minimum:
- Separate platform admin roles from workload owner roles
- Use PIM for privileged role activation
- Create break-glass accounts and protect them (strong auth, monitoring, limited use)
Outcome:
- No permanent standing admin access for day-to-day work
- Set policy guardrails: deny the obvious, audit then tighten
Policy is how you prevent the common mistakes that cause incidents and cost blowouts.
A pragmatic strategy:
- Deny: obvious security foot-guns (public exposure, weak TLS, no encryption where mandatory)
- Audit: controls you want visibility on before enforcing
- Deploy if not exists: safe defaults (for example, diagnostic settings) where appropriate
Do not start with “deny everything”. You will break delivery and teams will route around you.
- Standardize networking patterns and decide DNS early
Pick one primary networking model:
- Hub and spoke
- vWAN-based transit
Decide early:
- How workloads reach the internet (egress control)
- How private connectivity is implemented
- Who owns DNS zones and resolution for private endpoints
Private endpoints without a DNS ownership model create painful, slow outages.
- Make logging and monitoring non-negotiable from day 0
Your future incident response depends on what you collect today.
Minimum baseline:
- Central log destination (one place to query)
- Subscription activity logs routed centrally
- Standard diagnostic settings approach for core services
If logging is optional, it will be skipped during delivery pressure.
- Implement subscription vending (this is how you scale)
Subscription vending is how you add teams without chaos.
Start with:
- A pipeline to create new subscriptions
- Automatic RBAC assignment based on workload metadata
- Automatic policy assignment based on management group placement
- Automatic logging onboarding
Result:
- A workload subscription becomes compliant immediately
- Treat ALZ as a product: update, validate, and improve
A landing zone is not “done”.
Establish:
- A change cadence (monthly or quarterly)
- A backlog of platform improvements
- Testing for policy/networking changes
- A safe rollout plan (pilot subscriptions first)
Platform drift is guaranteed unless you actively manage it.
What to deploy first (a realistic week 1 to 2 plan)
Week 1: governance skeleton
- Management group structure
- Platform subscriptions (platform-owned)
- RBAC model and privileged access baseline
- Initial policy baseline (deny plus audit)
Week 2: platform services baseline
- Logging and diagnostics approach
- Network baseline and DNS ownership decisions
- Subscription vending pipeline
Common pitfalls (things that cause rework)
Landing zones are an operating model. If you do not plan for updates and drift control, your guardrails will decay.
Private connectivity is powerful, but it requires a clear DNS pattern and ownership model.
Over-modeling the org in management groups and policies makes governance brittle. Start simple, evolve intentionally.
Start with denies for clear foot-guns. Audit the rest, then tighten based on evidence.
Validation checks (what good looks like)
- ✓
A new subscription can be vended via pipeline and is compliant on day 0 (RBAC, policy, logging).
- ✓
Platform subscriptions have tighter controls than workload subscriptions.
- ✓
Central logging exists and core platform signals flow into it.
- ✓
Policy assignments are versioned and updated through Git.
- ✓
Networking has a defined standard and DNS has a clear owner.
- ✓
There is a process and cadence to keep the landing zone current.
A landing zone is how you make “secure by default” real. The fastest teams are not the ones with no controls. They are the ones with standard controls that do not require constant negotiation.