S3, Cloudfront, and Cloudflare. Oh My.

Why rebuild the blog?

Recently I migrated my personal blog from a self hosted Jekyll install to Pelican. I am a big fan of Pelican. Jekyll seemed to not want to be self hosted. For example, in order to serve an SSL certificate, I had to run a reverse proxy from NGINX.

Similarly, I wanted to reduce unnecessary complexity. So, in the process of redesigning the blog, I decided to also reconsider hosting.


I didn’t really have a reason to use Heroku. My blog is fairly simple, there’s not really anything crazy going on in the backend that would require a more sophisticated platform. I’ll probably be using Heroku for You’re being Reported when I eventually overhaul the website.

S3 + Route 53 + Cloudfront

Originally I had placed all my eggs in the big Bezos basket by having all content served from Cloudfront. However, I had some issue. For one, Cloudfront doesn’t allow for a high level of customization. I felt like my content wasn’t replicating as quickly as I’d like. Another snag was that I felt as though it wasn’t as performant as I’d like. I don’t think this is anything but anecdotal, but I figured I would explore other options.

Cloudfront + Cloudflare

At this point, I decided to try Cloudflare again. I really like Cloudflare. The way I have the setup is that Cloudfront serves the S3 bucket, but isn’t distributed. The reason for this is that S3 alone cannot serve SSL. So I then have Cloudfront pass the content via SSL to Cloudflare, where it hosts the user facing SSL certificate and does some CDN magic. I like Cloudflare as it feels like a more fully fleshed out product. However, there is a downside, and it’s that certain products cost money. Based on how much I like the service, I feel it is a justified cost.

Colin Murray avatar
About Colin Murray
I am a solutions engineer at Cloudflare. All opinions are my own.
comments powered by Disqus