Why a Landing Zone Is Not Just "Setting Up Accounts"
A landing zone is the foundational architecture that every subsequent workload in your AWS estate inherits. Get it wrong and you spend the next three years accreting technical debt on top of a bad foundation. Get it right and new workloads land in a consistent, secure, auditable environment in days rather than months.
On a large federal cloud migration — moving a platform serving millions of users from an on-premises stack to AWS across multiple environments — the landing zone decisions made in the first 90 days shaped everything that followed. This is what we learned.
The Account Topology Decision
The first and most consequential decision is account topology: how many AWS accounts, and how do you structure them?
The pattern we used — and that I recommend for regulated, multi-workload environments — is a hub-and-spoke model with functional account types:
Management account: Only used for AWS Organizations, Service Control Policies, and consolidated billing. No workloads. Access tightly restricted to a small number of cloud administrators.
Security account: Centralized logging (CloudTrail, Config, VPC Flow Logs all aggregate here), centralized GuardDuty, Security Hub. SIEM integration feeds from this account. Security engineers have read access; no one has write access outside of the pipeline.
Shared services account: Internal DNS (Route 53 Private Hosted Zones), AWS Service Catalog portfolios, shared AMI distribution, internal package repositories (CodeArtifact). Workload accounts consume services from here without duplicating them.
Network account: Transit Gateway hub, Direct Connect or VPN termination, shared VPCs (more on this below). All routing flows through this account.
Workload accounts: One per environment per application domain (or one per environment if application domains are tightly coupled). Dev, staging, production are separate accounts — not separate VPCs in the same account.
This last point is important. Using separate accounts per environment provides a hard blast radius boundary. A misconfigured IAM role in dev cannot affect production because the accounts are isolated at the AWS level, enforced by SCPs, not just by IAM policy within a shared account.
Shared VPC Networking with Resource Access Manager
In a large estate, giving each workload account its own VPC and managing all the peering connections is operationally unscalable. The better pattern is centralized networking using VPC sharing through AWS Resource Access Manager (RAM).
The network account owns the VPCs. Shared subnets from those VPCs are shared with workload accounts using RAM. Each workload account can place resources (EC2 instances, ECS tasks, RDS clusters) into the shared subnets without owning the VPC.
The traffic flow to the internet — or to on-premises networks via Direct Connect — goes through the Transit Gateway in the network account. Workload accounts route through the TGW; they do not have their own internet gateways.
This gives you centralized egress inspection (a firewall in the network account sees all traffic), centralized DNS resolution, and a single network team managing the topology rather than each application team managing their own. On the migration I am describing, we had multiple environments and dozens of application domains. Managing that without centralized networking would have been untenable.
IAM Federation at Scale
Federal environments almost universally have an existing identity provider — Active Directory, or increasingly Azure Active Directory / Entra ID. The landing zone needs to connect AWS IAM to that IdP so engineers authenticate once (through their corporate identity) and assume AWS roles, rather than managing separate IAM user credentials.
The mechanism is IAM Identity Center (formerly SSO), connected to the organization's IdP via SAML 2.0 or SCIM. Engineers log into the Identity Center portal with their corporate credentials and see the accounts and permission sets they are authorized for.
Permission sets in Identity Center define what a role can do. We created a tiered set: read-only (for all engineers), developer (deploy permissions in non-production accounts), platform-admin (full access in non-production, restricted in production), and break-glass (full access in production, requires approval, all actions logged and alerted).
The break-glass pattern is important in regulated environments. Production changes go through the pipeline. The break-glass role exists for genuine emergencies — it is not used for routine work. Every assumption of the break-glass role triggers an alarm that wakes up the security team. This creates accountability without preventing legitimate emergency access.
Service Control Policies as Guardrails
Service Control Policies at the AWS Organizations level enforce constraints that no IAM policy within an account can override. This is the mechanism that makes the account isolation actually effective.
Key SCPs we implemented:
- Region restriction: All accounts except shared services were restricted to us-east-1 and us-west-2. Resources could not be accidentally created in unauthorized regions.
- No root account actions: The root user of each workload account was locked down. No root API calls allowed from workload accounts.
- Mandatory Config and CloudTrail: Neither Config nor CloudTrail could be disabled in any account. This ensures continuous compliance recording even if an account administrator tries to disable it.
- IAM protections: The security-account's centralized logging roles could not be modified or deleted from workload accounts.
SCPs are enforced *before* IAM policies are evaluated. An administrator in a workload account with full IAM permissions cannot work around an SCP. This is the fundamental difference between SCPs and just trusting your IAM policies.
The Migration Reality: Cutover Under Load
On the migration I referenced, we were not building a landing zone for greenfield workloads — we were building it to receive a running system under active load. Millions of users. Existing data contracts with upstream federal systems. Fixed deadlines.
The approach that worked: the landing zone was built and stabilized first, before a single workload was migrated. This sounds obvious but requires organizational discipline. There is always pressure to start migrating workloads before the foundation is solid. Resist it.
We used a shadow environment pattern: the legacy on-premises environment ran in production while we built AWS alongside it. Data migration pipelines ran in parallel for weeks before cutover. The actual cutover was a DNS change, not a data migration — all the data was already in AWS and synchronized.
These environments (multiple dev tiers, integration testing, performance testing, UAT, and production variants for different program teams) meant the landing zone had to be replicable. Every account had to look the same in structure and differ only in the permissible configurations (larger instances in production, smaller in dev, etc.).
Infrastructure as Code — specifically Terraform with Terragrunt — is what made that replicability feasible. The same root module deployed to every account, with environment-specific inputs overriding the defaults.
What the Foundation Enables
A well-designed landing zone is not the exciting part of a cloud program. It is the infrastructure behind the infrastructure. But it is what determines whether the program runs smoothly for years or spends years patching architectural mistakes.
The programs that got it right had consistent security posture across accounts, fast onboarding for new application teams (landing in an established environment rather than building from scratch), clean audit evidence (because logging and compliance controls were built into the foundation, not added later), and the ability to add new capabilities — a new region, a new shared service, a new account type — without rearchitecting anything.
The programs that got it wrong were still untangling shared-account architectures and manual IAM management three years into their cloud journey.
Get the foundation right. Everything else follows.