Ringkasan gangguan layanan Amazon DynamoDB yang terjadi di region AS Timur (Virginia Utara, US-East-1)

 (aws.amazon.com)
3 poin oleh GN⁺ 2025-10-24 | 2 komentar | Bagikan ke WhatsApp
  • Pada 19–20 Oktober 2025, beberapa layanan inti termasuk Amazon DynamoDB mengalami gangguan berkepanjangan di region AWS N. Virginia (us-east-1)
  • Gangguan dimulai ketika catatan DNS kosong yang keliru dibuat akibat race condition laten dalam sistem manajemen DNS otomatis DynamoDB
  • Akibatnya, terjadi rangkaian masalah seperti kegagalan pembuatan instance EC2, error koneksi Network Load Balancer (NLB), serta latensi dan kegagalan API pada banyak layanan seperti Lambda, ECS, dan Redshift
  • AWS mengidentifikasi akar masalah sebagai tabrakan pembaruan simultan abnormal antar DynamoDB DNS Enactor, lalu memulihkan layanan sepenuhnya sekitar pukul 2:20 siang pada 20 Oktober melalui pemulihan manual
  • Insiden ini menyoroti kompleksitas saling ketergantungan antar sistem otomasi internal AWS, dan perbaikan struktural untuk meningkatkan ketahanan DNS, EC2, dan NLB telah diisyaratkan

Ringkasan insiden

  • Gangguan dimulai pada 19 Oktober 2025 pukul 11:48 malam (PDT) dan berakhir pada 20 Oktober pukul 2:20 siang (PDT)
    • Ada tiga periode dampak utama:
      1. 19 Oktober 11:48PM~20 Oktober 2:40AM: tingkat error API DynamoDB melonjak tajam
      2. 20 Oktober 5:30AM~2:09PM: error koneksi NLB meningkat
      3. 20 Oktober 2:25AM~10:36AM: kegagalan pembuatan instance EC2 baru dan masalah konektivitas jaringan
  • Gangguan bermula dari cacat pada sistem manajemen DNS DynamoDB lalu meluas ke banyak layanan seperti EC2, NLB, Lambda, dan Redshift

Penyebab dan dampak gangguan DynamoDB

  • Sistem manajemen DNS otomatis DynamoDB memicu cacat laten, sehingga catatan DNS untuk dynamodb.us-east-1.amazonaws.com keliru diperbarui menjadi kosong
    • Sistem ini dipisah menjadi dua komponen:
      • DNS Planner: memantau status load balancer dan membuat rencana DNS baru
      • DNS Enactor: bertugas menerapkan perubahan ke Route53
  • Terjadi race condition di antara DNS Enactor yang ditempatkan secara independen di tiga Availability Zone (AZ)
    • Enactor pertama yang terlambat menerapkan rencana lama
    • Enactor kedua menerapkan rencana terbaru lalu menghapus rencana lama, sehingga semua alamat IP ikut terhapus dan sistem masuk ke kondisi tidak konsisten
    • Karena pemulihan otomatis gagal, dibutuhkan intervensi manual
  • Tepat setelah gangguan terjadi pada 11:48PM, semua layanan dan trafik pelanggan yang bergantung pada DynamoDB mengalami kegagalan koneksi
    • Pelanggan yang menggunakan global table masih dapat mengirim permintaan ke replika di region lain, tetapi terjadi replication lag
  • Pada 12:38AM, engineer AWS memastikan bahwa status DNS adalah akar masalah
    • Pada 1:15AM, langkah pemulihan sementara memulihkan sebagian koneksi layanan internal
    • Pada 2:25AM, informasi DNS pulih sepenuhnya, dan pada 2:40AM semua koneksi kembali normal

Dampak pada Amazon EC2 dan proses pemulihan

  • Dari 19 Oktober 11:48PM hingga 20 Oktober 1:50PM, terjadi kenaikan tingkat error API EC2, kegagalan pembuatan instance, dan peningkatan latensi
    • Instance yang sudah berjalan tidak terdampak
  • Pengelolaan instance EC2 menggunakan dua subsistem: DropletWorkflow Manager (DWFM) dan Network Manager
    • DWFM mengelola status server fisik (“droplet”) dan melakukan pemeriksaan status secara berkala
    • Network Manager menyebarkan konfigurasi jaringan instance
  • Karena gangguan DynamoDB, pemeriksaan status DWFM gagal dan lease droplet kedaluwarsa
    • Setelah DynamoDB pulih pada 2:25AM, DWFM mencoba terhubung kembali, tetapi jumlah droplet yang sangat besar memicu congestive collapse
    • Pada 4:14AM, engineer me-restart host DWFM secara selektif untuk membersihkan antrean dan melanjutkan pemulihan
    • Pada 5:28AM, semua lease droplet dipulihkan dan pembuatan instance baru dilanjutkan
  • Setelah itu, saat Network Manager memproses backlog propagasi status jaringan yang tertunda, terjadi latensi konektivitas jaringan
    • Pada 10:36AM, waktu propagasi jaringan kembali normal
    • Pada 11:23AM, pelonggaran throttling dimulai, dan pada 1:50PM EC2 pulih sepenuhnya

