Courseiva
ANS-C01Chapter 14 of 15Objective 2.4

DNS and Content Delivery with Route 53 and CloudFront

DNS and Content Delivery with Route 53 and CloudFront. This is how the internet finds the right server and delivers content to you at lightning speed, without every request having to travel across the planet. For the ANS-C01 exam, you must understand how these services work together to make websites fast, reliable, and secure, because real-world networks rely on them daily.

12 min read
Intermediate
Updated Jul 23, 2026
Editorial oversight: Johnson Ajibi· Security Systems Architect · MSc IT Security · IEEE Senior Member

A simple way to picture DNS and Content Delivery with Route 53 and CloudFront

The Library Phone Directory Analogy

Have you ever called a giant library to ask if they have a specific book, only to be transferred to a dozen different departments before you get an answer?

DNS (Domain Name System) and CloudFront (a content delivery network) are like a super-efficient phone directory and a network of neighbourhood book depositories for that library.

Imagine you want to read "The Hobbit." Instead of calling the main library, your phone first contacts the DNS — the library’s master phone directory. It doesn’t have the book, but it knows the exact department that does (like "Fantasy Fiction, 3rd Floor, West Wing"). That’s a DNS record: it translates the friendly name "thehobbit.com" into an IP address, which is the precise location of the library server that has the book.

Now, imagine hundreds of people in London, Sydney, and Tokyo all want that book at the same time. The main library in New York would get swamped. CloudFront solves this by creating miniature "local depositories" in cities all over the world. When you ask for the book, CloudFront checks if your local depository already has a copy saved (a cache). If it does, you get it instantly — no need to cross the ocean. If not, it copies the book from the main library, stores it in your local depository, and hands it to you quickly.

The result: you always get the book fast, the main library isn’t overwhelmed, and the phone directory always points you to the nearest depository. That’s exactly how Route 53 (AWS’s DNS service) and CloudFront work together for the internet.

How It Actually Works

Let’s start with the basic problem. The internet runs on numbers. Every device connected to the internet — every web server, every laptop, every phone — has a unique numerical address called an IP address. But humans are bad at remembering long strings of numbers like 192.0.2.1. We prefer names, like "amazon.com" or "myapp.io."

DNS, the Domain Name System, is the phonebook of the internet. It translates human-friendly domain names (like "example.com") into IP addresses (like "93.184.216.34"). When you type a website address into your browser, your computer first asks a DNS server: "Where is example.com?" The DNS server replies with the IP address of the server that hosts that website. Only then can your browser connect to that server and download the page.

Route 53 is Amazon Web Services’ (AWS) DNS service. It does the translation work, but it also does much more. Route 53 can route traffic based on rules you set. For example, it can send users in Europe to a server in London, users in Asia to a server in Singapore, and everyone else to a server in Virginia. This is called a routing policy. Route 53 also checks if your servers are healthy. If one server crashes, it stops sending traffic there and redirects users to a working server. AWS named it Route 53 because DNS uses port 53 for its communication.

Now, even with fast DNS, a problem remains. If your website’s server is in New York, a user in Tokyo has to send a request across the Pacific Ocean and back, which takes time. The farther the data travels, the longer the delay. This delay is called latency.

CloudFront solves this. CloudFront is a content delivery network (CDN). A CDN is a system of many servers placed in data centres all over the world. These servers are called edge locations. When you set up CloudFront, you configure it to deliver your website’s files — images, videos, HTML pages, CSS files, JavaScript — from these edge locations.

How does CloudFront deliver content so fast? It uses caching. Caching means storing a copy of a file at an edge location that is close to the user. The first time a user in Tokyo requests your website’s logo image, CloudFront’s nearest edge location in Tokyo checks its cache. If it does not have the image, it fetches the original from your New York server (the origin), stores a copy in Tokyo, and sends it to the user. The next time a user in Tokyo requests the same image, CloudFront serves it from the Tokyo edge location immediately. No need to go to New York again.

Route 53 and CloudFront work together seamlessly. When a user types your domain name, Route 53 can automatically point them to the nearest CloudFront edge location. This combo makes websites faster and more reliable.

DNS and CloudFront also improve security. Route 53 can be integrated with AWS Shield, a service that protects against distributed denial-of-service (DDoS) attacks, which try to overwhelm a website with traffic. CloudFront can block malicious requests at the edge, stopping attacks before they reach your origin server.

For the ANS-C01 exam, you need to know the specific types of DNS records that Route 53 supports. Key record types include:

