Static websites on Amazon S3 with Cloudfront — which way to go?

Amzon Webservices (AWS) offer a CDN called CloudFront and a data storage called Simple Storage Service (S3). Both of them are designed to work together to serve any kind of static website from just HTML with pictures over larger file downloads to a complete JavaScript single-page-app.

Static Hosting should be solid like a rock: you don’t have any code running on the server that could throw exceptions or run out of memory. (Own image taken near Alcúdia, Mallorca.)

S3 alone already offers Website-functionality, but CloudFront extends this, not only with the global cache network (CDN), but also by providing SSL/TLS (for secure https) and the ability to serve for a domain that has a different name than your bucket.

A thing which puzzles almost everyone working with S3 and CloudFront for the first time is that there are two different ways to integrate both services: one is via the AWS-internal REST-Api and the other is using S3 website features.

The differences between both are explained on an AWS documentation page, but one has to read that one really carefully to understand the consequences of this choice. No amount of blog posting by anyone can make this any simpler, but at least I can provide a summary of the most important differences. So I’ll do that here without further ado.

Advantages of publishing your bucket as a website:

• you can configure redirects, index documents (by path) and error pages like in a webserver configuration. This can be quite powerful, see the docs here.
• you can use the S3-website-URL for internal testing to bypass CloudFront (which can be very useful when you have weird bugs around cache invalidation).

On the other hand, if you use the REST-Api approach:

• your bucket will only be accessible through CloudFront and nobody can access it via an s3-website-domain.
• you can even go as far as not giving public access to the bucket via the S3 API.
• you can have SSL-encrypted communication between CloudFront and S3.
• you can enable PUT and POST requests to actually store data in S3 using CloudFront.

In my personal application of S3 + CloudFront it turned out that I can make very good use of both advantages of the S3-website feature: it helps with debugging and its redirect feature provides a flexible way to get nice URLs for all the pages. In fact, I wasted quite a bit of time debugging issues caused by the cache and the ability to bypass the cache via the S3-website URLs could have saved me that time.

But your choice really depends on your use case. For example I only came to my conclusion of using S3-website after I had worked with the REST-based way for a while. REST-based got me started faster because it offers a really simple way to set an entry-document for the entire distribution — it was a really easy starting point until I outgrew it.

Interested in joining FRIDAY?

If you’d like to join us on the journey of building a new digital insurance with the first insurance experience customers love, check our open positions.