Domain migration (what I shouldn't have done)
Introduction
For the next steps of this blog, I wanted to migrate the domain marcoaguzzi.it from the first AWS account I’ve signed to the second one (the one that actually has the real site going on, dev.marcoaguzzi.cloudns.ph/).
These poses a few threats:
- The registered domain should be moved to the first account to the second, and should continue serving the old site (now a placeholder with redirects)
- The hosted zone containing all the records should be migrated to the new account
- I didn’t want any downtime (little did I knew!)
Domain migration
The registered domain migration has been easy. Following the AWS guide at https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-transfer-between-aws-accounts.html was straightforward. Exported the domain from the first account, and imported to the second, neat.
Moving the hosted zone
The AWS guide continued in what should have been the hosted zone migration process, but it was quite awkward: it involved exporting the hosted zone as a json file and modifying it trying to break all the possible json syntaxes. Moreover, I wasn’t sure about the records pertaining to the https certificate that display a neat lock on the address bar.
Creating a Maintenance page
I simply create a simple html page with a maintenance message on the s3 website, still provisioned from the cloudfront distribution.
The simple but effective template was found at https://gist.github.com/pitch-gist/2999707
Starting building the new ‘prod’ site
Once the domain was migrated, I started creating the new ‘prod’ site using the same cloudformation template I had been using for the ‘dev’ site (the one that is displaying the arcticles at the moment).
Step 1 - Generating the new stack and the change set
Using git from AWS cloudshell
I’ve found this script that sets up the git certificate for cloning with ssh a repo in the cloudshell, which I’ve found useful to issue simple cli commands
I wanted to check wether the cloudformation stack was ok, so I started using CLI in order to create the new stack from a new changeset that I could revise:
aws cloudformation create-change-set --stack-name marcoaguzzi-website-prod --change-set-name first-deploy --template-body file://marcoaguzzi.json --change-set-type CREATE --parameters file://parameters-prod.json
I did a bunch of back and fort deletion and re-creation using the delete command
aws cloudformation delete-change-set --change-set-name arn:aws:cloudformation:us-east-1:***:changeSet/first-deploy/***
Step 2 - change set execution
And then finally execute the change set
aws cloudformation execute-change-set --change-set-name arn:aws:cloudformation:us-east-1:***:changeSet/first-deploy/***
This led to a bunch of problems:
- The new created hosted zone had the dns server set up randomically, while the registered domain had the one pointed to the hold hosted zone (which I didn’t migrate)
- Due to the discrepancy above, the https certificate couldn’t be automatically validated
Step 3 - updating the registered domain and trial and error
The registered domain
Reluctantly, I updated the registered domain DNS to match the hosted zone ones, and that led to have the main domain, marcoaguzzi.it, not responding for one hour and a half.
The cloudfront distribution breaks it all
After the domain matched the hosted zone, I confirmed the certificate, and cloudformation template went on creating stuff but.. the cloudfront distribution couldn’t be created because the old one was serving the same CNAME that I wanted in the new account. Cloudfront rolled back by destroying all the resources (including the hosted zone).
I had to restart all from the beginning, including registered domain DNS update
Step 4 - migrated domain back to life
I destroyed the cloudfront distribution in the first account (I first only disabled it, but it costed me another re-run), and run cloudformation template from the beginning, this time it all went through and the “prod” domain was still responding
Yet to do stuff
Here’s a list of stuff to fix in order to have the new production site mimic the “dev” one (from where you’re reading this post)
- check cloudformation drifts
- reactivate lambda@edge on “prod” to align to “dev”
- add CNAME record (from www.marcoaguzzi.it to marcoaguzzi.it) in cloudformation
- activate logging in “prod” cloudfront
Conclusion
Hope that this post will be of some help to anyone reading it, probably I’ll update it as long as improvement to cloudformation template will be put in place
Domain migration (what I shouldn't have done)