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