EDP vs Spot Instances: Committed Pricing Strategy for AWS Buyers

The Core Tension: Savings vs Reliability

AWS pricing offers enterprise buyers a rich menu of cost reduction mechanisms, but no single mechanism is universally superior. Spot Instances, Reserved Instances, Savings Plans, and the Enterprise Discount Program (now universally referred to as PPA by AWS) each address a different point in the workload-commitment-risk spectrum. The mistake many enterprise FinOps teams make is treating these as mutually exclusive choices rather than complementary components of an integrated cost strategy.

The tension between Spot Instances and committed pricing comes down to a fundamental question: how tolerant is your workload of interruption, and how predictable is its compute demand? The answers to these two questions should drive your pricing strategy — not the headline discount rate that makes Spot Instances so commercially appealing in isolation.

For enterprise buyers with an AWS EDP (or PPA, in current AWS terminology), there is an additional consideration that is often overlooked: Spot Instance spend does not count toward your committed EDP spend. If you are at risk of shortfall against your EDP commitment, consuming compute via Spot Instances instead of drawdown-eligible services worsens your shortfall exposure rather than helping it. Understanding this interaction is essential for integrated cost management.

Understanding Spot Instances: The Mechanics Behind the Discount

Spot Instances are spare EC2 capacity that AWS makes available at steep discounts — typically 60–90% off on-demand pricing — because the underlying capacity would otherwise sit idle. The catch is that AWS can reclaim Spot capacity at any time with a two-minute interruption notice. When that notice arrives, your Spot Instance will be either stopped or terminated, depending on the interruption behaviour you have configured.

The average interruption frequency across all instance types and regions is historically less than 5%, but this average conceals significant variation. In high-demand availability zones or for popular instance types, interruption rates can run significantly higher — in some cases exceeding 20% per month. Workloads that are sensitive to interruption, that carry stateful data not protected by checkpointing, or that are part of a customer-facing critical path, face genuine reliability risk on Spot capacity.

AWS has evolved its tooling significantly to help manage Spot interruption risk. Capacity Rebalancing — which allows Auto Scaling groups to proactively replace at-risk Spot Instances before the two-minute notice — and the shift away from the legacy Spot Fleet toward EC2 Auto Scaling groups are both meaningful improvements. But they are operational mitigations, not eliminations of the fundamental risk. For a workload to be genuinely Spot-appropriate, its architecture must be designed for interruption tolerance, not retrofitted to cope with it.

Workload Types Where Spot Makes Sense

The workloads where Spot Instances deliver reliable savings without operational compromise are well-defined: batch processing pipelines that can checkpoint and resume, CI/CD build runners where a failed job simply retries, stateless web tier scale-out behind a load balancer where instance termination is transparent to users, ML training jobs that checkpoint to S3 regularly, ETL and data transformation workloads that are fault-tolerant by design, and HPC simulations that can be structured to handle node failure gracefully.

What all these have in common is that an individual instance interruption does not cause data loss, does not break a user-visible transaction, and does not require manual intervention to recover. If your workload does not meet these criteria, the operational cost of managing Spot interruptions can easily exceed the pricing benefit.

Where Committed Pricing Wins for Predictable Workloads

For workloads that run continuously, carry stateful data, or are part of customer-facing critical paths, committed pricing — whether via Savings Plans, Reserved Instances, or EDP-level discounts — is the more appropriate cost strategy. The reasons are both direct (reliable capacity, no interruption risk) and indirect (better cost predictability, EDP drawdown contribution, and operational simplicity).

EC2 Savings Plans and Compute Savings Plans

Compute Savings Plans are the most flexible committed pricing mechanism AWS offers, providing discounts of up to 66% off on-demand pricing across EC2, Lambda, and Fargate, regardless of instance family, size, region, or operating system. A one-year Compute Savings Plan on a steady-state workload will deliver a consistent 40–55% discount depending on the utilisation profile, with no interruption risk and no capacity reservation complexity.

EC2 Instance Savings Plans are less flexible — they lock you into a specific instance family and region — but provide higher discounts of up to 72% for the relevant instance type. For workloads where the instance family is genuinely stable over the commitment term, EC2 Instance Savings Plans are worth evaluating against Compute Savings Plans on a case-by-case basis.

Critically, both Savings Plan types count toward your AWS EDP commit drawdown. Every dollar of Savings Plan spend contributes to your annual EDP commitment, reducing the risk of shortfall penalties at year-end. Spot Instance spend does not. This asymmetry means that for buyers who are managing EDP shortfall risk, Savings Plans are doubly valuable: they reduce on-demand compute costs while simultaneously improving EDP compliance.

The EDP Interaction: Why It Changes the Spot Calculus

Enterprise buyers with an AWS EDP (PPA) need to model the Spot vs committed pricing decision through the lens of their EDP commitment structure. The EDP provides a percentage discount off your AWS bill in exchange for a committed minimum annual spend. If you miss your commit, you pay the shortfall amount regardless of what you actually consumed — which is the most common source of financial surprise in AWS commercial relationships.

