FinOps og Omkostningsstyring 12 min læsning

Savings Plans vs Reserved Instances i 2026: Multi-Cloud Guide til AWS, Azure og GCP

Lær at vælge mellem Savings Plans, Reserved Instances og CUDs på tværs af AWS, Azure og GCP. Med CLI-eksempler, beregningsformler og en lagdelt strategi der kan spare dig op til 50% på din cloud compute-regning.

Editorial Team

Hvorfor Rabatforpligtelser Er Din Største Uudnyttede Besparelse

Her er et tal, der burde få enhver cloud-ansvarlig til at spærre øjnene op: organisationer der kun fokuserer på at slette ubrugte ressourcer, reducerer typisk omkostningerne med 10-20%. Det lyder da fint nok, ikke? Men teams der også optimerer deres commitment-dækning? De rammer 30-50% reduktion — uden at ændre en eneste linje applikationskode.

Alligevel viser State of FinOps 2026-rapporten, at hele 21% af virksomhedernes cloud-budgetter stadig går til spilde. Det er ret vilde penge, der bare fordamper.

Problemet er egentlig ikke, at rabatforpligtelser er komplicerede i sig selv. Problemet er, at hver cloud-udbyder kalder dem noget helt forskelligt, strukturerer dem på sin egen måde og har vidt forskellige regler for fleksibilitet, opsigelse og kapacitetsreservation. AWS har Savings Plans og Reserved Instances. Azure har Reservations og Savings Plans. GCP har Committed Use Discounts og Sustained Use Discounts. Det er — ærligt talt — et minefelt, især i multi-cloud-miljøer.

Så lad os få styr på det hele.

I denne guide gennemgår vi samtlige commitment-modeller på tværs af AWS, Azure og GCP, med reelle prissammenligninger, CLI-eksempler du kan kopiere direkte, beregningsformler og en konkret lagdelt strategi der sikrer dig de bedste rabatter uden at binde dig til spild.

Overblik: Commitment-Modeller På Tværs af Udbydere

Før vi dykker ned i detaljerne, er her et samlet overblik. Gem denne tabel — du får brug for den:

Funktion AWS Azure GCP
Primær model Savings Plans + Reserved Instances Reservations + Savings Plans Committed Use Discounts (CUDs)
Automatiske rabatter Nej Nej Ja (Sustained Use Discounts)
Maksimal rabat Op til 72% Op til 72% Op til 70%
Bindingsperioder 1 eller 3 år 1 eller 3 år 1 eller 3 år
Fleksibilitet Høj (Compute SP) Høj (Savings Plans) Moderat-Høj (Spend-based CUDs)
Kapacitetsreservation Kun RIs Kun Reservations Kun Resource-based CUDs
Videresalg Ja (Standard RIs) Nej Nej

AWS: Savings Plans og Reserved Instances

AWS tilbyder to fundamentalt forskellige commitment-modeller, og forskellen mellem dem er faktisk ret afgørende for din strategi.

Savings Plans: Fleksibilitet Først

Med en Savings Plan forpligter du dig til et fast beløb per time i USD over 1 eller 3 år. AWS anvender så automatisk rabatterede priser på al kvalificeret forbrug op til dette beløb. Simpelt nok koncept — men der er tre varianter, og det er her det bliver vigtigt at vælge rigtigt:

  • Compute Savings Plans — op til 66% rabat. Dækker EC2, Fargate og Lambda. Fuld fleksibilitet på tværs af instansfamilier, regioner, OS og tenancy. Det er den mest populære type af en god grund.
  • EC2 Instance Savings Plans — op til 72% rabat. Bundet til en specifik instansfamilie i en specifik region, men stadig fleksibel på størrelse, OS og tenancy.
  • SageMaker Savings Plans — specifikt til ML-workloads på SageMaker. Relevant hvis du kører tunge ML-pipelines.

Reserved Instances: Maksimal Rabat, Mindre Fleksibilitet

Reserved Instances (RIs) er den ældre model. Du forpligter dig til en specifik instanstype i en specifik region, og til gengæld får du den dybeste rabat. De fås i to varianter:

  • Standard RIs — op til 72% rabat. En bonus her: de kan videresælges på AWS Reserved Instance Marketplace (AWS tager 12% gebyr, men det er bedre end at sidde fast med ubrugte RIs).
  • Convertible RIs — op til 54% rabat. Kan konverteres til andre instanstyper, tenancies og OS'er, hvilket giver noget mere fleksibilitet.

