Cargando...
Cargando...
Low-latency, high-throughput content delivery at the AWS edge — worldwide, secure, and deeply integrated
Amazon CloudFront is a globally distributed Content Delivery Network (CDN) that accelerates delivery of static, dynamic, and streaming content by caching it at 600+ Points of Presence (PoPs) across 100+ countries. It integrates natively with AWS origins (S3, ALB, API Gateway, Lambda Function URLs) and custom origins, while providing built-in DDoS protection via AWS Shield Standard at no extra cost. CloudFront is not merely a cache — it is a programmable, secure edge compute and delivery platform.
Reduce latency and origin load by serving content from the edge location nearest to the end user, while providing security, programmability, and deep AWS integration.
Use When
Avoid When
Global Edge Network (600+ PoPs, 100+ countries)
Includes both Edge Locations and Regional Edge Caches
Origin Shield (additional caching layer)
Optional, costs extra, reduces origin requests
HTTPS / TLS 1.3 support
Free with SNI; ACM certs must be in us-east-1
HTTP/2 and HTTP/3 (QUIC) support
HTTP/3 must be explicitly enabled per distribution
WebSocket support (passthrough)
Passes through WebSocket connections to origin; not a stateful WebSocket server
Signed URLs
Restrict access to individual files; ideal for single-file access control
Signed Cookies
Restrict access to multiple files; ideal for subscription/membership content
Origin Access Control (OAC)
Preferred over legacy OAI for S3 origins; supports SSE-KMS encrypted buckets
Origin Access Identity (OAI)
Legacy method for S3 private origin; OAC is recommended replacement
Field-Level Encryption
Encrypts specific POST fields at the edge using asymmetric keys; data stays encrypted through the stack
CloudFront Functions (Viewer events only)
JavaScript, <1ms, 10 KB max, free tier included
Lambda@Edge (all 4 event types)
Node.js/Python, must be in us-east-1, replicated globally
AWS WAF integration
WAF WebACL attached at CloudFront is globally applied at edge
AWS Shield Standard (DDoS)
Included at no cost; Shield Advanced is optional paid upgrade
Real-Time Logs (Kinesis)
Configurable sampling rate 1-100%
Standard Access Logs (S3)
Delivered with delay (up to several hours); not real-time
Cache Invalidation
First 1,000 paths/month free; charged after
Geo-Restriction (Country-level)
Allowlist OR blocklist, not both
Continuous Deployment (Staging Distribution)
Test config changes on a subset of traffic before full promotion
Origin Failover (Origin Groups)
Primary + secondary origin; failover on 4xx/5xx HTTP status codes
Compressed Content (Gzip / Brotli)
CloudFront can compress objects automatically if origin doesn't
IPv6 support
Must be enabled per distribution; update Route 53 AAAA records
Trusted Key Groups (for Signed URLs/Cookies)
Preferred over CloudFront Key Pairs (root account required legacy method)
Response Headers Policy
Add/modify security headers (CORS, HSTS, CSP, X-Frame-Options) without Lambda@Edge
Cache Policy and Origin Request Policy
Decouple cache key configuration from what is forwarded to origin
VPC Origins (Private ALB/NLB/EC2)
CloudFront can connect to origins inside a VPC without public internet exposure
Static Website / Asset Delivery with Private Origin
high freqUse CloudFront with Origin Access Control (OAC) to serve private S3 content without making the bucket public. Block all public S3 access and grant CloudFront OAC principal access via bucket policy. Supports SSE-KMS encrypted buckets (OAI does not). This is the standard pattern for SPAs, static websites, and media asset delivery.
Custom Domain with Latency-Based or Geo Routing
high freqUse Route 53 Alias records pointing to CloudFront distribution domain (*.cloudfront.net). Route 53 can also perform latency-based routing between multiple CloudFront distributions or between CloudFront and regional endpoints. For HTTPS with custom domain, ACM certificate must be provisioned in us-east-1.
Lambda@Edge for Dynamic Edge Processing
high freqDeploy Lambda functions (Node.js/Python) in us-east-1; CloudFront replicates them to edge locations. Use for: JWT/OAuth token validation at Viewer Request, URL rewriting at Origin Request, adding security headers at Viewer Response, A/B testing at Origin Request. Lambda@Edge runs at 4 event types: Viewer Request, Origin Request, Origin Response, Viewer Response.
API Acceleration and Edge Caching
high freqPlace CloudFront in front of API Gateway (Regional endpoint) to cache GET responses, add WAF protection globally, and leverage the AWS backbone for reduced latency. Note: API Gateway already has Edge-Optimized endpoints that use CloudFront internally — but using your own CloudFront distribution gives more control over caching, WAF rules, and custom domains.
Complementary Acceleration — Not Redundant
high freqCloudFront caches content at edge and is HTTP/HTTPS-only CDN. Global Accelerator routes TCP/UDP traffic over AWS backbone to regional endpoints without caching — it's for non-HTTP workloads (gaming, IoT, VoIP) or when you need static anycast IPs. They solve different problems: CloudFront = content caching + edge compute; Global Accelerator = network-layer acceleration for any protocol.
Global Edge-Based Web Application Firewall
high freqAttach a WAF WebACL to a CloudFront distribution to enforce rate limiting, IP reputation lists, SQL injection/XSS protection, and geo-blocking at the edge — before traffic reaches your origin. WAF rules on CloudFront apply globally across all edge locations simultaneously, unlike WAF on ALB which is regional.
Hybrid Content Delivery to On-Premises Origins
medium freqUse CloudFront with a custom origin pointing to an on-premises server reachable via Direct Connect or VPN. CloudFront caches responses at edge, reducing the number of requests traversing the Direct Connect link. Origin Shield can further reduce origin hits.
Serverless Image Processing at Edge
medium freqS3 stores original images; Lambda@Edge (Origin Request) dynamically resizes/transforms images based on query parameters or device type before returning to CloudFront cache. Subsequent requests for the same transformed image are served from cache. This avoids pre-generating all image variants.
ACM certificates for CloudFront MUST be created in us-east-1 (N. Virginia) regardless of where your origin or users are located. This is a hard requirement with no exceptions.
CloudFront vs. Global Accelerator: If the question mentions HTTP/HTTPS content caching, CDN, or edge compute — choose CloudFront. If the question mentions TCP/UDP, static anycast IPs, non-HTTP protocols, or 'network-layer acceleration' — choose Global Accelerator. They are NOT interchangeable.
Use Origin Access Control (OAC) — not Origin Access Identity (OAI) — for new S3 private origin configurations. OAC supports SSE-KMS encrypted S3 buckets; OAI does not. Exam questions about encrypted S3 origins should trigger OAC.
Lambda@Edge functions must be deployed in us-east-1. CloudFront automatically replicates them to edge locations. You cannot deploy Lambda@Edge in any other region. Standard Lambda (non-edge) runs in a specific region and is NOT replicated.
CloudFront Functions vs. Lambda@Edge decision rule: CloudFront Functions = ultra-fast (<1ms), Viewer events only (Viewer Request/Response), JavaScript only, 10 KB max, very low cost. Lambda@Edge = all 4 events (including Origin Request/Response), Node.js/Python, up to 50 MB, up to 30s timeout, higher cost. Choose CloudFront Functions for simple header manipulation, redirects, URL rewrites. Choose Lambda@Edge for auth, A/B testing, complex logic, or origin-side processing.
CloudFront ≠ Global Accelerator: CloudFront CACHES HTTP/HTTPS content at edge. Global Accelerator ROUTES any TCP/UDP traffic over AWS backbone without caching. Static IPs or non-HTTP → Global Accelerator. CDN/caching/edge compute → CloudFront.
All CloudFront 'us-east-1 only' requirements: ACM SSL certificates, Lambda@Edge function deployment, WAF WebACLs for CloudFront — all MUST be in us-east-1. This is tested constantly across all 6 certifications.
OAC (not OAI) is the current best practice for private S3 origins — OAC supports SSE-KMS encrypted buckets, OAI does not. Any question mentioning encrypted S3 + CloudFront should trigger OAC as the answer.
Signed URLs are for single-file access control (e.g., one video file). Signed Cookies are for multiple-file access control (e.g., all videos in a subscription). If a question describes a user needing access to a collection of content, Signed Cookies is the correct answer.
Cache Invalidation costs money after the first 1,000 paths/month. For frequent content updates, use versioned file names (e.g., app.v2.js) or versioned S3 prefixes instead of invalidation — this is a best practice and appears in cost-optimization questions.
WAF attached to CloudFront is globally enforced at ALL edge locations simultaneously. WAF on ALB is regional. If a question asks for 'global' protection against SQL injection or rate limiting, CloudFront + WAF is the answer.
Origin Groups enable automatic failover: define a primary and secondary origin; CloudFront fails over to secondary on HTTP 4xx/5xx responses from the primary. This is CloudFront's built-in high-availability pattern for origins.
For 'near-real-time' CloudFront access log analysis, the answer is Real-Time Logs delivered to Kinesis Data Streams. Standard CloudFront access logs go to S3 with delays of up to several hours — not suitable for real-time dashboards or alerting.
Field-Level Encryption encrypts specific sensitive POST fields (e.g., credit card numbers) at the CloudFront edge using a public key. The encrypted data travels through the entire stack and can only be decrypted by the application with the private key. This is different from HTTPS (which only encrypts in transit).
Origin Shield is an optional additional caching layer between edge locations and the origin. It reduces the number of requests that reach your origin by consolidating cache misses from all edge locations through a single regional cache. Enable it when your origin is expensive to hit (on-prem, third-party API, or SSE-KMS S3).
Common Mistake
CloudFront and AWS Global Accelerator both accelerate global content delivery, so they can be used interchangeably for any use case.
Correct
CloudFront is an HTTP/HTTPS CDN that CACHES content at edge locations — it reduces latency by serving cached responses. Global Accelerator is a network-layer (Layer 3/4) service that routes TCP/UDP traffic over the AWS backbone WITHOUT caching — it reduces latency by using a faster network path. CloudFront is for web content, APIs, and media. Global Accelerator is for gaming, IoT, VoIP, or any workload needing static anycast IPs or non-HTTP protocols.
This is the #1 CloudFront trap on all certification exams. The key differentiator: caching (CloudFront) vs. network path optimization (Global Accelerator). If you see 'static IP addresses' or 'UDP' or 'TCP gaming traffic' → Global Accelerator. If you see 'CDN', 'caching', 'HTTP/HTTPS', 'edge compute' → CloudFront.
Common Mistake
Multi-region S3 replication with Route 53 latency-based routing is equivalent to CloudFront for global content delivery.
Correct
Multi-region S3 replication copies data to multiple S3 buckets in different regions — users still make full round trips to the nearest S3 regional endpoint. CloudFront caches content at 600+ edge PoPs (much closer to users than S3 regional endpoints), uses persistent connections to origins, and serves cached content without hitting S3 at all on cache hits. CloudFront dramatically reduces latency and origin load in ways that S3 replication cannot replicate.
S3 replication is about data durability and regional availability — NOT about CDN-level latency optimization. CloudFront edge PoPs are geographically denser than S3 regions. Exam questions about 'reducing global latency for static content' always point to CloudFront, not S3 replication.
Common Mistake
An Application Load Balancer (ALB) distributes traffic globally, so it provides the same global distribution benefit as CloudFront.
Correct
ALB is a REGIONAL service — it distributes traffic across targets within a single AWS region. It has no global edge presence. CloudFront has 600+ global edge locations. For global distribution, you need CloudFront (CDN) or Global Accelerator (network acceleration) — not ALB.
ALB's 'load balancing' is often confused with 'global distribution.' Remember: ALB = regional load balancing across AZs. CloudFront = global edge caching across 100+ countries. Putting CloudFront in front of ALB is a common and correct architecture — they complement each other.
Common Mistake
You can use CloudFront with an S3 bucket configured for static website hosting without any special configuration to keep the bucket private.
Correct
S3 static website hosting endpoints are HTTP-only public URLs — you cannot use OAC or OAI with website hosting endpoints (only with S3 REST API endpoints). If you use the website hosting endpoint as a CloudFront origin, the bucket MUST be public. To keep the bucket private, use the S3 REST API endpoint (bucket.s3.region.amazonaws.com) as the origin and configure OAC.
This is a subtle but important distinction. The correct architecture for private S3 + CloudFront is: disable website hosting, use S3 REST endpoint, enable OAC, block all public access on S3. Using website hosting endpoint bypasses OAC entirely.
Common Mistake
Setting CloudFront's Minimum TTL to 0 means objects will never be cached and every request goes to the origin.
Correct
Minimum TTL = 0 means CloudFront will honor Cache-Control: no-cache or max-age=0 headers from the origin and not cache those objects. But if the origin returns Cache-Control: max-age=3600, CloudFront WILL cache it for 3600 seconds. Minimum TTL of 0 does NOT disable caching — it simply allows the origin to instruct CloudFront not to cache when appropriate.
TTL behavior is a common exam topic. The hierarchy is: CloudFront's Minimum TTL ≤ Origin's Cache-Control max-age ≤ CloudFront's Maximum TTL. CloudFront always respects this hierarchy. To truly bypass cache, you must either invalidate the object or use query string/header cache key differentiation.
Common Mistake
Lambda@Edge can be deployed in any AWS region, just like regular Lambda functions.
Correct
Lambda@Edge functions MUST be authored and deployed in us-east-1 (N. Virginia). AWS CloudFront then automatically replicates the function to all edge locations globally. You cannot deploy Lambda@Edge in ap-southeast-1 or eu-west-1 — it will always be us-east-1.
This trips up candidates who assume Lambda@Edge follows normal Lambda regional deployment. Remember: us-east-1 is the 'home' for all CloudFront-related AWS resources that require a specific region (ACM certs, Lambda@Edge, WAF WebACLs for CloudFront).
Common Mistake
AWS Local Zones can replace CloudFront for achieving low-latency content delivery to users in specific metropolitan areas.
Correct
AWS Local Zones extend AWS infrastructure to specific metro areas for latency-sensitive applications that need single-digit millisecond latency to run compute (EC2, ECS, RDS) close to users — they are NOT a CDN and do NOT cache content. CloudFront serves cached content from 600+ globally distributed PoPs. Local Zones are for running application compute close to users, not for content delivery or caching.
Local Zones vs. CloudFront is a newer exam trap. Local Zones = run your own compute/storage closer to users. CloudFront = cache and serve content from edge. They solve fundamentally different problems. A correct architecture might use BOTH: CloudFront for static content + Local Zone for low-latency compute.
CAVE for Lambda@Edge event types: C=Client(Viewer) Request → A=After cache check(Origin) Request → V=View from origin(Origin) Response → E=Edge(Viewer) Response. Traffic flows: User → [Viewer Request] → CloudFront Cache → [Origin Request] → Origin → [Origin Response] → CloudFront → [Viewer Response] → User
ACM + CloudFront = Always Choose us-east-1 (N. Virginia). 'ACE' = ACM, CloudFront, East-1. All three go together.
OAC vs OAI: OAC = 'Obviously A Champion' (new, better, supports KMS). OAI = 'Old And Inferior' (legacy, no KMS support).
CloudFront Functions = FAST and CHEAP (Viewer only, <1ms, 10KB). Lambda@Edge = POWERFUL and FLEXIBLE (all 4 events, up to 30s, 50MB). Think: Functions = Formula 1 car (fast but limited). Lambda@Edge = SUV (more capable, slower, more expensive).
Signed URL = Single file access (URL = 1 file). Signed Cookie = Collection access (Cookie = multiple files in a 'jar'). 'One URL, one file. One Cookie jar, many files.'
CertAI Tutor · SAA-C03, SAP-C02, DEA-C01, DOP-C02, CLF-C02, DVA-C02 · 2026-02-21
In the Same Category
Comparisons
Guides & Patterns