Landing Zones & Cloud Foundations

What a landing zone actually is

Strip the marketing off and a landing zone is six concrete things, deployed once and reused by every workload that follows:

1. A resource hierarchy - folders or organizational units that group accounts/subscriptions/projects by environment and business unit.
2. An identity baseline - your SSO provider federated to the cloud, group-based access, no long-lived root credentials.
3. A shared network - central VPC/VNet topology (often hub-and-spoke), private connectivity to on-prem, no public egress by default.
4. A logging spine - aggregated audit, flow, and resource logs flowing to a centralized security project for long-term retention.
5. A policy spine - organization-level guardrails that pre-block risky configurations everywhere (no public buckets, no internet-routable SGs in prod, no unencrypted databases).
6. A delivery pipeline - the IaC repository, review process, and deploy pipeline that's the only thing allowed to change foundation resources.

Everything else workloads bring themselves. The foundation gives them a defined surface to land on.

Why it exists - the problem it solves

Two organizations adopt cloud. Both end up with 200 workloads after three years.

Org A built their first workload by hand. Team-by-team, every subsequent workload made similar decisions independently - its own log destination, its own VPC, its own IAM role naming, its own MFA enforcement. Audit asks "where are all your CloudTrail logs going?" and the answer is "uh, depends on the team." Their blast radius is the whole org because a compromise in one workload's permissions can reach others' data.

Org B stood up a landing zone first. Their second workload landed on it, then their fiftieth, then their two-hundredth. All 200 dump logs into the same security project, use the same SSO groups for access, sit in the same Shared VPC with the same egress controls, and are pre-blocked by the same org policies from creating public buckets in prod. Audit asks the same question; the answer is "one project, here's the dashboard."

The landing zone is the difference between those two paths. It's not faster on day one - it's slower. It pays off on day 200, when the cost of fixing 199 different patterns is much higher than the cost of building one good pattern up front.

The same logic applies at smaller scale: any time you have more than one team deploying to more than one environment, the foundation eliminates a whole class of "where does this go?" decisions.

The eight building blocks every landing zone has

Every cloud's reference design organizes the same eight ideas. The names and tooling differ - the underlying capabilities don't.

AWS, Azure, and GCP side-by-side

Each cloud ships a reference landing-zone implementation. The names differ. The capabilities map nearly one-to-one:

Anyone who's built a landing zone on one cloud has 80% of the conceptual model needed to build one on another. The remaining 20% is the cloud-specific quirks of each service - and that's where the multi-day reading lives.

AWS - Control Tower & Landing Zone Accelerator

AWS ships two overlapping reference designs. Knowing which is which matters when someone tells you their "landing zone."

AWS Control Tower

An AWS-managed service that provisions and continuously governs a multi-account landing zone. Low-code, opinionated, with a console-driven experience and a built-in Account Factory for vending new accounts. Includes mandatory and elective guardrails (SCPs + AWS Config rules) and a managed Audit and Log Archive account out of the box. The right choice if you want AWS to own the wiring.

Landing Zone Accelerator (LZA)

An open-source AWS Solution (CloudFormation + CDK) that deploys a more comprehensive baseline - more security services, more customizable network architectures, support for regulated workloads. Can run on top of Control Tower. The right choice if you need more control than Control Tower's opinionations allow (custom regions, specific compliance frameworks like FedRAMP, ITAR).

The key AWS-specific decisions

• Account vending - Account Factory for Terraform (AFT) is the GitOps-flavor pattern; Control Tower's built-in factory is the console-flavor.
• SCPs at the OU level - your strongest preventive control. Deny iam:DeleteRolePolicy on detective-only roles, deny all actions outside approved regions, deny disabling CloudTrail.
• Centralized GuardDuty + Security Hub - both delegated to the audit account so you have one pane across all accounts.
• Transit Gateway in the network account - spoke accounts attach via shared TGW; egress through inspection VPC with firewalls.

Azure - Cloud Adoption Framework landing zones

Microsoft's reference is the CAF Enterprise-Scale landing zone (often abbreviated "ALZ" - Azure Landing Zone). Unlike AWS, Azure's reference is a documented architecture plus reference IaC (Bicep, Terraform, ARM) - there's no single managed service that is the landing zone.

The CAF design

A management-group tree (Tenant Root → Top-Level MG → Platform, Landing Zones, Decommissioned, Sandbox) with subscriptions hanging off the right MGs. Platform MG holds the Connectivity, Identity, and Management subscriptions; Landing Zones MG holds workload subscriptions for application teams.

The key Azure-specific decisions

