Score:1

DNS policy for VPC endpoint

za flag

I have VPC with three subnets in different availability zones, and an interface VPC endpoint in each. The VPC endpoint has 4 DNS hostnames by default:

  • A regional DNS hostname, e.g. vpce-x.ec2.us-east-1.vpce.amazonaws.com.
  • Three endpoint-specific zonal DNS hostnames, e.g. vpce-x-us-east-1a.ec2.us-east-1.vpce.amazonaws.com.

As I understand the regional DNS hostname will to an arbitrary endpoint. Is there a way to configure a single DNS hostname that will always resolve to the endpoint within the same subnet, to reduce inter-AZ traffic? I'm not sure whether a latency routing policy is applicable for this use case or not, or whether there is another solution. Or will the regional DNS hostname already do something like this?

The use case here is an application that sends a lot of traffic to an external service via VPC instance endpoints - to the point that the data transfer incurs significant costs. Avoiding inter-AZ traffic for the VPC endpoint would reduce one portion of the data transfer costs.

Tim avatar
gp flag
Tim
What are you trying to achieve? What problem are you having?
za flag
Trying to reduce inter-AZ data transfer costs.
Tim avatar
gp flag
Tim
Your question is extremely specific without specifying the big picture, it asks about the solution you think will work. I suggest you ask a new question that outlines your workload, your architecture, describes your problem (which might include how much cross-AZ traffic you're getting) and asks for suggestions. Your proposed solution might be what people come up with, but people may have others ideas as well. For example an ALB with cross zone load balancing turned off could be a solution in some circumstances
za flag
Added some details on the use case. But I suspect the current answer is the way to go here, so won't post another question. Using an ALB (or NLB) is an interesting idea for this, but the costs would be close to the inter-AZ data transfer costs.
Score:1
cn flag

If you use the zonal DNS name, you're talking to that zone. From the docs:

Choose a subnet in your VPC to use the interface endpoint. We create an endpoint network interface in the subnet. An endpoint network interface is assigned a private IP address from the IP address range of your subnet, and keeps this IP address until the interface endpoint is deleted. You can specify more than one subnet in different Availability Zones (as supported by the service) to help ensure that your interface endpoint is resilient to Availability Zone failures. In that case, we create an endpoint network interface in each subnet that you specify.

So if you have an instance running in e.g. us-east-1a, tell it to use the east-1a endpoint and all comms will be within the AZ. You should be able to vary the DNS name by using environment variables in your code, mappings in your CloudFormation, or Parameter Store lookups. Bear in mind this won't be resilient to failure.

Unless you're doing HPC things that require extremely low latency, or transferring massive amounts of data across zones, I'd just use the regional (e.g. us-east-1) name. My expectation would be it will use something sensible.

You might be able to verify by doing some host REGIONALDNS and checking what IP it gives you back, and comparing with the zonal result.

za flag
There is enough data going through the endpoint that the inter-AZ traffic costs become significant. Using the zonal DNS names directly would solve the problem, but it would add some complexity to the service (currently it's the same service with the same config deployed to multiple AZs). I was hoping there's a simple way to do this with Route53.
cn flag
You could try setting up something in R53 to use geoproximity or latency routing, but it's not guaranteed - I'm not sure if geoproximity would work that close, and the latency is potentially variable based on load.
za flag
Using different hostnames for the different AZs is probably the route to go. This can be made resilient to failure by preferring the endpoint from the same AZ, and falling back to the others (e.g. separate records with failover routing policy).
za flag
I see geoproximity and latency routing policies are not available for private hosted zones, so seems like it's not designed for this use case.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.