GCP Architecture Series #10 — Premium and Standard Network Tiers: Where Traffic Leaves Google's Backbone

Business Challenge

A platform team is asked to bring the egress bill down. They find Network Service Tiers, read that Standard Tier is cheaper than Premium Tier, and switch a regional service across. The rate card was accurate; three of the four consequences were not in it.

Architecture

Google's network is an extensive private fiber network with over 200 points of presence around the globe. A PoP is where that network meets someone else's — a peering or transit network that can reach the user. The tier decides which PoP gets used.

Premium Tier: cross over near the user

Inbound, traffic from an internet user enters Google's network through peering or transit networks in a PoP that is as close as possible to that user. Google achieves this by advertising next hops for Premium Tier addresses in PoPs across the entire global network, with equivalent BGP metrics — which encourages the networks carrying the user's traffic to hand it over at whichever PoP is nearest to them.

Outbound, traffic is sent on the BGP best path, which typically routes it across Google's global network to a PoP as close as possible to the user before handing it to a peering or transit network. Google is explicit that this is typical rather than guaranteed: where an internet user's network peers with Google in several places, choosing the best path can select a PoP that is not the closest one to the user.

Standard Tier: cross over near the region

Inbound, traffic enters through a PoP as close as possible to the region of the Standard Tier IP address, achieved by advertising the best BGP metrics only with next hops in PoPs near that region. Outbound leaves the same way — through a peering or transit network in a PoP near the region — and normally exits from the same region as the sending VM or bucket, regardless of where the traffic is going.

Two details in that description are worth pulling out, because they are easy to skim past and they shape expectations. The closest peering PoPs might not be in the same country as the region. And their selection is made to minimise distance travelled on Google's own network — it explicitly does not optimise for performance.

There is also a documented escape hatch in the opposite direction: Standard Tier traffic might be routed as Premium Tier in rare circumstances, such as when no peering or transit network at the closest PoPs can reach the user at all.

Neither tier affects traffic between your own resources

Regardless of tier, the network is designed to keep traffic between VM instances in the same or different regions on Google's network, including when a load balancer is on the path — whether the addresses involved are publicly or privately routable. The tier is a statement about the path to and from the internet, not about internal traffic.

What each tier can carry

Standard Tier is available to resources using regional external IP addresses in all regions, so availability is not the constraint. Support is.

The SLA difference is exactly one nine

Google offers a 99.99% uptime SLA for Premium Tier VMs and 99.9% for Standard Tier VMs. The definition behind both is the same: a VM that loses external connectivity for more than a minute is considered to be in downtime.

One nine sounds small next to a per-gibibyte saving. Over a month it is the difference between roughly four minutes and roughly forty-three of permitted downtime, and it is downtime on the path to your users rather than inside your application.

Why This Architecture Holds Up

Both tiers are billed per GiB of data transfer out, based on the source region, with ingress free either way. Taking us-central1 as the source and North America as the destination:

Compare the first paid rates and Standard is 29.2% below Premium. That is the number the decision usually gets made on, and it is the most flattering one available.

A month of 10 TiB, worked through

Ten tebibytes is 10,240 GiB. On Premium that is 1 GiB free, 1,023 GiB at $0.12 and 9,216 GiB at $0.11 — $1,136.52. On Standard it is 200 GiB free and 10,040 GiB at $0.085 — $853.40.

The saving is $283.12, or 24.9% — not 29.2%, because Premium's own volume discount has already started and Standard's has not. Keep going and the gap keeps closing: above 10,240 GiB Premium is $0.08 and Standard is $0.065, a difference of 18.75%.

The free allowance, and a wording worth reading twice

Always Free usage limits apply to Premium Tier and do not apply to Standard Tier — Standard has a free allowance of its own instead. The pricing page describes it as the first 200 GiB per month free, per account, calculated across all regions. The Network Service Tiers documentation describes 200 GB per month in each region you use, across all your projects, on a per-SKU basis.

Those are not the same allowance, and the difference is a factor of however many regions you run in. Plan against the pricing page's reading, which is the smaller of the two: an allowance you were not entitled to turns into a bill, while one you did not claim is a rounding error.

When Standard is genuinely the right answer

Google's own framing is the useful one: applications that are not latency or performance sensitive, and deployments that fit within a single region. In practice that points at a specific and quite common shape of workload.

Bulk transfer out of one region — backups, log shipping, dataset delivery, replication to another provider — where the receiver is a machine that does not care about a few tens of milliseconds, the volume is large, and the whole thing lives in one region anyway.

Regional services with regional users. If the audience and the region are in the same place, entering Google's network near the region and entering it near the user are nearly the same instruction, and Standard is close to free money.

Not anything user-facing and globally distributed, anything that might want Cloud CDN, and anything that will grow into a second region. The tier is chosen per resource, so these can coexist inside one project — Standard on the batch egress path, Premium on the front door.

The setting is chosen at creation, again

Premium is the default at the project level and at the resource level, and where both are set the resource wins. That much is easy to change.

What is not easy is the address. The two tiers draw from separate pools, an address cannot move between them, and a Standard Tier address in one region cannot move to another region even within the same tier. So changing the tier of a VM with an ephemeral address changes its address, and changing a load balancer's tier means deleting the forwarding rule and creating a new one.

That puts network tier alongside the project ID from post #5 and the bucket location from post #9: a field with a sensible default, cheap to set and expensive to revisit.

Key Architecture Decisions

Closing Thought

Network Service Tiers is one of the few settings on Google Cloud that changes physics rather than policy. Most of this series so far has been about where a resource sits in a hierarchy, or how a request is authorised. This one decides how many kilometres of somebody else's network sit between your region and your user.

Which is why the useful habit is to state the geography before opening the pricing page. Where are the users, where is the region, and how far apart are they? If the answer is "the same city", Standard is a saving with almost no cost attached. If the answer is "another continent", the rate card is describing a trade nobody in the meeting has priced.

Official Google Cloud Reference

• Network Service Tiers overview
• Using Network Service Tiers
• Network Service Tiers pricing
• VPC network pricing
• Compute Engine Service Level Agreement