Whole site hosting - Cloudfront?

Question

If i plan on creating a static website (using a WCMS like Jahia, Wordpress etc) can i try and host the whole site via Cloudfront, using an approach something like below?

• Build the website in the WCMS and export the whole site structure
• Create an S3 static website bucket
• Use a tool such as S3_Website (on Git) to the exported website file into S3
  • At any later time when need to synchronise updates to the exported website with the S3 website, run s3_website push again. (It will calculate the difference, update the changed files, upload the new files and delete the obsolete files.)
    • Use some sort of polling process to run the export API and S3_website push script to auomate the whole process. Maybe a Lambda function. Run this say every night assuming a cache TTL of 24 hours?
• Flush the content to the Cloudfront cache via a pre warm script (such as the armfront script on Git). I'm a bit unclear how this works in terms of it does a flush and replace or invalidate if this matched time wise (i.e. the content TTL expires just before we pre warm etc?). Do i even need to pre warm?/flush
• Cloudfront is set to use the S3 bucket as its origin server and will cache according to cache headers. CF will continue to serve the content even if expired

Will this work or is this more complex in terms of cached content (invalidation etc)?

Answer 1

Don't think of CloudFront as primarily "hosting" your site. CloudFront caches your site to a) reduce traffic to the origin web server (not a big concern when hosting on S3 to begin with) and b) to speed up delivery to clients since CloudFront caches are geographically distributed throughout the globe, instead of just having one centralised server.

Yes, you can host a website this way. Put the actual "master copy" on S3, configure CloudFront as a front-end cache to it. The master copy needs to stay where it is; in case you were thinking of removing it from S3 once it's cached in CloudFront, that would be a bad idea. CloudFront makes no guarantees about keeping your data available; caches may expire at any time, entire CloudFront nodes may be taken offline, replaced, or added at any time, and in all those cases the CloudFront node needs an origin server to get its copy from.

The only problem left then is cache expiry. As always, there are two approaches:

1. Configure a sensible cache timeout for your content. If you set your content to expire after, say, 1 hour, then any client may see data which is outdated by up to an hour after you update your content. This may or may not be a problem, you decide. You can and should configure different expiry times for different kinds of content; images and such can probably be cached indefinitely, while the HTML of an often-updated front page should probably have much shorter life times.

2. Explicitly flush the cache with an invalidation request after you update your content. The problem with this is that you only have a limited number of free invalidation requests on CloudFront. It is not something AWS likes you to do and is mostly reserved as a tool for emergencies when incorrect data got pushed out. AWS prefers you to let content expire naturally, since this puts the least stress on the network.

"Pre-warming" is not typically necessary and difficult to do anyway, since you cannot push content to CloudFront; CloudFront pulls content from the origin as needed. I'm not sure what "armfront" you're referring to exactly or what it supposedly does. Without pre-warming, the very first request for a particular page in a particular geographic region will be ever so slightly slower, that's all.