How to switch EC2 instance types without downtime

by Hang Tian
As a Senior DevOps Engineer with 6+ years’ experience, I’m here to explain tricky technical concepts, breakdown new trends and share tips on working with cloud-native technologies.
Published on February 2024

Although serverless and microservice architectures are becoming prevalent throughout the industry, many still rely on EC2.

For those workloads requiring fine-grained control, a static, predictable resource does it best. But when it comes to trading in one instance type for another, there can be a fair bit of disruption.

So, as an engineer working for the experts in uptime, I thought I’d share some tips on how to migrate your EC2 instances while keeping any downtime to a minimum.

Move your workload gradually between two autoscaling groups – if you have a variable workload and want to observe the change slowly

If you have variable workloads and want a solution that meets that demand during the transition, this is the method for you.

Essentially, you set up two autoscaling groups: one for your old instance type (this group likely already exists); one for your new instance type. Then, you gradually move your workload from the old group to the new.

While you’re doing this, keep an eye on KPIs like:

  • Application performance
  • Response times
  • CPU and memory usage
  • Network latency
  • Whether your scaling events are triggering as configured

This allows you to test your new instance type gradually, serving users from your older group if the new instances run into issues.

Pros and cons of the autoscaling method


  • This is a safe way of rolling out changes to users gradually
  • Depending on the method used to split traffic, rollback can be speedy
  • You can gain valuable insights into performance over time


  • To gradually shift traffic between autoscaling groups, an application load balancer or similar service (e.g. Cloudflare) is required
  • If it’s a lengthy rollout window, you’ll need to deploy the application to two groups simultaneously
  • Two sets of application servers can make for licensing issues
  • This can often be the most costly method due to the two sets of instances

Blue-green deployment – if you can replicate your environment and have instant rollback

If you’re set up for it, blue-green deployment can offer a fast, downtime-light migration, especially if you have high demand.

This involves creating a perfect replica (the green) of your old environment (the blue). You then move traffic from one to the other.

Because your green is a whole new environment, you will be able to see how your new instance type performs in terms of:

  • Cost
  • Deployments affecting users
  • Required rollbacks and bugs
  • Many of the same performance KPIs used in the case of autoscaling

The blue-green method is useful for critical updates with minimal disruption to users – and avoiding downtime.

Pros and cons of the blue-green method


  • Can be implemented with very low disruption to users
  • Can effectively reduce downtime
  • This method allows you to see how your new instances perform within the existing environment


  • As in the first case, an application load balancer or similar is required
  • Again, a longer rollout will mean simultaneous deployments
  • Although less expensive than the autoscaling method in most cases, two sets of servers will incur a cost

The AMI method – if you can tolerate some downtime and are short on resources

If you’re part of a small team, and you want to migrate to your new EC2 instance types without the hassle of creating a perfect replica of your previous environment – this is for you.

It’s also a good idea if you need to replicate other settings very precisely.

Using an Amazon AMI, you can take a snapshot of your existing instance and deploy a new instance with the new instance type and test accordingly.

When testing is completed, a window can be coordinated with your team for an outage while you manage the changeover.

This is a direct method, without as much contingency.

Once you’ve carried out the AMI method, you’ll want to monitor many of the same KPIs as in the previous two methods.

Pros and cons of the AMI method


  • This is the most simple method of upgrading instance types
  • The instance can be updated without updating network configurations
  • The rollback is a simple process: power down, change the instance type, power up
  • This is the cheapest method of rolling out a new instance type


  • Downtime will occur. This makes the AMI method unsuitable for large applications serving a high volume of users

How we can help

At Just After Midnight, we support mission-critical AWS environments for leading brands, agencies, and products around the world. So, if you’re looking for some extra help keeping your AWS environment online during a migration, or for anything else – just get in touch.



With partners across the USA, Europe and APAC, we provide a truly global service. So wherever you or your clients are based, contact us today to find out what we can do.