GCP Committed Use Discounts 2026: Så sparar du upp till 70 % på Google Cloud

Uppdaterad: 21 juli 2026

Google Cloud Committed Use Discounts (CUDs) är ett rabattprogram där du åtar dig antingen en viss resursmängd eller ett minsta timkostnadsbelopp i 1 eller 3 år i utbyte mot upp till 70 % lägre pris på Compute Engine, GKE Autopilot och Cloud Run. Efter migreringen till direct discount-modellen som slutfördes den 21 januari 2026, och det utökade Flex CUD-täckningsområdet från september 2025, ser 2026 års CUD-landskap radikalt annorlunda ut än för bara 18 månader sedan. Jag har hjälpt team med multi-cloud-fotavtryck att välja mellan CUD, AWS Savings Plans och Azure Reservations, och ärligt talat är GCP:s modell fortfarande den mest missförstådda av de tre.

• Resursbaserade CUD ger 37–55 % rabatt (upp till 70 % för minnesoptimerade M-serier), men låser dig till en specifik region och maskinfamilj.
• Flex CUD (spend-based) ger 28 % för 1 år och 46 % för 3 år, men fungerar över Compute Engine, GKE Autopilot, Cloud Run och Cloud Run Functions.
• Från 21 januari 2026 är alla Flex CUD migrerade till direct discount-modellen. Rabatten dras direkt från SKU-priset istället för att synas som kreditreverseringar.
• Nya faktureringskonton som skapats efter 16 juni 2026 har CUD-delning aktiverad by default, så resursbaserade rabatter delas automatiskt mellan alla projekt.
• Sustained Use Discounts (SUDs) ger 20–30 % rabatt automatiskt utan åtagande. De flesta team glömmer att räkna med detta i sina CUD-kalkyler.
• Jämfört med AWS är GCP:s max-rabatt lägre (70 % vs 72 %), men No Upfront är enda betalningsmodellen, vilket sänker likviditetsrisken.

Vad är GCP Committed Use Discounts?

Committed Use Discounts är Google Clouds motsvarighet till AWS Savings Plans / Reserved Instances och Azure Reservations. Du åtar dig antingen en mängd Compute Engine-resurser (vCPU + minne) i en specifik region eller ett timbaserat spendbelopp, och i utbyte får du 28–70 % lägre pris under 1 eller 3 år. Åtagandet är bindande. Du kan inte säga upp en CUD i förtid, så all analys handlar egentligen om att hitta din "faktiska baseline", alltså den nivå av användning som du är helt säker på kommer att finnas kvar om ett år eller tre.

Det finns två huvudsakliga varianter: resursbaserade CUD (djupast rabatt men rigid) och Flex CUD (bredare täckning men lägre rabatt). Dessa två går att kombinera, och de flesta seriösa GCP-team gör det. Resursbaserade CUD täcker den stabila kärnkapaciteten, Flex CUD det som rör sig. Utöver dessa två får du Sustained Use Discounts gratis, utan åtagande. Det är en detalj som ofta försvinner i multi-cloud-jämförelser eftersom AWS och Azure inte har någon motsvarighet.

CUD gäller inte för alla Google Cloud-tjänster. De täcker Compute Engine, GKE (både Standard-noder och Autopilot), Cloud Run, Cloud Run Functions, Cloud SQL, Cloud Spanner, Memorystore, samt vissa AI/ML-tjänster som Vertex AI. BigQuery använder ett eget commitment-system (slots och Editions-reservationer) och räknas inte som en CUD i strikt bemärkelse.

Resursbaserad CUD vs Flex CUD: skillnaden 2026

