Gangguan pada Berbagai Layanan AWS di Region us-east-1

• AWS mengalami gangguan pada berbagai layanan di region us-east-1
• Akibatnya, perusahaan pengguna infrastruktur cloud mengalami downtime layanan
• Dilaporkan adanya masalah ketersediaan pada layanan penting seperti API Gateway, Lambda
• Para insinyur menyoroti kebutuhan untuk menyiapkan jalur alternatif dan meninjau rencana tanggap darurat
• AWS Health Dashboard menyediakan informasi gangguan dan pembaruan secara real-time

---

Gambaran Umum Gangguan Region AWS us-east-1

• Pada 21 Oktober 2025, AWS Health Dashboard melaporkan bahwa sejumlah layanan di region us-east-1 mengalami gangguan
• Secara khusus, layanan penting seperti API Gateway, Lambda, S3 terdampak dan banyak pelanggan mengalami gangguan layanan
• Sejak saat gangguan terjadi, AWS langsung memulai analisis penyebab dan pekerjaan pemulihan
• Perusahaan SaaS, startup, dan perusahaan TI yang bergantung pada region tersebut melaporkan keterlambatan layanan dan downtime
• Insinyur serta administrator TI menekankan pentingnya membangun jalur fallback darurat dan strategi redundansi antar region untuk layanan kritis

Dampak dan Penanganan Gangguan

• Region us-east-1 adalah salah satu region dengan lalu lintas terbanyak di infrastruktur cloud global, sehingga dampak gangguan ini sangat besar
• Secara nyata, berbagai pelanggan melaporkan penghentian layanan, respons API yang terlambat, dan gangguan pemrosesan data secara bersamaan
• AWS menyampaikan kondisi terkini melalui Health Dashboard, sekaligus menyediakan dokumentasi dukungan dan pembaruan
• Tim TI pelanggan melakukan pemantauan kondisi gangguan, jalur sementara, dan pemberitahuan pengguna untuk meminimalkan dampak

Implikasi untuk Para Insinyur

• Kebutuhan akan sistem pemantauan dan mekanisme pemberitahuan insiden saat gangguan terjadi kembali ditekankan
• Arsitektur yang tahan gangguan melalui penyebaran multiregion, tindakan pemulihan otomatis, dan strategi pencadangan kembali menonjol
• AWS Health Dashboard berperan sebagai alat bantu pengambilan keputusan dengan informasi cepat pada saat gangguan

Kesimpulan

• Penyedia layanan cloud berskala besar perlu secara wajib menyiapkan mitigasi terhadap kemungkinan gangguan layanan
• Saat gangguan terjadi, proses pemulihan cepat, komunikasi yang transparan, dan kemampuan respons insiden infrastruktur yang efisien kembali menjadi sangat penting

[GN⁺]

Komentar Hacker News

• Hari ini memang hari yang sangat menarik. Aku berada di incident bridge sejak jam 3 pagi. Sebagian besar sistem sudah pulih, tetapi masih ada departemen di sisi back office yang masih mengalami kesulitan karena kekurangan sumber daya. Kekeliruan terbesar dari sisi kami adalah bahwa meskipun sistem sudah didesain agar bisa beroperasi multi-region, kami tidak bisa menjalankan proses failover. Hal ini karena tim keamanan memindahkan kami ke Identity Center dan menempatkannya hanya di us-east-1, sehingga seluruh perusahaan terkunci total ke control plane AWS. Saat kami akhirnya mengambil root credentials dari brankas, sistem hampir sepenuhnya pulih. Dari insiden ini saya menyadari lagi bahwa rantai paling lemah menentukan ketangguhan keseluruhan.
  • Beberapa tahun lalu, saya teringat saat data center Google di Paris pernah kebanjiran lalu terbakar. Kami sendiri tidak menempatkan resource compute di sana secara langsung, tetapi sedang berkomputasi di data center AWS EU, dan DNS resolver untuk layanan Google di-host di Paris sehingga jalur masuk lebih dulu dirutekan ke Paris. Solusi sementara itu cukup menarik. Saat itu saya baru tahu bahwa file /etc/hosts yang dideploy ke Kubernetes bisa diubah secara global dengan mudah, dan benar-benar terasa perlu untuk melakukannya. Biasanya saya tidak akan memakai /etc/hosts untuk tujuan seperti itu, namun sebagai patch sementara abstraksinya sangat pas.
  • Terlintas contoh serupa di Facebook saat pembaruan BGP-nya membuat akses ke vault menjadi benar-benar tidak mungkin. Jika jalur autentikasi bersifat sirkular, ketika DNS sekali saja bermasalah berarti kita tak bisa melakukan apa-apa.
  • Pada akhirnya akan datang saat di mana seseorang harus membawa hardware token, terbang ke data center lain, lalu mereset kunci inti agar sistem global bisa kembali berjalan.
  • Aku bertanya-tanya karena diceritakan bahwa Identity Center ditempatkan hanya di us-east-1, apakah itu bisa diletakkan di beberapa region? Terakhir kali saya cek, ia hanya bisa digunakan dari satu region, dan untuk memindahkannya harus dihapus terlebih dulu.
  • Batasan keamanan yang berlebihan justru membuat semuanya macet. Ingin tahu apakah tim keamanan akan bertanggung jawab atas kejadian ini. Kedepannya rasanya semua proyek akan jadi lebih lambat. Tim keamanan rasanya sudah terlalu agresif. Siapa yang mengawasi si pengawas?
