Strategije i najbolje prakse 12 min čitanja

Right-sizing cloud instanci: Praktični vodič za AWS, Azure i GCP u 2026.

Naučite kako sustavno provoditi right-sizing cloud instanci na AWS-u, Azureu i GCP-u. Praktični vodič s CLI naredbama, Terraform automatizacijom i strategijom migracije na ARM procesore za uštedu 20-40%.

Editorial Team

Zašto je right-sizing temelj svake cloud optimizacije

Ako ste pročitali naše prethodne vodiče o reserved instances, spot instancama i lifecycle politikama za pohranu, vjerojatno ste već osjetno smanjili svoj cloud račun. Ali postoji jedan korak koji bi, iskreno, trebao doći prije svega navedenog — right-sizing.

Right-sizing je, najjednostavnije rečeno, postupak usklađivanja tipa i veličine cloud instanci s onim što vam zapravo treba. Zvuči trivijalno, zar ne? Statistike govore sasvim drugačije.

Prema podacima iz 2026., organizacije u prosjeku bacaju 28 do 35% svog cloud budžeta na prekomjerno provizonirane ili neiskorištene resurse. A compute resursi — EC2, Azure VM-ovi, GCP Compute Engine — gotovo uvijek su najveća stavka na računu. Dakle, tu se krije najviše novca za uštedjeti.

Evo zašto je to toliko bitno: ako kupite reserved instance za instancu koja je dvostruko veća nego što treba, zaključali ste se na plaćanje viška na jednu do tri godine. Koristite spot instance za predimenzionirane workloadove? I dalje trošite više nego što biste trebali, čak i uz popust od 90%. Ukratko — right-sizing je preduvjet za sve ostale strategije uštede.

Timovi koji sustavno provode right-sizing obično vide uštede od 20 do 40% na troškovima računalnih resursa, i to bez degradacije performansi. U ovom vodiču prolazimo kroz konkretne korake kako to postići na sva tri velika cloud providera — s CLI naredbama, skriptama i Terraform kodom koji možete odmah koristiti.

Kako right-sizing zapravo funkcionira: proces u tri koraka

Bez obzira koji cloud koristite, right-sizing se svodi na tri faze: prikupljanje metrika, analiza i preporuke, te primjena promjena. Svaka faza ima svoje alate i (nažalost) svoje zamke.

Faza 1: Prikupljanje metrika korištenja

Da biste donijeli ispravne odluke, trebate podatke o stvarnom korištenju CPU-a, memorije, mrežnog prometa i disk I/O-a. Ovo je apsolutno ključno — odluke temeljene na pretpostavkama gotovo uvijek završe prekomjernim provizioniranjem jer inženjeri (razumljivo) preferiraju sigurnost nad štednjom.

Minimalno preporučeno razdoblje za prikupljanje podataka je 14 dana. Ali za zaista pouzdane preporuke, ciljajte na 30 dana ili više. Razlog? Želite uhvatiti tjedne uzorke korištenja — opterećenje radnim danom obično se značajno razlikuje od vikenda, a to dosta utječe na prosjek.

Faza 2: Analiza i generiranje preporuka

Svaki cloud provider ima nativne alate koji automatski analiziraju prikupljene metrike i generiraju preporuke. AWS ima Compute Optimizer, Azure ima Advisor, GCP ima Recommender. O svakom detaljno u nastavku.

Faza 3: Primjena promjena

I tu većina timova — stane. Preporuke postoje u dashboardu, ali nitko ih ne primjenjuje jer se svi boje da će nešto pući u produkciji.

Ključ je u postupnom pristupu: počnite s instancama koje koriste manje od 40% CPU-a i memorije, primijenite promjenu, pratite metriku 48 sati, pa tek onda idite dalje. Nikad nemojte mijenjati sve odjednom — to je recept za katastrofu.

AWS Compute Optimizer: detaljni vodič

AWS Compute Optimizer je besplatan alat koji analizira metrike korištenja vaših EC2 instanci, Auto Scaling grupa, Lambda funkcija, EBS volumena i ECS servisa na Fargateu. Koristi strojno učenje za generiranje preporuka koje optimiziraju i trošak i performanse — što ga čini odličnom polaznom točkom.

