≡ Menu

Poking Holes in CloudFront-Based Sites for Dynamic Content

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.

Poking Holes

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.

Admin pages

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 /wp-login.php page.

Form actions

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.

A great technique for feedback forms is to use WuFoo, where you can visually construct forms and integrate them into your website by simple Javascipt. This means that your page can remain static – the Javascript code dynamically inserts the form, and WuFoo handles the processing, stops the spam, and sends you the results via email.

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?

Object versioning

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 comments… add one }

  • Don May 15, 2012, 1:09 pm

    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?

    • shlomo May 17, 2012, 6:17 am

      @Don,

      Your public-facing domain name www.example.com is 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.

  • Callum July 25, 2012, 7:54 am

    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.

  • Jose Delgado August 28, 2013, 5:59 am

    Hi,
    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,

    Jose Delgado

Leave a Comment