Edge and DNS
Bringing content and endpoints closer to global users and steering traffic by latency, location and health. Part of Domain 3: Design High-Performing Architectures, 24% of the scored content.
Route 53 records
Amazon Route 53
Route 53 hosts public and private DNS zones. The alias record is the AWS extension that the exam tests most.
Key points
- Common types: A (IPv4), AAAA (IPv6), CNAME, MX, NS, SOA, TXT, CAA, SRV, PTR. AWS recommends TXT instead of SPF records.
- CNAME: maps a name to another name, never at the zone apex (
example.com). - Alias: points to AWS resources (CloudFront, ELB, S3 website, API Gateway, Global Accelerator, VPC interface endpoint or another record in the zone), works at the apex and queries to AWS resources are free.
- Private hosted zone: DNS names resolvable only inside associated VPCs.
On the exam
"Point the root domain to a load balancer or CloudFront" -> alias record, never a CNAME. Alias also avoids query charges.
The routing policy decides which record answers each DNS query. Combined with health checks it gives DNS-level failover and traffic steering.
Key points
- Geolocation answers by the user location (continent, country, state). Add a default record or unmatched users get no answer.
- Geoproximity routes by distance to resources and shifts load with a bias from -99 to +99.
- Multivalue answer returns up to 8 healthy records at random. It is not a substitute for a load balancer.
- IP-based routes by the client CIDR (CIDR collections), useful for ISP-specific routing. Not available in private hosted zones.
On the exam
"Lowest latency for global users" -> latency, not geolocation. "Content rights or language by country" -> geolocation. "Send 10% to the new version" -> weighted.
Route 53 routing policies
| Policy | Use it for |
|---|---|
| Simple | A single resource, no health checks on the answer. |
| Weighted | Splitting traffic by percentage: canary, blue/green, A/B tests. |
| Latency | Sending users to the Region with the lowest latency for them. |
| Failover | Active-passive: primary while healthy, secondary otherwise. |
| Geolocation | Answering by the user location: compliance, localization. |
| Geoproximity | Routing by distance, with a bias to grow or shrink a region. |
| IP-based | Routing by the client IP range you know (CIDR collections). |
| Multivalue answer | Up to 8 healthy records returned at random. |
Route 53 health checks remove unhealthy endpoints from DNS answers, which drives failover between Regions.
Key points
- Endpoint check: health checkers around the world probe an IP or domain. The endpoint is healthy when more than 18% of them report it healthy.
- Calculated check: combines the results of other health checks.
- CloudWatch alarm check: follows an alarm. Required for resources with only private IPs, because the checkers run outside the VPC.
- Failover routing uses the check on the primary record to switch to the secondary (for example, a static S3 site).
On the exam
"Fail over to a backup Region automatically when the primary is unhealthy" -> failover routing + health check. "Health of a private resource" -> CloudWatch alarm based check.
Content delivery network with more than 750 points of presence and 15 Regional edge caches. It caches static and dynamic content close to users and protects the origin.
Key points
- Origins: S3 bucket, S3 website, ALB, NLB, EC2, API Gateway, Lambda function URL, MediaPackage or any HTTP server. VPC origins reach ALB, NLB and EC2 in private subnets.
- Cache behaviors: path patterns (
/images/*,/api/*) map to origins and cache policies. Defaults: min TTL 0, default TTL 86,400 s (24 hours), max TTL 31,536,000 s (1 year). - Origin Shield: an extra caching layer that reduces load on the origin.
- Origin failover: an origin group with primary and secondary origins, for GET, HEAD and OPTIONS requests.
- HTTPS: the ACM certificate for a custom domain must be in
us-east-1.
On the exam
"Global users, static content from S3, lower latency and lower origin load" -> CloudFront. A cache hit ratio problem points to cache policy and TTLs, not to a bigger origin.
CloudFront can keep the origin private, require signed access, block countries and encrypt sensitive fields at the edge.
Key points
- Origin access control (OAC): the S3 bucket accepts only requests signed by CloudFront. Supports SSE-KMS and PUT/DELETE. The legacy origin access identity (OAI) is not recommended.
- Signed URLs: one URL per file, or clients that do not support cookies. Signed cookies: many restricted files without changing URLs. Sign with trusted key groups.
- Geographic restrictions: allow list or block list of countries for the whole distribution.
- Field-level encryption: encrypts up to 10 POST fields at the edge with a public key, so only the backend with the private key reads them.
- AWS WAF and Shield Standard protect the distribution at the edge.
On the exam
"Users must not reach the S3 bucket directly" -> OAC. "Paid video library, many files per subscriber" -> signed cookies. "One download link" -> signed URL, not presigned S3 URLs when CloudFront is in front.
Code that runs in CloudFront to change requests and responses. CloudFront Functions are light and cheap, Lambda@Edge is more capable.
Key points
- CloudFront Functions: JavaScript, viewer request and viewer response only, sub-millisecond, 10 KB max size, no network access, millions of requests per second.
- Lambda@Edge: Node.js or Python, viewer and origin events, network access, up to 30 s, created in
us-east-1. - Typical CloudFront Functions jobs: header manipulation, URL rewrites and redirects, cache key normalization, simple token checks.
- Typical Lambda@Edge jobs: calls to external services, larger bodies, origin selection, logic that needs more memory or time.
On the exam
"Rewrite URLs or add headers at massive scale, lowest cost" -> CloudFront Functions. "Call a third-party API or change the origin request" -> Lambda@Edge.
CloudFront Functions or Lambda@Edge
| Aspect | CloudFront Functions and Lambda@Edge |
|---|---|
| Events |
|
| Runtime |
|
| Duration |
|
| Network access |
|
| Memory |
|
Global Accelerator
AWS Global Accelerator
Static anycast IP addresses that send users onto the AWS global network at the nearest edge and on to healthy Regional endpoints. No caching.
Key points
- Static IPs: 2 anycast IPv4 addresses (4 with dual stack) that never change while endpoints move behind them.
- Protocols: TCP and UDP, so it fits gaming, IoT (MQTT) and VoIP that CloudFront does not serve.
- Endpoints: ALB, NLB, EC2 instances and Elastic IPs in one or more Regions.
- Failover: detects an unhealthy endpoint and takes it out of service in less than 1 minute, with no DNS caching delay.
- Traffic dials per Region and weights per endpoint, plus client affinity.
On the exam
"Static IPs for allowlisting, UDP, fast Regional failover" -> Global Accelerator. "Cache content at the edge, HTTP" -> CloudFront. Both use the edge, only CloudFront caches.
S3 Transfer Acceleration
Amazon S3 Transfer Acceleration
Faster uploads and downloads to a bucket over long distances, entering the AWS network at a CloudFront edge location.
Key points
- Endpoint:
bucketname.s3-accelerate.amazonaws.com(or the dual-stack endpoint). - Bucket name: must be DNS-compliant without periods.
- Pricing: you pay only for accelerated transfers. If it would not be faster, there is no charge.
- Speed Comparison tool shows the gain for your location before you enable it.
On the exam
"Users on other continents upload large files to one bucket" -> S3 Transfer Acceleration, combined with multipart upload for large objects. Not CloudFront, which is mainly for delivery.