AWS Gagal Pulihkan Data di Bahrain, Ini Pelajaran bagi Bisnis

Kerusakan fisik pada infrastruktur Amazon Web Services (AWS) di Bahrain dan Uni Emirat Arab (UEA) menyebabkan sejumlah data dan sumber daya pelanggan tidak dapat dipulihkan. Insiden yang bermula pada Maret tersebut menjadi perhatian terhadap ketahanan infrastruktur cloud, terutama dalam menghadapi gangguan berskala besar yang dapat melumpuhkan beberapa pusat data sekaligus.

AWS mengungkapkan bahwa pihaknya telah kehabisan opsi untuk memulihkan sejumlah data dan sumber daya di Bahrain yang belum dipindahkan sebelum Region tersebut tidak lagi tersedia. Sementara itu, di UEA, perusahaan menyatakan tidak dapat memulihkan akses ke data dan sumber daya yang hanya tersimpan di satu Availability Zone tertentu.

Dalam pembaruan pada 15 September, AWS menyampaikan bahwa kerusakan yang terjadi pada infrastruktur cloud di kawasan Timur Tengah telah menimbulkan dampak serius terhadap operasional layanan. Kondisi tersebut tidak hanya memengaruhi ketersediaan sistem, tetapi juga menyebabkan sebagian data pelanggan tidak dapat diakses kembali melalui infrastruktur yang terdampak.

Insiden ini sekaligus menyoroti pentingnya strategi disaster recovery, backup, serta penerapan arsitektur cloud yang mampu menghadapi gangguan di luar perkiraan. Peristiwa tersebut juga mempertegas bahwa penggunaan layanan cloud tidak sepenuhnya menghilangkan risiko kehilangan data, terutama ketika kerusakan meluas hingga memengaruhi beberapa lokasi infrastruktur.

AWS menjelaskan bahwa Region Bahrain dengan kode me-south-1 memiliki tiga Availability Zone. Namun, kerusakan fisik yang terjadi pada infrastruktur di kawasan tersebut berdampak pada lebih dari satu zona, sehingga kemampuan pemulihan yang tersedia tidak lagi mencukupi untuk mengembalikan seluruh layanan dan data.

Gangguan ini bermula pada Maret ketika infrastruktur AWS di Bahrain dan UEA mengalami kerusakan akibat serangan. Berdasarkan informasi AWS yang dikutip Reuters, insiden tersebut mengakibatkan kerusakan fisik pada infrastruktur cloud dan mengganggu layanan di kedua negara.

Setelah Availability Zone pertama di Bahrain mengalami kerusakan, AWS segera menyarankan pelanggan untuk memindahkan beban kerja (workload) mereka ke Region lain. Langkah ini dilakukan untuk mengurangi dampak gangguan dan menjaga agar layanan pelanggan tetap dapat beroperasi.

Menurut laporan Reuters, sebagian besar pelanggan telah memindahkan beban kerja mereka sebelum kerusakan pada Availability Zone kedua terjadi pada April. Kerusakan lanjutan tersebut kemudian menyebabkan seluruh Region Bahrain tidak dapat diakses.

AWS selanjutnya melakukan penilaian terhadap infrastruktur yang terdampak untuk mengetahui kemungkinan pemulihan layanan dan data. Namun, setelah mengevaluasi berbagai pilihan yang tersedia, perusahaan menyatakan tidak lagi memiliki cara untuk memulihkan sumber daya dan data yang belum dipindahkan sebelum Region Bahrain dinyatakan tidak tersedia.

Pelanggan yang masih terdampak didukung untuk membangun kembali operasional mereka di lokasi lain dengan menggunakan cadangan data yang tersedia maupun metode pemulihan alternatif. Meski demikian, data yang tidak memiliki salinan cadangan atau mekanisme pemulihan lain berisiko tidak dapat dikembalikan.

Kondisi serupa juga terjadi di UEA. AWS mengoperasikan Region Timur Tengah dengan kode me-central-1, yang terdiri dari tiga Availability Zone. Salah satu zona, yakni mec1-az2, mengalami kerusakan sehingga perusahaan menyatakan tidak dapat memulihkan akses ke sumber daya dan data yang hanya dihosting di lokasi tersebut.

Berbeda dengan Bahrain yang seluruh Region-nya tidak tersedia, proses pemulihan di UEA masih berlangsung. AWS terus berupaya memulihkan sumber daya di berbagai bagian Region tersebut, termasuk Availability Zone lain yang turut terdampak.

