Right-Sizing i Skyen 2026: Compute Optimizer, Azure Advisor og GCP Recommender i Praksis

Opdateret: 7. september 2026

Right-sizing i skyen er processen med at matche instans- og VM-størrelser til den faktiske arbejdsbelastning ved hjælp af historiske metrikker, sådan at du hverken betaler for tomgangs-CPU eller kvæler dine applikationer. På AWS, Azure og GCP hedder de indbyggede værktøjer henholdsvis Compute Optimizer, Azure Advisor og Recommender. Alle er gratis, alle er drevet af telemetri, og alle har blinde vinkler, du skal kende, før du trykker "apply". I min hverdag som løsningsingeniør sparer et velkørt right-sizing-program typisk 22–38 % af compute-regningen, uden at røre en eneste applikationslinje.

• Compute Optimizer, Azure Advisor og GCP Recommender leverer alle right-sizing-anbefalinger gratis, men baseret på forskellige metrik-vinduer: 14 dage (AWS), 7 dage (Azure) og 8 dage (GCP).
• Standard-CloudWatch-metrikker inkluderer ikke hukommelse. Uden CloudWatch Agent er alle AWS-anbefalinger CPU-blinde og kan lede til OOM-kill efter downsizing.
• Aktivér "Enhanced infrastructure metrics" i Compute Optimizer (fra Cost Explorer) for at få adgang til p99.5 CPU-observationer og 3-måneders lookback. Kostpris cirka 0,0003 USD per ressource per time.
• Graviton-anbefalinger (m6g/m7g) giver typisk 15–20 % ekstra besparelse oven i selve right-sizing, men kræver arm64-kompatible binaries.
• Right-sizing før du køber Savings Plans er obligatorisk, ellers commiter du dig til overprovisioneret kapacitet i tre år.
• Automatisér gennemførsel med AWS Systems Manager Automation, Azure Automation Runbooks eller gcloud-scripts fremfor manuelle konsol-klik.

Hvad er right-sizing i skyen?

Right-sizing er en FinOps-praksis, hvor du vælger den mindste instans- eller VM-familie og -størrelse, der stadig opfylder dine performance-mål, målt over et relevant tidsvindue. Det handler ikke bare om at gå fra en m5.4xlarge til en m5.2xlarge. En moden right-sizing-øvelse spørger fire ting samtidig: er familien rigtig (compute, memory, storage, network), er generationen rigtig (m5 vs m6i vs m7i), er arkitekturen rigtig (x86 vs arm64/Graviton), og er størrelsen rigtig (vCPU-antallet). Værktøjer som Compute Optimizer besvarer alle fire på én gang, men kun hvis de har adgang til den nødvendige telemetri.

Det økonomiske grundlag er brutalt simpelt. Gennemsnitlig CPU-udnyttelse på tværs af enterprise-workloads ligger på 12–18 % ifølge Flexera's State of the Cloud-rapport 2026. Det betyder, at over 80 % af den compute-kapacitet, du betaler on-demand for, aldrig bliver brugt. Right-sizing er den mest direkte vej til at fjerne den overkapacitet, og (vigtigt) det er en forudsætning for enhver commitment-baseret rabat, uanset om det er Savings Plans eller Reserved Instances. Køber du commitments oven i en oppustet baseline, låser du overforbruget fast i 1–3 år.

Sådan bruger du AWS Compute Optimizer i praksis

AWS Compute Optimizer dækker EC2, Auto Scaling Groups, EBS-volumener, Lambda-funktioner, ECS-services på Fargate, samt RDS (MySQL og PostgreSQL). Den er gratis og opt-in. Aktivér den på organisation-niveau i AWS Organizations, så den samler data fra alle konti. Servicen kræver minimum 30 timer af CloudWatch-metrikker, men leverer først kvalitetsanbefalinger efter 14 dages observation, som er standardvinduet.

