Egress cost per user: turning bandwidth into a unit economic

Quick answer

Egress cost per user is monthly outbound data transfer spend divided by monthly active users. For a typical SaaS application serving mostly JSON and modest assets, it lands between 0.002 and 0.05 dollars per user per month. For media-heavy products it can exceed 2 dollars. The metric matters because it is the only form in which bandwidth spend can be compared against average revenue per user: if egress costs 0.40 dollars per user against 9.99 dollars of revenue, it is 4 percent of gross margin. The goal is a flat or falling per-user number as the product grows.

A bandwidth bill that grew from 40,000 to 52,000 dollars tells you nothing on its own. It might be a crisis or it might be the best news of the quarter, depending entirely on what happened to usage. The only way to answer that is to divide by something: users, sessions, requests, or revenue. Egress cost per active user is the version that lines up most directly with how SaaS businesses are already measured.

Building the numerator

Egress spend is spread across several meters, so gather them all. On AWS the relevant usage types are DataTransfer-Out-Bytes for internet egress, DataTransfer-Regional-Bytes for cross-AZ, the region-to-region transfer types, CloudFront's DataTransfer-Out, NAT gateway data processing, and load balancer processed bytes where applicable. Sum them per month and tag by product line if you can.

A common mistake is counting only the internet egress line. For a microservice-heavy application, cross-AZ and NAT processing can be 40 percent or more of total network spend, and excluding them makes the metric look better than reality while hiding the fastest-growing component.

Choosing the denominator

Denominator	Good for	Caveat
Monthly active users	Consumer and SaaS products	Hides heavy-user skew
Paying accounts	B2B SaaS margin analysis	Ignores free-tier load
Sessions	Usage-driven products	Session definition drifts
API calls	Platform and API products	Call sizes vary widely
Viewer-hours	Media products	Quality tier dominates

Most teams should track two: one aligned to how they charge and one aligned to what drives the bytes. A B2B product charging per seat should track per paying account for margin, and per API call to catch an integration that starts polling every second.

Typical values

A project management SaaS serving mostly JSON and a few images might move 8 MB per active user per month. At a blended 0.085 dollars per GB that is about 0.00068 dollars per user, essentially free. A design tool syncing large files could move 3 GB per user monthly, or 0.26 dollars. A video product at 10 viewer-hours of 1080p per user moves 22.5 GB, costing about 1.91 dollars per user. The spread across product categories is three orders of magnitude, which is why comparing against an industry benchmark is less useful than comparing against your own trend.

Reading the trend

The interesting signal is direction. A flat per-user number as users grow means bandwidth scales linearly and your unit economics are stable. A falling number usually means caching is improving or heavy features are being adopted by a shrinking share of the base. A rising number means something changed: a new feature shipped with a fat payload, a client started polling more aggressively, a cache hit ratio degraded after a cache key change, or a large customer onboarded with unusual usage.

The rising case is where the metric earns its keep. Without it, a 30 percent bandwidth increase during a quarter of 25 percent user growth looks normal. With it, the 4 percent per-user increase is visible and can be traced to a specific release.

Segmenting to find the heavy tail

Averages hide skew, and bandwidth is one of the most skewed metrics in any product. It is common for 1 percent of users to drive 30 to 50 percent of transfer. Segment the metric by plan tier, by geography, and by feature usage. If the top percentile is on a free tier moving 40 GB each while the median paying user moves 200 MB, that is a product and pricing finding, not an infrastructure one. Rate limits, fair-use thresholds, and quality caps exist precisely for this case.

Connecting it to margin

The final step is putting the number next to revenue. If average revenue per user is 9.99 dollars and egress per user is 0.40 dollars, bandwidth is 4 percent of gross margin, which is manageable. If egress per user is 3.20 dollars on the same revenue, bandwidth is 32 percent and the pricing model needs to change, not just the infrastructure. Media businesses learn this early; SaaS businesses usually learn it when a data-heavy feature launches.

Forecasting with it

Once the metric is stable, forecasting becomes arithmetic: projected users multiplied by egress per user, adjusted for known feature launches. That is far more defensible than extrapolating a spend curve, and it lets you answer the question finance actually asks, which is what infrastructure will cost at 3x the users. Pair the metric with pre-deploy pricing so a new feature's expected contribution is known before launch rather than discovered afterward. Price your infrastructure against the resource catalog.

FAQ

What is egress cost per user?

Monthly outbound data transfer spend divided by monthly active users. It converts an absolute bandwidth bill, which means nothing on its own, into a unit economic that can be trended, forecast, and compared against average revenue per user. Typical values range from 0.002 dollars for lightweight SaaS to over 2 dollars for media-heavy products.

Which cost lines belong in the numerator?

All network transfer meters, not just internet egress. On AWS that means internet data transfer out, cross-AZ regional transfer, region-to-region transfer, CDN delivery, NAT gateway data processing, and load balancer processed bytes. For microservice-heavy applications, cross-AZ and NAT processing can be 40 percent or more of network spend, so omitting them understates the metric badly.

What denominator should I use?

Track two: one aligned to how you charge and one aligned to what drives bytes. Monthly active users suit consumer and SaaS products, paying accounts suit B2B margin analysis, API calls suit platform products, and viewer-hours suit media. Using both catches different problems, such as an integration that starts polling aggressively without any change in user count.

What does a rising per-user number mean?

Something changed structurally: a new feature shipped with a large payload, a client began polling more aggressively, a cache hit ratio degraded after a cache key change, or a large customer onboarded with unusual usage. Without the per-user metric, a 30 percent bandwidth rise during 25 percent user growth looks normal; with it, the 4 percent per-user increase is visible and traceable.

Why segment the metric?

Because bandwidth is heavily skewed. It is common for 1 percent of users to drive 30 to 50 percent of transfer. Segmenting by plan tier, geography, and feature usage reveals cases like a free tier whose top percentile moves 40 GB each while the median paying user moves 200 MB, which is a pricing and product finding rather than an infrastructure one.

How does C3X support unit economics work?

C3X prices infrastructure from Terraform before deployment, so the expected cost contribution of a new feature's infrastructure is known at design time. Combined with a stable per-user metric, that lets you forecast by multiplying projected users by expected per-user cost and adjusting for planned launches, rather than extrapolating a historical spend curve.

What to do next

Turn infrastructure spend into a number you can forecast. C3X prices Terraform against a live resource catalog. Start with the quickstart.