FinOps på AWS: 23 tactics som halverar molnfakturan

De flesta AWS-konton jag granskar har tjugo till fyrtio procent som går att kapa utan att röra en enda funktion. Pengarna ligger inte gömda på ett ställe utan utspridda över många små och medelstora poster. FinOps handlar om att systematiskt ta dem, i rätt ordning. Här är de taktiker jag använder för att halvera en AWS-faktura, grupperade så att du ser var de hör hemma. Ordningen spelar roll - optimera innan du binder dig.

Innan jag rör en enda resurs sätter jag dock alltid synlighet först. Du kan inte optimera en kostnad du inte kan se, och en faktura som bara är en klumpsumma går inte att agera på. Med Cost Explorer och en genomtänkt taggning vet jag var pengarna faktiskt tar vägen, och först då blir det meningsfullt att börja kapa. Den ordningen - mät, optimera, bind, bevaka - går igen i allt jag gör med molnkostnad, och den är skillnaden mellan en tillfällig dipp och en bestående sänkning.

Compute: där de stora pengarna ligger

Den enskilt största posten är nästan alltid överdimensionerad compute. Servrar och databaser valda med marginal som aldrig justerades, och som månad efter månad ligger på en bråkdel av sin kapacitet. En instans på tio procents last kostar lika mycket som en på nittio. Genom att titta på faktisk förbrukning över tid och anpassa storleken nedåt frigörs ofta en betydande del av notan direkt, utan att något användarmärkbart förändras.

• Rightsizing av EC2 och RDS efter faktisk förbrukning.
• Schemalägg avstängning av icke-produktion utanför arbetstid.
• Byt till Graviton-baserade instanser för bättre pris mot prestanda.
• Flytta lämpliga arbetsbelastningar till spot-instanser.
• Konsolidera underutnyttjade instanser till färre, fullare.

Rightsizing ger snabb effekt och kräver inget åtagande - därför börjar jag alltid där. Graviton, AWS egna ARM-baserade processorer, är värt en särskild kommentar: för många arbetsbelastningar ger de bättre prestanda per krona än motsvarande x86-instanser, och bytet är ofta odramatiskt för tjänster som inte är hårt bundna till en arkitektur. Det är en av få optimeringar som sänker kostnaden utan att kräva vare sig nedskalning eller åtagande.

Åtaganden: bind först när lasten är känd

När du rightsizat och vet din baslast är det dags för savings plans och reserverade instanser. De ger rejäl rabatt mot att du binder dig på ett eller tre år.

• Compute Savings Plans för flexibel täckning av baslasten.
• Reserverade instanser för stabila, förutsägbara arbetsbelastningar.
• Täck baslasten, inte topparna - lämna marginalen åt on-demand och spot.

Ordningen är avgörande: binder du dig innan du rightsizat låser du in en för stor förbrukning i flera år.

Lagring: tyst men växande

Lagring kryper uppåt om ingen tittar.

• Livscykelregler som flyttar gammal S3-data till billigare nivåer.
• Städa oanvända EBS-volymer och gamla snapshots.
• Välj rätt EBS-volymtyp efter faktiskt prestandabehov.
• Komprimera och partitionera data som frågas ofta.

Nätverk och dataöverföring

Den post som förvånar flest är dataöverföring. Den syns sällan i den första budgeten men växer tyst med trafiken, och egress - trafik ut ur AWS - prissätts på ett sätt som straffar oövertänkt arkitektur. Jag ser ofta tjänster som skickar data fram och tillbaka mellan tillgänglighetszoner i onödan, eller hämtar från internet det som kunde nås internt.

• Minska trafik mellan tillgänglighetszoner där det går.
• Använd VPC-endpoints i stället för trafik via internet.
• Lägg CDN framför utgående trafik för att kapa egress.
• Cachelagra det som hämtas ofta i stället för att läsa om och om igen.

De här posterna är sällan enorma var för sig, men för ett bolag med mycket trafik summerar de till en överraskande stor del av notan. Och till skillnad från compute går de inte att lösa med ett åtagande - de kräver att arkitekturen tänks om, vilket gör dem lätta att skjuta upp men värda att ta tag i.

Synlighet och kultur

Resten av taktikerna handlar om att hålla besparingen kvar.

• En taggstrategi som kopplar varje kostnad till ett team.
• Budgetar och larm som fångar avvikelser tidigt.
• Kostnadsanomali-detektering för att upptäcka skenande poster.
• Showback så att team ser vad de faktiskt kostar.
• Kostnad som en naturlig del av arkitekturbeslut, inte en eftertanke.

En engångsstädning ger en dipp som kryper tillbaka. Det som håller är synlighet och att utvecklare ser prislappen på det de bygger. Vill du ha en intensiv insats med snabbt resultat har jag en sprint för kostnadsjakt, och du kan läsa mer om min molninfrastruktur.

Räkna hem det i rätt ordning

Om du ska ta med dig en enda sak är det ordningen. Börja med synlighet så att du vet var pengarna går. Ta sedan rightsizing och avstängning, som ger snabb effekt utan att binda dig. Bind först därefter baslasten med savings plans, när du vet vad den faktiskt är. Lägg på lagrings- och nätverksoptimering, och avsluta med den synlighet och kultur som håller besparingen kvar. Tjugotre taktiker låter mycket, men de flesta är små grepp inom de här fem stegen. Den som följer ordningen i stället för att hoppa direkt på rabatter undviker det vanligaste och dyraste misstaget: att låsa in en uppblåst förbrukning i ett treårsåtagande.

Relaterat

• Service mesh med Istio vs Linkerd: Trafikkontroll och mTLS i Kubernetes
• Disaster Recovery i molnet: RTO/RPO-design och automatiserade failover-tester
• AWS Landing Zone för svenska scale-ups: Multi-account från dag 1

Vill du ta det vidare?

Vill ni halvera AWS-fakturan på riktigt hjälper jag er med både snabba grepp och bestående struktur. Läs om min molninfrastruktur, se exempel i casebook, eller boka ett samtal.