AWS Spot vs Reserved vs Savings Plans: Enterprise Cost Strategy

Understanding the Three AWS Purchasing Models

AWS offers three distinct mechanisms for purchasing compute capacity below on-demand pricing. Each operates on a fundamentally different commercial logic. Understanding that logic — not just the headline discount percentages — is the prerequisite for building an effective enterprise cost strategy.

The on-demand baseline is deliberately expensive. AWS prices on-demand at a significant premium to encourage commitment. For enterprises spending $5M+ annually on AWS, running significant workloads on on-demand pricing is the equivalent of paying rack rate at a hotel every night for a year while your competitor has a corporate rate agreement. The savings are available — they require a structured purchasing strategy to access them.

Spot Instances: Maximum Savings, Specific Use Cases

Spot Instances are the highest-discount, highest-risk purchasing option in AWS. The risk is not financial — you don't pay for capacity that's reclaimed — it's operational. If your workload is not designed to handle interruption gracefully, Spot will create more problems than it solves. Most enterprises that "tried Spot and it didn't work" failed at workload selection, not technical implementation.

The key insight for enterprise Spot strategy is that interruption rates vary significantly by instance type and availability zone. Popular instance families like m5 and c5 are interrupted far more frequently than older generation families like m4 or less-in-demand families like m6g (Graviton-based). A well-implemented Spot strategy uses Spot Fleet or Auto Scaling Groups with multiple instance types and availability zones, so interruptions to one pool trigger automatic failover to another rather than job failure.

For enterprises running large ML training workloads, Spot is transformational. A typical deep learning training job on p3.8xlarge instances costs approximately $12.24/hour on-demand. The same instance on Spot often prices at $3–4/hour — a 65–75% reduction. A data science team running 100 GPU-hours of training per week is looking at annual savings exceeding $400,000 from Spot alone, on a single workload type. The key requirement: training frameworks must support checkpointing so that an interrupted job resumes from its last checkpoint rather than starting over.

Reserved Instances: The Right Baseline Coverage

Reserved Instances are the workhorse of enterprise AWS cost management. They deliver the deepest discounts for predictable, long-running compute workloads — production databases, persistent application servers, and any service that runs at consistent capacity 24/7. The commercial model is a commitment: you pay for capacity whether you use it or not. The discipline required is accurate workload forecasting.

AWS offers three RI payment options with different discount structures: All-Upfront (pay 100% upfront, highest discount, no monthly charge), Partial-Upfront (pay 50% upfront, lower discount, reduced monthly charge), and No-Upfront (no upfront payment, lowest discount, higher monthly charge). For enterprises with treasury flexibility, All-Upfront 3-year RIs on baseline production workloads deliver the best return — but the full financial analysis must account for the opportunity cost of upfront capital versus the monthly savings profile.

RI coverage is measured as the percentage of your EC2 usage hours that are covered by Reserved Instances. AWS Cost Explorer reports your RI coverage directly. The target for most enterprises should be 70–80% coverage of production workload hours — leaving 20–30% on flexible purchasing (Savings Plans or on-demand) to absorb capacity growth and workload variability. Enterprises that over-commit to RIs and then scale down end up with unused reservations they're paying for regardless.

Convertible Reserved Instances solve the instance family lock-in problem at the cost of a lower discount — typically 3–5 percentage points less than Standard RIs. For enterprises with active migration roadmaps from Intel to Graviton, or from traditional EC2 to containerised workloads, Convertible RIs provide the flexibility to change instance attributes (type, OS, tenancy) during the commitment term. Standard RIs offer higher discounts but cannot be exchanged once purchased.

Savings Plans: Flexibility vs. Commitment

AWS Savings Plans, introduced in 2019, were designed to simplify commitment purchasing by replacing instance-specific RI logic with a spend-rate commitment. Instead of committing to specific EC2 instance types in specific regions, you commit to a consistent $/hour spend across your compute usage, and AWS automatically applies discount rates to eligible services.

