10

Background:

I have a Javascript hosted on S3 bucket with static website + Cloudfront distribution + Route 53 setup. I need Cloudfront because I need custom domain with SSL support. This works fine. As an example, the script can be accessed at https://app.example.org/myscript.js. This URL is given to clients to embeded on their webpages and I can not change it.

The setup in Route 53 is like this:

app.example.org => Cloudfont Distribution (s3://app.example.org)

What I want:

I want to set up a staging environment for new features. I would like to direct 10% of production request to another version of the script.

What I tried

I've tried setting up another S3 bucket with static webiste + cloudfront with different alternative domain name (e.g. app-beta.example.org).

I need to use a different alternative subdomain because Cloudfront does not allow same alternative domain name with multiple distributions.

In Route 53, I set up alias A records like this:

app-beta.example.org => Alias Cloudfont Distribution (s3://app-beta.example.org) app.example.org => Alias app-beta.example.org (weighted 10) app.example.org => Alias Cloudfont Distribution (s3://app.example.org) (weighted 100)

Why didn't it work

It turned out that this won't work:

Because the requested domains is the same app.example.org, cloudfront distribution (s3://app.example.org) will pickup the request regardless the record of app.example.org => Alias app-beta.example.org.

I think here Route 53 do try routing the traffics to cloudfront according to the weight rules but eventually when requests reach cloudfront, cloudfront respects the 'alternative domain name' and use the one with (app.example.org) regardless.

How about not using cloudfront?

I've thought of using EC2 or EBS for an nginx server serving the static javascript files. This could work. But:

  • the javascript file will be requested worldwide. Using EC2 or EBS means for some users it will have higher latency. This is not ideal.

  • this means extra resources to manage and cost.

How about lambda@Edge?

Technically lambda@Edge is a perfect solution if it is cheaper. Yes, it is already cheap ($0.0000006 per request) but in our case, we will be paying more than USD 10k for it. ( the script is requested > 10 billion times per month, and 2 lambda functions are required for the set up)

Question

Is there any other way I can achieve what I want ? (i.e. gradually roll out new version without changing the URL)

David Lin
  • 13,168
  • 5
  • 46
  • 46

0 Answers0