Spot Instance spend does not count toward your EDP commit. This creates a structural incentive to bias your workload mix toward EDP-eligible consumption — including Savings Plans, Reserved Instances, and on-demand EC2 — rather than Spot. A buyer who runs 20% of their compute fleet on Spot is effectively running 20% of their capacity outside the EDP framework, which means their EDP commit is harder to achieve from the remaining 80% of their workload.

The optimal strategy for EDP buyers is therefore a tiered approach: use committed pricing (Savings Plans, RIs) for the stable, predictable baseline that you want to count toward EDP drawdown; use on-demand for the variable layer above the baseline; and reserve Spot strictly for workloads that are genuinely interruption-tolerant and where the absolute cost reduction justifies accepting the operational complexity and the EDP accounting disadvantage. For a detailed treatment of EDP commitment structure and shortfall risk management, see our AWS EDP shortfall risk management guide.

Designing a Hybrid Pricing Strategy

For most enterprise AWS buyers, the right answer is not "Spot" or "committed pricing" — it is a deliberate portfolio that allocates each workload tier to the appropriate pricing mechanism based on its characteristics.

The tiered model that consistently delivers the best results across organisations with $2M+ annual AWS spend works as follows. The steady-state baseline — the minimum compute capacity you need to run core production workloads at any point in time — is covered by a combination of Compute Savings Plans (for flexibility) and EC2 Instance Savings Plans (for high-discount workloads with stable instance families). This layer counts toward your EDP drawdown and runs with zero interruption risk.

The variable layer above the baseline — demand spikes, seasonal peaks, new project ramp-ups — is handled on-demand. On-demand pricing, while higher than committed rates, is still subject to any EDP discount you have negotiated on top-of-commit consumption. The operational simplicity of on-demand capacity for variable loads usually justifies the premium over Spot in this tier, unless engineering capacity to manage Spot interruptions is abundant.

The third tier — batch workloads, CI/CD infrastructure, ML training, and other genuinely interruption-tolerant jobs — is where Spot delivers its most reliable value. By keeping this tier architecturally isolated from the first two, you contain the interruption risk, avoid contaminating your EDP drawdown calculations, and capture the real cost benefit of Spot pricing where it is structurally appropriate.

Practical Steps for Rebalancing Your Pricing Mix

Implementing a well-structured hybrid pricing strategy requires a workload classification exercise before you can act on the commercial opportunity. The starting point is a service inventory from AWS Cost Explorer that shows your EC2 spend by instance family, region, and account, segmented by pricing mechanism (on-demand, Savings Plan, RI, Spot). Most enterprise buyers find that their current Spot usage is either too low (leaving savings on the table for batch workloads) or too high (creating EDP shortfall risk and operational complexity for workloads that should be committed).

Once you have the current state, a structured workload-to-pricing mapping exercise — involving your engineering leads and your FinOps team — identifies the rebalancing opportunities. Document each workload's interruption tolerance, its run pattern (continuous vs batch vs bursty), its data state requirements, and its criticality to customer-facing operations. Use this data to define the appropriate pricing tier for each workload, and then model the cost impact of the proposed rebalancing against your current spend and EDP commitment level.

For a comprehensive treatment of how Savings Plans and Reserved Instances fit within the EDP framework, our AWS RI and Savings Plan optimisation guide provides the detailed mechanics. Buyers evaluating their data transfer and egress costs alongside compute pricing should also review our AWS data transfer and egress negotiation guide, as egress cost is frequently the second-largest driver of AWS spend after compute.

Marketplace Procurement and Spot: A Note on ISV Workloads

One increasingly common scenario involves ISV solutions purchased through the AWS Marketplace that run workloads on EC2. In some cases, customers attempt to run Marketplace-deployed ISV solutions on Spot capacity to reduce the infrastructure cost beneath the ISV licence fee. The viability of this depends entirely on whether the ISV solution is architecturally designed for Spot — most enterprise ISV applications are not, and running them on Spot capacity creates support boundary issues that are commercially and technically complex.

If you are considering Spot for Marketplace-deployed workloads, validate with the ISV that Spot is a supported infrastructure configuration before implementing it. The cost saving is real if it works; the remediation cost if it causes instability is equally real.

Finally, for buyers whose AWS Enterprise Support costs are a significant line item, understanding how the support plan cost interacts with EDP is covered in our AWS Enterprise Support pricing and negotiation guide. Support costs are always negotiable in the context of a broader EDP conversation, and buyers who treat them as fixed are leaving money on the table.

About the Author

Morten Andersen is Co-Founder of Redress Compliance and has 20+ years of enterprise software licensing advisory experience across 500+ engagements. He has supported enterprise AWS buyers with EDP negotiations, Savings Plan optimisation, and cloud cost governance across multiple industries. Redress Compliance is Gartner recognised and operates exclusively on the buyer side.