Vigtigt at vide: RDS, ElastiCache, OpenSearch og Redshift er ikke dækket af Savings Plans. Så for managed databases er Reserved Instances din eneste vej til commitment-rabatter. Det overser mange teams desværre.

Sådan Tjekker Du Din Nuværende Dækning med AWS CLI

Før du køber noget som helst, skal du forstå dit nuværende forbrug. Her er de CLI-kommandoer, du får brug for:

# Se nuværende Savings Plans-dækning
aws ce get-savings-plans-coverage   --time-period Start=2026-03-01,End=2026-04-01   --granularity MONTHLY

# Hent AWS-anbefalinger til Savings Plans
aws ce get-savings-plans-purchase-recommendation   --savings-plans-type COMPUTE_SP   --term-in-years ONE_YEAR   --payment-option NO_UPFRONT   --lookback-period-in-days SIXTY_DAYS

# Se RI-udnyttelse
aws ce get-reservation-utilization   --time-period Start=2026-03-01,End=2026-04-01   --granularity MONTHLY

Køb en Compute Savings Plan via CLI

# Køb en 1-årig Compute Savings Plan på $5/time (ingen forudbetaling)
aws savingsplans create-savings-plan   --savings-plan-offering-id <offering-id>   --commitment 5.0   --savings-plan-type ComputeSavingsPlans   --term ONE_YEAR   --payment-option NoUpfront

For at finde det korrekte offering-id:

aws savingsplans describe-savings-plans-offering-rates   --savings-plan-type ComputeSavingsPlans   --filters Name=region,Values=eu-west-1   --query "searchResults[0:5]"

Azure: Reservations og Savings Plans

Azure har siden 2022 tilbudt sin egen version af Savings Plans ved siden af de klassiske Reservations. Det minder meget om AWS' model, men der er et par vigtige forskelle.

Azure Reservations

Azure Reservations er direkte sammenlignelige med AWS Reserved Instances. Du forpligter dig til en specifik VM-størrelse i en specifik region over 1 eller 3 år og får op til 72% rabat. Reservationer dækker en hel del tjenester:

  • Virtual Machines
  • Azure SQL Database
  • Azure Cosmos DB
  • Azure Synapse Analytics
  • App Service (Premium-plan)
  • Azure Managed Disks

Azure Hybrid Benefit: Her har Azure en ret unik fordel. Du kan kombinere reservationer med eksisterende Windows Server- eller SQL Server-licenser via Azure Hybrid Benefit. Det kan reducere dine effektive VM-omkostninger med yderligere 40-50% oven i reservationsrabatten. Hvis du allerede har Microsoft-licenser, er det nærmest gratis penge.

Azure Savings Plans

Azures Savings Plans fungerer ligesom AWS Compute Savings Plans — du forpligter dig til et beløb per time i USD, og rabatten gælder automatisk på tværs af VM-familier, regioner og OS. Der er to typer:

  • Savings Plan for Compute — 1 eller 3 år. Dækker Azure VMs, App Service, Azure Functions og Container Instances.
  • Savings Plan for Databases — kun 1-årig binding. Dækker Azure SQL Database og Managed Instance (kun Generation 7+). Denne er relativt ny og stadig lidt begrænset.

Køb en Azure Reservation via CLI

# Se anbefalinger for VM-reservationer
az consumption reservation recommendation list   --scope "Single"   --resource-type VirtualMachines   --look-back-period Last60Days

# Køb en reservation via Azure Portal anbefales,
# men du kan også bruge REST API:
az rest --method PUT   --url "https://management.azure.com/providers/Microsoft.Capacity/reservationOrders/ORDER_ID?api-version=2022-11-01"   --body @reservation-order.json

Indholdet af reservation-order.json:

{
  "sku": {
    "name": "Standard_D4s_v5"
  },
  "location": "westeurope",
  "properties": {
    "reservedResourceType": "VirtualMachines",
    "billingScopeId": "/subscriptions/SUBSCRIPTION_ID",
    "term": "P1Y",
    "quantity": 2,
    "displayName": "ProdWebServer-Reservation",
    "appliedScopeType": "Shared",
    "billingPlan": "Monthly"
  }
}

Vigtigt om Azure Trade-Ins

En stor fordel i Azure er muligheden for at trade-in eksisterende reservationer til en Savings Plan. Microsoft annullerer din reservation, udsteder en forholdsmæssig refusion og overfører værdien til din nye Savings Plan.

Men pas på: du kan ikke annullere eller ombytte Savings Plans — kun reservationer kan trades ind. Så tænk dig om, før du binder dig.

