Route 53 DNS Foundations

Configure hosted zones and DNS record types in Amazon Route 53.

Introduction

30 Second Summary

Every time you type a website address into your browser, a behind-the-scenes system called DNS translates that human-readable name into a numeric IP address. Understanding how this system works is essential for designing resilient, high-performing cloud architectures on AWS.

In this project, you will build a complete Route 53 DNS environment that covers every DNS concept tested on the SAA-C03 exam. You'll create public and private hosted zones, configure multiple record types, route traffic to real AWS resources, and verify DNS resolution behavior hands-on.

What You'll Build

A fully configured Amazon Route 53 DNS environment with both public and private hosted zones, multiple record types routing traffic to real AWS resources, and split-view DNS for internal resolution.

By the end of this project, you'll have:

  • A public hosted zone configured with A, CNAME, MX, TXT, CAA, and alias records that route traffic to an S3 static website and an EC2 instance.
  • A private hosted zone associated with your VPC for internal DNS resolution, demonstrating split-view DNS where the same domain name returns different answers depending on where the query comes from.
  • Hands-on verification of all records using Route 53's TestDNSAnswer API and nslookup from the command line, proving your DNS configuration works end-to-end.
  • Secret Mission: Configure subdomain delegation using NS records to simulate how large organizations manage DNS zones across different teams.

Are there any prerequisites?

You'll need an AWS account (free tier eligible) and a basic understanding of what IP addresses are and what DNS does at a high level. No domain registration is required for this project.

Create Your Public Hosted Zone

Every time you type a website address into your browser, a chain of DNS lookups happens behind the scenes to translate that human-readable name into an IP address.

In this step, you'll learn exactly how that resolution chain works and create your first Route 53 hosted zone. This is the foundation for every DNS record you'll configure in the rest of the project.

In this step, get ready to:
  • Understand the DNS resolution process from browser to authoritative server.
  • Create a public hosted zone in Route 53.
  • Examine the default NS and SOA records Route 53 creates automatically.
Understand the DNS resolution process

Before touching the console, you need to understand what happens when a user types www.example.com into their browser. The SAA-C03 exam tests your knowledge of each step in this chain.

Here's the full DNS resolution process:

  • The browser and operating system check the local DNS cache first.
  • If the answer isn't cached, the request goes to a recursive DNS resolver (your ISP or a configured resolver like 8.8.8.8).
  • The resolver asks a root name server: "Who handles .com?"
  • The TLD name server for .com responds: "Route 53's name servers handle example.com."
  • The authoritative name server (Route 53) looks up the record in the hosted zone and returns the answer.
  • The resolver caches the response for the duration of the TTL (Time To Live).
  • The browser connects to the returned IP address.

What role does Route 53 play in DNS?

Route 53 is an authoritative DNS service. It holds the definitive answer for your domain's records.

Route 53 is NOT a recursive resolver. It does not query other DNS servers on your behalf. It only answers questions about domains you've configured in your hosted zones.

What is TTL and why does it matter?

TTL determines how long resolvers cache the answer (in seconds). A longer TTL means fewer queries reach Route 53, which lowers cost but slows down propagation of changes.

A shorter TTL means changes propagate faster, but more queries reach Route 53, increasing your bill. You'll explore TTL strategy in detail later in this project.

Create a public hosted zone

A hosted zone is a container for DNS records that define how traffic is routed for a domain. A public hosted zone answers queries from the internet.

  • Open the Route 53 console at https://console.aws.amazon.com/route53/.
  • In the left navigation, choose Hosted zones.
  • Choose Create hosted zone.
  • For Domain name, enter: myexamprep.com.
  • For Type, select Public hosted zone.
  • Choose Create hosted zone.

Do I need to own this domain?

No. You don't need to register or own myexamprep.com. The hosted zone will work perfectly for learning. You just can't receive real internet traffic without domain registration.

You'll verify all your records using Route 53's built-in TestDNSAnswer tool and direct queries to the name servers.

Hosted zone pricing

A public hosted zone costs $0.50 per month. If you delete it within 12 hours of creation, you won't be charged for the zone itself (queries are still charged separately).

Examine the default records

After creation, Route 53 automatically creates two records in your hosted zone. These are mandatory for DNS to function.

  • Look at your hosted zone's record list. You should see two records already present: an NS record and an SOA record.

The NS (Name Server) record lists the 4 Route 53 name servers assigned to your zone. Notice that each server has a different top-level domain (for example, .com, .net, .org, .co.uk). This distribution across 4 TLDs provides high availability. If one TLD has issues, the other 3 still work.

The SOA (Start of Authority) record contains administrative information about the zone: the primary name server, administrator email, serial number, refresh/retry/expire timers, and the minimum TTL for negative caching.

What is negative caching?

Negative caching is how long resolvers remember "this record doesn't exist." The minimum TTL field in the SOA record controls this duration. It prevents resolvers from repeatedly asking about non-existent records.

Why can't I delete NS or SOA records?

Route 53 does not allow you to delete the NS or SOA records from a hosted zone. They are required for DNS to function correctly. The exam may present scenarios where deleting these records is offered as an option. It's always wrong.

