Landing Zones and Multi-Team Scale
At organizational scale, Terraform stops being about individual resources and becomes about platform. A landing zone is the baseline every team builds on: the accounts, networking, identity, logging, and security guardrails that should be identical and correct everywhere before a single application resource exists. The question shifts from "how do I create a VPC" to "how do dozens of teams each get a compliant VPC without reinventing it or getting it subtly wrong."
The answer is a platform team that provides paved roads — standardized accounts and opinionated modules — so application teams ship on a secure, consistent foundation they didn't have to build. Terraform is what makes that foundation reproducible.
What a Landing Zone Is
A landing zone is the standardized multi-account foundation: an AWS Organizations structure with separate accounts for workloads, shared services, logging, and security; the baseline networking that connects them; the identity and access model; centralized logging and audit trails; and the security baselines applied to every account. The defining property is sameness — every account is stamped from the same definition, so there are no snowflakes and no account that quietly missed a control. Multi-account isolation is the blast-radius strategy: a compromise or a runaway cost in one account can't reach the others.
Account Vending
New teams and projects need new accounts, and account vending is the automated path to provisioning and baselining them consistently. Rather than someone clicking through account creation and then hand-applying the baseline, a vending process — built on AWS Control Tower and Organizations, driven by Terraform — creates the account, enrolls it in the organization, and applies the standard networking, identity, logging, and guardrails. Every account that comes out the other side is identical and compliant from minute one. The alternative, hand-built accounts, is how an estate ends up with thirty accounts configured thirty slightly different ways.
Paved-Road Modules
The platform team publishes opinionated, compliant Terraform modules that application teams consume — a module that produces a correctly-configured service with the right logging, encryption, and network placement baked in. The point is to make the compliant path the path of least resistance: a team gets a secure setup by calling a module, not by becoming experts in every control. The failure mode to avoid is rigidity. A paved road so constraining that teams can't accomplish legitimate work routes them around the platform entirely, and now you have shadow infrastructure that bypasses every guardrail. Real modules ship with escape hatches for the genuine exceptions.
Guardrails at Scale
You cannot enforce a baseline across dozens of teams with manual review — a human approving every change is a bottleneck that either slows everyone down or gets rubber-stamped into uselessness. Guardrails at scale are automated: service control policies at the Organizations level that make whole classes of action impossible, policy-as-code that checks every plan against rules before it applies, and standardized backends so state is consistently located, encrypted, and locked. The baseline enforces itself rather than depending on someone catching a violation in review.
Team Topology
The ownership split determines whether the model scales. The platform team owns the foundation — the landing zone, account vending, the paved-road modules, the guardrails — and application teams own their own state, their own deploys, and the resources they build on top. Centralizing all state and pipelines in the platform team turns it into a bottleneck for every application change, which defeats the purpose. The platform provides the road and the rules; the teams drive on it independently. That division is what lets dozens of application teams move fast without each one being trusted to get the security baseline right.
- Letting every team build its own account baseline and networking, producing an inconsistent estate where no two accounts are secured the same way.
- Publishing paved-road modules so rigid that teams route around the platform, creating shadow infrastructure that bypasses every guardrail.
- Enforcing guardrails with manual review at scale, making the platform team a bottleneck that either slows everyone or gets rubber-stamped.
- Centralizing all state and pipelines in the platform team, so every application change waits on a single team to run it.
- Vending accounts by hand instead of automating it, so the baseline drifts and new accounts quietly miss controls older ones have.
- Provide a standardized landing zone and automated account vending so every team starts from the same secure, compliant baseline.
- Publish paved-road modules that make the compliant path the easy path, and ship escape hatches for the genuine exceptions.
- Enforce the baseline with service control policies and policy-as-code, not manual gatekeeping that bottlenecks or rubber-stamps.
- Divide ownership so the platform team owns the foundation and modules while application teams own their own state and deploys.
- Standardize the backend across teams — consistent state location, encryption, and locking — so the foundation is uniform everywhere.
Knowledge Check
What does a landing zone provide?
- A standardized multi-account foundation — org structure, networking, identity, logging, and security baselines — every team builds on
- A single shared AWS account where every team deploys all of its workloads together behind one common set of root credentials and policies
- A managed AWS service that authors and maintains the Terraform configuration on your behalf
- A region-failover mechanism for state files
What is the role of account vending?
- Automatically provisioning and baselining new accounts consistently, so each one is identical and compliant from the start
- Selling unused account capacity and reserved instances back to AWS in exchange for billing credit at the end of each monthly cycle
- Merging multiple existing accounts into one consolidated account to cut overhead
- Rotating IAM access credentials across all accounts on a fixed recurring schedule
Why do paved-road modules need escape hatches?
- A module too rigid to handle legitimate exceptions drives teams to route around the platform, creating shadow infrastructure that bypasses guardrails
- To let application teams disable encryption at rest whenever they decide they want faster deploys and lower latency on a release
- Because a Terraform module can't otherwise accept any input variables at all, so an escape hatch is the only mechanism that lets a caller pass values into it
- To allow the platform team to bypass review on its own changes
How do guardrails scale across dozens of teams without manual review?
- Service control policies and policy-as-code enforce the baseline automatically, so the rules apply without a human gatekeeping every change
- A dedicated platform reviewer manually inspects and approves every single plan from every team in real time before any one of them can apply
- Each team self-certifies its own compliance status once a year in a written attestation
- Guardrails are applied only to the production accounts and skipped in every non-prod environment
You got correct