OptimizationOctober 10, 2026 10 min read

Reserved Instances vs Savings Plans: how to decide what to reserve on AWS using real usage data

AWS Reserved Instances and Savings Plans cut your bill in exchange for a one- or three-year commitment. We explain how they differ and how to use AAA Sentinel to find which EC2 instances and RDS databases are worth reserving, with a full worked example and the maths done.

This article is also available in:esfrpt

Committing to AWS is the most direct way to pay less for the same thing: you reserve capacity or spend for one or three years and get a significant discount on the on-demand price. The catch is that the commitment is paid whether you use it or not. Reserving a machine you switch off four months later costs more than reserving nothing. This article sums up what Reserved Instances and Savings Plans are, then shows you, step by step, how to decide what to reserve using the usage data AAA Sentinel already collects from your account.

Reserved Instances and Savings Plans in two minutes

Both trade commitment for discount, but they commit to different things:

  • Reserved Instances (RIs): you commit to a specific configuration (instance type, region, operating system) for 1 or 3 years. They exist for EC2 and also for databases such as RDS. On EC2 there are two flavours: Standard, with the biggest discount (AWS quotes up to 72%) and little flexibility, and Convertible, with a slightly smaller discount (up to 66%) in exchange for being able to swap it for another configuration.
  • Savings Plans: you commit to a fixed spend per hour (for example, $10/hour) for 1 or 3 years, and AWS applies the discount to whatever fits. The Compute Savings Plan covers EC2, Fargate and Lambda across any family, size or region (up to 66%). The EC2 Instance Savings Plan is limited to one family in one region and gets close to a Standard RI discount (up to 72%).
  • Payment options, for both: everything upfront (All Upfront), part of it (Partial Upfront) or nothing upfront (No Upfront). The more you pay upfront, the bigger the discount; but even with nothing upfront, you commit to paying every month of the term.

Which one to choose

There is no universal answer, but there is a rule of thumb that works for most teams:

  • Changing architecture (containers, moves between families, Lambda or Fargate): Compute Savings Plan. You give up some discount, but the commitment keeps working when you change machines.
  • A stable fleet that will not change family or region during the term: Standard RI or EC2 Instance Savings Plan, which give the biggest discount.
  • RDS databases: Compute Savings Plans do not cover RDS, so the classic route is RDS Reserved Instances.
  • Term: three years almost doubles the discount of one, but also the risk. Only worth it for workloads you are very sure about.

The most common trap is not choosing wrongly between RIs and Savings Plans, but reserving for three years an instance generation your team will abandon within one. Before committing, ask whether that workload will still exist, in that shape, for the whole term.

The problem: committing blind

A reservation only saves money if the machine would have been running anyway. An m5.large in eu-west-1 costs about $73 a month on demand; the same with a 1-year No Upfront RI, about $45. In other words, the RI costs around 62% of the on-demand price. If that instance was going to run for less than 62% of the hours in the month, the reservation loses you money. So the useful question is not "how much discount do I get?" but "which workloads are stable enough to commit to?". Answering it takes usage data, not gut feeling.

What you gain

Deciding reservations with data changes the conversation with finance:

  • You know which specific instances are candidates and why, instead of reserving "a percentage of the bill".
  • You see 1-year and 3-year savings side by side, with a confidence level for each recommendation.
  • You know the real commitment you are signing: how much you will pay every month no matter what.
  • You can check the impact in the simulator before buying anything.

What AAA Sentinel covers (and what it does not)

Best to be clear from the start: AAA Sentinel's reservation recommendations currently cover AWS Reserved Instances for EC2 instances and RDS databases. The platform does not recommend Savings Plans, Azure Reservations or Google Cloud Committed Use Discounts (CUDs). If you use those, evaluate them with each provider's native tools:

  • AWS Savings Plans: in the Billing and Cost Management console, Savings Plans → Recommendations. AWS works out the hourly commitment from your recent usage.
  • Azure Reservations: Azure Advisor, in its cost recommendations, suggests reservations based on the usage of your virtual machines and other services.
  • Google Cloud CUDs: the Google Cloud Recommender (visible in the billing console) suggests commitments based on your consumption.

