Azure Landing Zone Checklist

Complete before the first production resource exists. Retrofitting subscription structure, tagging and identity onto a running estate is among the most expensive work in cloud engineering, and it is entirely avoidable.

Workload / environment: _______________ Owner: _______________ Date: _______

1. Tenant and subscription structure#

• [ ] Management group hierarchy defined, not everything in the root
• [ ] Separate subscription per environment (production isolated)
• [ ] Naming convention agreed and documented
• [ ] Resource groups grouped by lifecycle, not by resource type
• [ ] Subscription owner named for each

🔴 The subscription is the strongest practical boundary Azure offers for blast radius, policy and cost attribution. Sharing one across production and development to save administration trades a permanent boundary for a temporary convenience.

2. Identity#

• [ ] Human access through directory groups, not individual assignments
• [ ] Multi-factor authentication enforced, especially for privileged roles
• [ ] Conditional access policies defined and tested — including a break-glass exclusion
• [ ] Break-glass account exists, excluded from conditional access, credentials sealed and stored where two people can reach them
• [ ] Privileged roles time-bound rather than standing where available
• [ ] Workload identity used for applications — no secrets in code
• [ ] Access review cadence set

Break-glass tested on: _______

A conditional access policy that locks out every administrator is a well-documented way to lose an entire tenant. Test the escape route before you need it.

3. Networking#

• [ ] Virtual network and address space planned against future growth and any on-premises overlap
• [ ] Subnets segmented by tier
• [ ] Network security groups default-deny inbound
• [ ] Anything reachable from the internet listed explicitly and justified
• [ ] Private endpoints used for platform services holding data
• [ ] Outbound path deliberate
• [ ] DNS resolution planned, including hybrid

4. Policy guardrails#

• [ ] Policies assigned at management group level, not per resource
• [ ] Allowed regions restricted
• [ ] Required tags enforced (owner, environment, cost centre)
• [ ] Public network access denied by default for data services
• [ ] Deny rules chosen over audit-only where the risk warrants it

Policy is the mechanism that keeps an estate consistent as it grows. Audit-only policies tell you about drift you then have to chase.

5. Data#

• [ ] Soft delete and purge protection enabled where available
• [ ] Deletion protection / resource locks on production data stores
• [ ] Key management decided — platform-managed or customer-managed, with a reason
• [ ] Data residency requirements met and recorded

6. Cost#

• [ ] Budget set with alerts to a real inbox
• [ ] Tagging enforced by policy, not by convention
• [ ] Non-production resources scheduled to stop outside working hours
• [ ] Reservations or savings plans considered after a measured baseline
• [ ] Orphaned resources reviewed — disks, addresses, snapshots

7. Monitoring and recovery#

• [ ] Diagnostic settings sending logs to a central workspace
• [ ] Retention set deliberately
• [ ] Alerts that page a person, routed to a named rota
• [ ] Restore tested on ____ — took ____
• [ ] Backups isolated from the workload's own credentials
• [ ] Recovery objectives (RPO/RTO) written down and achievable

🔴 An untested backup is a belief. Fill in the restore row with a real date and a real duration, or record the gap honestly.

8. Before go-live#

• [ ] No standing owner-level access
• [ ] No public endpoints beyond the listed ones
• [ ] Every resource tagged
• [ ] Alerts tested by causing the condition
• [ ] Runbook written for the three most likely failures

Sign-off#

Back to Azure