AWS juga memberikan dukungan kepada pelanggan untuk mengaktifkan kembali operasional mereka di Region alternatif dengan memanfaatkan cadangan data dan mekanisme pemulihan yang tersedia.

Dampak insiden ini tidak terbatas pada pelanggan AWS. Reuters melaporkan bahwa gangguan yang terjadi sejak Maret turut memengaruhi layanan lain, termasuk operasional perbankan. Hal ini menunjukkan besarnya ketergantungan berbagai sektor terhadap infrastruktur digital dan layanan cloud dalam menjalankan aktivitas sehari-hari.

Kerusakan Infrastruktur Menguji Ketahanan Multi-AZ dan Multi-Region

Insiden di Bahrain dan UEA kembali memunculkan perhatian terhadap kemampuan infrastruktur cloud dalam menghadapi gangguan berskala besar. Selama ini, penggunaan layanan cloud dengan arsitektur terdistribusi menjadi salah satu pendekatan untuk menjaga ketersediaan aplikasi dan data ketika terjadi kegagalan infrastruktur.

AWS membedakan dua pendekatan utama dalam menjaga ketahanan layanan, yakni high availability melalui beberapa Availability Zone dan disaster recovery melalui strategi pemulihan yang dapat mencakup beberapa Region.

Dalam panduan AWS Well-Architected, perusahaan merekomendasikan penerapan arsitektur multi-AZ untuk menghadapi gangguan yang hanya memengaruhi satu Availability Zone. Sementara itu, organisasi yang membutuhkan perlindungan dari gangguan yang berdampak pada seluruh Region dapat mempertimbangkan arsitektur pemulihan bencana lintas Region atau multi-Region.

Availability Zone merupakan lokasi fisik yang terpisah di dalam satu Region. Setiap zona memiliki infrastruktur independen, termasuk sistem kelistrikan, jaringan, dan mekanis. Pemisahan ini dirancang untuk mengurangi kemungkinan gangguan pada satu zona memengaruhi zona lainnya.

Dengan mendistribusikan beban kerja ke beberapa Availability Zone, aplikasi dapat tetap beroperasi ketika salah satu zona mengalami kegagalan. Namun, ketahanan tersebut bergantung pada konfigurasi aplikasi, distribusi sumber daya, serta kesiapan mekanisme pengalihan layanan.

Sebagai contoh, perusahaan dapat menempatkan aplikasi dan basis data pada beberapa Availability Zone sehingga ketika salah satu lokasi mengalami gangguan, lalu lintas dapat dialihkan ke zona lain yang masih beroperasi. Pendekatan ini dapat mengurangi risiko terhentinya layanan akibat kegagalan infrastruktur di satu lokasi.

Namun, insiden di Bahrain memperlihatkan bahwa arsitektur multi-AZ memiliki batas perlindungan. AWS menyatakan bahwa kerusakan yang terjadi meluas hingga memengaruhi beberapa Availability Zone dan melampaui kemampuan yang dirancang untuk ditangani oleh layanan regional maupun multi-AZ.

Situasi tersebut menunjukkan bahwa pemisahan infrastruktur dalam satu Region belum tentu cukup untuk menghadapi gangguan yang berdampak luas. Ketika beberapa Availability Zone mengalami kerusakan secara bersamaan, organisasi membutuhkan mekanisme pemulihan tambahan agar dapat mempertahankan operasional.

Dalam kondisi tersebut, strategi multi-Region dapat menjadi salah satu pilihan. Dengan menempatkan sumber daya dan salinan data di Region yang berbeda secara geografis, organisasi memiliki alternatif lokasi untuk menjalankan layanan apabila Region utama mengalami gangguan serius.

Meski demikian, perlindungan lintas Region tidak tersedia secara otomatis. Pelanggan perlu merancang dan mengonfigurasi strategi pemulihan secara mandiri sesuai dengan kebutuhan bisnis dan tingkat risiko yang dapat diterima.

AWS menyediakan layanan AWS Backup yang memungkinkan pelanggan menyalin cadangan data ke Region lain, baik secara manual maupun melalui jadwal pencadangan otomatis. Mekanisme ini dapat membantu organisasi memenuhi kebutuhan business continuity sekaligus persyaratan kepatuhan yang mengharuskan pemisahan geografis antara data produksi dan salinan pemulihan.

