Replace the root volume for an Amazon EC2 instance without stopping it
Amazon EC2 enables you to replace the root Amazon EBS volume for a running instance while retaining the following:
-
Data stored on instance store volumes — Instance store volumes remain attached to the instance after the root volume has been restored.
-
Data stored on data (non-root) Amazon EBS volumes — Non-root Amazon EBS volumes remain attached to the instance after the root volume has been restored.
-
Network configuration — All network interfaces remain attached to the instance and they retain their IP addresses, identifiers, and attachment IDs. When the instance becomes available, all pending network traffic is flushed. Additionally, the instance remains on the same physical host, so it retains its public and private IP addresses and DNS name.
-
IAM policies — IAM profiles and policies (such as tag-based policies) that are associated with the instance are retained and enforced.
How root volume replacement works
When you replace the root volume for an instance, we create root volume replacement task. The original root volume is detached from the instance, and the new root volume is attached to the instance in its place. The instance's block device mapping is updated to reflect the ID of the replacement root volume.
When you replace the root volume for an instance, you must specify the source of the snapshot for the new volume. The following are the possible options.
This option replaces the current root volume with a volume that is based on the snapshot that was used to create it.
Considerations for using the launch state
The replacement root volume gets the same type, size, and delete on termination attributes as the original root volume.
This option replaces the current root volume with a replacement volume that is based on the snapshot that you specify. For example, a specific snapshot that you previously created from this root volume. This is useful if you need to recover from issues caused by corruption of the root volume or network configuration errors in the guest operating system.
The replacement root volume gets the same type, size, and delete on termination attributes as the original root volume.
Considerations for using a snapshot
-
You can only use snapshots that belong to the same lineage as the current root volume.
-
You can't use snapshot copies created from snapshots that were taken from the root volume.
-
After successfully replacing the root volume, you can still use snapshots taken from the original root volume to replace the new (replacement) root volume.
This option replaces the current root volume using an AMI that you specify. This is useful if you need to perform operating system and application patching or upgrades. The AMI must have the same product code, billing information, architecture type, and virtualization type as the instance.
If the instance is enabled for ENA or sriov-net, then you must use an AMI that supports those features. If the instance is not enabled for ENA or sriov-net, then you can either select an AMI that doesn't include support for those features, or you can automatically add support if you select an AMI that supports ENA or sriov-net.
If the instance is enabled for NitroTPM, then you must use an AMI that has NitroTPM enabled. NitroTPM support is not enabled if the instance was not configured for it, regardless of the AMI that you select.
You can select an AMI with a different boot mode than that of the instance, as long as the instance supports the boot mode of the AMI. If the instance does not support the boot mode, the request fails. If the instance supports the boot mode, the new boot mode is propagated to the instance and its UEFI data is updated accordingly. If you manually modified the boot order or added a private UEFI Secure Boot key to load private kernel modules, the changes are lost during root volume replacement.
The replacement root volume gets the same volume type and delete on termination attribute as the original root volume, and it gets the size of the AMI root volume block device mapping.
Note
The size of the AMI root volume block device mapping must be equal to or greater than the size of the original root volume. If the size of the AMI root volume block device mapping is smaller than the size of the original root volume, the request fails.
After the root volume replacement task completes, the following new and updated information is reflected when you describe the instance using the console, AWS CLI or AWS SDKs:
-
New AMI ID
-
New volume ID for the root volume
-
Updated boot mode configuration (if changed by the AMI)
-
Updated NitroTPM configuration (if enabled by the AMI)
-
Updated ENA configuration (if enabled by the AMI)
-
Updated sriov-net configuration (if enabled by the AMI)
The new AMI ID is also reflected in the instance metadata.
Considerations for using an AMI:
-
If you use an AMI that has multiple block device mappings, only the root volume of the AMI is used. The other (non-root) volumes are ignored.
-
You can only use this feature if you have permissions to the AMI and its associated root volume snapshot. You cannot use this feature with AWS Marketplace AMIs.
-
You can only use an AMI without a product code only if the instance does not have a product code.
-
The size of the AMI root volume block device mapping must be equal to or greater than the size of the original root volume. If the size of the AMI root volume block device mapping is smaller than the size of the original root volume, the request fails.
-
The instance identity documents for the instance are automatically updated.
-
If the instance supports NitroTPM, the NitroTPM data for the instance is reset and new keys are generated.
You can choose whether to keep the original root volume after the root volume replacement process has completed. If you choose delete the original root volume after the replacement process completes, the original root volume is automatically deleted and becomes unrecoverable. If you choose to keep the original root volume after the process completes, the volume remains provisioned in your account; you must manually delete the volume when you no longer need it.
The root volume replacement task transitions through the following states:
-
pending— The replacement volume is being created. -
in-progress— The original volume is being detached and the replacement volume is being attached. -
succeeded— The replacement volume has been successfully attached to the instance and the instance is available. -
failing— The replacement task is in the process of failing. -
failed— The replacement task has failed, but the root volume is still attached. -
failing-detached— The replacement task is in the process of failing and the instance might not have a root volume attached. -
failed-detached— The replacement task has failed and the instance doesn't have a root volume attached.
If the root volume replacement task fails, the instance is rebooted and the original root volume remains attached to the instance.
Considerations
Before you begin, consider the following.
Requirements
-
The instance must be in the
runningstate. -
The instance is automatically rebooted during the process. The contents of the memory (RAM) is erased during the reboot. No manual reboots are required.
-
You can't replace the root volume if it is an instance store volume. Only instances with Amazon EBS root volumes are supported.
-
You can replace the root volume for all virtualized instance types and EC2 Mac bare metal instances. No other bare metal instance types are supported.
-
You can use any snapshot that belongs to the same lineage as any of the instance's previous root volumes.
-
If your account is enabled for Amazon EBS encryption by default in the current Region, the replacement root volume created by the root volume replacement task is always encrypted, regardless of the encryption status of the specified snapshot or the root volume of the specified AMI.
Encryption outcomes
The following table summarizes the possible encryption outcomes.
| Original root volume | Specified snapshot or AMI | Encryption by default | Replacement root volume | Encryption key used for replacement root volume | |
|---|---|---|---|---|---|
| Restore replacement root volume to initial launch state | Encrypted | Not applicable | Not considered | Encrypted | Same KMS key as original root volume |
| Unencrypted | Not applicable | Disabled | Unencrypted | Not applicable | |
| Unencrypted | Not applicable | Enabled | Encrypted | Account's default KMS key for Amazon EBS encryption | |
| Restore replacement root volume from snapshot or AMI | Encrypted | Unencrypted | Not considered | Encrypted | Same KMS key as original root volume |
| Encrypted | Encrypted | Not considered | Encrypted | Same KMS key as original root volume | |
| Unencrypted | Unencrypted | Disabled | Unencrypted | Not applicable | |
| Unencrypted | Unencrypted | Enabled | Encrypted | Account's default KMS key for Amazon EBS encryption | |
| Unencrypted | Encrypted | Not considered | Encrypted | If the AMI or snapshot is owned by the account, the replacement volume is encrypted with the AMI or snapshot’s KMS key. If AMI or snapshot is shared with the account, replacement volume is encrypted with the account's default KMS key for Amazon EBS encryption. |
Replace a root volume
When you replace the root volume for an instance, a root volume replacement task is created. You can use the root volume replacement task to monitor the progress and outcome of the replacement process.
