Savings Plans vs Reserved Instances 2026

Uppdaterad: 30 maj 2026

AWS Savings Plans ger oftast mer värde än Reserved Instances 2026: samma rabatt på upp till 72 %, men med betydligt större flexibilitet, eftersom Compute Savings Plans automatiskt täcker EC2, Fargate och Lambda oavsett region, instansfamilj eller operativsystem. Reserved Instances (RIs) finns kvar, men AWS rekommenderar numera Savings Plans för nya åtaganden i de flesta scenarier. Den här guiden jämför båda mekanismerna med konkreta priser, brytpunkter och beslutsregler jag samlat på mig från riktiga FinOps-uppdrag.

Compute Savings Plans ger 66 % rabatt över 3 år med all upfront och fungerar för EC2, Fargate och Lambda i vilken region som helst.
EC2 Instance Savings Plans ger upp till 72 % rabatt, men låser dig till en specifik instansfamilj i en region (t.ex. m6i i eu-west-1).
Standard Reserved Instances ger fortfarande störst rabatt på RDS, ElastiCache, OpenSearch och Redshift, eftersom AWS inte släppt Savings Plans för dessa tjänster.
För arbetsbelastningar med över 70 % stabil basanvändning betalar sig ett 3-årigt åtagande tillbaka inom 14–18 månader.
Spot Instances kombineras fritt med Savings Plans: åtagandet täcker on-demand-baslinjen, Spot tar topparna.
Använd AWS Cost Explorers rekommendationsmotor som golv, inte tak. Den underskattar ofta värdet av Convertible RIs och Compute SP-portföljer.

Vad är AWS Savings Plans och hur skiljer de sig från Reserved Instances?

AWS Savings Plans är en åtagandebaserad prismodell där du förbinder dig till en specifik dollarmängd per timme under 1 eller 3 år. I gengäld får du rabatt jämfört med on-demand. Reserved Instances är den äldre modellen där du istället reserverar en specifik instanstyp (till exempel m6i.large i eu-west-1) och får rabatt på just den konfigurationen. Den avgörande skillnaden är granularitet: Savings Plans räknar pengar, Reserved Instances räknar instanser.

I praktiken betyder det att Compute Savings Plans automatiskt räknar om rabatten när du byter från m5 till m6i, flyttar arbetsbelastning från Stockholm till Frankfurt, eller migrerar batch-jobb från EC2 till Fargate. Reserved Instances kräver däremot att du säljer den gamla reservationen på Marketplace eller konverterar den (gäller bara Convertible RIs), en process som tar timmar och ofta lämnar tio procent på golvet.

2026 har AWS publicerat att fler än 80 % av nya åtaganden registreras som Savings Plans snarare än EC2 RIs, enligt deras egen officiella Savings Plans-dokumentation. RIs är fortfarande vägen framåt för databasprodukter (RDS, ElastiCache, OpenSearch, Redshift, DynamoDB Reserved Capacity, DocumentDB) där Savings Plans inte finns tillgängliga ännu.

Jämförelsetabell: Savings Plans vs Reserved Instances 2026

Tabellen nedan visar de fyra viktigaste rabattmekanismerna jämförda mot ett baspris för m6i.large i eu-north-1 (Stockholm) på 0,1152 USD/timme on-demand.

Egenskap	Compute Savings Plans	EC2 Instance Savings Plans	Standard Reserved Instances	Convertible Reserved Instances
Max rabatt (3 år, all upfront)	66 %	72 %	72 %	54 %
Pris efter rabatt (USD/tim)	0,0392	0,0323	0,0323	0,0530
Täcker EC2, Fargate, Lambda	Ja	Endast EC2	Endast EC2	Endast EC2
Flexibel mellan instansfamiljer	Ja	Nej (låst till familj)	Nej	Ja (via byte)
Flexibel mellan regioner	Ja	Nej (låst till region)	Nej (regional eller zonal)	Nej
Säljbar på Marketplace	Nej	Nej	Ja	Nej
Bäst för	Heterogena arbetsbelastningar	Stabila storskaliga EC2-flottor	RDS, ElastiCache, OpenSearch	EC2-flottor som ändrar form

När ska jag välja Compute Savings Plans framför EC2 Instance Savings Plans?

Välj Compute Savings Plans när din arbetsbelastning är blandad eller fortfarande utvecklas. Den extra flexibiliteten kostar dig sex procentenheter (66 % istället för 72 %), men du slipper omförhandla åtagandet när teamet migrerar från Intel-baserade m5-instanser till AWS Graviton-baserade m7g, eller när en batch-pipeline plötsligt flyttas från EC2 till Fargate.