• Aku rasa gangguan utama masih terus berlanjut. Kondisinya lebih buruk dibanding empat jam yang lalu. Aku data engineer, dan Redshift serta Airflow (layanan terkelola AWS) benar-benar berantakan.
  • Gangguan ini cukup lama, jadi penasaran berapa banyak sembilan yang hilang. 365 hari * 24 jam * 0.0001 kira-kira 8 jam; artinya kita sudah kehilangan ketersediaan 99.99%.
  • Aku tak paham mengapa banyak perusahaan masih ngotot pakai us-east-1. Kalau bicara frekuensi insiden, ini sangat buruk. Dulu perusahaan kami memutuskan menghindari us-east-1 dan hanya memakai region lain. Tentu saja, jika layanan dikatakan 'global', dalam praktiknya sering berarti us-east-1, jadi kadang-kadang tidak banyak membantu.
  • Operasi control-plane create-function di Lambda masih gagal dengan InternalError. Layanan lain (Lambda, SNS, SQS, EFS, EBS, CloudFront) sudah pulih. Aku lagi ambil master CS yang topiknya tentang cloud availability, jadi dari beberapa akun AWS uji-coba, aku merangkum timeline gangguan dan dampaknya. Postingan analisis
  • Di Down Detector, gangguan AWS tetap terlihat parah. Amazon bilang "pemulihan sedang berlangsung", tapi sebenarnya pencarian produk di Amazon.com pun tidak berjalan. AWS Health Page
  • Menurut Down Detector, pada pukul 12:52 AM Pacific (3:53 Eastern) aduan masalah AWS berjumlah 5.755, lalu turun ke 1.190 pada 4:22 AM Pacific (7:22 Eastern), dan naik lagi menjadi 9.230 pada 9:32 AM Pacific (12:32 Eastern). Mungkin karena West US kembali aktif laporan meningkat, tapi sepertinya AWS masih belum benar-benar mengendalikan situasi.
• Insiden ini benar-benar berdampak langsung ke rutinitasku. Aku berniat beli chocolate bar di Whole Foods Hudson Yards, New York, tapi diskon Prime tidak berlaku. Jadi tidak jadi beli, dan sekarang stok coklatku jadi sangat rendah.
  • Pagi ini juga "alexa, hidupkan coffeepot" tidak berfungsi. Aku jadi linglung.
  • Waktu makan siang aku coba isi Hotbar lalu self-checkout, sempat lama berpikir kenapa barcode Whole Foods tidak bisa dipakai. Baru setelah 20 detik kusadari ini karena gangguan.
  • Menarik sekali bisa ikut berbagi kasus seperti ini. Tapi jadi penasaran juga, apa yang terjadi dengan orang yang sedang di Amazon Go saat insiden AWS ini.
