The return window, in full
AWS documents a narrow correction mechanism for purchase errors. A Savings Plan can be returned when all of the following hold:
The hourly commitment is $100 or less. The plan was purchased within the last seven days. The return happens in the same calendar month as the purchase, measured in UTC. The account has not exceeded its return limit, which is ten returns per management account per calendar year, applied across a consolidated billing family.
On a successful return, AWS refunds 100 percent of any upfront charges, reflected in the bill within 24 hours. Usage previously covered reverts to on-demand rates, or to another Savings Plan if one applies.
The documented reasons a return fails are worth reading as a list, because each is a way the mechanism does not help you:
The hourly commitment is greater than $100. The plan was purchased in a different month, or in the same month more than seven days ago. The request comes from a user without the savingsplans:returnSavingsPlan permission, which only root users and holders of that permission have. The plan is All Upfront or Partial Upfront and the account is registered under AWS Brazil or AWS Turkey as seller of record. The management account differs from the one used at purchase.
A plan in payment-pending state also cannot be returned; it has to activate first.
What the $100 cap means at scale
The cap is expressed per hour, which makes it easy to misread. Annualized, $100 per hour is $876,000 of committed spend per year.
Any organization committing more than that has no return path at all. And because a commitment is normally sized to a fraction of the on-demand baseline rather than to the whole of it, the on-demand spend at which an organization crosses the threshold is higher still. At 70 percent coverage the crossing point is roughly $1.25 million of annual on-demand spend; at 80 percent coverage, roughly $1.10 million.
Below that, the return window is a genuine safety net for a mis-sized purchase. Above it, the mechanism is documentation that does not apply to you.
The inversion
Here is the part that matters, and it runs counter to how these instruments are usually understood.
A Compute Savings Plan is the most operationally flexible instrument available. The discount follows usage across instance families, regions, operating systems, and into Fargate and Lambda. It adapts as the infrastructure changes, which is precisely why teams choose it.
It also has no secondary market. Once the return window closes, there is no mechanism to exit it.
A Standard Reserved Instance is the least flexible instrument. It is bound to an instance family and a region, and it does not follow a workload that moves. Teams avoid it for that reason.
It can be listed and sold on the AWS Reserved Instance Marketplace.
So the instrument that adapts best to change offers no way out, and the instrument that adapts worst has a liquidation path. Convertible Reserved Instances sit between the two: they cannot be sold, but they can be exchanged for different instance families.
Flexibility during the term and optionality at exit are different properties, they are not correlated, and choosing on one without examining the other is how organizations end up holding something they cannot use and cannot leave.