EC2 Instance Savings Plans är rätt val när du har en mycket stor, mycket stabil flotta. Tänk dig ett team som kör 200 r6i.4xlarge dygnet runt i eu-west-1 för en SQL Server-databas som inte kommer migreras inom tre år. Då vinner du 6 procentenheter extra rabatt utan att förlora något i praktiken, eftersom du ändå inte tänkt byta familj.

En vanlig portföljstrategi 2026 är att lägga 60–70 % av åtagandet som Compute SP (för flexibilitet) och topplaget 10–20 % som EC2 Instance SP riktat mot de mest stabila arbetsbelastningarna. Resten lämnas på on-demand eller Spot. Den här mixen ger genomsnittligt 58–62 % rabatt med bibehållen migrationsfrihet. I mitt senaste uppdrag för ett spelbolag i Stockholm landade vi på exakt 61 % efter åtta veckor av iteration.

När är Reserved Instances fortfarande rätt val?

Reserved Instances är fortfarande det enda alternativet för flera AWS-tjänster där Savings Plans inte erbjuds. Det gäller framför allt managed databases: RDS, Aurora, ElastiCache (Redis och Memcached), OpenSearch, Redshift och DocumentDB. För dessa tjänster ger Standard RIs typiskt 40–60 % rabatt över 3 år. Convertible RIs finns inte för databaser, så valet står mellan Standard RI eller on-demand.

Ett konkret exempel: ett SaaS-företag jag arbetade med körde 18 RDS-instanser av typen db.r6g.2xlarge Multi-AZ i Stockholm för ungefär 480 000 USD per år on-demand. Genom att teckna 3-åriga Standard RIs (all upfront) sjönk kostnaden till 188 000 USD per år, en besparing på 60 % som motsvarade 876 000 USD över löptiden. Inga Savings Plans i världen hade matchat det, eftersom AWS helt enkelt inte erbjuder Savings Plans för RDS ännu.

RIs har också en sekundärmarknad. Om dina behov förändras kan du sälja onödiga Standard RIs på AWS Reserved Instance Marketplace till andra kunder. Compute Savings Plans saknar denna möjlighet helt: när du skrivit på är pengarna borta oavsett om du använder kapaciteten eller inte. För kapitalkänsliga organisationer kan den utträdesventilen göra RIs mer attraktiva trots lägre nominell flexibilitet.

Hur kombineras Savings Plans med Spot Instances?

Savings Plans och Spot Instances är komplement, inte konkurrenter. Spot ger 70–90 % rabatt mot on-demand men avbryts med två minuters varsel när AWS behöver kapaciteten. Strategin är ganska enkel: täck din stabila baslinje med Savings Plans och låt Spot ta toppbelastningen. Den här genomgången av Kubernetes right-sizing med VPA och Goldilocks visar samma princip på containernivå.

Praktiskt exempel från ett dataanalysteam: 12 m6i.4xlarge körs kontinuerligt för dashboards och API:er (täckta av Compute SP), medan 80–200 Spot-instanser provisioneras dynamiskt av Karpenter för Spark-jobb. Resultatet: 64 % effektiv rabatt på den totala compute-budgeten, jämfört med 38 % när allt låg på on-demand med RIs.

