AWS API Gateway простой http-прокси Неверный адрес конечной точки

Question

Я пытаюсь использовать шлюз API AWS для настройки простого прокси-сервера http, следуя примеру, приведенному на этой странице: https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-create-api-as-simple-proxy-for-http.html Проблема, с которой я сталкиваюсь, заключается в том, что она работает, если URL-адрес моей конечной точки является другимШлюз API AWS, но я не могу заставить его работать для любого другого URL.

Я создаю прокси-ресурс с путем к ресурсу / {proxy +} и включаю API-шлюз CORS, а затем создаю ЛЮБОЙ метод как HTTPПрокси-сервер и обработка контента (точно так же, как в примере с домашним магазином в приведенном выше примере).Если я устанавливаю свою конечную точку как другой шлюз API AWS, она работает.

Однако, если я устанавливаю свою конечную точку как URL не-AWS, я получаю ответ 500 и вижу в своем журнале шлюза API Cloudwatch:

Ошибка выполнения из-за ошибки конфигурации: Неверный адрес конечной точки

Моя конечная точка находится во внутренней сети компании, но в качестве теста я также попытался проксировать по адресу в Интернетеи это не удалось с той же ошибкой.(Должен заметить, что в обоих случаях я пытаюсь прокси-сервер к адресу https, а не просто к http.)

В порядкеЧтобы исключить проблему сетевой маршрутизации или брандмауэра, я вошел в экземпляр AWS EC2 в том же регионе и проверил доступ к URL-адресу конечной точки с помощью curl, и это было успешно.

Кто-нибудь успешно использовал шлюз API, простой https-проксик чему-либо, кроме другого шлюза AWS API?

Answer 1

Я предполагал, что тестирование из экземпляра EC2 подтвердит отсутствие проблем с маршрутизацией, брандмауэром или DNS.Это было неверное предположение, поскольку выясняется, что шлюз API не обязательно находится в той же сети или имеет тот же доступ, что и EC2 в том же регионе.Благодаря помощи @Michael - sqlbot я смог определить, что на самом деле это была проблема с доступом к сети, но моя команда DevOps не смогла решить ее из-за отсутствия шлюза API в нужной сети.

Вместо этого оказалось, что мне пришлось написать небольшую лямбда-функцию (созданную ресурсом шлюза API с интеграцией прокси-серверов лямбда), аналогично тому, как я написал другие лямбда-выражения для API-интерфейсов RESTful в нашем приложении.Благодаря лямбде у меня больше гибкости в доступе к внутренним ресурсам, включая возможность настройки VPC, поэтому я смог использовать стандартные клиентские API-интерфейсы HTTP в лямбде для прокси-соединения вызова внутреннего ресурса.