AWS Disaster Recovery: Production Sistemleri Kesintilere Nasıl Hazırlanır?

Kısaca

AWS Disaster Recovery, production workload'larının büyük kesinti, veri kaybı veya bölgesel arıza gibi olaylardan sonra belirlenen RTO ve RPO hedefleri içinde geri getirilebilmesi için backup, replication, network, DNS, identity, runbook ve test süreçlerinin birlikte tasarlanmasıdır.

Dynamis Teknoloji'de DR'ı yalnız backup almak olarak değil, uygulamanın gerçekten geri ayağa kalktığını kanıtlayan recovery mimarisi olarak ele alıyoruz.

AWS Disaster Recovery nedir?

Disaster Recovery; bir workload'un kritik arıza sonrası yeniden çalışır hale gelmesi için gereken teknik ve operasyonel planın tamamıdır.

Bu plan yalnız data backup içermez.

Tipik kapsam:

• application
• database
• storage
• network
• DNS
• identity / IAM
• secret
• monitoring
• deployment artifact
• runbook
• test

RTO ve RPO nedir?

RTO

Recovery Time Objective, servisin ne kadar sürede geri gelmesi gerektiğini ifade eder.

Örnek:

• 15 dakika
• 1 saat
• 4 saat

RPO

Recovery Point Objective, kabul edilebilir maksimum veri kaybı penceresini ifade eder.

Örnek:

• 5 dakika
• 1 saat
• 24 saat

RTO ve RPO business tarafından tanımlanmalı, teknik ekip mimariyi bu hedeflere göre tasarlamalıdır.

Backup ile Disaster Recovery aynı şey mi?

Hayır.

Backup:

• verinin kopyasını tutar

Disaster Recovery:

• veriyi geri getirir
• uygulamayı ayağa kaldırır
• network ve DNS'i yönlendirir
• dependency'leri doğrular
• operasyon ekibinin runbook'u uygulamasını sağlar

Backup DR'ın önemli bir bileşenidir ama tek başına DR değildir.

AWS'de temel DR stratejileri

AWS mimarilerinde yaygın olarak dört yaklaşım konuşulur:

Backup & Restore

En düşük sürekli maliyetli yaklaşımlardan biridir.

Kaynaklar kesinti sonrası backup ve IaC/artifact'lar kullanılarak yeniden oluşturulur.

Avantaj:

• düşük sürekli maliyet

Dezavantaj:

• daha uzun RTO

Pilot Light

Kritik data ve bazı temel servisler recovery ortamında sürekli hazır tutulur; compute kapasitesi olay sırasında büyütülür.

Avantaj:

• backup/restore'a göre daha hızlı recovery

Dezavantaj:

• sürekli çalışan minimum altyapı maliyeti

Warm Standby

Recovery ortamında küçültülmüş ama çalışan bir production kopyası bulunur.

Olay sırasında kapasite artırılır.

Avantaj:

• daha kısa RTO

Dezavantaj:

• daha yüksek sürekli maliyet

Multi-site / Active-Active

Birden fazla environment veya Region aynı anda production trafiği taşıyabilir.

Avantaj:

• çok düşük RTO potansiyeli

Dezavantaj:

• en yüksek maliyet ve operasyon karmaşıklığı

Her workload için en pahalı DR modeli doğru değildir.

Multi-AZ ile Multi-Region farkı

Multi-AZ

Aynı AWS Region içindeki Availability Zone'lar arasında resilience sağlar.

Tipik kullanım:

• AZ failure
• infrastructure failure

Multi-Region

Farklı AWS Region'lar arasında recovery veya active architecture sağlar.

Tipik kullanım:

• regional disaster
• data residency veya business continuity gereksinimleri

Multi-Region daha yüksek maliyet ve operasyon karmaşıklığı oluşturabilir.

Her workload için multi-Region gerekli mi?

Hayır.

Karar şu faktörlere göre verilmelidir:

• business criticality
• kabul edilebilir downtime
• RTO
• RPO
• compliance
• data residency
• bütçe