AWS offers two types of Savings Plans with meaningfully different characteristics. EC2 Instance Savings Plans (comparable to Standard RIs) commit to a specific instance family in a specific region, offering discounts up to 72% — identical to Standard RI discounts — but apply automatically across any instance size within that family. This eliminates the RI "sizing" problem where you purchased m5.xlarge RIs and your workload scaled to m5.2xlarge. Compute Savings Plans apply to any EC2 instance type, in any region, any OS, and also cover Lambda and Fargate. The discount is lower — up to 66% — but the flexibility is unmatched.

The practical implication: for enterprises moving toward containerised workloads with ECS Fargate or serverless with Lambda, Compute Savings Plans are the most commercially sensible commitment vehicle. You maintain the flexibility to shift workloads between compute platforms without stranding committed spend. For enterprises with stable, instance-specific production workloads, EC2 Instance Savings Plans deliver RI-equivalent discounts with better size flexibility.

The Stacking Strategy: How to Use All Three

The maximum savings from AWS come from using all three purchasing models simultaneously, with each model assigned to the workload category it serves best. This is the "stacking" approach — and it requires workload classification as the prerequisite step.

The recommended layering framework for enterprise AWS environments:

• Layer 1 — Savings Plans (Baseline Coverage, 50–60% of spend): Apply EC2 Instance Savings Plans or Compute Savings Plans to your most predictable baseline compute workloads. These workloads run consistently 24/7 at relatively stable capacity. Target 1-year Savings Plans unless your workload stability and financial position justify 3-year commitments.
• Layer 2 — Spot Instances (Variable/Interruptible Workloads, 20–30% of spend): Run all batch, CI/CD, ML training, and development workloads on Spot. Use Spot Fleets with diversified instance type pools. Configure Auto Scaling Groups to use Spot for scale-out capacity, On-Demand for minimum baseline capacity.
• Layer 3 — On-Demand (Unpredictable Bursts, 10–20% of spend): Reserve on-demand purchasing for genuine capacity surges that cannot be anticipated — product launches, seasonal peaks, and workloads not yet profiled sufficiently to commit. Over time, as workload patterns mature, convert on-demand usage to Savings Plans.

An enterprise spending $10M/year on AWS with this stacking strategy typically achieves: $5–6M of spend covered by Savings Plans at 40–50% discount = $2–3M savings; $2–3M of spend on Spot at 60–80% discount = $1.2–2.4M savings; remainder on on-demand with modest additional optimisation. Total blended savings: $3.2–5.4M — equivalent to a 32–54% reduction on the original spend, delivered through purchasing model optimisation before any EDP negotiation is considered.

Workload Classification: The Foundation of Cost Optimisation

None of the above is implementable without accurate workload classification. The majority of enterprises that fail to optimise their AWS purchasing models do so because they lack the operational inventory to classify workloads by their purchasing model fit. Building that inventory is the foundational step.

Classify every running workload across four dimensions: Interruption tolerance (Can this workload handle a 2-minute shutdown with graceful recovery? Yes = Spot eligible); Usage predictability (Does this workload run at consistent capacity, or does it fluctuate significantly? Consistent = RI/Savings Plan eligible); Commitment horizon (How confident are you that this workload will continue running in its current form for 1–3 years? Confident = Standard RI or 3-year Savings Plan candidate); and Instance flexibility (Is this workload tied to a specific instance family, or can it run on any current-generation instance? Flexible = Compute Savings Plan candidate).

Most enterprises discover that their AWS estate breaks roughly as follows once classified: 15–25% of workloads are Spot-eligible (primarily batch, build, and development workloads); 40–55% are highly predictable production workloads suitable for long-term Savings Plans; 15–25% are growing or evolving workloads better served by short-term Savings Plans or Convertible RIs; and the remainder are genuinely variable or unclassified, appropriate for on-demand until usage patterns mature.

How Purchasing Models Interact With Your AWS EDP

