- Gangguan pada AWS, penyedia layanan cloud terbesar di dunia, membuat ribuan situs web dan aplikasi berhenti, sehingga muncul peringatan bahwa infrastruktur internet terlalu bergantung pada segelintir perusahaan.
- Dampaknya mencakup layanan utama seperti Snapchat, Roblox, Signal, Duolingo hingga lembaga publik dan keuangan seperti Lloyds Bank, Ring, HMRC.
- AWS menyebut penyebabnya sebagai kesalahan sistem internal di region AWS timur AS, menyingkirkan kemungkinan serangan siber, dan mayoritas layanan pulih dalam hitungan jam.
- Para ahli menegaskan bahwa dasar-bagian demokrasi dan jurnalisme tidak boleh bergantung pada infrastruktur milik segelintir perusahaan dan menekankan kebutuhan diversifikasi infrastruktur cloud.
- Struktur yang berpusat pada perusahaan cloud raksasa dianggap menyingkap kerentanan internet global, sekaligus memicu diskusi tentang kedaulatan teknologi untuk infrastruktur publik.
Gambaran Gangguan
- Gangguan besar pada layanan global terjadi akibat kesalahan internal di region AWS US-East-1.
- Gangguan dimulai sekitar pukul 08.00 waktu lokal pada hari Senin (16.00 waktu Inggris).
- Amazon mengumumkan bahwa tingkat error API dan latensi meningkat.
- Menurut Downdetector, lebih dari 2.000 perusahaan di seluruh dunia terdampak, dengan lebih dari 1,9 juta di AS, 1 juta di Inggris, dan 410 ribu di Australia melaporkan masalah.
- AWS menunjuk masalah pada subsistem monitoring load balancer internal sebagai penyebab dan menolak kemungkinan serangan siber.
- Dilaporkan bahwa kesalahan terkait DynamoDB menyebabkan respons API gagal.
- Untuk mencegah lonjakan lalu lintas, AWS menerapkan pembatasan jumlah permintaan untuk sementara waktu.
- AWS secara resmi mengumumkan bahwa operasional kembali normal pada sore hari, meski beberapa layanan tetap menerima laporan gangguan berkelanjutan.
Cakupan Dampak
- Layanan utama: Snapchat, Roblox, Signal, Duolingo, Coinbase, Slack, Wordle, PlayStation Network, Peloton, dan banyak lagi.
- Di Inggris, terjadi gangguan akses pada layanan keuangan seperti Lloyds, Halifax, Bank of Scotland dan juga situs web HMRC (otoritas pajak Inggris).
- Pengguna Ring Doorbell mengeluh bahwa layanan pemantauan bukaan pintu terhenti.
- Gangguan akses juga dilaporkan pada platform global seperti Epic Games, Pokémon Go, Wordle.
Analisis Ahli
- Dr. Corinne Cath-Speth (Article 19): “Dasar demokrasi dan jurnalisme yang independen tidak boleh bergantung pada infrastruktur segelintir perusahaan. Diversifikasi cloud sangat mendesak.”
- Cori Crider (Future of Technology Institute): “Inggris perlu keluar dari ketergantungan pada big tech AS. Gangguan di satu AWS sempat membuat hampir seluruh perekonomian modern melambat.”
- Madeline Carr (UCL): “Modal besar perusahaan cloud memang menjaga keamanan dan skalabilitas, tetapi struktur di mana seluruh dunia terikat pada risiko yang sama sangat berbahaya.”
- Steven Murdoch (UCL): “Penyebabnya diduga kesalahan operasional internal AWS, bukan serangan siber.”
Tanggapan Pemerintah dan Regulasi
- Pemerintah Inggris mengumumkan bahwa mereka mengaktifkan saluran komunikasi darurat dengan AWS dan memantau proses pemulihan.
- Komite Keuangan House of Commons Inggris mendorong agar AWS ditetapkan sebagai ‘pihak ketiga kritis’ (critical third party) di sektor keuangan.
- Penetapan ini akan membuat AWS berada di bawah pengawasan regulator keuangan dan memungkinkan penguatan stabilitas infrastruktur keuangan.
- Ketua komite Meg Hillier mengkritik AWS karena “menyatakan menyediakan daya tahan, tetapi justru mengekspos kerentanan”.
Latar Belakang dan Implikasi
- AWS memegang lebih dari 30% pangsa pasar cloud global, menjadikannya peringkat pertama.
- Bersama Microsoft Azure dan Google Cloud, AWS tengah membentuk struktur oligopoli tiga cloud utama.
- Pada 2024, pernah terjadi insiden Blue Screen of Death pada PC Windows global akibat kesalahan perangkat lunak CrowdStrike.
- Kejadian ini kembali menonjolkan risiko sistemik akibat konsentrasi infrastruktur digital dan membakar diskusi di banyak negara tentang kedaulatan teknologi dan strategi penyebaran cloud.
3 komentar
Semangat, Naver Cloud!
"Kalau kamu tidak suka cloud, ya bangun dan pakai sendiri," jadi apakah ini masih bisa didiskusikan?
Multicloud? Membangun dan mengelolanya juga bukan sesuatu yang akan dilakukan oleh orang lain.
Opini Hacker News
Saat ini sedang dibahas bahwa beberapa layanan di AWS us-east-1 sedang down, dan ada thread panjang terkait di sini
Bahkan pada insiden Fastly 2021, "ahli" juga mengkritik hal serupa, tetapi tidak ada perubahan nyata yang terlihat. Isu seperti ini biasanya tak lagi disebut media setelah seminggu berlalu. Praktisi tahu betapa sulitnya mengoperasikan skala AWS. Solusi kompensasi yang benar-benar efektif untuk bersiap menghadapi kondisi ini membutuhkan biaya yang sangat besar, sehingga manfaatnya sangat kecil bagi mayoritas perusahaan. Kalau memang layanannya benar-benar "kritis", memang seharusnya dirancang agar tahan terhadap kegagalan semacam itu. Kenyataan bahwa tidak bisa login ke Fortnite menunjukkan bahwa menerapkan mitigasi semacam ini secara realistis tidaklah mudah dan mahalnya juga terlihat nyata. Media pun biasanya tidak membahas pentingnya multi-region atau multi-cloud sampai insiden terjadi, lalu cepat melupakannya. Pada akhirnya, ini hanya rasa penasaran soal akar penyebab teknisnya. Kritikan "ahli" tanpa tindak lanjut hampir tak berarti; yang penting justru analisis pasca-insiden yang konstruktif dan tanpa saling menyalahkan.
"Ahli" yang dimaksud di sini adalah orang-orang yang tidak punya pengalaman nyata di infrastruktur atau operasi cloud. Misalnya, Dr. Corinne Cath-Speth adalah doktor antropologi, Cori Crider seorang pengacara, dan Madeline Carr seorang profesor ilmu politik. Artinya, mereka ini orang-orang yang menulis paper dan memberi wawancara media, bukan yang punya pengalaman mengoperasikan layanan hosting langsung.
Kalau terus mengkritik ketergantungan cloud, akhirnya saya setuju bahwa kita harus siap menghadapi downtime lebih dari 16 jam per tahun. Ketika gangguan hanya beberapa jam, orang biasanya merasakannya sangat besar, tetapi penurunan performa pada 8.742 jam sisanya bisa lebih mematikan. Kalau kondisi 16 jam downtime bisa menjatuhkan perusahaan, berarti saya atau lawan bicara sama-sama tidak paham bisnisnya. Saya lebih tertarik pada sistem yang high availability, redundansi geografis, dan daya tahan tinggi.
Tidak harus mengeluarkan biaya besar. Tidak semua layanan perlu "bertahan" dengan cara yang sama. Memakai penyedia berbeda dapat mencegah semuanya terdampak sekaligus.
Media menyoroti bahwa redundansi multi-region/multi-cloud sering kali tidak efektif. Secara tampak seolah hanya satu region yang bermasalah, namun layanan memang sering dipengaruhi di beberapa region sekaligus. Hot standby multi-cloud membuat beban biaya besar, dan makin kompleks infrastrukturnya, makin berat biayanya. Menerapkannya belakangan tanpa rencana awal sangat sulit.
Jika melihat laporan yang diterbitkan AWS sendiri, terlihat fokus berlebihan pada region tertentu dan layanan tertentu (misalnya DynamoDB). Arsitektur yang sangat terpusat ini sudah terlihat lebih dari 10 tahun. Namun mengapa belum berubah? Insiden ini membuat lebih dari 2.000 layanan down dalam waktu lama. Lihat AWS status page
Mungkin perlu dipikirkan untuk mengganti istilah "cloud" atau "internet" dengan "gudang di Virginia". Misalnya, "layanan kami sepenuhnya ada di gudang Virginia", "semua file saya di gudang Virginia", "gudang Virginia didesain agar tahan perang nuklir", dan sebagainya. Asli
Kini sudah banyak penyedia VPS, dan makin sering muncul contoh bahwa pindah ke sana menurunkan biaya; pada praktiknya ini soal cloud lock-in dan isu pemasaran.
Saat ini perusahaan tidak lagi banyak memakai IaaS level dasar seperti EC2, tetapi layanan PaaS tingkat tinggi AWS seperti DynamoDB, RedShift. Azure dan Google Cloud pun dalam kondisi yang sama. Ketika bergantung pada layanan tingkat tinggi itu, migrasi ke VPS seperti Hetzner atau self-hosting berarti harus membangun dan mengoperasikan ulang stack AWS secara langsung, sehingga jadi sangat rumit. Tidak cukup hanya pasang PostgreSQL.
Setiap kali ada tulisan yang bilang penghematan biaya dengan VPS, biasanya dibalas dengan, "AWS itu web-scale, tidak akan pernah mati; VPS hanya punya uptime satu hari dalam sebulan."
Amazon juga menyediakan VPS seperti EC2, jadi penasaran apakah EC2 juga terdampak di insiden ini.
Pendapat para ahli cenderung lebih fokus pada konteks geopolitik (misalnya ketergantungan sistem nasional secara real-time pada perusahaan asing) daripada sisi teknis. Untuk perusahaan biasa, bergantung pada satu penyedia bisa menyederhanakan kompleksitas dan tidak terlalu memberatkan dari sisi frekuensi gangguan. Tidak harus memakai multi-cloud. Bahkan satu penyedia saja bisa membuat frekuensi downtime lebih baik.
Saya pikir industri secara keseluruhan memang sudah terjebak dalam cloud lock-in. Saya penasaran bagaimana cara kita membaliknya ke depan. Docker juga, menurut saya, jadi salah satu penyebab utama masalah lock-in, sama seperti perusahaan cloud besar.
Bagi insinyur operasi atau staf support di lapangan, kenyataannya adalah saat jam 1 dini hari menemukan bahwa outage AWS global membuat semuanya runtuh, nyatanya tak ada yang ingin mengubah kondisi itu.
Penasaran mengapa Docker menjadi masalah.
Saya sudah lama keluar dari operasional cloud, tetapi pada masa itu fitur dasar (primitive) antar provider sedang diseimbangkan. Saya penasaran apakah redundansi multi-cloud terlalu mahal, celah teknisnya terlalu jauh, atau memang tak perlu dipertimbangkan dari sisi bisnis. slide pets vs cattle
Deploy dan operasi di beberapa cloud jadi beban manajemen dan beban kognitif tim yang besar. Menjaga keahlian untuk infrastruktur lebih dari dua cloud juga butuh banyak orang. Tim kecil atau tim yang bergerak cepat tidak cocok untuk itu. Kesederhanaan memakai satu cloud langsung berdampak ke uptime. Perusahaan besar juga sebagian besar diuntungkan dengan pembelian dalam skala besar di satu cloud untuk menurunkan harga. Dan tidak ada yang dipecat karena memilih AWS.
Multi-cloud pun tidak efektif jika cloud lain tidak bisa respons saat region-nya bermasalah. Penyedia masih tetap memaksakan 100% standarnya sendiri, dan control plane-nya pun Kubernetes. Pada akhirnya, hampir semuanya berhenti di Kubernetes.
Semua cloud memberikan komputing murah, tetapi egress jaringan sangat mahal. Jika membangun konfigurasi multi-cloud, biaya traffic akan meledak. Saya kira itu mungkin sengaja.
Nyatanya, sepertinya cloud memang mendapatkan pendapatan dari biaya egress. Karena itu, multi-cloud, bahkan redundansi antar region dan AZ dalam satu cloud, terasa terlalu mahal untuk banyak cloud dan aplikasi. Kalau ada outage global di satu cloud, redundansi region di dalam cloud itu pun tak berguna. Selain itu, saat satu cloud down, memindahkan traffic ke cloud lain juga sulit dan kerja tambahannya terlalu besar dibanding hasilnya. Untuk sebagian besar aplikasi, justru lebih baik menanggung downtime beberapa jam itu dan mengalokasikan uang serta tenaga untuk hal lain.
Banyak pelanggan menyimpan file/data di cloud; jika penyedia dan cloud lain berbeda, mengoperasikan layanan tidak jadi mudah dan malah mempersulit akuisisi pelanggan. Karena penyedia akhirnya jadi standar pasar, pelanggan pun cenderung memusatkan data mereka di cloud tersebut, sehingga sulit membenarkan biaya memakai storage di dua cloud sekaligus. Saya mulai dari niat platform-agnostic, tetapi akhirnya karena semua calon pelanggan memakai cloud yang sama, kompleksitas jadi berkurang.
Tahun ini tak mungkin diprediksi sebelumnya bahwa AWS us-east-1 tak akan mencapai uptime dua angka 9.
Sebagai orang yang sudah memakai AWS hampir 20 tahun, saya tak bisa memahami mengapa memilih us-east-1, padahal ini paling tua, paling banyak trafik, dan paling penting.
Penasaran apakah instance seperti EC2 juga benar-benar terdampak.
Banyak orang berpikir, kalau semuanya down maka otomatis tak bisa menyalahkan siapa pun, tetapi dari pengalaman layanan yang melayani pelanggan biasa, itu tidak berlaku.
Penyebab insiden ini adalah masalah pada sub-sistem internal yang menangani health check network load balancer. Halaman status layanan AWS