8 Things to consider while Migrating Cloud Infrastructure between AWS Regions

With the recent launch of AWS’s Mumbai region, the first thought that comes to the mind of any DevOps would be to migrate IT-Infra from Singapore region to Mumbai if we have a huge customer base in India. This would, of course, decrease the latency as well as help them to save a lot of bucks as it is cheaper than Singapore region.

We have been taking care of an e-commerce website hosted in AWS Singapore region, and now we have migrated it to Mumbai region. We thought of writing a blog on what we have learned during this migration activity. Migration, as we all know, is to migrate servers which are responsible for keeping our web application running such as application, web, database, etc. and a few other. We would be looking for few things which were required to be considered while performing this migration activity:

1. Update base AMI: Base AMI is the one which includes security, monitoring, and logging packages such as “fail2ban”, NewRelic, Logstash forwarder, auditd, etc. This is a good time to update these packages and their configuration and include new ones if required. In case Docker is being used, Docker version could be updated.
2. Update base docker images: We are using Docker in all the environments. We can include basic packages in docker images which we observed as good to have in older times for debugging such as curl, telnet and few others such as vim, wget, zip, etc.
3. AWS Discovery Plugin of Elasticsearch: We are using Elasticsearch database and while migrating it to Mumbai we encountered an issue where AWS Discovery plugin was not supported in Mumbai Region. We resolved it by changing its code. The details could be found here.
4. Migrating Jenkins Server: We can simply migrate Jenkins server by creating server’s AMI in Singapore region and then copying it in Mumbai region. This task is not as simple as the servers’ IP may be different in Mumbai region. After bringing the server up, the jobs need to be tested to figure out any authentication problem with the servers the job tries to connect. Since the jobs would be trying to connect to the servers running in Mumbai region after migration so, all needs to be well tested.
5. Cron jobs running on various servers: All Cron jobs need to be listed in one place if already not centralized so that every job could be taken care off. We may have to update the jobs in case we are using IPs in them.
6. VPN Server: If one is using VPN server for secure logging into the servers then we may have to create all the client again because the public IP of the VPN server would get changed. Currently, AWS does not address the EIP migration between regions.
7. Third Party Payment Gateway: Most of the e-commerce websites used third party payment gateways.The payment gateways need IPs to be whitelisted. In Mumbai region, we had to create a new AWS NAT gateway and get its public IP whitelisted by the payment gateway.
8. Centralized Logging: Most of us use ELK as a centralized logging system, and we make the communication between the servers secure by using a secure certificate which we generate against a particular URL or IP. Ensure to update the certificate if generated against an IP.

DevOps are required to provide endpoints to the developers if updated. They may need to update the AWS region in the code where it is referred. I hope this would be helpful during such kind of a migration process.