Cost per customer is an allocation policy, not a warehouse project

A write-up on dev.to takes aim at a familiar quarter-end scramble: a board deck needs the cost to serve customer X, or its sharper cousin, which ten customers have the worst gross margin, and engineering opens a bill organised by service and region rather than by customer ^[1][2]. It matters because the reflex response is a project, billing exports into the warehouse joined against tenant telemetry, six months, two data engineers, and the author's argument is that pricing and margin decisions rarely need it ^[3][4].

The structural reason is not tooling. Cloud costs attach to resources, and in a multi-tenant product customers live inside shared resources: one Aurora cluster serving four hundred tenants, one Kubernetes cluster running everyone's workloads, one load balancer in front of all of it ^[5]. The bill knows what the cluster costs and cannot know which tenant caused which fraction, because the provider never sees your tenants ^[6]. That splits per-customer cost into two different problems. Dedicated resources, a customer's own database or VPC or SFTP endpoint, are a tagging exercise and the result is exact ^[7]. Everything shared needs an allocation key, and the output is a modelled estimate no matter who builds it or what the build costs ^[8]. The post's framing is that this is a management number, not a billing number: consistent, explainable, directionally right, and not exact to the cent ^[9].

The proposed mechanism is three buckets with three rules ^[10]. Dedicated spend gets a tenant tag carrying the customer id, enforced at provision time; the author asserts this is often 20 to 40 per cent of spend even in deeply multi-tenant products, and calls it the anchor that makes the rest credible ^[11]. Shared-variable systems each get one usage driver taken from telemetry you already collect: requests per tenant from gateway or load balancer logs for the API tier, read/write units from a nightly query for the shared database, CPU and memory requests per namespace where tenants map to namespaces, bytes per tenant for storage, job-minutes from the scheduler you already run ^[12]. What that produces is a per-tenant usage table shaped as (day, tenant_id, system, units), a handful of scheduled queries and usually a few hundred rows a day ^[13]. The other side of the join is billing data grouped by system, and the whole computation is described as a 20-line SQL job or a small script ^[14].

The third bucket is the one people fudge. Control planes, NAT gateways, observability, security tooling and staging have no honest usage driver, so the recommendation is to pick a policy, evenly per customer or proportional to revenue or proportional to the first two buckets, label it as policy on every report, and keep it as its own visible line rather than smearing it into the variable rate ^[15].

The arithmetic is unremarkable, which is the point. A shared Aurora cluster at $9,000 a month is about $300 a day, implying a 30-day month, and a tenant generating 42 per cent of read/write units on Tuesday carries $126 ^[16][1][2]. The sample monthly statement is $2,210 dedicated, $3,804 allocated by drivers and $310 platform share under an even split, totalling $6,324 ^[17][3]. Dedicated is 35 per cent of that, inside the band the author claims, and the policy bucket is under 5 per cent ^[4][5].

Two things decide whether this holds. Tagging has to be enforced at provision time ^[11], because untagged dedicated resources fall into the shared pools and quietly cross-subsidise the accounts you most want to price. And the policy line has to stay visible ^[15]: at 5 per cent of an example bill nobody argues, but the same policy applied to a heavier platform tax is where the first customer-facing challenge will land. Note also that the figures above are the author's illustration, not measurements from a named company ^[18].