https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-resize.html
As your needs change, you might find that your instance is over-utilized (the instance type is too small) or under-utilized (the instance type is too large). If this is the case, you can change the size of your instance. For example, if your t2.micro instance is too small for its workload, you can change it to another instance type that is appropriate for the workload.
You might also want to migrate from a previous generation instance type to a current generation instance type to take advantage of some features; for example, support for IPv6.
If the root device for your instance is an EBS volume, you can change the size of the instance simply by changing its instance type, which is known as resizing it. If the root device for your instance is an instance store volume, you must migrate your application to a new instance with the instance type that you need. For more information about root device volumes, see Storage for the root device.
When you resize an instance, you must select an instance type that is compatible with the configuration of the instance. If the instance type that you want is not compatible with the instance configuration you have, then you must migrate your application to a new instance with the instance type that you need.
Important
When you resize an instance, the resized instance usually has the same number of instance store volumes that you specified when you launched the original instance. With instance types that support NVMe instance store volumes (which are available by default), the resized instance might have additional instance store volumes, depending on the AMI. Otherwise, you can migrate your application to an instance with a new instance type manually, specifying the number of instance store volumes that you need when you launch the new instance.
Contents
- Compatibility for resizing instances
- Resizing an Amazon EBS–backed instance
- Migrating an instance store-backed instance
- Migrating to a new instance configuration
Compatibility for resizing instances
You can resize an instance only if its current instance type and the new instance type that you want are compatible in the following ways:
- Virtualization type: Linux AMIs use one of two types of virtualization: paravirtual (PV) or hardware virtual machine (HVM). You can’t resize an instance that was launched from a PV AMI to an instance type that is HVM only. For more information, see Linux AMI virtualization types. To check the virtualization type of your instance, see the Virtualization field on the details pane of the Instances screen in the Amazon EC2 console.
- Architecture: AMIs are specific to the architecture of the processor, so you must select an instance type with the same processor architecture as the current instance type. For example:
- If you are resizing an instance type with a processor based on the Arm architecture, you are limited to the instance types that support a processor based on the Arm architecture, such as A1 and M6g.
- The following instance types are the only instance types that support 32-bit AMIs:
t2.nano, t2.micro, t2.small, t2.medium, c3.large, t1.micro, m1.small, m1.medium, and c1.medium. If you are resizing a 32-bit instance, you are limited to these instance types.
- Network: Newer instance types must be launched in a VPC. Therefore, you can’t resize an instance in the EC2-Classic platform to a instance type that is available only in a VPC unless you have a nondefault VPC. To check whether your instance is in a VPC, check the VPC ID value on the details pane of the Instances screen in the Amazon EC2 console. For more information, see Migrating from a Linux Instance in EC2-Classic to a Linux Instance in a VPC.
- Enhanced networking: Instance types that support enhanced networking require the necessary drivers installed. For example, the A1, C5, C5a, C5d, C5n, C6g, F1, G3, G4, H1, I3, I3en, Inf1,
m4.16xlarge, M5, M5a, M5ad, M5d, M5dn, M5n, M6g, P2, P3, R4, R5, R5a, R5ad, R5d, R5dn, R5n, R6g, T3, T3a, u-6tb1.metal, u-9tb1.metal, u-12tb1.metal, u-18tb1.metal, u-24tb1.metal, X1, X1e, and z1d instance types require EBS-backed AMIs with the Elastic Network Adapter (ENA) drivers installed. To resize an existing instance to an instance type that supports enhanced networking, you must first install the ENA drivers or ixgbevf drivers on your instance, as appropriate.
- NVMe: EBS volumes are exposed as NVMe block devices on instances built on the Nitro System. If you resize an instance from an instance type that does not support NVMe to an instance type that supports NVMe, you must first install the NVMe drivers on your instance. Also, the device names for devices that you specify in the block device mapping are renamed using NVMe device names (
/dev/nvme[0-26]n1). Therefore, to mount file systems at boot time using /etc/fstab, you must use UUID/Label instead of device names.
- AMI: For information about the AMIs required by instance types that support enhanced networking and NVMe, see the Release Notes in the following documentation:
- General purpose instances
- Compute optimized instances
- Memory optimized instances
- Storage optimized instances
Resizing an Amazon EBS–backed instance
You must stop your Amazon EBS–backed instance before you can change its instance type. When you stop and start an instance, be aware of the following:
- We move the instance to new hardware; however, the instance ID does not change.
- If your instance has a public IPv4 address, we release the address and give it a new public IPv4 address. The instance retains its private IPv4 addresses, any Elastic IP addresses, and any IPv6 addresses.
- If your instance is in an Auto Scaling group, the Amazon EC2 Auto Scaling service marks the stopped instance as unhealthy, and may terminate it and launch a replacement instance. To prevent this, you can suspend the scaling processes for the group while you’re resizing your instance. For more information, see Suspending and Resuming Scaling Processes in the Amazon EC2 Auto Scaling User Guide.
- If your instance is in a cluster placement group and, after changing the instance type, the instance start fails, try the following: stop all the instances in the cluster placement group, change the instance type for the affected instance, and then restart all the instances in the cluster placement group.
- Ensure that you plan for downtime while your instance is stopped. Stopping and resizing an instance may take a few minutes, and restarting your instance may take a variable amount of time depending on your application’s startup scripts.
For more information, see Stop and start your instance.
Use the following procedure to resize an Amazon EBS–backed instance using the AWS Management Console.
To resize an Amazon EBS–backed instance
- (Optional) If the new instance type requires drivers that are not installed on the existing instance, you must connect to your instance and install the drivers first. For more information, see Compatibility for resizing instances.
- Open the Amazon EC2 console.
- In the navigation pane, choose Instances.
- Select the instance and choose Actions, Instance State, Stop.
- In the confirmation dialog box, choose Yes, Stop. It can take a few minutes for the instance to stop.
- With the instance still selected, choose Actions, Instance Settings, Change Instance Type. This action is disabled if the instance state is not
stopped.
- In the Change Instance Type dialog box, do the following:
- From Instance Type, select the instance type that you want. If the instance type that you want does not appear in the list, then it is not compatible with the configuration of your instance (for example, because of virtualization type). For more information, see Compatibility for resizing instances.
- (Optional) If the instance type that you selected supports EBS–optimization, select EBS-optimized to enable EBS–optimization or deselect EBS-optimized to disable EBS–optimization. If the instance type that you selected is EBS–optimized by default, EBS-optimized is selected and you can’t deselect it.
- Choose Apply to accept the new settings.
- To restart the stopped instance, select the instance and choose Actions, Instance State, Start.
- In the confirmation dialog box, choose Yes, Start. It can take a few minutes for the instance to enter the
running state.
- (Troubleshooting) If your instance won’t boot, it is possible that one of the requirements for the new instance type was not met. For more information, see Why is my Linux instance not booting after I changed its type?
Migrating an instance store-backed instance
When you want to move your application from one instance store-backed instance to an instance store-backed instance with a different instance type, you must migrate it by creating an image from your instance, and then launching a new instance from this image with the instance type that you need. To ensure that your users can continue to use the applications that you’re hosting on your instance uninterrupted, you must take any Elastic IP address that you’ve associated with your original instance and associate it with the new instance. Then you can terminate the original instance.
To migrate an instance store-backed instance
- Back up any data on your instance store volumes that you need to keep to persistent storage. To migrate data on your EBS volumes that you need to keep, take a snapshot of the volumes (see Creating Amazon EBS snapshots) or detach the volume from the instance so that you can attach it to the new instance later (see Detaching an Amazon EBS volume from a Linux instance).
- Create an AMI from your instance store-backed instance by satisfying the prerequisites and following the procedures in Creating an instance store-backed Linux AMI. When you are finished creating an AMI from your instance, return to this procedure.
- Open the Amazon EC2 console and in the navigation pane, choose AMIs. From the filter lists, choose Owned by me, and choose the image that you created in the previous step. Notice that AMI Name is the name that you specified when you registered the image and Source is your Amazon S3 bucket.
Note
If you do not see the AMI that you created in the previous step, make sure that you have selected the Region in which you created your AMI.
- Choose Launch. When you specify options for the instance, be sure to select the new instance type that you want. If the instance type that you want can’t be selected, then it is not compatible with configuration of the AMI that you created (for example, because of virtualization type). You can also specify any EBS volumes that you detached from the original instance.It can take a few minutes for the instance to enter the
running state.
- (Optional) You can terminate the instance that you started with, if it’s no longer needed. Select the instance and verify that you are about to terminate the original instance, not the new instance (for example, check the name or launch time). Choose Actions, Instance State, Terminate.
Migrating to a new instance configuration
If the current configuration of your instance is incompatible with the new instance type that you want, then you can’t resize the instance to that instance type. Instead, you can migrate your application to a new instance with a configuration that is compatible with the new instance type that you want.
If you want to move from an instance launched from a PV AMI to an instance type that is HVM only, the general process is as follows:
To migrate your application to a compatible instance
- Back up any data on your instance store volumes that you need to keep to persistent storage. To migrate data on your EBS volumes that you need to keep, create a snapshot of the volumes (see Creating Amazon EBS snapshots) or detach the volume from the instance so that you can attach it to the new instance later (see Detaching an Amazon EBS volume from a Linux instance).
- Launch a new instance, selecting the following:
- An HVM AMI.
- The HVM only instance type.
- If you are using an Elastic IP address, select the VPC that the original instance is currently running in.
- Any EBS volumes that you detached from the original instance and want to attach to the new instance, or new EBS volumes based on the snapshots that you created.
- If you want to allow the same traffic to reach the new instance, select the security group that is associated with the original instance.
- Install your application and any required software on the instance.
- Restore any data that you backed up from the instance store volumes of the original instance.
- If you are using an Elastic IP address, assign it to the newly launched instance as follows:
- In the navigation pane, choose Elastic IPs.
- Select the Elastic IP address that is associated with the original instance and choose Actions, Disassociate address. When prompted for confirmation, choose Disassociate address.
- With the Elastic IP address still selected, choose Actions, Associate address.
- From Instance, select the new instance, and then choose Associate.
- (Optional) You can terminate the original instance if it’s no longer needed. Select the instance and verify that you are about to terminate the original instance, not the new instance (for example, check the name or launch time). Choose Actions, Instance State, Terminate.
https://aws.amazon.com/premiumsupport/knowledge-center/resize-instance/
What steps do I need to take before changing the instance type of my EC2 Linux instance?
My system requires more CPU or memory than is available on my current Amazon Elastic Compute Cloud (Amazon EC2) instance. What steps do I take before resizing my instance to be sure that the transition is successful?
Short description
Changing the instance type of your EC2 Linux instance allows you to change the following:
- Number of CPU cores
- Amount of RAM
- Amazon Elastic Block Store (Amazon EBS) optimization
- Enhanced networking
- GPU cores
Before changing instance types or instance families, verify if the current instance type and the new instance type are compatible.
Resolution
The following common issues cause compatibility problems when changing instance types. To be sure that your instance type change is successful, be sure that you review these areas. For a full list of compatibility issues, see Compatibility for resizing instances.
After you’ve verified compatibility, you can resize your Amazon EBS-backed instance.
Stop your instance
You must stop your instance before you change instance types. Before stopping your instance, be sure you understand the following:
- If your instance is instance store-backed or has instance store volumes containing data, the data is lost when you stop the instance. If you are moving from one instance store-backed instance to another instance store-backed instance, you must migrate your instance store-backed instance. For more information, see Migrating an instance store-backed instance.
- If your instance is part of an Amazon EC2 Auto Scaling group, stopping the instance may terminate the instance. If you launched the instance with Amazon EMR, AWS CloudFormation, or AWS Elastic Beanstalk, your instance might be part of an AWS Auto Scaling group. Instance termination in this scenario depends on the instance scale-in protection settings for your Auto Scaling group. If your instance is part of an Auto Scaling group, then temporarily remove the instance from the Auto Scaling group before starting the resolution steps.
- If you’re not using an Elastic IP address, stopping and starting the instance changes the public IP address of your instance. It’s a best practice to use an Elastic IP address instead of a public IP address when routing external traffic to your instance. If you are using Route 53, you might have to update the Route 53 DNS records when the public IP changes.
Back up your data
It’s a best practice to maintain backups of your instances and data. Consider creating an AMI or creating snapshots of your EBS volumes before you change your infrastructure.
Enhanced networking
If you’re converting to an instance that supports enhanced networking, be sure that you install any required drivers and enable enhanced networking on your current instance. For more information, see Enhanced networking on Linux.
Nitro-based instance types
Before changing your instance to a Nitro-based instance type, check that the NVMe and ENA modules are installed on your instance and that any block devices listed in /etc/fstab are compatible with NVMe block device names (/dev/nvme1, /dev/nvme2, and so on). To automate these checks, run the NitroInstanceChecks script. For more information, see Why is my Linux instance not booting after I changed its type to a Nitro-based instance type and follow the instructions in the Run the NitroInstanceChecks script section.
After the script runs and you’ve made necessary updates, verify that the DRIVERS entry in /etc/udev/rules.d/70-persistent-net.rules is set to ? or ENA.
Use a text editor to access the file. The following example uses the vi editor.
vi /etc/udev/rules.d/70-persistent-net.rules
The correct entry appears as follows:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="01:23:45:67:89:ab", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0
Networking on current generation instances
Current generation instances launch only in a virtual private cloud (VPC). If your current instance is an EC2-Classic instance, then migrate the instance to a Linux instance in a VPC.
