Route 53 Resolver hybrid DNS
Hybrid DNS with Route 53 Resolver endpoints
On-prem and AWS resolve each other's names through inbound and outbound Resolver endpoints, not the VPC+2 address alone.
Why hybrid DNS needs Resolver endpoints
Every VPC ships with a built-in recursive resolver, historically called Route 53 Resolver and now Route 53 VPC Resolver. It listens on two link-local addresses: the base of the VPC CIDR plus two (the "VPC+2" address, for example 10.0.0.2 in a 10.0.0.0/16 VPC) and the reserved 169.254.169.253 address (plus fd00:ec2::253 for IPv6). It answers three kinds of queries automatically: internal EC2 names such as ec2-192-0-2-44.compute-1.amazonaws.com, records in Route 53 private hosted zones associated with the VPC, and public records via recursion out to the internet.
The catch is that VPC+2 is only reachable from inside the VPC. It is not a routable address you can point an on-premises DNS server at over Direct Connect or VPN. That single fact is why hybrid DNS exists as its own architecture. To let names flow in both directions you deploy Route 53 Resolver endpoints, which are real elastic network interfaces (ENIs) sitting in your subnets with private IP addresses that both sides can route to.
The two directions are independent and often both are configured. An inbound endpoint lets DNS resolvers on your network forward queries into the VPC so on-premises clients can resolve names in your private hosted zones. An outbound endpoint, paired with conditional forwarding rules, lets EC2 instances resolve names that only your on-premises DNS servers know about. The diagram traces both paths through a single DNS hub VPC.
Outbound endpoints and forwarding rules (AWS to on-prem)
To send queries from your VPCs to on-premises DNS, you create an outbound endpoint plus one or more forwarding rules. The endpoint specifies the private source IP addresses that queries leave from; because those are private, not public, addresses, the endpoint needs Direct Connect, a VPN connection, or a NAT gateway to actually reach your network. Each forwarding rule names exactly one domain (for example corp.example.com) and lists the target IP addresses of your on-premises resolvers. A rule does nothing until you associate it with a VPC; association is what tells VPC Resolver to start forwarding matching queries out the outbound endpoint.
Rule evaluation is driven by the most specific domain match, and a forwarding rule applies to the domain and all of its subdomains. This creates a common failure mode: if you forward corp.example.com to on-prem but a subdomain like aws.corp.example.com actually lives in a private hosted zone that VPC Resolver should answer, the broad forwarding rule would wrongly ship those queries to your data center. The fix is a system rule for aws.corp.example.com, which selectively overrides the forwarding rule and makes VPC Resolver answer that subtree locally. Similarly, a catch-all "." rule forwards everything to your network, but VPC Resolver still refuses to forward certain internal AWS domains (via autodefined system rules) because those names resolve to ranges that are meaningless outside AWS.
Two operational details matter for reliability and cost. First, when a rule lists multiple on-prem target IPs, VPC Resolver picks one at random with no preference and retries a different random target if one does not respond, so all targets must be reachable or resolution times balloon. Second, endpoints bill per ENI, and each outbound query VPC Resolver receives is sent redundantly for availability, so a single logical query can produce more than one packet leaving your network interfaces.
Inbound endpoints (on-prem to AWS)
An inbound endpoint is the mirror image. You choose private IP addresses from your VPC's own ranges, and your on-premises DNS resolvers are configured with conditional forwarding (or NS delegation glue records, for a delegation endpoint) that points the relevant zone at those inbound IPs. Queries arrive over Direct Connect or VPN, hit the inbound ENIs, and VPC Resolver answers from the private hosted zones associated with that VPC.
AWS requires a minimum of two IP addresses per endpoint for redundancy and recommends placing them in at least two Availability Zones. For each unique combination of Availability Zone, subnet, and IP address, Resolver creates one ENI, and those private IPs stay fixed for the life of the endpoint. The security group on the endpoint must allow inbound TCP and UDP on port 53 (add 443 if you use DNS over HTTPS). The endpoint supports Do53 by default and optional DoH or DoH-FIPS for encryption in transit.
A subtle capacity trap lives in that security group. A single IP address in an endpoint can process up to roughly 10,000 UDP queries per second, but if restrictive security group rules force connection tracking (or queries are funneled through a Network Load Balancer), the effective ceiling for that IP can drop as low as about 1,500 QPS. Because throughput scales per ENI, you raise capacity by adding more IP addresses across more Availability Zones, not by changing a single dial.
Scaling, capacity, and failure modes
Route 53 VPC Resolver itself has no per-VPC aggregate query limit. It runs as a Nitro Resolver service on each host plus a highly available Zonal Resolver fleet per Availability Zone, so it scales as you add instances and interfaces. What it does enforce is a link-local budget: each ENI in your VPC allows 1,024 packets per second to link-local services (Resolver, NTP, IMDS), and packets past that are dropped. You can watch for this with the linklocal_allowance_exceeded counter from ethtool or the CloudWatch agent.
Endpoints, by contrast, do have quotas you must design around. The defaults are four Resolver endpoints per Region per account, six IP addresses per endpoint, six target IP addresses per rule, 1,000 rules per Region, and 2,000 rule-to-VPC associations per Region. AWS guidance is to add network interfaces once your peak query rate exceeds 50 percent of an interface's capacity, using CloudWatch per-IP metrics to see the load on each ENI.
The most common real-world outages are not about quotas at all. They are unreachable forwarding targets (a rule points at an on-prem resolver whose route or firewall is broken, and the random-retry behavior masks it only briefly before resolution slows), missing return routes across Direct Connect or VPN so answers cannot come back, and security groups that silently invoke connection tracking and throttle an inbound endpoint far below its nominal 10,000 QPS.
Sharing rules across accounts with RAM
In a multi-account landing zone you rarely want an outbound endpoint and a duplicate set of forwarding rules in every account. Instead a central networking account creates the outbound endpoint and the forwarding rules once, then shares those rules with other accounts, organizational units, or the whole organization using AWS Resource Access Manager (RAM). A consumer account associates a shared rule with its own VPCs exactly as if it had created the rule; matching queries from those VPCs are then forwarded through the outbound endpoint that the owning account defined. This central-egress pattern is the point of sharing.
The ownership boundary is strict. An account a rule is shared with can associate it with VPCs but cannot change, delete, re-tag, or re-share the rule; only the creating account can. The quotas split accordingly: the rules-per-Region quota counts against the account that created the rule, while the associations-per-Region quota counts against the account that consumes it. If a shared rule is deleted or unshared, consumer VPCs simply fall back to their remaining rules, which is the same behavior as disassociating the rule.
RAM sharing of Resolver rules is a different mechanism from sharing DNS answers via private hosted zones (which use VPC associations and cross-account authorizations, capped at 300 VPCs per hosted zone) and from Route 53 Profiles, a newer construct that bundles rules, hosted zones, and firewall groups for distribution at larger scale. For the exam, keep the three straight: RAM shares Resolver rules, private hosted zones are associated to VPCs, and Profiles package many DNS resources for org-wide reuse.
Sources
- What is Route 53 VPC Resolver?
- Forwarding outbound DNS queries to your network
- Using rules to control which queries are forwarded to your network
- Values that you specify when you create or edit inbound endpoints
- Managing forwarding rules (sharing with RAM)
- Route 53 quotas (Resolver endpoints, rules, QPS)
Practice what you just read