Route 53 Resolver Inbound and Outbound Rules Explained (2026)

Route 53 Resolver rules don’t just forward DNS queries; they actively route them based on domain name, acting like a smart DNS traffic cop for your hybrid cloud.

Let’s see this in action. Imagine you have an on-premises Active Directory domain, corp.local, and you want your AWS VPCs to be able to resolve its DNS records. You also have a public domain, example.com, that you want to resolve normally via public DNS servers.

First, you’ll set up an inbound endpoint in Route 53 Resolver. This endpoint listens for DNS queries coming from your AWS VPC to your on-premises DNS servers.

aws route53resolver create-resolver-endpoint \
    --name "vpc-to-onprem-inbound" \
    --direction INBOUND \
    --creator-request-id "vpc-to-onprem-inbound-$(date +%s)" \
    --security-group-ids sg-0123456789abcdef0 \
    --ip-addresses SubnetId=subnet-0123456789abcdef0,Ip="10.0.1.10" \
    --ip-addresses SubnetId=subnet-0abcdef9876543210,Ip="10.0.2.10"

This creates an endpoint in your VPC. The Ip addresses are the Elastic Network Interfaces (ENIs) that Route 53 Resolver provisions within your specified subnets. Your on-premises DNS servers will then be configured to forward queries for corp.local to these IPs.

Next, you need a rule to tell Route 53 Resolver what to do with queries originating from your VPC. This is where the routing logic comes in.

aws route53resolver create-resolver-rule \
    --name "corp-local-rule" \
    --domain-name "corp.local" \
    --rule-type FORWARD \
    --resolver-endpoint-id <your-resolver-endpoint-id> \
    --target-ip-list Ip=192.168.1.53,Ipv4="192.168.1.53" \
    --target-ip-list Ip=192.168.2.53,Ipv4="192.168.2.53"

Here, domain-name "corp.local" specifies that this rule applies to queries for that domain. rule-type FORWARD means queries will be sent to the target-ip-list, which are your on-premises DNS servers (e.g., 192.168.1.53). The resolver-endpoint-id links this rule to the inbound endpoint we created earlier.

Now, for example.com, you don’t need a specific rule to forward. If no other rule matches, Route 53 Resolver’s default behavior is to send queries to public DNS servers. However, if you wanted to explicitly control this or use a specific set of public DNS resolvers, you’d create another rule.

aws route53resolver create-resolver-rule \
    --name "public-dns-rule" \
    --domain-name "." \
    --rule-type FORWARD \
    --resolver-endpoint-id <your-resolver-endpoint-id> \
    --target-ip-list Ip=8.8.8.8,Ipv4="8.8.8.8" \
    --target-ip-list Ip=8.8.4.4,Ipv4="8.8.4.4"

The domain-name "." is a wildcard that matches any domain not covered by other rules. This rule forwards queries to Google’s public DNS servers.

Finally, you associate these rules with your VPC. This is what makes the rules active for resources within that VPC.

aws route53resolver associate-resolver-rule \
    --resolver-rule-id <your-corp-local-rule-id> \
    --vpcs vpc-0123456789abcdef0

And for the public DNS rule:

aws route53resolver associate-resolver-rule \
    --resolver-rule-id <your-public-dns-rule-id> \
    --vpcs vpc-0123456789abcdef0

When a resource in vpc-0123456789abcdef0 queries for server.corp.local, Route 53 Resolver sees the corp.local rule, forwards the query to 192.168.1.53 (or 192.168.2.53), and returns the IP. If it queries for www.example.com, it hits the wildcard rule (or defaults to public DNS if no wildcard is explicitly defined and no other rule matches) and gets the public IP.

This system is essential for hybrid cloud architectures, enabling seamless DNS resolution between AWS and your on-premises data centers without complex DNS server configurations or VPN tunnel management for DNS traffic. It allows you to manage your internal DNS zones on your existing infrastructure while leveraging AWS for your public-facing or other cloud-native domains.

What most people miss is that the FORWARD rule type is only one half of the equation for inbound traffic. You also need an outbound endpoint to receive queries from on-premises to AWS, and then rules associated with that outbound endpoint to direct those queries to the correct VPCs or Resolver Rule Groups.

The next step you’ll likely explore is using Resolver Rule Groups to organize and apply rules across multiple VPCs more efficiently.