Tips for migrating services on Amazon AWS

When working with large infrastructures, especially when we define a new infrastructure for an existing service, it is time to carry out the final change, and start using all services with the new environment.

If your new infrastructure is in Amazon AWS, these simple tips can make your migration more comfortable.

Use the weights of Route 53

The Route 53 DNS service allows you to assign weights to the different entries. This is very useful to be able to change the traffic gradually from the old IPs to the new ones, and see how our platform behaves as the traffic increases.

All we have to do is create two equal entries, each pointing to the new destination, and distribute the total weight (255) between each entry. As we change it, Amazon will direct more traffic to the new destination until the process is complete.

“Warm up” ELB balancers

Amazon’s infrastructure is reactive to the different increases or decreases in traffic that are occurring.

In ELB load balancers, when the traffic increases suddenly, it is normal that the IPs of these balancers change, and the latency decreases even if the traffic increases.

This seems to indicate that Amazon detects the load increase and switches to an ELB with more capacity that can guarantee an adequate response for the new traffic.

Therefore, before migrating, it is advisable to launch a high number of requests to the balancer (or to the entire infrastructure) using Jmeter or a similar program, so that the balancer detects the change of traffic and assigns us new balancers of more capacity. This way we will be more prepared to process the new traffic.

Load the cache

If your new infrastructure has a distributed cache system such as CloudFront or Fastly, we can anticipate the change and improve the performance of it (while reducing the load of the platform) by preloading content into it.

If we expect that most of the traffic comes from a specific area, when launching requests from that area the system will request and store the result in its cache, so when making the change it will not be necessary to make the requests again .

Leave static content generated

If our infrastructure is ready to generate static content (for example clippings with Lambda against S3), leaving already generated those contents that we hope will be used will avoid an unnecessary burden in the first moments of the change of platform.

Forecast scaling

Unless our platform is completely serverless , it is normal to expect that the EC2 instances will escalate (new instances will be activated due to an increase in load).

This process (depending on your configuration), can take several minutes, during which the performance of the platform can be reduced, or even stopped if the load increase is very high.

Therefore, for platform migration it is advisable to start with one or two more instances, which allow us to avoid problems if we receive more load than expected, or if we have dimensioned our resources by default.

In short, prepare for the worst and try to leave everything generated or prepared before you start, so that the change is as traumatic as possible.