Amazon CloudFront - Support for Dynamic Content

Introduction
Amazon CloudFront's network of edge locations (currently 30, with more in the works) gives you the ability to distribute static and streaming content to your users at high speed with low latency.

Today we are introducing a set of features that, taken together, allow you to use CloudFront to serve dynamic, personalized content more quickly.

What is Dynamic Personalized Content?
As you know, content on the web is identified by a URL, or Uniform Resource Locator such as http://media.amazonwebservices.com/blog/console_cw_est_charge_service_2.png . A URL like this always identifies a unique piece of content.

A URL can also contain a query string. This takes the form of a question mark  ("?") and additional information that the server can use to personalize the request. Suppose that we had a server at www.example.com, and that can return information about a particular user by invoking a PHP script that accepts a user name as an argument, with URLs like http://www.example.com/userinfo.php?jeff or http://www.example.com/userinfo.php?tina.

Up until now, CloudFront did not use the query string as part of the key that it uses to identify the data that it stores in its edge locations.

We're changing that today, and you can now use CloudFront to speed access to your dynamic data at our current low rates, making your applications faster and more responsive, regardless of where your users are located.

With this change (and the others that I'll tell you about in a minute), Amazon CloudFront will become an even better component of your global applications. We've put together a long list of optimizations that will each increase the performance of your application on their own, but will work even better when you use them in conjunction with other AWS services such as Route 53, Amazon S3, and Amazon EC2.

Tell Me More
Ok, so here's what we've done:

Persistent TCP Connections - Establishing a TCP connection takes some time because each new connection requires a three-way handshake between the server and the client. Amazon CloudFront makes use of persistent connections to each origin for dynamic content. This obviates the connection setup time that would otherwise slow down each request. Reusing these "long-haul" connections back to the server can eliminate hundreds of milliseconds of connection setup time. The connection from the client to the CloudFront edge location is also kept open whenever possible.

Support for Multiple Origins - You can now reference multiple origins (sources of content) from a single CloudFront distribution. This means that you could, for example, serve images from Amazon S3, dynamic content from EC2, and other content from third-party sites, all from a single domain name. Being able to serve your entire site from a single domain will simplify implementation, allow the use of more relative URLs within the application, and can even get you past some cross-site scripting limitations.

Support for Query Strings - CloudFront now uses the query string as part of its cache key. This optional feature gives you the ability to cache content at the edge that is specific to a particular user, city (e.g. weather or traffic), and so forth. You can enable query string support for your entire website or for selected portions, as needed.

Variable Time-To-Live (TTL) - In many cases, dynamic content is either not cacheable or cacheable for a very short period of time, perhaps just a few seconds. In the past, CloudFront's minimum TTL was 60 minutes since all content was considered static. The new minimum TTL value is 0 seconds. If you set the TTL for a particular origin to 0, CloudFront will still cache the content from that origin. It will then make a GET request with an If-Modified-Since header, thereby giving the origin a chance to signal that CloudFront can continue to use the cached content if it hasn't changed at the origin.

Large TCP Window - We increased the initial size of CloudFront's TCP window to 10 back in February, but we didn't say anything at the time. This enhancement allows more data to be "in flight" across the wire at a given time, without the usual waiting time as the window grows from the older value of 2.

API and Management Console Support - All of the features listed above are accessible from the CloudFront APIs and the CloudFront tab of the AWS Management Console. You can now use URL patterns to exercise fine-grained control over the caching and delivery rules for different parts of your site.

Of course, all of CloudFront's existing static content delivery features will continue to work as expected. GET and HEAD requests, default root object, invalidation, private content, access logs, IAM integration, and delivery of objects compressed by the origin.

Working Together
Let's take a look at the ways that various AWS services work together to make delivery of static and dynamic content as fast, reliable, and efficient and possible (click on the diagram at right for an even better illustration):

• From Application / Client to CloudFront - CloudFront’s request routing technology ensures that each client is connected to the nearest edge location as determined by latency measurements that CloudFront continuously takes from internet users around the world. Route 53 may be optionally used as a DNS service to create a CNAME from your custom domain name to your CloudFront distribution. Persistent connections expedite data transfer.
• Within the CloudFront Edge Locations - Multiple levels of caching at each edge location speed access to the most frequently viewed content and reduce the need to go to your origin servers for cacheable content.
• From Edge Location to Origin - The nature of dynamic content requires repeated back and forth calls to the origin server. CloudFront edge locations collapse multiple concurrent requests for the same object into a single request. They also maintain persistent connections to the origins (with the large window size). Connections to other parts of AWS are made over high-quality networks that are monitored by Amazon for both availability and performance. This monitoring has the beneficial side effect of keeping error rates low and window sizes high.

 

Cache Behaviors
In order to give you full control over query string support, TTL values, and origins you can now associate a set of Cache Behaviors with each of your CloudFront distributions. Each behavior includes the following elements:

• Path Pattern - A pattern (e.g. "*.jpg") that identifies the content subject to this behavior.
• Origin Identifier -The identifier for the origin where CloudFront should forward user requests that match this path pattern.
• Query String - A flag to enable support for query string processing for URLs that match the path pattern.
• Trusted Signers - Information to enable other AWS accounts to create signed URLs for this URL path pattern.
• Protocol Policy - Either allow-all or https-only, also applied only to this path pattern.
• MinTTL - The minimum time-to-live for content subject to this behavior.

Tool Support
Andy from CloudBerry Lab sent me a note to let me know that they have added dynamic content support to the newest free version of the CloudBerry Explorer for Amazon S3.  In Andy's words:

I'd like to let you know that CloudBerry Explorer is ready to support new CloudFront features by the time of release.  We have added the ability to manage multiple origins for a distribution, configure cache behavior for each origin based on URL path patterns and configure CloudFront to include query string parameters.

You can read more about this in their new blog post, How to configure CloudFront Dynamic Content with CloudBerry S3 Explorer .

Andy also sent some screen shots to show us how it works. The first step is to specify the Origins and CNAMEs associated with the distribution:

The next step is to specify the Path Patterns:

With the Origins and Path Patterns established, the final step is to configure the Path Patterns:

Update: Tej from Bucket Explorer wrote in to tell me that they are now supporting this feature:

Hi, I am one of the developer of Bucket Explorer. I am excited to announce that Bucket Explorer new version is supporting CloudFront Dynamic Content feature. Try Its 30 day trial version with full featured. Dynamic Content (Steps and Images).

And Here You Go
Together with CloudFront's cost-effectiveness (no minimum commits or long-term contracts), these features add up to a content distribution system that is fast, powerful, and easy to use.

So, what do you think? What kinds of applications can you build with these powerful new features?

-- Jeff;

PS - Read more about this new feature in Werner's new post: Dynamic Content Support in Amazon CloudFront.

Comments

[Jon Verhelst]

Good to see that CloudFront is getting some extra goodies.

Although I must say I'm a little disappointed that we are still lacking proper (dynamic) gzip support for S3 backed storages.

[GabrieleMittica]

Great feature! This is a fantastic news!

[Geoffrey Plitt]

That is straight-up awesome. Good stuff, guys.

[Saku Mättö]

Hi and this all sounds great! I'm still confused as a webmaster for a Wordpress site as to whether or not I can now run my WP site on Cloudfront. Is there more where I can read about this?
Thanks,
Saku

[Silentlennie]

What do I think ? I think there is still one thing that is preventing me from being a customer.

If only CloudFront DNS latency wasn't so high because they use to many CNAMEs and no Anycast for the top domain.

Please DO contact me for more details, I would love to be a CloudFront customer if this is solved.

[IArtem]

You've just made me happy!

[Johann]

I'd be interested in hearing what increasing initcwnd did for CloudFront. I've tried this before and the gains weren't exactly clear http://twitter.com/#!/johannburkard/status/169754429069852672/photo/1/large But maybe you see real gains with your traffic?

[Renat Zubairov]

Hi,

That's a great feature. We are already using CloudFront with custom origin for serving dynamically generated images (see our blog [1]) however one problem we didn't had a solution up to now is the image size. For example if image URL looks like this:

http://img.elastic.io/img/2519313

We want to add a sizing information like this

http://img.elastic.io/img/2519313?width=100

However up to now CloudFront was ignoring the query parameters, and it's really nice addition that it will support it now.

Thanks Allot!

Links:

[1] http://blog.elastic.io/post/22773181715/how-we-use-amazon-cloudfront-for-dynamically-generated

[Micah Nolte]

These are great additions, and Cloudfront has already been a high-quality service.

The main deal-breaker is how you charge for bandwidth between the origin and all of the edge locations, essentially charging twice for each piece of unique content. With these changes to make them dynamic, that means the bandwidth bill will be twice what it would be if they were serving that same file directly from S3 or EC2, assuming they were using a query string with a time stamp, or something similar.

Also, on the bill, this cost is hidden inside of the misleading name "AWS Data Transfer (excluding Amazon CloudFront)."

Are there any changes to the pricing model for transferring data to the edge locations?

[Alex Smithq]

This looks awesome. One quick question though...in theory, this should speed up even dynamic PHP content with no static content at all? Our application is centered around lots of AJAX calls to a PHP script which returns data from our database (RDS). Would we benefit from using CloudFront with the PHP script or would there be a minimal speed difference because it's not cached and has to get content from the origin (EC2 ELB) every time?

Thanks!

[Bob Van Zant]

This is pretty awesome, but where's IPv6 support? Even Akamai has that.

[urbanjunkie]

Does this mean that 'versioning' of files via the querystring now works?

Here's the scenario have a file called stylesheet.css and access it via stylesheet.css?ver=2012051401. If I update stylesheet.css, I change the "ver" parameter to 2012151402 to force CF to 'refresh' the file without needing to invalidate it (invalidations seem to be woefully unsupported without using the API).

Is my understanding correct?

[Rustin]

This is the right step forward for Amazon and it's customers using AWS CloudFront; though not exciting or new to advanced customers and a benefit that should have been offered years ago as technology and software has existed prior to AWS.

Great for marketing I suppose, to teach decision makers that don't truly understand technology or businesses they run. Pinch me when decided to offer edge computing and storage.

Are there still many dial-up users left; a modem. Go USR! At least they made a movie.

[Scott McArthur]

Hello,
Looks good, but what support is there for https (SSL). I presume that there is still no way to provide our own SSL certificate to CloudFront, so no way to benefit secure applications?
Cheers,
Scott

[Darren]

Does this also work with SSL (e.g.: https://)?

[Devon Bleak]

Awesome updates :-)

@Johann - TCP window size/scaling only governs incoming data to the system in question. In this case it's allowing the origin (or end-user, in the case of a large request payload) to send ~64MB of data to CF all at once rather than the previous value of ~256kb. Receiving data faster from the origin means CF can better saturate the link to the end-user for stuff that's not already in its cache, but the window size to the end-user is still governed by their TCP stack settings which is why you were probably not seeing much of an improvement in your tests.

@Alex Smithq - You should see a drop in overall load times for your use case due to the persistent origin connections - your users wouldn't be having to wait on a lengthy three-way handshake back to your origin, instead making a much faster three-way handshake to CF's closest cache. For users that are very remote from your origin but very close to a CF cache you can expect to see upwards of .5s shaved off overall request time (assuming the CF cache node in question already has a persistent connection open to your origin). For smaller dynamic payloads that generally fit within the initial tcp window for the connection you're not likely to see much of an improvement beyond that. You could achieve similar results using HTTP keep-alives between your origin and end-users, but this has the advantages of also caching your static content, giving you the option of setting/tuning short non-zero TTLs on things that are dynamic but don't need to be real-time, and being able to keep way fewer idle connections open to your origin.

[Stephen]

These are great additions. Keep up the great work!

Still, the largest want that I've had and seen in the forums is a solution to the S3 domain apex (aka, naked domain, root domain) issue. Having A record support for S3 buckets & CloudFront distros would be huge. Until then, we are forced to use hacky work arounds like this:

http://blog.dnsimple.com/how-the-alias-virtual-record-works/

Thanks again,
smm

[Per Osbeck]

Nice!

How about supporting POST as well?

[Frank]

Million Dollar Question: can SSL sites use this dynamic content delivery setup?

[Jose R. Revuelta]

You rock!!! This is the kind of functionality that add real value!

[Kumar D]

Is SSL (https) supported?

[Johann]

@Devon thank you for the explanation.

[Tej Kiran]

Hi,
I am one of the developer of Bucket Explorer. I am excited to announce that Bucket Explorer new version is supporting CloudFront Dynamic Content feature. Try Its 30days trial version with full featured.

Dynamic Content (Steps and Images) - http://www.bucketexplorer.com/documentation/cloudfront--how-to-create-distribution-for-dynamic-content-delivery.html

Thanks

Tej Kiran
www.bucketexplorer.com

[John Mark Mitchell]

As of me writing this (May 23 2012), SSL is supported via the CloudFront distribution URL only. Meaning, you cannot CNAME the SSL URL. Concretely, you can reference an item via SSL as:

https://.cloudfront.net/picture.jpg

but not:

https://cdn.mydomain.com/picture.jpg

where cdn.mydomain.com is a CNAME to .cloudfront.net. At present you will get SSL errors.

This means you are unable to use your domain name or SSL cert. This can cause problems with crossdomain policies in the browser as well as add undo complexity to the maintenance of a site.

I have been assured by AWS staff that HTTPS support for distribution CNAMEs is on their feature list but that it needs community support for prioritization. To help in this effort please fill out the CloudFront survey (see below) and note this feature request. AWS staff use data gathered from the survey for planning and prioritizing the CloudFront roadmap.

Be sure to note that HTTPS CNAME support is needed when you take the CloudFront Survey: http://aws.qualtrics.com/SE/?SID=SV_9yvAN5PK8abJIFK

[Christiaan Conover]

This is fantastic!

I'd love to use this for handling traffic to my Wordpress site. There are only two things missing to prevent that.

1. Support for POST requests to handle authentication, publishing, etc.
2. Ability for CloudFront to be accessed at domain root with a valid A record instead of a subdomain (e.g. example.com instead of www.example.com)

However, this is a phenomenal feature for making my static asset serving more efficient.

[Garret]

Now that you have support for query parameters, why not allow query parameters on the default root object?

If you attempt to use a query parameter the UI complains saying: "Must contain only valid URL characters", which is an incorrect error message because ?, =, and & are perfectly valid URL characters.

[Soan]

I am looking at integrating the asp.net BlogEngine application with Cloudfront.
I think i have read a lot about it till now and good to go ahead with it.

One doubt that i wanted to clarify is whether the cloudfront work fine with dynamix AJAX content that we have on site? I have read that it does not yet support POST http calls and hence will return 403 forbidden errors for POST based AJAX calls.
Has anybody tried this or has any information to share?

[Niels Tindbæk]

This is awesome, cant wait to get started!

Many people are asking about SSL... does anyone have any insight on that?
If I can live with the AWS domain, i'm fine right? HTTPS is only an issue when CNAMEing?

How about private dynamic content? Can dynamic content be "hidden" behind signed time limited URLs?

[Soan]

I think naked domain mapping is one of the biggest request that i also have.
I have a website hosted on a hosting server and want to use the dynamic whole website caching with Cloudfront.
The images and other static content is already on cloudfront but i am unable a way to point my naked domain to cloudfront cache.