Distributions

To use Amazon CloudFront, you start by creating a distribution, which is identified by a DNS domain name such as d111111abcdef8.cloudfront.net. To serve files from Amazon CloudFront, you simply use the distribution domain name in place of your website’s domain name; the rest of the file paths stay unchanged. You can use the Amazon CloudFront distribution domain name as-is, or more typically you create a user-friendly DNS name in your own domain by creating a Canonical Name Record (CNAME) in Amazon Route 53 or another DNS service that refers to the distribution’s domain name. Clients who use the CNAME are automatically redirected to your Amazon CloudFront distribution domain name. If you use Route53 as your DNS service, you can also use a feature called aliases to redirect a zone root address such as “example.com” (which cannot be a CNAME) to your CloudFront distribution.

Origins

When you create a distribution, you must specify the DNS domain name of the origin—the Amazon S3 bucket or HTTP server—from which you want Amazon CloudFront to retrieve the definitive version of your objects (web files). For example, note the following:

• Amazon S3 bucket: myawsbucket.s3.amazonaws.com
• Amazon EC2 instance: ec2–203–0–113–25.compute-1.amazonaws.com
• Elastic Load Balancing Load Balancer: my-load-balancer-1234567890.us-west-2 .elb.amazonaws.com
• Website URL: mywebserver.mycompanydomain.com

Cache Control

Once requested and served from an edge location, objects stay in the cache until they expire or are evicted to make room for more frequently requested content. By default, objects expire from the cache after 24 hours. After an object expires, the next request results in Amazon CloudFront forwarding the request to the origin to verify that the object is unchanged or to fetch a new version if it has changed.

Optionally, you can control how long objects stay in an Amazon CloudFront cache before expiring. To do this, you can choose to use Cache-Control headers set by your origin server, or you can set the minimum, maximum, and default Time to Live (TTL) for objects in your Amazon CloudFront distribution.

You can also remove copies of an object from all Amazon CloudFront edge locations at any time by calling the invalidation Application Programming Interface (API) or through the Amazon CloudFront console. This feature removes the object from every Amazon CloudFront edge location regardless of the expiration period you set for that object on your origin server. The invalidation feature is designed to be used in unexpected circumstances, such as to correct an error or to make an unanticipated update to a website—not as part of your everyday workflow.

Instead of invalidating objects manually or programmatically, it is a best practice to use a version identifier as part of the object (file) path name. For example, note the following:

• Old file: assets/v1/css/narrow.css
• New file: assets/v2/css/narrow.css

When using versioning, users will see the latest content through Amazon CloudFront when you update your site without using invalidation. Old versions will expire from the cache automatically. That said, depending on other settings, you may need to invalidate the base page that includes references to the versioned objects.

Configuring Amazon CloudFront

The following steps walk you through the process required to configure Amazon CloudFront:

Amazon CloudFront Configures Its Edge Locations

5. After assigning a domain name, Amazon CloudFront will automatically send your distribution’s configuration (but not your content) to all of its edge locations.

As you build your website or application, you can use the domain name that Amazon CloudFront provides for your URLs when referencing objects. For example, if Amazon CloudFront returns the domain d111111abcdef8.cloudfront.net for your distribution, the URL for logo.jpg in your Amazon S3 bucket or the root directory of your web server would be as follows: http://d111111abcdef8.cloudfront.net/logo.jpg. A more typical practice, however, is to use relative paths that do not specify the host part of the URL at all, unless another host name is actually required. This provides more flexibility in terms of site construction and the use of CNAMEs, load balancers, and CloudFront distributions. For example, an image file would be referenced as “/images/website-logo.png”, or to take the previous example, “logo.jpg”. This allows the reference to work properly whether the web page is accessed directly from the server by its DNS name or IP address, via the CloudFront distribution’s DNS name, or via a CNAME such as www.example.com that you provide that points to the CloudFront distribution’s DNS name.

Optionally, you can configure your origin server to add headers to the files, with a header indicating how long you want the files to stay in the cache in the Amazon CloudFront edge location. By default, each object stays in an edge location for 24 hours before it expires. The minimum expiration time is 0 seconds, with no maximum expiration time limit.

Figure 7.1 shows an overview of the steps required to configure your Amazon CloudFront distribution.

How CloudFront Operates

The following steps outline what happens when users request objects after you’ve configured Amazon CloudFront to deliver your content.