Korak 1: Aktivacija Compute Optimizera

Compute Optimizer zahtijeva eksplicitnu aktivaciju (nije uključen po defaultu). Možete ga aktivirati za pojedinačni račun ili za cijelu organizaciju:

# Aktivacija za trenutni račun
aws compute-optimizer update-enrollment-status \
  --status Active

# Za AWS Organizations — aktivacija iz management računa
aws compute-optimizer update-enrollment-status \
  --status Active \
  --include-member-accounts

# Provjera statusa
aws compute-optimizer get-enrollment-status

Nakon aktivacije, Compute Optimizer treba minimalno 30 sati prikupljanja metrika za prve preporuke. Za pouzdanije rezultate, pričekajte barem 14 dana — znam da to zvuči dugo, ali isplati se.

Korak 2: Aktivacija naprednih metrika (opcionalno)

Standardni Compute Optimizer analizira zadnjih 14 dana CloudWatch metrika. Za workloadove s mjesečnim ciklusima, to jednostavno nije dovoljno. Napredne infrastrukturne metrike proširuju period analize na čak 93 dana:

# Aktivacija naprednih metrika (plaćena opcija — $0,000336/resurs/sat)
aws compute-optimizer put-recommendation-preferences \
  --resource-type Ec2Instance \
  --scope '{"name": "AccountId", "value": "123456789012"}' \
  --enhanced-infrastructure-metrics Active

Jedan detalj koji mnogi zaborave: CloudWatch standardno ne prikuplja metrike memorije. Ako želite da Compute Optimizer uzme u obzir korištenje RAM-a (a definitivno biste trebali), morate instalirati CloudWatch Agent na svoje instance. Agent objavljuje metrike u CWAgent namespace, a Compute Optimizer ih automatski prepoznaje.

Korak 3: Dohvaćanje preporuka

# Dohvati preporuke za sve EC2 instance
aws compute-optimizer get-ec2-instance-recommendations \
  --region eu-central-1

# Dohvati preporuke za specifičnu instancu
aws compute-optimizer get-ec2-instance-recommendations \
  --instance-arns arn:aws:ec2:eu-central-1:123456789012:instance/i-0abcdef1234567890

# Izvoz svih preporuka u S3 za analizu
aws compute-optimizer export-ec2-instance-recommendations \
  --s3-destination-config '{"bucket": "moj-bucket-za-optimizaciju", "keyPrefix": "ec2-preporuke"}' \
  --file-format Csv \
  --include-member-accounts

Preporuke uključuju procijenjenu mjesečnu uštedu, rizik za performanse (nizak, srednji, visok) i preporučeni tip instance. Moj savjet — usredotočite se prvo na preporuke s niskim rizikom i visokom uštedom. To su "low-hanging fruit" promjene koje daju rezultate bez noćnih mora.

Korak 4: Primjena promjene veličine

Za EC2 instance koje nisu u Auto Scaling grupi, promjena tipa zahtijeva zaustavljanje instance. Da, to znači kratak downtime — planirajte ga unaprijed:

# Zaustavi instancu
aws ec2 stop-instances --instance-ids i-0abcdef1234567890

# Promijeni tip instance
aws ec2 modify-instance-attribute \
  --instance-id i-0abcdef1234567890 \
  --instance-type m7g.large

# Pokreni instancu
aws ec2 start-instances --instance-ids i-0abcdef1234567890

# Provjeri novi tip
aws ec2 describe-instances \
  --instance-ids i-0abcdef1234567890 \
  --query "Reservations[].Instances[].InstanceType"

Lambda right-sizing

Za Lambda funkcije, right-sizing se svodi na optimizaciju alokacije memorije. Previše memorije — bacate novac. Premalo memorije — funkcija se izvršava duže, a plaćate memorija × trajanje. Znači, gubi se na obje strane.

# Dohvati preporuke za Lambda funkcije
aws compute-optimizer get-lambda-function-recommendations \
  --region eu-central-1

# Ažuriraj memoriju Lambda funkcije
aws lambda update-function-configuration \
  --function-name moja-funkcija \
  --memory-size 512