The RIs AAA Sentinel recommends and a Savings Plan are not mutually exclusive: you can reserve the most stable workloads with RIs and cover the rest of your compute with a Compute Savings Plan. What matters is not reserving the same workload twice.

Worked example: ACME's steady fleet

ACME, a fictional company, has one AWS account in eu-west-1, running Linux, with everything switched on all month. Its total spend on the account is around $2,400 a month. This is the part we care about:

ACME · running instances (30-day metrics)

4 × m5.large (web)
Average CPU 35%, p95 55%
2 × c5.xlarge (queue workers)
Average CPU 22%, p95 60%
1 × t3.medium (nightly reports)
Average CPU 18%, p95 70%
1 × t3.small (bastion)
Average CPU 3%
1 × t3.nano (health check)
Average CPU 20%
RDS db.m5.large (production)
40 connections on average
RDS db.t3.medium (staging)
2 connections on average

Step 1: start from the savings overview

With the account connected and at least one completed scan, go to Optimization → "Savings overview". This page is available on every plan and gathers the savings potential from the latest scan: "Total savings/mo" (1-year Reserved Instances plus rightsizing), the number of "RI candidates" and the "Potential savings breakdown". From here you reach the three detail pages: Reserved Instances, Rightsizing and "Savings simulator", which require the Pro plan (the 30-day free trial includes Pro).

The reservation analysis is recalculated on every scan. On Pro, scans run automatically every day, so the candidate list always reflects the latest snapshot of your account.

Step 2: read the Reserved Instances page

Under Optimization → "Reserved Instances" (/savings/reservations) you will see, for the selected account (if you have several, there is a selector at the top right):

  • A term selector, "1 year" or "3 years", which recalculates the whole page.
  • Three indicators: "1 year savings" (or "3 years savings"), with the total monthly saving; "Candidates", the instances that meet the criteria; and "Analyzed", how many instances were evaluated.
  • A table with one row per candidate: "Instance" (name and ID), "Type", On-Demand price, RI price, "Savings" as an amount and a percentage, average CPU and "Confidence".
  • A "How does it work?" box summarising the criteria and the pricing assumptions.

Step 3: understand the criteria and the confidence

Knowing how a candidate is chosen is what lets you trust the list. These are the exact criteria:

  • EC2: only running instances, of a type the platform has in its price catalogue, costing at least $10 a month on demand. On top of that, average CPU over the last 30 days (or 7, if there are not 30 days of metrics) must be 15% or more.
  • EC2 confidence: "High" if average CPU is 30% or more and p95 is no more than twice the average; "Medium" if the average is 15% or more and p95 is no more than three times the average; "Low" otherwise. An instance with sharp peaks does not drop off the list: it appears with "Low" confidence, and should be read as a warning, not a recommendation.
  • RDS: instances of a class included in the catalogue, costing at least $10 a month, with average connections over 7 days above 0.5. Confidence is "High" with more than 5 connections on average and "Medium" otherwise. RDS has no CPU column.

At ACME, the bastion (3% average CPU) is left out for low usage and the t3.nano for not reaching $10 a month. Both deserve a different question: whether they really need to be on all day.

Step 4: the pricing assumptions and ACME's result

The amounts come from a catalogue of approximate eu-west-1 Linux prices, with No Upfront RIs and, for RDS, Single-AZ. The same catalogue is applied whatever the instance's region. With the term set to "1 year", ACME's page shows "1 year savings" of $287.10/month, 9 "Candidates" and 11 "Analyzed" (the 9 running EC2 instances plus the 2 RDS ones). With "3 years", savings rise to $458.50/month. This is the 1-year detail:

ACME · 1-year RI candidates (US$/month per instance)