Skillnaden mellan de två varianterna avgör i praktiken hela din besparingsstrategi. Resursbaserade CUD är åtaganden på specifika vCPU-kärnor och minne i en specifik region för en specifik maskinfamilj. Om du åtar dig 100 vCPU N2 i us-central1 och sen migrerar workloaden till europe-west1, eller byter till C3-maskiner, så förfaller din CUD outnyttjad. Du fortsätter betala men får ingen rabatt tillbaka. Flex CUD, däremot, är ett åtagande på ett timbaserat spendbelopp som appliceras dynamiskt över alla dina eligible resurser i alla regioner.

Egenskap	Resursbaserad CUD	Flex CUD (spend-based)
Åtagandetyp	Specifik vCPU + minne i en region	USD-belopp per timme
Rabatt 1 år	37–55 %	28 %
Rabatt 3 år	57–70 % (M-serier)	46 %
Flexibilitet region	Låg, låst till en region	Hög, alla regioner
Flexibilitet maskintyp	Låg, låst till en familj	Hög, alla eligible VM-familjer
Täcker GKE Autopilot & Cloud Run	Nej	Ja
Uppgradering vid nya maskingenerationer	Kräver ombokning	Automatisk
Bäst för	Stabil baseline, kända regioner	Skiftande workloads, containeriserad drift

Ett räkneexempel

Anta en steady-state produktionsmiljö med 500 vCPU N2-standard-4 i europe-west1, körande 24/7. On-demand-priset ligger ungefär på $0,0388/vCPU-timme, alltså $17 000/månad för hela flottan. Med en 3-års resursbaserad CUD (~55 % rabatt) betalar du ~$7 650/månad. Med en 3-års Flex CUD (46 % rabatt) betalar du ~$9 180/månad. Skillnaden är $1 530/månad, eller $55 000 över 3 år.

Men (och det är hela poängen), om ni någon gång under de 3 åren migrerar hälften av flottan till C3 eller till europe-west4, tappar den resursbaserade CUD sin effekt på den delen. Flex CUD följer med. I mitt hjälparbete med team som ligger på Google Cloud har jag sett en tumregel utkristallisera sig: om du har mindre än 60 % konfidens att både region och maskinfamilj kommer att vara oförändrade om 12 månader, ta Flex. Har du hög konfidens, ta resursbaserad och plocka de extra procenten.

CUD-nyheter 2026: direct discount, delning, utökad täckning

Tre förändringar under 2025–2026 har omdefinierat hur CUD ser ut i praktiken. Om ditt team senast rörde vid CUD 2023 eller tidigare är sannolikheten stor att er nuvarande strategi baseras på antaganden som inte längre stämmer.

1. Direct discount-modellen (fullt utrullad januari 2026)

Tidigare fungerade Flex CUD som en kreditmodell: du betalade full on-demand-taxa och fick sen en negativ krediterad rad i fakturan som representerade rabatten. Detta gjorde kostnadsallokering till ett helvete. Teamet som körde workloaden såg fullpriset i sin projektfaktura, medan krediten landade på faktureringskontot. Från och med 21 januari 2026 är alla Flex CUD migrerade till direct discount-modellen, där rabatten dras direkt från SKU-priset innan fakturan skrivs. Slutkostnaden är identisk, men allokerings- och chargeback-processer blir dramatiskt mycket enklare.

2. CUD Sharing default för nya konton (16 juni 2026)

Tidigare var resursbaserade CUD låsta till det projekt de köptes i, om inte administratören manuellt aktiverade CUD sharing på faktureringskontot. Från och med 16 juni 2026 är CUD-delning aktiverad by default för alla nya Cloud Billing-konton. Det betyder att en resursbaserad CUD köpt i projekt "produktion" automatiskt kan konsumeras av matchande användning i "staging" eller "data-platform", så länge de tillhör samma faktureringskonto. Konton som skapats före 16 juni 2026 måste fortfarande aktivera detta manuellt via Console → Billing → Commitments → Sharing.

3. Flex CUD täcker nu GKE Autopilot, Cloud Run och H4D HPC

