Right-Sizing în Cloud: Ghid Practic AWS Compute Optimizer, Azure Advisor și GCP Recommender (2026)

De ce right-sizing-ul este prioritatea #1 în FinOps

Studiile din 2026 arată că organizațiile risipesc în medie 30% din bugetul cloud pe resurse supradimensionate. AWS raportează că majoritatea instanțelor EC2 rulează la o utilizare medie a CPU de sub 40%, iar un sondaj Stacklet a relevat că 78% din organizații estimează că 21–50% din bugetele lor cloud sunt irosite pe capacitate nefolosită. Într-o companie care cheltuiește 100.000 USD/lună, asta înseamnă 20.000–50.000 USD pierdute lunar. Lunar. Fără ca nimeni să observe.

Right-sizing-ul — procesul de ajustare a dimensiunii resurselor cloud la consumul real — este intervenția cu cel mai rapid ROI în orice program FinOps. Spre deosebire de Reserved Instances sau Savings Plans, care necesită angajamente de 1–3 ani, right-sizing-ul generează economii imediate, fără riscuri financiare suplimentare. Și sincer, e unul dintre puținele locuri în cloud unde poți vedea rezultatele direct pe factura din luna următoare.

În acest ghid vom parcurge pas cu pas cum să utilizezi AWS Compute Optimizer, Azure Advisor și GCP Recommender pentru a identifica și aplica recomandările de right-sizing pe flota ta de mașini virtuale — cu exemple concrete de CLI și o metodologie sigură de implementare.

Ce înseamnă right-sizing-ul în cloud?

Practic, right-sizing-ul presupune selectarea tipului și dimensiunii de instanță care corespunde cel mai bine cerințelor reale ale workload-ului. Adică nu prea mare (care risipesc bani) și nu prea mic (care degradează performanța). Sună simplu, dar în practică e mai complicat decât pare.

Există două direcții principale:

• Downsize (reducere) – instanțe over-provisioned unde CPU, memorie și rețea sunt consistent sub-utilizate. Acestea reprezintă 80–90% din oportunități — adică marea majoritate a cazurilor pe care le vei întâlni.
• Upsize (creștere) – instanțe under-provisioned unde resursele sunt saturate, cauzând latență crescută, throttling sau OOM kills.

Un lucru important: right-sizing-ul nu trebuie confundat cu oprirea instanțelor inactive (eliminarea resurselor zombie) sau cu trecerea la Spot Instances pentru workload-uri tolerante la întreruperi — acestea sunt strategii complementare, nu identice.

De ce sunt instanțele supradimensionate?

Supradimensionarea apare din câteva motive structurale pe care le regăsim în aproape orice organizație. (Dacă lucrezi în tech suficient de mult, probabil le recunoști pe toate.)

• Estimările worst-case – echipele de inginerie aleg dimensiunea instanței pe baza unui scenariu de vârf teoretic, adaugă un buffer de 2×–3× „ca să fie sigur", și nu revizuiesc niciodată decizia.
• Lipsa ownership-ului financiar – dacă nimeni nu e responsabil pentru costul unui serviciu individual, nimeni nu are motivația să optimizeze.
• Teama de degradarea performanței – echipele ezită să reducă dimensiunea instanțelor pentru că nu au un plan de rollback clar și nu există SLO-uri definite.
• Provizionarea inițială niciodată revizuită – o instanță lansată în 2021 pentru un vârf de trafic sezonier poate rula supradimensionat 5 ani fără ca nimeni să observe. Și asta se întâmplă mai des decât ai crede.

Pasul 0: Right-size înainte de commitments financiare

Aceasta e probabil cea mai importantă regulă din tot ghidul: realizează right-sizing întotdeauna înaintea achizițiilor de Reserved Instances sau Savings Plans. Dacă achiziționezi un Reserved Instance de tip m5.4xlarge pentru o instanță care în realitate are nevoie de m5.xlarge, ai blocat plata pentru capacitate de 4× mai mare timp de 1–3 ani — anulând complet avantajul discount-ului.

Dacă deja utilizezi commitments și descoperi oportunități de right-sizing, consultă ghidul nostru despre strategii multi-cloud pentru Reserved Instances și Savings Plans pentru a înțelege cum poți modifica sau converti commitments existente pe AWS, Azure și GCP.

Right-Sizing pe AWS cu AWS Compute Optimizer

AWS Compute Optimizer este instrumentul nativ AWS pentru right-sizing, bazat pe machine learning. Analizează datele CloudWatch din ultimele 14 zile (sau 93 de zile cu Enhanced Infrastructure Metrics) și generează recomandări pentru EC2, Auto Scaling Groups, EBS, Lambda și Amazon ECS pe Fargate. Este, fără îndoială, cel mai matur instrument de acest tip dintre toți cei trei cloud provideri majori.