• Azure Policy at the MG level - built-in initiatives like "Azure Security Benchmark" assigned at the top of the tree, with deny/audit effects on configurations everywhere below.
• Hub VNet in the Connectivity subscription - Azure Firewall (or NVA), ExpressRoute gateway, peered to spoke VNets in workload subscriptions.
• Log Analytics workspace in the Management subscription - diagnostic settings on every resource point to the central workspace; Sentinel reads from it.
• Entra ID PIM - Privileged Identity Management for just-in-time elevation; standing access only for break-glass.
• Defender for Cloud at the MG level - coverage applied top-down; recommendations and secure-score visible across all subs.

Implementation choice: Enterprise-Scale (ESLZ) reference repo, ALZ-Bicep, Terraform module, or the portal-driven Azure landing zone accelerator. All deploy roughly the same architecture.

GCP - Enterprise Foundations Blueprint

Google's reference is the Enterprise Foundations Blueprint (formerly the Security Foundations Blueprint). Like Azure, it's a documented design + reference Terraform (terraform-example-foundation) - not a single managed service.

The blueprint design

One organization at the top. A folder hierarchy by environment (production, non-production, development) and by business unit. Projects under each folder, grouped by purpose (workload projects, host projects for Shared VPC, security projects for centralized services).

The key GCP-specific decisions

• Cloud Identity synced from your IdP - groups drive IAM allow-policy bindings; no individual user grants.
• Shared VPC with a host project - workload projects (service projects) attach to the central network; no workload owns its own VPC.
• Aggregated log sinks at the org level - every project's audit, data-access, and VPC flow logs route to a central bucket or BigQuery dataset in a dedicated security project.
• Organization Policy constraints - pre-block configs like storage.publicAccessPrevention, compute.requireOsLogin, allowed regions, allowed external IPs.
• Cloud Build + Terraform pipeline - the only identity that can change foundation resources; humans get view-only.
• Security Command Center Premium - surfacing findings across the org with built-in detectors (Event Threat Detection, Container Threat Detection).

Reference repo: terraform-example-foundation on GitHub - every resource the blueprint describes, deployable.

Maturity stages - day 1 vs day 500

You don't deploy the full reference design on day one. Foundations grow with the org:

Skipping stages is expensive. A common failure mode is going from Stage 1 to Stage 4 because someone read the reference design and tried to deploy all of it at once - you end up with a complex foundation no one understands. Build incrementally; the reference designs are the destination, not the starting point.

When you do not need a landing zone

Foundations are overhead. The overhead pays off when you have multiple teams, environments, and workloads. If you don't, it's pure cost.

• Single workload, single team, single environment. A landing zone for one static site is over-engineering. (See our cloud deployment page for what a sensible single-project setup looks like.)
• Greenfield prototype. If you're not sure the project will exist in six months, build it in a dedicated sandbox account with sensible defaults. Move it into a real landing zone once it's surviving.
• Pure-SaaS organization. If your "cloud" is Microsoft 365 + Salesforce + Workday and you have no IaaS workloads, the landing-zone concept doesn't fit. You want SSPM instead - different posture problem.
• Acquired or M&A environment. Don't try to retrofit a brand-new landing zone onto an acquired company's 5-year-old cloud estate. Migrate workloads onto your foundation one at a time; the acquired estate stays as-is in a separate management boundary.

The rule of thumb: if your second workload is six months away, you don't need a landing zone yet. If your second workload is six weeks away, you needed one yesterday.

Bootstrapping path

For anyone standing up a foundation from scratch, a sane order of operations:

1. Pick a reference - Control Tower + LZA on AWS; ALZ on Azure; the Enterprise Foundations Blueprint on GCP. Don't invent your own - every "we built our own landing zone" story I've seen ended in a rewrite within three years.
2. Stand up identity first. SSO from your IdP, group-to-role mappings, MFA enforced, root accounts locked away. Nothing else matters if identity is broken.
3. Stand up the log spine second. One destination per log type (audit, flow, data-access). Retention policies. Sink into your SIEM (or just into a bucket/storage account/dataset for now).
4. Stand up the hierarchy third. Three top-level folders/OUs/MGs - prod, non-prod, sandbox - even if you have one workload. The hierarchy is cheap; restructuring later is expensive.
5. Layer in the network. Shared VPC / hub VNet / TGW once you have more than one workload that needs to talk privately. Skip if you don't.
6. Layer in guardrails as needed. Don't deploy 100 SCPs/Policies on day one - pick the highest-leverage 10 (no public buckets, deny outside approved regions, require encryption, deny disabling logs) and grow the library as patterns emerge.
7. Wire deploy through CI/CD. Foundation changes go through a pipeline with code review; no console writes in prod. Same model as application deploys - see our cloud deployment page for the small-scale version of this idea.
8. Vending last. Once you have a working foundation, automate the "new account" path so app teams can self-serve. Don't write account-factory code before you have a working foundation to put accounts into.

