DynamoDB Capacity Modes: Provisioned vs On-Demand — Pilih yang Tepat untuk Hindari Throttling

Saat pertama kali deploy aplikasi ke DynamoDB, hampir semua engineer menghadapi pertanyaan yang sama: pilih Provisioned atau On-Demand? Salah pilih di awal bisa berarti throttling yang tidak terduga saat traffic naik, atau tagihan yang membengkak karena over-provisioning kapasitas yang tidak pernah terpakai. Artikel ini membahas DynamoDB capacity modes secara operasional — bukan sekadar definisi, tapi bagaimana keduanya berperilaku di produksi dan kapan masing-masing menjadi pilihan yang tepat.

TL;DR — DynamoDB Capacity Modes

Aspek	On-Demand	Provisioned
Traffic pattern	Tidak diketahui / tidak terprediksi	Stabil dan terprediksi
Throttling risk	Rendah (auto-scale instan)	Tinggi jika RCU/WCU tidak cukup
Biaya per request	Lebih mahal per unit	Lebih murah jika utilisasi tinggi
Operasional overhead	Minimal	Perlu monitoring & capacity planning
Auto Scaling	Built-in, tidak perlu konfigurasi	Opsional, perlu dikonfigurasi
Cocok untuk	Aplikasi baru, traffic burst, dev/staging	Aplikasi mature dengan traffic stabil

Bagaimana DynamoDB Capacity Modes Bekerja

DynamoDB mengukur throughput dalam satuan Read Capacity Units (RCU) dan Write Capacity Units (WCU). Satu RCU merepresentasikan satu strongly consistent read per detik untuk item hingga 4 KB, atau dua eventually consistent reads per detik untuk ukuran yang sama. Satu WCU merepresentasikan satu write per detik untuk item hingga 1 KB. Pemilihan capacity mode menentukan bagaimana DynamoDB mengalokasikan dan menagih unit-unit ini.

