AWS Compute Optimizer Right-Sizing Gids…

Bijgewerkt: 9 juli 2026

AWS Compute Optimizer is een machine learning-gestuurde service die je EC2-instances, EBS-volumes, Lambda-functies, Auto Scaling Groups en ECS-taken op Fargate analyseert om gerichte right-sizing aanbevelingen te geven die typisch 25% tot 40% op je AWS-rekening besparen. In deze gids laat ik zien hoe ik Compute Optimizer in 2026 gebruik om over-provisioned workloads te vinden, gp2-volumes veilig naar gp3 te migreren, memory-over-allocation in Lambda op te sporen en de aanbevelingen te combineren met Compute Savings Plans voor de maximale ROI. Concrete SKU's, CLI-commando's en risico-inschattingen inbegrepen.

AWS Compute Optimizer is gratis (behalve de Enhanced Infrastructure Metrics-add-on voor $0,0003360215 per instance-uur) en analyseert 14 dagen aan CloudWatch-metrics per resource.
Voor EC2 identificeert de service over-provisioned, under-provisioned en optimized instances met concrete SKU-aanbevelingen (bijvoorbeeld m5.2xlarge naar m6i.large).
EBS-aanbevelingen richten zich op de gp2-naar-gp3-migratie: gp3 is standaard 20% goedkoper per GB en biedt losgekoppelde IOPS/throughput-provisioning.
Lambda-aanbevelingen sporen memory over-allocation op. Een 3.008 MB-functie die maar 512 MB gebruikt kost je 6x per invocatie.
Voor Auto Scaling Groups en ECS op Fargate levert Compute Optimizer aanbevelingen op basis van P95/P99-utilisatie in plaats van gemiddelden.
Combineer right-sizing altijd voor je Compute Savings Plans koopt, anders zit je vast aan overbodige capaciteit voor 1 of 3 jaar.

Wat is AWS Compute Optimizer?

AWS Compute Optimizer is een regionale service die machine learning gebruikt om historisch gebruik van je AWS-resources te analyseren en concrete aanbevelingen te doen voor een goedkopere of beter passende configuratie. In tegenstelling tot generieke tips uit AWS Trusted Advisor levert Compute Optimizer SKU-specifieke aanbevelingen: het zegt niet "kies een kleinere instance", maar "vervang je huidige m5.2xlarge door een m6i.large, met een verwachte besparing van $187,20 per maand en 3% risico op prestatievermindering". Dat verschil telt zwaar als je aan een change advisory board moet uitleggen waarom je iets aanpast.

De service ondersteunt in 2026 vijf resourcetypes: EC2-instances, EBS-volumes, Lambda-functies, Auto Scaling Groups en ECS-services op Fargate. Onder de motorkap consumeert de service standaard 14 dagen aan CloudWatch-metrics (CPU, memory als de agent is geïnstalleerd, netwerk, disk I/O) en maakt vergelijkingen met tienduizenden vergelijkbare workloads binnen AWS. Voor productie-workloads met stabiele patronen kun je de analysewindow uitbreiden naar 3 maanden via Enhanced Infrastructure Metrics. Dat is vooral nuttig voor workloads met maandelijkse batchcycli.

Ik gebruik Compute Optimizer als de eerste stap in elke FinOps-engagement omdat het onderscheid maakt tussen "gebruik minder resources" en "gebruik andere resources". Een EC2-instance verkleinen van m5.2xlarge naar m5.large is één type besparing; een generatie-upgrade van m5.2xlarge naar m6i.xlarge levert 8% besparing op zonder capaciteitsverlies, puur door prijs-per-prestatie-verbetering van de nieuwere generatie. Compute Optimizer maakt beide zichtbaar in één dashboard.

Compute Optimizer activeren en configureren

Compute Optimizer is standaard uitgeschakeld. Voor multi-account setups activeer je het op je AWS Organizations management account zodat je aanbevelingen krijgt voor alle member accounts. Onthoud dat de service regionaal is, je moet hem in elke regio waar je workloads draaien apart activeren.

