Cloudarchitectuur onder controle: landing zones, identity en policy op schaal

Landing zones als architecturale contracten

Een landing zone is geen template, maar een architecturaal contract dat vastlegt hoe een account of subscription zich gedraagt binnen het grotere ecosysteem. Op schaal moet iedere landing zone standaard voorzien in centrale audit logging met niet-wijzigbare opslag, uniforme netwerksegmentatie inclusief egress- en ingress-controle, gestandaardiseerde identity-integratie met een centrale directory, verplichte taggingstructuren voor cost en ownership, baseline security policies zoals encryptie en key management en een consistente monitoring- en alertingconfiguratie.

Het cruciale ontwerpprincipe hier is idempotentie. Landing zones moeten herhaalbaar uitgerold en geüpdatet kunnen worden zonder handmatige interventie en iedere afwijking van de baseline moet automatisch detecteerbaar zijn via drift-detectiemechanismen. Dit impliceert dat landing zones volledig als code worden beheerd, onder versiebeheer staan en uitsluitend via gecontroleerde pipelines worden uitgerold. Nieuwe accounts worden niet geconfigureerd via console-interactie, maar geprovisioned via een gecontroleerd proces dat architectuurprincipes afdwingt.

De fout die veel organisaties maken, is dat landing zones initieel correct worden ingericht maar daarna niet als evoluerend architectuurcomponent worden beheerd. Op schaal vereist ook de landing zone zelf lifecyclebeheer.

Multi-account-architectuur en isolatiegrenzen

Multi-accountstrategieën zijn noodzakelijk voor isolatie en compliance, maar zonder expliciete ontwerpregels worden ze een bron van fragmentatie. Een beheersbare architectuur definieert daarom duidelijke isolatieniveaus, waarbij organisatorische isolatie per business capability wordt gecombineerd met strikte scheiding tussen productie- en niet-productieomgevingen, data-isolatie op basis van classificatie en netwerkisolatie via gescheiden virtuele netwerken.

Cross-accountcommunicatie moet expliciet ontworpen zijn en herleidbaar zijn tot een functionele noodzaak. Dat betekent dat identity federation centraal wordt ingericht, dat het aantal cross-account-IAM-rollen strikt wordt geminimaliseerd, dat netwerkpeering alleen plaatsvindt via gecontroleerde hubs en dat full-meshconnectiviteit tussen domeinen principieel wordt vermeden.

Het aantal accounts op zich is zelden het probleem. Het ontbreken van duidelijke onderlinge relaties en isolatieprincipes is dat wel.

Identity-architectuur als primaire controlelaag

In cloud is identity de dominante controlelaag. Netwerkbeveiliging zonder identitydiscipline is onvoldoende. Op schaal vereist identity-architectuur expliciete scheiding tussen menselijke en machine-identiteiten, waarbij menselijke toegang altijd via federatie en sterke authenticatie verloopt en machine-identiteiten minimaal privilege hanteren en automatisch roteren via geautomatiseerde processen.

Daarnaast moeten rollen hiërarchisch en systematisch ontworpen zijn. Rollen worden niet per applicatie gedefinieerd, maar per privilegecategorie, waardoor een beheersbare rolcatalogus ontstaat in plaats van duizenden unieke policies. Permanente elevated access is een ontwerpfout; tijdelijke rechten moeten standaard verlopen en via geautomatiseerde workflows worden toegekend en ingetrokken.

Identity drift ontstaat wanneer rollen lokaal worden aangepast zonder centrale controle. Daarom moet IAM-configuratie volledig onder versiebeheer staan en via code worden uitgerold, niet via handmatige console-interacties.

Policy-as-code en afdwingbaarheid

Architectuur zonder afdwinging is intentie. Op schaal moet ieder architectuurprincipe vertaald worden naar technische policies die automatisch worden geëvalueerd bij resourcecreatie en -wijziging. Dat betekent dat resources zonder encryptie standaard worden geweigerd, niet-getagde resources automatisch worden geblokkeerd of gemarkeerd, publieke endpoints alleen toegestaan zijn binnen vooraf gedefinieerde categorieën en netwerkconfiguraties automatisch worden gevalideerd tegen vastgelegde regels.

Policy engines fungeren hierbij als realtime architectuurcontrole. Drift detection blijft essentieel, want zelfs met policy-as-code kunnen configuraties wijzigen door updates of nieuwe services. Continue compliance scanning moet afwijkingen detecteren voordat ze incidenten veroorzaken. Een volwassen architectuur accepteert dat afwijkingen mogelijk zijn, maar tolereert geen onzichtbare afwijkingen.

Netwerkarchitectuur en Zero Trust

Traditionele perimeterbeveiliging verliest betekenis in cloudomgevingen. Netwerkarchitectuur moet daarom gebaseerd zijn op expliciete trust boundaries, waarbij gescheiden netwerklagen per domein worden ingericht, egress-verkeer gecontroleerd en gemonitord wordt en ingress centraal wordt afgehandeld via gecontroleerde gateways.

Zero Trust betekent in deze context dat iedere service-interactie expliciet gevalideerd wordt op basis van identiteit en context. Full mesh-netwerken verhogen flexibiliteit, maar vernietigen overzicht en vergroten blast radius. Hub-and-spoke-architecturen met gecontroleerde transitpunten verhogen daarentegen beheersbaarheid en beperken onbedoelde afhankelijkheden.

Observability op platformniveau

In multi-accountomgevingen moet observability boven de workloadlaag uitstijgen. Auditlogs, netwerkflows, IAM-events en policy violations moeten centraal worden geaggregeerd en genormaliseerd, zodat correlatie over accounts en regio’s heen mogelijk wordt.

Logs uit verschillende accounts moeten dezelfde structuur volgen, zodat analyse geen handmatige interpretatie vereist. Zonder platformbrede observability blijft architectuur blind voor systeemgedrag en wordt elk incident een forensische oefening.

Cost-architectuur als technische discipline

Kostenbeheersing op schaal vereist architecturale keuzes. Dat betekent dat taggingstandaarden automatisch worden afgedwongen, dat resource lifecycle policies ongebruikte resources automatisch opruimen of archiveren, dat reserved capacity centraal wordt geoptimaliseerd en dat cost anomalies per domein realtime zichtbaar zijn.

Cost telemetry moet geïntegreerd zijn in observability, omdat kosten zonder realtime zichtbaarheid niet bestuurbaar zijn. Kosten die pas aan het einde van de maand zichtbaar worden, zijn architecturaal gezien al te laat.

Regionaal ontwerp en resilience-design

Grootschalige cloudomgevingen vereisen expliciete keuzes over regionale spreiding en redundantie. Multi-regiondesign verhoogt beschikbaarheid, maar verhoogt ook complexiteit en kosten. Daarom moet per workloadcategorie worden vastgelegd welke redundantie is vereist, welke datasynchronisatie is vereist en welke recovery time objectives gelden.

Cross-region replication mag geen impliciete standaard zijn, maar een bewuste architecturale beslissing die past bij het risicoprofiel van de workload.