AWS Compute Optimizer útmutató 2026

Q: Mennyibe kerül az AWS Compute Optimizer?

Az alap-szolgáltatás ingyenes . Az „enhanced infrastructure metrics" bekapcsolása memória-alapú EC2 ajánlásokhoz 0,0468 USD/instance/hó (us-east-1, 2026-os áron). Az ECS on Fargate és Lambda riportok mindig ingyenesek.

Frissítve: 2026. július 29.

Az AWS Compute Optimizer egy ingyenes, machine learning alapú szolgáltatás, amely EC2 példányok, Auto Scaling csoportok, EBS kötetek, Lambda függvények és ECS on Fargate feladatok konfigurációját elemzi CloudWatch metrikák alapján, majd konkrét right-sizing ajánlásokat ad. Jellemzően 15–35% havi költségmegtakarítást eredményez úgy, hogy közben a teljesítmény változatlan vagy jobb marad. 2026-ra a szolgáltatás már támogatja a 7. generációs Graviton instanciákat, az idempotens exportot S3-ba, és a licenc-figyelmeztetéseket SQL Server workloadokra is.

A Compute Optimizer ingyenes, de opcionálisan bekapcsolható „enhanced infrastructure metrics" (memória-alapú ajánlások) havi ~0,0468 USD/instance áron.
Az ajánlások 14 napos CloudWatch előzményekre épülnek. Új workloadokra érdemes legalább 30 napot várni a stabil javaslatokért.
Graviton (ARM) instanciákra váltás átlagosan 20–40% árelőnyt ad x86-hoz képest, ha a workload újrafordítható.
A Lambda memória-tuning külön Optimizer riport. A „Not optimized" függvények 40–60%-a alul- vagy túlkonfigurált.
Multi-account környezetben az Organizations-integrációval egyszerre nyerhetsz ki riportokat 100+ fiókból CSV/S3 exportba.
A Compute Optimizer nem helyettesíti a Savings Plans és Reserved Instances döntést: először méretezz, aztán vásárolj kedvezményt.

Mi az AWS Compute Optimizer és mennyibe kerül?

A Compute Optimizer egy regionálisan bekapcsolható szolgáltatás, amely a CloudWatch metrikákból (CPU, hálózati I/O, disk I/O, és opcionálisan memória) 14 napos futóablakot vesz mintaként, majd egy proprietary ML modell alapján javasol alternatív konfigurációt. Az alap-szolgáltatás ingyenes: nem kell külön licenc, nem terhel az S3 API, és nincs adatátviteli díj a CloudWatchból történő olvasásért. Elég szép ajánlat egy AWS eszközhöz, valljuk be.

Van egy fizetős kiegészítő. Az „enhanced infrastructure metrics" bekapcsolásakor a Compute Optimizer figyelembe veszi a memóriakihasználtságot is (ehhez a CloudWatch Agent-et kell futtatnod az EC2-n). Ennek díja 0,0468 USD/instance/hó az us-east-1 régióban, ami egy 1 000 instance-os flottánál kb. 47 USD havonta. Filléres, ha ez oldja fel a helyes ajánlásokat memory-bound Java/JVM workloadokra. A hivatalos AWS Compute Optimizer dokumentáció részletesen leírja, mit fed le pontosan a szolgáltatás.

Fontos limit: a Compute Optimizer csak akkor ad ajánlást, ha az adott erőforrás legalább 30 óra CloudWatch adattal rendelkezik. Új környezetekre (pl. friss ASG-k) várj legalább egy hetet, éles produkciós flottára inkább 30 napot, mielőtt a javaslatokat megvalósítod. A rövidebb minta „Insufficient data" státuszt ad, nem téves ajánlást. Ez tulajdonképpen egy nagyon jó biztosíték.

Bekapcsolás és Organizations-integráció lépésről lépésre

