Компания перенесла приложение в AWS, используя инстансы EC2 в группе Auto Scaling в нескольких AZ. Приложение обращается к стороннему сервису данных по HTTPS, который использует статический ACL для разрешения доступа с определённых клиентских IP-адресов. У компании есть работающий Direct Connect к локальной инфраструктуре. Сетевой инженер должен разработать решение, чтобы масштабируемое приложение могло продолжать доступ к сервису поставщика, минимизируя при этом необходимость обновления списка разрешённых адресов поставщика. Какое решение соответствует этому требованию с наименьшими текущими изменениями в списке разрешённых адресов поставщика?

Правильный ответ — развертывание частного NAT Gateway в каждой зоне доступности. NAT Gateway предоставляет статический публичный IP-адрес для исходящего трафика из частных подсетей. Поскольку приложение масштабируется, все экземпляры EC2 в частной подсети будут использовать один и тот же статический IP-адрес NAT Gateway для доступа к стороннему сервису. Это минимизирует количество IP-адресов, которые необходимо добавить в список разрешенных поставщика, так как потребуется добавить только IP-адреса NAT Gateway (по одному на каждую AZ). Другие варианты не подходят: Использование Elastic Network Interface (ENI) для каждого экземпляра Auto Scaling неэффективно, так как при масштабировании приложения количество ENI и, соответственно, IP-адресов будет меняться, что потребует частых обновлений у поставщика. Создание отдельных экземпляров EC2 с ENI для маршрутизации трафика усложняет архитектуру и увеличивает накладные расходы на управление, а также не решает проблему динамического изменения IP-адресов при масштабировании. Использование ALB для маршрутизации к стороннему сервису не является его основной функцией и не обеспечивает статический исходящий IP-адрес для бэкенд-инстансов. ALB сам имеет динамические IP-адреса, которые меняются со временем, что не подходит для статического списка разрешенных адресов.