Multi-AZ Bukan Multi-Region: Pelajaran dari Outage us-west-2

Multi-AZ Bukan Multi-Region: Pelajaran dari Outage us-west-2

Semua perusahaan yang kena outage us-west-2 hampir pasti sudah menjalankan multi-AZ — sistem disebar ke beberapa Availability Zone, pusat data terpisah dalam satu region AWS. Tidak ada satu pun yang tertolong. Itu pelajaran utamanya: redundansi AZ menyelesaikan masalah yang berbeda dari yang bikin mereka down.

Pada 24 Juli 2026, satu perangkat networking hardware gagal di region us-west-2 milik AWS, Oregon. Reddit mati total. DoorDash berhenti menerima order. Hulu tidak bisa dimuat. Apple Pay menolak transaksi. PlayStation Network melempar pemain keluar di tengah pertandingan.

Timeline resmi AWS menyebut gangguan konektivitas utama sekitar dua puluh menit. Laporan lain menyebut disrupsi yang dirasakan pengguna lebih dekat ke delapan puluh menit, kalau dihitung semua yang masih berusaha reconnect selama satu jam berikutnya (Tech Times).

Cerita gampangnya "cloud-nya down" — nyaman, karena menaruh kegagalan di luar kendali siapa pun. Tapi itu pelajaran yang keliru untuk redundansi sistem sendiri. Ada satu perbedaan yang justru menjelaskan kenapa AZ tidak menyelamatkan satu pun perusahaan itu pagi itu.

Apa yang sebenarnya rusak

AWS menunjuk networking hardware yang membawa routing antara region dan area Seattle Metro sebagai penyebabnya. Itu koneksi antara us-west-2 dan internet luas, bukan kerusakan di satu data hall tertentu (IncidentHub). Jendela dampak utama berlangsung sekitar pukul 10:55 hingga 11:15 UTC. Layanan yang tersentuh meliputi Direct Connect, Global Accelerator, konektivitas internet umum, IoT Core, Site-to-Site VPN, API Gateway, EC2, ECS, ELB, dan VPC.

Compute dan storage di dalam region tetap sehat sepanjang waktu itu. Server tetap hidup. Database tetap menjawab query. Mereka cuma tidak bisa bicara dengan siapa pun di luar gedung.

Untuk layanan yang berhadapan langsung dengan konsumen, perbedaan itu tidak ada artinya. Server Reddit yang baik-baik saja tapi tidak terjangkau siapa pun, terlihat persis seperti Reddit yang down.

AZ menyelesaikan masalah yang berbeda

Bayangkan AZ seperti gudang cabang yang dibangun berjauhan supaya kebakaran di satu gudang tidak ikut membakar gudang sebelah. Itu persis alasan AWS membangun Availability Zone: bertahan dari peristiwa fisik shared-fate — kehilangan daya listrik, gangguan air, putusnya fiber, gempa bumi, kebakaran, banjir. AZ dalam satu region berjarak sampai sekitar 60 mil satu sama lain karena alasan itu (AWS Fault Isolation Boundaries).

Tapi setiap AZ dalam satu region tetap menjangkau internet lewat infrastruktur transit milik region itu sendiri, yang dipakai bersama. Itulah batas yang gagal pada 24 Juli — bukan antara dua AZ, tapi antara region dan segala sesuatu di luarnya. Multi-AZ cuma melindungi dari kehilangan satu gedung. Begitu pintu depan region itu sendiri macet, ia tidak menolong apa-apa — semua AZ di belakangnya ikut terkurung.

Region ke region adalah batas terpisah lagi, dan batas itu bertahan: us-east-1 dan region AWS lain tetap berjalan normal selagi us-west-2 terputus. Isolasi antar-region bekerja persis seperti dirancang. Cuma bukan isolasi yang sebenarnya diandalkan perusahaan-perusahaan terdampak itu.

Ekor pemulihan yang tidak pernah direncanakan orang

Dua puluh menit kedengarannya bisa ditolerir, dan untuk banyak bisnis memang begitu. Yang bikin insiden ini lebih parah justru ekor pemulihannya, bukan angka utama itu. SendGrid failover dan kembali normal dalam sekitar enam menit setelah routing dipulihkan. NinjaOne butuh sekitar sembilan setengah jam untuk membereskan backlog sekitar 150.000 perangkat yang semuanya berusaha reconnect bersamaan (IncidentHub).

Akar masalahnya sama, waktu pemulihannya jauh berbeda. Kecepatan failover dan kecepatan menghabiskan backlog adalah dua masalah engineering yang berbeda. Kebanyakan tim cuma merancang untuk yang pertama.

