AWS Organizations from day one.

The mistake is a quiet one. You sign up for AWS, deploy the MVP, get a few customers, and along the way someone runs terraform apply against the wrong workspace, or pastes a prod IAM key into a dev script, or runs a forgotten cleanup job that finds the production S3 bucket because it lives in the same account as everything else.

It's avoidable. The fix is AWS Organizations + multiple accounts, and you should set it up before you have anything worth protecting — because retrofitting it once you do is a six-month project.

Why one account is the wrong default

One account means:

• Every IAM role with broad permissions can touch every resource you own.
• Cost attribution requires hand-tagging every resource. Tags drift. The tags lie.
• Service quotas are shared. Your dev pipeline burning EC2 instances eats prod's headroom.
• A compromised CI key is potentially a compromised production environment.
• Splitting later means migrating data between accounts, which is real engineering, not just clicking.

Multi-account flips every one of those. Resources in different accounts are physically isolated by IAM. Cost shows up per account in Cost Explorer with no tagging effort. Service quotas are per-account. Blast radius from any single mistake is contained.

The minimum viable Organization

You don't need 14 accounts on day one. You need three:

Root org (no resources, billing only)
├── management         ← the account you signed up with. Locked down.
├── Workloads OU
│   ├── prod           ← production workloads
│   └── nonprod        ← dev, staging, ephemeral envs
└── Sandbox OU
    └── sandbox        ← engineers' personal experimentation

That's it. Four accounts, free, set up in an afternoon. Each account gets its own root credentials (locked in a password manager, never used) and its own IAM Identity Center access for humans.

If you eventually need logging (centralised CloudTrail), audit, or shared services (private DNS, transit gateway), add them as separate accounts later. The point is the topology, not the account count.

SCPs are the actual superpower

Service Control Policies are organization-level guardrails that even the root user of a member account can't override. This is where blast-radius control comes from.

Three SCPs we put on every new Organization, day one:

// 1. Refuse resource creation outside EU regions (GDPR + cost predictability)
{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["eu-central-1", "eu-west-1", "us-east-1"]
    }
  }
}

(Keep us-east-1 in the allowlist for IAM, CloudFront, ACM certs for CloudFront, and Route 53 — they're global services with control planes that AWS pins there.)

// 2. Prevent leaving the Organization or disabling guardrails
{
  "Effect": "Deny",
  "Action": [
    "organizations:LeaveOrganization",
    "cloudtrail:StopLogging",
    "cloudtrail:DeleteTrail",
    "guardduty:DeleteDetector",
    "guardduty:DisassociateMembers"
  ],
  "Resource": "*"
}

// 3. Block public S3 ACLs at the org level (defence in depth)
{
  "Effect": "Deny",
  "Action": ["s3:PutBucketAcl", "s3:PutObjectAcl"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "s3:x-amz-acl": ["public-read", "public-read-write", "authenticated-read"]
    }
  }
}

Three policies, attached to the root or to specific OUs. They cost nothing and they prevent entire categories of incident.

Humans get in via IAM Identity Center

Stop creating IAM users. The pattern in 2026 for any account count above one:

1. Enable IAM Identity Center (formerly AWS SSO) in your management account.
2. Define permission sets (Admin, Developer, ReadOnly, Billing).
3. Assign humans to permission sets per account. Same human can have Admin on sandbox and ReadOnly on prod.
4. People log in via aws sso login, get short-lived credentials. No long-lived keys to leak.

If your team is on Google Workspace or Microsoft 365, wire Identity Center to that as the identity source. One sign-on, one offboarding ritual.

Retrofitting: it's not as bad as you fear

If you're already on a single-account setup, the news isn't catastrophic. The migration order we use:

1. Create the Organization and add a fresh workloads-prod account.
2. Use AWS Resource Access Manager and account-cross IAM roles to start consuming shared resources from the new account.
3. Migrate stateless workloads first (containers, lambdas, EC2 with rebuild scripts). They're easy.
4. Migrate stateful resources (RDS, S3) using the AWS service-specific migration tools. RDS Cross-Account Snapshot Sharing, S3 Batch Replication.
5. Repeat for non-prod, then sandbox.
6. The original account becomes management — strip it of workloads and use it for billing + Organization root only.

The painful part isn't the migration; it's the IAM cleanup, the hardcoded account IDs, and the ECR repos people forgot they were sharing. Plan for two months for a small system, four for anything larger than 30 services.

We set up AWS landing zones for Greek and EU teams — Organization, OUs, SCPs, Identity Center, the works. Usually 1–2 weeks. Talk to us.