AWS and Azure FinOps for Mid-Market: A Field Guide to Recovering 25–40% of Cloud Spend

Updated for 2026, The four cost drivers are unchanged, but a fifth one now compounds faster than any of them: vertical SaaS vendors repricing to per-agent and per-action meters. Pair this guide with our agent licensing meter field guide and the pre-renewal audit briefing before your next Q3 renewal cycle. Why your AWS bill is going up 18% a year The CFO of a 220-person regulated SaaS company called us last quarter with a number she could not explain. Her AWS bill had grown 18% year over year for three consecutive years, against headcount growth of roughly 6% and revenue growth of roughly 14%. Engineering leadership had told her, plausibly, that the company was scaling. Her finance instinct told her the line item was outrunning the business it was supposed to support. She was right. We have read enough of these bills to know the shape of the problem before we open the console. A mid-market AWS or Azure bill compounds for four reasons, and engineering is rewarded for none of them. The first is workload accumulation. Engineering teams are measured on shipping, not decommissioning. A workload that goes to production in 2022 is still running in 2025 because nobody owns the question of whether it should be. We have walked into accounts where 12% of monthly compute spend was attributable to staging environments belonging to projects that had been canceled, products that had sunset, and engineers who had left the company. The autoscaling group keeps running because the autoscaling group has nobody whose job it is to turn it off. The second source is commitment plans set at the wrong tier. Reserved Instances, Savings Plans, and Azure Reservations are sold by the cloud providers as discount instruments and treated by procurement as one-time decisions. They are neither. A commitment set at the company's December 2022 baseline, when a team was scaling aggressively, before an architecture migration, before a workload was rightsized, locks the company into paying for capacity it no longer needs at a discount that no longer matches the workload mix. We routinely audit accounts where the commitment portfolio is delivering 8–12% effective savings against on-demand pricing. With the same workloads and a re-laddered commitment portfolio, the same accounts could be delivering 28–34%. The third source is transit and data-transfer cost that nobody owns. Cross-AZ traffic, NAT Gateway egress, inter-region replication, S3 to internet, and the assorted small-cents-per-GB line items aggregate into a meaningful portion of the bill, frequently 6–12% in mid-market accounts, and they are nobody's responsibility. Engineering teams provision the architecture; finance teams see the line item; neither has the joint accountability to redesign the data path that is generating the charge. The result is a quietly growing cost center that grows with usage, not with revenue. The fourth source is the SaaS portfolio. Most of what a CFO calls "cloud spend" is not on AWS or Azure at all. It is on Datadog, Snowflake, MongoDB Atlas, Auth0, GitHub, Vercel, Sentry, PagerDuty, Postman, Linear, Notion, and the forty-odd other recurring B2B subscriptions that the engineering org has accumulated over the same three-year window. There is no renewals function for these vendors at most mid-market firms. Procurement does not own them; engineering procures them; finance sees them in the accruals and not in a portfolio view. They renew on auto-pay at last year's price plus an inflation kicker, and nobody negotiates them because nobody is responsible for negotiating them. These four compounding sources, orphaned workloads, mistuned commitments, unowned transit, and an unmanaged SaaS portfolio, are the reason a healthy mid-market business sees its cloud line item outrun every other operational expense year after year. None of them are engineering failures. All of them are operating-model failures. And all of them are recoverable, on the order of 25–40% of total spend, by the firms that treat the recovery as a finance function with engineering inputs rather than an engineering project with a finance audience. The four levers in cloud FinOps There are exactly four levers a mid-market firm can pull to recover cloud cost. They are not equally weighted. They do not produce savings on the same timeline. They are not owned by the same function. And the firms that announce a savings number on a press release have almost always pulled the wrong two and skipped the right two. We work the levers in the order below. Lever 1: Commitment management. Reserved Instances, Savings Plans, and Azure Reservations are the single largest source of recoverable spend in a mid-market account, typically producing 35–50% of total realized savings on a properly run optimization. The mechanics are dull and the discipline is what matters: a portfolio of overlapping commitments, laddered across one-year and three-year terms, sized to baseline (not peak) workload demand, with a re-laddering review every quarter. The firms that get this right treat commitments the way a treasurer treats a bond ladder, durable instruments, deliberately staggered, repriced on a schedule. The firms that get this wrong treat commitments the way a procurement team treats a software license: bought in a panic, oversized, and forgotten until renewal. Time to realize: 30–60 days for the first re-ladder; ongoing thereafter. Owner: finance, with engineering providing workload forecasts. Not engineering with finance approving, that's the inversion that produces the 8% portfolios. Lever 2: Rightsizing and idle reduction. This is the lever everyone reaches for first because it is the most legible. Identify oversized instances, identify idle resources, identify orphaned volumes and snapshots, decommission. In a mid-market account that has never been rigorously rightsized, this lever produces 15–25% of total savings. After the first pass it produces single-digit percentages on each subsequent pass. It is a one-time recovery on the orphan inventory and a continuous discipline on rightsizing. Time to realize: 14–45 days. Owner: engineering, with a defined rightsizing review cadence. The trap here is treating rightsizing as the whole project. It isn't. It's the visible portion of the iceberg. Lever 3: Architectural optimization. Storage tiering, compute family migration (Graviton, AMD, ARM-based instance families on AWS; equivalent on Azure), serverless conversion where it pencils out, data-transfer redesign, container density. These are real engineering projects with real timelines, and they typically produce 15–25% of total savings on a multi-quarter horizon. Time to realize: 90–270 days. Owner: engineering, with finance providing the business case for prioritization. The firms that try to lead with architectural optimization end up doing the engineering work but missing the commitment savings that should have been picked up in the first 60 days. The sequencing matters. Lever 4: Vendor and SaaS rationalization. The portfolio of B2B subscriptions adjacent to cloud, observability, data warehousing, identity, CI/CD, developer tooling, security tooling, typically produces 15–25% of total realized savings on a mid-market optimization, and almost none of that savings comes out of the AWS or Azure bill. It comes out of the eight-figure SaaS portfolio that finance has been treating as forty separate line items rather than a single category. Time to realize: 60–180 days, gated by renewal cycles. Owner: a renewals function that, in most mid-market firms, does not yet exist and has to be stood up. We come back to this in the next section because it is the lever the press-release firms skip and the lever the durable-savings firms make their largest contribution from. The relative weighting matters. A typical mid-market recovery on a $4M annual cloud spend, optimized end-to-end, looks like this in our engagement data: $480K from commitment management, $240K from rightsizing, $280K from architectural optimization, $300K from SaaS rationalization. Total: $1.3M, or roughly 33% of starting spend. The press-release version of the same engagement, where the firm cancels staging environments and announces a number, looks like $200K of rightsizing and a quiet $400K of unbooked compliance debt. Same starting spend; very different ending posture. The SaaS rationalization layer When a CFO uses the phrase "our cloud bill," she is almost always describing a portfolio that is half AWS or Azure and half a constellation of B2B SaaS subscriptions that engineering has procured over a three-to-five-year accumulation window. A typical 200-person mid-market firm runs 35–60 distinct SaaS contracts in the engineering and IT footprint alone, with another 40–80 across the business functions. The cloud-provider bill is the loudest. The SaaS portfolio is, very often, the larger number. We see four recurring patterns when we audit the SaaS layer. The first is the underused-license gap. A firm bought 200 Datadog APM seats two years ago when the engineering org was 200 strong; the engineering org is now 140; nobody has reduced the license count. A firm bought a Snowflake commitment based on a forecast that didn't materialize; consumption is running at 60% of the commitment; the contract auto-renews at the commitment level. A firm bought a Postman team plan, a Notion enterprise plan, and a Linear plan with seats provisioned for everyone who has ever joined the company, and the offboarding process touches Workday but doesn't touch the SaaS portfolio. We audit firms where 18–28% of total SaaS spend is attributable to seats, capacity, or features that are not being used. None of that spend is on AWS. All of it is recoverable. The second is the renewals-function gap. Most mid-market firms do not have anybody whose job it is to negotiate SaaS renewals. The contract was signed by an engineering manager three years ago; that engineering manager has moved on; the renewal lands in procurement's inbox 30 days before renewal date with no internal owner; procurement signs because the alternative is a service interruption. Renewals at this stage are 100% of list. A firm with a renewals function, even a fractional one, even a controller plus a calendar plus a playbook, recovers 12–22% of contract value at every renewal cycle, partly through right-sizing and partly through actual price negotiation, which the major SaaS vendors expect from any account managed seriously and do not extract from accounts that are not. The third is the observability tooling sprawl. Every mid-market firm we audit runs at least two and frequently three overlapping observability tools. Datadog plus New Relic plus Grafana Cloud. Honeycomb plus Sentry plus an internal Prometheus. Splunk plus Sumo Logic plus CloudWatch Logs Insights. The overlaps were never consolidated because each tool was procured for a specific need and the consolidation question was never asked. The full-picture rationalization on observability alone is frequently 30–45% of the observability category, and it is the single highest-yield SaaS-rationalization workstream in our practice. The fourth is the identity and developer-tooling sprawl. Auth0 plus Okta plus an internal SSO. GitHub plus GitLab plus Bitbucket because of an acquisition. Three CI/CD tools. Two artifact registries. The firms that grew through acquisition or that grew quickly without architectural governance accumulate this sprawl and pay for the duplication every month. The rationalization here is more disruptive than observability, identity migrations and CI/CD migrations are real engineering projects, but the recurring savings are durable. The pattern across all four: the SaaS portfolio is large, it is poorly governed, it renews on autopilot, and the firm does not have a renewals function. Standing up that function, whether internally or as a managed service, is the single highest-leverage operating-model change a CFO can make in the cloud-cost-recovery program. It is also the lever that the press-release firms skip, because canceling a workload makes a number; renegotiating a Snowflake contract takes nine months and produces a number you can't put in a press release until the next renewal. The reservation and savings-plan trap We have walked into accounts where the previous cost-optimization engagement produced a press-release-quality savings number by aggressive commitment buying, and the next CFO inherited the bill. The pattern is consistent enough to name. A consulting firm comes in, recommends a heavy three-year all-upfront commitment posture across the largest workload categories, and books the accounting savings against on-demand pricing. The CFO who signed the engagement leaves. The architecture migrates over the next 18 months. The commitment portfolio doesn't match the workload it was sized for. The new CFO discovers that 40% of the company's cloud spend is locked into commitments that don't apply to the workloads actually running, and the unutilized commitment is being burned regardless. The "savings" was an accounting artifact; the lock-in is real. The defensible commitment posture for a mid-market firm with a normal rate of architectural change, meaning, a firm that will probably migrate at least one significant workload per year, will probably adopt at least one new instance family per 18 months, and will probably make at least one acquisition or divestiture in any three-year window, is not all-three-year-all-upfront. It is a layered ladder. We use a 60/30/10 model with our cloud-cost-recovery clients. Sixty percent of the commitment portfolio sits in one-year Savings Plans or Reserved Instances, sized to the 12-month forward baseline. These are durable enough to capture meaningful discounts (one-year terms still get 30–40% off on-demand) and short enough to re-tune annually as the workload mix changes. Thirty percent sits in three-year Compute Savings Plans (AWS) or three-year Reservations with flexibility (Azure), sized to the load that has been demonstrably stable for at least 18 months and is unlikely to migrate to a different instance family. The discount is meaningfully better, 50–60% off on-demand, and the lock-in is acceptable on workloads that have proven they aren't going anywhere. Ten percent is held in reserve as on-demand to absorb growth, new workload onboarding, and architectural experiments. That ten-percent on-demand buffer is not a failure of optimization; it is the cost of optionality on a portfolio that needs to absorb change. The 60/30/10 model produces a portfolio-level effective discount of 38–44% against on-demand, against a 50–55% theoretical maximum on an all-three-year posture. The four to ten percentage points of forgone discount is the price of not handcuffing the next CFO to a portfolio that doesn't match the next architecture. We pay it on every engagement, and the engagements where we did not pay it, early in the practice, before we had run the numbers across a full architectural migration cycle, are the ones we point to as cautionary tales when a client asks why we won't sign off on the more aggressive posture the cloud-provider account team is pitching. The cloud providers' account teams are aligned on aggressive commitment posture because the cloud providers' compensation structure rewards commitment dollars, not customer success on the resulting bill. That is not a moral failing; it is a structural fact. The firm's job is to acknowledge it and sign the commitments it can defend across an architecture cycle, not the commitments that maximize the discount on this quarter's run rate. Multi-cloud cost optimization realities Multi-cloud cost arbitrage, moving workloads between AWS and Azure (or GCP) to capture price differentials, is one of the most consistently oversold ideas in mid-market FinOps. We have run the numbers across more than fifty mid-market clients. Below roughly $5M in annual cloud spend, the math does not pencil out. The migration cost, the dual-platform engineering tax, the duplicated tooling, the duplicated runbook investment, and the duplicated commitment posture cost more than the price differential the arbitrage was supposed to capture. The firms that try it at $2M annual spend produce migration projects that take 14 months and recover the migration cost in year three, by which time the price differential has shifted again. It is the kind of project that looks compelling in a deck and produces a footnote in the post-mortem. There are two scenarios where multi-cloud is genuinely worth the operating cost. The first is regulated workloads with data-residency or sovereignty constraints that one provider can satisfy and the other cannot in a specific region. We see this in some state-government-adjacent workloads, some federal-adjacent workloads where the FedRAMP posture differs by provider, and some healthcare workloads where a specific BAA-covered service is only available on one provider. In those cases the multi-cloud posture is not arbitrage; it is the only viable architecture. The cost premium is the price of being able to serve the workload at all. The second is M&A integration. A firm that acquires a target running on a different cloud has a temporary multi-cloud posture by acquisition, and the question is not whether to be multi-cloud but how long the integration window should be. The CFO's question in this scenario is the right one: how much does it cost to run both clouds for 6, 12, or 24 months, and what is the migration cost to consolidate to a single provider on each timeline. The answer is almost always to consolidate within 18 months, the dual-platform tax compounds, but to pace the migration so the engineering organization does not stall its product roadmap to absorb the integration. We have done the modeling on enough M&A integrations to have a defensible point of view: the consolidation case is real, the timing case is more nuanced than the consolidation case usually admits, and the firms that try to consolidate in six months break their roadmap and the firms that try to consolidate in 36 months pay the dual-platform tax for 30 months they did not have to. The third scenario that comes up in conversation, and that we generally argue against, is "multi-cloud for negotiating leverage." The theory is that holding workloads on a second cloud gives the firm leverage in commitment negotiations with the primary cloud. In practice, the cloud providers' account teams know the firm's workload distribution from their own data; the leverage is largely illusory; and the real cost of running the second cloud meaningfully exceeds the marginal negotiation discount. We have seen one engagement out of fifty where the negotiating-leverage theory produced a defensible result, and that engagement was at $40M annual spend, not $4M. For the mid-market regulated firm or the PE portfolio company, the recommended cloud posture is single-cloud-primary with a documented secondary for specific regulated or M&A-driven exceptions. Optimize the primary cloud aggressively. Treat the secondary as an exception architecture, not a strategic posture. The math improves with scale; below $5M annual spend, single-cloud is almost always the right answer. The 10-day cloud cost teardown When a CFO engages us on the Cut-Cloud-and-SaaS-Spend Diagnostic, we run a 10-day cost teardown against the cloud and SaaS portfolio. The output is a written report the CFO can hand to the board, the controller, or the next operating partner. The structure is below; we publish it because it is more useful as a reference than as a sales pitch, and because a finance team with capacity can do most of it internally. Days 1–2: Bill ingestion and category mapping. We pull twelve months of AWS Cost and Usage Reports or Azure cost exports, plus the trailing twelve months of SaaS contract value across the engineering and IT footprint. We map every dollar to a category: compute, storage, transit, managed services, observability, data warehousing, identity, developer tooling, security tooling, productivity. Output: a single category-level cost ledger with month-over-month trend. Days 3–4: Commitment portfolio audit. We pull every Reserved Instance, Savings Plan, and Azure Reservation. We compute portfolio coverage, portfolio utilization, effective discount versus on-demand, and the ladder structure across one-year and three-year terms. We compare the current portfolio against a re-laddered 60/30/10 portfolio sized to the trailing 90-day baseline. Output: a commitment gap register with quantified savings. Days 5–6: Workload and rightsizing inventory. We pull instance-level utilization for the top 80% of compute spend by dollar, identify rightsizing candidates, identify idle resources, identify orphan storage, and identify candidates for compute-family migration (Graviton, AMD). Output: a rightsizing target list with effort estimate and projected monthly savings. Days 7–8: SaaS portfolio audit. We pull every SaaS contract over $10K annual, compute seat utilization where the data is accessible, identify renewal dates and contract terms, and identify consolidation candidates across observability, identity, developer tooling, and data warehousing. Output: a SaaS rationalization plan with renewal-by-renewal sequencing. Day 9: Architectural optimization candidates. We identify the top architectural optimization opportunities, storage tiering, transit redesign, serverless conversion, container density, and quantify each one against a multi-quarter timeline. We do not commit the firm to architectural projects; we surface them so the CFO can prioritize alongside the engineering roadmap. Output: an architectural opportunity register. Day 10: Sequenced recovery plan. We deliver a 25–40 page written report. The first 10 pages are a sequenced action plan: what to do in the first 30 days (commitment re-laddering, idle decommissioning), the next 60 days (rightsizing pass, observability rationalization), the next 180 days (architectural optimization, renewal cycle SaaS recovery). The remaining pages are the supporting analysis and the data appendix. The CFO can hand the report to the controller and the engineering VP and they can execute against it without us. We run a 60-minute walkthrough with leadership and provide a 30-day clarifying-question window. The 10-day teardown is what the Cut-Cloud-and-SaaS-Spend Diagnostic is. It is fixed-scope and fixed-price. It is not implementation. It is not an ongoing engagement. It is a written assessment that produces a sequenced recovery plan a competent finance and engineering team can execute. Where the firm wants implementation help, we have a separate executory engagement; the diagnostic stands on its own and we recommend many firms do the implementation internally. Where the diagnostic fits, and what a CFO can do this quarter The recovery range we quote, 25–40% of total cloud and SaaS spend, is a function of starting condition, not engagement intensity. A mid-market firm at $1–3M annual cloud spend that has never run a serious optimization is consistently at the high end of that range; a firm at $5–10M that has done one optimization in the last 24 months but did not pull the SaaS lever is consistently at the middle; a firm at $10M+ that has ongoing FinOps maturity is at the low end and the recovery comes mostly from the SaaS portfolio. The range narrows with scale because the well-run portfolios exhaust the easy wins faster. Diminishing returns are real. The first optimization on a previously unmanaged portfolio recovers 25–40%. The second, run 12–18 months later, recovers 8–14%. The third, on the same cycle, recovers 4–8%. After the first two cycles the discipline has to shift from periodic optimization to continuous FinOps, a renewals function, a quarterly commitment review, a monthly rightsizing review, a category-level budget owner, and the savings become embedded in the operating model rather than booked as a recovery. That transition is where most mid-market firms stall. The first optimization is exciting; the second is satisfying; the discipline of the third and beyond is unglamorous and is consistently underinvested. Where the Diagnostic fits. The Cut-Cloud-and-SaaS-Spend Diagnostic is the right engagement for a CFO who wants a sequenced, defensible recovery plan that the controller and the engineering VP can execute, a CFO who has inherited a portfolio she does not yet have a point of view on, or a PE operating partner who needs a 10-day read on a portfolio company's cloud cost posture as part of post-close optimization. It is fixed-scope, fixed-price, and produces a written report. It is not a retainer. It is not an implementation engagement. It is the diagnostic that tells the CFO what to do, in what order, and why, and the firm executes against the plan with us, with someone else, or internally. Where a firm wants more, a productized vCISO retainer that pairs the cost discipline with the broader risk and compliance posture, an executory engagement on the SaaS renewals function, those exist, and they are separate. Three actions any CFO can take this quarter, regardless of whether they engage us: 1. Run the commitment portfolio audit. Pull every Reserved Instance, Savings Plan, and Azure Reservation. Compute portfolio coverage, utilization, and effective discount against on-demand. If the effective discount is below 30%, the portfolio is mistuned. If portfolio utilization is below 90%, commitments are being wasted. The audit takes a competent finance analyst three to five days. The output is a defensible re-laddering plan that the engineering team can validate against the 12-month forecast. Most firms find at least one significant misalignment on the first audit. 2. Stand up a SaaS renewals function. It does not have to be a full-time hire. It can be a controller plus a calendar plus a playbook plus a quarterly review with the engineering VP. The function owns three things: the contract inventory (every SaaS over $10K annual, with renewal date and contract terms), the seat-utilization data (where it is accessible from the vendor), and the renewal-cycle negotiation. Even at a fractional-effort posture, the function recovers 12–22% of contract value at every renewal. The firms that do not have this function are paying list price on a portfolio that is, in aggregate, the largest single category of recoverable spend they own. 3. Establish category-level budget ownership. Compute, storage, transit, observability, data warehousing, identity, developer tooling, security tooling, each category needs an owner who is accountable for the trend line month over month, not just a finance team that sees the aggregate bill and an engineering team that sees the consoles. The ownership model is what converts a one-time recovery into durable discipline. Without it, the savings booked in the first optimization cycle erode over the following 18 months as the operating-model failures that produced the original drift reassert themselves. Three actions, ninety days, no engagement required. If the audit, the renewals function, or the ownership model surfaces gaps the firm cannot close internally, or if the recovery target is large enough that getting the sequencing wrong is expensive, that is where the Diagnostic comes in. Ten business days, fixed-price written report you keep regardless. The Cloud and SaaS Cost Audit Worksheet paired with this guide gives you the working template we use on the first two days of the engagement: a category-level cost ledger, a commitment-portfolio audit grid, a SaaS contract inventory with renewal-date sequencing, and a rightsizing target list with the same effort-estimate columns we use internally. Run it on the trailing twelve months of bills before the next budget cycle. Run it again before the next renewal window. Update it quarterly as the portfolio moves, and we will keep doing the same on our side.