As of Februrary 2011 AWS S3 has been able to serve static websites, giving you superior availability for unchanging (or seldom-changing) content. But most websites today are not static; dynamic elements drive essential features such as personalized pages, targeted advertisements, and shopping carts. Today’s release from AWS CloudFront: Support for Dynamic Content alleviates some of the challenge of running dynamic websites. You can now configure a custom set of URL patterns to always be passed through to the origin server. This allows you to “poke holes” in the CDN cache for providing dynamic content.
Some web sites, such as this one, appear to be static but are driven by dynamic code. WordPress renders each page on every request. Though excellent tools exist to provide caching for WordPress, these tools still require your web server to process WordPress’s PHP scripts. Heavy traffic or poor hosting choices can still overwhelm your web server.
It’s relatively easy to configure your entire domain to be served from CloudFront. What do you need to think about when you poke holes in a CloudFront distribution? Here are two important items: admin pages and form actions.
The last thing you want is for your site’s control panel to be statically served. You need an accurate picture of the current situation in order to manage your site. In WordPress, this includes everything in the
/wp-admin/* path as well as the
Your site most likely does something with the information people submit in forms – search with it, store it, or otherwise process it. If not, why collect it? In order to process the submitted information you need to handle it dynamically in your web application, and that means the submit action can’t lead to a static page. Make sure your form submission actions – such as search and feedback links – pass through to the webserver directly.
When Content Isn’t So Dynamic
Sometimes content changes infrequently – for example, your favicon probably changes rarely. Blog posts, once written, seldom change. Serving these items from a CDN is still an effective way to reduce load on your webserver and reduce latency for your users. But when things do change – such as updated images, additional comments, or new posts, how can you use CloudFront to serve the new content? How can you make sure CloudFront works well with your updated content?
A common technique used to enable updating static objects is called object versioning. This means adding a version number to the file name, and updating the link to the file when a new version is available. This technique also allows an entire set of resources to be versioned at once, when you create a versioned directory name to hold the resources.
Object versioning works well with CloudFront. In fact, it is the recommended way to update static resources that change infrequently. The alternative method, invalidating objects, is more expensive and difficult to control.
Combining the Above Techniques
You can use a combination of the above techniques to create a low-latency service that caches sometimes-dynamic content. For example, a WordPress blog could be optimized by integrating these techniques into the WordPress engine, perhaps via a plugin. Here’s what you’d do:
- Create a CloudFront distribution for the site, setting its custom origin to point to the webserver.
- Poke holes in the distribution necessary for the admin, login, and forms pages.
- Create new versions of pages, images, etc. when they change, and new versions of the pages that refer to them.
Even though WordPress generates each page via PHP, this collection of techniques allows the pages to be served via CloudFront and also be updated when changes occur. I don’t know of a plugin that combines all these techniques, but I suspect the good folks at W3-EDGE, producers of the W3 Total Cache performance optimization framework I mentioned above, are already working on it.
7 replies on “Poking Holes in CloudFront-Based Sites for Dynamic Content”
Cool article. I have been playing with dynamic CF with a website hosted outside of EC2. I don’t see how I can use the same domain name (www.example.com) for the CNAME for the CF distro *and* for the content that will be served directly from the origin server (WordPress admin stuff). Can you shed some light on that?
Your public-facing domain name
www.example.comis a CNAME for the CloudFront distro. The CloudFront dynamic content is configured separately: specify a URL path such as
/wp-admin*, and CloudFront will forward the request
http://www.example.com/wp-admin/...to the origin.
This is only true for an HTTP site. Unless you want to put your actual domain as your cloudfront distribution name (asdfasdfasdf.cloudfront.net) then you can’t use SSL, so no dynamic secure content. Plus, you can’t serve HTTP via CloudFront and HTTPS directly, so for any site which requires SSL encrypted traffic (say any ecommerce site) this approach doesn’t work.
PS> It’s an interesting strategy, and thanks for a well written article.
Thanks for pointing that out. CloudFront has had HTTPS limitation from the outset, and AWS has promised that support for user-provided SSL certs is in the works. You can help prioritize this feature by indicating you want HTTPS CNAME support from CloudFront on this AWS survey. Unfortunately it’s a long, tedious survey 🙁 .
First of all: great article.
Secondly, we have added Cloufront to one of our WordPress websites.
It does a great job serving its pages but we have an issue with the Comments.
You mentioned in your article that this is a typical issue, but how did you manage to make WP Comments work combined with Cloudfront?
Thanks in advance,
I use a plugin called W3 Total Cache. http://wordpress.org/plugins/w3-total-cache/
It’s great, but requires some getting used to.
Contact me privately if you’d like an introduction to my guy who can set it up and tell you all about how to work with it.