AWS Compute Optimizer: Průvodce 2026

Aktualizováno: 22. srpna 2026

AWS Compute Optimizer je bezplatná ML-based služba, která analyzuje CloudWatch metriky za posledních 14 dní a doporučuje menší instance, jiné rodiny nebo úpravy paměti (typicky s úsporou 25–45 % bez dopadu na výkon). Upřímně, považuju ji za výchozí bod každého rightsizing sprintu: než uzavřu Savings Plan, chci přesně vědět, na kterou skutečnou velikost instance closovat. Tenhle průvodce ukazuje, jak Compute Optimizer aktivovat napříč AWS Organizations, jak číst doporučení pro EC2, Lambda i EBS a jak celý proces zautomatizovat.

AWS Compute Optimizer je zdarma a pokrývá EC2, Auto Scaling Groups, EBS volumes, Lambda, ECS on Fargate a RDS (od února 2026 i Aurora Serverless v2).
Bez Enhanced Infrastructure Metrics vidí pouze CPU a network, takže pro paměťová doporučení musíte instalovat CloudWatch agenta a povolit rozšířené metriky (0,36 USD/měsíc/instance).
Migrace z gp2 na gp3 EBS je nejrychlejší win: úspora ~20 % ceny za GB bez rebootu a bez downtime, doporučení generuje Compute Optimizer automaticky.
Lambda Power Tuning kombinuje Compute Optimizer s AWS Step Functions state machine. Pro CPU-bound funkce najdete sweet spot obvykle mezi 1769 MB (1 vCPU threshold) a 3008 MB.
Azure Advisor a GCP Recommender pokrývají podobný scope, ale accuracy a granularita se liší. Porovnání najdete v tabulce níže.
Automatizovaná aplikace doporučení přes AWS Systems Manager Automation nebo Terraform je bezpečnější než manuální click-ops, ale vyžaduje canary strategii.

Co je AWS Compute Optimizer a jak se liší od Trusted Advisor

Compute Optimizer je specializovaná ML služba zaměřená na rightsizing výpočetních zdrojů. Analyzuje CloudWatch metriky (CPU, network, disk, memory pokud jsou k dispozici) za posledních 14 dní, nebo 32 dní s aktivovanou možností lookBackPeriodPreference: THIRTY_TWO_DAYS, a pomocí sady modelů natrénovaných na milionech reálných workloadů navrhuje konkrétní SKU. Není to obecná bezpečnostní/best-practice kontrola jako Trusted Advisor. Compute Optimizer řeší jeden problém: „jakou instanci vlastně potřebuju“.

V mém deníčku engagementů posledních měsíců vypadá typický výsledek takhle: z 340 EC2 instancí ve třech regionech dostane zákazník 187 doporučení NOT_OPTIMIZED, z toho zhruba 60 % nedostatečně využitých (over-provisioned) a asi 15 % s memory pressure. Zbylých 153 instancí je klasifikováno jako OPTIMIZED. Realizovaná úspora po aplikaci je obvykle mezi 25 a 45 % on-demand ceny, přičemž headroom pro Savings Plan pak počítám z těch nových velikostí. Jinak byste si zbytečně zamkli závazek na nadměrné instance.

Klíčový rozdíl vůči AWS Trusted Advisor: Trusted Advisor je široký best-practices checklist (bezpečnost, service limits, HA), zatímco Compute Optimizer používá strojové učení k predikci workload profile a doporučí konkrétní alternativní SKU včetně odhadu risk score. Trusted Advisor u EC2 řekne „instance má nízké CPU“, Compute Optimizer řekne „migrujte z m5.2xlarge na m6i.xlarge, ušetříte 62,40 USD/měsíc, risk MEDIUM“.

Jak aktivovat Compute Optimizer napříč AWS Organizations

Compute Optimizer je zdarma a aktivuje se dvěma příkazy. V multi-account setupu chcete aktivaci provést z management účtu Organizations a nastavit trusted access, aby jeden delegovaný admin viděl doporučení pro všechny linked accounts. Já to dělám z dedikovaného „FinOps“ účtu, který také hostuje Cost Explorer a CUR (Cost and Usage Report).