m5.large × 4 · High confidence
73.00 → 45.30 · saves 27.70 (38%)
c5.xlarge × 2 · Medium confidence
128.50 → 80.30 · saves 48.20 (38%)
t3.medium · Low confidence (p95 nearly 4× the average)
31.00 → 20.00 · saves 11.00 (35%)
db.m5.large · High confidence
131.40 → 82.90 · saves 48.50 (37%)
db.t3.medium · Medium confidence
58.40 → 38.00 · saves 20.40 (35%)
1-year total
$287.10/month

These are reference prices, not your bill. Before buying, check the exact price in the AWS console for your region, operating system and payment option. Outside eu-west-1, or with Windows or Multi-AZ, the difference can be noticeable.

Step 5: decide what to actually reserve

The list is the starting point, not the purchase order. ACME reviews it with the team and leaves out two candidates:

  • The reporting t3.medium, because of its "Low" confidence: with peaks close to four times the average, the team would rather study whether another size fits better before locking in for a year.
  • The staging database, because they plan to switch it off at night. A reservation on something you will turn off half the time loses almost all its point.
  • Result: they reserve the 4 m5.large, the 2 c5.xlarge and the db.m5.large. Savings: $255.70/month, about $3,068 a year.
  • Commitment: they will pay $424.70 a month for 12 months ($5,096.40 in total), whether or not they use those machines. On demand they were paying $680.40/month for them.

Over 3 years, those same seven instances would save $406.40/month, but ACME would be tied to the m5 and c5 families for 36 months. Since the team plans to move to a newer generation next year, it sticks with the 1-year term.

Step 6: check it in the Simulator

In Optimization → "Savings simulator", ACME switches on the "Reserved Instances (1 year)" scenario. The "Estimated savings (USD/mo)" field comes pre-filled with the 1-year total from the latest scan (287.10). They change it to 255.70 to reflect their decision and click "Simulate savings". The simulator returns "Monthly savings" $255.70, "Annual savings" $3,068.40 and "New cost", which is the account's monthly spend in the latest scan minus that saving: about $2,144.

  • You can combine the scenario with "Instance rightsizing" and the others, but be careful: if an instance appears in both Rightsizing and Reserved Instances, rightsize it first and then reserve it at its new size. The two savings do not simply add up.
  • The simulator's reservation scenario works on a 1-year term. To compare with 3 years, use the term selector on the Reserved Instances page.

Step 7: buy the reservation in AWS

AAA Sentinel recommends, but does not buy: the reservation is purchased in the AWS console (EC2 → Reserved Instances for instances, RDS → Reserved instances for databases). Choose the same type, region, operating system and payment option you evaluated. After the purchase, later scans will still see those instances running, so do not be surprised if they stay on the list: the platform does not yet read the reservations you already hold.

What it does not do yet

For the tool to help you without surprises, it is worth knowing its current limits:

  • It only recommends AWS Reserved Instances for EC2 and RDS. It does not recommend Savings Plans, Azure Reservations or Google Cloud CUDs.
  • It does not take into account reservations or Savings Plans you have already bought: review your current coverage in AWS Cost Explorer before buying more.
  • It uses approximate eu-west-1 catalogue prices (Linux, No Upfront, RDS Single-AZ), not your exact price.
  • Instance types not in the catalogue are skipped.
  • It does not buy or manage reservations for you.

Checklist before reserving

With these points covered, every dollar you commit will have a workload behind it that really uses it:

  • AWS account connected and a recent scan completed.
  • Candidate list reviewed on Reserved Instances, at 1 and 3 years.
  • "Low" confidence candidates studied one by one, not reserved blindly.
  • Anything you will switch off, resize or migrate during the term taken off the list.
  • Current RI and Savings Plans coverage checked in AWS Cost Explorer.
  • Scenario checked in the Savings simulator and price confirmed in the AWS console.
  • For Savings Plans, Azure or Google Cloud: each provider's native recommendations.