Share cached pages without mixing visitors — CloudFront and Cache policies

Your goal

Choose which request details should produce a different cached response.

Why this matters

A shop serves both public product pages and private account pages. You will design useful cache keys, avoid unnecessary copies, and protect personalized responses.

Words you will use

A cache stores a response for reuse. A cache key decides which requests share it. Headers, cookies, and query strings can change what a server returns.

How to proceed

Read each situation and choose an answer. The lesson explains the result. Try again if needed, then continue through all three decisions and finish the tour.

1. Notice what changes the answer

The same product page can be shown in two languages selected by a request field. Reusing one response for both languages would be wrong. Choose the key rule.

What must the cache distinguish?

The request details that affect the cached response.

A cache key groups requests that may reuse a response. Include the relevant differences when caching variants, and ensure the origin receives what it needs. Otherwise a cache hit can still be the wrong answer.

Language variants can receive the correct response.

Response-changing field → distinct cache variant

2. Remove useless differences

Every public-page request includes a tracking ID that does not change the page. Including it in the cache key creates many copies of the same response. Choose an improvement.

What should happen to that key field?

Exclude it from the key if it does not affect the response.

Keep the cache key as small as correctness allows. Unnecessary differences reduce reuse. Forwarding a field to the origin and including it in the cache key are separate choices that should be reviewed together.

More equivalent requests can reuse the same public response.

Same public content → same cache key

3. Protect private pages

Account pages contain each visitor’s private orders. A public-page cache policy could accidentally reuse those responses. Choose the safest starting design.

How should account pages be handled?

Use a separate behavior that disables shared caching, then verify headers.

Keep personalized pages out of a shared cache unless a carefully reviewed design makes reuse safe. Check cache policy minimum TTL and origin cache controls; an unsafe policy can override the intended protection.

Private account responses have a separate, tested cache rule.

Private path → caching disabled → authorized origin response

Practice, then check your understanding

In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.

Read the official AWS documentation for service behavior and production details.