# 1) Aktivace v management účtu Organizations
aws organizations enable-aws-service-access \
    --service-principal compute-optimizer.amazonaws.com

# 2) Delegace na FinOps účet (nahraďte skutečným Account ID)
aws compute-optimizer put-recommendation-preferences \
    --resource-type Ec2Instance \
    --scope name=Organization,value=o-xxxxxxxxxx \
    --enhanced-infrastructure-metrics Active \
    --look-back-period ThirtyTwoDays

# 3) Opt-in všech účtů v Organizations najednou
aws compute-optimizer update-enrollment-status \
    --status Active \
    --include-member-accounts

# 4) Ověření stavu
aws compute-optimizer get-enrollment-statuses-for-organization \
    --query 'accountEnrollmentStatuses[?status!=`Active`]'

První doporučení se objeví až po 30 hodinách běhu instance a minimálně 24 hodinách CloudWatch metrik. To je časté překvapení: po aktivaci nevidíte nic a myslíte si, že něco nefunguje. Nefunguje čas.

EC2 rightsizing: doporučení a Enhanced Infrastructure Metrics

U EC2 vrací Compute Optimizer až tři alternativní SKU seřazené podle rank. Každé má odhadovanou úsporu, projected utilization pro nový SKU a performanceRisk score (1 = velmi nízké, 5 = vysoké). Pro produkci beru pouze doporučení s performanceRisk ≤ 2. Risk 3+ posílám na dev/test.

Bez CloudWatch agenta vidí Compute Optimizer pouze CPU, síť a disk I/O, což vede k systematickému under-provisioningu paměti. Java aplikace, PostgreSQL nebo Redis vypadají „nevytížené“, dokud nedostanou OOM killer. Přesně tohohle bugu jsem si užil při jednom migračním sprintu v roce 2024, kdy nám doporučení srazilo Kafka broker na polovinu paměti a Zookeeper začal odpadávat během špičky. Enhanced Infrastructure Metrics vyžadují instalaci CloudWatch agenta a export mem_used_percent metriky. Konfigurační snippet:

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

Praktický příklad z minulého kvartálu: klient měl 42× c5.4xlarge ($0,68/hod, 16 vCPU, 32 GB) pro API cluster. Compute Optimizer po týdnu měření s memory metrics doporučil migraci na c6i.2xlarge ($0,34/hod, 8 vCPU, 16 GB), projected CPU 68 %, memory 71 %. Roční úspora: ~125 000 USD. Risk score 2 (přijatelné pro non-critical API). Migrace proběhla přes ASG rolling update, bez jediného zákaznického ticketu.

Pokud řešíte Kubernetes clustery, doporučuju přečíst také náš průvodce optimalizace nákladů na Kubernetes 2026. Compute Optimizer sice umí right-sizovat nody, ale skutečné úspory přijdou až s pod-level rightsizingem přes VPA a Karpenter.

Optimalizace Lambda funkcí: paměť, cold start, Power Tuning

U Lambda je konfigurovatelný pouze paměťový parametr. vCPU se škáluje lineárně (1 vCPU při 1769 MB, 2 vCPU při 3538 MB, až 6 vCPU při 10240 MB). Compute Optimizer analyzuje Duration, MaxMemoryUsed a Init Duration a vrací dvě kategorie doporučení:

MemorySizeGeneration, tedy zvýšit nebo snížit paměť. Sníženou paměť doporučuje jen pro funkce s peak utilization pod 20 %.
ComputeOptimization: v edge cases doporučí zvýšit paměť, i když je nevytížená, protože vyšší vCPU zkrátí duration natolik, že celkově zaplatíte méně (paměť × doba běhu × invocations).

Compute Optimizer sám ale často nenajde optimální sweet spot. Pro CPU-bound funkce (image processing, video transcoding, ML inference) používám AWS Lambda Power Tuning, což je Step Functions state machine, která spustí funkci s 6–10 různými memory profily a vyhodnotí náklady/výkon. Instalace přes SAR:

aws serverlessrepo create-cloud-formation-change-set \
    --application-id arn:aws:serverlessrepo:us-east-1:451282441545:applications/aws-lambda-power-tuning \
    --stack-name lambda-power-tuning \
    --capabilities CAPABILITY_IAM

# Spuštění pro konkrétní funkci
aws stepfunctions start-execution \
    --state-machine-arn arn:aws:states:eu-west-1:ACCOUNT_ID:stateMachine:powerTuningStateMachine \
    --input '{
      "lambdaARN": "arn:aws:lambda:eu-west-1:ACCOUNT_ID:function:my-function",
      "powerValues": [512, 1024, 1769, 2048, 3008, 4096, 5120],
      "num": 50,
      "payload": {"key": "value"},
      "strategy": "balanced"
    }'

V mé praxi Power Tuning odhalí, že defaultních 128 MB stojí 3× víc než 1024 MB u JSON transformací nad 100 KB payloady, protože doba běhu klesne z 4200 ms na 620 ms. Kontraintuitivní, ale sedne to.

EBS volumes: migrace gp2 → gp3 bez downtime

Nejpodceňovanější doporučení Compute Optimizeru? Migrace gp2 → gp3. gp3 stojí 0,08 USD/GB/měsíc vs. gp2 0,10 USD/GB/měsíc (asi 20 % úspora) a defaultně poskytuje 3000 IOPS + 125 MB/s, což pokrývá přes 90 % workloadů. Compute Optimizer označí každý gp2 volume jako NOT_OPTIMIZED, pokud jeho utilizace IOPS nepřesahuje 3000.

Migrace je online, bez rebootu, bez detach/attach. AWS API modify-volume spustí background copy a přepne typ za běhu:

# Získání všech gp2 volumes v regionu
aws ec2 describe-volumes \
    --filters "Name=volume-type,Values=gp2" \
    --query 'Volumes[].VolumeId' \
    --output text | tr '\t' '\n' > gp2-volumes.txt

# Bulk migrace na gp3 (paralelně, s throttlingem)
while read -r vol; do
    aws ec2 modify-volume \
        --volume-id "$vol" \
        --volume-type gp3 \
        --iops 3000 \
        --throughput 125
    sleep 1  # respekt k API rate limits
done < gp2-volumes.txt

# Sledování postupu (state = modifying → completed)
aws ec2 describe-volumes-modifications \
    --filters "Name=modification-state,Values=modifying"

Pro plnohodnotný úklid stálých úspor doporučuju spárovat rightsizing s auditem nepřipojených volumes a snapshotů. Přehled najdete v článku zombie cloudové zdroje: jak najít a eliminovat nečinné EBS, snapshoty a NAT Gateway.

Auto Scaling Groups, ECS Fargate a RDS doporučení

Compute Optimizer pokrývá i Auto Scaling Groups (od 2020), ECS on Fargate (od 2022) a RDS instance (obecně dostupné od listopadu 2023, Aurora Serverless v2 přidána v únoru 2026). Přístupy se ale liší.

Auto Scaling Groups

Doporučení zohledňuje mixed instances policy a spot allocation strategy. Vrátí seznam alternativních instance typů seřazených podle cena/výkon. Zajímavý edge case: pokud používáte capacity-optimized-prioritized, doporučení jsou konzervativnější, protože ASG už optimalizuje mix.

ECS on Fargate

Fargate má diskrétní kombinace CPU/memory (0,25 vCPU + 512 MB, 0,25 + 1024 MB, ...). Compute Optimizer doporučuje přechod na nejbližší nižší kombinaci pouze pokud p99 CPU zůstane pod 70 %. U kontejnerů si vždy ověřuju, že se do doporučené kombinace vejde request+limit každého sidecaru (Datadog agent, Fluent Bit, Envoy).

RDS instance

