A 90-day FinOps onboarding plan for companies without a FinOps practitioner

A FinOps practice without a dedicated practitioner is a part-time responsibility for an existing engineer (typically platform engineering), structured around four practices that fit in 25-30% of one person's week. This is the 90-day plan we use to stand up that practice. It assumes you have read our pillar on mid-market FinOps; this post is the operational sequencing.

Why this exists

Most FinOps content assumes you have someone whose job is FinOps. At mid-market scale (50-500 person companies, cloud spend $30k-$1M/month), the math doesn't justify a dedicated hire. The practice has to be built on existing capacity.

The trap when there is no dedicated owner: the work happens reactively (the bill spikes, someone scrambles), or it happens once and decays (a quarterly review that was scheduled stops happening), or it gets distributed so widely that nobody owns it. None of these produce sustained savings.

The 90-day plan below addresses this by:

• Concentrating the high-effort setup work in a defined window
• Naming a specific owner with explicit time allocation
• Building habits that survive the absence of a dedicated team
• Measuring what matters week-to-week, not month-to-month

This is not a maximalist plan. We are explicitly leaving things out — sophisticated chargeback, multi-cloud unified attribution, custom dashboards — that don't pay back at this scale and within this time budget.

Prerequisites

Before day one:

• Named owner. A specific engineer (typically on the platform team) who has explicit allocation of 1 day/week for the next 90 days, with their manager's agreement that this displaces other work.
• Executive air cover. A VP or C-level (often the CTO or CFO) who has stated that this practice is a priority and is willing to back the owner when other priorities push back.
• Access. The owner has read access to the cloud billing, Cost Explorer / equivalent, and the cloud account-level resources. Write access for tagging, lifecycle actions, and commitment purchases.
• Budget agreement. Finance is bought in on what the practice is supposed to do. Specifically: are you trying to reduce spend, attribute spend, or both?

If any of those is missing, fix that first. The plan does not work without them.

The 90-day plan

Three phases of approximately 30 days each:

Phase 1: Visibility (Days 1-30)

The phase produces no savings directly. It produces the foundation for everything that follows.

Days 1-7: Audit current state.

• Pull the last 90 days of billing data into one place (cloud-native cost surface, simple BI tool, or even a sheet at small scale).
• Categorize spend by service. Identify the top 5-8 services that represent ~80% of the bill. These are the focus.
• Run a tagging audit. What percentage of resources have a team, product, and environment tag? Document the gap.
• List existing FinOps-related tooling (Cost Explorer alerts, any vendor tools, manual reports). Document what exists.

The output of week 1 is a one-page document: current spend by service, current tagging coverage, current tooling. Share it with the executive sponsor.

Days 8-14: Establish tagging discipline.

• Define the required tags (team, product, environment is the minimum; some organizations add cost-center, compliance-tier).
• Update infrastructure-as-code modules to require these tags at provision time.
• For Kubernetes, deploy Kyverno or a similar policy engine to require the tags as labels on namespaces and deployments.
• Bulk-tag existing resources via a script. For each untagged resource, contact the inferred owner; tag based on response.

Aim for 95%+ of new resources tagged automatically. Aim for 90%+ of existing resources tagged within the phase.

Days 15-21: Attribution and reporting.

• Build a simple per-team monthly spend report. Cloud-native dashboards work; a Looker/Metabase dashboard against the cloud's billing export works. The format matters less than the cadence — a report nobody reads is wasted effort.
• Distribute the report to engineering leadership monthly. Make it easy to read; one team's column at a time.
• Schedule a 30-minute quarterly review with each engineering team to walk through their attributed spend.

Days 22-30: Anomaly alerting.

• Set up cost anomaly alerts. AWS Cost Anomaly Detection, GCP's quota and budget alerts, Azure's anomaly alerts — all native, all free.
• Send to the practice owner's Slack channel (or email). Tune sensitivity for the first month; expect false positives initially.
• Document the alert response process: who triages, what actions are available, when to escalate.

Phase 1 completion criteria:

• [ ] Tagging coverage above 90%
• [ ] Per-team monthly spend report exists and is distributed
• [ ] Anomaly alerts active and triaged
• [ ] One-page state document updated and shared with executive sponsor

Phase 2: First-pass optimization (Days 31-60)

