AWS Landing Zones met CDK

Je AWS-account is geen strategie. Tien onbeheerde accounts? Dat is een risico dat vanzelf bovenkomt bij je volgende audit.

We hebben dit uit ervaring geleerd. Toen we begonnen met het bouwen van landing zones voor bedrijven was het patroon altijd hetzelfde. Inconsistente security baselines. Developers die accounts aanmaken zonder enige guardrail. Een netwerkopzet bij elkaar gehouden door stamkennis en een Confluence-pagina die sinds 2021 niet meer is bijgewerkt.

Een landing zone lost dit op. Het is het fundament dat governance, security, kostenbeheersing en snelheid van ontwikkeling werkelijk laat samenwerken. Maar hoe je die landing zone bouwt, is minstens zo belangrijk als dat je er überhaupt een bouwt.

Waarom enterprises een multi-account strategie nodig hebben

Je weet wat een AWS-account is. De vraag die er echt toe doet: waarom hebben organisaties met 5, 50 of 500 accounts een geformaliseerde aanpak nodig?

Blast radius beperken. Een verkeerd geconfigureerde IAM-rol in dev mag geen productiedata kunnen raken. Isolatie op account niveau is de sterkste grens die AWS biedt. Sterker dan VPCs, sterker dan IAM-policies. Gebruik het.

Compliance op schaal. AVG, SOC 2, NIS2. Het regelgevingslandschap blijft groeien. Handmatig elk account auditen is een verloren strijd. Je hebt guardrails nodig die overtredingen voorkomen, geen detective werk dat ze vindt als de schade al is aangericht.

Kosten visibiliteit. Zonder goede account structuur en afdwinging van tags vliegt je FinOps-team blind. We hebben organisaties gezien die zes cijfers aan niet-toe-te-wijzen kosten verbranden, simpelweg omdat niemand tagging vanaf dag één afdwong.

Developer velocity. Dit verrast mensen. Goede governance vertraagt teams niet. Wanneer een developer zelf een nieuw account kan aanvragen dat vooraf geconfigureerd komt met networking, logging en security baselines, shipt die sneller dan het team dat drie weken wacht tot IT alles handmatig heeft ingericht. We hebben dit bij klanten met eigen ogen gezien: goed ingerichte account vending maakte van een wekenlang proces een kwestie van minuten.

De bouwstenen van een landing zone

Elke enterprise landing zone heeft deze componenten nodig, ongeacht welke tooling je kiest.

1. Account vending

Geautomatiseerde accountcreatie met vooraf geconfigureerde baselines. Een developer vraagt een workload-account aan en krijgt binnen minuten:

• Een account in de juiste OU met de juiste SCPs
• VPC met gestandaardiseerde CIDR-ranges, gekoppeld aan Transit Gateway of toegang tot een shared VPC
• CloudTrail, GuardDuty, Config en Security Hub ingeschakeld
• IAM Identity Center-toegang geconfigureerd
• Budget alerts ingesteld

Geen tickets. Geen wachten. Geen handmatige opzet waarbij iemand een stap vergeet.

We behandelen account vending als een intern product, niet als een eenmalig project. Het heeft versioning, testing en een backlog nodig. De teams die accounts afnemen zijn je gebruikers, en hun ervaring doet ertoe.

2. Guardrails: SCPs en Config Rules

Service Control Policies zijn je eerste verdedigingslinie. Ze definiëren wat niet kan, ongeacht IAM-permissies:

• Voorkomen dat CloudTrail of GuardDuty wordt uitgeschakeld
• Deployments beperken tot goedgekeurde regio’s (eu-west-1, eu-central-1, essentieel voor de AVG)
• Publieke S3 buckets en onversleutelde EBS volumes blokkeren
• Specifieke tags vereisen op alle resources

AWS Config rules vullen SCPs aan door continu drift te detecteren. Samen: preventieve én detectieve controles.

