Fix a CloudFront site serving old files after deployment

The origin contains the new JavaScript or image, but some visitors still receive an older version. Re-uploading the same filename repeatedly may not change the cached response immediately.

Why this happens

CloudFront and browser caches follow cache keys and freshness rules. The origin’s current file is not necessarily fetched for every viewer request.

Step-by-step solution

1. Compare the origin response with the distribution response and inspect cache-related headers. Confirm that the requested path is the one actually deployed.

2. Prefer versioned or content-hashed asset filenames for immutable assets. Keep HTML freshness appropriate to how it references those assets.

3. When an existing path must change immediately, use a targeted invalidation through the deployment process. Review wildcard scope and potential cost rather than invalidating everything by habit.

Worked example

app.a1b2.js and app.c3d4.js can coexist while new HTML references the newer file. That avoids relying on every cache to forget an overwritten app.js at the same moment.

Verify the fix

Fetch the exact updated URL through CloudFront and test a browser reload. Confirm that HTML does not reference assets already removed from the origin.

Prevent a repeat

Design deployment and cache policy together, retaining old hashed assets long enough for previously cached HTML to keep working.

Reference

Official documentation or standards guidance

An original Gistmax troubleshooting guide. Scenarios and sample values are illustrative; configuration depends on your software version and environment. Cover diagram: Gistmax Tutorials.