How to Cut Cloud Spend 20% in 90 Days Without Migrating a Workload
Twenty percent in ninety days is aggressive. It is also common at companies with no prior FinOps effort. The number requires no migrations, no architectural rewrites, and no new headcount beyond a dedicated FinOps lead. What it does require is sequencing.
This is the sequence.
What does week 1 look like?
Baseline and instrumentation. Nothing gets cut in week 1; everything gets measured.
- Day 1 to 3. Wire up a cost management platform to AWS, GCP, Azure, and Kubernetes billing. Read-only IAM roles, billing exports, Kubernetes metrics agent. First data lands within 24 hours.
- Day 4 to 5. Pull the last 12 months of spend by service and by account. Identify the top 20 services by cost. These are where 80% of the savings will come from.
- Day 6 to 7. Publish the baseline. One number, prominently: current gross monthly spend, projected annual run rate. This is what the 20% cut works against.
No optimization decisions get made in week 1. The point is to prove that the numbers can be trusted before anyone acts on them.
What does the allocation phase look like?
Weeks 2 and 3. Get to 90% cost allocation.
- Week 2. Build the allocation rule stack. Start from tags, layer account defaults, add Kubernetes namespace mapping, split shared services by usage. Coverage should reach 85% by end of week.
- Week 3. Ship allocation rules for the remaining edge cases: NAT gateway, data transfer, marketplace charges, cross-region replication. Coverage reaches 92%+ by end of week.
Publish the per-team cost report at the end of week 3. This is when engineering teams first see their own numbers, and it is when the political case for the rest of the project either wins or loses. If the numbers are wrong or unclear, everything downstream stalls.
What does the cleanup phase look like?
Weeks 4 and 5. Delete what nobody uses.
- Orphaned load balancers. ALBs and NLBs with no target group targets healthy for 7+ days. Delete after 24-hour notification.
- Unattached EBS volumes. Volumes not attached to any instance for 30+ days. Snapshot and delete.
- Idle RDS instances. Databases with under 5% CPU utilization and no connections for 14+ days. Confirm with owning team, then downsize or delete.
- Unused Elastic IPs. Any EIP not attached to a running instance. Release.
- Orphaned snapshots. Snapshots older than 90 days whose source volume no longer exists. Delete after ownership check.
- Stale S3 buckets. Buckets with no access in 180+ days and no owner. Move to Glacier or delete after review.
Typical savings from cleanup: 2 to 4% of gross spend. Not glamorous, but it is real money and it happens fast.
What does the rightsizing phase look like?
Weeks 4 through 6, in parallel with cleanup. This is where engineering time is required.
The mechanic:
- Identify candidates. Instances with average CPU below 20% and memory below 40% over the last 30 days. This filter typically flags 15 to 30% of the fleet.
- Compute the recommendation. For each candidate, the next smaller instance size in the same family. Do not skip sizes; that is where reliability issues creep in.
- Assign to owning teams. One workload per ticket, one recommendation per ticket. Include projected savings and rollback instructions.
- Track completion weekly. If a ticket is open for more than 14 days, escalate to the team lead.
Typical savings from rightsizing: 4 to 7% of gross spend. Requires the most engineering coordination of any bucket, which is why it starts in week 4 and runs through week 6.
What does the commitment optimization phase look like?
Weeks 7 through 10. This is often the largest single savings bucket.
| Week | Action |
|---|---|
| 7 | Analyze current commitment coverage and utilization. Identify gaps. |
| 8 | Build a 12-month usage forecast. Compute the optimal commitment portfolio. |
| 9 | Purchase the first tranche of Compute Savings Plans, sized at 60% of steady-state baseline. |
| 10 | Purchase Reserved Instances for RDS, ElastiCache, and OpenSearch. Confirm month-over-month savings show up. |
Two rules to hold to.
- Do not commit above 75% of baseline. Ever. Overcommitting turns a saving into a permanent floor on the bill.
- Start with 1-year terms. Only shift to 3-year for the bottom 40% of the stack, and only after a full year of stable usage.
Typical savings from commitment optimization: 5 to 10% of gross spend. The wide range depends on how commitment-naive the starting state was; companies with zero prior commitments land at the top of the range.
What does the lock-in phase look like?
Weeks 11 and 12. This is where the savings become sustained rather than transient.
- Anomaly detection. Wire up per-service, per-team anomaly detection with alerts routed to team channels. This prevents future spend regressions.
- Weekly cost reports. Automated per-team summaries published every Monday. Not a dashboard; a rendered summary.
- Rightsizing guardrails. For any newly created instance, check the last 30 days of similar workloads for typical utilization. Flag if the new instance is more than 2x the historical baseline.
- Quarterly commitment review. Scheduled on the calendar, with defined inputs and outputs. Not an ad-hoc conversation.
- Written FinOps program doc. RACI, cadences, escalation paths, savings targets. Published internally so the program survives handoffs.
Skipping this phase is the number one reason 90-day savings do not stick. The optimization work is real, but without the lock-in practices, the underlying behaviors that produced the waste return.
What does the savings roll-up look like?
For a company at $2M per month gross cloud spend, targeting a 20% reduction.
| Bucket | Target savings | Dollar impact (annualized) |
|---|---|---|
| Orphaned resource cleanup | 3% | $720K |
| Rightsizing | 5% | $1.2M |
| Commitment optimization | 7% | $1.68M |
| Storage lifecycle policies | 2% | $480K |
| Network and data transfer fixes | 3% | $720K |
| Total | 20% | $4.8M |
Program cost: $500K per year. Net year-one savings: $4.3M. Payback: under 60 days from the start of the project.
The numbers are aggressive but not unusual. Companies with prior FinOps investment will see smaller absolute percentages but similar payback economics. Companies with none will typically see the top of every range.
What are the biggest risks to hitting the 20% target?
Three, in order of likelihood.
- Engineering time not allocated. Rightsizing requires engineering execution. If teams are not committed to the work in advance, week 6 will find zero rightsizing done and 5% of the target missed.
- Commitment purchase deferred. Buying commitments requires CFO sign-off in most companies. If the approval chain takes 4 weeks, the commitment savings do not land until month 5. Get pre-approval on the projected purchase envelope before week 1.
- Political pushback on allocation. The moment teams see their allocated cost, someone will dispute the numbers. Have the allocation rules documented and defensible before publishing the first team report.
None of these are fatal, but each can push the timeline out by 2 to 4 weeks. Plan for them explicitly.
The mistake to avoid
Ninety-day cost cuts fail when they try to compress work that inherently takes longer. Do not try to re-architect. Do not try to migrate workloads to a cheaper cloud. Do not try to ship a full unit economics model in the first quarter. All of those are worthy projects for months 4 through 12. In the first 90 days, sequence the work as allocation, cleanup, rightsizing, commitments, then lock-in, and take the 20% that is available without heroics. The heroic version is what stretches to 12 months and delivers half the savings.
Frequently asked questions
Is 20% in 90 days realistic for a mature FinOps company?
Not without architectural change. Companies with mature FinOps programs have already captured most of the low-hanging fruit, so 90-day gains are usually 5 to 10% on top of prior savings. The 20% target is for companies with no prior FinOps effort, or where a specific driver (over-committed Savings Plans, orphaned Kubernetes clusters, forgotten proof-of-concepts) is dragging down the baseline. Assess the starting maturity before setting the target.
What if we cannot get engineering time for rightsizing execution?
Focus the first 30 days on cuts that do not require engineering: deleting orphaned resources, canceling unused Savings Plans if the term allows, and enabling automated storage lifecycle policies. These are usually 5 to 8% of spend and require only platform team execution. Escalate the rightsizing plan to leadership if engineering time cannot be secured after the first month; a project blocked at week 5 will not finish at week 12.
Should we cancel commitments to save money?
Only if you are demonstrably over-committed and the commitments are near expiration. Canceling active Savings Plans is not possible; they run to term. For Standard RIs, marketplace sales are an option but usually recover only 85 to 90% of remaining value. The bigger opportunity is often re-shaping the commitment stack going forward: let expiring commitments lapse instead of renewing them at the same level, and buy the smaller amount actually needed.
How do we handle savings that require multi-team coordination?
Time-box the coordination. If a savings opportunity requires more than two teams to approve or implement, put a 14-day deadline on the decision and escalate to engineering leadership if it stalls. Coordination-heavy savings are the ones that most often slip past the 90-day window and never get realized. Better to skip a 5% opportunity than to spend a quarter on a 3% one that does not close.
What happens after day 90?
The savings need to be locked in with sustained practice, or they erode. Ship anomaly detection to catch spend regressions, publish weekly cost reports per team, and set a quarterly commitment review. Companies that hit 20% in 90 days but do not sustain the practices typically give back half the savings within a year. Treat day 90 as the start of the ongoing program, not the end of the project.
Every cloud dollar gets an owner
Pyrenis allocates 100% of AWS, GCP, Azure, and Kubernetes spend to the teams that create it, catches anomalies in hours, and ships savings with real numbers.
Request early access