# Understand how multi-tenant distributions work
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
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
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).