Your public hosted zone is live and ready for records. Next up, you'll populate it with every DNS record type the SAA-C03 exam tests.

Create Standard DNS Records

Your public hosted zone is live with its NS and SOA records, which means Route 53 is ready to serve answers for myexamprep.com. But right now there's nothing useful to answer with.

In this step, you'll create the five standard record types that appear most frequently on the SAA-C03 exam. Each record type serves a distinct purpose: mapping names to IP addresses, redirecting to other domain names, routing email, storing verification data, and controlling certificate issuance.

In this step, get ready to:
  • Create an A record that maps a subdomain to an IPv4 address.
  • Create CNAME, MX, and TXT records for routing and verification purposes.
  • Create a CAA record to control which certificate authorities can issue certificates for your domain.
Create an A record

An A record is the most fundamental DNS record type. It maps a domain name directly to an IPv4 address, answering the question: "what IP address should I connect to for this name?"

  • In the Route 53 console, select your myexamprep.com hosted zone.
  • Choose Create record.
  • For Record name, enter server1.
  • For Record type, select A – Routes traffic to an IPv4 address.
  • For Value, enter 192.0.2.1.
  • For TTL, enter 300.
  • Choose Create records.

You should see the new A record appear in your hosted zone's record list, showing server1.myexamprep.com pointing to 192.0.2.1.

What did you just create?

This A record creates the mapping server1.myexamprep.com → 192.0.2.1. When anyone queries this name, Route 53 responds with that IP address.

The IP 192.0.2.1 is a documentation-reserved address (RFC 5737), which makes it safe for learning. The TTL of 300 seconds (5 minutes) means resolvers will cache this answer for 5 minutes before checking again.

What about AAAA records?

AAAA records work identically to A records, but for IPv6 addresses (e.g., 2001:0db8:85a3::8a2e:0370:7334). The exam expects you to know both exist, and that A = IPv4 while AAAA = IPv6.

Create CNAME, MX, and TXT records

These three record types each solve a different problem. CNAME records redirect one domain name to another. MX records tell email systems where to deliver mail. TXT records store text data used for verification and security.

Start with the CNAME record.

  • Choose Create record.
  • For Record name, enter www.
  • For Record type, select CNAME.
  • For Value, enter server1.myexamprep.com.
  • For TTL, enter 300.
  • Choose Create records.

What does a CNAME record do?

A CNAME (Canonical Name) record maps one domain name to another domain name, not to an IP address. When a resolver queries www.myexamprep.com, it receives the answer server1.myexamprep.com, then follows up with a second query to get the actual IP.

Critical exam rule: CNAME cannot be used at the zone apex

You CANNOT create a CNAME record at the zone apex (the naked domain myexamprep.com itself). CNAMEs can only be used for subdomains like www.myexamprep.com.

This is a DNS standard limitation, not a Route 53 limitation. This is exactly why alias records exist, which you'll create in the next step.

Now create the MX record for email routing.

  • Choose Create record.
  • Leave Record name blank (this sets the MX record at the zone apex myexamprep.com).
  • For Record type, select MX.
  • For Value, enter 10 mail.myexamprep.com.
  • For TTL, enter 300.
  • Choose Create records.

What does the 10 in the MX value mean?

The number 10 is the priority. Lower numbers mean higher priority. If you had multiple MX records (e.g., 10 mail.myexamprep.com and 20 backup-mail.myexamprep.com), email would go to the server with priority 10 first.

Finally, create the TXT record.

  • Choose Create record.
  • Leave Record name blank (zone apex).
  • For Record type, select TXT.
  • For Value, enter "v=spf1 include:amazonses.com ~all".
  • For TTL, enter 300.
  • Choose Create records.

What is this TXT record for?

TXT records store arbitrary text data. They are commonly used for email security (SPF, DKIM, DMARC) and domain ownership verification.

This SPF record tells receiving mail servers: "only Amazon SES is authorized to send email on behalf of this domain." The ~all means soft-fail anything else.

You should now see four custom records in your hosted zone: A, CNAME, MX, and TXT (alongside the auto-generated NS and SOA).

Don't see all four records?

Make sure you clicked Create records after each individual record. If a record is missing, choose Create record and enter it again using the values above.

Help me troubleshoot my Route 53 records

Create a CAA record

A CAA (Certificate Authority Authorization) record is a security control. It specifies which certificate authorities are allowed to issue SSL/TLS certificates for your domain.

  • Choose Create record.
  • Leave Record name blank (zone apex).
  • For Record type, select CAA.
  • For Value, enter 0 issue "amazon.com".
  • For TTL, enter 300.
  • Choose Create records.

What does this CAA record do?

This record tells certificate authorities: "only Amazon (ACM) is allowed to issue SSL/TLS certificates for this domain." If any other CA receives a certificate request for your domain and finds this CAA record, they must refuse to issue.

The 0 is a flags field (0 means non-critical). The issue tag specifies which CA can issue standard certificates. The value amazon.com identifies Amazon's certificate authority.

Your hosted zone now contains all five standard record types. You should see seven records total: NS, SOA (auto-generated), plus A, CNAME, MX, TXT, and CAA.

Record creation failed?

