Explanation
Why the waste happens and who it affects.
They remain fully supported, so nothing forces a migration, and long-lived instances, AMIs, launch templates and infrastructure-as-code modules keep them running for years. AWS itself encourages moving to current generation types to get the best performance.
The cost problem is price-performance. A previous generation instance is billed at its own hourly rate, but it typically delivers less compute, memory bandwidth, network and EBS performance than a current generation equivalent, so the same spend buys less work and workloads end up on larger sizes or more instances than necessary. Some older families (C1, C3, I2, M1, M2, M3 and R3) are not EBS-optimized by default and charge an additional hourly fee to enable it. AWS Cost Optimization Hub reports this as an Upgrade recommendation for EC2 instances and Auto Scaling groups.
Billing model
The pricing dimensions that drive this cost.
- Instance-hour rate
- Each instance type has its own On-Demand, Spot and Reserved rate; previous generation types stay billable at their own rates indefinitely
- EBS-optimized fee
- For C1, C3, I2, M1, M2, M3 and R3, EBS optimization is optional and billed as an additional hourly fee
- Commitments
- Reserved Instances and EC2 Instance Savings Plans are tied to an instance family, so coverage bought for an old family does not follow a move to a new one
How to detect
5 checks to find it in your estate.
- Inventory running instances and compare their families with the Amazon EC2 previous generation instances list
- Check launch templates, launch configurations, Auto Scaling groups and IaC defaults for previous generation instance types, since they will keep launching new capacity on old families
- Review Cost Optimization Hub recommendations with the Upgrade action for EC2 instances and EC2 Auto Scaling groups; the recommendation notes whether a hypervisor change is involved
- Review AWS Compute Optimizer EC2 recommendations: even for instances classified as Optimized it may recommend a newer generation type, and the Platform differences column shows hypervisor, network interface, storage interface and virtualization type changes to plan for
- Flag previous generation instances that have EBS optimization enabled as a paid add-on
How to fix
5 ways to remove the waste.
- Stop the EBS-backed instance, change the instance type to a current generation equivalent, and start it again; test the workload afterward, because some changes can alter performance characteristics
- Before moving from a Xen-based family to a Nitro-based family, install the ENA and NVMe drivers, and on Linux mount file systems in /etc/fstab by UUID or label, since EBS volumes appear as NVMe devices on Nitro
- If the instance was launched from a paravirtual (PV) AMI or uses a 32-bit AMI, plan a migration to a new HVM, 64-bit instance, because the instance type cannot simply be changed
- Update launch templates, Auto Scaling groups and IaC modules so that new capacity launches on current generation types
- Align commitments with the new family: exchange Convertible Reserved Instances, let family-specific commitments expire, or rely on Compute Savings Plans, which are not tied to an instance family
Documentation
Vendor references for pricing and configuration.