AWS API Gateway simple http proxy Invalid endpoint address

Question

I am trying to use an AWS API gateway to configure simple http proxy, following the example from this page: https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-create-api-as-simple-proxy-for-http.html The issue I'm running into is that it seems to work if my endpoint URL is another AWS API gateway, but I can't get it to work for any other URL.

I'm creating a proxy resource with resource path /{proxy+} and enabling API gateway CORS, then creating ANY method as HTTP Proxy and content handling passthrough (just like the petshop example in the above mentioned example). If I set my endpoint to be another AWS API gateway, it works.

However, if I set my endpoint to be a non-AWS URL I get back a 500 response and I see in my API gateway Cloudwatch log:

Execution failed due to configuration error: Invalid endpoint address

My endpoint is on my internal company network, but as a test I also tried proxying to an Internet address and this failed with the same error. (I should note that in both cases, I am trying to proxy to an https address, not just http.)

In order to rule out a network routing or firewall issue I logged into an AWS EC2 instance in our same region and tested access to the endpoint URL via curl, and this was successful.

Has anyone successfully used API gateway simple https proxy to anything other than another AWS API gateway?

Answer 1

I was assuming that testing from an EC2 instance would verify that there was no routing or firewall or DNS issue. This was a bad assumption, as it turns out that an API gateway does not necessarily live in the same network or have the same access as an EC2 in the same region. Thanks to help from @Michael - sqlbot I was able to determine that this was in fact a network access issue, but it was not one that my DevOps team was able to resolve due to the API gateway not being in the right network.

Instead, the solution turned out to be that I had to write a small lambda function (fronted by an API gateway resource with lambda proxy integration), similar to how I have written other lambdas for the RESTful APIs in our application. From the lambda I have more flexibility in accessing internal resources, including the ability to configure VPCs, so I was able to use standard HTTP client APIs in the lambda to proxy the call to the back-end resource.