What’s the best way to allocate AWS costs across tenants in a shared SaaS platform?

Keep a usage ledger for each billing period. Record tenant-associated events in a queryable store, such as tables in object storage, and reconcile those records with the AWS bill and container-level metrics. This lets you produce repeatable estimates and revise the allocation model later without needing to redesign the whole platform.

If you need strong tenant-level accuracy, isolate more resources by tenant. Dedicated databases or other tenant-specific AWS resources can be tagged and billed directly, although that increases operational overhead and may not be practical for every customer. With an application-level tenantId in one shared database, some custom metering and allocation logic is unavoidable.

Your approach is reasonable as a starting point, but request count alone may not represent actual resource consumption. Add the tenant ID to traces and usage records, then track things such as request duration, CPU or compute intensity, database query time, rows scanned, storage, and transferred bytes. Use those measurements to build a cost-to-serve model and document the assumptions behind each allocation.

Treat this as a cost-allocation problem rather than something AWS can solve automatically. Separate costs that can be attributed directly from shared overhead. Tenant-specific egress, storage, and domain traffic can usually be mapped fairly well, while EKS capacity, database CPU, caching, monitoring, and idle headroom need allocation rules based on measurable usage. Use different drivers where appropriate instead of applying request percentage to everything.

First decide how accurate the number needs to be. For internal pricing or forecasting, total infrastructure cost divided by a representative usage metric may be enough, especially if the resulting rate is rounded and kept stable for a period. Trying to calculate every shared dollar precisely can create a lot of complexity without producing a more useful business decision.