Nejdůležitější doporučení jsou přechod z db.m5 na db.m6g (Graviton, asi 15 % levnější) a snížení velikosti u Multi-AZ, kde read replica často má úplně jiný profil než primary. Compute Optimizer neřeší storage, na to potřebujete samostatný audit gp2 → gp3.

Compute Optimizer vs Azure Advisor vs GCP Recommender

V multi-cloud FinOps praxi řeším rightsizing napříč všemi třemi providery. Každý má vlastní nástroj a chování se liší dost na to, aby bylo dobré rozdíly znát. Detailnější kontext k multi-cloud strategii jsem popsal v průvodci FinOps v multi-cloud prostředí 2026.

Vlastnost	AWS Compute Optimizer	Azure Advisor	GCP Recommender
Cena	Zdarma (bez EIM); EIM 0,36 USD/inst/měsíc	Zdarma	Zdarma
Lookback období	14 nebo 32 dní	7 nebo 30/60/90 dní (Cost)	8, 30, nebo 90 dní
Pokrytí	EC2, ASG, EBS, Lambda, ECS Fargate, RDS, Aurora Serverless v2	VMs, VMSS, Managed Disks, SQL DB, App Service	GCE, GKE nody, Cloud SQL, Persistent Disks
Paměťové metriky	Vyžaduje CloudWatch agenta	Automaticky přes Azure Monitor Agent	Automaticky přes Ops Agent
ML model	Ranking + risk score (1–5)	Právě jedno doporučení + confidence	Predicted savings + priority
API pro automatizaci	Vyspělé CLI, EventBridge integrace	Advisor REST API + Azure Policy	Recommender API v1 (gRPC)
Doporučení pro spot/preemptible	Ne	Ne přímo (Reservation Recs samostatně)	Ano, Idle VM + preemptible mix

Můj shrnutý dojem: Compute Optimizer má nejlepší accuracy díky risk score a nejlepší CLI, ale nejhorší out-of-the-box memory pokrytí. Azure Advisor je nejjednodušší (memory metriky zadarmo), ale doporučuje jen jednu alternativu. GCP Recommender má nejvíc granular rec typů (přes 40 typů recommenderů), ale UI je nejméně intuitivní.

Automatizace: aplikace doporučení přes Terraform a SSM

Manuální click-ops na 200 doporučeních je recept na chyby. Pro production fleety používám kombinaci exportu doporučení, GitOps review a canary rollout přes Systems Manager. Základní pipeline:

# 1) Export doporučení do S3 (CSV nebo JSON)
aws compute-optimizer export-ec2-instance-recommendations \
    --s3-destination-config bucketName=finops-recs,keyPrefix=weekly/ \
    --file-format Csv \
    --include-member-accounts

# 2) Filtrování na low-risk doporučení (Python)
python3 <<'EOF'
import csv, boto3

recs = []
with open('recs.csv') as f:
    for row in csv.DictReader(f):
        if (row['finding'] == 'NotOptimized'
            and float(row['currentPerformanceRisk']) <= 2
            and row['recommendationOptions_1_performanceRisk'] == '1'):
            recs.append({
                'instance': row['instanceArn'],
                'current': row['currentInstanceType'],
                'target': row['recommendationOptions_1_instanceType'],
                'saving_pct': row['recommendationOptions_1_estimatedMonthlySavings_value'],
            })

# Zapsat jako Terraform tfvars pro následný apply
with open('rightsizing.auto.tfvars.json', 'w') as f:
    import json; json.dump({'instance_targets': recs}, f, indent=2)
EOF

# 3) Aplikace přes SSM Automation (canary: 10 % fleetu)
aws ssm start-automation-execution \
    --document-name AWS-ResizeInstance \
    --parameters "InstanceId=i-0abc123,InstanceType=m6i.xlarge" \
    --max-concurrency "10%" \
    --max-errors "1"

Před resize vždycky spouštím stop instance přes Systems Manager s pre/post hooks pro odpojení target groups. Rolling resize u ASG je čistší cesta: nový launch template s novým instance typem a instance_refresh s minimálním healthy percentage 90 %.

Časté chyby při implementaci doporučení

