We're using cloudfront to front end a web app (myapp.com with s3, lambda, athena, ... etc)
Before a new release we're creating an entire new distribution (next.myapp.com) with new code and content, testing and then would like to make it the live version of myapp.com. But this doesn't seem possible.
Multiple Cloudfront distributions can't have the same CNAMEs so we can't change the DNS entry for myapp.com to point to the new service.
Changing the distribution means there's a delay as the new config populates around the world.
Is there away of doing this using amazon infrastructure? Or am I doing this completely wrong? Would like to be able to migrate the live service ASAP, but still have the existing version available for manual failback if the release breaks something
This is possible with only a very brief period of downtime, if you follow these steps.
Create the new distribution with the correct certificate but no Alternate Domain Name, and allow it to stabilize.
Change the DNS for the site to point to the new distribution. This does not have the negative impact that you would assume, because the site continues to work on the existing distribution. CloudFront does not differentiate between arrival endpoints -- it's only looking at the SNI and Host header, matching these against the Alternate Domain Name -- so the old distribution will continue to handle the traffic.
Edit the existing distribution to remove the Alternate Domain Name. You do not need to wait for it to return to "Deployed" status.
Edit the new distribution to add the Alternate Domain Name. You may have to attempt this more than once but it will eventually be accepted.
The trick is to use *.myapp.com as CNAME for the new distribution, switch your DNS records to point to the new distribution and when the switch is effective you clean everything up.
See Moving an Alternate Domain Name to a Different CloudFront Distribution.
It's not possible to do this for a second-level domain (myapp.com) without contacting AWS. The solution is to use www.myapp.com for the live version and have another distribution only for the HTTPS redirection from myapp.com to www.myapp.com (or a redirection with S3 but HTTP only then). The CNAME for this distribution would never need to be updated.
Related
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.
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?
We have a site setup in AWS. When we bring up a stack for a new release we make it available at a versioned URL. i.e.
V1 available at v1.mysite.com
V2 available at v2.mysite.com
etc
Is it possible to make a single DNS entry that will point to the latest deployed version of my site automatically? So, after I deploy V1, I would have two DNS entries:
v1.mysite.com which goes to the IP of it's stack
mysite.com which redirect to v1.mysite.com
Then when I deploy V2, mysite.com now redirects to v2.mysite.com without me manually having to edit the DNS entry.
In general, can I automatically make DNS entries or make some kind of wildcarded DNS entry that will always point to the highest numbered version of my site currently available in AWS? It should look at the digits after the V for all currently available DNS entries/stacks and make mysite.com point to the numerically highest one.
We are using CloudFormation to create our stacks and our DNS (Route 53) entries, so putting any logic in those scripts would work as well.
This isn't part of DNS itself, so it's unlikely to be supported by anything on Route53. Your best bet is a script that runs when your new instance starts or is promoted to be the production instance. It's pretty simple using boto:
Create a new boto.route53.record.Record
Create a new boto.route53.record.ResourceRecordSets
Add a change record with the action UPSERT and your record
Commit the ResourceRecordSets (with a simple retry in case it fails)
get_change() until Route53 replies INSYNC
Depending on your application you may also want to wait for all the authoritative DNS servers (dns.resolver.query('your-domain', 'NS')) at Amazon to know about your change.
We ended up must making this a manual step before deploying a new stack. If the new stack needed to be resovled at mysite.com, the deployer has to manually remove the existing mapping. Then the cloud formation scripts will create the new DNS mapping.
Not ideal but better than a ton of messy logic in cloud formation scripts I suppose.
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.