graph TD A["Request Masuk"] --> B["DynamoDB Router"] B --> C{"Capacity Mode?"} C -->|"On-Demand"| D["Auto-scale kapasitas"] C -->|"Provisioned"| E{"RCU/WCU tersedia?"} D --> F["Request diproses"] E -->|"Ya"| F E -->|"Tidak"| G{"Burst capacity
tersedia?"} G -->|"Ya"| F G -->|"Tidak"| H["ProvisionedThroughput
ExceededException"] F --> I["Response ke client"]

Request masuk ke DynamoDB partition berdasarkan partition key.
DynamoDB memeriksa apakah throughput yang tersedia mencukupi untuk request tersebut.
Pada mode Provisioned, jika RCU/WCU habis, request langsung di-throttle dengan ProvisionedThroughputExceededException.
Pada mode On-Demand, DynamoDB menyesuaikan kapasitas secara otomatis — tidak ada throttling akibat limit kapasitas yang di-set manual.
Burst capacity (pada Provisioned) dapat menyerap lonjakan singkat, tapi bukan solusi untuk sustained traffic spike.

Bayangkan Provisioned seperti menyewa jalur tol dengan jumlah lajur tetap — murah jika selalu penuh, tapi kendaraan antri jika tiba-tiba ada konvoi besar. On-Demand seperti jalan tol yang lajurnya otomatis bertambah sesuai kepadatan, tapi tarif per kendaraan lebih mahal.

On-Demand Mode — Kapan Ini Pilihan yang Benar

Jika traffic pattern aplikasi belum diketahui — misalnya aplikasi baru yang baru saja launch, atau fitur yang traffic-nya bergantung pada kampanye marketing — On-Demand adalah pilihan defensif yang tepat. DynamoDB On-Demand tidak memerlukan capacity planning sama sekali; tabel otomatis menyesuaikan diri dengan workload aktual.

Yang perlu dipahami: On-Demand bukan berarti unlimited tanpa batas. DynamoDB menetapkan previous peak sebagai referensi skalabilitas. Tabel baru dimulai dengan batas default, dan kapasitas dapat meningkat hingga dua kali lipat dari peak sebelumnya dalam waktu singkat. Jika traffic naik drastis melebihi dua kali peak sebelumnya dalam waktu sangat singkat, throttling masih bisa terjadi — meski jarang dalam kondisi normal.

Untuk memverifikasi apakah tabel sudah dalam mode On-Demand:

aws dynamodb describe-table \
  --table-name nama-tabel-anda \
  --query 'Table.BillingModeSummary'

Output yang diharapkan:

{
    "BillingMode": "PAY_PER_REQUEST",
    "LastUpdateToPayPerRequestDateTime": "2024-01-15T10:30:00.000Z"
}

Membuat tabel baru dengan On-Demand mode:

aws dynamodb create-table \
  --table-name nama-tabel-anda \
  --attribute-definitions AttributeName=pk,AttributeType=S \
  --key-schema AttributeName=pk,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST

Provisioned Mode — Kapan Biaya Lebih Penting dari Fleksibilitas

Begitu traffic pattern aplikasi sudah stabil dan terprediksi — misalnya aplikasi internal yang digunakan jam kerja saja, atau sistem batch yang jadwalnya konsisten — Provisioned mode bisa memangkas biaya secara signifikan dibanding On-Demand. Kuncinya adalah utilisasi yang tinggi: jika kapasitas yang di-provision hampir selalu terpakai, cost per request jauh lebih rendah.

Provisioned mode tanpa Auto Scaling adalah jebakan yang sering tidak disadari. Engineer men-set RCU/WCU berdasarkan estimasi, lalu lupa. Tiga bulan kemudian traffic naik 3x, throttling mulai muncul di CloudWatch, dan tim baru sadar masalahnya setelah user complaint.

Selalu aktifkan Auto Scaling jika menggunakan Provisioned mode. Auto Scaling DynamoDB menggunakan Application Auto Scaling untuk menyesuaikan RCU/WCU berdasarkan target utilization. Konfigurasi via CLI:

🔽 Klik untuk expand — Konfigurasi Auto Scaling untuk Provisioned Mode

# Daftarkan tabel sebagai scalable target untuk write capacity
aws application-autoscaling register-scalable-target \
  --service-namespace dynamodb \
  --resource-id "table/nama-tabel-anda" \
  --scalable-dimension "dynamodb:table:WriteCapacityUnits" \
  --min-capacity 5 \
  --max-capacity 500

# Daftarkan tabel sebagai scalable target untuk read capacity
aws application-autoscaling register-scalable-target \
  --service-namespace dynamodb \
  --resource-id "table/nama-tabel-anda" \
  --scalable-dimension "dynamodb:table:ReadCapacityUnits" \
  --min-capacity 5 \
  --max-capacity 500

# Buat scaling policy untuk write capacity
aws application-autoscaling put-scaling-policy \
  --service-namespace dynamodb \
  --resource-id "table/nama-tabel-anda" \
  --scalable-dimension "dynamodb:table:WriteCapacityUnits" \
  --policy-name "WriteAutoScalingPolicy" \
  --policy-type "TargetTrackingScaling" \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "DynamoDBWriteCapacityUtilization"
    }
  }'

Target value 70% adalah titik keseimbangan yang umum digunakan — cukup headroom untuk menyerap burst sebelum Auto Scaling bereaksi, tanpa terlalu boros kapasitas idle.

Decision Guide — Pilih Mode yang Tepat

