Amazon ANS-C01: DNS and Route 53 — Study Guide
Part of the AWS Advanced Networking Specialty ANS-C01 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
Core concept
DNS is the glue between human-friendly names and distributed endpoints, but in AWS it becomes an active control plane for latency-based routing, health-aware failover, and multi-account private name resolution. Amazon Route 53 supports authoritative public DNS via public hosted zones and private DNS for VPC-scoped resolution via private hosted zones. Private hosted zones are associated with one or more VPCs and return answers only for queries originating from those VPCs or via Route 53 Resolver inbound endpoints. This split-horizon behavior—having different answers for the same name depending on source—lets you expose a public endpoint for internet clients while resolving the same name to private IPs within your VPCs.
Route 53 also integrates routing decision logic and active health checks into DNS. Routing policies include Simple, Weighted, Latency, Failover (primary/secondary), Geolocation and Multi-Value Answer, and Traffic Flow (geoproximity and complex flows). Health checks created with CreateHealthCheck permit Route 53 to remove unhealthy endpoints from DNS answers or drive failover record sets; health checks are configurable with HealthCheckConfig fields such as Type, FullyQualifiedDomainName, IPAddress, Port, ResourcePath, RequestInterval, and FailureThreshold. Because DNS is cached by resolvers and clients, Route 53’s TTL and frequent health-check polling (minimum 10 seconds under specific settings) must be balanced against DNS propagation behavior for failover and weighted routing changes.
Key services and configuration
When exposing AWS resources, use Alias records to point DNS directly at AWS resources where supported, avoiding additional hops or CNAMEs. Alias records use an AliasTarget that references the AWS resource’s hosted zone ID and DNS name (for example, an Elastic Load Balancer, API Gateway custom domain, CloudFront distribution or S3 website endpoint). Creating or changing records is done via the ChangeResourceRecordSets API; for programmatic workflows use ChangeBatch with UPSERT/DELETE actions and SetIdentifier for routing policy identification. For failover you create two records with the same name and Failover set to PRIMARY and SECONDARY, each referencing a health check via HealthCheckId that you create with CreateHealthCheck.
For cross-account and hybrid DNS resolution, Route 53 Resolver provides inbound and outbound endpoints created with CreateResolverEndpoint. An inbound endpoint allows on-premises resolvers to forward queries into VPCs (useful to resolve private hosted zones), while an outbound endpoint lets VPC resources forward queries to on-premises DNS servers or other resolvers. Resolver rules (CreateResolverRule) let you forward queries for specific domains to IP addresses and you associate rules to VPCs using AssociateResolverRule. For a central DNS architecture, you can create forwarding rules in a central account and AssociateResolverRule with VPCs in other accounts, optionally using AWS Resource Access Manager (RAM) and PutResolverRulePolicy to control associations.
Route 53 Resolver DNS Firewall provides domain-based filtering and logging. You create domain lists with CreateFirewallDomainList, rule groups with CreateFirewallRuleGroup, and then AssociateFirewallRuleGroup to VPCs to enforce rules. Firewall rules can BLOCK, ALLOW or OVERWRITE responses, and you can log evaluations to CloudWatch Logs or S3. Use CreateFirewallRule and PutFirewallRuleGroupPolicy for management and to apply prioritized rules, especially to limit exfiltration via DNS or to block malicious domains from VPC-attached resources.
Design patterns and trade-offs
For highly available, globally distributed services, use latency-based or geo-based routing to direct clients to the closest healthy endpoint, paired with health checks to remove unhealthy regional endpoints. Latency routing depends on Route 53’s regional latency tables and is suitable for multi-region active-active designs; failover routing is better for active-passive disaster recovery where only one region should receive traffic at a time. Weighted routing supports gradual traffic shifts (blue-green or canary deployments) by assigning weight values to records and changing them with ChangeResourceRecordSets. Multi-value answer routing can return multiple IPs for client-side load distribution and requires health checks to ensure only healthy IPs are returned.
Private hosted zones and resolver endpoints are the canonical patterns for multi-account, multi-VPC name resolution. For many business units, a central shared services VPC hosting private hosted zones or resolver endpoints simplifies management: create a private hosted zone and use AssociateVPCWithHostedZone to attach the service VPCs, or run Route 53 Resolver outbound/inbound endpoints and forwarding rules so each account keeps its VPC isolation while relying on central DNS policy. The trade-off is that private hosted zones associated with many VPCs complicate IAM and change control, and associations cross-account require an authorization step. Resolver forwarding introduces central operational overhead but scales because you do not need to associate every VPC directly with every hosted zone; instead you associate resolver rules.
When enforcing strict access paths—such as requiring traffic to flow only via Global Accelerator—you must design the security group and network controls to match DNS. Route 53 can point to Global Accelerator by creating A records with the accelerator’s static IP addresses or using CNAMEs to an accelerator-managed domain, but enforcement is done at the ALB security group and network ACL layer. The ALB security group should allow ingress only from the Global Accelerator static IP addresses; Global Accelerator guarantees those static IPs will be the source for incoming traffic, so limiting ingress preserves the access-only-via-accelerator requirement.
Common pitfalls and decision criteria
A typical pitfall is assuming Route 53 health checks instantly remove endpoints; DNS caching (TTL) and client resolver behavior mean failover is not instantaneous. Keep TTLs low for critical failover names, but remember lower TTLs increase query volume and cost. Another common mistake is duplicating names across public and private hosted zones without understanding VPC associations: a private hosted zone with the same name as a public hosted zone will shadow public answers for queries originating in associated VPCs, which is usually desirable for split-horizon but can be surprising if not documented.
Carefully choose between Alias and CNAME records: Alias records for ELB and CloudFront are preferable because they avoid extra DNS lookups and are supported by Route 53’s change propagation logic, but they are tied to AWS resource hosted zone IDs and cannot be used for arbitrary external endpoints. When designing cross-account DNS, prefer resolver rules and endpoints over directly associating many VPCs with a single private hosted zone when scale or administrative boundaries are concerns; resolver rules give more granular control and are easier to audit with CloudTrail.
Practical Problem: Use-Case Scenario
Company: NimbusPay — challenge: Provide secure, low-latency gRPC services over TLS with mutual TLS to an EKS backend, enforce access to the web front-end only via Global Accelerator, and allow multiple business-unit VPCs across accounts to consume shared data services with centralized DNS controls.
For the gRPC service requiring end-to-end TLS with mutual authentication and thousands of concurrent connections, deploy a Network Load Balancer (NLB) with TCP listeners on port 443 using target type ip so pod IPs are registered directly. Configure the AWS Load Balancer Controller annotations service.beta.kubernetes.io/aws-load-balancer-type: “nlb-ip” and set target group protocol TCP; do not terminate TLS at the NLB (no TLS listener) so mutual TLS is passed through to pod containers where server certificates and client certificate verification are enforced. Use Route 53 A records (Alias) pointing to the NLB via ChangeResourceRecordSets; prefer low TTLs only if you need rapid failover, otherwise keep a conservative TTL for DNS stability.
To ensure the web front-end ALB accepts traffic only from Global Accelerator, provision an accelerator and assign its two static IP addresses to NimbusPay. Configure Route 53 public records to resolve the public name to the accelerator IPs (A records with the static IPs). On the ALB, set the security group ingress rules to allow only those static IP addresses and close 0.0.0.0/0. This enforces that only traffic arriving from the accelerator static IPs can reach the ALB. Use CloudWatch Logs and VPC Flow Logs to validate incoming source IPs and to audit that non-accelerator traffic is blocked.
For multiple business-unit VPCs across accounts needing access to shared services, deploy a central Route 53 Resolver outbound/inbound endpoint pair in the shared services account using CreateResolverEndpoint and place the endpoints in private subnets. Create forwarding rules (CreateResolverRule) in the shared account for the shared service domains and Share the rules using AWS RAM or use PutResolverRulePolicy to permit associations. Each business unit associates the resolver rule to their VPCs (AssociateResolverRule), enabling name resolution without directly attaching all VPCs to private hosted zones. For sensitive controls, attach Route 53 Resolver DNS Firewall rule groups (CreateFirewallRuleGroup and AssociateFirewallRuleGroup) to the shared VPC to block unwanted exfiltration or to enforce domain allowlists. The rationale: NLB TCP passthrough preserves mutual TLS and scales to many concurrent connections, restricting ALB ingress to Global Accelerator static IPs enforces access-only-via-accelerator, and resolver endpoints with centrally managed rules scale DNS resolution across accounts while preserving per-account IAM boundaries and auditing.
← Transit Gateway and Network Topology · All domains · Load Balancing and Traffic Management →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →