# Configure distributions
You create an Amazon CloudFront distribution to tell CloudFront from where you want content to be delivered, and the details about how to track and manage content delivery.
When you create your CloudFront distribution, CloudFront automatically configures most distribution settings for you, based on your content origin type. For more details about the preconfigured settings, see [Preconfigured distribution settings reference](template-preconfigured-origin-settings.md). Optionally, you can choose to manually edit your distribution settings. For more information, see [All distribution settings reference](distribution-web-values-specify.md).
The following settings can be configured:
+ **Your content origin**—The Amazon S3 bucket, AWS Elemental MediaPackage channel, AWS Elemental MediaStore container, Elastic Load Balancing load balancer, or HTTP server from which CloudFront gets the files to distribute. You can specify any combination of up to 25 origins for a single distribution.
+ **Access**—Whether you want access to the files to be available to everyone or restricted to some users.
+ **Security**—Whether you want to enable AWS WAF protection and require users to use HTTPS to access your content. For multi-tenant distributions, only AWS WAF V2 web access control lists (ACLs) are supported.
+ **Cache key**—Which values, if any, you want to include in the *cache key*. The cache key uniquely identifies each file in the cache for a given distribution.
+ **Origin request settings**—Whether you want CloudFront to include HTTP headers, cookies, or query strings in requests that it sends to your origin.
+ **Geographic restrictions**—Whether you want CloudFront to prevent users in selected countries from accessing your content.
+ **Logs**—Whether you want CloudFront to create standard logs or real-time access logs that show viewer activity.
For more information, see [All distribution settings reference](distribution-web-values-specify.md).
For the current maximum number of distributions that you can create for each AWS account, see [General quotas on distributions](cloudfront-limits.md#limits-web-distributions). There is no maximum number of files that you can serve per distribution.
You can use distributions to serve the following content over HTTP or HTTPS:
+ Static and dynamic download content, such as HTML, CSS, JavaScript, and image files, using HTTP or HTTPS.
+ Video on demand in different formats, such as Apple HTTP Live Streaming (HLS) and Microsoft Smooth Streaming. (For multi-tenant distributions, Smooth Streaming is not supported.) For more information, see [Deliver video on demand with CloudFront](on-demand-video.md).
+ A live event, such as a meeting, conference, or concert, in real time. For live streaming, you can create the distribution automatically by using an CloudFormation stack. For more information, see [Deliver video streaming with CloudFront and AWS Media Services](live-streaming.md).
The following topics provide more details about CloudFront distributions and how to configure them to meet your business needs. For more information about creating a distribution, see [Create a distribution](distribution-web-creating-console.md).
**Topics**
+ [
# Understand how multi-tenant distributions work
](distribution-config-options.md)
+ [
# Create a distribution
](distribution-web-creating-console.md)
+ [
# Preconfigured distribution settings reference
](template-preconfigured-origin-settings.md)
+ [
# All distribution settings reference
](distribution-web-values-specify.md)
+ [
# Test a distribution
](distribution-web-testing.md)
+ [
# Update a distribution
](HowToUpdateDistribution.md)
+ [
# Tag a distribution
](tagging.md)
+ [
# Delete a distribution
](HowToDeleteDistribution.md)
+ [
# Use various origins with CloudFront distributions
](DownloadDistS3AndCustomOrigins.md)
+ [
# Enable IPv6 for CloudFront distributions
](cloudfront-enable-ipv6.md)
+ [
# Use CloudFront continuous deployment to safely test CDN configuration changes
](continuous-deployment.md)
+ [
# Use custom URLs by adding alternate domain names (CNAMEs)
](CNAMEs.md)
+ [
# Use WebSockets with CloudFront distributions
](distribution-working-with.websockets.md)
+ [
# Request Anycast static IPs to use for allowlisting
](request-static-ips.md)
+ [
# Using gRPC with CloudFront distributions
](distribution-using-grpc.md)
# Understand how multi-tenant distributions work
Added support for multi-tenant distribution and distribution tenants
You can create a multi-tenant distribution to set common distribution settings based on your origin type. Then, you can reuse the multi-tenant distribution to create multiple distribution tenants that share those settings. You can then customize specific distribution tenants as you add additional websites or applications.
You can create CloudFront multi-tenant distributions with settings that can be reused across multiple distribution tenants. With a multi-tenant distribution, you can have CloudFront configure your distribution settings for you, based on your content origin type. For more details about the preconfigured settings, see [Preconfigured distribution settings reference](template-preconfigured-origin-settings.md).
Benefits of using a multi-tenant distribution instead of a standard distribution include:
+ Reducing operational burden.
+ Reusable configurations for web admins and software providers to manage CloudFront distribution for multiple web applications that deliver content to end users.
+ Enhanced integrations with other AWS services to deliver automated certificate management, unified security controls, and hassle-free configuration control at scale.
+ Maintaining consistent resource patterns across your implementations. Define settings that must be shared and then specify customizations for settings to override.
+ Customizable origin and security settings to meet specific needs at the distribution tenant level.
+ Organize your distribution tenants into different tiers. For example, if some distribution tenants require Origin Shield and some do not, you can group distribution tenants into different multi-tenant distributions.
+ Sharing a common DNS configuration across multiple domains.
Unlike a standard distribution, a multi-tenant distribution cannot be accessed directly because it has no CloudFront routing endpoint. Therefore, it must be used in conjunction with a connection group and one or more distribution tenants. While standard distributions have their own CloudFront endpoint and can be directly accessed by end users, they cannot be used as a template for other distributions.
For information about multi-tenant distribution quotas, see [Quotas on multi-tenant distributions](cloudfront-limits.md#limits-template).
**Topics**
+ [
## How it works
](#how-template-distribution-works)
+ [
## Terms
](#template-distributions-concepts)
+ [
## Unsupported features
](#unsupported-saas)
+ [
# Distribution tenant customizations
](tenant-customization.md)
+ [
# Request certificates for your CloudFront distribution tenant
](managed-cloudfront-certificates.md)
+ [
# Create custom connection group (optional)
](custom-connection-group.md)
+ [
# Migrate to a multi-tenant distribution
](template-migrate-distribution.md)
## How it works
In a *standard distribution*, the distribution contains all the settings that you want to enable for your website or application, such as the origin configurations, cache behaviors, and security settings. If you wanted to create a separate website and use many of the same settings, you would need to create a new distribution each time.
CloudFront multi-tenant distributions are different in that you can create an initial multi-tenant distribution. For each new website, you create a distribution tenant that automatically inherits the defined values of its source distribution. Then, you customize specific settings for your distribution tenant.
**Overview**
1. To get started, you first create a multi-tenant distribution. CloudFront configures your distribution settings for you, based on your content origin type. You can customize settings for all origins except VPC origins. VPC origins settings are customized on the VPC origin resource itself. For more information about the multi-tenant distribution settings that you can customize, see [Preconfigured distribution settings reference](template-preconfigured-origin-settings.md).
+ The TLS certificate that you use for the multi-tenant distribution can be inherited by your distribution tenants. The multi-tenant distribution itself is not routable, so it will not have a domain name associated with it.
1. By default, CloudFront creates a connection group for you. The connection group controls how viewer requests for content connect to CloudFront. You can customize some routing settings in the connection group.
You can change this by manually creating your own connection group. For more information, see [Create custom connection group (optional)](custom-connection-group.md).
1. Then, you create one or more distribution tenants. The distribution tenant is the "front door" for viewers to access your content. Each distribution tenant references the multi-tenant distribution and is automatically associated with the connection group that CloudFront created for you. The distribution tenant supports an individual domain or subdomain.
1. You can then customize some distribution tenant settings, such as vanity domains and origin paths. For more information, see [Distribution tenant customizations](tenant-customization.md).
1. Finally, you must update the DNS record in your DNS host to route traffic to the distribution tenant. To do this, get the CloudFront endpoint value from your connection group and create a CNAME record that points to the CloudFront endpoint.
**Example**
The following graphic demonstrates how a multi-tenant distribution,distribution tenants, and connection groups work together to deliver content for your viewers for multiple domains.
1. The multi-tenant distribution defines the inherited settings for each distribution tenant. You use the multi-tenant distribution as a template.
1. Each distribution tenant created from the multi-tenant distribution has its own domain.
1. The distribution tenants are automatically added to the connection group that CloudFront created for you when you created the multi-tenant distribution. Connection groups control how viewer requests are connected to the CloudFront network.
![\[How multi-tenant distributions work with distribution tenants.\]](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/images/template_distribution.png)
For detailed multi-tenant distribution creation instructions, see [Create a CloudFront distribution in the console](distribution-web-creating-console.md#create-console-distribution).
## Terms
The following concepts describe components of multi-tenant distributions:
**Multi-tenant distribution**
A blueprint, multi-tenant distribution that specifies all shared configuration settings for any distribution tenants, including cache behavior, security protections, and origins. Multi-tenant distributions cannot serve traffic directly. They must be used in conjunction with connection groups and distribution tenants.
**Standard distribution**
A distribution that does not have multi-tenant functionality. These distributions are best for supporting single websites or apps.
**Distribution tenant**
A distribution tenant inherits the multi-tenant distribution configuration. Some configuration settings can be customized at the distribution tenant level. The distribution tenant must have a valid TLS certificate, which can be inherited from the multi-tenant distribution as long as it covers the distribution tenant domain or subdomain.
The distribution tenant must be associated with a connection group. CloudFront creates a connection group for you when you create a distribution tenant, and automatically assigns any distribution tenants to that connection group.
**Multi-tenancy**
You can use the multi-tenant distribution to serve content across multiple domains, while sharing configuration and infrastructure. This approach allows different domains (called tenants) to share common settings from the multi-tenant distribution, while maintaining their own customizations.
**Connection group**
Provides the CloudFront routing endpoint that serves content to viewers. You must associate each distribution tenant to a connection group to get the corresponding CloudFront routing endpoint for the CNAME record that you create for your distribution tenant domain or subdomain. Connection groups can be shared across multiple distribution tenants. Connection groups manage routing settings for distribution tenants, such as IPv6 and Anycast IP list settings.
**Parameters**
A list of key-value pairs for placeholder values, such as origin paths and domain names. You can define parameters in your multi-tenant distribution and provide values for those parameters at the distribution tenant level. You choose whether the parameter values are required to be entered for the distribution tenant.
If you do not provide a value for an optional parameter in a distribution tenant, then the default value from the multi-tenant distribution is used as the value.
**CloudFront routing endpoint**
Canonical DNS for the connection group, such as `d123.cloudfront.net`. Used in the CNAME record for your distribution tenant domain or subdomain.
**Customizations**
You can customize your distribution tenants so that they use *different* settings from the multi-tenant distribution. For each distribution tenant, you can specify a different AWS WAF web access control list (ACL), TLS certificates, and geographic restrictions.
## Unsupported features
The following features can't be used with a multi-tenant distribution. If you want to create a new multi-tenant distribution using the same settings as your standard distribution, note that some settings aren't available.
**Notes**
Currently, AWS Firewall Manager policies only apply to your standard distributions. Firewall Manager will add support for multi-tenant distributions in a future release.
Unlike standard distributions, you specify your domain name (alias) at the *distribution tenant* level. For more information, see [Request certificates for your CloudFront distribution tenant](managed-cloudfront-certificates.md) and the [CreateDistributionTenant](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistributionTenant.html) API operation.
+ [Continuous deployment](continuous-deployment.md)
+ [Origin access identity (OAI)](private-content-restricting-access-to-s3.md#private-content-restricting-access-to-s3-oai) – Use [origin access control (OAC)](private-content-restricting-access-to-origin.md) instead.
+ [Dedicated IP custom SSL support](DownloadDistValuesGeneral.md#DownloadDistValuesClientsSupported) – Only the `sni-only` method is supported.
+ [AWS WAF Classic (V1) web ACL](DownloadDistValuesGeneral.md#DownloadDistValuesWAFWebACL) – Only AWS WAF V2 web ACLs are supported.
+ [Standard logging (legacy)](standard-logging-legacy-s3.md)
+ [Minimum TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL)
+ [Default TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesDefaultTTL)
+ [Maximum TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL)
+ [ForwardedValues](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ForwardedValues.html)
+ [PriceClass](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DistributionConfig.html)
+ [Trusted Signers ](DownloadDistValuesCacheBehavior.md#DownloadDistValuesTrustedSigners)
+ [Smooth streaming](DownloadDistValuesCacheBehavior.md#DownloadDistValuesSmoothStreaming)
+ [AWS Identity and Access Management (IAM) server certificates](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_server-certs.html)
+ [Dedicated IP addresses](cnames-https-dedicated-ip-or-sni.md#cnames-https-dedicated-ip)
+ [Minimum Protocol Version SSLv3](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy)
The following settings can't be configured in a multi-tenant distribution or distribution tenant. Instead, set the values that you want in a connection group. All distribution tenants associated in the connection group will use these settings. For more information, see [Create custom connection group (optional)](custom-connection-group.md).
+ [Enable IPv6 (viewer requests)](DownloadDistValuesGeneral.md#DownloadDistValuesEnableIPv6)
+ [Anycast static IP list](request-static-ips.md)
# Distribution tenant customizations
Added example parameters[https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/tenant-customization.html#examples-parameters](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/tenant-customization.html#examples-parameters)
Added examples for using parameters with domain names and origin paths in distribution tenants.
When using a multi-tenant distribution, your distribution tenants inherit the multi-tenant distribution configuration. However, you can customize some settings at the distribution tenant level.
You can customize the following:
+ **Parameters** – Parameters are key-value pairs that you can use for the origin domain or origin paths. See [How parameters work with distribution tenants](#tenant-customize-parameters).
+ **AWS WAF web ACL (V2)** – You can specify a separate web ACL for the distribution tenant, which will *override* the web ACL used for the multi-tenant distribution. You can also disable this setting for a specific distribution tenant, which means the distribution tenant won't inherit the web ACL protections from the multi-tenant distribution. For more information, see [AWS WAF web ACL](DownloadDistValuesGeneral.md#DownloadDistValuesWAFWebACL).
+ **Geographic restrictions **– Geographic restrictions that you specify for a distribution tenant will *override* any geographic restrictions for the multi-tenant distribution. For example, if you block Germany (DE) in your multi-tenant distribution, all associated distribution tenants will also block DE. However, if you allow DE for a specific distribution tenant, that distribution tenant settings will override the settings for the multi-tenant distribution. For more information, see [Restrict the geographic distribution of your content](georestrictions.md).
+ **Invalidation paths** – Specify the file paths to the content that you want to invalidate for the distribution tenant. For more information, see [Invalidate files](Invalidation_Requests.md).
+ **Custom TLS certificates** – AWS Certificate Manager (ACM) certificates that you specify for distribution tenants are supplemental to the certificate provided in the multi-tenant distribution. However, if the same domain is covered by both the multi-tenant distribution and distribution tenant certificates, then the tenant certificate is used. For more information, see [Request certificates for your CloudFront distribution tenant](managed-cloudfront-certificates.md).
+ **Domain names** – You must specify at least one domain name per distribution tenant.
## How parameters work with distribution tenants
A parameter is a key-value pair that you can use for placeholder values. Define the parameters that you want to use in your multi-tenant distribution and specify whether they're required.
When you define parameters in your multi-tenant distribution, you choose whether those parameters are required to be entered at the distribution tenant level.
+ If you define the parameters as *required* in the multi-tenant distribution, then they must be entered at the distribution tenant level. (They are not inherited).
+ If the parameters are *not required*, then you can provide a default value in the multi-tenant distribution that is inherited by the distribution tenant.
You can use parameters in the following properties:
+ Origin domain name
+ Origin path
In the multi-tenant distribution, you can define up to two parameters for each of the preceding properties.
## Example parameters
See the following examples for using parameters for the domain name and origin path.
**Domain name parameters**
In the multi-tenant distribution configuration, you can define a parameter for the origin domain name like the following examples:
**Amazon S3**
+ `{{parameter1}}.amzn-s3-demo-logging-bucket.s3.us-east-1.amazonaws.com`
+ `{{parameter1}}–amzn-s3-demo-logging-bucket.s3.us-east-1.amazonaws.com`
**Custom origins**
+ `{{parameter1}}.lambda-url.us-east-1.on.aws`
+ `{{parameter1}}.mediapackagev2.ap-south-1.amazonaws.com`
When you create a distribution tenant, specify the value to use for `parameter1`.
```
"Parameters": [
{
"Name": "parameter1",
"Value": "mycompany-website"
}
]
```
Using the previous examples specified in the multi-tenant distribution, the origin domain name for the distribution tenant resolves to the following:
+ `mycompany-website.amzn-s3-demo-bucket3.s3.us-east-1.amazonaws.com`
+ `mycompany-website–amzn-s3-demo-bucket3.s3.us-east-1.amazonaws.com`
+ `mycompany-website.lambda-url.us-east-1.on.aws`
+ `mycompany-website.mediapackagev2.ap-south-1.amazonaws.com`
**Origin path parameters**
Similarly, you can define parameters for the origin path in the multi-tenant distribution like the following examples:
+ `/{{parameter2}}`
+ `/{{parameter2}}/test`
+ `/public/{{parameter2}}/test`
+ `/search?name={{parameter2}}`
When you create a distribution tenant, specify the value to use for `parameter2`.
```
"Parameters": [
{
"Name": "parameter2",
"Value": "myBrand"
}
]
```
Using the previous examples specified in the multi-tenant distribution, the origin path for the distribution tenant resolves to the following:
+ `/myBrand`
+ `/myBrand/test`
+ `/public/myBrand/test`
+ `/search?name=myBrand`
**Example**
You want to create multiple websites (tenants) for your customers, and you need to ensure that each distribution tenant resource uses the correct values.
1. You create a multi-tenant distribution and include two parameters for the distribution tenant configuration.
1. For the origin domain name, you create a parameter named *customer-name* and specify that it's required. You enter the parameter before the S3 bucket, so that it appears as:
`{{customer-name}}.amzn-s3-demo-bucket3.s3.us-east-1.amazonaws.com`.
1. For origin path, you create a second parameter named *my-theme*, and specify that it's optional, with a default value of *basic*. Your origin path appears as: `/{{my-theme}}`
1. When you create a distribution tenant:
+ For domain name, you must specify a value for *customer-name*, because it's marked as required in the multi-tenant distribution.
+ For origin path, you can optionally specify a value for *my-theme* or use the default value.
# Request certificates for your CloudFront distribution tenant
Request certificates (distribution tenant)
When you create a distribution tenant, the tenant inherits the shared AWS Certificate Manager (ACM) certificate from the multi-tenant distribution. This shared certificate provides HTTPS for all tenants associated with the multi-tenant distribution.
When you create or update a CloudFront distribution tenant to add domains, you can add a managed CloudFront certificate from ACM. CloudFront then gets an HTTP-validated certificate from ACM on your behalf. You can use this tenant-level ACM certificate for custom domain configurations. CloudFront streamlines the renewal workflow to help keep certificates up-to-date and secure content delivery uninterrupted.
**Note**
You own the certificate, but it can *only* be used with CloudFront resources and the private key *cannot* be exported.
You can request the certificate when you create or update the distribution tenant.
**Topics**
+ [
## Add a domain and certificate (distribution tenant)
](#vanity-domain-tls-tenant)
+ [
## Complete domain setup
](#complete-domain-ownership)
+ [
## Point domains to CloudFront
](#point-domains-to-cloudfront)
+ [
## Domain considerations (distribution tenant)
](#tenant-domain-considerations)
+ [
## Wildcard domains (distribution tenant)
](#tenant-wildcard-domains)
## Add a domain and certificate (distribution tenant)
The following procedure shows you how to add a domain and update the certificate for a distribution tenant.
**To add a domain and certificate (distribution tenant)**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Under **SaaS**, choose **Distribution tenants**.
1. Search for the distribution tenant. Use the dropdown menu in the search bar to filter by domain, name, distribution ID, certificate ID, connection group ID, or web ACL ID.
1. Choose the distribution tenant name.
1. For **Domains**, choose **Manage domain**.
1. For **Certificate**, choose if you want a **Custom TLS certificate** for your distribution tenant. The certificate verifies whether you're authorized to use the domain name. The certificate must exist in the US East (N. Virginia) Region.
1. For **Domains**, choose **Add domain** and enter the domain name. Depending on your domain, the following messages will appear under the domain name that you enter.
+ This domain is covered by the certificate.
+ This domain is covered by the certificate, pending validation.
+ This domain isn't covered by a certificate. (This means you must verify domain ownership.)
1. Choose **Update distribution tenant**.
On the tenant details page, under **Domains**, you can see the following fields:
+ **Domain ownership** – The status of domain ownership. Before CloudFront can serve content, your domain ownership must be verified by using TLS certificate validation.
+ **DNS status** – Your domain's DNS records must point to CloudFront to route traffic correctly.
1. If your domain ownership isn't verified, on the tenant details page, under **Domains**, choose **Complete domain setup** and then complete the following procedure to point the DNS record to your CloudFront domain name.
## Complete domain setup
Follow these procedures to verify that you own the domain for your distribution tenants. Depending on your domain, choose one of the following procedures.
**Note**
If your domain is already pointed to CloudFront with an Amazon Route 53 alias record, you must add your DNS TXT record with `_cf-challenge.` in front of the domain name. This TXT record verifies that your domain name is linked to CloudFront. Repeat this step for each domain. The following shows how to update your TXT record:
Record name: `_cf-challenge.DomainName`
Record type: `TXT`
Record value: `CloudFrontRoutingEndpoint`
For example, your TXT record might look like: `_cf-challenge.example.com TXT d111111abcdef8.cloudfront.net`
You can find your CloudFront routing endpoint in the console on the distribution tenant detail page or use the [ListConnectionGroups](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListConnectionGroups.html) API action in the *Amazon CloudFront API Reference* to find it.
**Tip**
If you're a SaaS provider and you want to allow certificate issuance without requiring your customers (tenants) to add a TXT record directly to their DNS, do the following:
If you own the domain `example-saas-provider.com`, assign subdomains to your tenants, such as `customer-123.example-saas-provider.com`
In your DNS, add the `_cf-challenge.customer-123.example-saas-provider.com TXT d111111abcdef8.cloudfront.net` TXT record to your DNS configuration.
Next, your customers (the tenants) can then update their own DNS record to map their domain name to the subdomain that you provided.
`www.customer-domain.com CNAME customer-123.example-saas-provider.com`
------
#### [ I have existing traffic ]
Select this option if your domain can't tolerate downtime. You must have access to your origin/web server. Use the following procedure to validate domain ownership.
**To complete domain setup when you have existing traffic**
1. For **Specify your web traffic**, choose **I have existing traffic** and then choose **Next**.
1. For **Verify domain ownership**, choose one of the following options:
+ **Use existing certificate** – Search for an existing ACM certificate or enter the certificate ARN that covers the listed domains.
+ **Manual file upload** – Choose if you have direct access to upload files to your web server.
For each domain, create a plain text file that contains your validation token from the **Token location** and upload it to your origin at the specified **File path** on your existing server. The path to this file might look like the following example: `/.well-known/pki-validation/acm_9c2a7b2ec0524d09fa6013efb73ad123.txt`. After you complete that step, ACM verifies the token and then issues the TLS certificate for the domain.
+ **HTTP redirect** – Choose if you don't have direct access to upload files to your web server, or if you're using a CDN or proxy service.
For each domain, create a 301 redirect on your existing server. Copy the well-known path under **Redirect from** and point to the specified certificate endpoint under **Redirect to**. Your redirect might look like the following example:
```
If the URL matches: example.com/.well-known/pki-validation/leabe938a4fe077b31e1ff62b781c123.txt
Then the settings are:Forwarding URL
Then 301 Permanent Redirect:To validation.us-east-1.acm-validations.aws/123456789012/.well-known/pki-validation/leabe938a4fe077b31e1ff62b781c123.txt
```
**Note**
You can choose **Check certificate status** to verify when ACM issues the certificate for the domain.
1. Choose **Next**.
1. Complete the steps for [Point domains to CloudFront](#point-domains-to-cloudfront).
------
#### [ I don't have traffic ]
Select this option if you're adding new domains. CloudFront will manage certificate validation for you.
**To complete domain setup if you don't have traffic**
1. For **Specify your web traffic**, choose **I don't have traffic yet**.
1. For each domain name, complete the steps for [Point domains to CloudFront](#point-domains-to-cloudfront).
1. After you update your DNS records for each domain name, choose **Next**.
1. Wait for the certificate to be issued.
**Note**
You can choose **Check certificate status** to verify when ACM issues the certificate for the domain.
1. Choose **Submit**.
------
## Point domains to CloudFront
Update your DNS records to route traffic from each domain to the CloudFront routing endpoint. You can have multiple domain names, but they must all resolve to this endpoint.
**To point domains to CloudFront**
1. Copy the CloudFront routing endpoint value, such as d111111abcdef8.cloudfront.net.
1. Update your DNS records to route traffic from each domain to the CloudFront routing endpoint.
1. Sign in to your domain registrar or DNS provider management console.
1. Navigate to the DNS management section for your domain.
+ **For subdomains** – Create a CNAME record. For example:
+ **Name** – Your subdomain (such as `www` or `app`)
+ **Value / Target** – The CloudFront routing endpoint
+ **Record type** – CNAME
+ **TTL** – 3600 (or whatever is appropriate for your use case)
+ **For apex/root domains** – This requires a unique DNS configuration, because standard CNAME records can’t be used at the root or apex domain level. Because most DNS providers don’t support ALIAS records, we recommend creating an ALIAS record in Route 53. For example:
+ **Name ** – Your apex domain (such as `example.com`)
+ **Record type** – A
+ **Alias** – Yes
+ **Alias target** – Your CloudFront routing endpoint
+ **Routing policy** – Simple (or whatever is appropriate for your use case)
1. Verify that the DNS change has propagated. (This usually happens when the TTL is expired. Sometimes it can take 24-48 hours.) Use a tool like `dig` or `nslookup`.
```
dig www.example.com
# Should eventually return a CNAME pointing to your CloudFront routing endpoint
```
1. Return to the CloudFront console and choose **Submit**. When your domain is active, CloudFront updates the domain status to indicate that your domain is ready to serve traffic.
For more information, see the documentation for your DNS provider:
+ [Cloudflare](https://developers.cloudflare.com/dns/manage-dns-records/how-to/create-dns-records/)
+ [ClouDNS](https://www.cloudns.net/wiki/article/9/)
+ [DNSimple](https://support.dnsimple.com/categories/dns/)
+ [Gandi.net](https://www.gandi.net/)
+ [GoDaddy](https://www.godaddy.com/help/manage-dns-records-680)
+ [Google Cloud DNS](https://cloud.google.com/dns/docs/records)
+ [Namecheap](https://www.namecheap.com/support/knowledgebase/article.aspx/767/10/how-to-change-dns-for-a-domain/)
## Domain considerations (distribution tenant)
When a domain is active, domain control has been established and CloudFront will respond to all viewer requests to this domain. Once activated, a domain can't be deactivated or changed to an inactive status. The domain can't be associated with another CloudFront resource while it's already in use. To associate the domain with another distribution, use the [UpdateDomainAssociation](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDomainAssociation.html) request to move the domain from one CloudFront resource to another.
When a domain is inactive, CloudFront won't respond to viewer requests to the domain. While the domain is inactive, note the following:
+ If you have a pending certificate request, CloudFront will respond to requests for the well-known path. While the request is pending, the domain can't be associated with any other CloudFront resources.
+ If you don't have a pending certificate request, CloudFront won't respond to requests for the domain. You can associate the domain with other CloudFront resources.
+ You can only have *one pending certificate request* per distribution tenant. Before you can request another certificate for additional domains, you must cancel the existing pending request. Canceling an existing certificate request does not delete the associated ACM certificate. You can delete that by using the ACM API.
+ If you apply a new certificate to your distribution tenant, this will disassociate the previous certificate. You can reuse the certificate to cover the domain for another distribution tenant.
As with renewals for DNS-validated certificates, you will be notified when the certificate renewal succeeds. However, you don't need to do anything else. CloudFront will manage the certificate renewal for your domain automatically.
**Note**
You don't need to call the ACM API operations to create or update your certificate resources. You can manage your certificates by using the [CreateDistributionTenant](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistributionTenant.html) and [UpdateDistributionTenant](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistributionTenant.html) API operations to specify the details for your managed certificate request.
## Wildcard domains (distribution tenant)
Wildcard domains are supported for distribution tenants in the following situations:
+ When the wildcard is included in the shared certificate that's inherited from the parent multi-tenant distribution
+ When you use a valid existing custom TLS certificate for your distribution tenant
# Create custom connection group (optional)
By default, CloudFront creates a connection group for you when you create a multi-tenant distribution. The connection group controls how viewer requests for content connect to CloudFront.
We recommend that you use the default connection group. However, if you need to isolate enterprise applications or manage groups of distribution tenants separately, you can choose to create a custom connection group. For example, you might need to move a distribution tenant to a separate connection group if it experiences a DDoS attack. This way, you can protect other distribution tenants from impact.
## Create custom connection group (optional)
Optionally, you can choose to create a custom connection group for your distribution tenants.
**To create a custom connection group (optional)**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. In the navigation pane, choose **Settings**.
1. Turn on the **Connection group** settings.
1. In the navigation pane, choose **Connection groups**, and then choose **Create connection group**.
1. For **Connection group name**, enter a name for the connection group. You can't update this name after you create the connection group.
1. For **IPv6**, specify if you want to enable this IP protocol. For more information, see [Enable IPv6 (viewer requests)](DownloadDistValuesGeneral.md#DownloadDistValuesEnableIPv6).
1. For **Anycast static IP list**, specify if you want to deliver traffic to your distribution tenants from a set of IP addresses. For more information, see [Anycast static IP list](request-static-ips.md).
1. (Optional) Add tags to your connection group.
1. Choose **Create connection group**.
When your connection group is created, you can find the settings that you specified, and also the ARN and endpoint.
+ The ARN looks like the following example: `arn:aws:cloudfront::123456789012:connection-group/cg_2uVbA9KeWaADTbKzhj9lcKDoM25`
+ The endpoint looks like the following example: d111111abcdef8.cloudfront.net
You can edit or delete your custom connection group after you create it. Before you can delete a connection group, you must first delete all associated distribution tenants from it. You can't delete the default connection group that CloudFront created for you when you created your multi-tenant distribution.
**Important**
If you change the connection group for a distribution tenant, CloudFront will continue to carry traffic for the distribution tenant, but with increased latency. We recommend that you update the DNS record for the distribution tenant to use the CloudFront routing endpoint from the new connection group.
Until you update the DNS record, CloudFront will route based on settings defined for the routing endpoint that the website is currently pointing to with DNS. For example, assume that your default connection group does not use Anycast static IPs but your new, custom connection group does. You must update the DNS record before CloudFront will use Anycast static IPs for the distribution tenants in your custom connection group.
# Migrate to a multi-tenant distribution
If you have a CloudFront standard distribution and you want to migrate to a multi-tenant distribution, follow these steps.
**To migrate from a standard distribution to a multi-tenant distribution**
1. Review the [Unsupported features](distribution-config-options.md#unsupported-saas).
1. Create a multi-tenant distribution with the same configuration as your standard distribution, minus the unsupported features. For more information, see [Create a CloudFront distribution in the console](distribution-web-creating-console.md#create-console-distribution).
1. Create a distribution tenant and add an alternative domain name that you own.
**Warning**
Do *not* use the current domain name that's associated with your standard distribution. Add a placeholder domain instead. You will move your domain over later. For more information about creating a distribution tenant, see [Create a CloudFront distribution in the console](distribution-web-creating-console.md#create-console-distribution).
1. Provide an existing certificate for the distribution tenant domain. This is the certificate that will cover the placeholder domain and the domain that you want to move.
1. Copy the CloudFront routing endpoint from the distribution tenant detail page in the console. Alternatively, find it by using the [ListConnectionGroups](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListConnectionGroups.html) API action in the *Amazon CloudFront API Reference*.
1. To verify domain ownership, create a DCV TXT record with an underscore ( \$1 ) prefix that points to the CloudFront routing endpoint for your distribution tenant. For more information, see [Point domains to CloudFront](managed-cloudfront-certificates.md#point-domains-to-cloudfront).
1. When your changes have propagated, update your distribution tenant to use the domain that you previously used for your standard distribution.
+ **Console** – For detailed instructions, see [Add a domain and certificate (distribution tenant)](managed-cloudfront-certificates.md#vanity-domain-tls-tenant).
+ **API** – Use the [UpdateDomainAssociation](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDomainAssociation.html) API action in the *Amazon CloudFront API Reference*.
**Important**
This resets the cache key for your content. After this, CloudFront starts caching your content using the new cache key. For more information, see [Understand the cache key](understanding-the-cache-key.md).
1. Update your DNS record to point your domain to the CloudFront routing endpoint for your distribution tenant. Once you complete this step, your domain will be ready to serve traffic to your distribution tenant. For more information, see [Point domains to CloudFront](managed-cloudfront-certificates.md#point-domains-to-cloudfront).
1. (Optional) After you successfully migrate your domain to a distribution tenant, you can use a different CloudFront managed certificate that covers the domain name for your distribution tenant. To request a managed certificate, create a separate TXT record to issue the certificate and follow the steps here in [Complete domain setup](managed-cloudfront-certificates.md#complete-domain-ownership).
# Create a distribution
This topic explains how to use the CloudFront console to create a distribution.
**Overview**
1. Create one or more Amazon S3 buckets, or configure HTTP servers as your origin servers. An *origin* is the location where you store the original version of your content. When CloudFront gets a request for your files, it goes to the origin to get the files that it distributes at edge locations. You can use any combination of Amazon S3 buckets and HTTP servers as your origin servers.
+ If you use Amazon S3, the name of your bucket must be all lowercase and cannot contain spaces.
+ If you use an Amazon EC2 server or another custom origin, review [Use Amazon EC2 (or another custom origin)](DownloadDistS3AndCustomOrigins.md#concept_CustomOrigin).
+ 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).
1. Upload your content to your origin servers. You make your objects publicly readable, or you can use CloudFront signed URLs to restrict access to your content.
**Important**
You are responsible for ensuring the security of your origin server. You must ensure that CloudFront has permission to access the server and that the security settings safeguard your content.
1. Create your CloudFront distribution:
+ For a detailed procedure that creates a distribution in the CloudFront console, see [Create a CloudFront distribution in the console](#create-console-distribution).
+ For information about creating a distribution using the CloudFront API, see [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html) in the *Amazon CloudFront API Reference*.
1. (Optional) If you use the CloudFront console to create your distribution, create more cache behaviors or origins for the distribution. For more information about behaviors and origins, see [To update a multi-tenant distribution](HowToUpdateDistribution.md#HowToUpdateDistributionProcedure).
1. Test your distribution. For more information about testing, see [Test a distribution](distribution-web-testing.md).
1. Develop your website or application to access your content using the domain name that CloudFront returned after you created your distribution in Step 3. For example, if CloudFront returns d111111abcdef8.cloudfront.net as the domain name for your distribution, the URL for the file `image.jpg` in an Amazon S3 bucket or in the root directory on an HTTP server is `https://d111111abcdef8.cloudfront.net/image.jpg`.
If you specified one or more alternate domain names (CNAMEs) when you created your distribution, you can use your own domain name. In that case, the URL for `image.jpg` might be `https://www.example.com/image.jpg`.
Note the following:
+ If you want to use signed URLs to restrict access to your content, see [Serve private content with signed URLs and signed cookies](PrivateContent.md).
+ If you want to serve compressed content, see [Serve compressed files](ServingCompressedFiles.md).
+ For information about CloudFront request and response behavior for Amazon S3 and custom origins, see [Request and response behavior](RequestAndResponseBehavior.md).
**Topics**
+ [
## Create a CloudFront distribution in the console
](#create-console-distribution)
+ [
## Values that CloudFront displays in the console
](#distribution-web-values-returned)
+ [
## Additional links
](#distribution-helpful-links)
+ [
# Add a domain to your CloudFront standard distribution
](add-domain-existing-distribution.md)
## Create a CloudFront distribution in the console
When you create a distribution, CloudFront configures your distribution settings for you, based on your content origin type. For more details about the preconfigured settings, see [Preconfigured distribution settings reference](template-preconfigured-origin-settings.md). You can also create multi-tenant distributions with settings that can be reused across multiple distribution tenants. For more information, see [Understand how multi-tenant distributions work](distribution-config-options.md). Alternatively, you can manually configure your own distribution settings.
------
#### [ Multi-tenant ]
**To create a multi-tenant distribution**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. In the navigation pane, choose **Distributions**, then choose **Create distribution**.
1. Choose **Multi-tenant architecture**, **Next**.
1. Enter a **Distribution name** for the multi-tenant distribution. The name will appear as the value for the `Name` key. You can change this value later. You can add up to 50 tags for your multi-tenant distribution. For more information, see [Tag a distribution](tagging.md) .
1. (Optional) For **Wildcard certificate**, choose the AWS Certificate Manager (ACM) certificate that will cover all subdomains under the root domain, such as *\$1.example.com*. The certificate must be in the US East (N. Virginia) Region.
1. Choose **Next**.
1. On the **Specify origin** page, select the origin type that CloudFront will get your content from. CloudFront will use the recommended settings for that origin type for your multi-tenant distribution. For more information about the recommended settings, see [Preconfigured distribution settings reference](template-preconfigured-origin-settings.md).
1. For **Origin**, under the origin type that you selected, choose or enter the origin to use.
1. For **Origin path**, enter the forward slash (`/`) character, followed by the origin path.
1. (Optional) To add a parameter, choose **Insert parameter** for either the origin domain name or origin path. You can enter up to two parameters for each field.
1. Choose **Create new parameter**.
1. On the **Create new parameter** dialog box, for **Parameter name**, enter a unique name for the parameter and, optionally, a description.
1. For **Required parameter**, select the checkbox to make this parameter value required at the distribution tenant level. If it's not required, enter a **Default value** that the distribution tenant will inherit.
1. Choose **Create parameter**. This parameter appears in the corresponding field.
1. For **Options**, choose one of the following options:
+ **Use recommended origin settings** – Use the default recommended cache and origin settings for the origin type that you selected.
+ **Customize origin settings** – Customize the cache and origin settings. If you choose this option, specify your own values that appear.
1. Choose **Next**.
1. On the **Enable security protections** page, choose whether to enable AWS WAF security protections. You can customize the web ACL for specific distribution tenants later. For more information, see [Enable AWS WAF for a new distribution](WAF-one-click.md#enable-waf-new-distribution).
1. Choose **Next**, **Create distribution**.
1. On the **Distributions** page, your multi-tenant distribution appears in the list of resources. You can choose the **All distributions** dropdown to filter by standard distribution or multi-tenant distribution. You can also choose the **Type** column to filter by standard or multi-tenant distribution.
By default, CloudFront creates a connection group for you. The connection group controls how viewer requests for content connect to CloudFront. You can customize some routing settings in the connection group. For more information, see [Understand how multi-tenant distributions work](distribution-config-options.md).
You can create additional distribution tenants using the multi-tenant distribution as a template.
**To create a distribution tenant**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. In the navigation pane, do one of the following:
+ Choose **Distributions**, choose a multi-tenant distribution, and then choose **Create tenant**.
+ Choose **Distribution tenants** and then choose **Create tenant**.
1. For **Distribution tenant name**, enter the name. The name must be unique in your AWS account and can't be changed after you create it.
1. For **Template distribution**, choose a multi-tenant distribution ID from the list.
1. For **Manage tags**, add up to 50 key-value pairs for the distribution tenant. For more information, see [Tag a distribution](tagging.md). ****
1. Choose **Next**.
1. On the **Add domains** page, for **Certificate**, choose if you want a **Custom TLS certificate** for your distribution tenant. The certificate verifies whether you're authorized to use the domain name. The certificate must exist in the US East (N. Virginia) Region.
1. For **Domains**, enter your domain name.
**Note**
If you entered a domain name that isn't covered by a certificate, you will need to verify that you own the domain. You can still create the distribution tenant for now and verify domain ownership later. For more information, see [Request certificates for your CloudFront distribution tenant](managed-cloudfront-certificates.md).
1. Choose **Next**.
1. On the **Define parameters** page, the parameters that you specified in the multi-tenant distribution appear. For required parameters, enter a value next to the parameter name and save your changes.
1. To add another parameter, choose **Add parameter** and enter a name and value.
1. Choose **Next**.
1. (Optional) For **Security customization**, if you choose to **Override distribution settings**, select the option for your use case.
1. (Optional) For **Geographic restrictions customization**, if you choose to **Override distribution settings**, select the appropriate **Restriction type** and **Countries** for the distribution tenant. For more information, see [Restrict the geographic distribution of your content](georestrictions.md).
1. Choose **Next**.
1. Choose **Create distribution tenant**.
You can find all your distribution tenants on the **Distribution tenants** page. You can filter by the following:
**Association**
+ Distribution ID
+ Certificate ID
+ Connection group ID
+ Web ACL ID
**Properties**
+ Name
+ Domain
You can edit your distribution tenants to customize specific settings. For more information, see [Distribution tenant customizations](tenant-customization.md).
------
#### [ Standard ]
**To create a standard distribution**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. In the navigation pane, choose **Distributions**, then choose **Create distribution**.
1. Enter a **Distribution name** for the standard distribution. The name will appear as the value for the `Name` key as a tag. You can change this value later. You can add up to 50 tags for your standard distribution. For more information, see [Tag a distribution](tagging.md).
1. Choose **Single website or app**, **Next**.
1. (Optional) For **Domain setup**, enter a domain that's already registered with Route 53 in your AWS account, or register a new domain. Complete the setup steps.
+ If your domain uses a DNS provider other than Route 53, you can still add the domain, but you'll need to do so after creating the distribution. Skip the domain setup for now to proceed with distribution creation. You must manually configure the domain and TLS certificate later. For more information, see [Add a domain to your CloudFront standard distribution](add-domain-existing-distribution.md).
1. Choose **Next**.
1. On the **Specify origin** page, select the origin type that CloudFront will get your content from. CloudFront will use the recommended settings for that origin type for your distribution. For more information about the recommended settings, see [Preconfigured distribution settings reference](template-preconfigured-origin-settings.md).
1. For **Origin**, choose or enter your origin.
1. For **Settings**, choose one of the following options:
+ **Use recommended origin settings** – Use the default recommended cache and origin settings for the origin type that you selected.
+ **Customize origin settings** – Customize the cache and origin settings. If you choose this option, specify your own values.
1. Choose **Next**.
1. On the **Enable security protections** page, choose whether to enable AWS WAF security protections.
1. Choose **Next**.
1. (Optional) If you are using Route 53 for your domain, you will see the **TLS certificate** page. If CloudFront can't find an existing AWS Certificate Manager (ACM) certificate for your domain in your AWS account in the `us-east-1` AWS Region, you can choose to automatically create a certificate or manually create it. After the certificate is created, choose **Next**.
1. Review your distribution details and choose **Create distribution**.
1. After CloudFront creates your distribution, the value of the **Status** column for your distribution will change from **Deploying** to the date and time that the distribution is deployed.
The domain name that CloudFront assigns to your distribution appears in the list of distributions. (It also appears on the **General** tab for a selected distribution.)
**Tip**
You can use an alternate domain name, instead of the name assigned to you by CloudFront, by following the steps in [Use custom URLs by adding alternate domain names (CNAMEs)](CNAMEs.md).
1. When your distribution is deployed, confirm that you can access your content by using your new CloudFront URL (d111111abcdef8.cloudfront.net) or the CNAME. For more information, see [Test a distribution](distribution-web-testing.md).
1. Make sure to update your DNS records to point to CloudFront when you're ready to send traffic to your distribution. For more information, see [Point domains to CloudFront (standard distribution)](add-domain-existing-distribution.md#point-domains-standard).
------
## Values that CloudFront displays in the console
Values that are displayed
When you create a new distribution or update an existing distribution, CloudFront displays the following information in the CloudFront console.
**Note**
Active trusted signers, the AWS accounts that have an active CloudFront key pair and can be used to create valid signed URLs, are currently not visible in the CloudFront console.
### Distribution ID
When you perform an action on a distribution using the CloudFront API, you use the distribution ID to specify which distribution to use, for example, `EDFDVBD6EXAMPLE`. You can't change a distribution's distribution ID.
### Deploying and status
When you deploy a distribution, you see the **Deploying** status under the **Last modified** column. Wait for the distribution to finish deploying and make sure the **Status** column shows **Enabled**. For more information, see [Distribution state](DownloadDistValuesGeneral.md#DownloadDistValuesEnabled).
### Last modified
The date and time that the distribution was last modified, using ISO 8601 format, for example, 2012-05-19T19:37:58Z. For more information, see [https://www.w3.org/TR/NOTE-datetime](https://www.w3.org/TR/NOTE-datetime).
### Domain name
You use the distribution's domain name in the links to your objects. For example, if your distribution's domain name is `d111111abcdef8.cloudfront.net`, the link to `/images/image.jpg` would be `https://d111111abcdef8.cloudfront.net/images/image.jpg`. You can't change the CloudFront domain name for your distribution. For more information about CloudFront URLs for links to your objects, see [Customize the URL format for files in CloudFront](LinkFormat.md).
If you specified one or more alternate domain names (CNAMEs), you can use your own domain names for links to your objects instead of using the CloudFront domain name. For more information about CNAMEs, see [Alternate domain names (CNAMEs)](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME).
**Note**
CloudFront domain names are unique. Your distribution's domain name was never used for a previous distribution and will never be reused for another distribution in the future.
## Additional links
For more information about creating a distribution, see the following links.
+ To learn how to create a distribution that uses an Amazon Simple Storage Service (Amazon S3) bucket origin with origin access control (OAC), see [Get started with a CloudFront standard distribution](GettingStarted.SimpleDistribution.md).
+ For information about using the CloudFront APIs to create a distribution, see [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html) in the *Amazon CloudFront API Reference*.
+ For information about updating a distribution (for example, to add cache behaviors to standard distributions, or to customize distribution tenants), see [Update a distribution](HowToUpdateDistribution.md).
+ To see the current maximum number of distributions that you can create for each AWS account, or to request a higher quota (formerly known as limit), see [General quotas on distributions](cloudfront-limits.md#limits-web-distributions).
# Add a domain to your CloudFront standard distribution
After you create a new CloudFront standard distribution, you can add a domain to it. Optionally, you can set up a Amazon Route 53 domain for your standard distribution when you create it. For more information, see [Create a CloudFront distribution in the console](distribution-web-creating-console.md#create-console-distribution).
## Add a domain to your existing standard distribution
**To add a domain to your standard distribution**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. In the navigation pane, choose **Distributions**, then choose the distribution ID.
1. Under **Settings**, **Alternate domain names**, choose **Add a domain**.
1. Enter up to five domains to serve.
1. Choose **Next**.
1. For **TLS certificate**, if CloudFront can't find an existing AWS Certificate Manager (ACM) certificate for your domain in your AWS account in the `us-east-1` AWS Region, you can create one.
+ If you are using Amazon Route 53 (Route 53), CloudFront automatically creates a certificate for you.
1. When your certificate is provisioned, you must update your DNS records with your DNS provider to prove domain ownership. Then, choose **Validate certificate**. For more information, see [Point domains to CloudFront (standard distribution)](#point-domains-standard).
+ If you are using Route 53, CloudFront updates your DNS records for you.
1. Choose **Next**.
1. Review your changes and choose **Add domains**.
1. Before you send traffic to your distribution, make sure to update your DNS records to point to CloudFront. For more information, choose **Route domains to CloudFront** in the **Settings** section of your distribution details page.
+ If you are using Route 53, you can have CloudFront set up DNS routing for you automatically.
## Point domains to CloudFront (standard distribution)
Update your DNS records to route traffic from each domain to the CloudFront hostname. You can have multiple domain names, but they must all resolve to this hostname.
**To point domains to CloudFront**
1. Copy the CloudFront hostname value, such as d111111abcdef8.cloudfront.net.
1. Update your DNS records to route traffic from each domain to the CloudFront hostname.
1. Sign in to your domain registrar or DNS provider management console.
1. Navigate to the DNS management section for your domain.
+ **For subdomains** – Create a CNAME record. For example:
+ **Name** – Your subdomain (such as `www` or `app`)
+ **Value / Target** – Your CloudFront hostname
+ **Record type** – CNAME
+ **TTL** – 3600 (or whatever is appropriate for your use case)
+ **For apex/root domains** – This requires a unique DNS configuration, because standard CNAME records can’t be used at the root or apex domain level. Because most DNS providers don’t support ALIAS records, we recommend creating an ALIAS record in Route 53. For example:
+ **Name ** – Your apex domain (such as `example.com`)
+ **Record type** – A
+ **Alias** – Yes
+ **Alias target** – Your CloudFront hostname
+ **Routing policy** – Simple (or whatever is appropriate for your use case)
1. Verify that the DNS change has propagated. (This usually happens when the TTL is expired. Sometimes it can take 24-48 hours.) Use a tool like `dig` or `nslookup`.
```
dig www.example.com
# Should eventually return a CNAME pointing to your CloudFront hostname
```
1. Return to the CloudFront console and choose **Submit**. When your domain is active, CloudFront updates the domain status to indicate that your domain is ready to serve traffic.
For more information, see the documentation for your DNS provider:
+ [Cloudflare](https://developers.cloudflare.com/dns/manage-dns-records/how-to/create-dns-records/)
+ [ClouDNS](https://www.cloudns.net/wiki/article/9/)
+ [DNSimple](https://support.dnsimple.com/categories/dns/)
+ [Gandi.net](https://www.gandi.net/)
+ [GoDaddy](https://www.godaddy.com/help/manage-dns-records-680)
+ [Google Cloud DNS](https://cloud.google.com/dns/docs/records)
+ [Namecheap](https://www.namecheap.com/support/knowledgebase/article.aspx/767/10/how-to-change-dns-for-a-domain/)
# Preconfigured distribution settings reference
Preconfigured distribution settings
When you create your CloudFront distribution, CloudFront automatically configures most distribution settings for you, based on your content origin type. Optionally, you can choose to manually edit your distribution settings. For more information, see [All distribution settings reference](distribution-web-values-specify.md).
The following sections describe the default preconfiguration settings for distributions, and the settings that you can customize.
## Amazon S3 origin
Following are the origin settings that CloudFront preconfigures for your Amazon S3 origin in a multi-tenant distribution.
**Origin settings (preconfigured)**
+ **Origin Access Control (console only)** – CloudFront sets this up for you. CloudFront attempts to add the S3 bucket policy for standard distributions and for multi-tenant distributions with no parameters used in the origin domain.
+ **Add custom header** – None
+ **Enable Origin Shield** – No
+ **Connection attempts** – 3
Following are the cache settings that CloudFront preconfigures for your Amazon S3 origin in a multi-tenant distribution.
**Cache settings (preconfigured)**
+ **Compress objects automatically** – Yes
+ **Viewer protocol policy** – Redirect to HTTPS
+ **Allowed HTTP method** – `GET, HEAD`
+ **Restrict viewer access** – No
+ **Cache policy** – `CachingOptimized`
+ **Origin request policy** – None
+ **Response header policy** – None
+ **Smooth Streaming** – No
+ **Field level encryption** – No
+ **Enable real-time access logs** – No
+ **Functions** – No
Following are the settings that you can customize for your Amazon S3 origin in a multi-tenant distribution.
**Customizable settings**
+ **S3 access** – CloudFront sets this for you, based on your S3 bucket settings:
+ **If your bucket is public** – No Origin Access Control (OAC) policy is needed.
+ **If your bucket is private** – You can choose or create an OAC policy to use.
+ **Enable Origin Shield** – No
+ **Compress objects automatically** – Yes
+ If you choose **Yes**, then the `CachingOptimized` caching policy is used.
+ If you choose **No**, then the `CachingOptimizedForUncompressedObjects` caching policy is used.
## API Gateway origin
Following are the origin settings that CloudFront preconfigures for your API Gateway origin in a multi-tenant distribution.
**Origin settings (preconfigured)**
+ **Protocol** – HTTPS only
+ **HTTPS port** – 443
+ **Minimum origin SSL protocol** – TLSv1.2
+ **Origin path** – None
+ **Origin Access Control (console only)** – CloudFront sets this up for you
+ **Add custom header** – None
+ **Enable Origin Shield** – No
+ **Connection attempts** – 3
+ **Response timeout** – 30
+ **Keep-alive timeout** – 5
Following are the cache settings that CloudFront preconfigures for your API Gateway origin in a multi-tenant distribution.
**Cache settings (preconfigured)**
+ **Compress objects automatically** – Yes
+ **Viewer protocol policy** – Redirect to HTTPS
+ **Allowed HTTP method** – `GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE`
+ **Cache HTTP methods** – No
+ **Allow gRPC requests over HTTP/2** – No
+ **Restrict viewer access** – No
+ **Cache policy** – `CachingDisabled` (Possible values: `UseOriginCacheControlHeaders`, `UseOriginCacheControlHeaders-QueryStrings`)
+ **Origin request policy** – `AllViewerExceptHostHeader` (Possible values: `AllViewer`, `AllViewerandCloudFrontHeaders-2022-06`)
+ **Response header policy** – None
+ **Smooth Streaming** – No
+ **Field level encryption** – No
+ **Enable real-time access logs** – No
+ **Functions** – No
Following are the settings that you can customize for your API Gateway origin in a multi-tenant distribution.
**Customizable settings**
+ **Enable Origin Shield** – (Default: No)
+ **Compress objects automatically** – (Default: Yes)
## Custom origin and EC2 instance
Following are the origin settings that CloudFront preconfigures for your custom origin in a multi-tenant distribution.
**Origin settings (preconfigured)**
+ **Protocol** – Match viewer
+ **HTTP port** – 80
+ **HTTPS port** – 443
+ **Minimum origin SSL protocol** – TLSv1.2
+ **Origin path** – None
+ **Add custom header** – None
+ **Enable Origin Shield** – No
+ **Connection attempts** – 3
+ **Response timeout** – 30
+ **Keep-alive timeout** – 5
Following are the cache settings that CloudFront preconfigures for your custom origin and EC2 instance in a multi-tenant distribution.
**Cache settings (preconfigured)**
+ **Compress objects automatically** – Yes
+ **Viewer protocol policy** – Redirect to HTTPS
+ **Allowed HTTP method** – `GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE`
+ **Cache HTTP methods** – No
+ **Allow gRPC requests over HTTP/2** – No
+ **Restrict viewer access** – No
+ **Cache policy** – `UseOriginCacheControlHeaders` (Possible values: `UseOriginCacheControlHeaders-QueryStrings`, `CachingDisabled`, `CacheOptimized`, `CachingOptimizedForUncompressedObjects`)
+ **Origin request policy** – `AllViewer` (Possible values: `AllViewerExceptHostHeader`, `AllViewerandCloudFrontHeaders-2022-06`)
+ **Response header policy** – None
+ **Smooth Streaming** – No
+ **Field level encryption** – No
+ **Enable real-time access logs** – No
+ **Functions** – No
Following are the settings that you can customize for your custom origin and EC2 instance in a multi-tenant distribution.
**Customizable settings**
+ **Enable Origin Shield** – (Default: No)
+ **Compress objects automatically** – (Default: Yes)
+ **Caching** – (Default: `Cache by Default`)
+ If `Cache by Default` is selected, the `UseOriginCacheControlHeaders` cache policy is used.
+ If `Do Not Cache by Default` is selected, the `CachingDisabled` cache policy is used.
+ **Include query string in cache** – (Default: Yes, if `Cache by Default` is already selected)
+ If `Do Not Cache by Default` is already selected and you then choose to include the query string in the cache, the `UseOriginCacheControlHeaders-QueryStrings` cache policy is used.
## Elastic Load Balancing origin
Following are the origin settings that CloudFront preconfigures for your Elastic Load Balancing origin in a multi-tenant distribution.
**Origin settings (preconfigured)**
+ **Protocol** – HTTPS only
+ **HTTPS port** – 443
+ **Minimum origin SSL protocol** – TLSv1.2
+ **Origin path** – None
+ **Add custom header** – None
+ **Enable Origin Shield** – No
+ **Connection attempts** – 3
+ **Response timeout** – 30
+ **Keep-alive timeout** – 5
Following are the cache settings that CloudFront preconfigures for your Elastic Load Balancing origin in a multi-tenant distribution.
**Cache settings (preconfigured)**
+ **Compress objects automatically** – Yes
+ **Viewer protocol policy** – Redirect to HTTPS
+ **Allowed HTTP method** – `GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE`
+ **Cache HTTP methods** – No
+ **Allow gRPC requests over HTTP/2** – No
+ **Restrict viewer access** – No
+ **Caching** – (Default: `Cache by Default`)
+ If `Cache by Default` is selected, the `UseOriginCacheControlHeaders` cache policy is used.
+ If `Do Not Cache by Default` is selected, the `CachingDisabled` cache policy is used.
+ **Include query string in cache** – (Default: Yes, if `Cache by Default` is already selected)
+ If `Do Not Cache by Default` is already selected and you then choose to include the query string in the cache, the `UseOriginCacheControlHeaders-QueryStrings` cache policy is used.
+ **Origin request policy** – `All Viewer` (Possible values: `AllViewerExceptHostHeader`, `AllViewerandCloudFrontHeaders-2022-06`)
+ **Response header policy** – None
+ **Smooth Streaming** – No
+ **Field level encryption** – No
+ **Enable real-time access logs** – No
+ **Functions** – No
Following are the settings that you can customize for your Elastic Load Balancing origin in a multi-tenant distribution.
**Customizable settings**
+ **Enable Origin Shield** – (Default: No)
+ **Compress objects automatically** – (Default: Yes)
+ **Caching** – (Default: `Cache by Default`)
+ If `Cache by Default` is selected, the `UseOriginCacheControlHeaders` cache policy is used.
+ If `Do Not Cache by Default` is selected, the `CachingDisabled` cache policy is used.
+ **Include query string in cache** – (Default: Yes, if `Cache by Default` is already selected)
+ If `Do Not Cache by Default` is already selected and you then choose to include the query string in the cache, the `UseOriginCacheControlHeaders-QueryStrings` cache policy is used.
## MediaPackage v1 origin
Following are the origin settings that CloudFront preconfigures for your MediaPackage v1 origin in a multi-tenant distribution.
**Origin settings (preconfigured)**
+ **Protocol** – HTTPS only
+ **HTTPS port** – 443
+ **Minimum origin SSL protocol** – TLSv1.2
+ **Origin path** – You provide this by entering your MediaPackage URL.
+ **Add custom header** – None
+ **Enable Origin Shield** – No
+ **Connection attempts** – 3
+ **Response timeout** – 30
+ **Keep-alive timeout** – 5
Following are the cache settings that CloudFront preconfigures for your MediaPackage v1 origin in a multi-tenant distribution.
**Cache settings (preconfigured)**
+ **Compress objects automatically** – Yes
+ **Viewer protocol policy** – Redirect to HTTPS
+ **Allowed HTTP method** – `GET, HEAD`
+ **Cache HTTP methods** – No
+ **Allow gRPC requests over HTTP/2** – No
+ **Restrict viewer access** – No
+ **Cache policy** – `Elemental-MediaPackage`
+ **Origin request policy** – None
+ **Response header policy** – None
+ **Smooth Streaming** – No
+ **Field level encryption** – No
+ **Enable real-time access logs** – No
+ **Functions** – No
## MediaPackage v2 origin
Following are the origin settings that CloudFront preconfigures for your MediaPackage v2 origin in a multi-tenant distribution.
**Origin settings (preconfigured)**
+ **Origin Access Control** – CloudFront sets this up for you and adds the policy
+ **Protocol** – HTTPS only
+ **HTTPS port** – 443
+ **Minimum origin SSL protocol** – TLSv1.2
+ **Origin path** – None
+ **Add custom header** – None
+ **Enable Origin Shield** – No
+ **Connection attempts** – 3
+ **Response timeout** – 30
+ **Keep-alive timeout** – 5
Following are the cache settings that CloudFront preconfigures for your MediaPackage v2 origin in a multi-tenant distribution.
**Cache settings (preconfigured)**
+ **Compress objects automatically** – Yes
+ **Viewer protocol policy** – Redirect to HTTPS
+ **Allowed HTTP method** – `GET, HEAD`
+ **Cache HTTP methods** – No
+ **Allow gRPC requests over HTTP/2** – No
+ **Restrict viewer access** – No
+ **Cache policy** – `Elemental-MediaPackage`
+ **Origin request policy** – None
+ **Response header policy** – None
+ **Smooth Streaming** – No
+ **Field level encryption** – No
+ **Enable real-time access logs** – No
+ **Functions** – No
## MediaTailor origin
Following are the origin settings that CloudFront preconfigures for your MediaTailor origin in a multi-tenant distribution.
**Origin settings (preconfigured)**
+ **Protocol** – HTTPS only
+ **HTTPS port** – 443
+ **Minimum origin SSL protocol** – TLSv1.2
+ **Origin path** – You provide this by entering your MediaPackage URL.
+ **Add custom header** – None
+ **Enable Origin Shield** – No
+ **Connection attempts** – 3
+ **Response timeout** – 30
+ **Keep-alive timeout** – 5
Following are the cache settings that CloudFront preconfigures for your MediaTailor origin in a multi-tenant distribution.
**Cache settings (preconfigured)**
+ **Compress objects automatically** – Yes
+ **Viewer protocol policy** – Redirect to HTTPS
+ **Allowed HTTP method** – `GET, HEAD`
+ **Cache HTTP methods** – No
+ **Allow gRPC requests over HTTP/2** – No
+ **Restrict viewer access** – No
+ **Cache policy** – None
+ **Origin request policy** – `Elemental-MediaTailor-PersonalizedManifests`
+ **Response header policy** – None
+ **Smooth Streaming** – No
+ **Field level encryption** – No
+ **Enable real-time access logs** – No
+ **Functions** – No
# All distribution settings reference
All distribution settings
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
Added viewer security policy
Added the TLSv1.2\$12025 security policy.
+ [Supported protocols and ciphers between viewers and CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/secure-connections-supported-viewer-protocols-ciphers.html)
+ [Security policy (minimum SSL/TLS version) ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DownloadDistValuesGeneral.html#DownloadDistValues-security-policy)Added viewer security policy[https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DownloadDistValuesGeneral.html#DownloadDistValues-security-policy](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DownloadDistValuesGeneral.html#DownloadDistValues-security-policy)
Added TLSv1.3\$12025, a new TLS 1.3-only security policy.
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
HTTP/3 support for CloudFront distributions
You can now choose HTTP/3 for your CloudFront distribution.
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).
# Test a distribution
After you've created your distribution, CloudFront knows where your origin server is, and you know the domain name associated with the distribution. To test your distribution, do the following:
1. Wait until your distribution is deployed.
+ View your distribution **Details** in the console. When your distribution is done deploying, the **Last modified** field changes from **Deploying** to a date and time.
1. Create links to your objects with the CloudFront domain name by using the following procedure.
1. Test the links. CloudFront serves the objects to your webpage or application.
## Create links to your objects
Use the following procedure to create test links for the objects in your CloudFront web distribution.
**To create links to objects in a web distribution**
1. Copy the following HTML code into a new file, replace *domain-name* with your distribution's domain name, and replace *object-name* with the name of your object.
```
My CloudFront Test
My text content goes here.
```
For example, if your domain name were `d111111abcdef8.cloudfront.net` and your object were `image.jpg`, the URL for the link would be:
`https://d111111abcdef8.cloudfront.net/image.jpg`.
If your object is in a folder on your origin server, then the folder must also be included in the URL. For example, if image.jpg were located in the images folder on your origin server, then the URL would be:
`https://d111111abcdef8.cloudfront.net/images/image.jpg`
1. Save the HTML code in a file that has an .html file name extension.
1. Open your webpage in a browser to ensure that you can see your object.
The browser returns your page with the embedded image file, served from the edge location that CloudFront determined was appropriate to serve the object.
# Update a distribution
In the CloudFront console, you can see the CloudFront distributions that are associated with your AWS account, view the settings for a distribution, and update most settings. Be aware that settings changes that you make won't take effect until the distribution has propagated to the AWS edge locations.
## Update a distribution in the console
The following procedures show you how to update a CloudFront distribution in the console.
------
#### [ Multi-tenant ]
**To update a multi-tenant distribution**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Search for and choose the ID of the multi-tenant distribution.
1. Choose the tab for the settings you want to update.
1. Make the updates, and then, to save your changes, choose **Save changes**. For more information about the settings you can update, see [Preconfigured distribution settings reference](template-preconfigured-origin-settings.md).
You can also update a distribution by using the CloudFront API:
+ To update a distribution, see [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) in the *Amazon CloudFront API Reference*.
**Important**
When you update your distribution, be aware that a number of additional fields are required that are not required when you first create a distribution. To help make sure that all of the required fields are included when you use the CloudFront API to update a distribution, follow the steps described in [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) in the *Amazon CloudFront API Reference*.
To change the multi-tenant distribution for a distribution tenant, you update the distribution tenant. You also update the distribution tenant to update its domain, certificate, customizations, or parameter values. For more details about updating the distribution tenant certificate, see [Add a domain and certificate (distribution tenant)](managed-cloudfront-certificates.md#vanity-domain-tls-tenant).
**To update a distribution tenant**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Under **SaaS**, choose **Distribution tenants**.
1. Search for the distribution tenant. Use the dropdown menu in the search bar to filter by domain, name, distribution ID, certificate ID, connection group ID, or web ACL ID.
1. Choose the distribution tenant's name.
1. To update general **Details**, choose **Edit**, make the updates, and choose **Update distribution tenant**.
1. Choose the appropriate tab for any other settings to update, make your updates, and save them. For more information about the distribution tenant settings you can customize, see [Distribution tenant customizations](tenant-customization.md).
------
#### [ Standard ]
**To update a standard distribution**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Select the ID of a distribution. The list includes all of the distributions associated with the AWS account that you used to sign in to the CloudFront console.
1. To update general settings, choose **Edit**. Otherwise, choose the tab for the settings that you want to update.
1. Make the updates, and then choose **Save changes**. For information about the fields, see the following topics:
+ **General settings:** [Distribution settings](DownloadDistValuesGeneral.md)
+ **Origin settings:** [Origin settings](DownloadDistValuesOrigin.md)
+ **Cache behavior settings:** [Cache behavior settings](DownloadDistValuesCacheBehavior.md)
1. If you want to delete an origin in your distribution, do the following:
1. Choose **Behaviors**, and then make sure you have moved any default cache behaviors associated with the origin to another origin.
1. Choose **Origins**, and then select an origin.
1. Choose **Delete**.
You can also update a distribution by using the CloudFront API:
+ To update a distribution, see [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) in the *Amazon CloudFront API Reference*.
**Important**
When you update your distribution, be aware that a number of additional fields are required that are not required to create a distribution. To help make sure that all of the required fields are included when you use the CloudFront API to update a distribution, follow the steps described in [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) in the *Amazon CloudFront API Reference*.
------
When you save changes to your distribution configuration, CloudFront starts to propagate the changes to all edge locations. Successive configuration changes propagate in their respective order. Until your configuration is updated in an edge location, CloudFront continues to serve your content from that location based on the previous configuration. After your configuration is updated in an edge location, CloudFront immediately starts to serve your content from that location based on the new configuration.
Your changes don't propagate to every edge location at the same time. While CloudFront is propagating your changes, we can't determine whether a given edge location is serving your content based on the previous configuration or the new configuration.
**Note**
In rare cases when a host or network link is disrupted, some distribution tenant traffic might be served using older configurations for a brief period until your changes make their way through the network.
To see when your changes are propagated, view your distribution **Details** in the console. The **Last modified** field changes from **Deploying** to a date and time when deployment is complete.
# Tag a distribution
Tag a distribution
Tags are words or phrases that you can use to identify and organize your AWS resources. You can add multiple tags to each resource, and each tag includes a key and a value that you define. For example, the key might be "domain" and the value might be "example.com". You can search and filter your resources based on the tags you add.
You can use tags with CloudFront, such as the following examples:
+ Enforce tag-based permissions on CloudFront distributions. For more information, see [ABAC with CloudFront](security_iam_service-with-iam.md#security_iam_service-with-iam-tags).
+ Track billing information in different categories. When you apply tags to CloudFront distributions or other AWS resources (such as Amazon EC2 instances or Amazon S3 buckets) and activate the tags, AWS generates a cost allocation report as a comma-separated value (CSV file) with your usage and costs aggregated by your active tags.
You can apply tags that represent business categories (such as cost centers, application names, or owners) to organize your costs across multiple services. For more information about using tags for cost allocation, see [Using cost allocation tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) in the *AWS Billing User Guide*.
**Notes**
You can tag distributions, but you can't tag origin access identities or invalidations.
[Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) and [Resource groups](https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html) aren't currently supported for CloudFront.
For the current maximum number of tags that you can add to a distribution, see [General quotas](cloudfront-limits.md#limits-general).
**Contents**
+ [
## Tag restrictions
](#tagging-restrictions)
+ [
## Add, edit, and delete tags for distributions
](#tagging-add-edit-delete)
+ [
## Programmatic tagging
](#tagging-related-information)
## Tag restrictions
The following basic restrictions apply to tags:
+ For the maximum number of tags per distribution, see [General quotas](cloudfront-limits.md#limits-general).
+ Maximum key length – 128 Unicode characters
+ Maximum value length – 256 Unicode characters
+ Valid values for key and value – a-z, A-Z, 0-9, space, and the following characters: \$1 . : / = \$1 - and @
+ Tag keys and values are case sensitive
+ Don't use `aws:` as a prefix for keys. This prefix is reserved for AWS use.
## Add, edit, and delete tags for distributions
You can use the CloudFront console to manage tags for your distributions.
**To add tags, edit, or delete tags for a distribution**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Choose the ID for the distribution that you want to update.
1. Choose the **Tags** tab.
1. Choose **Manage tags**.
1. On the **Manage tags** page, you can do the following:
+ To add a tag, enter a key and, optionally, a value for the tag. Choose **Add new tag** to add more tags.
+ To edit a tag, change the tag’s key or its value, or both. You can delete the value for a tag, but the key is required.
+ To delete a tag, choose **Remove**.
1. Choose **Save changes**.
## Programmatic tagging
You can also use the CloudFront API, AWS Command Line Interface (AWS CLI), AWS SDKs, and AWS Tools for Windows PowerShell to apply tags. For more information, see the following topics:
+ CloudFront API operations:
+ [ListTagsForResource](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListTagsForResource.html)
+ [TagResource](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_TagResource.html)
+ [UntagResource](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UntagResource.html)
+ AWS CLI – See [cloudfront](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudfront/index.html) in the *AWS CLI Command Reference*
+ AWS SDKs – See the applicable SDK documentation on the [AWS Documentation](https://docs.aws.amazon.com/index.html) page
+ Tools for Windows PowerShell – See [Amazon CloudFront](https://docs.aws.amazon.com/powershell/latest/reference/items/CloudFront_cmdlets.html) in the [AWS Tools for PowerShell Cmdlet Reference](https://docs.aws.amazon.com/powershell/latest/reference/)
# Delete a distribution
The following procedure deletes a distribution by using the CloudFront console. For information about deleting with the CloudFront API, see [DeleteDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DeleteDistribution.html) in the *Amazon CloudFront API Reference*.
If you need to delete a distribution with an OAC attached to an S3 bucket, see [Delete a distribution with an OAC attached to an S3 bucket](private-content-restricting-access-to-s3.md#delete-oac-distribution-s3) for important details.
**Warning**
Before you can delete a distribution, you must disable it, which requires permission to update the distribution. Once deleted, a distribution cannot be recovered.
If you disable a distribution that has an alternate domain name associated with it, CloudFront stops accepting traffic for that domain name (such as www.example.com), even if another distribution has an alternate domain name with a wildcard (\$1) that matches the same domain (such as \$1.example.com).
You can't delete a distribution that is subscribed to a [CloudFront flat-rate pricing plan](flat-rate-pricing-plan.md). You will receive an error that says, "You can't delete this distribution while it's subscribed to a pricing plan." You must first cancel the pricing plan and then after the current billing cycle, delete the distribution.
------
#### [ Multi-tenant ]
Before you can delete a multi-tenant distribution, you must first delete all associated distribution tenants from it.
**To delete a multi-tenant distribution**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. In the right pane of the CloudFront console, choose the name of the multi-tenant distribution that you want to delete.
1. For **Tenants**, select and delete all associated distribution tenants.
1. Choose **Disable** to disable the distribution, and choose **Disable distribution** to confirm.
1. Wait until the new timestamp appears under the **Last modified** column.
+ It might take a few minutes for CloudFront to propagate your change to all edge locations.
1. Choose **Delete**, **Delete distribution**.
**To delete a distribution tenant**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Under **SaaS**, choose **Distribution tenants**.
1. Search for the distribution tenant. Use the dropdown menu in the search bar to filter by domain, name, distribution ID, certificate ID, connection group ID, or web ACL ID.
1. Select the distribution tenant to delete.
1. Choose **Delete tenant**, **Delete distribution tenant**.
------
#### [ Standard ]
**To delete a standard distribution**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. In the right pane of the CloudFront console, find the distribution that you want to delete.
+ If the **Status** column shows that the distribution is already **Disabled**, skip to Step 6.
+ If the **Status** shows **Enabled** but the distribution still shows **Deploying** in the **Last modified** column, wait for deployment to finish before continuing to step 3.
1. In the right pane of the CloudFront console, select the check box for the distribution that you want to delete.
1. Choose **Disable** to disable the distribution, and choose **Yes, Disable** to confirm. Then choose **Close**.
+ The value of the **Status** column immediately changes to **Disabled**.
1. Wait until the new timestamp appears under the **Last modified** column.
+ It might take a few minutes for CloudFront to propagate your change to all edge locations.
1. Select the check box for the distribution that you want to delete.
1. Choose **Delete**, **Delete**.
+ If the **Delete** option isn't available, it means that CloudFront is still propagating your change to the edge locations. Wait until the new timestamp appears under the **Last modified** column, then repeat steps 6-7.
------
# Use various origins with CloudFront distributions
Use various origins
When you create a distribution, you specify the *origin* where CloudFront sends requests for the files. You can use several different kinds of origins with CloudFront. For example, you can use an Amazon S3 bucket, a MediaStore container, a MediaPackage channel, an Application Load Balancer, or an AWS Lambda function URL. When you create your CloudFront distribution, CloudFront automatically 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).
If you have an Application Load Balancer, Network Load Balancer, or EC2 instance in a private subnet, you can use it as a VPC origin. With VPC origins, your applications can be accessed only in a private subnet with a CloudFront distribution, which prevents your application from being accessible on the public internet. For more information, see [Restrict access with VPC origins](private-content-vpc-origins.md).
**Note**
You can use edge functions to dynamically select the appropriate origin for each request. By using CloudFront Functions or Lambda@Edge, you can route requests to different origins based on factors such as the viewer's geographic location, the request headers, or query string parameters. For more information, see [Customize at the edge with functions](edge-functions.md).
**Topics**
+ [
## Use an Amazon S3 bucket
](#using-s3-as-origin)
+ [
## Use a MediaStore container or a MediaPackage channel
](#concept_AWS_Media)
+ [
## Use an Application Load Balancer
](#concept_elb_origin)
+ [
## Use a Network Load Balancer
](#concept_nlb_origin)
+ [
## Use a Lambda function URL
](#concept_lambda_function_url)
+ [
## Use Amazon EC2 (or another custom origin)
](#concept_CustomOrigin)
+ [
## Use CloudFront origin groups
](#concept_origin_groups)
+ [
## Use Amazon API Gateway
](#use-api-gate-way-origin)
## Use an Amazon S3 bucket
The following topics describe the different ways that you can use an Amazon S3 bucket as the origin for a CloudFront distribution.
**Topics**
+ [
### Use a standard Amazon S3 bucket
](#concept_S3Origin)
+ [
### Use Amazon S3 Object Lambda
](#using-S3-Object-Lambda)
+ [
### Use Amazon S3 Access Point
](#using-S3-Access-Point)
+ [
### Use an Amazon S3 bucket that's configured as a website endpoint
](#concept_S3Origin_website)
+ [
### Add CloudFront to an existing Amazon S3 bucket
](#adding-cloudfront-to-s3)
+ [
### Move an Amazon S3 bucket to a different AWS Region
](#move-s3-bucket-different-region)
+ [
### Use an Amazon S3 Multi-Region Access Point
](#using-s3-mrap-as-origin)
### Use a standard Amazon S3 bucket
When you use Amazon S3 as an origin for your distribution, you place the objects that you want CloudFront to deliver in an Amazon S3 bucket. You can use any method that is supported by Amazon S3 to get your objects into Amazon S3. For example, you can use the Amazon S3 console or API, or a third-party tool. You can create a hierarchy in your bucket to store the objects, just as you would with any other standard Amazon S3 bucket.
Using an existing Amazon S3 bucket as your CloudFront origin server doesn't change the bucket in any way; you can still use it as you normally would to store and access Amazon S3 objects at the standard Amazon S3 price. You incur regular Amazon S3 charges for storing the objects in the bucket. For more information about the charges to use CloudFront, see [Amazon CloudFront Pricing](https://aws.amazon.com/cloudfront/pricing/). For more information about using CloudFront with an existing S3 bucket, see [Add CloudFront to an existing Amazon S3 bucket](#adding-cloudfront-to-s3).
**Important**
For your bucket to work with CloudFront, the name must conform to DNS naming requirements. For more information, go to [Bucket naming rules](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html) in the *Amazon Simple Storage Service User Guide*.
When you specify an Amazon S3 bucket as an origin for CloudFront, we recommend that you use the following format:
`bucket-name.s3.region.amazonaws.com`
When you specify the bucket name in this format, you can use the following CloudFront features:
+ Configure CloudFront to communicate with your Amazon S3 bucket using SSL/TLS. For more information, see [Use HTTPS with CloudFront](using-https.md).
+ Use an origin access control to require that viewers access your content using CloudFront URLs, not by using Amazon S3 URLs. For more information, see [Restrict access to an Amazon S3 origin](private-content-restricting-access-to-s3.md).
+ Update the content of your bucket by submitting `POST` and `PUT` requests to CloudFront. For more information, see [HTTP methods](RequestAndResponseBehaviorS3Origin.md#RequestS3HTTPMethods) in the topic [How CloudFront processes and forwards requests to your Amazon S3 origin](RequestAndResponseBehaviorS3Origin.md#RequestBehaviorS3Origin).
Don't specify the bucket using the following formats:
+ The Amazon S3 path style: `s3.amazonaws.com/bucket-name`
+ The Amazon S3 CNAME
**Note**
CloudFront supports S3 origins using any storage class, including S3 Intelligent-Tiering. When CloudFront requests objects from an S3 origin, the objects are retrieved regardless of the storage tier they currently reside in. Using CloudFront with S3 Intelligent-Tiering doesn't impact the performance or functionality of your distribution. For more information, see [Managing storage costs with Amazon S3 Intelligent-Tiering](https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering.html) in the *Amazon Simple Storage Service User Guide*.
### Use Amazon S3 Object Lambda
Create an origin using Amazon S3 Object Lambda
You can use an Amazon S3 Object Lambda Access Point alias as an origin for your distribution.
When you [create an Object Lambda Access Point](https://docs.aws.amazon.com/AmazonS3/latest/userguide/olap-create.html), Amazon S3 automatically generates a unique alias for your Object Lambda Access Point. You can [use this alias](https://docs.aws.amazon.com/AmazonS3/latest/userguide/olap-use.html#ol-access-points-alias) instead of an Amazon S3 bucket name as an origin for your CloudFront distribution.
When you use an Object Lambda Access Point alias as an origin for CloudFront, we recommend that you use the following format:
`alias.s3.region.amazonaws.com`
For more information about finding the `alias`, see [How to use a bucket-style alias for your S3 bucket Object Lambda Access Point](https://docs.aws.amazon.com/AmazonS3/latest/userguide/olap-use.html#ol-access-points-alias) in the *Amazon S3 User Guide*.
**Important**
When you use an Object Lambda Access Point as an origin for CloudFront, you must use [origin access control](private-content-restricting-access-to-s3.md).
For an example use case, see [Use Amazon S3 Object Lambda with Amazon CloudFront to Tailor Content for End Users](https://aws.amazon.com/blogs/aws/new-use-amazon-s3-object-lambda-with-amazon-cloudfront-to-tailor-content-for-end-users/).
CloudFront treats an Object Lambda Access Point origin the same as [a standard Amazon S3 bucket origin](#concept_S3Origin).
If you're using Amazon S3 Object Lambda as an origin for your distribution, you must configure the following four permissions.
------
#### [ Object Lambda Access Point ]
**To add permissions for the Object Lambda Access Point**
1. Sign in to the AWS Management Console and open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. In the navigation pane, choose **Object Lambda Access Points**.
1. Choose the Object Lambda Access Point that you want to use.
1. Choose the **Permissions** tab.
1. Choose **Edit** in the **Object Lambda Access Point policy** section.
1. Paste the following policy into the **Policy** field.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "cloudfront.amazonaws.com"
},
"Action": "s3-object-lambda:Get*",
"Resource": "arn:aws:s3-object-lambda:us-east-1:123456789012:accesspoint/Object-Lambda-Access-Point-name",
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:aws:cloudfront::123456789012:distribution/CloudFront-distribution-ID"
}
}
}
]
}
```
------
1. Choose **Save changes**.
------
#### [ Amazon S3 Access Point ]
**To add permissions for the Amazon S3 Access Point**
1. Sign in to the AWS Management Console and open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. In the navigation pane, choose **Access Points**.
1. Choose the Amazon S3 Access Point that you want to use.
1. Choose the **Permissions** tab.
1. Choose **Edit** in the **Access Point policy** section.
1. Paste the following policy into the **Policy** field.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "default",
"Statement": [
{
"Sid": "s3objlambda",
"Effect": "Allow",
"Principal": {
"Service": "cloudfront.amazonaws.com"
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:us-east-1:123456789012:accesspoint/Access-Point-name",
"arn:aws:s3:us-east-1:123456789012:accesspoint/Access-Point-name/object/*"
],
"Condition": {
"ForAnyValue:StringEquals": {
"aws:CalledVia": "s3-object-lambda.amazonaws.com"
}
}
}
]
}
```
------
1. Choose **Save**.
------
#### [ Amazon S3 bucket ]
**To add permissions to the Amazon S3 bucket**
1. Sign in to the AWS Management Console and open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. In the navigation pane, choose **Buckets**.
1. Choose the Amazon S3 bucket that you want to use.
1. Choose the **Permissions** tab.
1. Choose **Edit** in the **Bucket policy** section.
1. Paste the following policy into the **Policy** field.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "*",
"Resource": [
"arn:aws:s3:::bucket-name",
"arn:aws:s3:::bucket-name/*"
],
"Condition": {
"StringEquals": {
"s3:DataAccessPointAccount": "AWS-account-ID"
}
}
}
]
}
```
------
1. Choose **Save changes**.
------
#### [ AWS Lambda function ]
**To add permissions to the Lambda function**
1. Sign in to the AWS Management Console and open the AWS Lambda console at [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/).
1. In the navigation pane, choose **Functions**.
1. Choose the AWS Lambda function that you want to use.
1. Choose the **Configuration** tab, then choose **Permissions**.
1. Choose **Add permissions** in the **Resource-based policy statements** section.
1. Choose **AWS account**.
1. Enter a name for **Statement ID**.
1. Enter `cloudfront.amazonaws.com` for **Principal**.
1. Choose `lambda:InvokeFunction` from the **Action** dropdown menu.
1. Choose **Save**.
------
### Use Amazon S3 Access Point
When you [use an S3 Access Point](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-access-points.html), Amazon S3 automatically generates a unique alias for you. You can use this alias instead of an Amazon S3 bucket name as an origin for your CloudFront distribution.
When you use an Amazon S3 Access Point alias as an origin for CloudFront, we recommend that you use the following format:
`alias.s3.region.amazonaws.com`
For more information about finding the `alias`, see [Using a bucket-style alias for your S3 bucket access point](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-points-alias.html) in the *Amazon S3 User Guide*.
**Important**
When you use an Amazon S3 Access Point as an origin for CloudFront, you must use [origin access control](private-content-restricting-access-to-s3.md).
CloudFront treats an Amazon S3 Access Point origin the same as [a standard Amazon S3 bucket origin](#concept_S3Origin).
If you're using Amazon S3 Object Lambda as an origin for your distribution, you must configure the following two permissions.
------
#### [ Amazon S3 Access Point ]
**To add permissions for the Amazon S3 Access Point**
1. Sign in to the AWS Management Console and open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. In the navigation pane, choose **Access Points**.
1. Choose the Amazon S3 Access Point that you want to use.
1. Choose the **Permissions** tab.
1. Choose **Edit** in the **Access Point policy** section.
1. Paste the following policy into the **Policy** field.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "default",
"Statement": [
{
"Sid": "s3objlambda",
"Effect": "Allow",
"Principal": {"Service": "cloudfront.amazonaws.com"},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:us-east-1:123456789012:accesspoint/Access-Point-name",
"arn:aws:s3:us-east-1:123456789012:accesspoint/Access-Point-name/object/*"
],
"Condition": {
"StringEquals": {"aws:SourceArn": "arn:aws:cloudfront::123456789012:distribution/CloudFront-distribution-ID"}
}
}
]
}
```
------
1. Choose **Save**.
------
#### [ Amazon S3 bucket ]
**To add permissions to the Amazon S3 bucket**
1. Sign in to the AWS Management Console and open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. In the navigation pane, choose **Buckets**.
1. Choose the Amazon S3 bucket that you want to use.
1. Choose the **Permissions** tab.
1. Choose **Edit** in the **Bucket policy** section.
1. Paste the following policy into the **Policy** field.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "*",
"Resource": [
"arn:aws:s3:::bucket-name",
"arn:aws:s3:::bucket-name/*"
],
"Condition": {
"StringEquals": {
"s3:DataAccessPointAccount": "AWS-account-ID"
}
}
}
]
}
```
------
1. Choose **Save changes**.
------
### Use an Amazon S3 bucket that's configured as a website endpoint
You can use an Amazon S3 bucket that's configured as a website endpoint as a custom origin with CloudFront. When you configure your CloudFront distribution, for the origin, enter the Amazon S3 static website hosting endpoint for your bucket. This value appears in the [Amazon S3 console](https://console.aws.amazon.com/s3/), on the **Properties** tab, in the **Static website hosting** pane. For example:
`http://bucket-name.s3-website-region.amazonaws.com`
For more information about specifying Amazon S3 static website endpoints, see [Website endpoints](https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteEndpoints.html) in the *Amazon Simple Storage Service User Guide*.
When you specify the bucket name in this format as your origin, you can use Amazon S3 redirects and Amazon S3 custom error documents. For more information, see [Configuring a custom error document](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CustomErrorDocSupport.html) and [Configuring a redirect](https://docs.aws.amazon.com/AmazonS3/latest/userguide/how-to-page-redirect.html) in the *Amazon Simple Storage Service User Guide*. (CloudFront also provides custom error pages. For more information, see [Create a custom error page for specific HTTP status codes](creating-custom-error-pages.md).)
Using an Amazon S3 bucket as your CloudFront origin server doesn't change the bucket in any way. You can still use it as you normally would and you incur regular Amazon S3 charges. For more information about the charges to use CloudFront, see [Amazon CloudFront Pricing](https://aws.amazon.com/cloudfront/pricing/).
**Note**
If you use the CloudFront API to create your distribution with an Amazon S3 bucket that is configured as a website endpoint, you must configure it by using `CustomOriginConfig`, even though the website is hosted in an Amazon S3 bucket. For more information about creating distributions by using the CloudFront API, see [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html) in the *Amazon CloudFront API Reference*.
### Add CloudFront to an existing Amazon S3 bucket
If you store your objects in an Amazon S3 bucket, you can either have users get your objects directly from S3, or you can configure CloudFront to get your objects from S3 and then distribute them to your users. Using CloudFront can be more cost effective if your users access your objects frequently because, at higher usage, the price for CloudFront data transfer is lower than the price for Amazon S3 data transfer. In addition, downloads are faster with CloudFront than with Amazon S3 alone because your objects are stored closer to your users.
**Note**
If you want CloudFront to respect Amazon S3 cross-origin resource sharing settings, configure CloudFront to forward the `Origin` header to Amazon S3. For more information, see [Cache content based on request headers](header-caching.md).
If you currently distribute content directly from your Amazon S3 bucket using your own domain name (such as example.com) instead of the domain name of your Amazon S3 bucket (such as amzn-s3-demo-bucket.s3.us-west-2.amazonaws.com), you can add CloudFront with no disruption by using the following procedure.
**To add CloudFront when you're already distributing your content from Amazon S3**
1. Create a CloudFront distribution. For more information, see [Create a distribution](distribution-web-creating-console.md).
When you create the distribution, specify the name of your Amazon S3 bucket as the origin server.
**Important**
For your bucket to work with CloudFront, the name must conform to DNS naming requirements. For more information, go to [Bucket naming rules](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html) in the *Amazon Simple Storage Service User Guide*.
If you're using a CNAME with Amazon S3, specify the CNAME for your distribution, too.
1. Create a test webpage that contains links to publicly readable objects in your Amazon S3 bucket, and test the links. For this initial test, use the CloudFront domain name of your distribution in the object URLs, for example, `https://d111111abcdef8.cloudfront.net/images/image.jpg`.
For more information about the format of CloudFront URLs, see [Customize the URL format for files in CloudFront](LinkFormat.md).
1. If you're using Amazon S3 CNAMEs, your application uses your domain name (for example, example.com) to reference the objects in your Amazon S3 bucket instead of using the name of your bucket (for example, amzn-s3-demo-bucket.s3.amazonaws.com). To continue using your domain name to reference objects instead of using the CloudFront domain name for your distribution (for example, d111111abcdef8.cloudfront.net), you need to update your settings with your DNS service provider.
For Amazon S3 CNAMEs to work, your DNS service provider must have a CNAME resource record set for your domain that currently routes queries for the domain to your Amazon S3 bucket. For example, if a user requests this object:
`https://example.com/images/image.jpg`
The request is automatically rerouted, and the user sees this object:
`https://amzn-s3-demo-bucket.s3.amazonaws.com/images/image.jpg`
To route queries to your CloudFront distribution instead of your Amazon S3 bucket, you need to use the method provided by your DNS service provider to update the CNAME resource record set for your domain. This updated CNAME record redirects DNS queries from your domain to the CloudFront domain name for your distribution. For more information, see the documentation provided by your DNS service provider.
**Note**
If you're using Route 53 as your DNS service, you can use either a CNAME resource record set or an alias resource record set. For information about editing resource record sets, see [Editing records](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-editing.html). For information about alias resource record sets, see [Choosing between alias and non-alias records](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html). Both topics are in the *Amazon Route 53 Developer Guide*.
For more information about using CNAMEs with CloudFront, see [Use custom URLs by adding alternate domain names (CNAMEs)](CNAMEs.md).
After you update the CNAME resource record set, it can take up to 72 hours for the change to propagate throughout the DNS system, although it usually happens faster. During this time, some requests for your content will continue to be routed to your Amazon S3 bucket, and others will be routed to CloudFront.
### Move an Amazon S3 bucket to a different AWS Region
If you're using Amazon S3 as the origin for a CloudFront distribution and you move the bucket to a different AWS Region, CloudFront can take up to an hour to update its records to use the new Region when both of the following are true:
+ You're using a CloudFront origin access identity (OAI) to restrict access to the bucket.
+ You move the bucket to an Amazon S3 Region that requires Signature Version 4 for authentication.
When you're using OAIs, CloudFront uses the Region (among other values) to calculate the signature that it uses to request objects from your bucket. For more information about OAIs, see [Use an origin access identity (legacy, not recommended)](private-content-restricting-access-to-s3.md#private-content-restricting-access-to-s3-oai). For a list of AWS Regions that support Signature Version 2, see [Signature Version 2 signing process](https://docs.aws.amazon.com/general/latest/gr/signature-version-2.html) in the *Amazon Web Services General Reference*.
To force a faster update to CloudFront's records, you can update your CloudFront distribution, for example, by updating the **Description** field on the **General** tab in the CloudFront console. When you update a distribution, CloudFront immediately checks the Region that your bucket is in. Propagation of the change to all edge locations should take only a few minutes.
### Use an Amazon S3 Multi-Region Access Point
You can also use an Amazon S3 Multi-Region Access Point as a CloudFront origin. Amazon S3 Multi-Region Access Points provide a global endpoint that automatically routes requests to the closest Amazon S3 bucket based on network latency. When you use an Amazon S3 Multi-Region Access Point as an origin, specify the Multi-Region Access Point hostname as the origin domain name:
`multi-region-access-point-alias.accesspoint.s3-global.amazonaws.com`
To restrict access to the S3 Multi-Region Access Point so that it's only accessible through your CloudFront distribution, see [Restrict access to an Amazon S3 Multi-Region Access Point origin](private-content-restricting-access-to-s3-mrap.md).
## Use a MediaStore container or a MediaPackage channel
To stream video using CloudFront, you can set up an Amazon S3 bucket that is configured as a MediaStore container, or create a channel and endpoints with MediaPackage. Then you create and configure a distribution in CloudFront to stream the video.
For more information and step-by-step instructions, see the following topics:
+ [Serve video by using AWS Elemental MediaStore as the origin](live-streaming.md#video-streaming-mediastore)
+ [Serve live video formatted with AWS Elemental MediaPackage](live-streaming.md#live-streaming-with-mediapackage)
## Use an Application Load Balancer
You can use CloudFront to route traffic to both internal and internet-facing Application Load Balancers.
If your origin is one or more HTTP(S) servers (web servers) hosted on one or more Amazon EC2 instances, you can choose to use an internet-facing Application Load Balancer to distribute traffic to the instances. An internet-facing load balancer has a publicly resolvable DNS name and routes requests from clients to targets over the internet.
For more information about using an internet-facing Application Load Balancer as your origin for CloudFront, including how to make sure that viewers can only access your web servers through CloudFront and not by accessing the load balancer directly, see [Restrict access to Application Load Balancers](restrict-access-to-load-balancer.md).
Alternatively, you can use VPC origins to deliver content from applications that are hosted with an internal Application Load Balancer in your virtual private cloud (VPC) private subnets. VPC origins prevents your application from being accessible on the public internet. For more information, see [Restrict access with VPC origins](private-content-vpc-origins.md).
## Use a Network Load Balancer
You can use both internal and internet-facing Network Load Balancers with Amazon CloudFront. You can use internal Network Load Balancers inside private subnets with CloudFront by using VPC origins. CloudFront VPC origins allow you to serve content from applications hosted in private VPC subnets without exposing them to the public internet. For more information, see [Restrict access with VPC origins](private-content-vpc-origins.md).
Alternatively, you can also use CloudFront for delivering traffic from internet-facing Network Load Balancers. An internet-facing load balancer has a publicly resolvable DNS name and can receive requests from both clients on the internet and CloudFront distributions.
## Use a Lambda function URL
CloudFront supports Lambda function URLs
If you build a serverless web application by using Lambda functions with function URLs, you can now add CloudFront for an array of benefits.
A [Lambda function URL](https://docs.aws.amazon.com/lambda/latest/dg/lambda-urls.html) is a dedicated HTTPS endpoint for a Lambda function. You can use a Lambda function URL to build a serverless web application entirely within Lambda. You can invoke the Lambda web application directly through the function URL, with no need to integrate with API Gateway or an Application Load Balancer.
If you build a serverless web application by using Lambda functions with function URLs, you can add CloudFront to get the following benefits:
+ Speed up your application by caching content closer to viewers
+ Use a custom domain name for your web application
+ Route different URL paths to different Lambda functions using CloudFront cache behaviors
+ Block specific requests using CloudFront geographic restrictions or AWS WAF (or both)
+ Use AWS WAF with CloudFront to help protect your application from malicious bots, help prevent common application exploits, and enhance protection from DDoS attacks
To use a Lambda function URL as the origin for a CloudFront distribution, specify the full domain name of the Lambda function URL as the origin domain. A Lambda function URL domain name uses the following format:
`function-URL-ID.lambda-url.AWS-Region.on.aws`
When you use a Lambda function URL as the origin for a CloudFront distribution, the function URL must be publicly accessible. To do so, use one of the following options:
+ If you use origin access control (OAC), the `AuthType` parameter of the Lambda function URL must use the `AWS_IAM` value and allow the `lambda:InvokeFunctionUrl` and `lambda:InvokeFunction` permissions in a resource-based policy. For more information about using Lambda function URLs for OAC, see [Restrict access to an AWS Lambda function URL origin](private-content-restricting-access-to-lambda.md).
+ If you don't use OAC, you can set the `AuthType` parameter of the function URL to `NONE` and allow the `lambda:InvokeFunctionUrl` permission in a resource-based policy.
You can also [add a custom origin header](add-origin-custom-headers.md) to the requests that CloudFront sends to the origin, and write function code to return an error response if the header isn't present in the request. This helps to make sure that users can only access your web application through CloudFront, not directly using the Lambda function URL.
For more information about Lambda function URLs, see the following topics in the *AWS Lambda Developer Guide*:
+ [Lambda function URLs](https://docs.aws.amazon.com/lambda/latest/dg/lambda-urls.html) – A general overview of the Lambda function URLs feature
+ [Invoking Lambda function URLs](https://docs.aws.amazon.com/lambda/latest/dg/urls-invocation.html) – Includes details about the request and response payloads to use for coding your serverless web application
+ [Security and auth model for Lambda function URLs](https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html) – Includes details about the Lambda auth types
## Use Amazon EC2 (or another custom origin)
You can use both internal and internet-facing EC2 instances with Amazon CloudFront. You can use internal EC2 instances inside private subnets with CloudFront by using VPC origins. CloudFront VPC origins allow you to serve content from applications hosted in private VPC subnets without exposing them to the public internet. For more information, see [Restrict access with VPC origins](private-content-vpc-origins.md).
A custom origin is an HTTP(S) web server with a publicly resolvable DNS name that routes requests from clients to targets over the internet. The HTTP(S) server can be hosted on AWS–for example, an Amazon EC2 instance–or hosted somewhere else. An Amazon S3 origin configured as a website endpoint is also considered a custom origin. For more information, see [Use an Amazon S3 bucket that's configured as a website endpoint](#concept_S3Origin_website).
When you use your own HTTP server as a custom origin, you specify the DNS name of the server, along with the HTTP and HTTPS ports and the protocol that you want CloudFront to use when fetching objects from your origin.
Most CloudFront features are supported when you use a custom origin with the exception of private content. Although you can use a signed URL to distribute content from a custom origin, for CloudFront to access the custom origin, the origin must remain publicly accessible. For more information, see [Serve private content with signed URLs and signed cookies](PrivateContent.md).
Follow these guidelines for using Amazon EC2 instances and other custom origins with CloudFront.
+ Host and serve the same content on all servers that are serving content for the same CloudFront origin. For more information, see [Origin settings](DownloadDistValuesOrigin.md) in the [All distribution settings reference](distribution-web-values-specify.md) topic.
+ Log the `X-Amz-Cf-Id` header entries on all servers in case you need Support or CloudFront to use this value for debugging.
+ Restrict requests to the HTTP and HTTPS ports that your custom origin listens on.
+ Synchronize the clocks of all servers in your implementation. Note that CloudFront uses Coordinated Universal Time (UTC) for signed URLs and signed cookies, for logs, and reports. In addition, if you monitor CloudFront activity using CloudWatch metrics, note that CloudWatch also uses UTC.
+ Use redundant servers to handle failures.
+ For information about using a custom origin to serve private content, see [Restrict access to files on custom origins](private-content-overview.md#forward-custom-headers-restrict-access).
+ For information about request and response behavior and about supported HTTP status codes, see [Request and response behavior](RequestAndResponseBehavior.md).
If you use Amazon EC2 for a custom origin, we recommend that you do the following:
+ Use an Amazon Machine Image that automatically installs the software for a web server. For more information, see the [Amazon EC2 documentation](https://docs.aws.amazon.com/ec2/index.html).
+ Use an Elastic Load Balancing load balancer to handle traffic across multiple Amazon EC2 instances and to isolate your application from changes to Amazon EC2 instances. For example, if you use a load balancer, you can add and delete Amazon EC2 instances without changing your application. For more information, see the [Elastic Load Balancing documentation](https://docs.aws.amazon.com/elasticloadbalancing/index.html).
+ When you create your CloudFront distribution, specify the URL of the load balancer for the domain name of your origin server. For more information, see [Create a distribution](distribution-web-creating-console.md).
## Use CloudFront origin groups
You can specify an origin group for your CloudFront origin if, for example, you want to configure origin failover for scenarios when you need high availability. Use origin failover to designate a primary origin for CloudFront plus a second origin that CloudFront automatically switches to when the primary origin returns specific HTTP status code failure responses.
For more information, including the steps for setting up an origin group, see [Optimize high availability with CloudFront origin failover](high_availability_origin_failover.md).
## Use Amazon API Gateway
You can use API Gateway as a custom origin for your CloudFront distribution. For more information, see the following topics:
+ [Securing Amazon API Gateway with secure ciphers using Amazon CloudFront](https://aws.amazon.com/blogs/networking-and-content-delivery/securing-amazon-api-gateway-with-secure-ciphers-using-amazon-cloudfront/) AWS blog post
+ [How do I set up API Gateway with my own CloudFront distribution?](https://repost.aws/knowledge-center/api-gateway-cloudfront-distribution) AWS re:Post
# Enable IPv6 for CloudFront distributions
Enable IPv6
Amazon CloudFront supports both IPv4 and IPv6 from clients to AWS edge locations. CloudFront also supports IPv6 and dual-stack (IPv4 and IPv6) connectivity towards origins. This helps you achieve end-to-end IPv6 delivery.
IPv6 is the next-generation internet protocol designed to replace IPv4. While IPv4 uses 32-bit addresses (such as 192.0.2.44), IPv6 uses 128-bit addresses (such as 2001:0db8:85a3::8a2e:0370:7334). IPv6 provides an expanded address space to accommodate more internet-connected devices.
**Topics**
+ [
## IPv6 viewer requests
](#ipv6-viewer-requests)
+ [
## IPv6 origin requests
](#ipv6-origin-requests)
## IPv6 viewer requests
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 [Create a signed URL using a custom policy](private-content-creating-signed-url-custom-policy.md). For information about creating signed cookies by using a custom policy, see [Set signed cookies using a custom policy](private-content-setting-signed-cookie-custom-policy.md).
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:
+ You enable IPv6 for the distribution
+ You're using alternate domain names in the URLs for your objects
For more information, see [Routing traffic to an Amazon CloudFront distribution by using your domain name](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-cloudfront-distribution.html) 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 [Log file fields](standard-logs-reference.md#BasicDistributionFileFormat).
**Note**
To maintain high customer availability, CloudFront responds to viewer requests by using IPv4 if our data suggests that IPv4 will provide a better user experience. To find out what percentage of requests CloudFront is serving over IPv6, enable CloudFront logging for your distribution and parse the `c-ip` column, which contains the IP address of the viewer that made the request. This percentage should grow over time, but it will remain a minority of traffic as IPv6 is not yet supported by all viewer networks globally. Some viewer networks have excellent IPv6 support, but others don't support IPv6 at all. (A viewer network is analogous to your home internet or wireless carrier.)
For more information about our support for IPv6, see the [CloudFront FAQ](https://aws.amazon.com/cloudfront/faqs/). For information about enabling access logs, see the [Standard logging](DownloadDistValuesGeneral.md#DownloadDistValuesLoggingOnOff) and [Log prefix](DownloadDistValuesGeneral.md#DownloadDistValuesLogPrefix) fields.
## IPv6 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 custom origins (excluding Amazon S3 and VPC origins), you have the following connectivity options:
+ **IPv4 only (default)** – This is the default configuration that CloudFront uses to connect to origins over IPv4.
+ **IPv6 only** – Requires your origin domain to resolve to an IPv6 address. CloudFront will exclusively use IPv6 addresses for origin connections.
+ **Dual-stack** – Enables connections over IPv4 and IPv6. CloudFront automatically chooses IPv4 or IPv6 origin connectivity to prioritize performance and availability so that you can use CloudFront as an IPv6 and IPv4 dual-stack internet gateway for your web applications.
Choose the option that aligns with your origin's network configuration and connectivity requirements. For more information, see [Designing DNS for IPv6](https://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/designing-dns-for-ipv6.html) and [IPv6 security and monitoring considerations](https://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/ipv6-security-and-monitoring-considerations.html).
# Use CloudFront continuous deployment to safely test CDN configuration changes
Use continuous deployment to safely test changesContinuous deployment for safely testing configuration changes
You can now deploy changes to your CDN configuration by testing with a subset of production traffic.
With Amazon CloudFront *continuous deployment* you can safely deploy changes to your CDN configuration by testing first with a subset of production traffic. You can use a *staging distribution* and a *continuous deployment policy* to send some traffic from real (production) viewers to the new CDN configuration and validate that it works as expected. You can monitor the performance of the new configuration in real time, and promote the new configuration to serve all traffic via the *primary distribution* when you're ready.
The following diagram shows the benefit of using CloudFront continuous deployment. Without it, you would have to test CDN configuration changes with simulated traffic. With continuous deployment you can test the changes with a subset of production traffic, then promote the changes to the primary distribution when you're ready.
![\[Graphic of CloudFront continuous deployment that sends production traffic to a staging distribution.\]](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/images/cloudfront-continuous-deployment.png)
Learn more about working with continuous deployment in the following topics.
**Topics**
+ [
# CloudFront continuous deployment workflow
](continuous-deployment-workflow.md)
+ [
# Work with a staging distribution and continuous deployment policy
](working-with-staging-distribution-continuous-deployment-policy.md)
+ [
# Monitor a staging distribution
](monitoring-staging-distribution.md)
+ [
# Learn how continuous deployment works
](understanding-continuous-deployment.md)
+ [
# Quotas and other considerations for continuous deployment
](continuous-deployment-quotas-considerations.md)
# CloudFront continuous deployment workflow
The following high-level workflow explains how to safely test and deploy configuration changes with CloudFront continuous deployment.
1. Choose the distribution that you want to use as the *primary distribution*. The primary distribution is one that currently serves production traffic.
1. From the primary distribution, create a *staging distribution*. A staging distribution starts as a copy of the primary distribution.
1. Create a *traffic configuration* inside a *continuous deployment policy*, and attach it to the primary distribution. This determines how CloudFront routes traffic to the staging distribution. For more information about routing requests to a staging distribution, see [Route requests to the staging distribution](understanding-continuous-deployment.md#understanding-continuous-deployment-routing).
1. Update the configuration of the staging distribution. For more information about the settings that you can update, see [Update primary and staging distributions](understanding-continuous-deployment.md#updating-staging-and-primary-distributions).
1. Monitor the staging distribution to determine whether the configuration changes perform as expected. For more information about monitoring a staging distribution, see [Monitor a staging distribution](monitoring-staging-distribution.md).
As you monitor the staging distribution, you can:
+ Update the configuration of the staging distribution again, to continue testing configuration changes.
+ Update the continuous deployment policy (traffic configuration) to send more or less traffic to the staging distribution.
1. When you're satisfied with the performance of the staging distribution, *promote* the staging distribution's configuration to the primary distribution, which copies the staging distribution's configuration to the primary distribution. This also disables the continuous deployment policy which means that CloudFront routes all traffic to the primary distribution.
You can build automation that monitors the performance of the staging distribution (step 5) and promotes the configuration automatically (step 6) when certain criteria are met.
After you promote a configuration, you can reuse the same staging distribution the next time you want to test a configuration change.
For more information about working with staging distributions and continuous deployment policies in the CloudFront console, the AWS CLI, or the CloudFront API, see the following section.
# Work with a staging distribution and continuous deployment policy
You can create, update, and modify staging distributions and continuous deployment policies in the CloudFront console, with the AWS Command Line Interface (AWS CLI), or with the CloudFront API.
## Create a staging distribution with a continuous deployment policy
The following procedures show you how to create a staging distribution with a continuous deployment policy.
------
#### [ Console ]
You can create a staging distribution with a continuous deployment policy by using the AWS Management Console.
**To create a staging distribution and continuous deployment policy (console)**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. In the navigation pane, choose **Distributions**.
1. Choose the distribution that you want to use as the *primary distribution*. The primary distribution is one that currently serves production traffic, the one from which you will create the staging distribution.
1. In the **Continuous deployment** section, choose **Create staging distribution**. This opens the **Create staging distribution** wizard.
1. In the **Create staging distribution** wizard, do the following:
1. (Optional) Type a description for the staging distribution.
1. Choose **Next**.
1. Modify the configuration of the staging distribution. For more information about the settings that you can update, see [Update primary and staging distributions](understanding-continuous-deployment.md#updating-staging-and-primary-distributions).
When you are finished modifying the staging distribution's configuration, choose **Next**.
1. Use the console to specify the **Traffic configuration**. This determines how CloudFront routes traffic to the staging distribution. (CloudFront stores the traffic configuration in a *continuous deployment policy*.)
For more information about the options in a **Traffic configuration**, see [Route requests to the staging distribution](understanding-continuous-deployment.md#understanding-continuous-deployment-routing).
When you are finished with the **Traffic configuration**, choose **Next**.
1. Review the configuration for the staging distribution, including the traffic configuration, then choose **Create staging distribution**.
When you finish the **Create staging distribution** wizard in the CloudFront console, CloudFront does the following:
+ Creates a staging distribution with the settings that you specified (in step 5c)
+ Creates a continuous deployment policy with the traffic configuration that you specified (in step 5d)
+ Attaches the continuous deployment policy to the primary distribution that you created the staging distribution from
When the primary distribution's configuration, with the attached continuous deployment policy, deploys to edge locations, CloudFront begins sending the specified portion of traffic to the staging distribution based on the traffic configuration.
------
#### [ CLI ]
To create a staging distribution and a continuous deployment policy with the AWS CLI, use the following procedures.
**To create a staging distribution (CLI)**
1. Use the **aws cloudfront get-distribution** and **grep** commands together to get the `ETag` value of the distribution that you want to use as the *primary distribution*. The primary distribution is one that currently serves production traffic, from which you will create the staging distribution.
The following command shows an example. In the following example, replace *primary\$1distribution\$1ID* with the ID of the primary distribution.
```
aws cloudfront get-distribution --id primary_distribution_ID | grep 'ETag'
```
Copy the `ETag` value because you need it for the following step.
1. Use the **aws cloudfront copy-distribution** command to create a staging distribution. The following example command uses escape characters (\$1) and line breaks for readability, but you should omit these from the command. In the following example command:
+ Replace *primary\$1distribution\$1ID* with the ID of the primary distribution.
+ Replace *primary\$1distribution\$1ETag* with the `ETag` value of the primary distribution (that you got in the previous step).
+ (Optional) Replace *CLI\$1example* with the desired caller reference ID.
```
aws cloudfront copy-distribution --primary-distribution-id primary_distribution_ID \
--if-match primary_distribution_ETag \
--staging \
--caller-reference 'CLI_example'
```
The command's output shows information about the staging distribution and its configuration. Copy the staging distribution's CloudFront domain name because you need it for a following step.
**To create a continuous deployment policy (CLI with input file)**
1. Use the following command to create file named `continuous-deployment-policy.yaml` that contains all of the input parameters for the **create-continuous-deployment-policy** command. The following command uses escape characters (\$1) and line breaks for readability, but you should omit these from the command.
```
aws cloudfront create-continuous-deployment-policy --generate-cli-skeleton yaml-input \
> continuous-deployment-policy.yaml
```
1. Open the file named `continuous-deployment-policy.yaml` that you just created. Edit the file to specify the continuous deployment policy settings that you want, then save the file. When you edit the file:
+ In the `StagingDistributionDnsNames` section:
+ Change the value of `Quantity` to `1`.
+ For `Items`, paste the CloudFront domain name of the staging distribution (that you saved from a previous step).
+ In the `TrafficConfig` section:
+ Choose a `Type`, either `SingleWeight` or `SingleHeader`.
+ Remove the settings for the other type. For example, if you want a weight-based traffic configuration, set `Type` to `SingleWeight` and then remove the `SingleHeaderConfig` settings.
+ To use a weight-based traffic configuration, set the value of `Weight` to a decimal number between `.01` (one percent) and `.15` (fifteen percent).
For more information about the options in `TrafficConfig`, see [Route requests to the staging distribution](understanding-continuous-deployment.md#understanding-continuous-deployment-routing) and [Session stickiness for weight-based configurations](understanding-continuous-deployment.md#understanding-continuous-deployment-sessions).
1. Use the following command to create the continuous deployment policy using input parameters from the `continuous-deployment-policy.yaml` file.
```
aws cloudfront create-continuous-deployment-policy --cli-input-yaml file://continuous-deployment-policy.yaml
```
Copy the `Id` value in the command's output. This is the continuous deployment policy ID, and you need it in a following step.
**To attach a continuous deployment policy to a primary distribution (CLI with input file)**
1. Use the following command to save the primary distribution's configuration to a file named `primary-distribution.yaml`. Replace *primary\$1distribution\$1ID* with the primary distribution's ID.
```
aws cloudfront get-distribution-config --id primary_distribution_ID --output yaml > primary-distribution.yaml
```
1. Open the file named `primary-distribution.yaml` that you just created. Edit the file, making the following changes:
+ Paste the continuous deployment policy ID (that you copied from a previous step) into the `ContinuousDeploymentPolicyId` field.
+ Rename the `ETag` field to `IfMatch`, but don't change the field's value.
Save the file when finished.
1. Use the following command to update the primary distribution to use the continuous deployment policy. Replace *primary\$1distribution\$1ID* with the primary distribution's ID.
```
aws cloudfront update-distribution --id primary_distribution_ID --cli-input-yaml file://primary-distribution.yaml
```
When the primary distribution's configuration, with the attached continuous deployment policy, deploys to edge locations, CloudFront begins sending the specified portion of traffic to the staging distribution based on the traffic configuration.
------
#### [ API ]
To create a staging distribution and continuous deployment policy with the CloudFront API, use the following API operations:
+ [CopyDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CopyDistribution.html)
+ [CreateContinuousDeploymentPolicy](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateContinuousDeploymentPolicy.html)
For more information about the fields that you specify in these API calls, see the following:
+ [Route requests to the staging distribution](understanding-continuous-deployment.md#understanding-continuous-deployment-routing)
+ [Session stickiness for weight-based configurations](understanding-continuous-deployment.md#understanding-continuous-deployment-sessions)
+ The API reference documentation for your AWS SDK or other API client
After you create a staging distribution and a continuous deployment policy, use [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) (on the primary distribution) to attach the continuous deployment policy to the primary distribution.
------
## Update a staging distribution
The following procedures show you how to update a staging distribution with a continuous deployment policy.
------
#### [ Console ]
You can update certain configurations for both the primary and staging distributions. For more information, see [Update primary and staging distributions](understanding-continuous-deployment.md#updating-staging-and-primary-distributions).
**To update a staging distribution (console)**
1. Open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. In the navigation pane, choose **Distributions**.
1. Choose the primary distribution. This is the distribution that currently serves production traffic, the one from which you created the staging distribution.
1. Choose **View staging distribution**.
1. Use the console to modify the configuration of the staging distribution. For more information about the settings that you can update, see [Update primary and staging distributions](understanding-continuous-deployment.md#updating-staging-and-primary-distributions).
As soon as the staging distribution's configuration deploys to edge locations it takes effect for incoming traffic that's routed to the staging distribution.
------
#### [ CLI ]
**To update a staging distribution (CLI with input file)**
1. Use the following command to save the staging distribution's configuration to a file named `staging-distribution.yaml`. Replace *staging\$1distribution\$1ID* with the staging distribution's ID.
```
aws cloudfront get-distribution-config --id staging_distribution_ID --output yaml > staging-distribution.yaml
```
1. Open the file named `staging-distribution.yaml` that you just created. Edit the file, making the following changes:
+ Modify the configuration of the staging distribution. For more information about the settings that you can update, see [Update primary and staging distributions](understanding-continuous-deployment.md#updating-staging-and-primary-distributions).
+ Rename the `ETag` field to `IfMatch`, but don't change the field's value.
Save the file when finished.
1. Use the following command to update the staging distribution's configuration. Replace *staging\$1distribution\$1ID* with the staging distribution's ID.
```
aws cloudfront update-distribution --id staging_distribution_ID --cli-input-yaml file://staging-distribution.yaml
```
As soon as the staging distribution's configuration deploys to edge locations it takes effect for incoming traffic that's routed to the staging distribution.
------
#### [ API ]
To update the configuration of a staging distribution, use [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) (on the staging distribution) to modify the configuration of the staging distribution. For more information about the settings that you can update, see [Update primary and staging distributions](understanding-continuous-deployment.md#updating-staging-and-primary-distributions).
------
## Update a continuous deployment policy
The following procedures show you how to update a continuous deployment policy.
------
#### [ Console ]
You can update your distribution's traffic configuration by updating the continuous deployment policy.
**To update a continuous deployment policy (console)**
1. Open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. In the navigation pane, choose **Distributions**.
1. Choose the primary distribution. This is the distribution that currently serves production traffic, the one from which you created the staging distribution.
1. In the **Continuous deployment** section, choose **Edit policy**.
1. Modify the traffic configuration in the continuous deployment policy. When you are finished, choose **Save changes**.
When the primary distribution's configuration with the updated continuous deployment policy deploys to edge locations, CloudFront begins sending traffic to the staging distribution based on the updated traffic configuration.
------
#### [ CLI ]
**To update a continuous deployment policy (CLI with input file)**
1. Use the following command to save the continuous deployment policy's configuration to a file named `continuous-deployment-policy.yaml`. Replace *continuous\$1deployment\$1policy\$1ID* with the continuous deployment policy's ID. The following command uses escape characters (\$1) and line breaks for readability, but you should omit these from the command.
```
aws cloudfront get-continuous-deployment-policy-config --id continuous_deployment_policy_ID \
--output yaml > continuous-deployment-policy.yaml
```
1. Open the file named `continuous-deployment-policy.yaml` that you just created. Edit the file, making the following changes:
+ Modify the configuration of the continuous deployment policy as desired. For example, you can change from using a header-based to a weight-based traffic configuration, or you can change the percentage of traffic (weight) for a weight-based configuration. For more information, see [Route requests to the staging distribution](understanding-continuous-deployment.md#understanding-continuous-deployment-routing) and [Session stickiness for weight-based configurations](understanding-continuous-deployment.md#understanding-continuous-deployment-sessions).
+ Rename the `ETag` field to `IfMatch`, but don't change the field's value.
Save the file when finished.
1. Use the following command to update the continuous deployment policy. Replace *continuous\$1deployment\$1policy\$1ID* with the continuous deployment policy's ID. The following command uses escape characters (\$1) and line breaks for readability, but you should omit these from the command.
```
aws cloudfront update-continuous-deployment-policy --id continuous_deployment_policy_ID \
--cli-input-yaml file://continuous-deployment-policy.yaml
```
When the primary distribution's configuration with the updated continuous deployment policy deploys to edge locations, CloudFront begins sending traffic to the staging distribution based on the updated traffic configuration.
------
#### [ API ]
To update a continuous deployment policy, use [UpdateContinuousDeploymentPolicy](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateContinuousDeploymentPolicy.html).
------
## Promote a staging distribution configuration
The following procedures show you how to promote a staging distribution configuration.
------
#### [ Console ]
When you *promote* a staging distribution, CloudFront copies the configuration from the staging distribution to the primary distribution. CloudFront also disables the continuous deployment policy and routes all traffic to the primary distribution.
After you promote a configuration, you can reuse the same staging distribution the next time you want to test a configuration change.
**To promote a staging distribution's configuration (console)**
1. Open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. In the navigation pane, choose **Distributions**.
1. Choose the primary distribution. This is the distribution that currently serves production traffic, the one from which you created the staging distribution.
1. In the **Continuous deployment** section, choose **Promote**.
1. Type **confirm** and then choose **Promote**.
------
#### [ CLI ]
When you *promote* a staging distribution, CloudFront copies the configuration from the staging distribution to the primary distribution. CloudFront also disables the continuous deployment policy and routes all traffic to the primary distribution.
After you promote a configuration, you can reuse the same staging distribution the next time you want to test a configuration change.
**To promote a staging distribution's configuration (CLI)**
+ Use the **aws cloudfront update-distribution-with-staging-config** command to promote the staging distribution's configuration to the primary distribution. The following example command uses escape characters (\$1) and line breaks for readability, but you should omit these from the command. In the following example command:
+ Replace *primary\$1distribution\$1ID* with the ID of the primary distribution.
+ Replace *staging\$1distribution\$1ID* with the ID of the staging distribution.
+ Replace *primary\$1distribution\$1ETag* and *staging\$1distribution\$1ETag* with the `ETag` values of the primary and staging distributions. Make sure the primary distribution's value is first, as shown in the example.
```
aws cloudfront update-distribution-with-staging-config --id primary_distribution_ID \
--staging-distribution-id staging_distribution_ID \
--if-match 'primary_distribution_ETag,staging_distribution_ETag'
```
------
#### [ API ]
To promote a staging distribution's configuration to the primary distribution, use [UpdateDistributionWithStagingConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistributionWithStagingConfig.html).
------
# Monitor a staging distribution
To monitor the performance of a staging distribution, you can use the same [metrics, logs, and reports](reports-and-monitoring.md) that CloudFront provides for all distributions. For example:
+ You can view the [default CloudFront distribution metrics](viewing-cloudfront-metrics.md#monitoring-console.distributions) (such as total requests and error rate) in the CloudFront console, and you can [turn on additional metrics](viewing-cloudfront-metrics.md#monitoring-console.distributions-additional) (such as cache hit rate and error rate by status code) for an additional cost. You can also create alarms based on these metrics.
+ You can view [standard logs](AccessLogs.md) and [real-time access logs](real-time-logs.md) to get detailed information about the requests that are received by the staging distribution. Standard logs contain the following two fields that help you identify the primary distribution that the request was originally sent to before CloudFront routed it to the staging distribution: `primary-distribution-id` and `primary-distribution-dns-name`.
+ You can view and download [reports](reports.md) in the CloudFront console, for example the cache statistics report.
# Learn how continuous deployment works
The following topics explain how CloudFront continuous deployment works.
**Topics**
+ [
## Route requests to the staging distribution
](#understanding-continuous-deployment-routing)
+ [
## Session stickiness for weight-based configurations
](#understanding-continuous-deployment-sessions)
+ [
## Update primary and staging distributions
](#updating-staging-and-primary-distributions)
+ [
## Primary and staging distributions don't share a cache
](#staging-and-primary-no-shared-cache)
## Route requests to the staging distribution
When you use CloudFront continuous deployment, you don't need to change anything about the viewer requests. Viewers cannot send requests directly to a staging distribution using a DNS name, IP address, or CNAME. Instead, viewers send requests to the primary (production) distribution, and CloudFront routes some of those requests to the staging distribution based on the traffic configuration settings in the continuous deployment policy. There are two types of traffic configurations:
**Weight-based**
A weight-based configuration routes the specified percentage of viewer requests to the staging distribution. When you use a weight-based configuration, you can also enable *session stickiness*, which helps make sure that CloudFront treats requests from the same viewer as part of a single session. For more information, see [Session stickiness for weight-based configurations](#understanding-continuous-deployment-sessions).
**Header-based**
A header-based configuration routes requests to the staging distribution when the viewer request contains a specific HTTP header (you specify the header and the value). Requests that don't contain the specified header and value are routed to the primary distribution. This configuration is useful for local testing, or when you have control over the viewer requests.
Headers routed to your staging distribution must contain the prefix `aws-cf-cd-`.
## Session stickiness for weight-based configurations
When you use a weight-based configuration to route traffic to a staging distribution, you can also enable *session stickiness*, which helps make sure that CloudFront treats requests from the same viewer as a single session. When you enable session stickiness, CloudFront sets a cookie so that all requests from the same viewer in a single session are served by one distribution, either the primary or staging.
When you enable session stickiness, you can also specify the *idle duration*. If the viewer is idle (sends no requests) for this amount of time, the session expires and CloudFront treats future requests from this viewer as a new session. You specify the idle duration as a number of seconds, from 300 (five minutes) to 3600 (one hour).
In the following cases, CloudFront resets all sessions (even active ones) and considers all requests to be a new session:
+ You disable or enable the continuous deployment policy
+ You disable or enable the session stickiness setting
## Update primary and staging distributions
When a primary distribution has an attached continuous deployment policy, the following configuration changes are available for both primary and staging distributions:
+ All cache behavior settings, including the default cache behavior
+ All origin settings (origins and origin groups)
+ Custom error responses (error pages)
+ Geographic restrictions
+ Default root object
+ Logging settings
+ Description (comment)
You can also update external resources that are referenced in a distribution's configuration—such as a cache policy, a response headers policy, a CloudFront function, or a Lambda@Edge function.
## Primary and staging distributions don't share a cache
The primary and staging distributions don't share a cache. When CloudFront sends the first request to a staging distribution, its cache is empty. As requests arrive at the staging distribution, it begins caching responses (if configured to do so).
# Quotas and other considerations for continuous deployment
CloudFront continuous deployment is subject to the following quotas and other considerations.
## Quotas
+ Maximum number of staging distributions per AWS account: 20
+ Maximum number of continuous deployment policies per AWS account: 20
+ Maximum percentage of traffic you can send to a staging distribution in a weight-based configuration: 15%
+ Minimum and maximum values for session stickiness idle duration: 300–3600 seconds
For more information, see [Quotas](cloudfront-limits.md).
**Note**
When using continuous deployment and your primary distribution is set with OAC for S3 bucket access, update your S3 bucket policy to allow access for the staging distribution. For example S3 bucket policies, see [Grant CloudFront permission to access the S3 bucket](private-content-restricting-access-to-s3.md#oac-permission-to-access-s3).
## AWS WAF web ACLs
If you enable continuous deployment for your distribution, the following considerations apply for AWS WAF:
+ You can't associate an AWS WAF web access control list (ACL) to the distribution if it's the first time that ACL has been associated with the distribution.
+ You can't disassociate an AWS WAF web ACL from the distribution.
Before you can do the preceding tasks, you must delete the continuous deployment policy for your production distribution. This also deletes the staging distribution. For more information, see [Use AWS WAF protections](distribution-web-awswaf.md).
## Cases when CloudFront sends all requests to the primary distribution
In certain cases, such as periods of high resource utilization, CloudFront might send all requests to the primary distribution regardless of what's specified in the continuous deployment policy.
CloudFront sends all requests to the primary distribution during peak traffic hours, regardless of what's specified in the continuous deployment policy. Peak traffic refers to the traffic on the *CloudFront service*, and not the traffic on your distribution.
## HTTP/3
You cannot use continuous deployment with a distribution that supports HTTP/3.
# Use custom URLs by adding alternate domain names (CNAMEs)
Use custom URLs
When you create a distribution, CloudFront provides a domain name for it, such as d111111abcdef8.cloudfront.net. Instead of using this provided domain name, you can use an alternate domain name (also known as a CNAME).
To learn how to use your own domain name, such as www.example.com, see the following topics:
**Topics**
+ [
## Requirements for using alternate domain names
](#alternate-domain-names-requirements)
+ [
## Restrictions on using alternate domain names
](#alternate-domain-names-restrictions)
+ [
# Add an alternate domain name
](CreatingCNAME.md)
+ [
# Move an alternate domain name
](alternate-domain-names-move.md)
+ [
# Remove an alternate domain name
](alternate-domain-names-remove-domain.md)
+ [
# Use wildcards in alternate domain names
](alternate-domain-names-wildcard.md)
## Requirements for using alternate domain names
When you add an alternate domain name, such as www.example.com, to a CloudFront distribution, the following are requirements:
**Alternate domain names must be lowercase**
All alternate domain names (CNAMEs) must be lowercase.
**Alternate domain names must be covered by a valid TLS certificate**
To add an alternate domain name (CNAME) to a CloudFront distribution, you must attach to your distribution a trusted, valid TLS certificate that covers the alternate domain name. This ensures that only people with access to your domain’s certificate can associate with CloudFront a CNAME related to your domain.
A trusted certificate is one that is issued by AWS Certificate Manager (ACM) or by another valid certificate authority (CA). You can use a self-signed certificate to validate an existing CNAME, but *not* for a new CNAME. CloudFront supports the same certificate authorities as Mozilla. For the current list, see [ Mozilla Included CA Certificate List](https://wiki.mozilla.org/CA/Included_Certificates). For information about intermediate certificates when using a third-party CA, see [Intermediate certificates](cnames-and-https-requirements.md#https-requirements-intermediate-certificates).
To verify an alternate domain name by using the certificate that you attach, including alternate domain names that include wildcards, CloudFront checks the subject alternative name (SAN) on the certificate. The alternate domain name that you’re adding must be covered by the SAN.
Only one certificate can be attached to a CloudFront distribution at a time.
You prove that you are authorized to add a specific alternate domain name to your distribution by doing one of the following:
+ Attaching a certificate that includes the alternate domain name, like product-name.example.com.
+ Attaching a certificate that includes a \$1 wildcard at the beginning of a domain name, to cover multiple subdomains with one certificate. When you specify a wildcard, you can add multiple subdomains as alternate domain names in CloudFront.
The following examples illustrate how using wildcards in domain names in a certificate work to authorize you to add specific alternate domain names in CloudFront.
+ You want to add marketing.example.com as an alternate domain name. You list in your certificate the following domain name: \$1.example.com. When you attach this certificate to CloudFront, you can add any alternate domain name for your distribution that replaces the wildcard at that level, including marketing.example.com. You can also, for example, add the following alternate domain names:
+ product.example.com
+ api.example.com
However, you can’t add alternate domain names that are at levels higher or lower than the wildcard. For example, you can’t add the alternate domain names example.com or marketing.product.example.com.
+ You want to add example.com as an alternate domain name. To do this, you must list the domain name example.com itself on the certificate that you attach to your distribution.
+ You want to add marketing.product.example.com as an alternate domain name. To do this, you can list \$1.product.example.com on the certificate, or you can list marketing.product.example.com itself on the certificate.
**Permission to change DNS configuration**
When you add alternate domain names, you must create CNAME records to route DNS queries for the alternate domain names to your CloudFront distribution. To do this, you must have permission to create CNAME records with the DNS service provider for the alternate domain names that you’re using. Typically, this means that you own the domains, but you might be developing an application for the domain owner.
**Alternate domain names and HTTPS**
If you want viewers to use HTTPS with an alternate domain name, you must complete some additional configuration. For more information, see [Use alternate domain names and HTTPS](using-https-alternate-domain-names.md).
## Restrictions on using alternate domain names
Note the following restrictions on using alternate domain names:
**Maximum number of alternate domain names**
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).
**Duplicate and overlapping alternate domain names**
You cannot add an alternate domain name to a CloudFront distribution if the same alternate domain name already exists in another CloudFront distribution, even if your AWS account owns the other distribution.
However, you can add a wildcard alternate domain name, such as \$1.example.com, that includes (that overlaps with) a non-wildcard alternate domain name, such as www.example.com. If you have overlapping alternate domain names in two distributions, CloudFront sends the request to the distribution with the more specific name match, regardless of the distribution that the DNS record points to. For example, marketing.domain.com is more specific than \$1.domain.com.
If you have an existing wildcard DNS entry that points to a CloudFront distribution and you receive an incorrectly configured DNS error when trying to add a new CNAME with a more specific name, see [CloudFront returns an incorrectly configured DNS record error when I try to add a new CNAME](troubleshooting-distributions.md#troubleshoot-incorrectly-configured-DNS-record-error).
**Domain fronting**
CloudFront has protection against domain fronting occurring across different AWS account. This is a scenario when a non-standard client creates a TLS/SSL connection to a domain name in one AWS account, and then makes an HTTPS request for an unrelated domain name in another AWS account.
For example, the TLS connection might connect to www.example.com, and then issue a request for www.example.org.
To determine whether a request is being domain fronted, CloudFront performs the following checks:
+ The SNI extension is equal to the HTTP request `Host` header
+ The certificate belongs to the same AWS account as the distribution for the request
+ The HTTP request `Host` is covered by the certificate that is served during the TLS handshake
If none of these conditions are met, CloudFront determines the request is domain fronting. CloudFront will reject the request with a 421 HTTP error response.
If the client doesn't provide the SNI extension and gets a default \$1.cloudfront.net certificate instead, CloudFront will accept the incoming requests.
**How CloudFront identifies the distribution for a request**
CloudFront identifies a distribution for a HTTP request based on the `Host` header. CloudFront doesn't depend on the CloudFront IP address that you're connecting to or what SNI handshake was provided during TLS handshake.
When CloudFront receives a request, it will use the value of the `Host` header to match the request to the specific distribution.
For example, say that you have two distributions and you've updated your DNS configuration so that the alternate domain names route to the following endpoints:
+ primary.example.com points to d111111primary.cloudfront.net
+ secondary.example.com points to d222222secondary.cloudfront.net
If you make a request to https://primary.example.com but specify the `Host` header as secondary.example.com, such as `curl https://primary.example.com -H "Host: secondary.example.com"`, the request will route to the secondary distribution instead.
**Adding an alternate domain name at the top node (zone apex) for a domain**
When you add an alternate domain name to a distribution, you typically create a CNAME record in your DNS configuration to route DNS queries for the domain name to your CloudFront distribution. However, you can’t create a CNAME record for the top node of a DNS namespace, also known as the zone apex; the DNS protocol doesn’t allow it. For example, if you register the DNS name example.com, the zone apex is example.com. You can’t create a CNAME record for example.com, but you can create CNAME records for www.example.com, newproduct.example.com, and so on.
If you’re using Route 53 as your DNS service, you can create an alias resource record set, which has the following advantages over CNAME records:
+ You can create an alias resource record set for a domain name at the top node (example.com).
+ You can create an HTTPS record for an alternate domain name 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).
+ You don’t pay for Route 53 queries when you use an alias resource record set.
If you enable IPv6, you must create two alias resource record sets: one to route IPv4 traffic (an A record) and one to route IPv6 traffic (an AAAA record). For more information, see [Enable IPv6 (viewer requests)](DownloadDistValuesGeneral.md#DownloadDistValuesEnableIPv6) in the topic [All distribution settings reference](distribution-web-values-specify.md).
For more information, see [Routing traffic to an Amazon CloudFront web distribution by using your domain name](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-cloudfront-distribution.html) in the *Amazon Route 53 Developer Guide*.
If you're not using Route 53 for your DNS, you can request Anycast static IP addresses to route apex domains like example.com to CloudFront. For more information, see [Request Anycast static IPs to use for allowlisting](request-static-ips.md).
# Add an alternate domain name
The following task list describes how to use the CloudFront console to add an alternate domain name to your distribution so that you can use your own domain name in your links instead of the CloudFront domain name. For information about updating your distribution using the CloudFront API, see [Configure distributions](distribution-working-with.md).
**Note**
If you want viewers to use HTTPS with your alternate domain name, see [Use alternate domain names and HTTPS](using-https-alternate-domain-names.md).
**Before you begin:** Make sure that you do the following before you update your distribution to add an alternate domain name:
+ Register the domain name with Route 53 or another domain registrar.
+ Get a TLS certificate from an authorized certificate authority (CA) that covers the domain name. Add the certificate to your distribution to validate that you are authorized to use the domain. For more information, see [Requirements for using alternate domain names](CNAMEs.md#alternate-domain-names-requirements).
**Add an alternate domain name**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Choose the ID for the distribution that you want to update.
1. On the **General** tab, choose **Add a domain**.
1. Enter up to five domains to serve.
1. Choose **Next**.
1. For **TLS certificate**, if CloudFront can't find an existing AWS Certificate Manager (ACM) certificate for your domain in your AWS account in the `us-east-1` AWS Region, you can choose to automatically create a certificate or manually create it in ACM.
1. When your certificate is provisioned, you must update your DNS records with your DNS provider to prove domain ownership. The entries that you need to make to your DNS records are provided for you in the CloudFront console.
1. After you update your DNS records, choose **Validate certificate**.
1. When the certificate is validated, choose **Next**.
1. Review your changes and choose **Add domains**.
1. On the **General** tab for the distribution, confirm that **Distribution Status** has changed to **Deployed**. If you try to use an alternate domain name before the updates to your distribution have been deployed, the links that you create in the following steps might not work.
1. Configure the DNS service for the alternate domain name (such as www.example.com) to route traffic to the CloudFront domain name for your distribution (such as d111111abcdef8.cloudfront.net). The method that you use depends on whether you’re using Route 53 as the DNS service provider for the domain or another provider. For more information, see [Add a domain to your CloudFront standard distribution](add-domain-existing-distribution.md).
**Route 53**
Create an alias resource record set. With an alias resource record set, you don’t pay for Route 53 queries. You can also create an alias resource record set for the root domain name (example.com), which DNS doesn’t allow for CNAMEs. For instructions on creating an alias resource record set, see [Routing traffic to an Amazon CloudFront web distribution by using your domain name](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-cloudfront-distribution.html) in the *Amazon Route 53 Developer Guide*.
Optionally, you can create an HTTPS record for an alternate domain name to allow protocol negotiation as part of the DNS lookup if the client supports it.
**To create an alias resource record set with an HTTPS record (optional)**
1. Enable HTTP/2 or HTTP/3 in your CloudFront distribution settings. For more information, see [Supported HTTP versions](DownloadDistValuesGeneral.md#DownloadDistValuesSupportedHTTPVersions) and [Update a distribution](HowToUpdateDistribution.md).
1. In the Route 53 console, create an alias resource record set. Follow the [Routing traffic to an Amazon CloudFront web distribution by using your domain name](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-cloudfront-distribution.html) procedure.
1. While you are creating the alias resource record set, create an alias record with record type **HTTPS**.
**Another DNS service provider**
Use the method provided by your DNS service provider to add a CNAME record for your domain. This new CNAME record will redirect DNS queries from your alternate domain name (for example, www.example.com) to the CloudFront domain name for your distribution (for example, d111111abcdef8.cloudfront.net). For more information, see the documentation provided by your DNS service provider.
If you already have an existing CNAME record for your alternate domain name, update that record or replace it with a new one that points to the CloudFront domain name for your distribution.
1. Using `dig` or a similar DNS tool, confirm that the DNS configuration that you created in the previous step points to the domain name for your distribution.
The following example shows a `dig` request on the www.example.com domain, as well as the relevant part of the response.
```
PROMPT> dig www.example.com
; <<> DiG 9.3.3rc2 <<> www.example.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15917
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 10800 IN CNAME d111111abcdef8.cloudfront.net.
...
```
The answer section shows a CNAME record that routes queries for www.example.com to the CloudFront distribution domain name d111111abcdef8.cloudfront.net. If the name on the right side of `CNAME` is the domain name for your CloudFront distribution, the CNAME record is configured correctly. If it’s any other value, for example, the domain name for your Amazon S3 bucket, then the CNAME record is configured incorrectly. In that case, go back to step 7 and correct the CNAME record to point to the domain name for your distribution.
1. Test the alternate domain name by visiting URLs with your domain name instead of the CloudFront domain name for your distribution.
1. In your application, change the URLs for your objects to use your alternate domain name instead of the domain name of your CloudFront distribution.
# Move an alternate domain name
If you try to add an alternate domain name to a standard distribution or distribution tenant, and the alternate domain name is already associated with a different resource, you will get an error message.
For example, you will get the `CNAMEAlreadyExists` error message (One or more of the CNAMEs you provided are already associated with a different resource) when you try to add www.example.com to a standard distribution or distribution tenant, but that alternate domain name is already associated with a different resource.
In that case, you might want to move the existing alternate domain name from one resource to another. This is the *source distribution* and the *target distribution*. You can move alternate domain names between either standard distributions and/or distribution tenants.
To move the alternate domain name, see the following topics:
**Topics**
+ [
# Set up the target standard distribution or distribution tenant
](alternate-domain-names-move-create-target.md)
+ [
# Find the source standard distribution or distribution tenant
](alternate-domain-names-move-find-source.md)
+ [
# Move the alternate domain name
](alternate-domain-names-move-options.md)
# Set up the target standard distribution or distribution tenant
Before you can move an alternate domain name, you must set up the target resource. This is the target standard distribution or distribution tenant that you're moving the alternate domain name to.
------
#### [ Standard distribution ]
**To set up a target standard distribution**
1. Request a TLS certificate. This certificate includes the alternate domain name as the Subject or Subject Alternative Domain (SAN), or a wildcard (\$1) that covers the alternate domain name that you’re moving. If you don’t have one, you can request one from AWS Certificate Manager (ACM) or from another certificate authority (CA) and import it into ACM.
**Note**
You must request or import the certificate in the US East (N. Virginia) (`us-east-1`) Region.
For more information, see [Request a public certificate using the console](https://docs.aws.amazon.com/acm/latest/userguide/acm-public-certificates.html#request-public-console) and [Import a certificate](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-api-cli.html) in the AWS Certificate Manager in the *AWS Certificate Manager User Guide*.
1. If you haven’t created the target standard distribution, create one now. As part of creating the standard distribution, associate the certificate with this standard distribution. For more information, see [Create a distribution](distribution-web-creating-console.md).
If you already have a target standard distribution, associate the certificate with the standard distribution. For more information, see [Update a distribution](HowToUpdateDistribution.md).
1. **If you’re moving alternate domain names within the same AWS account, skip this step.**
To move an alternate domain name from one AWS account to another, you must create a TXT record in your DNS configuration. This verification step helps prevent unauthorized domain transfers. CloudFront uses this TXT record to validate your ownership of the alternate domain name.
In your DNS configuration, create a DNS TXT record that associates the alternate domain name with the target standard distribution. The TXT record format can vary, depending on the domain type.
+ For subdomains, specify an underscore (`_`) in front of the alternate domain name. The following shows an example TXT record.
`_www.example.com TXT d111111abcdef8.cloudfront.net`
+ For an apex (or root domain), specify an underscore and period ( `_.`) in front of the domain name. The following shows an example TXT record.
`_.example.com TXT d111111abcdef8.cloudfront.net`
------
#### [ Distribution tenant ]
**To set up the target distribution tenant**
1. Request a TLS certificate. This certificate includes the alternate domain name as the Subject or Subject Alternative Domain (SAN), or a wildcard (\$1) that covers the alternate domain name that you’re moving. If you don’t have one, you can request one from AWS Certificate Manager (ACM) or from another certificate authority (CA) and import it into ACM.
**Note**
You must request or import the certificate in the US East (N. Virginia) (`us-east-1`) Region.
For more information, see [Request a public certificate using the console](https://docs.aws.amazon.com/acm/latest/userguide/acm-public-certificates.html#request-public-console) and [Import a certificate](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-api-cli.html) in the AWS Certificate Manager in the *AWS Certificate Manager User Guide*.
1. If you haven’t created the target distribution tenant, create one now. As part of creating the distribution tenant, associate the certificate with the distribution tenant. For more information, see [Create a distribution](distribution-web-creating-console.md).
If you already have a target distribution tenant, associate the certificate with the distribution tenant. For more information, see [Add a domain and certificate (distribution tenant)](managed-cloudfront-certificates.md#vanity-domain-tls-tenant).
1. **If you’re moving alternate domain names within the same AWS account, skip this step.**
To move an alternate domain name from one AWS account to another, you must create a TXT record in your DNS configuration. This verification step helps prevent unauthorized domain transfers, and CloudFront uses this TXT record to validate your ownership of the alternate domain name.
In your DNS configuration, create a DNS TXT record that associates the alternate domain name with the target distribution tenant. The TXT record format can vary, depending on the domain type.
+ For subdomains, specify an underscore (`_`) in front of the alternate domain name. The following shows an example TXT record.
`_www.example.com TXT d111111abcdef8.cloudfront.net`
+ For an apex (or root domain), specify an underscore and period ( `_.`) in front of the domain name. The following shows an example TXT record.
`_.example.com TXT d111111abcdef8.cloudfront.net`
------
Next, see the following topic to find the source standard distribution or distribution tenant that is already associated with the alternate domain name.
# Find the source standard distribution or distribution tenant
Before you can move an alternate domain name from one distribution (standard or tenant) to another, find the *source distribution*. This is the resource that the alternate domain name is already associated with. When you know the AWS account ID of both the source and target distribution resources, you can determine how to move the alternate domain name.
**Notes**
We recommend that you use the [ListDomainConflicts](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListDomainConflicts.html) API operation, because it supports both standard distributions and distribution tenants.
The [ListConflictingAliases](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListConflictingAliases.html) API operation only supports standard distributions.
Follow these examples to find the source distribution (standard or tenant).
------
#### [ list-domain-conflicts ]
**Tip**
For a standard distribution, you must have the `cloudfront:GetDistribution` and `cloudfront:ListDomainConflicts` permissions.
For a distribution tenant, you must have the `cloudfront:GetDistributionTenant` and `cloudfront:ListDomainConflicts` permissions.
**To use `list-domain-conflicts` to find the source standard distribution or distribution tenant**
1. Use the `list-domain-conflicts` command as shown in the following example.
1. Replace *www.example.com* with the domain name.
1. For the `domain-control-validation-resource`, specify the ID of the target standard distribution or distribution tenant [that you set up previously](alternate-domain-names-move-create-target.md). You must have a standard distribution or distribution tenant that is associated with a certificate that covers the specified domain.
1. Run this command using the credentials that are in the same AWS account as the target standard distribution or distribution tenant.
**Request**
This example specifies a distribution tenant.
```
aws cloudfront list-domain-conflicts \
--domain www.example.com \
--domain-control-validation-resource "DistributionTenantId=dt_2x9GhoK0TZRsohWzv1b9It8JABC"
```
**Response**
For each domain name in the command’s output, you can see the following:
+ The resource type that the domain is associated with
+ The resource ID
+ The AWS account ID that owns the resource
The resource ID and the account ID are partially hidden. This allows you to identify the standard distribution or distribution tenant that belongs to your account, and helps to protect the information of ones that you don’t own.
```
{
"DomainConflicts": [
{
"Domain": "www.example.com",
"ResourceType": "distribution-tenant",
"ResourceId": "***************ohWzv1b9It8JABC",
"AccountId": "******112233"
}
]
}
```
The response lists all the domain names that conflict or overlap with the one that you specified.
**Example**
+ If you specify *tenant1.example.com*, the response includes tenant1.example.com and the overlapping wildcard alternate domain name (\$1.example.com if it exists).
+ If you specify *\$1.tenant1.example.com*, the response includes \$1.tenant1.example.com and any alternate domain names covered by that wildcard (for example, test.tenant1.example.com, dev.tenant1.example.com, and so on).
1. In the response, find the source standard distribution or distribution tenant for the alternate domain name that you're moving, and note the AWS account ID.
1. Compare the account ID of the *source* standard distribution or distribution tenant with the account ID where you created the *target* standard distribution or distribution tenant in the [previous step](alternate-domain-names-move-create-target.md). You can then determine whether the source and target are in the same AWS account. This helps you determine how to move the alternate domain name.
For more information, see the [https://docs.aws.amazon.com/cli/latest/reference/cloudfront/list-domain-conflicts.html](https://docs.aws.amazon.com/cli/latest/reference/cloudfront/list-domain-conflicts.html) command in the *AWS Command Line Interface Reference*.
------
#### [ list-conflicting-aliases (standard distributions only) ]
**Tip**
You must have the `cloudfront:GetDistribution` and `cloudfront:ListConflictingAliases` permissions on the target standard distribution.
**To use `list-conflicting-aliases` to find the source standard distribution**
1. Use the `list-conflicting-aliases` command as shown in the following example.
1. Replace *www.example.com* with the alternate domain name, and *EDFDVBD6EXAMPLE* with the ID of the target standard distribution [that you set up previously](alternate-domain-names-move-create-target.md).
1. Run this command using credentials that are in the same AWS account as the target standard distribution.
**Request**
This example specifies a standard distribution.
```
aws cloudfront list-conflicting-aliases \
--alias www.example.com \
--distribution-id EDFDVBD6EXAMPLE
```
**Response**
For each alternate domain name in the command’s output, you can see the ID of the standard distribution that it’s associated with, and the AWS account ID that owns the standard distribution. The standard distribution and account IDs are partially hidden, which allows you to identify the standard distributions and accounts that you own, and helps to protect the information of ones that you don’t own.
```
{
"ConflictingAliasesList": {
"MaxItems": 100,
"Quantity": 1,
"Items": [
{
"Alias": "www.example.com",
"DistributionId": "*******EXAMPLE",
"AccountId": "******112233"
}
]
}
}
```
The response lists the alternate domain names that conflict or overlap with the one that you specified.
**Example**
+ If you specify *www.example.com*, the response includes www.example.com and the overlapping wildcard alternate domain name (\$1.example.com) if it exists.
+ If you specify *\$1.example.com*, the response includes \$1.example.com and any alternate domain names covered by that wildcard (for example, www.example.com, test.example.com, dev.example.com, and so on).
1. Find the standard distribution for the alternate domain name that you're moving, and note the AWS account ID. Compare this account ID with the account ID where you created the target standard distribution in the [previous step](alternate-domain-names-move-create-target.md). You can then determine whether these two standard distributions are in the same AWS account and how to move the alternate domain name.
For more information, see the [https://docs.aws.amazon.com//cli/latest/reference/cloudfront/list-conflicting-aliases.html](https://docs.aws.amazon.com//cli/latest/reference/cloudfront/list-conflicting-aliases.html) command in the *AWS Command Line Interface Reference*.
------
Next, see the following topic to move the alternate domain name.
# Move the alternate domain name
Depending on your situation, choose from the following ways to move the alternate domain name:
**The source and target distributions (standard or tenant) are in the same AWS account**
Use the **update-domain-association** command in the AWS Command Line Interface (AWS CLI) to move the alternate domain name.
This command works for all same-account moves, including when the alternate domain name is an apex domain (also called a *root domain*, like example.com).
**The source and target distributions (standard or tenant) are in different AWS accounts**
If you have access to the source standard distribution or distribution tenant, the alternate domain name is *not* an apex domain, and you are not already using a wildcard that overlaps with that alternate domain name, use a wildcard to move the alternate domain name. For more information, see [Use a wildcard to move an alternate domain name](#alternate-domain-names-move-use-wildcard).
If you don’t have access to the AWS account that has the source standard distribution or distribution tenant, you can try using the **update-domain-association** command to move the alternate domain name. The source standard distribution or distribution tenant must be disabled before you can move the alternate domain name. For additional help, see [Contact AWS Support to move an alternate domain name](#alternate-domain-names-move-contact-support).
**Note**
You can use the **associate-alias** command, but this command only supports standard distributions. See [AssociateAlias](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_AssociateAlias.html) in the *Amazon CloudFront API Reference*.
------
#### [ update-domain-association (standard distributions and distribution tenants) ]
**To use `update-domain-association` to move an alternate domain name**
1. Use the `update-domain-association` command, as shown in the following example.
1. Replace *example.com* with the alternate domain name, and specify the ID of the target standard distribution or distribution tenant.
1. Run this command using credentials that are in the same AWS account as the target standard distribution or distribution tenant.
**Note the following restrictions**
In addition to the `cloudfront:UpdateDomainAssociation` permission, you must have the `cloudfront:UpdateDistribution` permission to update a standard distribution. To update a distribution tenant, you must have the `cloudfront:UpdateDistributionTenant` permission.
If the source and target distributions (standard or tenant) are in different AWS accounts, the source must be disabled before you can move the domain.
The target distribution must be set up as described in [Set up the target standard distribution or distribution tenant](alternate-domain-names-move-create-target.md).
**Request**
```
aws cloudfront update-domain-association \
--domain "www.example.com" \
--target-resource DistributionTenantId=dt_9Fd3xTZq7Hl2KABC \
--if-match E3UN6WX5ABC123
```
**Response**
```
{
"ETag": "E7Xp1Y3N9DABC",
"Domain": "www.example.com",
"ResourceId": "dt_9Fd3xTZq7Hl2KABC"
}
```
This command removes the alternate domain name from the source standard distribution or distribution tenant and adds it to the target standard distribution or distribution tenant.
1. After the target distribution is fully deployed, update your DNS configuration to point your domain name to the CloudFront routing endpoint. For example, your DNS record would point your alternate domain name (`www.example.com`) to the CloudFront provided domain name d111111abcdef8.cloudfront.net. If the target is a distribution tenant, specify the connection group endpoint. For more information, see [Point domains to CloudFront](managed-cloudfront-certificates.md#point-domains-to-cloudfront).
------
#### [ associate-alias (standard distributions only) ]
**To use `associate-alias` to move an alternate domain name**
1. Use the `associate-alias` command, as shown in the following example.
1. Replace *www.example.com* with the alternate domain name, and *EDFDVBD6EXAMPLE* with the target standard distribution ID.
1. Run this command using credentials that are in the same AWS account as the target standard distribution.
**Note the following restrictions**
You must have `cloudfront:AssociateAlias` and `cloudfront:UpdateDistribution` permissions on the target standard distribution.
If the source and target standard distribution are in the same AWS account, you must have `cloudfront:UpdateDistribution` permission on the source standard distribution.
If the source standard distribution and target standard distribution are in different AWS accounts, you must disable the source standard distribution first.
The target standard distribution must be set up as described in [Set up the target standard distribution or distribution tenant](alternate-domain-names-move-create-target.md).
**Request**
```
aws cloudfront associate-alias \
--alias www.example.com \
--target-distribution-id EDFDVBD6EXAMPLE
```
This command removes the alternate domain name from the source standard distribution and moves it to the target standard distribution.
1. After the target standard distribution is fully deployed, update your DNS configuration to point the alternate domain name’s DNS record to the distribution domain name of the target standard distribution. For example, your DNS record would point your alternate domain name (`www.example.com`) to the CloudFront provided domain name d111111abcdef8.cloudfront.net.
For more information, see the [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudfront/associate-alias.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudfront/associate-alias.html) command in the *AWS CLI Command Reference*.
------
## Use a wildcard to move an alternate domain name
If the source distribution is in a different AWS account than the target distribution, and the source distribution is enabled, you can use a wildcard to move the alternate domain name.
**Note**
You can’t use a wildcard to move an apex domain (like example.com). To move an apex domain when the source and target distributions are in different AWS accounts, contact Support. For more information, see [Contact AWS Support to move an alternate domain name](#alternate-domain-names-move-contact-support).
**To use a wildcard to move an alternate domain name**
**Note**
This process involves multiple updates to your distributions. Wait for each distribution to fully deploy the latest change before proceeding to the next step.
1. Update the target distribution to add a wildcard alternate domain name that covers the alternate domain name that you are moving. For example, if the alternate domain name that you’re moving is www.example.com, add the alternate domain name \$1.example.com to the target distribution. To do this, the SSL/TLS certificate on the target distribution must include the wildcard domain name. For more information, see [Update a distribution](HowToUpdateDistribution.md).
1. Update the DNS settings for the alternate domain name to point to the domain name of the target distribution. For example, if the alternate domain name that you’re moving is www.example.com, update the DNS record for www.example.com to route traffic to the domain name of the target distribution (for example d111111abcdef8.cloudfront.net).
**Note**
Even after you update the DNS settings, the alternate domain name is still served by the source distribution because that’s where the alternate domain name is currently configured.
1. Update the source distribution to remove the alternate domain name. For more information, see [Update a distribution](HowToUpdateDistribution.md).
1. Update the target distribution to add the alternate domain name. For more information, see [Update a distribution](HowToUpdateDistribution.md).
1. Use **dig** (or a similar DNS query tool) to validate that the DNS record for the alternate domain name resolves to the domain name of the target distribution.
1. (Optional) Update the target distribution to remove the wildcard alternate domain name.
## Contact AWS Support to move an alternate domain name
If the source and target distributions are in different AWS accounts, and you don’t have access to the source distribution’s AWS account or can’t disable the source distribution, you can contact Support to move the alternate domain name.
**To contact Support to move an alternate domain name**
1. Set up a target distribution, including the DNS TXT record that points to the target distribution. For more information, see [Set up the target standard distribution or distribution tenant](alternate-domain-names-move-create-target.md).
1. [Contact Support](https://console.aws.amazon.com/support/home) to request that they verify that you own the domain, and move the domain to the new CloudFront distribution for you.
1. After the target distribution is fully deployed, update your DNS configuration to point the alternate domain name’s DNS record to the distribution domain name of the target distribution.
# Remove an alternate domain name
If you want to stop routing traffic for a domain or subdomain to a CloudFront distribution, follow the steps in this section to update both the DNS configuration and the CloudFront distribution.
It’s important that you remove the alternate domain names from the distribution as well as update your DNS configuration. This helps prevent issues later if you want to associate the domain name with another CloudFront distribution. If an alternate domain name is already associated with one distribution, it can’t be set up with another.
**Note**
If you want to remove the alternate domain name from this distribution so you can add it to another one, follow the steps in [Move an alternate domain name](alternate-domain-names-move.md). If you follow the steps here instead (to remove a domain) and then add the domain to another distribution, there will be a period of time during which the domain won’t link to the new distribution because CloudFront is propagating to the updates to edge locations.
**To remove an alternate domain name from a distribution**
1. To start, route internet traffic for your domain to another resource that isn’t your CloudFront distribution, such as an Elastic Load Balancing load balancer. Or you can delete the DNS record that’s routing traffic to CloudFront.
Do one of the following, depending on the DNS service for your domain:
+ **If you’re using Route 53**, update or delete alias records or CNAME records. For more information, see [Editing records](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-editing.html) or [Deleting records](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-deleting.html).
+ **If you’re using another DNS service provider**, use the method provided by the DNS service provider to update or delete the CNAME record that directs traffic to CloudFront. For more information, see the documentation provided by your DNS service provider.
1. After you update your domain’s DNS records, wait until the changes have propagated and DNS resolvers are routing traffic to the new resource. You can check to see when this is complete by creating some test links that use your domain in the URL.
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home), and update your CloudFront distribution to remove the domain name by doing the following:
1. Choose the ID for the distribution that you want to update.
1. On the **General** tab, choose **Edit**.
1. In **Alternate Domain Names (CNAMEs)**, remove the alternate domain name (or domain names) that you no longer want to use for your distribution.
1. Choose **Yes, Edit**.
# Use wildcards in alternate domain names
When you add alternate domain names, you can use the \$1 wildcard at the beginning of a domain name instead of adding subdomains individually. For example, with an alternate domain name of \$1.example.com, you can use any domain name that ends with example.com in your URLs, such as www.example.com, product-name.example.com, marketing.product-name.example.com, and so on. The path to the object is the same regardless of the domain name, for example:
+ www.example.com/images/image.jpg
+ product-name.example.com/images/image.jpg
+ marketing.product-name.example.com/images/image.jpg
Follow these requirements for alternate domain names that include wildcards:
+ The alternate domain name must begin with an asterisk and a dot (\$1.).
+ You *cannot* use a wildcard to replace part of a subdomain name, like this: \$1domain.example.com.
+ You cannot replace a subdomain in the middle of a domain name, like this: subdomain.\$1.example.com.
+ All alternate domain names, including alternate domain names that use wildcards, must be covered by the subject alternative name (SAN) on the certificate.
A wildcard alternate domain name, such as \$1.example.com, can include another alternate domain name that’s in use, such as example.com.
# Use WebSockets with CloudFront distributions
Use WebSockets
Amazon CloudFront supports using WebSocket, a TCP-based protocol that is useful when you need long-lived bidirectional connections between clients and servers. A persistent connection is often a requirement with real-time applications. The scenarios in which you might use WebSockets include social chat platforms, online collaboration workspaces, multi-player gaming, and services that provide real-time data feeds like financial trading platforms. Data over a WebSocket connection can flow in both directions for full-duplex communication.
WebSocket functionality is automatically enabled to work with any distribution. To use WebSockets, configure one of the following in the cache behavior that's attached to your distribution:
+ Forward all viewer request headers to your origin. You can use the [AllViewer managed origin request policy](using-managed-origin-request-policies.md#managed-origin-request-policy-all-viewer).
+ Specifically forward the `Sec-WebSocket-Key` and `Sec-WebSocket-Version` request headers in your origin request policy.
## How the WebSocket protocol works
The WebSocket protocol is an independent, TCP-based protocol that allows you to avoid some of the overhead—and potentially increased latency—of HTTP.
To establish a WebSocket connection, the client sends a regular HTTP request that uses HTTP's upgrade semantics to change the protocol. The server can then complete the handshake. The WebSocket connection remains open and either the client or server can send data frames to each other without having to establish new connections each time.
By default, the WebSocket protocol uses port 80 for regular WebSocket connections and port 443 for WebSocket connections over TLS. The options that you choose for your CloudFront [Viewer protocol policy](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy) and [Protocol (custom origins only)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy) apply to WebSocket connections and also HTTP traffic.
## WebSocket requirements
WebSocket requests must comply with [RFC 6455](https://datatracker.ietf.org/doc/html/rfc6455) in the following standard formats.
**Example Sample client request**
```
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: https://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
```
**Example Sample server response**
```
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat
```
If the WebSocket connection is disconnected by the client or server, or by a network disruption, client applications are expected to re-initiate the connection with the server.
## Recommended WebSocket headers
To avoid unexpected compression-related issues when using WebSockets, we recommend that you include the following headers in an [origin request policy](origin-request-create-origin-request-policy.md):
+ `Sec-WebSocket-Key`
+ `Sec-WebSocket-Version`
+ `Sec-WebSocket-Protocol`
+ `Sec-WebSocket-Accept`
+ `Sec-WebSocket-Extensions`
**Note**
Currently, CloudFront only supports WebSocket connections over the HTTP/1.1 protocol.
# Request Anycast static IPs to use for allowlisting
Anycast static IPs
You can request Anycast static IPs from CloudFront to use with your distributions.Anycast static IPs
You can use Anycast static IPs to enable routing of apex domains directly to your CloudFront distributions.Anycast static IPs
You can now choose between only IPv4 addresses or both IPv4 and IPv6 addresses (dualstack).
You can request Anycast static IPs from CloudFront to use with your distributions. Anycast static IP lists can contain only IPv4 IP addresses or both IPv4 and IPv6 IP addresses. These IP addresses are dedicated to your AWS account and spread across geographic regions.
You can request 21 Anycast static IP addresses to allowlist with network providers so that you can waive data charges for viewers who access your application. Alternatively, you can use these static IPs within outbound security firewalls to control traffic exchange with approved applications. Anycast static IP lists can be used with one or more distributions.
If you want to enable routing of apex domains (such as example.com) directly to your CloudFront distributions, you can request 3 Anycast static IP addresses for this use case. Then, add A records in your DNS to point the apex domain to CloudFront.
Anycast static IPs work with [Server Name Indication (SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication). For more information, see [Use SNI to serve HTTPS requests (works for most clients)](cnames-https-dedicated-ip-or-sni.md#cnames-https-sni).
## Prerequisites
To use Anycast static IP lists with your CloudFront distribution, you must select **Use all edge locations** for the price class for the distribution. For more information about pricing, see [CloudFront pricing](https://aws.amazon.com/cloudfront/pricing/).
## Request an Anycast static IP list
Request an Anycast static IP list to use with your CloudFront distribution.
**To request an Anycast static IP list**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. In the left navigation pane, choose **Static IPs**.
1. For **Request**, choose the link to contact CloudFront support engineering.
1. Provide your workload information (request bytes per second and requests per second).
1. CloudFront support engineering reviews your request. The review process might take up to two days.
After your request is approved, you can create an Anycast static IP list and associate it with one or more distributions.
## Create an Anycast static IP list
Before you begin, request an Anycast static IP list as explained in the preceding section.
**To create an Anycast static IP list**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. In the left navigation pane, choose **Static IPs**.
1. Choose **Create Anycast IP list**.
1. For **Name**, enter a name.
1. For **Static IP use cases**, select the appropriate use case.
1. For **IP address type**, specify one of the following options:
+ **IPv4** – Allocate a list of only IPv4 addresses
+ **Dualstack** – Allocate a list of both IPv4 and IPv6 addresses
1. Review the service terms and pricing, and choose **Submit**.
After your static IP list is created, you can view the allocated IP addresses on your static IP list detail page. You can also associate distributions with the static IP list.
## Associate an Anycast static IP list with an existing distribution
Before you begin, request and create an Anycast static IP list as explained in the preceding sections.
Verify that the following distribution settings are compatible with your Anycast static IP list:
+ [Price class](DownloadDistValuesGeneral.md#DownloadDistValuesPriceClass) has the **Use all edge locations (best performance)** setting.
+ If [IPv6](cloudfront-enable-ipv6.md) is enabled, you can associate a dualstack Anycast static IP list. An Anycast static IP list that only has IPv4 addresses can't be associated to distributions with IPv6 enabled.
**To associate an Anycast static IP list with an existing distribution**
+ Do one of the following:
+ Associate the static IP list from the static IP list detail page:
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Choose **Static IPs** in the left navigation pane.
1. Choose the name of your static IP list.
1. Choose **Associate distributions**.
1. Select one or more distributions and choose **Associate distributions**.
+ Associate the static IP list from the distribution detail page:
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Choose **Distributions** in the left navigation pane.
1. Choose the name of your distribution.
1. On the **General** tab, under **Settings**, choose **Edit**.
1. For **Anycast IP list**, select the Anycast static IP list to use with this distribution.
1. Choose **Save changes**.
## Associate an Anycast static IP list with a new distribution
Before you begin, request and create an Anycast static IP list as explained in the preceding sections.
**To associate an Anycast static IP list with a new distribution**
+ Create a new distribution. For more information, see [Create a CloudFront distribution in the console](distribution-web-creating-console.md#create-console-distribution). For **Settings**, you must make the following selections to use your Anycast static IP list:
+ For **Anycast IP list**, select your Anycast static IP list from the dropdown list.
+ For **Price class**, select **Use all edge locations (best performance)**.
+ **Note:** If your Anycast static IP is only using IPv4 and not dualstack, for **IPv6**, select **Off**.
Finish creating your distribution. You can choose any other settings and configurations that are not required for Anycast static IP lists based on your needs.
For more information about quotas related to Anycast static IP lists, see [Amazon CloudFront endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/cf_region.html#limits_cloudfront) in the *AWS General Reference*.
## Associate an Anycast static IP list with a connection group
Before you begin, request and create an Anycast static IP list as explained in the previous sections.
**To associate an Anycast static IP list with a new connection group**
1. Ensure you have enabled connection groups under **Settings**.
1. Create a connection group. For more information, see [Create custom connection group](custom-connection-group.md).
1. For **Settings**, you must make the following selections to use your Anycast static IP list.
1. For **Anycast IP list**, select your Anycast static IP list from the dropdown list.
1. Finish creating your connection group.
**Note**
If your Anycast static IP is only using IPv4 and not dualstack, for **IPv6**, select **Off**.
For more information about quotas related to Anycast static IP lists, see [Amazon CloudFront endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/cf_region.html#limits_cloudfront) in the *Amazon Web Services General Reference*.
## Update an Anycast static IP list
After you have created your Anycast static IP address and associated it to a distribution, you can change the IP address type of your Anycast static IP list..
**To update an Anycast static IP list**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. In the left navigation pane, choose **Static IPs**.
1. Choose the name of your static IP list.
1. Choose **Edit**.
1. For **IP address type**, specify one of the following options:
+ **IPv4** – Allocate a list of only IPv4 addresses
+ **Dualstack** – Allocate a list of both IPv4 and IPv6 addresses
**Note**
You can't choose **IPv4** if your associated distribution has already enabled IPv6. To do so, disable IPv6 before you can update the IP address type for your Anycast static IP. For more information, see [Enable IPv6 for CloudFront distributions](cloudfront-enable-ipv6.md).
1. Choose **Submit** to save your changes and update the Anycast static IP list.
# Bring your own IP to CloudFront using IPAM
Add support for bringing your own IP to CloudFront using IPAM
CloudFront supports bringing your own IPv4 addresses through IPAM's BYOIP for global services.
This tutorial shows how to use IPAM to manage your BYOIP CIDRs for CloudFront Anycast Static IP lists.
**Topics**
+ [
## What is BYOIP for Anycast Static IPs?
](#what-is-byoip-anycast)
+ [
## Why use this feature?
](#why-use-byoip)
+ [
## Prerequisites
](#byoip-prerequisites)
+ [
## Step 1: Request an Anycast static IP list
](#request-anycast-static-ip-list)
+ [
## Step 2: Create an Anycast static IP list
](#create-anycast-static-ip-list)
+ [
## Step 3: Create a CloudFront distribution
](#create-cloudfront-distribution)
+ [
## Step 4: Associate with CloudFront resources
](#associate-with-cloudfront-resources)
+ [
## Step 5: Prepare for migration
](#prepare-for-migration)
+ [
## Step 6: Advertise CIDR globally
](#advertise-cidr-globally)
## What is BYOIP for Anycast Static IPs?
CloudFront supports bringing your own IPv4 and IPv6 addresses through IPAM's BYOIP for global services. Through IPAM's unified interface, customers can create dedicated IP address pools using their own IP addresses (BYOIP) and assign them to CloudFront distributions while leveraging the AWS worldwide content delivery network to deliver their applications and content. Your IP addresses are advertised from multiple CloudFront edge locations simultaneously using anycast routing.
## Why use this feature?
**Control network access in allow lists to:**
+ Allow-list IP addresses with network providers to waive data charges for approved viewers
+ Configure outbound security firewalls to restrict traffic to approved applications only
**Simplify operations and migrations**
+ Route apex domains (example.com) directly to CloudFront by adding A records that point to your static IPs
+ Migrate from other CDNs without updating IP infrastructure or firewall configurations
+ Maintain existing IP allowlists with partners and clients
+ Share a single Anycast static IP list across multiple CloudFront distributions
**Consistent branding**
+ Keep your existing IP address space for consistent branding when moving to AWS
## Prerequisites
To use Anycast static IP lists with your CloudFront distribution, you must select **Use all edge locations** for the price class for the distribution. For more information about pricing, see [CloudFront pricing](https://aws.amazon.com/cloudfront/pricing/). For Bring Your Own IP (BYOIP), you also need to disable IPv6 for the distribution or connection group when using IPv4-only BYOIP. For dual-stack BYOIP, associate a dual-stack Anycast static IP List and enable IPv6 for the distribution or connection group.
Complete these steps before starting:
+ IPAM setup: See [Integrate IPAM with accounts](https://docs.aws.amazon.com/vpc/latest/ipam/enable-integ-ipam.html) and [Create an IPAM](https://docs.aws.amazon.com/vpc/latest/ipam/create-ipam.html).
+ Domain verification: [Verify domain control](https://docs.aws.amazon.com/vpc/latest/ipam/tutorials-byoip-ipam-domain-verification-methods.html).
+ Create a top-level pool: Follow steps 1 to 2 in [Bring your own IPv4 CIDR to IPAM](https://docs.aws.amazon.com/vpc/latest/ipam/tutorials-byoip-ipam-console-ipv4.html) and/or [Bring your own IPv6 CIDR to IPAM](https://docs.aws.amazon.com/vpc/latest/ipam/tutorials-byoip-ipam-console-ipv6.html).
+ Create an IPAM pool with locale as global to use with CloudFront. For more information, see [Bring your own IP to CloudFront using IPAM](https://docs.aws.amazon.com/vpc/latest/ipam/tutorials-byoip-cloudfront.html).
**Note**
Requires **three /24 and/or /48** IPv4 CIDR blocks.
## Step 1: Request an Anycast static IP list
Request an Anycast static IP list to use with your CloudFront distribution.
**To request an Anycast static IP list**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. In the left navigation pane, choose **Static IPs**.
1. For **Request**, choose the link to contact CloudFront support engineering.
1. Provide your workload information (request bytes per second and requests per second).
1. CloudFront support engineering reviews your request. The review process might take up to two days.
1. After your request is approved, you can create an Anycast static IP list and associate it with one or more distributions.
## Step 2: Create an Anycast static IP list
Before you begin, request an Anycast static IP list as explained in the preceding section.
**To create an Anycast static IP list**
1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. In the left navigation pane, choose **Static IPs**.
1. Choose **Create Anycast IP list**.
1. For **Name**, enter a name.
1. For **Static IP use cases**, select **BYOIP** as your use case.
1. For **IP address type**, pick **IPv4** or **Dualstack**.
1. For **IPAM pool**, pick the IPAM pool(s) you provisioned through IPAM and CIDR group(s) from them.
The following steps differ from the standard regional BYOIP process and establish the pattern for global services:
### AWS CLI
Installing or updating to the latest version of the AWS CLI. For more information, see the [AWS Command Line Interface User Guide](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Retrieve the IpamPoolArn of the IPAM pool where your CIDR blocks were provisioned. For more information, see [Bring your own public IPv4 CIDR to IPAM using only the AWS CLI](https://docs.aws.amazon.com/vpc/latest/ipam/tutorials-byoip-ipam-ipv4.html) or [Bring your own public IPv6 CIDR to IPAM using only the AWS CLI](https://docs.aws.amazon.com/vpc/latest/ipam/tutorials-byoip-ipam-ipv6.html).
1. Create an Anycast IP list with your CIDR blocks and IPAM configuration:
For IPv4:
```
aws cloudfront create-anycast-ip-list \
--name byoip-aip-1 \
--ip-count 3 \
--region us-east-1 \
--ip-address-type ipv4 \
--ipam-cidr-configs '[{"Cidr":"1.1.1.0/24","IpamPoolArn":"arn:aws:ec2::123456789012:ipam-pool/ipam-pool-005d58a8aa8147abc"},{"Cidr":"2.2.2.0/24","IpamPoolArn":"arn:aws:ec2::123456789012:ipam-pool/ipam-pool-005d58a8aa8147abc"},{"Cidr":"3.3.3.0/24","IpamPoolArn":"arn:aws:ec2::123456789012:ipam-pool/ipam-pool-005d58a8aa8147abc"}]'
```
For IPv6:
```
aws cloudfront create-anycast-ip-list \
--name byoip-aip-dualstack \
--ip-count 3 \
--region us-east-1 \
--ip-address-type dualstack \
--ipam-cidr-configs '[{"Cidr":"1.1.1.0/24","IpamPoolArn":"arn:aws:ec2::123456789012:ipam-pool/ipam-pool-005d58a8aa8147abc"},{"Cidr":"2.2.2.0/24","IpamPoolArn":"arn:aws:ec2::123456789012:ipam-pool/ipam-pool-005d58a8aa8147abc"},{"Cidr":"3.3.3.0/24","IpamPoolArn":"arn:aws:ec2::123456789012:ipam-pool/ipam-pool-005d58a8aa8147abc"},{"Cidr":"2600:9000:a100::/48","IpamPoolArn":"arn:aws:ec2::123456789012:ipam-pool/ipam-pool-0a3b7c9e2f41d6789"},{"Cidr":"2600:9000:a200::/48","IpamPoolArn":"arn:aws:ec2::123456789012:ipam-pool/ipam-pool-0a3b7c9e2f41d6789"},{"Cidr":"2600:9000:a300::/48","IpamPoolArn":"arn:aws:ec2::123456789012:ipam-pool/ipam-pool-0a3b7c9e2f41d6789"}]'
```
**Note**
You can't select the specific IP address from the pool. CloudFront will do this automatically.
## Step 3: Create a CloudFront distribution
For CloudFront, you can follow instructions to [create a standard distribution ](distribution-web-creating-console.md) or use [multi-tenant distributions](distribution-config-options.md).
## Step 4: Associate with CloudFront resources
+ [Associate an Anycast static IP list with an existing distribution](request-static-ips.md#associate-static-ip-list-existing)
+ [Associate an Anycast static IP list with a new distribution](request-static-ips.md#associate-static-ip-list-new)
+ [Associate an Anycast static IP list with a connection group](request-static-ips.md#associate-anycast-ip-connection-group)
## Step 5: Prepare for migration
For more information, see [Step 4: Prepare for migration](https://docs.aws.amazon.com/vpc/latest/ipam/tutorials-byoip-cloudfront.html#step-4-prepare-for-migration) in the *Amazon VPC User Guide*.
## Step 6: Advertise CIDR globally
For more information, see [Step 5: Advertise CIDR globally](https://docs.aws.amazon.com/vpc/latest/ipam/tutorials-byoip-cloudfront.html#step-5-advertise-cidr-globally) in the *Amazon VPC User Guide*.
# Using gRPC with CloudFront distributions
Using gRPCAdded support for gRPC
CloudFront now supports gRPC requests for your distribution.
Amazon CloudFront supports gRPC, an open-source remote procedure call (RPC) framework built on HTTP/2. gRPC offers bi-directional streaming and binary protocol that buffers payloads, making it suitable for applications that require low latency communications.
CloudFront receives your gRPC requests and proxies them directly to your origins. You can use CloudFront to proxy four types of gRPC services:
+ Unary RPC
+ Server streaming RPC
+ Client streaming RPC
+ Bi-directional streaming RPC
## How gRPC works in CloudFront
To configure gRPC in CloudFront, set an origin that provides a gRPC service as your distribution’s origin. You can use origins that provide both non-gRPC and gRPC services. CloudFront determines if the incoming request is a gRPC request or an HTTP/HTTPS request based on the `Content-Type` header. If a request’s `Content-Type` header has value of `application/grpc`, the request is considered a gRPC request and CloudFront will proxy the request to your origin.
**Note**
To enable a distribution to handle gRPC requests, include HTTP/2 as one of the supported HTTP versions, and allow HTTP methods, including `POST`. Your gRPC origin endpoint must be configured to support HTTPS, as CloudFront only supports secure (HTTPS-based) gRPC connections. gRPC only supports end-to-end HTTPS. If you're using a custom origin, verify that your [Protocol](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy) settings support HTTPS.
To enable gRPC support for your distribution, complete the following steps:
1. Update your distribution's cache behavior to allow HTTP methods, including the `POST` method.
1. After you select the `POST` method, select the gRPC checkbox that appears.
1. Specify **HTTP/2** as one of the supported HTTP versions.
For more information, see the following topics:
+ [Allow gRPC requests over HTTP/2](DownloadDistValuesCacheBehavior.md#enable-grpc-distribution)
+ [GrpcConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_GrpcConfig.html) in the *Amazon CloudFront API Reference*
Because gRPC is used only for non-cacheable API traffic, your cache configurations won't affect gRPC requests. You can use an origin request policy to add custom headers to the gRPC requests that are sent to your gRPC origin. You can use AWS WAF with CloudFront to manage access to your gRPC distribution, control bots, and protect your gRPC applications from web exploits. CloudFront gRPC supports [CloudFront Functions](cloudfront-functions.md).
In addition to HTTPS status, you will receive grpc-status along with your gRPC response. For a list of possible values for grpc-status, see [Status codes and their use in gRPC](https://grpc.github.io/grpc/core/md_doc_statuscodes.html).
**Notes**
gRPC doesn't support the following CloudFront features:
[Custom error responses](GeneratingCustomErrorResponses.md)
[Origin failover ](high_availability_origin_failover.md) isn't supported with gRPC, as gRPC uses `POST` method. CloudFront fails over to the secondary origin only when the HTTP method of the viewer request is `GET`, `HEAD`, or `OPTIONS`.
CloudFront proxies gRPC requests directly to the origin and bypasses the Regional Edge Cache (REC). Because gRPC bypasses the REC, gRPC doesn't support [Lambda@Edge](lambda-at-the-edge.md) or [Origin Shield](origin-shield.md).
gRPC doesn't support AWS WAF request body inspection rules. If you enabled these rules on the web ACL for a distribution, any request that uses gRPC will ignore the request body inspection rules. All other AWS WAF rules will still apply. For more information, see [Enable AWS WAF for distributions](WAF-one-click.md).