Cloud costs in technical due diligence: what the AWS bill reveals

The cloud bill is the one document in a technical due diligence data room that nobody rewrote for the process. The architecture diagram was redrawn last month, the roadmap was reshaped around the raise, and the security policy was written for a questionnaire. The AWS invoice was generated by a machine on the first of the month and paid by finance without ceremony. In our audits we ask for twelve months of it, by service and by account, before anything else about infrastructure.

It tells us how the system is built, how the team operates it, and whether the margin in the model survives growth.

Hosting as a share of revenue, and where that share is heading

The first number takes a spreadsheet and ten minutes: infrastructure spend divided by revenue, month by month. For a mature SaaS it is a small share, flat or falling; for a young product it can be large, and the direction matters more than the level. A bill that grows faster than revenue describes an architecture that gets more expensive per customer as it scales, and that is a scalability finding wearing a finance hat.

If the model assumes gross margin improves with scale, the bill should already show the mechanism: cost per customer going down, or fixed infrastructure spread over more accounts. If not, the margin improvement is an assumption, and we say so. For AI products this is the same question we treat in AI product margins, with inference added to the hosting line.

Cost per customer, or per unit of whatever they sell

The second number, cost per customer or per document or per transaction, needs the company’s help. Most teams have never computed it, so we derive it with the CTO from the invoice and usage data. A team that can tag spend by customer or product line has a discipline that shows up elsewhere. A team that can only give a total runs infrastructure the way a household runs a water bill, paid and never read.

Unit cost also exposes the customer that does not pay for itself: in usage-heavy products there is often one account consuming a disproportionate share of compute at a flat price, and that contract belongs on the committee’s list.

What the top five line items say about the architecture

Sort the bill by service and read the top five; they describe the system better than the diagram does.

Data transfer near the top means egress, often because the architecture moves large objects between regions that should have stayed put. Database spend out of proportion to compute usually means instances sized for a peak that happened once, or a managed database used as a queue. A logging line that rivals the application means nobody set retention policies and the company pays to store two-year-old debug output. Many small instances that never scale down mean environments created for a demo and never deleted; we count them, and there are always more than the CTO remembers.

Each line says something about how the team builds, and together they tell us whether the system will hold at ten times the load, or whether the bill will get there first.

Reserved capacity and the LLM line as maturity signals

Two items get separate attention. The first is the split between on-demand and committed spend. A company running everything on demand after three years is either growing so fast that nothing can be forecast, which is plausible at seed and implausible at Series C, or has never had anyone own the bill.

The second is the model provider line for AI products. It sits in an OpenAI or Anthropic invoice rather than in AWS, and it is where the margin lives. We want it per feature and per customer, and we look at whether cost per request has moved over time. A flat cost per request on a growing product means nobody has cached, routed to cheaper models, or trimmed the context window. The fix is weeks of work, and the saving goes straight to gross margin.

The gap between what the CTO thinks it costs and what finance pays

Before the CTO session we ask finance for the monthly total, all providers included, then ask the CTO for the same number from memory. When the two match, infrastructure has an owner. When the CTO’s figure is lower, the difference usually sits in the accounts nobody looks at: a legacy region, a staging environment on a forgotten card, a SaaS tool billed per seat to a team that has halved. When it is higher, someone has been cutting cost without telling the room.

Most of what this reading produces is waste, and waste rarely changes a price. It goes into the 100-day technology plan with an owner and a date. The findings that do reach the negotiation are structural: a unit cost that rises with scale, a margin assumption the bill contradicts, an egress pattern that cannot be fixed without a rebuild.

We read the bill early because it is cheap evidence that sets the questions for the rest of the audit, including which parts of our technical due diligence checklist deserve the deepest cut. If the invoices in your data room have only ever been paid, a technical and AI audit is where they get read.