1. Activarea AWS Compute Optimizer

Dacă lucrezi la nivel de AWS Organization, activezi Compute Optimizer pentru toate conturile membre dintr-o singură comandă:

# Activare pentru contul curent
aws compute-optimizer update-enrollment-status --status Active

# Activare pentru toate conturile din Organization
aws compute-optimizer update-enrollment-status \
  --status Active \
  --include-member-accounts

Recomandările inițiale apar în aproximativ 12 ore. Instanțele trebuie să fi acumulat cel puțin 30 de ore de metrici pentru a primi recomandări — deci nu te aștepta la rezultate imediate după activare.

2. Activarea metricilor de memorie RAM

Implicit, CloudWatch nu colectează utilizarea memoriei RAM. Fără acest metric, Compute Optimizer nu poate recomanda right-sizing pe dimensiunea memoriei — un dezavantaj major pentru instanțele memory-intensive. Instalează CloudWatch Agent pe instanțele EC2:

# Instalare CloudWatch Agent pe Amazon Linux 2 / AL2023
sudo yum install -y amazon-cloudwatch-agent

# Pornire wizard de configurare (include metrici de memorie)
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

La scară, folosește AWS Systems Manager Run Command cu documentul AmazonCloudWatch-ManageAgent pentru a instala și configura agentul pe întreaga flotă simultan, fără acces SSH direct. Mult mai elegant decât să faci SSH pe fiecare server în parte.

3. Citirea recomandărilor via AWS CLI

# Recomandări pentru toate instanțele EC2, cu economii estimate
aws compute-optimizer get-ec2-instance-recommendations \
  --output json \
  --query 'instanceRecommendations[*].{
    Instance: instanceName,
    Finding: finding,
    CurrentType: currentInstanceType,
    RecommendedType: recommendationOptions[0].instanceType,
    MonthlySavingsUSD: recommendationOptions[0].estimatedMonthlySavings.value
  }'

Câmpul finding poate returna:

• OVER_PROVISIONED – cel puțin o dimensiune poate fi redusă
• UNDER_PROVISIONED – cel puțin o dimensiune trebuie mărită
• OPTIMIZED – instanța este corect dimensionată
• NOT_OPTIMIZED – date insuficiente pentru o recomandare

4. Export la scară pentru flote mari

Pentru flote cu sute sau mii de instanțe, exportă recomandările în S3 pentru analiză în Athena sau QuickSight:

# Export CSV în S3 pentru analiză offline
aws compute-optimizer export-ec2-instance-recommendations \
  --s3-destination-config '{
    "bucket": "bucket-finops-recomandari",
    "keyPrefix": "compute-optimizer/ec2/"
  }' \
  --file-format Csv \
  --include-member-accounts

5. Enhanced Infrastructure Metrics: lookback de 93 de zile

Pentru workload-uri cu pattern-uri săptămânale sau lunare (ex.: procesări batch de end-of-month), activează lookback-ul extins. Costul e de aproximativ $0.0003360/resursă/oră, dar recomandările sunt semnificativ mai precise:

aws compute-optimizer update-enrollment-status \
  --status Active \
  --enhanced-infrastructure-metrics Activate

Pentru o flotă de 100 de instanțe EC2, costul lunar al Enhanced Metrics este de aproximativ $24 — neglijabil față de economiile de zeci de mii de dolari generate. Matematica e simplă.

6. Bonus: Migrarea la AWS Graviton 4

Compute Optimizer poate recomanda și migrarea la instanțe cu arhitectură ARM (AWS Graviton 4), care sunt cu 20–25% mai ieftine față de echivalentele Intel/AMD și oferă performanță mai bună. Instanțele C8g (Graviton4) sunt recomandarea pentru 2026 pentru workload-uri compute-intensive, cu până la 30% performanță față de C7g (Graviton3):

# Verifică dacă AMI-ul suportă arm64
aws ec2 describe-images \
  --image-ids ami-XXXXXXXX \
  --query 'Images[*].{Name:Name,Arch:Architecture}'

# Lansare instanță Graviton 4 (c8g.xlarge)
aws ec2 run-instances \
  --image-id ami-XXXXXXXX-arm64 \
  --instance-type c8g.xlarge \
  --count 1 \
  --subnet-id subnet-XXXXXXXX

Aplicațiile Go, Python, Java (JVM) și Node.js rulează nativ pe arm64 fără modificări de cod în marea majoritate a cazurilor. Am văzut echipe care au economisit suplimentar 20% doar din această migrare, pe lângă right-sizing-ul propriu-zis.