Ini juga insiden reliabilitas AWS yang ketiga dalam sekitar tiga bulan terakhir (Tech Times). Pada skala ini, region dan jaringan gagal lebih dari sekali per kuartal. Itu fakta yang perlu direncanakan, bukan skandal yang mengagetkan.

Apa kata AWS sendiri soal default yang seharusnya

Ini bagian yang sering mengejutkan pemilik SME: AWS sendiri tidak merekomendasikan multi-region sebagai default. Well-Architected Framework-nya mendaftarkan "menerapkan multi-Region padahal multi-AZ sudah cukup" sebagai anti-pattern yang secara eksplisit disebutkan. Multi-region disediakan untuk beban kerja yang butuh resiliensi ekstrem — infrastruktur kritikal, sistem kesehatan, kontrak dengan jaminan uptime yang tidak bisa dipenuhi satu region saja (AWS Well-Architected Framework). Untuk kebanyakan bisnis, itu bukan kasusnya, dan AWS mengatakannya sendiri di dokumentasinya.

Itu bukan izin untuk tidak melakukan apa-apa. Itu izin untuk menyesuaikan besar respons dengan risiko yang sebenarnya, bukan over-building karena panik baca headline.

Biaya sebenarnya dari multi-region

Kalau memang benar-benar dibutuhkan, kenali dulu apa yang sedang dibeli. Panduan AWS sendiri menjabarkannya: duplikasi infrastruktur dan layanan data di region kedua, replikasi image mesin dan container. Tambahkan replikasi data lintas-region (DynamoDB global tables, atau pasangan primary/read-replica untuk RDS dan Aurora). Siapkan juga DNS failover lewat Route 53 health check atau AWS Application Recovery Controller (AWS Well-Architected Framework).

Semuanya serba dua, harus selalu sinkron, dan beban pemantauannya ikut dobel. Perlu seseorang di tim yang memahami kedua sisinya cukup dalam untuk melakukan failover di bawah tekanan jam 3 pagi. Untuk bisnis yang menjalankan satu beban kerja produksi, itu bukan perubahan konfigurasi. Itu hampir menggandakan belanja infrastruktur, plus kebiasaan operasional permanen menjaga dua region agar tidak saling menyimpang. Kebanyakan tim SME tidak punya cukup orang untuk menjalankannya dengan baik.

Saya sudah pernah menghitung angka ini untuk klien yang kaget lihat nominalnya. Wajar saja mereka lalu bertanya apakah ada cara lebih murah untuk membeli ketenangan yang sama.

Kapan halaman statis justru jawaban yang tepat

Untuk kebanyakan SME, ada. Cari tahu dulu apa yang benar-benar tidak bisa ditoleransi bisnis itu sendiri. Jarang sekali jawabannya "dua puluh menit outage total." Biasanya jawabannya "pelanggan mengira kami sudah tutup" atau "kami tidak punya cara memberi tahu siapa pun apa yang terjadi."

Sebuah halaman status statis — di-hosting di provider berbeda, atau minimal di region berbeda dari produksi — memuat nomor telepon dan kalimat sederhana "kami tahu, sedang kami tangani". Halaman itu menutupi skenario ini dengan biaya beberapa dolar sebulan dan waktu setup satu sore. Halaman itu tidak akan memproses satu order pun. Tapi ia akan mencegah gangguan jaringan dua puluh menit terbaca seolah bisnis diam-diam sudah tutup.

Itulah latihan penyesuaian skala yang sebenarnya sudah ditunjukkan AWS: samakan belanja redundansi dengan apa yang benar-benar bisa merusak bisnis, bukan dengan apa yang terjadi pada Reddit.

Mulai dari peta dependency, bukan keputusan arsitektur

Sebelum memutuskan multi-AZ sudah cukup atau multi-region diperlukan, tuliskan setiap layanan pihak ketiga yang bisa menjatuhkan bisnis kalau tiba-tiba mati. Daftarnya termasuk payment processor, provider SMS atau email, region cloud, DNS, dan CDN. Untuk masing-masing, catat lokasi status page-nya dan apa fallback yang sebenarnya. Single point of failure yang bersembunyi di vendor yang tidak pernah dipikirkan siapa pun menyebabkan lebih banyak hari buruk dibanding keputusan arsitektur yang diperdebatkan semua orang.

Peta itu cuma butuh waktu satu sore untuk dibuat. Bagian ini hampir tidak pernah dikerjakan siapa pun sebelum outage terjadi. Bagian ini juga yang paling disesali semua orang kalau belum sempat dikerjakan saat outage berlangsung.