Amazon CloudFront has two policies with deceptively similar configuration screens: a Cache Policy and an Origin Request Policy. Both let you select headers, cookies, and query strings, but they serve different purposes. A cache policy determines which request values become part of the cache key. An origin request policy forwards additional values to the origin without adding them to the cache key.
A poor configuration usually shows up in one of two ways. Adding user-agent strings, session cookies, or many query parameters to the cache key creates a large number of cache variants and lowers the cache hit ratio. Failing to forward a value that the origin needs can produce the wrong language or device version, break authorization, or cause the origin to reject the request.
Start with the Cache Key and the Origin Request
When a viewer request reaches CloudFront, CloudFront builds a cache key according to the cache policy. If the matching object is already cached, CloudFront can return it immediately. On a cache miss, CloudFront sends a request to the origin.
Headers, cookies, and query strings included in the cache key are automatically included in the origin request. The origin request policy covers a different group: request values that the origin needs to receive but that should not create separate cached versions.
Consider a page that uses lang=en to select a language and utm_source=newsletter for traffic attribution. The language parameter changes the response, so it belongs in the cache policy. The tracking parameter should not create another copy of the same page. If the origin needs it for logging, it can be forwarded through an origin request policy. If analytics runs entirely in the browser, CloudFront may not need to forward it at all.
What Each Policy Controls
| Setting | Cache Policy | Origin Request Policy |
|---|---|---|
| Main purpose | Defines the cache key and cache lifetime | Adds information to an origin request |
| Headers | Selected values create cache variants | Forwarded without creating cache variants |
| Cookies | Selected values create cache variants | Forwarded without creating cache variants |
| Query strings | Selected values create cache variants | Forwarded without creating cache variants |
| TTL settings | Controls minimum, default, and maximum TTL | Does not control TTL |
| Compression settings | Can normalize and cache Gzip or Brotli variants | Does not create compressed cache variants |
| Cache hit ratio | Directly affected by selected values | Not directly affected, although the origin response may vary |
An origin request policy cannot repair an incorrect cache key. Suppose the origin changes its response according to a cookie. If CloudFront forwards the cookie but excludes it from the cache key, the response generated for one cookie value may be stored under a shared key and served to requests carrying other values. Any request value that changes a cacheable response must be part of the cache key, or the response must be excluded from shared caching.
How to Handle Headers
Headers can fragment a cache quickly. A browser request may contain User-Agent, Referer, tracking fields, and several client hints. Including all viewer headers in the cache key can produce an enormous number of variants.
A header is a reasonable cache-key candidate when the origin genuinely returns different content for it and the number of possible values is controlled. An image service that returns AVIF, WebP, or JPEG according to a normalized Accept value is a common example. Normalize raw header values into a small number of categories before adding them to the cache key; otherwise, minor browser differences can create separate objects.
A header used only for origin logging or processing, without changing the shared response, can be forwarded with an origin request policy. Headers that the origin does not use should normally be omitted. This reduces unnecessary forwarding and limits accidental exposure of viewer information.
The Authorization header needs special attention. AWS does not allow it to be added individually to an origin request policy header allowlist. To forward it, you can include it in a cache policy or use an origin request policy that forwards all viewer headers. Authorization responses often vary by user, so forwarding the header is only part of the design. You must also prevent private responses from being shared through an unsafe cache key.
How to Handle Cookies
Many distributions forward all cookies because it appears convenient. This often damages cache efficiency. Analytics, advertising, A/B testing, and session tools continuously add cookies, and every cookie included in the cache key expands the number of possible combinations.
Review cookies one by one:
If a cookie changes the response body, status code, redirect target, or authorization result, add it to the cache key or prevent the response from entering a shared cache.
If it is used only for origin-side logging and the response remains identical, forward it through the origin request policy only when that data is required.
If the origin does not need it, do not forward it.
Authenticated pages deserve extra care. Forwarding a session cookie to the origin while allowing multiple users to share the same cache key can expose personalized content. Account, order, billing, and control-panel routes usually need caching disabled or a carefully tested isolation design.
How to Handle Query Strings
Query strings often mix content controls with tracking data. Content parameters change the representation; tracking parameters describe how a visitor arrived.
?page=2,?lang=en, and?format=webpmay change the response and therefore may belong in the cache key.?utm_source=,?utm_campaign=, and?gclid=usually do not change page content and should not create cache variants.Signed parameters, temporary tokens, and user identifiers affect access or private content and require an explicit security and caching design.
If parameter order and irrelevant parameters create duplicate URLs, a CloudFront Function at the viewer request event can normalize them before cache lookup. For example, it can remove tracking parameters that the application has confirmed are unnecessary. Test first: a parameter should not be removed if it affects rendering, redirects, authorization, or required attribution.
TTL Settings Belong to the Cache Policy
A cache policy also defines Minimum TTL, Default TTL, and Maximum TTL. CloudFront evaluates these values together with the origin's Cache-Control and Expires headers.
Minimum TTL is the setting most likely to cause an unpleasant surprise. When it is greater than zero, CloudFront can cache content for at least that period even when the origin sends Cache-Control: no-cache, no-store, or private. Behaviors that handle personal data, signed-in sessions, or real-time permissions should use a Minimum TTL of zero and be tested with the actual origin response headers.
Default TTL applies when the origin does not provide a usable cache lifetime. Maximum TTL limits how long CloudFront can retain an object. Static assets, HTML pages, APIs, and authenticated routes rarely benefit from one broad TTL configuration. Separate cache behaviors by path and content type when their requirements differ.
A Practical Configuration Example
Assume a public product listing uses these request values:
The
langquery parameter selects the language.A
currencycookie changes displayed prices.The
utm_sourcequery parameter is used for origin-side analytics.A
session_idcookie is written to logs but does not change the anonymous listing.User-Agentdoes not affect the response.
| Request value | Policy placement | Reason |
|---|---|---|
lang | Cache policy | Each language produces a different page |
currency | Cache policy | Currency changes the rendered content |
utm_source | Origin request policy, or omit it | It should not split the page cache |
session_id | Forward cautiously; first confirm it is required | It adds privacy and logging risk |
User-Agent | Usually omit from both policies | Raw values have high cardinality and the page does not use them |
This design produces a language-by-currency cache matrix. Four languages and three currencies create up to 12 primary variants per URL. Adding raw user agents and many campaign parameters can multiply that number dramatically.
Managed Policies or Custom Policies?
AWS provides managed cache policies and managed origin request policies for common use cases. They can shorten setup time, but you should still open the policy details and review TTLs, headers, cookies, query strings, and compression settings.
Use a caching-optimized managed policy for ordinary static assets when its settings match your requirements. Choose an appropriate managed origin request policy when the origin needs a broader set of viewer information, and review the privacy implications. APIs and dynamic pages often need custom policies limited to the exact values that affect their responses.
AWS manages its built-in policies, so you cannot edit them. Create a custom policy when you need different fields or TTL values. If several cache behaviors share one custom policy, a policy update affects every associated behavior. Record those associations before making changes.
Common Configuration Mistakes
Putting Every Viewer Header in the Cache Key
Browsers, devices, extensions, and networks can produce many header combinations. Identify the headers the origin actually uses, then normalize high-cardinality values into a few stable categories.
Forwarding a Response-Changing Value Without Caching on It
The origin receiving a parameter does not mean CloudFront can distinguish the resulting responses. If a value changes cacheable content, include it in the cache key.
Adding Tracking Parameters to the Cache Key
Campaign and click identifiers usually create duplicate cached objects. Remove them at the edge, forward only what the origin needs, or collect them through browser-side analytics.
Setting a Positive Minimum TTL for Private Responses
A positive Minimum TTL can override no-cache, no-store, and private for the configured period. Review user-specific paths separately.
Reusing One Policy for Every Path
Static files, public HTML, anonymous APIs, and signed-in pages have different caching requirements. Separate cache behaviors make those rules easier to test and troubleshoot.
Troubleshooting Low Hit Ratios and Incorrect Content
Start with the X-Cache response header, then use CloudFront standard logs or real-time logs to examine paths, query strings, and cache results.
Compare the old and new cache policies and identify newly added headers, cookies, or query strings.
Measure the cardinality of each value. A field with thousands of daily values will usually fragment the cache when added to the key.
Confirm whether the origin changes its response for each value.
Check whether CloudFront Functions or Lambda@Edge modifies the request before cache lookup.
Review Minimum, Default, and Maximum TTL together with the origin's
Cache-Controlheader.Reproduce suspected content mixing with different request values; compare the body,
Age,ETag, andX-Cacheheaders.
Existing cached objects do not automatically become part of the new design when policy logic changes. If old objects may be reused incorrectly, use a scoped invalidation or a versioned URL. A broad invalidation can temporarily lower the hit ratio and may add cost.
Pre-Deployment Checklist
List every request value that changes the response body, status, redirect, or authorization result.
Put those values in the cache key, or explicitly prevent the corresponding responses from using a shared cache.
Forward logging and origin-processing values only when needed.
Remove unused headers, cookies, and query strings.
Review
Authorization, session cookies, signed parameters, and user identifiers separately.Set Minimum TTL to zero for user-related paths and verify origin cache directives.
Test cache isolation with several combinations of request values while monitoring the hit ratio.
Document policy-to-cache-behavior associations and prepare a rollback path.
Frequently Asked Questions
Can a Cache Behavior Use Both Policies?
Yes. A cache behavior can normally use one cache policy and one origin request policy. Values included in the cache key are automatically sent to the origin; the origin request policy adds values that need forwarding without becoming cache dimensions.
Does an Origin Request Policy Reduce the Cache Hit Ratio?
It does not directly change the cache key, so it does not create variants in the same way as a cache policy. It can still cause trouble if the extra values make the origin return different content that CloudFront stores under one shared key.
Does Forwarding All Query Strings Mean They Are All Cached?
No. An origin request policy can forward query strings without adding them to the cache key. The query-string setting in the cache policy determines cache variation.
Should I Forward All Cookies?
Few publicly cached pages need every cookie. An allowlist provides tighter control over cache combinations and privacy exposure. For private dynamic pages, reconsider whether shared CloudFront caching should be enabled at all.
Do I Need an Invalidation After Changing a Policy?
It depends on the change and the risk. If an old object could be reused for an incompatible request, perform a scoped invalidation or move to a versioned URL. Adding a field used only for origin logging generally does not require invalidating every object. Validate the change on a test distribution or test path first.
Conclusion
A cache policy controls the cache key, TTLs, and compressed cache variants. An origin request policy adds information to requests sent to the origin. Values already included in the cache key are automatically forwarded, so they do not need to be configured twice.
Build the cache key from values that change the response. Handle analytics, logging, and origin-only fields separately. This keeps the number of cached variants manageable and reduces the risk of serving one user's or one content variant's response to another request.
References
AWS CloudFront Developer Guide: Understand the cache key. Reviewed August 19, 2026.
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/understanding-the-cache-key.htmlAWS CloudFront Developer Guide: Control the cache key with a policy. Reviewed August 19, 2026.
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/controlling-the-cache-key.htmlAWS CloudFront Developer Guide: Control origin requests with a policy. Reviewed August 19, 2026.
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/controlling-origin-requests.htmlAWS CloudFront Developer Guide: Use managed cache policies. Reviewed August 19, 2026.
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-managed-cache-policies.htmlAWS CloudFront Developer Guide: Use managed origin request policies. Reviewed August 19, 2026.
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-managed-origin-request-policies.html