Azure Advisor: vodič za right-sizing VM-ova

Azure Advisor koristi algoritme strojnog učenja za identifikaciju nedovoljno iskorištenih virtualnih strojeva i Virtual Machine Scale Set-ova. Analizira CPU, memoriju, IOPS cachiranih podataka i mrežnu propusnost kroz period od minimalno 7 dana.

Dohvaćanje preporuka putem Azure CLI-ja

# Dohvati sve cost preporuke iz Azure Advisora
az advisor recommendation list \
  --category cost \
  --output table

# Filtriraj samo preporuke za VM-ove
az advisor recommendation list \
  --category cost \
  --query "[?impactedField=='Microsoft.Compute/virtualMachines']" \
  --output table

Azure Advisor prepoznaje tri scenarija: instancu treba ugasiti (ako nije korištena zadnjih 7 dana), smanjiti (ako su CPU i memorija konstantno niski), ili prebaciti na B-seriju — burstable SKU idealan za varijabilna opterećenja s niskim prosjekom i povremenim skokovima.

Analiza metrika prije promjene

Ovo je važno — Advisor koristi samo 7 dana podataka. To je premalo za donošenje odluke o produkcijskom serveru. Uvijek provjerite metrike za duži period, idealno 30 dana:

# Dohvati prosječno i maksimalno korištenje CPU-a za zadnjih 30 dana
az monitor metrics list \
  --resource /subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Compute/virtualMachines/{vm-name} \
  --metric "Percentage CPU" \
  --start-time 2026-02-01T00:00:00Z \
  --end-time 2026-03-02T00:00:00Z \
  --interval PT1H \
  --aggregation Average Maximum \
  --output table

Promjena veličine VM-a

# Provjeri trenutnu veličinu
az vm show \
  --resource-group moja-grupa-resursa \
  --name moj-vm \
  --query hardwareProfile.vmSize \
  --output tsv

# Prikaži dostupne veličine za promjenu
az vm list-vm-resize-options \
  --resource-group moja-grupa-resursa \
  --name moj-vm \
  --output table

# Promijeni veličinu VM-a (zahtijeva restart)
az vm resize \
  --resource-group moja-grupa-resursa \
  --name moj-vm \
  --size Standard_B2ms

Jedno bitno upozorenje: ako imate kupljene Reserved Instance za određeni SKU, promjena veličine VM-a može značiti gubitak tog popusta. Obavezno provjerite rezervacije prije nego primijenite bilo kakvu preporuku.

GCP Recommender: vodič za Compute Engine

Google Cloud Recommender analizira korištenje CPU-a i memorije vaših VM instanci kroz zadnjih 8 dana i generira preporuke za promjenu tipa stroja. Posebno je zanimljiv u kombinaciji s GCP-ovim custom machine types — ali o tome malo kasnije.

Aktivacija i dohvaćanje preporuka

# Aktiviraj Recommender API
gcloud services enable recommender.googleapis.com

# Dohvati preporuke za right-sizing u određenoj zoni
gcloud recommender recommendations list \
  --recommender=google.compute.instance.MachineTypeRecommender \
  --project=moj-projekt \
  --location=europe-west3-a \
  --format=table

# Dohvati preporuke za Managed Instance Groups
gcloud recommender recommendations list \
  --recommender=google.compute.instanceGroupManager.MachineTypeRecommender \
  --project=moj-projekt \
  --location=europe-west3-a \
  --format=yaml

Par stvari za imati na umu: GCP neće prikazati preporuke ako je procijenjena ušteda manja od 10 dolara mjesečno. Također, preporuke ne postoje za instance kreirane putem App Enginea, Dataflowa, GKE-a ili Dataproca — za te resurse morate koristiti druge pristupe.

Primjena preporuke — promjena tipa stroja

# Zaustavi VM
gcloud compute instances stop moj-vm --zone=europe-west3-a

# Promijeni na preporučeni tip stroja
gcloud compute instances set-machine-type moj-vm \
  --zone=europe-west3-a \
  --machine-type=e2-standard-4

