Cloud Cost Due Diligence: Can Infrastructure Support the Underwritten Margin?

A software target’s current cloud-spend ratio does not tell a buyer whether its infrastructure economics will support the underwritten margin.

Cloud cost due diligence should answer four questions:

1. What does the target’s consumed infrastructure actually cost after discounts, credits, prepaid commitments, support, marketplace purchases, and shared services?
2. Which customers, transactions, workloads, or AI requests drive that cost?
3. How will unit cost change as volume, product mix, customer concentration, reliability requirements, and AI usage change?
4. What do those changes mean for the forecast, transaction terms, and post-close plan?

The useful underwriting output is a cost curve, not a list of optimization ideas. It should show whether infrastructure costs are likely to grow slower than, in line with, or faster than revenue under the investment case.

Why the current cloud-spend ratio can mislead buyers

Cloud expense as a percentage of revenue is a useful starting point. It can also conceal the drivers that matter after close.

A favorable ratio may reflect temporary credits, light customer usage, deferred reliability work, or a discount that expires during the ownership period. An unfavorable ratio may reflect rapid onboarding, a recent migration, non-production environments, or prepaid capacity that distorts the monthly invoice.

Cloud billing can also separate cash timing from resource consumption. AWS reservation data, for example, can distribute upfront reservation fees across the affected billing periods and identify unused reserved quantities. Reviewing only the invoice month can therefore distort the operating baseline. ^[5] The FinOps Open Cost and Usage Specification defines effective cost as the amortized cost after applicable reduced rates, discounts, and relevant prepaid purchases, providing a useful normalization concept across billing structures. ^[4]

The deal team should distinguish three views:

• Economic cost: What did the infrastructure consumed during the period effectively cost?
• Cash cost: What was paid during the period, including upfront purchases and support charges?
• Forward exposure: Which rates, discounts, credits, and commitments will apply under new ownership?

Use economic cost to assess gross margin, cash cost to test liquidity and debt-service requirements, and forward exposure to determine whether historical economics can persist.

Step 1: Rebuild the effective-cost baseline

Invoices and general-ledger totals alone are usually not enough for this analysis. Buyers should request detailed billing and usage exports covering enough time to expose seasonality, growth, customer onboarding, and major architecture changes.

Google Cloud’s standard billing export can include account, service, SKU, project, label, location, usage, cost, credit, adjustment, and currency data. Its detailed export adds resource-level cost information, while separate exports cover pricing and committed-use-discount metadata. ^[10] Fields vary by provider, but the objective is consistent: reconcile the financial records to a workload-level view of consumption.

A practical diligence request should include:

• detailed billing and usage exports;
• invoices and general-ledger reconciliations;
• credits, refunds, negotiated discounts, and support charges;
• reserved capacity, savings plans, committed-use discounts, and upfront purchases;
• marketplace software and data services billed through cloud accounts;
• account, subscription, project, region, and environment mappings;
• tagging or labeling coverage;
• production, development, test, disaster-recovery, and internal workloads;
• architecture diagrams and major workload inventories;
• customer, transaction, API, storage, and AI-usage data needed for allocation;
• provider agreements, private-pricing terms, renewal dates, and transfer restrictions.

The reconstructed baseline should:

• spread prepaid purchases across their benefit periods;
• identify unused commitments;
• separate temporary credits from recurring economics;
• distinguish production from non-production consumption;
• expose costs that cannot be allocated to a product, customer, or workload.

Unallocated cost deserves attention. A shared-services bucket may be reasonable, but a large or unexplained one can mean management cannot identify which products or customers consume infrastructure. That limits both underwriting confidence and post-close accountability.

Step 2: Choose units that explain the business

Cloud unit economics translate technology spending into measures such as cost per customer, transaction, product, workload, service request, or token. ^[1][2] The right denominator depends on how the target delivers and prices value.

