Диагностика: приложение в приватной подсети не может подключиться к внешнему API, хотя security group и NACL разрешают исходящий трафик. Какие шаги диагностики и какой компонент вероятнее всего отсутствует?

Короткий ответ

Скорее всего в приватной подсети отсутствует маршрут к NAT gateway (или NAT не настроен/находится в другой AZ без привязки), поэтому исходящие пакеты в интернет не могут выйти, даже если firewall-правила их разрешают.

Как это работает подробнее

трафику из приватной подсети в интернет нужна цепочка: правило security group/NACL разрешает трафик, таблица маршрутизации подсети должна направлять 0.0.0.0/0 на NAT gateway, а NAT gateway должен находиться в публичной подсети с собственным маршрутом на internet gateway.

Пример кода

example.txtКопировать

$ ip route # внутри инстанса
default via 10.0.2.1  # шлюз подсети выглядит нормально
# Проверка таблицы маршрутизации подсети в облаке:
aws ec2 describe-route-tables --route-table-ids rtb-0priv123 \
  --query "RouteTables[0].Routes"
# [{"DestinationCidrBlock": "10.0.0.0/16", ...}]   <- маршрута 0.0.0.0/0 на NAT нет!

Что использовать на практике

• Рекомендация. диагностику начинают с проверки таблицы маршрутизации приватной подсети (есть ли маршрут на NAT), затем проверяют статус NAT gateway и его привязку к нужной AZ, и только потом смотрят security group/NACL как последний слой.
• Проверка. после добавления маршрута 0.0.0.0/0 -> nat-0456 в таблицу приватной подсети curl https://api.example.com из инстанса должен завершиться успешно.

Подводные камни

• Риск. сразу чинить security group, хотя проблема в маршрутизации
• Риск. создавать один NAT gateway в одной AZ и ожидать, что он будет работать для подсетей в других AZ без отдельных маршрутов, теряя при этом отказоустойчивость
• Риск. забывать, что NACL stateless и требует явных правил в обе стороны, в отличие от security group.