Route 53 DNS and CloudFront Content Delivery for SOA-C03

Route 53 organizes DNS records into hosted zones, and the first configuration decision is visibility. A public hosted zone answers queries from anywhere on the internet for a domain you control. A private hosted zone answers only from the VPCs you explicitly associate with it — you can associate more VPCs at any time, but each VPC must have DNS resolution and DNS hostnames enabled or queries fall through. You can run both zones for the same name (split-horizon DNS): inside an associated VPC the private zone wins, so db.example.com can resolve to a private IP internally while the public internet sees nothing.

The record types you will actually operate:

• A — name to IPv4 address; AAAA — name to IPv6 address.
• CNAME — name to another name. A CNAME cannot coexist with other record types at the same name, and DNS forbids it at the zone apex (the bare domain).
• TXT — arbitrary text: domain-ownership verification, SPF and DKIM email policy.
• MX — mail servers with priorities; the lowest number is tried first.

Operationally, remember that hosting a zone and registering a domain are separate functions: you can host a zone for a domain registered elsewhere by pointing that registrar at your zone's four Route 53 name servers. Record changes propagate quickly from Route 53's side; what limits how fast the world sees them is resolver caching — which is where TTLs and alias records, the next section, come in.

Alias records are a Route 53 extension to standard DNS that solve the CNAME problem. Where a CNAME can only point at another name and is illegal at the zone apex, an alias record points directly at an AWS resource — a CloudFront distribution, an Application or Network Load Balancer, an API Gateway API, a Global Accelerator, or another record in the same hosted zone — and it works at the apex. “Point example.com (no www) at an ALB” is an alias-record answer every time. Alias queries to AWS resources are also free, unlike standard queries, so swapping a busy CNAME that targets a load balancer for an alias cuts query charges. Route 53 manages the alias's TTL itself and tracks the target: when the load balancer's or the distribution's addresses change, the alias follows automatically, which is why a hard-coded A record listing today's IPs is never the right fix. An alias can also evaluate its target's health (Evaluate Target Health, covered with health checks below).

For everything else, TTL is your main operational lever. A record's TTL tells every caching resolver in the world how long it may keep the answer — which means the TTL that hurts you during a change is the one that was set before the change. Lowering the TTL at the moment of the cutover, converting to an alias at that moment, or submitting the change as a change batch all leave resolvers holding the old answer for the old TTL. The standard migration play: well ahead of a planned cutover, and at least one full old-TTL period in advance, lower the record's TTL from, say, 86400 seconds to 60. Wait for the old value to age out of caches, make the change, confirm the new target is healthy (a rollback is now just as fast), then raise the TTL back so resolvers stop hammering your zone. Low TTLs buy fast changes at the cost of more queries; high TTLs buy a cheap, resilient steady state at the cost of slow changes.

Every VPC has a built-in DNS server: the Route 53 Resolver, reachable at the VPC CIDR base plus two — in 10.0.0.0/16, that is 10.0.0.2 (the link-local address 169.254.169.253 also works). It resolves private hosted zone names, VPC-internal names, and public internet names for every instance in the VPC, and it is reachable only from inside the VPC. That last property is exactly what hybrid DNS has to work around, in two directions.

Inbound Resolver endpoint — on premises resolves AWS names. An inbound endpoint places ENIs with fixed private IPs into your subnets. You configure your on-premises DNS servers to conditionally forward AWS zones — say internal.example.com — to those IPs; the queries arrive over your Site-to-Site VPN and hand off to the Resolver. Result: data-center servers resolve private hosted zone records.

Outbound Resolver endpoint — VPCs resolve on-premises names. An outbound endpoint gives the Resolver a path out. You create forwarding rules — “for corp.example.com, forward to 10.10.0.53” — and associate each rule with the VPCs that need it. Instances keep querying their normal .2 address; matching queries are forwarded through the endpoint to your on-premises DNS servers.