Refusionsgrænsen for reservationer er $50.000 USD per 12 måneder (rullende vindue).

GCP: Committed Use Discounts og Sustained Use Discounts

Google Cloud gør tingene lidt anderledes (som de plejer). De har to parallelle rabatsystemer — ét du aktivt køber, og ét der bare gælder automatisk. Det sidste er faktisk ret fedt.

Committed Use Discounts (CUDs)

CUDs er GCPs svar på Reserved Instances og Savings Plans. Der er to typer:

  • Resource-based CUDs — du forpligter dig til en specifik mængde vCPU og memory i en specifik region. Op til 57% rabat for standard maskintyper og op til 70% for memory-optimerede. Det er solide rabatter.
  • Spend-based (Flexible) CUDs — du forpligter dig til et beløb per time, som automatisk gælder på tværs af Compute Engine, GKE og Cloud Run. 28% rabat for 1 år, 46% rabat for 3 år.

Opdatering 2026: Fra den 21. januar 2026 migrerer Google automatisk kvalificerede faktureringskonti fra den gamle kreditbaserede spend-based CUD-model til en ny direkte rabatmodel. Tjek om din konto er berørt.

Sustained Use Discounts (SUDs)

SUDs er noget helt unikt for GCP — de kræver ingen forpligtelse overhovedet. Google anvender simpelthen automatisk stigende rabatter baseret på, hvor meget af måneden en ressource kører:

  • 25% af måneden: Første rabattrin aktiveres
  • 50% af måneden: Yderligere rabat
  • 75% af måneden: Endnu højere rabat
  • 100% af måneden: Maksimal SUD-rabat på op til 30%

Det smarte er, at du ikke skal gøre noget. Bare kør dine workloads, og rabatterne tikker ind.

En vigtig detalje: CUDs og SUDs stacker ikke. Forbrug dækket af en CUD er ikke kvalificeret til SUD. Men overskydende forbrug ud over din CUD-forpligtelse kan automatisk få SUD-rabat. Så de komplementerer hinanden ret godt i praksis.

Køb en Resource-Based CUD via gcloud CLI

# Køb en 1-årig CUD for 16 vCPUs og 64 GB memory i europe-west1
gcloud compute commitments create prod-commitment-eu   --region=europe-west1   --resources=vcpu=16,memory=64GB   --plan=12-month   --type=GENERAL_PURPOSE

# Tjek eksisterende commitments
gcloud compute commitments list   --regions=europe-west1   --format="table(name,status,plan,startTimestamp,endTimestamp)"

# Se CUD-anbefalinger
gcloud recommender recommendations list   --project=mit-projekt   --location=europe-west1   --recommender=google.compute.commitment.UsageCommitmentRecommender

Sådan Beregner Du Det Rigtige Commitment-Niveau

Okay, her kommer den del, der virkelig gør forskellen. Den mest kritiske — og mest fejlhåndterede — del af commitment-strategien er at beregne det rigtige beløb. Køber du for meget, betaler du for ubrugt kapacitet. Køber du for lidt, betaler du unødigt On-Demand-priser.

Trin 1: Analysér Dit Baseline-Forbrug (P10, Ikke Gennemsnit)

Den fejl jeg ser oftest er at dimensionere commitments efter gennemsnitligt forbrug. Gør det ikke. Brug i stedet dit P10-forbrug — altså det forbrug du ligger over i 90% af timerne. Under-udnyttet commitment er en permanent omkostning, og den kan du ikke få refunderet.

# AWS: Hent timebasis-forbrugsdata de seneste 60 dage
aws ce get-cost-and-usage   --time-period Start=2026-02-01,End=2026-04-01   --granularity HOURLY   --metrics "UnblendedCost"   --filter file://ec2-filter.json   --group-by Type=DIMENSION,Key=INSTANCE_TYPE

Trin 2: Brug 80%-Reglen som Udgangspunkt

En solid tommelfingerregel: dæk 80% af dit P10-forbrug med commitments. Det giver plads til nedadgående udsving uden at du taber penge på ubrugte forpligtelser.

Herefter monitorerer du månedligt og tilkøber trinvise commitments for at nærme dig den optimale dækningskurve. Tålmodighed betaler sig her.

Trin 3: Beregn Break-Even-Punktet

For at afgøre om en commitment overhovedet kan betale sig, skal du beregne break-even-punktet. Formlen er faktisk ganske simpel:

Break-Even Timer/Måned = (Commitment Timepris / On-Demand Timepris) × 730 timer