Egyetlen fiókra a bekapcsolás egy kattintás a konzolon. De multi-account környezetben, ami a legtöbb komolyabb ügyfélnél a valóság, az Organizations delegated administrator setup a helyes út. Az én tapasztalatom szerint a management accountra soha ne engedj ilyen szolgáltatást. Inkább hozz létre egy dedikált „finops" fiókot, és delegálj neki.

Íme a teljes bekapcsolási parancsláncolat AWS CLI-vel a management accountból, majd a delegált fiókból:

# 1. Management account: engedélyezd a Compute Optimizert Organizations szinten
aws organizations enable-aws-service-access \
  --service-principal compute-optimizer.amazonaws.com

# 2. Regisztráld a finops fiókot delegált adminisztrátorként
aws compute-optimizer put-recommendation-preferences \
  --resource-type Ec2Instance \
  --scope name=AccountId,value=123456789012

# 3. Delegated admin account: kapcsold be a szolgáltatást minden gyerekfiókra
aws compute-optimizer update-enrollment-status \
  --status Active \
  --include-member-accounts

# 4. Ellenőrizd, hány fiók van beregisztrálva
aws compute-optimizer get-enrollment-statuses-for-organization \
  --output table

Ezután a Compute Optimizer 24–48 órán belül elkezdi feldolgozni a metrikákat. A régiónkénti bekapcsolás automatikus, tehát nem kell minden régiót külön regisztrálni. Viszont a metrikák régióspecifikusak, tehát egy eu-central-1-ben futó VM ajánlása csak az eu-central-1 régió konzolján fog megjelenni.

EC2 right-sizing: hogyan olvasd az ajánlásokat helyesen

Amikor megnyitod a Compute Optimizer EC2 riportot, minden példány négy státusz egyikébe kerül: Under-provisioned, Over-provisioned, Optimized, vagy Not optimized. Az „Optimized" azt jelenti, hogy nincs jobb konfiguráció adott peremfeltételek mellett, nem azt, hogy a példány kihasználtsága magas. Egy alacsony kihasználtságú instance is lehet „Optimized", ha nincs kisebb instance-típus adott vCPU/memória arányban. Ez egy elég gyakori félreértés forrása belső workshopokon is.

A „Recommendation options" oszlopban 1–3 alternatíva jelenik meg, mindegyikre egy Performance risk pontszám (0–5, alacsonyabb = biztonságosabb) és becsült havi költség. Én személy szerint a 0-ás vagy 1-es performance risk-nél merek automatizált változtatást, 2-es fölött mindig manual review-t kérek. A 4–5 risk általában akkor jelenik meg, ha a workload burst-ös és a Compute Optimizer nem tud stabilan következtetni.

Konkrét példa egy tavalyi ügyfelemnél. 240 db m5.2xlarge webszerver, átlag 18% CPU, 42% memória. A Compute Optimizer m6i.xlarge-ot javasolt, ami 50%-kal kisebb, ~30% olcsóbb példány, 1-es performance risk. Egy hét canary deployment után az egész flottát migráltuk, havi 14 400 USD megtakarítás, nulla incidens. Az ilyen „ordító" ajánlásokra érdemes elsőként ráugrani.

Graviton (ARM) migráció: mikor éri meg és mikor nem

2026-ra a Compute Optimizer alapértelmezetten mutatja a Graviton (ARM64) alternatívákat is x86 példányokra, feltéve, hogy engedélyezted a „Recommendation preferences" alatt. A c7g, m7g, és r7g családok 15–25% jobb ár/teljesítmény arányt kínálnak azonos vCPU/memória mellett. A c8g/m8g (Graviton4) 2025 vége óta további 10–15% előnyt ad SPEC CPU 2017 benchmarkokban.

Mikor éri meg váltani? A hivatalos AWS Graviton dokumentáció szerint a legtöbb multi-arch container image (Python, Node.js, Go, Java 17+) különösebb módosítás nélkül futtatható. Én az alábbi checklistet használom:

