Birincil Bölgede bir ALB'nin arkasındaki EC2 örneklerinde çok katmanlı bir web uygulaması çalıştırıyorsunuz. ALB ve Auto Scaling grubu bir yedek Bölgede çoğaltılır, ancak Auto Scaling grubunun minimum ve maksimum değerleri sıfıra ayarlanmıştır. Bir RDS Multi-AZ örneği verileri depolar ve yedek Bölgede bir okuma replikasına sahiptir. Route 53 kullanıcı uç noktasını sağlar. RTO'yu 15 dakikanın altına düşürmeniz ve etkin-etkin bir strateji olmadan yedek Bölgeye otomatik yük devretmeyi etkinleştirmeniz gerekiyor. Ne önermelisiniz?

Bu çözüm, 15 dakikanın altında bir RTO için etkin-pasif bir afet kurtarma stratejisi sağlar. Route 53 sağlık denetimi, birincil bölgedeki web uygulamasını izler ve başarısız olduğunda Route 53 yük devretme yönlendirmesi trafiği yedek bölgedeki ALB'ye yönlendirir. Aynı zamanda, birincil bölgedeki sağlık denetimi başarısız olduğunda tetiklenen bir Lambda işlevi, yedek bölgedeki RDS okuma replikasını ana veritabanına yükseltir ve Auto Scaling grubunun minimum/maksimum değerlerini güncelleyerek EC2 örneklerini başlatır. Diğer seçenekler neden yanlış: Birinci seçenek, gecikme tabanlı yönlendirme kullandığı için etkin-etkin bir stratejidir ve bu, soruda belirtilen "etkin-etkin bir strateji olmadan" gereksinimini karşılamaz. Ayrıca, CloudWatch alarmı yalnızca 5XX hatalarını izler ve uygulamanın tamamen erişilemez olduğu senaryoları kapsamayabilir. Üçüncü seçenek, yedek bölge Auto Scaling grubunu sürekli çalışır durumda tutarak maliyeti artırır ve etkin-pasif stratejiye uymaz. RDS okuma replikasını kaldırmak ve S3 ile yedekleme yapmak, RTO'yu 15 dakikanın üzerine çıkarabilir. Dördüncü seçenek, AWS Global Accelerator'ı eşit ağırlıklarla kullanmak yine etkin-etkin bir stratejiye işaret eder. Ayrıca, CloudWatch alarmı yalnızca 5XX hatalarını izler ve uygulamanın tamamen erişilemez olduğu senaryoları kapsamayabilir.