How to design a private DNS failover solution for on-premises to AWS connectivity?
Short answer
C Place the EC2 instances in private subnets. Create an Amazon Route 53 private hosted zone for the AWS reserved domain name. Associate the private hosted zone with the VPCreate a Route 53 Resolver inbound endpoint. Configure conditional forwarding in the on-premises DNS resolvers to forward all DNS queries for the AWS domain to the inbound endpoint IP address for Route 53 Resolver. In the private hosted zone, configure primary and failover records that point to the IP addresses of the EC2 instances. Create an Amazon CloudWatch metric and alarm to monitor the application's health. Set up a health check on the alarm for the primary application endpoint.
Question
Key Takeaways
Route 53 health checkers cannot directly reach private IP addresses; to fail over private endpoints you must use a CloudWatch alarm as the health check target.
This question tests the design of a private DNS failover architecture using Route 53 private hosted zones, Route 53 Resolver inbound endpoints, and CloudWatch-based health checks for EC2 instances in private subnets accessed from on-premises.
Common mistake: Many candidates choose D because it uses native Route 53 health checks directly on private IPs, forgetting that Route 53 health checkers live on the public internet and cannot resolve or reach private VPC addresses without a public IP.
Expert Analysis
The scenario requires three things: (1) DNS resolution of an AWS-reserved private domain from on-premises, (2) automatic failover between EC2 instances in the same VPC, and (3) no exposure of the application to the internet.
Why Option C is Correct
Option C correctly combines all the required components:
- Private subnets keep the EC2 instances unreachable from the internet.
- A Route 53 private hosted zone (PHZ) is associated with the VPC, ensuring the AWS-reserved domain is resolved only inside the VPC and through authorized resolvers.
- A Route 53 Resolver inbound endpoint allows on-premises DNS resolvers (connected via VPN or Direct Connect) to forward queries for the AWS domain into the VPC.
- Primary and failover records in the PHZ provide the required automatic failover between EC2 instances.
- Because the EC2 instances are in private subnets, Route 53 health checkers (which operate from public internet locations) cannot reach them directly. The correct workaround is to create a CloudWatch alarm that monitors application health and then attach the Route 53 health check to that CloudWatch alarm. This is the officially documented pattern for health-checking private resources.
Why the Other Options Are Wrong
- Option A assigns public IP addresses to the EC2 instances and uses an outbound endpoint. Outbound endpoints are for forwarding queries from AWS to on-premises, not the other way around. Public IPs also violate the requirement to not expose the application to the internet.
- Option B uses a public hosted zone, which would make the application's DNS records visible on the public internet — violating the core requirement.
- Option D attempts to set up Route 53 health checks directly on the private IP addresses of the EC2 instances. This is impossible because Route 53 health checkers reside outside the VPC and cannot route to private RFC 1918 addresses. Without a CloudWatch alarm intermediary, the health check will fail and failover will not work.
Community Consensus
The community strongly supports C (86%). Commenters correctly point out that "Route 53 health checkers need a public IP" and that for private resources you "can only use CloudWatch" as the health check target, referencing the official AWS blog on performing Route 53 health checks on private resources with CloudWatch.
Official Reference
- https://aws.amazon.com/blogs/networking-and-content-delivery/performing-route-53-health-checks-on-private-resources-in-a-vpc-with-aws-lambda-and-amazon-cloudwatch/
- https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-fail-over-configuring-health-checks.html
- https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html
These links open the official vendor documentation in a new tab.
Exam Strategy
When a question mentions private IPs and Route 53 health checks, immediately recall that Route 53 health checkers are public. Look for the CloudWatch alarm bridge in the correct answer; any option that health-checks a private IP directly is a trap.
Community Votes
100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 6 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 6
-
backspace0900 👍 10C Route53 healthchecker need publicIP
-
cerifyme85 👍 3 Answered CCan only be done using cloudwatch for private IPS https://aws.amazon.com/blogs/networking-and-content-delivery/performing-route-53-health-checks-on-private-resources-in-a-vpc-with-aws-lambda-and-amazon-cloudwatch/ R53 cannot monitor pHz https://repost.aws/questions/QUVcLK5gUqSxKGondJkrzw0Q/private-zone-route53-health-checks#:~:text=If%20you%20mean,private%20hosted%20zone
-
Spaurito 👍 1C - as per documentation - To set up Route 53 health checks on the private IP addresses of EC2 instances, you need to assign a public IP address to the EC2 instance as Route 53 health checkers can only access resources with publicly routable IP addresses; then, configure the health check in Route 53 to point to that public IP, allowing you to monitor the health of your private resource within the VPC; you can use a private hosted zone to associate the health check with your internal domain names This would expose to the internet. Monitoring the applications endpoint is the next solution.
-
KobDragoon 👍 1 Answered DI vote for D instead of C, because Route53 health checks are necessary for the implementation of Route53 failover records. R53 health checks can be done directly to the instances or to the cloudwatch alarms, but why use cloudwatch alarm configuration when you can go the more direct route and there is no requirement to get any metrics from the EC2s from cloudwatch.
-
khaanikahttak 👍 1D is correct answer. Coz route53 health check is design for end points fail over. route 53 redirect traffic to the healthy end point in case one is failed.
Show 1 more comment
-
backspace0900 👍 3 Answered Csupplement the vote
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All ANS-C01 Questions
Access 137 questions with complete answers and detailed explanations.
View Full ANS-C01 Practice Test →