AWS Compute Optimizer: Sprievodca rightsizingom EC2 a úsporami 30–50 % v roku 2026
Bezplatný AWS Compute Optimizer analyzuje CloudWatch metriky a odporúča optimálnu veľkosť EC2, EBS, Lambda a RDS. Zistite, ako ušetriť 20–50 % s CLI a Terraform príkladmi z reálnych auditov 2026.
AWS Compute Optimizer je bezplatná služba, ktorá pomocou strojového učenia analyzuje CloudWatch metriky za posledných 14 dní a odporúča optimálnu veľkosť EC2 inštancií, EBS zväzkov, Lambda funkcií, ECS Fargate úloh, RDS databáz a Auto Scaling skupín. Ak recommendation preferences nastavíte správne a zapnete Enhanced Infrastructure Metrics (memory cez CloudWatch Agent), typický účet zníži EC2 spend o 20–35 % a EBS o 25–40 %. V tomto článku vás prevediem každou metrikou, presnými CLI krokmi, Terraform snippetmi a bežnými chybami, na ktoré som narazil pri desiatkach zákazníckych auditov v roku 2026.
Compute Optimizer je zadarmo pre základné odporúčania. Enhanced Infrastructure Metrics stoja 0,0003360215 USD/hod. za sledovaný resource (~0,25 USD/mesiac/inštancia).
Bez nainštalovaného CloudWatch Agenta služba nevidí memory utilization, a odporúčania budú konzervatívne alebo úplne chýbať pre memory-bound workloady.
EBS gp2 → gp3 migrácia je "free lunch": rovnaký alebo lepší výkon za približne 20 % nižšiu cenu, žiadny downtime pre root ani data volumes.
Odporúčania založené na 14-dňovom okne môžu podceniť sezónne špičky. Pre kampaňové alebo mesačne uzavieracie workloady vždy overte 90-dňový CloudWatch graf pred aplikovaním.
Kombinácia Compute Optimizer + Compute Savings Plans + Graviton3/4 target v roku 2026 typicky ušetrí 45–65 % oproti on-demand x86 baseline.
Čo je AWS Compute Optimizer a ako funguje?
Compute Optimizer je AWS-native služba spustená v decembri 2019. Klasifikuje resource na štyri stavy: Under-provisioned, Over-provisioned, Optimized alebo Not optimized. Používa proprietárne ML modely trénované na anonymizovaných CloudWatch metrikách naprieč miliónmi AWS účtov. Vstupom sú CPU utilization, network I/O, disk I/O, počet vCPU a (voliteľne) memory utilization plus ephemeral storage cez CloudWatch Agent. Analytický horizont je štandardne 14 dní. Ak zapnete Look-back period 93 dní (pridané pre paying účty v Q1 2025), zaplatíte extra, ale získate presnejšie odporúčania pre workloady s mesačnými cyklami.
V praxi vidím, že developerské tímy Compute Optimizer často podcenia, pretože ho porovnávajú s Trusted Advisor Cost Optimization checkom. Trusted Advisor pozerá iba na priemerný CPU pod 10 % za 14 dní, čo je heuristický prah. Compute Optimizer vypočíta konkrétny cieľový inštance type z ~750 dostupných SKUs vrátane Graviton a najnovších M8g/C8g/R8g rodín uvedených v Q2 2026. Presnosť je vyššia hlavne pre workloady, kde CPU nie je jediný bottleneck. Detaily o algoritme a metrikách nájdete v oficiálnej dokumentácii AWS Compute Optimizer.
Aké resource typy Compute Optimizer podporuje v roku 2026
Zoznam v H1 2026 obsahuje: EC2 inštancie (vrátane Windows, RHEL, SUSE), Auto Scaling groups (single- aj mixed-instance), EBS zväzky (gp2/gp3/io1/io2/st1/sc1), Lambda funkcie s 50+ invokáciami za 14 dní, ECS services on Fargate (Linux X86 aj ARM), commercial RDS engines (MySQL, PostgreSQL, MariaDB, Aurora MySQL/PostgreSQL) a od februára 2026 aj DynamoDB tabuľky v provisioned kapacitnom režime. Pre RDS je špecificky pridaná analýza inštancie plus storage typu (gp2 → gp3, provisioned IOPS scaling), čo bolo predtým manuálna práca. Docela solídny záber, keď si to zrátate.
Ako povoliť Compute Optimizer v Organizations účte
Ak ste jeden účet, aktivácia je jedno API volanie. Ak spravujete AWS Organizations s desiatkami accountov (bežný setup u mojich zákazníkov), musíte to povoliť z management alebo delegated administrator účtu, aby ste videli agregovanú view. Delegovanie odporúčam. Nechcete pracovať v management účte, ktorý má root prístup k billingu.
# 1. V management účte deleguj administrator na dedikovaný audit/cost account
aws organizations register-delegated-administrator \
--account-id 111122223333 \
--service-principal compute-optimizer.amazonaws.com
# 2. V delegated admin účte zapni Compute Optimizer pre celú Organization
aws compute-optimizer update-enrollment-status \
--status Active \
--include-member-accounts
# 3. Overenie stavu naprieč všetkými účtami
aws compute-optimizer get-enrollment-statuses-for-organization \
--query 'accountEnrollmentStatuses[?status!=`Active`].[accountId,status,statusReason]' \
--output table
IAM permissions pre čítanie odporúčaní
Pre platformových inžinierov, ktorí chcú odporúčania čítať cez CLI alebo integrovať do CI/CD, stačí read-only policy. Toto je minimálny set, ktorý používam v produkcii:
Compute Optimizer vracia pre každú EC2 inštanciu až tri alternatívne inštance types zoradené podľa performance risk (0.0 = žiadne riziko, 5.0 = vysoké). Každá alternatíva má odhad ročnej úspory a hodnotu Migration effort: Very Low / Low / Medium / High. Migration effort High vidím typicky pri prechode z x86 na ARM64 (Graviton), pretože code musí byť rekompilovaný. Pri Java, Go, Node.js a Python workloadoch je migračná bariéra reálne Low až Medium. O tom viac v našom playbooku pre migráciu na AWS Graviton.
Príklad reálneho výstupu z konzoly pre m5.4xlarge inštanciu bežiacu Kafka broker (jeden z mojich klientov, koncom júna):
Kľúčový insight: option 2 má nižšiu migration effort, ale performance risk 3.0, pretože ide na polovičnú memory kapacitu. Ak Kafka broker retention držíte v RAM, spôsobíte page cache miss a latency spike. Vždy validujte navrhované SKU proti reálnemu memory profile, pretože 14-dňové okno môže zmeškať mesačný špičkový offload. Presne toto som raz podcenil pri migrácii a musel som robiť rollback o 2:30 ráno. Odvtedy dvakrát meriam.
Performance risk skóre v praxi
Interne používam pravidlo: risk ≤ 1.0 = aplikuj bez váhania, 1.1–2.0 = otestuj v staging, > 2.0 = nedotýkaj sa bez load testu. Toto pravidlo mi za posledné dva roky nezavarilo produkčný incident naprieč šiestimi väčšími migráciami. AWS v oficiálnom blogu potvrdil, že risk ≥ 3.0 znamená viac ako 20 % pravdepodobnosť saturation aspoň jednej resource dimenzie.
Enhanced Infrastructure Metrics a CloudWatch Agent
Bez memory metriky Compute Optimizer nemôže spoľahlivo odporučiť memory-bound rightsizing. A bude preferovať konzervatívne odporúčania. AWS ponúka dve úrovne:
Basic: používa iba default CloudWatch metriky (CPU, network, disk I/O). Zadarmo.
Enhanced Infrastructure Metrics: 3 mesiace look-back a memory utilization z CloudWatch Agenta. 0,0003360215 USD/inštancia/hod. (~0,25 USD mesačne za m5.large, ~5 USD ročne).
Cena je pri seriózne veľkých parkoch triviálna. Enhanced zapnete jedným API volaním per resource type per scope:
Toto je najrýchlejšia úspora, akú Compute Optimizer odhalí. gp3 stojí ~0,08 USD/GB-mesiac oproti 0,10 USD pre gp2 (us-east-1), čiže okamžitých 20 %. Navyše gp3 dáva 3 000 baseline IOPS a 125 MB/s throughput bez ohľadu na veľkosť, kým gp2 škáluje IOPS podľa GB (3 IOPS/GB, max 16 000). Pre 100 GB volume dostávate na gp3 rovnaké alebo lepšie IOPS za nižšiu cenu.
Modification je online. Root volume môžete zmeniť za bežiacej inštancie:
# Zoznam všetkých gp2 volumes s odporúčaním na migráciu
aws compute-optimizer get-ebs-volume-recommendations \
--query 'volumeRecommendations[?volumeRecommendationOptions[0].configuration.volumeType==`gp3`].[volumeArn,currentConfiguration.volumeType,volumeRecommendationOptions[0].estimatedMonthlySavings.value]' \
--output table
# Batch migrácia: modify všetkých gp2 volumes taggovaných Environment=prod
aws ec2 describe-volumes \
--filters "Name=volume-type,Values=gp2" "Name=tag:Environment,Values=prod" \
--query 'Volumes[].VolumeId' --output text | \
xargs -n1 -P4 -I{} aws ec2 modify-volume --volume-id {} --volume-type gp3
Lambda, ECS Fargate a RDS odporúčania
Compute Optimizer pre Lambda potrebuje aspoň 50 invokácií a dáta z minimálne 14 dní. Kľúčový výstup je odporúčaná MemorySize. Zaujímavosť: Lambda účtuje za GB-sekundy, takže znížením memory zo 1024 MB na 512 MB nedvojnásobne škrtnete cenu, pretože CPU alokácia klesne úmerne a duration môže vzrásť. Compute Optimizer tento tradeoff vypočíta a odporučí cost-optimal alebo performance-optimal preferenciu. Pre podrobné stratégie k serverlessu odporúčam náš sprievodca serverless optimalizáciou pre Lambda, Azure Functions a Cloud Run.
Pre ECS Fargate odporúčania fungujú na service level (nie task level), s look-back 14 dní. Analyzujú CPU a memory za celý service a odporúčajú novú task definition. Praktická rada: ak máte ECS service s auto-scaling nastaveným cez target tracking na CPU 70 %, Compute Optimizer často odporučí menšiu task size, pretože scaling policy udrží CPU okolo target hodnoty, takže priemerný CPU je vždy nižší ako peak. Znie to očividne, ale prekvapivo veľa tímov to prehliadne.
RDS odporúčania — čo je nové v 2026
Compute Optimizer podporuje RDS od Q4 2024 a od Q1 2026 pridal aj analýzu storage autoscaling a odporúčania na Multi-AZ Cluster (2 readable standby) pre Aurora. Novinka H1 2026: Compute Optimizer už identifikuje idle RDS databázy (žiadne query > 100 rows/day za posledných 30 dní), čo je bežná diera v rozpočte pri dev/staging environmentoch. Reálne odporúčanie z môjho auditu minulý mesiac:
Compute Optimizer vs Cost Explorer vs Trusted Advisor
Kľúčová otázka, ktorú počúvam každý týždeň: "Nemáme už Trusted Advisor a Cost Explorer? Načo Compute Optimizer?" Krátka odpoveď: každý nástroj rieši iný layer FinOps stacku. Nasledujúca tabuľka to zhŕňa.
Kritérium
Compute Optimizer
Cost Explorer Rightsizing
Trusted Advisor
Cena
Zadarmo (Enhanced $0.25/mo/inst.)
Zadarmo
Business Support+
ML model
Áno (~750 SKU)
Áno (obmedzený set)
Nie (prahové hodnoty)
Memory utilization
Áno (s CW Agent)
Nie
Nie
Odporúča Graviton
Áno
Nie priamo
Nie
EBS gp2 → gp3
Áno
Nie
Čiastočne
Look-back okno
14 alebo 93 dní
14 dní
14 dní
Lambda / ECS / RDS
Áno
Nie
Nie
Automatická akcia
Nie (len advisory)
Nie
Nie
V praxi ich používam v tandeme: Compute Optimizer na taktické rightsizing rozhodnutia, Cost Explorer na dlhodobé trend analýzy a Trusted Advisor ako alerting layer pre bežných engineerov, ktorí nechcú lozit do Compute Optimizer konzoly. Ak plánujete pokryť committed usage layer, prečítajte si aj náš detailný sprievodca Savings Plans, Reserved Instances a CUD, kde vysvetľujem, ako správne kombinovať rightsizing s commitment discounts.
Automatizácia right-sizingu s CLI a Terraform
Compute Optimizer nemá autonomous action funkciu. Nespraví za vás ModifyInstanceAttribute. To je zámerné, pretože automatizovaná zmena inštance type by mohla spôsobiť incident. Väčšina zrelých FinOps tímov si preto stavia vlastný pipeline. Toto je pattern, ktorý používam u zákazníkov s ~5000 EC2 inštanciami:
# Weekly EventBridge Scheduler cron spúšťa Lambdu, ktorá:
# 1. Zavolá get-ec2-instance-recommendations pre celú Organization
# 2. Filtruje na performance_risk <= 1.0 A monthly_savings >= 50 USD
# 3. Vytvorí JIRA ticket pre owner tímu (z tagu CostCenter)
# 4. Pushne odporúčanie do S3 ako parquet pre Athena reporting
import boto3, json
from datetime import datetime
co = boto3.client('compute-optimizer')
def lambda_handler(event, context):
paginator = co.get_paginator('get_ec2_instance_recommendations')
actionable = []
for page in paginator.paginate(accountIds=[event['account_id']]):
for rec in page['instanceRecommendations']:
if not rec.get('recommendationOptions'):
continue
best = rec['recommendationOptions'][0]
risk = best.get('performanceRisk', 5.0)
savings = best.get('estimatedMonthlySavings', {}).get('value', 0)
if risk <= 1.0 and savings >= 50:
actionable.append({
'instance_arn': rec['instanceArn'],
'current_type': rec['currentInstanceType'],
'recommended_type': best['instanceType'],
'monthly_savings_usd': savings,
'performance_risk': risk,
'cost_center': next(
(t['value'] for t in rec.get('tags', [])
if t['key'] == 'CostCenter'), 'unknown')
})
return {'actionable_count': len(actionable), 'items': actionable}
Pre Terraform-managed inštancie mám pravidlo: nikdy nemeňte inštance type mimo Terraform. Automatizácia posiela pull request do infra repo, ktorý zmení instance_type premennú. Reviewer schvaľuje a Atlantis alebo Terraform Cloud aplikuje. Toto zachováva drift-free stav, ktorý FinOps a compliance auditi vyžadujú. Skúsenosť ma naučila, že jeden manuálny modify-instance-attribute cez konzolu vie potichu rozbiť ďalších päť pipeline runov.
Bežné chyby, ktorým sa vyhnúť
Za posledné dva roky som auditoval približne 80 AWS účtov a stále vidím tie isté štyri chyby, ktoré berú tímom desiatky tisíc dolárov mesačne. Pozrite si aj náš sprievodca Kubernetes rightsizingu, ktorý sa venuje EKS-špecifickému uhlu.
Nezapnuté Enhanced Infrastructure Metrics. Bez memory dát vidíte iba CPU-optimized odporúčania. Pre PostgreSQL, Redis, Kafka a JVM workloady je to zásadné podcenenie skutočnej resource potreby. Cena 25 centov za inštanciu mesačne je zanedbateľná.
Ignorovanie Graviton odporúčaní. Compute Optimizer často odporúča Graviton3/4, ale tímy ich odmietajú kvôli údajnému "risku". V roku 2026 je väčšina managed runtime (Amazon Corretto, Amazon Linux 2023, ECR public images) natívne ARM64 kompatibilná. Testujte, nie odmietajte apriori.
Aplikácia odporúčania bez preverenia sezónnosti. 14-dňové okno nezachytí koncoročné špičky pre e-commerce, mesačné batch joby ani daňové obdobia. Vždy pozrite 90-dňový CloudWatch graf pred aplikáciou. Alebo priplaťte za 93-dňový look-back.
Chýbajúca cross-account view. Ak Compute Optimizer nezapnete cez delegated administrator, každý účet vidí len svoje odporúčania. Central FinOps team nemá agregovaný pohľad a stráca úspory z volume rozhodovania (napr. Compute Savings Plan cez viac accountov).
Kedy Compute Optimizer nepomôže
Compute Optimizer neanalyzuje ElastiCache, OpenSearch, EMR ani MSK. Neurčí, či máte vôbec spúšťať konkrétny workload. Nekritizuje architektonické rozhodnutia (napr. "premeňte to na Lambda"). Nepočíta úspory z prechodu na spot inštancie. Pre AI/GPU workloady, kde je väčšina cost driveru GPU allocation, používajte GPU-specific tooling ako AWS HyperPod recommendations alebo third-party služby ako Kubecost pre GPU nodes.
Často kladené otázky
Je AWS Compute Optimizer zadarmo?
Základné odporúčania (14-dňové okno, bez memory metrík) sú zadarmo. Enhanced Infrastructure Metrics, ktoré pridávajú 93-dňový look-back a memory analýzu, stoja 0,0003360215 USD za resource-hodinu, čo je približne 0,25 USD mesačne za jednu inštanciu. Pre 100-inštancový parc to je 25 USD mesačne oproti typickým úsporám v tisícoch USD.
Ako dlho trvá, kým sa objavia prvé odporúčania?
Prvé odporúčania sa objavia po približne 12 hodinách od aktivácie. Pre štatisticky spoľahlivé odporúčania čakajte plných 14 dní, aby model získal dostatočný metrický vzorník. Ak zapnete 93-dňový look-back a resource je nový, počiatočné odporúčania môžu byť pomerne konzervatívne.
Aký je rozdiel medzi Compute Optimizer a Trusted Advisor?
Trusted Advisor používa jednoduché prahové hodnoty (napr. priemerný CPU pod 10 % za 14 dní) na identifikáciu underused resources. Compute Optimizer využíva ML modely na predikciu optimálneho inštance typu spomedzi ~750 dostupných SKU, vrátane Graviton alternatív, a poskytuje performance risk skóre. Compute Optimizer je presnejší, hlbší a pokrýva viac resource typov (Lambda, ECS, RDS, EBS).
Môže Compute Optimizer automaticky zmeniť veľkosť mojich EC2 inštancií?
Nie, Compute Optimizer je čisto advisory služba, teda nevykonáva žiadne modifikácie. Automatizáciu musíte postaviť sami cez Lambda plus EventBridge, alebo cez Systems Manager Automation dokumenty. Toto obmedzenie je zámerné, pretože automatická zmena inštance typu vyžaduje reštart a môže spôsobiť produkčný incident, ak sa vykoná bez validácie.
Prečo pre niektoré inštancie Compute Optimizer neposkytuje odporúčanie?
Najčastejšie dôvody: inštancia beží menej ako 30 hodín, chýbajú CloudWatch metriky (napr. IMDSv2 misconfiguration), inštancia je Spot alebo Dedicated Host (nepodporované), alebo ide o novšiu inštanciu typu z GPU rodiny (P5, P6, G6e), ktoré ešte nie sú v modeli. Skontrolujte finding stĺpec: hodnota "Not classified" znamená nedostatok dát.
Ako presné sú odporúčania Compute Optimizer?
Vo verejnom benchmarku AWS z Q3 2025 dosahovala Compute Optimizer odporúčania s risk skóre ≤ 1.0 stabilne pod 5 % pravdepodobnosť saturation po aplikácii. Vlastný audit ~80 zákazníckych účtov ukazuje, že presnosť pre CPU-bound workloady je vysoká, pre memory-bound iba vtedy, keď je zapnutý CloudWatch Agent. Vždy validujte odporúčania s risk > 2.0 v staging prostredí.
Praktický playbook, ako znížiť Snowflake účet o 40–60 %: auto-suspend, right-sizing, Gen2 na Graviton 3, Query Acceleration, resource monitors a chargeback cez ACCOUNT_USAGE.
FOCUS 1.2 normalizuje fakturačné dáta z AWS, Azure a GCP do jednej schémy. V článku ukážem, ako povoliť exporty, akú DDL použiť v BigQuery či Snowflake, kde je rozdiel oproti CUR 2.0 a ktoré chyby ma pri nasadzovaní najviac potrápili.
Showback ukazuje cloud náklady tímom, chargeback ich reálne fakturuje. Porovnanie modelov, alokácia zdieľaných nákladov a implementácia v AWS, Azure a GCP.