A record: Maps a domain name to an IPv4 address (like 192.0.2.1).

AAAA record: Maps a domain name to an IPv6 address (like 2001:db8::1).

CNAME record: Maps a domain name to another domain name (like "www.example.com" to "example.com").

MX record: Specifies mail servers for a domain.

TXT record: Holds arbitrary text, often used for security verification.

Alias record: Route 53-specific; maps a domain name to an AWS resource (like a CloudFront distribution or an Elastic Load Balancer) and works for the zone apex (the root domain like "example.com" without "www").

Route 53 offers several routing policies that determine how it answers DNS queries. The most important for the exam are:

Simple routing: Just returns one IP address for a domain.

Weighted routing: Sends a percentage of traffic to different servers (e.g., 10% to a new version of your site for testing).

Latency-based routing: Sends users to the server region with the lowest latency for that user.

Failover routing: Routes traffic to a primary server, and if that server fails, routes to a backup.

Geolocation routing: Routes traffic based on the geographic location of the user’s IP address.

Geoproximity routing: Routes traffic based on the physical distance between the user and a server, and you can optionally shift traffic using a bias value.

Multivalue answer routing: Returns multiple IP addresses in response to a DNS query, similar to simple routing but with health checks.

When using CloudFront, you must understand key concepts:

Distribution: The configuration that tells CloudFront which files to deliver and how. There are two types: web distributions for HTTP/HTTPS content, and RTMP distributions for streaming video (RTMP is legacy).

Origin: The source of the original files. This can be an S3 bucket, an HTTP server (like an EC2 instance or an on-premises server), or an AWS service like Elastic Load Balancer.

Edge location: A data centre with CloudFront servers that cache copies of your content.

Cache behavior: Rules that determine how long CloudFront keeps a file cached (the TTL, or time to live), and whether to forward requests to the origin or serve from cache.

Signed URLs and Signed Cookies: Used to restrict access to premium content, like a private video. Only users with a valid signed URL can access the file.

Origin Access Control (OAC): A security feature that ensures only CloudFront can access your S3 bucket origin.

A common exam scenario is how to use CloudFront with an Application Load Balancer (ALB) as the origin. The ALB sits in front of your EC2 instances, and CloudFront caches content from the ALB. This adds both speed and security. Route 53 points the user’s browser to the CloudFront distribution’s domain name (like d123.cloudfront.net) instead of directly to your servers.

The core principle is simple: DNS finds where the content lives, and the CDN brings that content as close to the user as possible. Route 53 makes the first step smart, and CloudFront makes the second step fast.

This diagram shows how a user request flows from browser through Route 53 DNS to a CloudFront edge location, where cache is checked and origin content is fetched if needed.

Walk-Through

1

Register Domain and Create Hosted Zone

Register your domain (e.g., myapp.com) with Route 53 or transfer an existing one. Route 53 automatically creates a hosted zone, which is a container for all DNS records for that domain. This hosted zone has four authoritative name servers that answer DNS queries from the internet.

2

Configure Route 53 Records

Create DNS records in the hosted zone. For a web application, create an Alias record (not a CNAME) that maps myapp.com to your CloudFront distribution’s domain name. Optionally, create CNAME records for subdomains like www.myapp.com. This step makes your domain point to CloudFront for content delivery.

3

Create a CloudFront Distribution and Add Origins

In CloudFront, create a new web distribution. Define origins: for static files (images, CSS), use an S3 bucket; for dynamic content (HTML, API responses), use an Application Load Balancer or an EC2 instance. You can add multiple origins in one distribution. Each origin is the source of a specific type of content.

4

Define Cache Behaviours for Path Patterns

Set cache behaviours that match URL path patterns to specific origins. For example, path pattern '/images/*' sends requests to the S3 bucket origin with a 24-hour TTL. The default behaviour (for '/') sends dynamic requests to the ALB origin with a 0-second TTL (no caching). This controls how long CloudFront keeps different types of content cached.

5

Implement Security: Origin Access Control and Signed URLs

Set up Origin Access Control (OAC) to ensure only CloudFront can access your private S3 bucket. For premium content, generate signed URLs using a CloudFront key pair. The URLs contain a signature that expires after a set time, so only authorised users can access the content. This step protects your content from unauthorised access.

6

Associate AWS WAF and Enable Monitoring

Associate your CloudFront distribution with an AWS WAF web ACL to block common attack patterns like SQL injection or cross-site scripting. Enable CloudFront logs and CloudWatch metrics to monitor requests, error rates, and cache hit ratios. This gives you visibility into performance and security events.

