Rätt dimensionering: den åtgärd som ger mest per krona

Rightsizing — att matcha instanstyp och storlek mot faktiskt resursbehov — är den mest kostnadseffektiva enskilda åtgärden. Inga avtal behöver omförhandlas, inga arkitekturförändringar krävs.

Så genomför du en rightsizing-analys

1. Samla minst 14 dagars CPU- och minnesdata. AWS CloudWatch, Azure Monitor eller Datadog ger tillräckligt underlag. Två veckor fångar de flesta variationer utom månadscykler.

2. Identifiera instanser med CPU-snitt under 20 % och minnesutnyttjande under 40 %. Dessa är kandidater för nedstorlek.

3. Utvärdera burstbara alternativ. T3/T3a-instanser (AWS) eller B-serien (Azure) är ofta perfekta för arbetsbelastningar med ojämn profil.

4. Testa i staging först. Storleksändra, kör lasttest, validera. Först därefter produktion.

5. Automatisera. AWS Compute Optimizer och Azure Advisor ger löpande rekommendationer. Bygg in rightsizing i er kvartalsrutin.

Besparingspotential per instansfamilj

Reservationer och Savings Plans: köp smart

När ni har rätt dimensionerat era resurser vet ni vad som faktiskt behövs. Då — och inte innan — är det dags att binda upp er för rabatterade priser.

AWS: Savings Plans vs. Reserved Instances

Savings Plans (Compute eller EC2) ger rabatt mot ett åtagande om en viss timkostnad (exempelvis 10 USD/timme i ett eller tre år). Flexibiliteten är hög: ni kan byta instansfamilj, storlek, operativsystem och region (för Compute Savings Plans).

Reserved Instances ger djupare rabatt men kräver att ni specificerar instansfamilj, region och hyresperiod. Lämpligt för databaser och andra arbetsbelastningar som inte förändras.

Vår rekommendation: Säkra 60–70 % av er stabila baseline med Savings Plans. Lägg reserverade instanser ovanpå för de mest förutsägbara arbetsbelastningarna. Låt resten köra on-demand eller Spot.

Azure: Reservations och Savings Plans

Azure har sedan 2023 ett liknande upplägg. Azure Reservations fungerar som reserverade instanser, medan Azure Savings Plan for Compute ger flexibilitet över VM-familjer. Azure Hybrid Benefit kan dessutom ge ytterligare rabatter om ni redan äger Windows Server- eller SQL Server-licenser.

Google Cloud: CUD:er

Committed Use Discounts (CUD) i Google Cloud liknar reserverade instanser. Spend-based CUD:er ger flexibilitet liknande Savings Plans. Google erbjuder också automatiska rabatter för varaktig användning (Sustained Use Discounts) — en fördel om ni inte vill binda er.

Spot-instanser och preemptible VM:er: den underskattade rabatten

Spot-instanser (AWS), Spot VMs (Azure) och Preemptible VMs (Google Cloud) erbjuder 60–90 % rabatt mot att leverantören kan återta kapaciteten med kort varsel. Det låter riskabelt, men för rätt arbetsbelastningar är det en av de mest effektiva optimeringarna.

Lämpliga arbetsbelastningar:

• CI/CD-pipelines och byggjobb
• Batchbearbetning och dataanalys
• Rendering och vetenskapliga beräkningar
• Kubernetes-noder med korrekt konfigurerade Pod Disruption Budgets
• Utvecklings- och testmiljöer

Olämpliga arbetsbelastningar:

• Primära databasinstanser
• Stateful tjänster utan automatisk återstart
• Realtidstjänster med strikta latenskrav

I Opsios Kubernetes-kluster kör vi regelmässigt 40–50 % av icke-kritiska noder på Spot. Med Karpenter (AWS) eller Cluster Autoscaler konfigurerad för diversifiering över instansfamiljer har vi sett mindre än 2 % avbrott under de senaste tolv månaderna.

Taggning och kostnadsallokering: fundamentet du inte kan skippa

