Multi-account landing zone with Control Tower and centralized networking
Control Tower gives you a governed landing zone in an afternoon, but the network is the part it deliberately leaves for you to design.
The landing zone problem
Once an organization outgrows a single AWS account, it needs blast-radius isolation between environments, a consistent security baseline, and a place to see every account's logs at once. Building that by hand across dozens of accounts is slow and drifts out of compliance.
AWS Control Tower solves the governance half of this. It orchestrates AWS Organizations to create a landing zone: a multi-account structure with a security baseline, guardrails, and centralized logging that new accounts inherit automatically. The key mental model is separation of concerns: Control Tower owns identity, governance, and logging, while you still own the network design on top.
Two halves of a landing zone: what Control Tower owns vs what you own
Trace
The landing zone mental model is separation of concerns. Control Tower orchestrates Organizations to own identity, governance, and centralized logging, and every new workload account inherits that baseline automatically. The network layer on top is deliberately left for you to design.
What Control Tower builds for you
When you set up a landing zone, Control Tower creates a management account plus a Security organizational unit (OU) that holds two dedicated accounts: a Log Archive account and an Audit account. It configures an organization-level AWS CloudTrail and AWS Config so that trails and configuration history from every account are delivered into a central S3 bucket in the Log Archive account. The Audit account is where security teams get cross-account read access and where services like GuardDuty and Security Hub aggregate findings.
Guardrails come in two flavors. Preventive guardrails are implemented as service control policies (SCPs) that outright block disallowed actions across the organization, for example denying a member account the ability to disable CloudTrail. Detective guardrails are implemented as AWS Config rules that continuously check for and flag non-compliant resources but do not block them. Account Factory then lets teams provision new accounts that inherit this baseline the moment they are created.
What Control Tower builds: OUs, centralized logging, and guardrails
Trace
Control Tower creates a management account plus a Security OU holding a Log Archive account and an Audit account. Organization CloudTrail and AWS Config deliver logs from every account into the central Log Archive bucket, GuardDuty and Security Hub aggregate findings in the Audit account, preventive guardrails are SCPs that block actions and detective guardrails are Config rules that flag drift, and Account Factory provisions new accounts that inherit it all.
The networking Control Tower does not build
Control Tower does not build your inter-VPC or hybrid network, and this is the gap the exam loves to test. The reference answer is a dedicated Network account that owns the shared connectivity fabric so workload accounts never manage it themselves.
At the center is an AWS Transit Gateway created in the Network account and shared to the workload accounts with AWS Resource Access Manager (AWS RAM); each workload VPC then creates its own attachment to that shared gateway instead of a mesh of VPC peering connections. Egress is centralized through an inspection VPC in the Network account: spoke traffic crosses the Transit Gateway to an AWS Network Firewall for inspection and then leaves through a single shared NAT gateway, which both applies uniform filtering and collapses many per-account NAT gateways into one. Hybrid connectivity is centralized the same way: a Direct Connect gateway (or VPN) lives in the Network account and the Transit Gateway routes on-premises traffic to it, so a single connection serves every account.
Centralized networking in a dedicated Network account
Trace
The network is the part Control Tower leaves for you. A dedicated Network account owns a Transit Gateway shared to workload accounts through AWS RAM, so each spoke VPC attaches instead of building a full mesh of peering connections. Egress is centralized through an inspection VPC (Network Firewall then one shared NAT gateway), and hybrid traffic reaches on-premises through a single Direct Connect gateway that serves every account.
What this teaches for the exam
When a scenario asks you to stand up governance for many accounts (central logging, a security baseline, guardrails, self-service account creation), the answer is Control Tower orchestrating Organizations, with the Log Archive and Audit accounts in a Security OU. Match preventive requirements to SCPs and detective requirements to Config rules.
When the same scenario then asks how the accounts talk to each other and to on-premises, do not expect Control Tower to answer it. Reach for a separate Network account, a Transit Gateway shared through AWS RAM, and centralized egress and hybrid connectivity. The recurring exam trap is assuming Control Tower also wires the network, or reaching for full-mesh VPC peering when a shared Transit Gateway is the scalable choice.
Separation of concerns: matching each need to the right tool
Trace
The recurring exam trap is expecting Control Tower to also wire the network, or reaching for full-mesh VPC peering. One scenario, two questions: governance answers with Control Tower orchestrating Organizations (Log Archive and Audit in a Security OU, preventive SCPs, detective Config rules), and connectivity answers separately with a Network account and a Transit Gateway shared through AWS RAM plus centralized egress and hybrid links.
