Chapter 11: Cold Fronts and CloudFront

Obviously named after Weather Fronts, AWS CloudFront is a CDN (Content Delivery Network). There can be different weather fronts, including cold fronts, warm fronts, etc  However, Cold Fronts are bad:

"Cold fronts often bring heavy thunderstorms, rain and hail. Cold fronts can produce sharper changes in weather."

But hopefully CloudFronts are good.

CDN's can reduce web latency for users who are located near an CDN edge location (where the content is cached), and can reduce load on the origin servers (either AWS or your own), and therefore improve scalability. CloudFront support all content that can be served over HTTP and HTTPS, including javascript. It also support media streaming using RTMP (what's that? Real Time Messaging Protocol).

CloudFront has distributions, origins and cache control.  I'm not sure exactly what a "distribution" is, but an origin is where the content comes from.

A simple example is:

• Store the original versions of your objects in one Amazon Simple Storage Service (Amazon S3) bucket.
• Distribute download content such as text or graphics.
• Make your objects accessible to everyone.
• Use the CloudFront domain name in URLs for your objects (for example,http://d111111abcdef8.cloudfront.net/image.jpg) instead of your own domain name (for example, http://www.example.com/image.jpg).
• Keep your objects in CloudFront edge locations for the default duration of 24 hours. (The minimum duration is 0 seconds.)

Objects stay in an edge location cache for 24 hours once they are loaded the 1st time. They are removed after 24 hours or to make room for more frequently requested objects. Cach control allows the time before refresh to be changed, 0 time means the request always goes to the origin. Cached objects can be invalidated before cache expiry with a invalidation API. it is designed for "unexpected" circumstances.

CloudFront can also server dynamic content using cache behaviours. This appears to give multiple paths for content for different matching content types. E.g. static content goes one way, dynamic another. Not 100% sure how this works but from Werner's blog it looks like the reason that a 0 second cache time was added was actually to enable dynamic content - i.e. so the request doesn't get stale dynamic content (which yes, is dynamic and probably end-user dependent).

Use cases: They suggest it should work fine for users are geographically distributed - i.e. not from a single location or appearing to (e.g. being funneled through a corporate VPN).

CDNs have been around for a while so I'm not sure that I've got much to add.  There a lot written (but not much I can find from a s/w engineering perspective) on why CDNs work for html5 and web pages and HTTP etc

Only that we've done some modelling for real clients and demos (using Dynatrace easyTravel application) to predict the impact (reduced latency and load on servers) of CDNs (and other caching) using our software performance modelling tool. Already described in the blog on ElastiCache.