Why one account stops working
An AWS account is the strongest boundary AWS offers. Inside one account, a mistake in a test environment, an over-broad IAM policy or a compromised developer key can reach production. Costs are hard to separate, and so is evidence for an auditor. Separate accounts give each environment its own blast radius, its own bill and its own permissions.
Anwar has set up AWS multi-account organisations from scratch. This is a starting point that follows AWS’s published guidance.
A starting structure
AWS Organizations groups accounts into organisational units (OUs). AWS recommends these foundational OUs:
| OU | Accounts | Purpose |
|---|---|---|
| Security | Log Archive, Security Tooling | Central, tamper-resistant logs, and the security services that watch every account |
| Infrastructure | Shared networking, shared services | Resources every workload uses, such as networking and CI/CD |
| Workloads | Production, and non-production | Your applications, with production separate from everything else |
| Sandbox | One per developer or team | Experiments, with no access to production |
A growing company doesn’t need every account on day one. A sensible first step is the management account, Log Archive, Security Tooling, production and non-production. Add the rest when there’s a reason to.
Keep the management account empty
The account that owns the organisation should run no workloads. It holds billing, Organizations and IAM Identity Center, and very few people should be able to sign in to it.
Guardrails with service control policies
Service control policies (SCPs) set the maximum permissions for every account in an OU, which no one in that account can override. Start with a few that are hard to argue with, such as stopping accounts from leaving the organisation:
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "DenyLeavingOrganization",
"Effect": "Deny",
"Action": "organizations:LeaveOrganization",
"Resource": "*"
}]
}Others commonly added: stopping anyone switching off CloudTrail or GuardDuty, and limiting which regions can be used.
How people sign in
Use IAM Identity Center, connected to your identity provider, with MFA. People sign in once and choose an account and a role, with temporary credentials. There are no IAM users with long-lived keys to rotate or leak.
Moving from one account
Your existing account usually becomes production, because moving production is the riskiest step. New accounts are created around it: non-production gets rebuilt from infrastructure code, and logging and security move to their own accounts. See AWS consulting and a minimum AWS security baseline.
Sources
Next step
Still running everything in one account?
On a 30-minute call we’ll sketch the account structure that fits your company and how to move to it.