# All distribution settings reference
You can choose to manually edit your CloudFront distribution settings when you create or update your distribution. Following are the settings that you can edit.
However, CloudFront configures most distribution settings for you, based on your content origin type. For more information, see [Preconfigured distribution settings reference](template-preconfigured-origin-settings.md).
For more information about creating or updating a distribution by using the CloudFront console, see [Create a distribution](distribution-web-creating-console.md) or [Update a distribution](HowToUpdateDistribution.md).
**Topics**
+ [Origin settings](DownloadDistValuesOrigin.md)
+ [Cache behavior settings](DownloadDistValuesCacheBehavior.md)
+ [Distribution settings](DownloadDistValuesGeneral.md)
+ [Custom error pages and error caching](DownloadDistValuesErrorPages.md)
+ [Geographic restrictions](DownloadDistValuesEnableGeoRestriction.md)
# Origin settings
When you use the CloudFront console to create or update a distribution, you provide information about one or more locations, known as *origins*, where you store the original versions of your web content. CloudFront gets your web content from your origins and serves it to viewers via a worldwide network of edge servers.
For the current maximum number of origins that you can create for a distribution, or to request a higher quota, see [General quotas on distributions](cloudfront-limits.md#limits-web-distributions).
If you want to delete an origin, you must first edit or delete the cache behaviors that are associated with that origin.
**Important**
If you delete an origin, confirm that files that were previously served by that origin are available in another origin and that your cache behaviors are now routing requests for those files to the new origin.
When you create or update a distribution, you specify the following values for each origin.
**Topics**
+ [Origin domain](#DownloadDistValuesDomainName)
+ [Protocol (custom origins only)](#DownloadDistValuesOriginProtocolPolicy)
+ [Origin path](#DownloadDistValuesOriginPath)
+ [Name](#DownloadDistValuesId)
+ [Origin access (Amazon S3 origins only)](#DownloadDistValuesOAIRestrictBucketAccess)
+ [Add custom header](#DownloadDistValuesOriginCustomHeaders)
+ [Enable Origin Shield](#create-update-fields-origin-shield)
+ [Connection attempts](#origin-connection-attempts)
+ [Connection timeout](#origin-connection-timeout)
+ [Response timeout](#DownloadDistValuesOriginResponseTimeout)
+ [Response completion timeout](#response-completion-timeout)
+ [Keep-alive timeout (custom and VPC origins only)](#DownloadDistValuesOriginKeepaliveTimeout)
+ [Response and keep-alive timeout quotas](#response-keep-alive-timeout-quota)
## Origin domain
The origin domain is the DNS domain name of the resource where CloudFront will get objects for your origin, such as an Amazon S3 bucket or HTTP server. For example:
+ **Amazon S3 bucket** – `amzn-s3-demo-bucket.s3.us-west-2.amazonaws.com`
**Note**
If you recently created the S3 bucket, the CloudFront distribution might return `HTTP 307 Temporary Redirect` responses for up to 24 hours. It can take up to 24 hours for the S3 bucket name to propagate to all AWS Regions. When the propagation is complete, the distribution automatically stops sending these redirect responses; you don't need to take any action. For more information, see [Why am I getting an HTTP 307 Temporary Redirect response from Amazon S3?](https://repost.aws/knowledge-center/s3-http-307-response) and [Temporary Request Redirection](https://docs.aws.amazon.com/AmazonS3/latest/dev/Redirects.html#TemporaryRedirection).
+ **Amazon S3 bucket configured as a website** – `amzn-s3-demo-bucket.s3-website.us-west-2.amazonaws.com`
+ **MediaStore container** – `examplemediastore.data.mediastore.us-west-1.amazonaws.com`
+ **MediaPackage endpoint** – `examplemediapackage.mediapackage.us-west-1.amazonaws.com`
+ **Amazon EC2 instance** – `ec2-203-0-113-25.compute-1.amazonaws.com`
+ **Elastic Load Balancing load balancer** – `example-load-balancer-1234567890.us-west-2.elb.amazonaws.com`
+ **Your own web server** – `www.example.com`
Choose the domain name in the **Origin domain** field, or type the name. Resources from opt-in Regions must be entered manually. The domain name is not case-sensitive. Your origin domain must have a publicly resolvable DNS name that routes requests from clients to targets over the internet.
If you configure CloudFront to connect to your origin over HTTPS, one of the domain names in the certificate must match the domain name that you specify for **Origin Domain Name**. If no domain name matches, CloudFront returns HTTP status code 502 (Bad Gateway) to the viewer. For more information, see [Domain names in the CloudFront distribution and in the certificate](cnames-and-https-requirements.md#https-requirements-domain-names-in-cert) and [SSL/TLS negotiation failure between CloudFront and a custom origin server](http-502-bad-gateway.md#ssl-negotitation-failure).
**Note**
If you are using an origin request policy that forwards the viewer host header to the origin, the origin must respond with a certificate that matches the viewer host header. For more information, see [Add CloudFront request headers](adding-cloudfront-headers.md).
If your origin is an Amazon S3 bucket, note the following:
+ If the bucket is configured as a website, enter the Amazon S3 static website hosting endpoint for your bucket; don’t select the bucket name from the list in the **Origin domain** field. The static website hosting endpoint appears in the Amazon S3 console, on the **Properties** page under **Static website hosting**. For more information, see [Use an Amazon S3 bucket that's configured as a website endpoint](DownloadDistS3AndCustomOrigins.md#concept_S3Origin_website).
+ If you configured Amazon S3 Transfer Acceleration for your bucket, do not specify the `s3-accelerate` endpoint for **Origin domain**.
+ If you're using a bucket from a different AWS account and if the bucket is not configured as a website, enter the name, using the following format:
`bucket-name.s3.region.amazonaws.com`
If your bucket reside in a US Region, and you want Amazon S3 to route requests to a facility in northern Virginia, use the following format:
`bucket-name.s3.us-east-1.amazonaws.com`
+ The files must be publicly readable unless you secure your content in Amazon S3 by using a CloudFront origin access control. For more information about access control, see [Restrict access to an Amazon S3 origin](private-content-restricting-access-to-s3.md).
**Important**
If the origin is an Amazon S3 bucket, the bucket name must conform to DNS naming requirements. For more information, go to [Bucket restrictions and limitations](https://docs.aws.amazon.com/AmazonS3/latest/userguide/BucketRestrictions.html) in the *Amazon Simple Storage Service User Guide*.
When you change the value of **Origin domain** for an origin, CloudFront immediately begins replicating the change to CloudFront edge locations. Until the distribution configuration is updated in a given edge location, CloudFront continues to forward requests to the previous origin. As soon as the distribution configuration is updated in that edge location, CloudFront begins to forward requests to the new origin.
Changing the origin does not require CloudFront to repopulate edge caches with objects from the new origin. As long as the viewer requests in your application have not changed, CloudFront continues to serve objects that are already in an edge cache until the TTL on each object expires or until seldom-requested objects are evicted.
## Protocol (custom origins only)
**Note**
This applies only to custom origins.
The protocol policy that you want CloudFront to use when fetching objects from your origin.
Choose one of the following values:
+ **HTTP only:** CloudFront uses only HTTP to access the origin.
**Important**
**HTTP only** is the default setting when the origin is an Amazon S3 static website hosting endpoint, because Amazon S3 doesn’t support HTTPS connections for static website hosting endpoints. The CloudFront console does not support changing this setting for Amazon S3 static website hosting endpoints.
+ **HTTPS only:** CloudFront uses only HTTPS to access the origin.
+ **Match viewer:** CloudFront communicates with your origin using HTTP or HTTPS, depending on the protocol of the viewer request. CloudFront caches the object only once even if viewers make requests using both HTTP and HTTPS protocols.
**Important**
For HTTPS viewer requests that CloudFront forwards to this origin, one of the domain names in the SSL/TLS certificate on your origin server must match the domain name that you specify for **Origin domain**. Otherwise, CloudFront responds to the viewer requests with an HTTP status code 502 (Bad Gateway) instead of returning the requested object. For more information, see [Requirements for using SSL/TLS certificates with CloudFront](cnames-and-https-requirements.md).
**Topics**
+ [HTTP port](#DownloadDistValuesHTTPPort)
+ [HTTPS port](#DownloadDistValuesHTTPSPort)
+ [Minimum origin SSL protocol](#DownloadDistValuesOriginSSLProtocols)
### HTTP port
**Note**
This applies only to custom origins.
(Optional) You can specify the HTTP port on which the custom origin listens. Valid values include ports 80, 443, and 1024 to 65535. The default value is port 80.
**Important**
Port 80 is the default setting when the origin is an Amazon S3 static website hosting endpoint, because Amazon S3 only supports port 80 for static website hosting endpoints. The CloudFront console does not support changing this setting for Amazon S3 static website hosting endpoints.
### HTTPS port
**Note**
This applies only to custom origins.
(Optional) You can specify the HTTPS port on which the custom origin listens. Valid values include ports 80, 443, and 1024 to 65535. The default value is port 443. When **Protocol** is set to **HTTP only**, you cannot specify a value for **HTTPS port**.
### Minimum origin SSL protocol
**Note**
This applies only to custom origins.
Choose the minimum TLS/SSL protocol that CloudFront can use when it establishes an HTTPS connection to your origin. Lower TLS protocols are less secure, so we recommend that you choose the latest TLS protocol that your origin supports. When **Protocol** is set to **HTTP only**, you cannot specify a value for **Minimum origin SSL protocol**.
If you use the CloudFront API to set the TLS/SSL protocol for CloudFront to use, you cannot set a minimum protocol. Instead, you specify all of the TLS/SSL protocols that CloudFront can use with your origin. For more information, see [OriginSslProtocols](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginSslProtocols.html) in the *Amazon CloudFront API Reference*.
## Origin path
If you want CloudFront to request your content from a directory in your origin, enter the directory path, beginning with a slash (/). CloudFront appends the directory path to the value of **Origin domain**, for example, **cf-origin.example.com/production/images**. Do not add a slash (/) at the end of the path.
For example, suppose you’ve specified the following values for your distribution:
+ **Origin domain** – An Amazon S3 bucket named **amzn-s3-demo-bucket**
+ **Origin path** – **/production**
+ **Alternate domain names (CNAME)** – **example.com**
When a user enters `example.com/index.html` in a browser, CloudFront sends a request to Amazon S3 for `amzn-s3-demo-bucket/production/index.html`.
When a user enters `example.com/acme/index.html` in a browser, CloudFront sends a request to Amazon S3 for `amzn-s3-demo-bucket/production/acme/index.html`.
## Name
A name is a string that uniquely identifies this origin in this distribution. If you create cache behaviors in addition to the default cache behavior, you use the name that you specify here to identify the origin that you want CloudFront to route a request to when the request matches the path pattern for that cache behavior.
## Origin access (Amazon S3 origins only)
**Note**
This applies only to Amazon S3 bucket origins (those that are *not* using the S3 static website endpoint).
Choose **Origin access control settings (recommended)** if you want to make it possible to restrict access to an Amazon S3 bucket origin to only specific CloudFront distributions.
Choose **Public** if the Amazon S3 bucket origin is publicly accessible.
For more information, see [Restrict access to an Amazon S3 origin](private-content-restricting-access-to-s3.md).
For information about how to require users to access objects on a custom origin by using only CloudFront URLs, see [Restrict access to files on custom origins](private-content-overview.md#forward-custom-headers-restrict-access).
## Add custom header
If you want CloudFront to add custom headers whenever it sends a request to your origin, specify the header name and its value. For more information, see [Add custom headers to origin requests](add-origin-custom-headers.md).
For the current maximum number of custom headers that you can add, the maximum length of a custom header name and value, and the maximum total length of all header names and values, see [Quotas](cloudfront-limits.md).
## Enable Origin Shield
Choose **Yes** to enable CloudFront Origin Shield. For more information about Origin Shield, see [Use Amazon CloudFront Origin Shield](origin-shield.md).
## Connection attempts
You can set the number of times that CloudFront attempts to connect to the origin. You can specify 1, 2, or 3 as the number of attempts. The default number (if you don’t specify otherwise) is 3.
Use this setting together with **Connection timeout** to specify how long CloudFront waits before attempting to connect to the secondary origin or returning an error response to the viewer. By default, CloudFront waits as long as 30 seconds (3 attempts of 10 seconds each) before attempting to connect to the secondary origin or returning an error response. You can reduce this time by specifying fewer attempts, a shorter connection timeout, or both.
If the specified number of connection attempts fail, CloudFront does one of the following:
+ If the origin is part of an origin group, CloudFront attempts to connect to the secondary origin. If the specified number of connection attempts to the secondary origin fail, then CloudFront returns an error response to the viewer.
+ If the origin is not part of an origin group, CloudFront returns an error response to the viewer.
For a custom origin (including an Amazon S3 bucket that’s configured with static website hosting), this setting also specifies the number of times that CloudFront attempts to get a response from the origin. For more information, see [Response timeout](#DownloadDistValuesOriginResponseTimeout).
## Connection timeout
The connection timeout is the number of seconds that CloudFront waits when trying to establish a connection to the origin. You can specify a number of seconds between 1 and 10 (inclusive). The default timeout (if you don’t specify otherwise) is 10 seconds.
Use this setting together with **Connection attempts** to specify how long CloudFront waits before attempting to connect to the secondary origin or before returning an error response to the viewer. By default, CloudFront waits as long as 30 seconds (3 attempts of 10 seconds each) before attempting to connect to the secondary origin or returning an error response. You can reduce this time by specifying fewer attempts, a shorter connection timeout, or both.
If CloudFront doesn’t establish a connection to the origin within the specified number of seconds, CloudFront does one of the following:
+ If the specified number of **Connection attempts** is more than 1, CloudFront tries again to establish a connection. CloudFront tries up to 3 times, as determined by the value of **Connection attempts**.
+ If all the connection attempts fail and the origin is part of an origin group, CloudFront attempts to connect to the secondary origin. If the specified number of connection attempts to the secondary origin fail, then CloudFront returns an error response to the viewer.
+ If all the connection attempts fail and the origin is not part of an origin group, CloudFront returns an error response to the viewer.
## Response timeout
The origin response timeout, also known as the *origin read timeout* or *origin request timeout*, applies to both of the following values:
+ How long (in seconds) CloudFront waits for a response after forwarding a request to the origin.
+ How long (in seconds) CloudFront waits after receiving a packet of a response from the origin and before receiving the next packet.
**Tip**
If you want to increase the timeout value because viewers are experiencing HTTP 504 status code errors, consider exploring other ways to eliminate those errors before changing the timeout value. See the troubleshooting suggestions in [HTTP 504 status code (Gateway Timeout)](http-504-gateway-timeout.md).
CloudFront behavior depends on the HTTP method in the viewer request:
+ `GET` and `HEAD` requests – If the origin doesn’t respond or stops responding within the duration of the response timeout, CloudFront drops the connection. CloudFront tries again to connect according to the value of [Connection attempts](#origin-connection-attempts).
+ `DELETE`, `OPTIONS`, `PATCH`, `PUT`, and `POST` requests – If the origin doesn’t respond for the duration of the read timeout, CloudFront drops the connection and doesn’t try again to contact the origin. The client can resubmit the request if necessary.
## Response completion timeout
**Note**
Response completion timeout doesn't support the [continuous deployment](continuous-deployment.md) feature.
The time (in seconds) that a request from CloudFront to the origin can stay open and wait for a response. If the complete response isn't received from the origin by this time, CloudFront ends the connection.
Unlike **Response timeout**, which is the wait time for *individual* response packets, **Response completion timeout** is the *maximum* allowed amount of time that CloudFront waits for the response to complete. You can use this setting to ensure that CloudFront doesn't wait indefinitely for a slow or unresponsive origin, even if other timeout settings allow for a longer wait.
This maximum timeout includes what you specified for other timeout settings and the number of **Connection attempts** for each retry. You can use these settings together to specify how long CloudFront waits for the full request and when to end the request, regardless if it's complete or not.
For example, if you set the following settings:
+ **Connection attempts** is 3
+ **Connection timeout ** is 10 seconds
+ **Response timeout** is 30 seconds
+ **Response completion timeout** is 60 seconds
This means CloudFront will try to connect to the origin (up to 3 total attempts), with each connection attempt timing out at 10 seconds. Once connected, CloudFront will wait up to 30 seconds for the origin to respond to the request until it receives the last packet of the response.
Regardless of the number of connection attempts or the response timeout, CloudFront will end the connection if the complete response from the origin takes longer than 60 seconds to complete. CloudFront will then return to the viewer a [HTTP 504 status code (Gateway Timeout)](http-504-gateway-timeout.md) error response or a custom error response if you specified one.
**Notes**
If you set a value for response completion timeout, the value must be equal to or greater than the value for the [response timeout (origin read timeout)](#DownloadDistValuesOriginResponseTimeout).
If you don't set a value for the response completion timeout, CloudFront doesn't enforce a maximum value.
## Keep-alive timeout (custom and VPC origins only)
The keep-alive timeout is how long (in seconds) CloudFront tries to maintain a connection to your custom origin after it gets the last packet of a response. Maintaining a persistent connection saves the time that is required to re-establish the TCP connection and perform another TLS handshake for subsequent requests. Increasing the keep-alive timeout helps improve the request-per-connection metric for distributions.
**Note**
For the **Keep-alive timeout** value to have an effect, your origin must be configured to allow persistent connections.
## Response and keep-alive timeout quotas
+ For [response timeout,](#DownloadDistValuesOriginResponseTimeout) the default is 30 seconds.
+ For [keep-alive timeout](#DownloadDistValuesOriginKeepaliveTimeout), the default is 5 seconds.
If you request a timeout increase for your AWS account, update your distribution origins so that they have the response timeout and keep-alive timeout values that you want. A quota increase for your account doesn't automatically update your origins. For example, if you're using a Lambda@Edge function to set a keep-alive timeout of 90 seconds, your origin must already have a keep-alive timeout of 90 seconds or more. Otherwise, your Lambda@Edge function might fail to execute.
For more information about distribution quotas, including how to request an increase, see [General quotas on distributions](cloudfront-limits.md#limits-web-distributions).
# Cache behavior settings
By setting the cache behavior, you can configure a variety of CloudFront functionality for a given URL path pattern for files on your website. For example, one cache behavior might apply to all `.jpg` files in the `images` directory on a web server that you're using as an origin server for CloudFront. The functionality that you can configure for each cache behavior includes:
+ The path pattern
+ If you have configured multiple origins for your CloudFront distribution, the origin to which you want CloudFront to forward your requests
+ Whether to forward query strings to your origin
+ Whether accessing the specified files requires signed URLs
+ Whether to require users to use HTTPS to access those files
+ The minimum amount of time that those files stay in the CloudFront cache regardless of the value of any `Cache-Control` headers that your origin adds to the files
When you create a new distribution, you specify settings for the default cache behavior, which automatically forwards all requests to the origin that you specify when you create the distribution. After you create a distribution, you can create additional cache behaviors that define how CloudFront responds when it receives a request for objects that match a path pattern, for example, `*.jpg`. If you create additional cache behaviors, the default cache behavior is always the last to be processed. Other cache behaviors are processed in the order in which they're listed in the CloudFront console or, if you're using the CloudFront API, the order in which they're listed in the `DistributionConfig` element for the distribution. For more information, see [Path pattern](#DownloadDistValuesPathPattern).
When you create a cache behavior, you specify the one origin from which you want CloudFront to get objects. As a result, if you want CloudFront to distribute objects from all of your origins, you must have at least as many cache behaviors (including the default cache behavior) as you have origins. For example, if you have two origins and only the default cache behavior, the default cache behavior causes CloudFront to get objects from one of the origins, but the other origin is never used.
For the current maximum number of cache behaviors that you can add to a distribution, or to request a higher quota (formerly known as limit), see [General quotas on distributions](cloudfront-limits.md#limits-web-distributions).
**Topics**
+ [Path pattern](#DownloadDistValuesPathPattern)
+ [Origin or origin group](#DownloadDistValuesTargetOriginId)
+ [Viewer protocol policy](#DownloadDistValuesViewerProtocolPolicy)
+ [Allowed HTTP methods](#DownloadDistValuesAllowedHTTPMethods)
+ [Field-level encryption config](#DownloadDistValuesFieldLevelEncryption)
+ [Cached HTTP methods](#DownloadDistValuesCachedHTTPMethods)
+ [Allow gRPC requests over HTTP/2](#enable-grpc-distribution)
+ [Cache based on selected request headers](#DownloadDistValuesForwardHeaders)
+ [Allowlist headers](#DownloadDistValuesAllowlistHeaders)
+ [Object caching](#DownloadDistValuesObjectCaching)
+ [Minimum TTL](#DownloadDistValuesMinTTL)
+ [Maximum TTL](#DownloadDistValuesMaxTTL)
+ [Default TTL](#DownloadDistValuesDefaultTTL)
+ [Forward cookies](#DownloadDistValuesForwardCookies)
+ [Allowlist cookies](#DownloadDistValuesAllowlistCookies)
+ [Query string forwarding and caching](#DownloadDistValuesQueryString)
+ [Query string allowlist](#DownloadDistValuesQueryStringAllowlist)
+ [Smooth Streaming](#DownloadDistValuesSmoothStreaming)
+ [Restrict viewer access (use signed URLs or signed cookies)](#DownloadDistValuesRestrictViewerAccess)
+ [Trusted signers](#DownloadDistValuesTrustedSigners)
+ [AWS account numbers](#DownloadDistValuesAWSAccountNumbers)
+ [Compress objects automatically](#DownloadDistValuesCompressObjectsAutomatically)
+ [CloudFront event](#DownloadDistValuesEventType)
+ [Lambda function ARN](#DownloadDistValuesLambdaFunctionARN)
+ [Include body](#include-body)
## Path pattern
A path pattern (for example, `images/*.jpg`) specifies to which requests you want this cache behavior to apply. When CloudFront receives an end-user request, the requested path is compared with path patterns in the order in which cache behaviors are listed in the distribution. The first match determines which cache behavior is applied to that request. For example, suppose you have three cache behaviors with the following three path patterns, in this order:
+ `images/*.jpg`
+ `images/*`
+ `*.gif`
**Note**
You can optionally include a slash (/) at the beginning of the path pattern, for example, `/images/*.jpg`. CloudFront behavior is the same with or without the leading /. If you don't specify the / at the beginning of the path, this character is automatically implied; CloudFront treats the path the same with or without the leading /. For example, CloudFront treats `/*product.jpg` the same as `*product.jpg`
A request for the file `images/sample.gif` doesn't satisfy the first path pattern, so the associated cache behaviors are not applied to the request. The file does satisfy the second path pattern, so the cache behaviors associated with the second path pattern are applied even though the request also matches the third path pattern.
**Note**
When you create a new distribution, the value of **Path Pattern** for the default cache behavior is set to **\$1** (all files) and cannot be changed. This value causes CloudFront to forward all requests for your objects to the origin that you specified in the [Origin domain](DownloadDistValuesOrigin.md#DownloadDistValuesDomainName) field. If the request for an object does not match the path pattern for any of the other cache behaviors, CloudFront applies the behavior that you specify in the default cache behavior.
**Important**
Define path patterns and their sequence carefully or you may give users undesired access to your content. For example, suppose a request matches the path pattern for two cache behaviors. The first cache behavior does not require signed URLs and the second cache behavior does require signed URLs. Users are able to access the objects without using a signed URL because CloudFront processes the cache behavior associated with the first match.
If you're working with a MediaPackage channel, you must include specific path patterns for the cache behavior that you define for the endpoint type for your origin. For example, for a DASH endpoint, you type `*.mpd` for **Path Pattern**. For more information and specific instructions, see [Serve live video formatted with AWS Elemental MediaPackage](live-streaming.md#live-streaming-with-mediapackage).
The path you specify applies to requests for all files in the specified directory and in subdirectories below the specified directory. CloudFront does not consider query strings or cookies when evaluating the path pattern. For example, if an `images` directory contains `product1` and `product2` subdirectories, the path pattern `images/*.jpg` applies to requests for any .jpg file in the `images`, `images/product1`, and `images/product2` directories. If you want to apply a different cache behavior to the files in the `images/product1` directory than the files in the `images` and `images/product2` directories, create a separate cache behavior for `images/product1` and move that cache behavior to a position above (before) the cache behavior for the `images` directory.
You can use the following wildcard characters in your path pattern:
+ `*` matches 0 or more characters.
+ `?` matches exactly 1 character.
The following examples show how the wildcard characters work:
****
| Path pattern | Files that match the path pattern |
| --- | --- |
| `*.jpg` | All .jpg files. |
| `images/*.jpg` | All .jpg files in the `images` directory and in subdirectories under the `images` directory. |
| `a*.jpg` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DownloadDistValuesCacheBehavior.html) |
| `a??.jpg` | All .jpg files for which the file name begins with `a` and is followed by exactly two other characters, for example, `ant.jpg` and `abe.jpg`. |
| `*.doc*` | All files for which the file name extension begins with `.doc`, for example, `.doc`, `.docx`, and `.docm` files. You can't use the path pattern `*.doc?` in this case, because that path pattern wouldn't apply to requests for `.doc` files; the `?` wildcard character replaces exactly one character. |
The maximum length of a path pattern is 255 characters. The value can contain any of the following characters:
+ A-Z, a-z
Path patterns are case-sensitive, so the path pattern `*.jpg` doesn't apply to the file `LOGO.JPG`
+ 0-9
+ \$1 - . \$1 \$1 / \$1 " ' @ : \$1
+ &, passed and returned as `&`
### Path normalization
CloudFront normalizes URI paths consistent with [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986#section-6) and then matches the path with the correct cache behavior. Once the cache behavior is matched, CloudFront sends the raw URI path to the origin. If they don't match, requests are instead matched to your default cache behavior.
Some characters are normalized and removed from the path, such as multiple slashes (`//`) or periods (`..`). This can alter the URL that CloudFront uses to match the intended cache behavior.
**Example**
You specify the `/a/b*` and `/a*` paths for your cache behavior.
+ A viewer sending the `/a/b?c=1` path will match the `/a/b*` cache behavior.
+ A viewer sending the `/a/b/..?c=1` path will match the `/a*` cache behavior.
To work around the paths being normalized, you can update your request paths or the path pattern for the cache behavior.
## Origin or origin group
This setting applies only when you create or update a cache behavior for an existing distribution.
Enter the value of an existing origin or origin group. This identifies the origin or origin group to which you want CloudFront to route requests when a request (such as https://example.com/logo.jpg) matches the path pattern for a cache behavior (such as \$1.jpg) or for the default cache behavior (\$1).
## Viewer protocol policy
Choose the protocol policy that you want viewers to use to access your content in CloudFront edge locations:
+ **HTTP and HTTPS**: Viewers can use both protocols.
+ **Redirect HTTP to HTTPS**: Viewers can use both protocols, but HTTP requests are automatically redirected to HTTPS requests.
+ **HTTPS Only**: Viewers can only access your content if they're using HTTPS.
For more information, see [Require HTTPS for communication between viewers and CloudFront](using-https-viewers-to-cloudfront.md).
## Allowed HTTP methods
Specify the HTTP methods that you want CloudFront to process and forward to your origin:
+ **GET, HEAD:** You can use CloudFront only to get objects from your origin or to get object headers.
+ **GET, HEAD, OPTIONS:** You can use CloudFront only to get objects from your origin, get object headers, or retrieve a list of the options that your origin server supports.
+ **GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE:** You can use CloudFront to get, add, update, and delete objects, and to get object headers. In addition, you can perform other POST operations such as submitting data from a web form.
**Note**
If you're using gRPC in your workload, you must select **GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE**. gRPC workloads require the `POST` method. For more information, see [Using gRPC with CloudFront distributions](distribution-using-grpc.md).
CloudFront caches responses to `GET` and `HEAD` requests and, optionally, `OPTIONS` requests. Responses to `OPTIONS` requests are cached separately from responses to `GET` and `HEAD` requests (the `OPTIONS` method is included in the [cache key](understanding-the-cache-key.md) for `OPTIONS` requests). CloudFront does not cache responses to requests that use other methods.
**Important**
If you choose **GET, HEAD, OPTIONS** or **GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE**, you might need to restrict access to your Amazon S3 bucket or to your custom origin to prevent users from performing operations that you don't want them to perform. The following examples explain how to restrict access:
**If you're using Amazon S3 as an origin for your distribution:** Create a CloudFront origin access control to restrict access to your Amazon S3 content, and give permissions to the origin access control. For example, if you configure CloudFront to accept and forward these methods *only* because you want to use `PUT`, you must still configure Amazon S3 bucket policies to handle `DELETE` requests appropriately. For more information, see [Restrict access to an Amazon S3 origin](private-content-restricting-access-to-s3.md).
**If you're using a custom origin:** Configure your origin server to handle all methods. For example, if you configure CloudFront to accept and forward these methods *only* because you want to use `POST`, you must still configure your origin server to handle `DELETE` requests appropriately.
## Field-level encryption config
If you want to enforce field-level encryption on specific data fields, in the dropdown list, choose a field-level encryption configuration.
For more information, see [Use field-level encryption to help protect sensitive data](field-level-encryption.md).
## Cached HTTP methods
Specify whether you want CloudFront to cache the response from your origin when a viewer submits an `OPTIONS` request. CloudFront always caches the response to `GET` and `HEAD` requests.
## Allow gRPC requests over HTTP/2
Specify whether you want your distribution to allow gRPC requests. To enable gRPC, select the following settings:
+ For **[Allowed HTTP methods](#DownloadDistValuesAllowedHTTPMethods)**, select the **GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE** methods. gRPC requires the `POST` method.
+ Select the gRPC checkbox that appears after you select the `POST` method.
+ For **[Supported HTTP versions](DownloadDistValuesGeneral.md#DownloadDistValuesSupportedHTTPVersions)**, select **HTTP/2**.
For more information, see [Using gRPC with CloudFront distributions](distribution-using-grpc.md).
## Cache based on selected request headers
Specify whether you want CloudFront to cache objects based on the values of specified headers:
+ **None (improves caching)** – CloudFront doesn't cache your objects based on header values.
+ **Allowlist** – CloudFront caches your objects based only on the values of the specified headers. Use **Allowlist Headers** to choose the headers that you want CloudFront to base caching on.
+ **All** – CloudFront doesn't cache the objects that are associated with this cache behavior. Instead, CloudFront sends every request to the origin. (Not recommended for Amazon S3 origins.)
Regardless of the option that you choose, CloudFront forwards certain headers to your origin and takes specific actions based on the headers that you forward. For more information about how CloudFront handles header forwarding, see [HTTP request headers and CloudFront behavior (custom and Amazon S3 origins)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior).
For more information about how to configure caching in CloudFront by using request headers, see [Cache content based on request headers](header-caching.md).
## Allowlist headers
These settings apply only when you choose **Allowlist** for **Cache Based on Selected Request Headers**.
Specify the headers that you want CloudFront to consider when caching your objects. Select headers from the list of available headers and choose **Add**. To forward a custom header, enter the name of the header in the field, and choose **Add Custom**.
For the current maximum number of headers that you can allowlist for each cache behavior, or to request a higher quota (formerly known as limit), see [Quotas on headers](cloudfront-limits.md#limits-custom-headers).
## Object caching
If your origin server is adding a `Cache-Control` header to your objects to control how long the objects stay in the CloudFront cache and if you don't want to change the `Cache-Control` value, choose **Use Origin Cache Headers**.
To specify a minimum and maximum time that your objects stay in the CloudFront cache regardless of `Cache-Control` headers, and a default time that your objects stay in the CloudFront cache when the `Cache-Control` header is missing from an object, choose **Customize**. Then specify values in the **Minimum TTL**, **Default TTL**, and **Maximum TTL** fields.
For more information, see [Manage how long content stays in the cache (expiration)](Expiration.md).
## Minimum TTL
Specify the minimum amount of time, in seconds, that you want objects to stay in the CloudFront cache before CloudFront sends another request to the origin to determine whether the object has been updated.
**Warning**
If your minimum TTL is greater than 0, CloudFront will cache content for at least the duration specified in the cache policy's minimum TTL, even if the `Cache-Control: no-cache`, `no-store`, or `private` directives are present in the origin headers.
For more information, see [Manage how long content stays in the cache (expiration)](Expiration.md).
## Maximum TTL
Specify the maximum amount of time, in seconds, that you want objects to stay in CloudFront caches before CloudFront queries your origin to see whether the object has been updated. The value that you specify for **Maximum TTL** applies only when your origin adds HTTP headers such as `Cache-Control max-age`, `Cache-Control s-maxage`, or `Expires` to objects. For more information, see [Manage how long content stays in the cache (expiration)](Expiration.md).
To specify a value for **Maximum TTL**, you must choose the **Customize** option for the **Object Caching** setting.
The default value for **Maximum TTL** is 31536000 seconds (one year). If you change the value of **Minimum TTL** or **Default TTL** to more than 31536000 seconds, then the default value of **Maximum TTL** changes to the value of **Default TTL**.
## Default TTL
Specify the default amount of time, in seconds, that you want objects to stay in CloudFront caches before CloudFront forwards another request to your origin to determine whether the object has been updated. The value that you specify for **Default TTL** applies only when your origin does *not* add HTTP headers such as `Cache-Control max-age`, `Cache-Control s-maxage`, or `Expires` to objects. For more information, see [Manage how long content stays in the cache (expiration)](Expiration.md).
To specify a value for **Default TTL**, you must choose the **Customize** option for the **Object Caching** setting.
The default value for **Default TTL** is 86400 seconds (one day). If you change the value of **Minimum TTL** to more than 86400 seconds, then the default value of **Default TTL** changes to the value of **Minimum TTL**.
## Forward cookies
**Note**
For Amazon S3 origins, this option applies to only buckets that are configured as a website endpoint.
Specify whether you want CloudFront to forward cookies to your origin server and, if so, which ones. If you choose to forward only selected cookies (an allowlist of cookies), enter the cookie names in the **Allowlist Cookies** field. If you choose **All**, CloudFront forwards all cookies regardless of how many your application uses.
Amazon S3 doesn't process cookies, and forwarding cookies to the origin reduces cache ability. For cache behaviors that are forwarding requests to an Amazon S3 origin, choose **None** for **Forward Cookies**.
For more information about forwarding cookies to the origin, go to [Cache content based on cookies](Cookies.md).
## Allowlist cookies
**Note**
For Amazon S3 origins, this option applies to only buckets that are configured as a website endpoint.
If you chose **Allowlist** in the **Forward Cookies** list, then in the **Allowlist Cookies** field, enter the names of cookies that you want CloudFront to forward to your origin server for this cache behavior. Enter each cookie name on a new line.
You can specify the following wildcards to specify cookie names:
+ **\$1** matches 0 or more characters in the cookie name
+ **?** matches exactly one character in the cookie name
For example, suppose viewer requests for an object include a cookie named:
`userid_member-number`
Where each of your users has a unique value for *member-number*. You want CloudFront to cache a separate version of the object for each member. You could accomplish this by forwarding all cookies to your origin, but viewer requests include some cookies that you don't want CloudFront to cache. Alternatively, you could specify the following value as a cookie name, which causes CloudFront to forward to the origin all of the cookies that begin with `userid_`:
`userid_*`
For the current maximum number of cookie names that you can allowlist for each cache behavior, or to request a higher quota (formerly known as limit), see [Quotas on cookies (legacy cache settings)](cloudfront-limits.md#limits-allowlisted-cookies).
## Query string forwarding and caching
CloudFront can cache different versions of your content based on the values of query string parameters. Choose one of the following options:
**None (Improves Caching)**
Choose this option if your origin returns the same version of an object regardless of the values of query string parameters. This increases the likelihood that CloudFront can serve a request from the cache, which improves performance and reduces the load on your origin.
**Forward all, cache based on allowlist**
Choose this option if your origin server returns different versions of your objects based on one or more query string parameters. Then specify the parameters that you want CloudFront to use as a basis for caching in the [Query string allowlist](#DownloadDistValuesQueryStringAllowlist) field.
**Forward all, cache based on all**
Choose this option if your origin server returns different versions of your objects for all query string parameters.
For more information about caching based on query string parameters, including how to improve performance, see [Cache content based on query string parameters](QueryStringParameters.md).
## Query string allowlist
This setting applies only when you choose **Forward all, cache based on allowlist** for [Query string forwarding and caching](#DownloadDistValuesQueryString). You can specify the query string parameters that you want CloudFront to use as a basis for caching.
## Smooth Streaming
Choose **Yes** if you want to distribute media files in the Microsoft Smooth Streaming format and you do not have an IIS server.
Choose **No** if you have a Microsoft IIS server that you want to use as an origin to distribute media files in the Microsoft Smooth Streaming format, or if you are not distributing Smooth Streaming media files.
**Note**
If you specify **Yes**, you can still distribute other content using this cache behavior if that content matches the value of **Path Pattern**.
For more information, see [Configure video on demand for Microsoft Smooth Streaming](on-demand-video.md#on-demand-streaming-smooth).
## Restrict viewer access (use signed URLs or signed cookies)
If you want requests for objects that match the `PathPattern` for this cache behavior to use public URLs, choose **No**.
If you want requests for objects that match the `PathPattern` for this cache behavior to use signed URLs, choose **Yes**. Then specify the AWS accounts that you want to use to create signed URLs; these accounts are known as trusted signers.
For more information about trusted signers, see [Specify signers that can create signed URLs and signed cookies](private-content-trusted-signers.md).
## Trusted signers
This setting applies only when you choose **Yes** for **Restrict Viewer Access (Use Signed URLs or Signed Cookies**.
Choose which AWS accounts you want to use as trusted signers for this cache behavior:
+ **Self:** Use the account with which you're currently signed into the AWS Management Console as a trusted signer. If you're currently signed in as an IAM user, the associated AWS account is added as a trusted signer.
+ **Specify Accounts:** Enter account numbers for trusted signers in the **AWS Account Numbers** field.
To create signed URLs, an AWS account must have at least one active CloudFront key pair.
**Important**
If you're updating a distribution that you're already using to distribute content, add trusted signers only when you're ready to start generating signed URLs for your objects. After you add trusted signers to a distribution, users must use signed URLs to access the objects that match the `PathPattern` for this cache behavior.
## AWS account numbers
This setting applies only when you choose **Specify Accounts** for **Trusted Signers**.
If you want to create signed URLs using AWS accounts in addition to or instead of the current account, enter one AWS account number per line in this field. Note the following:
+ The accounts that you specify must have at least one active CloudFront key pair. For more information, see [Create key pairs for your signers](private-content-trusted-signers.md#private-content-creating-cloudfront-key-pairs).
+ You can't create CloudFront key pairs for IAM users, so you can't use IAM users as trusted signers.
+ For information about how to get the AWS account number for an account, see [View AWS account identifiers](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html) in the *AWS account Management Reference Guide*.
+ If you enter the account number for the current account, CloudFront automatically checks the **Self** check box and removes the account number from the **AWS Account Numbers** list.
## Compress objects automatically
If you want CloudFront to automatically compress files of certain types when viewers support compressed content, choose **Yes**. When CloudFront compresses your content, downloads are faster because the files are smaller, and your web pages render faster for your users. For more information, see [Serve compressed files](ServingCompressedFiles.md).
## CloudFront event
This setting applies to **Lambda Function Associations**.
You can choose to run a Lambda function when one or more of the following CloudFront events occur:
+ When CloudFront receives a request from a viewer (viewer request)
+ Before CloudFront forwards a request to the origin (origin request)
+ When CloudFront receives a response from the origin (origin response)
+ Before CloudFront returns the response to the viewer (viewer response)
For more information, see [Choose the event to trigger the function](lambda-how-to-choose-event.md).
## Lambda function ARN
This setting applies to **Lambda Function Associations**.
Specify the Amazon Resource Name (ARN) of the Lambda function that you want to add a trigger for. To learn how to get the ARN for a function, see step 1 of the procedure [ Adding Triggers by Using the CloudFront Console](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-add-triggers.html#lambda-edge-add-triggers-cf-console).
## Include body
This setting applies to **Lambda Function Associations**.
For more information, see [Include body](lambda-generating-http-responses.md#lambda-include-body-access).
# Distribution settings
The following values apply to the entire distribution.
**Topics**
+ [Price class](#DownloadDistValuesPriceClass)
+ [AWS WAF web ACL](#DownloadDistValuesWAFWebACL)
+ [Alternate domain names (CNAMEs)](#DownloadDistValuesCNAME)
+ [SSL certificate](#DownloadDistValuesSSLCertificate)
+ [Custom SSL client support](#DownloadDistValuesClientsSupported)
+ [Security policy (minimum SSL/TLS version)](#DownloadDistValues-security-policy)
+ [Supported HTTP versions](#DownloadDistValuesSupportedHTTPVersions)
+ [Default root object](#DownloadDistValuesDefaultRootObject)
+ [Standard logging](#DownloadDistValuesLoggingOnOff)
+ [Connection logs](#DownloadDistValuesConnectionLogs)
+ [Log prefix](#DownloadDistValuesLogPrefix)
+ [Cookie logging](#DownloadDistValuesCookieLogging)
+ [Enable IPv6 (viewer requests)](#DownloadDistValuesEnableIPv6)
+ [Mutual authentication](#DownloadDistValuesMutualAuthentication)
+ [Enable IPv6 for custom origins (origin requests)](#DownloadDistValuesEnableIPv6-origin)
+ [Comment](#DownloadDistValuesComment)
+ [Distribution state](#DownloadDistValuesEnabled)
## Price class
Choose the price class that corresponds with the maximum price that you want to pay for CloudFront service. By default, CloudFront serves your objects from edge locations in all CloudFront Regions.
For more information about price classes and about how your choice of price class affects CloudFront performance for your distribution, see [CloudFront pricing](https://aws.amazon.com/cloudfront/pricing/).
## AWS WAF web ACL
You can protect your CloudFront distribution with [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf), a web application firewall that allows you to secure your web applications and APIs to block requests before they reach your servers. You can [Enable AWS WAF for distributions](WAF-one-click.md) when creating or editing a CloudFront distribution.
Optionally, you can later configure additional security protections for other threats specific to your application in the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
For more information about AWS WAF, see the [AWS WAF Developer Guide](https://docs.aws.amazon.com/waf/latest/developerguide/).
## Alternate domain names (CNAMEs)
Optional. Specify one or more domain names that you want to use for URLs for your objects instead of the domain name that CloudFront assigns when you create your distribution. You must own the domain name, or have authorization to use it, which you verify by adding an SSL/TLS certificate.
For example, if you want the URL for the object:
`/images/image.jpg`
To look like this:
`https://www.example.com/images/image.jpg`
Instead of like this:
`https://d111111abcdef8.cloudfront.net/images/image.jpg`
Add a CNAME for `www.example.com`.
**Important**
If you add a CNAME for `www.example.com` to your distribution, you also must do the following:
Create (or update) a CNAME record with your DNS service to route queries for `www.example.com` to `d111111abcdef8.cloudfront.net`.
Add a certificate to CloudFront from a trusted certificate authority (CA) that covers the domain name (CNAME) that you add to your distribution, to validate your authorization to use the domain name.
You must have permission to create a CNAME record with the DNS service provider for the domain. Typically, this means that you own the domain, or that you're developing an application for the domain owner.
For the current maximum number of alternate domain names that you can add to a distribution, or to request a higher quota (formerly known as limit), see [General quotas on distributions](cloudfront-limits.md#limits-web-distributions).
For more information about alternate domain names, see [Use custom URLs by adding alternate domain names (CNAMEs)](CNAMEs.md). For more information about CloudFront URLs, see [Customize the URL format for files in CloudFront](LinkFormat.md).
## SSL certificate
If you specified an alternate domain name to use with your distribution, choose **Custom SSL Certificate**, and then, to validate your authorization to use the alternate domain name, choose a certificate that covers it. If you want viewers to use HTTPS to access your objects, choose the settings that support that.
+ **Default CloudFront Certificate (\$1.cloudfront.net)** – Choose this option if you want to use the CloudFront domain name in the URLs for your objects, such as `https://d111111abcdef8.cloudfront.net/image1.jpg`.
+ **Custom SSL Certificate** – Choose this option if you want to use your own domain name in the URLs for your objects as an alternate domain name, such as `https://example.com/image1.jpg`. Then choose a certificate to use that covers the alternate domain name. The list of certificates can include any of the following:
+ Certificates provided by AWS Certificate Manager
+ Certificates that you purchased from a third-party certificate authority and uploaded to ACM
+ Certificates that you purchased from a third-party certificate authority and uploaded to the IAM certificate store
If you choose this setting, we recommend that you use only an alternate domain name in your object URLs (https://example.com/logo.jpg). If you use your CloudFront distribution domain name (https://d111111abcdef8.cloudfront.net/logo.jpg) and a client uses an older viewer that doesn't support SNI, how the viewer responds depends on the value that you choose for **Clients Supported**:
+ **All Clients**: The viewer displays a warning because the CloudFront domain name doesn't match the domain name in your SSL/TLS certificate.
+ **Only Clients that Support Server Name Indication (SNI)**: CloudFront drops the connection with the viewer without returning the object.
## Custom SSL client support
Applies only when you choose **Custom SSL Certificate (example.com)** for **SSL Certificate**. If you specified one or more alternate domain names and a custom SSL certificate for the distribution, choose how you want CloudFront to serve HTTPS requests:
+ **Clients that Support Server Name Indication (SNI) - (Recommended)** – With this setting, virtually all modern web browsers and clients can connect to the distribution, because they support SNI. However, some viewers might use older web browsers or clients that don’t support SNI, which means they can’t connect to the distribution.
To apply this setting using the CloudFront API, specify `sni-only` in the `SSLSupportMethod` field. In CloudFormation, the field is named `SslSupportMethod` (note the different capitalization).
+ **Legacy Clients Support** – With this setting, older web browsers and clients that don’t support SNI can connect to the distribution. However, this setting incurs additional monthly charges. For the exact price, go to the [Amazon CloudFront Pricing](https://aws.amazon.com/cloudfront/pricing/) page, and search the page for **Dedicated IP custom SSL**.
To apply this setting using the CloudFront API, specify `vip` in the `SSLSupportMethod` field. In CloudFormation, the field is named `SslSupportMethod` (note the different capitalization).
For more information, see [Choose how CloudFront serves HTTPS requests](cnames-https-dedicated-ip-or-sni.md).
## Security policy (minimum SSL/TLS version)
Specify the security policy that you want CloudFront to use for HTTPS connections with viewers (clients). A security policy determines two settings:
+ The minimum SSL/TLS protocol that CloudFront uses to communicate with viewers.
+ The ciphers that CloudFront can use to encrypt the content that it returns to viewers.
For more information about the security policies, including the protocols and ciphers that each one includes, see [Supported protocols and ciphers between viewers and CloudFront](secure-connections-supported-viewer-protocols-ciphers.md).
The security policies that are available depend on the values that you specify for **SSL Certificate** and **Custom SSL Client Support** (known as `CloudFrontDefaultCertificate` and `SSLSupportMethod` in the CloudFront API):
+ When **SSL Certificate** is **Default CloudFront Certificate (\$1.cloudfront.net)** (when `CloudFrontDefaultCertificate` is `true` in the API), CloudFront automatically sets the security policy to TLSv1.
+ When **SSL Certificate** is **Custom SSL Certificate (example.com)** *and* **Custom SSL Client Support** is **Clients that Support Server Name Indication (SNI) - (Recommended)** (when `CloudFrontDefaultCertificate` is `false` *and* `SSLSupportMethod` is `sni-only` in the API), you can choose from the following security policies:
+ TLSv1.3\$12025
+ TLSv1.2\$12025
+ TLSv1.2\$12021
+ TLSv1.2\$12019
+ TLSv1.2\$12018
+ TLSv1.1\$12016
+ TLSv1\$12016
+ TLSv1
+ When **SSL Certificate** is **Custom SSL Certificate (example.com)** *and* **Custom SSL Client Support** is **Legacy Clients Support** (when `CloudFrontDefaultCertificate` is `false` *and* `SSLSupportMethod` is `vip` in the API), you can choose from the following security policies:
+ TLSv1
+ SSLv3
In this configuration, the TLSv1.3\$12025, TLSv1.2\$12025, TLSv1.2\$12021, TLSv1.2\$12019, TLSv1.2\$12018, TLSv1.1\$12016, and TLSv1\$12016 security policies aren’t available in the CloudFront console or API. If you want to use one of these security policies, you have the following options:
+ Evaluate whether your distribution needs Legacy Clients Support with dedicated IP addresses. If your viewers support [server name indication (SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication), we recommend that you update your distribution’s **Custom SSL Client Support** setting to **Clients that Support Server Name Indication (SNI)** (set `SSLSupportMethod` to `sni-only` in the API). This enables you to use any of the available TLS security policies, and it can also reduce your CloudFront charges.
+ If you must keep Legacy Clients Support with dedicated IP addresses, you can request one of the other TLS security policies (TLSv1.3\$12025, TLSv1.2\$12025, TLSv1.2\$12021, TLSv1.2\$12019, TLSv1.2\$12018, TLSv1.1\$12016, or TLSv1\$12016) by creating a case in the [AWS Support Center](https://console.aws.amazon.com/support/home).
**Note**
Before you contact AWS Support to request this change, consider the following:
When you add one of these security policies (TLSv1.3\$12025, TLSv1.2\$12025, TLSv1.2\$12021, TLSv1.2\$12019, TLSv1.2\$12018, TLSv1.1\$12016, or TLSv1\$12016) to a Legacy Clients Support distribution, the security policy is applied to *all* non-SNI viewer requests for *all* Legacy Clients Support distributions in your AWS account. However, when viewers send SNI requests to a distribution with Legacy Clients Support, the security policy of that distribution applies. To make sure that your desired security policy is applied to *all* viewer requests sent to *all* Legacy Clients Support distributions in your AWS account, add the desired security policy to each distribution individually.
By definition, the new security policy doesn’t support the same ciphers and protocols as the old one. For example, if you chose to upgrade a distribution’s security policy from TLSv1 to TLSv1.1\$12016, that distribution will no longer support the DES-CBC3-SHA cipher. For more information about the ciphers and protocols that each security policy supports, see [Supported protocols and ciphers between viewers and CloudFront](secure-connections-supported-viewer-protocols-ciphers.md).
## Supported HTTP versions
Choose the HTTP versions that you want your distribution to support when viewers communicate with CloudFront.
For viewers and CloudFront to use HTTP/2, viewers must support TLSv1.2 or later, and Server Name Indication (SNI).
For viewers and CloudFront to use HTTP/3, viewers must support TLSv1.3 and Server Name Indication (SNI). CloudFront supports HTTP/3 connection migration to allow the viewer to switch networks without losing connection. For more information about connection migration, see [Connection Migration](https://www.rfc-editor.org/rfc/rfc9000.html#name-connection-migration) at RFC 9000.
**Note**
For more information about supported TLSv1.3 ciphers, see [Supported protocols and ciphers between viewers and CloudFront](secure-connections-supported-viewer-protocols-ciphers.md).
**Note**
If you use Amazon Route 53, you can use HTTPS records to allow protocol negotiation as part of the DNS lookup if the client supports it. For more information, see [Create alias resource record set](CreatingCNAME.md#alternate-domain-https).
## Default root object
Optional. The object that you want CloudFront to request from your origin (for example, `index.html`) when a viewer requests the root URL of your distribution (`https://www.example.com/`) instead of an object in your distribution (`https://www.example.com/product-description.html`). Specifying a default root object avoids exposing the contents of your distribution.
The maximum length of the name is 255 characters. The name can contain any of the following characters:
+ A-Z, a-z
+ 0-9
+ \$1 - . \$1 \$1 / \$1 " '
+ &, passed and returned as `&`
When you specify the default root object, enter only the object name, for example, `index.html`. Do not add a `/` before the object name.
For more information, see [Specify a default root object](DefaultRootObject.md).
## Standard logging
Specify if you want CloudFront to log information about each request for an object and store the log files. You can enable or disable logging at any time. There is no extra charge if you enable logging, but you may accrue charges for storing and accessing the files. You can delete the logs at any time.
CloudFront supports the following standard logging options:
+ [Standard logging (v2)](standard-logging.md) – You can send logs to delivery destinations, including Amazon CloudWatch Logs, Amazon Data Firehose, and Amazon Simple Storage Service (Amazon S3).
+ [Standard logging (legacy)](AccessLogs.md) – You can only send logs to an Amazon S3 bucket.
## Connection logs
When you turn on [mutual authentication](#DownloadDistValuesMutualAuthentication) for your distribution, CloudFront provides connection logs that capture attributes about the requests sent to your distributions. Connection logs contain information such as the client IP address and port, client certificate information, connection results, and TLS ciphers being used. These connection logs can then be used to review request patterns and other trends.
To learn more about connection logs, see [Observability using connection logs](connection-logs.md).
## Log prefix
(Optional) If you enable standard logging (legacy), specify the string, if any, that you want CloudFront to prefix to the access log file names for this distribution, for example, `exampleprefix/`. The trailing slash ( / ) is optional but recommended to simplify browsing your log files. For more information, see [Configure standard logging (legacy)](standard-logging-legacy-s3.md).
## Cookie logging
If you want CloudFront to include cookies in access logs, choose **On**. If you choose to include cookies in logs, CloudFront logs all cookies regardless of how you configure the cache behaviors for this distribution: forward all cookies, forward no cookies, or forward a specified list of cookies to the origin.
Amazon S3 doesn't process cookies, so unless your distribution also includes an Amazon EC2 or other custom origin, we recommend that you choose **Off** for the value of **Cookie Logging**.
For more information about cookies, see [Cache content based on cookies](Cookies.md).
## Enable IPv6 (viewer requests)
If you want CloudFront to respond to viewer requests from IPv4 and IPv6 IP addresses, select **Enable IPv6**. For more information, see [Enable IPv6 for CloudFront distributions](cloudfront-enable-ipv6.md).
## Mutual authentication
Optional. You can choose to turn on mutual authentication for your CloudFront distribution. For more information, see [Mutual TLS authentication with CloudFront (Viewer mTLS)Origin mutual TLS with CloudFront](mtls-authentication.md).
## Enable IPv6 for custom origins (origin requests)
When you use a custom origin (excluding Amazon S3 and VPC origins), you can customize origin settings for your distribution to choose how CloudFront connects to your origin using IPv4 or IPv6 addresses. For more information, see [Enable IPv6 for CloudFront distributions](cloudfront-enable-ipv6.md).
## Comment
Optional. When you create a distribution, you can include a comment of up to 128 characters. You can update the comment at any time.
## Distribution state
Indicates whether you want the distribution to be enabled or disabled once it's deployed:
+ *Enabled* means that as soon as the distribution is fully deployed you can deploy links that use the distribution's domain name and users can retrieve content. Whenever a distribution is enabled, CloudFront accepts and handles any end-user requests for content that use the domain name associated with that distribution.
When you create, modify, or delete a CloudFront distribution, it takes time for your changes to propagate to the CloudFront database. An immediate request for information about a distribution might not show the change. Propagation usually completes within minutes, but a high system load or network partition might increase this time.
+ *Disabled* means that even though the distribution might be deployed and ready to use, users can't use it. Whenever a distribution is disabled, CloudFront doesn't accept any end-user requests that use the domain name associated with that distribution. Until you switch the distribution from disabled to enabled (by updating the distribution's configuration), no one can use it.
You can toggle a distribution between disabled and enabled as often as you want. Follow the process for updating a distribution's configuration. For more information, see [Update a distribution](HowToUpdateDistribution.md).
# Custom error pages and error caching
You can have CloudFront return an object to the viewer (for example, an HTML file) when your Amazon S3 or custom origin returns an HTTP 4xx or 5xx status code to CloudFront. You can also specify how long an error response from your origin or a custom error page is cached in CloudFront edge caches. For more information, see [Create a custom error page for specific HTTP status codes](creating-custom-error-pages.md).
**Note**
The following values aren't included in the Create Distribution wizard, so you can configure custom error pages only when you update a distribution.
**Topics**
+ [HTTP error code](#DownloadDistValuesErrorCode)
+ [Response page path](#DownloadDistValuesResponsePagePath)
+ [HTTP response code](#DownloadDistValuesResponseCode)
+ [Error caching minimum TTL (seconds)](#DownloadDistValuesErrorCachingMinTTL)
## HTTP error code
The HTTP status code for which you want CloudFront to return a custom error page. You can configure CloudFront to return custom error pages for none, some, or all of the HTTP status codes that CloudFront caches.
## Response page path
The path to the custom error page (for example, `/4xx-errors/403-forbidden.html`) that you want CloudFront to return to a viewer when your origin returns the HTTP status code that you specified for **Error Code** (for example, 403). If you want to store your objects and your custom error pages in different locations, your distribution must include a cache behavior for which the following is true:
+ The value of **Path Pattern** matches the path to your custom error messages. For example, suppose you saved custom error pages for 4xx errors in an Amazon S3 bucket in a directory named `/4xx-errors`. Your distribution must include a cache behavior for which the path pattern routes requests for your custom error pages to that location, for example, **/4xx-errors/\$1**.
+ The value of **Origin** specifies the value of **Origin ID** for the origin that contains your custom error pages.
## HTTP response code
The HTTP status code that you want CloudFront to return to the viewer along with the custom error page.
## Error caching minimum TTL (seconds)
The minimum amount of time that you want CloudFront to cache error responses from your origin server.
# Geographic restrictions
If you need to prevent users in selected countries from accessing your content, you can configure your CloudFront distribution with an **Allowlist** or a **Block list**. There is no additional charge for configuring geographic restrictions. For more information, see [Restrict the geographic distribution of your content](georestrictions.md).