Front end aplikacji komunikuje się z instancjami backendu za pośrednictwem Network Load Balancer (NLB) w tej samej VPC. Aplikacja obejmuje dwie strefy dostępności (Availability Zones) i musi minimalizować ruch między strefami. Ruch z front endu powinien pozostać w tej samej strefie dostępności, chyba że w tej strefie nie ma zdrowego celu, w którym to przypadku powinien przełączyć się na drugą strefę. Jaka konfiguracja spełnia te wymagania?

Wyłączenie równoważenia obciążenia między strefami (cross-zone load balancing) na NLB sprawia, że ruch kierowany jest wyłącznie do celów w tej samej strefie dostępności, o ile są one zdrowe. Jeśli wszystkie cele w danej strefie staną się niezdrowe, NLB automatycznie przekieruje ruch do zdrowych celów w innych strefach. Konfiguracja front endu tak, aby rozwiązywał nazwę DNS NLB odpowiadającą jego lokalnej strefie dostępności, zapewnia, że początkowo ruch pozostaje w tej samej strefie, minimalizując transfer międzystrefowy. Pozostałe opcje są nieprawidłowe, ponieważ: Routing ważony (weighted routing) w prywatnej strefie hostowanej nie zapewnia automatycznego przełączania awaryjnego na podstawie stanu zdrowia celów NLB. Rekordy przełączania awaryjnego (failover records) w prywatnej strefie hostowanej są bardziej złożone i nie są natywnym mechanizmem NLB do zarządzania ruchem międzystrefowym w oparciu o stan zdrowia. Sesje trwałe (sticky sessions) są funkcją Application Load Balancer (ALB), a nie Network Load Balancer (NLB), i nie rozwiązują problemu minimalizacji ruchu międzystrefowego w przypadku awarii.