Landing Zones & Governance
Grow with structure, not sprawl
Stand up the organizational skeleton: multi-account/scope structure, guardrails (SCPs, policies, budgets), networking hubs, and identity hygiene — so growth adds accounts, not chaos.
What you will learn
- Design the org/account/scope structure
- Lay guardrails that deny by default
- Wire identity, networking, and budgeting centrally
A landing zone is the pre-built foundation an account/environment inherits: org structure (management + identity + workload accounts/scopes), guardrail tier (SCPs/organization policies/deny rules that sit above tenant IAM), a network hub (shared transit, central egress when it's needed), centralized identity (SSO, least-privilege roles), and budgets with alerts at every scope. New teams get a scaffold, not a blank canvas.
What is this?
Structure: management scope (billing, org-level policies) + identity hub + per-workload/team scopes (prod, non-prod, shared). AWS uses Organizations + SCPs; Azure mgmt groups + subscription blueprints; GCP org + folders + IAM. Guardrails: SCPs/policies deny actions terraform-unguardable (public buckets, delete-protected removal, cross-account egress) regardless of IAM — deny-by-default sits above allow-by-role. Security-architecture controls; guardrails for cost: budgets + alerts + auto-notify on spend anomalies, tagging policy (all resources tagged: owner, cost-center, env). Identity: SSO + MFA + short-lived creds; break-glass (emergency) path documented; access reviews quarterly. Networking: a shared hub (transit gateway/hub VNet) for central DNS, egress controls, peering; spokes attach. The landing zone is IaC: scaffolding releases versioned 'foundation updates' (new guardrail, region policy, SSO rule) that land in every scope through a rollout, not email.
Why do you need it?
- Structure prevents the sprawl tax: 12 hand-rolled accounts/tenants each with its own admin habits.
- Deny-by-default guardrails work even when a team's IAM is too loose.
- Cost + tagging guardrails make the invoice legible to the business.
- The landing zone as IaC means governance improvements are shipped like code.
Mental model
Unincorporated territory, laws made on the spot
Town bylaws on the books, building checked against codes
SCPs and policies are the zoning code above any single tenant's IAM.
How it works
- Create mgmt + identity + workload scopes with budgets and tagging.
- Enforce guardrails: SCP/org policies deny unguardable actions.
- Provide the network hub + egress policy; connect spokes.
- Roll foundation updates as versioned IaC across all scopes.
Landing zone: guardrails above everything.
In production
- New team provisions into a pre-built landing zone in a day, guardrails included, no privileged access handed out.
- A deny rule stops a public-data-leak in dev because the SCP forbids it above the IAM allow.
- Monthly cost report grouped by tag: every dollar has an owner and a purpose.
Best practices
- Deny by default at the org/policy tier.
- Tagging policy + budgets tied to every scope.
- SSO, MFA, short-lived creds, quarterly access reviews, documented break-glass.
- Foundation updates versioned and rolled out, not emailed.
Common mistakes
- Accounts/tenants created by hand, guardrails added after the mess.
- An SCP so permissive it's a wish — or so rigid it blocks safe work.
- Budgets that exist but alert nobody.
Debugging tips
- 'IAM says allowed but the action fails' → suspect an SCP/org-level deny; check the guardrail layer above IAM first.
- New scope missing a standard guardrail → diff its foundation version vs the latest rollout.
Interview checkpoint
Quick quiz
Where do you stop a public bucket leak that tenant IAM allowed?