# Use custom URLs by adding alternate domain names (CNAMEs) 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.