Activeren via de CLI voor je hele organisatie:

# Activeer Compute Optimizer voor alle accounts in de organisatie
aws compute-optimizer update-enrollment-status \
    --status Active \
    --include-member-accounts \
    --region eu-west-1

# Controleer inschrijvingsstatus per member account
aws compute-optimizer get-enrollment-statuses-for-organization \
    --region eu-west-1 \
    --output table

# Zet Enhanced Infrastructure Metrics aan voor productie-accounts
# (dit kost $0,0003360215 per instance-uur, ~$0,24 per instance/maand)
aws compute-optimizer put-recommendation-preferences \
    --resource-type Ec2Instance \
    --scope name=AccountId,value=123456789012 \
    --enhanced-infrastructure-metrics Active \
    --region eu-west-1

Na activering duurt het tot 24 uur voor de eerste aanbevelingen verschijnen, en workloads moeten minimaal 30 uur aan CloudWatch-data hebben voordat ze in aanmerking komen voor analyse. Nieuw uitgerolde instances verschijnen dus pas de dag erna. Als je memory-utilisatie wilt zien voor EC2-aanbevelingen (essentieel voor JVM- en Python-workloads), moet je de CloudWatch-agent op je instances installeren en de mem_used_percent-metric publiceren. Die stap ben ik ooit vergeten en dan zie je alleen CPU-aanbevelingen, wat voor Java-services vaak volledig naast de kwestie is.

EC2 right-sizing aanbevelingen analyseren

De EC2-aanbevelingen zijn de meest impactvolle. Voor elke EC2-instance categoriseert Compute Optimizer de resource als Under-provisioned, Optimized, Over-provisioned of None (te weinig data). Voor over-provisioned instances krijg je tot drie aanbevolen configuraties met daarbij geschatte maandelijkse besparingen en een performance risk-score van 1 tot 5.

Haal een overzicht op van alle over-provisioned instances met een risk score lager dan 2:

aws compute-optimizer get-ec2-instance-recommendations \
    --filters name=Finding,values=Overprovisioned \
    --region eu-west-1 \
    --output json \
    | jq '.instanceRecommendations[]
        | select(.recommendationOptions[0].performanceRisk <= 2)
        | {
            instance: .instanceArn,
            current: .currentInstanceType,
            recommended: .recommendationOptions[0].instanceType,
            monthly_savings: .recommendationOptions[0].estimatedMonthlySavings.value,
            risk: .recommendationOptions[0].performanceRisk
          }'

In de praktijk zie ik drie terugkerende patronen. Ten eerste: instances die zijn gekozen op basis van "wat we in on-prem hadden", zoals 32 GB RAM voor een webserver die 4 GB gebruikt. Ten tweede: instances die zijn geschaald voor piekbelasting die maar één keer per kwartaal voorkomt. Voor deze gevallen is een combinatie van right-sizing plus een Auto Scaling Group (met een schaalbeleid op basis van P95-utilisatie) beter dan permanente capaciteit. Ten derde: instances die nog op oude generaties draaien (m4, c4, r4) omdat niemand ooit een migratieplan heeft gemaakt.

Generatie-upgrades: een gratis besparing

De meeste engineers vergeten dat AWS elke instance-generatie 10-20% goedkoper prijst per prestatie-eenheid dan de vorige. Een migratie van m5.xlarge naar m7i.xlarge levert typisch 5-15% besparing op zonder capaciteitsverlies. Compute Optimizer's aanbevelingen prioriteren nieuwere generaties zolang de instance-familie beschikbaar is in je regio. Als je diepere analyse van generatiekeuzes wilt, lees dan onze vergelijking tussen Reserved Instances en Savings Plans. Die conclusie geldt ook voor right-sizing: begin altijd met de nieuwste generatie.

EBS-volumes: van gp2 naar gp3 migreren