This phase produces the single largest savings of the engagement. The order matters: lifecycle first (decommissioning is fastest and least risky), then rightsizing, then any quick wins on services that emerged from Phase 1.

Days 31-37: Lifecycle audit.

• Identify idle resources (CPU < 5% for 14+ days, attached to nothing, no recent activity).
• Identify orphaned resources (snapshots without volumes, AMIs unreferenced, NAT gateways with no traffic).
• Identify forgotten projects (workloads from initiatives that ended; ask owners; default to decommission after 14-day notice).
• For non-prod environments: implement scheduled scale-down outside business hours.

The lifecycle work in week one of phase two typically captures 7-14% savings. For most mid-market customers, this is the largest single batch of savings in the entire 90 days.

Days 38-44: Compute rightsizing — top 20 resources.

• Use AWS Compute Optimizer / GCP Recommender / Azure Advisor to surface rightsizing recommendations.
• For Kubernetes: deploy VPA in recommendation-only mode; let it observe for at least 7 days before acting on its output.
• Apply high-confidence rightsizing recommendations on the top 20 resources by spend. Skip the long tail; the cost-to-effort ratio is bad for small resources.
• Track the savings as resources are resized.

Days 45-51: Storage and managed-service rightsizing.

• Storage tier review (S3 intelligent tiering, EBS gp2 -> gp3 migration where applicable, lifecycle policies for cold data).
• Database rightsizing (RDS instance class, OpenSearch sizing, Redis tier).
• Managed-service-specific reviews (Lambda memory configuration, DynamoDB capacity mode, etc.).

The storage and managed-service work usually surfaces another 5-10% savings, less concentrated than the compute lifecycle work but real.

Days 52-60: First-pass review.

• Total the savings captured. Compare to the original spend by service.
• Update the per-team spend report to reflect the new baseline.
• Document the changes made (what was decommissioned, what was rightsized) in a place accessible to the engineering team.
• Plan Phase 3 commitments based on the new steady-state baseline.

Phase 2 completion criteria:

• [ ] Top 20 resources rightsized (or formally deferred with reason)
• [ ] Lifecycle audit complete; idle resources removed; non-prod scheduled
• [ ] Storage and managed-service tier review complete
• [ ] Total savings from phase quantified and reported

For a typical mid-market customer starting from a previously-untuned state, expect 18-32% reduction in monthly spend by end of Phase 2.

Phase 3: Sustaining practice (Days 61-90)

The practice must outlive the 90-day setup window. This phase puts the structure in place for that.

Days 61-67: Commitment analysis and purchase.

• Compute the trailing-90-day baseline of On-Demand compute spend, post-Phase-2 optimization.
• Recommend a commitment level (default: 60-70% of baseline on 1-year terms). For AWS, use Compute Savings Plans for flexibility. For GCP, use flexible Committed Use Discounts. For Azure, use Reserved Instances or Savings Plan.
• Review with finance. Get budget approval and execute the purchase.

The commitment work delivers another 17-28% discount on the covered baseline. Visible in the next month's bill.

Days 68-74: Process documentation.

Document the recurring practice work:

