Network egress is the cloud cost that people notice too late

cloudwebschool.com

Network egress is the cloud cost people notice too late

Most cloud cost estimates start with compute.

That makes sense. Compute is visible, familiar, and easy to discuss in architecture meetings.

But plenty of painful cloud bills are not caused by the VM, the container, or the database instance. They are caused by the data moving between them, or out to the internet.

Network egress is one of those costs that stays invisible until a service gets busy enough for the bill to become uncomfortable.

The easy rule to remember

In GCP, ingress is free.

The trouble starts when data leaves a boundary that Google charges for:

• out to the internet
• across regions
• and, in some cases, across zones

That is why two architectures with the same compute footprint can end up with very different monthly costs.

What is usually free

The source guide gives a useful practical summary of traffic that is often free:

• traffic coming into GCP from the internet
• same-zone traffic on internal IPs
• same-region traffic on internal IPs between most GCP services
• traffic to Google APIs such as googleapis.com

That means a lot of same-region, privately-routed communication can be kept cheap if you design for it deliberately.

What tends to cost money

Again using the source guide as the reference point:

• some cross-zone traffic in the same region can cost about $0.01/GB
• traffic between GCP regions can cost roughly $0.01-0.08/GB, depending on the region pair
• internet egress from the Americas and Europe is around $0.085/GB for the first TB per month
• internet egress from Asia-Pacific is higher, around $0.12/GB

Those figures are approximate and the guide is clear that exact prices vary by region pair and can change over time. The point is not to memorise each number. The point is to remember that placement decisions have a direct cost.

The most common expensive mistake

The easiest way to create avoidable egress is to put related services in different regions.

The example in the source guide is simple and realistic:

• application servers in europe-west1
• primary Cloud SQL database in us-central1

Every database query crossing that boundary creates inter-region egress. If the application talks to the database constantly, the cost piles up quickly.

This is why "closer to users" is not the only placement question. You also need to ask what the service talks to all day.

If two components communicate heavily, they usually belong in the same region unless you have a very good reason to split them.

Storage and compute can quietly double the problem

The same pattern shows up with data processing workloads.

If you store a large dataset in Cloud Storage and process it from compute in a different region, you can pay on the way in and on the way out:

• data transferred from storage to compute
• results transferred back again

That is why the source guide recommends co-locating compute and storage for data-heavy workloads.

It sounds obvious when written down. In practice, it is easy to miss because teams often choose storage location and compute location in separate conversations.

Internal IPs are not a small detail

One of the most useful low-effort recommendations in the source guide is to keep same-region service-to-service traffic on internal IPs whenever possible.

If two services in the same region communicate over public addresses instead, traffic can leave and re-enter GCP, which is exactly the kind of path that can introduce charges you did not need to create.

This is not just a networking cleanliness issue. It is a cost-control habit.

Cloud CDN is not just about speed

People usually think of Cloud CDN as a performance tool first.

It is also a cost tool.

The guide points out that cached responses served from edge locations use CDN egress pricing, which is lower than regular internet egress pricing. If you are serving cacheable assets or responses with a good cache hit ratio, CDN can reduce both origin load and outbound transfer cost.

That is especially relevant for:

• static assets
• large downloadable files
• API responses that can actually be cached

It is not a fit for personalised or frequently-changing responses, but when it fits, it changes the cost profile meaningfully.

A better way to think about egress in reviews

Instead of asking "what does this service cost?", ask:

1. where is the data coming from?
2. where is it going?
3. how often does that happen?
4. is it crossing a region or the public internet?

That framing catches egress problems much earlier than staring at a pricing calculator after the design is already fixed.

One practical checklist

When I want to sanity-check egress risk quickly, I use this:

• keep compute and storage in the same region if they exchange a lot of data
• keep application services and databases in the same region if latency and cost both matter
• prefer internal IPs for same-region communication
• consider Cloud CDN for cacheable high-traffic content
• include egress explicitly in every cost estimate

That last point matters most. The source guide is blunt about it: many teams estimate compute and storage, then barely think about network transfer. That is how egress becomes the line item that surprises everyone later.

You still need visibility after launch

Architecture choices are only part of the story. You also need a way to see what is actually happening.

The source guide recommends two useful routes:

• billing export analysis in BigQuery to find the SKUs driving transfer cost
• VPC Flow Logs to understand where traffic is actually going

That is the difference between "we think networking is expensive" and "we know which path is expensive".

The main takeaway

Network egress is not an edge case. It is part of the architecture.

If data leaves the region, leaves the platform, or takes the wrong network path, you pay for it. Good architecture reduces that spend long before finance asks where the bill came from.

If you want the full breakdown, read the original Network Egress Costs Explained in GCP guide.

If you are estimating Cloud Run workloads as part of that architecture, the Cloud Run Cost Calculator is useful because it includes egress in the estimate rather than treating compute as the whole bill.