
Een grote enterprise liep vast in de manier waarop AWS-infrastructuur werd geprovisioned naarmate het cloudgebruik groeide. Handmatig deployment scripts draaien voldeed niet meer: accounts en omgevingen werden onoverzichtelijk, er was geen deployment history en het gebruik van Infrastructure as Code was nergens afgedwongen.
Multi-account AWS landing zone als basis voor schaalbare provisioning.
Van handmatige scripts naar volledig geautomatiseerde provisioning via een pipeline.
CloudFormation als basis, met deployment history en versioning in Git.
Eén plek waar accounts, omgevingen en baselines worden beheerd.
Een security baseline die op elk account wordt afgedwongen, niet alleen aanbevolen.
Teams provisionen accounts en resources zelf, binnen vooraf gedefinieerde guardrails.
De klant wilde één centrale definitie van het volledige public cloud-platform als code, gecombineerd met een versiebeheerbare deployment pipeline: een klassieke Infrastructure as Code-aanpak. Een cloud landing zone moest het mogelijk maken cloudgebruik te laten groeien zonder dat elk extra account of elke extra resource ook meteen extra beheerlast oplevert. De pipeline moest daarbij zekerheid geven over uniformiteit en security van de landing zone-automatisering zelf.
We zijn begonnen met het volledig in kaart brengen van de bestaande deployment-aanpak en de specifieke eisen van de klant. Op basis daarvan is een ontwerp gemaakt voor zowel de huidige als toekomstige infrastructuur, met het AWS-raamwerk voor landing zones als startpunt. De architectuur is ontworpen rond een GitOps-werkwijze: elke wijziging aan de super-infrastructure of de componenten daarbinnen start vanuit de code-repo als single source of truth.
Tijdens de implementatie liepen we tegen een aantal concrete knelpunten aan. Veel baseline resources gebruikten AWS API-calls die niet rechtstreeks via CloudFormation beschikbaar zijn. Daarvoor hebben we Lambda-backed custom resources ingezet, met een zorgvuldig ontwerp van CREATE, UPDATE en DELETE zodat idempotency over de hele baseline gewaarborgd bleef.
Sommige baseline resources vroegen om gesynchroniseerde stappen met core accounts. Om immutability en idempotency te behouden, gebruikten we cross-account roles, zodat baseline resources als self-contained resource definitions konden blijven functioneren.
De bestaande code-repository integreerde niet goed met CI/CD-tooling. We hebben de repo verhuisd naar een self-hosted GitLab-server en de pipeline gebouwd op GitLab CI, aangevuld met enkele custom componenten voor de use cases van de klant.
De landing zone stelde de klant in staat nieuwe accounts te provisionen via een Account Vending Machine (AVM): een set Lambda-backed custom resources die AWS Organizations-accounts automatisch aanmaakt, inclusief een baseline. Die baseline omvat onder andere:
De AVM is uitgeleverd als AWS Service Catalog-product en gedeeld met nested Organization Units (OUs). Zo kon de provisioning van nieuwe accounts naar business units worden gedelegeerd, terwijl de security baseline voor elk nieuw account afgedwongen blijft. Updates aan de AVM-baseline werden bovendien automatisch overgenomen.
Een landing zone is de basis onder een cloudplatform: security, compliance, IAM/RBAC, networking, billing, logging, monitoring en auditing: samen met de productconfiguratie voor specifieke workloads. We leveren landing zones met Infrastructure as Code, zodat uitrol consistent, betrouwbaar en herhaalbaar blijft.
Bekijk de dienst