Platform Monkey ctx

Landing Zones That Survive Year Two: AWS Control Tower vs. Azure LZ vs. Google Cloud Foundations

· By
Sources

Every cloud provider will happily sell you a landing zone. None of them will tell you the part that matters: landing zones don't fail at launch — they fail at month 14, when the second platform team has arrived, the first customization framework has been deprecated, and the governance bill has quietly compounded. This guide compares the three providers' landing-zone models as they actually behave in production, with named deployments, real cost math, and the failure points nobody puts in the reference diagram.

The three definitions diverge more than the marketing admits. AWS Control Tower orchestrates existing services (Organizations, Service Catalog, IAM Identity Center, Config) into a governed multi-account structure and calls the result a landing zone. Microsoft's Azure landing zone model splits into a centralized platform landing zone plus per-team application landing zones, deployed from Azure Verified Modules accelerators. Google doesn't even lead with the term — Google Cloud's landing zone design calls it a cloud foundation: a modular configuration of resource hierarchy, identity, network, and policy that you assemble yourself from Terraform blueprints.

That divergence is not cosmetic. It determines who owns the toil when the foundation drifts, which automation framework you'll be forced to migrate off of, and which line item eats your Year Two budget.

The Pattern: Three Layers, Three Very Different Owners

Strip the branding away and every landing zone is the same three-layer pattern:

LAYER 1 — RESOURCE HIERARCHY (the blast-radius boundary)
  AWS:    Organization -> OUs -> accounts        (account = hard boundary)
  Azure:  Management groups -> subscriptions    (subscription = boundary)
  GCP:    Organization -> folders -> projects  (project = boundary)

LAYER 2 — POLICY & IDENTITY (the guardrails)
  AWS:    SCPs + Control Tower controls (preventive/detective via Config)
  Azure:  Azure Policy + RBAC/Entra ID, assigned at management-group scope
  GCP:    Organization policies (constraints) + IAM, inherited down the tree

LAYER 3 — AUTOMATION (the part that rots)
  AWS:    Account Factory / AFT / CfCT  (three overlapping frameworks)
  Azure:  ALZ accelerators (Bicep/Terraform AVM) — after Blueprints died
  GCP:    Cloud Foundation Fabric / Stellar Engine / terraform-example-foundation

WHO OWNS YEAR-TWO DRIFT:
  AWS:    you own drift detection (Config rules, aggregators)
  Azure:    you own drift detection (Policy compliance state)
  GCP:    org policies are enforced at the API — drift is mostly impossible

The structural difference that drives everything else: AWS and Azure treat accounts and subscriptions as soft boundaries — the boundary is only as strong as the policy you attach to it, and detective controls (AWS Config, Azure Policy in audit mode) tell you about violations after they exist. GCP's resource hierarchy is enforced at the API layer — an organization policy constraint like gcp.resourceLocations rejects the create request before the resource exists. You trade flexibility for the guarantee that a mis-tagged resource never lands in the wrong folder.

name: organizations/01234567890/policies/gcp.resourceLocations
spec:
  rules:
  - values:
      allowedValues:
      - in:us-east1
      - in:europe-west1

The Architecture in Practice

The provider diagrams differ in vocabulary but converge on the same production topology: a central platform layer that owns identity, connectivity, and policy, vending standardized workload containers to teams.

flowchart TB
    subgraph P[Platform layer - owned by central platform team]
        ID[Identity & access
IAM Identity Center / Entra ID / Cloud Identity]
        NET[Connectivity
hub VPC / vWAN / Shared VPC]
        LOG[Org-level logging
CloudTrail sinks / Log Analytics / log sinks]
        POL[Policy & guardrails
SCPs+Config / Azure Policy / org policies]
    end
    subgraph A[Workload containers]
        A1[Account / subscription / project]
        A2[Account / subscription / project]
        A3[Account / subscription / project]
    end
    V[Vending machine: Account Factory, AFT,
ALZ accelerators, project factory]
    P --> V
    V --> A1
    V --> A2
    V --> A3
    A1 -.->|inherit policies| POL
    A2 -.->|route via hub| NET
    A3 -.->|audit logs to org sinks| LOG
    A1 -.->|SSO| ID

