Why one AWS account isn't enough

Most AWS journeys start the same way. Someone creates an account with a company credit card, launches a few things, and it works. Then more teams arrive, production and testing share the same account, someone has admin rights who shouldn't, and nobody can tell which resources belong to which project.

The fix is a multi-account setup, usually called a landing zone. It sounds like enterprise bureaucracy, but it's one of the best investments a growing company can make in AWS. (Azure and Google Cloud have similar concepts, which I'll cover at the end.)

Why split accounts

An AWS account is the strongest isolation boundary AWS offers. Separate accounts give you:

• Security isolation. A compromised developer account can't touch production.
• Blast radius limits. A runaway script or misconfiguration stays in one account.
• Clear cost allocation. Each account's bill belongs to a team or environment.
• Service quotas per account, so one team can't exhaust limits for everyone.
• Simpler permissions. Instead of complex IAM policies separating teams in one account, you give teams access to their own accounts.
• Compliance scoping. Regulated workloads (like payment processing) live in their own accounts with stricter controls, limiting what auditors need to look at.

A typical account structure

AWS Organizations lets you manage many accounts centrally and group them into Organizational Units (OUs):

Root (management account: billing and organisation only)
├── Security OU
│   ├── Log Archive      (central, immutable logs)
│   └── Security Tooling (GuardDuty, Security Hub, audit access)
├── Infrastructure OU
│   ├── Network          (Transit Gateway, shared networking, DNS)
│   └── Shared Services  (CI/CD, container registry)
├── Workloads OU
│   ├── Prod OU
│   │   ├── shop-prod
│   │   └── search-prod
│   └── Non-Prod OU
│       ├── shop-staging
│       └── shop-dev
└── Sandbox OU
    └── personal and experiment accounts (with budgets)

Key rules: don't run workloads in the management account, and keep logs in a separate account that workload teams can't modify.

Accounts are cheap. Untangling a single shared account later is very expensive.

Organizations, Control Tower and SCPs

AWS Organizations provides the hierarchy, consolidated billing and policies.

Service Control Policies (SCPs) are guardrails applied to OUs or accounts. They define the maximum permissions anyone in those accounts can have, even administrators. Examples:

• Deny use of regions you don't operate in.
• Deny disabling CloudTrail, GuardDuty or AWS Config.
• Deny leaving the organisation.
• Deny creating IAM users with long-lived access keys.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideEU",
    "Effect": "Deny",
    "NotAction": ["iam:*", "organizations:*", "sts:*", "support:*", "cloudfront:*", "route53:*"],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": { "aws:RequestedRegion": ["eu-central-1", "eu-west-1"] }
    }
  }]
}

(Global services are excluded because they're served from US regions.)

AWS has also added Resource Control Policies for guardrails on resources, and declarative policies for enforcing service configurations across accounts.

AWS Control Tower automates setting up a landing zone: it creates the core accounts (log archive, audit), configures guardrails, and offers an Account Factory to create new accounts with a standard baseline. It's the quickest way to start. For more customisation, many teams use Account Factory for Terraform (AFT) or manage accounts entirely with Terraform.

Access: IAM Identity Center

Don't create IAM users in each account. Use IAM Identity Center (formerly AWS SSO) connected to your company identity provider (Entra ID, Okta, Google Workspace):

• People log in once and choose which account and role to use.
• Permission sets define roles like ReadOnly, Developer, Admin.
• Access is granted by group, and removed automatically when people leave.
• The CLI uses short-lived credentials (aws sso login).

Connecting it all

Accounts are isolated by default, so networking needs a plan:

• A Network account with Transit Gateway connecting VPCs across accounts, or VPC sharing (RAM) to share subnets.
• Plan IP ranges centrally (AWS IPAM helps) so VPCs don't overlap.
• Centralised egress and inspection where needed, for example shared NAT or firewalls.
• Route 53 private hosted zones shared across accounts for internal DNS.

Security baseline in every account

Applied automatically to every new account:

• CloudTrail (organisation trail) to the Log Archive account
• GuardDuty, Security Hub and AWS Config, managed from the Security Tooling account
• Default EBS encryption, S3 Block Public Access
• Budgets and cost alerts
• Standard IAM roles for CI/CD with OIDC

Azure and GCP equivalents

• Azure: management groups and subscriptions, with Azure Policy as guardrails. Microsoft's Azure landing zone reference architecture (part of the Cloud Adoption Framework) is the equivalent of Control Tower.
• Google Cloud: the resource hierarchy of organisation, folders and projects, with Organization Policies. Google provides a landing zone blueprint and Terraform foundation modules.

The concepts are the same: a hierarchy, isolation per environment and team, central guardrails, central logging and identity.

So, where do I start?

If you're still in one account, set up AWS Organizations and Control Tower now, create separate production and non-production accounts, and move new workloads there. Migrate old workloads gradually. If you already have many accounts, check that SCPs, central logging and Identity Center are in place.

My take: a landing zone is the foundation of your cloud house. It's boring to build, and you'll be grateful for it every day afterwards.

— Desly