Savings & optimization

Plutus surfaces four separate optimization signals: savings recommendations, waste detection, commitment utilization, and credit burn-down. Each answers a different question, and each has a boundary worth knowing before you act on it.

Savings recommendations

The /savings page lists two kinds of recommendation side by side, each labeled with its source, with no deduplication between them:

• Provider recommendations — read directly from each cloud’s own recommendation engine (AWS Compute Optimizer / Cost Explorer rightsizing, Azure Advisor, GCP Recommender). Plutus doesn’t compute these; it fetches, stores, and displays what the provider already computed.
• Plutus’s own rightsizing engine — runs nightly over resource inventory, utilization telemetry, and resource-grain cost. Unlike the provider passthrough, this one is Plutus’s own analysis.

Two recommendations for the same resource can disagree — AWS Compute Optimizer might say “downsize to m5.large” while Plutus’s engine says “no clear saving here” for the same instance. That disagreement is shown, not resolved, because it’s informative: it usually means the two engines are looking at different observation windows or weighting peaks differently.

Why recommendations decline rather than guess

Plutus’s own engine is written to decline a recommendation rather than emit a low-confidence one:

• A low average never overrides a high peak. An instance that averages 15% CPU but spikes to 90% during a daily batch job is not a rightsizing candidate, even though the average alone would suggest one. The engine looks at the percentile distribution, not just the mean.
• A saving it can’t size is not emitted. If the utilization telemetry for a resource is too sparse to compute a confident estimate, no recommendation is shown for it — there’s no low-confidence tier with a smaller dollar figure attached.

Every Plutus-sourced recommendation shows the observation window, sample count, and percentiles it rested on, so you can check the evidence rather than take the recommendation on faith. A provider recommendation doesn’t carry this — it shows whatever detail the provider’s own API returned.

Worked example: two EC2 instances both average 20% CPU over the past 30 days.

• Instance A’s utilization samples are tightly clustered around 20% — p50 and p95 both near 20%. Plutus recommends downsizing, with the observation window and sample count shown.
• Instance B has the same 30-day average, but its p95 is 85% — a recurring weekly job spikes it. Plutus emits no recommendation for instance B, even though the two instances look identical on average.

A provider engine looking only at the average might recommend downsizing both.

Waste detection

/waste is AWS-only. It runs Plutus’s own rules over a resource inventory, independent of the rightsizing recommendations above — waste detection asks “is this resource plausibly wasted spend at all”, not “should this resource be a different size.”

The rules cover: unattached EBS volumes, unassociated Elastic IPs, load balancers with no targets, orphaned snapshots, idle NAT gateways, and long-stopped instances. Each finding carries the evidence that produced it (for example, how long a volume has been unattached).

Severity reflects confidence, not the size of the saving. A $4/month unassociated Elastic IP can be a high-severity finding if the evidence is unambiguous, while a $200/month idle NAT gateway might be lower severity if there’s a plausible reason it’s kept around (for example, a disaster-recovery VPC that’s meant to sit idle). Don’t read severity as a ranking of dollar impact — sort by the savings estimate itself if that’s what you need.

Dismissal is per (resource, rule) pair, not per resource: dismissing “unattached volume” findings for a volume you’re intentionally keeping doesn’t suppress a different rule (say, “orphaned snapshot”) that later fires on the same resource. A dismissal takes an optional note and an optional expiry — set an expiry when the reason is temporary (for example, a volume you’re keeping through the end of a migration) so the finding reappears once it passes.

Commitment utilization

/commitment-utilization is AWS-only and answers a third, distinct question from the two above: not “what should you change” or “is this wasted”, but how much of what you’ve already bought (Reserved Instances and Savings Plans) is actually being used.

It’s a small number of periodic snapshots — one row per commitment type per month — rather than an open-ended list. A commitment you bought at 100% intended utilization that’s now running at 60% is losing money on the unused 40%, and this page is where that shows up. It doesn’t recommend a fix; it reports the number.

Both savings recommendations and commitment utilization ride as a non-fatal extra step after your normal AWS cost sync. If Plutus’s access is missing a permission these need, your cost sync still completes — you just see nothing on /savings or /commitment-utilization for that account until the permission is granted.

Credits & burn-down

Where a cost source has a credit balance (a startup program grant, a prepaid commitment, a promotional credit), Plutus tracks balance, burn rate, and projected exhaustion date per cost source.

Credits are shown beside spend, not netted into it — your cost charts show gross spend, and the credit balance is a separate figure next to it. Budget and overage enforcement also counts gross spend; a credit balance doesn’t pause an alert or budget threshold.

A runway that can’t be computed is absent, never zero or infinite. If there isn’t enough burn-rate history to project an exhaustion date, or the balance figure itself isn’t available, the runway simply doesn’t render — it’s not shown as “0 days remaining” (which would read as an emergency that isn’t real) or as no limit at all (which would hide a real one).

Price catalogue & what-if

GET /api/prices and GET /api/prices/compare serve an effective-dated catalogue of AWS, Azure, and GCP list prices, refreshed weekly for the regions your connected accounts actually spend in.

A comparison across incompatible units, price types, or currencies doesn’t guess at an answer — it returns comparable: false with a reason. Comparing an hourly on-demand rate in USD against a monthly reserved rate in EUR isn’t a single number you can trust, so Plutus doesn’t produce one.

What this doesn’t do

Every mechanism on this page is read-only advice. Plutus never resizes an instance, cancels a reservation, deletes an unattached volume, or purchases a commitment on your behalf. Automated remediation is a deliberate absence, not a gap waiting to be filled — granting write access to a customer’s cloud account is a trust position Plutus doesn’t ask for.