Eski bir uygulama AWS'ye taşındı ve özel alt ağlardaki üç EC2 örneğinde (her biri üç AZ'den birinde) çalışıyor. Bu örnekler, üç genel alt ağdaki bir Application Load Balancer (ALB) için hedeflerdir. Uygulamanın, yalnızca tek bir şirket IP adresinden gelen trafiği kabul eden şirket içi sistemleri çağırması gerekiyor. Güvenlik ekibi, yalnızca bu tek IP'yi buluta getirdi ve bunun için bir Elastic IP tahsis etti. Çözüm, uygulamanın şirket içi sistemlere ulaşmasına ve hataları otomatik olarak ele almasına izin vermelidir. Hangi tasarım bu gereksinimleri karşılar?

Doğru cevap, tek bir NAT Gateway kullanır ve Elastic IP'yi ona atar. Uygulama, şirket içi sistemlere erişmek için bu NAT Gateway üzerinden çıkar. CloudWatch özel metrikleri ile NAT Gateway'in sağlığı izlenir. NAT Gateway sağlıksız hale gelirse, bir Lambda işlevi yeni bir NAT Gateway oluşturur ve Elastic IP'yi ona yeniden atayarak otomatik hata işleme ve yüksek erişilebilirlik sağlar. Bu yaklaşım, şirket içi sistemlerin yalnızca tek bir IP adresinden gelen trafiği kabul etme gereksinimini karşılar ve maliyet etkin bir çözüm sunar. Diğer seçenekler neden yanlış: Üç NAT Gateway dağıtmak ve Elastic IP'yi onlara atamak mümkün değildir, çünkü bir Elastic IP yalnızca tek bir kaynağa atanabilir. Ayrıca, NAT Gateway'lerin sağlık kontrolleri doğrudan Elastic IP yeniden atamasıyla otomatik olarak entegre değildir. ALB'yi NLB ile değiştirmek ve Elastic IP'yi NLB'ye atamak, uygulamanın şirket içi sistemlere çıkış IP'sini yönetme sorununu çözmez; NLB gelen trafiği yönetir, giden trafiği değil. Elastic IP'yi ALB'ye atamak ve Route 53 sağlık kontrolleri kullanmak, şirket içi sistemlere giden trafiğin sabit bir IP adresi üzerinden çıkışını sağlamaz. ALB, giden trafik için kendi IP adreslerini kullanır.