E ExamMaster

AWS Cloud Architect & Developer · AWS Cloud Architecture

Route 53 and CloudFront CDN

DNS with Route 53 and global content delivery with the CloudFront CDN.

Seven concepts. Route 53 and CloudFront questions on SAA-C03 almost always turn on a routing-policy keyword or a DNS record-type choice under time pressure — not on arithmetic — so each concept here is built around the distinction the exam actually tests.

  • AWS Cloud Architect & Developer
  • Medium level
  • 7 concepts
  • 5 practice questions

1Alias records at the zone apex

Route 53 Alias records map a name directly to an AWS resource — a CloudFront distribution, an Application Load Balancer, an S3 static-website endpoint, or another Route 53 record — without introducing a second hostname in the answer. That matters at the zone apex: a CNAME cannot be used at the zone apex because the apex must also hold NS and SOA records, and DNS forbids a CNAME from coexisting with any other record type at the same name. An Alias is implemented as an A or AAAA record that Route 53 resolves to the target's current addresses on your behalf, and queries to AWS Alias targets are not billed separately.

On a subdomain such as www.example.com a CNAME to the CloudFront domain name still works, but the root domain example.com has no www prefix and is the case Alias was built for. The exam trap is reaching for CNAME whenever CloudFront appears — that is correct on a subdomain and wrong at the apex.

Figure. Two names in the same hosted zone: only the apex path needs Alias.

How it works

  1. Apex constraintThe zone apex must publish NS and SOA. A CNAME at the same name would collide with them, so RFC 1034 forbids it.
  2. Alias workaroundRoute 53 Alias is an A/AAAA answer that points at an AWS target. Route 53 resolves the target's current IPs for you.
  3. Exam pickRoot domain to CloudFront, ALB, or S3 website endpoint ⇒ Alias. Subdomain to any hostname ⇒ CNAME is fine.
Alias versus CNAME
RecordZone apexTarget typesQuery billing
AliasYesAWS resources and eligible same-zone Route 53 recordsFree for AWS Alias targets
CNAMENoAny hostnameStandard Route 53 query charge
You must serve example.com (no www) from a CloudFront distribution. Which Route 53 record is valid?
  1. CNAME pointing to the distribution domain name
  2. Alias A record pointing to the CloudFront distribution
  3. A record with a static CloudFront IP address

CNAME is forbidden at the zone apex. An Alias A record is the supported way to point the root domain at CloudFront. CloudFront IPs change, so a static A record is fragile and not how the service is meant to be wired.

2Latency-based routing

Latency-based routing sends each DNS query to the AWS Region that currently offers the lowest measured latency for that resolver's location. Route 53 maintains latency measurements between resolver locations and Regions; when a user asks for your domain, the answer is whichever healthy endpoint in the lowest-latency Region wins — not a fixed percentage split and not a rule keyed to the user's country.

The exam phrase is almost always "lowest latency per user" or "fastest Region for each user." That is latency-based routing. Geolocation routing (the next concept) keys off the query origin's geographic location for compliance or localized content — a different question with a different answer.

Figure. Two users, two Regions — each query picks the nearer healthy endpoint.

How it works

  1. MeasureRoute 53 tracks latency from resolver locations to each Region where you have a record.
  2. Pick the winnerEach query gets the answer from the Region with the lowest current latency among healthy targets.
  3. Keyword match"Fastest Region for each user" or "minimize latency globally" ⇒ latency-based, not geolocation or weighted.
Latency-based versus geolocation
PolicyDecision basisTypical goal
Latency-basedLowest measured latency to a RegionSpeed — send each user to the fastest healthy Region
GeolocationCountry or continent of the DNS query originCompliance, localized content, data residency
WeightedConfigured percentage weightsCanary releases, A/B traffic split
An application runs in us-east-1, eu-west-1, and ap-southeast-1. You want each user routed to whichever Region gives them the lowest latency. Which Route 53 routing policy?
  1. Geolocation routing
  2. Latency-based routing
  3. Weighted routing

The goal is minimum latency per user, which is exactly what latency-based routing measures. Geolocation routes by the user's location for compliance or localization, not by measured speed. Weighted splits by percentage regardless of where the user sits.

3Geolocation routing

Geolocation routing answers a DNS query based on the geographic location from which the query originates — country, continent, or a default catch-all — and sends the user to the endpoint you mapped for that location. Use it when regulations require data to stay in a jurisdiction, when you want country-specific landing pages, or when you must block traffic from certain regions.

The trap is confusing geolocation with latency-based routing. Latency-based picks the fastest healthy Region for each resolver; geolocation picks the endpoint you assigned to that location regardless of which Region is physically closer. A user in Canada might be sent to a US endpoint by geolocation rule even if a Canadian Region would have been faster.

Figure. Geolocation maps the querier's location to an answer — different from latency-based which picks lowest RTT.

How it works

  1. Map locationsCreate one record per geography — e.g. EU users to eu.example.com, US users to us.example.com, default for everyone else.
  2. Match query originRoute 53 inspects where the DNS query came from and returns the record for that geography.
  3. Keyword match"Route by user's country", "comply with data residency", or "localize content by region" ⇒ geolocation.