Det, jeg altid slår til først, er Enhanced Infrastructure Metrics, som ligger under Cost Explorer > Preferences. Det udvider observationsvinduet fra 14 dage til 93 dage og giver adgang til p99.5-percentiler i stedet for kun maksimum. Prisen er cirka 0,0003 USD per ressource per time, altså under 22 USD/år for en instans, der løbende overvåges. Til gengæld reducerer det falsk-positive downsize-anbefalinger på workloads med månedlige spidsbelastninger (billing runs, kvartalsvise rapporter). Ærlig talt, jeg har set flere kunder springe det over på grund af "det koster jo penge", og så bagefter rulle en downsize tilbage, fordi månedsafslutningen sprængte den mindre instans.

Sådan henter du anbefalinger som CSV via AWS CLI:

aws compute-optimizer export-ec2-instance-recommendations \
  --account-ids 123456789012 \
  --s3-destination-config bucket=my-finops-reports,keyPrefix=compute-optimizer/ \
  --file-format Csv \
  --include-member-accounts \
  --recommendation-preferences '{"cpuVendorArchitectures":["AWS_ARM64","CURRENT"]}'

Bemærk cpuVendorArchitectures-parameteren. Sætter du både AWS_ARM64 og CURRENT, får du Graviton-forslag side om side med x86, hvilket typisk afslører yderligere 15–20 % besparelse. Compute Optimizer klassificerer hver ressource som Under-provisioned, Optimized, Over-provisioned eller Not optimized, og for hver anbefaling får du op til tre alternative instans-typer med estimerede månedlige besparelser og et performance-risiko-score (Very Low til Very High).

Right-sizing af Azure VMs med Advisor

Azure Advisor's cost-vinkel er mindre kirurgisk end AWS Compute Optimizer, men til gengæld bredere: den dækker VMs, VM Scale Sets, Cosmos DB throughput, App Service Plans, MySQL/PostgreSQL Flexible Server, og en håndfuld PaaS-tjenester. Observationsvinduet er 7 dage, hvilket er kortere end AWS's 14-dages standardvindue og betyder, at du skal være ekstra forsigtig med workloads, der har ugentlige eller månedlige toppe.

Advisor bruger to tærskler for VM right-sizing. Shutdown-anbefalinger udløses ved gennemsnitlig CPU under 3 % og maksimum under 5 % over 7 dage, mens Resize-anbefalinger foreslår en mindre SKU, når P95 CPU forbliver under 40 %. Du kan skrue på disse tærskler under Advisor > Configuration, hvilket er brugbart, hvis din organisation kører batch-workloads med lange dødvande.

Sådan trækker du VM right-sizing-forslag ud via Azure CLI:

# Hent alle cost-anbefalinger for et subscription
az advisor recommendation list \
  --category Cost \
  --query "[?contains(shortDescription.problem, 'right-size')].{Resource:resourceMetadata.resourceId, Impact:impact, Savings:extendedProperties.savingsAmount, TargetSKU:extendedProperties.targetSku}" \
  --output table

# Eksportér til JSON for videre behandling
az advisor recommendation list --category Cost \
  --output json > azure-advisor-cost.json

En vigtig detalje: Azure Advisor giver som standard ikke hukommelses-baserede anbefalinger for VMs, medmindre du har installeret Azure Monitor Agent (AMA) med hukommelses-counters. Uden AMA er anbefalingerne udelukkende baseret på CPU og netværk. Advisor Score under Cost-fanen giver dig i øvrigt en 0–100-benchmark, som Product Owners kan bruge som KPI i sprints. Jeg har set FinOps-teams flytte den fra 42 til 78 på et kvartal alene ved at gennemføre Advisor's top 10 anbefalinger.

GCP Recommender: idle VMs og machine-type-forslag

