Running EC2 instances on pre-Nitro families such as t2, m4 and c4 that have a cheaper Nitro successor

Older instance families pay more for less

AWS lists the families built on the Nitro System on its Nitro instances page. M5, C5, R5 and T3 appear there as Nitro v2 families, and the Nitro generations bring enhanced networking through the Elastic Network Adapter (ENA) and EBS volumes exposed as NVMe devices. Families such as T2, M4, C4 and R4 are not on that list. They predate Nitro, and AWS’s own compatibility notes use T2 to M4 and M4 to M5 as examples of moves between network adapters.

That is the case this rule looks for. It is not a performance lecture; it only speaks up when the newer family is also cheaper, so the change pays for itself.

Finding pre-Nitro instances in a Region

List running instances in the older families, then compare each type with its successor:

aws ec2 describe-instances \
  --filters Name=instance-state-name,Values=running \
            Name=instance-type,Values='t2.*','m4.*','c4.*','r4.*','m3.*','c3.*','r3.*' \
  --query 'Reservations[].Instances[].[InstanceId,InstanceType]' \
  --output table

aws ec2 describe-instance-types --instance-types m4.large m5.large \
  --query 'InstanceTypes[].[InstanceType,Hypervisor,NetworkInfo.EnaSupport]'

The Hypervisor field reads nitro for Nitro-based types, and the ENA column shows whether the type supports enhanced networking with ENA.

Which instances qualify

• The instance is running. Stopped instances bill no compute, so a type change saves nothing.
• Its family is on ZopNight’s pre-Nitro list: t2, m3, m4, c3, c4, r3, r4, d2, g3, p2, x1, f1, h1, i2 and i3. The one exception is i3.metal, which already runs on Nitro and is skipped.
• A named same-size successor exists, for example m4 to m5, c4 to c5, r4 to r5, t2 to t3, d2 to d3, g3 to g4dn and x1 to x2idn. F1, H1 and P2 have no successor on the list, so they never produce a finding.
• ZopNight has a monthly cost for the instance and on-demand rates for both the current and the target type.

When a pre-Nitro instance gets no recommendation

If the successor’s hourly rate is equal to or higher than the current one, nothing is raised. The same happens when either rate is missing from ZopNight’s price data. The rule never falls back to a flat percentage, and it never proposes an ARM (Graviton) type here: every successor on its list is an x86 family.

Pricing the family swap

saving = monthly instance cost x (1 - successor hourly rate / current hourly rate)

Treat the performance and security gain as the main reason and the dollar figure as proof that the move does not cost more.

Moving an instance to its Nitro successor

1. Confirm the AMI has ENA and NVMe drivers. AWS’s compatibility notes say Nitro-based instances require EBS-backed AMIs with ENA drivers, and that EBS device names change to /dev/nvme* names, so /etc/fstab should mount by UUID or label.
2. Stop the instance: aws ec2 stop-instances --instance-ids i-0123456789abcdef0
3. Change the type: aws ec2 modify-instance-attribute --instance-id i-0123456789abcdef0 --instance-type Value=m5.large
4. Start it again with aws ec2 start-instances and check the application, network throughput and disk mounts.