LEARN. PRACTICE. GROW.Representation identity
Design the cache key from what changes content. A factsheet can vary by language and market, while a campaign identifier serves only analytics. If the origin selects language by cookie, forwarding that cookie is insufficient to separate stored objects: cache must distinguish the variant. Cache-policy values enter the key and are forwarded; an origin request policy can forward additional values without fragmenting cache. Validate policy interaction too: an origin-request blocklist does not remove a value included in the key. In the application contract, list every dimension, its inclusion rationale and a pair of requests proving the intended separation. Avoid adding irrelevant high-cardinality values merely to make every request unique.
Authorization and lifetime
A personalized response cannot be shared merely because the first request passed authentication. If Authorization reaches only the origin, a hit can bypass that check. When every access requires origin authorization, disable caching on the corresponding behavior. Other strategies need deliberate identity, revocation and lifetime design. A positive Minimum TTL can impose caching despite private, no-store or no-cache. Conversely, zero minimum does not mean caching is disabled when default and maximum remain positive. Review effective policy, origin headers and behavior ordering. A broad pattern before a restrictive one can capture the request and apply access rules different from those the team expected. Test distinct identities before approving the release.
Private origin and transport
For a regular S3 origin, OAC with always sign combines signing with documented HTTPS behavior to S3. Authorization still requires a distribution-scoped bucket policy; SSE-KMS objects also need appropriate key-policy permissions. Do not use broad permission as a substitute for investigating which control is missing. An S3 website endpoint is a custom origin and supports neither OAC nor OAI: migration also requires reviewing website features in use. For a custom HTTPS origin, validate expected name, certificate and chain. An unexpired certificate for another name does not satisfy the identity contract. Keep viewer-to-CloudFront and CloudFront-to-origin segments separate when collecting encryption evidence for a change or audit.
Failover with defined scope
An origin group is not universal application recovery. In Default mode, a miss starts at the primary even after another request used the secondary. Status criteria, connection failure, timeouts and eligible methods determine the next attempt. POST does not receive this automatic failover; successful GET does not prove write resilience. OPTIONS also requires the documented cached-method configuration. Define testing by the actual method and functional result: instruction acknowledgement, correct-version reading or file recovery. For timed-out writes, consider partial processing and idempotency before retrying. Reporting should explain which operations were demonstrated and which need an additional recovery strategy, including ownership of unresolved or potentially duplicated work.
Errors surviving a fix
After fixing a missing object, the viewer can still receive a cached error. Compare current origin state with the cache path and relevant Error Caching Minimum TTL. A lifetime header in an error response can increase retention up to the applicable bound; values are not added together. Exceptions exist: 416 is not cached, and an S3 origin with caching enabled retains a one-second minimum even when configured error minimum is zero. Do not turn one specific rule into a principle for every status. Record status, URL, headers and time to distinguish origin recovery, cache expiry and a failure that remains active elsewhere in the delivery path.
Updating and accepting a release
A viewer GET with Cache-Control or Pragma no-cache does not force CloudFront to query the origin. Define versioning or invalidation strategy and verify received content. If the key distinguishes query strings, enumerate variants or use a trailing wildcard with reviewed scope. Paths are case sensitive, and a misplaced wildcard can be literal. Invalidation cannot be cancelled after submission; assess miss load and origin capacity beforehand. During a personalized-content incident, correcting policy and removing affected entries are complementary steps. Use fictional data, two identities and negative tests for acceptance, preserving sufficient evidence without recording tokens or real statements in tickets, logs or test fixtures.
def cache_key(path, request, dimensions):
return path, tuple((name, request.get(name)) for name in dimensions)
pt = {"language": "pt", "campaign": "a"}
en = {"language": "en", "campaign": "a"}
assert cache_key("/factsheet", pt, []) == cache_key("/factsheet", en, [])
assert cache_key("/factsheet", pt, ["language"])!= cache_key("/factsheet", en, ["language"])
assert cache_key("/factsheet", pt, ["language"]) == cache_key("/factsheet", {**pt, "campaign": "b"}, ["language"])
assert cache_key("/factsheet", pt, ["language"])!= cache_key("/prices", pt, ["language"])
assert cache_key("/factsheet", pt, ["language", "campaign"])!= cache_key("/factsheet", {**pt, "campaign": "b"}, ["language", "campaign"])
print("five key checks passed; no real content cached or authorized")
Two /factsheet requests with language=pt and language=en should produce distinct variants; a different campaign should not create a variant if it does not change the document.
Common pitfalls
Confusing forwarding with key identity; assuming no-store defeats a positive minimum; treating recovered GET as complete DR.
Related topics: Identity and TLS · Release and rollback
Design caching, authorization, transport and recovery as verifiable contracts on each path.
Reference: Control the cache key · ANS-C01