Lad os tage et konkret eksempel med en AWS m6i.xlarge i eu-west-1:

# On-Demand pris: $0,192/time
# 1-årig EC2 SP pris (No Upfront): $0,121/time
# Break-even: ($0,121 / $0,192) x 730 = 460 timer/måned

# Det svarer til ca. 15,3 timer/dag eller 63% udnyttelse.
# Kører din instans mere end det, sparer du penge med SP.

# Besparelse ved 100% udnyttelse:
# On-Demand: $0,192 x 730 = $140,16/måned
# Med SP: $0,121 x 730 = $88,33/måned
# Besparelse: $51,83/måned (37%)

63% udnyttelse som break-even — det er et ret lavt krav. De fleste produktionsworkloads slår det uden problemer.

Trin 4: Implementér en Lagdelt Strategi

Den mest modne FinOps-tilgang i 2026 kombinerer flere lag af rabatter. Tænk på det som en lagkage (en meget profitabel lagkage):

  1. Lag 1 — Compute Savings Plans / Flexible CUDs (60-70% af baseline): Dækker dit kerneforbrugsniveau med maksimal fleksibilitet. Vælg 1-årig No Upfront for lavest risiko.
  2. Lag 2 — Instance-specifikke RIs / Resource-based CUDs (10-15% af baseline): For instansfamilier du er helt sikker på ikke ændres. Giver dybere rabat end de fleksible planer.
  3. Lag 3 — On-Demand + SUDs (20-30%): Behold en buffer til vækst, spikes og eksperimenter. På GCP dækker Sustained Use Discounts automatisk en del af dette.
  4. Lag 4 — Spot Instances (variabelt): For fejltolerant og elastisk compute som kan håndtere interruptions. Ikke for alle workloads, men fantastisk til de rigtige.

Multi-Cloud Commitment-Strategi: Praktisk Eksempel

Lad os gøre det konkret. Her er et eksempel med en virksomhed der bruger $50.000/måned på compute fordelt på tre udbydere:

Udbyder Månedligt forbrug Optimal strategi Forventet besparelse
AWS ($30.000) 60% af total Compute SP $25/t + RDS RIs for 3 DB-instanser $10.500/md (35%)
Azure ($12.000) 24% af total VM Reservations + Hybrid Benefit $6.000/md (50%)
GCP ($8.000) 16% af total Resource-based CUDs + automatiske SUDs $3.200/md (40%)

Samlet besparelse: $19.700/måned — en reduktion på 39,4% af det samlede cloud compute-budget. Over et år er det $236.400 i besparelser. Det er ikke lommeenpenge.

Terraform-Eksempel: Automatisér Azure Reservation

Du kan (og bør, hvis du er seriøs omkring IaC) administrere dine Azure Reservations med Terraform:

resource "azurerm_capacity_reservation_group" "prod" {
  name                = "prod-reservation-group"
  resource_group_name = azurerm_resource_group.main.name
  location            = "westeurope"
}

resource "azurerm_capacity_reservation" "web_servers" {
  name                          = "web-server-reservation"
  capacity_reservation_group_id = azurerm_capacity_reservation_group.prod.id

  sku {
    name     = "Standard_D4s_v5"
    capacity = 4
  }
}

De 5 Største Fejl ved Cloud Commitment-Køb

Baseret på FinOps Foundation-data og (indrømmet) en del smertefulde erfaringer, er her de fejl der oftest spilder penge:

1. At Købe Commitments Før Right-Sizing

Denne ser jeg gang på gang. Teams forpligter sig før de har right-sized deres instanser. At låse spild fast til en rabat er stadig spild — bare til en lavere enhedspris. Det er lidt som at købe to kilo slik på tilbud, når du kun har brug for et halvt. Du sparede per kilo, men du smed stadig penge ud.

Kør altid en right-sizing-analyse først.

2. At Bruge Gennemsnitsforbrug Til Dimensionering

Som nævnt: dimensionér efter P10 (baseline), ikke gennemsnit. Et team med et gennemsnit på $20/time men en baseline på $12/time bør starte med commitments der dækker $12/time — ikke $20/time. Den forskel kan koste dig dyrt.

3. At Ignorere Time-Granularitet

Commitments afregnes per time. Har du workloads der kører intensivt 12 timer og er idle 12 timer, dækker en commitment reelt kun halvdelen. Analysér altid på timebasis — daglige eller månedlige gennemsnit skjuler dette mønster fuldstændigt.

4. Set-and-Forget Mentalitet

