AWS services or capabilities described in AWS documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with AWS services in China.

Values That You Specify When You Create or Update a Distribution

When you use the CloudFront console to create a new distribution or update an existing distribution, you specify the following values.

For more information about creating or updating a distribution by using the CloudFront console, see Creating a Distribution or Updating a Distribution.

Origin Settings

The following values apply to all types of origins:

The following values apply only to Amazon S3 origins (those that are not using the S3 static website endpoint):

The following values apply only to custom origins, such as Amazon EC2 instances, Elastic Load Balancing load balancers, MediaPackage origins, MediaStore containers, or your own web server:

Cache Behavior Settings

The following values apply to the Default Cache Behavior Settings (when you create a distribution) and to other cache behaviors that you create later.

The following values apply to Lambda Function Associations.

Distribution Settings

Custom Error Pages and Error Caching

Restrictions

Origin Settings

When you 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 world-wide network of edge servers. Each origin is either an Amazon S3 bucket or an HTTP server, for example, a web server.

For the current maximum number of origins that you can create for a distribution, or to request a higher quota (formerly known as limit), see General Quotas on Distributions.

If you want to delete an origin, you must first edit or delete the cache behaviors that are associated with that origin.

When you create or update a distribution, you specify the following values for each origin.

Origin Domain Name

The DNS domain name of the Amazon S3 bucket or HTTP server from which you want CloudFront to get objects for this origin, for example:

Choose the domain name in the Origin Domain Name field, or type the name. The domain name is not case-sensitive.

If your origin is an Amazon S3 bucket, note the following:

When you change the value of Origin Domain Name 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 HTTP server or Amazon S3 bucket. As soon as the distribution configuration is updated in that edge location, CloudFront begins to forward requests to the new HTTP server or Amazon S3 bucket.

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.

Origin Path

If you want CloudFront to request your content from a directory in your AWS resource or your custom origin, enter the directory path, beginning with a slash (/). CloudFront appends the directory path to the value of Origin Domain Name, 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:

When a user enters example.com/index.html in a browser, CloudFront sends a request to Amazon S3 for myawsbucket/production/index.html.

When a user enters example.com/acme/index.html in a browser, CloudFront sends a request to Amazon S3 for myawsbucket/production/acme/index.html.

Origin ID

A string that uniquely distinguishes this origin or origin group in this distribution. If you create cache behaviors in addition to the default cache behavior, you use the ID that you specify here to identify the origin or origin group that you want CloudFront to route a request to when the request matches the path pattern for that cache behavior.

For more information, see the following:

Origin Connection Attempts

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 Origin 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:

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 Origin Response Timeout.

Origin Connection Timeout

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 Origin 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:

Origin Custom Headers

If you want CloudFront to add custom headers whenever it sends a request to your origin, specify the following values:

For more information, see Adding custom headers to origin requests.

For the current maximum number of custom headers that you can forward to the origin, the maximum length of a custom header name and value, and the maximum total length of all header names and values, see Quotas.

Restrict Bucket Access

Choose Yes if you want to require users to access objects in an Amazon S3 bucket by using only CloudFront URLs, not by using Amazon S3 URLs. Then specify additional values.

Choose No if you want users to be able to access objects by using either CloudFront URLs or Amazon S3 URLs.

For more information, see Restricting Access to Amazon S3 Content by Using an Origin Access Identity.

For information about how to require users to access objects on a custom origin by using only CloudFront URLs, see Restricting access to files on custom origins.

Origin Access Identity

If you chose Yes for Restrict Bucket Access, choose whether to create a new origin access identity or use an existing one that is associated with your AWS account. If you already have an origin access identity, we recommend that you reuse it to simplify maintenance. For more information about origin access identities, see Restricting Access to Amazon S3 Content by Using an Origin Access Identity.

Comment

If you chose Create a New Identity for Origin Access Identity, enter a comment that identifies the new origin access identity. CloudFront creates the origin access identity when you create this distribution.

Your Identities

If you chose Use an Existing Identity for Origin Access Identity, choose the origin access identity that you want to use. You cannot use an origin access identity that is associated with another AWS account.

Grant Read Permissions on Bucket

If you want CloudFront to automatically grant the origin access identity the permission to read objects in your Amazon S3 bucket, choose Yes, Update Bucket Policy.

If you want to update permissions manually, for example, if you want to update ACLs on your objects instead of updating bucket permissions, choose No, I will Update Permissions.

Minimum Origin SSL Protocol

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.

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 in the Amazon CloudFront API Reference.

Origin Protocol Policy

The protocol policy that you want CloudFront to use when fetching objects from your origin server.