One denominator is rarely enough. FinOps distinguishes resource-efficiency measures, such as cost per gigabyte or token, from business-unit measures, such as cost per tenant, transaction, or resolved case. ^[2] Diligence often needs both levels to explain margin behavior.

For example, cost per token can help explain model efficiency. Cost per completed workflow shows whether the feature’s economics support its price. A lower technical unit cost may not improve margin if the workflow makes more model calls, usage rises, or the company cannot charge for incremental consumption.

Averages can also hide material dispersion. Buyers should examine unit cost by:

• product and module;
• customer segment and contract type;
• geography and hosting region;
• workload type;
• new and mature customer cohorts;
• ordinary and peak demand;
• highest-consumption customers.

A company can have acceptable average economics while a small number of fixed-price customers consume disproportionate infrastructure. In that case, what appears to be a cloud-efficiency problem may be a pricing and customer-concentration problem.

Step 3: Determine the shape of the forward cost curve

Once the baseline and allocation model are credible, diligence should identify what causes unit cost to move.

The key question is not whether the architecture uses modern technologies. It is whether resource demand and cost respond predictably to business volume.

Capacity and demand management

Autoscaling can improve economics when capacity follows workload demand. It is not proof of efficiency by itself. Scaling rules, minimum capacity, startup time, service limits, peak behavior, and downstream bottlenecks affect the result.

AWS identifies automatic scaling, throttling, buffering, and queues as ways to match resource supply to demand or smooth demand to reduce overprovisioning and cost. ^[9] In diligence, these mechanisms should be treated as financial drivers. A service that scales horizontally may still push cost into a database, data pipeline, observability platform, or network layer that scales poorly.

Database, storage, and data-transfer behavior

Database design can determine whether growth produces a gradual cost increase or a costly capacity step. Diligence should examine large instances, replicas, high-availability configurations, backup retention, storage growth, expensive queries, and any expected sharding or re-architecture.

Revenue may grow with customer count while infrastructure cost grows with data volume, retention, geography, or access frequency. The financial model should use the relevant technical demand driver rather than assume every cost moves with revenue.

Reliability and observability requirements

Historical margins may reflect a system that has not yet been built to the resilience, security, or service level required by larger customers. Added redundancy, disaster recovery, monitoring, logging, and support may be necessary, but they change the cost base.

This analysis should connect with technical debt due diligence. If the target has deferred work needed to sustain growth, the buyer should distinguish recurring infrastructure expense from one-time remediation investment.

AI consumption

AI-enabled products add another source of variability. Model selection, context size, repeated calls, retrieval architecture, agent loops, caching, fallback models, and customer behavior can all affect cost per completed workflow.

The FinOps Foundation’s 2026 survey included 1,192 respondents representing more than $83 billion in annual cloud spend. It reported that 98% manage AI spend and identified AI cost management as the leading skill-development priority. ^[3]

For a target, the relevant investment question is whether AI usage produces enough retention, pricing power, labor efficiency, or product value to cover its incremental cost. Buyers should connect cloud analysis with AI due diligence rather than evaluate model capabilities and economics separately.

Step 4: Stress-test the underwritten margin

The cloud-economics model should reconcile to historical results and then test cases tied to the investment thesis.

At minimum, buyers should evaluate:

1. Growth case: Revenue and usage reach plan with the expected customer and product mix.
2. Slower-growth case: Committed spending remains fixed while customer acquisition or usage falls below plan.
3. Peak-load case: Demand spikes require added capacity, data movement, or third-party services.
4. Customer-concentration case: High-consumption customers grow faster than their contract value.
5. AI-usage case: AI requests, context size, or multi-step workflows exceed product assumptions.
6. Pricing case: The company cannot pass through usage growth or reprice uneconomic contracts.
7. Provider-rate case: Credits expire, discounts change, or incremental consumption receives less favorable rates.
8. Reliability case: Enterprise growth requires more redundancy, observability, security, or regional deployment.

Each case should show:

