What's changed: Deepened SOA-C02 Chapter 5 to Associate depth (tables, scenarios, FAQ, traps; localized figures)
5.3Operating CloudFront and Load Balancing
Understand CloudFront edge caching (TTL, invalidation), ELB types (ALB/NLB) and health checks, and choosing between them in operations.
Delivering content fast and cheap and stably distributing traffic is where ops shines. Use CloudFront (CDN) and ELB (load balancing).
5.3.1CloudFront and ELB
- CloudFront: caches at the edge to cut latency and origin load; control freshness with TTL and force updates with invalidation.
- Choose between ALB (L7; HTTP path/host routing) and NLB (L4; ultra-low latency/high throughput).
- Health checks remove unhealthy targets, distributing only to healthy ones.
Common on SOA: stale content served = check TTL or invalidation, HTTP path-based routing = ALB, ultra-low latency/static IP/TCP = NLB, fast static delivery = CloudFront + S3.
CloudFront is a CDN that caches at the edge to cut latency and origin load. Freshness is set by TTL (controlled via a cache policy); when stale content appears after a deploy, force it fresh with an invalidation or version file names for a clean cutover (invalidations are charged beyond the free tier—versioning is preferred). With an S3 origin, OAC (Origin Access Control) keeps the bucket private and allows access only via CloudFront. Use CloudFront Functions for lightweight edge logic and Lambda@Edge for heavier processing. For load balancing, choose the L7 ALB for HTTP path/host-based routing, WebSocket, or auth; choose the L4 NLB for ultra-low latency, static IP, TCP/UDP (or to offer via PrivateLink). Both use health checks to drop unhealthy targets and distribute per target group. ALB conveys the client IP via X-Forwarded-For and can keep sessions with sticky sessions (cookies). A common pattern is CloudFront + S3 for static and an ALB origin for dynamic content.
| Requirement | Use |
|---|---|
| Fast static delivery | CloudFront + S3 (OAC) |
| Stale content after deploy | Invalidation / versioned filenames |
| HTTP path/host routing | ALB (L7) |
| Ultra-low latency, static IP, TCP/UDP | NLB (L4) |
Scenario: serve a static site fast, but updates don’t show immediately. Serve via CloudFront + S3 (private bucket with OAC). Stale content after deploy is the TTL at work—hash file names for a clean cutover and use an invalidation only in emergencies. Make a dynamic API an ALB origin and route /api/* by path.
Q. Stale content? Check TTL/invalidation (prefer filename versioning). Q. Route by HTTP path? ALB (L7). Q. Ultra-low latency/static IP/TCP? NLB (L4). Q. Serve S3 while private? OAC. Q. Lightweight edge logic? CloudFront Functions (heavy = Lambda@Edge).
Watch the mix-ups: (1) Stale content is mainly TTL—invalidation is a stopgap; the durable fix is filename versioning. (2) Don’t swap ALB = L7 (HTTP routing) / NLB = L4 (static IP, ultra-low latency). (3) Protect S3 origins with OAC (legacy OAI is deprecated). (4) ACM certs for CloudFront must be issued in us-east-1.
If stale content appears after a deploy, create a CloudFront invalidation or version your file names.
5.3.2Section summary
- CloudFront = edge cache (TTL/invalidation) / ALB (L7), NLB (L4)
- Fix stale content with invalidation
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. CloudFront still serves old content after a deploy. What is the best fix?
Q2. You want to route HTTP requests based on URL path. Which load balancer?
Q3. You need to distribute TCP traffic with ultra-low latency and a static IP. Which load balancer?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.