Attributing Shared AWS Cost Across Products and Customers

An anonymous SaaS engagement combining AWS cost exports, application metrics and explicit allocation rules for product and customer reporting.

A service-level bill could not explain a product-level decision

A SaaS company ran several products on shared AWS infrastructure. Finance could see the cloud bill and engineering could see service spending, but neither view explained how shared resources should be assigned to products or customers. A database tagged to its owning team could still serve work from several product lines.

Ampity built a cost-attribution path that combined AWS Cost and Usage Reports with application metrics and an explicit allocation model. The work connected the billing source, the rules for shared resources and finance-facing reporting. Its purpose was to make the assigned amounts explainable before using them in product decisions.

Choose allocation rules before polishing the dashboard

The alternatives included a wider tagging initiative, a commercial cost-management platform and a custom allocation model. The selected approach used the existing AWS billing sources and usage evidence to represent the company's shared infrastructure.

Tags remained useful for identifying dedicated resources and their owners. A tag alone could not divide the same shared database between its callers. The custom model made that division a separate policy choice, with application metrics supplying evidence where a proportional rule was appropriate.

Owning the model also meant owning its maintenance. A change in product boundaries, telemetry or billing treatment could change the allocation without changing the underlying infrastructure. A commercial tool could help operate the process, but would not decide the company's allocation policy for it.

Connect the billing source to the reporting view

The implementation used billing reports in Amazon S3, Athena tables for querying, a Lambda enrichment function and application metrics. Resources were classified into direct, proportional and allocated buckets, and allocation rules were documented with finance. QuickSight provided the reporting view.

The work proceeded from the billing foundation to rule definition, enrichment and dashboard review. The review included comparing aggregate totals with the AWS bill and documenting anomalies. That comparison answered a different question from whether a shared-cost driver was appropriate: totals can reconcile while an allocation still assigns cost unfairly.

The exact billing delivery, field projection, adjustment treatment and usage-driver definitions are not specified here. A new implementation needs those details before it can reproduce an accepted product or customer statement.

Keep an unresolved amount visible

For a comparable system, define one reporting period, currency and cost basis before joining billing and usage records. Preserve unmatched charges, missing ownership and incomplete activity evidence instead of deleting them to make a dashboard look complete. These are proposed operating checks, not additional controls claimed for this engagement.

Shared capacity, retained data and centrally funded work can require different rules. A request-count proxy does not automatically explain storage responsibility. Nor does an application identity necessarily identify each customer using that application. Keep the scope of the meter beside the allocation.

Conceptual allocation review, not a deployed topology or a measured customer result. Keep assigned, centrally retained and unresolved amounts in the same reconciliation. Matching a source total does not prove that a driver is fair or that spend was saved.

A product-level cost statement also needs its revenue and commercial boundary reviewed before it supports a margin decision. Reassigning a cost between recipients is not a saving. If the source amount is unchanged, report the movement rather than presenting it as an infrastructure improvement.

Reproduce one reporting period before expanding the model

Begin with authorized read-only access to an approved billing extract and aggregate application metrics. Keep account identifiers, customer names and query contents in controlled records; use sanitized references in the review packet. New instrumentation or billing-export changes require their own owner approval and cost boundary.

If a mapping fails or the source changes, hold the candidate statement and preserve its evidence. Correct it through a new reporting revision. Reverting a dashboard does not retract a pricing decision or an internal charge already made from it; finance owns those downstream corrections separately.

Scope without a savings or margin benchmark

This case describes the attribution pipeline, shared-resource model and reporting work. It does not publish measured savings, customer profitability, forecast accuracy or a verified allocation-completeness result.

Start where ownership and usage diverge

Choose one shared resource and ask which evidence supports its product assignment, which part is a policy decision and which part remains unknown. The shared RDS allocation article explains that identity problem in more detail. The allocation-ledger playbook owns the period-close procedure and its synthetic examples, not this customer's results.

Technical reference

AWS documents querying CUR data in S3 with Athena. Its line-item reference distinguishes charge types and notes that resource identifiers are optional or blank for some charges. Those are general source-handling boundaries, not proof of this project's report configuration or reconciliation. Verify the actual export schema before adapting a query.