Increasing the Proportion of Requests that Are Served from CloudFront Edge Caches
One of the purposes of using CloudFront is to reduce the number of requests that your origin server responds to. This reduces the load on your origin server and also reduces latency because more objects are served from CloudFront edge locations, which are closer to your users. The more requests that CloudFront is able to serve from edge caches as a proportion of all requests (the greater the cache hit ratio), the fewer requests that CloudFront needs to forward to your origin to get the latest version or a unique version of an object.
You can view the percentage of viewer requests that are hits, misses, and errors in the CloudFront console. For more information, see CloudFront Cache Statistics Reports in the Amazon CloudFront Developer Guide.
The following sections explain how to improve your cache hit ratio.
Specifying How Long CloudFront Caches Your Objects
To increase your cache hit ratio, you can configure your origin to add a
Cache-Control max-age directive to your objects, and specify the longest
practical value for
max-age. The shorter the cache duration, the more
frequently CloudFront forwards another request to your origin to determine whether the object has
changed and, if so, to get the latest version. For more information, see Specifying How Long Objects Stay in a CloudFront Edge Cache
Caching Based on Query String Parameters
If you configure CloudFront to cache based on query string parameters, you can improve caching if you do the following:
Configure CloudFront to forward only the query string parameters for which your origin will return unique objects.
Use the same case (uppercase or lowercase) for all instances of the same parameter. For example, if one request contains
parameter1=Aand another contains
parameter1=a, CloudFront forwards separate requests to your origin when a request contains
parameter1=Aand when a request contains
parameter1=a. CloudFront then separately caches the corresponding objects returned by your origin separately even if the objects are identical. If you use just
a, CloudFront forwards fewer requests to your origin.
List parameters in the same order. As with differences in case, if one request for an object contains the query string
parameter1=a¶meter2=band another request for the same object contains
parameter2=b¶meter1=a, CloudFront forwards both requests to your origin and separately caches the corresponding objects even if they're identical. If you always use the same order for parameters, CloudFront forwards fewer requests to your origin.
For more information, see Configuring CloudFront to Cache Based on Query String
Parameters. If you want to review the query strings that CloudFront
forwards to your origin, enable CloudFront access logs and see the values in the
cs-uri-query column of your log files. For more information, see Access Logs.
Caching Based on Cookie Values
If you configure CloudFront to cache based on cookie values, you can improve caching if you do the following:
Configure CloudFront to forward only specified cookies instead of forwarding all cookies. For the cookies that you configure CloudFront to forward to your origin, CloudFront forwards every combination of cookie name and value, and separately caches the objects that your origin returns, even if they're all identical.
For example, suppose that viewers include two cookies in every request, that each cookie has three possible values, and that all combinations of cookie values are possible. CloudFront forwards up to six different requests to your origin for each object. If your origin returns different versions of an object based on only one of the cookies, then CloudFront is forwarding more requests to your origin than necessary and is needlessly caching multiple identical versions of the object.
Create separate cache behaviors for static and dynamic content, and configure CloudFront to forward cookies to your origin only for dynamic content.
For example, suppose you have just one cache behavior for your distribution and that you're using the distribution both for dynamic content, such as .php files, and for .css files that rarely change. CloudFront caches separate versions of your .css files based on cookie values, so each CloudFront edge location forwards a request to your origin for every new cookie value or combination of cookie values.
If you create a cache behavior for which the path pattern is *.css and for which CloudFront doesn't cache based on cookie values, then CloudFront forwards requests for .css files to your origin only for the first request that an edge location receives for a given .css file and for the first request after a .css file expires.
If possible, create separate cache behaviors for dynamic content for which cookie values are unique for each user (such as a user ID) and dynamic content that varies based on a smaller number of unique values.
For more information, see Configuring CloudFront to Cache Objects Based on Cookies. If you want
to review the cookies that CloudFront forwards to your origin, enable CloudFront access logs and see the
values in the
cs(Cookie) column of your log files. For more information, see
Caching Based on Request Headers
If you configure CloudFront to cache based on request headers, you can improve caching if you do the following:
Configure CloudFront to forward and cache based only specified headers instead of forwarding and caching based on all headers. For the headers that you specify, CloudFront forwards every combination of header name and value and separately caches the objects that your origin returns even if they're all identical.
CloudFront always forwards to your origin the headers specified in the following topics:
How CloudFront Processes and Forwards Requests to Your Amazon S3 Origin Server > HTTP Request Headers That CloudFront Removes or Updates
How CloudFront Processes and Forwards Requests to Your Custom Origin Server > HTTP Request Headers and CloudFront Behavior
When you configure CloudFront to cache based on request headers, you don't change the headers that CloudFront forwards, only whether CloudFront caches objects based on the header values.
Try to avoid caching based on request headers that have large numbers of unique values.
For example, if you want to serve different sizes of an image based on the user's device, then don't configure CloudFront to cache based on the
User-Agentheader, which has an enormous number of possible values. Instead, configure CloudFront to cache based on the CloudFront device-type headers
CloudFront-Is-Tablet-Viewer. In addition, if you're returning the same version of the image for tablets and desktops, then forward only the
CloudFront-Is-Tablet-Viewerheader, not the
For more information, see Configuring CloudFront to Cache Objects Based on Request Headers.
Serving Media Content by Using HTTP
When you use HTTP to serve media content, we recommend that you use an HTTP-based dynamic streaming protocol such as Apple HTTP Dynamic Streaming (Apple HDS), Apple HTTP Live Streaming (Apple HLS), Microsoft Smooth Streaming, or MPEG-DASH. For dynamic-streaming protocols, a video is divided into a lot of small segments that are typically just a few seconds long each. If your users commonly stop watching before the end of a video (for example, because they close their viewer during the credits), CloudFront has still cached all of the small segments up to that point in the video. If you're using a protocol for which a video is served in a single, large file and a user stops watching before the end, CloudFront might not cache the entire video, and it might need to request the video from your origin again the next time that CloudFront receives a request for it.