Increased flexibility – sometimes referred to as ‘elasticity’ – is one of the major reasons organizations decide to leverage the AWS Platform. Elasticity is the flexibility to use only the resources you require, with the ability to scale out and in as needed, where needed. But what happens when a workload grows beyond its provisioned resources? Sometimes an application will grow to need more RAM or processing power, and simply adding more nodes isn’t a viable solution.
This is where resizing your EC2 instances comes into effect. AWS has made resizing your EBS-backed instances quite effortless.
Before resizing an instance, there are three compatibility checks that must be met:
Virtualization type
Network
Platform.
Virtualization type
Linux-based AMIs use one of two types of virtualization: Paravirtual (PV) or Hardware Virtual Machine (HVM). You cannot resize an instance from PV to a HVM.
Network
Some instance types are not supported in EC2-Classic and must be launched in a VPC. You cannot resize an instance in EC2-Classic mode to a instance type that is available only in a VPC unless you have a custom VPC. To check if your instance is in a VPC or EC2-Classic, navigate to the EC2 console and check the VPC ID value on the details pane of the Instances screen.
Platform
All EC2 instance types support 64-bit AMIs, but only the following support 32-bit AMIs: t2.nano, t2.micro, t2.small, t2.medium, c3.large, t1.micro, m1.small, m1.medium, and c1.medium.
Once the requirements for resizing your instance have been met, you can go ahead with the resizing process.
Resizing an EBS-backed instance
Open the EC2 console
Select the instance you wish to resize, and stop the instance
With the selected instance, choose Actions > Instance Settings > Change Instance Type
From the Change Instance Type dialog box, choose which instance you would like to resize to
If the desired instance class is not listed, then it isn’t compatible with your existing instance configuration
Once applied, start the stopped instance – it will now be running on the new instance class you chose
Things to note about resizing your instance:
The instance ID will not change, even though the underlying hardware is changed.
If your instance is running in a VPC and has a public IPv4 address, it will receive a new public IPv4 address but retains its private IPv4 addresses, any Elastic IP addresses, and any IPv6 addresses.
If the instance is in an Auto Scaling group, you must suspend Auto Scaling otherwise the stopped instance will be marked as unhealthy and may be terminated before you can resize the instance.
Should your desired new instance be incompatible with the previous instance, system compatibility or switching from PV to HVM virtualization, you can migrate your workload to a new instance using the process below.
Migrating your workload to a new instance
Create a snapshot of any instance-store volumes so as to not lose any of the required data
Launch the desired new instance
EC2-VPC – Be sure to launch the new instance in the same VPC as the currently running instance
Stop the old instance and detach any EBS volumes you want to use with the new instance
Attach the EBS volumes from the old instance to the new instance
Restore any data from the instance-store volume backups
Install your application(s) as needed on the new instance
If an Elastic IP is being used, detach it from the old instance and associate with the new instance
Optional – Terminate the old instance if it is no longer needed
Things to note about migrating your workload to a new instance:
The instance ID will change, so keep this in mind as you may have to modify security settings to reflect the change.
If your instance is running in a VPC it will receive a new private IP address and a new public IP address if you’re not using an Elastic IP address.
If the instance is in an Auto Scaling group, you must suspend Auto Scaling otherwise the stopped instance will be marked as unhealthy and may be terminated before you can complete the migration.
As always, be sure to follow best practices when it comes to data migration and change control as the processes described in this article can cause service interruptions to your environment.