# Exempel: Karpenter NodePool som blandar Spot och on-demand-bas
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: mixed-savings
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]   # Spot foerst, fallback till on-demand
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["m6i.2xlarge", "m6i.4xlarge", "m7g.4xlarge"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  limits:
    cpu: 1000
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s

Konfigurationen ovan låter Karpenter välja Spot när det är tillgängligt och falla tillbaka till on-demand (som täcks av din Compute Savings Plan) när Spot-priser eller -kapacitet inte räcker. Den genomsnittliga rabatten blir då en vägd kombination av Spot-rabatten (cirka 75 %) och Savings Plans-rabatten (66 %). Jag har sett mixen krascha en gång när någon tog bort on-demand från values-listan, så lämna alltid båda kvar.

FinOps-beslutsmodell i fem steg

Den här checklistan använder jag på varje nytt FinOps-uppdrag innan jag rekommenderar någon form av åtagande. Den tar typiskt två dagar att gå igenom, och betalar sig oftast tillbaka inom en månad.

Mät den stabila baslinjen. Exportera 90 dagars timgranulär användning per tjänst via Cost and Usage Report (CUR) till S3, ladda in i Athena och beräkna 5:e percentilen per timme. Det är din säkra åtagandenivå.
Separera flexibla från låsta arbetsbelastningar. Databaser och statefulla tjänster är låsta, så där väljer du RIs. Stateless compute är flexibelt, så där väljer du Compute SP.
Validera mot tre års plan. Om produktstrategin innebär migration till serverless inom 18 månader, teckna 1-årigt åtagande istället för 3-årigt även om rabatten är mindre.
Räkna NPV med diskonteringsränta. All upfront sparar nominellt 4–6 procentenheter mot no upfront, men kapitalet kostar. Med 8 % diskonteringsränta är partial upfront ofta optimalt.
Implementera i lager. Börja med 50 % av baslinjen, mät i en månad, lägg sedan på resterande 20–30 %. Lämna alltid en buffert för right-sizing och oväntade avstängningar.

Vår genomgång av FinOps för AI och GPU-kostnader visar hur samma beslutsmodell appliceras på P5- och G6-instanser, där brytpunkterna är ännu skarpare.

Vanliga misstag som kostar miljoner

Efter att ha granskat tjugotvå svenska AWS-konton de senaste två åren ser jag samma misstag igen och igen. Här är de tre dyraste.

Att blint följa Cost Explorers rekommendationer

AWS Cost Explorers Savings Plans-rekommendationer bygger på de senaste 7, 30 eller 60 dagarna. Om du nyss skalat upp för Black Friday rekommenderas du att binda topparna i tre år. Filtrera alltid bort kampanjperioder, A/B-testfönster och migrationsfaser innan du läser rekommendationen.

Att glömma att Savings Plans inte täcker EBS, dataöverföring eller NAT Gateway

Savings Plans rabatterar endast själva compute-timmarna. Om din EC2-faktura består av 40 % compute och 60 % EBS gp3, dataöverföring mellan AZ och NAT Gateway-trafik, har en 66 % SP-rabatt bara minskat 40 % av kostnaden, alltså en effektiv besparing på 26 %. Ofta är right-sizing av EBS-volymer och konsolidering till VPC-endpoints en större vinst.

Att teckna åtagande för Linked Accounts utan portföljvy

Savings Plans tillämpas hierarkiskt i AWS Organizations: först på det konto som tecknat planen, sedan på syskonkonton. Om team A tecknar Compute SP för 5 USD/timme medan team B har överkapacitet på 8 USD/timme, kan team B:s överskott "äta upp" team A:s plan utan att A märker det. Aktivera RI/SP-rabattdelning bara där det medvetet är önskvärt, och använd taggning med rabattbarhetsattribut. Detaljerna finns i AWS dokumentation om hur Savings Plans tillämpas.

Vanliga frågor

Vad är skillnaden mellan Savings Plans och Reserved Instances?

Savings Plans är ett dollarbaserat åtagande per timme som flexibelt täcker EC2, Fargate och Lambda. Reserved Instances är ett instansbaserat åtagande låst till en specifik typ. Savings Plans erbjuder mer flexibilitet, RIs erbjuder något högre maxrabatt och är fortfarande enda alternativet för RDS, ElastiCache och Redshift.

Hur stor rabatt ger Savings Plans i praktiken?

Compute Savings Plans ger upp till 66 % rabatt över 3 år med all upfront. EC2 Instance Savings Plans ger upp till 72 %. I genomsnitt landar svenska kunder på 45–60 % effektiv rabatt, eftersom inte 100 % av baslinjen åtagandebeläggs.

Kan man kombinera Spot Instances med Savings Plans?

Ja, helt fritt. Savings Plans täcker bara on-demand-priset. Spot-instanser körs på Spot-priset och berörs inte. Den vanligaste arkitekturen är Savings Plans för baslinjen och Spot för toppar via Karpenter eller EC2 Auto Scaling-grupper med mixed instances policy.

Vad händer om jag inte använder min Savings Plan en månad?

Du faktureras hela det timåtagande du tecknat även om ingen användning matchar. Det är därför man aldrig bör täcka mer än 80 % av sin uppmätta baslinje. Outnyttjad kapacitet kan inte säljas vidare som med Standard RIs.

Hur länge är åtagandet för Savings Plans?

1 eller 3 år. 3-årigt åtagande ger cirka 20 procentenheter större rabatt. Återbetalningstiden för 3-årigt all upfront är typiskt 14–18 månader vid 70 % utnyttjande, så det dominerande valet i mogna FinOps-organisationer är 3-årigt åtagande på Compute SP för den stabila baslinjen.