Memahami Instance T3 Burstable: Cara Kerja CPU Credits dan Kenapa Server Tiba-tiba Melambat

Anda baru saja deploy aplikasi di instance T3, semua berjalan lancar selama beberapa menit — lalu tiba-tiba response time melonjak, CPU usage turun drastis, dan pengguna mulai mengeluh. Tidak ada error di log aplikasi, tidak ada masalah jaringan. Ini adalah gejala klasik CPU credit exhaustion pada instance T3 burstable, dan memahami mekanisme di baliknya adalah kunci untuk menghindari insiden serupa di production.

TL;DR: CPU Credits pada Instance T3

Aspek Penjelasan
Apa itu CPU Credit? Satuan yang merepresentasikan hak pakai CPU penuh selama 1 menit pada 1 vCPU
Kapan credit bertambah? Saat CPU usage di bawah baseline instance
Kapan credit berkurang? Saat CPU usage melebihi baseline instance
Mode default T3 Unlimited — instance dapat burst melampaui credit balance dengan biaya tambahan
Gejala credit habis (Standard mode) CPU tiba-tiba terkunci di angka baseline, performa turun drastis
Solusi utama Pilih mode yang tepat (Unlimited vs Standard), atau upgrade ke instance non-burstable

Cara Kerja CPU Credits pada Instance T3 Burstable

Instance T3 dirancang untuk workload yang tidak membutuhkan CPU tinggi secara terus-menerus — web server dengan traffic ringan, environment development, microservice dengan load rendah. Mekanisme burstable bekerja seperti rekening tabungan CPU: Anda menabung saat idle, dan menarik saat dibutuhkan.

Setiap instance T3 memiliki baseline CPU utilization — persentase CPU yang dapat digunakan secara berkelanjutan tanpa mengonsumsi credit. Ketika CPU usage berada di bawah baseline, instance mengakumulasi credit. Ketika usage melebihi baseline, instance mengonsumsi credit dari balance yang tersedia.

Bayangkan credit seperti baterai laptop. Saat terhubung ke charger (CPU rendah), baterai terisi. Saat dipakai intensif (CPU tinggi), baterai terkuras. Jika baterai habis dan tidak ada charger, performa turun ke mode hemat daya.

Satu CPU credit setara dengan penggunaan satu vCPU pada 100% selama satu menit penuh. Atau ekuivalennya: dua vCPU pada 50% selama satu menit, atau satu vCPU pada 50% selama dua menit.

