AWS Landing Zone Diagram: Multi-Account Setup with Organizations and Control Tower

One AWS account for everything works until it does not. A test script deletes a production bucket. Finance cannot split the bill by team. An auditor asks who can modify the audit logs, and the honest answer is "anyone with admin". A landing zone is the multi-account foundation you put in place before workloads arrive: the account structure, identity, guardrails, logging and network that every new account inherits.

This post walks through a landing zone design with a diagram: why multiple accounts, the recommended organizational units, the core accounts, guardrails with service control policies (SCPs), resource control policies (RCPs) and declarative policies, identity, central logging and security tooling, networking, and how to build it with Control Tower, including what changed in landing zone 4.0, or with Terraform.

Why multiple accounts

An AWS account is the strongest isolation boundary AWS offers. IAM permissions, service quotas, costs and most failures stop at its edge. Separate accounts give you:

• Blast radius. A mistake or a compromised credential in a sandbox cannot touch production.
• Clear ownership and billing per team, application or environment.
• Simpler permissions. Instead of one account full of conditions on tags, each account gets the access its team needs.
• Independent quotas, so one team's load test does not exhaust another team's limits.

The cost is coordination: identity, logging, guardrails and networking must work across dozens of accounts. That coordination is what a landing zone provides.

The structure: organizational units

AWS Organizations groups accounts into organizational units (OUs), and policies attached to an OU apply to every account below it. The AWS whitepaper on organizing your environment recommends a set of OUs to start from:

Split Workloads into Prod and Non-prod sub-OUs early. Guardrails differ between them, and moving accounts later is painful. Add a Suspended OU with a deny-all policy for accounts awaiting closure.

The management account

The management account owns the organization, consolidated billing and Control Tower. Keep workloads out of it, for one decisive reason: SCPs do not affect users or roles in the management account, as the Organizations documentation states. Nothing you deploy there is constrained by your guardrails, so give it as few users and resources as possible.

Core accounts

• Log Archive. Receives the organization's CloudTrail trail and AWS Config history in S3. Almost nobody gets write or delete access; consider S3 Object Lock so even administrators cannot alter logs.
• Security Tooling, also called Audit. The delegated administrator for GuardDuty, Security Hub, IAM Access Analyzer and the AWS Config aggregator, so the security team sees every account from one place without access to the management account.
• Network. Owns the Transit Gateway, private connectivity to data centers, DNS resolvers and IP address management, shared with workload accounts through AWS Resource Access Manager.
• Shared Services. CI/CD, artifact repositories and other tools that many teams use.

Guardrails: SCPs, RCPs and declarative policies

Organizations offers several policy types, and they answer different questions:

Policies only restrict; they never grant permissions. Start with a short list of high-value guardrails:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeavingOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    },
    {
      "Sid": "ProtectCloudTrail",
      "Effect": "Deny",
      "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail", "cloudtrail:UpdateTrail"],
      "Resource": "*"
    }
  ]
}

Region restrictions are popular and easy to get wrong, because global services such as IAM must stay allowed. Test every new policy on a staging OU with one representative account before attaching it to Workloads.

Control Tower packages guardrails as controls of three kinds: preventive controls implemented with SCPs and RCPs, detective controls implemented with AWS Config rules, and proactive controls that check resources before CloudFormation creates them.

Identity

People should never have IAM users with long-lived keys in workload accounts. Connect IAM Identity Center to your corporate identity provider, provision users and groups with SCIM, and grant access through permission sets assigned to groups per account: developers get power-user access in Non-prod and read-only in Prod, for example.

Keep two break-glass identities with hardware MFA, stored offline and monitored. For root users, IAM can now manage root access for member accounts centrally, introduced in November 2024, so you can remove root credentials from member accounts entirely and perform the few root-only tasks from a central place.

Logging and detection

1. An organization trail in CloudTrail records API activity in every account and region into the Log Archive account.
2. AWS Config records resource configuration everywhere, with an aggregator in Security Tooling.
3. GuardDuty and Security Hub are enabled organization-wide, with Security Tooling as delegated administrator, so new accounts are covered automatically.
4. Findings go to your security information and event management system or on-call tooling.

Networking

Workload accounts own their VPCs, but not their connectivity. The Network account provides a Transit Gateway shared through Resource Access Manager, centralized egress and inspection, DNS resolution between cloud and data center, and an IP address plan, ideally managed with Amazon VPC IP Address Manager so no two VPCs overlap. The AWS VPC diagram covers what goes inside each workload VPC, and the AWS multi-region architecture diagram covers extending the design across regions.