De fleste engineering-teams lader 20% af deres potentielle besparelser ligge ved at behandle commitments som engangsbeslutninger. Køb en gang, glem alt om det, og undre sig over regningen et år senere.

Overvåg udnyttelse og dækning månedligt og justér løbende. Det tager 30 minutter om måneden og kan spare dig tusindvis af dollars.

5. At Glemme Database-Tjenester

Savings Plans (AWS) og Savings Plans for Compute (Azure) dækker ikke managed databases. For RDS, Azure SQL, Cloud SQL og lignende skal du bruge Reserved Instances eller Reservations specifikt. Mange teams overser dette og ender med at betale fuld On-Demand-pris for databaser der kører 24/7/365. Det gør ondt på bundlinjen.

Overvågning og Løbende Optimering

Køb af commitments er kun begyndelsen. Her er et praktisk script til at holde øje med din dækning på tværs af udbydere:

#!/bin/bash
# commitment-monitor.sh — Tjek commitment-udnyttelse på tværs af udbydere

echo "=== AWS Savings Plans Dækning ==="
aws ce get-savings-plans-utilization   --time-period Start=$(date -u -v-30d +%Y-%m-%d),End=$(date -u +%Y-%m-%d)   --granularity MONTHLY   --query "Total.Utilization.UtilizationPercentage"

echo ""
echo "=== AWS RI Dækning ==="
aws ce get-reservation-coverage   --time-period Start=$(date -u -v-30d +%Y-%m-%d),End=$(date -u +%Y-%m-%d)   --granularity MONTHLY   --query "Total.CoverageHours.CoverageHoursPercentage"

echo ""
echo "=== GCP Commitment Status ==="
gcloud compute commitments list   --format="table(name,status,plan,statusMessage)"   --filter="status=ACTIVE"

echo ""
echo "=== Anbefalinger ==="
echo "--- AWS ---"
aws ce get-savings-plans-purchase-recommendation   --savings-plans-type COMPUTE_SP   --term-in-years ONE_YEAR   --payment-option NO_UPFRONT   --lookback-period-in-days THIRTY_DAYS

FAQ: Ofte Stillede Spørgsmål om Cloud Rabatforpligtelser

Kan jeg annullere en Savings Plan eller CUD efter køb?

Kort svar: nej. Hverken AWS Savings Plans, Azure Savings Plans eller GCP CUDs kan annulleres efter køb. AWS Standard Reserved Instances kan dog videresælges på Reserved Instance Marketplace, og Azure Reservations kan refunderes op til $50.000 USD per 12-måneders rullende vindue. Derfor anbefaler jeg altid at starte med 1-årige No Upfront-planer for at minimere risikoen.

Hvad sker der med ubrugt commitment per time?

Den går tabt. Ingen overførsel til næste time. Hvis du har en Savings Plan på $10/time og kun bruger for $7, betaler du stadig de fulde $10. Dét er grunden til, at dimensionering mod baseline (P10) og ikke gennemsnit er så afgørende.

Stacker GCP Sustained Use Discounts med Committed Use Discounts?

Nej, de stacker ikke. Forbrug dækket af en CUD er ikke kvalificeret til SUD. Men — og det her er den vigtige nuance — overskydende forbrug ud over din CUD-forpligtelse vil automatisk modtage SUDs baseret på den pågældende måneds udnyttelse. Den optimale strategi er at købe CUDs op til dit stabile baseline og lade SUDs håndtere de variable spikes.

Skal jeg vælge All Upfront, Partial Upfront eller No Upfront?

All Upfront giver den dybeste rabat (typisk 5-8% mere end No Upfront), men binder kapital og øger risikoen. For de fleste organisationer er No Upfront med 1-årig binding det bedste udgangspunkt — du får stadig 60-66% af den maksimale rabat med minimal risiko og ingen kapitalbinding. Start der, og overvej All Upfront når du har mere erfaring med dine forbrugsmønstre.

Hvordan fungerer Azure Hybrid Benefit sammen med reservationer?

De stacker — og det er her det bliver rigtigt interessant. Først reducerer reservationen din compute-pris med op til 72%, og derefter fjerner Hybrid Benefit licensomkostningen for Windows Server eller SQL Server. Samlet kan det betyde op til 80-85% besparelse sammenlignet med fuld On-Demand-pris med inkluderet licens. Har du eksisterende Microsoft-licenser, er det virkelig en no-brainer at kombinere de to.

Om Forfatteren Editorial Team

Our team of expert writers and editors.

Relaterede Artikler