Dampak pada Network Load Balancer (NLB)

  • Dari 20 Oktober 5:30AM hingga 2:09PM, sebagian pelanggan mengalami peningkatan error koneksi NLB
    • NLB memiliki arsitektur multi-tenant dan merutekan trafik ke instance EC2 backend
  • Penyebab gangguan adalah kegagalan health check akibat keterlambatan propagasi status jaringan
    • Konfigurasi jaringan pada instance EC2 yang baru ditambahkan belum selesai, sehingga health check gagal
    • Hasil health check berulang secara tidak stabil, menyebabkan node NLB dihapus dari DNS lalu dikembalikan lagi
  • Pada 6:52AM, sistem pemantauan mendeteksi masalah dan engineer mulai merespons
    • Peningkatan beban pada subsistem health check memicu failover DNS AZ otomatis
    • Pada 9:36AM, failover otomatis dinonaktifkan sehingga semua node yang sehat kembali
    • Pada 2:09PM, setelah EC2 pulih, failover otomatis diaktifkan kembali

Dampak pada layanan AWS lainnya

  • AWS Lambda:
    • Dari 19 Oktober 11:51PM hingga 20 Oktober 2:15PM terjadi error API dan latensi
    • Gangguan DynamoDB menyebabkan kegagalan pembuatan dan pembaruan fungsi, serta keterlambatan pemrosesan event SQS/Kinesis
    • Pada 7:04AM, kegagalan health check NLB menyebabkan penyusutan sistem internal dan pembatasan pemanggilan asinkron
    • Pada 2:15PM, semua backlog selesai diproses dan layanan kembali normal
  • ECS, EKS, Fargate:
    • Dari 19 Oktober 11:45PM hingga 20 Oktober 2:20PM terjadi kegagalan menjalankan container dan keterlambatan penskalaan cluster
  • Amazon Connect:
    • Dari 19 Oktober 11:56PM hingga 20 Oktober 1:20PM terjadi error pada panggilan, chat, dan pemrosesan case
    • Setelah DynamoDB pulih, sebagian besar fungsi kembali normal, tetapi setelah 7:04AM error muncul lagi akibat dampak NLB dan Lambda
    • Pada 1:20PM layanan pulih sepenuhnya
  • AWS STS:
    • Dari 19 Oktober 11:51PM hingga 20 Oktober 9:59AM terjadi error dan latensi pada API autentikasi
    • Setelah DynamoDB pulih, layanan sempat normal sementara, lalu error muncul lagi karena masalah NLB
  • Login IAM dan Identity Center:
    • Dari 19 Oktober 11:51PM hingga 20 Oktober 1:25AM terjadi peningkatan kegagalan autentikasi
    • Setelah DynamoDB pulih, layanan kembali normal
  • Amazon Redshift:
    • Dari 19 Oktober 11:47PM hingga 20 Oktober 2:21AM terjadi kegagalan query dan modifikasi cluster
    • Setelah DynamoDB pulih, sebagian cluster masih belum normal karena gangguan EC2
    • Pada 21 Oktober 4:05AM layanan pulih sepenuhnya
    • Karena ketergantungan pada IAM API, kegagalan query sementara juga terjadi di region global
  • Layanan lainnya:
    • Managed Workflows for Apache Airflow, Outposts, AWS Support Center, dan lainnya juga terdampak

Tindak lanjut dan rencana perbaikan

  • Otomasi DynamoDB DNS Planner dan Enactor dinonaktifkan sepenuhnya, dan sebelum diaktifkan kembali AWS berencana memperbaiki race condition serta menambahkan mekanisme pengaman
  • NLB: akan diperkenalkan mekanisme rate control yang membatasi kapasitas yang dapat dihapus oleh satu NLB saat health check gagal
  • EC2:
    • Membangun test suite baru yang mencakup workflow pemulihan DWFM
    • Menyempurnakan smart throttling pada sistem propagasi data dengan menambahkan pembatasan permintaan berdasarkan ukuran antrean tunggu
  • AWS juga sedang meninjau tambahan langkah untuk memperpendek waktu pemulihan dan mencegah insiden serupa, melalui analisis ketergantungan antarlayanan secara menyeluruh

