AWS Savings Plans vs Reserved Instances: What Reddit Actually Says

Buy Compute Savings Plans first for the flexible part of your baseline. Add Standard Reserved Instances only where the fleet is genuinely steady and you need the capacity guarantee that Savings Plans do not provide. That is the practitioner consensus across r/aws and r/FinOps, and it matches the AWS documentation.

The disagreement in those threads is almost never about that conclusion. It is about the numbers, and the numbers have moved. Three of the most repeated Reddit claims are now either wrong or incomplete, and one entire product category launched after most of the highly upvoted answers were written.

This is the point the r/aws regulars make most consistently, and it is the one AWS marketing pages bury. In a November 2025 thread asking how a capacity reservation differs from an EC2 Savings Plan, u/Liquidjojo1987 put it plainly:

"It’s important to note that savings plans are more of a “billing” mechanism and DO NOT reserve or guarantee any type of capacity. For discount + capacity reservation you would need a zonal reserved instance."

The AWS documentation agrees, and adds a route the thread missed. The Savings Plans user guide states: "Savings Plans doesn’t provide capacity reservations, but you can allocate On-Demand Capacity Reservation (ODCR) for your needs and your Savings Plans will apply."

That matters. The Reddit answer implies a zonal Standard RI is the only way to get discount plus guaranteed capacity. It is not. You can pair an On-Demand Capacity Reservation with a Savings Plan and keep the flexibility, which is usually the better shape for GPU or launch-sensitive workloads that also change instance types.

Search this topic and you will find confident answers stating that Savings Plans cover EC2, Fargate and Lambda only, and that databases need their own Reserved Instances. That was correct until 2 December 2025, when AWS announced Database Savings Plans.

AWS now documents four Savings Plans types, not three. Database Savings Plans "provide flexibility to use AWS database services while reducing costs by up to 35% on Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Timestream, Neptune, Keyspaces, DMS, and Amazon OpenSearch Service."

The r/FinOps reaction thread is more useful than the announcement, because it names the limits immediately. u/classjoker opened with the term restriction: "Only 1 year reservations... A strategy to lower to maximum saving % as you can’t buy a 3 year plan and get a marginally better %."

u/HandRadiant8751 went at the headline number: "The 35% discount claim relates to serverless Aurora only, for most of instance based RDS, it’s only 20%. So there’s still significant upside using RDS RIs (30-35%)". Treat that as a practitioner estimate rather than a published figure, but the direction is corroborated by the AWS docs, which note Database Savings Plans apply "to the latest provisioned instance generations" rather than to everything.

u/magheru_san drew the practical conclusion: "the main use case for this is covering Aurora serverless. For provisioned capacity RIs offer better discounts and within the available 1 year term they’re not as likely to be affected by instance type changes."

There is a footnote to this that says something about why the threads are worth reading at all. Six weeks before the launch, an r/aws user noticed their Savings Plan coverage had inexplicably dropped from nearly 100% to 80%, with strange new RDS-shaped lines appearing in the coverage breakdown. AWS rolled the change back and told them it was resources not eligible for Savings Plans showing up in error. u/Negative-Cook-5958 posted the follow-up on 23 October 2025: "So I was right with the RDS, maybe it was a sneak peek of a new feature coming at re:Invent :)". They were right. The feature shipped at re:Invent that December.

One July 2026 r/aws thread does something most comparison articles skip: it works out what you actually commit to. u/ivanavich had a single db.r8i.2xlarge running SQL Server on Windows, and could not reconcile the AWS Purchase Analyzer recommendation with their own arithmetic.

The instance was $1.20/hr, the Windows licence $0.184/hr and the SQL Server licence $0.48/hr. They assumed the commitment should be the full discounted spend of $1.624/hr. The Purchase Analyzer said $0.96/hr.

The thread is unanimous, and correct. u/JonnyBravoII: "Licensing costs aren’t discounted in EC2 nor RDS, you pay full price regardless. So you make the instance cost commitment only." u/MateusKingston spelled out the failure mode: "if you do $1.624/hr commit you will spend that + all the hourly licenses so $2.288/hr".

