4

Two CloudFront Distributions :

The option I attempted was to have two separate CloudFront Web Distributions, one for a static site in s3 bucket (A version) and other for another static site in s3 bucket (B version). I attempted to use a Route53 weighted routing policy where I added two records for my www.domain.com Route53 record, one pointing to CloudFront Distribution A with a weight of 0 and the other pointing to CloudFront Distribution B with a weight of 0. I want to do A/B Testing.

Used www.domain.com as Alternate CNAME for Prod distribution A.

Used *.domain.com as Alternate CNAME for Prod distribution B.

My content is always getting served from A. I want it to be served from both the versions with equal proportion.

Any help on this ?

sysadmin1138
  • 133,124
  • 18
  • 176
  • 300
Anushka Potabatti
  • 61
  • 1
  • 4
  • I've answered your question, below -- but this follow-up question occurs to me: what problem was this setup intended to solve? There may be an alternative. – Michael - sqlbot Feb 04 '16 at 23:26
  • I want to perform A/B Testing of two static sites hosted in s3. – Anushka Potabatti Feb 08 '16 at 11:29
  • Two different static sites? Two identical static sites but with content hosted in buckets in different locations? There might be a solution, here, but I need to understand the difference in "A" vs "B" -- what is being compared/tested/evaluated? For A/B testing, why would you want the two sites to appear at the same hostname? – Michael - sqlbot Feb 08 '16 at 11:34
  • No, they are same sites with different UI content. We want to show once A site and once B site to the user. – Anushka Potabatti Feb 08 '16 at 12:13
  • It doesn't seem like you could effectively use round robin DNS (weighted or not) to accomplish this effectively... (W)RR is not that deterministic. – Michael - sqlbot Feb 08 '16 at 12:30
  • What about setting Traffic Policy in Route53 ? Any other suggestion other than this ? – Anushka Potabatti Feb 08 '16 at 12:37
  • I don't understand why you don't simply use two hostnames and two distributions. Perhaps I am still not understanding what you are trying to accomplish. – Michael - sqlbot Feb 08 '16 at 12:41

2 Answers2

6

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.

Michael - sqlbot
  • 22,658
  • 2
  • 63
  • 86
  • I am trying to set up zero down deployment for my website with the mentioned approach in the question and the same is suggested in this white paper (Refer 25-26 pages). https://d1.awsstatic.com/whitepapers/Storage/Building%20Static%20Websites%20on%20AWS.pdf Even in this white paper, they recommended the same approach which is mentioned in question but what would be the alternate way to avoid wildcard entries in Alternate CNAMEs? Every time I am getting redirected to the distribution which mentioned exact domain name with weighted routing policy as well. – Dinesh Chitta Mar 18 '20 at 06:40
  • 1
    @DineshChitta it isn't clear what you are really asking, here. The wildcard entry is absolutely critical because it's the only reason this solution is viable. Also unclear is your reference to *"weighted routing policy"* because it isn't possible to use weighted routing to split traffic across CloudFront distributions. Which distribution's Alternate Domain Name a request's HTTP `Host` header matches is ultimately the *only* criterion used for distribution selection. The specific endpoint where the request arrives at CloudFront does not matter. – Michael - sqlbot Mar 18 '20 at 12:44
2

One solution I got is : I tried using two different services. Where I added two records for my www.domain.com Route53 record, one pointing to CloudFront Distribution A with a weight of 0 and the other pointing to directly to the s3 Bucket (www.domain.com) at location B with a weight of 0. WRR works. But, I don’t think we can use the S3/Cloudfront style of WRR because the performance will be so different between the two that the A/B testing will not really be fair to the S3 version. Clients will get much better response times from the Cloudfront edge servers.

I got another option i.e. setting up a traffic policy in Route 53. I think I should go with this. Is there any other option which I can try and which is fulfills AB Testing requirement plus is cost effective?

Anushka Potabatti
  • 61
  • 1
  • 4