Building blocks
Design goal
Give application teams repeatable landing zones without coupling every workload to the lifecycle or ownership of shared platform services.
Success criteria
- Separate platform and application subscriptions
- Apply governance at scale
- Centralize shared connectivity and security
- Enable repeatable workload onboarding
Architecture
A platform landing zone supplies shared services while application landing zones inherit governance and connect through controlled network paths.
Architecture flow
- Microsoft Entra ID provides identity
- Management Groups organize subscriptions
- Policy applies guardrails
- Platform subscriptions host connectivity and management
- Application landing zones host workloads
Architecture decisions
Separate platform subscriptions
WhyConnectivity, management, and security services evolve independently from application subscriptions and should have clear ownership boundaries.
Trade-offClear platform boundaries improve ownership and blast-radius control, but create cross-subscription dependencies that require disciplined RBAC, networking, and change management.
Apply policy high in the hierarchy
WhyManagement-group scoped policy provides consistent guardrails while allowing workload-specific controls lower in the hierarchy.
Trade-offCentral policy improves consistency, but overly broad or poorly tested assignments can block legitimate workload requirements across many subscriptions.
Networking
Make the traffic path explicit. Use centralized connectivity when shared routing, inspection, private DNS, or hybrid connectivity are required. Choose hub-and-spoke or Virtual WAN based on scale and operating model.
Security
Protect the control and data paths deliberately. Use Entra-based access, Azure Policy, Defender for Cloud, centralized activity/resource logs, and least-privilege RBAC.
- Privileged role governance
- Policy guardrails
- Central security monitoring
- Private connectivity where appropriate
Availability
Design for the failure domain that must be survived. Platform services should use zone-redundant or multi-instance patterns where the selected Azure region/service supports them.
Disaster recovery
Treat regional recovery as a separate operating state. Landing zone services should not become a single recovery dependency; workload DR remains defined per application tier and region strategy.
Cost drivers
- Azure Firewall or Virtual WAN
- Log Analytics ingestion/retention
- ExpressRoute or VPN
- Defender for Cloud plans
- Shared DNS/private endpoint footprint
Design assumptions
- A Microsoft Entra tenant exists
- Multiple subscriptions are permitted
- Central governance and networking ownership are defined
Implementation plan
- Define the management-group and subscription hierarchy around policy inheritance, platform ownership, workload ownership, and environment boundaries.
- Configure Entra ID groups, RBAC, PIM, and break-glass access before delegating subscriptions to application teams.
- Apply a policy baseline at the highest safe scope and document exemptions instead of embedding exceptions into every workload subscription.
- Deploy shared connectivity, private DNS, logging, and security services in dedicated platform subscriptions with clear owners.
- Onboard a pilot workload landing zone and confirm inherited policy, routing, DNS, logging, and cost allocation before scaling the pattern.
Validate the design
- Create or onboard a test workload subscription and confirm expected policy assignments and exemptions are inherited.
- Verify representative spoke routes and private DNS resolution through the platform connectivity services.
- Generate a test log/security event and confirm it reaches the centralized destination with the expected ownership.
- Review privileged roles and PIM activation to confirm application teams cannot bypass platform boundaries.