Jaap Haagmans The all-round IT guy


Serving dynamic content using Cloudfront

As I mentioned earlier, it's possible to serve dynamic content using Cloudfront. Which is wonderful, because this means Cloudfront emerged from being a "simple" CDN to being an actual caching solution for your entire website. There are a few things to keep in mind though.

Misses and hits

Cloudfront is a caching mechanism. In fact, I wouldn't be surprised if it's based on something like the proven Varnish. So it works with misses and hits. If it doesn't find the content the visitor is looking for, it will count as a miss and put in a request to the origin server. After this, it will cache the missed fragment. If your miss rate is very high, your website will in fact be slower for most of your visitors. If you can't properly cache your website, you're probably better off not using Cloudfront. However, a hit will be very fast. Some websites can produce a hit rate of over 99%, which means they serve almost every visitor from an edge location, while the origin can remain at rest.

Cookies and sessions

If your website serves content that is visitor-specific (like shopping carts or an account page), you will have to specify the cookies that are used to identify the session. If you don't, the cart of the first user that visited a page will be cached and displayed to every other user. If Cloudfront knows about these session cookies, it will be able to store a version of the page for each individual visitor. If you display the shopping cart on every page though, this might add overhead you'll want to avoid. If that's the case, loading the cart in a separate request using AJAX might be a better way to go, so that the majority of the page can be cached once for all users while retaining the websites dynamic nature.

Page expiry

You can handle expiration of pages entirely within the origin of your website. By default, Cloudfront will assume your objects or pages expire after 24 hours and will check for updates once a day. If your website is pretty much static, this could be fine for you. Every page will have one "slow hit" per day and that's it. However, many websites will require a much lower setting because the underlying data changes. You can set the max-age on your cache control header value on every page and Cloudfront will respect that. So if you have a very busy blog with commenting functionality, you could set the max-age to 600 seconds (10 minutes) on your homepage and to 10 seconds on your post pages for instance. If every post is visited every second, that will reduce load time for 90% of your visitors. But in this case, you could also consider loading comments through AJAX, reducing the expiration time needed (in fact, the expiration time could be very high for posts).


If you have an e-commerce website, you probably handle (parts of) user requests through SSL. Custom SSL domains with Cloudfront come at a price though, so you will want to think this through. An option might be to use an URL like secure.example.com for your encrypted pages and send those requests directly to your origin, while serving "unsecure" pages through Cloudfront.