Gangguan AWS: Batas Perlindungan Multi-AZ

Menyebar server ke beberapa pusat data AWS dalam satu region disebut multi-AZ. Cara ini mengurangi risiko gangguan satu lokasi, tetapi tidak menutup semua risiko jaringan atau layanan bersama. Pelajaran gangguan us-west-2 pada 24 Juli 2026: tentukan dulu proses bisnis yang harus tetap berjalan, lalu uji apakah jalur cadangannya melewati komponen yang sama.

Pada 24 Juli 2026, perangkat jaringan di wilayah layanan (region) us-west-2 milik AWS di Oregon mengalami kegagalan. 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).

Perencanaan cadangan perlu membedakan kegagalan satu lokasi dari gangguan konektivitas wilayah layanan. Multi-AZ saja belum tentu menutup risiko kedua. Laporan publik yang dirujuk juga tidak menjelaskan arsitektur setiap perusahaan yang terdampak.

Apa yang sebenarnya rusak

AWS menunjuk perangkat jaringan yang mengatur rute antara region dan area Seattle Metro sebagai penyebabnya. Itu koneksi antara us-west-2 dan internet luas, bukan kerusakan di satu gedung pusat data 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.

Laporan tersebut mengidentifikasi gangguan konektivitas, tetapi tidak membuktikan bahwa seluruh komputasi dan penyimpanan pelanggan tetap sehat. Server dapat tetap menyala dan basis data tetap menjawab kueri, sementara akses dari luar terputus.

Bagi pengguna, server yang tetap menyala tetapi tidak dapat dijangkau tetap berarti layanan tidak tersedia.

Bedakan perlindungan antarlokasi dan antarwilayah

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 yang berdampak bersama — 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).

Beberapa AZ dalam satu wilayah tetap dapat bergantung pada komponen jaringan dan layanan bersama. Itulah batas yang gagal pada 24 Juli — bukan antara dua AZ, tetapi antara region dan segala sesuatu di luarnya. Multi-AZ membantu menghadapi kegagalan satu lokasi. Perlindungannya tidak mencukupi jika akses yang digunakan bersama oleh beberapa lokasi terputus.

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. Kasus ini menunjukkan mengapa batas isolasi perlu disesuaikan dengan jenis kegagalan yang direncanakan.

Perhitungkan waktu menyelesaikan antrean setelah pulih

Dua puluh menit kedengarannya bisa ditolerir, dan untuk banyak bisnis memang begitu. Yang membuat insiden ini lebih parah justru pekerjaan pemulihan setelah koneksi kembali, bukan angka utama itu. SendGrid beralih ke jalur cadangan dan kembali normal dalam sekitar enam menit setelah routing dipulihkan. NinjaOne butuh sekitar sembilan setengah jam untuk membereskan antrean sekitar 150.000 perangkat yang mencoba menyambung kembali bersamaan (IncidentHub).

Akar masalahnya sama, waktu pemulihannya jauh berbeda. Kecepatan pengalihan ke jalur cadangan (failover) berbeda dari kecepatan penyelesaian antrean. Rancangan pemulihan perlu menguji keduanya.

Ini juga insiden reliabilitas AWS yang ketiga dalam sekitar tiga bulan terakhir (Tech Times). Riwayat insiden tersebut menjadi alasan untuk menyiapkan pemulihan; tiga kejadian itu sendiri bukan jaminan pola frekuensi gangguan berikutnya.

Sesuaikan cadangan dengan kebutuhan bisnis

Dalam panduan untuk merancang keandalan, AWS sendiri tidak merekomendasikan multi-region sebagai default. Well-Architected Framework-nya mendaftarkan "menerapkan multi-Region padahal multi-AZ sudah cukup" sebagai pola yang perlu dihindari. 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). Nilai kebutuhan tersebut dari persyaratan bisnis Anda, bukan dari asumsi bahwa semua bisnis membutuhkan beberapa wilayah.

Tentukan perlindungan dari risiko dan batas gangguan yang dapat diterima bisnis. Arsitektur yang lebih rumit perlu dibenarkan oleh kebutuhan tersebut.

Biaya sebenarnya dari multi-region

Jika beberapa wilayah memang diperlukan, hitung komponen dan pekerjaan tambahannya. 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).

Infrastruktur tambahan memerlukan sinkronisasi data dan pemantauan pada kedua wilayah. 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. Rancangan dengan dua wilayah aktif dapat mendekati dua kali belanja infrastruktur; rancangan siaga memiliki biaya berbeda, plus kebiasaan operasional permanen menjaga dua region agar tidak saling menyimpang. Banyak tim usaha kecil dan menengah tidak punya cukup orang untuk menjalankannya dengan baik.

Saat menghitung kebutuhan ini bersama klien, biaya tambahannya sering memicu pertanyaan tentang alternatif yang lebih sederhana. Jawabannya bergantung pada pekerjaan yang harus tetap tersedia.

Kapan halaman statis justru jawaban yang tepat

Untuk usaha kecil dan menengah, masalah yang paling mendesak mungkin cara memberi kabar kepada pelanggan. Periksa apakah bisnis perlu tetap memproses transaksi, atau cukup menyediakan informasi dan kanal kontak selama gangguan.

Sebuah halaman status statis — ditempatkan pada penyedia berbeda, atau minimal di region berbeda dari produksi — memuat nomor telepon dan kalimat sederhana "kami tahu, sedang kami tangani". Hitung biaya hosting dan waktu penyiapannya sesuai penyedia yang dipilih. 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.

Petakan ketergantungan sebelum memilih 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 pemroses pembayaran, penyedia SMS atau surel, wilayah layanan komputasi awan, DNS, dan CDN. Untuk masing-masing, catat lokasi halaman status dan jalur cadangan yang benar-benar tersedia. 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.

Mulailah dengan peta sederhana yang dapat dibuat sekitar satu sore. Gunakan hasilnya untuk menentukan cadangan, penanggung jawab, dan latihan pemulihan sebelum terjadi gangguan.