Right-Sizing pe Azure cu Azure Advisor

Azure Advisor folosește algoritmi de machine learning pentru a analiza utilizarea CPU, memorie și rețea a VM-urilor și a recomanda fie reducerea dimensiunii (resize), fie oprirea instanțelor inactive. Integrarea cu portalul Azure e elegantă, dar CLI-ul rămâne instrumentul de ales la scară.

1. Vizualizarea recomandărilor via Azure CLI

# Recomandări de cost pentru VM-urile subutilizate
az advisor recommendation list \
  --category Cost \
  --query "[?contains(impactedField,'virtualMachines')].{
    Resource: impactedValue,
    Impact: impact,
    Problem: shortDescription.problem,
    Solution: shortDescription.solution
  }" \
  --output table

2. Configurarea perioadei de lookback

Implicit, Azure Advisor analizează ultimele 7 zile de utilizare. Pentru workload-uri cu variații mari, extinde lookback-ul — 30 de zile e un bun echilibru:

# Configurare lookback la 30 de zile la nivel de subscription
az advisor configuration update \
  --configuration-name default \
  --vm-config '{"vmRecommendationLookbackPeriodInDays": 30}'

Perioadele disponibile sunt: 7, 14, 21, 30, 60 și 90 de zile. Recomandările se actualizează în maximum 48 de ore după modificarea configurației.

3. Criterii de decizie Azure Advisor

Azure Advisor marchează o VM ca subutilizată când media utilizării CPU este sub 5% în ultimele 14 zile (prag configurabil). Dacă utilizarea e aproape de zero, recomandă oprirea VM-ului; altfel sugerează trecerea la un SKU mai mic din aceeași familie sau la o familie mai nouă (exemplu: D3v2 → D2v3). Advisor evaluează și eligibilitatea pentru SKU-uri Burstable (seria B), mai ieftine pentru workload-uri cu utilizare variabilă.

4. Aplicarea recomandărilor Azure

# Oprire VM inactiv (deallocate eliberează resursele de compute)
az vm deallocate \
  --resource-group myResourceGroup \
  --name myVMName

# Redimensionare VM la SKU mai mic
az vm resize \
  --resource-group myResourceGroup \
  --name myVMName \
  --size Standard_D2v3

# Repornire VM după resize
az vm start \
  --resource-group myResourceGroup \
  --name myVMName

Atenție: Verifică utilizarea memoriei independent față de recomandările Advisor — acesta se concentrează pe CPU și rețea. O VM cu CPU scăzut dar utilizare ridicată de RAM poate deveni instabilă după downsize. E o greșeală clasică pe care o fac echipele în grabă.

Right-Sizing pe GCP cu GCP Recommender

Compute Engine generează automat recomandări de right-sizing bazate pe datele Cloud Monitoring din ultimele 8 zile. Recomandările acoperă atât reducerea cât și creșterea numărului de vCPU și cantității de RAM, iar recomandările cu economii sub $10/lună nu sunt afișate (pentru a evita zgomotul).

1. Listarea recomandărilor via gcloud

# Listare recomandări pentru toate VM-urile dintr-o zonă
gcloud recommender recommendations list \
  --recommender=google.compute.instance.MachineTypeRecommender \
  --project=my-project-id \
  --location=us-central1-a \
  --format="table(
    name.basename(),
    stateInfo.state,
    primaryImpact.costProjection.cost.units,
    content.overview.recommendedMachineType.name
  )"

2. Aplicarea unei recomandări

# Oprire instanță (necesară pentru schimbarea machine type)
gcloud compute instances stop my-vm-name --zone=us-central1-a

# Modificare tip mașină conform recomandare
gcloud compute instances set-machine-type my-vm-name \
  --zone=us-central1-a \
  --machine-type=n2-standard-4

# Repornire instanță
gcloud compute instances start my-vm-name --zone=us-central1-a

3. Custom Machine Types — avantajul unic GCP

GCP are un avantaj unic față de AWS și Azure: Custom Machine Types, care îți permit să specifici exact numărul de vCPU și cantitatea de RAM, independent una de alta:

# Creare VM cu 6 vCPU și 12 GB RAM
# Sintaxa: custom-{vCPU}-{RAM_in_MB}
gcloud compute instances create my-custom-vm \
  --zone=us-central1-a \
  --machine-type=custom-6-12288 \
  --image-family=debian-12 \
  --image-project=debian-cloud

