У меня возникли проблемы с настройкой ссылки VPC шлюза AWS API на существующий ELB, чтобы сделать частную конечную точку общедоступной.
Ошибка, которую я получаю при просмотре конечной точки шлюза API: {"message":"Service Unavailable"}
Вот настройка проекта.
Основная платформа отлично работает для людей, подключающихся по HTTP через ELB, однако любые запросы к конечной точке шлюза API ждут некоторое время, а затем возвращают ответ HTTP503 с телом {"message":"Service Unavailable"}
Журналы Cloudwatch показывают ответ HTTP503, но не содержат никакой другой полезной информации. Журналы ELB не показывают запросов, поступающих с запрошенным URL-адресом.
Результаты выглядят так, как будто ссылка VPC не работает, а запрос к ELB отклоняется группой безопасности на ELB, даже если SecGroup ELB настроен на разрешение «весь трафик» из SecGroup, используемой ссылкой VPC.
Я не понимаю, что может быть причиной проблемы, и надеюсь, что кто-то сможет заметить что-то, что я пропустил по пути.
Я следил за различными документами AWS, включая:
Ни в одном из них не упоминается настройка SecGroup.
Мне удалось создать интеграцию HTTP URI и указать ее на конечной точке, которая разрешает публичные запросы. Это нехорошо, поскольку приложение должно оставаться частным, кроме одной или двух конечных точек.
Все, что я прочитал, предполагает, что подход API Gateway -> VPC Link -> ELB -> EC2 должен работать.
ОБНОВЛЕНИЕ 1
Настройка канала VPC
Интеграция со шлюзом API
Метод выбора: Ручной Целевая служба: ALB/NLB Балансировщик нагрузки: SM-01-ELB Прослушиватель: HTTP 80 Ссылка VPC: ссылка SM01-VPC
@AshBlake Я согласен с вами в том, что GW не перенаправляется на ELB. VPCLink использует тот же VPC, что и экземпляры EC2, и ELB. У EC2 есть общедоступные IP-адреса, но у них есть правила SecGroup, чтобы ограничить их определенными IP-адресами управления для SSH.
Согласно документам, там сказано:
Ссылки VPC позволяют создавать частные интеграции, которые соединяют ваши маршруты HTTP API с частными ресурсами в VPC.
Вы создали ALB и VPC Link, расположенные в частных подсетях? Я предполагаю, что вы не сможете успешно подключиться к ALB, если используете его в частных подсетях.
И можете ли вы также проверить, создан ли ENI VPC Link или нет?
Мне нужно разместить свои вопросы здесь, так как раздел комментариев для меня довольно мал
Не могли бы вы уточнить, что вы подразумеваете под «Я предполагаю, что вы не сможете успешно подключиться к ALB, если используете его в частных подсетях»?
Я имею в виду, что согласно документам все ваши ресурсы должны находиться в частных подсетях, что означает наличие шлюза NAT. Я предполагаю, что вы размещаете все ресурсы в общедоступной подсети, чтобы вы могли подключаться напрямую
Я думаю ты прав. Глядя на них, они кажутся общедоступными подсетями, которые были привязаны. Я создам новый частный VPC для тестирования, чтобы посмотреть, работает ли он, и если да, то я отмечу ответ как правильный. Это, безусловно, имело бы смысл
Пожалуйста, попробуйте ^^ Я сделал это всего месяц назад, и с вашей базой все в порядке.
У меня не было другого шанса посмотреть, но я подтвердил, что установка использует общедоступные VPC, но у меня не будет возможности изменить ее на какое-то время, поэтому я обошел ее с помощью шлюза API к Lambda с лямбдой, находящейся в ВКК
Какой смысл иметь лямбду между ними, если эти (подсети) общедоступны? В этом случае вы можете использовать HTTP-интеграцию APIG и указать ее на свой LB.
Я сделал это месяц назад, и это сработает и на вашей стороне. И я думаю, что в вашем исходном состоянии нет ничего плохого. Можете ли вы прикрепить образ конфигурации vpc_link к ALB. Я думаю, что ваш API GW не направляет трафик на ALB. Можете ли вы проверить, ставите ли вы VPC Link в частные подсети, а не в публичные?