Ons advies? Begin streng. Zet alles op slot. Het is véél makkelijker om een guardrail te versoepelen voor een legitieme use case dan om er achteraf een af te dwingen nadat teams eromheen hebben gebouwd.

3. Networking

Transit Gateway als ruggengraat, die workload-VPCs verbindt met shared services en on-premises netwerken. De belangrijkste keuzes:

• Hub-and-spoke vs. Shared VPC’s
• Gecentraliseerde vs. gedistribueerde egress
• DNS-resolutiestrategie (Route 53 Resolver rules)
• Plaatsing van Network Firewall

Krijg je networking niet goed, dan heeft de rest daar last van. Dit is consequent waar we de meeste technical debt zien bij organisaties die hun AWS-footprint organisch hebben laten groeien.

4. Identity en access

IAM Identity Center voor menselijke toegang. Federeer met je bestaande IdP (Entra ID, Okta) en definieer permission sets die aansluiten bij je organisatierollen.

Voor machine-to-machine: IAM roles met duidelijk afgebakende policies. Cross-account toegang via role assumption. Nooit langlevende credentials. We verbazen ons er nog steeds over hoeveel enterprise-omgevingen we tegenkomen met statische access keys die ouder zijn dan sommige teamleden die ze gebruiken.

5. Gecentraliseerde logging en security

Een dedicated Log Archive-account dat verzamelt:

• CloudTrail organization trails
• VPC Flow Logs
• Config snapshots en compliance-historie
• GuardDuty- en Security Hub-bevindingen

Een apart Security Tooling-account draait je automatisering: remediation lambdas, SIEM-integraties, compliance dashboards. Houd security tooling gescheiden van de logs waar het op acteert.

Wat de documentatie je niet vertelt

We hebben er genoeg gebouwd om te weten waar de echte valkuilen zitten. Dit hadden we graag eerder geweten.

Test je landing zone als software. We gebruiken CDK’s assertion testing om te valideren dat constructs de verwachte CloudFormation-output produceren. We testen SCPs tegen realistische scenario’s. We draaien cdk-nag in CI. Infrastructuurcode verdient dezelfde kwaliteitslat als applicatiecode. De meeste organisaties behandelen het niet zo, en dat betalen ze later.

Negeer day-two operaties niet. Een landing zone die prachtig deployt maar niet veilig ge-update kan worden, is een tikkende tijdbom. Ontwerp vanaf het begin voor incrementele updates. CDK’s cdk diff en gefaseerde rollouts maken dit beheersbaar, maar alleen als je er vooraf voor plant.

FinOps vanaf dag één. Bak cost allocation tags, budget alerts en anomaly detection in je baseline. Kostenvisibiliteit achteraf inbouwen na 18 maanden ongetagde resources is pijnlijk en duur. We hebben klanten geholpen hun AWS-rekening met 30% te verlagen, puur door goede tagging en accountstructuur in te richten. Dat is geen optimalisatie, dat is zichtbaarheid.

Code-eigenaarschap is niet onderhandelbaar. Dit zit in het DNA van hoe we bij Forrict werken. Elke regel CDK-code die we schrijven voor je landing zone? Die is van jou. De Git-repo, de pipeline, het deploymentproces, alles van jou. We creëren geen vendor lock-in naar onszelf. Als wij weggaan, moet je je landing zone zelfstandig kunnen onderhouden en doorontwikkelen. Dat is freedom through craftsmanship.

Klaar om je AWS-fundament te bouwen?

Een degelijke landing zone is het verschil tussen een AWS-omgeving die met vertrouwen schaalt en een die kwetsbaarder wordt naarmate je groeit. De investering verdient zichzelf terug in security posture, compliance readiness, developer productivity en kostenvisibiliteit.

Bij Forrict bouwen we landing zones die volledig van jou zijn. Geen proprietary tools, geen managed-service lock-in. Solide CDK-code, beproefde patronen en de kennisoverdracht om het zelf te draaien.

Wil je je AWS-fundament goed neerzetten? Laten we praten.