Aceasta e ideală când recomandatorul sugerează un tip standard care oferă prea mult dintr-o dimensiune și prea puțin din alta — situație frecventă pentru aplicații memory-bound sau compute-bound neobișnuite. Nu o să găsești această flexibilitate pe AWS sau Azure.

4. Automatizarea right-sizing-ului pe GCP

Poți automatiza aplicarea recomandărilor prin etichetarea VM-urilor eligibile și un Cloud Function/Cloud Run care rulează periodic:

# Etichetare VM pentru procesare automată
gcloud compute instances add-labels my-vm-name \
  --zone=us-central1-a \
  --labels=auto-rightsize=enabled

# Vizualizare toate VM-urile cu label-ul setat
gcloud compute instances list \
  --filter="labels.auto-rightsize=enabled" \
  --format="table(name,zone,machineType,status)"

Notă importantă GCP: Instalează Ops Agent (înlocuitorul Cloud Monitoring Agent) pe toate VM-urile pentru ca recomandatorul să aibă acces la metrici de memorie, esențiale pentru recomandări precise.

Fluxul de lucru recomandat: Right-Sizing sigur pas cu pas

Indiferent de cloud provider, urmează acest workflow pentru a minimiza riscul și maximiza economiile. Pare mult, dar după primele două iterații devine aproape a doua natură:

1. Colectează date pe 30–90 de zile – Nu te baza pe ultima săptămână. Capturează un ciclu business complet (lunar, trimestrial) pentru a evita să ratezi vârfuri sezoniere.
2. Segmentează pe tier de serviciu – Separă producția de staging/dev. Non-producția poate fi agresiv redusă (economii tipice: 40–60%); producția necesită mai multă atenție.
3. Prioritizează top 20% din instanțele cu cel mai mare cost – Conform principiului Pareto, acestea generează 80% din economiile potențiale.
4. Verifică atât media cât și percentilele p90/p99 – O instanță cu CPU mediu de 5% poate avea spike-uri la 80% timp de 10 minute pe zi. Reducerea ar putea cauza timeout-uri în orele de vârf.
5. Testează în non-producție mai întâi – Aplică resize-ul pe staging/QA și monitorizează 24–48 de ore înainte de a promova pe producție.
6. Reduce incremental, un nivel la un moment dat – De exemplu: m5.2xlarge → m5.xlarge, nu m5.2xlarge → m5.small.
7. Definește criterii de rollback automat – Dacă latența p99 crește cu >20% sau rata de erori depășește 0.1%, revino automat la dimensiunea anterioară.
8. Repetă trimestrial – Right-sizing-ul nu e o acțiune one-time; workload-urile evoluează și oportunitățile reapar.

Right-Sizing ca parte a strategiei FinOps multi-nivel

Right-sizing-ul este cel mai eficient ca fundament al unei strategii FinOps multi-nivel. Gândește-te la el ca la primul strat din care construiești tot restul:

• Right-sizing → Commitments: Abia după ce ai stabilit dimensiunea corectă, aplică Reserved Instances sau Savings Plans pentru baseline-ul stabil. Altfel, blochezi overcapacitate timp de 1–3 ani, anulând beneficiul discount-ului.
• Right-sizing → Spot Instances: Pentru workload-uri tolerante la întreruperi, combină right-sizing-ul cu Spot Instances multi-cloud pentru economii cumulate de 60–80% față de On-Demand.

Economii potențiale prin right-sizing: tabel comparativ

Capcane comune de evitat

Înainte să te arunci în implementare, câteva greșeli clasice pe care le văd frecvent:

• Nu face right-sizing bazat exclusiv pe media de utilizare – Media poate ascunde spike-uri critice. Analizează întotdeauna percentilele p90 și p99.
• Nu uita de metricile de memorie – Fără CloudWatch Agent (AWS) sau Ops Agent (GCP), recomandatorii nu pot evalua RAM-ul și pot sugera reduceri periculoase pentru aplicații memory-bound.
• Nu aplica pe toate instanțele simultan – Un incident pe producție poate costa mai mult decât economiile generate în 6 luni. Rulează în wave-uri de 10–20% din flotă.
• Nu confunda utilizarea CloudWatch cu performanța reală a aplicației – Monitorizează latența și rata de erori la nivel de aplicație, nu doar CPU/RAM la nivel de OS.
• Nu ignora instanțele de dev/staging – Acestea sunt adesea dimensionate identic cu producția și reprezintă câștiguri rapide de 30–50% fără riscuri.
• Nu face right-sizing fără criterii clare de succes – Definește înainte SLO-urile: latența p99 maximă acceptabilă, rata de erori maximă. Fără acestea, nu poți evalua dacă resize-ul a funcționat.