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