Memilih antara EBS gp2 dan gp3: Skalabilitas IOPS dan Efisiensi Biaya

Saat menyiapkan volume EBS untuk instance EC2, banyak engineer terjebak di layar pemilihan tipe volume dan bertanya-tanya: apa bedanya gp2 dan gp3 secara nyata, dan mana yang lebih masuk akal untuk workload produksi? Pertanyaan ini bukan soal preferensi — ada perbedaan arsitektur mendasar yang langsung berdampak pada biaya dan perilaku performa di bawah beban tinggi.

TL;DR: Perbandingan Cepat gp2 vs gp3

Aspek gp2 gp3
Model IOPS Terikat ukuran volume (3 IOPS/GB) Independen dari ukuran volume
IOPS Dasar Minimum 100, maksimum 16.000 3.000 IOPS tanpa biaya tambahan
Throughput Dasar Hingga 250 MiB/s 125 MiB/s default, dapat ditingkatkan ke 1.000 MiB/s
Burst IOPS Ada (bucket kredit), hingga 3.000 IOPS Tidak ada mekanisme burst — performa konsisten
Biaya Umum Lebih mahal per GB untuk volume kecil Umumnya lebih hemat ~20% dibanding gp2
Rekomendasi AWS Legacy, masih didukung Tipe default yang direkomendasikan

Cara Kerja gp2 dan gp3: Fondasi Arsitektur

Sebelum memilih, penting memahami mengapa kedua tipe ini berperilaku berbeda — bukan hanya apa yang berbeda.

Model Performa gp2: Terikat Ukuran Volume

gp2 menggunakan model di mana IOPS yang tersedia dihitung langsung dari ukuran volume: 3 IOPS per GB, dengan batas bawah 100 IOPS dan batas atas 16.000 IOPS. Artinya, volume 100 GB hanya mendapat 300 IOPS dasar. Untuk mendapat 16.000 IOPS, volume harus berukuran minimal ~5.334 GB.

Di atas angka dasar itu, gp2 memiliki mekanisme burst berbasis I/O credit bucket. Ketika volume tidak digunakan penuh, kredit terakumulasi. Saat beban melonjak, kredit dipakai untuk mencapai hingga 3.000 IOPS sementara. Masalahnya: jika kredit habis dan ukuran volume kecil, performa turun drastis ke angka dasar tanpa peringatan eksplisit di level aplikasi.

Model Performa gp3: Independen dan Deterministik

gp3 memisahkan kapasitas penyimpanan dari performa. Setiap volume gp3 mendapat 3.000 IOPS dan 125 MiB/s throughput secara default, terlepas dari ukurannya — bahkan volume 1 GB sekalipun. IOPS dapat ditingkatkan hingga 16.000 dan throughput hingga 1.000 MiB/s dengan konfigurasi eksplisit dan biaya tambahan per unit.

Tidak ada mekanisme burst. Performa yang dikonfigurasi adalah performa yang diterima — konsisten dan dapat diprediksi.

graph TD subgraph GP2["gp2: IOPS Terikat Ukuran"] A["Volume 100 GB"] -->|"3 IOPS/GB"| B["300 IOPS Dasar"] B --> C{"Burst Kredit Tersedia?"} C -->|"Ya"| D["Hingga 3.000 IOPS (sementara)"] C -->|"Kredit Habis"| E["Kembali ke 300 IOPS"] E --> F["Latensi Meningkat Tanpa Error Log"] end subgraph GP3["gp3: IOPS Independen"] G["Volume 100 GB"] --> H["3.000 IOPS Default (semua ukuran)"] H --> I{"Butuh Lebih?"} I -->|"Ya"| J["Konfigurasi Eksplisit hingga 16.000 IOPS"] I -->|"Tidak"| K["3.000 IOPS Konsisten Tanpa Burst"] end
  1. gp2 (kiri): IOPS terikat langsung ke ukuran volume. Volume kecil mendapat IOPS rendah. Burst tersedia tapi bergantung pada kredit yang terakumulasi saat idle.
  2. gp3 (kanan): 3.000 IOPS tersedia untuk semua ukuran volume secara default. IOPS dan throughput dapat dikonfigurasi secara independen tanpa mengubah ukuran volume.
  3. Titik kritis gp2: Ketika I/O credit habis pada volume kecil, performa turun ke angka dasar — ini sering menjadi sumber latensi tak terduga di produksi.

