Guide · CloudFront deployment safety
CloudFront TTL policy and invalidation
A narrow decision path for origin headers, CloudFront's minimum/default/maximum TTL bounds, and public deploys.
Start with the right path
| Situation | Start here | Why |
|---|---|---|
| Private or sensitive | MinTTL=0 and a disabled/all-zero edge policy where appropriate | A positive CloudFront minimum can override origin private, no-store, or no-cache. |
| Frequently changing public asset | Fingerprint the URL and update all references | The new request target avoids waiting for the old object; retain the old URL for rollback. |
| Stable HTML / urgent correction | Invalidate the exact CloudFront path and poll to Completed | It refreshes selected CloudFront edge entries, not every browser or downstream cache. |
Read the audit refresh: it keeps the compact precedence matrix and synthetic /account red-flag consequence, then tightens standalone s-maxage, viewer-only response-header, effective cache-key, rewrite, and completion-status boundaries.
Keep the boundary visible
Edge policy
max-age, s-maxage, Expires, and privacy directives are origin signals. The matching CloudFront policy's minimum, default, and maximum TTLs determine the documented edge result.
CloudFront-specific Do not generalize its positive-minimum override to HTTP or every CDN.
Viewer and downstream
A viewer-facing max-age is separate from the shared edge. Invalidation does not clear browser history/bfcache, service workers, corporate proxies, other CDNs, or uninstrumented hops.
Observed · none This run is documentation-only.