If you see an error about invalid value format, double-check that you included the quotes around amazon.com in the CAA value and the quotes around the TXT value. Route 53 is strict about formatting for these record types.

Help me fix my CAA or TXT record format

✔️ I see all seven records

Your hosted zone is fully populated with standard DNS records. Each one demonstrates a different way DNS maps names to resources or stores metadata.

ⓧ I'm missing some records

Check the record list for these seven entries: NS, SOA, A, CNAME, MX, TXT, CAA. If any custom record is missing, scroll up to find the matching instructions and create it. Each record must be created individually by choosing Create record.

You now have a complete set of standard DNS records. Next up, you'll create alias records and route traffic to real AWS resources like S3 and EC2.

Create Alias Records and Route to AWS Resources

Your hosted zone now has a complete set of standard DNS records covering A, CNAME, MX, TXT, and CAA.

There's one problem with standard records. You can't use a CNAME at the zone apex (the naked domain myexamprep.com). This step introduces alias records, which solve that problem and route traffic to AWS resources with zero query charges.

In this step, get ready to:
  • Understand the critical differences between alias and non-alias records.
  • Create an S3 static website with an alias record at the zone apex.
  • Launch an EC2 instance and create a standard A record for it.
Understand alias vs non-alias records

Alias records are a Route 53-specific extension to DNS. They let you map a domain name directly to an AWS resource (like an S3 bucket or a CloudFront distribution) without needing the resource's IP address.

Key differences between alias and non-alias records

  • Alias records point to AWS resources (ELB, CloudFront, S3, API Gateway, Global Accelerator). Non-alias records point to IP addresses or domain names.
  • Alias records CAN be used at the zone apex (naked domain). CNAME records CANNOT be used at the zone apex.
  • Alias queries to AWS resources (ELB, CloudFront, S3, API Gateway, Global Accelerator, Elastic Beanstalk) are free. Standard queries cost $0.40 per million.
  • Route 53 sets the TTL automatically for alias records. You cannot override it.
  • Alias records use Evaluate Target Health instead of separate health checks.

When to use alias records

Use alias records when routing to an ELB (Elastic Load Balancer), a CloudFront distribution, an S3 bucket configured as a website, another Route 53 record in the same hosted zone, API Gateway, Elastic Beanstalk, VPC interface endpoints, or Global Accelerator.

You CANNOT use alias records to route directly to an EC2 instance or to external (non-AWS) resources. For those, use a standard A record with the IP address.

Create an S3 static website and an alias record

You'll create an S3 bucket configured for static website hosting, then create an alias record at the zone apex that points to it. This demonstrates the primary use case for alias records on the exam.

  • Open the S3 console at https://console.aws.amazon.com/s3/.
  • Choose Create bucket.
  • For Bucket name, enter myexamprep.com.
  • For AWS Region, select US East (N. Virginia) us-east-1.
  • Scroll down to Block Public Access settings for this bucket.
  • Uncheck Block all public access.
  • A warning will appear asking you to acknowledge. Check the acknowledgment box to confirm.
  • Scroll down and choose Create bucket.

Why must the bucket name match the domain?

For an alias record to work with S3 static website hosting, the bucket name MUST exactly match the record name. Since you're creating an alias at the zone apex myexamprep.com, the bucket must also be named myexamprep.com.

Now enable static website hosting on your new bucket.

  • Click your myexamprep.com bucket to open it.
  • Choose the Properties tab.
  • Scroll to the bottom and find Static website hosting.
  • Choose Edit.
  • Select Enable for Static website hosting.
  • For Index document, enter index.html.
  • Choose Save changes.

