AWS'de Felaket Kurtarma: RTO, RPO ve 4 Stratejinin Karşılaştırması
"Bulut güvenilirdir" ile "verimiz güvende" iki ayrı cümledir. AWS dayanıklılık için olağanüstü yapı taşları verir — ve hiçbiri varsayılan olarak açık değildir. Müşterilerimiz için DR kurulumları tasarlayıp işletiyoruz; bizzat müdahale ettiğimiz olaylar yüzünden kurduğumuz değiştirilemez (immutable), hesaplar-arası yedek kasaları dahil. Bu rehber, o saha tecrübesini gerçekten önemli olan kararlara indiriyor: iki sayı, dört strateji ve tekrar tekrar gördüğümüz hatalar.
Her şeyi belirleyen iki sayı: RTO ve RPO
- RTO (Kurtarma Süresi Hedefi): Ne kadar süre kapalı kalabilirsiniz? "Sistem 4 saat içinde dönmeli" = 4 saatlik RTO.
- RPO (Kurtarma Noktası Hedefi): Ne kadar veri kaybını göze alabilirsiniz? "En fazla son 15 dakika" = 15 dakikalık RPO.
Her DR kararı, bu iki sayıya biçilen fiyattır — sayılar küçüldükçe maliyet kabaca üstel artar. En pahalı hata yavaş bir strateji seçmek değil, iş birimine bu sayıların gerçekte ne olduğunu hiç sormamış olmaktır. Sistem sistem sorun: tanıtım siteniz ile ödeme hattınız aynı RTO'yu paylaşmaz.
4 AWS DR stratejisi
| Strateji | Nasıl çalışır | Tipik RTO | Tipik RPO | Göreli maliyet |
|---|---|---|---|---|
| Backup & restore | Başka bölge/hesaba düzenli yedek; felakette yeniden kur | Saatler | Saatler (son yedek) | $ — yalnız depolama |
| Pilot light | Çekirdek veri sürekli replike; asgari altyapı bekler, felakette büyütülür | On dakikalar–saatler | Dakikalar | $$ |
| Warm standby | Küçültülmüş ama tam işlevsel kopya sürekli çalışır; büyüt + trafiği çevir | Dakikalar | Saniyeler–dakikalar | $$$ |
| Multi-site aktif/aktif | Birden çok bölgede tam kapasite canlı trafik; arıza yalnızca trafiği kaydırır | Sıfıra yakın | Sıfıra yakın | $$$$ |
Dürüst rehberlik: çoğu şirketin çoğu sistemi için doğru yapılmış backup & restore, gerçekten bekleyemeyen bir-iki sistem için pilot light ya da warm standby yeter. Multi-site aktif/aktif, dakika-başına-ciro işleri içindir; onu her şeye almak DR bütçelerinin ölüm şeklidir. Ucuz stratejileri inandırıcı kılan şey altyapının kod olmasıdır (IaC ve GitOps rehberimiz): "sıfırdan kur" ancak kurulum bir pipeline'sa hızlıdır, bir insanın hafızasıysa değil.
Kötü günü atlatabilen yedekler
Yukarıdaki stratejiler, yedeklerin ihtiyaç anında var olduğunu varsayar. Gerçekten çalıştığımız olaylardan üç kural:
- Hesaplar-arası, sadece bölgeler-arası değil. Yedekler üretimle aynı hesaptaysa, hesaba erişen saldırgan ikisini birden siler — tam olarak bunun denendiğini gördük. Kendi kimlik bilgileri ve asgari güven ilişkisi olan ayrı, kilitli bir yedek hesabı, tek başına en yüksek değerli DR yükseltmesidir. Bu argümanın saldırı tarafı AWS ihlal playbook'umuzda.
- Değiştirilemez, sadece kopyalanmış değil. S3 Object Lock (compliance modu), yedekleri belirlenen saklama süresi boyunca kimse tarafından silinemez kılar — root dahil, admin kimlik bilgilerini ele geçirmiş fidye yazılımı dahil. Bu deseni müşterilerimiz için üretimde bizzat işletiyoruz; çünkü "saldırgan yedekleri de sildi" bir düşünce deneyi değil, gerçek bir arıza modudur.
- 3-2-1 hâlâ geçerli: üç kopya, iki farklı sistem, biri uzakta (bulut karşılığı: başka hesap ve bölge). Tek başına RDS otomatik yedekleri, tek yerde tek kopyadır.
Test edilmemiş DR planı, plan değil temennidir
Restore testi planın kendisidir. Takvime bağlayın: çeyrekte bir, bir veritabanı yedeğini temiz bir instance'a geri yükleyip süreyi ölçün; yılda bir, birincil bölgenin kaybını simüle eden bir tatbikat (game day) yapın. Bugüne kadar elimize geçen her DR dokümanında artık çalışmayan en az bir adım vardı — süresi dolmuş kimlik, adı değişmiş kaynak, ayrılmış birine referans veren runbook. Bunları ya sakin bir salı günü bulursunuz ya felaket sırasında; üçüncü seçenek yok.
Olayı felakete çeviren hatalar
- Patlama yarıçapındaki yedekler — aynı hesap, aynı kimlikler; aynı saldırgan ya da aynı yanlış script tarafından silinebilir.
- RDS snapshot'ını DR planı sanmak — veriyi kapsar; trafiği gerçekten karşılamak için gereken VPC, IAM, DNS, secret ve konfigürasyonu kapsamaz.
- DNS'in sona bırakılması — baskı altında elle kayıt düzenlemek isteyen failover, her RTO'ya bir saat ekler. Health-check'li Route 53 failover yönlendirmesi ucuzdur.
- Failover etmeyen secret'lar — uygulama yedek bölgede kimlik doğrulayamıyorsa o bölge işe yaramaz. Secret'ları bilinçli replike edin.
- Planın tek sahibi olması — runbook birinin kafasındaysa, gerçek RTO'nuz onun izin takvimini içerir.
Sık sorulan sorular
RTO ile RPO arasındaki fark nedir?
RTO kurtarmanın ne kadar sürebileceğidir (kesinti toleransı); RPO ne kadar güncel veri kaybedebileceğinizdir (yedek/replikasyon sıklığı). İkisi de iş birimi tarafından sistem bazında belirlenir; her DR mimari kararı bu ikiliye göre fiyatlanır.
Hangi AWS DR stratejisini seçmeliyiz?
Çoğu sistem için doğru yapılmış backup & restore; saatler bekleyemeyen az sayıda sistem için pilot light ya da warm standby. Tek strateji her şeye değil — sistem bazında gerçek RTO/RPO'ya göre seçin.
Yedekler fidye yazılımına karşı korur mu?
Ancak saldırgan silemiyorsa: hesaplar-arası izolasyon + S3 Object Lock değiştirilemezliği tutan desendir. Aynı hesaptaki silinebilir yedekler, tam da en çok ihtiyaç duyduğunuz anda çöker.
DR ne sıklıkla test edilmeli?
Çeyreklik ölçümlü restore testleri; yılda en az bir tam failover tatbikatı. Test edilmemiş plan, güvenilir biçimde artık çalışmayan adımlar içerir.
Özet
DR satın alınan bir ürün değil; seçtiğiniz iki sayı ve onlara karşı dürüstçe yapılan mühendisliktir: temel olarak hesaplar-arası değiştirilemez yedekler, sistem başına doğru strateji katmanı, DNS ve secret'lar dahil, takvimde bir restore testi. Bunu yapın; çoğu "felaket", runbook'u olan bir olaya dönüşür.
DR duruşunuzu bunu üretimde işleten bir ekibe göstermek ister misiniz? Yedekleme ve DR tasarımı AWS Yönetilen Hizmetlerimizin parçası; Güvenlik Denetimi 98 maddesi arasında yedek izolasyonu ve değiştirilemezliği de kontrol eder. Ücretsiz sağlık taraması, yedeklerinizin en kötü gününüzü atlatıp atlatamayacağını hızla söyler.