graph TD A["CPU Usage
di bawah Baseline"] -->|"Credit Bertambah"| B["Credit Balance Meningkat"] C["CPU Usage
di atas Baseline"] -->|"Credit Dikonsumsi"| D["Credit Balance Berkurang"] D --> E{"Balance = 0?"} E -->|"Standard Mode"| F["CPU Di-throttle
ke Baseline"] E -->|"Unlimited Mode"| G["Burst Berlanjut
Surplus Credit Dikenakan Biaya"] B --> C F -->|"Credit Terakumulasi Kembali"| B
  1. Akumulasi Credit: Saat CPU usage di bawah baseline, credit bertambah sesuai laju akumulasi per jam instance tersebut.
  2. Burst: Saat CPU usage melebihi baseline, credit dikonsumsi dari balance. Instance dapat mencapai 100% CPU selama credit tersedia.
  3. Credit Habis (Standard mode): Jika balance mencapai nol, CPU dikunci pada level baseline — inilah yang menyebabkan perlambatan mendadak.
  4. Unlimited mode: Instance dapat terus burst melampaui balance dengan biaya per vCPU-hour tambahan, tanpa throttling.

Baseline dan Laju Akumulasi Credit per Tipe Instance T3

Setiap ukuran instance T3 memiliki baseline dan laju akumulasi yang berbeda. Nilai ini didokumentasikan secara resmi oleh AWS.

Instance Type vCPU Baseline CPU per vCPU Credit Accrual per jam Max Credit Balance
t3.nano 2 5% 6 144
t3.micro 2 10% 12 288
t3.small 2 20% 24 576
t3.medium 2 20% 24 576
t3.large 2 30% 36 864
t3.xlarge 4 40% 96 2304
t3.2xlarge 8 40% 192 4608

Catatan: Pricing dan limits dapat berubah — selalu verifikasi di dokumentasi resmi AWS.

Standard Mode vs Unlimited Mode: Perbedaan yang Krusial

Secara default, instance T3 diluncurkan dalam mode Unlimited. Ini berbeda dengan generasi sebelumnya seperti T2, yang default-nya adalah Standard. Perbedaan ini penting dan sering menjadi sumber kebingungan saat migrasi dari T2 ke T3.

graph LR subgraph Standard["Standard Mode"] S1["Credit Balance"] -->|"Habis"| S2["CPU Throttle
ke Baseline"] S2 -->|"Tidak ada biaya tambahan"| S3["Performa Terbatas"] end subgraph Unlimited["Unlimited Mode (Default T3)"] U1["Credit Balance"] -->|"Habis"| U2["Burst Berlanjut"] U2 -->|"Surplus Credit"| U3["Biaya Tambahan
per vCPU-hour"] end
  1. Standard mode: Instance dibatasi ketat oleh credit balance. Saat credit habis, CPU di-throttle ke baseline. Tidak ada biaya tambahan di luar harga instance.
  2. Unlimited mode (default T3): Instance dapat burst melampaui credit balance. AWS mengenakan biaya per vCPU-hour untuk penggunaan di atas baseline saat balance nol. Tidak ada throttling, tapi tagihan bisa mengejutkan.
  3. Surplus credit: Dalam Unlimited mode, kredit yang digunakan saat balance nol disebut 'surplus credits'. Biaya dikenakan untuk surplus credits yang tidak terbayar oleh akumulasi berikutnya dalam periode penagihan.

Dalam Unlimited mode, instance T3 tidak akan pernah mengalami throttling mendadak — tapi Anda bisa mendapat tagihan AWS yang tidak terduga jika workload terus-menerus tinggi. Ini adalah trade-off yang harus dipahami sebelum memilih mode.

Mendiagnosis Masalah CPU Credit pada Instance T3

Ketika server tiba-tiba melambat tanpa alasan yang jelas di log aplikasi, urutan diagnosis berikut menutup celah yang tidak tertangkap oleh monitoring aplikasi biasa.

Langkah 1: Periksa CPU Credit Balance saat ini

Monitoring aplikasi tidak akan menangkap credit exhaustion — ini adalah metrik infrastruktur yang hanya terlihat di CloudWatch. Mulai dari sini untuk mengkonfirmasi apakah throttling sedang terjadi.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T23:59:59Z \
  --period 300 \
  --statistics Average \
  --region us-east-1

Jika CPUCreditBalance mendekati nol bersamaan dengan waktu insiden, credit exhaustion adalah penyebabnya. Untuk instance dalam Standard mode, ini langsung menyebabkan throttling.

Langkah 2: Periksa CPU Credit Usage dan Surplus

Credit balance saja tidak cukup — Anda perlu melihat laju konsumsi untuk memahami seberapa cepat credit terkuras. Untuk instance Unlimited mode, periksa juga surplus credit untuk memperkirakan biaya tambahan.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUCreditUsage \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T23:59:59Z \
  --period 300 \
  --statistics Sum \
  --region us-east-1
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUSurplusCreditBalance \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T23:59:59Z \
  --period 300 \
  --statistics Average \
  --region us-east-1

CPUSurplusCreditBalance yang terus meningkat pada instance Unlimited mode adalah sinyal bahwa workload melebihi kapasitas baseline secara konsisten — artinya tagihan surplus credit akan muncul di akhir bulan.

Langkah 3: Verifikasi Mode Instance (Standard vs Unlimited)

Karena T3 default ke Unlimited, banyak engineer mengira instance mereka tidak bisa di-throttle — padahal jika instance pernah diubah ke Standard secara manual atau melalui IaC, throttling bisa terjadi. Verifikasi mode aktual sebelum mengambil kesimpulan.

aws ec2 describe-instance-credit-specifications \
  --instance-ids i-1234567890abcdef0 \
  --region us-east-1

Output akan menampilkan CpuCredits dengan nilai standard atau unlimited. Jika hasilnya tidak sesuai ekspektasi, lanjut ke langkah berikutnya.

Langkah 4: Ubah Mode CPU Credit

Jika instance dalam Standard mode dan workload membutuhkan burst yang lebih panjang, ubah ke Unlimited. Perubahan ini dapat dilakukan tanpa restart instance.

aws ec2 modify-instance-credit-specification \
  --instance-credit-specifications InstanceId=i-1234567890abcdef0,CpuCredits=unlimited \
  --region us-east-1

Untuk kembali ke Standard mode (misalnya untuk mengontrol biaya pada instance yang jarang burst):

aws ec2 modify-instance-credit-specification \
  --instance-credit-specifications InstanceId=i-1234567890abcdef0,CpuCredits=standard \
  --region us-east-1

Langkah 5: Buat CloudWatch Alarm untuk Credit Balance Rendah

Diagnosis reaktif tidak cukup untuk production. Credit exhaustion yang tidak terdeteksi dini akan selalu mengejutkan. Alarm ini menutup gap monitoring yang tidak tertangkap oleh health check aplikasi.

aws cloudwatch put-metric-alarm \
  --alarm-name T3-CPUCreditBalance-Low \
  --alarm-description 'CPU Credit Balance rendah pada instance T3' \
  --namespace AWS/EC2 \
  --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --statistic Average \
  --period 300 \
  --evaluation-periods 2 \
  --threshold 20 \
  --comparison-operator LessThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:ops-alerts \
  --region us-east-1

Sesuaikan nilai --threshold berdasarkan laju akumulasi instance Anda. Untuk t3.micro dengan akumulasi 12 credit/jam, threshold 20 memberi waktu sekitar 1,5 jam sebelum credit benar-benar habis.

Pengalaman Lapangan: Salah Diagnosis yang Umum Terjadi

Insiden yang paling sering salah didiagnosis: instance T3 di production berjalan normal selama berminggu-minggu, lalu tiba-tiba response time naik 10x pada jam sibuk. Tim langsung memeriksa database, koneksi jaringan, dan log aplikasi — semua bersih. Tidak ada exception, tidak ada slow query.

Yang terlewat: instance baru saja diluncurkan ulang dua hari sebelumnya setelah maintenance, sehingga credit balance mulai dari nol. Selama dua hari pertama, instance mengakumulasi credit saat traffic rendah di malam hari. Ketika traffic pagi hari melonjak, credit terkuras dalam hitungan menit — dan karena instance dalam Standard mode (diset manual oleh IaC lama), CPU langsung di-throttle ke baseline 10%.

Metrik CPUUtilization di CloudWatch menunjukkan angka yang 'normal' — sekitar 10% — padahal seharusnya 80%+. Ini yang membuat diagnosis sulit: throttling membuat CPU usage terlihat stabil, bukan spike. Satu-satunya sinyal yang jelas adalah CPUCreditBalance yang menyentuh nol tepat saat insiden dimulai.

Pelajarannya: jika CPU usage terlihat terlalu stabil di tengah insiden performa, periksa credit balance sebelum menggali lebih dalam ke layer aplikasi.

Kapan Harus Upgrade dari T3 ke Instance Non-Burstable

Instance T3 bukan pilihan yang tepat untuk semua workload. Jika salah satu kondisi berikut terpenuhi secara konsisten, pertimbangkan migrasi ke instance compute-optimized atau general purpose non-burstable.

graph TD A["Rata-rata CPU Usage"] --> B{"Konsisten di atas Baseline?"} B -->|"Tidak"| C["T3 Burstable
Pilihan Tepat"] B -->|"Ya"| D{"Latency Sensitif?"} D -->|"Tidak"| E{"Biaya Surplus
Lebih Mahal dari M/C?"} D -->|"Ya"| F["Upgrade ke
M atau C Series"] E -->|"Ya"| F E -->|"Tidak"| G["Tetap T3 Unlimited Monitor Surplus Credit"]
  1. CPU baseline tidak mencukupi: Jika rata-rata CPU usage secara konsisten melebihi baseline instance, surplus credit akan terus dikenakan biaya. Pada titik ini, instance M atau C series sering lebih ekonomis.
  2. Workload tidak bisa diprediksi: Jika traffic spike terjadi tanpa pola yang memungkinkan credit terakumulasi terlebih dahulu, burstable tidak memberikan keuntungan.
  3. Latency sensitif: Throttling mendadak pada Standard mode tidak dapat diterima untuk workload real-time atau latency-critical.

IAM Permission untuk Mengelola CPU Credit Specification

Untuk menjalankan perintah diagnosis dan modifikasi di atas, pastikan IAM principal memiliki permission yang diperlukan.

🔽 Klik untuk melihat contoh IAM Policy 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DescribeCreditSpec",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstanceCreditSpecifications",
        "ec2:ModifyInstanceCreditSpecification"
      ],
      "Resource": "*"
    },
    {
      "Sid": "CloudWatchMetrics",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:PutMetricAlarm"
      ],
      "Resource": "*"
    }
  ]
}

