Tagging-schuld renteert. Begin met de policy, niet met de tags.
Waarom retroactief taggen langzamer is dan het lijkt
Als we een mid-market estate voor het eerst auditen, zit de tag-coverage tussen de 40 en 60 procent. De ontbrekende tags zijn niet weg omdat engineers onzorgvuldig zijn. Ze zijn weg omdat de resource aangemaakt is voordat de tag-policy bestond, voordat de engineer de policy kende, of in een automatiseringsscript dat de tag-schema twee jaar oud is.
500 resources retroactief taggen betekent: de resource vinden, de eigenaar bepalen (vaak onduidelijk), de juiste tag-waarden kiezen, ze toepassen zonder bestaande automatisering te breken, en verifiëren dat de kostenallocatie de wijziging oppikt. We meten dit. Het gemiddelde is 2,5 tot 4 uur gecombineerde engineering- en FinOps-tijd per resource-klasse. Voor een estate van 500 resources is dat drie tot vier weken onderbroken werk, waarna de rekening nog steeds gaten heeft omdat er tijdens de opruiming nieuwe resources zijn aangemaakt.
De schemavraag die mensen overslaan
De meeste tag-discussies beginnen met welke tags we verplicht moeten stellen. De belangrijkere vraag is hoe je het juiste antwoord de voor de hand liggende weg maakt.
Het schema dat werkt in productie is drie lagen. Account- of subscriptie-niveau: omgeving (prod, staging, dev), kostenplaats, business unit. Deze zijn statisch, eenmalig ingesteld bij aanmaak van het account. Service-niveau: servicenaam, teamnaam, tier (kritiek, standaard, batch). Dit mapt op het team-eigendomsmodel en wijzigt alleen bij een herstructurering. Workload-niveau: applicatienaam, component, versie. Optioneel, maar precies genoeg voor chargeback als een team meerdere producten draait.
Vijf verplichte tags per resource. Optionele tags per team. Alles gevalideerd in IaC, niet gedocumenteerd in een wiki die niemand opent voor het provisioneren.
Policy voor tags: de controles die echt werken
AWS Organizations tag policies, Azure Policy tag-regels en GCP Organization Policy bieden alle drie een mechanisme om resource-aanmaak zonder verplichte tags te blokkeren. Geen van hen staat standaard aan. Geen van hen is moeilijk in te schakelen. We hebben nog geen team gezien dat ze proactief inschakelt zonder externe aanmoediging.
Het enforcement-pad dat wij draaien: definieer het tag-schema in de platform-repo als een machineleesbare spec. Handhaaf in Terraform via een gedeelde validatiemodule die het plan laat falen als verplichte tags ontbreken. Handhaaf op cloud-organisatieniveau via een policy die API-calls voor niet-conforme resources blokkeert. Toon overtredingen wekelijks in een Slack-kanaal met een link naar het herstel-runbook. Drie handhavingslagen: een ontbrekende tag faalt voor een PR samenvoegt, faalt voor een Terraform-apply, en faalt voor de cloud-API het verzoek accepteert.
Tag-coverage stijgt van 55 procent naar 95 procent in de eerste sprint. De resterende 5 procent zijn resources die dateren van voor de handhaving. Ze worden opgeruimd in het volgende kwartaal terwijl teams normale infra-wijzigingen uitvoeren.
"Tag-coverage van 55 naar 95 procent is een sprint. Het resterende gat is geen tagging-probleem. Het is een kostenmodel-probleem."
Danny Zak / FinOps Lead
Het allocatie-gat dat goede tagging overleeft
Zelfs met 95 procent tag-coverage en correcte waarden blijft 8 tot 12 procent van de cloudkosten niet-gealloceerd. Dit is de onherleidbare overhead van gedeelde infrastructuur: NAT-gateways, gedeelde VPC's, cross-account-netwerken, support-kosten en dataverkeer-kosten die geen resource-ID dragen. Geen ervan tagt naar een workload, want geen ervan behoort aan één workload toe.
Het allocatie-gat is geen tagging-probleem. Het is een kostenmodel-probleem. De oplossing is een gedeelde-services-budgetregel die een eigenaar heeft, wordt voorspeld en elk kwartaal wordt beoordeeld, los van de workload-kosten. Teams houden op met het onverdeelde deel als iemand anders zijn probleem te behandelen als het budget expliciet is.
Van 60 procent tag-coverage naar 95 procent is een sprint. Van 95 procent naar accurate financiële rapportage is een kostenmodel-ontwerp. Beide zijn vereist. Teams die de tweede stap overslaan hebben precieze tags op 95 procent van de resources en kunnen toch niet beantwoorden wat team A vorige maand heeft uitgegeven. De tags kloppen. Het model is nooit gebouwd.