Where they stop converging is Layer 3, the automation — and that's where the Year Two stories live.

AWS: The Account Factory Conveyor Belt

Control Tower itself is free; you pay for the services it configures — CloudTrail, Config, CloudWatch, Service Catalog, SNS, S3 — as its pricing page states plainly. The landing zone it builds is genuinely fast to stand up: AWS's customer page quotes Liferay CTO Igor Arouca on a 70% reduction in account-provisioning time, and Deutsche Börse Group on using Account Factory to hand teams pre-configured accounts with guardrails already attached. Those numbers match what we see in the field: the first month is a triumph.

Year Two is where the conveyor belt jams, and the ProGlove write-up is the most candid production account of it. In 6,000 AWS accounts, three people, one platform (AWS Architecture Blog, February 2026), ProGlove's platform team describes running account-per-tenant at industrial scale: three platform engineers keeping six thousand accounts alive through full automation. Their hard-won lessons are the ones the reference architecture omits:

Then there's the framework churn. If you automate account vending on AWS today you choose between Account Factory for Terraform (AFT), the console's Account Factory Customizations, and the CloudFormation-based Customizations for Control Tower (CfCT) — three overlapping mechanisms for the same job. AFT is maintained in the open on GitHub and still actively developed (a July 2026 release added automatic customization re-application), but it runs its own pipeline infrastructure — Lambda, Step Functions, DynamoDB, CodePipeline — that your platform team now owns. Choose one and plan the migration off it. Assume any customization framework has a five-year shelf life.

module "aft_account_request" {
  source = "./modules/aft-account-request-framework"

  control_tower_parameters = {
    AccountEmail              = "payments-prod@yourcorp.example"
    AccountName               = "payments-prod"
    ManagedOrganizationalUnit = "prod-ou"
    SSOUserEmail              = "platform-team@yourcorp.example"
    SSOUserFirstName          = "Platform"
    SSOUserLastName           = "Team"
  }

  account_tags = {
    environment = "prod"
    cost_center = "payments"
    owner       = "team-payments"
  }
}

The honest AWS summary: fastest launch, strongest ecosystem of worked examples, and the highest ongoing automation tax of the three. Budget the platform team before you budget the tooling.

Azure: Platform Landing Zones and the Blueprints Ghost

Microsoft's current model, documented in the Cloud Adoption Framework, is the cleanest conceptual split of the three: one platform landing zone (the centralized foundation — identity, connectivity, management, governance subscriptions) and many application landing zones (subscriptions where teams deploy inside platform guardrails). Implementation is via accelerators built on Azure Verified Modules, in Bicep or Terraform, with GitHub or Azure DevOps pipelines. The Azure Well-Architected Framework that governs workload design inside those landing zones rests on five pillars: Reliability, Security, Cost Optimization, Operational Excellence, and Performance Efficiency.

The most instructive Azure story isn't Microsoft's; it's the framework churn visible from the outside. Azure Blueprints — the original landing-zone deployment mechanism — is in phased retirement: since July 31, 2026 no new blueprint definitions can be created; from October 31, 2026 existing definitions and assignments freeze; December 31, 2026 assignments become read-only; and on January 31, 2027 the API stops responding entirely and anything not exported is deleted. Microsoft's own migration success stories still describe customers deploying self-service landing zones with Azure Blueprints — a mechanism that now has a hard deletion date. If your landing-zone story predates 2024, your Layer-3 automation has a deadline.

