Amazon CloudFront Caching, TTLs, and Behaviors – SAP-C02 Study Guide

Purpose of This Lesson

Amazon CloudFront is AWS’s content delivery network (CDN). It improves application performance by serving cached content from locations close to viewers instead of retrieving every object from the origin.

For the SAP-C02 exam, focus on how CloudFront handles cache hits and misses, how TTLs affect freshness and performance, and how cache behaviors route requests to different origins.

Key Concepts

CloudFront distribution and origins

A CloudFront distribution defines how content is delivered. A distribution can use one or more origins, such as:

• Amazon S3 buckets
• Amazon EC2 applications
• Application Load Balancers
• API Gateway endpoints
• Custom HTTP servers

CloudFront uses cache behaviors to decide how requests are handled. A behavior can specify the path pattern, origin, allowed HTTP methods, caching settings, forwarded values, and other policies.

Edge locations and regional edge caches

A viewer first connects to a nearby CloudFront edge location, which is a global point of presence. After the request enters the CloudFront network, traffic can travel across the AWS global network to the selected origin or an intermediate cache.

A regional edge cache sits between CloudFront edge locations and the origin. Regional edge caches generally have more storage capacity than individual edge locations and can reduce repeated origin requests when an object is not present at the viewer’s local edge location.

The basic request path is:

1. Viewer sends a request to a nearby edge location.
2. CloudFront checks the edge cache.
3. If the object is missing, CloudFront checks the regional edge cache when applicable.
4. If the object is still unavailable, CloudFront fetches it from the origin.
5. The response is cached and returned to the viewer.

Cache hits and cache misses

A cache hit occurs when CloudFront has a valid cached object that matches the request. The object is returned without contacting the origin.

A cache miss occurs when the object is not cached, has expired, or the request maps to a different cache key. CloudFront retrieves the object from the next cache tier or origin and then caches it according to the configured policies.

Caching improves:

• Viewer latency
• Origin scalability
• Throughput for frequently requested objects
• Resilience against repeated origin requests

TTL and object freshness

The time-to-live (TTL) controls how long an object can remain fresh in a CloudFront cache before CloudFront checks the origin again.

CloudFront behavior settings can include:

• Minimum TTL: The lowest caching duration CloudFront permits.
• Default TTL: Used when the origin does not provide caching directives.
• Maximum TTL: The upper limit CloudFront allows for an object’s freshness period.

The origin can also influence caching with HTTP response headers, including:

Cache-Control: max-age=3600
Expires: Wed, 01 Jan 2027 12:00:00 GMT

Cache-Control: max-age specifies the freshness duration in seconds. Expires supplies an expiration date and time. CloudFront applies the configured caching rules and limits when determining the effective TTL.

Shorter TTLs are appropriate for frequently changing content, but they increase origin requests and may reduce cache-hit ratios. Longer TTLs improve performance and reduce origin load, but they increase the possibility that viewers receive an older version.

Invalidations

You can explicitly invalidate cached objects before their TTL expires. This is useful when an object was deleted or replaced and viewers must receive the new version immediately.

Invalidations can incur charges and are usually less efficient than using a versioned object name, such as:

/app.js?v=2026-09-01
/app-20260901.js

With versioned filenames, new content uses a new cache key while old content can expire naturally.

Path patterns and multiple origins

A CloudFront distribution can route different URL paths to different origins. For example:

Path pattern	Origin	Typical content
*.jpg	S3 bucket	Images
*.mp4	Video origin	Video files
/api/*	Application Load Balancer	Dynamic API requests
Default behavior	Primary origin	All unmatched requests

CloudFront evaluates path patterns and uses the matching behavior. Requests that do not match a specific pattern use the default behavior.

Path-based routing is useful when a single public hostname must serve content from different backends. Each behavior can have its own TTL, allowed methods, forwarding rules, and security configuration.

Request headers and cache variation

CloudFront can forward viewer request headers to the origin. Header handling also affects the cache key and therefore whether CloudFront can reuse an object.

Common strategies include:

• Forward only the headers required by the origin.
• Whitelist selected headers when the response varies based on those headers.
• Forward all headers when necessary, recognizing that this can prevent effective caching in legacy CloudFront configurations.
• Avoid including irrelevant headers in the cache key because doing so creates unnecessary cache variants.

If CloudFront caches separate versions based on a header, each distinct header value can produce a different cached object. For example, varying on a language header may create separate English, French, and German cache entries.

In current CloudFront configurations, cache policies and origin request policies separate two related decisions:

• Cache policy: Which request values form the cache key and which values are cached.
• Origin request policy: Which additional values are forwarded to the origin without necessarily becoming part of the cache key.

The exam may describe this using older terminology such as forwarding headers, cookies, or query strings in a cache behavior.

Exam-Relevant Takeaways

• CloudFront serves content from edge locations close to viewers.
• A cache hit avoids an origin request; a cache miss requires retrieval from another cache tier or the origin.
• Regional edge caches provide an intermediate caching layer with greater capacity than individual edge locations.
• TTL is a freshness-versus-performance tradeoff: longer TTLs improve cache efficiency, while shorter TTLs reduce staleness.
• Cache-Control: max-age and Expires can influence object freshness.
• Minimum, default, and maximum TTLs are configured for a cache behavior and constrain effective caching behavior.
• Explicit invalidation removes objects before expiration but may incur charges and is often less efficient than versioned object names.
• Path patterns route different requests to different origins.
• The default behavior handles requests that match no more specific path pattern.
• Forwarding unnecessary headers, cookies, or query strings can fragment the cache and lower the cache-hit ratio.
• Forwarding all headers can prevent useful caching in legacy behavior configurations.

Architecture Decision Guide

Requirement	Recommended approach	Main tradeoff
Static assets rarely change	Use a long TTL and versioned filenames	Old filenames remain cached until expiration
Frequently changing content	Use a shorter TTL and origin cache headers	More origin requests and potentially lower cache-hit ratio
Immediate removal of compromised or incorrect content	Use CloudFront invalidation	Additional operational cost and deployment dependency
Images and APIs use different backends	Create path-based cache behaviors with separate origins	Behavior ordering and cache settings must be managed carefully
Responses vary by language, device, or authorization context	Include only the required values in the cache key	More variants reduce cache efficiency
Origin needs a header but responses do not vary by it	Forward it through an origin request policy without adding it to the cache key	Incorrect policy design can cause wrong or inconsistent responses
Unmatched requests need a catch-all route	Configure the default behavior and default origin	A broad default can unintentionally route unexpected paths

Common Exam Traps

• Confusing edge locations with origins: An edge location is where CloudFront serves content; it is not necessarily where the application or data is stored.
• Assuming every request reaches the origin: A valid cache hit is served without an origin fetch.
• Treating TTL as a guarantee of immediate deletion: TTL controls freshness, not instant removal. Use invalidation for urgent removal.
• Choosing a very short TTL for all content: This may reduce staleness but can unnecessarily increase origin load and cost.
• Forgetting the default behavior: Requests that do not match a path pattern still need a configured default behavior and origin.
• Creating excessive cache variants: Forwarding every header, cookie, or query string can significantly reduce cache reuse.
• Caching personalized responses incorrectly: If user-specific data is cached without the relevant identity or authorization context in the cache key, one user’s response could be served to another user. Dynamic or personalized content requires careful cache-policy design.
• Assuming path patterns are arbitrary routing rules: A path pattern matches the viewer request path; it does not inspect the content type returned by the origin.

Real-World Engineer Notes

• Prefer immutable, versioned asset names for application deployments. This allows long TTLs while making releases predictable.
• Keep dynamic API caching separate from static asset caching. APIs often require different allowed methods, cache keys, authentication handling, and TTLs.
• Minimize the cache key. Include only headers, cookies, and query strings that genuinely change the response.
• Test cache behavior using response headers such as Age, Via, and X-Cache where available, along with CloudFront logs and metrics.
• Be cautious with authorization headers, session cookies, and personalized content. Caching without correct variation can create data exposure risks.
• A cache miss can occur even when an object exists elsewhere because the request may use a different cache key, behavior, query string, header, or cookie configuration.
• Use origin cache-control headers as part of the deployment contract, but enforce safe lower and upper bounds through CloudFront cache policies.

Quick Reference Summary

• Edge location: Viewer-facing CloudFront point of presence.
• Regional edge cache: Intermediate cache between edge locations and origins.
• Cache hit: Object is available and fresh in the applicable cache.
• Cache miss: CloudFront must retrieve the object from another tier or the origin.
• TTL: How long an object remains fresh.
• Invalidation: Explicitly removes objects before TTL expiration.
• Path pattern: Routes matching viewer request paths to a behavior and origin.
• Default behavior: Handles requests that match no more specific pattern.
• Cache key: Request attributes that determine whether two requests can share a cached response.
• Core tradeoff: Longer TTLs improve performance and reduce origin load; shorter TTLs improve freshness.

Flashcards

1. Q: What is a CloudFront cache hit?

A: A request for which CloudFront has a valid matching object and can respond without contacting the origin.

1. Q: What happens during a cache miss?

A: CloudFront checks another cache tier when applicable and ultimately fetches the object from the origin if it is unavailable.

1. Q: What is the purpose of a regional edge cache?

A: It provides an intermediate, higher-capacity cache between viewer-facing edge locations and the origin.

1. Q: What does TTL control?

A: How long a cached object can remain fresh before CloudFront checks the origin again.

1. Q: Which HTTP header specifies a relative cache duration?

A: Cache-Control: max-age=<seconds>.

1. Q: Which HTTP header specifies an absolute expiration time?

A: Expires.

1. Q: Why use versioned filenames for static assets?

A: They allow long TTLs while ensuring new content uses a new cache key, reducing the need for invalidations.

1. Q: What does a CloudFront path pattern determine?

A: Which cache behavior and origin handle a matching viewer request.

1. Q: What handles a request that matches no explicit path pattern?

A: The distribution’s default behavior and its associated default origin.

1. Q: Why can forwarding all headers harm caching?

A: It can cause many cache variants or disable effective caching in legacy configurations.

1. Q: What is the difference between a cache policy and an origin request policy?

A: A cache policy determines cache-key values; an origin request policy determines additional request values sent to the origin.

1. Q: When is a short TTL appropriate?

A: When content changes frequently and stale responses are unacceptable, provided the increased origin load is acceptable.

Practice Questions

Question 1

A global application serves product images from Amazon S3 through CloudFront. Images are immutable after publication, and each deployment writes files with a new versioned filename. Which configuration best improves performance and minimizes origin requests?

A. Use a very short TTL and invalidate every image after deployment.
B. Use a long TTL and versioned object names.
C. Forward all viewer headers and cookies to S3.
D. Disable CloudFront caching for image requests.

Correct answer: B

Explanation: Immutable, versioned assets can safely use long TTLs. New filenames create new cache keys, so deployments do not depend on mass invalidation.

Question 2

A CloudFront distribution serves /static/* from Amazon S3 and /api/* from an Application Load Balancer. Requests to /static/logo.jpg are being sent to the load balancer. What is the most likely issue?

A. Regional edge caching is disabled.
B. The S3 bucket must be in the same Region as the load balancer.
C. The path behavior is missing, incorrectly ordered, or has an incorrect pattern.
D. CloudFront cannot use multiple origins.

Correct answer: C

Explanation: Path patterns determine which behavior and origin handle a request. The /static/* behavior must exist and be evaluated correctly relative to other behaviors; unmatched requests use the default behavior.

Question 3

An application returns different content based on a language request header. CloudFront currently caches one response for all languages. What should the architect do?

A. Remove caching entirely from the distribution.
B. Include the language value in the cache key.
C. Forward all headers but keep the same cache key.
D. Increase the maximum TTL.

Correct answer: B

Explanation: When a request attribute changes the response, that attribute must be represented in the cache key so CloudFront maintains separate cached variants. Only the necessary header should be included to avoid unnecessary fragmentation.

Question 4

A security team requires a deleted object to stop being served from CloudFront immediately, even though its configured TTL has not expired. Which action meets the requirement?

A. Wait for the TTL to expire.
B. Change the regional edge cache.
C. Create a CloudFront invalidation for the object.
D. Add another origin without changing the behavior.

Correct answer: C

Explanation: An invalidation explicitly removes matching objects before normal TTL expiration. It may incur charges, so it should be used selectively for urgent changes.

Question 5

A dynamic application requires a custom request header at the origin, but the response is identical regardless of that header’s value. Which design generally provides the best cache efficiency?

A. Add the header to the cache key.
B. Forward the header to the origin without including it in the cache key.
C. Forward every viewer header and disable caching.
D. Add the header to the object filename.

Correct answer: B

Explanation: The origin request policy can forward a required header while the cache policy excludes it from the cache key when it does not affect the response. This preserves cache reuse while satisfying the origin requirement.