Kesimpulan dan permintaan maaf

  • AWS menyampaikan permintaan maaf resmi atas dampak insiden ini terhadap pelanggan
  • Perusahaan mengakui bahwa meski selama ini mempertahankan ketersediaan layanan yang tinggi, gangguan kali ini berdampak signifikan pada bisnis pelanggan
  • AWS berjanji menjadikan insiden ini sebagai pelajaran untuk memperkuat ketahanan sistem otomasi dan prosedur penanganan gangguan

Bacaan terkait

2 komentar

 
shakespeares 2025-10-26

Katanya ini dampak susulan setelah karyawan senior dipangkas..benarkah?
 
GN⁺ 2025-10-24
Komentar Hacker News

  • Saya selalu mengulang hal yang sama tentang topik ini. Jika Anda belum membaca tulisan Richard Cook, saya sarankan berhenti membaca postmortem ini sekarang dan baca dulu How Complex Systems Fail. Itu salah satu tulisan teknis terbaik tentang kegagalan sistem kompleks. Cook menolak konsep akar penyebab (root cause) itu sendiri, dan saya rasa dalam insiden ini pun dia benar

    • Tulisan Cook bagus, tetapi terasa seperti daftar argumen intuitif. Untuk benar-benar memahaminya secara mendalam, sepertinya perlu membaca seluruh referensinya. Di kelas sistem MIT 6.033 juga dibaca makalah tahun 1962 dan makalah klasik lain yang membahas tema serupa. Pada akhirnya, saya melihat masalah seperti ini sebagai contoh kompleksitas tingkat 'wicked problem'
    • Bagian yang paling berkesan dari tulisan Cook adalah bahwa upaya memperbaiki sistem agar “lebih aman” setelah insiden justru bisa mengurangi keselamatan. Penjelasan bahwa langkah-langkah untuk mencegah kesalahan manusia meningkatkan keterikatan dan kompleksitas sistem, sehingga menambah titik kegagalan potensial dan membuat deteksi maupun pencegahan lebih sulit, sangat terasa relevan
    • Ada juga sudut pandang lain, yaitu teori 'Normal Accidents'. Gagasannya adalah bahwa semakin kuat keterikatan antar komponen, semakin kompleks interaksinya, dan semakin serius konsekuensi kegagalannya, maka sistem itu secara inheren semakin berbahaya. Lihat wiki Normal Accidents
    • Saya belum menamatkan kedua dokumen itu, tetapi saya tidak setuju dengan klaim bahwa hanya karena sistem itu kompleks maka akar penyebab kegagalan tidak bisa ditentukan. Dalam olahraga pun skor lahir dari banyak faktor, tetapi tetap ada ‘pencetak gol’. Sudut pandang luas itu bagus, tetapi menunjuk penyebab inti juga praktis
    • Saya seorang kontraktor yang menjalani tugas on-call. Kebanyakan perusahaan tidak menganggap on-call dengan serius. Dokumentasinya kurang, dan tidak diberi waktu untuk membaca kode kompleks buatan orang lain. Saya benar-benar ingin merasakan budaya seperti AWS yang menganggap on-call sebagai bagian dari pembelajaran dan tanggung jawab

  • Internet makin berubah menjadi jaringan tunggal yang terpusat (mononet). Internet yang lahir sebagai jaringan terdistribusi pada era Perang Dingin kini punya struktur di mana satu kesalahan deployment bisa menghentikan perbankan, belanja, dan perjalanan di seluruh dunia. Metafora cloud sudah melampaui batasnya.
    Untuk startup atau R&D, itu masih berguna, tetapi perusahaan tahap pertumbuhan atau pemerintah seharusnya punya server sendiri, cloud sendiri, dan layanan inti sendiri. Teknologi dan SDM-nya sudah cukup

  • Di postmortem AWS, saya terkesan dengan visualisasi garis waktu yang akurat. Seperti presentasi legendaris GDC “I Shot You First”, cara mengekspresikan aliran waktu dengan panah miring sambil bertanya “di mana keterlambatan terjadi” sangat berguna.
    Tetapi yang lebih mengejutkan bagi saya adalah bahwa layanan pengelolaan lease node EC2 tidak punya prosedur pemulihan (runbook). Untuk layanan inti AWS, saya kira hampir semua situasi pengecualian sudah diantisipasi

    • Situasi seperti ini seharusnya tidak ditakuti, melainkan dipahami sebagai pola inheren sistem kompleks. Kegagalan potensial ada seperti fraktal, dan mustahil memiliki runbook untuk setiap kemungkinan

  • Inti insiden ini tampak seperti variasi dari masalah cache invalidation pada sistem DNS. Dua DNS Enactor menerapkan plan pada waktu yang berbeda sehingga terjadi race condition, lalu plan lama menimpa plan baru

    • Itu hanya penjelasan untuk publik; di internal sebenarnya setelah insiden terselesaikan akan dilakukan evaluasi kemungkinan terulang dan penyusunan mitigasi (runbook). Setelah itu pembelajaran dan berbagi pengetahuan di tingkat organisasi akan berlanjut
    • Menurut saya, race condition itu sendiri adalah akar penyebabnya. Jika bug itu tidak ada, insiden ini juga tidak akan terjadi
    • Saya bertanya-tanya mengapa DNS Planner dan Enactor dipisahkan. Jika itu satu layanan, kondisi balapan seperti ini akan terlihat lebih jelas. Bisa jadi ini akibat penyalahgunaan microservices yang menambah kompleksitas
    • Saya pernah mengalami masalah serupa, dan penyebabnya adalah jeda JVM GC serta perangkat keras yang rusak. Mungkin kali ini pun ada kemungkinan seperti itu
    • Namun AWS tidak menjelaskan langkah pencegahan jika keterlambatan seperti ini terjadi lagi

  • Enactor seharusnya membandingkan versi record saat ini (CAS) sebelum menerapkan nilai baru. Meski kurang efisien, itu pengaman dasar. DynamoDB sendiri seharusnya bisa menanganinya

  • Saya kaget membaca penjelasan bahwa DynamoDB mengelola ratusan ribu record DNS per region. Bahwa dynamodb.us-east-1.amazonaws.com bisa di-resolve ke ratusan ribu IP terasa seperti melewati batas Route53. Mungkin caranya dengan menjaga TTL tetap rendah dan hanya memperbarui sebagian

    • Memang DNS AWS bekerja seperti itu. Route53 beroperasi pada unit resource record set (RRSet), lalu mengembalikan set yang sesuai melalui health check atau logika pemilihan berbasis latensi
    • CDN juga bekerja mirip. Sistem mengumpulkan metrik untuk menghitung PoP optimal per jaringan. bunny.net SmartEdge adalah contoh yang baik
    • Saya juga mengujinya dengan S3, dan dalam beberapa detik saya mendapat ratusan IP berbeda. Bahkan dalam satu region pun ada keragaman seperti itu

  • Bug akan selalu ada. Verifikasi formal (formal verification) itu sulit, dan bug berprobabilitas rendah kadang baru meledak bertahun-tahun kemudian.
    Karena itu, sistem harus dirancang dengan asumsi bahwa ia pasti gagal, lalu dibuat struktur untuk membatasi dampaknya. Arsitektur berbasis sel, rollout bertahap, dan zona terisolasi adalah contohnya.
    AWS juga mencoba pendekatan berbasis sel, tetapi khususnya di us-east-1 masih ada ketergantungan silang warisan. Dalam jangka panjang, region harus dirancang sepenuhnya independen.
    Pekerjaan seperti ini sulit berjalan tanpa dukungan eksekutif tingkat tinggi, tetapi dari sudut pandang pemegang saham ini adalah investasi penting untuk mengurangi risiko keberlangsungan perusahaan

  • Saya agak terkejut laporan ini memakai zona waktu PT, bukan UTC

    • Sampai muncul lelucon “epoch fail?”, tetapi karena kebanyakan pelanggan berbasis di AS, PT mungkin terasa lebih intuitif
    • Bisa juga memang dimaksudkan untuk menekankan sulitnya respons malam hari

  • Saya heran tidak ada pola seperti versioning per-endpoint atau 2PC, single writer lease. Meski begitu, saya sangat menghargai AWS yang mempublikasikan hal ini dengan transparan

    • Sebenarnya API perubahan DNS memang melakukan CAS, tetapi beberapa writer asinkron bersaing tanpa urutan logis, sehingga masalah muncul. Seharusnya urutan diserialkan dengan zone serial atau sentinel record

  • Saya melihat penyebab langsung insiden ini adalah race condition laten di sistem manajemen DNS DynamoDB. Plan lama menimpa plan terbaru sehingga record DNS endpoint regional menjadi kosong

    • Tetapi konsep “akar penyebab” perlu diperlakukan hati-hati. Ini adalah keruntuhan metastabil (metastable collapse), dan masalah utamanya adalah tidak adanya prosedur pemulihan (runbook).
      Referensi: How Complex Systems Fail