Compare an AWS Compute Savings Plan with an EC2 Instance Savings Plan: what does each one commit you to, and what flexibility do you give up for the deeper discount?

## What a Savings Plan actually is A Savings Plan is not a reservation of hardware and not a discount code attached to an instance. It is a commitment to spend a certain number of dollars per hour on compute, for a one- or three-year term. At billing time AWS looks at your eligible compute usage, applies the plan's discounted rates until the hourly commitment is exhausted, and bills anything beyond it at On-Demand rates. Below the commitment, unused dollars are simply lost for that hour. Because the unit of commitment is money rather than instances, the interesting variable is *which usage the plan is allowed to attach to*. That is the entire difference between the two EC2-oriented plan types. ## Compute Savings Plans: maximum breadth A Compute Savings Plan attaches to compute usage almost regardless of shape. Concretely, it covers: - EC2 instances of any family and any size, - in any AWS Region, - on any operating system, - at any tenancy, - plus AWS Fargate and AWS Lambda usage. That breadth means the plan follows your architecture. Move a service from `m6i` to `m7g`, containerise it onto Fargate, or rewrite the batch tier as Lambda functions, and the same commitment keeps applying. For an organisation in motion, that property is worth more than a few extra percentage points of discount, because a commitment that stops matching your fleet is a commitment you pay twice for: once for the unused commitment, and again at On-Demand rates for the workload that moved. ## EC2 Instance Savings Plans: depth in exchange for a lock An EC2 Instance Savings Plan is scoped when you buy it: one instance family, one region. Inside that box you keep meaningful freedom — the plan still applies across sizes within the family (this is *instance size flexibility*: normalisation means one `xlarge`-worth of commitment covers two `large` instances of the same family), across operating systems, across tenancies, and across Availability Zones. Outside the box, it applies to nothing. The deeper discount is the direct compensation for the narrower promise: you have told AWS not just how much you will spend but roughly what hardware you will spend it on, which is far more useful for their capacity planning. ## The trap that catches people The most common production surprise is a family lock colliding with a migration. Suppose you hold a three-year EC2 Instance Savings Plan on the `m5` family in `us-east-1`, and the platform team then migrates services to Graviton-based `m7g` instances to cut cost. `m7g` is a different family. The plan does not follow, so you now pay On-Demand for the new fleet *and* keep paying the old commitment for capacity you no longer run. The saving from the migration is wiped out by the stranded commitment. A Compute Savings Plan would have followed the move without a murmur. The symmetric trap is over-caution: buying Compute Savings Plans for a stable, boring, long-lived fleet leaves the extra discount on the table for years. ## Choosing between them A usable decision rule: - **Is the family and region genuinely fixed for the whole term?** Databases pinned to a licensed platform, a legacy fleet nobody is funding a rewrite for, a steady-state control plane — EC2 Instance plan. - **Is anything about the compute model in flux — containers, serverless, Graviton, region expansion?** Compute plan. - **Unsure?** Split the commitment. Most estates buy a Compute Savings Plan for the portion of the baseline they are confident about at the *fleet* level, and add EC2 Instance plans only for the subset that is provably static. Terms can be laddered too: shorter terms on the uncertain portion, three-year terms on the boring one. ## Practical mechanics worth naming Savings Plans cannot be cancelled, returned or resold once purchased — that irreversibility is why the sizing discussion matters more than the plan-type discussion. They apply automatically across a billing family when discount sharing is enabled, and AWS applies the benefit to the usage with the highest discount percentage first, so a plan will naturally attach to the most expensive matching usage rather than to whatever you had in mind when you bought it. When an interviewer asks this question they are usually not testing whether you memorised the discount percentages. They are checking whether you understand that you are pricing *optionality*, and that the right plan depends on how confident you are in the shape of the fleet a year from now.