CloudFront Distributions and Origins

Amazon CloudFront is AWS's global Content Delivery Network (CDN) that caches and delivers content from edge locations distributed across 400+ cities in 90+ countries. When a user requests content, CloudFront serves it from the nearest edge location, dramatically reducing latency compared to fetching it from the origin server.

CloudFront is not just for static files—it also accelerates dynamic content, APIs, and video streaming. It integrates with other AWS services like S3, ALB, Lambda@Edge, WAF, and Shield, making it the standard distribution layer for modern AWS architectures.

A CloudFront distribution is the primary configuration unit. It defines: one or more origins (where content lives), cache behaviours (how different URL paths are cached), security settings, and pricing tiers. You access your content through the distribution's domain name (e.g., d1234abcdef.cloudfront.net) or a custom domain (e.g., cdn.example.com) using a CNAME or ALIAS record.

After creation, distributions take 10–15 minutes to deploy globally across all edge locations. Changes to an existing distribution also take several minutes to propagate. There are two distribution types historically, but today all distributions use the unified configuration interface.

Using an S3 bucket as a CloudFront origin is one of the most common patterns. CloudFront fetches objects from S3, caches them at edge locations, and serves subsequent requests from the cache without hitting S3 again. This reduces S3 request costs, improves latency for global users, and offloads bandwidth from S3.

To serve an S3-backed site, you do not need to make the bucket public. Instead, use Origin Access Control (OAC)—the modern replacement for Origin Access Identity (OAI). OAC grants only the CloudFront distribution permission to read from the bucket, keeping S3 private while CloudFront serves the content publicly.

CloudFront also supports custom origins: any HTTP or HTTPS server accessible from the internet, including EC2 instances, Application Load Balancers, API Gateway endpoints, and on-premises servers. Custom origins enable CloudFront to cache and accelerate dynamic applications and APIs, not just static files.

When using an ALB as a custom origin, configure the ALB to only accept connections from CloudFront IP ranges in its security group. This forces all external traffic through CloudFront, enabling WAF rules and TLS termination at the edge while keeping the ALB internal to AWS.

Origin Access Identity (OAI) was the original way to restrict S3 bucket access to CloudFront. It is a special CloudFront user identity granted in the S3 bucket policy. While OAI still works, it is considered legacy.

Origin Access Control (OAC) is the modern replacement. OAC supports all S3 bucket types (including S3 in AWS China Regions and SSE-KMS encrypted buckets), uses IAM service principals for more granular control, and automatically signs requests to S3 using SigV4. For new distributions, always use OAC instead of OAI.

The Viewer Protocol Policy controls how CloudFront handles connections between users (viewers) and the edge location:

• HTTP and HTTPS: allow both; not recommended for sensitive content
• Redirect HTTP to HTTPS: transparently redirect HTTP requests to HTTPS; the most common setting
• HTTPS Only: reject HTTP connections entirely; use for strict TLS enforcement

Separately, the Origin Protocol Policy controls how CloudFront communicates with your origin: HTTP only, HTTPS only, or match viewer. For S3 origins with OAC, CloudFront always uses HTTPS.

To serve content from cdn.example.com instead of the CloudFront domain, you configure a Alternate Domain Name (CNAME) in the distribution and attach an SSL/TLS certificate from AWS Certificate Manager (ACM). The ACM certificate must be in the us-east-1 Region (regardless of where your distribution serves traffic), because CloudFront is a global service managed from us-east-1.

Create the Route 53 record as an ALIAS record pointing to the CloudFront distribution domain name. CloudFront automatically serves your certificate to matching SNI requests.

CloudFront's Price Class controls which edge locations are used to serve your distribution. Higher price classes include more expensive edge locations (typically in regions with higher bandwidth costs):

• Price Class 100: North America and Europe only (lowest cost)
• Price Class 200: North America, Europe, Asia, Middle East, Africa
• Price Class All: all edge locations worldwide (best performance, highest cost)

Use Price Class 100 for internal tools or audiences limited to North America/Europe. Use Price Class All for truly global consumer-facing applications.

Origin groups enable CloudFront origin failover. You define a primary origin and a secondary origin in a group. If the primary origin returns a specific HTTP error code (e.g., 500, 502, 503, 504), CloudFront automatically retries the request against the secondary origin.

Origin failover is useful for disaster recovery: keep a primary S3 bucket in us-east-1 and a replicated backup in us-west-2 as the secondary origin. CloudFront transparently fails over during an S3 outage without requiring DNS changes. This pattern complements S3 Cross-Region Replication.

CloudFront can deliver access logs to an S3 bucket, recording details about every viewer request: timestamp, edge location, status code, bytes transferred, cache hit/miss, user agent, and more. Logs are delivered in batches every few minutes.

Use access logs to analyse traffic patterns, identify hotspot content, audit security-relevant fields (IP, referrer, user agent), and measure cache hit ratios. The x-edge-result-type field tells you whether the request was a Hit, Miss, or RefreshHit at the edge.

CloudFront has two tiers of caching infrastructure:

• Edge locations: hundreds of PoPs globally close to end users; serve cached content with minimal latency
• Regional Edge Caches (RECs): 13 larger, longer-lived caches between edge locations and origins; serve content that is not popular enough to stay in small edge location caches

When a request misses the edge location cache, CloudFront checks the REC before going all the way to the origin. RECs are transparent—you do not configure them directly—but they significantly improve cache hit ratios for long-tail content and reduce origin load.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: CloudFront distributions cache content at edge locations globally, OAC keeps S3 buckets private while allowing CloudFront access, and custom origins support ALBs, API Gateway, and any HTTP server. ACM certificates for CloudFront must be provisioned in us-east-1. Next up we explore cache behaviours and TTL settings.