1) Begin met cost allocation: maak kosten toewijsbaar
Als je kosten niet kunt toewijzen, kun je ze ook niet sturen. Azure Cost Management kan kosten analyseren op scope (management group/subscription/resource group) en tags: inclusief cost allocation functionaliteit zoals tag inheritance en het verdelen van shared costs.
Praktische tagging set (minimaal):
- costCenter (of business unit)
- product (welke applicatie/klantwaarde)
- environment (dev/test/acc)
- owner (team of persoon)
- criticality (bijv. tier-1/tier-2)
Tip: maak tagging geen “best effort”. Leg het vast als standaard (policy/landing zone), anders wordt het een schoonmaakproject dat elke maand terugkomt.
“Developers zijn verantwoordelijk voor wat ze maken, inclusief de operatie en productie. Ownership hebben over kosten is daar een logisch onderdeel van.”
2) Zet guardrails: budgets + alerts (en voorkom bill shock)
Zodra je allocation op orde is, wil je voorkomen dat je pas bij de factuur schrikt. Met Azure budgets kun je drempels instellen (bijv. 50/80/100%) en automatisch alerts versturen. Budgets worden per periode beheerd (maandelijks/kwartaal/jaar) en alerts verschijnen in cost alerts en kunnen e-mailen naar een recipient list.
Deze aanpak raden wij aan:
- Budget op subscription-niveau voor “cap”
- Extra budgets op resource group of tag scope voor productteams
- Alerts naar: team channel + product owner + platform/FinOps
Bonus: Azure Cost Management heeft ook anomaly detection en bijbehorende alerts, handig voor onverwachte spikes.
3) Pak de grootste cost drivers aan en maak quick wins
De meeste winst zit bijna altijd in dezelfde categorieën: compute, storage, databases en netwerk. Het doel is niet “alles optimaliseren”, maar de top 20% die 80% impact geeft.
Compute (VMs, App Service, AKS nodes, etc.)
- Right-sizing: te grote SKU’s zijn de klassieker.
- Schedules: dev/test omgevingen ’s nachts en in het weekend uit (waar kan).
- Autoscale: liever dynamisch schalen dan structureel overprovisionen.
Storage
- Lifecycle policies (hot/cool/archive) en retentie op logs/backups.
- Voorkom dat “tijdelijke” blobs jarenlang blijven staan.
Databases
- Check of je te zwaar zit qua tier/DTU/vCore.
- Kijk naar opties zoals serverless/pausing waar het patroon dat toelaat.
Network (de stille kostenmaker)
- Egress kan onverwacht oplopen (bijv. data export, cross-region verkeer).
- Maak “data movement” expliciet in architectuurkeuzes.
4) Committed spend: Savings Plans vs Reservations
Als je basis op orde is, komt de vraag: “Kunnen we committed discounts inzetten?”
Azure savings plan for compute
Een savings plan is een vaste hourly spend commitment voor 1 of 3 jaar. Je krijgt korting op eligible compute, en die korting kan oplopen tot “up to 65%” afhankelijk van de meter/term. Belangrijk detail: je wordt elk uur voor het committed bedrag gefactureerd, ook als je dat uur minder gebruikt.
Wanneer past dit goed?
- Je compute is dynamisch, maar je totale spend is redelijk stabiel.
- Je wilt flexibiliteit over meerdere compute-typen (binnen eligibility).
Azure Reservations
Reservations zijn gerichter (bijv. Reserved VM Instances of reserved capacity voor bepaalde services) en je beheert o.a. scope (single subscription/resource group of shared) en benutting. Microsoft benadrukt dat echte savings komen van sustained use en het maximaliseren van utilization. Wij zien dat dit vaak tot kostenreducties van 30 tot 40% loopt, in de meest extreme scenarios kan dit oplopen tot wel 80%.
Wanneer past dit goed?
- Workloads zijn stabiel en voorspelbaar (24/7 of vaste baseline).
- Je weet dat de SKU/shape niet snel verandert.
Valkuil: onderbenutting. Als je commitment niet “opgaat”, betaal je alsnog. Bouw dus monitoring in op utilization en herzie commitments periodiek.
5) Maak er een ritme van: FinOps als samenwerking, niet als project
FinOps gaat niet alleen over tooling, maar over gedrag en ownership: engineering, finance en business die samen beslissen op basis van data. De FinOps Foundation beschrijft optimalisatie als een set prescriptieve stappen om provisioning en usage structureel cost-aware te maken.
Bijvoorbeeld met deze structuur:
- Wekelijks: top anomalies + grootste stijgers per product/tag
- Maandelijks: reserved/savings utilization review + roadmap (welke workloads next)
- Per kwartaal: governance/guardrails aanscherpen (policies, templates, tagging discipline)
Checklist
- Hebben alle resources een minimale tag set (costCenter, product, environment, owner)?
- Is reporting ingericht op management group/subscription + tag views?
- Zijn budgets actief op subscription én team/product scopes?
- Krijgt het juiste team alerts (niet alleen finance)?
- Is anomaly detection/alerting gebruikt voor onverwachte spikes?
- Is compute right-sized en waar kan gescheduled/autoscaled?
- Zijn storage lifecycle en retentie expliciet geregeld?
- Worden egress-kosten actief gemonitord bij data-intensieve flows?
- Is er een beslisregel voor Savings Plans vs Reservations?
- Wordt utilization van commitments maandelijks gereviewd?
Conclusie
Cost optimization in Azure is vooral: eerst zichtbaarheid, dan guardrails, dan pas discounts, en daarna zorgen dat het proces blijft draaien. Als je deze volgorde aanhoudt, voorkom je verrassingen én wordt besparen een normale engineering-activiteit in plaats van een brandje dat je elk kwartaal blust.