One of the most common queries we get from our AWS customers is something along the lines of “Why is their CloudFront serving outdated content?”.

CloudFront caches a response from Amazon S3 for 24 hours. If you request within that 24 hours, CloudFront returns the cached response even if you updated the content in Amazon S3.

Here, at Bobcares, we assist our customers with similar AWS queries as part of our AWS Support Services.

Today, let’s see how our Support Techs resolve this outdated content issue.

Why is CloudFront serving outdated content from Amazon S3?

Amazon CloudFront is a content delivery service offered by AWS that speeds up the distribution of static, dynamic web, or streaming content to end-users.

It delivers the content through a worldwide network of data centers called edge locations.

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

Our Support Engineers fix this outdated content issue by using any of the following methods.

• Invalidate the S3 objects.
• Use object versioning.

Methods to push the updated S3 content from CloudFront

Now let’s discuss in detail how both methods resolve outdated S3 content issues.

Invalidate the S3 objects

In this method, we can invalidate an S3 object to removes them from the CloudFront edge cache. After the object is removed from the cache, the next request retrieves the object directly from Amazon S3.

Consider the following points before proceeding with an invalidation:

• • We can run an invalidation only on a web distribution. That is we can’t invalidate a Real Time Messaging Protocol (RTMP) distribution.

• • CloudFront invalidates all versions of the object. That is we can’t invalidate a specific versions of an object that uses cookies or headers to vary the response.

• • Each AWS account is allowed 1,000 free invalidation paths per month. There is a price per invalidation path over 1,000 per month.

On creating an invalidation, our support techs noticed that we need to make sure the object paths meet the following requirements:

• • The first point we have noted is the object paths must be for individual objects or the paths must end with the wildcard character (*). That is if we use a path like /images/*.jpeg, we can’t run an invalidation because it is not for an individual object.

• • The next point is invalidation requests are case-sensitive. That is the specified path must exactly match the capitalization of the object’s path.

• • We can remove specific versions of an object by including QueryString in the invalidation path.

Steps to Invalidate the S3 objects

1. Log into AWS console.
2. Navigate to CloudFront service.
3. Select the CloudFront ID connected to the bucket.
4. Navigate into the CloudFront instance.
5. Go to the `Invalidations` tab.
6 ‘Create Invalidation’.
7. Click on ‘create navigation.
8. Enter the `Object Path`.
9. Finally click on ‘Invalidate’.

Object invalidations typically take from 60 to 300 seconds to complete. We can check the status of invalidation by viewing your distribution from the CloudFront console.

Use object versioning

If we are updating the S3 content frequently, the best way is to use the object versioning method to clear the CloudFront distribution’s cache.
Because it might cost less than using the invalidation method.

Our Support Techs add versioning to the objects by using any of the following methods.

•  The first method is to store new versions of the object at the origin with the version number in the key name.

/image_v1.png to /image_v2.png

•  The other method is to whitelist a query string with the object version, like the following query string:

/image.png?ver=1 to /image.png?ver=2

We can use a cache policy to specify which query strings are included in the cache key and origin requests.

Advantages and Disadvantages of object versioning Method

If we add the version to the object name, we can revert changes because the previous version of the object remains in Amazon S3 under the previous name. However, storing multiple versions of an object can increase your storage costs.

If we whitelist a query string with the object version, it can reduce your storage costs. but we can’t revert changes because the object is overwritten. So it’s a best practice to keep previous object versions offline.

Conclusion

In short, today we saw how our Support Techs resolves the outdated content issue in Amazon CloudFront.