Why most cloud cost cutting is a one-time exercise that decays within a quarter, and what it looks like to make rightsizing a continuous, data-backed practice instead.
Most cloud cost optimization projects follow the same arc: a FinOps push, a spreadsheet of oversized instances, a round of resizing, a temporary dip in the bill — and then, six to nine months later, the spend curve is back where it started. Not because the original rightsizing was wrong, but because it was a snapshot. Traffic patterns shift, new services launch provisioned generously "to be safe," and nobody revisits last quarter's sizing decisions until finance asks why the bill crept up again.
The underlying problem isn't the sizing exercise itself. It's that rightsizing is usually treated as a project with a start and end date, applied to a system that never stops changing. A cost model built on a point-in-time snapshot decays the moment traffic patterns move, which they always do.
The fix isn't a bigger spreadsheet or a more disciplined quarterly review. It's making rightsizing a continuous, automatically-refreshed function of actual usage — the same way you wouldn't set a monitoring threshold once and never revisit it.
There are, broadly, two ways an organization decides an instance is oversized. The first is guesswork dressed up as judgment: an engineer looks at a dashboard, eyeballs a CPU graph that looks mostly idle, and downsizes based on a glance. This works often enough to feel reliable and fails often enough to make teams cautious about doing it again — because the glance doesn't account for the monthly batch job that spikes utilization for six hours a quarter, and a downsize based on an incomplete picture becomes an incident.
The second approach is what Applicare's cost intelligence is built around: rightsizing recommendations backed by actual utilization data collected over a full 30-day window, not a glance at a live dashboard. A 30-day window is long enough to capture weekly cycles, month-end processing spikes, and the kind of intermittent load that a spot-check would miss entirely — which is precisely the load pattern that causes "safe-looking" downsizes to turn into incidents.
| Approach | Data window | Catches intermittent load | Confidence in the recommendation |
|---|---|---|---|
| Manual dashboard review | Point-in-time glance | No | Low — depends on when you looked |
| Quarterly FinOps audit | Snapshot, revisited infrequently | Partial | Medium, decays between reviews |
| Applicare cost intelligence | Continuous 30-day rolling actuals | Yes | High — backed by real utilization, not a glance |
The other half of cloud cost optimization isn't sizing — it's catching spend that shouldn't be happening at all: a runaway job, a misconfigured autoscaling policy, a forgotten dev environment left running. A pure dollar-threshold alert ("tell me if daily spend exceeds $X") suffers from the same structural weakness as a static performance threshold: it can't distinguish a legitimate traffic spike from a wasteful one, because a number alone carries no context about why it moved.
Applicare's Azure Cost Intelligence capability, for example, correlates spend anomalies directly with traffic and deploy events, rather than evaluating the dollar figure in isolation. A cost spike that lines up with a genuine traffic surge is a scaling decision working as intended. A cost spike with no corresponding traffic or deploy event is the pattern worth investigating — and the correlation is what tells you which one you're looking at, not the raw number by itself.
Illustrative example — not a verified customer figure
Consider a mid-sized environment running 200 EC2 instances at an average of $180/month each ($36,000/month in aggregate). If continuous 30-day utilization data shows that 40% of those instances are running at under 20% average CPU — a common pattern where capacity was provisioned for a peak that rarely recurs — and rightsizing brings those instances down one tier, a reduction in that range is directionally consistent with the 38% average AWS cost reduction reported after deployment. Your own ratio will depend on how conservatively your environment was originally provisioned.
The point of walking through that arithmetic isn't to promise a specific percentage — it's to show that the 38% figure isn't a marketing number pulled from nowhere. It's the plausible, and observed, outcome of replacing provisioned-for-peak guesswork with sizing based on what actually gets used.
The two headline figures in this paper come from different parts of the platform, worth being precise about. The 38% average AWS cost reduction is measured after deployment across customers using Applicare's AWS cost and customer-impact correlation capability, which ties each incident and cost signal to affected sessions, transactions, and spend, so cost decisions can be prioritized against actual business impact rather than raw dollar amounts alone.
The 35% average Azure cost reduction comes from Applicare's Azure Cost Intelligence capability specifically — the same feature described in Chapter 3, where spend anomalies are correlated with traffic and deploys, and rightsizing recommendations are backed by actual 30-day utilization rather than static instance-family guidance.
Both numbers describe averages across deployed customers, not a guaranteed outcome for any specific environment — provisioning discipline going in affects how much headroom there is to recover.
Compute rightsizing tends to get most of the attention in cost conversations, but database infrastructure is often the more over-provisioned category, precisely because resizing a database feels riskier than resizing a stateless compute instance — so teams provision generously once and never revisit it. Applicare's database platform capability extends the same cost discipline here: identifying unused indexes and over-provisioned database instances, with rightsizing recommendations backed by the same 30-day actual-usage model described in Chapter 2, rather than a one-time capacity-planning guess.
Because database instances are frequently the largest single line items in a cloud bill, and the ones teams are most reluctant to touch without confidence, extending continuous, data-backed rightsizing to this category tends to surface savings that a compute-only review misses entirely.
The throughline of this paper is simple: cloud cost optimization fails as a project and succeeds as a continuously running function. The 30-day rolling utilization window that backs Applicare's rightsizing recommendations doesn't reset after a review — it keeps updating, which means a service that grows into its current sizing gets flagged for a bump, and one that shrinks gets flagged for a cut, without anyone scheduling a quarterly audit to notice either.
That's the practical difference between guesswork and data-driven rightsizing described in Chapter 2: not a smarter one-time analysis, but an analysis that never goes stale, because it's never really finished.