Choose one of the following values:

Origin Response Timeout

The origin response timeout, also known as the origin read timeout or origin request timeout, applies to both of the following values:

The default timeout is 30 seconds. You can change the value to be from 1 to 60 seconds. If you need a timeout value outside that range, create a case in the AWS Support Center.

CloudFront behavior depends on the HTTP method in the viewer request:

Origin Keep-alive Timeout

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.

The default timeout is 5 seconds. You can change the value to a number from 1 to 60 seconds. If you need a keep-alive timeout longer than 60 seconds, create a case in the AWS Support Center.

HTTP Port

Optional. The HTTP port that the custom origin listens on. Valid values include ports 80, 443, and 1024 to 65535. The default value is port 80.

HTTPS Port

Optional. The HTTPS port that the custom origin listens on. Valid values include ports 80, 443, and 1024 to 65535. The default value is port 443.

Cache Behavior Settings

A cache behavior lets you 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:

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.

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.

Path Pattern

A path pattern (for example, images/*.jpg) specifies which requests you want this cache behavior to apply to. 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:

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.

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 Serving Live Video Formatted with AWS Elemental 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:

The following examples show how the wildcard characters work:

The maximum length of a path pattern is 255 characters. The value can contain any of the following characters:

Origin or Origin Group

Enter the value of an existing origin or origin group. This identifies the origin or origin group that you want CloudFront to route requests to when a request (such as https://example.com/logo.jpg) matches the path pattern for a cache behavior (such as *.jpg) or for the default cache behavior (*).

Viewer Protocol Policy

Choose the protocol policy that you want viewers to use to access your content in CloudFront edge locations:

For more information, see Requiring HTTPS for Communication Between Viewers and CloudFront.

Allowed HTTP Methods

Specify the HTTP methods that you want CloudFront to process and forward to your origin:

If you use an Amazon S3 bucket as the origin for your distribution and if you use CloudFront origin access identities, POST requests aren't supported in some Amazon S3 Regions and PUT requests in those Regions require an additional header. For more information, see Using an OAI in Amazon S3 Regions that Support Only Signature Version 4 Authentication.

Field Level Encryption Config

If you want to enforce field-level encryption on specific data fields, in the drop-down list, choose a field-level encryption configuration.

For more information, see Using Field-Level Encryption to Help Protect Sensitive Data.

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.

Cache Based on Selected Request Headers

Specify whether you want CloudFront to cache objects based on the values of specified headers:

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 S3 Origins).

For more information about how to configure caching in CloudFront by using request headers, see Caching content based on request headers.

Whitelist 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 whitelist for each cache behavior, or to request a higher quota (formerly known as limit), see Quotas on 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 Managing how long content stays in the cache (expiration).

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.

For more information, see Managing how long content stays in the cache (expiration).

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 Managing how long content stays in the cache (expiration).

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 Managing how long content stays in the cache (expiration).

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

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 (a whitelist of cookies), enter the cookie names in the Whitelist 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 cacheability. 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 Caching content based on cookies.

Whitelist Cookies

If you chose Whitelist in the Forward Cookies list, then in the Whitelist 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:

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 whitelist for each cache behavior, or to request a higher quota (formerly known as limit), see Quotas on Whitelisted 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:

For more information about caching based on query string parameters, including how to improve performance, see Caching content based on query string parameters.

Query String Whitelist

If you chose Forward all, cache based on whitelist for Query String Forwarding and Caching, 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.

For more information, see Configuring Video on Demand for Microsoft Smooth Streaming.

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 Specifying the signers that can create signed URLs and signed cookies.

Trusted Signers

Choose which AWS accounts you want to use as trusted signers for this cache behavior:

To create signed URLs, an AWS account must have at least one active CloudFront key pair.

AWS Account Numbers

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:

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 webpages render faster for your users. For more information, see Serving compressed files.

CloudFront Event

You can choose to run a Lambda function when one or more of the following CloudFront events occur:

For more information, see How to Decide Which CloudFront Event to Use to Trigger a Lambda Function.

Lambda Function ARN

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.

Distribution Settings

The following values apply to the entire distribution.

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 Choosing the price class for a CloudFront distribution. For information about CloudFront pricing, including how price classes map to CloudFront Regions, go to Amazon CloudFront Pricing.

AWS WAF Web ACL

If you want to use AWS WAF to allow or block requests based on criteria that you specify, choose the web ACL to associate with this distribution.

AWS WAF is a web application firewall that lets you monitor the HTTP and HTTPS requests that are forwarded to CloudFront, and lets you control access to your content. Based on conditions that you specify, such as the IP addresses that requests originate from or the values of query strings, CloudFront responds to requests either with the requested content or with an HTTP 403 status code (Forbidden). You can also configure CloudFront to return a custom error page when a request is blocked. For more information about AWS WAF, see the AWS WAF Developer Guide.

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:

http://www.example.com/images/image.jpg

Instead of like this:

http://d111111abcdef8.cloudfront.net/images/image.jpg

Add a CNAME for www.example.com.

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.

For more information about alternate domain names, see Using Custom URLs for Files by Adding Alternate Domain Names (CNAMEs). For more information about CloudFront URLs, see Customizing the URL Format for Files in CloudFront.

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.

Custom SSL Client Support

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:

For more information, see Choosing How CloudFront Serves HTTPS Requests.

Security Policy

Specify the security policy that you want CloudFront to use for HTTPS connections with viewers (clients). A security policy determines two settings:

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.

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):

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 TLS 1.2 or later, and must support Server Name Identification (SNI).

In general, configuring CloudFront to communicate with viewers using HTTP/2 reduces latency. You can improve performance by optimizing for HTTP/2. For more information, do an internet search for "http/2 optimization."

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 (http://www.example.com/) instead of an object in your distribution (http://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:

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 Specifying a Default Root Object.

Logging

Whether you want CloudFront to log information about each request for an object and store the log files in an Amazon S3 bucket. You can enable or disable logging at any time. There is no extra charge if you enable logging, but you accrue the usual Amazon S3 charges for storing and accessing the files in an Amazon S3 bucket. You can delete the logs at any time. For more information about CloudFront access logs, see Configuring and using standard logs (access logs).

Bucket for Logs

If you chose On for Logging, the Amazon S3 bucket that you want CloudFront to store access logs in, for example, myLogs-.s3.amazonaws.com.

If you enable logging, CloudFront records information about each end-user request for an object and stores the files in the specified Amazon S3 bucket. You can enable or disable logging at any time. For more information about CloudFront access logs, see Configuring and using standard logs (access logs).

Log Prefix

Optional. If you chose On for Logging, 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 about CloudFront access logs, see Configuring and using standard logs (access logs).

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, go to Caching content based on cookies.

Enable IPv6

IPv6 is a new version of the IP protocol. It's the eventual replacement for IPv4 and uses a larger address space. CloudFront always responds to IPv4 requests. If you want CloudFront to respond to requests from IPv4 IP addresses (such as 192.0.2.44) and requests from IPv6 addresses (such as 2001:0db8:85a3:0000:0000:8a2e:0370:7334), select Enable IPv6.

In general, you should enable IPv6 if you have users on IPv6 networks who want to access your content. However, if you're using signed URLs or signed cookies to restrict access to your content, and if you're using a custom policy that includes the IpAddress parameter to restrict the IP addresses that can access your content, do not enable IPv6. If you want to restrict access to some content by IP address and not restrict access to other content (or restrict access but not by IP address), you can create two distributions. For information about creating signed URLs by using a custom policy, see Creating a signed URL using a custom policy. For information about creating signed cookies by using a custom policy, see Setting signed cookies using a custom policy.

If you're using a Route 53 alias resource record set to route traffic to your CloudFront distribution, you need to create a second alias resource record set when both of the following are true:

For more information, see Routing traffic to an Amazon CloudFront distribution by using your domain name in the Amazon Route 53 Developer Guide.

If you created a CNAME resource record set, either with Route 53 or with another DNS service, you don't need to make any changes. A CNAME record routes traffic to your distribution regardless of the IP address format of the viewer request.

If you enable IPv6 and CloudFront access logs, the c-ip column includes values in IPv4 and IPv6 format. For more information, see Configuring and using standard logs (access logs).

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:

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 Updating a Distribution.

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 Creating a custom error page for specific HTTP status codes.

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.

Error Caching Minimum TTL (seconds)

The minimum amount of time that you want CloudFront to cache error responses from your origin server.

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:

HTTP Response Code

The HTTP status code that you want CloudFront to return to the viewer along with the custom error page.

Restrictions

If you need to prevent users in selected countries from accessing your content, you can configure your CloudFront distribution either to allow users in a whitelist of specified countries to access your content or to not allow users in a blacklist of specified countries to access your content. For more information, see Restricting the Geographic Distribution of Your Content.

Enable Geo-Restriction

Whether you want to prevent users in selected countries from accessing your content. There is no additional charge for configuring geo restriction.

Restriction Type

How you want to specify the countries from which your users can access your content:

Countries

The countries that you want to add to your whitelist or blacklist. To add a country, select it in the list on the left and choose Add. Note the following: