A landing zone is the secure, multi-account foundation you build once so that every future workload inherits good networking, identity and governance by default. Skimp on it and you will spend years retrofitting security; invest in it and you scale cleanly.
The account structure
Use AWS Organizations with Control Tower to provision a management account, a dedicated security account (for GuardDuty, Security Hub and audit), a log-archive account, shared-services accounts, and separate accounts per workload and per environment. This isolation limits blast radius and makes billing and access boundaries explicit.
The network
Adopt a hub-and-spoke topology with a central AWS Transit Gateway. Each workload VPC uses private subnets for compute and data, public subnets only for load balancers and NAT, and no direct internet exposure for application tiers. Centralise egress and inspection through a shared network account, and connect on-prem through Direct Connect with a VPN backup for resilience.
Identity and guardrails
Federate human access through AWS IAM Identity Center rather than IAM users, so credentials are short-lived and centrally revocable. Enforce preventive guardrails with Service Control Policies — for example, denying the disabling of CloudTrail or the creation of resources outside approved regions — and detective controls through AWS Config rules that flag drift.
Automate the whole thing
Every element of the landing zone should be codified in CloudFormation, CDK or Terraform and deployed through a pipeline. Account provisioning, baseline security and network wiring become repeatable, reviewable and fast — turning what was once a months-long enterprise project into a governed, self-service platform.