• Hari ini ada meeting dengan account manager AWS. Aku akan menjelaskan arahnya: kami mau keluar dari “All in on AWS” dan mendistribusikan workload. Alasan utamanya karena kecepatan inovasi layanan inti makin lambat dan layanan AI juga terlalu tertinggal dibanding kompetitor. Tim AWS terus mengklaim jangan pernah lakukan workload diversification karena stabilitas ekstrem AWS. Aku menantikan meeting ini.
  • Baik AWS, Cloudflare, Google Cloud, Akismet, siapa pun, pada akhirnya pasti pernah mengalami insiden. Tiap kali begini, jadi terpikir juga untuk kembali ke in-house hosting. Akhirnya dapat refund lalu mengoperasikan lagi. Hasil akhirnya mirip, jadi aku pikir tak perlu menambah beban kerja.
  • Pada laporan kinerja sebelumnya, setelah Andy Jassy dikritik karena AWS dianggap tertinggal dalam inovasi, yang dia soroti adalah reliabilitas, trust, durability. Tapi kondisi sekarang membuatnya tidak terdengar meyakinkan.
  • Di luar us-east-1, region lain berjalan cukup stabil. Perusahaan kami sebagian besar sekarang ada di eu-west-1 dan berjalan tanpa ada masalah berarti.
  • AWS secara jangka panjang sedang menurun. Sekarang sepertinya cuma menjaga layanan yang sudah ada. Inovator-inovator berbakat ditekan oleh birokrasi internal dan tuntutan performa, sehingga juga tertinggal di AI.
  • Klaim AWS soal stabilitas sejak awal memang bukan fakta. Kami pernah dulu setup monitoring multicloud pakai beberapa cloud + dedicated server, jadi bisa melihat persis mana yang pertama bermasalah. Hasilnya AWS memang tidak selalu juara pertama; sangat mirip dengan data netcraft.com.
• EPL hari ini pun akan menjalankan VAR dan sistem offside otomatis secara terbatas karena gangguan AWS. Benar-benar zaman yang aneh. Link BBC
  • Mulai terasa ada sisi baik meski ini adalah kegagalan cloud.
• Kalau us-east-1 jadi region utama, ketika outage terjadi semua orang langsung kena bersamaan, jadi tidak ada yang sendirian kena. Di region AS lain, kamu tak bisa menikmati “hak istimewa” itu.
  • Salah satu keuntungan tak terduga saat migrasi dari data center lama ke AWS adalah saat satu region down, pelanggan biasanya jadi lebih pengertian. Karena semuanya bermasalah, orang lebih mudah menerima.
  • Kadang semua orang memang perlu merasakan downtime teknis setidaknya sekali.
  • Oke, ayo semua bawa infrastruktur ke US-East-1.
  • Butuh waktu lama untuk sadar apa yang benar-benar penting di perusahaan. Nyatanya, yang lebih penting daripada availability adalah struktur yang membuat penyebabnya bisa dialihkan. Kalau karena human error ada downtime 5 menit, tanggung jawabnya ke CTO; kalau AWS outage 5 jam, semua kena sehingga dianggap kejadian yang tak terhindarkan. Akhirnya AWS, Crowdstrike, dan lain-lain: yang penting bukan kuatnya sistem, bukan value, bukan manajemen risiko, tetapi siapa saja yang sama-sama kesakitan. Menyebalkan, tapi ini realitas. Bagi orang yang suka sistem berjalan mulus, ini bikin emosi.
  • Region Tokyo sekarang jalan baik! Hanya beberapa fitur seperti login ke console yang masih bermasalah.
• Dari penyelidikan disebut, "Masalahnya tampaknya terkait dengan DNS resolution di endpoint API DynamoDB us-east-1, dan kami sedang menjalankan jalur paralel untuk mempercepat pemulihan." Seperti biasa penyebab akhirnya DNS.
  • Aku penasaran apakah memang ini murni masalah DNS resolution, atau masalah setelan internal/penyimpanan data DNS server. Kira-kira yang kedua.
  • Lalu di notifikasi berikutnya tertulis kegagalan network load balancer yang jadi akar penyebab. DNS adalah 'gejala' dari akar tersebut. DNS bisa jadi merusak health check, tapi saya pikir penyebab utamanya di sisi jaringan.
  • Bisa jadi BGP hanyalah DNS yang bersembunyi.
  • Akar masalahnya tetap us-east-1.
  • Kalau bukan DNS, pada akhirnya tetaplah DNS.
