5.3 Network Service Tiers: Premium vs. Standard

Why Network Service Tiers Show Up on the Exam

Network Service Tiers determine which network your traffic travels on between Google Cloud and the rest of the internet, and that choice directly affects which load balancer types you can use, what SLA you get, and how much you pay for egress. Domain 2 of the ACE exam guide lists Network Service Tiers as an explicit planning topic, and it pairs naturally with the load balancing and regional placement concepts from the previous two sections — because tier selection constrains which load balancer scope (global vs. regional) is even possible.

The Two Tiers

• Premium Tier routes traffic over Google's own private global backbone — the same fiber network Google uses for Search and Gmail. Inbound traffic enters at the point of presence (PoP) closest to the end user and rides Google's network all the way to your resource, wherever it is; outbound traffic exits as close to the destination as possible. This minimizes hops across the public internet and delivers the most consistent latency and packet loss.
• Standard Tier enters and exits Google's network only in the region where your resource is deployed, then relies on public internet peering and transit/ISP routes for the rest of the journey. It trades some performance consistency for meaningfully lower per-GB egress pricing.

Resource Support Matrix

Not every resource is available in both tiers — this is the single most exam-relevant fact about Network Service Tiers:

Standard Tier is a regional-only service. If a design calls for a single global anycast IP, global external Application Load Balancer, or Cloud CDN, Premium Tier is mandatory — there is no Standard Tier equivalent for any of these. This is exactly why the load balancer choice in section 5.1 and the tier choice in this section have to be planned together: choosing a global load balancer implicitly commits you to Premium Tier pricing for that resource.

SLA and Pricing

Google's stated availability commitments differ by tier: Premium Tier targets 99.99% availability, reflecting the fully Google-managed backbone path, while Standard Tier targets 99.9% availability, reflecting its reliance on public internet peering for part of the path. Standard Tier's appeal is cost — its per-GB egress pricing is lower than Premium Tier's — which makes it attractive for workloads where every user and every backend sit in the same region and the extra hop through public peering is an acceptable trade-off (batch processing endpoints, internal tools, regional-only customer bases, or cost-sensitive services with generous latency budgets).

Configuring Tiers

Network Service Tier is set at the project level (Premium is the default for new projects) but can be overridden per resource — for example, giving one external IP address Standard Tier pricing while the rest of the project stays on Premium. A critical operational detail: you cannot change the tier of an existing IP address or forwarding rule in place — changing tiers requires releasing the current external IP/forwarding rule and creating a new one on the desired tier. This is a common trap in "how do you migrate this workload to Standard Tier" scenario questions, where the tempting-but-wrong answer is "edit the existing IP's tier setting."

Exam Scenarios

Scenario 1: A company serves a public web application to users on five continents and needs the lowest possible latency with a single global IP address. Answer: Premium Tier — it is required for the global external Application Load Balancer and delivers routing over Google's backbone for the best cross-continent performance.

Scenario 2: An internal batch-reporting service in asia-southeast1 serves only regional back-office staff, and the team wants to minimize monthly network egress cost with no requirement for global reach. Answer: Standard Tier — since every client and backend is regional, the reduced-cost public-internet path is an acceptable trade, and no global IP or Cloud CDN capability is needed.

Scenario 3: A team currently running a Standard Tier regional external IP now needs to add Cloud CDN in front of that backend. Answer: This isn't possible as-is — Cloud CDN requires Premium Tier, so the team must reserve a new Premium Tier IP (and reconfigure the forwarding rule/load balancer to use it), since the existing IP's tier cannot be changed in place.

Common Traps

• Believing Standard Tier is simply "Premium Tier but slower" — it is architecturally different: it is regional-only and cannot back a global load balancer, global anycast IP, or Cloud CDN at all, not just a degraded version of them.
• Assuming tier is a one-time, whole-project setting — it defaults at the project level but is overridable per resource, so a single project can mix Premium and Standard IP addresses.
• Trying to "switch" an existing IP's tier — the correct migration path is to create a new IP/forwarding rule on the target tier and cut over, not edit the existing resource.

Key Takeaways

• Premium Tier routes traffic over Google's global backbone end-to-end and is the only tier that supports global IPs, global load balancers, and Cloud CDN; it targets 99.99% availability.
• Standard Tier is regional-only, uses public internet peering outside the resource's region, costs less per GB of egress, and targets 99.9% availability.
• Tier is set at the project level (Premium by default) but can be overridden per resource, and an existing IP address's tier cannot be changed in place — you must provision a new one on the desired tier.