Previous-generation EC2 families (such as m3, m4, c3, c4, t2, r3, and r4) often have modern equivalents with better price-performance. This finding flags running instances on those older families where Parsivex identifies a recommended replacement type.
This is different from oversized EC2 findings, which compare CPU utilization against the current instance size, and from idle EC2 findings, which flag near-zero utilization regardless of generation.
Before you change the instance type
- Verify the recommended modern type supports your required architecture (ARM vs x86), EBS optimization, and enhanced networking settings.
- Stop the instance before changing type unless you use a type that supports modification while stopped only — most generation jumps require a stop/start cycle.
- Test application compatibility in a non-production environment when moving across families (for example t2 to t3, or m4 to m6i).
- Update Auto Scaling launch templates, Terraform, or CloudFormation definitions so the instance is not reverted on the next deploy.
Paid plans include remediation scripts with stop, modify-instance-attribute, and start commands. Plan for brief downtime during the change.
What triggers this finding
A running EC2 instance on a previous-generation family (e.g. m3, m4, c3, c4, t2, r3, r4) where a modern equivalent instance type is available at lower cost.
Typical fix
Migrate to the recommended modern instance type. Stop the instance, change the type, then start and verify application compatibility.
Example savings
Often 10–30% of instance cost — varies by family and size.
See also: Severity and savings estimates for how Parsivex calculates figures on your report.
Why the older family costs more
AWS prices each instance family at launch and rarely reprices it afterwards. Newer families arrive on cheaper hardware and are listed at a lower rate, and the older listing simply stays where it is. The result is an unusual situation in cloud pricing: the upgrade is not a trade-off between cost and performance, it is cheaper and faster, and the only reason to still be on the old family is that nobody has moved.
The gaps are modest per instance and meaningful per fleet. At the us-east-1 Linux on-demand rates Parsivex prices against, m4.xlarge runs $146.00 a month against $138.24 for m5.xlarge; t2.large is $67.74 against $60.74 for t3.large; r3.xlarge is $243.09 against $182.50 for r5.xlarge. The r3 and m3 generations are where the real money sits, because they predate two hardware refreshes rather than one.
Parsivex maps t2 to t3, m3 and m4 to m5, c3 and c4 to c5, and r3 and r4 to r5, holding the size suffix constant. A pair is only reported when both types are priced and the modern one is strictly cheaper, so the finding never proposes a change that costs money. Findings worth more than $50 a month are raised to high severity; the rest are medium.
Confirming which families you are running
aws ec2 describe-instances \
--filters Name=instance-state-name,Values=running \
--query 'Reservations[].Instances[].[InstanceId,InstanceType,Placement.AvailabilityZone]' \
--output table
Anything whose family prefix is t2, m3, m4, c3, c4, r3, or r4 is in scope. Stopped instances are not — the detector only reads running instances, since a stopped instance is not accruing the hourly rate the saving is measured against.
Reasons the move is not free
The recommended type is always a same-size, same-architecture x86 equivalent, so the change is usually mechanical. Three things make it otherwise, and all three are worth checking before a maintenance window is booked.
The Nitro boundary. The m5, c5, and r5 families run on the Nitro system and require ENA networking and NVMe block-device support in the guest. A current Amazon Linux, Ubuntu, or Windows AMI has both. An image that has been carried forward since the m3 era may have neither, in which case the instance starts and is simply unreachable. This is the single most common cause of a failed generation jump.
Instance-store disks. The m3, c3, and r3 families include local instance-store volumes. Their modern equivalents do not. If anything on the host writes to ephemeral local disk, that storage has to be replaced with EBS before the move, and the EBS cost eats into the saving.
Burstable credit behaviour. t2 and t3 both bank CPU credits, but t3 defaults to unlimited mode, which bills a surcharge for sustained bursting rather than throttling to baseline. On a workload that regularly exhausts its credits, a t2 to t3 move can raise the bill even though the hourly rate fell. Check the credit balance metrics, or set the target to standard mode.
Reserved Instances and Savings Plans are the other reason to pause. The estimate here is pure on-demand arithmetic and knows nothing about your commitments. If a Reserved Instance is already covering the m4 fleet, moving to m5 strands that reservation and the net effect is a loss until it expires. Size-flexible regional Reserved Instances do not transfer across families.
What the change costs
The instance must be stopped to change its type, so plan for a short interruption, the loss of any instance-store data, and a new auto-assigned public IPv4 address. The step itself is reversible in both directions. What is not reversible by default is the definition drift described on the oversized EC2 page — update the launch template, Auto Scaling configuration, or infrastructure code in the same change, or the next deploy quietly restores the older family and the saving with it.