Ingen optimering fungerar utan synlighet, och synlighet kräver konsekvent taggning. Ändå är bristfällig taggning det vanligaste problemet vi ser vid onboardings.

Minsta möjliga taggningsstandard

Använd AWS Organizations SCP:er, Azure Policy eller Google Cloud Organization Policies för att tvinga taggning vid resursskapande. Resurser utan taggar ska automatiskt flaggas och efter en grace period avslutas.

Vårt FinOps-erbjudande

FinOps som organisatorisk praxis

Verktyg och tekniker tar er halvvägs. Den andra halvan handlar om kultur och processer. FinOps Foundation — numera en del av The Linux Foundation — definierar tre faser: Inform, Optimize, Operate.

Inform: skapa synlighet

Ge varje team en dashboard som visar deras molnkostnader, uppdelade per tjänst och miljö. AWS Cost Explorer, Azure Cost Management och Google Cloud Billing Console räcker initialt. Dashboarden ska vara lättillgänglig — inte gömd i en finansrapport som levereras en gång i månaden.

Optimize: agera på insikterna

Schemalägg månatliga kostnadsgranskningar per team. Granska:

• Rightsizing-rekommendationer (AWS Compute Optimizer, Azure Advisor)
• Oanvända reservationer och Savings Plans med lågt utnyttjande
• Resurser utan taggar eller med taggen Environment: dev som körs dygnet runt
• Datatransferkostnader som ökat onormalt

Operate: gör det kontinuerligt

Bädda in kostnadsmedvetenhet i utvecklingsprocessen. Pull request-granskningar bör inkludera resurskostnad. Terraform-moduler kan standardisera instansstorlekar. Automatisering stänger ner dev/staging utanför kontorstid (en enkel Lambda/Azure Function sparar 65 % på dessa miljöer).

Managerade molntjänster

Kubernetes-specifik kostnadsoptimering

Kubernetes adderar ett lager av komplexitet. Resurser allokeras på pod-nivå via requests och limits, men den faktiska förbrukningen matchar sällan konfigurationen.

Vanliga misstag vi ser:

• CPU-requests satta till 1000m (1 vCPU) för tjänster som snittar 50m
• Inga limits konfigurerade, vilket leder till oförutsägbar schemaläggning
• Namespace-kvoter saknas, så ett team kan allokera hela klustrets kapacitet
• Persistent Volume Claims som aldrig raderas efter att en pod försvunnit

Verktyg att använda:

• Kubecost ger kostnadsallokering per namespace, deployment och pod
• Goldilocks (från Fairwinds) ger VPA-baserade rightsizing-rekommendationer
• Karpenter (AWS) eller Karpenter-motsvarigheter optimerar nodpooler dynamiskt

Enligt CNCF:s årliga undersökning ökar Kubernetes-adoption stadigt, och med det växer behovet av Kubernetes-specifik FinOps. Rätt konfigurerade requests och limits i kombination med kluster-autoskalning och Spot-noder kan sänka Kubernetes-compute-kostnader med 50 % eller mer.

Managerad DevOps

Datatransfer — den dolda kostnadsposten

Datatransferkostnader (egress) är den post som oftast överraskar. AWS tar betalt för data som lämnar en region, som korsar AZ-gränser och som går till internet. Azure och Google Cloud har liknande modeller, även om Google nyligen sänkt egress-priser.

Praktiska åtgärder:

• Håll trafik inom samma AZ där det är möjligt (gratis eller nästan gratis)
• Använd VPC-endpoints/Private Link istället för att gå via internet till S3, DynamoDB etc.
• CDN (CloudFront, Azure Front Door, Cloud CDN) minskar egress från origin
• Komprimera data före överföring — gzip/zstd på API-svar och loggar
• Granska NAT Gateway-kostnader — de faktureras per GB och kan bli en stor post

Governance och automatisering

Manuell optimering skalerar inte. Bygg automatiserade policies:

• Schemalägg start/stopp av dev- och staging-miljöer (AWS Instance Scheduler, Azure Automation)
• Automatiska reservationsköp baserat på AWS Cost Explorer-rekommendationer med manuellt godkännande
• Budget-alarm per team med eskalering vid 80 % och 100 % av budget
• Anomalidetektering via AWS Cost Anomaly Detection eller Azure Cost Management alerts