Mengapa gp3 Umumnya Lebih Murah untuk Sebagian Besar Workload

Pola umum yang sering terjadi: tim DevOps memperbesar volume gp2 bukan karena butuh ruang, tapi karena butuh IOPS lebih tinggi. Volume 500 GB diprovisikan bukan karena data sebesar itu, melainkan karena 1.500 IOPS yang dibutuhkan. Ini adalah pemborosan biaya yang langsung.

Dengan gp3, IOPS dan throughput dikonfigurasi secara eksplisit. Anda bisa memiliki volume 50 GB dengan 6.000 IOPS tanpa harus memperbesar kapasitas penyimpanan. Biaya per GB gp3 juga lebih rendah dari gp2 — selisihnya bervariasi per region, tapi secara konsisten gp3 lebih hemat untuk konfigurasi yang setara.

Bayangkan gp2 seperti paket internet lama yang kecepatannya ditentukan oleh berapa banyak kuota bulanan yang Anda beli — mau kecepatan tinggi, beli kuota lebih banyak. gp3 seperti paket modern: pilih kecepatan dan kapasitas secara terpisah.

Pricing dan kuota spesifik berubah per region dan waktu — selalu verifikasi di halaman harga resmi AWS EBS.

Kapan gp2 Masih Relevan

Jujur saja: untuk workload baru, hampir tidak ada alasan teknis memilih gp2 hari ini. Tapi ada skenario di mana gp2 tetap ada di infrastruktur:

  • Volume legacy yang sudah berjalan stabil — migrasi ke gp3 membutuhkan modifikasi volume yang, meski online, tetap memiliki risiko operasional kecil.
  • Automation atau IaC lama yang hardcode tipe volume dan belum diperbarui.
  • Workload dengan pola I/O sangat rendah di mana burst gp2 sudah cukup dan tidak ada insentif biaya signifikan untuk migrasi.

Di luar skenario itu, gp3 adalah pilihan default yang lebih masuk akal.

Mengonfigurasi dan Memigrasikan Volume EBS ke gp3

Modifikasi volume EBS dari gp2 ke gp3 dapat dilakukan secara online tanpa downtime menggunakan Elastic Volumes. Volume tetap tersedia selama proses modifikasi berlangsung.

Memeriksa Tipe Volume yang Sedang Berjalan

aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[*].{VolumeId:VolumeId,Size:Size,Iops:Iops,Type:VolumeType}' \
  --output table \
  --region us-east-1

Perintah ini menampilkan semua volume gp2 aktif di region, lengkap dengan ukuran dan IOPS yang dikonfigurasi — titik awal yang baik sebelum merencanakan migrasi batch.

Memodifikasi Volume gp2 ke gp3

aws ec2 modify-volume \
  --volume-id vol-0123456789abcdef0 \
  --volume-type gp3 \
  --iops 3000 \
  --throughput 125 \
  --region us-east-1

Parameter --iops dan --throughput di sini menggunakan nilai default gp3. Jika workload membutuhkan lebih, naikkan angkanya sesuai kebutuhan terukur — bukan estimasi.

Memantau Status Modifikasi

aws ec2 describe-volumes-modifications \
  --volume-ids vol-0123456789abcdef0 \
  --query 'VolumesModifications[*].{VolumeId:VolumeId,State:ModificationState,Progress:Progress}' \
  --output table \
  --region us-east-1

Status akan bergerak dari modifying ke optimizing lalu completed. Volume tetap dapat digunakan selama seluruh proses ini.

Mengonfigurasi gp3 dengan IOPS Kustom Saat Membuat Volume Baru

aws ec2 create-volume \
  --availability-zone us-east-1a \
  --volume-type gp3 \
  --size 100 \
  --iops 6000 \
  --throughput 250 \
  --region us-east-1