graph TD Start(["Mulai: Pilih Capacity Mode"]) --> Q1{"Traffic pattern
sudah diketahui?"} Q1 -->|"Belum / Tidak pasti"| OD["On-Demand
PAY_PER_REQUEST"] Q1 -->|"Ya, stabil"| Q2{"Volume traffic
tinggi & konsisten?"} Q2 -->|"Tidak"| OD Q2 -->|"Ya"| Q3{"Biaya On-Demand
sudah signifikan?"} Q3 -->|"Tidak"| OD Q3 -->|"Ya"| Q4{"Bisa aktifkan
Auto Scaling?"} Q4 -->|"Ya"| PROV_AS["Provisioned +
Auto Scaling"] Q4 -->|"Tidak / Sangat predictable"| PROV["Provisioned
+ Monitoring ketat"] OD --> NOTE1["Pantau CloudWatch
beberapa minggu"] PROV_AS --> NOTE2["Target utilization
~70%"] PROV --> NOTE3["Wajib alarm
ThrottledRequests"]

Mulai dari pertanyaan paling fundamental: apakah traffic pattern sudah diketahui?
Jika belum — On-Demand adalah pilihan aman. Tidak ada throttling akibat misconfiguration kapasitas.
Jika traffic stabil, evaluasi apakah biaya On-Demand sudah terasa signifikan. Jika ya, pindah ke Provisioned dengan Auto Scaling.
Untuk workload dengan traffic yang sangat predictable dan volume tinggi, Provisioned tanpa Auto Scaling (dengan Reserved Capacity) bisa memberikan penghematan maksimal — tapi ini memerlukan monitoring aktif.

Migrasi Antar Mode — Hal yang Perlu Diketahui

Mengubah capacity mode bisa dilakukan kapan saja, tapi ada batasan frekuensi: setiap tabel hanya bisa beralih antara On-Demand dan Provisioned sekali per 24 jam. Ini penting saat merencanakan strategi migrasi — jangan asumsikan bisa bolak-balik sesuka hati dalam satu hari.

Mengubah tabel yang sudah ada ke On-Demand:

aws dynamodb update-table \
  --table-name nama-tabel-anda \
  --billing-mode PAY_PER_REQUEST

Mengubah ke Provisioned dengan nilai awal RCU dan WCU:

aws dynamodb update-table \
  --table-name nama-tabel-anda \
  --billing-mode PROVISIONED \
  --provisioned-throughput ReadCapacityUnits=100,WriteCapacityUnits=50

Verifikasi status perubahan — operasi update-table bersifat asinkron:

aws dynamodb describe-table \
  --table-name nama-tabel-anda \
  --query 'Table.TableStatus'

Pola Kegagalan Nyata — Throttling yang Tidak Terduga di Provisioned Mode

Ini skenario yang sering terjadi: tabel berjalan lancar selama berbulan-bulan dengan Provisioned mode dan Auto Scaling aktif. Suatu hari, ada proses batch yang menulis ribuan item dalam waktu singkat. CloudWatch menunjukkan ConsumedWriteCapacityUnits normal, tapi aplikasi mulai melaporkan error sporadis.

Diagnosis awal biasanya salah: tim melihat WCU aggregate masih di bawah limit, lalu menyimpulkan masalah ada di aplikasi. Yang sebenarnya terjadi adalah hot partition — semua write dari proses batch menggunakan partition key yang sama, sehingga satu partition menerima traffic jauh melebihi kapasitasnya meskipun total WCU tabel masih aman.

Cara mendeteksi hot partition via CloudWatch Contributor Insights:

aws dynamodb update-contributor-insights \
  --table-name nama-tabel-anda \
  --contributor-insights-action ENABLE

Setelah diaktifkan, buka CloudWatch console dan cari rule DynamoDBContributorInsights-PKC-nama-tabel-anda untuk melihat partition key mana yang mendominasi traffic. Ini adalah layer diagnostik yang sering dilewati karena engineer terlalu fokus pada metric aggregate.

Solusinya bukan menaikkan WCU — tapi memperbaiki partition key design agar distribusi write lebih merata. Capacity mode tidak bisa memperbaiki hot partition; ini adalah masalah data modeling.

IAM — Izin Minimum untuk Mengelola Capacity Mode

Operasi update-table dan describe-table memerlukan izin IAM yang spesifik. Berikut policy minimum untuk mengelola capacity mode:

🔽 Klik untuk expand — IAM Policy untuk DynamoDB Capacity Management

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DynamoDBCapacityManagement",
      "Effect": "Allow",
      "Action": [
        "dynamodb:DescribeTable",
        "dynamodb:UpdateTable",
        "dynamodb:UpdateContributorInsights",
        "dynamodb:DescribeContributorInsights"
      ],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/nama-tabel-anda"
    },
    {
      "Sid": "AutoScalingManagement",
      "Effect": "Allow",
      "Action": [
        "application-autoscaling:RegisterScalableTarget",
        "application-autoscaling:PutScalingPolicy",
        "application-autoscaling:DescribeScalableTargets",
        "application-autoscaling:DescribeScalingPolicies"
      ],
      "Resource": "*"
    }
  ]
}

