This is the only finding Parsivex raises that is account-wide rather than per-resource. It appears once per scan, not once per instance, and its fix is a purchase rather than a configuration change.
What triggers this finding
Either Cost Explorer shows at least $50/month in potential Reserved Instance savings, or you have EC2/RDS instances running steadily for 30+ days with estimated savings of $50+ at a 33% discount rate.
Typical fix
Purchase 1-year no-upfront Reserved Instances or Compute Savings Plans for consistently running workloads. Use the AWS Cost Management console to compare options.
Example savings
Typically 30–40% off on-demand pricing — $50–$500+/month for accounts with steady compute spend.
See also: Severity and savings estimates for how Parsivex calculates figures on your report.
How commitment discounts are billed
A Reserved Instance or Savings Plan does not change what you run — it changes the rate you are charged for running it. You promise AWS a year or three years of steady usage, and AWS bills the matching usage at roughly a third less than on-demand. The commitment applies to the hours whether or not you use them: with a no-upfront one-year term you still owe twelve months of the hourly rate, even if the instance is terminated in month two. That asymmetry is the whole risk profile of this finding. Every other finding on your report costs you money by existing; this one can cost you money by being acted on carelessly.
Parsivex reaches the $50-a-month reporting threshold by one of two routes. When Cost Explorer data is available, it takes your on-demand spend for the period and models a 30% discount against it. When it is not, it falls back to your inventory: EC2 instances that have been running for at least 30 days and are not part of an Auto Scaling group, plus RDS instances in the available state, priced from Parsivex's instance-type tables and discounted by a flat 33%. Findings above $200 a month are marked high severity.
Getting AWS's own recommendation
Both of Parsivex's numbers are models. AWS will compute the real one from your actual usage history, and it is one call:
aws ce get-reservation-purchase-recommendation \
--service "Amazon Elastic Compute Cloud - Compute" \
--term-in-years ONE_YEAR --payment-option NO_UPFRONT \
--lookback-period-in-days SIXTY_DAYS
aws ce get-savings-plans-purchase-recommendation \
--savings-plans-type COMPUTE_SP --term-in-years ONE_YEAR \
--payment-option NO_UPFRONT --lookback-period-in-days SIXTY_DAYS
The response includes the hourly commitment AWS suggests, the expected monthly saving, and — the part worth reading twice — the estimated utilization of the commitment. In the console the same data lives under Billing and Cost Management → Savings Plans → Recommendations and Reserved Instances → Recommendations. Compute Savings Plans cover EC2, Fargate, and Lambda and follow you across instance families and regions; Reserved Instances are cheaper still but bind you to a family. Run both recommendations before choosing.
Limits of this estimate
Read the figure as a prompt to look, not as an amount to spend.
- The Cost Explorer path is deliberately coarse. It applies a flat 30% to your on-demand spend for the period without filtering by service, so spend on things that cannot be reserved at all — S3, data transfer, CloudWatch — is included in the base. The real reservable share is smaller, often much smaller.
- The inventory fallback prices what it recognises. Instance types absent from Parsivex's rate tables contribute nothing, so the figure understates for unusual hardware. It also filters EC2 by a 30-day run and no Auto Scaling group tag, but applies no age filter to RDS: a database launched yesterday counts in full.
- Existing commitments are not netted out of the fallback. If you already hold RIs or a Savings Plan covering these instances, the inventory path counts them again. The Cost Explorer path does not, because covered spend lands outside the on-demand bucket.
- It can point at instances you should delete instead. This is the one that costs real money. The same steadily-running instance can appear in this finding and in an idle EC2 or oversized-instance finding, and committing to it locks the waste in for a year at a discount.
Resolve the deletion and rightsizing findings first. Commit only to the fleet that survives them.
The least reversible fix Parsivex suggests
Everything else on your report can be undone in an afternoon. Commitments cannot:
- Standard Reserved Instances can be modified within limits — availability zone, instance size inside a family, network platform — and in supported regions can be listed on the Reserved Instance Marketplace, at whatever price a buyer will pay.
- Convertible Reserved Instances can be exchanged for other reservations of equal or greater value, but cannot be sold.
- Savings Plans cannot be cancelled, exchanged, or sold for the whole term. The commitment runs to the end.
- RDS reserved instances cannot be sold or transferred at all.
No-upfront payment removes the cash outlay, not the obligation; you pay the hourly commitment every hour of the term regardless of usage.
The practical mitigation is to size the commitment against the trough of your usage rather than the average. Cover the capacity you are confident will still be running in eleven months, take the discount on that, and leave the rest on on-demand where it stays free to change. You can always add a second commitment later; you cannot remove the first.