A company must serve EU customers only from infrastructure in the EU to meet data-residency rules. Which Route 53 routing policy?
  1. Latency-based routing
  2. Geolocation routing
  3. Failover routing

Data residency is a geographic rule — EU queries must get EU endpoints — which is geolocation routing. Latency-based would send an EU user to whichever Region is fastest, possibly outside the EU. Failover is for active-passive disaster recovery, not residency.

4Failover routing and health checks

Failover routing implements active-passive disaster recovery in DNS: a primary record receives all traffic while its health check passes, and Route 53 automatically switches answers to a secondary record when the primary is unhealthy. You attach a Route 53 health check to the primary endpoint — HTTP/HTTPS, TCP, or calculated from other checks — and define primary and secondary records with the Failover routing policy.

Pair failover with a low TTL — often 60 seconds — so clients pick up the change quickly after a failure. Without a health check, failover has nothing to trigger on and the secondary never takes over automatically.

Figure. Health check on the primary; secondary idle until the check fails.

How it works

  1. Primary recordCreate a Failover primary record pointing at the active Region or endpoint.
  2. Health checkAttach a Route 53 health check monitoring the primary — HTTP 200 on /health is the common pattern.
  3. Secondary recordCreate a Failover secondary record for the standby. When the check fails, all queries get the secondary answer.
  4. Low TTLSet TTL around 60 s on failover records so resolvers refresh quickly after a switch.
A site runs in us-east-1 (primary) with eu-west-1 as standby. Traffic must switch to the standby automatically when the primary fails. Which configuration?
  1. Latency-based records in both Regions with equal weights
  2. Failover routing with a health check on the primary
  3. Weighted routing at 90/10 between the two Regions

Automatic switchover on primary failure is Failover routing with a health check. Latency-based sends users to the fastest Region, not to a standby on failure. Weighted splits traffic by percentage and does not fail over.

5Weighted routing

Weighted routing splits DNS answers by percentage. Assign each record a weight — e.g. 90 for the stable version and 10 for the canary — and Route 53 distributes queries in proportion. Unlike latency-based or geolocation routing, the split is intentional and fixed by you, not derived from user location or measured speed.

Use weighted routing to canary-test a new deployment, run A/B experiments, or gradually shift traffic during a migration. Combine it with health checks so unhealthy weighted records stop receiving their share.

Figure. Weighted routing splits traffic by relative weights — canary and blue/green DNS shifts use this.

How it works

  1. Create recordsAdd multiple records with the same name, each pointing at a different target.
  2. Set weightsAssign relative weights — weights 90 and 10 give roughly 90% and 10% of queries.
  3. Keyword match"Split traffic by percentage", "canary a new version", or "send 10% to the beta stack" ⇒ weighted.
When weighted beats the other policies
Scenario keywordPolicy
Lowest latency per userLatency-based
Route by country or continentGeolocation
Active-passive DR with automatic switchoverFailover
Split by percentage or canary testWeighted
Single endpoint, no splittingSimple
You want 10% of production traffic to hit a new application version while 90% stays on the current one. Which Route 53 routing policy?
  1. Weighted routing
  2. Failover routing
  3. Geolocation routing

A fixed percentage split is weighted routing — set weights 90 and 10. Failover sends all traffic to one endpoint until it fails. Geolocation routes by the user's location, not by percentage.

6CloudFront edge caching

Amazon CloudFront is a global content delivery network. It caches copies of your content at edge locations close to viewers, so a user in Tokyo is served from a nearby edge rather than crossing the planet to your origin in us-east-1. That cuts latency for static assets — images, CSS, JavaScript, video — and reduces load on the origin server.

CloudFront accepts an origin such as an S3 bucket, an Application Load Balancer, or a custom HTTP server. Cache behaviour is controlled by TTL settings and Cache-Control headers from the origin; the default TTL is 24 hours. The exam trigger phrase is almost always "reduce latency for global users" or "cache static content at the edge" — reach for CloudFront, then wire Route 53 to the distribution with an Alias record.

Figure. First request fills the edge; later requests stay local.

How it works

  1. OriginPoint a CloudFront distribution at your S3 bucket, ALB, or custom origin.
  2. Edge cacheOn a cache miss at an edge, CloudFront fetches from the origin and caches the object at that edge (and often its regional cache) — not at every edge worldwide.
  3. Serve locallyLater requests from nearby users hit the edge cache, not the distant origin.
  4. DNSUse a Route 53 Alias record to point your domain at the distribution.
Static media in an S3 bucket in us-east-1 loads slowly for users in Europe and Asia. Which service reduces latency without moving the bucket?
  1. Amazon CloudFront with the S3 bucket as origin
  2. AWS Transit Gateway
  3. Latency-based Route 53 routing to the bucket

CloudFront caches content at edge locations near users, cutting download latency. Transit Gateway connects VPCs, not end users to S3. Latency-based routing picks among Regions but does not cache objects at the edge.

