Route 53 Resolver for On-Prem Access to Private API Gateway over Direct Connect Options

Question

I have API Gateway Private API using a VPC end point that will only be accessed by clients (browser and applications) from on premises over Direct Connect.   x-apigw-api-id:{api-id} Header is not an option as some application code can not be modified at this time.  The interim solution is NGINX on Fargate, but I want a solution without a proxy in the middle for operational simplicity.

I have created a forwarder zone for {restapi-id}.execute-api.{region}.amazonaws.com on their on-prem DNS pointing to their deployed Route 53 Inbound Resolvers.  What I have found is that the first response for an API Gateway DNS name is a CNAME to execute-api.eu-central-1.amazonaws.com, which will never get resolved up to an A record by our DNS or internet forwarders.

A request directly to the Route53 Resolver using the FQDN for the private API will work because a client will ask the same Route 53 Resolver again to resolve the CNAME.  However, I want clients talk to a local DNS server, which forwards to Route 53 Resolver, the returned CNAME is queried against local DNS which gets forwarded to internet instead of last used resolver.

**Options: Is there a recommended pattern?**

Option 1 - Create forwarding zone for execute-api.eu-central-1.amazonaws.com.  This will solve the problem, however that means prod/non-prod API-gateway requests will go through a single VPC.  However I want isolated prod / non-prod environments.

Option 2 - Dedicated VPC with Private API Gateway, Route 53 Resolver, and VPC Endpoint used for all regional on-prem API access requests.

Option 3 - A configuration (QiP / BIND) to re-ask last resolver for CNAME.

**Additional Questions**

1 - Is there an option I am missing or even better a recommended architecture for this use case?

2 - Are there configurations I'm missing on Route 53 resolver to return the A record to the client?  Have Route 53 Resolver ask for A records when receiving a CNAME.

Tom_Adamski · Accepted Answer

All the options you've listed are valid although it looks like the first two are mixing prod and no-prod environments which you don't want to do.

The 3rd option (if technically possible is the cleanest). You could configure the on-premise resolvers to either override the CNAME resolution ( example for BIND: https://www.redpill-linpro.com/sysadvent/2015/12/08/dns-rpz.html) or just create local zones for their private API hostnames ({restapi-id}.execute-api.{region}.amazonaws.com) and include A records directly to the IP addresses of the API endpoints (they don't change).

One addition option that comes to mind would be to deploy ALBs in front of the Private API endpoints. It's still a proxy approach but at least using managed services instead of NGINX.

API requests would go to an internal ALB first (using any domain/hostname) which would forward it to the IP addresses of  Private API endpoints (again IPs don't change).  One extra step required would be to create appropriate mappings under "Custom Domain Tab" of API Gateway and correlate the domain used on ALB with the actual API. Because private mapping is not included you would create it as regional or edge mapping and it would still work.

Tom

Route 53 Resolver for On-Prem Access to Private API Gateway over Direct Connect Options

Relevant content