AWS compute pricing is not a single choice between “cheap” and “expensive.” On-Demand, Savings Plans, Reserved Instances, and Spot Instances exchange different kinds of flexibility for different kinds of savings. The right model depends on whether usage is steady, whether the application can be interrupted, whether the organization is willing to make a time commitment, and whether capacity must be reserved in a particular Availability Zone.
Those trade-offs are part of the cloud economics behind AWS Certified Cloud Practitioner CLF-C02 and become architectural inputs for AWS Solutions Architect – Associate SAA-C03. The useful question is not “Which pricing option has the biggest discount?” It is “Which obligation can this workload safely accept in exchange for a lower effective rate?”
On-Demand is the flexibility baseline
On-Demand Instances let you run EC2 capacity without a long-term usage commitment. For many common operating systems, EC2 bills eligible instance usage by the second, subject to service-specific minimums and rules. This is the cleanest model for new workloads, short-lived environments, uncertain demand, migrations that are still being measured, and systems whose future instance family or Region is not yet known.
The premium you pay for On-Demand is flexibility. There is no one- or three-year commitment to consume a particular level of compute. That makes it useful during discovery and change, but a stable fleet that runs all day can leave meaningful savings unused if it stays entirely On-Demand after its baseline becomes predictable.
On-Demand also provides a reference price against which discounts are usually discussed. Cost optimization therefore starts by measuring the stable portion of usage instead of immediately trying to commit every instance. Variable peaks, experiments, and newly launched services can remain On-Demand while predictable baseline demand is covered by a discount model.
Savings Plans trade a usage commitment for pricing flexibility
Savings Plans reduce eligible usage prices in exchange for committing to a consistent amount of usage, measured in dollars per hour, for a defined term. For EC2, the two most relevant forms are Compute Savings Plans and EC2 Instance Savings Plans. Compute Savings Plans provide broader flexibility across instance families, sizes, operating systems, tenancy choices, Regions, and even eligible Fargate and Lambda usage. EC2 Instance Savings Plans are narrower because they are tied to an instance family in a chosen Region, but can offer a deeper discount.
The important design characteristic is that a Savings Plan is a spend commitment, not an instance reservation. If the organization commits to an hourly amount and then uses less eligible capacity, the unused commitment is still paid. If eligible usage exceeds the commitment, the excess falls back to applicable On-Demand pricing. Good purchases therefore cover a durable baseline rather than optimistic peak demand.
A currentness detail matters in 2026: AWS now describes four Savings Plans families—Compute, EC2 Instance, Database, and SageMaker AI Savings Plans. Database Savings Plans were introduced in late 2025 and cover eligible database usage under their own rules. That change means older material that says AWS offers only two or three Savings Plans types is stale. For EC2 architecture, however, Compute and EC2 Instance Savings Plans remain the central choices.
Reserved Instances are still valid, but they are a more configuration-oriented commitment
Reserved Instances, or RIs, also reduce EC2 cost for committed usage over a one- or three-year term, but they are built around instance configuration attributes rather than a general hourly spend commitment. AWS documentation now describes RIs as an older purchasing option and encourages many customers to use Savings Plans as RIs expire because Savings Plans can provide similar discount economics with more flexibility.
That does not make every RI irrelevant. Existing organizations may have established RI processes, and certain capacity-planning situations still require understanding the distinction between pricing and capacity. A Regional RI provides a billing discount within its scope but does not itself reserve capacity in a specific Availability Zone. A Zonal RI can include a capacity reservation for the specified AZ and configuration. On-Demand Capacity Reservations are another separate mechanism for holding capacity and can, in supported cases, be covered by qualifying discounts.
The architecture lesson is to avoid treating “Reserved Instance” as a synonym for “guaranteed capacity” or “cheaper EC2.” Pricing benefit, placement flexibility, and capacity reservation are related but separate dimensions.
Spot exchanges interruption tolerance for the largest variable discount
Spot Instances use spare EC2 capacity and can be available at a steep discount compared with On-Demand prices. The trade-off is interruption: AWS can reclaim Spot capacity when it is needed elsewhere. Spot is therefore a workload design choice, not merely a billing choice.
Good Spot candidates can lose individual instances without losing the job. Batch processing, data transformation, CI/CD workers, rendering, stateless horizontal services, and distributed analytics can often retry work or replace capacity. Checkpointing, queue-based work distribution, multiple instance types, multiple Availability Zones, and Auto Scaling make the application less dependent on any one Spot pool.
Bad Spot candidates are systems that assume an instance will remain available, cannot resume work, or have a stateful single point of failure. A database can technically run on many kinds of EC2 capacity, but placing a unique production database node on interruptible capacity without a resilient design would turn a pricing optimization into an availability risk.
Do not buy commitments before understanding the workload shape
The most reliable sequence is measure first, segment second, commit third. Start with actual usage and identify a baseline that persists across days and business cycles. Separate always-on production demand from burst demand, dev/test schedules, seasonal peaks, and fault-tolerant batch work. Then choose the pricing model that matches each segment.
A common pattern is a blended fleet. A predictable baseline is covered by Savings Plans. Uncertain growth or temporary demand stays On-Demand. Fault-tolerant jobs use Spot. Capacity Reservations are added only where capacity assurance in a specific AZ matters. This is more robust than forcing the entire fleet into one pricing instrument.
Real cost also includes attached services. Storage, data transfer, load balancing, logging, snapshots, and software licensing can materially affect the bill even when EC2 compute is discounted. That broader perspective is important when evaluating the real cost of running workloads on AWS.
Commitment flexibility matters as much as discount percentage
Suppose a platform team knows it will consume a large amount of compute for three years but expects to change instance families and possibly Regions as architectures evolve. A broad Compute Savings Plan can align with that uncertainty better than a narrow configuration commitment. If a specific EC2 family in one Region is extremely stable, an EC2 Instance Savings Plan may fit better. If the organization has an established RI portfolio, it should manage that portfolio as a commitment inventory rather than renewing automatically out of habit.
The same reasoning applies to term length and payment choices. A longer commitment or larger upfront payment can improve the effective discount, but it also increases financial lock-in. The best economic result is not the highest advertised percentage; it is high utilization of a commitment that still permits the architecture to change when the business changes.
Spot and commitments solve different parts of the cost problem
Savings Plans and RIs reduce the price of predictable eligible usage. Spot reduces the price of interruptible capacity. They therefore belong to different workload segments. Trying to compare Spot’s potential discount directly with a Savings Plan can be misleading because Spot also changes the reliability contract of the instance.
A well-designed Auto Scaling group can mix purchasing models, keeping stable capacity on non-interruptible instances while adding Spot for elastic portions. Batch platforms can be even more aggressive because work is queued and retried. The design should define what happens when Spot disappears before the finance team counts the savings.
Similarly, a commitment should be sized against observed baseline usage rather than total theoretical capacity. Buying a commitment for the peak defeats its purpose if that peak appears only briefly. The excess can remain flexible until the utilization pattern proves durable.
Another reason to separate these models is accounting ownership. Engineering can identify which capacity is technically interruptible, but finance and procurement still need visibility into commitment utilization and expiration dates. A Savings Plan that was sensible at purchase time can become underutilized after a migration, just as an RI portfolio can drift away from the fleet it was intended to cover. Cost optimization therefore needs both workload telemetry and commitment reporting. The pricing instrument should follow the architecture, and the architecture team should know when a financial commitment limits future change.
A decision sequence keeps pricing aligned with architecture
Use On-Demand when demand is new, short-lived, highly variable, or needs maximum freedom. Use Savings Plans when the organization can make an hourly usage commitment and wants discount coverage with the flexibility appropriate to the selected plan type. Use RIs where their configuration model, existing portfolio, or capacity characteristics are specifically useful. Use Spot only where interruption is an accepted and engineered behavior.
Then revisit the decision periodically. Instance families change, applications move to containers or serverless services, traffic patterns shift, and AWS adds pricing models—as the arrival of Database Savings Plans demonstrated. Cloud economics is therefore an operating discipline, not a one-time procurement event. The right mix is the one that keeps commitments highly utilized while preserving enough technical flexibility for the workload to evolve.