Route 53 Resolver: DNS in Hybrid Cloud (Part 1)

DNS can be a real pain in hybrid cloud setups, but Amazon Route 53 Resolver makes it a breeze. Whether you're a DNS enthusiast or a cloud architect navigating hybrid networks, this series will show you how Route 53 Resolver simplifies DNS management.

In this post, we’ll break down what Route 53 Resolver is and how it tackles hybrid cloud challenges. Stay tuned for Part 2, where we’ll dive into Active Directory integration and multi-VPC DNS, and Part 3 for Route 53 Profiles.

🔎 What Is Route 53 Resolver?

Route 53 Resolver is the backbone of DNS in AWS VPCs, acting as a managed service to handle DNS resolution. By default, your VPC instances use Route 53 Resolver at the VPC CIDR + 2 IP address (e.g., 10.0.0.2 for a 10.0.0.0/16 CIDR) or the local address of 169.254.169.253. Unlike a traditional DNS server, it’s a highly available, multi-tenant gateway deployed in each Availability Zone (AZ) for fault isolation, with local caching on instances to speed up repeated queries.

One catch: each network interface (ENI) on an EC2 instance is limited to sending 1,024 packets per second to the Route 53 Resolver, a crucial consideration for scaling.

Route 53 Resolver classifies queries in the following way:

Private DNS: Queries for Route 53 private hosted zones associated with the VPC are resolved internally.
VPC DNS: Handles EC2 instance names and reverse DNS for RFC 1918 addresses.
Public DNS: Queries not matching the above are forwarded to public DNS authorities.

⚠️ Challenges of DNS in Hybrid Cloud Environments

When connecting on-premises networks to AWS via AWS Direct Connect or VPN, DNS resolution becomes more complex. While IP connectivity allows machines to communicate, DNS resolution for names across these boundaries does not work out of the box. For example, an on-premises server trying to resolve an EC2 instance's private DNS name will fail unless there is a mechanism to forward DNS queries across environments.

The old-school fix was to deploy forwarding instances - EC2 instances running DNS software like BIND or Unbound, configured to forward queries between on-premises and AWS.

While functional, this approach had several downsides:

Scaling limitations: The forwarding instances become a bottleneck as traffic increases, with each instance capped at a limit of 1,024 pps for traffic destined to the Route 53 Resolver
Fault tolerance challenges: Failure of a forwarding instance can cause DNS resolution failures or delays due to client retry behavior.
Complex management: Maintaining custom DNS servers adds operational overhead.
Availability zone crossing: Queries often crossed AZ boundaries, increasing latency and reducing fault isolation.

🚀 Route 53 Resolver Endpoints to the Rescue

Since late 2018, Route 53 Resolver Endpoints have replaced clunky self-managed forwarding instances with a managed, scalable solution.

Route 53 Resolver Endpoints consist of three key components and here’s how they work:

Inbound Endpoints: These are for DNS queries coming into AWS from on-premises networks. These create ENIs in your VPC that on-premises DNS servers can target via Direct Connect or VPN, letting them resolve AWS private DNS names. Each endpoint supports up to 6 ENIs, handling 10,000 queries per second per ENI.

Network Architecture with Inbound Endpoints

2. Outbound Endpoints: These are for DNS queries going out of AWS to your on-premises networks. When AWS resources need to resolve on-premises DNS names, Route 53 Resolver forwards queries back to your on-premises DNS servers via this endpoint. Similar to inbound endpoints, each endpoint supports up to 6 ENIs, handling 10,000 queries per second per ENI.

Network Architecture with Outbound Endpoints

3. Resolver Rules: allow you to specify which DNS queries should be forwarded through the outbound endpoints. Resolver rules come in two types: “Forward” rules forward matching queries for specific domains (e.g., mycompany.com) to on-premises DNS servers, while “system” rules allow the default behavior of the Route 53 Resolver system to answer queries (Private DNS, VPC DNS, Public DNS).

For example, you can create a forward rule to send all queries for mycompany.com to your on-premises DNS, while letting other queries resolve normally in AWS. Rules are associated with one or more VPCs, enabling fine-grained control over DNS forwarding behavior. When multiple rules match a query, the most specific rule takes precedence, similar to routing table logic.

🛠️ Best Practices for Resolver Endpoints

One inbound/outbound endpoint can have up to 6 IP addresses or ENIs. Spread ENIs across multiple AZs for high availability and fault tolerance.
Use forwarding sparingly. DNS is a critical service; minimize forwarding hops.
Assign fixed IPs to inbound endpoint ENIs and configure your on-premises DNS to forward queries to them.
Monitor query metrics and set CloudWatch alarms to detect traffic spikes or capacity limits on resolver endpoints.
Use a caching forwarding resolver on-premises for better performance.
Use resolver rules wisely to avoid conflicts and ensure smooth DNS resolution.

💰 Pricing

Endpoints: $0.125 per ENI per hour (up to 6 ENIs per inbound or outbound endpoint).
Queries: $0.40 per million queries (for the first 1 billion/month), $0.20 per million thereafter. Local Resolver queries are free.

Check the Route 53 pricing page for details.

🌟 Wrapping Up

Route 53 Resolver takes the headache out of hybrid cloud DNS with managed endpoints and forwarding rules, eliminating the need for custom forwarding instances. It’s fast, reliable, and scalable, making hybrid DNS resolution easier to manage. By following best practices like spreading ENIs across AZs and monitoring query metrics, you’ll keep your DNS setup rock-solid. In Part 2, we’ll zoom in on integrating Active Directory and managing DNS across multiple VPCs. Stay tuned!

Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.

Site Terms, Privacy, and more.