Moving an EC2 Instance to a Larger Size

When you discover that the entry level t1.micro instance size is simply not cutting it for your growing application needs, you may want to try upgrading it to a larger instance type, perhaps an m1.small or even a c1.medium.

Instead of starting a new instance and having to configure it from scratch, you may be able to simply resize the existing instance by asking Amazon move it to better hardware for you. Of course, since this is AWS, you don’t have to actually talk to anybody—just type a few commands and the job is done automatically.

Constraints

Before you try this approach, note that there are some conditions:

1. You must be running an EBS boot instance (not instance-store or S3-based AMI). Any files on ephemeral storage (e.g., /mnt) will be lost.

2. You can only move to a different instance type of the same architecture (32-bit or 64-bit).

3. The private and initial public IP addresses of the instance will be different when it is running on the new hardware. Use an Elastic IP Address to keep the public IP address the same.

4. There will be a short outage while the instance is moved to new hardware (roughly equivalent to the reboot time of normal hardware).

Process

Run a new t1.micro Ubuntu 10.04 Lucid instance to be our demo. I recommend uploading your own ssh key first.

instance_id=$(ec2-run-instances --instance-type t1.micro --key $USER ami-3e02f257 |
  egrep ^INSTANCE | cut -f2)

Wait until it is running and perhaps log in to install software or touch some files so you know it’s your instance. When you are ready:

Step 1 - stop the t1.micro instance:

ec2-stop-instances $instance_id

At this point in a normal environment, you might want to create an EBS snapshot AMI of the instance for backup purposes in the event that anything goes wrong. (See: ec2-create-image)

Step 2 - While the EBS boot instance is stopped, switch the instance type from t1.micro to m1.small:

ec2-modify-instance-attribute --instance-type m1.small $instance_id

Step 3 - Start the instance using its new m1.small type:

ec2-start-instances $instance_id

Wait until it is running (again), then log in to verify that it is the same instance with all your software and data. If you were using an Elastic IP address with the instance, it would need to be reassociated after the instance is started.

Eventually, you’ll discover that an m1.small isn’t all that powerful either for moderate loads, so you’ll want to upgrade to a c1.medium, which for many purposes is a great size. It offers 5X the CPU of an m1.small for only 2X the price.

Unfortunately, with a 32-bit instance, c1.medium is as high as you can currently go as of this writing. You’ll need to switch over to a new instance running a 64-bit AMI if you want to go larger.

If you were following along with this example, don’t forget to clean up after yourself:

ec2-terminate-instances $instance_id

Bonus

Though we often think “scaling” means moving to larger/faster/more hardware, Amazon EC2 has shown us that it is equally valuable to be able to scale down when we no longer need the extra capacity. The above approach can be used to move your instances to smaller instance types to reduce costs.

If you run this demo, you will be charged for 1 hour of t1.micro instance time plus 1 hour of m1.small instance time, plus fractions of a penny in EBS volume and IO charges. That’s slightly more than a dime.

My company has used this technique a number of times as a way of scaling up and down certain services that did not have a load balanced auto scaling architecture set up. It’s a fantastic way to temporarily increase memory on a system while you debug a new memory issue, and then scale back down after you resolve it.