Introduction

Updating a file behind CloudFront is really a cache-management problem. Changing the object in S3 or another origin does not instantly replace every cached copy at CloudFront edge locations, so you usually solve the problem with versioned filenames, targeted invalidations, or cache settings that fit your deployment pattern.

Understand What Actually Gets Cached

CloudFront caches responses from your origin according to cache keys, TTL rules, and response headers. That means two different things exist after deployment:

• the new file at the origin
• the old file that may still be cached at edge locations

If users keep requesting the same URL and the old object is still cached, they can continue receiving the old version until the cached entry expires or is invalidated.

That is why "I uploaded the new file" and "users are seeing the new file" are not automatically the same event.

Best Practice: Versioned File Names

For static assets such as JavaScript, CSS, and images, the preferred approach is usually versioning the file name or URL.

Examples:

• 'app.20260311.js'
• 'styles.abcd1234.css'
• '/assets/logo-v2.png'

This works well because a new URL forces a new cache lookup. CloudFront does not need to be told to forget the old object, and browsers also behave more predictably.

A simple deployment pattern is:

1. upload the new versioned asset to the origin
2. update HTML or app references to the new URL
3. let the old cached asset age out naturally

For frequently changing front-end assets, this is usually better than repeated invalidations.

Use Invalidation When the Path Must Stay the Same

If the URL cannot change, such as /index.html or a known download path, create a CloudFront invalidation.

With the AWS CLI:

aws cloudfront create-invalidation \
  --distribution-id E1234567890ABC \
  --paths "/index.html"

You can invalidate multiple paths too:

aws cloudfront create-invalidation \
  --distribution-id E1234567890ABC \
  --paths "/index.html" "/app/config.json"

And for broader invalidation:

aws cloudfront create-invalidation \
  --distribution-id E1234567890ABC \
  --paths "/assets/*"

Invalidation tells CloudFront to stop serving the cached object for those paths and fetch fresh content from the origin on the next request.

When to Use Which Strategy

A practical rule is:

• use versioned names for static assets that can tolerate URL changes
• use invalidation for stable URLs that must remain the same
• use sensible cache headers so emergency invalidations are not your only control mechanism

This is why many production deployments version assets aggressively but still invalidate /index.html after each release. The HTML file is stable by name, while the assets it references are versioned.

Cache-Control Headers Still Matter

CloudFront behavior is strongly affected by origin cache headers such as Cache-Control.

For example, if you want aggressive caching for versioned assets, that is reasonable:

Cache-Control: public, max-age=31536000, immutable

For frequently changing HTML entry points, a shorter caching policy may be more appropriate.

The right answer is not "invalidate everything all the time." The better answer is to align CloudFront caching rules with the update pattern of each file type.

Updating Files in S3 Is Not Enough by Itself

If your origin is S3, uploading a replacement object to the same key updates the origin copy, but CloudFront may still serve the older cached version until expiration or invalidation.

That means the deployment flow for a same-path replacement is usually:

1. upload the new S3 object
2. create a CloudFront invalidation for that path if the cache must refresh immediately

If the path changes through versioning, step 2 is often unnecessary.

Automating the Process

In CI or deployment scripts, it is common to automate both the upload and the invalidation.

1aws s3 cp dist/index.html s3://my-bucket/index.html
2aws cloudfront create-invalidation \
3  --distribution-id E1234567890ABC \
4  --paths "/index.html"

For a versioned-asset deployment, the script may upload hashed files and only invalidate the stable HTML shell.

That keeps invalidation counts smaller and makes cache behavior more predictable.

Common Pitfalls

One common mistake is updating a file in S3 and expecting CloudFront to refresh instantly without invalidation or versioning.

Another pitfall is invalidating large path sets on every release when versioned filenames would make deployment cleaner and cheaper.

A third issue is ignoring cache headers. If every file gets the same caching policy, update behavior becomes harder to control.

Finally, developers sometimes invalidate the CDN but forget browser caching. Versioned asset URLs are the cleanest way to solve both CloudFront and browser cache problems at once.

Summary

• Updating a file at the origin does not automatically replace cached copies at CloudFront edge locations.
• Versioned filenames are usually the best solution for static assets.
• Use CloudFront invalidation when the path must stay the same.
• Set cache headers according to how often each type of file changes.
• For stable entry-point files, a common deployment pattern is upload first, then invalidate the specific path.