The way I have solved this in the past is to configured the API Gateway with a private endpoint in the firewall VPC. Configure the the firewall pool behind a Public ALB to serve as you front end with your desired app cert. Use a source and destination NAT rule to forward that traffic through the firewalls to the API GW endpoint FQDN.
One nuance, if you intend to decrypt the traffic on the way through use a SSL Forward Proxy decryption profile rather than the more intuitive Inbound Decrypt profile. The API gateway does not allow you to load a custom cert when using a private endpoint. By flipping the profile, you can get around the SSL handshake errors. The ALB will ignore the self signed cert warning.
I used this guide.
When the private endpoint is created, it will have a zone redundant FQDN assigned to it. You use that FDQN as our destination in the NAT rule.
You do also need a source nat on the same rule to ensure the proper return path from the api GW to the firewall. That would typically be your trust side interface address.
@jmeurer your reply is helping. I tried the following;
1. Create a sample lambda function of pet store - http://petstore-demo-endpoint.execute-api.com/petstore/pets
2. Created VPC endpoint
3. Created private REST API and attached endpoint
4. Created DNAT in PA with destination as VPC endpoint
**PA LAN and VPC endpoint are in same subnet
Now I called the URL http://PAWANIP/petstore/pets
Tried diff URLs, patterns, https nothing worked. Is there anything wrong in the method done.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!