What This Looks Like on the Job

An IT professional working for an e-commerce company called "ShopEasy" needs to ensure its website loads quickly for customers worldwide, especially during a big sale event. The company sells physical products — clothing and electronics — and has a web application hosted on AWS. The server infrastructure runs on EC2 instances behind an Application Load Balancer, with a static S3 bucket for product images and CSS files.

Here is the step-by-step process they would follow. First, they register the domain name "shopeasy.com" in Route 53. They create a hosted zone, which is a container for DNS records. Inside this zone, they create an A record (or an Alias record) that points shopeasy.com to the Application Load Balancer’s DNS name. They also create a CNAME record for "www.shopeasy.com" that points to "shopeasy.com." This ensures both variants of the domain work.

Next, they set up CloudFront. They create a CloudFront web distribution. For the origin, they specify the Application Load Balancer’s DNS name. They add a second origin for the S3 bucket containing images and CSS. CloudFront will treat these as two separate origins within one distribution. They configure cache behaviors: for the path "/images/*" and "/css/*", they set a longer cache time (TTL of 24 hours) because product images rarely change. For the main website path "/" (which includes dynamic content like prices and stock levels), they set a shorter TTL or even no caching, because prices change during sales.

They then update the Route 53 record to point shopeasy.com to the CloudFront distribution’s domain name (e.g., d123.cloudfront.net). Now, when a customer in Brazil visits shopeasy.com, their browser asks Route 53 for the IP address. Route 53 returns the IP of the nearest CloudFront edge location in São Paulo. The browser requests the page from that edge. CloudFront in São Paulo checks its cache. For the HTML page (dynamic), if it is not cached, CloudFront forwards the request to the origin ALB in us-east-1. The ALB processes the request, returns the HTML, and CloudFront passes it to the user. For the static image of a T-shirt, CloudFront in São Paulo likely has it cached, so it delivers it instantly.

During the sale, the company wants to do a canary deployment — testing a new checkout page with 5% of users. They configure Route 53 weighted routing. They have two records: one pointing to the current production ALB (weight 95) and one pointing to a new ALB with the new checkout page (weight 5). This way, only 5% of DNS queries go to the new checkout.

They also enable health checks. Route 53 continuously checks that the ALB and EC2 instances respond correctly. If the new checkout page causes errors, the health check fails, and Route 53 automatically stops routing traffic to that server, directing all traffic to the healthy production server.

Finally, they set up CloudFront signed URLs to protect a private video demonstrating a new product. Only customers who have purchased the product and received a unique link via email can access it. They configure a CloudFront key pair and write a small server-side function to generate these signed URLs upon purchase confirmation.

The result: ShopEasy’s website loads quickly globally, remains available during the sale, and securely delivers premium content. The IT professional monitors performance using Amazon CloudWatch and CloudFront access logs to see which edge locations are most used and how much data is transferred.

How ANS-C01 Actually Tests This

The ANS-C01 exam tests DNS and content delivery extensively. You must be ready for scenario-based questions that ask you to select the best Route 53 routing policy or CloudFront configuration for a given use case. The exam does not ask you to remember the exact AWS CLI commands, but it does require deep understanding of how these services work and how to design network architectures with them.

Here are the specific concepts and question patterns you will encounter.

Route 53 record types: The exam loves Alias records versus CNAME records. A common trap: CNAME records do not work for the zone apex (e.g., "example.com"). Only Alias records can point the zone apex to an AWS resource. You will see questions where the wrong answer is a CNAME record for the root domain.

Routing policy selection: Questions will describe a scenario (e.g., "Users in different regions need the lowest latency" or "We want to test a new version with 10% of users") and ask you to choose the correct routing policy. Memorise the characteristics of weighted, latency-based, failover, geolocation, geoproximity, and multivalue answer. For example, latency-based routing is ideal for global applications where you care about speed, but it does not guarantee traffic stays in a specific region. Geolocation routing ensures a user in France is always sent to a French server, but it can cause issues if that server goes down (unless you combine it with failover).

Health checks and failover: You must understand how Route 53 health checks work with DNS failover. The exam will test that if a primary server fails, the DNS record automatically returns the secondary’s IP. But remember DNS caching: even after Route 53 changes the answer, some users may still get the old IP for a few minutes due to TTL. This is a common trap in disaster recovery questions.