# Ili koristi custom machine type za precizno dimenzioniranje
gcloud compute instances set-machine-type moj-vm \
  --zone=europe-west3-a \
  --custom-cpu=4 \
  --custom-memory=10240MB

# Pokreni VM
gcloud compute instances start moj-vm --zone=europe-west3-a

GCP Custom Machine Types: tajno oružje za right-sizing

Ovo je, po mom mišljenju, jedna od najboljih stvari na GCP-u za optimizaciju troškova. Umjesto da birate između fiksnih veličina (2 vCPU / 8 GB, 4 vCPU / 16 GB i tako dalje), možete definirati točno koliko vam treba — recimo, 4 vCPU i 10 GB memorije.

To znači da ne plaćate 16 GB kad vam zapravo treba samo 10. Razlika se brzo akumulira na desetke ili stotine instanci.

# Kreiranje instance s prilagođenom konfiguracijom
gcloud compute instances create web-server-prod \
  --zone=europe-west3-a \
  --custom-cpu=4 \
  --custom-memory=10240MB \
  --image-family=debian-12 \
  --image-project=debian-cloud

# Za radna opterećenja koja trebaju više memorije po vCPU-u (>6.5 GB/vCPU)
gcloud compute instances create db-server \
  --zone=europe-west3-a \
  --custom-cpu=2 \
  --custom-memory=26624MB \
  --custom-extensions \
  --image-family=debian-12 \
  --image-project=debian-cloud

Automatizacija right-sizinga s Terraformom

Ručno mijenjanje tipova instanci funkcionira dok imate par servera. Ali kad upravljate s desetcima ili stotinama instanci, to postaje nemoguće. Tu na scenu stupa Terraform.

AWS primjer s Terraformom

# variables.tf — centralizirano upravljanje tipovima instanci
variable "instance_configs" {
  description = "Konfiguracija instanci nakon right-sizing analize"
  type = map(object({
    instance_type = string
    name          = string
  }))
  default = {
    web_server = {
      instance_type = "m7g.large"    # Prethodno: m5.xlarge
      name          = "web-server"
    }
    api_server = {
      instance_type = "c7g.medium"   # Prethodno: c5.large
      name          = "api-server"
    }
    worker = {
      instance_type = "t4g.medium"   # Prethodno: t3.large
      name          = "worker"
    }
  }
}

# main.tf
resource "aws_instance" "servers" {
  for_each = var.instance_configs

  ami           = data.aws_ami.latest_al2023.id
  instance_type = each.value.instance_type

  tags = {
    Name        = each.value.name
    Environment = "production"
    ManagedBy   = "terraform"
    LastRightSized = timestamp()
  }
}

Azure primjer s Terraformom

resource "azurerm_linux_virtual_machine" "app_server" {
  name                = "app-server-prod"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location

  # Nakon right-sizing analize: Standard_D4s_v3 -> Standard_B2ms
  size = "Standard_B2ms"

  admin_username = "adminuser"

  network_interface_ids = [
    azurerm_network_interface.main.id,
  ]

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "StandardSSD_LRS"
  }

  tags = {
    environment    = "production"
    last_rightsized = "2026-03-02"
  }
}

Migracija na ARM arhitekturu: Graviton, Cobalt i Axion

Right-sizing ne znači samo smanjivanje instanci. Znači i odabir prave arhitekture procesora. A u 2026., ARM-bazirani procesori nude znatno bolji omjer cijene i performansi od tradicionalnih x86 čipova.

AWS Graviton

AWS Graviton instance koštaju do 20% manje od usporedivog x86 tipa, a često isporučuju i 25% bolje performanse. Najnoviji Graviton4 donosi preko 30% brže performanse od Graviton3, s 50% više jezgri i 75% više memorijske propusnosti. Prema Gartneru, ARM instance će do kraja 2026. činiti 25% svih cloud compute resursa — i taj trend samo raste.

Prepoznajete ih po slovu g u nazivu tipa — m7g.large je Graviton verzija m7i.large. Dobra vijest: preko 95% modernih aplikacija radi na Gravitonu bez ikakvih modifikacija.

Azure Cobalt