Igen, migrálj: containeres microservice-ek Alpine/Ubuntu ARM64 image-ekkel; Java-alapú Spring Boot; PostgreSQL/Redis; Nginx; Go binárisok.
Óvatosan: Node.js native modulok (pl. bcrypt, sharp) újrafordítást igényelnek; .NET workloadok esetén .NET 8+ oké, régebbi nem.
Ne migrálj: Windows Server workloadok (nincs ARM support); zárt forrású x86 binárisok; specifikus SIMD (AVX-512) optimalizált HPC kód.

Egy praktikus tipp: mielőtt a Compute Optimizer Graviton ajánlását végrehajtod, futtasd le a workloadot AWS Graviton Ready image-en canary módban legalább 3 napig. A p95/p99 latency-t figyeld, nem az átlagot. Java workloadok esetén a JIT warm-up az ARM-en más profilú, tehát az első 5–10 perc metrikáit érdemes eldobni. Ezt a hibát én is elkövettem egyszer élesben, csúnyán félrement a döntés adata.

Lambda memória-tuning a Compute Optimizerrel

A Lambda költsége lineárisan függ a memóriától (128 MB, egészen 10 240 MB-ig), de a CPU teljesítmény is ehhez van csatolva. 1 769 MB-nál kapsz egy teljes vCPU-t. Ez azt jelenti, hogy a „kevesebb memória = olcsóbb" naiv szabály sokszor rossz: gyakran több memória gyorsabb futást ad, ami kevesebb GB-second-öt, azaz alacsonyabb számlát eredményez.

A Compute Optimizer Lambda riportja pontosan ezt oldja meg: az invocation metrikákból (duration, memory used) becsli az optimális memória-konfigurációt. Az én tapasztalatom szerint egy tipikus REST API mögötti Lambda flotta 40–60%-a alul- vagy túlkonfigurált. Ha nem szereted a manuális iterációt, használhatod az AWS Lambda Power Tuning Step Functions state machine-t is, ami a Compute Optimizer ajánlását validálja empirikus futtatással.

Nézzük meg CLI-vel, hogyan húzhatod le a top-10 „biggest savers" Lambda függvényt egyetlen fiókodból:

# Export az összes Lambda ajánlás S3-ba (CSV formátum)
aws compute-optimizer export-lambda-function-recommendations \
  --s3-destination-config bucket=my-finops-reports,keyPrefix=lambda/ \
  --file-format Csv \
  --fields-to-export FunctionArn CurrentMemorySize RecommendationOptionsConfigurationMemorySize \
                     RecommendationOptionsEstimatedMonthlySavingsValue

# Top 10 megtakaritas jelolt kiolvasasa (S3 letoltes utan)
aws s3 cp s3://my-finops-reports/lambda/ - --recursive | \
  sort -t',' -k4 -nr | head -10

EBS kötet-optimalizálás: gp2 → gp3 és iops-tuning

A Compute Optimizer EBS Volume riport az egyik legelfelejtettebb, mégis leggyorsabb megtakarítás. A gp2 típust az AWS 2020 óta a gp3 váltotta le, és minden új account default-je a gp3. De a régi gp2 kötetek gyakran ott ragadnak a rendszerben évekig. A gp3 alapból 3 000 IOPS-t és 125 MB/s throughput-ot ad, a legtöbb workloadnak elég, és 20%-kal olcsóbb, mint a gp2 azonos kapacitáson.

Az AWS EBS modify-volume dokumentációja szerint a gp2 → gp3 konverzió élesben, downtime nélkül futtatható. Egy sima parancssorozat végrehajtja az egészet:

# Listazd az osszes gp2 kotetet es becsult megtakaritast
aws ec2 describe-volumes \
  --filters "Name=volume-type,Values=gp2" \
  --query 'Volumes[].[VolumeId,Size,State]' \
  --output table

# Konvertalj egyet gp3-ra (elesben, downtime nelkul)
aws ec2 modify-volume \
  --volume-id vol-0abc123def456789 \
  --volume-type gp3