CloudFront behaviours and origins: The exam tests how to configure multiple origins (S3, ALB, custom HTTP) with different cache behaviours based on URL path patterns. A typical question: "You want to serve static files from S3 and dynamic files from an ALB. What configuration achieves this?" The answer is to set two origins in one CloudFront distribution and map paths with cache behaviours.

Signed URLs vs. signed cookies: You need to know when to use each. Signed URLs are for individual files (like a single video or download). Signed cookies are for applying access restrictions to multiple files or an entire directory without changing every URL.

Origin Access Control (OAC): This is the modern, secure way to allow CloudFront to access an S3 bucket. Older references to Origin Access Identity (OAI) are legacy, but the exam may still test OAI. Understand that OAC is recommended.

AWS Shield and Web Application Firewall (WAF): The exam will test integration. CloudFront can be associated with AWS WAF to block malicious requests (like SQL injection) at the edge, and AWS Shield Advanced provides DDoS protection.

Content optimisation: CloudFront can automatically optimise content using Lambda@Edge (running code at edge locations to modify requests/responses) or using origin shields (an additional caching layer to reduce load on origins). The exam may test when to use Lambda@Edge for things like A/B testing or URL rewriting.

Restrictive access to content: Questions may ask how to ensure only CloudFront can access your ALB or EC2 instances. The answer involves using security group rules that allow inbound traffic only from CloudFront’s IP ranges (published by AWS), or using custom headers.

IPv6 and DNS64: The exam may test how Route 53 handles DNS64 for IPv6-to-IPv4 translation, relevant for services like AWS NAT64/DNS64 used in dual-stack VPCs.

Common traps include confusing routing policies (selecting geolocation when latency-based is appropriate), forgetting that CNAME records cannot be used at the zone apex, and assuming CloudFront caches all content indefinitely (it respects the Cache-Control and Expires headers from the origin). Also, many beginners think Route 53 health checks are instantaneous — they are not; they have a configurable interval (10 or 30 seconds) and a threshold (e.g., 3 consecutive failures before marking unhealthy).

Make sure you can explain why you would use CloudFront over just Route 53 latency-based routing. Route 53 only improves the initial connection; CloudFront actually caches content and serves it from nearby edge locations, reducing load on the origin and improving latency for every subsequent request. The exam expects you to recognise when the problem is about reducing load on the origin rather than just finding the fastest server.

Key Takeaways

Route 53 Alias records are the only way to point a root domain (zone apex) to an AWS resource like CloudFront or an Elastic Load Balancer.

CloudFront uses a pull-based caching model; content is only cached at an edge location after the first user request from that region.

Choose latency-based routing when you want the fastest response for each user, and geolocation routing when you must comply with regional content regulations.

Origin Access Control (OAC) allows CloudFront to securely access a private S3 bucket without making the bucket public.

Signed URLs protect individual files, while signed cookies protect multiple files or an entire directory without modifying each URL.

CloudFront health checks and Route 53 health checks are separate; Route 53 health checks determine DNS routing, while CloudFront health checks (if configured) determine whether to fetch from the origin.

CNAME records cannot be used at the zone apex; always use an Alias record for the root domain.

CloudFront can be integrated with AWS WAF to filter malicious traffic at the edge before it reaches your origin servers.

Easy to Mix Up

These come up on the exam all the time. Here's how to tell them apart.

Alias Record

Can be used at the zone apex (root domain).

Is Route 53-specific and free of charge.

Automatically updates if the target AWS resource’s IP changes.

CNAME Record

Cannot be used at the zone apex.

Is a standard DNS record type supported by all providers.

Requires manual updates if the target resource’s IP changes.

Latency-based Routing

Routes based on network latency to the user's location.

Does not guarantee which region the user ends up in.

Best for global apps where speed is the primary concern.

Geolocation Routing

Routes based on the user’s specific geographic location (country, continent).

Guarantees users from a region are sent to a specific endpoint.

Best for complying with data sovereignty laws, like serving EU users from EU servers.

Signed URL

Protects a single file (e.g., one video or PDF).

Requires generating a unique URL per user per file.

Ideal for individual premium downloads or time-limited access.

Signed Cookie