Selain pencadangan, organisasi juga dapat menerapkan replikasi data untuk menjaga agar salinan data di lokasi alternatif tetap diperbarui. Namun, AWS menekankan bahwa replikasi dan pencadangan memiliki fungsi yang berbeda dalam strategi pemulihan bencana.

Replikasi memungkinkan data disalin secara berkelanjutan dari sistem utama ke lokasi lain. Sementara itu, pencadangan menyediakan salinan data yang dapat digunakan untuk memulihkan sistem ke kondisi pada titik waktu tertentu.

Perbedaan ini menjadi penting karena replikasi secara terus-menerus dapat ikut menyalin perubahan yang tidak diinginkan, termasuk penghapusan data, kesalahan konfigurasi, atau kerusakan yang terjadi pada sistem utama.

Oleh karena itu, AWS merekomendasikan agar organisasi tetap melakukan pencadangan terhadap data yang telah direplikasi di lokasi pemulihan. Dengan cara tersebut, perusahaan memiliki pilihan untuk mengembalikan data ke kondisi sebelum gangguan terjadi melalui mekanisme point-in-time recovery.

Kombinasi antara replikasi dan pencadangan dapat memberikan lapisan perlindungan tambahan, terutama bagi organisasi yang mengelola data penting dan membutuhkan tingkat ketersediaan layanan yang tinggi.

AWS dan Pelanggan Memiliki Tanggung Jawab Berbeda

Di balik insiden tersebut, terdapat aspek penting lain yang perlu diperhatikan, yakni pembagian tanggung jawab antara penyedia layanan cloud dan pelanggan. AWS menerapkan model shared responsibility yang membedakan kewajiban dalam pengelolaan infrastruktur cloud dan perlindungan beban kerja pelanggan.

Dalam model ini, AWS bertanggung jawab terhadap keamanan dan ketahanan infrastruktur dasar yang mendukung layanan cloud. Tanggung jawab tersebut mencakup pengelolaan fasilitas fisik, perangkat keras, jaringan, dan infrastruktur pendukung lainnya.

Sementara itu, pelanggan bertanggung jawab mengonfigurasi aplikasi, mengelola data, serta merancang sistem agar memenuhi kebutuhan keamanan dan pemulihan masing-masing.

Pada layanan Amazon EC2, misalnya, pelanggan bertanggung jawab menentukan lokasi penerapan instans, mendistribusikan beban kerja ke lokasi yang sesuai, mengonfigurasi mekanisme pemulihan, dan membangun aplikasi yang mampu menghadapi gangguan.

Adapun pada layanan terkelola seperti Amazon S3 dan Amazon DynamoDB, AWS menangani infrastruktur dan platform yang mendasarinya. Namun, pelanggan tetap bertanggung jawab menentukan strategi ketahanan data, termasuk pencadangan, pengaturan versi (versioning), dan replikasi sesuai kebutuhan.

AWS menyebutkan bahwa sebagian besar beban kerja dapat memenuhi kebutuhan ketahanan dengan menggunakan beberapa Availability Zone dalam satu Region. Namun, untuk aplikasi yang harus tetap beroperasi ketika seluruh Region mengalami gangguan, organisasi perlu mengevaluasi penerapan arsitektur multi-Region.

Pembagian tanggung jawab ini menunjukkan bahwa meskipun penyedia cloud menyediakan infrastruktur dengan tingkat ketahanan tertentu, pelanggan tetap perlu memastikan bahwa data dan aplikasi mereka memiliki perlindungan yang memadai.

Dengan demikian, organisasi tidak cukup hanya mengandalkan jaminan ketersediaan dari penyedia cloud. Perencanaan pencadangan, pengujian pemulihan, dan penentuan lokasi penyimpanan data tetap menjadi bagian penting dari pengelolaan sistem.

RTO dan RPO Menentukan Strategi Pemulihan

Perencanaan pemulihan bencana tidak hanya berkaitan dengan teknologi yang digunakan, tetapi juga target waktu dan jumlah kehilangan data yang dapat ditoleransi oleh organisasi.

Dua parameter utama yang digunakan dalam perencanaan tersebut adalah Recovery Time Objective (RTO) dan Recovery Point Objective (RPO).

Recovery Time Objective (RTO) merupakan batas waktu maksimal yang ditetapkan organisasi untuk memulihkan sistem setelah terjadi gangguan. Parameter ini menentukan seberapa cepat layanan harus kembali beroperasi agar dampak terhadap kegiatan bisnis tetap terkendali.

