The instructions you are following are for migrating a subdomain to a different distribution within the same account.
You cannot add an alternate domain name to a CloudFront distribution if the 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 *.example.com, that includes (that overlaps with) a non-wildcard alternate domain name, such as www.example.com. Overlapping domain names can be in the same distribution or in separate distributions as long as both distributions were created by using the same AWS account. (emphasis added)
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html#alternate-domain-names-wildcard
It is not possible to have wildcard ambiguity across multiple accounts, and what you are trying to do would set up just such a condition. It isn't supported because it's a security vulnerability.
I don't understand why the Cloudfront distribution needs to know what things CNAME to it, which is maybe part of the reason I'm not understanding the error below.
HTTP and DNS interact in such a way that the destination server is unaware of the DNS resolution path that led the browser to the server address to which it is connected. The server can only identify the site the browser is requesting by the HTTP Host
header and the value of the SNI field when HTTPS is in use -- the dzczcexample.cloudfront.net
intermediate hostname is lost in the process. The Alternate Domain Name configuration setting (unfortunately and inaccurately also called CNAME, for legacy reasons) is what CloudFront -- a massive, globally-distributed system -- uses in order to determine which specific distribution should handle the request, so Alternate Domain Name can only be set to foo.example.com
for one distribution in all of CloudFront.
As noted above, *.example.com
can only be set on a CloudFront distribution within the same account as foo.example.com
, because to allow otherwise creates a domain hijacking vulnerability.
The workaround is a little bit delicate, but it can be done.
- Set up the new CloudFront distribution, without setting the Alternate Domain Name, and wait for it to transition to the
Deployed
status.
- Change DNS to point to the assigned hostname for the new distribution. This will not do what you might assume: traffic will actually still be handled by the old distribution, because of the
Host
header/SNI mapping mentioned above... but this setting needs to be changed before continuing.
- Remove the hostname from the Alternate Domain Name settings of the old distribution and save changes.
- Add the hostname to the new distribution's Alternate Domain Name settings and save changes. You should get errors for a short period of time, after which the change will be accepted and traffic will be served by the new distribution.
You will want to set up two test distributions and a dummy subdomain (probably in a different domain, entirely) and work through these steps to familiarize yourself with the process. The resulting outage, when I have walked through this process previously, is brief, since you are not creating a new distribution (which takes some time) but simply changing the attributes of one stable distribution, and then the other.