Full hybrid DNS uses both endpoints at once, one per direction. On the exam, direction is everything: “on-premises servers must resolve VPC or private-zone names” is an inbound endpoint; “EC2 instances must resolve data-center domains” is an outbound endpoint plus forwarding rules. Neither replaces network connectivity — endpoints carry DNS queries over the private links you already have. And on-premises DNS cannot simply forward to a VPC's .2 address over the VPN: that address serves only queries from inside the VPC, which is the whole reason the inbound endpoint exists.

Why not just a DHCP options set? Pointing a VPC's DHCP options set at on-premises DNS servers does make instances query the data center directly — but it bypasses the Route 53 Resolver, so instances lose private hosted zone and AWS-internal name resolution unless the on-premises servers forward those names back. Keeping instances on the .2 Resolver and adding a forwarding rule forwards only the matching domain and leaves everything else working.

A private hosted zone or a Resolver forwarding rule built once can serve many VPCs and accounts, but each resource crosses account boundaries in its own way, and the exam tests which mechanism belongs to which.

Two traps follow from the table. Endpoints are not what you share — rules (or Profiles) are. And authorize-then-associate is the private hosted zone flow only; Resolver rules never use it. Whichever mechanism you choose, the records stay maintained in one place, which is usually the requirement that rules out copying a zone into each account.

Routing policies decide how Route 53 answers when multiple records share a name, and the exam tests them as scenario-to-policy matching.

Distinguish the geo pair: geolocation is about where the user is — an exact-match lookup, so Germany gets the Frankfurt answer, full stop — while geoproximity is about how far the user is from your resources, with a bias value that grows or shrinks each resource's catchment area. Geolocation answers only the locations you list, so a location with no matching record gets no answer unless you add a Default record. Latency routing is a third, separate idea: it measures network latency from the user's resolver to each Region, so it cannot honor a border-exact compliance rule.

Simple, weighted and multivalue are easy to confuse. Simple routing returns every value in its one record but cannot use health checks, so a failed server stays in the answer. Weighted routing can skip unhealthy records, but each response comes from a single weighted record, so a client never gets a set of independently health-checked addresses to fall back on. Multivalue answer returns up to eight healthy records per response, each with its own health check, letting a client fail over to another address without querying again. It is still not a load balancer — the client chooses.

The canary walkthrough — migrating an API from an old load balancer to a new one:

1. Days ahead, lower the record TTL to 60 seconds and let the old TTL age out of caches.
2. Create two weighted alias records for the same name: old target weight 90, new target weight 10.
3. Watch the new target's error rates and latency while it takes a tenth of production traffic.
4. Shift weights in stages — 50/50, then 0/100. A bad stage rolls back by setting the new record's weight to 0.
5. Once stable, delete the old record and raise the TTL back up.

A routing policy only steers around failures if Route 53 knows what is healthy, and there are two ways to tell it. Health checks themselves are configured as Route 53 resources; Domain 2 covers their resilience role, and here the question is which one a record can use.

Records accept health checks, not alarms directly: for a private service behind failover records in a private hosted zone, the pattern is metric → CloudWatch alarm → health check that monitors the alarm → attached to the primary record. For multi-Region latency or failover records that alias load balancers, turning on Evaluate Target Health (or attaching a health check) lets Route 53 skip that Region's record when its load balancer has no healthy targets and answer with the next-best record instead.

Route 53 offers two query logs, and exam questions hinge on knowing which log records which queries — and which tools record none.

Public query logging answers “who is querying my public domain” — verifying a record is being queried after a cutover or spotting query floods. If the log group is in another Region, or the resource policy is missing, the configuration cannot be saved. Resolver query logging answers “what are my instances looking up” — which instance queried a suspicious domain, why an application resolves the wrong name, or what Route 53 Resolver DNS Firewall just blocked.