graph LR A["Identifikasi Volume gp2 describe-volumes"] --> B["Jalankan modify-volume ke gp3"] B --> C["Status: modifying"] C --> D["Status: optimizing"] D --> E["Status: completed"] E --> F["Verifikasi Performa CloudWatch Metrics"] B -.->|"Volume tetap online selama proses"| G["Instance EC2 Tetap Berjalan"]
  1. Identifikasi volume gp2 menggunakan describe-volumes dengan filter tipe.
  2. Jalankan modify-volume — proses dimulai secara asinkron, volume tetap online.
  3. Monitor status dengan describe-volumes-modifications hingga state completed.
  4. Verifikasi performa menggunakan CloudWatch metric VolumeReadOps dan VolumeWriteOps setelah modifikasi selesai.

Pengalaman Lapangan: Misdiagnosis yang Umum Terjadi

Skenario yang sering muncul di produksi: database query yang biasanya selesai dalam 50ms tiba-tiba naik ke 800ms secara intermiten, tanpa perubahan kode atau data. CloudWatch menunjukkan CPU normal, memory normal. Tim mulai curiga ke query plan atau network latency.

Setelah investigasi lebih dalam, penyebabnya adalah volume gp2 berukuran 200 GB yang mendapat 600 IOPS dasar. Selama jam sibuk, I/O credit habis dan performa turun ke angka dasar itu. Tidak ada alarm yang terpicu karena tidak ada threshold yang dikonfigurasi untuk BurstBalance metric di CloudWatch.

Solusinya bukan optimasi query — tapi migrasi ke gp3 dengan 3.000 IOPS konsisten. Latensi kembali normal dan stabil. Pelajarannya: gp2 burst depletion tidak meninggalkan error log di level aplikasi — yang terlihat hanya latensi tinggi yang tampak acak.

Untuk menghindari ini, pantau metric BurstBalance pada semua volume gp2 yang masih berjalan:

aws cloudwatch get-metric-statistics \
  --namespace AWS/EBS \
  --metric-name BurstBalance \
  --dimensions Name=VolumeId,Value=vol-0123456789abcdef0 \
  --start-time 2024-01-01T00:00:00Z \
  --end-time 2024-01-02T00:00:00Z \
  --period 300 \
  --statistics Average \
  --region us-east-1

Jika nilai BurstBalance konsisten di bawah 20%, volume itu adalah kandidat migrasi ke gp3 dengan prioritas tinggi.

IAM Policy untuk Operasi Modifikasi Volume EBS

Engineer yang menjalankan operasi modifikasi volume membutuhkan izin eksplisit. Berikut policy dengan prinsip least privilege untuk operasi ini:

🔽 Klik untuk melihat IAM Policy 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DescribeEBSVolumes",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeVolumes",
        "ec2:DescribeVolumesModifications"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ModifyEBSVolumes",
      "Effect": "Allow",
      "Action": "ec2:ModifyVolume",
      "Resource": "arn:aws:ec2:us-east-1:123456789012:volume/*"
    },
    {
      "Sid": "CloudWatchEBSMetrics",
      "Effect": "Allow",
      "Action": "cloudwatch:GetMetricStatistics",
      "Resource": "*"
    }
  ]
}

Catatan: ec2:DescribeVolumes dan ec2:DescribeVolumesModifications adalah Read/List actions yang memerlukan "Resource": "*" karena tidak mendukung resource-level permission. Verifikasi di AWS Service Authorization Reference untuk konfirmasi terkini.

Memilih gp2 vs gp3: Panduan Keputusan