Realistic time investment for a small org doing this with a focused team: 2-3 months to a usable Stage 2; 6-12 months to a credible Stage 3. The reference designs are larger and assume larger teams; they're not deliverables-in-a-quarter.

Common pitfalls

• Building the foundation faster than the org needs it. A team of three building a 20-account landing zone for two prototypes is theater. Build to the scale you actually have, plus one stage.
• Treating the landing zone as a one-time project. Foundations rot. Cloud providers add services every quarter; org policy guardrails need updating; SCPs accumulate exceptions. Treat the foundation as a product owned by a named team. If nobody owns it, it decays.
• SCPs / Org Policies that block real work. Guardrails that pre-block every "I need to test this" path force teams to ship around the foundation, not on top of it. Build an exception path (a sandbox OU with looser policy, or a documented "request elevation" flow) so the guardrails stay strict in prod without being a barrier to learning.
• Centralized logging without analysis. Aggregating logs is necessary but not sufficient. If no one reads them, they're a compliance artifact, not a security control. Wire the high-signal logs (org-changes, IAM-changes, security-finding-creates) into alerts on day one.
• Skipping IaC for "the foundation is the IaC." Tempting to deploy the reference design once via console for speed. Don't - the foundation more than any other resource set needs to be in version control. Especially because the reference designs are configurable, you'll lose track of what you changed and why.
• Not federating identity from day one. Workloads created with local IAM users are technical debt forever. SSO every account from creation; never create local users for humans.

Further reading

Reference designs

• AWS Control Tower documentation
• AWS Landing Zone Accelerator (open source)
• AWS - Organizing Your AWS Environment Using Multiple Accounts (whitepaper)
• Microsoft - CAF landing zones
• Azure Enterprise-Scale reference (GitHub)
• GCP - Enterprise Foundations Blueprint
• GCP - terraform-example-foundation (GitHub)

Frameworks & benchmarks

• AWS Well-Architected Framework - Security pillar
• Microsoft Cloud Adoption Framework
• Google Cloud Architecture Framework
• CIS Benchmarks - what your guardrails should be enforcing

Related CSOH pages

• Cloud deployment - the single-project, defense-in-depth version of these ideas, applied to csoh.org itself.
• Cloud security best practices - the strategic principles (least privilege, zero trust, defense-in-depth) that the foundation implements.
• Shared responsibility model - which half of all this the cloud provider already handles.
• CSPM vs CNAPP - the tools that watch a landing zone once it's running.
• Glossary - landing zone.

FAQ

What is the difference between a "landing zone" and a "cloud foundation"?

In practice, none. "Cloud foundation" is the more vendor-neutral phrasing; "landing zone" originated in AWS terminology and spread to every cloud. Microsoft's docs use both terms; Google's blueprint title says "foundations"; AWS docs say "landing zone." Pick whichever your org uses.

Should I use the cloud vendor's reference or roll my own?

Use the reference. The "we built our own" path almost always reinvents the same patterns the reference already implements - but worse, and undocumented, and abandoned when the original engineer leaves. Customize on top of the reference; don't replace it.

How long does standing up a real landing zone take?

For a focused team using a vendor reference: 4-8 weeks to a credible Stage 2 (separation + logging + basic guardrails); 4-6 months to a credible Stage 3 (vending + shared network + meaningful policy library). The reference design fully deployed is more like a year of work plus an ongoing platform team - but most orgs don't need the full reference.

Does Cloud Adoption Framework work for AWS or just Azure?

"Cloud Adoption Framework" is Microsoft's term. AWS has its own equivalent (the Cloud Adoption Framework for AWS, plus the Well-Architected Framework). Google has the Cloud Architecture Framework. All three are general guidance documents; the landing-zone reference designs are the specific deployable artifacts within them.

Can I use Terraform / OpenTofu for any of these?

Yes - all three clouds publish Terraform reference implementations (LZA has CDK first but Terraform support exists; ALZ has an official Terraform module; the GCP blueprint is Terraform). Vendor IaC (CloudFormation, Bicep, Deployment Manager) is also supported on each respective cloud. Pick what your team operates today.

What about Kubernetes - does the landing zone include cluster baselines?

The classic landing-zone reference designs do not include opinionated Kubernetes baselines. The foundation provides the account / network / logging layer that K8s clusters land into; the cluster-level baseline (Pod Security Standards, network policies, admission controllers, RBAC) is a separate concern. Increasingly orgs deploy a "platform" layer on top of the foundation that includes cluster baselines - but that's an addition, not part of the standard landing-zone reference.

How does this relate to zero trust?

The landing zone is where zero-trust principles get operationalized. "Verify explicitly" means SSO + MFA at the foundation. "Least privilege" means SCP/Policy guardrails at the OU/MG/folder level. "Assume breach" means centralized logging + detective controls. Zero trust is the philosophy; the landing zone is the infrastructure that makes it actually work.