Als je nog gp2-volumes gebruikt, laat je gewoon geld liggen. Zo simpel is het eigenlijk. gp3 is een nieuwere volumeklasse die standaard 3.000 IOPS en 125 MB/s throughput biedt bij een 20% lagere prijs per GB dan gp2. Compute Optimizer analyseert je gp2-volumes en genereert een aanbeveling met de exacte gp3-configuratie (baseline IOPS + extra provisioning indien nodig) die dezelfde of betere prestaties levert tegen lagere kosten.

Voor een simpele omgevingsbrede migratie kun je alle gp2-volumes met een CLI-loop naar gp3 omzetten:

# Lijst alle gp2 volumes op
gp2_volumes=$(aws ec2 describe-volumes \
    --filters Name=volume-type,Values=gp2 \
    --query 'Volumes[].VolumeId' \
    --output text \
    --region eu-west-1)

# Modificeer elk volume naar gp3 (baseline: 3000 IOPS, 125 MB/s)
for vol in $gp2_volumes; do
    echo "Migreren van $vol naar gp3..."
    aws ec2 modify-volume \
        --volume-id "$vol" \
        --volume-type gp3 \
        --region eu-west-1
    sleep 2  # respecteer rate limits
done

# Monitor progressie
aws ec2 describe-volumes-modifications \
    --volume-ids $gp2_volumes \
    --region eu-west-1

Voor volumes gekoppeld aan RDS-instances is de migratie iets anders: je verandert de storage type op de DB-instance zelf. Details staan in onze gids over cloud database kosten verlagen voor RDS, Azure SQL en Cloud SQL.

Lambda memory tuning met Compute Optimizer

Lambda-functies worden geprijst op basis van GB-seconden: memory-allocatie vermenigvuldigd met executietijd. Een functie met 3.008 MB die maar 512 MB gebruikt kost je 6x meer per invocatie dan nodig. Compute Optimizer analyseert de memory-utilisatie van je Lambda-functies en beveelt de optimale memory-allocatie aan.

Wat de meeste engineers missen: meer memory betekent niet altijd hogere kosten. Lambda's CPU-allocatie schaalt lineair met memory (elke 1.769 MB memory geeft één vCPU), dus voor CPU-gebonden werk kan een functie met méér memory sneller draaien en per saldo goedkoper zijn. Compute Optimizer's aanbevelingen houden rekening met dit effect, in tegenstelling tot naïeve memory-monitoring.

Haal Lambda-aanbevelingen op inclusief de kostenimpact:

aws compute-optimizer get-lambda-function-recommendations \
    --region eu-west-1 \
    --output json \
    | jq '.lambdaFunctionRecommendations[]
        | select(.finding != "Optimized")
        | {
            function: .functionArn | split(":")[-1],
            current_memory_mb: .currentMemorySize,
            recommended_memory_mb: .memorySizeRecommendationOptions[0].memorySize,
            finding: .finding,
            savings_month: .memorySizeRecommendationOptions[0].estimatedMonthlySavings.value
          }'

Werk je met veel Lambda-functies? Combineer Compute Optimizer met AWS Lambda Power Tuning, een open source tool die je functies daadwerkelijk invocateert op verschillende memory-configuraties en de sweet spot voor kosten of latency vindt. Compute Optimizer geeft goede uitgangspunten; Power Tuning verifieert ze empirisch. Voor bredere Lambda-optimalisatie zie onze gids over serverless kosten optimalisatie.

Auto Scaling Groups en ECS op Fargate

Auto Scaling Group-aanbevelingen zijn subtieler dan losse EC2-aanbevelingen. Compute Optimizer analyseert de gecombineerde utilisatie van alle instances in de ASG en beveelt óf een andere instance-type óf een andere ASG-configuratie aan. Voor stateless webservices zie ik regelmatig dat een ASG van 10x m5.large kan worden vervangen door 6x m6i.large met dezelfde totale capaciteit, tegen 25% lagere kosten.