Building it: Control Tower or Terraform

AWS Control Tower sets up the organization, core accounts, an organization trail, Config and a catalog of controls, and provides Account Factory for creating new accounts. Landing zone version 4.0, released on November 17, 2025, made it considerably more flexible, according to the Control Tower release notes:

• The AWS Config, CloudTrail, security roles and AWS Backup integrations became optional.
• A Security OU is no longer required; you can define your own OU structure.
• A minimal setup can use only the Organizations integration and controls.
• Config and CloudTrail get dedicated resources, and a service-linked Config aggregator replaces older aggregation.

Terraform teams often combine Control Tower with Account Factory for Terraform (AFT), which provisions and customizes accounts from a Git repository. Since September 2026, AFT can run customizations in plan-only mode to preview changes before applying them. Others manage Organizations entirely in Terraform, or use the Landing Zone Accelerator on AWS solution. All three work; what matters is that account creation is automated and repeatable.

Account vending

New accounts should arrive ready to use: a request, often a pull request, creates the account in the right OU, applies the baseline (Identity Center assignments, budgets and alerts, a VPC attached to the Transit Gateway, default security services) and hands it to the team. Organizations limits an organization to 10 accounts by default, adjustable through Service Quotas, so request an increase before you need it.

Common mistakes

• Workloads in the management account, where no SCP applies.
• One flat Workloads OU, so production and development share guardrails.
• Guardrails written after teams have built on assumptions they break.
• A Log Archive account that administrators can modify.
• Accounts created by hand, each slightly different.

The landing zone diagram

How to read it:

• The management account at the top holds the organization and the policies; its edges to each OU are guardrail attachments.
• The Security OU contains Log Archive, which receives logs from every account, and Security Tooling, which administers GuardDuty and Security Hub.
• The Infrastructure OU holds the Network account, whose Transit Gateway connects workload VPCs, and Shared Services for CI/CD.
• The Workloads OU separates Prod and Non-prod accounts; the Sandbox OU stays isolated.
• IAM Identity Center on the right grants people access through permission sets.
• The Markdown block lists the starting guardrails.

Drawing account structures clearly

• Draw OUs as containers and put accounts inside them; the hierarchy is the policy model.
• Show the management account apart. It is outside your guardrails, and the picture should say so.
• Draw only the flows that cross accounts: logs to the archive, network attachments, delegated administration, identity.
• Name accounts by function, not by account number.

For the security model behind it, see the zero trust architecture diagram. If you manage infrastructure as code, the Terraform architecture diagram shows how to draw Terraform-managed environments.

Build it in Archboard

1. Sign in with Google or GitHub and create a diagram.
2. Add a Policy node from the Security pack for the management account and an Identity Provider for IAM Identity Center.
3. Add four Core Frame nodes for the OUs: Security, Infrastructure, Workloads and Sandbox.
4. In Security, add an Object Storage node from the Cloud pack for Log Archive and an Alert node from the DevOps pack for Security Tooling. In Infrastructure, add a Router from the Network pack for the Network account and a Pipeline from the DevOps pack for Shared Services.
5. Add Compute nodes from the Cloud pack for the Prod, Non-prod and Sandbox accounts.
6. Connect the management account to each OU, the accounts to Log Archive and the Network account to the workloads, and add a Markdown block from the Core pack with the guardrails.

The example uses 14 diagram nodes, within the Free plan.

FAQ

What is an AWS landing zone? A multi-account AWS environment set up according to your security and operational standards before workloads move in: organizational units, core accounts, identity, guardrails, logging and networking.

Do I need AWS Control Tower for a landing zone? No. Control Tower is the managed way to build one, and version 4.0 made it more flexible. You can also manage Organizations with Terraform, Account Factory for Terraform or the Landing Zone Accelerator.

What is the difference between an SCP and an RCP? An SCP limits what principals in member accounts can do. An RCP limits what can be done to resources in member accounts, for example preventing buckets from being shared outside the organization. Neither grants permissions.

Why should the management account stay empty? SCPs do not apply to users and roles in the management account, so anything there is outside your guardrails. It also controls billing and the organization itself, which makes it the most sensitive account you have.

How many accounts can an organization have? Ten by default. The quota is adjustable through Service Quotas, and only the management account can request the increase.

Start free — one seat, no credit card.