AWS kalıcı veri kaybını doğruladı: Multi-AZ kurulum neden yedek sayılmaz?

Ne oldu?

Mart 2026’da İran’ın drone saldırıları, AWS’nin Bahreyn ve Birleşik Arap Emirlikleri’ndeki veri merkezlerine zarar verdi. Haberlere göre Bahreyn’deki tesisler sonraki aylarda tekrar hedef alındı. Aylarca süren kurtarma çalışmasından sonra AWS, Eylül ortasında AWS Health Dashboard üzerinden şunu açıkladı:

• Orta Doğu (Bahreyn) bölgesi, me-south-1: Sadece bu bölgede tutulan kaynaklara ve verilere erişim geri getirilemiyor.
• BAE bölgesi, me-central-1: Üç erişilebilirlik alanından biri (mec1-az2) için aynı durum geçerli. Diğer iki alan toparlanıyor.

AWS’nin ifadesiyle hasar, bölgesel ve çoklu alan servislerinin dayanacak şekilde tasarlandığı sınırın ötesine geçti. Müşterilere önerisi: Başka bölgelere taşınmak ve oradaki yedeklerden geri yüklemek. Yani yedeği başka bir bölgede olmayanlar için veri gitti.

Bölge ve erişilebilirlik alanı farkı

AWS’de iki katman var:

• Bölge (Region): Coğrafi bir alan. Örneğin Frankfurt ya da Bahreyn.
• Erişilebilirlik alanı (Availability Zone, AZ): Bir bölgenin içindeki, elektriği, soğutması ve ağı ayrı olan veri merkezi grupları. Genelde bir bölgede üç tane bulunur ve birbirlerine yakındır.

“Multi-AZ” dediğimiz kurulumlar, örneğin iki alana dağıtılmış bir veritabanı, bir veri merkezinin yanması, elektriğin kesilmesi gibi yerel arızalara karşı koruma sağlar. Ama bütün alanlar aynı şehirdeyse, bütün bölgeyi etkileyen bir olay hepsini birden götürebilir. Bahreyn’de olan tam olarak buydu.

Yüksek erişilebilirlik ≠ yedek

İki kavram sıkça karıştırılır:

• Yüksek erişilebilirlik: Sistem, bir parça bozulduğunda çalışmaya devam eder. Veriyi anlık olarak başka bir kopyaya yansıtır.
• Yedek: Verinin ayrı, bağımsız ve geri yüklenebilir bir kopyası. Mümkünse başka bir yerde.

Anlık yansıtma, yanlışlıkla silinen bir tabloyu da anında her kopyaya yansıtır. Aynı bölgedeki kopyalar da aynı felakette birlikte gider. Yani yüksek erişilebilirlik yedeğin yerini tutmaz.

AWS’nin paylaşılan sorumluluk modeli de bunu açıkça söyler: Altyapıyı AWS korur, ama verinin nerede ve kaç kopya tutulacağı müşterinin sorumluluğudur.

Pratikte ne yapabilirsin?

AWS’nin felaket kurtarma rehberi birkaç seviye tanımlıyor. En ucuz başlangıç noktası yedekle ve geri yükle (backup & restore):

• EBS disk görüntülerini (snapshot) ve veritabanı yedeklerini başka bir bölgeye kopyala.
• S3’te bölgeler arası replikasyonu aç.
• Mümkünse yedekleri ayrı bir hesapta tut. Böylece ana hesabın ele geçirilse bile yedeklerin güvende kalır.
• Ve en önemlisi: Geri yüklemeyi gerçekten dene. Hiç denenmemiş bir yedek, yedek değil umuttur.

Daha kritik sistemler için ikinci bölgede sürekli çalışan küçük bir kopya (“pilot light”) ya da iki bölgede aynı anda çalışan kurulumlar var. Maliyet arttıkça kurtarma süresi kısalıyor. Her sistemin buna ihtiyacı yok. Ama verini kaybetmeyi göze alamıyorsan, en azından bir kopyası başka bir coğrafyada olmalı. Tek bir alanın düşmesinin bile aynı bölgedeki öbür alanları nasıl zorladığını Google Cloud Londra kesintisi yazısında anlattık. Denenmemiş yedeğin nasıl patladığının en ünlü örneğini GitLab’in 2017 veritabanı kazası yazısında anlattık.

Düşün

• Senin projenin yedekleri nerede duruyor? Asıl sistemle aynı bölgede mi?
• En son ne zaman bir yedeği gerçekten geri yükleyip denedin?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.