AWS Organizations: een multi-account strategie
Als je AWS-omgeving groeit, komt het moment dat één account met IAM-scheiding niet meer werkt. IAM-policies zijn flexibel, maar ze beschermen niet tegen accidentele fouten door iemand met brede rechten, en ze geven je geen harde kostengrens per team of omgeving. Een multi-account strategie lost beide problemen op.
Waarom meerdere accounts beter werken dan IAM alleen
In één account deelt alles hetzelfde blast radius. Een verkeerd geconfigureerde S3-bucket of een per ongeluk verwijderde RDS-instance in productie raakt alles. In een aparte account is de schade beperkt tot wat er in die account staat.
Accounts geven ook een harde resourcegrens. Service Quotas gelden per account. Als een team in een eigen account een Lambda-limiet bereikt, heeft dat geen effect op de productie-account. Met IAM in één account kun je dat niet afdwingen.
Tot slot maakt multi-account kostentoewijzing veel eenvoudiger. Elke account heeft een eigen kostenlijn in de geconsolideerde billing-view.
Hoe je accounts indeelt
Er zijn twee veelgebruikte modellen:
Account per omgeving: één account voor ontwikkeling, één voor staging, één voor productie. Eenvoudig te begrijpen, werkt goed voor kleinere organisaties en teams die gezamenlijk aan één product werken. Het nadeel is dat alle teams dezelfde productie-account delen, wat bij grotere organisaties weer een blast radius-probleem geeft.
Account per team: elk team heeft zijn eigen set accounts (development en productie per team). Meer isolatie, maar meer accounts om te beheren. Dit schaalt beter bij organisaties met tien of meer teams.
Een hybride aanpak werkt voor de meeste middelgrote organisaties: gedeelde accounts voor gedeelde diensten (netwerken, logging, security tooling) en per-team accounts voor applicatieworkloads.
Standaard te maken accounts ongeacht het model:
- Management account (alleen voor Organizations, nooit voor workloads)
- Log archive account (centrale CloudTrail en Config logs, read-only toegang)
- Security tooling account (GuardDuty, Security Hub, centrale alarmering)
- Shared services account (interne tooling, CI/CD, artifact registries)
Service Control Policies op OU-niveau
AWS Organizations groepeert accounts in Organizational Units (OU’s). Service Control Policies (SCP’s) zijn JSON-policies die je op een OU of account hangt en die een maximumgrens stellen aan wat IAM-principals in die scope mogen doen, ook als hun IAM-policy ruimer is.
Praktische voorbeelden van SCP’s:
- Blokkeer alle regio’s behalve eu-west-1 en eu-central-1 (relevant voor AVG-compliance).
- Verhinder dat root-gebruikers API-calls maken.
- Blokkeer het aanmaken van publieke S3-buckets in productie-accounts.
- Verhinder dat accounts de Organizations-lidmaatschapsconfiguratie aanpassen.
SCP’s zijn preventief, geen detectief. Ze voorkomen dat iemand iets doet dat niet mag. GuardDuty en Config detecteren wat er al gebeurd is.
Geconsolideerde billing
De management account ontvangt één gecombineerde factuur voor alle lid-accounts. AWS geeft volumekortingen op Reserved Instances en Savings Plans over alle accounts heen. Als één account een Reserved Instance ongebruikt laat, kan een andere account er automatisch van profiteren als het instance-type overeenkomt.
Dit is een concreet financieel voordeel van Organizations dat je mist als teams in losse, ongerelateerde accounts werken.
Control Tower of zelf bouwen
AWS Control Tower is een beheerde landingzone. Het zet de basisaccounts aan (log archive, audit), past een set standaard-SCP’s toe en geeft je een portal om nieuwe accounts te provisioneren via Account Factory.
Het is een goed startpunt als je geen team hebt dat de tijd heeft om dit zelf te bouwen en te onderhouden. Control Tower is opinionated: het maakt keuzes over OU-structuur en SCP-inrichting die je later kunt aanpassen, maar moeilijker kunt ombuigen als je andere eisen hebt.
Zelf bouwen (via Terraform of CDK) geeft meer controle en is de betere keuze als je al een platform-team hebt, als je afwijkende compliance-eisen hebt, of als je de flexibiliteit wilt om Account Factory te vervangen door je eigen provisioneringsproces.
De twee zijn ook te combineren: Control Tower voor de basisstructuur, custom Terraform voor aanvullende configuratie.