FinOps-besparingen zitten niet waar je denkt.
De compute-fallacy
Open tien FinOps-decks willekeurig. Acht beginnen met right-sizing van EC2- of VM-instances. Het is het strakste verhaal om te vertellen: we meten CPU, we adviseren een kleinere box, we besparen 12 procent op het regelitem.
Op de rekeningen die wij auditen is EC2 zelden de grootste verspillingsbron. Het is wel de zichtbaarste. Engineers vinden het leuk. De besparingen zijn echt maar gecapt. Spendeer een kwartaal aan right-sizing en je haalt misschien 8 procent terug. Spendeer hetzelfde kwartaal aan de drie regelitems hieronder en het cijfer is twee tot drie keer dat.
De eerste stapel: cross-region en cross-AZ dataverkeer
Netwerk is onzichtbaar. Elk architectuurdiagram glijdt over de lijnen tussen boxen. De rekening niet. Op AWS kan dataverkeer 12 tot 18 procent van de totale rekening zijn op een multi-AZ, multi-VPC topologie. Op Azure is het equivalent bandbreedte en ExpressRoute. Op beide is het meeste verkeer dat het team nooit bedoelde.
Het patroon: een service in account A doet een database-call naar account B. De call routeert via een NAT gateway omdat de oorspronkelijke landing zone zo gebouwd is. Zes maanden later kopieert een logging-pipeline dezelfde data tussen regio's om compliance-redenen die niemand meer kent. Niets ervan is verkeerd. Alles telt op.
De fix is architectureel, niet commercieel. VPC endpoints, PrivateLink, intra-AZ plaatsing van co-located services. De besparingen verschijnen dezelfde week dat we de wijziging deployen.
De tweede stapel: opslag die het team vergeten is
Snapshots, oude backups, AMI's, EBS-volumes die tijdens een incident gedetacheerd zijn en nooit teruggekoppeld. Logs die naar S3 verzenden met een dertig-dagen-lifecycle-policy die nooit geschreven is.
Op een typische mid-market estate vinden we opslagverspilling van 6 tot 14 procent van de rekening. De fix is mechanisch: lifecycle policies, retentie-review, snapshot-rotatie. De reden dat het onopgelost blijft, is dat niemand het bezit. Het platformteam denkt dat applicatieteams gaan taggen. Applicatieteams denken dat het platformteam een default policy heeft. Beide teams hebben het mis. Tot de rekening een eigenaar heeft, blijft de verspilling.
"Right-sizing van compute is de tweede sprint, niet de eerste. De eerste sprint is netwerk, opslag en managed-service-inventaris."
Danny Zak / FinOps Lead
De derde stapel: idle managed services
Managed databases die drie jaar geleden in non-productie draaiden, met multi-AZ aan omdat dat de template was. RDS-replicas die niemand bevraagt. ElastiCache-clusters geprovisioneerd voor een launch die niet doorging. Snowflake-warehouses die blijven draaien. OpenSearch-domains voor een feature die opgeleverd en gedeprecieerd is.
De kosten per service zijn klein. Het aantal is groot. Een recente rekening die we auditen telde 47 RDS-instances, waarvan 12 in 90 dagen nul connecties hadden. Maandelijkse verspilling: ongeveer €11.000. Het team wist niet dat ze draaiden.
De fix is inventaris plus policy. Elke managed service krijgt een eigenaar-tag. Elke ongetagde of zero-traffic service triggert een review na 30 dagen. Negen op de tien gemarkeerde services worden gedeprovisioneerd. De tiende blijkt een reden te hebben; dat is prima.
Wat dit betekent voor de FinOps-roadmap
Right-sizing van compute is de tweede sprint, niet de eerste. De eerste sprint is netwerk, opslag en managed-service-inventaris. De getallen zijn groter, de politiek is kleiner (niemand verdedigt ongetagde opslag), en de wijzigingen leveren zonder engineer-tijd op.
De tweede sprint kan dan right-sizing zijn, met een budget en een meetplan. Tegen die tijd heeft het team vertrouwen in de FinOps-praktijk, omdat de rekening al met 20 procent of meer is gedaald door de saaie wijzigingen.
Het besparingsverhaal dat de meeste consultancies vertellen, is het verkeerde verhaal omdat het makkelijke antwoord (right-size EC2) het zichtbare antwoord is. Het eerlijke antwoord is saaier. Het eerlijke antwoord betaalt beter.