Two neighbors are not substitutes. VPC Flow Logs record IP traffic metadata with no domain names, and they do not capture traffic to the Amazon-provided DNS server at all. AWS CloudTrail records Route 53 API calls — management events such as record changes and hosted zone updates — not the DNS queries instances send to the Resolver.

A CloudFront distribution is configuration, not infrastructure you place: you define origins (where content lives) and cache behaviors (how requests are handled), and CloudFront serves users from its global edge locations.

S3 origins and Origin Access Control. The operational standard for S3 is a private bucket, Block Public Access left on, fronted by Origin Access Control (OAC). CloudFront signs its requests to S3 as the cloudfront.amazonaws.com service principal, and the bucket policy allows s3:GetObject to that principal only when AWS:SourceArn equals your distribution's ARN — so only this distribution can read, and direct bucket URLs fail. Signed URLs do not replace this: they control which viewers may use the distribution, not whether CloudFront may read the bucket. Referer-header bucket policies need public access and are trivially spoofed.

OAC works only with the bucket's REST endpoint. An S3 website endpoint is treated as a custom origin that serves public content; CloudFront cannot sign requests to it, so the bucket would have to be public.

SSE-KMS objects. If objects are encrypted with a customer managed KMS key, the bucket policy is not enough: the KMS key policy must also allow the CloudFront service principal kms:Decrypt, conditioned on the distribution's ARN. A bucket policy statement granting kms:Decrypt does nothing, because bucket policies govern S3 actions only. The telltale symptom is 403s on objects written after the encryption change while older SSE-S3 objects still load. OAC is also the successor to the legacy origin access identity (OAI), which does not support SSE-KMS; new configurations should use OAC.

Custom origins. These cover everything that speaks HTTP: an Application Load Balancer, an API Gateway API, or any web server with a resolvable DNS name. With CloudFront VPC origins (since November 2024), a distribution can also reach an internal ALB, NLB or EC2 instance in a private subnet without exposing it to the internet.

