Wat een verkeerd gebouwde landing zone je kost.
De structuren die we het vaakst erven
Drie patronen verschijnen keer op keer als we een cloud-estate overnemen die twee of meer jaar heeft gedraaid. Het eerste is de single-account-monoliet: alle omgevingen, alle teams, alle services in één AWS-account of Azure-subscriptie, gescheiden door naamconventie en de hoop dat niemand een security group misconfigureert. Het tweede is het flat network: een VPC of VNet zonder subnet-segmentatie, directe peering tussen productie en ontwikkeling, en een gedeelde NAT-gateway voor workloads met heel verschillende blast radii. Het derde is de ontbrekende guardrail-laag: geen Service Control Policies, geen Azure Policy, geen organisatie-brede budgetwaarschuwingen. Elk team heeft toegang tot iets wat het niet zou moeten hebben.
Deze patronen zijn niet het resultaat van slechte engineering. Ze zijn het resultaat van landing zones gebouwd door teams die snel bewogen en de schaaldrempel nog niet hadden bereikt waarop de structuur een verplichting wordt. Die drempel ligt doorgaans tussen de 15 en 30 engineers, of tussen één en drie teams die productieservices beheren. Onder de drempel is structuur overhead. Boven de drempel is de afwezigheid van structuur de overhead.
Wat retroactief aanpassen werkelijk kost
Een landing zone retroactief aanpassen op een draaiende estate is geen technisch project. Het is een coördinatieproject met technische afhankelijkheden. Elke wijziging aan account-structuur, netwerktopologie of identiteitsmodel raakt iets waar een team al op vertrouwt. De migratievolgorde telt meer dan de doelarchitectuur.
Op de estates die we hebben gemigreerd, valt het werk ruwweg als volgt uiteen. Account-structuur en factureringsreorganisatie: 2 tot 3 weken, voornamelijk coördinatie met finance en de cloudleverancier. Netwerk-re-architectuur, herindeling van subnets, vervanging van NAT-gateways door VPC-endpoints, bedrading van PrivateLink: 4 tot 6 weken met 2 tot 4 geplande onderhoudsvensters en een reële kans op een ongeplande storing. Beveiligingsbaseline-uitrol, SCP's, Azure Policy, IAM-opruiming, secrets-rotatie: 3 tot 4 weken, waarbij 20 tot 40 individuele bevindingen naar boven komen die elk afzonderlijk opgelost moeten worden. Identiteitsmigratie van langdurige sleutels naar kortdurende rol-aanname: minimaal 2 tot 3 weken.
Totaal: 11 tot 16 weken aaneengesloten platform-team-inspanning, waarbij het team weinig nieuwe features levert. Op een team van 3 tot 5 platform-engineers is dat de volledige team-capaciteit voor een kwartaal. Dezelfde landing zone, correct gebouwd vanaf het begin, kost 3 tot 5 weken.
De vijf beslissingen die op dag nul tellen
Eén: account-hiërarchie. Besluit hoe je omgevingen (prod, non-prod), business units en beveiligingsgrenzen scheidt in afzonderlijke accounts of subscripties. De AWS Organizations- of Azure Management Group-hiërarchie is moeilijker te wijzigen dan bijna alles anders in de estate.
Twee: netwerktopologie. Besluit over hub-and-spoke of mesh vóórdat je de eerste VPC aanmaakt. Besluit welke services VPC-endpoints en PrivateLink gebruiken in plaats van publieke endpoints. Dit later veranderen is meetbaar in onderhoudsvensters en applicatie-herwerk.
Drie: identiteitsmodel. Besluit over één identiteitsprovider, gefedereerd over alle accounts, vanaf het begin. Geen enkele menselijke gebruiker heeft langdurige toegangssleutels. De migratie van langdurige sleutels naar kortdurende rol-aanname is het meest verstorende onderdeel van elke retroactieve aanpassing.
Vier: facturering en tagging. Besluit over het kostenallocatiemodel en het tag-schema voordat je de eerste resource aanmaakt. De sessie over tag-policy duurt twee uur. Het retroactieve tag-project duurt drie maanden.
Vijf: beveiligingsbaseline. Deploy SCP's of Azure Policy vanuit de organisatieroot op dag één. De verzameling dingen die je per ongeluk niet kunt doen is vroeg meer waard dan elke later toegevoegde guardrail.
"De landing zone die fout gebouwd is bij 20 engineers kost 14 weken platform-capaciteit om te herstellen bij 80. Goed gebouwd vanaf het begin kost vier."
Maikel Vlasman / Cloud Architect
Hoe correct eruitziet voor EU mid-market
Voor een team van 20 tot 100 engineers met 2 tot 6 productlijnen is de juiste landing zone niet de AWS- of Azure-referentiearchitectuur zonder aanpassing. De referentiearchitecturen zijn ontworpen voor onbegrensde schaal en gaan uit van capaciteiten die de meeste mid-market-teams niet hebben: een dedicated security-team, 24/7 SOC, dedicated FinOps-functie.
Wat werkt in de praktijk: drie account-tiers (management, beveiliging, workloads), met workload-accounts gesplitst op omgeving en productlijn boven een bepaalde teamomvang. Eén transit-VPC voor gedeelde services. VPC-endpoints voor al het AWS-serviceverkeer dat ze ondersteunt. OIDC-federatie voor CI/CD-identiteit, waarmee deploy-keys volledig worden vervangen. SCP's die publieke S3-buckets voorkomen en ongebruikte regio's uitschakelen. Een kostenallocatiemodel dat gedeelde infrastructuur scheidt van workload-uitgaven vanaf de eerste factureringscyclus.
Voor EU-bedrijven die onder NIS2 of DORA vallen, horen er twee extra lagen in de landing zone vanaf dag één: een onveranderbare auditlog-architectuur met een schrijfbeveiligd doel, en een account-structuur die het mogelijk maakt om automatisch een ICT-afhankelijkheidskaart te genereren. Beide zijn veel goedkoper in de structuur te bouwen dan achteraf toe te voegen.