1. Users access your website or application and request one or more objects, such as an image file and an HTML file.
2. DNS routes the request to the Amazon CloudFront edge location that can best serve the user’s request, typically the nearest Amazon CloudFront edge location in terms of network latency.
3. In the edge location, Amazon CloudFront will check its cache for the requested files, returning them to the user if they are found in the cache. If the files are not found in the cache, Amazon CloudFront will perform the following actions:
   1. Amazon CloudFront will compare the request with your distribution configuration and forward the request for the files to the applicable origin server for the corresponding file type (for example, to your Amazon S3 bucket for image files and to your HTTP server for the HTML files).
   2. The origin servers send the files back to the Amazon CloudFront edge location.
   3. As soon as the first byte arrives from the origin, Amazon CloudFront begins to forward the files to the user. Amazon CloudFront also adds the files to the cache in the edge location for the next time someone requests those files.

The process for CloudFront content delivery is shown in Figure 7.2.

Dynamic Content, Multiple Origins, and Cache Behaviors

Serving static assets, as described previously, is a common way to use a CDN. An Amazon CloudFront distribution, however, can easily be set up to also serve dynamic content and to use more than one origin server. You can control which requests are served by which origin and how requests are cached using a feature called cache behaviors.

A cache behavior lets you configure a variety of Amazon CloudFront functionalities for a given URL path pattern for files on your website, as shown in Figure 7.3. One cache behavior applies to all PHP files in a web server (dynamic content) using the path pattern *.php, while another behavior applies to all JPEG images in another origin server (static content) using the path pattern *.jpg.

The functionality that you can configure for each cache behavior includes the following:

• The path pattern
• Which origin to forward your requests to
• Whether to forward query strings to your origin
• Whether accessing the specified files requires signed URLs
• Whether to require HTTPS access
• The amount of time that those files stay in the Amazon CloudFront cache (regardless of the value of any cache control headers that your origin adds to the files)

Cache behaviors are applied in order; if a request does not match the first path pattern, it drops down to the next path pattern. Normally, the last path pattern specified is * to match all files.

A Note on Performance: Dynamic Content and HTTP/2

It is very useful that Amazon CloudFront can seamlessly deal with all content, including dynamically-generated content that is not cacheable alongside a wide array of content that can be cached (see previous and following sections). But you may assume that there is no performance benefit in that case. After all, if the Amazon CloudFront edge location needs to reach back to the origin each time it receives a request for a particular URL representing dynamic content, how can it speed up content delivery? You may then assume that if an item is not in the Amazon CloudFront cache, the use of Amazon CloudFront won’t speed up access to that content the first time it is requested.

As it turns out, even dynamic or initially uncached content will often be delivered with lower latency to end users. The reason has to do with the time it takes to set up the TCP or TLS connections that underlie the content caching and delivery mechanisms. Each such connection takes a finite amount of time to establish, and if a connection from CloudFront to the origin can be reused, significant latency gains are possible.

For example, let’s assume that the round-trip latency between an end user and the Amazon CloudFront edge location is 30 milliseconds, and the round-trip latency between the edge location and the origin is 100 milliseconds. (For context, as of this writing, even over the high performance AWS backbone the roundtrip latency from the Singapore region to the Northern Virginia region was about 240 milliseconds.) In all cases, before any content can be delivered for the very first time, the TCP connection establishment between the three hosts (which require one full round-trip for the SYN/ACK packets from client to edge, and the edge to origin) will take at least 130 milliseconds (ignoring local overhead, which is much higher for TLS connections).

Now, let’s assume a new client connects to the edge location and begins requesting content from the same origin, whether dynamic content, or content not yet in the edge cache. The Amazon CloudFront edge server will often be able to re-use an existing connection to the origin server, and avoid the connection setup overhead. This can reduce the first-byte delivery time by 100 milliseconds or more. That may not seem like a lot, but even 1/10 of a second per TCP connection can add up quickly. Avoiding the overhead of establishing an encrypted TLS session each time will decrease latency even more. So using Amazon CloudFront is a performance win even in cases where content caching is not playing a role. Your users will be happy to receive the best possible performance in all of these scenarios.

Amazon CloudFront also supports connections from clients via the HTTP/2 protocol. That new protocol, already supported by most modern browsers, provides a significant number of enhancements that improve performance by connection re-use, multiplexing, server push, etc. Even if your origin server does not support HTTP/2 yet, those enhanced features in use between your end-users and the Amazon CloudFront edge servers can significantly improve performance even when Amazon CloudFront is accessing your origin server using HTTP/1.x. Not only can you use Amazon CloudFront to optimize origin access via connection re-use, but content in the edge cache will be delivered faster than it could be from your origin servers, even ignoring latency differences between the edge and the origin.

Whole Website

Using cache behaviors and multiple origins, you can easily use Amazon CloudFront to serve your whole website and to support different behaviors for different client devices.

Private Content

