PILLAR 01 OF 06
Architecture and Landing Zones
How organizations structure their cloud estates: landing zones, account and subscription design, networking, identity boundaries, infrastructure as code and migration, compared across Azure, AWS and Google Cloud.
What this pillar covers
Landing zones and account structure
Management groups and subscriptions on Azure, multi-account organizations on AWS, and the resource hierarchy on Google Cloud. How to split by environment, business unit and regulation.
Networking and connectivity
Hub and spoke versus transit designs, private connectivity to on-premises, DNS, egress control, and connecting estates that span more than one cloud.
Infrastructure as code and guardrails
Bicep, Terraform and CloudFormation patterns, module libraries, and the policy guardrails that keep a landing zone compliant after day one.
Migration and modernization
Assessment, wave planning and landing workloads safely, plus how AI workloads change what a landing zone needs to provide.
Latest in Architecture and Landing Zones
No articles in this section yet. Coming up in this pillar: the first Architecture deep dive, “Landing zones compared across Azure, AWS and Google Cloud”, is planned for January 2027. Subscribe to get it by email.
How many landing zones does your organization actually run?
Reference architectures assume one clean landing zone per cloud. Acquisitions, regulated workloads and sandbox estates usually mean more. Tell us which split has been worth it for you, or suggest the comparison you want next.