Microsoft je lansirao Cobalt 100 ARM procesore za Azure, s do 20% boljim omjerom cijene i performansi za web servere, aplikacijske servere i kontejnerske workloadove. Dostupni su kroz Dpsv6 i Epsv6 seriju VM-ova.

GCP Axion

Google je predstavio Axion procesore bazirane na ARM arhitekturi — do 30% bolje performanse i 50% bolja energetska učinkovitost od usporedivih x86 VM-ova. Nalaze se u C4A seriji VM-ova.

Moj praktični savjet za migraciju: počnite s razvojnim okruženjima i CI/CD pipelineima. Ako sve radi bez problema (a u velikoj većini slučajeva hoće), prebacite staging, pa onda produkciju. Lambda funkcije, Cloud Functions i kontejnerizirane aplikacije su najlakše za migraciju jer ne ovise o specifičnoj procesorskoj arhitekturi.

Skripta za automatsko otkrivanje prekodimenzioniranih instanci

Evo Bash skripte koja koristi AWS CLI za brzo identificiranje EC2 instanci s prosječnim korištenjem CPU-a ispod 20%. To su idealni kandidati za right-sizing — instance koje doslovno većinu vremena ne rade ništa korisno:

#!/bin/bash
# right-size-scan.sh — Identificira prekodimenzioniranje EC2 instance
# Korištenje: ./right-size-scan.sh [region] [prag-cpu-postotak]

REGION=${1:-eu-central-1}
CPU_THRESHOLD=${2:-20}
DAYS_BACK=14

echo "Skeniram EC2 instance u regiji: $REGION"
echo "Prag CPU korištenja: ${CPU_THRESHOLD}%"
echo "Period analize: zadnjih $DAYS_BACK dana"
echo "==========================================="

START_TIME=$(date -u -v-${DAYS_BACK}d +"%Y-%m-%dT%H:%M:%SZ" 2>/dev/null || \
             date -u -d "$DAYS_BACK days ago" +"%Y-%m-%dT%H:%M:%SZ")
END_TIME=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

# Dohvati sve running instance
INSTANCES=$(aws ec2 describe-instances \
  --region "$REGION" \
  --filters "Name=instance-state-name,Values=running" \
  --query "Reservations[].Instances[].[InstanceId,InstanceType,Tags[?Key=='Name'].Value|[0]]" \
  --output text)

echo "$INSTANCES" | while read -r INSTANCE_ID INSTANCE_TYPE INSTANCE_NAME; do
  # Dohvati prosječno CPU korištenje
  AVG_CPU=$(aws cloudwatch get-metric-statistics \
    --region "$REGION" \
    --namespace AWS/EC2 \
    --metric-name CPUUtilization \
    --dimensions Name=InstanceId,Value="$INSTANCE_ID" \
    --start-time "$START_TIME" \
    --end-time "$END_TIME" \
    --period 86400 \
    --statistics Average \
    --query "sort_by(Datapoints,&Timestamp)[-1].Average" \
    --output text 2>/dev/null)

  if [ "$AVG_CPU" != "None" ] && [ -n "$AVG_CPU" ]; then
    CPU_INT=${AVG_CPU%%.*}
    if [ "$CPU_INT" -lt "$CPU_THRESHOLD" ]; then
      printf "%-20s %-15s %-25s CPU: %.1f%%  ← KANDIDAT\n" \
        "$INSTANCE_ID" "$INSTANCE_TYPE" "${INSTANCE_NAME:-N/A}" "$AVG_CPU"
    fi
  fi
done

echo "==========================================="
echo "Gotovo. Za detaljne preporuke pokrenite:"
echo "aws compute-optimizer get-ec2-instance-recommendations --region $REGION"

Raspored right-sizing procesa: mjesečni ciklus

