Cloud cost per feature, per customer and per environment comes from cutting already allocated cost along one more dimension: the environment through accounts, projects or a tag, the feature through tags, labels or service boundaries, the customer through dedicated resources per tenant or through measured consumption. These views show what production costs against test, what a feature costs to run and what it costs to serve a customer. They supply the numerator for unit costs and the technical gross margin, and they are only as precise as their mechanism: exact where a resource belongs to one customer, feature or environment, an estimate where it is shared.
How it works
Each view is one more segment over the same billing data, alongside team and cost centre (segments and hierarchies); the three differ in the mechanism that assigns a line.
Environment
Production, staging and development can be separated by structure. A separate account, subscription or project per environment writes the environment onto every line, completely, retroactively and without tagging (allocation by account, subscription and project). Where environments share an account, a tag such as environment carries it, and in a Kubernetes cluster a namespace per environment does. The view stays exact as long as no resource serves several environments; tooling such as CI or monitoring that serves all of them is their shared cost.
Feature
A feature rarely has an account of its own. It becomes visible through a tag or label on its resources (tags and labels) or through a service boundary: a function, a queue, a service or a namespace that serves only this feature (Kubernetes cost allocation). That is exact for resources only the feature uses. Where it shares a database or a cluster with others, its share is an estimate through a driver, such as the requests or compute time it causes there.
Customer or tenant
How precise cost per customer can be depends on the application's tenancy model. The AWS SaaS Lens distinguishes silo (dedicated resources per tenant), pool (shared resources) and bridge (a mix, service by service). Microsoft's guidance for multitenant solutions describes the matching mechanisms. Dedicated resources carry a tag with the tenant ID, or the tenant has its own account, subscription, resource group or project; the cost is then exact. Where several tenants share a resource, such as a shard or a deployment stamp, the guidance recommends a tag with the group's ID rather than one tag per tenant, since tags per resource are limited, and a separate mapping of tenants to the group in a shard map or lookup table. The group's cost is exact, the single tenant's share is not.
For fully shared resources the application measures consumption per tenant. Microsoft names requests per tenant (which assume requests cost roughly the same), a key transaction such as documents created, and indicative metrics such as data stored; the AWS SaaS Lens describes turning such measurements into a consumption share per tenant and applying it to the infrastructure cost from the bill. For Kubernetes, GKE's multi-tenancy guidance puts each customer instance of a SaaS provider into its own namespace, so namespace cost becomes customer cost and the cluster's remainders become shared cost.
The arithmetic
Cost per customer or per feature is its direct cost (resources that belong only to it) plus a share of shared cost, split by a named driver (shared cost and how to split it). The driver comes from the same period as the cost. Whatever neither direct allocation nor the driver captures stays visible as an unallocated remainder, and all customers plus the remainder add up to the cost the calculation started from.
| View | Mechanism | Exact or estimated | Data needed | Pitfall |
|---|---|---|---|---|
| Environment | account, subscription or project per environment; tag; namespace | exact while nothing is shared | account list or tag | shared tooling such as CI and monitoring |
| Feature | tag or label; own service or namespace | exact for its own resources, otherwise estimated | tag, service boundary, driver from the application | a shared database without a driver |
| Customer, dedicated resources | account, project, resource group or tenant ID tag | exact | tenant ID on the account, resource group or resource | the shared platform stays shared |
| Customer, shared resources | group tag plus mapping table; metered consumption | estimated | a measurement per tenant from the application | requests of unequal cost, sampled telemetry |
What it means for your cost
In the billing data, environment and feature appear as an account or a tag column, the customer only for dedicated resources. For shared resources the customer never appears in the provider's data; cost per customer only arises when the billing data is joined with the application's measurements. The native tools cover part of this: AWS Cost Categories group lines by account, tag and other dimensions into one value per line; Azure cost allocation rules move shared cost between subscriptions, resource groups or tags, only for certain billing account types and without reservation or savings plan purchases. On Google Cloud the join happens in queries over the BigQuery export.
The environment view shows what everything outside production costs, the feature view sets running cost beside roadmap and architecture, and the customer view shows cost to serve per tenant and pricing tier, including tenants who consume far more than others under flat-rate pricing. The FinOps Foundation's Unit Economics capability counts cost per tenant and cost to serve among its business unit metrics, and observes that many organisations learn more from how such a figure moves over time inside one FinOps scope than from comparing it across unrelated products. How a product is priced is a separate question; these figures are one input to it.
A figure derived from a driver is an estimate and is reported as one: with its driver, its period and the share that was allocated directly. Microsoft's guidance warns against measuring more precisely than needed and against measuring cost in real time; the AWS SaaS Lens considers it better value to gather consumption data only where cost concentrates. The figure gains meaning in a period comparison.
Where it goes wrong
- A tenant tag on a shared resource. Symptom: a database that serves several tenants appears entirely under one of them. Cause: a tag assigns the whole resource to one value; a shared resource carries the group's ID, and the split lives in a separate table.
- Monitoring data as the split key. Symptom: tenants' shares move although their usage has not changed. Cause: monitoring tools sample telemetry and, according to Microsoft's guidance, are not built for precise metering.
- Environments share an account. Symptom: production cost includes test and staging resources. Cause: several environments run in the same account or cluster without a tag or namespace per environment.
- The remainder disappears into the customers. Symptom: the customers add up exactly to the invoice, and cost per customer rises for all of them at once. Cause: the unallocated remainder was spread along with the driver.
Sources
Read on 2026-10-16. FinOps Foundation Unit Economics capability (CC BY 4.0); AWS SaaS Lens: silo, pool, and bridge models, SaaS Lens: expenditure awareness and organizing costs using AWS Cost Categories; Microsoft architectural approaches for cost management and allocation in a multitenant solution, measure the consumption of each tenant and introduction to cost allocation; Google cluster multi-tenancy.