How to Build Unit Economics for Cloud Cost per Customer

Cloud unit economics is what turns a spend report into a decision. Without it, you know how much you paid this month. With it, you know how much you paid to serve customer A vs. customer B, whether feature X is gross-margin positive, and which of your top customers is one architecture change away from becoming unprofitable.

The math is not complicated. The plumbing takes work.

What are the right units to measure?

For most B2B software companies, four units cover 90% of the decisions.

• Cost per customer. The primary business unit. Directly feeds gross margin per customer and customer lifetime value modeling.
• Cost per tenant. For multi-tenant products where tenants and customers differ. A single customer may run 50 tenants.
• Cost per 1000 requests. The primary engineering unit. Directly feeds capacity planning and architecture decisions.
• Cost per feature. For product decisions. Which features are cost centers, which are cost heroes.

Pick the ones your business actually needs. A pure API company may only need cost per 1000 requests. A vertical SaaS product may only need cost per tenant. Do not build all four if you only need two; the maintenance cost of each is real.

What data model do you need to compute unit economics?

Three tables, tied together by service.

The join is straightforward: service cost divided by service usage gives cost per unit; multiplied by per-customer usage gives cost per customer.

The trap is the middle table. Most companies do not have per-service, per-customer usage data. They have total service usage and total customer usage, but not the cross. Building the cross usually requires a lightweight change to service instrumentation: emit a customer or tenant identifier with every request-level metric.

How do you allocate cost from services to customers?

Three methods, in order of accuracy.

• Direct attribution. Each request tags its customer, and each service emits per-customer usage. Cost splits by usage share. This is the gold standard, and it requires instrumentation.
• Usage proxy. The service does not know which customer made a request, but the API layer does. Attribute service cost to customers by their share of the parent service's requests. Adds a hop of imprecision.
• Revenue proxy. The service is deeply shared and cannot be attributed to specific customers. Attribute by customer revenue share, or by seat count. Least accurate, use only for truly common services.

Most B2B companies end up with a mix. The top 3 to 5 services get direct attribution. The next 10 use a usage proxy. The remaining shared services use a revenue proxy. That mix gets to 8 to 12% accuracy, which is enough for management decisions.

What is a reasonable cost per customer, by segment?

The right ratio is gross margin, not absolute dollars. Absolute cost per customer depends heavily on the product; gross margin does not. Rough benchmarks for software companies with meaningful cloud spend.

The benchmarks are directional. Your business context matters more than the average. What matters is that the number is measured, tracked over time, and moved intentionally.

Which customers become unprofitable at scale?

Three patterns come up.

• The whale that runs weird workloads. Customer signs a large contract based on their headcount, but their usage pattern involves batch jobs, ML inference, or high-egress traffic that costs 10x an average customer. Gross margin is flat or negative on the whale.
• The free tier that never converts. Trial or free-plan customers who use 20% of the platform's capacity without ever paying. If free tier cost is not measured per user, it silently taxes the paying customers.
• The enterprise with 50 tenants. Contract is priced per company, but the customer runs 50 workspaces, each with production-scale usage. Cost scales linearly, revenue does not.

You cannot find any of these without per-customer unit economics. You will find them in a board meeting when someone asks the gross margin per top-decile customer, and the answer is a scramble.

How do you use unit economics to shape engineering?

Four decisions get better with the data.

• Feature retirement. Features with negative gross margin need pricing changes or architectural change. Sometimes both. Unit economics turns retirement decisions from political fights into arithmetic.
• Capacity planning. Cost per 1000 requests is the input to any accurate capacity forecast. Without it, capacity plans are extrapolations of total cost, which miss efficiency changes.
• Architecture reviews. New designs get a projected cost per unit, defended in the RFC. Reviews compare the projected number to the current baseline. Regressions get flagged before they ship.
• Contract negotiation. Sales knows which customers are gross-margin heroes and which are not, and can steer contract terms accordingly.

Each of these is worth 5 to 15% of engineering effort, redirected toward the work that matters most. That leverage compounds over years.

What breaks in the first quarter of running unit economics?

Two things, both fixable, both important.

• Numbers do not tie to the invoice. Total per-customer cost sums to less than the total cloud bill, because some cost was allocated to internal or platform-only services. This is fine and expected. Report it clearly: "Direct customer cost: X. Platform overhead: Y. Total cloud: X plus Y."
• Top customers demand explanations. Once the numbers exist, sales and CSMs will ask questions about specific accounts. Have the drill-down ready before publishing the summary. If you cannot answer "why is customer A more expensive than customer B" within an hour, the summary generates more work than it saves.

The first is a communication problem. The second is a tooling problem. Both are solvable in the first month if you plan for them.

The mistake to avoid

Most FinOps teams try to compute unit economics from raw billing data without first building 100% cost allocation. That produces numbers that are 30 to 40% wrong, get publicly disputed by engineering, and burn the FinOps team's credibility for the next year. Get allocation to 95% first, then add the business dimensions table, then compute the units. The sequence matters. Unit economics on top of bad allocation is worse than no unit economics at all, because leadership will make decisions on the wrong numbers and blame the FinOps team when the decisions fail.