In many cases, you may want to restrict access to content in Amazon CloudFront only to selected requestors, such as paid subscribers or to applications or users in your company network. Amazon CloudFront provides several mechanisms to allow you to serve private content:

Signed URLs Use URLs that are valid only between certain times and optionally from certain IP addresses.

Signed cookies Require authentication via public and private key pairs.

Origin Access Identities (OAI) Restrict access to an Amazon S3 bucket only to a special Amazon CloudFront user associated with your distribution. This is the easiest way to ensure that content in a bucket is accessed only by Amazon CloudFront.

RTMP Distributions

RTMP distributions stream media files using Adobe Media Server and the Adobe RTMP. When using an RTMP distribution for Amazon CloudFront, you need to provide both your media files and a media player to your end users. Media player examples include JW Player, Flowplayer, and Adobe Flash.

End users will view your media files using the media player that you provide for them. They do not use the media player (if any) that is already installed on their computer or device. This is due in part to the fact that when the end user streams your media file, the media player begins to play the content of the file while the file is still being downloaded from Amazon CloudFront. The media file is not stored locally on the end user’s system.

To use Amazon CloudFront to serve media in this way, you need two types of distributions: a web distribution to serve the media player and an RTMP distribution for the media files. The web distribution will serve files over HTTP, while the RTMP distribution will stream media files over RTMP or a variant of RTMP.

Figure 7.4 shows that the media files and your media player are stored in different buckets in Amazon S3. You could also make the media player available to users in other ways, such as using Amazon CloudFront and a custom origin; however, the media files must use an Amazon S3 bucket at the origin.

Figure 7.4 also shows two separate buckets being used: one for your media files and the other for your media player. You can also store media files and your media player in the same Amazon S3 bucket (not shown in the figure).

In Figure 7.4, there are two distributions used for Amazon CloudFront streaming:

1. Your media player bucket holds the media player, and it is the origin server for a regular HTTP distribution. In this example, the domain name for the distribution is d1234.cloudfront.net. The d in d1234.cloudfront.net indicates that this is a web distribution.
2. Your streaming media bucket holds your media files, and it is the origin server for an RTMP distribution. In this example, the domain name for the distribution is  s5678.cloudfront.net. The s in s5678.cloudfront.net indicates that this is an RTMP distribution.

There are other streaming options available with Amazon CloudFront.

Wowza Streaming Engine 4.2 You can use the Wowza Streaming Engine 4.2 to create live streaming sessions for global delivery using Amazon CloudFront. Wowza Streaming Engine 4.2 supports the following HTTP-based streaming protocols:

• HLS
• HTTP Dynamic Streaming (HDS)
• Smooth Streaming
• MPEG Dynamic Adaptive Streaming over HTTP (DASH)

For these protocols, Amazon CloudFront will break video into smaller chunks that are cached in the Amazon CloudFront network for improved performance and scalability.

Live HTTP streaming using Amazon CloudFront and any HTTP origin Amazon CloudFront supports any live encoder, such as Elemental Live. The encoder must output HTTP-based streams to stream live performances, webinars, and other events.

On-demand video streaming using Amazon CloudFront and other media players When streaming media files using Amazon CloudFront, you provide both the media files and media player that you want end users to utilize to play the media file.

Alternate Domain Names

In Amazon CloudFront, an alternate domain name lets you use your own domain name (for example, www.example.com) for links to your objects instead of using the domain name that CloudFront assigns to your distribution. Both web and RTMP distributions support alternate domain names.

When you create a distribution, Amazon CloudFront returns a domain name for the distribution, for example: d111111abcdef8.cloudfront.net.

When you use the Amazon CloudFront domain name for your objects, the URL for an object called /images/image.jpg would be: http://d111111abcdef8.cloudfront.net/images/image.jpg.

If you want to use your own domain name, such as www.example.com, instead of the cloudfront.net domain name that Amazon CloudFront assigned to your distribution, you can add an alternate domain name to your distribution for www.example.com. You can then use the following URL for /images/image.jpg: http://www.example.com/images/image.jpg.

When you add alternate domain names, you can use the wildcard * at the beginning of a domain name instead of specifying subdomains individually. For example, with an alternative domain name of *.example.com, you can use any domain name that ends with example.com in your object URLs, such as www.example.com, product-name.example.com, and marketing.product-name.example.com.

Access Logs

Amazon CloudFront can create log files that contain detailed information about every user request that Amazon CloudFront receives. Access logs are available for both web and RTMP distributions. When you enable logging for your distribution, you specify the Amazon S3 bucket in which you want Amazon CloudFront to store log files.

You can store the log files for multiple distributions in the same bucket. When you enable logging, you can specify an optional prefix for the file names so that you can keep track of which log files are associated with which distributions.