Naming conventions voor Azure resources die schalen

Slechte namen in Azure zijn een beheerprobeem dat langzaam erger wordt. In het begin merk je er weinig van. Na een jaar heb je tientallen resources die “test”, “new” of de naam van de collega die ze aangemaakt heeft bevatten. Na twee jaar kun je bij een incident niet meer snel zien welke resource bij welke omgeving hoort.

Een naming convention kost je een uur om te bedenken en een half uur om te documenteren. Dat verdien je terug bij de eerste keer dat je ‘s nachts een resource probeert te vinden.

Een patroon dat werkt

De Microsoft Cloud Adoption Framework (CAF) beschrijft een aanbevolen structuur. Het basispatroon is:

{workload}-{env}-{region}-{resourcetype}-{nn}

Waarbij:

• workload de applicatie of dienst is (max 8 tekens, lowercase)
• env de omgeving is: prod, acc, dev, tst
• region de Azure-regio is: weu voor West Europe, neu voor North Europe
• resourcetype het type resource: vm, vnet, rg, kv, sql
• nn een volgnummer voor als je meerdere van hetzelfde hebt: 01, 02

Voorbeeld voor een virtual machine in productie in West Europe voor een HR-applicatie:

hr-prod-weu-vm-01

Voor een key vault in acceptatie:

hr-acc-weu-kv-01

Het storage account probleem

Storage accounts zijn de uitzondering op het patroon. Ze accepteren geen koppeltekens in de naam, alleen lowercase alfanumerieke tekens. Maximale lengte is 24 tekens.

Dat betekent dat hr-prod-weu-sa-01 niet werkt. Je moet het omzetten naar iets als hrprodweusa01. Leesbaar is anders, maar het is de enige optie.

Leg dit expliciet vast in je convention: storage accounts volgen het patroon zonder koppeltekens. Iedereen die ooit een storage account aanmaakt moet dit weten, anders ga je inconsistente namen krijgen.

Goede vs. slechte namen in de praktijk

Slecht	Goed	Probleem met de slechte naam
vm-test	hr-tst-weu-vm-01	Welk project? Welke regio?
storageaccount1	hrprodweusa01	Geen context, omgeving onduidelijk
johns-vnet	fin-prod-weu-vnet-01	Persoonsgebonden, niet overdraagbaar
new-keyvault	crm-acc-weu-kv-01	”New” is altijd tijdelijk, dit was permanent
rg-everything	hr-prod-weu-rg-01	Te breed, geen duidelijke scope

Resource groups vs. tags

Een naming convention voor resource groups is net zo belangrijk. Gebruik hetzelfde patroon:

hr-prod-weu-rg-01

Resource groups zijn je eerste afbakeningslaag. Alle resources voor een workload in een omgeving horen in dezelfde resource group. Gooi niet alles in een gedeelde resource group “omdat het makkelijker is”.

Tags zijn aanvullend, niet vervangend. Gebruik tags voor informatie die je niet in de naam kunt stoppen: costcenter, eigenaar, ticket-ID, lifecycledatum. Tags zijn doorzoekbaar via Azure Policy en de Cost Management-rapporten.

Een resource die alleen een tag heeft maar een onduidelijke naam, is alsnog moeilijk te vinden als je in het portaal scrolt.

Bekijk Azure governance trainingen over naming en tagging

Wanneer afwijken

Er zijn situaties waar het standaardpatroon niet past:

• Sommige resources hebben maximale naamlengte van 15 tekens (klassieke VMs, sommige SQL-resources). Pas het patroon aan: laat het volgnummer weg of gebruik een kortere regio-code.
• Als je een landelijke afkorting als workload-prefix wilt, zorg dan dat de lijst met geldige workload-codes centraal beheerd wordt. Twee teams die allebei fin kiezen voor Finance en fin voor een ander project is een bekende valkuil.

Documenteer de uitzonderingen naast de hoofdregel. Zo hoeft niemand te raden wanneer afwijken mag en wanneer niet.

Hoe je het afdwingt

Een convention die alleen in een Word-document staat, wordt niet gevolgd. Gebruik Azure Policy om af te dwingen dat resources voldoen aan het patroon. Microsoft heeft een ingebouwde policy definition voor naming patterns (via het like-effect in policy rules).

Voor nieuwe omgevingen kun je dit opnemen in je Infrastructure as Code: een Bicep-module of Terraform-configuratie die de naam genereert op basis van de parameters die je meegeeft. Dan hoeft niemand het patroon uit zijn hoofd te kennen.