CODEWITHSUNDEEP
amazon-cloudfront
Yalamber
Yalamber

Reputation: 7580

S3, cloudfront and expiry date

I am using s3 to host static website. This website is placed in s3 bucket and being distributed by cloudfront. It all works well but we are facing problem when we need to change specific files. if we change index.html file in s3 bucket we are not getting the latest file from cloudfront. Should I be setting expiry time on s3 for these static files and only then after expired time will cloudfront look for new version of file and distribute new files?

Upvotes: 4

Views: 6681

Answers (2)

Travis D
Travis D

Reputation: 317

It looks like you have to set the meta data on the s3 side:

http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingMetadata.html

The best way I found to do this is use BucketExplorer and go "Batch Operation", "Update Metadata", "Add Metadata" and then add "Cache-Control:max-age=604800, public" a 1 week cache period.

Upvotes: 2

marekful
marekful

Reputation: 15351

CloudFront uses the Cache-Control and Expires header sent by the origin server to decide if a resource is to be stored in cache and how long a it is considered fresh. If you don't control caching via response headers, CF will consider each resource as stale after 24 hours it was fetched from the origin. Optionally, you can configure a distribution to ignore cache control headers and use an expiry time for each resource that you specify.

When you update a file at the origin, CF will not attempt to refresh its copy until it expires. You can follow different strategies to have CF update cached copies.

1) The least efficient and not recommended is use invalidation. You can do it via AWS console or API.

2) Tell CF when to look for updated content by sending Expires headers. For example, if you have a strict policy for deploying new content/version to your website and you know that say you roll out a deployment almost every Thursday, you may send an Expires header with each resource from your origin set to next planned deployment date. (This will probably not work with S3 origins.)

3) The most efficient and recommended way is to use versioned URLs. A good practice could be to include the last modified time of the resource in its access URI. With EC2 or other origins able to serve dynamic content it is fairly easy, with an S3 origin, it's not that straight forward if possible at all.

Therefore I'd recommend invalidating the updated resources.

Upvotes: 2

Related Questions