Changing an EC2 instance type is not as straight forward as you might think, so I’m writing this post in note form as a reference for next time I come to do it. If it can also be of help to anyone else out there trying to get to grips with Amazon EC2, then that’s great too.

The aim here is to create a copy of the original instance, upgrading any hardware in the process, then swap the Elastic IP address over to the new instance to avoid any downtime.

1. Create a snapshot of the volume used on the current device.

2. Create a new machine image (AMI) based on this snapshot. It’s important to note here that you need to make sure the Kernel IDs match on the existing instance to the AMI you are creating. If they don’t the instance will fail server checks when starting up the instance. This had me stumped for quite a while until I found the blog post mentioning this (which I’ve referenced below).

3. Launch the new instance based on the new AMI you have created. There are lots of options here but specifically make sure you:

  • Choose the appropriate instance type you want. If you’re upgrading from micro -> small, then this is where you choose this.
  • Enter the size of the volume for the instance.
  • Select a security group if you already have a suitable one setup.
  • Choose an existing key pair to login to the server if you already have one you want to use.

4. Once you’re happy that the new instance has started up ok and the status checks confirm this, swap over the Elastic IP address you’re using to the new instance.

Disclaimer: This all worked for me, but if you have any problems please note this blog post is for reference/help only and comes with no promises or gaurantees.

Troubleshooting

Status check fails when loading AMI created from snapshot

“At a guess (check your console log, you might get more info) – either your AKI (kernel) or fstab (mounted volumes) differ. Check which AKI each image is launch with and see if they match. If it is your fstab trying to mount a non-existent volume, it should show up in your console log.”

“When you create an image from a snapshot, make sure you use the same architecture you used for the original instance/AMI. The default value in this wizard is i386, but in many cases you may want x86_64, which is the standard Amazon EC2 Linux architecture. This, together with selecting the exact AKI kernel – worked for me.”

Read more at http://serverfault.com/questions/395249/aws-status-check-fails-when-loading-ami-created-from-snapshot

Upgrading an Amazon EC2 instance from t1.micro to medium, instance storage remains same

“I created a m2.medium instance of 400 GB, but when I log into the shell and issue the command

df -h

… it shows an 8 GB partition. However, the command

sudo fdisk -l

showed that the device was indeed 400 GB. The problem is that Amazon created a default 8 GB partition on it, and that partition needs to be expanded to the full size of the device. The command to do this is:

sudo resize2fs -f /dev/xvda1

where /dev/xvda1 is the mounted root volume. Use the ‘df -h’ command to be sure you have the right volume name. Then simply reboot the instance, log in again, and you’ll see the fdisk command now says there’s nearly 400 GB available space. Problem solved.”

Read more at http://stackoverflow.com/questions/18918186/upgrading-an-amazon-ec2-instance-from-t1-micro-to-medium-instance-storage-remai

Other resources:

http://stackoverflow.com/questions/5898308/how-to-safely-upgrade-an-amazon-ec2-instance-from-t1-micro-to-large