Blue/Green deployments with CloudFront
Solution 1:
Two Cloudfront Distributions
Since AWS allows for overlap between wildcard alternate CNAMEs in the same AWS account, you can switch between two cloudfront distributions in the following manner:
- Use www.domain.com as Alternate CNAME for Prod distribution 1
- Use *.domain.com as Alternate CNAME for Prod distribution 2
- Point your CNAME DNS www.domain.com to distribution 1 or distribution 2. (*.cloudfront.net).
- Remove the alternate CNAME from the distribution which you don't want to serve the content from anymore.
However, the two different distribution DNSs (*.cloudfront.net) may point to the same edge nodes, which means that the way your content is served is by matching the cloudfront.net CNAME to the Edge nodes serving it and then to match by hostname. In this case, if both your distributions are using the same edge nodes (it can be checked for example with dig) the cut will not be clean.
e.g. If both distributions share one or more edge nodes, distribution 1 with Alt CNAME www.domain.com will take precedence over distribution 2 with the more generic *.domain.com until the CNAME gets removed from the distribution 1 config in all edge nodes. So the version retrieved from one request may be different from the other during the transition period.
Solution 2:
A bit late in the game here, but for anyone else looking for this. I believe this can be done using lambda@edge. Similar to A/B tests. https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html. You can implement a lambda function triggered when a user requests a url. Choose to serve the blue/green content from different origins or url prefix. A cookie value will determine which deployment will be served. When the first request arrives (no cookie) set the the cookie randomly say 95% blue 5% green.
Solution 3:
Shooting from the hip, how long does it take to switch the origin within a cloud front distribution? 1) deploy new code behind ELB, warm it up 2) add this ELB as a new origin to your cloud front distribution while removing the old origin 3) once cutover, tear down old code behind old ELB.
To get away from the delays associated with CloudFront updates or DNS updates, you could swap the autoscale group behind your ELB. 1) deploy new code in new ASG, warm it up 2) register your existing ELB with this new ASG 3) de-register the old ASG from your ELB 4) once cutover, tear down old ASG.