Küçük veya düşük kritik workload için same-Region multi-AZ + test edilmiş backup/restore yeterli olabilir.

AWS Elastic Disaster Recovery ne işe yarar?

AWS Elastic Disaster Recovery, source server'ları düşük maliyetli staging ortamına sürekli replicate edip disaster veya drill sırasında recovery instance'ları başlatmaya yardımcı olan AWS servisidir.

Bu yaklaşım özellikle server-based workload recovery senaryolarında değerlendirilebilir.

Ancak application-level dependency, database consistency, DNS ve operational runbook yine ayrıca planlanmalıdır.

AWS Backup DR içinde nasıl kullanılır?

AWS Backup, farklı AWS resource tipleri için merkezi backup policy ve lifecycle yönetimi sağlamaya yardımcı olabilir.

Kontrol edilmesi gerekenler:

• backup frequency
• retention
• cross-account backup
• cross-Region copy
• encryption
• restore test

Backup policy RPO hedefiyle uyumlu olmalıdır.

Cross-account backup neden önemli olabilir?

Aynı account'taki operational hata veya yetki problemi backup'ları da etkileyebilir.

İhtiyaca göre backup'ların ayrı AWS account'ta tutulması blast radius'u azaltabilir.

Ancak IAM, KMS ve recovery access ayrıca test edilmelidir.

Cross-Region backup ne zaman gerekli?

Regional event senaryosuna karşı recovery planlanıyorsa backup veya replication başka Region'a taşınabilir.

Ancak:

• data transfer
• storage
• compliance
• recovery network

maliyetleri hesaba katılmalıdır.

Database Disaster Recovery

Database DR workload'a göre farklı tasarlanabilir.

Seçenekler:

• snapshot / backup restore
• read replica
• cross-Region replica
• native database replication
• managed multi-AZ

RPO hedefi ne kadar düşükse replication gereksinimi genellikle artar.

EC2 Disaster Recovery

EC2 workload'larında DR planı şu bileşenleri kapsamalıdır:

• AMI veya deployment artifact
• EBS snapshot / replication
• VPC
• security group
• IAM role
• load balancer
• DNS
• user data / automation

Tek EC2 instance backup'ı, tüm application environment'ı geri kurmak için yeterli olmayabilir.

Infrastructure as Code DR için neden önemli?

IaC, recovery ortamının aynı network ve resource modeliyle daha hızlı yeniden oluşturulmasını sağlar.

Örnek araçlar:

• CloudFormation
• Terraform

Ancak IaC repository'nin de erişilebilir ve güncel olması gerekir.

DNS failover

Disaster Recovery sırasında trafiğin recovery endpoint'e yönlendirilmesi gerekir.

Route 53 health check ve routing policy'leri uygun senaryolarda failover sürecine katkı sağlayabilir.

DNS TTL değeri recovery süresini etkileyebilir ancak tek başına zero downtime sağlamaz.

Secrets ve configuration

Application ayağa kalksa bile secret veya configuration eksikse recovery başarısız olabilir.

Recovery planında:

• Secrets Manager
• Parameter Store
• KMS
• environment configuration

erişimi doğrulanmalıdır.

Monitoring DR sırasında neden önemli?

Recovery sırasında yalnız instance'ın çalışıyor olması yeterli değildir.

Doğrulayın:

• application health
• HTTP success rate
• latency
• database connectivity
• queue backlog
• background worker
• backup status

AWS CloudWatch Nedir? monitoring ve alarm katmanını ayrıntılı açıklar.

Disaster Recovery runbook

Runbook adım adım uygulanabilir olmalıdır.

Örnek:

1. incident declaration
2. source environment health check
3. recovery decision
4. database/data recovery
5. compute activation
6. network / DNS change
7. application test
8. user validation
9. production traffic switch
10. monitoring

DR planı test edilmezse ne olur?

Dokümantasyon zamanla eskiyebilir.

Örneğin:

• resource ID değişir
• IAM role silinir
• subnet değişir
• DNS kaydı güncellenir
• backup restore permission bozulur

Bu yüzden düzenli recovery testleri kritik önemdedir.

Tabletop test nedir?

