.png)
Building a cost-per-customer metric means attributing your cloud infrastructure spend; compute, database, storage, data transfer to individual customers or customer segments so you can understand true unit economics, protect gross margin, and price your product accurately. For most SaaS companies, this requires a combination of resource tagging, cost allocation rules for shared infrastructure, and a consistent calculation model refreshed at least monthly.
To build a cost-per-customer metric, you need to: (1) tag all customer-attributable resources with a customer or tenant identifier, (2) define an allocation method for shared infrastructure, (3) pull billing data from your cloud provider and apply the allocation logic, (4) calculate total cost per customer per period and map it against revenue.
How to Calculate Cost Per Customer
The core formula is straightforward: divide your total infrastructure cost by the number of active customers for a given period. In practice, however, a simple average rarely tells you anything useful. Customers consume infrastructure unevenly, a single enterprise customer may drive ten times the compute and storage of ten SMB customers combined. The goal is attribution, not averaging.
Start by separating your infrastructure into two buckets: directly attributable costs (resources provisioned per customer, such as a dedicated database instance or per-tenant S3 bucket) and shared costs (resources serving all customers, such as a shared application tier, API gateway, or logging pipeline). Directly attributable costs can be assigned one-to-one. Shared costs require an allocation key typically proportional to usage signals such as API call volume, active compute hours, or storage consumed.
Step 1: Tag Every Customer-Attributable Resource
Apply a consistent tagging taxonomy from the start. At minimum, every resource that can be scoped to a customer should carry a customer ID or tenant ID tag. This applies to EC2 instances, RDS databases, S3 buckets, Lambda functions, EKS namespaces, and data transfer endpoints. If your architecture is fully multi-tenant and no resource is exclusively dedicated to one customer, tagging at the namespace or workload level is still essential; it creates the foundation for proportional allocation later.
Step 2: Define Your Shared Cost Allocation Method
Shared infrastructure is where most teams hit a wall. There is no universally correct allocation key, but the most defensible options are: proportional to active compute hours consumed per tenant, proportional to API request volume, or proportional to data storage consumed. Choose the signal that most closely correlates with actual infrastructure consumption for your product. Documenting the method and applying it consistently changing allocation logic mid-quarter makes trend analysis meaningless.
Step 3: Pull and Enrich Your Billing Data
Export your cloud provider cost and usage data (AWS Cost and Usage Report, GCP BigQuery billing export, or Azure Cost Management export) into a data warehouse or BI layer. Join it against your customer or tenant ID data to apply the allocation logic defined in Step 2. The output should be a table with one row per customer per billing period, showing total attributed cloud cost.
Step 4: Calculate and Monitor the Metric
Divide total attributed cost by the number of active customers in the same period to get your average cost per customer. More usefully, segment this by customer tier, product plan, or cohort this reveals whether your enterprise customers are genuinely more expensive to serve, whether free-tier or trial users are consuming disproportionate resources, and which customer segments are margin-accretive versus margin-dilutive.
Refresh this metric monthly at minimum. Track it against revenue per customer to produce a true infrastructure margin view. A healthy SaaS infrastructure margin sits above 60–70%; if cost per customer is rising faster than revenue per customer, you have a unit economics problem that requires either pricing adjustment, architecture changes, or both. For deeper context on how this feeds into gross margin, see our guide to how cloud costs impact SaaS gross margin (/faq/saas/gross-margin/).
Common Mistakes to Avoid
- Using a simple average across all customers; it masks which segments are unprofitable
- Ignoring shared infrastructure; this typically represents 40–60% of total spend and cannot be left out
- Tagging only at the account level rather than the resource level; makes customer-level attribution impossible in multi-tenant architectures
- Refreshing the metric quarterly instead of monthly; cost trends move faster than quarterly reporting cycles
- Treating cost per customer as a finance metric only; engineering teams need visibility to make architecture and rightsizing decisions
How Usage.ai helps track cost per customer
Usage.ai provides customer-level and tenant-level cost attribution across AWS, Azure, and GCP, making it possible to build and maintain a cost-per-customer metric without manual data pipeline work. Usage.ai’s allocation engine handles shared infrastructure apportionment and surfaces per-customer cost trends alongside commitment and savings data, giving FinOps and engineering teams a single source of truth for SaaS unit economics. See how Usage.ai works.