Feature Request: EC2 Instance Type Compatibility Matrix for Stop/Start Operations Across Families

Question

Hello AWS team and community,

I’d like to see a public compatibility matrix that clearly answers:
Can I stop an EC2 instance of type X and start it again as type Y — without AMI, driver, or OS-level boot failures?

🚀 What I’m Looking For:
A matrix or tool that can answer this in a simple Yes/No format, like:

* From Instance	To Instance	Compatible?	Notes
* r6i.large	r7i.large	✅ Yes	Both x86_64, Nitro, ENA/NVMe supported
* m4.large	m5.large	⚠️ Maybe	Requires ENA + NVMe drivers in AMI
* t3.micro	c7g.medium	❌ No	x86_64 → ARM not supported

🔍 Why This Is Important:
Avoids trial-and-error when changing instance families
Helps with automation, cost optimization, and right-sizing
Prevents downtime from failed boots due to architecture, ENA, NVMe, or hypervisor mismatches

📘 Ideal Implementation Options:
A public EC2 compatibility matrix (CSV or JSON)

AWS CLI command like:
"aws ec2 check-instance-compatibility --source m5.large --target m7a.large"
Or an enhancement to the AWS Console’s “Change Instance Type” dropdown

⚙️ Compatibility Factors to Consider:
* CPU architecture: x86_64 vs ARM (Graviton)
* ENA requirement
* NVMe support
* Hypervisor: Nitro vs Xen
* Boot device naming (e.g., /dev/xvda vs nvme0n1)
* Instance store presence or absence

Request:
Please consider this as a feature request. This simple compatibility view would save time for architects, admins, and operations teams managing EC2 fleets.

Thank you!

re:Post Agent · Answer

Thank you for your feature request regarding an EC2 Instance Type Compatibility Matrix for Stop/Start Operations Across Families. This is an interesting proposal that could indeed be valuable for AWS users managing EC2 fleets.

Currently, AWS does not provide a comprehensive public compatibility matrix exactly as you've described. However, there are existing resources and best practices that can help address some of the concerns you've raised.

When changing instance types, especially across different families, there are several factors to consider:

1. CPU Architecture: Changing between x86 (Intel/AMD) and ARM (Graviton) architectures is not supported without creating a new AMI.

2. Virtualization Type: Instances using paravirtual (PV) virtualization cannot be changed to hardware virtual machine (HVM) types and vice versa.

3. Network Adapters: Changing to an instance type that uses a different network adapter may require reconfiguration and potentially local administrator permissions.

4. Enhanced Networking: If moving to an instance type that supports enhanced networking, the necessary drivers (ENA or ixgbevf) must be installed.

5. NVMe: When changing to a Nitro-based instance type that uses NVMe for EBS volumes, the appropriate NVMe drivers must be installed, and file systems should be mounted using UUID/Label instead of device names.

6. Volume Limits: The new instance type must support at least the same number of EBS volumes as currently attached.

7. NitroTPM: If NitroTPM is enabled, you can only change to instance types that also support NitroTPM.

While a comprehensive matrix or tool as you've described doesn't currently exist, you can use the AWS CLI or SDKs to programmatically check instance type details and compare specifications. Additionally, thoroughly testing any instance type changes in a non-production environment is always recommended.

Your suggestion for an AWS CLI command to check instance compatibility is an interesting idea that could potentially simplify this process. Similarly, enhancing the AWS Console's "Change Instance Type" feature with more detailed compatibility information could be beneficial.

AWS regularly updates and introduces new instance types, so maintaining an up-to-date compatibility matrix would require ongoing effort. However, your request for a more user-friendly way to determine instance type compatibility is noted and could be valuable for many AWS users.

In the meantime, it's advisable to carefully review the specifications of both the current and target instance types, create AMI backups before making changes, and test thoroughly in non-production environments when changing instance types, especially across different families.  
**Sources**  
[Change EC2 instance type across family and hypervisor | AWS re:Post](https://repost.aws/knowledge-center/ec2-change-instance-type-family-hypervisor)  
[Compatibility for changing the instance type - Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/resize-limitations.html)  
[Compatibility and Potential Issues when Changing EC2 Instance Type from t3.xlarge to t3a.2xlarge | AWS re:Post](https://repost.aws/questions/QUXOvaX33lTcmdj5zKz8sI1g/compatibility-and-potential-issues-when-changing-ec2-instance-type-from-t3-xlarge-to-t3a-2xlarge)

Feature Request: EC2 Instance Type Compatibility Matrix for Stop/Start Operations Across Families

Add your answer

Relevant content