Amazon CloudFront: What It Is and When to Use It

Definition

Amazon CloudFront is AWS's global content delivery network (CDN). It accelerates the delivery of static and dynamic web content (HTML, CSS, JavaScript, images, video, API responses) by caching it at 600+ edge locations and Regional Edge Caches distributed around the world. Users are automatically served from the nearest edge, minimizing latency and taking load off your origin.

How It Works

A CloudFront deployment centers on a distribution:

1. You configure one or more origins — the canonical source of your content. Supported origins include Amazon S3 buckets, S3 static websites, Application/Network Load Balancers, MediaPackage, API Gateway, Lambda Function URLs, and any HTTP server on any cloud.
2. You define cache behaviors — path-based rules (e.g., /api/*, /static/*, /*) that map requests to origins and control caching, headers, query strings, cookies, and compression.
3. CloudFront assigns the distribution a domain name (e.g., d111111abcdef8.cloudfront.net), which you typically alias to a custom domain via Route 53.
4. When a viewer requests content, CloudFront routes the request to the nearest edge. If the edge has a valid cached copy, it returns it immediately (cache hit). Otherwise it fetches from the origin, caches at the Regional Edge Cache and the edge, and returns it (cache miss).

Edge-located compute — CloudFront Functions (for small, ultra-fast request/response manipulation) and Lambda@Edge (for heavier logic) — runs code at the edge before or after the origin fetch.

Key Features and Limits

• 600+ Edge Locations plus Regional Edge Caches as a second tier to reduce origin hits.
• Cache behaviors per distribution, with configurable TTLs (min/default/max) and support for Cache-Control / Expires response headers.
• Cache policies and origin request policies — reusable, managed cache-key and origin-request configurations.
• Response headers policies — add/overwrite CORS, HSTS, X-Frame-Options, and custom headers without editing origin code.
• Origin Access Control (OAC) — sign origin requests with SigV4 so your S3 bucket can allow only CloudFront. (OAC replaces the older Origin Access Identity (OAI).)
• Signed URLs and Signed Cookies — protect private content so only authorized viewers can access it.
• Field-level encryption — encrypt specific POST fields at the edge before they reach the origin.
• Geographic restrictions — allowlist or blocklist countries.
• CloudFront Functions: JavaScript, sub-millisecond startup, limited runtime (1 ms CPU budget), no network calls, priced per million invocations.
• Lambda@Edge: full Lambda runtime at the edge, up to 30 seconds for origin-triggered events, useful for A/B testing, auth, SSR redirect logic.
• AWS WAF and Shield integration — CloudFront is the front door where you apply Layer 7 filtering and DDoS protection.
• HTTP/3 (QUIC), HTTP/2, HTTPS, Brotli/Gzip compression supported by default.
• Real-time logs — standard access logs to S3, real-time logs to Kinesis Data Streams or Firehose.
• Multi-tenant distributions — CloudFront SaaS Manager for SaaS vendors serving thousands of customer domains.
• Cost: no per-distribution fee; billed by data transfer out + requests.

Common Use Cases

1. Static website and SPA acceleration — S3 origin behind CloudFront with OAC, plus /api/* routed to an API Gateway or Lambda Function URL origin.
2. Media delivery — HLS/DASH streaming via MediaPackage or MediaStore origins; signed URLs for paid content.
3. API acceleration — route API traffic through CloudFront for TLS termination, WAF, caching of GET responses, and edge routing.
4. Global software downloads — installers, game assets, AMI images distributed with Regional Edge Cache reducing origin egress.
5. Security shield — put WAF + CloudFront in front of origins (even non-AWS) to absorb DDoS and filter malicious requests.
6. Gradual rollouts with Lambda@Edge — split traffic at the edge based on cookies or headers.

Pricing Model

CloudFront bills you on multiple axes:

1. Data transfer out to viewers — per GB, with different rates per geographic pricing tier (North America / Europe / Asia / etc.). Larger commitments unlock lower prices via CloudFront Security Savings Bundle and tiered discounts.
2. HTTP/HTTPS requests — per 10,000 requests, also varying by pricing tier.
3. Invalidations — first 1,000 paths per month free; after that, per-path charge.
4. Field-level encryption, Origin Shield, real-time logs, Lambda@Edge, CloudFront Functions — each has its own unit price.
5. Origin fetch — free from AWS origins in the same partition (S3, ELB, etc.); paid from custom origins at standard internet data-transfer rates.

Importantly, the AWS Free Tier includes 1 TB of CloudFront data transfer out and 10 million requests per month forever — enough to serve substantial traffic at $0.

Pros and Cons

Pros

• Massive edge footprint (600+ locations) with low, consistent latency globally.
• Deep integration with AWS origins, WAF, Shield, Lambda, and Kinesis.
• OAC lets you lock down S3 origins to CloudFront-only access with IAM.
• CloudFront Functions give you edge compute with microsecond cold starts.
• Free 1 TB/month forever for small sites and MVPs.

Cons

• Cache-invalidation workflows are paid beyond 1,000 paths/month — most teams ship content with versioned filenames to avoid invalidations.
• Complex cache-key semantics (query strings, headers, cookies) need care; misconfigured cache policies create cache poisoning or cache misses that hammer origins.
• Lambda@Edge runs in limited Regions and has different quotas than regular Lambda.
• Custom SSL certificates for distributions must be in us-east-1 (for reasons of edge design).

Comparison with Alternatives

| | CloudFront | AWS Global Accelerator | S3 Transfer Acceleration | Fastly / Cloudflare | | --- | --- | --- | --- | --- | | Layer | Layer 7 (HTTP/HTTPS CDN) | Layer 4 (TCP/UDP anycast) | S3-specific upload/download | Layer 7 CDN | | Caches content | Yes | No | No (uses edge network for speed) | Yes | | Edge compute | CloudFront Functions, Lambda@Edge | No | No | Workers, VCL | | Static IP | No (DNS) | Yes (2 anycast IPs) | No | Usually no | | Best for | Web, media, API acceleration with caching | Non-HTTP protocols, static IPs, faster failover | Faster S3 uploads from distant clients | Multi-cloud / advanced edge logic |

Exam Relevance

• Solutions Architect Associate (SAA-C03) — CloudFront as an edge layer for S3 / ALB / API Gateway, OAC for private S3, signed URLs vs signed cookies, geographic restrictions, integration with WAF and Shield.
• Developer Associate (DVA-C02) — cache-key design, invalidations, CloudFront Functions and Lambda@Edge use cases, headers manipulation, CloudFront as an edge for API Gateway.
• SysOps Administrator (SOA-C02) — access logs to S3 / Kinesis, OCSP stapling, custom error pages, TLS certificates via ACM.

Classic exam trap: ACM certificates for CloudFront distributions must be requested in the us-east-1 Region, even if your origin is in another Region. Certificates for ALB / NLB, by contrast, must be in the same Region as the load balancer.

Frequently Asked Questions

Q: How do I keep an S3 bucket private but still serve it through CloudFront?

A: Use Origin Access Control (OAC), CloudFront's modern way of signing origin requests with SigV4. Block all public access on the S3 bucket, attach an OAC to the distribution, and grant the distribution's principal permission to read the bucket in the bucket policy. Viewers will reach content only via CloudFront — direct s3.amazonaws.com/... URLs return 403. OAC replaces the older Origin Access Identity (OAI); use OAC for new distributions.

Q: What is the difference between CloudFront Functions and Lambda@Edge?

A: CloudFront Functions are ultra-lightweight JavaScript running at the edge for viewer-request and viewer-response events, with a 1 ms CPU budget and no network calls — ideal for header rewrites, URL canonicalization, cache-key normalization, and simple A/B routing. Lambda@Edge runs full Node.js/Python Lambda code, supports network calls and longer execution, and fires on any of viewer-request, origin-request, origin-response, and viewer-response — useful for auth, SSR, and complex routing. Use CloudFront Functions when it fits; reach for Lambda@Edge when you need more.

Q: How do CloudFront invalidations work and when do I need them?

A: An invalidation marks cached objects for eviction so the next request goes back to the origin. You invalidate a path like /images/logo.png or wildcard patterns like /css/*. The first 1,000 paths per month are free; after that each path is charged. Most production sites avoid invalidations by using versioned filenames (e.g., logo.abcdef.png) or query strings — new filenames bypass the cache automatically, so you never have to invalidate.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official Amazon CloudFront documentation before making production decisions.