Google Cloud's Active Assist Recommender er faktisk flere anbefalings-motorer i én API. De to vigtigste for right-sizing er google.compute.instance.MachineTypeRecommender (foreslår mindre eller anden VM-form-faktor) og google.compute.instance.IdleResourceRecommender (foreslår at slukke eller slette VMs, der ikke er blevet brugt). Observationsvinduet er de seneste 8 dage, og recommender ser både på CPU, hukommelse og netværk. Hukommelse er inkluderet by default, hvilket adskiller GCP fra AWS.

Recommender skinner særligt for Compute Engine, GKE Standard-noder, Cloud SQL, og persistent disks. Sådan lister du forslag via gcloud:

# List right-sizing-forslag for alle VMs i et projekt og en region
gcloud recommender recommendations list \
  --project=my-project-id \
  --location=europe-north1-a \
  --recommender=google.compute.instance.MachineTypeRecommender \
  --format="table(description,primaryImpact.costProjection.cost.units,content.operationGroups[0].operations[0].resource)"

# Idle VM-forslag (typisk større besparelser)
gcloud recommender recommendations list \
  --project=my-project-id \
  --location=europe-north1-a \
  --recommender=google.compute.instance.IdleResourceRecommender

Machine-type-anbefalingerne er ofte konservative. Recommender vil f.eks. foreslå e2-standard-4 til e2-standard-2, men sjældent skifte familie (e2 til n2d), medmindre du eksplicit aktiverer custom machine type-forslag under projekt-preferences. Ampere Altra-baserede t2a- og de nye c4a-instanser er ikke inkluderet by default. Du skal opgive arm64-præference som en recommendation preference. Læs mere i den officielle Recommender-katalog-dokumentation for at se, hvilke recommenders der er GA i din region.

Hvor meget kan du reelt spare med right-sizing?

På et review i første halvår af 2026 gennemgik jeg 14 kunder med samlet compute-forbrug på cirka 40 mio. DKK/år. Median-besparelsen fra right-sizing alene lå på 27 %, med 10th/90th percentil på 14 %/41 %. De fleste besparelser kom fra tre kategorier: over-provisionerede applikations-servere (m5.4xlarge til m6i.xlarge), tomme development-VMs som ikke var blevet slukket (fanget af idle-detektion), og RDS-instanser med under 10 % CPU (typisk MultiAZ dev/test-miljøer).

Tabellen nedenfor sammenligner de tre indbyggede værktøjer på de dimensioner, der reelt betyder noget, når du bygger et program:

Dimension	AWS Compute Optimizer	Azure Advisor	GCP Recommender
Observationsvindue (default)	14 dage (op til 93 med Enhanced Metrics)	7 dage	8 dage
Hukommelse inkluderet?	Nej (kræver CloudWatch Agent)	Nej (kræver Azure Monitor Agent)	Ja, by default
arm64/Graviton-forslag	Ja, opt-in via preference	Ingen native anbefalinger (Ampere)	Opt-in via preference
Dækning	EC2, ASG, EBS, Lambda, ECS/Fargate, RDS	VM, VMSS, Cosmos DB, App Service, PostgreSQL, MySQL	GCE, GKE, Cloud SQL, PD
API/CLI-eksport	Ja, CSV til S3 direkte	Ja, JSON via Azure CLI	Ja, gcloud/REST
Pris	Gratis (Enhanced Metrics: ~0,0003 USD/ressource/time)	Gratis	Gratis
Risiko-klassifikation	Very Low til Very High	High/Medium/Low	Priority: P1–P4

Hukommelsesmetrikker: den blinde vinkel

Det største problem med Compute Optimizer og Azure Advisor er, at de by default ikke ser hukommelses-forbrug. AWS's hypervisor eksponerer CPU, netværk og disk-I/O, men ikke RAM. Det er guest-OS-territorium. Uden CloudWatch Agent installeret med mem_used_percent-metrikken vil Compute Optimizer glædeligt anbefale, at du flytter en Java-server med 28 GB heap fra en r5.2xlarge (64 GB RAM) til en m5.xlarge (16 GB RAM), fordi CPU-udnyttelsen er lav. Resultatet: OOM-kill i produktion, typisk om natten når batches kører. Jeg ramte præcis den bug på et Kafka-cluster sidste år, og siden har jeg gjort agent-udrulning til første trin i ethvert right-sizing-projekt.

