A deploy finishes, the pipeline is green, and the site still shows yesterday’s homepage. The reflex is to create an invalidation and move on. That works, and it also hides the reason it happened, which means it will happen again next week.
CloudFront is doing what it was told. The question is what it was told about the file you just replaced.
The two layers that decide freshness
Every request passes two caching decisions. The edge location keeps a copy according to the cache policy attached to the behaviour; the browser keeps its own copy according to the Cache-Control headers the origin sends.
When those disagree, the result is confusing: a hard refresh shows the new page, a normal visit shows the old one, and a colleague on another network sees something else again.
The fix is to decide freshness per file type rather than per site.
Hashed assets can be cached forever
Files produced by a build with a content hash in the filename — app.9f3c1a.js — can be cached for a year, because a new build produces a new name. There is no reason to expire them, and doing so wastes the benefit of the CDN.
This is the part that makes a site fast. Long-lived caching on immutable assets is not a risk; it is the design.
The HTML entry point cannot be cached for long
The HTML file is the one that references the hashed assets. If it is cached for a day, visitors keep requesting the previous bundle, and the new release is invisible until the TTL expires.
So the HTML gets a short TTL, often a few minutes, and a revalidation directive so the CDN checks rather than guesses. The exact number matters less than the principle: the entry point is the file that changes, so it must not outlive the release cycle.
Why invalidations are a symptom, not a strategy
An invalidation is a manual instruction to throw away cached copies. It is useful after a mistake, and expensive as a habit: invalidations are limited, they take time to propagate, and they briefly push all traffic to the origin.
A deployment process that depends on invalidations has usually not separated the entry point from the assets. Fix that and the invalidation disappears from the runbook.
Cache policy versus legacy forwarding
Older distributions forward headers to the origin to control caching, which fragments the cache and lowers the hit rate. Modern cache policies are explicit: which headers, cookies and query strings form part of the cache key.
Forwarding every header means every visitor gets their own cache entry, and the CDN becomes an expensive proxy. Forward only what changes the response — an authorisation header on a private route, a language cookie if the page varies by language, and nothing else on public pages.
The deploy pattern that avoids all of this
- Build with content-hashed filenames.
- Upload assets first, with a long cache lifetime.
- Upload HTML last, with a short lifetime.
- Publish atomically so a visitor never sees half a release.
- Keep the previous build available for a one-step rollback.
With that order, a visitor either gets the old HTML and old assets, or the new HTML and new assets. There is no window where the page references a file that does not exist yet.
When the cache is genuinely the problem
Sometimes the cache is fine and the origin is wrong: an upload that silently failed, a build that published to the wrong prefix, or a second distribution still pointing at the previous bucket.
Check the origin response before invalidating. If the file at the origin is also old, the CDN is innocent and an invalidation just costs time.
What to look at in the response headers
x-cache tells you whether the edge served a cached copy or went to the origin. age tells you how long the copy has been there. cache-control tells you what the origin asked for. Those three headers answer most freshness questions without guessing.
If x-cache says hit and age is large on HTML, the policy is wrong. If it says miss and the content is still old, the origin or the deploy is wrong.
The cost angle
Requests that miss the cache are served from the origin, and origin responses are billed. A site with a poor hit rate pays more and loads slower, which is a rare combination of two bad outcomes.
Fixing the cache policy is usually the cheapest performance work available, and it does not require touching the application.
Our static website hosting setup includes cache policy by file type, hashed assets and a deploy with rollback. If the CDN is part of a wider AWS environment, the service catalogue on AWS cloud services covers the surrounding pieces, and cloud cost optimisation is where an unexpected egress bill usually gets explained.