graph TD START(["Volume EBS Baru atau Migrasi?"]) START --> Q1{"Volume Baru?"} Q1 -->|"Ya"| REC1["Gunakan gp3 ✓ Rekomendasi Default"] Q1 -->|"Tidak, gp2 Existing"| Q2{"Ukuran < 334 GB dan butuh > 1.000 IOPS?"} Q2 -->|"Ya"| REC2["Migrasi ke gp3 Prioritas Tinggi"] Q2 -->|"Tidak"| Q3{"BurstBalance konsisten < 20%?"} Q3 -->|"Ya"| REC3["Migrasi ke gp3 Segera"] Q3 -->|"Tidak"| Q4{"Latensi Intermiten Tak Terjelaskan?"} Q4 -->|"Ya"| REC4["Periksa BurstBalance lalu Migrasi ke gp3"] Q4 -->|"Tidak"| REC5["Rencanakan Migrasi ke gp3 Bertahap"]
  1. Volume baru — selalu mulai dengan gp3 sebagai default.
  2. Volume gp2 kecil (<334 GB) dengan kebutuhan IOPS >1.000 — kandidat migrasi prioritas tinggi karena gp3 memberi 3.000 IOPS tanpa biaya tambahan.
  3. Volume gp2 besar dengan BurstBalance stabil di atas 80% — migrasi tetap direkomendasikan untuk konsistensi performa, tapi urgensinya lebih rendah.
  4. Workload dengan latensi intermiten tak terjelaskan — periksa BurstBalance sebelum investigasi layer lain.

Kesimpulan dan Langkah Selanjutnya: Memilih EBS gp3 sebagai Default

Untuk hampir semua workload baru, gp3 adalah pilihan yang lebih baik — performa lebih konsisten, biaya lebih rendah, dan kontrol lebih granular. gp2 masih berfungsi, tapi model burst-nya menciptakan risiko performa yang sulit di-debug di produksi.

Langkah konkret yang bisa diambil sekarang:

  • Audit semua volume gp2 aktif menggunakan perintah describe-volumes di atas.
  • Prioritaskan migrasi volume dengan ukuran kecil tapi kebutuhan IOPS tinggi.
  • Pantau BurstBalance pada volume gp2 yang belum dimigrasikan.
  • Update template IaC (CloudFormation, Terraform) untuk default ke gp3.
  • Baca dokumentasi resmi: AWS EBS Volume Types dan Elastic Volumes.

Glosarium

Istilah Penjelasan
IOPS Input/Output Operations Per Second — ukuran berapa banyak operasi baca/tulis yang dapat dilakukan volume per detik.
Throughput Jumlah data yang dapat ditransfer per detik, diukur dalam MiB/s. Berbeda dari IOPS yang mengukur jumlah operasi.
I/O Credit Bucket (gp2) Mekanisme akumulasi kredit pada gp2 yang memungkinkan burst IOPS sementara. Kredit habis jika beban I/O terus-menerus melebihi angka dasar.
BurstBalance CloudWatch metric yang menunjukkan persentase sisa kredit burst pada volume gp2. Nilai rendah mengindikasikan risiko penurunan performa.
Elastic Volumes Fitur AWS yang memungkinkan modifikasi tipe, ukuran, IOPS, dan throughput volume EBS secara online tanpa detach atau downtime.

Komentar

Posting Komentar

Postingan populer dari blog ini

EC2 Tidak Bisa Akses Internet di Custom VPC: Cara Pasang Internet Gateway dan Update Route Table

Kamu baru saja membuat custom VPC, meluncurkan EC2 instance di public subnet, lalu mencoba ping google.com — dan tidak ada respons sama sekali. Ini adalah salah satu jebakan paling umum saat pertama kali bekerja dengan EC2 no internet access di custom VPC , dan penyebabnya hampir selalu kombinasi dari tiga hal: tidak ada Internet Gateway, route table yang belum diupdate, atau Security Group yang memblokir traffic. TL;DR: Checklist EC2 Tidak Bisa Internet di Custom VPC Komponen Yang Harus Dicek Kondisi Benar Internet Gateway Sudah dibuat dan di-attach ke VPC State: attached Route Table Ada route 0.0.0.0/0 ke IGW Target: igw-xxxxxxxx Subnet Association Public subnet terhubung ke route table yang benar Subnet ID muncul di associations Security Group Inbound HTTP/HTTPS/ICMP diizinkan Rule eksplisit untuk port 80, 443, atau ICMP Public IP Instance punya public IP atau Elastic IP PublicIpAddress tidak n...
Baca selengkapnya