# Add, remove, or replace content that CloudFront distributes
This section explains how to make sure CloudFront can access the content that you want to be served to your viewers, how to specify the objects in your website or in your application, and how to remove or replace content.
**Topics**
+ [
## Add and access content that CloudFront distributes
](#AddingObjects)
+ [
# Use file versioning to update or remove content with a CloudFront distribution
](UpdatingExistingObjects.md)
+ [
# Customize the URL format for files in CloudFront
](LinkFormat.md)
+ [
# Specify a default root object
](DefaultRootObject.md)
+ [
# Invalidate files to remove content
](Invalidation.md)
+ [
# Serve compressed files
](ServingCompressedFiles.md)
## Add and access content that CloudFront distributes
When you want CloudFront to distribute content (objects), you add files to one of the origins that you specified for the distribution, and you expose a CloudFront link to the files. A CloudFront edge location doesn't fetch the new files from an origin until the edge location receives viewer requests for them. For more information, see [How CloudFront delivers content](HowCloudFrontWorks.md).
When you add a file that you want CloudFront to distribute, make sure that you add it to one of the Amazon S3 buckets specified in your distribution or, for a custom origin, to a directory in the specified domain. In addition, confirm that the path pattern in the applicable cache behavior sends requests to the correct origin.
For example, suppose the path pattern for a cache behavior is `*.html`. If you don't have any other cache behaviors configured to forward requests to that origin, CloudFront will only forward `*.html` files. In this scenario, for example, CloudFront will never distribute .jpg files that you upload to the origin, because you haven't created a cache behavior that includes .jpg files.
CloudFront servers don't determine the MIME type for the objects that they serve. When you upload a file to your origin, we recommend that you set the `Content-Type` header field for it.
# Use file versioning to update or remove content with a CloudFront distribution
To update existing content that CloudFront is set up to distribute for you, we recommend that you use a version identifier in file names or in folder names. This helps give you control over managing the content that CloudFront serves.
## Update existing files using versioned file names
When you update existing files in a CloudFront distribution, we recommend that you include some sort of version identifier either in your file names or in your directory names to give yourself better control over your content. This identifier might be a date-time stamp, a sequential number, or some other method of distinguishing two versions of the same object.
For example, instead of naming a graphic file image.jpg, you might call it image\$11.jpg. When you want to start serving a new version of the file, you'd name the new file image\$12.jpg, and you'd update the links in your web application or website to point to image\$12.jpg. Alternatively, you might put all graphics in an images\$1v1 directory and, when you want to start serving new versions of one or more graphics, you'd create a new images\$1v2 directory, and you'd update your links to point to that directory. With versioning, you don't have to wait for an object to expire before CloudFront begins to serve a new version of it, and you don't have to pay for object invalidation.
Even if you version your files, we still recommend that you set an expiration date. For more information, see [Manage how long content stays in the cache (expiration)](Expiration.md).
**Note**
Specifying versioned file names or directory names is not related to Amazon S3 object versioning.
## Remove content so CloudFront won’t distribute it
You can remove files from your origin that you no longer want to be included in your CloudFront distribution. However, CloudFront will continue to show viewers content from the edge cache until the files expire.
If you want to remove a file right away, you must do one of the following:
+ **Use file versioning.** When you use versioning, different versions of a file have different names that you can use in your CloudFront distribution, to change which file is returned to viewers. For more information, see [Update existing files using versioned file names](#ReplacingObjects).
+ **Invalidate the file.** For more information, see [Invalidate files to remove content](Invalidation.md).
# Customize the URL format for files in CloudFront
After you set up your origin with the objects (content) that you want CloudFront to serve to your viewers, you must use the correct URLs to reference those objects in your website or application code so that CloudFront can serve it.
The domain name that you use in the URLs for objects on your web pages or in your web application can be either of the following:
+ The domain name, such as `d111111abcdef8.cloudfront.net`, that CloudFront automatically assigns when you create a distribution
+ Your own domain name, such as `example.com`
For example, you might use one of the following URLs to return the file `image.jpg`:
`https://d111111abcdef8.cloudfront.net/images/image.jpg`
`https://example.com/images/image.jpg`
You use the same URL format whether you store the content in Amazon S3 buckets or at a custom origin, like one of your own web servers.
**Note**
The URL format depends in part on the value that you specify for **Origin Path** in your distribution. This value gives CloudFront a top directory path for your objects. For more information about setting the origin path when you create a distribution, see [Origin path](DownloadDistValuesOrigin.md#DownloadDistValuesOriginPath).
For more information about URL formats, see the following sections.
## Use your own domain name (example.com)
Instead of using the default domain name that CloudFront assigns for you when you create a distribution, you can [add an alternate domain name](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesCNAME) that's easier to work with, like `example.com`. By setting up your own domain name with CloudFront, you can use a URL like this for objects in your distribution:
`https://example.com/images/image.jpg`
If you plan to use HTTPS between viewers and CloudFront, see [Use alternate domain names and HTTPS](using-https-alternate-domain-names.md).
## Use a trailing slash (/) in URLs
When you specify URLs for directories in your CloudFront distribution, choose either to always use a trailing slash or to never use a trailing slash. For example, choose only one of the following formats for all of your URLs:
`https://d111111abcdef8.cloudfront.net/images/`
`https://d111111abcdef8.cloudfront.net/images`
**Why does it matter?**
Both formats work to link to CloudFront objects, but being consistent can help prevent issues when you want to invalidate a directory later. CloudFront stores URLs exactly as they are defined, including trailing slashes. So if your format is inconsistent, you'll need to invalidate directory URLs with and without the slash, to ensure that CloudFront removes the directory.
It’s inconvenient to have to invalidate both URL formats, and it can lead to additional costs. That’s because if you must double up invalidations to cover both types of URLs, you might exceed the maximum number of free invalidations allowed for the month. And if that happens, you'll have to pay for all the invalidations, even if only one format for each directory URL exists in CloudFront.
## Create signed URLs for restricted content
If you have content that you want to restrict access to, you can create signed URLs. For example, if you want to distribute your content only to users who have authenticated, you can create URLs that are valid only for a specified time period or that are available only from a specified IP address. For more information, see [Serve private content with signed URLs and signed cookies](PrivateContent.md).
# Specify a default root object
You can configure CloudFront to return a specific object (the default root object) when a user (viewer) requests the root URL for your distribution instead of requesting an object in your distribution. You can use a default root object to avoid exposing the contents of your distribution.
**Contents**
+ [
## How to specify a default root object
](#DefaultRootObjectHowToDefine)
+ [
## How default root object works
](#DefaultRootObjectHow)
+ [
## How CloudFront works if you don’t define a root object
](#DefaultRootObjectNotSet)
## How to specify a default root object
To avoid exposing the contents of your distribution or returning an error, specify a default root object for your distribution. You can specify the exact file name or the path to the file. For example, if your root object is an `index.html` file, you can specify that file name. If your `index.html` file is in another folder, specify the path instead such as `exampleFolderName/index.html`. If you set a path to the default root object, viewer requests to the root URL of the distribution will return the specified file from that path. You can use a file path to have more flexibility to organize your content at the origin, as your default root object can be in a folder instead of at the root level.
**To specify a default root object for your distribution**
1. Upload the default root object to the origin that your distribution points to.
The file can be any type supported by CloudFront. For a list of constraints on the file name, see the `DefaultRootObject` element in [DistributionConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DistributionConfig.html) of the *Amazon CloudFront API Reference*.
**Note**
If the file name of the default root object is too long or contains an invalid character, CloudFront returns the error `HTTP 400 Bad Request - InvalidDefaultRootObject`. In addition, CloudFront caches the code for 10 seconds (by default) and writes the results to the access logs.
1. Confirm that the permissions for the object grant CloudFront at least read access.
For more information about Amazon S3 permissions, see [Identity and access management in Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html) in the *Amazon Simple Storage Service User Guide*.
1. Update your distribution to refer to the default root object by using the CloudFront console or the CloudFront API.
To specify a default root object by using the CloudFront console:
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. In the list of distributions in the top pane, select the distribution to update.
1. In the **Settings** pane, on the **General** tab, choose **Edit**.
1. In the **Edit settings** dialog box, in the **Default root object** field, enter the file name or path to the default root object.
**Tip**
Your string can't begin with a forward slash (`/`). Only specify the object name or the path to the object. For example, use `index.html` or `exampleFolderName/index.html`. Specifying a `/exampleFolderName/index.html` or `/index.html` can lead to a [403 Access Denied error](http-403-permission-denied.md).
1. Choose **Save changes**.
To update your configuration using the CloudFront API, specify a value for the `DefaultRootObject` element in your distribution. For information about using the CloudFront API to specify a default root object, see [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) in the *Amazon CloudFront API Reference*.
1. Confirm that you have enabled the default root object by requesting your root URL. If your browser doesn't display the default root object, perform the following steps:
1. Confirm that your distribution is fully deployed by viewing the status of your distribution in the CloudFront console.
1. Repeat steps 2 and 3 to verify that you granted the correct permissions and that you correctly updated the configuration of your distribution to specify the default root object.
## How default root object works
Suppose the following request points to the object `image.jpg`:
`https://d111111abcdef8.cloudfront.net/image.jpg`
In contrast, the following request points to the root URL of the same distribution instead of to a specific object, as in the first example:
`https://d111111abcdef8.cloudfront.net/`
When you define a default root object, an end-user request that calls the root of your distribution returns the default root object. For example, if you designate the file `index.html` as your default root object, a request for:
`https://d111111abcdef8.cloudfront.net/`
Returns:
`https://d111111abcdef8.cloudfront.net/index.html`
**Note**
CloudFront does not determine whether a URL with multiple trailing slashes (`https://d111111abcdef8.cloudfront.net///`) is equivalent to `https://d111111abcdef8.cloudfront.net/`. Your origin server makes that comparison.
If you define a default root object, an end-user request for a subdirectory of your distribution does not return the default root object. For example, suppose `index.html` is your default root object and that CloudFront receives an end-user request for the `install` directory under your CloudFront distribution:
`https://d111111abcdef8.cloudfront.net/install/`
CloudFront does not return the default root object even if a copy of `index.html` appears in the `install` directory. However, if you specified a *path* to your default root object, (`install/index.html`)CloudFront will return the default root object for end-user requests for the `install` directory
If you configure your distribution to allow all of the HTTP methods that CloudFront supports, the default root object applies to all methods. For example, if your default root object is index.php and you write your application to submit a `POST` request to the root of your domain (https://example.com), CloudFront sends the request to https://example.com/index.php.
The behavior of CloudFront default root objects is different from the behavior of Amazon S3 index documents. When you configure an Amazon S3 bucket as a website and specify the index document, Amazon S3 returns the index document even if a user requests a subdirectory in the bucket. (A copy of the index document must appear in every subdirectory.) For more information about configuring Amazon S3 buckets as websites and about index documents, see the [Hosting Websites on Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteHosting.html) chapter in the *Amazon Simple Storage Service User Guide*.
**Important**
Remember that a default root object applies only to your CloudFront distribution. You still need to manage security for your origin. For example, if you are using an Amazon S3 origin, you still need to set your Amazon S3 bucket ACLs appropriately to ensure the level of access you want on your bucket.
## How CloudFront works if you don’t define a root object
If you don't define a default root object, requests for the root of your distribution pass to your origin server. If you are using an Amazon S3 origin, any of the following might be returned:
+ **A list of the contents of your Amazon S3 bucket** – Under any of the following conditions, the contents of your origin are visible to anyone who uses CloudFront to access your distribution:
+ Your bucket is not properly configured.
+ The Amazon S3 permissions on the bucket associated with your distribution and on the objects in the bucket grant access to *everyone*.
+ An end user accesses your origin using your origin root URL.
+ **A list of the private contents of your origin** – If you configure your origin as a private distribution (only you and CloudFront have access), the contents of the Amazon S3 bucket associated with your distribution are visible to anyone who has the credentials to access your distribution through CloudFront. In this case, users are not able to access your content through your origin root URL. For more information about distributing private content, see [Serve private content with signed URLs and signed cookies](PrivateContent.md).
+ `Error 403 Forbidden`—CloudFront returns this error if the permissions on the Amazon S3 bucket associated with your distribution or the permissions on the objects in that bucket deny access to CloudFront and to everyone.
# Invalidate files to remove content
If you need to remove a file from CloudFront edge caches before it expires, you can do one of the following:
+ Invalidate the file from edge caches. The next time a viewer requests the file, CloudFront returns to the origin to fetch the latest version of the file.
+ Use file versioning to serve a different version of the file that has a different name. For more information, see [Update existing files using versioned file names](UpdatingExistingObjects.md#ReplacingObjects).
**Topics**
+ [
## Choose between invalidating files and using versioned file names
](#Invalidation_Expiration)
+ [
# Determine which files to invalidate
](invalidation-access-logs.md)
+ [
# What you need to know when invalidating files
](invalidation-specifying-objects.md)
+ [
# Invalidate files
](Invalidation_Requests.md)
+ [
# Concurrent invalidation request maximum
](InvalidationLimits.md)
+ [
# Pay for file invalidation
](PayingForInvalidation.md)
## Choose between invalidating files and using versioned file names
To control the versions of files that are served from your distribution, you can either invalidate files or give them versioned file names. If you want to update your files frequently, we recommend that you primarily use file versioning for the following reasons:
+ Versioning enables you to control which file a request returns even when the user has a version cached either locally or behind a corporate caching proxy. If you invalidate the file, the user might continue to see the old version until it expires from those caches.
+ CloudFront access logs include the names of your files, so versioning makes it easier to analyze the results of file changes.
+ Versioning provides a way to serve different versions of files to different users.
+ Versioning simplifies rolling forward and back between file revisions.
+ Versioning is less expensive. You still have to pay for CloudFront to transfer new versions of your files to edge locations, but you don't have to pay for invalidating files.
For more information about file versioning, see [Update existing files using versioned file names](UpdatingExistingObjects.md#ReplacingObjects).
# Determine which files to invalidate
If you want to invalidate multiple files such as all of the files in a directory or all files that begin with the same characters, you can include the `*` wildcard at the end of the invalidation path. For more information about using the `*` wildcard, see [Invalidation paths](invalidation-specifying-objects.md#invalidation-specifying-objects-paths).
To invalidate files, you can specify either the path for individual files or a path that ends with the `*` wildcard, which might apply to one file or to many, as shown in the following examples:
+ `/images/image1.jpg`
+ `/images/image*`
+ `/images/*`
If you want to invalidate selected files but your users don’t necessarily access every file on your origin, you can determine which files viewers have requested from CloudFront and invalidate only those files. To determine which files viewers have requested, enable CloudFront access logging. For more information about access logs, see [Access logs (standard logs)](AccessLogs.md).
# What you need to know when invalidating files
When you specify a file to invalidate, refer to the following information:
**Case sensitivity**
Invalidation paths are case sensitive. For example, `/images/image.jpg` and `/images/Image.jpg` specify two different files.
**Changing the URI by using a Lambda function**
If your CloudFront distribution triggers a Lambda function on viewer request events, and if the function changes the URI of the requested file, we recommend that you invalidate both URIs to remove the file from CloudFront edge caches:
+ The URI in the viewer request
+ The URI after the function changed it
**Example**
Suppose your Lambda function changes the URI for a file from:
`https://d111111abcdef8.cloudfront.net/index.html`
To a URI that includes a language directory:
`https://d111111abcdef8.cloudfront.net/en/index.html`
To invalidate the file, you must specify the following paths:
+ `/index.html`
+ `/en/index.html`
For more information, see [Invalidation paths](#invalidation-specifying-objects-paths).
**Default root object**
To invalidate the default root object (file), specify the path the same way that you specify the path for any other file. For more information, see [How default root object works](DefaultRootObject.md#DefaultRootObjectHow).
**Forwarding cookies**
If you configured CloudFront to forward cookies to your origin, CloudFront edge caches might contain several versions of the file. When you invalidate a file, CloudFront invalidates every cached version of the file regardless of its associated cookies. You can’t selectively invalidate some versions and not others based on the associated cookies. For more information, see [Cache content based on cookies](Cookies.md).
**Forwarding headers**
If you configured CloudFront to forward a list of headers to your origin and to cache based on the values of the headers, CloudFront edge caches might contain several versions of the file. When you invalidate a file, CloudFront invalidates every cached version of the file regardless of the header values. You can’t selectively invalidate some versions and not others based on header values. (If you configure CloudFront to forward all headers to your origin, CloudFront doesn't cache your files.) For more information, see [Cache content based on request headers](header-caching.md).
**Forwarding query strings**
If you configured CloudFront to forward query strings to your origin, you must include the query strings when invalidating files, as shown in the following examples:
+ `/images/image.jpg?parameter1=a`
+ `/images/image.jpg?parameter1=b`
If client requests include five different query strings for the same file, you can either invalidate the file five times, once for each query string, or you can use the \$1 wildcard in the invalidation path, as shown in the following example:
`/images/image.jpg*`
For more information about using wildcards in the invalidation path, see [Invalidation paths](#invalidation-specifying-objects-paths).
For more information about query strings, see [Cache content based on query string parameters](QueryStringParameters.md).
To determine which query strings are in use, you can enable CloudFront logging. For more information, see [Access logs (standard logs)](AccessLogs.md).
**Maximum allowed**
For more information about the maximum number of invalidations allowed, see [Concurrent invalidation request maximum](InvalidationLimits.md).
**Microsoft Smooth Streaming files**
You can't invalidate media files in the Microsoft Smooth Streaming format when you have enabled Smooth Streaming for the corresponding cache behavior.
**Non-ASCII or unsafe characters in the path**
If the path includes non-ASCII characters or unsafe characters as defined in [RFC 1738](https://tools.ietf.org/html/rfc1738), URL-encode those characters. Don't URL-encode any other characters in the path, or CloudFront won't invalidate the old version of the updated file.
Don't use the `~` character in your path. CloudFront doesn't support this character for invalidations, whether it's URL-encoded or not.
**Invalidation paths**
The path is relative to the distribution. For example, to invalidate the file at `https://d111111abcdef8.cloudfront.net/images/image2.jpg`, you would specify `/images/image2.jpg`.
In the [CloudFront console](https://console.aws.amazon.com/cloudfront/v4/home), you can omit the leading slash in the path, like this: `images/image2.jpg`. When you use the CloudFront API directly, invalidation paths must begin with a leading slash.
You can also invalidate multiple files simultaneously by using the `*` wildcard. The `*`, which replaces 0 or more characters, must be the last character in the invalidation path.
To use wildcards (\$1) in the invalidation, you must put the wildcard at the end of the path. Asterisks (\$1) inserted anywhere else are treated as a literal character match instead of a wildcard invalidation.
If you use the AWS Command Line Interface (AWS CLI) to invalidate files and you specify a path that includes the `*` wildcard, you must use quotes (`"`) around the path like `"/*"`.
The maximum length of a path is 4,000 characters.
**Example: Invalidation paths**
+ To invalidate all files in a directory:
`/`*directory-path*`/*`
+ To invalidate a directory, all of its subdirectories, and all files in the directory and subdirectories:
`/`*directory-path*`*`
+ To invalidate all files that have the same name but different file name extensions, such as logo.jpg, logo.png, and logo.gif:
`/`*directory-path*`/`*file-name*`.*`
+ To invalidate all of the files in a directory for which the file name starts with the same characters (such as all of the files for a video in HLS format), regardless of the file name extension:
`/`*directory-path*`/`*initial-characters-in-file-name*`*`
+ When you configure CloudFront to cache based on query string parameters and you want to invalidate every version of a file:
`/`*directory-path*`/`*file-name*`.`*file-name-extension*`*`
+ To invalidate all files in a distribution:
`/*`
For information about invalidating files if you use a Lambda function to change the URI, see [Changing the URI Using a Lambda Function](#invalidation-lambda-at-edge).
If the invalidation path is a directory and if you have not standardized on a method for specifying directories—with or without a trailing slash (/)—we recommend that you invalidate the directory both with and without a trailing slash, for example, `/images` and `/images/`.
**Signed URLs**
If you are using signed URLs, invalidate a file by including only the portion of the URL before the question mark (?).
# Invalidate files
You can use the CloudFront console to create and run an invalidation, display a list of the invalidations that you submitted previously, and display detailed information about an individual invalidation. You can also copy an existing invalidation, edit the list of file paths, and run the edited invalidation. You can't remove invalidations from the list.
**Contents**
+ [
## Invalidate files
](#invalidating-objects-console)
+ [
## Copy, edit, and rerun an existing invalidation
](#invalidating-objects-copy-console)
+ [
## Cancel invalidations
](#canceling-invalidations)
+ [
## List invalidations
](#listing-invalidations-console)
+ [
## Display information about an invalidation
](#invalidation-details-console)
## Invalidate files
To invalidate files using the CloudFront console, do the following.
------
#### [ Console ]
**To invalidate files (console)**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Choose the distribution for which you want to invalidate files.
1. Choose the **Invalidations** tab.
1. Choose **Create invalidation**.
1. For the files that you want to invalidate, enter one invalidation path per line. For information about specifying invalidation paths, see [What you need to know when invalidating files](invalidation-specifying-objects.md).
**Important**
Specify file paths carefully. You can’t cancel an invalidation request after you start it.
1. Choose **Create invalidation**.
------
#### [ CloudFront API ]
To learn about invalidating objects and displaying information about invalidations, see the following topics in the *Amazon CloudFront API Reference*:
+ [CreateInvalidation](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateInvalidation.html)
+ [ListInvalidations](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListInvalidations.html)
+ [GetInvalidation](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_GetInvalidation.html)
**Note**
If you use the AWS Command Line Interface (AWS CLI) to invalidate files and you specify a path that includes the `*` wildcard, you must use quotes (`"`) around the path, such as the following example:
```
aws cloudfront create-invalidation --distribution-id distribution_ID --paths "/*"
```
------
## Copy, edit, and rerun an existing invalidation
You can copy an invalidation that you created previously, update the list of invalidation paths, and run the updated invalidation. You can't copy an existing invalidation, update the invalidation paths, and then save the updated invalidation without running it.
**Important**
If you copy an invalidation that is still in progress, update the list of invalidation paths, and then run the updated invalidation, CloudFront won't stop or delete the invalidation that you copied. If any invalidation paths appear in the original and in the copy, CloudFront will try to invalidate the files twice, and both invalidations will count against your maximum number of free invalidations for the month. If you already reached the maximum number of free invalidations, you will be charged for both invalidations of each file. For more information, see [Concurrent invalidation request maximum](InvalidationLimits.md).
**To copy, edit, and rerun an existing invalidation**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Select the distribution that contains the invalidation that you want to copy.
1. Choose the **Invalidations** tab.
1. Choose the invalidation that you want to copy.
If you aren’t sure which invalidation you want to copy, you can choose an invalidation and choose **View details** to display detailed information about that invalidation.
1. Choose **Copy to new**.
1. Update the list of invalidation paths if applicable.
1. Choose **Create invalidation**.
## Cancel invalidations
When you submit an invalidation request to CloudFront, CloudFront forwards the request to all edge locations within a few seconds, and each edge location starts processing the invalidation immediately. As a result, you can’t cancel an invalidation after you submit it.
## List invalidations
You can display a list of the last 100 invalidations that you’ve created and run for a distribution by using the CloudFront console. If you want to get a list of more than 100 invalidations, use the `ListInvalidations` API operation. For more information, see [ListInvalidations](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListInvalidations.html) in the *Amazon CloudFront API Reference*.
**To list invalidations**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Select the distribution for which you want to display a list of invalidations.
1. Choose the **Invalidations** tab.
**Note**
You can’t remove invalidations from the list.
## Display information about an invalidation
You can display detailed information about an invalidation, including distribution ID, invalidation ID, the status of the invalidation, the date and time that the invalidation was created, and a complete list of the invalidation paths.
**To display information about an invalidation**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Select the distribution that contains the invalidation that you want to display detailed information for.
1. Choose the **Invalidations** tab.
1. Choose the applicable invalidation ID or select the invalidation ID and then choose **View details**.
# Concurrent invalidation request maximum
If you’re invalidating files individually, you can have invalidation requests for up to 3,000 files per distribution in progress at one time. This can be one invalidation request for up to 3,000 files, up to 3,000 requests for one file each, or any other combination that doesn’t exceed 3,000 files. For example, you can submit 30 invalidation requests that invalidate 100 files each. As long as all 30 invalidation requests are still in progress, you can’t submit any more invalidation requests. If you exceed the maximum, CloudFront returns an error message.
If you’re using the \$1 wildcard, you can have requests for up to 15 invalidation paths in progress at one time. You can also have invalidation requests for up to 3,000 individual files per distribution in progress at the same time; the maximum on wildcard invalidation requests allowed is independent of the maximum on invalidating files individually.
# Pay for file invalidation
The first 1,000 invalidation paths that you submit per month are free; you pay for each invalidation path over 1,000 in a month. An invalidation path can be for a single file (such as `/images/logo.jpg`) or for multiple files (such as `/images/*`). A path that includes the `*` wildcard counts as one path even if it causes CloudFront to invalidate thousands of files.
The maximum of 1,000 free invalidation paths per month applies to the total number of invalidation paths across all of the distributions that you create with one AWS account. For example, if you use the AWS account `john@example.com` to create three distributions, and you submit 600 invalidation paths for *each distribution* in a given month (for a total of 1,800 invalidation paths), AWS will charge you for the difference between the total invalidation paths and the 1000 free limit. In this example, AWS would charge you for 800 invalidation paths in that month.
The charge to submit an invalidation path is the same regardless of the number of files you’re invalidating: a single file (`/images/logo.jpg`) or all of the files that are associated with a distribution (`/*`). Because you're charged per path in your invalidation request, even if you bundle multiple paths into a single request, each path is still counted individually for billing purposes.
For more information about invalidation pricing, see [Amazon CloudFront Pricing](https://aws.amazon.com/cloudfront/pricing/). For more information about invalidation paths, see [Invalidation paths](invalidation-specifying-objects.md#invalidation-specifying-objects-paths).
# Serve compressed files
When requested objects are compressed, downloads can be faster because the objects are smaller—in some cases, less than a quarter the size of the original. Faster downloads can result in faster rendering of webpages for your viewers, especially for JavaScript and CSS files. In addition, the cost of CloudFront data transfer is based on the total amount of data served. Serving compressed objects can be less expensive than serving them uncompressed.
**Topics**
+ [
## Configure CloudFront to compress objects
](#compressed-content-cloudfront-configuring)
+ [
## How CloudFront compression works
](#compressed-content-cloudfront-how-it-works)
+ [
## Conditions for compression
](#compressed-content-cloudfront-notes)
+ [
## File types that CloudFront compresses
](#compressed-content-cloudfront-file-types)
+ [
## `ETag` header conversion
](#compressed-content-cloudfront-etag-header)
## Configure CloudFront to compress objects
To configure CloudFront to compress objects, update the cache behavior that you want to serve the compressed objects.
**To configure CloudFront to compress objects (console)**
1. Sign in to the [CloudFront console](https://console.aws.amazon.com/cloudfront/v4/home).
1. Choose your distribution and then choose the **Behavior** to edit.
1. For the **Compress objects automatically** setting, choose **Yes**.
1. Use a [cache policy](controlling-the-cache-key.md) to specify the caching settings, and enable both **Gzip** and **Brotli** compression formats.
**Notes**
You must use [cache policies](controlling-the-cache-key.md) to use Brotli compression. Brotli doesn't support legacy cache settings.
To enable compression by using [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-cachebehavior.html) or the [CloudFront](https://docs.aws.amazon.com/cloudfront/latest/APIReference/Welcome.html) API, set the `Compress`, `EnableAcceptEncodingGzip`, `EnableAcceptEncodingBrotli` parameters to `true`.
To understand how CloudFront compresses objects, see the following section.
## How CloudFront compression works
1. A viewer requests an object. The viewer includes the `Accept-Encoding` HTTP header in the request, and the header value includes `gzip`, `br`, or both. This indicates that the viewer supports compressed objects. When the viewer supports both Gzip and Brotli, CloudFront uses Brotli.
**Note**
Chrome and Firefox web browsers support Brotli compression only when the request is sent using HTTPS. They don't support Brotli with HTTP requests.
1. At the edge location, CloudFront checks the cache for a compressed copy of the requested object.
1. Depending whether the compressed object is in the cache or not, CloudFront does one of the following:
+ If the compressed object is already in the cache, CloudFront sends the object to the viewer and skips the remaining steps.
+ If the compressed object isn't in the cache, CloudFront forwards the request to the origin.
**Note**
If an uncompressed copy of the object is already in the cache, CloudFront might send it to the viewer without forwarding the request to the origin. For example, this can happen when CloudFront [previously skipped compression](#compression-skipped). When this happens, CloudFront caches the uncompressed object and continues to serve it until the object expires, is evicted, or is invalidated.
1. If the origin returns a compressed object, (as indicated by the `Content-Encoding` header in the HTTP response), CloudFront sends the compressed object to the viewer, adds it to the cache, and skips the remaining steps. CloudFront doesn’t compress the object again.
1. If the origin returns an uncompressed object to CloudFront without the `Content-Encoding` header in the HTTP response, CloudFront then determines whether the object can be compressed. For more information, see [Conditions for compression](#compressed-content-cloudfront-notes).
1. If the object can be compressed, CloudFront compresses it, sends it to the viewer, and then adds it to the cache.
1. If there are subsequent viewer requests for the same object, CloudFront returns the first cached version. For example, if a viewer requests a specific cached object that uses Gzip compression, and the viewer *accepts* the Gzip format, subsequent requests to the same object will always return the Gzip version, even if the viewer accepts both Brotli and Gzip.
Some custom origins can also compress objects. Your origin might be able to compress objects that CloudFront doesn’t compress. For more information, see [File types that CloudFront compresses](#compressed-content-cloudfront-file-types).
## Conditions for compression
The following list provides more information about scenarios in which CloudFront doesn't compress objects.
**Request uses HTTP 1.0**
If a request to CloudFront uses HTTP 1.0, CloudFront removes the `Accept-Encoding` header and doesn't compress the object in the response.
**`Accept-Encoding` request header**
If the `Accept-Encoding` header is missing from the viewer request, or if it doesn’t contain `gzip` or `br` as a value, CloudFront doesn't compress the object in the response. If the `Accept-Encoding` header includes additional values such as `deflate`, CloudFront removes them before forwarding the request to the origin.
When CloudFront is [configured to compress objects](#compressed-content-cloudfront-configuring), it includes the `Accept-Encoding` header in the cache key and in origin requests automatically.
**Content is already cached when you configure CloudFront to compress objects**
CloudFront compresses objects when it gets them from the origin. When you configure CloudFront to compress objects, CloudFront doesn’t compress objects that are already cached in edge locations. In addition, when a cached object expires in an edge location and CloudFront forwards another request for the object to your origin, CloudFront doesn’t compress the object when your origin returns an HTTP status code 304. This means that the edge location already has the latest version of the object. If you want CloudFront to compress objects that are already cached in edge locations, you need to invalidate those objects. For more information, see [Invalidate files to remove content](Invalidation.md).
**Origin is already configured to compress objects**
If you configure CloudFront to compress objects and the origin also compresses objects, the origin should include a `Content-Encoding` header. This header indicates to CloudFront that the object is already compressed. When a response from an origin includes the `Content-Encoding` header, CloudFront doesn't compress the object, regardless of the header’s value. CloudFront sends the response to the viewer and caches the object in the edge location.
**File types that CloudFront compresses**
For a complete list, see [File types that CloudFront compresses](#compressed-content-cloudfront-file-types).
**Size of objects that CloudFront compresses**
CloudFront compresses objects that are between 1,000 bytes and 10,000,000 bytes in size.
**`Content-Length` header**
The origin must include a `Content-Length` header in the response, which CloudFront uses to determine whether the size of the object is in the range that CloudFront compresses. If the `Content-Length` header is missing, contains an invalid value, or contains a value outside the range of sizes that CloudFront compresses, CloudFront doesn't compress the object. For more information about how CloudFront processes large objects that can exceed the size range, see [How CloudFront processes partial requests for an object (range GETs)](RangeGETs.md).
**HTTP status code of the response**
CloudFront compresses objects only when the HTTP status code of the response is `200`, `403`, or `404`.
**Response has no body**
When the HTTP response from the origin has no body, there is nothing for CloudFront to compress.
**`ETag` header**
CloudFront sometimes modifies the `ETag` header in the HTTP response when it compresses objects. For more information, see [`ETag` header conversion](#compressed-content-cloudfront-etag-header).
**CloudFront skips compression**
CloudFront compresses objects on a best-effort basis. In rare cases, CloudFront skips compressing an object when CloudFront experiences high traffic load. CloudFront makes this decision based on a variety of factors, including host capacity. If CloudFront skips compression for an object, it caches the uncompressed object and continues to serve it to viewers until the object expires, is evicted, or is invalidated.
## File types that CloudFront compresses
If you configure CloudFront to compress objects, CloudFront only compresses objects that have one of the following values in the `Content-Type` response header:
+ `application/dash+xml`
+ `application/eot`
+ `application/font`
+ `application/font-sfnt`
+ `application/javascript`
+ `application/json`
+ `application/opentype`
+ `application/otf`
+ `application/pdf`
+ `application/pkcs7-mime`
+ `application/protobuf`
+ `application/rss+xml`
+ `application/truetype`
+ `application/ttf`
+ `application/vnd.apple.mpegurl`
+ `application/vnd.mapbox-vector-tile`
+ `application/vnd.ms-fontobject`
+ `application/wasm`
+ `application/xhtml+xml`
+ `application/xml`
+ `application/x-font-opentype`
+ `application/x-font-truetype`
+ `application/x-font-ttf`
+ `application/x-httpd-cgi`
+ `application/x-javascript`
+ `application/x-mpegurl`
+ `application/x-opentype`
+ `application/x-otf`
+ `application/x-perl`
+ `application/x-ttf`
+ `font/eot`
+ `font/opentype`
+ `font/otf`
+ `font/ttf`
+ `image/svg+xml`
+ `text/css`
+ `text/csv`
+ `text/html`
+ `text/javascript`
+ `text/js`
+ `text/plain`
+ `text/richtext`
+ `text/tab-separated-values`
+ `text/xml`
+ `text/x-component`
+ `text/x-java-source`
+ `text/x-script`
+ `vnd.apple.mpegurl`
## `ETag` header conversion
When the uncompressed object from the origin includes a valid, strong `ETag` HTTP header, and CloudFront compresses the object, CloudFront also converts the strong `ETag` header value to a weak `ETag`, and returns the weak `ETag` value to the viewer. Viewers can store the weak `ETag` value and use it to send conditional requests with the `If-None-Match` HTTP header. This allows viewers, CloudFront, and the origin to treat the compressed and uncompressed versions of an object as semantically equivalent, which reduces unnecessary data transfer.
A valid, strong `ETag` header value begins and ends with a double quote character (`"`). To convert the strong `ETag` value to a weak one, CloudFront adds the characters `W/` to the beginning of the strong `ETag` value.
When the object from the origin includes a weak `ETag` header value (a value that begins with the characters `W/`), CloudFront does not modify this value, and returns it to the viewer as received from the origin.
When the object from the origin includes an invalid `ETag` header value (the value does not begin with `"` or with `W/`), CloudFront removes the `ETag` header and returns the object to the viewer without the `ETag` response header.
For more information, see the following pages in the MDN web docs:
+ [Directives](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag#Directives) (`ETag` HTTP header)
+ [Weak validation](https://developer.mozilla.org/en-US/docs/Web/HTTP/Conditional_requests#Weak_validation) (HTTP conditional requests)
+ [If-None-Match HTTP header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-None-Match)