Website under construction feedback appreciated at [email protected]
← Terug naar blog
azure

Azure Policy vs Blueprints in 2026

Yair Knijn · · 4 min lezen

Als je nog Azure Blueprints gebruikt, zet dan een herinnering in je agenda: op 11 juli 2026 wordt de service deprecated. Bestaande blueprint assignments blijven daarna mogelijk nog een tijdje werken, maar er komt geen ondersteuning meer, geen bugfixes, en Microsoft verwacht dat je migreert.

Hier is wat je moet weten en wat je ervoor in de plaats gebruikt.

Waarom Blueprints stopt

Blueprints was een manier om een set Azure-resources, policies, RBAC-rollen en ARM-templates te bundelen in een versioneerbaar pakket dat je kon toewijzen aan een abonnement. Het idee was goed: een “stempel” waarmee je nieuwe abonnementen snel in de juiste staat brengt.

Het probleem was de implementatie. Blueprints had zijn eigen API, zijn eigen portaalervaring, en paste niet goed in de bredere Infrastructure as Code-workflows die de meeste teams inmiddels gebruiken. Bicep en Terraform werden populairder. Deployment Stacks kwamen beschikbaar. Microsoft koos ervoor om niet twee systemen in stand te houden die hetzelfde doen.

Wat je in plaats daarvan gebruikt

Microsoft raadt drie services aan als vervanging, afhankelijk van wat je deed met Blueprints:

Azure Policy voor governance-afspraken en compliance. Policies dwingen af dat resources aan bepaalde eisen voldoen. Ze waren al de kern van de meeste Blueprints; nu gebruik je ze rechtstreeks, zonder de Blueprint-wrapper.

Template Specs voor het opslaan en delen van ARM- of Bicep-templates. Je kunt een Template Spec versioneren en er vanuit een deployment naar verwijzen. Dit vervangt het “ARM-template artifact” in Blueprints.

Deployment Stacks voor het bundelen van resources in een beheerde groep. Een Deployment Stack is een Azure-resource die een set gedeployde resources bijhoudt. Je kunt de stack updaten of verwijderen als geheel, inclusief de resources daarin. Dit vervangt de “samenhangende deployment” die Blueprints bood.

Bekijk Azure Policy en governance trainingen

Hoe je migreert

De migratie verloopt in drie stappen.

Eerst inventariseer je wat je hebt: welke blueprint definitions bestaan er, en welke assignments zijn actief? Dat doe je via de Azure portal (onder “Blueprints” in de zoekbalk) of via de REST API als je veel definities hebt.

Dan converteer je de inhoud:

  • Policy assignments uit je Blueprint worden directe Azure Policy assignments, bij voorkeur gebundeld in een Initiative (ook wel Policy Set).
  • RBAC-rollen uit je Blueprint worden directe Role Assignments, of je verwerkt ze in een Bicep-module.
  • ARM-template artifacts worden Template Specs, of je zet ze om naar Bicep en beheert ze vanuit je Git-repository.

Tot slot maak je voor elke omgeving of abonnement een Deployment Stack die de samenhang bewaart. Een Deployment Stack deploy je via Bicep of vanuit een pipeline, en hij bijhoudt welke resources erbij horen.

Een praktisch voorbeeld

Stel dat je een Blueprint had die dit deed bij een nieuw abonnement:

  1. Een resource group aanmaken
  2. Een Azure Policy toewijzen die het locatie-instelling afdwingt
  3. Een Log Analytics workspace deployen
  4. Een Contributor-rol toewijzen aan een groep

De nieuwe aanpak:

  1. De Azure Policy maak je een Initiative en je wijst die toe via Azure Policy Management of een pipeline.
  2. De Log Analytics workspace en resource group stop je in een Bicep-bestand en sla je op als Template Spec.
  3. De rol wijs je toe via een Bicep-module of rechtstreeks via de pipeline.
  4. Je bundelt stappen 2 en 3 in een Deployment Stack zodat je de deployment als geheel kunt beheren.

Is dit meer werk dan een Blueprint? Ja, de eerste keer. Het resultaat is wel beter te testen, beter te versioneren, en past in een normale CI/CD-workflow.

Als je nog niet bent begonnen

Heb je blueprints in productie die je nog niet hebt gemigreerd, begin dan nu. Twee maanden voor de deprecatie is krap als je meerdere omgevingen hebt. Microsoft biedt een migratiegids op learn.microsoft.com, maar die beschrijft de stappen op hoog niveau. De praktische kant van het omzetten van je eigen definities kost tijd.

Stel je prioriteiten: welke blueprints worden actief gebruikt, welke zijn er en worden nooit aangeraakt? Begin met de actieve. De slapende blueprints kun je misschien gewoon verwijderen.

azure-policy blueprints deprecation governance