The named deployments show what survives. Carne Group, Europe's largest independent third-party asset manager ($1 trillion in AUM), built a distinct Terraform-based landing zone for each product, migrated all compute out of a third-party datacenter in about six months under DORA pressure, then modernized in place — Azure Policy for boundaries, Azure Monitor for telemetry, and a deliberate lift-and-shift-first strategy to keep cutover risk low. Actavo (via FastTrack for Azure and partner SoftwareOne) used the landing-zone process as a forcing function for scope: Head of IT Gavin Scott's takeaway was that the landing zone "focused everybody in terms of what are the deliverables." The Microsoft customer story also documents two anonymized-but-detailed migrations — a US manufacturer that migrated hundreds of VMs in four weeks and its first subsidiary's mission-critical workloads by week eight, and a German enterprise standing up a compliant environment in eight weeks ahead of a datacenter exit. The pattern that works on Azure: treat the platform landing zone as a product with an owned roadmap, and use application landing zones as the unit of team onboarding.

The Azure trap is the opposite of AWS's: the accelerator deploys beautifully, management-group hierarchies and policy assignments included, and then nobody budgets the operations. Platform landing zones need a platform team exactly like an internal developer platform does — if the subscription vending process has no owner after go-live, drift accumulates in Azure Policy exemptions nobody reviews.

Google Cloud: The Foundation You Assemble Yourself

Google's landing-zone guidance is the least productized: a landing zone (Google prefers "cloud foundation") is a modular configuration — resource hierarchy (organization → folders → projects), identity federation, Shared VPC networking, org policies, logging sinks, billing — assembled from reference Terraform. The Google Cloud Well-Architected Framework organizes recommendations into pillars (security, reliability, performance, cost, operations, sustainability) plus cross-cutting perspectives.

The structural advantage is enforcement semantics. Organization policy constraints are evaluated at the API on every create/update — resource locations, service restrictions, IAM member domains — so a non-compliant resource is rejected rather than detected. Cloud Asset Inventory, the inventory that feeds most GCP governance tooling, is free of charge; you pay only for storage of exported data. The trade: GCP gives you no Console-driven "landing zone in an hour." You pick a blueprint and own its pipeline. The two that matter:

The named deployment: UC Riverside. The university's CISO Dewight Kramer describes a "compliance tax" that forced researchers to decline federal grants rather than build compliant environments. UCR partnered with Google Public Sector to build its Secure Enclave on Stellar Engine — compliance controls pre-configured into the infrastructure, with research teams set to onboard through 2026 and higher-assurance environments planned over the following 18 months. It's the clearest example of a landing zone functioning as a business enabler rather than an IT gate.

The GCP trap is the fork you never merge. Fabric and Stellar Engine are designed to be forked into your own repositories — which means you own upstream merges. Teams that fork FAST and never re-sync accumulate a bespoke foundation that no consultant can operate. Budget merge days like you budget on-call.

Cost Realism: The Year-Two Governance Bill

Nobody prices a landing zone at design time, and that is the second failure mode. The governance plane has a meter running the day you deploy. All figures below verified against live pricing pages on 2026-09-22 — re-check before you quote them, pricing changes.

AWS Config: the meter that never sleeps

AWS Config charges per configuration item recorded: $0.003 per continuous CI and $0.012 per periodic CI (one per resource per day), per rule evaluation, plus conformance-pack evaluations. The pricing page's own worked example: 100 resources at ~10 CIs/day under continuous recording is 1,000 CIs/day = $3.00/day, versus periodic recording's 100 CIs/day = $1.20/day. Control Tower's detective controls record continuously. Do the multiplication at real estate scale:

Environment (accounts × ~50 resources)Continuous recordingPeriodic recording
200 accounts — 10,000 resources$300/day ≈ $9,000/mo ≈ $108,000/yr$120/day ≈ $3,600/mo ≈ $43,800/yr
600 accounts — 30,000 resources$900/day ≈ $27,000/mo ≈ $324,000/yr$360/day ≈ $10,800/mo ≈ $129,600/yr

That is before rule evaluations and conformance packs. A 600-account estate recording everything continuously is a six-figure Config line item, and this is exactly how "free" Control Tower turns into a governance bill bigger than the workloads it protects. The mitigation is deliberate: select recording strategies (continuous only on critical resource types), scope recorder channels, and treat every new Control Tower control library as a pricing decision. The largest published optimizations cut Config bills by six figures annually by targeting what gets recorded.