Hos Opsio har vi byggt en intern FinOps-pipeline som dagligen analyserar kunders miljöer, genererar rightsizing-rekommendationer och flaggar zombieresurser. Rekommendationerna granskas av vårt NOC-team innan de levereras — automatisering med mänsklig validering.

Molnsäkerhet

Vanliga misstag vi ser — och hur ni undviker dem

1. Köpa reservationer innan rightsizing. Ni låser in er på överdimensionerade instanser i tre år. Gör alltid rightsizing först.

2. Ignorera datatransferkostnader. De kan utgöra 10–15 % av totalkostnaden i dataintensiva miljöer.

3. Centralisera allt kostnadsansvar till ekonomiavdelningen. De kan inte fatta tekniska beslut. FinOps kräver samarbete mellan ingenjörer, ekonomi och verksamhet.

4. Optimera en gång och tro att arbetet är klart. Molnmiljöer förändras ständigt. Kvartalsvis genomgång är minimum.

5. Jaga de sista procenten. 80/20-regeln gäller. De första 30 % besparingarna är enkla. De sista 5 % kostar mer i arbetstid än de sparar.

Så kommer ni igång — en 90-dagarsplan

Vecka 1–2: Implementera taggningsstandard. Aktivera Cost Explorer / Cost Management. Skapa budget-alarm.

Vecka 3–4: Genomför första rightsizing-analysen. Identifiera och avsluta zombieresurser. Schemalägg dev/staging för kontorstid.

Månad 2: Analysera reservationsmöjligheter baserat på 30+ dagars historik. Köp Savings Plans för den stabila basen. Inför månatliga kostnadsgranskningar per team.

Månad 3: Utvärdera Spot-instanser för lämpliga arbetsbelastningar. Optimera datatransferkostnader. Etablera FinOps-praxis med tydliga roller och ansvar.

Molnmigrering

Vanliga frågor

Vad är skillnaden mellan FinOps och traditionell kostnadsoptimering?

FinOps är en operativ praxis som ger ingenjörer, ekonomi och verksamhet gemensamt ansvar för molnkostnader i realtid. Traditionell kostnadsoptimering är ofta en engångsinsats från IT-avdelningen. FinOps handlar om kultur, processer och kontinuerlig feedback — inte bara om att stänga av oanvända instanser.

Hur mycket kan vi realistiskt spara genom molnkostnadsoptimering?

Det beror på hur mogen er molnmiljö är. Organisationer som aldrig gjort en systematisk genomgång sparar ofta 20–40 % inom de första tre månaderna. Mogna miljöer med etablerad FinOps-praxis optimerar löpande med 5–10 % per kvartal genom rightsizing, reservationer och arkitekturförbättringar.

Bör vi använda reserverade instanser eller Savings Plans?

Savings Plans (AWS) ger mer flexibilitet eftersom de täcker flera instansfamiljer och regioner. Reserverade instanser ger störst rabatt för stabila, förutsägbara arbetsbelastningar. I praktiken kombinerar de flesta organisationer båda: Savings Plans som bas och reserverade instanser för väldokumenterade, statiska arbetsbelastningar.

Vilka verktyg behövs för att komma igång med FinOps?

Börja med molnleverantörens inbyggda verktyg: AWS Cost Explorer, Azure Cost Management eller Google Cloud Billing. Komplettera med en taggningsstrategi och en enkel dashboard. Tredjepartsverktyg som Kubecost (för Kubernetes) eller plattformar som Spot by NetApp blir relevanta när miljön växer.

Hur påverkar multicloud-strategier kostnadsoptimeringen?

Multicloud ökar komplexiteten markant. Varje leverantör har unika prismodeller, rabattstrukturer och mätenheter. Utan centraliserad FinOps-styrning leder multicloud ofta till högre — inte lägre — totalkostnader. En gemensam FinOps-plattform och konsekvent taggning över leverantörerna är avgörande.