Azure Landing Zone IaC Accelerator: van nul naar productie in 2 dagen

Waarom een landing zone als code?

Een Azure Landing Zone is geen product dat je installeert — het is een architectuurpatroon dat de basis legt voor alles wat daarna komt. Management group hiërarchie, subscription vending, netwerktopologie, identity, governance: al deze onderdelen moeten consistent zijn over tientallen of honderden subscriptions. Zodra je dit handmatig inricht via de Azure Portal, verlies je reproduceerbaarheid. Elke keer dat iemand een instelling aanpast zonder dat dit gedocumenteerd wordt, groeit de afwijking tussen wat je denkt dat er staat en wat er werkelijk staat.

Infrastructure as Code lost dit fundamenteel op. Niet omdat code foutloos is, maar omdat code reviewbaar, versiebaar en herhaalbaar is. Een Bicep-module die een subscription uitrolt, doet dat elke keer op dezelfde manier. Een GitHub Actions-pipeline die een what-if uitvoert vóór elke deployment, maakt afwijkingen zichtbaar voordat ze productie bereiken.

De Microsoft CAF IaC Accelerator als startpunt

Microsoft biedt via het Cloud Adoption Framework (CAF) een IaC Accelerator aan die de platform landing zone als Bicep- of Terraform-code beschikbaar stelt. Dit is geen theoretisch framework maar werkende code, onderhouden door Microsoft en de community, gebaseerd op Azure Verified Modules (AVM). AVM zijn gestandaardiseerde, geteste Bicep- en Terraform-modules voor individuele Azure-resources en -patronen. Door AVM als building blocks te gebruiken, profiteer je van een consistente interface, ingebouwde validatie en een actief onderhouden module-registry.

De accelerator bestaat uit drie lagen. De platform landing zone bevat de gedeelde infrastructuur: connectiviteit (hub-spoke of Virtual WAN), identity (Microsoft Entra ID, Privileged Identity Management) en management (Log Analytics workspace, Defender for Cloud, Azure Policy). De subscription vending machine automatiseert het aanmaken van nieuwe subscriptions op basis van een parameterset — dit is de sleutel tot schaalbaar platform engineering. De governance-laag ten slotte bevat policy-initiatieven als code, RBAC-toewijzingen en compliance-rapportage.

Bicep of Terraform: een pragmatische keuze

De keuze tussen Bicep en Terraform is minder ideologisch dan vaak gesuggereerd. Bicep is de native Azure IaC-taal: geen state file, directe integratie met Azure Resource Manager, en uitstekende tooling in VS Code. Terraform biedt multi-cloud portabiliteit en een rijker ecosysteem van providers, maar vereist state management — bij voorkeur via een Azure Storage Account met locking. Voor organisaties die uitsluitend Azure gebruiken en een lage operationele overhead willen, is Bicep de logische keuze. Voor organisaties met een bestaande Terraform-investering of multi-cloud ambities is Terraform de betere optie. Beide worden ondersteund door de CAF IaC Accelerator.

CI/CD: van code naar deployment

Een landing zone als code heeft pas waarde als de deployment ook geautomatiseerd is. De pipeline bestaat uit drie fasen. In de validatiefase wordt de code gelinkt op syntaxfouten en stijlafwijkingen, gevolgd door een what-if analyse die toont welke resources worden aangemaakt, gewijzigd of verwijderd. Dit is de meest waardevolle stap: het maakt de impact van een change expliciet vóór uitvoering. In de goedkeuringsfase wacht de pipeline op een menselijke review voor productie-deployments — dit is het approval gate dat risicovolle changes tegenhoudt. In de deploymentfase wordt de landing zone uitgerold, gevolgd door een post-deployment verificatie die controleert of de gewenste toestand ook werkelijk bereikt is.

Van nul naar productie: wat kunt u verwachten?

In de praktijk duurt een initiële landing zone implementatie vier tot acht weken. De eerste week is gewijd aan assessment: wat is de huidige situatie, welke subscriptions bestaan er al, welke governance-vereisten zijn er? Week twee en drie zijn de kernimplementatie: platform landing zone als code, management group hiërarchie, subscription vending module en CI/CD pipeline. Week vier tot zes is validatie en overdracht: testen van de pipeline, documentatie van de architectuur en kennisoverdracht aan het interne platform team. Het resultaat is een reproduceerbare, auditeerbare Azure-omgeving die als basis dient voor alle workloads die daarna komen.

Veelgemaakte fouten

De meest voorkomende fout is het beginnen met de workload in plaats van het platform. Teams die direct beginnen met het deployen van applicaties zonder een gestandaardiseerde landing zone, bouwen technische schuld op die later duur is om te corrigeren. Een tweede veelgemaakte fout is het kopiëren van de accelerator zonder aanpassing: de accelerator is een startpunt, geen eindproduct. Elke organisatie heeft specifieke vereisten voor netwerktopologie, naming conventions en governance-beleid die in de code verwerkt moeten worden. Tot slot onderschatten teams regelmatig het belang van de subscription vending machine: handmatig subscriptions aanmaken is de bottleneck in elke schaalbare Azure-omgeving.