Vendor VPC Endpoint with private DNS - possible to do alias with our own PHZ?

0

Hey all,

We have a vendor which requires us to use a VPCE svc (so, we create a VPC i/f endpoint) to reach their service. We enable private DNS on the i/f endpoint, and as expected, svc.my.vendor.com pops up on the connection shortly thereafter. We then add an inbound resolver endpoint into our central networking account, point to it with a conditional forwarding zone from our on-prem DNS for *.my.vendor.com, then RAM share the i/f endpoint out to the customer account. All is well with this approach, but as more and more vendors are giving us VPCE svcs to connect to, we fear the cost of all of these ENIs we have to provision (2 for i/f endpoint, and 2 for inbound resolver endpoint).

From what I have read, with an AWS Service (but I've not been able to find any guidance yet on PrivateLink partners/vendors), we should be able to disable private DNS on an i/f endpoint, create a PHZ stub zone of, say, .our.internal.domain which has a wildcard record ALIAS'd to *.my.vendor.com so that we can have some internal consistency in our naming, and what's more we can then use our shared inbound resolver endpoint instead of creating one for each vendor which asks us to use VPCE. This way, we only take 2 ENIs on the chin for the i/f endpoint itself. Additionally, our on-prem DNS team do not have to do extra work with new conditional forwarding zones, as adding another subdomain on an existing forwarding rule is almost a NOOP. However, as briefly mentioned in parenthesis above, I've found this guidance only in the context of AWS services. Before going down the rabbit hole of trying to prove this out, I wanted to field some opinions.

Put another way:

  1. Original Private DNS name on i/f endpoint: svc.my.vendor.com
  2. We want to use our already-existing attached/associated PHZ so that we can hit svc.our.internal.domain and have it be forwarded by our on-prem DNS through the shared inbound rslvr endpoint, and then "route" to the VPCE i/f endpoint which hitherto has been known as svc.my.vendor.com (but now probably isn't, due to it having private DNS disabled in order to make this solution possible..?)

Any ideas welcome,

Thanks!

profile picture
asked 10 months ago313 views
1 Answer
1
Accepted Answer

We started off with the approach described at https://www.linkedin.com/pulse/how-share-interface-vpc-endpoints-across-aws-accounts-steve-kinsman/ just making AWS service VPCEs available across all accounts. The same approach worked fine when we added in additional VPCEs for vendor endpoints (ElasticSearch for example). These VPCEs can be used from VPCs in all accounts that have network connectivity and have the shared PHZ for the VPCE.

Note a Route 53 Resolver Inbound Endpoint isn't needed with this solution unless you want to access the services via VPCE from on-prem, over Direct Connect or site-to-site VPN. Then only one endpoint is needed anyway.

EXPERT
answered 10 months ago
profile picture
EXPERT
reviewed 10 months ago
  • Thanks Steve, helpful stuff. The linked James Devine article added the additional colour I needed on top of your quality post. Cheers.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions