When engineering leaders look at their AWS bills, Amazon EC2 compute usually dominates. To reduce these costs, AWS offers two primary commitment-based discount models: Reserved Instances (RIs) and Savings Plans (SPs). While both require a 1- or 3-year commitment in exchange for up to 72% discounts, picking the wrong one for your architecture can result in thousands of dollars in wasted spend.
Reserved Instances commit you to a specific instance configuration. You are reserving a "slot" (e.g., an m5.xlarge Linux instance in us-east-1a). If your workload changes and you no longer need that exact instance, you are still paying for it.
Savings Plans commit you to a consistent monetary spend (e.g., $10/hour). In exchange, any compute usage up to that $10/hr is billed at a heavily discounted rate. Computes Savings Plans are incredibly flexible, automatically applying across EC2, Fargate, and Lambda, regardless of region or instance family.
Scenario: A mid-sized SaaS company purchased 3-year Standard RIs for a fleet of 50 c5.2xlarge instances to run their core monolith application.
The Issue: 18 months into the commitment, the engineering team successfully refactored the monolith into microservices running on AWS Fargate and AWS Lambda. They also discovered that c6i instances offered 15% better price-performance for their remaining databases.
The Outcome: Because they bought Standard RIs, they were locked in. They could not apply their C5 reservations to Fargate, Lambda, or the new C6i instances. They had to continue paying for the RIs they were no longer using while simultaneously paying On-Demand prices for their new Fargate usage, effectively doubling their compute bill during the transition phase. This phenomenon is known as "underutilization risk."
Despite their rigidity, RIs still have a place in modern architectures. Standard RIs offer the highest absolute discount tier, and more importantly, Zonal RIs provide a Capacity Reservation. Savings Plans strictly provide billing discounts but do not guarantee that AWS will have the physical servers available when you try to launch them in a specific Availability Zone.
Scenario: A healthcare provider operates a massive, monolithic Oracle database on an r6i.16xlarge instance. Due to strict compliance and extreme latency requirements, they know this database will not be modernized to a managed service or distributed architecture for at least the next 3 years.
The Solution: The company correctly chose a 3-year Standard Reserved Instance tied to a specific Availability Zone. Not only did they secure the maximum possible discount, but the Zonal RI guaranteed capacity, ensuring they would never face a "InsufficientInstanceCapacity" error if they had to reboot or replace the host during a major availability zone event.
For 90% of modern cloud-native architectures, Savings Plans are the vastly superior choice. Compute Savings Plans offer unprecedented flexibility.
Scenario: An e-commerce platform relies on a mix of EC2 spot instances, on-demand EC2 for baseline load, and AWS Lambda for intermittent image processing. They frequently upgrade instance types as AWS releases new silicon (like Graviton processors).
The Solution: They purchased a 1-year Compute Savings Plan covering their baseline compute spend. As they incrementally migrated workloads from x86 EC2 instances to ARM-based Graviton (m6g) instances, and shifted batch jobs from EC2 to Fargate, the Savings Plan automatically applied the discount to the new compute types without any manual intervention or need to exchange reservations.
A common mistake with both models is over-committing. Companies often miscalculate their baseline usage by failing to account for seasonality or impending architecture efficiency improvements.
Never cover 100% of your current compute usage with commitments. Cloud architects recommend covering only 60-70% of your absolute minimum baseline compute with 1-year or 3-year Savings Plans. The remaining capacity should be handled via Auto-Scaling groups relying on On-Demand instances or heavily discounted Spot Instances.