Za posledních dvanáct měsíců rightsizing engagementů jsem viděl několik opakujících se failure módů, které stojí za to jmenovat:

Ignorování burst kapacity u T instancí. Compute Optimizer neuvažuje CPU credits u t3/t4g rodiny. Pokud instance běží na baseline 20 % s krátkými burst na 90 %, doporučení „downsize na t4g.micro“ vyčerpá credit balance během hodiny a workload začne throttlovat.
Aplikace doporučení bez SP recalculation. Když downsizeujete instance kryté Compute Savings Plan, hourly commitment zůstává stejný, a najednou máte overcommitment. Řešte v tomhle pořadí: rightsizing, dva týdny stabilizace, nákup nového SP na cílovou velikost. Detailní strategii popisuju v článku Reserved Instances vs Savings Plans vs CUD.
Rightsizing bez memory metrics. Bez CloudWatch agenta uvidíte jen CPU. Java aplikace s -Xmx8g na 16 GB instanci vypadá „nadměrně“ a Compute Optimizer doporučí přechod na 8 GB. Po migraci: OOM killer.
Ignorování licenční model dopadů. Přechod z m5.4xlarge na m6i.2xlarge snižuje vCPU z 16 na 8. Pokud máte SQL Server nebo Oracle licencované per-core, změní se i licenční náklady (může být úspora, ale musíte to spočítat separátně).
Aplikace na stateful workloads bez testu. Redis Cluster, PostgreSQL primary nebo Kafka broker vyžadují failover test před resize. Compute Optimizer nezná replication lag ani quorum requirements.

Často kladené otázky

Je AWS Compute Optimizer zdarma?

Ano, základní služba je bezplatná pro EC2, ASG, EBS, Lambda, ECS Fargate i RDS. Zpoplatněné jsou pouze Enhanced Infrastructure Metrics (paměťová a GPU doporučení) za 0,36 USD za instanci a měsíc. U fleetu 100 instancí to je 36 USD/měsíc, vratná investice obvykle první den.

Jak přesná jsou doporučení Compute Optimizeru?

V mé praxi 85–90 % low-risk doporučení (risk score 1–2) proběhne bez incidentu. Riziko roste s risk score 3+ (spíš 60–70 % úspěšnost) a u stateful workloadů bez rozšířených metrik. Doporučení revalidujte po 14 dnech běhu na nové velikosti, Compute Optimizer automaticky přepočítá.

Jaký je rozdíl mezi Trusted Advisorem a Compute Optimizerem?

Trusted Advisor je široká best-practices kontrola napříč bezpečností, HA, service limits a základními cost checky. Compute Optimizer je specializovaný ML nástroj čistě pro rightsizing výpočetních zdrojů s konkrétními SKU doporučeními. Používejte oba: Trusted Advisor pro governance, Compute Optimizer pro optimalizaci.

Podporuje Compute Optimizer také Lambda?

Ano, Lambda podpora je aktivní od prosince 2020. Analyzuje Duration, MaxMemoryUsed a doporučuje nové paměťové nastavení. Pro nejlepší výsledky u CPU-bound funkcí kombinujte s AWS Lambda Power Tuning, která projede 6–10 memory profilů v paralelních invocations a vypočte cost-per-invocation křivku.

Jak dlouho trvá, než se objeví první doporučení?

Compute Optimizer potřebuje minimálně 30 hodin běhu instance a 24 hodin CloudWatch metrik. V praxi počítám s 3 až 5 dny na stabilní doporučení, protože ML model potřebuje vidět denní/týdenní cyklus workloadu. Doporučení pro Lambda přicházejí rychleji, obvykle po asi 50 invocations.

Můžu Compute Optimizer používat pro Kubernetes nody?

Ano, EKS worker nody spadají pod EC2 a Auto Scaling Groups doporučení. Node-level rightsizing je ale jen půlka rovnice: plné úspory přijdou až s pod-level rightsizingem přes Vertical Pod Autoscaler a Karpenter. Compute Optimizer sám neanalyzuje pod resource requests ani container-level metriky.