• Monthly: Lifecycle audit (who runs it, what's the checklist, where are results posted)
• Monthly: Per-team spend report distribution
• Quarterly: Top-25 rightsizing review
• Quarterly: Commitment level reassessment

The documentation goes into the engineering wiki, owned by the practice owner. It is short — a one-page checklist per recurring activity. Long process documents do not get followed.

Days 75-81: Handoff and capacity check.

• Confirm the practice owner has the time allocation explicitly set on their work plan. The 25-30% must be defended against other priorities.
• If the original owner is moving on or had a temporary allocation, identify the next owner and run the handoff.
• Schedule the first three months of recurring activities on the calendar. Without scheduled time, recurring practice decays.

Days 82-90: 90-day review and forward planning.

• Total savings captured over the 90 days.
• Compare to the spend trajectory before the practice started; project what the next quarter would have looked like without intervention.
• Identify the next-quarter focus areas (one architectural improvement, one tool consideration, one new attribution dimension if needed).
• Present results to the executive sponsor.

Phase 3 completion criteria:

• [ ] Commitment in place at appropriate level
• [ ] Recurring process documented and scheduled
• [ ] Owner allocation confirmed for ongoing
• [ ] 90-day results presented to executive sponsor

What this plan deliberately leaves out

The plan does not include:

• Sophisticated chargeback. At mid-market scale, showback (visibility) is enough; chargeback (formal cost allocation as a financial event) adds complexity that doesn't pay back.
• Custom dashboards. Native cloud surfaces plus a single per-team report cover the visibility need. Custom dashboards can come later.
• Multi-cloud unification. If you are multi-cloud, run the plan per cloud. Unified multi-cloud reporting is a separate project.
• Vendor tooling beyond what's listed. The 90-day plan can be done with native tools and a small handful of free or low-cost additions (ProsperOps if commitment automation is desired). Larger vendor tools are evaluated after the practice is in place.
• Workload-architecture changes. Migration to spot, serverless, or different compute models that reduce cost are real options but live in a separate engineering planning track. The 90-day plan focuses on what doesn't require code changes.

We have seen organizations attempt all of these in the first 90 days. None of them complete on time. The practice ends up half-built and the savings are unrealized.

Common failure modes

In the engagements we've run that didn't go to plan, the failure modes cluster:

• Owner not given allocation. "Run FinOps in your spare time" produces nothing. The 25-30% must be explicit and protected.
• Phase 1 skipped because "we already know where the money goes." The actual visibility work always surfaces things that were not known. Skipping Phase 1 means Phase 2 targets the wrong things.
• Phase 3 deferred indefinitely. Commitment work feels less urgent than rightsizing. Deferred, it never happens. The savings are real and recurring; do it.
• Executive sponsor disengages mid-engagement. The practice loses defense against competing priorities. The owner gets pulled to other work.
• Tooling decision made too early. Evaluating CloudKeeper / Vantage / Cloudability in week 2, before there is data to evaluate against, produces premature commitment.

What success looks like at day 90

At successful completion of the 90-day plan, you have:

• 18-32% reduction in monthly cloud spend, sustained
• Per-team attribution at 90%+ of spend
• A documented, scheduled, named-owner practice running ongoing at 25-30% of one engineer
• A committed-capacity baseline at appropriate level for the workload
• A quarterly cadence for the next year of optimization work

The savings continue post-engagement. The practice prevents the slow re-accumulation of waste that happens without sustained attention.

What to do after day 90

The practice runs ongoing. The next-quarter focus areas typically include one of:

• A specific service deep-dive (Snowflake, Databricks, EKS, RDS — whichever is the largest line item not yet exhaustively optimized)
• An attribution refinement (per-customer cost for unit-economics analysis, per-feature cost for product decisions)
• A vendor tool evaluation if the in-house practice's limits become visible
• A multi-cloud or architectural change that requires more substantial engineering investment

FAQ

Q: We don't have an executive sponsor. Can we do this anyway? You can start the visibility work without a sponsor. The optimization work is harder to land without sponsor backing because it touches teams' running infrastructure. Get a sponsor before Phase 2 if at all possible.

Q: We are already 30 days into our own attempt. Can we skip Phase 1? Audit what you have. If tagging is above 90% and a per-team report exists, you've done Phase 1; proceed. If either is missing, finish that work before starting Phase 2.

Q: Our cloud spend is under $30k/month. Is this still worth doing? The framework still applies. The time investment may not pay back at small scale; the four-practice rigor produces 5-10% savings on small accounts vs 25-30% on larger ones. If the engineer hours are scarce, run a lighter version focused on lifecycle and commitment.

Q: Can we do this with a contractor instead of an internal engineer? For Phases 1 and 2, yes. For Phase 3 (sustaining), the practice needs an internal owner who is present continuously. A contractor handing off to an internal owner at day 60 works in our engagements; pure-contractor with no internal continuity does not.

Q: What if we're using GCP or Azure, not AWS? The plan is cloud-agnostic. Substitute the equivalent native surfaces (GCP Cost Management + Recommender, Azure Cost Management + Advisor) and the equivalent commitment products (CUDs, Reserved VM Instances). The phases and timeline are the same.

*For the broader framework this fits into, see our pillar on FinOps for 50-500 person companies. For the specific service-level optimization patterns, see EKS cost optimization and Snowflake cost optimization.*