Hybrid DNS is a foundational requirement in most cloud migration and modernization programs. When workloads span on-premises data centers and Amazon VPCs, bidirectional name resolution becomes mandatory for application communication, identity services, database access, and service discovery.
This article walks through the architectural evolution — from a simple working design to a highly available, centralized, and operationally mature hybrid DNS solution.
Problem Statement : You are designing a hybrid architecture where Enterprise workloads run in on-premises data centers and new applications are deployed in Amazon VPCs. Connectivity is established using Site-to-Site VPN or Direct Connect (DX). Now you must ensure:
1. On-premises applications can resolve private DNS names hosted in AWS.
2. AWS workloads can resolve internal corporate domain names hosted on-premises.
Through Resolver endpoints and conditional forwarding rules, you can resolve DNS queries between your on-premises resources and VPCs to create a hybrid cloud setup over VPN or Direct Connect (DX). Specifically:
- Inbound Resolver endpoints allow DNS queries to your VPC from your on-premises network or another VPC.
- Outbound Resolver endpoints allow DNS queries from your VPC to your on-premises network or another VPC.
- Resolver rules enable you to create one forwarding rule for each domain name and specify the name of the domain for which you want to forward DNS queries from your VPC to an on-premises DNS resolver and from your on-premises to your VPC. Rules are applied directly to your VPC and can be shared across multiple accounts.
The following diagram shows hybrid DNS resolution with Resolver endpoints. Note that the diagram is simplified to show only one Availability Zone.
The diagram illustrates the following steps:
Outbound DNS Resolution (AWS → On-Premises): When an AWS resource needs to resolve a domain hosted in your data center:
- An EC2 instance in the VPC tries to resolve
internal.example.com and this domain is hosted on an on-premises DNS server, not in AWS. - The DNS request first goes to the VPC Resolver.
- A Resolver forwarding rule is already configured for the domain
internal.example.com. Because of this rule, the query is sent to the Outbound Resolver Endpoint. - The Outbound Endpoint forwards the DNS request to the on-premises DNS server through AWS Direct Connect, or AWS Site-to-Site VPN
- The on-premises DNS resolver resolves the DNS query for internal.example.com and returns the answer to the Amazon EC2 instance via the same path in reverse.
Inbound DNS Resolution (On-Premises → AWS): When an on-premises system needs to resolve a domain hosted in AWS:
a. A client in the on-premises data center tries to resolve dev.example.com
b. The request is sent to the on-premises DNS server.
c. A forwarding rule is already configured on the on-prem DNS server for
dev.example.com. Because of this rule, the DNS query is forwarded to the Route 53 Inbound Resolver Endpoint in AWS. The query travels securely over AWS Direct Connect, or AWS Site-to-Site VPN.
d. The Inbound Endpoint passes the request to the VPC Resolver.
e. The VPC Resolver checks the Private Hosted Zone and finds the correct IP address and The response returns back through the same path.
Test your configuration
To test your configuration, perform a DNS resolution from one of the Amazon EC2 instances in your VPC:
- For Linux or macOS: dig <record name> <record type>
- For Windows: nslookup -type=<record type> <record name>
Gaps in this Simple Design?
Although functional, this minimal architecture introduces several risks and inefficiencies when deployed in production.
Single-AZ Deployment Risk
Resolver endpoints are implemented as ENIs that are scoped to specific Availability Zones. If deployed in a single AZ:
- An AZ failure results in DNS resolution failure.
- Applications experience cascading outages.
- Troubleshooting becomes complex because DNS failures often manifest as application timeouts.
DNS is foundational infrastructure. A single-AZ dependency introduces unacceptable operational risk.
Designing for High Availability (Multi-AZ)
- Deploy Inbound Resolver Endpoints in at least two AZs
- Deploy Outbound Resolver Endpoints in at least two AZs
- Place endpoint ENIs in separate subnets across different AZs
Missing Non-Centralized DNS Hub Architecture
In multi-VPC or multi-account environments, a naïve approach often results in:
- Resolver endpoints deployed in every workload VPC
- Duplicate forwarding rules across accounts
- Inconsistent DNS policies
- Increased cost due to redundant endpoints
- Governance challenges in regulated environments
As the environment scales, DNS configuration sprawl becomes a management burden. This is where architectural centralization becomes critical.
Central DNS Hub Design:
- Instead of deploying resolver endpoints in each workload VPC, adopt a Shared Services VPC model.
Shared Services VPC
├── Route 53 Resolver Inbound Endpoint (Multi-AZ)
├── Route 53 Resolver Outbound Endpoint (Multi-AZ)
├── Private Hosted Zones
├── Forwarding Rules
├── DNS Firewall
└── Query Logging- All workload (spoke) VPCs connect via Transit Gateway (preferred) Or VPC peering (limited scale)
- Resolver rules are shared across accounts using AWS RAM and associated with spoke VPCs.
Security and Compliance Controls
DNS is a critical exfiltration vector and must be secured via required controls:
- Security groups permitting UDP/TCP 53 only from trusted CIDRs
- Network ACL restrictions where required
- Route 53 Resolver Query Logging to CloudWatch or S3
- Enable Route 53 Resolver DNS Firewall
4. Observability and Monitoring
DNS visibility is often overlooked until failure occurs and so below are the recommended telemetry:
- Resolver query logging
- VPC Flow Logs
- CloudWatch alarms on: Endpoint ENI health, Query failure rates, Latency thresholds
In mature DevOps environments, metrics can be exported to centralized monitoring systems (e.g., Grafana) to ensure proactive detection of anomalies.
Conclusion
A basic hybrid DNS setup satisfies immediate connectivity needs, but enterprise environments demand more than functionality , they require resilience, observability, governance, and scalability.
By evolving from a simple per-VPC design to a centralized, multi-AZ DNS hub architecture integrated with Transit Gateway and security controls, organizations establish a production-ready foundation for hybrid cloud operations.
If this post adds value to your AWS journey, please consider reposting so it can reach more engineers working on hybrid cloud and DNS architectures.