I september 2025 utökade Google Flex CUD-täckningen från de gamla N1/N2/E2/N2D + C2/C2D-familjerna till att inkludera minnesoptimerade familjer, H3/H4D HPC-maskiner, Cloud Run request-based billing och Cloud Run Functions. Det praktiska värdet? Ett enda Flex CUD-åtagande kan nu täcka en workload som består av en Compute Engine-VM för databaser, en GKE Autopilot-kluster för microservices och några Cloud Run-endpoints för event-handlers. Innan denna förändring behövde du separata mekanismer per tjänst.

Så köper du en CUD i praktiken (steg-för-steg)

Kraftfulla verktyg är värdelösa om de aldrig aktiveras. Här är det konkreta arbetsflödet jag använder när jag går in i ett nytt GCP-konto och ska implementera CUD för första gången.

1. Kör Recommender API för CUD-förslag. Google har en inbyggd rekommendation som analyserar 30 dagars användning och föreslår ett åtagandebelopp. Från gcloud CLI:

gcloud recommender recommendations list \
  --project=$PROJECT_ID \
  --location=global \
  --recommender=google.compute.commitment.UsageCommitmentRecommender \
  --format="table(name.basename(),content.overview.commitmentType,content.overview.estimatedMonthlySavings)"

2. Verifiera baseline mot din faktiska cost-tabell. Recommender-förslaget baseras på senaste 30 dagarna. Om ni haft en säsongstopp eller en engångskampanj kan förslaget vara för högt. Kör en manuell kontroll i BigQuery-exporterade billing-data:

SELECT
  service.description AS service,
  sku.description AS sku,
  AVG(usage.amount_in_pricing_units) AS avg_hourly_usage,
  MIN(usage.amount_in_pricing_units) AS min_hourly_usage
FROM `PROJECT.billing_export.gcp_billing_export_v1_XXXX`
WHERE service.description IN ('Compute Engine', 'Kubernetes Engine', 'Cloud Run')
  AND usage_start_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY) AND CURRENT_TIMESTAMP()
GROUP BY service, sku
ORDER BY avg_hourly_usage DESC
LIMIT 20;

Använd MIN(usage) som konservativ baseline. Det är den nivå som alltid finns där, oavsett tid på dygnet eller år.

3. Välj typ och löptid. För baseline-delen: resursbaserad 3-års CUD om region och maskinfamilj är säkra, annars Flex 3-års CUD. För experimentella eller föränderliga workloads: Flex 1-års CUD.
4. Aktivera CUD Sharing. Om ni har fler än ett projekt på samma faktureringskonto, kontrollera att sharing är på. Nya konton (efter 16 juni 2026) har detta på by default; äldre konton måste aktivera manuellt.
5. Köp via Console eller Terraform. Med Terraform-provider google_compute_region_commitment för resursbaserad:

resource "google_compute_region_commitment" "prod_baseline" {
  name        = "prod-baseline-3yr"
  project     = var.project_id
  region      = "europe-west1"
  plan        = "THIRTY_SIX_MONTH"
  type        = "GENERAL_PURPOSE_N2"

  resources {
    type   = "VCPU"
    amount = "200"
  }
  resources {
    type   = "MEMORY"
    amount = "800"  # GB
  }
}

6. Övervaka utnyttjande. Sätt upp en larmpolicy i Cloud Monitoring som varnar när CUD-utnyttjandet faller under 90 %. Oanvänd CUD är rent slöseri.

GCP CUD vs AWS Savings Plans vs Azure Reservations

De tre stora molnleverantörerna erbjuder ytligt sett liknande commitment-produkter, men mekaniken skiljer sig radikalt. Om du sitter på multi-cloud-strategi och försöker jämföra äpplen med äpplen, är detta den tabell jag återkommer till oftare än någon annan i mina egna projekt.