Azure Monitor: ingestion-tier discipline

Azure Monitor Logs bills by ingestion plan: $2.30/GB pay-as-you-go for Analytics Logs (the plan everything defaults to), $0.50/GB for Basic Logs, $0.05/GB for Auxiliary Logs, with commitment tiers from $1.96/GB (100 GB/day) down to $1.48/GB (50,000 GB/day). Retention: 31 days interactive included, then $0.10/GB/month interactive; long-term at $0.02/GB/month.

Central platform Log Analytics ingestionAnalytics Logs PAYGSame volume as Basic Logs
5 GB/day$345/mo$75/mo
20 GB/day$1,380/mo$300/mo
100 GB/day$6,900/mo (or $5,880/mo at the 100 GB/day commitment tier)$1,500/mo

A platform landing zone centralizing platform logs (diagnostics from connectivity subscriptions, firewalls, identity sign-in logs) hits 20 GB/day almost immediately — and DORA-driven retention demands make the long-term archive a second meter. The mitigation: workspace design and table-level plan choices (Azure Monitor lets you set Basic Logs per table) decided at foundation time, not after the first invoice.

GCP: the quiet meter

Google's governance plane is nearly free at inventory level — Cloud Asset Inventory carries no charge, org policies are enforced in-line, and log sinks cost only what their destinations cost (BigQuery storage, Cloud Storage). The GCP surprise arrives in the same place as the other two: centralized logging destinations and, more sharply, Assured Workloads (Stellar Engine's companion), which carries its own per-project premiums depending on the compliance regime. Foundation tooling itself — Fabric, Stellar Engine — is open source and free; the toil is yours.

Comparison: Which Foundation for Which Team

DimensionAWS Control TowerAzure Landing ZoneGoogle Cloud Foundation
Time to first compliant account/subscription/projectFastest — console-driven, under an hour to landing zoneFast — accelerator with pipelines, hours to daysSlowest — fork a Terraform blueprint, own the pipeline
Boundary semanticsAccount = hard-ish boundary, drift detection is yoursSubscription = boundary, Policy is advisory-capableProject = API-enforced org policies
Automation framework riskHigh churn (AFC/AFT/CfCT overlap; plan the migration off)Blueprints dying Jan 2027 → Deployment Stacks + AVM acceleratorsFork-and-own (Fabric/Stellar) — upstream merges are your chore
Year-Two cost surpriseAWS Config at scale (six figures/yr at 600 accounts continuous)Log Analytics ingestion + retention if defaultedLog-sink destinations; Assured Workloads premiums
Best fitSaaS/reg orgs needing account-per-tenant; teams that want worked examplesMicrosoft-stack enterprises; regulated finance (DORA-style) with IaC culturePlatform-mature teams; compliance-heavy public sector

When NOT to Use Each

The Verdict

There is no best landing zone — there is only the one your org can operate in month 14. AWS wins the launch and owns the most candid post-mortem literature: ProGlove's three engineers per 6,000 accounts is the honest ratio, and AFT is the automation with the strongest current investment. Azure has the cleanest conceptual model (platform + application landing zones) and the clearest cautionary tale (a whole generation of Blueprints-based foundations hits a January 2027 deletion deadline). Google has the best enforcement semantics and the least hand-holding; Stellar Engine with the UCR-style compliance-as-infrastructure play is the most interesting 2026 development in the space, precisely because it treats the paperwork as code too.

The pattern that survives Year Two is the same on all three clouds: a funded platform team, an automation framework with a planned migration path, governance priced at design time, and a hierarchy that matches your org chart as it is, not as the reference architecture wishes it were. If you can name the person who owns the foundation's roadmap, you're ahead of most of the market. If you can't, you don't have a landing zone — you have an expensive group of unused accounts.

References & Further Reading