FinOps in 90 days: a cloud cost reduction plan that actually ships
By HarmanJyot Kaur · August 4, 2026 · 9 min read
TL;DR
- In our experience across dozens of AWS and GCP accounts, 25–40% of cloud spend is recoverable in the first 90 days — without any architectural changes.
- The reason most cost optimization efforts stall: they start with reservations or architecture changes before they have visibility. The right order is visibility → rightsizing → commitment-based purchasing, in that sequence.
- A structured 90-day plan regularly delivers 25–40% bill reduction. Month 1 builds the instruments and the map. Month 2 cuts the obvious waste. Month 3 locks in the savings.
- This post is the week-by-week version. If you want someone to run this for you, see our Cloud Cost Optimization engagement.
Why cloud cost optimization fails
Most cloud cost programs die in month one. The pattern is consistent:
A CFO flags the bill. Someone is given ownership of “cloud cost reduction.” That person buys a FinOps platform, stares at a waterfall chart, and schedules a meeting to talk about Reserved Instances. Three months later, spending is flat, the FinOps tool has a renewal coming up, and the CFO asks why nothing changed.
The failure mode isn’t a lack of tools or intent. It’s sequence. Committing to Reserved Instances before you understand your actual utilization patterns is like buying a three-year lease on an office before you know how many people you’re hiring. You lock in your current waste at a discount.
The other failure mode is treating cloud cost as a one-time cleanup rather than an ongoing operational discipline. You find $50K/month in idle resources, terminate them, celebrate, and ship new infrastructure that recreates the same problem over the next six months.
FinOps done well is a practice with three phases — see, act, govern — applied in sequence, then repeated. The 90-day plan below operationalizes that.
Before you start: what 90 days can actually change
Before week 1, calibrate expectations. Ninety days is enough time to:
- Build real cost visibility (tags, cost allocation, per-team dashboards)
- Terminate idle and oversized resources
- Rightsize compute for workloads you understand
- Make the first round of Reserved Instance or Savings Plan commitments
- Establish budget alerts and governance so the savings hold
It is not enough time for architectural changes — moving a workload from EC2 to Lambda, redesigning a data pipeline, or replatforming to a managed service. Those compound the savings, but they take longer to design and execute safely. Put them in a parallel track for months 4–6.
One more precondition: you need one person with clear ownership. Not a committee. A single engineer or FinOps practitioner who is accountable for the 90-day outcome and has enough access to pull billing data and make sizing changes. Without this, nothing ships.
Month 1: visibility — you can’t cut what you can’t see
The goal of month 1 is not to save money. It’s to earn the right to save money by building a clear picture of what you’re spending and why.
Week 1: turn on the instruments
Start with the free native tools before spending on anything else.
AWS: Enable Cost Explorer (if it’s off), turn on hourly granularity in billing preferences, and enable the Compute Optimizer service in every region you run workloads. Set up an S3 Cost and Usage Report (CUR) export if you’re running multi-account or want to query billing data in Athena later.
GCP: Enable the Billing Export to BigQuery. Enable Cloud Recommender for Compute and GKE. Make sure every project has a billing account linked — unlinked projects are a common blind spot.
All clouds: Verify that your cost alerts are configured. You want a budget alert at 80% and 100% of expected monthly spend — not as an optimization mechanism, but as a smoke alarm. If spend spikes unexpectedly, you want to know before the end-of-month invoice.
By end of week 1: you have billing data flowing, recommendations loading, and alerts configured.
Week 2: build the cost allocation map
This is the week most teams skip — and regret.
Cost allocation means knowing whose workload is generating which spend. Without it, you’re optimizing averages rather than owners, and nobody feels responsible for reducing their number.
The mechanism is tagging. Decide on a tag taxonomy: at minimum, team, environment (prod/staging/dev), and project. Apply these tags to every resource that accepts them. For AWS, use Tag Policies via AWS Organizations to enforce new resource tagging going forward.
Once tags are applied, create cost allocation tags in the billing console and wait 24 hours for them to propagate into Cost Explorer. Then build a simple dashboard: spend by team, spend by environment, spend by service. Share it with engineering leads.
The act of showing engineers their own spend number is one of the highest-leverage things you can do. Most engineers have never seen a cost number attached to infrastructure they own — and most will start asking questions the moment they do.
By end of week 2: you have a tagged cost map and per-team spend visibility.
Week 3: run the first rightsizing analysis
Now run the recommendation reports. AWS Compute Optimizer, GCP Recommender, and Azure Advisor all surface instance rightsizing suggestions based on observed utilization. Pull these reports and triage them into three buckets:
- Easy wins (terminate): instances running below 5% CPU/memory for 30+ days with no attached load balancer. These are almost certainly orphaned dev instances, abandoned experiments, or workloads that were migrated but never shut down. Get approval to terminate and do it.
- Rightsizing candidates: instances running consistently below 40% utilization with a clear downsize recommendation. For each, verify the recommendation against the workload’s actual behavior (is there a weekly batch job that spikes it? a peak traffic window?), then schedule the resize.
- Defer: anything with high peak utilization, complex workloads, or shared infrastructure that needs broader alignment to change.
The terminate bucket typically delivers quick wins. We routinely find 8–15% of compute spend in idle resources on accounts that haven’t done this in 12+ months.
By end of week 3: idle resources identified and queued for termination; rightsizing candidates triaged.
Week 4: get stakeholder alignment with real numbers
Before you terminate anything significant or start making Reserved Instance commitments, you need a brief alignment meeting with the team leads and one finance contact. Show them:
- Current monthly spend by team/environment
- The idle resource list and projected savings from termination
- A realistic forecast for months 2 and 3
This meeting has two goals: get approval for the month 2 actions, and establish that these numbers will be reviewed monthly going forward. Without the review cadence, savings erode as new infrastructure gets provisioned without governance.
By end of month 1: you have visibility, a cost map, a termination list, and stakeholder buy-in.
Month 2: reduction — cut the obvious waste first
Month 2 is where the bill moves. You’re executing on what month 1 found.
Weeks 5–6: rightsizing and idle resource termination
Execute the termination list from week 3. Move fast on orphaned dev instances — the risk of terminating something that’s actually in use is lower than it feels, because anything genuinely in use will have a monitoring alert or a user who notices within an hour.
For rightsizing, schedule maintenance windows and resize the compute optimizer candidates. For Kubernetes clusters, rightsizing is node-level — which is why we cover this in depth in the Kubernetes cost optimization post — but the first lever is simply setting resource requests and limits accurately so the cluster scheduler can bin-pack efficiently.
Track the spend changes in Cost Explorer with a week-over-week view. Savings from terminated instances appear immediately. Savings from rightsizing appear within 24 hours of the resize.
Week 7: storage and data transfer audit
Compute gets the attention, but storage and data transfer are often 20–30% of the total bill and almost never audited.
Storage: Pull a list of all EBS volumes not attached to a running instance (orphaned snapshots are a subset of this). Run the S3 Storage Lens analysis to find buckets with no access in 90+ days. Check for S3 Intelligent-Tiering being applied — or not applied — to buckets with infrequent access patterns.
Data transfer: Data egress is one of the most consistently underestimated cost categories. Query your CUR or billing export for DataTransfer-Out-Bytes grouped by region. Cross-region and internet-egress transfer is often created by logging pipelines, backup jobs, or CDN misconfigurations that predate the current team and have never been revisited.
A single logging misconfiguration — sending logs cross-region instead of to the local region — can run $8–12K/month on an account with high log volume. We find at least one of these per account on our first cost audit.
Week 8: make commitment-based purchasing decisions
By week 8 you have 6–7 weeks of post-optimization utilization data. That’s enough to make Reserved Instance or Savings Plan commitments with reasonable confidence.
The decision framework:
- Savings Plans (AWS) are more flexible than Reserved Instances — they apply to any compute (EC2, Fargate, Lambda) and don’t lock you to an instance type or region. Start here if you’re not certain of your instance mix.
- 1-year, no upfront is almost always the right first commitment. The discount is smaller than 3-year or all-upfront, but you’re not betting your workload shape three years into the future.
- Commit to only the steady-state baseline — the compute you’re confident will run 24/7. Leave burst and variable workloads on on-demand.
- For GCP: Committed Use Discounts (CUDs) work the same way — commit vCPUs and memory, not instance types.
A common mistake: committing to a 3-year RI in month 2 of a cost optimization program. Your workload will change. Your architecture will evolve. Commit 1-year first, run another optimization pass at the 6-month mark, then consider whether to extend.
By end of month 2: idle resources gone, compute rightsized, first commitments placed.
Month 3: governance — lock in the savings
Month 3 isn’t about finding more savings. It’s about making sure the savings from months 1 and 2 don’t erode as the team keeps shipping.
Weeks 9–10: automate the recurring checks
The actions from month 2 were manual. The governance layer automates them so they happen without a person remembering to do it.
At minimum, set up:
- Weekly cost anomaly detection (AWS Cost Anomaly Detection or equivalent) with an alert to the engineering leads channel when spend in any service or team spikes more than 20% week-over-week.
- Monthly rightsizing report automatically delivered from Compute Optimizer to the team lead. It doesn’t have to be acted on every month, but it should be seen.
- Tagging enforcement: New resources missing required tags should either fail to provision (Tag Policy with deny) or generate a Slack alert via a Config rule. The second path is gentler and less disruptive to implement in week 9.
Week 11: set per-team budgets and ownership
A FinOps program without team-level accountability is just a centralized cost dashboard that nobody owns.
Work with finance to set per-team monthly cloud budgets based on the actuals from month 1. These don’t have to be tight — budget at 110–120% of current spend to start. The goal is to make engineers aware of a number they’re accountable to, not to create bureaucratic friction.
Publish the per-team spend dashboard to a shared location (a Confluence page, a Grafana board, a Slack weekly digest — whatever the team actually reads). Review it in the monthly engineering all-hands.
Week 12: the 90-day close
Run a full comparison: spend at start of month 1 vs. spend in week 12. Break the savings down by category — terminations, rightsizing, commitment discounts, storage/transfer cleanup. This is the number you present to the CFO.
Set the roadmap for months 4–6: architectural optimization opportunities that month 1 surfaced but couldn’t be acted on in 90 days (the pipeline that sends 2TB/month cross-region, the RDS instance that could move to Aurora Serverless, the Fargate tasks that could move to Spot containers).
A real example
A B2B SaaS startup came to us with a $26K/month AWS bill. They had grown from $8K/month over two years, and nobody had looked closely at what was driving the increase. No tagging, no budgets, no rightsizing history.
Month 1 delivered the map: $4.8K/month attributable to a data processing pipeline that had been spun up for a one-time customer migration in early 2024 and never shut down. The team who ran the migration had moved on; nobody knew it was still running. On top of that: $3.4K in EC2 instances running below 5% CPU for over 60 days, and $1.1K in orphaned EBS snapshots from instances that had been terminated months earlier.
Month 2: the pipeline was shut down immediately. Idle EC2 instances were terminated. The remaining compute was rightsized based on Compute Optimizer recommendations. A one-year Savings Plan covering the steady-state baseline saved an additional $1.8K/month versus on-demand.
Month 3: tagging and budget alerts locked it in. New 12-week projected spend: $15K/month — a 42% reduction, with zero architecture changes.
Trade-offs and what to skip
Don’t start with Spot instances. Spot is a great tool for fault-tolerant workloads — training jobs, batch pipelines, stateless workers. But the engineering work to make a workload Spot-safe (checkpointing, interruption handling, graceful draining) takes time. In a 90-day plan, Spot belongs in the later months, not the first two weeks.
Don’t try to rightsize databases. Compute rightsizing is low-risk — wrong instance size? Resize again. Database rightsizing requires careful performance testing, maintenance windows, and often a separate DBA sign-off. Flag the opportunities but don’t execute them under time pressure.
Don’t buy a FinOps platform in month 1. Evaluate platforms after you’ve done the first 90-day cycle with native tools. You’ll be a much better buyer — you’ll know what gaps the platform actually needs to fill for you, rather than buying on vendor-demo promises.
What to do next
The 90-day plan above is what we execute on every FinOps engagement. If you want a senior engineer to run it with you — or if you’d rather have us run it for you and hand over the governance framework when it’s done — that’s exactly what our Cloud Cost Optimization service covers.
We typically find 25–40% in recoverable spend in the first two weeks of a cost audit, before a single instance is resized. Book a 30-minute call and we’ll tell you what we’d focus on for your specific account.