Current Stack
I am using a cloudfront to distribute my static website objects that live in an S3 bucket. I am using Route53 to handle my DNS routing and health checking.
What I'd like to accomplish
I recently came across Netlify that does Split testing between different feature Branches. I would like to stick with my current stack on AWS but would like to build in this functionality for AB testing.
What I tried
Originally, I wanted to have a Route53 serve 2 separate Cloudfront services each with their own S3 bucket. I would use Weighted Round Robin to distribute 10% of traffic to the testing environment and the other 90% to the production environment. I learned quickly that Amazon does not allow the same domain to serve 2 different Cloudfront services each serving their own S3.
The other option was to do this testing at the edge node of my cloudfront service. This would require me to serve two different objects to from the same S3, which seems very messy and not scalable.
My question
Is it even possible to replicate what Netlify does with Split testing when using AWS? If so, how can I implement it? If not, what is my next best option for AB testing a static website?
Related
I just tested a deployment with AWS Amplify and the Amazon console.
My app is based in Paris. I try to do a test with GTMETRIX (based in Canada), I get a bad "Largest Contentful Paint". More than 4.2s.
On the other hand, here in Europe, it loads very quickly (max 1 second).
I tested with a Canada based VPN, it is slow to load. In comparison, I hosted my application on another service (like Vercel or Netlify) and the loading is much faster.
I thought AWS Amplify was working with the Cloudfront CDN. I have the impression that it is not working properly given the slowness in other countries.
Can you tell me why ?
Thank you
PS : This is only a static vuejs application.
There are too many factors that leads to the slowness.
But, Yes - AWS Amplify leverages the Amazon CloudFront Global Edge Network to distribute your web app globally. To deliver content to end users with lower latency, Amazon CloudFront uses a global network of 144 Points of Presence (133 Edge Locations and 11 Regional Edge Caches) in 65 cities across 29 countries.
For debugging purpose, one thing that you can consider to try is by hosting your your static website in S3 and served through CloudFront (this article may help you to troubleshoot).
I'm having difficulty providing a bluegreen for my s3 static website. I publish a version of the website in a given bucket and it is exposed at:
a Cloudfront distribution
then on a Route 53
and yet another CDN (corporate, which resolves the DNS) to reach the internet.
I've trying some "compute" solutions, like ALB, but I'm not successful.
The main issue of my difficulty is the long DNS replication time when I update CloudFront with a new address, making it difficult to rollback a future version to the old one (considering using different buckets for this publication).
Has anyone been through this or have any idea how to solve this?
AWS recommends that you create different CloudFront distributions for each
blue/green variant, each with its own DNS.
From the Hosting Static Websites on AWS prescriptive guidance:
Different CloudFront distributions can point to the same Amazon S3
bucket so there is no need to have multiple S3 buckets. Each variation
[A/B or blue/green] would store its assets under different folders in the same S3 bucket.
Configure the CloudFront behaviors to point to the respective Amazon
S3 folders for each A/B or blue/green variation.
The other key part of this strategy is an Amazon Route 53 feature
called weighted routing. Weighted routing allows you to associate
multiple resources with a single DNS name and dynamically resolve DNS
based on their relative assigned weights. So if you want to split your
traffic 70/30 for an A/B test, set the relative weights to be 70 and
30. For blue/green deployments, an automation script can call the Amazon Route 53 API to gradually shift the relative weights from blue
to green after automated tests validate that the green version is
healthy.
Hosting Static Websites on AWS - It's 2016 year whitepaper. It relies on non-working examples that don't work. You can't just setup two cloudfront distributions to serve the same CNAME for dns switching.
Another way is to do green/blue logic in lambda edge.
You can do blue/green or gradual deployment with a single Cloudfront distribution, 2 S3 buckets and Lambda#Edge.
You can find a ready-to-use cloudformation template that does this here.
I have a semi-popular Django website with postgresql backend where users share photos with one another (approx 3 are shared per minute).
The whole set up is hosted on two separate Azure VMs - one for the web application and one for the database. I use classic VMs, both are part of the same resource group, and map to the same DNS as well (i.e. they both live on xyz.cloudapp.net). I also use Azure blob storage for my images (but not for other static files like the CSS) - for this I've provisioned a storage account.
Since I'm heavily reliant on images and I want to speed up how fast my static content is displayed to my users, I want to get Azure CDN into the mix. I just provisioned one from the portal, making it part of the same resource group as my classic VMs.
Next, I'm trying to add a CDN endpoint. I need help in setting that up:
1) Can a CDN be used with classic VMs, or is it feature solely for the resource manager deployment?
2) Given 'yes' to the previous one, when one provisions a CDN endpoint, what should the origin type be? Should it be the cloud service I'm using (i.e. under which my VMs fall), OR should it be the azure storage which holds all my images? What about other static content (e.g. the CSS), which isn't hosted on Azure blobs?
3) What's the purpose of the optional origin path? Should I specify directories? What happens if I don't?
4) Will I be up and running right after the CDN endpoint is successfully provisioned? Or is there more configuration to come after this? I'm unsure what to expect, and I don't want to disrupt my live service.
Btw, going through the answer here still doesn't comprehensively answer my questions. Reason being:
1) I don't use an azure web app, I've provisioned virtual machines and done my own set up over Ubuntu
2) I'm unsure whether I'm supposed to create a new storage account for the CDN, as discussed in this question's answer.
3) Again, not being a web app, should I map the origin type to my blob service URL? The answer seems to say so, however, I do have the option of using my cloudservice DNS instead. What happens in each case?
Sounds like you have two origins, a storage account and a VM.
What you need to do here is to create two CDN endpoints, one for your pictures in the storage account, one for the css on the VM.
Let's say I created myendpoint1.azureedge.net, using the VM as an origin and I also created myendpoint2.azureedge.net, using the storage account as an origin.
If I access myendpoint1.azureedge.net/Content/css/bootstrap.css, I should be able to get same content as xyz.cloudapp.net/Content/css/bootstrap.css
If I access myendpoint2.azureedge.net/myPictureContainer/pic.jpg, I should be able to get same content as mystorageaccount.blob.core.net/myPictureContainer/pic.jpg
After all the validation is done, you need to change your html files to reference the css from the myendpoint1.azureedge.net and reference the pictures from myendpoint2.azureedge.net, and then you deploy your website. There will be no interrupt of the service.
Also, CDN can be used on any kind of origins, so yes for Classic VM. They type of the origin doesn't matter, if the url of your VM/storage is not in any of the dropdown list, then just use the custom origin and use the correct url.
I am new here and have tried searching but could not get any answers.
I have set up Bit Torrent Sync on an EC2 micro instance with EBS attached.
The server is in Sydney which is where I spend most of my time.
However I do travel a fair bit and would like to have more locations where the files are located.
Is there a way to do this without setting up another EC2 server? I was thinking CloudFront may be helpful here but I do not know how to set it up.
Any other ideas?
Thanks in advance.
Well there's a couple of ways you can do this:
You can setup S3 with Cloudfront. Basically, you copy your static files to an S3 bucket (Global works good) and then say from the AWS console you can go to CloudFront and create a distribution for that specific bucket.
Point the the CloudFront distribution to the web server where you are hosting your files (Assuming you are using HTTP or HTTPs)
You can also specify a custom CNAME Record that you can use on your domain to point to the CloudFront distribution.
Furthermore for improved performance you can use: All Edge Locations when creating your CloudFront distribution.
Hope this helps.
I would like not to tight with aws technologies and I was wondering what are the Open Source Mature Equivalent of Amazon CloudFront?
CDN is not some software which can have open-source.. It is a network of computers ( POPs ) i.e. lots of hardware, server, bandwidths are needed to implement a CDN. Hence, open source is not possible.
Regarding getting tied up with AWS; all you need to do is create a different URL suppose for all media URLS like http://cdn.example.com .. And all the static content which should be served via CDN should be put on this URL.. something like http://cdn.example.com/abc.jpg
Now, you can just create A records, B records on your DNS server to point to Amazon Cloud Front.. if suppose tomorrow you want to switch your cloud front; all you need to do is change these records on dns server.. Thats it. You are in no way tied with amazon.