Why does CloudFront serve outdated content from Amazon S3?

Short description

By default, CloudFront caches a response from Amazon S3 for 24 hours (Default TTL of 86,400 seconds). If your request lands at an edge location that served the Amazon S3 response within 24 hours, then CloudFront uses the cached response. This happens even if you updated the content in Amazon S3.

Use one of the following methods to push the updated Amazon S3 content from CloudFront:

• Invalidate files to remove content.
• Use file versioning to update or remove content.

Resolution

Invalidate Amazon S3 objects

You can invalidate an Amazon S3 object to remove it from the CloudFront distribution's cache. After you remove the object from the cache, the next request retrieves the object directly from Amazon S3.

Note:

• You can't invalidate specific versions of an object that uses cookies or headers to vary the response. CloudFront invalidates all versions of the object in this case.
• Each AWS account is allowed 1,000 free invalidation paths per month. For more information, see Amazon CloudFront pricing.

When you create an invalidation, be sure that the object paths meet the following requirements:

• The object paths must be for individual objects, or the paths must end with the wildcard character (*). For example, you can't run an invalidation on a path similar to /images/*.jpeg. This is because the path isn't for an individual object, and it doesn't end in a wildcard character.
• The specified path must exactly match the capitalization of the object's path. Invalidation requests are case-sensitive.
• To remove specific versions of an object based on a query string, include query string parameters in the invalidation path.

Object invalidation typically takes 10-100 seconds to complete. To check the status of an invalidation, view your distribution from the CloudFront console.

Use file versioning

If you update content frequently, then it's a best practice to use file versioning to clear the CloudFront distribution's cache. For frequent cache refreshes, file versioning might cost less than invalidation.

To use file versioning, complete the following steps:

• Store new versions of the object at the origin with the version number in the key name. For example, if you update /image_v1.png, then store a new version of the object as /image_v2.png.
• Update the object at the origin but cache based on a query string with the file version. For example, the query string updates from /image.png?ver=1 to /image.png?ver=2. You can use a cache policy to specify which query strings are included in the cache key and origin requests.
  Note: You can still request the previous version (/image.png?ver=1) while it's available in the CloudFront cache.

Consider the following advantages and disadvantages for each method of file versioning:

• You can store new versions of the object at the origin to revert changes to previous versions that are still available under the previous names. However, if you store multiple versions of an object, then your storage costs can increase.
• Object updates at the origin and caching based on the query string can reduce your storage costs. To prepare for any rollbacks, it's a best practice to keep previous file versions offline.

Note: Specified versioned file names or directory names isn't related to S3 Versioning. S3 Versioning doesn't automatically update content. Make sure that you specify file paths correctly because you can't cancel an invalidation request after it starts.

Related information

Manage how long content stays in the cache (expiration)

Query string forwarding and caching