Voor ECS-services op Fargate zijn de aanbevelingen anders van aard: Fargate-tasks worden apart geprijsd per vCPU en GB memory. Compute Optimizer analyseert de container-utilisatie via Container Insights en beveelt task-definitie updates aan. Een typisch resultaat: een task-definitie met 2 vCPU / 8 GB die op basis van P99-utilisatie eigenlijk 1 vCPU / 4 GB nodig heeft. Dat is een 50% besparing op elke draaiende task. Ik zag dit patroon vorig jaar bij een klant met zo'n 120 Fargate-tasks; die ene aanpassing scheelde ongeveer $3.400 per maand.

Compute Optimizer voor Fargate vereist ECS Container Insights. Activeer deze op cluster-niveau:

aws ecs update-cluster-settings \
    --cluster productie-cluster \
    --settings name=containerInsights,value=enabled \
    --region eu-west-1

Container Insights kost ongeveer $0,30 per taak per maand voor de CloudWatch-metrics, maar de right-sizing besparingen wegen daar bijna altijd tegenop. Als je Fargate combineert met Kubernetes op EKS, lees dan onze Kubernetes kostenoptimalisatie gids voor de bredere context.

Enhanced Infrastructure Metrics: is het de moeite waard?

Enhanced Infrastructure Metrics is een betaalde upgrade van Compute Optimizer die de analysewindow verlengt van 14 dagen naar 3 maanden en 1-minuut granulariteit gebruikt in plaats van 5-minuut. De prijs is $0,0003360215 per resource-uur, ongeveer $0,24 per EC2-instance per maand.

Wanneer heeft dit nut? In mijn ervaring: voor productie-workloads met patronen die zich per maand of kwartaal herhalen. Voorbeelden: end-of-month batch processing, quarterly billing runs, seasonal e-commerce pieken. De 14-daagse basisanalyse mist deze pieken en kan onterecht aanbevelen om te downsizen, met als gevolg dat je bij de volgende maandcyclus een outage krijgt. Die fout heb ik zelf een keer gemaakt met een payroll-service, en dat is niet leuk uitleggen aan de opdrachtgever.

Feature	Standaard (gratis)	Enhanced Metrics
Analysewindow	14 dagen	93 dagen (3 maanden)
Granulariteit	5 minuten	1 minuut
Kosten per instance/maand	$0,00	~$0,24
Detecteert maandelijkse pieken	Nee	Ja
Detecteert sub-uur pieken	Beperkt	Ja
Aanbevolen voor	Dev/staging, stateless workloads	Productie, batch, stateful

Voor een gemiddelde productie-omgeving met 100 instances kost Enhanced Metrics ongeveer $24 per maand. Als het één verkeerd right-size besluit voorkomt voor een instance van $500/maand, is de ROI direct terugverdiend.

Hoeveel kun je besparen met Compute Optimizer?

AWS's eigen cijfers claimen gemiddeld 25% besparing na implementatie van aanbevelingen. In mijn portefeuille van FinOps-engagements in 2025 en 2026 zag ik het volgende bereik:

EC2 right-sizing: 15-35% besparing op compute-kosten, met een gemiddelde van 22%.
gp2 naar gp3 migratie: 20-25% besparing op EBS-kosten, zonder configuratiewijziging. Dit is echt laaghangend fruit, vaak binnen een dag geïmplementeerd.
Lambda memory tuning: 10-40% besparing per functie, sterk afhankelijk van workload. High-throughput API-Lambdas hebben doorgaans meer impact dan cron-Lambdas.
ECS op Fargate: 25-50% besparing, want de meeste teams starten met te ruime task-definities.

De sleutel is right-sizing eerst, Savings Plans daarna. Als je een 3-jaars All Upfront Compute Savings Plan koopt voordat je right-sized hebt, zit je vast aan een commitment gebaseerd op je huidige (over-provisioned) uitgaven. Ik heb klanten gezien die $200K aan SP-commitment hadden op een baseline die 40% te hoog was. De SP-korting van 60% werd effectief 36% omdat de commitment zelf te groot was. Pijnlijk.