Dimension	GCP CUD	AWS Savings Plans / RI	Azure Reservations / Savings Plans
Max rabatt (3 år)	70 % (M-serier)	72 % (RI, All Upfront)	66–72 % (Reserved VM)
Flexibel rabatt (3 år)	46 % (Flex CUD)	66 % (Compute Savings Plans)	25–50 % (Savings Plan)
Uppfront-betalning	Nej (endast månadsvis)	Ja (All / Partial / No Upfront)	Ja (Full / Monthly)
Automatisk rabatt utan åtagande	Ja (SUD, 20–30 %)	Nej	Nej
Cross-service-täckning	Compute Engine, GKE, Cloud Run, CF	EC2, Fargate, Lambda	Främst Compute VMs
Licens-stackning	Nej	Nej	Ja (Azure Hybrid Benefit)
Cancel/exchange	Ej möjligt	RI kan bytas; Savings Plans nej	Reservations kan bytas/refunderas
Åtagandekomplexitet	Låg	Hög	Medel

Praktiskt betyder detta att om ditt team spenderar $50 000+/månad på Google Cloud och behöver planera 3 år framåt, är CUD nästan alltid mer förlåtande att köpa än AWS RI, eftersom du bara betalar månadsvis och slipper likviditetstoppen. Å andra sidan når AWS djupare rabatt om du är villig att lägga All Upfront på en 3-årig Standard RI. För en detaljerad jämförelse på AWS-sidan har vi en dedikerad guide om AWS Savings Plans vs Reserved Instances 2026, och för Azure-sidan gäller Azure Reservations vs Savings Plans.

En sak som ofta missas: GCP CUD har inget exchange-alternativ. AWS Reserved Instances kan bytas mellan familjer och regioner (med restriktioner) och Azure Reservations kan säljas tillbaka. Med GCP är beslutet slutgiltigt, vilket förstärker vikten av konservativ baseline-analys innan köp. Enligt Google Clouds officiella CUD-dokumentation är detta explicit angivet: åtaganden kan inte annulleras eller refunderas.

Sustained Use Discounts (SUDs): den bortglömda automatiska rabatten

Sustained Use Discounts är den underskattade parten av Google Clouds prissättning. SUD är en automatisk rabatt som appliceras när en VM körs mer än 25 % av en kalendermånad, utan åtagande, utan förkonfiguration, utan CUD-köp. För N1-instanser når rabatten upp till 30 % för en VM som kör hela månaden. För nyare familjer (N2, N2D, E2, C2, C2D) är rabatten inbyggd i list-priserna istället, vilket förklarar varför N2 ser "billigare" ut än N1 vid första anblick. SUD-fördelen är redan inkluderad.

Praktiska konsekvenser: om du redan kör N1-instanser 24/7 utan CUD har du redan en 30 %-rabatt via SUD. En 1-års Flex CUD på 28 % ger dig då i praktiken ingen inkrementell besparing på N1-fotavtrycket. Det här är en fallgrop jag har sett i minst tre kundprojekt där någon "sålde in" Flex CUD utan att räkna av SUD först. Ta alltid med SUD-nivån i baseline när du utvärderar CUD-ROI.

Ett annat missförstånd: SUD gäller inte för GKE Autopilot eller Cloud Run. Det gäller Compute Engine-VMs med kontinuerlig upptid. För containeriserade workloads är CUD (särskilt Flex) det enda sättet att sänka priset.

CUD-strategi per workload-typ

Inget commitment-schema är rätt för hela kontot. Här är den fördelning jag rekommenderar per workload-arketyp. Grunden är att åtagandet ska matcha workloadens förutsägbarhet, inte tvärtom.

Stabila produktions-VMs (24/7 databas, applikationsserver)

Resursbaserad 3-års CUD för 80–90 % av baseline-kapaciteten. Komplettera med Flex 3-års CUD för de återstående 10–20 % om tillväxten är osäker. Detta ger dig ~55 % rabatt på 80 % av flottan och 46 % på resten. Vägd genomsnittsrabatt landar runt 53 %.

GKE Autopilot / Cloud Run microservices