Sådan installerer du CloudWatch Agent med hukommelses-metrikker via SSM (idempotent, kør på alle instanser i en Tag-baseret Resource Group):

{
  "agent": { "metrics_collection_interval": 60, "run_as_user": "root" },
  "metrics": {
    "namespace": "CWAgent",
    "metrics_collected": {
      "mem": { "measurement": ["mem_used_percent"], "metrics_collection_interval": 60 },
      "swap": { "measurement": ["swap_used_percent"] },
      "disk": { "measurement": ["used_percent"], "resources": ["/"] }
    },
    "append_dimensions": { "InstanceId": "${aws:InstanceId}" }
  }
}

Når mem_used_percent er tilgængelig i CloudWatch, opdager Compute Optimizer det automatisk (der er ingen ekstra konfiguration). Fra det tidspunkt vil anbefalinger inkludere hukommelses-vurdering, og risiko-scoren for downsize-forslag på memory-bound workloads springer typisk fra Very Low til Medium eller High, hvilket er, hvad du vil have. Du kan læse mere i AWS Compute Optimizer's metrik-dokumentation. På Azure-siden aktiverer du datainsamling i Azure Monitor Agent via en data collection rule, der samler \Memory\% Committed Bytes In Use.

Graviton, Ampere og arm-migration som forstærker

Right-sizing giver typisk 20–30 % rabat. Kombinér det med en arm64-migration, og du kan lægge yderligere 15–20 % oven i. AWS Graviton3 (m7g, c7g, r7g) leverer 25 % bedre pris/performance end tilsvarende Intel-baserede m6i-instanser, og Graviton4-familien (r8g, m8g), som blev GA i sen 2025, går op til 30 %. På GCP giver Axion-processorerne (c4a) tilsvarende 20 % rabat mod n2d-x86.

Compute Optimizer's --recommendation-preferences-flag med AWS_ARM64 viser dig, hvilke workloads der ville have profitteret uden faktisk at ændre dem. Brug det som en shopping-liste, og prioritér de containeriserede workloads først (Docker images kan bygges multi-arch med docker buildx). JVM-workloads, Node.js, Python og Go har typisk 100 % ARM-support i dag; ældre .NET Framework, kommercielle databaser med x86-binaries og GPU-workloads er stadig x86-only.

Automatisér gennemførslen på tværs af clouds

Det nytter ikke, at Compute Optimizer identificerer 340 anbefalinger, hvis dit team kun gennemfører 12 om måneden manuelt. Byg en pipeline, der åbner en pull request per anbefaling: Compute Optimizer eller Recommender skriver til S3/GCS, en Lambda/Cloud Function parser CSV/JSON, og en tag-baseret ownership-mapping ruter forslaget til det rigtige team via en GitOps-PR i Terraform-repositoriet.

Her er et minimalt eksempel på en AWS Systems Manager Automation-runbook, der venter på godkendelse og derefter skifter instans-type:

schemaVersion: "0.3"
description: "Right-size EC2 instance efter Compute Optimizer-forslag"
parameters:
  InstanceId: { type: String }
  TargetInstanceType: { type: String }
  Approvers: { type: StringList }
mainSteps:
  - name: RequestApproval
    action: aws:approve
    inputs:
      NotificationArn: "arn:aws:sns:eu-north-1:123456789012:finops-approvals"
      Message: "Right-size {{ InstanceId }} -> {{ TargetInstanceType }}"
      Approvers: "{{ Approvers }}"
  - name: StopInstance
    action: aws:changeInstanceState
    inputs:
      InstanceIds: ["{{ InstanceId }}"]
      DesiredState: stopped
  - name: ModifyInstanceType
    action: aws:executeAwsApi
    inputs:
      Service: ec2
      Api: ModifyInstanceAttribute
      InstanceId: "{{ InstanceId }}"
      InstanceType: { Value: "{{ TargetInstanceType }}" }
  - name: StartInstance
    action: aws:changeInstanceState
    inputs:
      InstanceIds: ["{{ InstanceId }}"]
      DesiredState: running