A distribution routes requests to origins by cache behavior: each behavior has a path pattern, a target origin, and its own policies. /api/* can go to the ALB origin with caching disabled, /static/* to the S3 origin with long TTLs, and the default * behavior catches whatever matches nothing else — changing the default's origin moves every unmatched request.

Precedence. Behaviors are evaluated in precedence order and the first matching pattern wins, so list specific patterns before general ones: /images/thumbs/* must sit above /images/* or thumbnail requests never reach it. In path patterns, * matches any characters including slashes, so /images/*.jpg still matches /images/thumbs/cat.jpg — rewriting a pattern is not a substitute for ordering.

Cache policy versus origin request policy. Each behavior also sets its viewer protocol policy (for example, redirect HTTP to HTTPS) and allowed methods, plus the two policies that trip people up:

CloudFront forwards to the origin only what is in the cache key or in the origin request policy. That matters for dynamic, per-user pages: CachingDisabled on its own stops caching but forwards no cookies or query strings, because nothing is in its key; pairing it with AllViewer sends everything the application needs and caches nothing. Keying on every value with tiny TTLs is the wrong fix — it still caches briefly and fragments the cache. In general, forward what the origin needs through the origin request policy, and key only on what truly changes the response.

Caching lifetime is a negotiation between your origin's headers and each behavior's three TTL settings. If the origin sends Cache-Control: max-age (or Expires), CloudFront honors it — clamped between the behavior's minimum TTL and maximum TTL, so a max-age=30 against a 300-second minimum is cached for 300 seconds. If the origin sends no caching headers, the default TTL applies. An origin emitting Cache-Control: no-cache against a minimum TTL of 0 is effectively uncached, and a forgotten long default TTL is why a quick fix is not showing up for users.

Edge versus browser lifetimes. s-maxage applies to shared caches: when it is present, CloudFront uses it instead of max-age (still within the TTL bounds), while browsers ignore it and use max-age. So Cache-Control: max-age=60, s-maxage=3600 keeps a page at the edge for an hour and in browsers for a minute. stale-while-revalidate is different: the object still goes stale after its max-age, and CloudFront may keep serving the stale copy for the window while it fetches a fresh one from the origin in the background — it does not extend how long the edge treats the copy as fresh.

Removing stale content. Changing a behavior's TTL settings does not remove copies already in edge caches. When a file at a fixed URL must change now, an invalidation removes it from the edge ahead of expiry. Invalidations are billed per path beyond a monthly free allowance — the first 1,000 paths each month are free — and a wildcard such as /assets/* counts as a single path. An invalidation also takes time to complete across edge locations, so during a wide invalidation pages can load a mix of old and new assets, and rolling back needs another invalidation. The better pattern for deployable assets is versioned object names — app.a1b2c3.css instead of app.css: each deploy's HTML references new cache keys, pages always get the exact bundle they were built with, nothing needs invalidating, old versions age out, and rollback means serving the previous HTML. Reserve invalidations for content whose URL cannot change.

Origin Shield is a separate lever: an additional, centralized caching layer between the edge caches and your origin that raises the hit ratio and reduces origin load. It does not refresh or remove objects already cached at the edge.

An origin group gives a cache behavior a primary and a secondary origin. CloudFront sends each request to the primary; if the primary returns a status code listed in the group's failover criteria (chosen from 400, 403, 404, 416, 500, 502, 503 and 504), or the connection fails or times out, CloudFront retries that same request against the secondary straight away. The connection attempts and timeout settings on an origin decide how quickly a non-responding primary counts as failed — raising them only makes CloudFront wait or retry longer against the same origin.

Origin failover applies only to GET, HEAD and OPTIONS requests. A POST or PUT — submitting a form, placing an order — goes to the primary origin even during an outage, and the primary's error goes back to the viewer. Failover depends on the method and the criteria, not on whether the response is cacheable.

Serving https://shop.example.com through CloudFront without certificate warnings takes three pieces, and the exam likes to drop one:

1. Certificate in us-east-1. Request or import a public ACM certificate covering the name in us-east-1 — CloudFront reads distribution certificates only from that Region, no matter where your origin, users, or you work. A certificate issued in the origin's Region simply does not appear as an option, and a certificate on the ALB's listener secures only the CloudFront-to-origin hop.
2. Alternate domain name. Add shop.example.com to the distribution's alternate domain names (CNAMEs) and attach that certificate.
3. DNS to the distribution. Create a Route 53 alias record for the name that targets the distribution's domain name (an alias is required at the apex, and preferred everywhere). Pointing DNS at the ALB instead bypasses the distribution.

Signed URLs or signed cookies are a separate control: they restrict delivery of private content to authorized viewers, and have nothing to do with the domain's certificate.

CloudFront and AWS Global Accelerator both put your application behind AWS's global edge network, and the exam loves making you choose. They solve different problems: CloudFront is a content delivery network that caches HTTP responses at the edge; Global Accelerator is a network-layer front door that gives you two static anycast IP addresses and proxies TCP and UDP connections over the AWS backbone to the closest healthy regional endpoint — an ALB, NLB, EC2 instance, or Elastic IP. It caches nothing.

The static-IP point deserves emphasis: because Global Accelerator's two anycast IPs never change, enterprise customers can allowlist them permanently — something a bare load balancer cannot offer. CloudFront now has opt-in Anycast Static IPs too, but that is a larger IP list for HTTP/HTTPS delivery only; Global Accelerator gives just two static IPv4 addresses (four on a dual-stack accelerator) for any TCP or UDP application and fails over between Regions. And because failover happens inside the accelerator rather than in DNS, there is no resolver cache to wait out. Read the scenario's nouns: “cache,” “content,” and “HTTP” point to CloudFront; “static IP,” “UDP,” and “instant regional failover” point to Global Accelerator. Some architectures legitimately use both — but never claim Global Accelerator accelerates cacheable content delivery; that is CloudFront's job.