AWS Savings Plans Refund and Cancellation Policy

It is the question every finance team asks too late: can we cancel this Savings Plan? The short answer is that, with one narrow exception, you cannot. A Savings Plan is a binding commitment for its full one or three-year term, non-cancellable and non-refundable. There is no marketplace to sell it on, no early-termination clause, and no partial refund for a workload that disappeared.

Across 500+ engagements and $2.4B+ in reviewed AWS spend, the painful cases almost always involve a buyer who treated the commitment as reversible and discovered otherwise. This guide lays out the policy plainly and, more usefully, how to commit so that irreversibility never hurts you.

The core policy: commitment is binding

When you purchase a Savings Plan, you commit to a dollar-per-hour spend for the full term. AWS bills that committed amount every hour for one or three years regardless of whether you use it. There is no standard mechanism to cancel the plan, reduce the committed rate, or obtain a refund partway through.

This is a deliberate part of the bargain. The discount exists because the commitment is firm — AWS gives you a lower rate in exchange for guaranteed revenue it can plan around. Reversibility and discount are traded off against each other.

The one exception: the return window

There is a narrow grace period. AWS allows you to return a Savings Plan within a short window after purchase — historically up to seven days — subject to limits on how many returns are permitted in a period. This exists to correct genuine mistakes: a wrong commitment rate, an accidental term, a fat-fingered purchase. It is not a trial period, and it is not a strategy — the allowance is limited and monitored.

If you realize within days of purchase that you committed incorrectly, act immediately and use the return window. Beyond it, the commitment is firm. Because policy specifics can change, always confirm the current return terms in the AWS console at the moment of purchase rather than relying on a remembered figure.

Why this differs from Reserved Instances

This is a crucial distinction. Standard Reserved Instances can be sold on the RI Marketplace, giving them a (imperfect) exit. Savings Plans cannot be transferred or sold at all. If liquidity and an exit path matter to you — for a workload you are genuinely unsure about — that is a point in favor of an RI for the specific case, despite Savings Plans being the better default for most usage. We compare the instruments fully in Savings Plans vs Reserved Instances.

How to commit so irreversibility never hurts

Because you cannot exit, the entire risk management happens before you sign. Five disciplines:

• Size to the floor, never the peak. Commit only to usage present in essentially every hour, so there is no scenario where the workload falls below the commitment. This is the method in our hourly commitment sizing guide.
• Prefer Compute Savings Plans for the flexible band. They float across instance families, regions, Lambda, and Fargate, so a workload that moves is still covered — the commitment survives architectural change that would strand a narrower instrument.
• Match term to forecast confidence. Three-year only where you can credibly see three years out. One-year where the future is murkier — the irreversibility window is shorter.
• Choose payment option by retirement risk. No-upfront keeps cash flexible and limits the downside of an early-retired workload; all-upfront maximizes discount but maximizes stranded cash if the bet goes wrong — see break-even analysis.
• Confirm the roadmap across teams. The most common stranding cause is a migration or retirement that finance did not know about. Get written confirmation that the workload survives the term before committing.

If you are already over-committed

If a commitment is stranded and past the return window, the mitigations are limited but real:

• Let a Compute Savings Plan float. Its automatic application across the Organization means an over-commitment on one workload may be absorbed by eligible usage elsewhere — covered in portfolio rebalancing.
• Concentrate eligible workloads. Where feasible, route eligible new usage into the Organization so the floating commitment has more to apply against.
• Factor it into the next EDP cycle. Stranded commitment still counts toward EDP burn, which can soften the impact — see EDP and Savings Plans stacking.

The governance that prevents stranding

Because the exit doors are so limited, the organizations that never strand a commitment are the ones with a purchase-approval process, not a purchase button. The pattern that works: no Savings Plan above a threshold is purchased without a brief written case that states the committed rate, the term, the payment option, the usage floor it is sized against, and — critically — a sign-off from the team that owns the underlying workload confirming it will survive the term. That last signature is the one that prevents the most expensive failures, because the classic stranding scenario is finance committing to a workload another team was already planning to migrate or retire.

This governance does not need to be heavy. For most buyers it is a single shared document and a two-person approval: the finance owner who sized the commitment and the engineering owner who vouches for the workload's longevity. The cost of that fifteen-minute step is trivial against the cost of a stranded multi-year, all-upfront commitment that cannot be cancelled or sold. The same register should track every active commitment with its return-window deadline and its term-end date, so genuine purchase errors can still be reversed inside the grace period and renewals are never missed. Buyers who treat commitment purchasing as a governed procurement decision rather than a console click essentially eliminate the stranding risk that the non-cancellable policy would otherwise expose them to — and they feed cleaner data into the rebalancing cadence.

What to do before every purchase

Treat every Savings Plan purchase as irreversible — because it is. Before signing: confirm the hourly rate against the usage floor, confirm the term against forecast confidence, confirm the workload roadmap across the owning teams, and confirm the current return-window terms in the console. After purchase, diarize the return-window deadline so a genuine error can still be corrected in time.

For an independent pre-commitment review — the check that catches an over-commitment before it becomes unrecoverable — Contact Us. See also Savings Plans optimization and utilization monitoring.