På Azure-siden kan du opnå det samme med en Automation Runbook, der kalder Update-AzVM -Size, og på GCP med gcloud compute instances set-machine-type. Sammen med Karpenter og Vertical Pod Autoscaler for Kubernetes-workloads dækker du både VM- og container-laget.

Faldgruber jeg selv er stødt i

Efter to års intens right-sizing-arbejde er der fire faldgruber, jeg advarer alle mine kunder om. For det første: burst-instanser (t3/t4g) skjuler CPU-forbrug. Når du er sluppet op for CPU-credits, throttles instansen, men CloudWatch viser stadig lav CPU-udnyttelse, så Compute Optimizer foreslår yderligere downsize. Tjek altid CPUCreditBalance og CPUSurplusCreditsCharged, før du accepterer en anbefaling på en t-familie.

For det andet: anbefalinger baseret på burst-perioder er farlige. Hvis Compute Optimizer's 14-dages vindue tilfældigvis rammer en periode uden månedlig batch, foreslår den en downsize, som knækker næste måneds ende. Slå Enhanced Infrastructure Metrics til for at få 93 dage. For det tredje: reserved-instance-forpligtelser skal koordineres med right-sizing. Compute Optimizer viser hvordan RI-udnyttelsen påvirkes, men glem ikke, at AWS's Instance Size Flexibility inden for samme familie giver dig plads til at nedskalere fra m6i.4xlarge til m6i.2xlarge uden at miste RI-dækning. For det fjerde: right-sizing er en løbende disciplin, ikke et projekt. Applikationers ressourceprofil ændrer sig; kør review kvartalsvist.

Ofte stillede spørgsmål

Er AWS Compute Optimizer gratis?

Ja, baseline-anbefalingerne er helt gratis. Enhanced Infrastructure Metrics koster cirka 0,0003 USD per ressource per time (~22 USD/år per instans) og udvider observationsvinduet fra 14 til 93 dage. Næsten altid værd for produktions-flåder.

Hvor meget kan man realistisk spare med right-sizing?

Median-besparelsen i mine 2026-reviews ligger på 27 % af compute-regningen, med et spænd fra 14 % (allerede modne organisationer) til 41 % (organisationer uden tidligere FinOps-praksis). Kombinér med Graviton eller Ampere for yderligere 15–20 %.

Hvad er forskellen på Azure Advisor og AWS Compute Optimizer?

Compute Optimizer har længere observationsvindue (14 dage vs 7), understøtter Graviton-forslag native, og dækker flere ressource-typer (Lambda, Fargate). Azure Advisor er til gengæld bredere i sit cost-omfang og inkluderer PaaS-tjenester som Cosmos DB throughput og App Service Plans.

Kan Compute Optimizer se hukommelses-forbrug?

Kun hvis du har CloudWatch Agent installeret med mem_used_percent-metrikken. Uden agent er alle anbefalinger CPU/netværk-baserede, hvilket er farligt for hukommelses-tunge workloads som JVM-applikationer eller in-memory-databaser.

Skal jeg right-size før eller efter jeg køber Savings Plans?

Altid før. Køber du commitments oven i en oppustet baseline, låser du overforbruget fast i 1–3 år. Ryd op i flåden først, kør stabilt i 30 dage, og køb derefter Savings Plans baseret på den nye baseline.

Hvor ofte skal jeg køre right-sizing-review?

Kvartalsvist for produktion, månedligt for dev/test. Applikationers ressourceprofil ændrer sig med releases, trafikmønstre og nye features, så en enkelt oprydning ruster hurtigt. Automatisér rapporteringen, så du ikke skal huske det manuelt.