Sementara itu, Recovery Point Objective (RPO) menentukan batas kehilangan data yang dapat ditoleransi berdasarkan titik waktu pemulihan. Parameter ini berkaitan dengan seberapa sering data perlu dicadangkan atau direplikasi agar kehilangan data akibat gangguan tidak melampaui batas yang telah ditentukan.

Sebagai contoh, perusahaan yang menetapkan RTO selama satu jam harus memiliki mekanisme yang memungkinkan sistem kembali beroperasi dalam waktu maksimal satu jam setelah gangguan. Jika RPO ditetapkan selama 15 menit, perusahaan harus memastikan bahwa data dapat dipulihkan dengan kehilangan perubahan maksimal sekitar 15 menit sebelum gangguan.

Penentuan RTO dan RPO akan memengaruhi pilihan arsitektur pemulihan, kebutuhan infrastruktur, serta besarnya biaya yang harus dialokasikan.

AWS mendokumentasikan beberapa pendekatan pemulihan bencana untuk memenuhi target tersebut, mulai dari backup and restore, konfigurasi standby, hingga penerapan active-active multi-Region. Masing-masing pendekatan memiliki karakteristik, kebutuhan sumber daya, tingkat kompleksitas, dan waktu pemulihan yang berbeda.

Perbedaan Backup and Restore, Standby, dan Active-Active

Pendekatan backup and restore merupakan metode pemulihan dengan menyimpan salinan data tanpa harus menyediakan lingkungan produksi duplikat secara lengkap. Ketika terjadi gangguan, organisasi menggunakan cadangan tersebut untuk membangun kembali sistem dan mengaktifkan layanan.

Strategi ini umumnya membutuhkan biaya infrastruktur yang lebih rendah selama operasional normal karena organisasi tidak perlu menjalankan lingkungan cadangan secara penuh. Namun, proses pemulihan dapat membutuhkan waktu lebih lama karena sistem harus dibangun atau diaktifkan kembali setelah insiden terjadi.

Berbeda dengan pendekatan tersebut, konfigurasi standby menyediakan infrastruktur cadangan di lokasi pemulihan. Infrastruktur ini dapat dijalankan dalam kapasitas terbatas atau dalam kondisi siaga, kemudian ditingkatkan ketika sistem utama mengalami gangguan.

Dengan adanya infrastruktur yang telah disiapkan, organisasi dapat mengurangi waktu yang diperlukan untuk memulihkan layanan. Meski demikian, konfigurasi standby memerlukan biaya tambahan untuk mempertahankan sumber daya di lokasi alternatif.

Sementara itu, arsitektur active-active memungkinkan sistem beroperasi secara aktif di beberapa Region secara bersamaan. Dalam konfigurasi ini, lalu lintas aplikasi dapat didistribusikan ke beberapa lokasi sehingga ketika salah satu Region mengalami gangguan, layanan dapat dialihkan ke Region lain yang masih beroperasi.

Pendekatan active-active dapat mengurangi ketergantungan terhadap satu Region, tetapi membutuhkan perencanaan yang lebih kompleks. Organisasi perlu memastikan konsistensi data, pengelolaan lalu lintas, sinkronisasi antarlokasi, serta mekanisme pengalihan layanan berjalan dengan baik.

AWS melalui Prescriptive Guidance menjelaskan bahwa penggunaan Region standby dengan infrastruktur yang sepenuhnya tersedia dan memiliki kapasitas sebanding dengan Region utama dapat meningkatkan biaya infrastruktur hingga sekitar dua kali lipat.

Selain biaya, penerapan multi-Region juga membutuhkan pengelolaan ketergantungan antarlayanan, proses failover atau pengalihan operasional, serta failback untuk mengembalikan layanan ke lokasi utama setelah gangguan teratasi.

Organisasi juga perlu melakukan pengujian pemulihan secara berkala untuk memastikan seluruh mekanisme dapat berjalan sesuai rencana. Tanpa pengujian yang memadai, sistem cadangan berisiko tidak dapat berfungsi sebagaimana mestinya ketika benar-benar dibutuhkan.

Kedaulatan Data Membatasi Pemulihan Lintas Region

Selain faktor teknis dan biaya, strategi pemulihan bencana juga harus mempertimbangkan persyaratan lokasi data residency.

