Amazon CloudFront Support for Custom Origins
Amazon CloudFront uses an ever-growing network of edge locations to give your users high speed, low latency access to your content, regardless of where they happen to live.
Effective today we are opening up CloudFront and giving you the ability to use the origin server of your choice.
You can now create a CloudFront distribution using a custom origin. Each distribution will can point to an S3 or to a custom origin. This could be another storage service, or it could be something more interesting and more dynamic, such as an EC2 instance or even an Elastic Load Balancer:
Putting intelligence (dynamic processing) behind CloudFront gives you the ability to create content on demand without having to worry about storage, caching, or global distribution. You can have content that appears static (based on its URL) but which is actually built on the fly the first time that it is needed.
This can be handy when the content is reusable but somewhat expensive to create and changes infrequently. I believe that map tiles are the classic example. Imagine a system which overlays a base map with one or more custom layers. Generating all possible combinations of tiles would be prohibitively expensive, and also wasteful since most of them would never be seen. Instead, the path component of each tile’s URL can include the parameters needed to generate the tile. If the tile is already present in a particular CloudFront edge location then it will be served up directly, otherwise it will be generated, returned to the edge location, and then used to satisfy future requests (time to live and invalidation notwithstanding).
The newest version of the CloudFront Developer Guide contains some guidelines for the use of custom origins. Here are some of the most important ones:
- Respect the HTTP Keep-Alive header to improve performance.
- Ensure that the Date and Last-Modified headers are accurate on the generated content.
- Do not use query string parameters since these are not preserved by CloudFront.
- Use the Cache-Control header to indicate whether responses can be cached.
- CloudFront accepts HTTP 1.1 requests but makes only HTTP 1.0 requests to the origin server.
- Cookies are forwarded only on misses and Set-Cookie headers are removed from cached content.
The following tools, toolkits, and applications already support this new feature:
Like many of the most popular AWS features, we implemented this one because people like you asked for it! If you have additional ideas or suggestions, post them as comments here or in the CloudFront discussion forum. We’re all ears!