Commitment-kortingen: de rekensom die de meeste teams verkeerd doen.
Coverage vs bezetting: het onderscheid dat telt
De meeste teams meten commitment-coverage: we hebben 80 procent van de compute gedekt met Savings Plans of Reserved Instances. Dit is de verkeerde metriek om op te optimaliseren.
Bezetting is het getal dat telt: van de commitments die je houdt, welk percentage heb je werkelijk verbruikt? Een commitment op 60 procent bezetting betekent dat je hebt toegezegd te betalen voor capaciteit die je niet gebruikt. Je hebt betaald voor de korting en de compute niet opgehaald.
Het doel: 95 tot 100 procent bezetting op alle commitments, met on-demand capaciteit die de variabele staart boven die vloer dekt. Coverage volgt uit bezetting. Niet andersom. Teams die eerst op coverage optimaliseren committeren routinematig te veel, en zitten dan met Reserved Instances die ze niet kunnen consumeren.
Waarom teams te veel committeren
Het instinct is te committeren op piekgebruik, of op een comfortabele buffer boven het gemiddelde. Beide produceren hetzelfde resultaat: gereserveerde capaciteit die stationair draait tijdens de daluren, weekenden en post-launch-dips die elke productie-workload heeft.
Te veel committeren op een 3-jarig Reserved Instance resulteert in het betalen van het gecommitteerde tarief voor capaciteit die je niet verbruikt. Die kosten zijn niet terug te winnen. De korting die aantrekkelijk leek op het moment van commitment wordt een verplichting voor de duur van de looptijd.
De juiste aanpak: haal drie maanden werkelijk gebruik-data op via de Savings Plans-recommender van AWS Cost Explorer, of het equivalente Azure-adviesrapport. Begin met het laagste aanbevolen commitment-niveau. Controleer de bezetting elk kwartaal. Verhoog coverage alleen als bestaande commitments gedurende een langdurige periode boven 95 procent bezetting zitten, niet omdat je verwacht dat het gebruik groeit.
Savings Plans vs Reserved Instances vs Spot
Savings Plans zijn van toepassing over instance-families en regio's heen. Reserved Instances zijn vergrendeld op een specifiek instance-type in een specifieke regio. Voor de meeste teams zijn Savings Plans de juiste standaard. Workloads veranderen: je right-sizet een m5.2xlarge naar m5.xlarge, migreert een service naar Graviton of verhuist een regio. Een Compute Savings Plan volgt de workload. Een Reserved Instance niet.
De uitzondering zijn databaseservices. RDS, ElastiCache en Redshift gebruiken Reserved Instances en nemen niet deel aan Savings Plans. Stabiele databases die binnen het commitment-venster niet worden vergroot of gemigreerd, zijn de juiste kandidaat voor een 1-jarig Reserved Instance. 3-jarige looptijden zijn alleen gerechtvaardigd als je architecturale zekerheid hebt voor het volledige venster. De meeste teams hebben die niet.
Spot is geen kortingsmechanisme voor productie-compute. Spot is een architectuurkeuze voor onderbreekbare, stateless, batch-workloads. Job-queues, ML-training en CI-runners die gebouwd zijn om onderbrekingen op te vangen met automatisch opnieuw proberen, besparen 60 tot 80 procent ten opzichte van on-demand. Een weblaag die bij een Spot-terugvordering uitvalt tijdens een verkeerspiek is geen prijsprobleem. Het is een architectuurprobleem.
"Committeer op je vloer, niet op je piek. Coverage volgt uit bezetting. Niet andersom."
Danny Zak / FinOps Lead
De keuze tussen 1 jaar en 3 jaar
Een 3-jarig commitment op AWS levert ruwweg 40 procent besparing op ten opzichte van on-demand. Een 1-jarig commitment levert ruwweg 25 procent op. De extra 15 procentpunten kopen 24 maanden extra vastgelegde schaal.
Om die extra commitment terug te verdienen, moet de workload drie jaar lang op ongeveer dezelfde schaal draaien. Voor een snelgroeiend engineeringteam is dit zelden waar voor het volledige fleet. Services worden herbouwd. Producten worden gedeprecieerd. De Kubernetes-namespace die vandaag op 30 nodes draait, zit in twee jaar op 12 of 50 nodes.
Ons standaardadvies voor groeifasebedrijven: 1-jarige Savings Plans, elk kwartaal beoordeeld, nooit verlengd bij een bezetting onder de 90 procent. Voor stabiele, langzaam veranderende workloads, zoals compliance-tooling, legacy-services die om contractuele redenen worden onderhouden en langlopende databases zonder geplande migratie, is een 3-jarig commitment geval per geval te overwegen. De vuistregel: als je er niet zeker van bent dat de workload over 36 maanden nog in zijn huidige vorm bestaat, is de 1-jarige looptijd de juiste keuze.