Amazon Route 53: Optimizing Availability with Public and Private Hosted Zones

This study guide explores the foundational and advanced configurations of Amazon Route 53 Hosted Zones, focusing on how to architect DNS for high availability and internal service discovery within AWS environments.

Learning Objectives

By the end of this module, you will be able to:

• Differentiate between Public and Private Hosted Zones (PHZ) and their specific use cases.
• Configure DNS records to optimize application availability across multiple Availability Zones (AZs).
• Implement private zonal DNS entries for internal traffic routing.
• Explain the integration of Route 53 with VPC-specific settings like enableDnsHostnames and enableDnsSupport.

Key Terms & Glossary

• Hosted Zone: A container for records that define how you want to route traffic for a domain (e.g., example.com) and its subdomains.
• Public Hosted Zone: A container that holds records for routing traffic on the internet.
• Private Hosted Zone (PHZ): A container that holds records for routing traffic within one or more Amazon VPCs without exposing the records to the internet.
• Resource Record Set: The basic unit of information in Route 53, such as an A record (IPv4 address) or a CNAME (canonical name).
• Split-View DNS: A configuration where you use the same domain name for both internal (private) and external (public) traffic, but with different IP resolutions.

The "Big Idea"

At its core, Route 53 isn't just a "phonebook" for the internet; it is a traffic controller. By leveraging Private Hosted Zones, architects can decouple internal service endpoints from their physical IP addresses, allowing for seamless failover and zonal optimization. This ensures that even if an entire Availability Zone or a public-facing endpoint fails, the internal network remains resilient and performant.

Formula / Concept Box

[!IMPORTANT] Alias Records vs. CNAMEs: Always prefer Alias records for AWS resources (like ELBs or S3 buckets) because they are free to query and can map to the zone apex (e.g., example.com instead of www.example.com).

Hierarchical Outline

1. Hosted Zone Fundamentals
   • Public Zones: Accessible via the internet; requires NS/SOA records.
   • Private Zones: Linked to specific VPCs; requires VPC DNS attributes enabled.
2. Optimizing Availability
   • Zonal DNS Entries: Routing traffic to specific instances in an AZ to reduce cross-AZ data transfer costs.
   • Health Checks: Monitoring endpoints to automatically remove failed resources from DNS responses.
3. Advanced Patterns
   • Multi-VPC Association: Sharing a single PHZ across multiple VPCs or accounts (via AWS RAM).
   • Split-View DNS: Managing internal vs. external traffic for the same domain name.

Visual Anchors

DNS Resolution Flow

Zonal Architecture

This diagram illustrates how Route 53 can point to resources in specific Availability Zones.

\begin{tikzpicture}[node distance=2cm] \draw[thick, dashed] (0,0) rectangle (8,4) node[pos=0.1, above] {VPC}; \draw[fill=blue!10] (0.5,0.5) rectangle (3.5,3.5) node[pos=0.5, below=1.2cm] {AZ-A}; \draw[fill=green!10] (4.5,0.5) rectangle (7.5,3.5) node[pos=0.5, below=1.2cm] {AZ-B}; \node[draw, fill=white] (r53) at (4,5) {Route 53 PHZ}; \node[draw, circle, fill=blue!30] (inst1) at (2,2) {Svr 1}; \node[draw, circle, fill=green!30] (inst2) at (6,2) {Svr 2}; \draw[->, thick] (r53) -- (inst1) node[midway, left] {az-a.app.internal}; \draw[->, thick] (r53) -- (inst2) node[midway, right] {az-b.app.internal}; \end{tikzpicture}

Definition-Example Pairs

• Private Zonal DNS: A DNS record that points specifically to a resource in one Availability Zone.
  • Example: Creating database-az1.internal pointing to 10.0.1.55 so that app servers in AZ1 don't incur cross-AZ charges when talking to the DB.
• Split-Horizon DNS: Providing different DNS responses based on the source of the query.
  • Example: api.myapp.com resolves to a Public IP for customers, but resolves to a Private IP (NLB endpoint) for internal microservices.

Worked Examples

Scenario: Configuring a Private Zonal Record

Goal: Route internal traffic from service.internal to three different EC2 instances using Multivalue Answer routing to ensure high availability.

1. Step 1: Create the PHZ: Create a zone named internal.com and associate it with vpc-12345.
2. Step 2: Create Record Set: Create an A record for app.internal.com.
3. Step 3: Routing Policy: Select Multivalue Answer.
4. Step 4: Health Checks: (Optional for PHZ) Associate the record with a Route 53 Health Check (requires the health checker to have a path to the private IP, often via an executable on an instance or using CloudWatch Alarms).
5. Step 5: Verification: From an EC2 instance in the VPC, run dig +short app.internal.com. You should receive up to 8 healthy records.

Checkpoint Questions

1. What two VPC settings must be set to true for Private Hosted Zones to function?
2. True or False: A single Private Hosted Zone can be associated with VPCs in different AWS accounts.
3. Why is an Alias record generally preferred over a CNAME for routing to an Application Load Balancer?
4. In a split-view DNS setup, if a record exists in the Public zone but NOT the Private zone, what will an internal VPC client receive when querying it?

▶Click to reveal answers

1. enableDnsHostnames and enableDnsSupport.
2. True (requires cross-account authorization or AWS RAM).
3. Alias records are free to query and support mapping to the zone apex.
4. It will fail (NXDOMAIN). The resolver does not "fall back" to the public zone if the private zone exists for that domain name but is missing that specific record.

Muddy Points & Cross-Refs

• Overlapping Namespaces: If you have a PHZ for example.com and a Public HZ for example.com, the PHZ takes precedence for resources inside the VPC. If you forget to mirror a public record into the PHZ, internal clients won't find it.
• Cross-Account PHZ: Associating a PHZ with a VPC in another account is a two-step CLI/API process (Authorization -> Association) that cannot be done entirely in the standard Console UI without AWS RAM.

Comparison Tables

[!TIP] To optimize availability, use Weighted Routing in your PHZ to shift traffic away from an Availability Zone during a maintenance window or a localized failure.