# Batch konverzio minden gp2 -> gp3 (egy regioban)
for vol in $(aws ec2 describe-volumes \
  --filters "Name=volume-type,Values=gp2" \
  --query 'Volumes[].VolumeId' --output text); do
  aws ec2 modify-volume --volume-id "$vol" --volume-type gp3
done

Ha a workload igényel több IOPS-t, a gp3 esetén ezt külön (kapacitástól függetlenül) tudod skálázni. Egy 100 GB-os gp3 kötethez adhatsz 16 000 IOPS-t plusz díjért, míg gp2-nél ehhez ~5 TB kapacitást kellene fizetned. A részletes tagging és allocation stratégiáról az AWS, Azure és GCP cost allocation cikkünkben írtunk bővebben.

Compute Optimizer vs. Trusted Advisor vs. Cost Explorer

Az AWS három különböző költségoptimalizálási eszközt kínál, és sok ügyfelem összekeveri őket. Röviden: a Cost Explorer diagnosztika, a Trusted Advisor szabály-alapú riasztás, a Compute Optimizer ML-alapú konfigurációs ajánlás. Nem egymás helyettesítői. Együtt kell használni őket.

Szempont	Compute Optimizer	Trusted Advisor	Cost Explorer
Fő funkció	Right-sizing ajánlás ML-lel	Szabály-alapú best practice check	Költség-elemzés és forecast
Ár	Ingyenes (+ opcionális memória-metrika)	Business/Enterprise support kell a teljes verzióhoz	Ingyenes UI, fizetős API-hozzáférés (0,01 USD/call)
Metrika-forrás	14 nap CloudWatch	Konfiguráció-snapshot	Billing adatok napi granularitással
Erőforrás típus	EC2, ASG, EBS, Lambda, ECS/Fargate	~100 fajta AWS erőforrás	Minden szolgáltatás billing szinten
Ajánlás jellege	Konkrét instance-típus + memória	„Idle EC2", „Underutilized EBS"	Nincs, csak riport és anomália
SP/RI integráció	Nincs	Van (SP/RI utilization)	Van (SP/RI vásárlási ajánlás)
API export	Van (S3 CSV)	Van (Support API)	Van (Cost Explorer API)

Az én workflow-om jellemzően így néz ki: (1) Cost Explorer-rel megtalálom a top 5 legdrágább szolgáltatást; (2) Trusted Advisor-ral kiszűröm az idle/unused erőforrásokat, és leállítom őket; (3) Compute Optimizer-rel right-size-olom a maradékot; (4) végül Savings Plans / RI vásárlással letakarom a stabil baseline-t. Ez a sorrend kritikus. Ha előbb veszel SP-t, majd right-size-olsz, feleslegesen sok kommitmentet fizetsz.

Ajánlások automatizált feldolgozása: CLI, Lambda és Terraform

Kis flottánál (100 instance alatt) a konzol elég. Nagy környezetben viszont a Compute Optimizer riportokat érdemes napi rendszerességgel S3-ba exportálni és GitOps pipeline-ba tolni. Egy tipikus setup: EventBridge scheduler, Lambda export, S3, Athena query, Slack/PagerDuty riport. A megvalósításhoz hasonló pipeline-okat részletesen leírtunk a felhőköltség-optimalizálás automatizálása cikkünkben.

Íme egy minimális Python Lambda, ami napi export-ot indít és a top-20 megtakarítást Slack-re dobja:

import boto3
import json
import os
import urllib3

optimizer = boto3.client('compute-optimizer')
http = urllib3.PoolManager()

BUCKET = os.environ['REPORT_BUCKET']
SLACK_HOOK = os.environ['SLACK_WEBHOOK_URL']

def lambda_handler(event, context):
    # 1. Inditsd az EC2 recommendation export jobot
    export = optimizer.export_ec2_instance_recommendations(
        s3DestinationConfig={
            'bucket': BUCKET,
            'keyPrefix': 'daily-ec2/'
        },
        fileFormat='Csv',
        fieldsToExport=[
            'AccountId', 'InstanceArn', 'CurrentInstanceType',
            'RecommendationOptionsInstanceType',
            'RecommendationOptionsEstimatedMonthlySavingsValue',
            'RecommendationOptionsPerformanceRisk'
        ],
        includeMemberAccounts=True
    )

    # 2. Slack ertesites, ha 500 USD+ potencial van
    total_savings = calculate_total_savings(export['jobId'])
    if total_savings > 500:
        http.request(
            'POST', SLACK_HOOK,
            body=json.dumps({
                'text': f'Compute Optimizer riport kesz: '
                        f'${total_savings:.0f} havi megtakaritas lehetseges'
            }),
            headers={'Content-Type': 'application/json'}
        )
    return {'jobId': export['jobId'], 'savings': total_savings}

Ha Infrastructure as Code-ban dolgozol, a Terraform AWS provider 5.60+ támogatja az aws_computeoptimizer_recommendation_preferences resource-t, tehát a Graviton preferenciákat és a memória-metrika bekapcsolást is deklaratív módon tudod kezelni. A Compute Optimizer JSON riportjaiból CDK-val vagy Terraform-mal generálhatsz PR-eket az ASG launch template-ekre. Ez a „closed-loop right-sizing", amit én is használok éles környezetben. Őszintén: nem triviális felépíteni, de amint megy, kényelmesen szinten tartja a flottát.

Gyakori kérdések

Mennyibe kerül az AWS Compute Optimizer?

Az alap-szolgáltatás ingyenes. Az „enhanced infrastructure metrics" bekapcsolása memória-alapú EC2 ajánlásokhoz 0,0468 USD/instance/hó (us-east-1, 2026-os áron). Az ECS on Fargate és Lambda riportok mindig ingyenesek.

Milyen gyakran frissülnek a Compute Optimizer ajánlások?

A Compute Optimizer napi rendszerességgel újraszámolja az ajánlásokat, 14 napos CloudWatch mintaablakot használva. Egy új workload legalább 30 óra után kap első ajánlást, de a stabil, megbízható javaslatokhoz érdemes 30 napot várni.

Mi a különbség a Compute Optimizer és a Trusted Advisor között?

A Trusted Advisor szabály-alapú checkeket futtat (pl. „idle EC2", „unassociated EIP"), a Compute Optimizer viszont ML-modellt használ, hogy konkrét alternatív instance-típust javasoljon 14 napos telemetria alapján. A Trusted Advisor a Business/Enterprise support előfizetéshez kötött teljes verzióban, a Compute Optimizer minden fiókhoz elérhető.

A Compute Optimizer figyelembe veszi a Savings Plans-t vagy Reserved Instances-t?

Nem közvetlenül. A right-sizing ajánlások az on-demand áron alapulnak. Az én ajánlásom: először right-size-olj a Compute Optimizerrel, aztán a Cost Explorer SP/RI recommender-t futtasd. Fordított sorrend feleslegesen nagy commitmentet eredményez.

Hogyan kapcsolható be a Graviton ajánlás a Compute Optimizerben?

A Compute Optimizer konzolján a „Recommendation preferences" és „Enhanced infrastructure metrics" mellett engedélyezd az „Include ARM64 (Graviton) instance types" opciót, vagy CLI-vel a put-recommendation-preferences paranccsal állítsd be az InferredWorkloadTypes paramétert.

Multi-account környezetben hogyan tudom központilag látni az összes ajánlást?

AWS Organizations-t kell használnod, és delegated administrator fiókot kell kijelölnöd (általában egy dedikált finops fiók). Ezután a delegált fiókból az --include-member-accounts flag-gel exportálhatod az összes tagfiók ajánlását egyetlen CSV-be S3-ba.