Next, add a bucket policy to allow public read access.

  • Choose the Permissions tab.
  • Under Bucket policy, choose Edit.
  • Paste the following policy into the editor:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::myexamprep.com/*"
    }
  ]
}

What does this policy do?

  • Principal "*" means anyone on the internet can access the bucket.
  • Action s3:GetObject limits the access to reading objects only (no uploads or deletes).
  • Resource targets all objects (/*) inside the myexamprep.com bucket.
  • Choose Save changes.

Seeing an access denied error?

Make sure you unchecked Block all public access when you created the bucket. If you left it checked, go back to the Permissions tab, choose Edit under Block public access, uncheck all boxes, and save.

Help me fix my S3 bucket policy permissions.

Now upload a simple HTML file for your website.

  • Choose the Objects tab.
  • Choose Upload.
  • Create a file on your computer named index.html with the content <h1>Route 53 Exam Prep - S3 Website</h1>.
  • Choose Add files, select your index.html file, and choose Upload.

Your S3 static website is ready. Now create the alias record in Route 53.

  • Open the Route 53 console at https://console.aws.amazon.com/route53/.
  • In the left navigation, choose Hosted zones.
  • Choose myexamprep.com to open your hosted zone.
  • Choose Create record.
  • Leave Record name blank (this creates the record at the zone apex myexamprep.com).
  • Toggle on the Alias switch.
  • For Route traffic to, choose Alias to S3 website endpoint.
  • For Region, select US East (N. Virginia).
  • Select the S3 endpoint that appears in the dropdown (it will show your myexamprep.com bucket).
  • Choose Create records.

You should see a new A record appear in your hosted zone with the type showing A and the Alias column showing Yes.

Why is this alias record at the zone apex so important for the exam?

A CNAME record cannot exist at the zone apex. This is a DNS standard limitation, not a Route 53 limitation. The exam frequently asks: "How do you route the naked domain (example.com) to an S3 website, ELB, or CloudFront?" The answer is always an alias record with record type A.

Alias queries to S3 website endpoints are also free, which makes this a cost-optimized approach.

Bucket not appearing in the dropdown?

Route 53 only shows your bucket if all three conditions are met: the bucket name matches the record name, static website hosting is enabled, and the bucket was created in the same AWS account. Double-check that you named the bucket exactly myexamprep.com and that static website hosting is enabled on it.

Help me troubleshoot why my S3 bucket isn't appearing in Route 53.

Create an A record for an EC2 instance

EC2 instances cannot use alias records. You must use a standard A record with the instance's public IP address. This is a critical exam distinction.

First, launch a t2.micro instance that will serve a simple web page.

  • Open the EC2 console at https://console.aws.amazon.com/ec2/.
  • Choose Launch instance.
  • For Name, enter Route53-ExamPrep.
  • For AMI, select Amazon Linux 2023 (it should be the default selection).
  • For Instance type, select t2.micro (free tier eligible).
  • For Key pair, select Proceed without a key pair (you won't need SSH for this project).
  • Under Network settings, choose Edit.
  • Under Firewall (security groups), choose Create security group.
  • Check Allow SSH traffic from Anywhere.
  • Check Allow HTTP traffic from the internet.

Now add a user data script that will automatically install and start a web server when the instance launches.

  • Expand Advanced details at the bottom of the launch page.
  • Scroll down to the User data text box.
  • Paste the following script into the User data field:
#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Route 53 Exam Prep - EC2 Instance</h1>" > /var/www/html/index.html

What does this user data script do?

  • yum update -y updates all system packages.
  • yum install -y httpd installs the Apache web server.
  • systemctl start httpd starts the web server immediately.
  • systemctl enable httpd ensures Apache starts automatically on reboot.
  • The final line writes a simple HTML page to the default web root.
  • Choose Launch instance.
  • Wait for the instance to reach the Running state (this takes about 30-60 seconds).
  • Click on your instance ID to open the instance details.
  • Find the Public IPv4 address field and note this IP address. You will need it for the DNS record.

Verify your web server is working by pasting the public IP address into a new browser tab. You should see the heading "Route 53 Exam Prep - EC2 Instance" after 1-2 minutes (the user data script needs time to complete).

Not seeing the web page?

Wait 2-3 minutes after launch for the user data script to finish. If you still see nothing, check that your security group allows HTTP (port 80) from anywhere. You can verify this in the Security tab of your instance details.

Help me troubleshoot why my EC2 web server isn't responding.

Now create the A record in Route 53 pointing to your EC2 instance.

  • Return to the Route 53 console and open your myexamprep.com hosted zone.
  • Choose Create record.
  • For Record name, enter web (this creates web.myexamprep.com).
  • For Record type, select A.
  • For Value, enter your EC2 instance's public IPv4 address.
  • For TTL, enter 60 (seconds).
  • Choose Create records.

Why use TTL 60 for EC2 and why no alias?

EC2 public IPs change every time you stop and start an instance. A low TTL of 60 seconds means DNS resolvers will re-check frequently, reducing downtime if the IP changes.

You cannot create an alias record directly to an EC2 instance. To use an alias, you would need to put an Elastic Load Balancer in front of the instance and alias to the ELB instead. The exam tests this distinction frequently.

Record not showing in your hosted zone?

Make sure you entered web in the Record name field (not the full web.myexamprep.com). Route 53 automatically appends the hosted zone name. Also confirm the Record type is set to A and not CNAME.

Help me create an A record in Route 53 for my EC2 instance.

Your public hosted zone now routes traffic to two real AWS resources. Next up, you'll verify that all your DNS records resolve correctly using Route 53's TestDNSAnswer tool and command-line queries.

Verify DNS Records with TestDNSAnswer

In the previous step, you created alias records and routed traffic to real AWS resources. You now have a fully populated hosted zone with every record type relevant to the SAA-C03 exam.

The challenge is that you don't own the domain myexamprep.com, so internet resolvers won't route queries to your hosted zone. In this step, you'll use Route 53's built-in TestDNSAnswer tool and Windows nslookup to verify every record you created, proving that your DNS configuration works correctly.

In this step, get ready to:
  • Verify DNS records using Route 53's TestDNSAnswer in the console.
  • Query your Route 53 name servers directly using nslookup from Command Prompt.
  • Understand TTL behavior and its impact on cost, propagation, and failover for the exam.
Use TestDNSAnswer in the console

Since you don't own the domain, internet resolvers won't route queries to your hosted zone. Route 53's TestDNSAnswer lets you query your hosted zone directly as if you were the authoritative server.

  • In the Route 53 console, choose Hosted zones in the left navigation.
  • Click on your myexamprep.com hosted zone to view its records.
  • In the left navigation under DNS management, choose Test record.
  • Select your myexamprep.com hosted zone at the top of the page.

What is TestDNSAnswer?

TestDNSAnswer simulates a DNS query against your hosted zone and shows you exactly what Route 53 would return. It bypasses the entire public DNS hierarchy and queries Route 53 directly as the authoritative server.

This is how you verify records for a domain you don't own. Real-world DNS resolvers will never reach your zone (because the TLD servers don't point to it), but TestDNSAnswer lets you confirm everything is configured correctly.

Now test each record type you created. For each test, enter the record name and select the record type, then choose Get Response.

  • Leave Record name blank and set Type to A. Choose Get Response. This queries the zone apex and should return the S3 alias response.
  • Enter server1 in Record name and set Type to A. Choose Get Response. You should see 192.0.2.1 in the response.
  • Enter www in Record name and set Type to CNAME. Choose Get Response. You should see server1.myexamprep.com in the response.
  • Leave Record name blank and set Type to MX. Choose Get Response. You should see 10 mail.myexamprep.com in the response.
  • Leave Record name blank and set Type to TXT. Choose Get Response. You should see your SPF record in the response.

What should I see?

For each test, the response section shows three things: the DNS query sent to Route 53 (in BIND format), a DNS response code (NOERROR means success), and the response record values. If you see NOERROR and the expected value, your record is configured correctly.

Seeing NXDOMAIN or no response?

Make sure you selected the correct hosted zone at the top of the Test record page. Double-check that the record name you entered matches what you created (excluding the hosted zone name). For example, enter server1 not server1.myexamprep.com.

Help me troubleshoot my TestDNSAnswer results.

Use nslookup from Command Prompt to query Route 53 directly

You can also query your Route 53 name servers directly from the command line. This proves that Route 53 is responding authoritatively for your zone, even though the domain isn't registered.

First, you need one of the name server addresses from your hosted zone's NS record. You noted these in Step 1 when you examined the default records.

  • Return to your hosted zone in the Route 53 console and find the NS record.
  • Copy one of the four name server addresses (it will look something like ns-1234.awsdns-56.com).
  • Open Command Prompt by pressing the Windows key, typing cmd, and pressing Enter.
  • Query the A record for server1.myexamprep.com by running this command:
nslookup server1.myexamprep.com [[NS_SERVER="your Route 53 name server e.g. ns-1234.awsdns-56.com"]]

You should see 192.0.2.1 in the response. This confirms that Route 53 is serving your A record correctly.

  • Query different record types by running these commands:
nslookup -type=MX myexamprep.com [[NS_SERVER="your Route 53 name server e.g. ns-1234.awsdns-56.com"]]
nslookup -type=TXT myexamprep.com [[NS_SERVER="your Route 53 name server e.g. ns-1234.awsdns-56.com"]]
nslookup -type=CNAME www.myexamprep.com [[NS_SERVER="your Route 53 name server e.g. ns-1234.awsdns-56.com"]]

What do these commands do?

Each nslookup command directly queries one of your Route 53 authoritative name servers. The -type= flag specifies which record type to look up. By specifying your Route 53 name server as the last argument, you bypass the normal DNS resolution chain and go straight to the source.

The MX query should return 10 mail.myexamprep.com. The TXT query should return your SPF record. The CNAME query should return server1.myexamprep.com.

Getting a timeout or DNS request timed out?

Make sure you replaced the name server placeholder with one of your actual NS record values from the hosted zone. Check that you copied the full name server address including the TLD (e.g. the .com, .net, .org, or .co.uk ending).

Help me fix my nslookup command.

Understand TTL behavior for the exam

TTL (Time To Live) is set in seconds and determines how long recursive resolvers cache your DNS answers. This directly impacts cost, change propagation speed, and failover effectiveness.

What does TTL mean for the exam?

  • 60 seconds (1 minute): Use for records that change frequently, like EC2 instance IPs or during migrations.
  • 300 seconds (5 minutes): A good default for most records.
  • 86400 seconds (24 hours): Use for stable records that rarely change.
  • Alias records: Route 53 sets TTL automatically. You cannot override it.

The exam tests TTL in several common scenarios. Make sure you understand each one.

  • Scenario: "Reduce DNS propagation time during migration." The answer is to lower TTL to 60 seconds BEFORE the migration. Wait for the old TTL to expire so all resolvers fetch fresh answers. Then make the DNS change. After migration is stable, raise TTL back.
  • Scenario: "Reduce Route 53 costs." The answer is to increase TTL. Longer caching means fewer queries reach Route 53, which means lower query charges.
  • Scenario: "Health check failover isn't working fast enough." The answer is that TTL of 60 seconds or less is recommended for records using health checks, so failover triggers quickly.

Why can't you set TTL on alias records?

Route 53 manages alias record TTL automatically to match the target resource's TTL. This ensures the alias response stays in sync with the underlying AWS resource. On the exam, if a question mentions setting TTL on an alias record, it's a distractor. You cannot do it.

Extra for Experts: TTL and cost optimization

Alias queries to AWS resources (ELB, CloudFront, S3 website endpoints, API Gateway, Global Accelerator) are free. Standard queries cost $0.40 per million. Latency-based routing queries cost $0.60 per million. Combining alias records with higher TTL values on standard records is the most cost-effective DNS configuration.

You've now verified every record in your hosted zone using two different tools. Next up, you'll create a private hosted zone for internal DNS resolution and explore how split-view DNS works inside a VPC.

Create a Private Hosted Zone for Internal DNS

Your public hosted zone is fully verified and routing traffic to real AWS resources. Now it's time to explore the other side of Route 53: internal DNS that only your VPC resources can see.

In production environments, teams use private hosted zones to give internal resources friendly hostnames like db.myexamprep.com instead of raw IP addresses. In this step, you'll create a private hosted zone with the same domain name as your public zone to demonstrate split-view DNS.

In this step, get ready to:
  • Create a private hosted zone associated with your VPC.
  • Add internal A records for simulated services.
  • Verify split-view DNS and understand NXDOMAIN behavior.
Create a private hosted zone

A private hosted zone works just like a public one, but its records are only resolvable from within VPCs you associate with it. DNS queries on private hosted zones are free.

  • Return to the Route 53 console.
  • In the left navigation, choose Hosted zones.
  • Choose Create hosted zone.
  • For Domain name, enter: myexamprep.com.
  • For Type, select Private hosted zone.
  • Under VPCs to associate with the hosted zone, select your default VPC in us-east-1.
  • Choose Create hosted zone.

Why the same domain name?

Using the same domain name for both a public and private hosted zone is exactly how split-view DNS works. Resources inside your VPC get answers from the private zone, while everyone else gets answers from the public zone.

How is a private hosted zone different from a public one?

  • Private hosted zones are only resolvable from within associated VPCs.
  • DNS queries on private hosted zones are free (no per-query charges).
  • You can associate up to 300 VPCs with a single private hosted zone.
  • The VPC must have enableDnsHostnames and enableDnsSupport set to true (default VPCs already have these enabled).

You should now see your new private hosted zone listed alongside your existing public one. Route 53 automatically creates NS and SOA records for it, just like it did for the public zone.

Don't see a VPC to select?

Make sure the region dropdown at the top of the page shows US East (N. Virginia). Your default VPC only appears when the correct region is selected.

Help me find my VPC when creating a private hosted zone

Create internal A records

Internal records give your VPC resources friendly names that resolve to private IP addresses. These records are invisible to the public internet.

  • In your private hosted zone, choose Create record.
  • For Record name, enter: db.
  • For Record type, select A.
  • For Value, enter: 10.0.0.50.
  • For TTL, enter: 300.
  • Choose Create records.

This creates db.myexamprep.com pointing to a private IP that simulates an internal database server. Now create the second record.

  • Choose Create record.
  • For Record name, enter: api.
  • For Record type, select A.
  • For Value, enter: 10.0.0.100.
  • For TTL, enter: 300.
  • Choose Create records.

This creates api.myexamprep.com simulating an internal API server. Now create the third record using your EC2 instance's private IP.

  • Open the EC2 console in a new tab.
  • Select your running instance.
  • Click the Networking tab in the details pane below.
  • Copy the Private IPv4 addresses value (it will look something like 172.31.x.x for a default VPC).
  • Return to your private hosted zone in Route 53.
  • Choose Create record.
  • For Record name, enter: web.
  • For Record type, select A.
  • For Value, paste your EC2 instance's private IPv4 address.
  • For TTL, enter: 300.
  • Choose Create records.

Why use the private IP here?

In your public hosted zone, web.myexamprep.com points to the EC2 instance's public IP. In this private zone, it points to the private IP. This is the foundation of split-view DNS: the same hostname resolves to different addresses depending on where the query originates.

Your private hosted zone should now show three A records alongside the default NS and SOA records.

Verify split-view DNS behavior

Split-view DNS means the same domain name returns different answers depending on where the query originates. To prove this works, you'll query from inside your VPC by SSH-ing into your EC2 instance.

  • Open Command Prompt on your Windows machine.
  • SSH into your EC2 instance by running this command:
ssh -i [[PEMPATH="path to your .pem key file"]] ec2-user@[[EC2_PUBLIC_IP="your EC2 public IPv4 address"]]

Where do I find my key file path?

When you launched your EC2 instance in the previous step, you selected or created a key pair. The .pem file was downloaded to your computer at that time. Use the full path to that file (for example, C:\Users\YourName\Downloads\my-key.pem).

  • Once connected, run this command on the EC2 instance:
nslookup web.myexamprep.com

What should I see?

This query goes through the VPC Resolver (located at the VPC CIDR base +2 address, for example 10.0.0.2 for a 10.0.0.0/16 VPC). It should return the private IP address you just configured in your private hosted zone.

Meanwhile, querying from outside the VPC (using the Route 53 name servers directly, like you did in the previous step) would return the public IP from your public hosted zone. Same hostname, different answers.

How does the VPC Resolver decide which zone to use?

  • Is there a private hosted zone associated with this VPC that matches the query? Use the private zone.
  • If the private zone exists but has NO matching record for the name and type, return NXDOMAIN. It does NOT fall through to the public zone.
  • If NO private zone matches the query domain at all, forward to public DNS.

The NXDOMAIN trap (common exam question)

If a private hosted zone exists for myexamprep.com and someone queries blog.myexamprep.com from within the VPC, but that record doesn't exist in the private zone, Route 53 returns NXDOMAIN. It does NOT check the public zone.

This catches many exam takers off guard. Remember: once a private zone matches the domain, the resolver commits to that zone. No fallback.

  • Test the NXDOMAIN behavior yourself by running:
nslookup blog.myexamprep.com

This should fail with a "server can't find" response because blog.myexamprep.com doesn't exist in your private zone. The resolver does not fall through to the public zone, even though the public zone might have a record for it.

Getting connection refused when SSH-ing in?

Check that your EC2 instance's security group allows SSH (port 22) from your IP address. Also confirm the instance is in a running state in the EC2 console.

Help me troubleshoot my SSH connection to EC2

Your private hosted zone is live and demonstrating split-view DNS in action. Next up, you'll consolidate everything you've learned about Route 53 pricing and review the key exam scenarios that tie all these concepts together.

Review Route 53 Pricing and Exam Concepts

You've built a complete DNS environment with public and private hosted zones, multiple record types, and verified resolution behavior. Now it's time to consolidate everything into exam-ready knowledge.

The SAA-C03 frequently tests pricing scenarios and "which record type should I use?" decisions. This step organizes the pricing model, record types, and the most common exam scenarios into a reference you can revisit before test day.

In this step, get ready to:
  • Review the Route 53 pricing model and cost optimization strategies.
  • Study the complete record types reference table for the exam.
  • Memorize 10 key exam scenarios and their answers.
Review the Route 53 pricing model

The SAA-C03 tests cost optimization across all four domains. Understanding Route 53 pricing helps you answer questions about reducing DNS costs and choosing the right record type.

Here is the complete pricing breakdown relevant to the exam:

  • Public Hosted Zone: $0.50/month for the first 25 zones. $0.10/month for each additional zone.
  • Private Hosted Zone queries: Free. Route 53 does not charge for queries on private hosted zones.
  • Standard DNS queries (public): $0.40 per million queries (first 1 billion per month).
  • Latency-based routing queries: $0.60 per million queries (first 1 billion per month).
  • Alias queries to AWS resources: Free for Elastic Load Balancers, Amazon CloudFront, AWS Elastic Beanstalk environments, Amazon API Gateway, Amazon S3 buckets configured as website endpoints, Amazon AppRunner, Amazon AppSync, Amazon LightSail, and Amazon Global Accelerator.
  • Health checks (AWS endpoints): First 50 free, then $0.50/month each.
  • Health checks (non-AWS endpoints): $0.75/month each.
  • Hosted zone deleted within 12 hours: Free (but queries on public hosted zones still incur charges).

What cost optimization scenarios appear on the exam?

"How do you reduce DNS costs?" Use alias records for AWS resources (free queries) and increase TTL values (fewer queries reach Route 53).

"Which routing policy incurs higher per-query costs?" Latency-based routing queries cost $0.60 per million compared to $0.40 per million for standard queries.

Study the complete record types reference

This reference covers every record type you might encounter on the SAA-C03. You've created most of these hands-on in the previous steps.

  • A record: Maps a name to an IPv4 address. Can be used at the zone apex. The most common record type.
  • AAAA record: Maps a name to an IPv6 address. Can be used at the zone apex. Same as A but for IPv6.
  • CNAME record: Maps one domain name to another domain name. CANNOT be used at the zone apex. Cannot coexist with other records of the same name.
  • Alias record: Maps a name to an AWS resource. Can be used at the zone apex. Free queries and automatic TTL. Route 53 specific (not a standard DNS type).
  • MX record: Specifies mail servers. Can be used at the zone apex. Uses a priority number (lower number = higher priority).
  • TXT record: Stores text data. Can be used at the zone apex. Used for SPF, DKIM, and domain verification.
  • NS record: Delegates to name servers. Can be used at the zone apex. Four NS records are auto-created per hosted zone. Also used for subdomain delegation.
  • SOA record: Contains zone administrative information. Auto-created and cannot be deleted.
  • CAA record: Specifies which certificate authorities can issue SSL/TLS certificates for the domain. A security control.
  • SRV record: Locates services using protocol, port, priority, weight, and target.
  • PTR record: Reverse DNS lookup (maps an IP address back to a name). Used in reverse lookup zones.

Why is the CNAME zone apex restriction so important?

This is one of the most frequently tested Route 53 concepts. CNAME records cannot exist at the zone apex because DNS standards require that NS and SOA records always exist there. A CNAME cannot coexist with any other record of the same name.

This is the entire reason alias records exist. When the exam asks "how do you route the naked domain to an ELB, CloudFront, or S3 website?" the answer is always an alias record with record type A.

Memorize 10 key exam scenarios

These are the most common Route 53 DNS scenarios that appear on the SAA-C03. Each one maps directly to a concept you built hands-on in this project.

  • "Route naked domain to ELB" — Alias record (type A) at zone apex pointing to the Elastic Load Balancer.
  • "Route naked domain to S3 website" — Alias record (type A). The bucket name MUST match the domain name.
  • "Route subdomain to EC2" — Standard A record with the public IP. You cannot create an alias record directly to an EC2 instance.
  • "Reduce DNS propagation time during migration" — Lower TTL to 60 seconds BEFORE the migration. Wait for the old TTL to expire, then make the change. Raise TTL back after migration is stable.
  • "Internal DNS for VPC resources" — Private hosted zone associated with the VPC.
  • "Same domain name, different results internally vs externally" — Split-view DNS using a public and private hosted zone with the same domain name.
  • "CNAME at zone apex" — Impossible. Use an alias record instead.
  • "Hosted zone has 4 name servers across different TLDs" — High availability design. If one TLD fails, the other three still work.
  • "Private hosted zone NXDOMAIN" — If a private hosted zone matches the query domain but has no record for the queried name and type, Route 53 returns NXDOMAIN. It does NOT fall through to public DNS.
  • "Reduce Route 53 bill" — Use alias records for AWS resources (free queries). Increase TTL values (fewer queries reach Route 53).

Why does the NXDOMAIN trap matter so much?

If there's a matching private hosted zone but there's no record that matches the domain name and type in the request, VPC Resolver doesn't forward the request to a public DNS resolver. Instead, it returns NXDOMAIN (non-existent domain) to the client.

This means creating a private hosted zone for a domain you also host publicly requires careful planning. Every name your VPC resources query must exist in the private zone, or those queries will fail silently.

Connect scenarios to your hands-on work

You've built every one of these scenarios in your own AWS account. When you see these questions on the exam, picture the records you created in your myexamprep.com hosted zone. Hands-on memory is stronger than memorized facts.

Secret mission

Subdomain Delegation with NS Records

In large organizations, different teams often manage their own DNS zones. The platform team owns the root domain, while the dev team manages their own subdomain independently. Can you set up subdomain delegation using NS records to simulate this enterprise pattern?

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

This project uses hosted zones that cost $0.50 per month each. The EC2 instance and S3 bucket are free tier eligible.

Cost warning

You created 3 hosted zones in this project. Each costs $0.50 per month, totaling $1.50/month if left running.

If you delete your hosted zones within 12 hours of creation, you won't be charged for them. Queries on public hosted zones will still incur charges.

Resources you used:

  • Public hosted zone: myexamprep.com ($0.50/month).
  • Public hosted zone: dev.myexamprep.com ($0.50/month, from Secret Mission).
  • Private hosted zone: myexamprep.com ($0.50/month).
  • EC2 instance (t2.micro) in us-east-1 (free tier eligible).
  • S3 bucket: myexamprep.com (free tier eligible).

Keep everything running

No action needed. Choose this if you're still actively building or plan to continue with the next Route 53 project on routing policies.

  • Your 3 hosted zones will cost $1.50/month total.
  • Your EC2 instance continues running within free tier.
  • Your S3 bucket remains within free tier.

Pause - I'll come back to this later

Shut down your EC2 instance to free up compute resources. Hosted zones continue to cost $0.50/month each.

  • Open the EC2 console.
  • Select your instance, then choose Instance state > Stop instance.
  • Your hosted zones will remain active and continue to cost $0.50/month each ($1.50 total).
  • Your S3 bucket and its contents remain in place at no additional cost.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow these steps in order.

Delete the hosted zones:

  • Open the Route 53 console and choose Hosted zones.
  • Select the dev.myexamprep.com hosted zone.
  • Delete all records except the NS and SOA records (select the A record for app.dev.myexamprep.com and choose Delete record).
  • Go back to the hosted zones list, select dev.myexamprep.com, and choose Delete.
  • Repeat for the private hosted zone myexamprep.com. Delete the A records for db, api, and web first, then delete the hosted zone.
  • Repeat for the public hosted zone myexamprep.com. Delete all records you created (A, CNAME, MX, TXT, CAA, alias A, and the NS delegation record for dev) first, then delete the hosted zone.

Terminate the EC2 instance:

  • Open the EC2 console.
  • Select your instance, then choose Instance state > Terminate instance.
  • Confirm the termination.

Empty and delete the S3 bucket:

  • Open the S3 console.
  • Select the myexamprep.com bucket.
  • Choose Empty, type permanently delete to confirm, and choose Empty.
  • Go back to the bucket list, select myexamprep.com, choose Delete, type the bucket name to confirm, and choose Delete bucket.

12-hour grace period

If you delete your hosted zones within 12 hours of creating them, you won't be charged the $0.50/month fee for any of them.

Nice Work!

Nice Work!

Nice work! You've built a complete Route 53 DNS environment from scratch, covering every DNS concept and record type tested on the SAA-C03 exam.

You've learned how to:

  • Create a public hosted zone with every exam-relevant DNS record type (A, CNAME, MX, TXT, CAA, alias) and route traffic to real AWS resources like S3 and EC2.
  • Set up a private hosted zone and demonstrate split-view DNS, where the same domain name returns different answers depending on whether the query originates inside or outside a VPC.
  • Verify DNS behavior using TestDNSAnswer and nslookup, and master TTL concepts, alias record advantages, and the Route 53 pricing model for exam readiness.
  • Secret Mission: Implemented subdomain delegation using NS records to simulate how large organizations manage DNS zones across different teams.

Ready to quiz yourself?