Right-sizing nije nešto što napravite jednom i zaboravite — to je kontinuirani proces. Evo mjesečnog ciklusa koji je po mom iskustvu najbolje funkcionirao:

  1. Tjedan 1 — Prikupljanje i analiza: Pregledajte preporuke iz Compute Optimizera, Azure Advisora i GCP Recommendera. Identificirajte top 10 instanci s najvećim potencijalom uštede.
  2. Tjedan 2 — Validacija: Za svaku identificiranu instancu provjerite metrike za duži period (30+ dana). Razgovarajte s vlasnicima aplikacija o predstojećim promjenama u opterećenju — ovo je korak koji se najčešće preskače, a ne bi se smio.
  3. Tjedan 3 — Implementacija: Primijenite promjene u kontroliranom prozoru održavanja. Počnite s instancama niskog rizika. Ažurirajte Terraform konfiguracije da odražavaju nove veličine.
  4. Tjedan 4 — Praćenje i izvještavanje: Pratite metriku optimiziranih instanci. Dokumentirajte ostvarene uštede. Pripremite izvještaj za sljedeći ciklus.

Što right-sizati prije kupnje reserved instanci

Ovo je kritično pravilo koje previše timova ignorira: uvijek napravite right-sizing prije nego kupite reserved instance ili savings plan. Ako se obvežete na jednu do tri godine plaćanja za m5.xlarge, a stvarno vam treba samo m7g.large, upravo ste zaključali preplaćivanje na godinu ili duže. Boli samo kad pogledate koliko se to akumulira.

Ispravan redoslijed optimizacije izgleda ovako:

  1. Očistite: Ugasite nekorištene resurse i izbrišite zombie instance (svi ih imamo).
  2. Right-sizajte: Uskladite veličinu preostalih instanci sa stvarnim opterećenjem.
  3. Modernizirajte: Prebacite se na najnoviju generaciju instanci — Graviton, Cobalt, Axion.
  4. Obvežite se: Tek sada kupite reserved instance ili savings plan za optimizirane resurse.
  5. Dopunite: Koristite spot instance za varijabilna opterećenja.

Svaki korak gradi na prethodnom, a ukupna ušteda je značajno veća nego kad se koraci rade izolirano ili pogrešnim redoslijedom.

Često postavljana pitanja

Koliko često treba provoditi right-sizing?

Minimalno jednom mjesečno. Radna opterećenja se stalno mijenjaju — aplikacije dobivaju nove značajke, promet raste ili opada sezonski, a cloud provideri redovito izdaju nove tipove instanci s boljim omjerom cijene i performansi. Po mojim iskustvima, timovi koji provode right-sizing mjesečno troše 20 do 40% manje od onih koji to rade jednom godišnje.

Je li right-sizing rizičan za produkcijske servere?

Ne, ako se radi kako treba. Analizirajte metrike za barem 30 dana, počnite s instancama koje koriste manje od 40% resursa, primijenite promjenu u kontroliranom prozoru održavanja i pratite performanse 48 sati nakon promjene. I bitno — uvijek ostavite marginu od 30 do 40%. Nemojte dimenzionirati instance na 100% prosječnog korištenja jer će vam prvi spike u prometu napraviti problem.

Trebam li right-sizati prije ili nakon kupnje reserved instanci?

Uvijek prije. Ako kupite reserved instance za predimenzionirani tip, zaključali ste se na plaćanje viška na jednu do tri godine. Redoslijed bi trebao biti: ugasite nekorišteno, right-sizajte, modernizirajte na najnoviju generaciju, pa tek onda kupite obvezujuće popuste.

Koji alati su besplatni za right-sizing?

Sva tri velika providera nude besplatne nativne alate: AWS Compute Optimizer (osnovni tier), Azure Advisor i GCP Recommender. Za većinu organizacija, ovi alati pokrivaju osnovne potrebe sasvim solidno. Za naprednije scenarije — multi-cloud okruženja, detaljniju analizu memorije ili automatsku primjenu preporuka — postoje plaćeni alati poput Hyperglance, Sedai ili nOps.

Koja je razlika između right-sizinga i auto-scalinga?

Right-sizing optimizira baznu veličinu instance — osigurava da imate pravi tip za vaše opterećenje. Auto-scaling dodaje ili uklanja instance prema trenutnom prometu. Idealno je koristiti oboje: right-sizing za baznu konfiguraciju, auto-scaling za prilagodbu varijabilnim opterećenjima. Zajedno, te dvije strategije mogu smanjiti troškove i za 30 do 50%.

O Autoru Editorial Team

Our team of expert writers and editors.

Povezani Članci