Enbart Flex CUD, 3 år, på ~70 % av genomsnittligt spend. Resursbaserad passar aldrig här eftersom Autopilot dynamiskt väljer maskintyper åt dig. Efter Flex CUD-utökningen i september 2025 finns ingen anledning att lämna dessa workloads utan rabatt.

AI/ML-training på Vertex AI

Vertex AI har egna commitment-typer separata från Compute CUD. För träning på TPU eller A2/A3-instanser är 3-års åtagande motiverat endast om ni har en stabil load. Annars är spot/preemptible VMs billigare. Vi går djupare på detta i vår guide om FinOps för AI och GPU-kostnadsminskning.

Batch-jobs och stateless workers

Ingen CUD alls. Använd Spot VMs (upp till 91 % rabatt) och låt Recommender-metrics visa vad som är kvar av baseline att covera. Det är samma mönster som gäller på AWS med EC2 Spot Instances i produktion, fast med Google Clouds egna terminologi.

Utvecklings- och test-miljöer

Sällan värt en CUD över huvud taget. Använd instance schedules för att stänga av VMs kvällstid och helger. 65 % besparing utan åtagande. Sätt Flex CUD endast om dev-flottan är stor nog att skapa en stabil baseline (>$5 000/månad).

Vanliga frågor om GCP CUD

Kan man avbryta eller sälja tillbaka en Committed Use Discount?

Nej. GCP CUD är bindande och kan inte avbrytas, bytas eller säljas tillbaka. Du måste betala månadsavgiften under hela löptiden (1 eller 3 år) även om du slutar använda resurserna. Detta skiljer sig från AWS Reserved Instances (kan bytas) och Azure Reservations (kan refunderas mot avgift).

Hur mycket rabatt ger en 3-års GCP CUD?

Resursbaserad 3-års CUD ger 57 % rabatt på standardmaskiner och upp till 70 % på minnesoptimerade M-familjer. Flex CUD (spend-based) ger 46 % rabatt på 3 år, applicerbar över alla eligible tjänster inklusive Compute Engine, GKE Autopilot, Cloud Run och Cloud Run Functions.

Vad är skillnaden mellan CUD och Sustained Use Discount (SUD)?

SUD är en automatisk rabatt som appliceras när en Compute Engine-VM körs mer än 25 % av en kalendermånad, utan åtagande. CUD kräver ett bindande 1- eller 3-årsåtagande men ger djupare rabatt. På N1-instanser ger SUD upp till 30 % automatiskt. På nyare maskinfamiljer (N2, E2, C2) är SUD inbakad i list-priset.

Vilken CUD-typ passar bäst för Kubernetes-workloads?

Flex CUD (spend-based) är nästan alltid rätt val för GKE, särskilt Autopilot där du inte styr maskintyp direkt. Sedan september 2025 täcker Flex CUD både GKE Standard och Autopilot samt Cloud Run. Resursbaserad CUD fungerar dåligt för Kubernetes eftersom pod-scheduling kan flytta workloads mellan maskintyper på ett sätt som slår sönder åtagandet.

Är GCP CUD billigare än AWS Savings Plans?

Nej, GCP har lägre maxrabatt än AWS: 70 % vs 72 % vid 3-års åtagande. Men GCP CUD kräver ingen uppfront-betalning (No Upfront är enda alternativet), vilket sänker likviditetsrisken. AWS når sina 72 % endast med All Upfront-betalning. På flexibel-sidan är AWS Compute Savings Plans (66 %) tydligt djupare än GCP Flex CUD (46 %).

Delas CUD automatiskt mellan projekt?

För faktureringskonton skapade efter 16 juni 2026: ja, CUD-delning är på by default. Resursbaserade CUD delas automatiskt mellan alla projekt på samma faktureringskonto som har matchande resursanvändning. För äldre konton måste sharing aktiveras manuellt via Console → Billing → Commitments → Sharing.