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, and Route 53 manages the TTL itself, tracking the target: when the load balancer's underlying IPs change, the alias follows automatically. An alias can also evaluate its target's health, which feeds failover configurations.

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. 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, 3600 seconds to 60. Wait for the old value to age out of caches, make the change, confirm the new target is healthy, 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. Lowering TTL before a migration is the single most-tested DNS operations move.

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.

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. And multivalue answer is not a load balancer: it returns several IPs and lets the client choose, but it does health-check each record, which simple routing cannot.

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.

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

Public DNS query logging captures the queries that Route 53's authoritative name servers answer for a public hosted zone — who on the internet asked for your domain, for which record name and type, from which resolver location, and what response code they received. It delivers to CloudWatch Logs, and the log group must live in us-east-1. Turn it on when the question is about traffic to your zone: verifying a record is actually being queried after a cutover, spotting query floods, or confirming resolvers picked up a change.

Resolver query logging captures the opposite side: queries originating inside your VPCs — everything instances ask the .2 Resolver, whether the answer comes from a private zone, a forwarding rule, or the public internet. It logs to CloudWatch Logs, S3, or Amazon Data Firehose, and you enable it per VPC. Turn it on when the question is about your workloads' behavior: which instance queried a suspicious domain, why an application resolves the wrong name, or what Route 53 Resolver DNS Firewall just blocked — Resolver logs record the firewall's action, making the pair a natural audit combination.

The mapping to remember: “who is querying my public domain” is public query logging on the hosted zone; “what are my instances looking up” is Resolver query logging on the VPC. They are configured in different places, capture disjoint traffic, and one is never a substitute for the other.

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.

Origins. For S3, the operational standard is a private bucket fronted by Origin Access Control (OAC): CloudFront signs its requests to S3, and the bucket policy grants access only to your distribution — no public bucket, no direct-to-bucket bypass. OAC is the successor to the legacy origin access identity (OAI), and new configurations should use it. Custom origins cover everything that speaks HTTP: an Application Load Balancer, an API Gateway API, or any web server with a publicly resolvable DNS name.

Cache behaviors. A distribution routes by path pattern: /api/* can go to the ALB origin with caching effectively disabled, /static/* to the S3 origin with long TTLs, and the default behavior catches whatever matches nothing else. Patterns are evaluated in order and the first match wins, so order them most-specific first. Each behavior sets its viewer protocol policy (for example, redirect HTTP to HTTPS), its allowed methods, and the two policies that trip people up: the cache policy defines the cache key — which headers, cookies, and query strings make cached responses distinct — plus the TTL bounds, while the origin request policy defines what is forwarded to the origin without joining the key. Everything you add to the cache key fragments the cache and drops the hit ratio, so 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. If the origin sends nothing, the default TTL applies. The operational consequences: 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.

When stale content must go now, an invalidation removes objects from edge caches 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 /images/* counts as a single path. The better operational pattern avoids the problem entirely: versioned object names, app.a1b2c3.css instead of app.css, mean every deploy references new objects, old versions simply age out, and rollback is instant. Reserve invalidations for mistakes.

Two more controls to recognize: an origin group gives a behavior a primary and a secondary origin, failing over when the primary returns configured error codes — origin failover, at concept level — and signed URLs or signed cookies restrict delivery of private content to authorized viewers.

Finally, the certificate gotcha the exam loves: to serve a custom domain over HTTPS, the ACM certificate for a CloudFront distribution must exist in us-east-1, no matter where your origin or your users are. A certificate for an ALB origin, by contrast, lives in the ALB's own Region.

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 — impossible with CloudFront or a bare load balancer. 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.