This is the single most expensive misunderstanding in commitment buying, and it applies to EC2 as much as RDS. Your commitment is denominated in discounted compute, not in your bill. Over-commit by the licence portion and you pay for unused commitment on top of licences you were always going to pay for.

Nearly every thread that recommends Reserved Instances mentions the RI Marketplace as the safety net: if it does not work out, sell it. The restrictions rarely make it into the same comment.

From the AWS documentation: only Standard regional and zonal EC2 Reserved Instances can be sold. Convertible RIs cannot be sold at all. Reserved Instances for other services, explicitly including RDS and ElastiCache, cannot be sold. The RI must have been active for at least 30 days with at least a month of term remaining. AWS takes "a service fee of 12 percent of the total upfront price".

The restriction that ends the conversation for most of the world: "When you register as a seller, the bank you specify must have a US address." AWS India accounts cannot register as sellers even with a US bank account. Only the account root user can register.

So for a team outside the US buying an RDS Reserved Instance, the escape hatch does not exist on any axis. That should change how much rigidity you are willing to accept at purchase time.

Older threads state flatly that a Savings Plan cannot be undone. That has not been true since March 2024, though the conditions are narrow enough that most people never qualify.

AWS documents it as follows: "Any Savings Plan with an hourly commitment of $100 or less that has been purchased in the last seven days and in the same calendar month can be returned, provided you haven’t reached your return limit. Once the calendar month ends (UTC time), these purchased Savings Plans can no longer be returned."

The quota is 10 returns per management account per calendar year. Note the calendar-month trap: a plan bought on the 30th has one day of return eligibility, not seven. If you are buying near month end and you are not certain, wait for the 1st.

On the question of coverage percentage the threads do not converge, and it is worth understanding why rather than picking the number you like.

u/TooMuchTaurine buys once a year and targets "about 95% coverage at peak to give us some buffer". Others treat anything above 70% as reckless. Both can be right, because they are measuring against different baselines. Coverage against peak is a much safer number than coverage against average, and coverage against average is the one that burns people.

The most useful framing in the thread came from u/AlphaToBe: "Stop chasing perfect coverage. The goal isnt 100%. Its covering your stable floor and leaving the variable portion on-demand. Trying to optimize the last 5-10% of coverage is where most of the analysis time goes and the savings are marginal." Their method is to pull 90 days from Cost Explorer at daily granularity and take the minimum daily spend, not the average, as the floor.

That is the reconciliation. Commit to the floor, not the mean. If you compute your baseline from the minimum, a high coverage number is safe. If you compute it from the average, you have already committed to capacity you do not always run.

The reason these threads go stale is that AWS keeps adding overlapping products without retiring the old mental models. One r/aws commenter, u/RecordingForward2690, described the problem better than any vendor blog:

"AWS has changed its mind a couple of times on how to offer/administer these types of plans, and the result is that there are confusing and overlapping plans... Also, there’s at least one plan (Scheduled Reserved Instances) that’s not being offered anymore, but is still in documentation, blog posts, social media comments and such."

So check the date on the comment before you act on it. Anything before December 2025 predates Database Savings Plans. Anything quoting 75% for Standard RIs predates the current pricing page, which says 72%. Anything saying a Savings Plan purchase is irreversible predates March 2024.

Pull 60 to 90 days of usage before committing to anything, then cover roughly 60 to 70% of the stable baseline with Compute Savings Plans. That leaves headroom for the right-sizing you have not done yet, which is the work that actually pays.

Only then look at the residual. If a fleet has been on the same instance family for a year and needs zonal capacity, a Standard RI earns its rigidity. If it is a database, price the Database Savings Plan against an RDS Reserved Instance rather than assuming the newer product wins, because on provisioned instances it frequently does not.

For the full decision framework, pricing tables and purchase sequence, see the companion guide.