7Origin Access Control for private S3

Origin Access Control (OAC) lets a CloudFront distribution read objects from a private S3 bucket. Block all public access on the bucket, enable OAC on the distribution, and add a bucket policy granting the CloudFront service principal s3:GetObject only for that distribution. Users reach content through CloudFront URLs; direct S3 object URLs return Access Denied.

This is the standard exam pattern for "serve a static site globally with low latency while keeping the bucket private." The steps are S3 private → CloudFront distribution with OAC → bucket policy → Route 53 Alias at the apex.

Figure. Direct S3 access blocked; CloudFront path allowed.

How it works

  1. Block public accessEnable Block Public Access on the S3 bucket so objects are not world-readable.
  2. Enable OACCreate a CloudFront distribution with the bucket as origin and turn on Origin Access Control.
  3. Bucket policyGrant s3:GetObject to the CloudFront service principal for this distribution only.
  4. Alias recordPoint the domain at the distribution with a Route 53 Alias record at the zone apex.
A static site is served through CloudFront from a private S3 bucket with OAC. Can a user download an object via its direct S3 URL?
  1. Yes, if they know the object key
  2. No — only CloudFront with OAC can read the objects
  3. Yes, but only from the same AWS Region as the bucket

OAC and the bucket policy allow only the CloudFront distribution to read objects. Direct S3 URLs hit a private bucket and return Access Denied. Knowing the key does not bypass the policy.

Notes

  • Route 53 Routing Policies: Simple, Weighted (split traffic by percentage), Latency-based (route to lowest-latency Region), Failover (active-passive), Geolocation, and Multivalue answer.
  • Alias Records: Route 53 Alias records map a domain to AWS resources (ALB, CloudFront, S3 website) at the zone apex for free, unlike CNAMEs which cannot be used at the apex.
  • Health Checks: Route 53 health checks monitor endpoints and enable DNS failover to a healthy resource or a static S3/CloudFront backup site.
  • CloudFront Basics: A global CDN that caches content at edge locations close to users, reducing latency and offloading origins like S3 or ALB.
  • Origin Access Control: OAC restricts an S3 origin so content is served only through CloudFront, not via direct public S3 URLs.

Formulas

  • Route 53 TTL: lower TTL speeds failover propagation but increases query volume; typical failover records use 60 seconds.
  • Route 53 SLA: 100% availability service commitment for the DNS service.
  • CloudFront TTL: default 24 hours (86,400 s); controlled by Cache-Control/Expires headers with configurable min/max TTL.
  • CloudFront pricing: charged per data transfer out to the internet and per HTTPS/HTTP request, varying by edge Region.
  • Alias vs CNAME: Alias supports the zone apex (example.com) and is not billed per query; CNAME cannot be used at the apex.

Exam traps & shortcuts

  • To serve users from the geographically closest Region, use Latency-based routing; to comply with data-residency by country, use Geolocation routing.
  • For active-passive disaster recovery on DNS, combine Failover routing with a health check on the primary.
  • Use an Alias record (not CNAME) when pointing the root domain to an ALB, CloudFront, or S3 website endpoint.
  • To cut origin load and speed global reads of static assets, put CloudFront in front of S3 and lock the bucket with OAC.

Reference tables

Route 53 routing policy cheat sheet
PolicyExam keywordWhat it does
SimpleSingle endpointOne record, one target, no splitting
WeightedPercentage, canary, A/BDistributes queries by configured weights
Latency-basedLowest latency, fastest RegionPicks the healthy Region with lowest measured latency per resolver
FailoverActive-passive DR, health checkPrimary while healthy; secondary when check fails
GeolocationCountry, continent, data residencyRoutes by the geographic origin of the DNS query
MultivalueMultiple healthy IPsReturns up to eight healthy records; not a substitute for an ELB

Recap

Match the keyword to the policy; reach for CloudFront when caching near users is the goal.

Alias
Root domain to CloudFront, ALB, or S3 website ⇒ Alias A/AAAA. CNAME works on subdomains only; never at the zone apex.
Latency
Fastest Region per user ⇒ latency-based. Not geolocation — that keys off country for compliance, not speed.
Geolocation
Data residency or localize by country ⇒ geolocation. Ignores which Region is physically closer.
Failover
Active-passive DR ⇒ Failover routing plus a health check on the primary. Low TTL (~60 s) speeds propagation.
Weighted
Percentage split or canary ⇒ weighted routing with relative weights.
CloudFront
Global static assets, high latency from one Region ⇒ CloudFront edge cache. Default TTL 24 h.
OAC
Private S3 plus global CDN ⇒ CloudFront with OAC and a bucket policy. Direct S3 URLs are denied.

Practise Route 53 and CloudFront CDN

Reading is free and needs no account. Practice, mocks and progress live in the app.

  • 5 exam-style questions on this topic, with explanations
  • A 6-question practice set that ends the chapter
  • Timed mocks scored with the real marking scheme
  • Readiness tracked per topic, kept on your device
Continue with Google — freeNo card, no trial. Works offline once installed.