Bisakah DynamoDB melakukan auto scaling?
Ya. Auto scaling DynamoDB memakai Application Auto Scaling untuk menyesuaikan kapasitas baca dan tulis provisioned menuju sebuah target utilisasi (bisa disetel 20–90%, umumnya 70%), dalam batas min/maks yang Anda tentukan. Sebagai alternatif, mode kapasitas on-demand menskala seketika mengikuti trafik tanpa konfigurasi apa pun. Keduanya menjaga tabel tetap responsif terhadap beban yang berubah tanpa perencanaan kapasitas manual.
Auto scaling provisioned
Anda membuat sebuah scaling policy per tabel (dan per global secondary index) yang menetapkan:
- sebuah target utilisasi (persentase kapasitas provisioned yang dituju),
- unit kapasitas minimum dan maksimum, dan
- apakah yang diskalakan baca, tulis, atau keduanya.
Alarm CloudWatch memicu Application Auto Scaling untuk menaikkan atau menurunkan kapasitas saat konsumsi melewati targetnya.
Mode on-demand
Kapasitas on-demand menghapus perencanaan sepenuhnya: DynamoDB menyesuaikan throughput ke trafik Anda dengan sendirinya — seketika mengakomodasi hingga dua kali lipat puncak trafik Anda sebelumnya — dan menagih Anda per request. Ia cocok ketika trafiknya meletup-letup atau sulit diprediksi.
Mana yang dipilih
Provisioned dengan auto scaling biasanya lebih murah ketika trafiknya stabil dan dipahami dengan baik; on-demand lebih sederhana dan lebih baik untuk trafik yang tak diketahui atau meletup-letup.
Di mana target utilisasi berhenti menguntungkan
Target utilisasi adalah tombol harga, dan ia punya lantai; di bawah lantai itu auto scaling kalah telak dari on-demand.
Di us-east-1 satu write capacity unit berbiaya $0,00065 per jam, jadi memesan satu unit untuk sebulan berbiaya $0,4745 dan membeli 2.628.000 tulis. Itu $0,00000018 per tulis berbanding $0,000000625 milik on-demand, membuat kapasitas provisioned 3,46 kali lebih murah ketika setiap unit yang dipesan benar-benar terpakai. Balikkan dan Anda mendapat titik impasnya: provisioned berhenti menguntungkan di bawah utilisasi rata-rata 28,9%. Baca menghasilkan angka 28,9% yang sama, jadi ini sifat model harganya, bukan sifat satu tarif tertentu.
Tulis berkelanjutan 1.000 per detik untuk item 1 KB, dihargai dengan kalkulator harga:
| Setelan kapasitas | Provisioned | Bulanan |
|---|---|---|
| Target 90% | 1.112 WCU | $527,64 |
| Target 70% | 1.429 WCU | $678,06 |
| Target 50% | 2.000 WCU | $949,00 |
| Target 20% | 5.000 WCU | $2.372,50 |
| On-demand | tidak ada | $1.642,50 |
Dua baris terakhir membawa pelajarannya. Target 20%, yang terendah yang diterima AWS, memesan lima kali lipat trafik Anda dan berbiaya 44% lebih mahal daripada membayar per request untuk pekerjaan yang sama persis. Setiap baris di atas mengasumsikan auto scaling memakukan kapasitas tepat di targetnya, jadi perlakukan sebagai kasus terbaik: trafik nyata berkelana dan algoritmenya mengikuti dengan terlambat, yang menyeret utilisasi terealisasi ke bawah berapa pun yang Anda konfigurasikan.
Apa yang dibeli tombol itu
Scale-up dan scale-down sengaja dibuat asimetris, dan asimetri itulah yang dibayar oleh headroom-nya. AWS mendokumentasikan scale-up terpicu setelah consumed capacity menembus targetnya selama dua menit berturut-turut dan scale-down setelah 15 titik data berturut-turut di bawahnya. Panggilan UpdateTable yang menyusul memakan beberapa menit lagi, dan apa pun di atas plafon lama akan di-throttle selama itu berjalan.
Penurunan juga dijatah. Anda memulai setiap hari UTC dengan empat dan memperoleh satu per jam, tak pernah memegang lebih dari empat, yang membatasi Anda pada 27 per hari per tabel. Global secondary index mendapat jatahnya sendiri.
Jadi target yang tinggi menghemat uang sungguhan dan membelanjakan buffer yang menutupi menit-menit itu. On-demand berbiaya lebih mahal per request dan menghapus pertukaran itu sepenuhnya.
Pelajari lebih lanjut
Bandingkan keduanya di on-demand vs kapasitas provisioned dan perkirakan biayanya dengan kalkulator harga. Unduh DynoTable untuk membaca estimasi ukuran dan jumlah item sebuah tabel di Table stats.
Referensi
- Managing throughput capacity automatically with DynamoDB auto scaling — Amazon DynamoDB Developer Guide
- DynamoDB on-demand capacity mode — Amazon DynamoDB Developer Guide
- DynamoDB provisioned capacity mode — Amazon DynamoDB Developer Guide
- Quotas in Amazon DynamoDB — Amazon DynamoDB Developer Guide — jatah penurunan, diperiksa ulang 2026-07-28.
Terakhir diverifikasi 2026-07-13 terhadap dokumentasi resmi AWS yang ditautkan di atas.
Titik impas dihitung 2026-07-28 dengan kalkulator harga kami sendiri atas tarif us-east-1 yang ia sinkronkan dari AWS Price List API. Penundaan penskalaan dan jatah penurunannya dibaca ulang dari dokumentasi AWS yang ditautkan di atas pada tanggal yang sama.