Chatty microservices: what all that internal traffic actually costs

Quick answer

Internal service-to-service traffic is free within one availability zone over private IPs and costs 0.01 dollars per GB in each direction across zones on AWS, so 0.02 dollars per GB round trip. A request that fans out to eight services, each exchanging 50 KB, moves 400 KB internally. At 10,000 requests per second with random zone placement, roughly two thirds of those hops cross a zone, which works out to about 3,400 dollars per month in cross-zone charges alone. The fix is not fewer services; it is zone-aware routing, coarser interfaces, and caching at the caller.

When a monolith is split into services, in-process function calls become network calls. Function calls are free. Network calls are metered. That change is invisible on an architecture diagram and completely visible on a bill, and it is the reason a service mesh migration sometimes arrives with a networking line item nobody forecast.

The rates that apply to east-west traffic

Path	AWS rate	Notes
Same AZ, private IP	0.00 per GB	The only genuinely free hop
Cross AZ, same region	0.01 per GB each way	0.02 per GB round trip
Cross region	0.02 per GB typical	us-east-1 to us-west-2
Through NAT gateway	0.045 per GB	Plus 0.045 per hour
Through NLB cross-zone	0.01 per GB	ALB cross-zone is free

How fan-out multiplies bytes

Consider a product page request. It calls a catalog service, a pricing service, an inventory service, a reviews service, a recommendation service, a user service, a promotions service, and a feature flag service. Each exchange is modest: a 5 KB request and a 45 KB response, so 50 KB per hop. Eight hops means 400 KB of internal traffic for a request whose final rendered output might be 30 KB.

Now place those services across three availability zones with no zone affinity. With random placement, about two thirds of calls land in a different zone from the caller. At 10,000 requests per second, the internal volume is 400 KB times 10,000, or roughly 4 GB per second. Two thirds of that, about 2.67 GB per second, crosses a zone and is billed in both directions at 0.01 dollars per GB. That is about 0.053 dollars per second, or roughly 4,600 dollars per month. Even at a more realistic 2,500 requests per second the figure is around 1,150 dollars per month for traffic that produces no customer-visible bytes at all.

Zone-aware routing is the first fix

The highest-leverage change is to prefer same-zone endpoints. Kubernetes supports this through topology aware routing and through service traffic distribution policies, which bias endpoint selection toward the caller's zone while still failing over across zones when local endpoints are unhealthy. In practice, moving from random placement to zone-preferred routing takes the cross-zone share from roughly 67 percent to under 15 percent, cutting the charge by about 78 percent. The mechanics and the failure modes are covered in Kubernetes cross-zone traffic cost.

Coarser interfaces beat more calls

The second fix is architectural. A chatty interface that requires five round trips to assemble one view costs five times the per-hop bytes and five times the latency. Batching those into one call that returns a composed object is a standard API design improvement that happens to be a cost improvement too. The classic offender is the N plus 1 pattern crossing a service boundary: a list endpoint returns 100 IDs and the caller makes 100 detail calls. At 3 KB each that is 300 KB of internal traffic where a single batch call returning 120 KB would do.

Cache at the caller, not just at the edge

A surprising fraction of east-west traffic is repeat reads of slow-changing data: feature flags, pricing tables, catalog metadata, permission sets. Caching these in the calling process for even 30 seconds removes most of the volume. A feature flag service polled by 500 pods every second at 8 KB per response moves about 10 TB per month. Cached for 30 seconds, that becomes 350 GB. Across zones the saving is roughly 190 dollars per month for a change that also removes a hard dependency at request time. Related trade-offs appear in monolith versus microservices infrastructure cost.

Watch the sidecar and the mesh

A service mesh adds a proxy to each hop. The proxies themselves consume CPU and memory, commonly 0.1 to 0.5 vCPU and 100 to 300 MB per sidecar, which at 100 pods on m7g instances is a few hundred dollars per month before any traffic charges. More importantly, mesh telemetry can ship trace and metric data out of the cluster continuously, which becomes its own egress line if the observability backend lives outside the region. Sampling traces at 1 percent instead of 100 percent cuts that by two orders of magnitude.

Measure before you refactor

VPC flow logs, or the mesh's own telemetry, will tell you which service pairs move the most bytes and how much of it crosses a zone. Nearly always the distribution is skewed: two or three service pairs account for most of the volume. Fix those and the rest can stay as it is. Splitting a system into services is still usually the right call; paying cross-zone rates on every internal hop is not. Price the topology before you build it against the resource catalog.

FAQ

How much does internal microservice traffic cost?

Traffic within one availability zone over private IPs is free. Cross-zone traffic in the same AWS region costs 0.01 dollars per GB in each direction, so 0.02 dollars per GB for a round trip. Cross-region traffic is typically 0.02 dollars per GB. A high-volume fan-out architecture with random zone placement can easily accumulate thousands of dollars per month in cross-zone charges alone.

How does fan-out multiply network cost?

Each service a request touches adds its own request and response bytes. A request calling eight services at 50 KB per exchange moves 400 KB internally even if the rendered output is 30 KB. With services spread randomly across three zones, about two thirds of hops cross a zone, so the billable volume is roughly 267 KB per request in each direction at 0.01 dollars per GB.

What is the fastest way to cut cross-zone service traffic?

Zone-aware routing. Kubernetes topology aware routing and traffic distribution policies bias endpoint selection toward the caller's zone while still failing over when local endpoints are unhealthy. Moving from random placement to zone-preferred routing typically drops the cross-zone share from around 67 percent to under 15 percent, cutting the charge by roughly 78 percent without changing application code.

Do coarser APIs reduce cost?

Yes. A chatty interface needing five round trips to assemble one view costs five times the per-hop bytes and five times the latency. The N plus 1 pattern across a service boundary is the worst case: a list endpoint returning 100 IDs followed by 100 detail calls at 3 KB each moves 300 KB where a single batch call returning 120 KB would suffice.

Does a service mesh add to network cost?

It adds overhead in two ways. Sidecar proxies consume CPU and memory, commonly 0.1 to 0.5 vCPU and 100 to 300 MB per pod, which at 100 pods is a few hundred dollars per month. Mesh telemetry can also ship trace and metric data continuously out of the cluster, becoming its own egress charge if the observability backend lives outside the region. Trace sampling controls that.

How does C3X help with microservice network cost?

C3X prices infrastructure from Terraform before deployment, so the subnets, load balancers, NAT gateways, and endpoints that internal traffic crosses are priced in the pull request. Because cross-zone charges are a property of placement and topology rather than of application code, seeing the priced plan is where zone-aware design decisions actually get made.

What to do next

See what your service topology costs before it runs. C3X prices Terraform against a live resource catalog. Start with the quickstart.