Migracija AWS EBS volumena s gp2 na gp3 u 2026. donosi 20% uštede na cijeni po GB-mjesecu (iz $0.10 na $0.08 u us-east-1) uz zadržavanje ili poboljšanje performansi za većinu radnih opterećenja. Prijelaz se izvodi bez downtime-a putem modify-volume API poziva, a AWS Compute Optimizer već označava vaše kandidate. Za tipičan portfelj od 500 TB gp2 volumena to znači oko $12.000 godišnje uštede, bez ijedne migracije podataka i bez restarta instance.
gp3 stoji $0.08 po GB-mjesecu naspram $0.10 za gp2 u us-east-1, dakle 20% jeftinije za identičnu količinu.
Svaki gp3 volumen dobiva bazu od 3.000 IOPS i 125 MB/s throughputa, neovisno o veličini.
Migracija je online: aws ec2 modify-volume --volume-type gp3 pokreće se bez detachanja.
Ako gp2 volumen radi ispod baze gp3, uštedu možete povećati čak i preko 20% otkazivanjem provisioned IOPS-a.
Compute Optimizer generira listu kandidata s procijenjenom mjesečnom uštedom. Koristite ga kao ulazni signal, ne kao final policy.
Snapshot cijene ostaju iste. Migracija ne utječe na $0.05/GB-mjesec za standardni EBS Snapshot.
gp2 vs gp3: što se točno promijenilo
AWS je gp3 lansirao krajem 2020., a u 2026. je i dalje najisplativija general-purpose SSD opcija za većinu EC2, RDS i EKS radnih opterećenja. Iskreno, ne sjećam se kad sam zadnji put klijentu preporučio gp2 za nešto novo. Ključna razlika izgleda ovako: kod gp2 IOPS je linearno vezan uz veličinu (3 IOPS/GB, s burst kreditima za male volumene), pa da bi 100 GB volumen dobio 3.000 IOPS morate ga naduvati na 1.000 GB. Kod gp3, svaki volumen (bez obzira je li 1 GB ili 16 TB) dolazi s 3.000 IOPS-a i 125 MB/s throughputa u startu. Dodatne IOPS ($0.005 po IOPS-mjesecu iznad 3.000) i throughput ($0.04 po MB/s iznad 125) plaćate zasebno.
U praksi to znači tri stvari. Prvo, storage i performance su razdvojeni, pa više ne morate over-provisionirati kapacitet samo da bi dobili IOPS. Drugo, mali root volumeni na EC2 instancama (najčešće 8–30 GB) sada rade puno brže "for free", jer 3 IOPS/GB kod gp2 znači samo 24 IOPS bazno za 8 GB, dok gp3 daje 3.000. Treće, cijena po GB-mjesecu je 20% niža u svakoj komercijalnoj regiji: us-east-1 ide s $0.10 na $0.08, eu-west-1 s $0.11 na $0.088, ap-southeast-1 s $0.12 na $0.096. Novi službeni gp3 pricing page uvijek pokazuje aktualne brojke po regiji.
Kako izračunati uštedu po SKU-u
Za tipični gp2 volumen kalkulacija je trivijalna: cijena × 0.8. Ali stvarna slika je zanimljivija kad uzmete u obzir bazne performanse gp3. Pogledajmo tri realna scenarija u us-east-1.
Scenario A, 500 GB gp2 root volumen za produkcijsku bazu: gp2 baseline = 1.500 IOPS. Košta 500 × $0.10 = $50/mjesec. Migracijom na gp3 pri istoj veličini plaćate 500 × $0.08 = $40/mjesec, a dobivate 3.000 IOPS-a i 125 MB/s. Ušteda: $10/mjesec (20%) uz duplo bolje performanse.
Scenario B, 100 GB gp2 volumen koji je "napuhan" da bi dobio 3.000 IOPS: Ako ste povećali kapacitet s 50 na 100 GB (i dalje ispod 3.000 IOPS baseline gp2), plaćate $10/mjesec. gp3 s 100 GB je $8, ali sada možete smanjiti kapacitet natrag na potrebnih 50 GB → $4/mjesec. Ušteda: $6/mjesec (60%).
Scenario C, 4 TB gp2 s traženih 10.000 IOPS: gp2 baseline je 4 × 3.000 = 12.000 IOPS, cijena $409.60. gp3 s 4 TB i +7.000 provisioned IOPS iznad baze: (4.000 × $0.08) + (7.000 × $0.005) = $320 + $35 = $355. Ušteda: $54.60/mjesec (~13%). Manje od 20%, ali još uvijek bez rizika.
Za portfolio-level procjenu koristim sljedeći SQL nakon što ubacim describe-volumes output u DuckDB ili Athena tablicu: SELECT SUM(size_gb * 0.10 - size_gb * 0.08) AS monthly_savings FROM ebs_volumes WHERE volume_type = 'gp2';. Kod klijenata s 200-500 TB gp2 flote ta jedna linija tipično prikaže $3.000–$8.000 mjesečnog waste-a. Kada dodam Scenario B tip situacija (napuhane volumene za IOPS), broj poraste za dodatnih 15–25%. Mali savjet iz iskustva: predstavite uštedu kao godišnji broj (× 12) jer je vizualno znatno veći i lakše dobiva sponzorstvo migracije od CFO-a nego mjesečna brojka. Prošla mi je istaknuto brže odobrenje čim smo prešli s "$8k mjesečno" na "$96k godišnje", iako je to matematički isto.
Jedan detalj koji se često previdi: gp3 IOPS iznad 3.000 se ne naplaćuju linearno. Cijena je $0.005 po IOPS-u samo iznad baseline-a. Ako trebate točno 3.000 IOPS, plaćate 0 dolara za performance dodatak. gp2 nema ekvivalent tog "free tier" ponašanja jer je baseline vezan uz veličinu.
Kada migrirati (i kada NE)
Ne postoji radno opterećenje na gp2 koje ne biste trebali barem procijeniti za gp3, ali ima nekoliko slučajeva kada je odgovor "još ne". Migrirajte odmah ako: (1) volumen radi steady-state ispod 3.000 IOPS-a i 125 MB/s, (2) koristite malu (<500 GB) root partiticiju gdje gp2 baseline nikad nije dovoljan, ili (3) volumen nikad ne "burshtira" (Burst Balance metric u CloudWatchu ostaje na 100%).
Pričekajte s migracijom ako: (1) volumen ovisi o gp2 burst kreditima za povremene spike-ove i njegov Burst Balance redovito pada ispod 50%, jer gp3 nema burst i sve što dobijete je provisioned, (2) koristite EBS Multi-Attach koji na gp3 nije podržan (samo io1/io2), ili (3) imate legacy AMI-je koji se buildaju samo za gp2 tip u svojoj Launch Template konfiguraciji. Za tu treću stavku fix je banalan (promjena VolumeType u Launch Templateu), ali zahtijeva rebuild pipeline test.
Prilikom procjene, poveznica s right-sizing cloud instanci na AWS-u i Azureu je korisna: ako mijenjate instance tip za CPU/RAM optimizaciju, iskoristite isti maintenance prozor i za gp3 prelazak.
Praktični koraci: modify-volume workflow
Migracija je online i ne zahtijeva reboot instance. Elastic Volumes značajka radi pod haubom (AWS pod-block-copy podataka odvija u pozadini). Vrijeme "optimizing" faze je oko 6 sati na TB, ali volumen je operativan cijelo vrijeme. Prvi put kad sam ovo pokrenuo, bio sam iznenađen koliko je proces "boring" na najbolji mogući način: pokreneš, gledaš progress bar, i to je to.
Stanje prolazi kroz modifying → optimizing → completed. Sam modifying traje minute, dok je optimizing pozadinski proces koji ne utječe na dostupnost. Volumen se naplaćuje po gp3 cijeni čim uđe u optimizing. Detalje sekvence pokriva službena AWS dokumentacija za modify-volume.
Compute Optimizer preporuke za EBS
AWS Compute Optimizer besplatno analizira 14 dana CloudWatch metrika (VolumeReadOps, VolumeWriteOps, VolumeReadBytes, VolumeWriteBytes) i generira preporuke za EBS volumene. Preporuke uključuju procijenjenu mjesečnu uštedu, ciljani tip volumena, IOPS i throughput konfiguraciju. Aktivacija: konzola → Compute Optimizer → Opt in za EBS. Podaci se pojavljuju nakon 14 dana promatranja.
Kad Compute Optimizer označi volumen kao Overprovisioned, obično predlaže smanjenje IOPS-a ili prijelaz na jeftiniju obitelj. U praksi: 60–80% gp2 volumena završi s preporukom "prebaci na gp3 uz iste ili niže performance parametre". Za širi kontekst kako spajati Compute Optimizer s ostalim AWS alatima, pogledajte naš vodič o automatskoj detekciji i čišćenju neiskorištenih cloud resursa.
Automatizacija migracije preko skripte
Za portfelje s više od 20-30 volumena ručna migracija nema smisla. Sljedeća Bash skripta prolazi kroz sve gp2 volumene u regiji, filtrira ih po tagu Migrate-to-gp3=true (siguran opt-in pattern) i migrira ih uz rate limiting. Ovakvu skriptu držim u repozitoriju već dvije godine i preživjela je više refactoringa nego bilo koji Terraform modul.
#!/usr/bin/env bash
# migrate-gp2-to-gp3.sh
# Zahtijeva: aws cli v2, jq
set -euo pipefail
REGION="${REGION:-us-east-1}"
TAG_KEY="Migrate-to-gp3"
TAG_VALUE="true"
BATCH_DELAY=5
echo "Tražim gp2 volumene s tagom ${TAG_KEY}=${TAG_VALUE} u ${REGION}..."
VOLUMES=$(aws ec2 describe-volumes \
--region "$REGION" \
--filters \
"Name=volume-type,Values=gp2" \
"Name=tag:${TAG_KEY},Values=${TAG_VALUE}" \
--query "Volumes[*].VolumeId" \
--output text)
if [ -z "$VOLUMES" ]; then
echo "Nema kandidata."
exit 0
fi
for VOL in $VOLUMES; do
echo "Migriram $VOL → gp3..."
aws ec2 modify-volume \
--region "$REGION" \
--volume-id "$VOL" \
--volume-type gp3 \
--output json | jq '.VolumeModification | {VolumeId, ModificationState, TargetVolumeType}'
sleep "$BATCH_DELAY"
done
echo "Gotovo. Prati napredak s: aws ec2 describe-volumes-modifications"
Kada io2 Block Express pobjeđuje gp3
gp3 ima gornji limit od 16.000 IOPS i 1.000 MB/s po volumenu. Za većinu OLTP baza to je dovoljno, ali high-performance workloadovi (SAP HANA, Oracle RAC, veliki Redshift clusteri) prelaze te brojke. Tu ulazi io2 Block Express: do 256.000 IOPS, 4.000 MB/s throughputa i 99.999% durability. Cijena je ~2× gp3 po GB, ali kada trebate sub-milisekundnu latenciju i preko 20.000 IOPS, gp3 s provisioned dodacima izlazi skuplji od io2 u većini kalkulacija.
Empirijski threshold koji koristim za odluku: ako trebate više od 16.000 IOPS-a ili trajno više od 700 MB/s, idite direktno na io2 Block Express i preskočite gp3. Ispod tih brojki gp3 gotovo uvijek pobjeđuje. Za kombinaciju s Reserved Instances i Savings Plans obvezujućim popustima, imajte na umu da EBS trošak nije pokriven Savings Planovima (samo compute), pa je gp3 optimizacija komplementarna, ne konkurirajuća ušteda.
Još jedan slučaj kada gp3 nije dobar izbor: NVMe instance store zamjena. Ako trenutno koristite lokalne NVMe diskove (i3, i4i, im4gn familije) za low-latency workload, prelazak na bilo koji EBS tip donosi ~10× lošiju latenciju. Odgovor tu nije gp3 već ponovno razmišljanje o arhitekturi, često cachiranje pred bazom ili prijelaz na Aurora Serverless. Za taj širi kontekst korisno je paralelno optimizirati troškove upravljanih baza podataka, jer sinkroniziranje maintenance prozora dva optimizacijska pravca smanjuje broj downtime prozora u tromjesečju.
AWS je u kolovozu 2026. relaksirao ograničenje: gp3 sada podržava do 64 TB po volumenu (ranije 16 TB), što znači da je za većinu data lake workloadova gp3 postao izvediv i tamo gdje je prije io2 bio jedina opcija. Vidjeti AWS Storage blog o migraciji gp2 na gp3 za detalje.
Usporedna tablica EBS tipova (us-east-1, 2026.)
Karakteristika
gp2
gp3
io2 Block Express
Cijena po GB-mjesecu
$0.10
$0.08
$0.125
Baseline IOPS
3 IOPS/GB (min 100, max 16.000)
3.000 (fiksno)
Provisioned (do 256.000)
Max throughput
250 MB/s
1.000 MB/s
4.000 MB/s
IOPS cijena iznad baze
N/A
$0.005/IOPS-mjesec
$0.065/IOPS-mjesec (do 32k), potom niže
Durability
99.8-99.9%
99.8-99.9%
99.999%
Multi-Attach podrška
Ne
Ne
Da
Tipičan use case
Legacy, migrirati
General purpose, root volumeni
Enterprise baze, SAP HANA
Česta pitanja
Trebam li reboot EC2 instance nakon migracije s gp2 na gp3?
Ne. Elastic Volumes značajka omogućava online promjenu tipa bez detachanja ili reboota. Volumen ostaje dostupan cijelo vrijeme dok AWS obavlja pozadinsku optimizaciju.
Utječe li migracija na EBS snapshotove?
Ne. Postojeći snapshotovi ostaju važeći i naplaćuju se po istoj cijeni ($0.05 po GB-mjesecu za standardne snapshotove). Novi snapshotovi kreirani nakon migracije rade identično neovisno o tipu source volumena.
Mogu li se vratiti s gp3 na gp2 ako nešto pođe po zlu?
Da. Isti modify-volume API prihvaća --volume-type gp2. Rollback je online kao i forward migracija, ali morate pričekati 6 sati od zadnje izmjene istog volumena.
Da li Compute Optimizer preporuke za EBS nešto koštaju?
Osnovna razina Compute Optimizera je besplatna, uključujući EBS volume recommendations. Enhanced infrastructure metrics (do 3 mjeseca povijesti) su plaćene opcije, ali za gp2→gp3 odluku bazna razina je više nego dovoljna.
Radi li migracija na gp3 za root volumene Windows i Linux EC2 instanci?
Da, za oba. Jedina caveat: Launch Templateovi i AMI blueprint definicije koji explicit-no navode gp2 tip trebaju biti ažurirani da nove instance startaju direktno kao gp3, inače ostaju u istom loopu.
Vodič za smanjenje NAT Gateway troškova na AWS-u, Azureu i GCP-u u 2026.: VPC Endpointi, Private Google Access, tagging i konkretni Terraform/CLI primjeri koji smanjuju račun za 40 do 70%.
Praktični vodič za 2026.: kako smo srezali troškove upravljanih baza (RDS, Aurora, Azure SQL, Cloud SQL) između 35% i 62%. Right-sizing, Reserved Instances, Aurora Serverless v2, Azure Hybrid Benefit, backup lifecycle i konkretni brojevi po instanci.
Praktični vodič za smanjenje troškova cloud logova na AWS CloudWatch, Azure Log Analytics i Google Cloud Logging: tier-ovi, filteri, retencija i OpenTelemetry primjer koji sam koristio u produkciji.