Perhatikan bahwa operasi Application Auto Scaling memerlukan "Resource": "*" — ini bukan kelalaian, tapi memang demikian yang didokumentasikan di AWS Service Authorization Reference untuk sebagian besar action Application Auto Scaling.

Monitoring Throttling — Metric yang Harus Dipantau

Terlepas dari capacity mode yang dipilih, dua metric CloudWatch ini harus selalu ada di dashboard:

ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits — menunjukkan utilisasi aktual. Pada Provisioned mode, bandingkan dengan nilai yang di-provision untuk menghitung utilization percentage.
ThrottledRequests — jika metric ini konsisten di atas nol pada On-Demand mode, kemungkinan ada hot partition atau tabel baru yang belum mencapai peak capacity yang cukup.

Membuat alarm CloudWatch untuk throttling:

aws cloudwatch put-metric-alarm \
  --alarm-name "DynamoDB-Throttling-nama-tabel" \
  --metric-name ThrottledRequests \
  --namespace AWS/DynamoDB \
  --dimensions Name=TableName,Value=nama-tabel-anda \
  --statistic Sum \
  --period 60 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:nama-sns-topic

Wrap-Up: DynamoDB Capacity Modes dan Langkah Selanjutnya

Untuk aplikasi yang traffic pattern-nya belum diketahui, mulai dengan On-Demand mode — ini menghilangkan satu variabel kegagalan di awal. Setelah aplikasi berjalan beberapa minggu dan traffic pattern mulai terlihat dari CloudWatch metrics, evaluasi apakah migrasi ke Provisioned mode dengan Auto Scaling memberikan penghematan biaya yang signifikan.

Yang paling penting: capacity mode bukan satu-satunya faktor yang menentukan performa DynamoDB. Partition key design, access pattern, dan penggunaan index yang tepat sama pentingnya — bahkan lebih. Throttling yang disebabkan hot partition tidak bisa diselesaikan hanya dengan mengganti capacity mode.

Referensi resmi untuk topik ini:

Glossary — Istilah Kunci

Istilah	Definisi
RCU (Read Capacity Unit)	Satuan throughput baca DynamoDB. Satu RCU = satu strongly consistent read/detik untuk item hingga 4 KB.
WCU (Write Capacity Unit)	Satuan throughput tulis DynamoDB. Satu WCU = satu write/detik untuk item hingga 1 KB.
Throttling	Kondisi di mana DynamoDB menolak request karena kapasitas yang tersedia tidak mencukupi, mengembalikan error `ProvisionedThroughputExceededException`.
Hot Partition	Kondisi di mana satu partition menerima traffic yang tidak proporsional dibanding partition lain, menyebabkan throttling meski total kapasitas tabel masih mencukupi.
Burst Capacity	Kapasitas cadangan yang DynamoDB simpan saat throughput tidak terpakai penuh, dapat digunakan untuk menyerap lonjakan traffic singkat pada Provisioned mode.

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

Cari Blog Ini

SW BBANG I