Protects multiple files or an entire path (e.g., /private/*).

Sets a cookie that authorises the user's browser for many requests.

Ideal for restricting access to a private area of a website.

Origin Access Control (OAC)

Modern, recommended method to restrict S3 bucket access.

Supports more AWS services and is more secure.

Works with S3 bucket policies automatically.

Origin Access Identity (OAI)

Legacy method, still supported but not recommended.

Only works with S3 bucket policies using a specific principal.

Limited to S3 origins only.

Watch Out for These

Mistake

Route 53 and DNS only translate domain names to IP addresses, and that is their only job.

Correct

Route 53 also performs health checks, traffic routing based on latency or geography, failover, and integrates with AWS resources like CloudFront and load balancers. DNS is the protocol, but Route 53 is a fully managed routing service.

Beginners see 'DNS' and think of a simple directory, but Route 53 adds routing policies that actively steer traffic, which is far more powerful.

Mistake

CloudFront stores a complete copy of all your website files on every edge location immediately after you set it up.

Correct

CloudFront uses a pull-based caching model. It only stores a file at an edge location after the first request for that file from that edge region. The initial request may be slow, but subsequent ones are fast.

The term 'distribution' sounds like content is distributed everywhere instantly, but CloudFront is not a wholesale copy service; it caches on demand.

Mistake

Setting a very long Time To Live (TTL) for CloudFront caching is always better because it reduces load on the origin.

Correct

A long TTL means users may see stale content for a long time. For dynamic content (like stock prices or new posts), you want a short TTL or no caching. TTL is a trade-off between freshness and performance.

Beginners optimise for speed alone and forget that content changes. A news site with 7-day TTL would show old headlines.

Mistake

You can use a CNAME record to point the root domain (example.com) to any AWS service.

Correct

CNAME records cannot be used at the zone apex. You must use an Alias record in Route 53 to point the root domain to AWS resources like CloudFront or Elastic Load Balancer.

DNS protocol prohibits CNAME at the apex, but beginners think 'it is just an alias' and do not know the technical limitation.

Mistake

Latency-based routing and geolocation routing are the same thing.

Correct

Latency-based routing sends traffic to the server with the lowest network latency for that user. Geolocation routing sends traffic based on the user's geographic location, regardless of actual latency. A user in Germany could have better latency to a US East server, but geolocation would still send them to a European server.

Both sound location-related, but their mechanisms and outcomes differ. The exam tests you to choose the right one for a given scenario.

Mistake

If you set up CloudFront with an S3 bucket origin, the bucket must be publicly accessible.

Correct

With Origin Access Control (OAC), you can keep the S3 bucket private. Only CloudFront can access it. Users never interact directly with the bucket.

Beginners assume that since content needs to be served, the bucket must be open, but OAC provides a secure, private origin.

Do You Actually Know This?

Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.

Frequently Asked Questions

What is the difference between Route 53 and CloudFront?

Route 53 is a DNS service that translates domain names to IP addresses and routes traffic based on policies. CloudFront is a content delivery network that caches content at edge locations worldwide for faster delivery. They work together: Route 53 points users to the nearest CloudFront edge location.

Can I use Route 53 without CloudFront?

Yes, you can use Route 53 to point users directly to your web server (e.g., an EC2 instance). You only need CloudFront if you want to cache content and reduce latency for a global audience.

What is a TTL in DNS and CloudFront?

In DNS, TTL (Time to Live) tells DNS resolvers how long to cache a record before asking again. In CloudFront, TTL tells the edge location how long to keep a cached file before checking the origin for a newer version. Short TTL means more frequent refreshes but less stale content.

How do I make my S3 bucket private but still serve content via CloudFront?

Use Origin Access Control (OAC) in CloudFront. Create an OAC, associate it with your distribution, and update the S3 bucket policy to only allow access from that OAC. Then only CloudFront can read the bucket objects.

What is the zone apex and why can it not use a CNAME?

The zone apex is the domain name without any subdomain, like 'example.com'. DNS protocol rules prohibit CNAME records at the root of a domain (the zone apex) because CNAME records must coexist with other record types (like SOA and NS), which is not allowed. Use an Alias record in Route 53 instead.

How do I route users to different servers based on their country?

Use Route 53 geolocation routing. Create separate records for different geographic locations (e.g., one for Europe, one for Asia) and assign each to a different server. Route 53 will automatically answer with the record that matches the user's location.

What is Lambda@Edge and when should I use it with CloudFront?

Lambda@Edge is a service that runs custom code at CloudFront edge locations in response to events (e.g., viewer request, origin request). Use it to modify content or headers, perform A/B testing, or authenticate users without modifying your backend.

Terms Worth Knowing

Keep going

You've finished DNS and Content Delivery with Route 53 and CloudFront. Continue through the ANS-C01 study guide to build a complete picture of the exam.

Done with this chapter?