• Dalam hal ketangguhan, arsitektur yang sudah dipikirkan dengan benar memang berjalan. Kami menaruh static origin multi-region di CloudFront dan ini tidak terdampak dalam insiden ini. Control-plane juga multi-region native, walau tergantung pada banyak layanan, ketersediaannya tetap terjaga. Tiap region berjalan independen; replikasi data tetap ada, tapi jika replikasi us-east-1 tidak jalan pun dampaknya tidak terasa. Layanannya sendiri multi-region dan failover ditangani di beberapa layer (DNS, routing, destination selection). Memang tidak sempurna dan banyak mode kegagalan, tapi kali ini jalan baik jadi aku senang. Hal yang kulakukan ini bukan rocket science, tidak mahal, tapi pendekatan yang sedikit berbeda dari kebiasaan. Kalau ada yang penasaran, tanya aja.
  • Menyelamatkan diri dari outage dengan menempatkan static origin multi-region di CloudFront seharusnya jadi standard di 2025; anehnya ini masih jadi hal yang dipuji.
  • Aku penasaran apakah arsitekturnya active/active, dan bagaimana stack datanya. Bagian ini yang paling sulit kalau menurutku.
  • Bagaimana kamu mengimplementasikan autentikasi tahan-fault untuk key dan sertifikat?
• Masalah besar lainnya adalah ada rantai gangguan karena sistem IAM/auth overload atau down. Mereka bilang penyebabnya DynamoDB, jadi aku penasaran apakah IAM juga tergantung ke Dynamo secara internal. Di sistem skala besar yang rumit, dependency saling kusut; Auth/IAM berisiko jadi global single point, jadi ingin menekan dependency serendah mungkin. Tapi skalabilitas dan konsistensi juga penting, jadi pakai DB yang sudah terbukti. Akhirnya dependency makin kompleks, sehingga saat sistem down kita harus melewati bootstrap process yang rumit. Penasaran bagaimana kalian menanganinya.
  • Sekitar 2017 sempat ada outage besar karena DynamoDB. EC2 menyimpan daftar server di DynamoDB, lalu saat DynamoDB down, EC2 juga down. Karena DynamoDB berjalan di atas EC2, jadi tak mungkin pulih hanya dengan meluncurkan instance EC2 baru. Kami akhirnya harus memulihkan secara manual dengan menyalakan instance selama beberapa hari. Sejak saat itu saya berusaha memisahkan dependency antar sistem tier-1 seperti S3, DynamoDB, EC2 sejauh mungkin. Tentu tak mungkin sempurna.
  • Banyak customer AWS menerapkan retry policy yang salah; saat satu sistem down, sistem lain jadi terdorong overload. Karena itu outage DynamoDB sampai ke IAM.
  • Di internal Amazon ada platform Dynamo KV store terpisah, berbeda dari DynamoDB. Jadi penyebabnya bisa jadi DNS routing atau distribusi node. Isu seperti ini terus muncul di postmortem insiden besar.
  • Waktu saya bekerja di AWS, IAM tidak bergantung ke Dynamo. Entah sekarang berubah atau tidak, saya belum yakin. Dampaknya dari issue jaringan besar terasa lebih masuk akal. Karena Auth/IAM tidak boleh jadi titik akses global tunggal, arsitekturnya memang meminimalkan dependency. IAM punya read-only cache sendiri per region, dan AWS SigV4 juga dirancang untuk operasi per-region. (Dokumen referensi)
  • Menarik juga karena penyebab GCP outage terakhir ini mirip masalah yang sama.
• Pada 3:03AM PT AWS menyatakan sedang pemulihan. Tapi kondisinya malah memburuk. Pada 9:13AM PT, mereka bilang kembali lagi sedang analisis penyebab. AWS sendiri sepertinya tak tahu penyebab pastinya, bikin resah.
  • Aku juga merasa ini bertepatan dengan minggu Diwali, liburan besar di India, sehingga banyak engineer India sedang cuti. Benar-benar sial.