An on-premises data center is connected to a VPC over Direct Connect. On-prem servers must resolve names held in a Route 53 private hosted zone, and EC2 instances must resolve internal on-prem names. Which Route 53 Resolver components do you configure in each direction?

## Why the default resolver isn't enough Every VPC has an Amazon-provided DNS resolver reachable at the VPC CIDR's base address plus two, and also at the link-local address `169.254.169.253`. It resolves public names, VPC internal names, and any private hosted zone associated with that VPC. It has one hard property that shapes this whole question: **it only answers queries that originate inside the VPC.** A packet arriving over Direct Connect or a Site-to-Site VPN from an on-prem host cannot use it, no matter how the routing is set up. Symmetrically, an EC2 instance asking the Amazon resolver for `db01.corp.example.com` gets NXDOMAIN, because that name lives only on the corporate DNS servers and the Amazon resolver has no idea they exist. Route 53 Resolver endpoints exist to bridge exactly these two gaps, and they are deliberately separate objects because the two directions have different security properties. ## Inbound endpoint — on-prem asking AWS An inbound endpoint is a set of elastic network interfaces you place in subnets of the VPC — at least two, in different Availability Zones, which is a requirement, not a recommendation. Each ENI gets an IP address from its subnet, and those addresses are what you hand to the on-prem team. On the corporate DNS servers you then configure a conditional forwarder: "for `aws.example.com`, forward to 10.0.1.10 and 10.0.2.10". Queries arrive at the endpoint, are resolved as if they came from inside the VPC, and can therefore see any private hosted zone associated with that VPC. Two operational details matter. The endpoint's security group must allow inbound UDP and TCP on port 53 from the on-prem ranges — TCP matters, because large answers and anything with EDNS0 fallback use it. And routing must actually work: the on-prem resolvers need a path to those subnet addresses over the Direct Connect or VPN attachment. ## Outbound endpoint and rules — AWS asking on-prem The outbound side has two parts, which is where people get confused. The endpoint itself is again ENIs in at least two AZs; it is only the *source* of forwarded queries. The behaviour lives in **Resolver rules**: ``` rule type: FORWARD domain name: corp.example.com target IPs: 10.100.0.53:53, 10.100.1.53:53 endpoint: rslvr-out-xxxxxxxx ``` A rule must be **associated with a VPC** before it does anything. Once associated, any query from that VPC matching the rule's domain is sent out through the endpoint to the target IPs instead of being resolved normally. Matching is by longest suffix, and there is also a `SYSTEM` rule type whose job is the opposite — to carve out a subdomain and send it back to the default Route 53 behaviour despite a broader FORWARD rule above it. In a multi-account organisation you do not repeat this per account. Build the endpoints and rules once in a shared networking account and share the rules with AWS Resource Access Manager; each spoke account then associates the shared rules with its own VPCs. ## What this costs and where it fails Resolver endpoints are billed per elastic network interface per hour plus a charge per million queries, so a pair of endpoints is a small standing cost that exists whether or not anyone queries them. Building them across two AZs is both a requirement and the availability story: lose one AZ and the other ENI still answers, provided the on-prem forwarders list both IPs. Common failures, in the order they actually occur: - **Security group forgot TCP/53.** Small answers work, larger ones hang. Classic and hard to spot. - **Only one IP handed to the on-prem team.** Resolution is fine until that AZ has a bad day. - **The rule was created but never associated with the VPC.** No forwarding happens and everything looks correctly configured in the console. - **A forwarding loop.** The on-prem servers forward a domain to AWS while a Resolver rule forwards the same domain back on-prem. Queries bounce until something gives up. - **Overly broad FORWARD rule.** Forwarding all of `example.com` on-prem sends public and AWS-internal names there too; scope rules to the specific internal suffix, or add a narrower rule for the parts that must stay in AWS. Also remember the per-instance limit: each network interface is capped at a documented number of packets per second toward the Amazon-provided resolver, so a chatty application with no local caching can hit that ceiling and see intermittent resolution failures that look like a Resolver problem but are not.