Sejumlah sektor memiliki regulasi yang mengatur agar data tertentu hanya disimpan dan diproses di wilayah geografis yang telah ditentukan. Persyaratan ini dapat membatasi kemampuan organisasi untuk memindahkan data ke Region lain ketika terjadi gangguan.

Dalam panduan yang diterbitkan pada Agustus 2026, AWS menyebutkan bahwa sektor pemerintahan, layanan keuangan, kesehatan, ketenagalistrikan, dan utilitas dapat menghadapi pembatasan terkait lokasi penyimpanan data penting serta infrastruktur pemulihan.

Untuk memenuhi kebutuhan tersebut, AWS menguraikan sejumlah alternatif, seperti replikasi data terenkripsi apabila diizinkan oleh regulasi, penggunaan infrastruktur pemulihan dalam negeri melalui AWS Outposts, serta penerapan lingkungan pemulihan di luar AWS.

AWS Outposts memungkinkan organisasi menggunakan infrastruktur AWS di lokasi mereka sendiri atau fasilitas yang memenuhi persyaratan tertentu. Solusi ini dapat menjadi pilihan bagi perusahaan yang harus mempertahankan infrastruktur dan data di dalam batas geografis tertentu.

Di sisi lain, penggunaan lingkungan pemulihan di luar AWS dapat menjadi alternatif bagi organisasi yang ingin mengurangi ketergantungan terhadap satu penyedia cloud.

Pemilihan pendekatan pemulihan harus mempertimbangkan regulasi yang berlaku, kebutuhan operasional, tingkat ketahanan yang ditargetkan, serta kemampuan organisasi dalam mengelola infrastruktur alternatif.

Bagi organisasi yang bergerak di sektor kritis, aspek kedaulatan data menjadi bagian penting dalam perencanaan pemulihan. Strategi yang secara teknis memungkinkan belum tentu dapat diterapkan apabila bertentangan dengan ketentuan penyimpanan dan pemrosesan data.

AWS Belum Memastikan Pemulihan Region Bahrain

Hingga pembaruan terakhir, AWS belum menetapkan tanggal pasti untuk memulihkan operasional Region Bahrain. Perusahaan menyatakan akan memberikan pembaruan berikutnya mengenai kondisi infrastruktur di wilayah tersebut pada awal 2027.

Sementara itu, proses pemulihan di UEA masih terus berlangsung. AWS berupaya memulihkan sumber daya di berbagai bagian Region yang terdampak sekaligus membantu pelanggan membangun kembali operasional mereka melalui lokasi alternatif.

Insiden ini menjadi pengingat bahwa ketahanan layanan cloud tidak hanya ditentukan oleh infrastruktur yang disediakan oleh penyedia layanan, tetapi juga oleh strategi perlindungan data dan kesiapan pemulihan yang diterapkan pelanggan.

Penerapan multi-AZ dapat membantu mengurangi dampak gangguan pada satu lokasi, tetapi tidak selalu cukup untuk menghadapi kerusakan yang meluas ke beberapa zona. Dalam situasi tertentu, penggunaan multi-Region, pencadangan terpisah, dan mekanisme pemulihan alternatif diperlukan untuk menjaga kelangsungan operasional.

Bagi perusahaan yang mengandalkan cloud untuk menjalankan layanan penting, penetapan RTO dan RPO, pemilihan strategi pencadangan, serta pengujian pemulihan secara berkala menjadi bagian penting dari perencanaan bisnis.

Kasus Bahrain dan UEA juga memperlihatkan bahwa ketersediaan layanan dan kemampuan memulihkan data merupakan dua hal yang berbeda. Sebuah sistem mungkin dirancang agar tetap beroperasi ketika satu komponen mengalami kegagalan, tetapi belum tentu mampu bertahan ketika gangguan memengaruhi sebagian besar infrastruktur dalam satu wilayah.

Oleh karena itu, organisasi perlu mengevaluasi kembali strategi ketahanan cloud mereka, termasuk memastikan ketersediaan salinan data di lokasi terpisah, memahami batas tanggung jawab penyedia layanan, serta menyiapkan rencana pemulihan yang sesuai dengan risiko operasional.

Dengan perencanaan yang tepat, organisasi dapat mengurangi dampak gangguan infrastruktur, mempercepat pemulihan layanan, dan menjaga keberlangsungan bisnis meskipun menghadapi insiden yang tidak terduga.