Two Cloudfront Distributions
Since AWS allows for overlap between wildcard alternate CNAMEs in the same AWS account, you can switch between two cloudfront distributions in the following manner:
- Use www.domain.com as Alternate CNAME for Prod distribution 1
- Use *.domain.com as Alternate CNAME for Prod distribution 2
- Point your CNAME DNS www.domain.com to distribution 1 or distribution 2. (*.cloudfront.net).
- Remove the alternate CNAME from the distribution which you don't want to serve the content from anymore.
However, the two different distribution DNSs (*.cloudfront.net) may point to the same edge nodes, which means that the way your content is served is by matching the cloudfront.net CNAME to the Edge nodes serving it and then to match by hostname. In this case, if both your distributions are using the same edge nodes (it can be checked for example with dig) the cut will not be clean.
e.g. If both distributions share one or more edge nodes, distribution 1 with Alt CNAME www.domain.com will take precedence over distribution 2 with the more generic *.domain.com
until the CNAME gets removed from the distribution 1 config in all edge nodes. So the version retrieved from one request may be different from the other during the transition period.
You can't do this with CloudFront.
tl;dr: your wildcard doesn't match hostnames where a specific, conflicting hostname is configured on another distribution.
You created the wildcard alternative hostname on distribution B as an attempt to work around this restriction:
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.
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html#alternate-domain-names-restrictions
There is, of course, a reason for this restriction, and it also explains why distribution B would never see your requests, even though your DNS configuration is working as expected.
The exception to the rule...
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.
... does not provide the exception you anticipated.
When a web browser connects to an endpoint, how the browser got there is not preserved -- was it a static A record, an Alias, a CNAME, a whole cascade of CNAMEs, or an entry in your hosts file? The server doesn't know, because that information is not preserved... It knows the IP address you arrived at, but that's from a pool shared by many distributions, so how your request happened to arrive at a particular CloudFront edge (which set of DNS records was followed, your "A" or "B" -- they may not even be different IP addresses on the CloudFront end) is not something that can be used to determine which distribution should service your request.
The only mechanism CloudFront has in order to determine which distribution should service a particular request is the HTTP Host: header in the incoming http request (potentially, SNI negotiation, too, but this doesn't change anything, whether or not CloudFront uses it).
Treating a request as belonging to a particular distribution is decided based on nothing else -- it can't be, since there's nothing else available to base it on.
By logical extension, only one distribution can be associated with any given incoming request Host: header, such as www.example.com (your distribution "A.")
The other distribution ("B"), *.example.com is, in fact, only able to serve requests for everything except www.example.com (or any other more specific alternate domain names you've associated with distributions that would otherwise match that wildcard) because another distribution on the same account with a more specific hostname associated ("A") claims the specific hostname www.example.com as an exception to the * wildcard.
Essentially, requests are checked for a distribution with a exact hostname match, first, and only when there is no match, would the distribution with the wildcard be used for the request.
Best Answer
Actually, they give the right content, in context. (Stick with me, here...)
The problem -- technically speaking -- is that you are actually wanting/expecting a response that would in fact be incorrect -- behavior that would be wrong if it actually worked the way you expected, based on the request being made.
Take a look at the request headers using
curl -v. They may be connecting to an address retrieved by queryingeu.example.combut check this request header:The browser is actually getting exactly what it asked for.
This is why you can't assign the same alternate domain name to two CloudFront distributions. CloudFront -- like essentially all web servers -- uses the
Host:header sent by the browser to understand what site the browser wants to see. Web servers can't see the DNS path that got you to them. The fact that you can do this while connecting to an IP address returned for a different site is no real surprise -- pick any CloudFront IP and forge aHost:header for a different site, and it is pretty likely to work, because there are good odds that the CloudFront equipment listening on that address can find the configuration within CloudFront and service the request.This configuration cannot be done using only CloudFront and Route 53.
You need a proxy server in EC2 in the target region in the EU to act as a target for the eu domain in DNS, rewrite the
Host:header, and forward the modified request to CloudFront.