Azure Landing Zones: Wat Ik Had Willen Weten Voor Mijn Eerste Enterprise-Scale Deployment
In dit artikel
- Wat Enterprise-Scale Je Eigenlijk Geeft
- De Management Group Hierarchy: Volg Het Tot Je Een Reden Hebt Om Af Te Wijken
- Azure Policy: Je Krachtigste Tool en Je Grootste Valkuil
- Networking: Hub-Spoke vs Virtual WAN
- De Identity Subscription Is Niet Optioneel
- De Referentie-Implementaties Zijn Startpunten
- Veelgemaakte Fouten Die Ik Blijf Tegenkomen
- Wat Ik De Volgende Keer Anders Zou Doen
Microsoft heeft net de Enterprise-Scale architectuur gepubliceerd als onderdeel van het Cloud Adoption Framework. Het is de meest uitgesproken, productierijpe Azure-basis die ze ooit hebben uitgebracht. Een volledige Management Group hierarchy, policy-driven governance, hub-spoke networking, gecentraliseerde logging en identity isolation: alles aan elkaar gekoppeld en ondersteund door referentie-implementaties die je vandaag nog kunt deployen.
Na deze architectuur de afgelopen maanden voor meerdere organisaties te hebben geimplementeerd (we hadden vroegtijdige toegang via het design partner programma), zijn dit de dingen die ik graag had geweten voor de eerste deployment.
Wat Enterprise-Scale Je Eigenlijk Geeft
De architectuur is geen diagram om naar te kijken. Het is een deploybaar framework dat het volgende provisioneert:
- Een Management Group hierarchy die platformzaken (identity, management, connectivity) scheidt van workload landing zones
- Azure Policy assignments die governance guardrails afdwingen vanaf de root: deny public IPs op NICs, verplichte disk encryption, verplichte resource tagging
- Hub-spoke networking met gecentraliseerde DNS, firewall en gateway-infrastructuur
- Gecentraliseerde logging via een platform Log Analytics workspace met diagnostic settings die vanuit elke subscription doorstromen
- Subscription vending patronen waarmee je voorgeconfigureerde subscriptions kunt uitdelen aan applicatieteams
Dit is geen whitepaper. Het is infrastructure as code die je deployt, en het werkt. Maar “werkt” en “werkt voor jouw organisatie” zijn twee verschillende dingen.
Azure docs: Enterprise-Scale architecture · Design principles
De Management Group Hierarchy: Volg Het Tot Je Een Reden Hebt Om Af Te Wijken
De aanbevolen hierarchy ziet er zo uit:
Tenant Root Group
└── Your Organisation
├── Platform
│ ├── Identity
│ ├── Management
│ └── Connectivity
├── Landing Zones
│ ├── Corp (interne workloads)
│ └── Online (internet-facing workloads)
├── Sandbox
└── DecommissionedElke keer dat ik iemand op dag een deze hierarchy zag proberen te “verbeteren”, door extra niveaus toe te voegen voor business units, geografische regio’s of cost centres, hadden ze er binnen een paar maanden spijt van. Management Groups zijn governance boundaries, geen organogrammen. Als je zes niveaus diep nest omdat je bedrijf zes divisies heeft, eindig je met policy inheritance chains die niemand kan debuggen en RBAC assignments die elkaar tegenspreken.
Begin met de referentie-hierarchy. Voeg alleen een niveau toe wanneer je een concreet policy- of RBAC-vereiste hebt dat niet op een andere manier op te lossen is. De meeste organisaties hebben hoogstens een extra tier nodig onder Landing Zones, en zelfs dat is vaak overbodig.
De Sandbox management group is het vermelden waard. Die staat buiten de Landing Zones branch, wat betekent dat er minimale policies worden overgeerfd. Dat is bewust zo. Geef developers een subscription onder Sandbox met een budget alert en soepele guardrails. Ze kunnen vrij experimenteren zonder policy violations te veroorzaken. Wanneer de workload klaar is voor productie, verhuist die naar een Landing Zone subscription met volledige governance. Dit patroon elimineert 80% van de klachten over “Azure Policy blokkeert mijn deployment”.
Azure docs: Management Group hierarchy · Subscription organisation
Azure Policy: Je Krachtigste Tool en Je Grootste Valkuil
Enterprise-Scale wordt geleverd met een verzorgde set policy assignments. De belangrijkste:
- Deny public IP addresses op network interfaces: dwingt verkeer af via gecentraliseerde networking
- Enforce encryption at rest voor storage accounts en managed disks
- Verplichte specifieke tags op resource groups (cost centre, environment, owner)
- Deploy diagnostic settings automatisch naar de centrale Log Analytics workspace
- Audit of deny non-compliant SKUs om kosten en security posture te beheersen
Deze policies zijn in principe correct. Het probleem is de timing. Als je elke policy op dag een op de root Management Group inschakelt, blokkeer je legitieme deployments van teams die midden in een migratie zitten. Een developer die een proof of concept probeert te deployen, loopt tegen een deny-muur aan, escaleert naar het platform team, en plots wordt je zorgvuldig ontworpen governance framework gezien als een obstakel in plaats van een guardrail.
De pragmatische aanpak: deploy policies eerst in Audit mode. Laat ze twee tot vier weken non-compliance rapporteren. Bekijk het compliance dashboard. Identificeer welke violations echte risico’s zijn en welke verwachte patronen zijn die exemptions nodig hebben. Schakel dan over naar Deny, met exemptions die al op hun plaats staan.
Policy exemptions zijn geen teken van zwakte. Ze zijn het mechanisme dat governance houdbaar maakt. Een storage account dat publieke blob access nodig heeft voor een CDN origin is geen policy failure: het is een gedocumenteerde uitzondering met een zakelijke rechtvaardiging. Bouw het exemption-proces vanaf het begin in je operating model in.
Azure docs: Policy-driven governance · Azure Policy exemption structure
Networking: Hub-Spoke vs Virtual WAN
Enterprise-Scale ondersteunt beide topologieen. De keuze is belangrijker dan je denkt.
Hub-spoke met Azure Firewall is de juiste standaard voor de meeste organisaties. Je hebt volledige controle over routing, directe peering tussen spokes wanneer nodig, en een networking model dat elke engineer begrijpt. De hub VNet is van jou: jij bepaalt wat erin komt.
Virtual WAN is de juiste keuze wanneer je meerdere Azure-regio’s hebt met complexe branch connectivity (SD-WAN integratie, tientallen VPN sites) en je wilt dat Microsoft de routing mesh beheert. Virtual WAN vereenvoudigt multi-region transit, maar je ruilt controle in voor gemak. Je kunt geen willekeurige resources deployen in de Virtual WAN hub, en troubleshooting van routing wordt moeilijker omdat de onderliggende infrastructuur managed is.
De fout die ik het vaakst zie: Virtual WAN kiezen omdat het meer “enterprise” klinkt, zonder de multi-region, multi-branch vereisten te hebben die het rechtvaardigen. Als je een Azure-regio en een ExpressRoute circuit hebt, is hub-spoke eenvoudiger, goedkoper en geeft het je meer flexibiliteit.
Welke topologie je ook kiest, neem de beslissing voor je Enterprise-Scale deployt. Overschakelen van hub-spoke naar Virtual WAN (of omgekeerd) achteraf betekent de hele connectivity subscription opnieuw deployen. Dit is geen instelling die je even omzet.
Azure docs: Network topology and connectivity · Virtual WAN overview
De Identity Subscription Is Niet Optioneel
De Platform > Identity subscription host je domain controllers (als je Active Directory in Azure draait), DNS forwarders en alle identity-infrastructuur waar workloads van afhankelijk zijn. Het is verleidelijk om dit samen te voegen met de Connectivity subscription of het helemaal over te slaan als je denkt “wij gebruiken alleen Azure AD.”
Doe het niet. Zelfs in een pure Azure AD omgeving heb je uiteindelijk Private DNS zones nodig voor private endpoints, conditional forwarders voor hybride resolutie, of een managed domain service. Een dedicated subscription met een eigen RBAC boundary betekent dat het identity team onafhankelijk kan werken van het networking team. Die scheiding is belangrijk wanneer je 50 subscriptions hebt en drie teams die het platform beheren.
Azure docs: Identity and access management
De Referentie-Implementaties Zijn Startpunten
Microsoft biedt referentie-implementaties aan in Bicep en Terraform. Ze zijn uitstekend om mee te beginnen. Het zijn geen afgewerkte producten.
Elke organisatie waarmee ik heb gewerkt, moest de referentie-implementaties aanzienlijk aanpassen:
- Custom policy definitions voor organisatiespecifieke vereisten (naming conventions, goedgekeurde regio’s, verplichte diagnostic categories)
- Integratie met bestaande CI/CD pipelines: de referentie-implementaties gaan uit van een specifiek deployment model dat zelden overeenkomt met wat teams al gebruiken
- State management: Terraform state backends, Bicep deployment stacks en de branching strategy voor platformwijzigingen vragen allemaal om ontwerpbeslissingen
- Module structure: de monolithische deployment opsplitsen in composable modules die verschillende teams onafhankelijk kunnen beheren en doorontwikkelen
Behandel de referentie-implementaties als een leermiddel en een bron van patronen. Haal eruit wat je nodig hebt, pas het aan op je operating model en neem eigenaarschap over het resultaat. Het hele repository forken en proberen in sync te blijven met upstream wijzigingen is een pad naar frustratie.
Azure docs: ALZ Bicep modules · ALZ Terraform module
Veelgemaakte Fouten Die Ik Blijf Tegenkomen
Te veel Management Groups. Elk extra niveau voegt cognitieve overhead en policy debugging complexiteit toe. Als je niet in een zin kunt uitleggen waarom een Management Group bestaat, verwijder die dan.
Policies die blokkeren zonder alternatieven. Public IPs weigeren is correcte governance. Public IPs weigeren zonder een gedocumenteerd pad naar private endpoints, Private Link en gecentraliseerde NAT te bieden, is gewoon werk blokkeren. Elke Deny policy heeft een bijbehorende “zo doe je het correct” handleiding nodig.
Geen exemption-proces. Teams zullen uitzonderingen nodig hebben. Als het enige pad “maak een ticket aan en wacht twee weken” is, gaan ze om je governance heen werken in plaats van erdoorheen. Bouw een lichtgewicht, auditeerbaar exemption-workflow.
Alles in een keer deployen. Enterprise-Scale is modulair by design. Begin met Management Groups en policies. Voeg networking toe wanneer je er klaar voor bent. Onboard workloads een subscription per keer. De organisaties die slagen zijn degenen die dit behandelen als een geleidelijke uitrol, niet als een big-bang migratie.
Het compliance dashboard negeren. Azure Policy compliance is alleen nuttig als iemand ernaar kijkt. Wijs een eigenaar toe aan het compliance dashboard en bekijk het wekelijks. Non-compliance die maanden blijft bestaan is governance debt, en die stapelt zich op.
Wat Ik De Volgende Keer Anders Zou Doen
Enterprise-Scale Landing Zones zijn het beste startpunt dat Microsoft ooit heeft geboden voor Azure governance. Ze bevatten jaren aan hardleerse lessen in een deploybaar framework. Maar een framework is geen oplossing. De beslissingen die je neemt rond policy timing, networking topologie, exemption-processen en IaC eigenaarschap bepalen of je landing zone je teams versnelt of frustreert.
Begin met de referentie-architectuur. Weersta de verleiding om alles op dag een aan te passen. Deploy policies in Audit mode. Bouw het exemption-proces voordat je het nodig hebt. En onthoud dat een landing zone nooit af is: die evolueert met je organisatie.
Het doel is niet een perfecte landing zone op dag een. Het doel is een basis die elke maand beter wordt.
Op zoek naar Azure-architectuurbegeleiding?
Wij ontwerpen en bouwen Azure-fundamenten die schalen - landing zones, netwerken, identiteit en governance op maat van uw organisatie.