Tabletop test teknik failover yapmadan ekibin incident senaryosunu ve runbook'u masa başında yürütmesidir.

Kontrol edilir:

• owner kim?
• karar kimde?
• hangi adımlar izlenecek?
• dependency listesi güncel mi?

Teknik DR drill

Gerçek veya izole recovery ortamında backup restore ve workload ayağa kaldırma süreci test edilir.

Ölçülmesi gerekenler:

• gerçek RTO
• gerçek RPO
• failed step
• manual intervention
• validation time

Failback planı

Recovery site'a geçiş kadar primary environment'a dönüş de planlanmalıdır.

Failback sırasında:

• data synchronization
• maintenance window
• DNS
• rollback

yeniden değerlendirilmelidir.

AWS Disaster Recovery maliyeti nasıl oluşur?

Toplam maliyet:

• backup storage
• replication
• standby compute
• database replica
• cross-Region data transfer
• network
• monitoring
• DR drill

kalemlerinden oluşabilir.

RTO/RPO hedefi agresifleştikçe sürekli maliyet genellikle artar.

DR maliyetini nasıl optimize edersiniz?

Her workload'u aynı seviyede korumayın.

Tier oluşturun:

• Tier 1: kritik, düşük RTO/RPO
• Tier 2: önemli, orta RTO/RPO
• Tier 3: düşük kritik, backup/restore

Bu yaklaşım DR bütçesini business criticality ile eşleştirir.

Disaster Recovery ve High Availability farkı

High Availability günlük infrastructure failure sırasında servisin çalışmaya devam etmesini hedefler.

Disaster Recovery ise daha büyük kesinti sonrası servisin geri kazanılmasına odaklanır.

İkisi birbirini tamamlar.

AWS Well-Architected Framework Nedir? reliability kararlarını daha geniş mimari perspektifte ele alır.

Production AWS DR checklist

• workload tier
• RTO
• RPO
• dependency inventory
• backup
• replication
• restore test
• cross-account ihtiyacı
• cross-Region ihtiyacı
• IaC
• DNS
• IAM
• secrets
• monitoring
• runbook
• drill
• failback
• owner

Dynamis AWS DR yaklaşımı

Dynamis ihtiyaca göre:

• RTO/RPO workshop
• architecture review
• backup strategy
• replication
• cross-account / cross-Region tasarım
• recovery runbook
• DR drill
• monitoring
• failback planı

alanlarını yönetebilir.

AWS yönetim hizmeti, Disaster Recovery'yi günlük AWS operasyonu, backup, monitoring, security ve incident response ile birlikte ele alır.

Genel Disaster Recovery prensipleri için Disaster Recovery nedir? rehberine bakabilirsiniz.

Sık yapılan hatalar

Backup var, DR hazır sanmak: Application ve dependency recovery ayrıca test edilmelidir.

RTO/RPO belirlemeden mimari seçmek: Business hedefleri önce gelmelidir.

Her workload'a multi-Region kurmak: Maliyet ve complexity iş kritikliğiyle eşleşmelidir.

Runbook'u test etmemek: Dokümantasyon zamanla eskiyebilir.

Failback'i unutmamak: Primary site'a dönüş planı da DR'ın parçasıdır.

Sonuç

AWS Disaster Recovery'nin amacı en karmaşık mimariyi kurmak değil, business tarafından belirlenen RTO ve RPO hedeflerine güvenilir biçimde ulaşmaktır.

Backup, replication, network, IAM, DNS, monitoring, runbook ve test süreçleri birlikte tasarlanmadıkça gerçek recovery hazırlığı oluşmaz.

Sırada ne var

• Disaster Recovery nedir?
• 3-2-1 Yedekleme Kuralı
• AWS Well-Architected Framework Nedir?
• AWS CloudWatch Nedir?
• AWS yönetim hizmeti

Kaynaklar

• AWS Disaster Recovery of Workloads on AWS
• Disaster recovery options in the cloud
• What is AWS Elastic Disaster Recovery?
• AWS Backup Developer Guide
• Reliability Pillar — Disaster Recovery