2

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 ?

  • 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 4 '16 at 23:26
  • I want to perform A/B Testing of two static sites hosted in s3. – Anushka Potabatti Feb 8 '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 8 '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 8 '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 8 '16 at 12:30
3

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.

1

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?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.