Enterprises with an AWS Enterprise Discount Program (EDP) agreement need to understand how purchasing model savings interact with their EDP commitment. The critical point: EDP discounts and purchasing model discounts are generally applied sequentially rather than in addition to each other. Your EDP discount typically applies to the effective rate after purchasing model discounts have been applied — meaning the EDP discount is calculated on already-reduced spend.

This has two important implications for commercial strategy. First, when you negotiate your EDP commitment level, your committed spend should reflect the purchasing model optimisations you plan to implement — not your current on-demand spend. Committing to on-demand-equivalent spend when you expect to move 30–40% of your compute to Spot and Reserved will result in over-commitment. Second, as your purchasing model strategy matures and your effective AWS spend decreases, you need to ensure your EDP commitment trajectory accounts for that reduction. Revisit your EDP annually — particularly if your Spot and RI coverage is increasing significantly.

Five Common Mistakes Enterprises Make

Mistake 1: Purchasing RIs without workload validation. Buying Standard RIs based on current EC2 usage reports without validating that the underlying workloads will remain on those specific instance types for the commitment term. The result: stranded RIs when workloads migrate to Graviton, containers, or different instance families.

Mistake 2: Using only Compute Savings Plans when EC2 Instance Savings Plans would deliver higher savings. Compute Savings Plans are more flexible but deliver lower discounts. For enterprises with stable production workloads that are definitively not moving instance family or region in the next 1–3 years, EC2 Instance Savings Plans deliver meaningfully better economics.

Mistake 3: Running Spot without proper interruption handling. Treating Spot as "cheaper on-demand" and running workloads that aren't interruption-tolerant. One AWS Spot interruption during a business-critical batch job can cause more operational damage than the cost savings justify. Implementation discipline matters more than discount depth.

Mistake 4: Setting Savings Plan commitment levels based on historical on-demand spend rather than projected future spend. If you're actively growing, your spend will increase. If you're optimising, your spend will decrease. Both scenarios make historical averages a poor commitment anchor. Model forward-looking spend with growth and optimisation assumptions before committing.

Mistake 5: Treating AWS purchasing model optimisation as a one-time project. The optimal purchasing model mix changes as workloads evolve, new services are adopted, and the AWS portfolio changes. Build a quarterly review process that reassesses coverage, commitment levels, and workload classification as your infrastructure evolves.

Building Your 90-Day Action Plan

A practical 90-day framework for enterprises that are ready to move from on-demand-heavy spending to an optimised multi-model purchasing strategy:

• Days 1–30 — Inventory and Classification: Use AWS Cost Explorer's RI coverage, Savings Plans coverage, and Spot usage reports as your starting point. Classify your top 20 workloads by spend across the four dimensions above. Identify the Spot-eligible workload candidates with the highest current on-demand spend.
• Days 31–60 — Spot Implementation and RI Analysis: Implement Spot for the 3–5 highest-value, clearly interruptible workloads (start with CI/CD and batch). Configure Spot Fleet with diversified instance pools. Run RI and Savings Plan recommendation tools in AWS Cost Explorer and validate recommendations against your workload roadmap.
• Days 61–90 — Savings Plan Commitment and Governance: Purchase Savings Plans for validated baseline workloads. Start with 1-year terms for any workloads with less than 24 months of stable history. Establish a monthly coverage review process. Integrate coverage metrics into your cloud cost governance dashboard.

The enterprises that implement this framework consistently deliver 30–45% reduction in AWS compute spend within the first year — without reducing functionality, without renegotiating contracts, and without the complexity of a major infrastructure transformation. Purchasing model optimisation is the fastest, most predictable path to significant AWS cost reduction at enterprise scale.

For organisations spending $5M or more annually on AWS, the complexity of coordinating purchasing model strategy with EDP negotiations, MACC commitments, and multi-cloud cost strategy justifies specialist support. Our AWS negotiation and cost optimisation service operates on a 25% gainshare basis — you keep 75% of every dollar we save you, and you pay nothing if we don't deliver.