• revenue;
• effective cloud cost;
• unit cost;
• gross margin;
• cash commitments;
• required engineering investment.

The model should also distinguish assumptions management can control from those driven by customers or provider terms. That separation helps the investment team adjust the forecast, the lender assess cash-flow sensitivity, the operating team set priorities, and management understand its post-close accountabilities.

Step 5: Review commitments as fixed exposures and operating constraints

Commitment discounts can improve margin when demand is stable and the purchased capacity fits the workload. They can create downside when the forecast or architecture changes.

Provider recommendations are not independent validation of the investment case. AWS states that its Savings Plans purchase analysis uses historical usage over a selected lookback period and does not forecast future usage. ^[6] A recommendation based on the seller’s historical environment may not account for a migration, customer loss, product retirement, redesign, or growth shortfall.

Contract terms matter as much as the discount. Microsoft states that Azure savings plans involve a fixed hourly-spend commitment for a one-year or three-year term and cannot be canceled or exchanged after purchase. ^[7] Google Cloud states that spend-based committed-use discounts cannot be canceled through the ordinary purchase process. Usage above the hourly commitment is charged at the regular on-demand rate, while usage below it leaves part of the commitment underutilized. ^[8]

For every material commitment, diligence should establish:

• committed amount, term, and expiration date;
• upfront or recurring payment structure;
• utilization and coverage by workload;
• cost of underutilization;
• rate applied above the commitment;
• portability across accounts, regions, services, or legal entities;
• interaction with private pricing and credits;
• treatment after a change of control or account restructuring;
• alignment with the planned architecture.

The buyer should model these commitments across the expected ownership period. A discount that improves the trailing period but expires shortly after close is not a durable margin advantage. A multi-year commitment to an architecture scheduled for replacement may constrain the value-creation plan.

How cloud findings should change the deal and ownership plan

Cloud findings should not end as observations assigned to the future CTO. Material findings should change the transaction, forecast, or execution plan.

Adjust the underwriting

The deal team may need to revise gross margin assumptions, separate recurring cost from temporary credits, normalize commitment amortization, or add reliability and architecture investment to the forecast.

Any adjusted EBITDA treatment should remain consistent with the accounting and quality-of-earnings analysis rather than being created independently by the technology workstream.

Address unresolved risk

If access is limited or a material contract remains unresolved, the buyer may seek more evidence, closing deliverables, contractual protection, or a valuation response. The appropriate mechanism depends on the transaction. The important point is to make the uncertainty explicit rather than bury it in a generic risk register.

Fund the value-creation plan

Optimization opportunities should be prioritized by economic effect, delivery effort, and business risk. Removing idle resources is different from redesigning a database, repricing customers, or migrating away from an uneconomic service.

Each initiative needs an owner, budget, dependencies, and realistic timing. The Private Capital Technology Decision Playbook provides a broader structure for turning technical evidence into an investment and execution decision.

Establish post-close accountability

Management should report a small set of measures connecting infrastructure performance to the investment plan, such as:

• effective cloud cost by product;
• cost per selected business unit;
• unit-cost dispersion across customer segments;
• commitment utilization and coverage;
• unallocated cost;
• AI cost per completed workflow;
• gross margin impact from high-consumption customers;
• realized savings against the approved operating plan.

These measures are more useful than a single cloud-budget variance because they show whether economic efficiency is improving as the company grows.

The investment question is whether the economics travel

A target can have capable engineers, a modern architecture, and reasonable current cloud spend while still carrying material margin risk. That risk may sit in customer behavior, pricing, commitments, product mix, or the infrastructure required for the next stage of growth.

Cloud cost due diligence should test whether historical economics travel into the buyer’s forecast. Reconstruct effective cost. Tie it to meaningful business units. Model how those units behave under growth and downside. Then translate the result into the price, protections, forecast, and operating plan.

That is the difference between identifying cloud savings and underwriting infrastructure economics.