Catatan: ec2:DescribeInstanceCreditSpecifications dan cloudwatch:GetMetricStatistics tidak mendukung resource-level restriction — keduanya memerlukan Resource: *. Verifikasi di AWS Service Authorization Reference.

Memahami Instance T3 Burstable: Kesimpulan dan Langkah Selanjutnya

Instance T3 burstable adalah pilihan cost-effective yang tepat untuk workload dengan pola CPU yang tidak merata — asalkan Anda memahami mekanisme credit di baliknya. Perlambatan mendadak yang tampak misterius hampir selalu dapat dijelaskan oleh satu dari dua kondisi: credit balance mencapai nol pada Standard mode, atau surplus credit yang terakumulasi tanpa disadari pada Unlimited mode.

Yang perlu diingat: T3 default ke Unlimited, tapi bukan berarti gratis. Unlimited mode mencegah throttling dengan menukar performa untuk biaya tambahan. Pilih mode berdasarkan prioritas workload Anda — bukan berdasarkan default.

Langkah selanjutnya yang direkomendasikan:

  • Aktifkan CloudWatch alarm untuk CPUCreditBalance pada semua instance T3 production
  • Review mode CPU credit pada instance T3 yang sudah berjalan menggunakan describe-instance-credit-specifications
  • Evaluasi apakah workload dengan CPU usage konsisten di atas baseline lebih cocok menggunakan instance M atau C series
  • Baca dokumentasi resmi: Burstable Performance Instances — AWS Documentation

Glosarium

Istilah Definisi
CPU Credit Satuan yang merepresentasikan hak penggunaan satu vCPU pada 100% selama satu menit
Baseline CPU Persentase CPU yang dapat digunakan secara berkelanjutan tanpa mengonsumsi credit
CPU Throttling Pembatasan penggunaan CPU ke level baseline saat credit balance habis (Standard mode)
Surplus Credit Credit yang digunakan saat balance nol dalam Unlimited mode; dikenakan biaya tambahan
Unlimited Mode Mode operasi T3 default yang memungkinkan burst tanpa throttling dengan biaya surplus

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