Aanbevelingen veilig in productie implementeren

Compute Optimizer geeft je een lijst; het uitrollen is jouw verantwoordelijkheid. Mijn checklist voor productie-implementatie:

Filter op performance risk score ≤ 2. AWS gebruikt een 1-5 schaal waarbij 1 = zeer laag risico. Voor productie start ik altijd met score 1-2 aanbevelingen; die met score 3+ vereisen load testing.
Gebruik een canary-approach. Voor ASG's: vervang eerst 10% van de instances met het nieuwe instance type en meet 48 uur voordat je verder rolt.
Monitor de juiste metrics. CPU en memory zijn niet genoeg. Voor stateful workloads meet ook StatusCheckFailed, applicatie-latency (P95/P99) en error rates. Compute Optimizer's aanbevelingen zijn statistisch, een enkele workload kan altijd een uitzondering zijn.
Gebruik Infrastructure as Code. Codeer de wijzigingen in Terraform of CloudFormation. Handmatige console-wijzigingen leiden tot configuratiedrift die je later duur betaalt.
Herzie elk kwartaal. Workloads veranderen. Zet een terugkerende kalenderafspraak om Compute Optimizer-aanbevelingen elk kwartaal te reviewen, minimaal.

Bekijk ook de Compute Optimizer API-referentie om aanbevelingen in je eigen dashboards te integreren. Voor Terraform-gebruikers is er een enrollment resource die de service via IaC activeert.

Veelgestelde vragen

Is AWS Compute Optimizer gratis?

Ja, de standaard Compute Optimizer-service is volledig gratis voor EC2, EBS, Lambda, Auto Scaling Groups en ECS op Fargate. Alleen de optionele Enhanced Infrastructure Metrics kost ongeveer $0,24 per instance per maand voor de uitgebreidere 3-maands analysewindow met 1-minuut granulariteit.

Hoe lang duurt het voordat Compute Optimizer aanbevelingen genereert?

De eerste aanbevelingen verschijnen doorgaans binnen 24 uur na activering, maar individuele resources hebben minimaal 30 uur aan CloudWatch-metrics nodig om in aanmerking te komen. Nieuw uitgerolde instances of Lambda-functies verschijnen dus pas na een dag activiteit.

Wat is het verschil tussen AWS Compute Optimizer en AWS Trusted Advisor?

Trusted Advisor geeft generieke waarschuwingen over ongebruikte resources en idle instances op basis van simpele regels. Compute Optimizer gebruikt machine learning om SKU-specifieke right-sizing aanbevelingen te doen (bijvoorbeeld m5.2xlarge naar m6i.large) met geschatte besparingen en risico-scores. Beide vullen elkaar aan.

Werkt Compute Optimizer met Spot Instances en Reserved Instances?

Compute Optimizer analyseert het gebruik van alle EC2-instances ongeacht hun aankoopmodel (On-Demand, Reserved, Spot of Savings Plans). Aanbevelingen tonen echter altijd de on-demand prijs voor de nieuwe configuratie. Je moet zelf verrekenen dat kortingen ook op de nieuwe SKU van toepassing zijn.

Kan ik Compute Optimizer inzetten voor multi-account AWS Organizations setups?

Ja, activeer Compute Optimizer op je management account met de --include-member-accounts vlag om aanbevelingen voor alle linked accounts te krijgen. Dit is de standaard voor grotere organisaties omdat je zo één centraal overzicht hebt van right-sizing kansen door de hele organisatie heen.

Hoe accurate zijn de geschatte besparingen van Compute Optimizer?

De geschatte besparingen zijn gebaseerd op on-demand pricing en typisch binnen 5-10% van de werkelijkheid, mits je Savings Plans- of Reserved Instances-korting apart verrekent. Voor stabiele workloads komen de cijfers goed uit; voor sterk variabele workloads is de spreiding groter en moet je zelf een marge inbouwen.