Amazon CloudFront Origins, Distributions, and Cache Behaviors – SAP-C02 Study Guide

Purpose of This Lesson

Amazon CloudFront is AWS’s content delivery network (CDN). It improves the performance of static and dynamic content by serving requests from globally distributed edge locations rather than requiring every user to retrieve content directly from a centralized origin.

For SAP-C02 scenarios, the key design task is selecting suitable origins and configuring a distribution that balances performance, security, cache efficiency, routing flexibility, and operational simplicity.

Key Concepts

CloudFront distributions

A distribution is the CloudFront configuration that defines how content is delivered. It specifies details such as:

• One or more origins
• Cache behaviors and path patterns
• Cache and origin request policies
• Viewer protocol behavior
• TLS certificates and custom domains
• Optional request and response processing at the edge

Every distribution has a default CloudFront hostname in the form of distribution-id.cloudfront.net. A custom DNS name can also be associated with the distribution, such as cdn.example.com.

A CloudFront web distribution supports HTTP and HTTPS traffic, including static content, dynamic application responses, uploads through forms or APIs, and live media use cases.

Origins

An origin is the location from which CloudFront retrieves content when the requested object is not available in an edge cache or must be revalidated.

Common origins include:

• Amazon S3 bucket: Suitable for static assets, documents, images, video files, and static websites.
• Application Load Balancer: Suitable for applications running on EC2 or other targets behind an ALB.
• Amazon EC2 or another HTTP server: Used when the application is directly exposed through a reachable HTTP endpoint.
• Other custom HTTP origins: Useful when the content is hosted outside the standard AWS origin types.

An origin is generally associated with a particular regional location or endpoint, while the distribution itself uses CloudFront’s global edge network.

For private S3 content, prefer a CloudFront origin access control (OAC) configuration so users retrieve objects through CloudFront without needing public bucket access. A bucket policy can restrict access to the specific CloudFront distribution.

Edge locations and caching

CloudFront routes users to an appropriate edge location based on AWS’s global routing system. When an object is cached at that edge location, subsequent requests can be served without contacting the origin.

This reduces:

• Network distance between users and content
• Origin load
• Repeated transfers over the origin path
• Perceived latency for cacheable objects

If the object is not cached, CloudFront retrieves it from the origin and can cache the response according to the applicable cache policy and response headers.

CloudFront’s use of the AWS global backbone for origin retrieval can improve consistency and network performance, but it does not eliminate all latency. The initial cache miss still requires an origin request, and application processing time remains relevant for dynamic content.

Cache behaviors and path patterns

A distribution can contain multiple cache behaviors. Each behavior matches a path pattern and defines how requests are handled.

For example:

• /images/* routes to an S3 origin with a long cache lifetime.
• /api/* routes to an application origin with a short or disabled cache lifetime.
• /media/* routes to a separate storage origin.

A cache behavior can specify the following:

• Origin selection
• Allowed HTTP methods
• Viewer protocol policy
• Cache policy
• Origin request policy
• Compression behavior
• Query string, cookie, and header forwarding
• Response and request handling controls

The default cache behavior applies when no more specific path pattern matches. More specific behaviors should be designed carefully because overlapping patterns and precedence can produce unexpected routing.

Cache policy versus origin request policy

These policies solve different problems:

• Cache policy: Controls which request values are included in the cache key and how long responses remain cached. Including unnecessary query strings, cookies, or headers can reduce the cache hit ratio.
• Origin request policy: Controls which request values CloudFront forwards to the origin. A value may be forwarded to the origin without being included in the cache key, but doing so requires care because different responses could otherwise be incorrectly reused.

For dynamic applications, forward only the headers, cookies, and query strings the origin actually needs. Forwarding every request value often produces poor cache efficiency and increases origin traffic.

Viewer protocol and TLS

CloudFront can support both HTTP and HTTPS. A common security configuration is Redirect HTTP to HTTPS, which allows users who connect over HTTP to be redirected to a secure connection.

For stricter security, use HTTPS Only when HTTP access should not be accepted at all. A custom domain requires an ACM certificate configured for CloudFront; certificates used by CloudFront are provisioned in the us-east-1 Region.

HTTPS between the viewer and CloudFront does not automatically guarantee HTTPS between CloudFront and the origin. Configure the origin protocol policy separately when end-to-end encryption is required.

Legacy RTMP distributions

RTMP distributions were a legacy CloudFront feature and are no longer available. Current designs use web distributions and modern HTTP-based media delivery patterns.

Exam-Relevant Takeaways

• CloudFront is global, but its origins are normally regional or tied to a specific origin endpoint.
• An edge location is not an origin. It is a caching and request-serving location in CloudFront’s global network.
• CloudFront reduces latency primarily by serving cacheable content closer to users.
• A cache miss causes CloudFront to retrieve content from the origin; it does not mean the user bypasses CloudFront.
• A distribution can use multiple origins.
• Cache behaviors route requests to different origins using path patterns.
• Use separate behaviors for static assets and dynamic API or application paths.
• Use OAC and an S3 bucket policy for private S3 content delivered through CloudFront.
• Redirecting viewers to HTTPS addresses viewer-to-CloudFront protocol use; configure the origin protocol policy independently.
• Excessive forwarding of cookies, headers, and query strings lowers cache efficiency and can create security or correctness problems.
• The default behavior handles requests that do not match a more specific path behavior.

Architecture Decision Guide

Requirement	CloudFront design choice	Important consideration
Globally distributed static files	S3 origin with CloudFront	Use long cache lifetimes for versioned assets
Private S3 objects	S3 origin with OAC	Deny public bucket access and permit the distribution through a bucket policy
EC2-hosted web application	ALB or custom HTTP origin	CloudFront can reduce repeated origin requests but does not replace application scaling
Static and dynamic content in one distribution	Multiple cache behaviors	Route paths such as /static/* and /api/* independently
Enforce encrypted viewer access	Viewer protocol policy set to redirect or require HTTPS	Decide whether plain HTTP should be redirected or rejected
Application requires user-specific cookies	Forward only required cookies and use a suitable cache policy	Avoid caching personalized responses for shared users
Content changes frequently	Short TTLs, revalidation, or invalidation	Versioned object names are often more scalable than frequent invalidations
Custom public hostname	Route DNS to CloudFront and attach an ACM certificate	CloudFront certificates must be in us-east-1
Reduce origin load	Cache objects effectively at edge locations	Cache behavior must not vary unnecessarily on request attributes

Common Exam Traps

• Confusing CloudFront with a regional cache: CloudFront distributions use a global edge network, while the origin is generally regional or tied to a specific endpoint.
• Assuming every request is served from cache: Cache misses, expiration, revalidation, and uncached responses still contact the origin.
• Making an S3 bucket public unnecessarily: CloudFront can access private S3 content using OAC; public bucket access is usually not the preferred security design.
• Using one cache policy for every path: APIs, personalized pages, and static assets usually have different caching requirements.
• Forwarding all cookies and query strings by default: This can fragment the cache and substantially reduce the cache hit ratio.
• Assuming viewer HTTPS encrypts the origin connection: Viewer protocol and origin protocol policies are separate settings.
• Routing all traffic to an S3 origin: Dynamic application paths generally need an application or custom HTTP origin.
• Ignoring behavior precedence: A request is handled by the most specific matching cache behavior; the default behavior is the fallback.
• Choosing very long TTLs for mutable objects: Long-lived cached objects can serve stale content unless filenames are versioned or invalidation is performed.

Real-World Engineer Notes

• Use immutable, versioned filenames such as app.8f31.js for static assets. This supports long TTLs while allowing new releases to use new object names.
• Keep user-specific or authorization-sensitive responses out of shared caches unless the cache key and forwarding rules are deliberately designed.
• CloudFront improves delivery latency, but origin performance still matters for cache misses and dynamic requests.
• Separate static and dynamic paths early. This makes cache policy, origin selection, protocol settings, and operational troubleshooting clearer.
• Treat cache invalidation as an operational tool, not the default deployment strategy for every update. Versioned assets generally reduce dependence on invalidations.
• When using an ALB as an origin, keep the origin endpoint stable and use the ALB for health checks, target distribution, and application scaling.
• Test behavior matching with representative paths, query strings, cookies, and headers. Small policy differences can produce large changes in cache hit ratio or application correctness.

Quick Reference Summary

• Distribution: Global CloudFront configuration.
• Origin: Source of content, such as S3, ALB, EC2, or another HTTP server.
• Edge location: Global location that serves cached content close to users.
• Cache behavior: Path-based rule that selects an origin and request-handling policies.
• Cache policy: Determines cache key components and TTL behavior.
• Origin request policy: Determines what CloudFront forwards to the origin.
• Viewer protocol policy: Controls HTTP/HTTPS behavior between users and CloudFront.
• OAC: Recommended mechanism for allowing CloudFront to access private S3 content.
• Default behavior: Fallback rule for requests that match no more specific behavior.

Flashcards

1. Q: What is the primary purpose of CloudFront?

A: To deliver content from globally distributed edge locations, reducing latency and origin load.

1. Q: What is a CloudFront origin?

A: The source endpoint from which CloudFront retrieves content, such as S3, an ALB, EC2, or another HTTP server.

1. Q: What happens on a CloudFront cache miss?

A: CloudFront retrieves the object from the configured origin and may cache the response according to policy.

1. Q: Can one distribution have multiple origins?

A: Yes. Cache behaviors can route different path patterns to different origins.

1. Q: What does a cache behavior control?

A: It can control path-based routing, origin selection, allowed methods, protocol policy, caching, and request forwarding.

1. Q: How does a cache policy differ from an origin request policy?

A: The cache policy controls the cache key and TTL-related behavior; the origin request policy controls what is sent to the origin.

1. Q: Why can forwarding all query strings and cookies be harmful?

A: It fragments the cache, lowers cache hit ratio, and increases origin requests.

1. Q: What is the preferred way to protect an S3 origin used by CloudFront?

A: Use CloudFront OAC and an S3 bucket policy that grants access to the distribution.

1. Q: Does HTTPS from the viewer automatically encrypt CloudFront-to-origin traffic?

A: No. The origin protocol policy must also be configured for HTTPS when required.

1. Q: Which behavior handles unmatched requests?

A: The default cache behavior.

Practice Questions

Question 1

A company hosts product images in Amazon S3 and an API on EC2 instances behind an Application Load Balancer. Users worldwide access both through www.example.com. The company wants images cached for a long time while API requests are sent to the application and are not shared between users. Which design is most appropriate?

A. Create separate CloudFront distributions, both using the S3 origin
B. Create one CloudFront distribution with an S3 origin, an ALB origin, and path-based cache behaviors
C. Place the ALB behind an S3 bucket and use the S3 website endpoint for all paths
D. Configure one cache behavior that forwards all requests to the ALB

Correct answer: B

A single distribution can define multiple origins and route paths such as /images/* to S3 and /api/* to the ALB. The image behavior can use a long TTL, while the API behavior can disable caching or use a carefully designed cache policy that does not share personalized responses.

Question 2

An organization uses CloudFront to deliver private documents from an S3 bucket. Security requires that users cannot access the bucket directly from the internet. Which solution best satisfies the requirement?

A. Make the S3 bucket public and rely on an obscure object key
B. Use CloudFront OAC and an S3 bucket policy that permits access only from the CloudFront distribution
C. Store the documents on an EC2 instance with a public IP address
D. Use a long CloudFront TTL without changing S3 permissions

Correct answer: B

OAC allows CloudFront to retrieve private S3 objects while the bucket remains non-public. The bucket policy should restrict access to the intended CloudFront distribution.

Question 3

A CloudFront distribution forwards every cookie, header, and query string to the origin. The cache hit ratio is poor, and the origin is overloaded even though many users request the same public assets. What is the best corrective action?

A. Forward even more request headers to guarantee cache correctness
B. Remove CloudFront and have users access the origin directly
C. Forward only request values required by the origin and exclude unnecessary values from the cache key
D. Set all objects to expire immediately

Correct answer: C

Unnecessary request attributes create many cache-key variations. A cache policy and origin request policy should be designed to include only the values needed for response variation and origin processing.

Question 4

A security team requires encrypted connections from users to CloudFront and from CloudFront to an application origin. Which configuration is required?

A. Set only the viewer protocol policy to redirect HTTP to HTTPS
B. Set the viewer protocol policy to HTTPS and configure the origin protocol policy to HTTPS
C. Use HTTP between CloudFront and the origin because the edge location is trusted
D. Configure HTTPS only on the origin and leave viewer connections unchanged

Correct answer: B

Viewer protocol and origin protocol settings control separate connections. Both must be configured for HTTPS to provide encryption across the complete path.

Question 5

A deployment updates JavaScript files in an S3 origin, but some users continue receiving the previous versions from CloudFront. Which approach is generally best for future releases?

A. Use versioned or content-hashed filenames and assign long TTLs to immutable assets
B. Disable caching for every CloudFront behavior permanently
C. Make the S3 bucket public and bypass CloudFront
D. Forward all cookies to force CloudFront to refresh the objects

Correct answer: A

Versioned filenames create new cache keys for each release, allowing long-lived caching without serving an older object under the same name. Invalidations can still be used when necessary, but they should not replace a sound asset-versioning strategy.