This chapter covers Route 53 Resolver endpoints for hybrid DNS, a critical component for integrating AWS VPCs with on-premises DNS infrastructure. For the SAA-C03 exam, understanding when and how to use Resolver endpoints is essential for designing resilient hybrid networks. Approximately 5-10% of exam questions touch on Route 53 or hybrid DNS scenarios, often involving Resolver endpoints, forwarding rules, or conditional forwarding. This chapter will demystify the architecture, configuration, and troubleshooting of these endpoints, ensuring you can answer questions accurately.
Jump to a section
Imagine a multinational company with two headquarters: one in New York (your AWS VPC) and one in London (your on-premises data center). Each office has its own internal phone directory (DNS resolver). Employees in New York can call each other using short extensions (private IP addresses), but they cannot reach London extensions because the directories are separate. To solve this, the company installs a PBX (Private Branch Exchange) in each office. The New York PBX (inbound endpoint) has a phone number that London can dial, and vice versa. When a New York employee wants to call London extension 100, they dial a special prefix that routes the call to the New York PBX, which then forwards it to the London PBX using the public phone network (AWS Direct Connect or VPN). The London PBX looks up extension 100 in its local directory and connects the call. The key is that each PBX maintains a translation table: it knows which local extension corresponds to which remote number. In AWS terms, the inbound endpoint is like a phone number that on-premises resolvers can query, and the outbound endpoint is like the PBX that forwards queries to on-premises. The forwarding rules are like a company directory that says "for extensions starting with 020, route to London." Without these endpoints, the two offices would be isolated islands, unable to resolve each other's internal DNS names.
What Are Route 53 Resolver Endpoints and Why Do They Exist?
Route 53 Resolver endpoints are managed DNS resolution gateways that enable bidirectional DNS query forwarding between AWS VPCs and on-premises networks. They are part of the Amazon Route 53 Resolver service, which by default provides DNS resolution within a VPC using the VPC+2 IP addresses (e.g., 10.0.0.2). However, in hybrid architectures, on-premises resources need to resolve private hosted zones (e.g., internal.example.com) and VPC instances need to resolve on-premises hostnames (e.g., db.corp.local). Without Resolver endpoints, you would have to set up custom DNS forwarders on EC2 instances, which adds management overhead and single points of failure.
How It Works Internally – Step Through the Mechanism
Route 53 Resolver endpoints come in two flavors: inbound endpoints and outbound endpoints. An inbound endpoint listens for DNS queries from on-premises resolvers (or other external networks) and forwards them to the VPC's default Resolver, which then queries private hosted zones and the public internet. An outbound endpoint forwards DNS queries from VPC resources to on-premises resolvers based on forwarding rules.
Inbound Endpoint Mechanism:
- The inbound endpoint is provisioned in a VPC with two elastic network interfaces (ENIs) in two different Availability Zones for high availability. Each ENI gets a private IP address from the VPC subnet.
- On-premises DNS resolvers are configured to forward queries for specific domains (e.g., aws.internal) to these inbound endpoint IP addresses.
- When a query arrives at the inbound endpoint, it is forwarded to the VPC's default Resolver (the Route 53 Resolver service) via the ENI. The default Resolver then checks private hosted zones associated with the VPC and returns the answer.
- If the domain is not in a private hosted zone, the Resolver forwards to the public internet (if recursion is enabled, which is default).
Outbound Endpoint Mechanism: - The outbound endpoint also has two ENIs in two AZs, each with a private IP. - You define forwarding rules (also called Resolver rules) that specify which domains should be forwarded to which on-premises DNS server IP addresses. - When a VPC resource makes a DNS query for a domain that matches a forwarding rule, the VPC's default Resolver (the VPC+2 IP) intercepts the query and, if it matches a rule, forwards it to the outbound endpoint. The outbound endpoint then sends the query to the on-premises DNS server over a VPN or Direct Connect. - The response is returned along the same path.
Key Components, Values, Defaults, and Timers
Inbound Endpoint: Requires at least two subnets in different Availability Zones. Each subnet must have a free IP for the ENI. The endpoint supports TCP and UDP on port 53. There is no built-in caching; caching is done by the client or the on-premises resolver.
Outbound Endpoint: Also requires two subnets in different AZs. You must associate forwarding rules with it. The endpoint does not cache responses; it simply forwards.
Forwarding Rules: Rules are created in the Route 53 console or via API. Each rule specifies a domain name (e.g., corp.local) and up to 10 target IP addresses (on-premises DNS servers). You can also set a rule to forward to another outbound endpoint (for multi-hop). Rules can be shared across accounts using AWS RAM.
Default Timeout: The Resolver endpoint has a 2-second timeout for DNS queries. If no response is received, it returns an error (SERVFAIL) to the client. This is a common exam point.
Max UDP Packet Size: DNS over UDP is limited to 512 bytes by default (RFC 1035). For larger responses, TCP fallback is used. Route 53 Resolver endpoints support both.
Rate Limits: Each inbound endpoint can handle up to 10,000 queries per second (QPS) per ENI. Outbound endpoints have similar limits. These are soft limits and can be increased via AWS Support.
Configuration and Verification Commands
Creating an inbound endpoint using AWS CLI:
aws route53resolver create-resolver-endpoint \
--creator-request-id unique-string \
--security-group-ids sg-12345678 \
--direction INBOUND \
--ip-addresses SubnetId=subnet-abc,SubnetId=subnet-def \
--name MyInboundEndpointCreating an outbound endpoint:
aws route53resolver create-resolver-endpoint \
--creator-request-id unique-string \
--security-group-ids sg-87654321 \
--direction OUTBOUND \
--ip-addresses SubnetId=subnet-ghi,SubnetId=subnet-jkl \
--name MyOutboundEndpointCreating a forwarding rule:
aws route53resolver create-resolver-rule \
--creator-request-id unique-string \
--rule-type FORWARD \
--domain-name corp.local \
--target-ips Ip=10.0.0.10,Port=53 Ip=10.0.0.11,Port=53 \
--resolver-endpoint-id rslvr-out-12345678Associating a rule with a VPC:
aws route53resolver associate-resolver-rule \
--resolver-rule-id rslvr-rr-12345678 \
--vpc-id vpc-12345678Verification: Use dig or nslookup from an EC2 instance in the VPC to test resolution. For example:
dig db.corp.local @169.254.169.253The 169.254.169.253 is the VPC's default Resolver IP. If the forwarding rule is active, the query should return the on-premises IP.
How It Interacts with Related Technologies
VPN or Direct Connect: Outbound endpoints require network connectivity to on-premises DNS servers. This is typically over AWS Site-to-Site VPN or AWS Direct Connect. The security group for the outbound endpoint must allow outbound traffic to the on-premises DNS server IPs on port 53 (UDP and TCP).
Private Hosted Zones: Inbound endpoints allow on-premises resolvers to resolve names in private hosted zones. However, private hosted zones are only resolvable from within the VPC they are associated with. Inbound endpoints bridge this gap.
Route 53 Resolver DNS Firewall: Can be used to filter outbound DNS queries from VPCs, but it works independently of Resolver endpoints.
AWS Transit Gateway: In complex multi-VPC architectures, you might attach each VPC to a Transit Gateway and use a centralized outbound endpoint in a shared services VPC. All VPCs route DNS queries for on-premises domains through that endpoint.
Exam-First Details
The SAA-C03 exam expects you to know:
Inbound endpoints allow on-premises to resolve AWS private hosted zones.
Outbound endpoints allow VPC resources to resolve on-premises DNS names.
Both require two ENIs in different AZs for high availability.
Forwarding rules are domain-based and can point to on-premises DNS servers.
The default DNS timeout is 2 seconds.
You must use security groups to control traffic.
You cannot use Route 53 Resolver endpoints to resolve on-premises DNS from an on-premises network directly to another on-premises network; they are for hybrid only.
Resolver endpoints do not support custom port numbers; they always use port 53.
You can create up to 1000 forwarding rules per account (soft limit).
Provision Inbound Endpoint in VPC
First, you create an inbound Resolver endpoint in your AWS VPC. You must specify at least two subnets in different Availability Zones. The service automatically creates an elastic network interface (ENI) in each subnet with a private IP address. These IPs become the targets for on-premises DNS forwarders. The security group attached to the endpoint must allow inbound UDP and TCP traffic on port 53 from the on-premises DNS server IPs. Without proper security group rules, the endpoint will silently drop queries.
Configure On-Premises DNS Forwarders
On the on-premises side, you configure your DNS resolvers (e.g., Windows DNS, BIND) to forward queries for the AWS private domain (e.g., `aws.internal`) to the inbound endpoint IP addresses. Typically, you add a conditional forwarder. For example, in Windows DNS, you create a new conditional forwarder for the domain `aws.internal` with the two inbound endpoint IPs. The on-premises resolver will send queries to these IPs over the VPN or Direct Connect connection. If one IP is unreachable, the resolver should try the other.
Provision Outbound Endpoint and Forwarding Rules
Similarly, you create an outbound Resolver endpoint in the same or a different VPC. Again, two subnets in different AZs are required. Then you create forwarding rules that map on-premises domains (e.g., `corp.local`) to the IP addresses of on-premises DNS servers. Each rule can have up to 10 target IPs. You then associate the rule with the VPCs that need to resolve that domain. The outbound endpoint's security group must allow outbound traffic to the on-premises DNS server IPs on port 53.
Associate Forwarding Rules with VPCs
After creating a forwarding rule, you must associate it with one or more VPCs. This tells the Route 53 Resolver in those VPCs to use the outbound endpoint for queries matching the rule's domain. The association is done via the console, CLI, or API. A single rule can be associated with many VPCs. Note that the VPC must have the outbound endpoint in the same region. Cross-region forwarding is not supported natively; you would need a separate endpoint in each region.
Test and Verify DNS Resolution
Finally, test the setup. From an EC2 instance in the VPC, run `dig db.corp.local` to verify that the on-premises IP is returned. The query goes to the VPC's default Resolver (169.254.169.253), which checks forwarding rules. If a match is found, it forwards to the outbound endpoint, which sends the query to on-premises. The response is returned. From on-premises, test resolving `web.aws.internal` – it should return the private IP of the EC2 instance. If the 2-second timeout is exceeded, the query fails. Common issues include security group rules blocking traffic, incorrect forwarding rule domain matching, or missing routes in the route tables.
In a typical enterprise, a company has a data center running Active Directory DNS with a domain ad.corp.com. They have migrated several applications to AWS VPCs and need EC2 instances to resolve hostnames like sql.ad.corp.com to on-premises IPs. They also have a private hosted zone aws.corp.com in Route 53 that contains records for AWS resources. The solution is to deploy an inbound endpoint in a shared services VPC and an outbound endpoint in the same VPC. The on-premises DNS servers are configured to forward aws.corp.com to the inbound endpoint IPs. The outbound endpoint has a forwarding rule for ad.corp.com pointing to the on-premises DNS servers. The forwarding rule is associated with all application VPCs via AWS RAM sharing. This setup allows bidirectional resolution without custom DNS forwarders on EC2.
Another scenario: A financial services company uses a multi-account architecture with hundreds of VPCs. They centralize DNS resolution in a single shared services VPC. They create inbound and outbound endpoints there. On-premises DNS servers forward all AWS domains to the inbound endpoint. All VPCs associate the same forwarding rule for the on-premises domain. The outbound endpoint's security group allows traffic only from the VPC's default Resolver IPs (169.254.169.253) to on-premises. This ensures that only queries from VPCs with the associated rule are forwarded. A common misconfiguration is forgetting to update route tables: the subnets used for the endpoint ENIs must have routes to the on-premises network via VPN/Direct Connect. If the route is missing, the outbound endpoint cannot reach on-premises DNS servers. Also, if the security group is too restrictive, the endpoint may be unreachable. In production, monitoring is critical – CloudWatch metrics like QueryVolume and Timeouts help detect issues. The 2-second timeout is often too short for high-latency connections; you may need to increase the timeout on the client side (e.g., options timeout:3 in /etc/resolv.conf).
The SAA-C03 exam tests Route 53 Resolver endpoints under Objective 2.5: 'Design hybrid and multi-account architectures.' Specifically, you need to know when to use inbound vs. outbound endpoints, and how they enable hybrid DNS. The most common wrong answer is choosing 'Configure an inbound endpoint on-premises' – there is no such thing; endpoints are always in AWS VPCs. Another trap is selecting 'Use a Route 53 Resolver endpoint to forward queries between VPCs' – for VPC-to-VPC DNS, you should use VPC peering or Route 53 Private DNS with association, not Resolver endpoints. Candidates often confuse Resolver endpoints with Route 53 Resolver DNS Firewall or with conditional forwarding in on-premises DNS. The exam loves to test the requirement for two ENIs in different AZs – if an answer says 'single subnet,' it's wrong. Also, the default timeout of 2 seconds is a specific number that appears in questions about slow DNS resolution. Edge cases: If an on-premises resolver sends a query to an inbound endpoint but the VPC has no private hosted zone for that domain, the Resolver will attempt to resolve via public internet – this might leak internal names. To prevent this, you can disable recursion on the inbound endpoint (not directly supported; you would need a custom solution). Another edge case: When using Direct Connect, you must ensure that the VPC's route table has a route to the on-premises CIDR via the virtual private gateway or transit gateway. If the route is missing, the outbound endpoint cannot reach on-premises. To eliminate wrong answers, remember: inbound = on-premises queries to AWS; outbound = AWS queries to on-premises. If the question mentions 'on-premises DNS server resolving AWS private hosted zones,' the answer must include an inbound endpoint. If it mentions 'EC2 instance resolving on-premises hostnames,' the answer must include an outbound endpoint and forwarding rules. The exam also tests that you cannot use Resolver endpoints to forward queries from one on-premises network to another – that would require a different mechanism (e.g., DNS forwarder on EC2).
Inbound endpoints allow on-premises DNS to resolve AWS private hosted zones; outbound endpoints allow VPC resources to resolve on-premises DNS.
Both inbound and outbound endpoints require at least two ENIs in different Availability Zones for high availability.
Forwarding rules define which domains are forwarded to which on-premises DNS servers; each rule supports up to 10 target IPs.
The default DNS timeout for Resolver endpoints is 2 seconds; queries exceeding this timeout return SERVFAIL.
Security groups must allow port 53 (UDP and TCP) traffic to/from the appropriate IP ranges.
Resolver endpoints do not support custom ports – only port 53.
Forwarding rules must be explicitly associated with each VPC; they are not automatically applied to all VPCs.
Route 53 Resolver endpoints are regional – you need separate endpoints for each region.
You cannot use Resolver endpoints for VPC-to-VPC DNS resolution; use VPC peering or Route 53 Private DNS for that.
AWS RAM can share forwarding rules across accounts, but each VPC still needs association.
These come up on the exam all the time. Here's how to tell them apart.
Route 53 Resolver Inbound Endpoint
Allows on-premises DNS resolvers to query private hosted zones in VPC
Listens for DNS queries from on-premises networks
Requires security group allowing inbound UDP/TCP port 53 from on-premises DNS IPs
No forwarding rules needed; just the endpoint itself
On-premises resolvers must be configured to forward to its IPs
Route 53 Resolver Outbound Endpoint
Allows VPC resources to query on-premises DNS servers
Sends DNS queries to on-premises networks
Requires security group allowing outbound UDP/TCP port 53 to on-premises DNS IPs
Requires forwarding rules to define which domains to forward and where
VPC resources use VPC's default Resolver which then uses this endpoint
Route 53 Resolver Endpoints
Managed service – no EC2 instances to manage
Highly available by default with two ENIs in different AZs
Scales automatically up to 10,000 QPS per ENI
Integrated with Route 53 Resolver and forwarding rules
Cannot customize DNS software or port settings
Custom DNS Forwarder on EC2
Full control over DNS software (e.g., BIND, dnsmasq)
Must manually configure high availability (e.g., Auto Scaling, multiple instances)
Requires scaling management and monitoring
Can use any DNS features (e.g., caching, custom ports)
More flexible but higher operational overhead
Mistake
Route 53 Resolver endpoints can be deployed in on-premises data centers.
Correct
Resolver endpoints are AWS resources that exist only within a VPC. They cannot be deployed on-premises. On-premises DNS servers must be configured to forward queries to the inbound endpoint IPs.
Mistake
A single ENI is sufficient for a Resolver endpoint.
Correct
AWS requires at least two ENIs in different Availability Zones for high availability. A single ENI would create a single point of failure and is not allowed by the service.
Mistake
Outbound endpoints can forward queries to any IP address without security group rules.
Correct
Outbound endpoints require security group rules that allow outbound traffic to the on-premises DNS server IPs on port 53 (UDP and TCP). Without these rules, the endpoint cannot send queries.
Mistake
Forwarding rules can be applied globally to all VPCs in an account.
Correct
Each forwarding rule must be explicitly associated with each VPC that needs it. There is no global apply. You can use AWS RAM to share rules across accounts, but still per-VPC association is required.
Mistake
Resolver endpoints support custom DNS ports.
Correct
Resolver endpoints only support port 53 (both TCP and UDP). Custom ports are not supported. If your on-premises DNS server uses a non-standard port, you must use a custom DNS forwarder on EC2.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Not necessarily. You only need an inbound endpoint if on-premises resolvers need to resolve AWS private hosted zones. You only need an outbound endpoint if VPC resources need to resolve on-premises DNS names. If you need bidirectional resolution, you need both. The exam often tests that you only deploy what is needed.
No. Resolver endpoints are regional. If you have VPCs in multiple regions that need to resolve on-premises DNS, you must create an outbound endpoint in each region. Similarly, inbound endpoints are per-region. Cross-region forwarding is not supported natively.
The outbound endpoint will fail to send queries to on-premises DNS servers. The VPC's default Resolver will timeout after 2 seconds and return SERVFAIL to the client. This is a common misconfiguration. Always verify that the security group allows outbound UDP/TCP port 53 to the on-premises DNS IPs.
Yes. In fact, Direct Connect is a common connectivity method. The endpoint's ENIs are in subnets that must have routes to the on-premises network via the Direct Connect virtual interface (VIF). Ensure the route tables for those subnets have a route to the on-premises CIDR pointing to the virtual private gateway or transit gateway.
Use AWS Resource Access Manager (RAM). Create the forwarding rule in one account (the owner), then share it with other accounts. The other accounts can then associate the shared rule with their VPCs. This is a common exam scenario for multi-account architectures.
The default soft limit is 1000 forwarding rules per account per region. This can be increased via AWS Support. The exam might test that you can have up to 1000 rules, but it's a soft limit.
No. Resolver endpoints are for private DNS resolution only. Public DNS queries are handled by the VPC's default Resolver directly. If you try to forward a public domain to an on-premises resolver via an outbound endpoint, it will work but is unnecessary and may cause issues if the on-premises resolver cannot resolve public names.
You've just covered Route 53 Resolver Endpoints for Hybrid DNS — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?