Network Service Tiers

Introduction

Network Service Tiers let Google Cloud customers choose, per resource, whether external traffic rides on Google's own private global backbone (Premium Tier) or on the public internet (Standard Tier). The tier choice changes routing behaviour, available load balancer types, the kind of static IP you can reserve, the SLA Google publishes, and — most visibly — the per-GB egress price. For PCNE candidates the tier appears in nearly every "design the network for a multi-region web app" scenario, because picking the wrong tier silently breaks Global External Load Balancing, Cloud CDN, and BYOIP. This study note covers the routing physics, the price model, how to switch tiers at the project or per-resource level, billing visibility, and the half-dozen places where Premium Tier is non-negotiable.

Premium Tier: Google's Global Backbone and Cold Potato Routing

Premium Tier carries traffic from the originating end user across Google's private fiber backbone all the way to the destination region. The packet enters Google's network at the edge POP closest to the user (over 200 worldwide), traverses Google-owned fiber and undersea cables, and only leaves Google's network at the region hosting the workload. The same path is used in reverse for return traffic.

Cold potato routing explained

"Cold potato" means Google holds onto the packet — keeps it cold, never tosses it — for as long as possible. The decision logic: at the ingress POP, Google looks up which region serves the destination IP, then forwards the packet along its own backbone using Google-internal routing protocols. The public internet only handles the last hop from the end-user's ISP to Google's nearest POP, which is typically a single AS hop away.

Single anycast IP for global reach

Premium Tier is the foundation of Google's global anycast advertising. A --global external IP address (e.g. attached to a Global External Application Load Balancer) is announced from every Google POP simultaneously. Users in Tokyo, Frankfurt, and São Paulo all hit the same IP, and BGP delivers each user to their nearest POP. This is why Premium Tier is mandatory for --global forwarding rules.

SLA and reliability

Google publishes the VPC SLA at 99.99% availability only for Premium Tier external traffic. Standard Tier traffic falls under regional infrastructure SLAs and inherits whatever availability the underlying internet path provides. For revenue-bearing customer traffic, Premium Tier is the only tier covered by financial credits.

Standard Tier: Public Internet and Hot Potato Routing

Standard Tier hands traffic off to the public internet at the earliest possible point near the destination region's edge. The packet leaves Google's network from the regional POP nearest the workload, travels across one or more transit ISPs to the end user, and crosses unknown networks along the way.

Hot potato routing explained

"Hot potato" means Google treats the packet as a hot potato and drops it onto the next network as quickly as possible. The egress decision is made at the region: Google's router picks the nearest IXP or transit peer with a route to the end user, and the packet is on its own from there. Performance depends on the quality of the chosen transit path and is subject to congestion, routing changes, and BGP convergence on networks Google does not control.

Regional anycast only

Standard Tier external IPs are regional, reserved with --region=REGION. You cannot announce a Standard Tier IP from multiple regions; each region runs its own forwarding rule with its own IP. This is why Standard Tier cannot back a global load balancer — there is no single IP to advertise globally.

Cost-effective egress

The headline reason teams choose Standard Tier is pricing. Internet egress on Standard Tier is roughly 30-50% cheaper than Premium Tier for the same destination, depending on the source region. For workloads that move a lot of bytes to end users in a single geography (a Tokyo-based CDN origin streaming to Tokyo subscribers, for example), the savings compound rapidly.

When latency variance is acceptable

Standard Tier latency is highly variable. A request from a São Paulo user to a us-central1 Standard Tier VM may go via Miami, Atlanta, then Chicago across two different ISPs, adding 50-150 ms compared to the Premium Tier path. For background batch traffic, internal admin tooling, or non-interactive scrapers this is irrelevant. For a real-time game backend it is a deal-breaker.

Pricing Model and Egress Cost Differences

Network Service Tier pricing is a separate line item on top of the underlying load balancer, NAT, or VM charges. Google publishes the rates per source region and destination continent in VPC network pricing.

Premium Tier pricing tiers (illustrative)

Premium Tier egress from us-central1 to worldwide destinations bills in three volume tiers:

• 0-1 TB/month: about $0.12/GB to most destinations.
• 1-10 TB/month: about $0.11/GB.
• 10 TB+/month: about $0.08/GB.

Inter-continental destinations (Australia, China) carry a premium of 50-100% above the headline North America rate. Always check the live pricing page; rates change.

Standard Tier pricing

Standard Tier egress from us-central1 to North America is roughly $0.085/GB flat (no volume discounts), and to Asia or South America $0.11-0.14/GB. The flat structure means heavy egress workloads (>50 TB/month) start to lose the savings vs Premium Tier's volume-discounted rate, so the cost case is strongest for medium-volume, single-geography traffic.

Cache fill and inter-region nuances

Cloud CDN cache fill from a Premium Tier-backed backend uses Google's backbone and bills under Premium egress. Switching the LB to Standard Tier does not change cache fill costs because cache fill is intra-Google. However, cache egress to clients does change: Standard Tier delivers from the region's POP only, so a Sydney user pulling content from a Standard Tier LB in us-central1 pays inter-continental Standard egress, not Premium egress.

Choosing a Tier per VM and per Load Balancer

The tier is set on the forwarding rule for load balancers and on the access config for Compute Engine VMs with external IPs. You can mix tiers freely within the same VPC, project, and even the same application — there is no global lock.

Per-VM tier selection

For an ephemeral external IP on a VM:

gcloud compute instances create batch-worker \
  --zone=us-central1-a \
  --network-tier=STANDARD

The --network-tier flag attaches the right kind of external IP at provisioning time. To change tier afterwards, you must remove the access config, reserve a new static IP in the desired tier, and attach it — there is no in-place flip.

Per-load-balancer tier selection

For a Network Load Balancer or Regional External Application LB, the tier is set on the forwarding rule:

gcloud compute forwarding-rules create my-fr \
  --region=us-central1 \
  --network-tier=STANDARD \
  --ip-protocol=TCP \
  --ports=443 \
  --backend-service=my-bs

Global External Application Load Balancers and Global Network Load Balancers can only use --network-tier=PREMIUM; trying to set Standard fails at validation.

Static IP reservation by tier

Static IPs are also tier-locked at reservation time:

# Premium global anycast IP for a gXLB
gcloud compute addresses create premium-ip --global

# Standard regional IP for a regional NLB
gcloud compute addresses create std-ip \
  --region=us-central1 --network-tier=STANDARD

You cannot convert a reserved IP between tiers. Plan IP allocation around tier choice from day zero, especially when external customers have allow-listed your IP and you want to change tier without forcing them to update firewall rules.

Project-Wide Default Tier

Rather than annotate every VM and LB, you can set a default tier for the whole project so that unspecified resources inherit it.

Setting the default

gcloud compute project-info update \
  --default-network-tier=STANDARD

After this, any resource created without an explicit --network-tier flag defaults to Standard. The default takes effect immediately for new resources; existing resources keep their original tier until recreated.

When project default is useful

• Cost-conscious labs and development projects — flip the default to Standard so engineers do not accidentally rack up Premium charges on throwaway VMs.
• Single-region production projects — if the entire application is regional by design (a Tokyo-only ride-hailing service, for example), default to Standard and explicitly opt VMs into Premium only when needed.

Cautions

Setting the default to Standard will cause gcloud compute forwarding-rules create --global to fail validation, because global forwarding rules require Premium. The error message is explicit: network tier STANDARD is not supported for global forwarding rule. Likewise, attempting to attach Cloud CDN to a Standard Tier backend service will be rejected at create time.

Tier Visibility in Billing Reports

Google Cloud Billing labels each line item with a SKU that includes the network tier, so you can attribute egress spend to Premium vs Standard with a few minutes of work in BigQuery or the Billing console.

SKU naming convention

Premium Tier internet egress SKUs follow the pattern Network Internet Egress from REGION to CONTINENT for Premium, and Standard Tier Internet Egress from REGION to CONTINENT for Standard. The SKU description always contains the literal string "Standard Tier" when applicable; Premium SKUs do not carry the word "Premium" in older reports, which can be confusing.

Filtering in the Billing console

In the Reports view, group by SKU and filter on sku.description:"Standard Tier" to isolate Standard spend. Cross-check with the Cost breakdown view filtered to the Networking service to see the relative weight of each tier in your total egress.

BigQuery export queries

Once Billing data is exported to BigQuery, a query like the following splits egress cost by tier:

SELECT
  REGEXP_EXTRACT(sku.description, r'^(Standard Tier|Premium Tier|Network)') AS tier_bucket,
  service.description AS service,
  SUM(cost) AS total_cost
FROM `project.dataset.gcp_billing_export_v1_xxx`
WHERE DATE(_PARTITIONTIME) >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
  AND service.description = 'Compute Engine'
  AND sku.description LIKE '%Egress%'
GROUP BY tier_bucket, service
ORDER BY total_cost DESC;

This lets FinOps teams quantify the dollar impact of any future tier migration before approving it.

Cloud Monitoring metrics by tier

The metric networking.googleapis.com/vm_flow/egress_bytes_count carries a network_tier label (PREMIUM or STANDARD) for VM-originated egress. Combine it with the billing SKUs to build dashboards that compare bytes shipped vs dollars billed on each tier.

When Premium Tier Is Mandatory

Several Google Cloud services require Premium Tier and will reject Standard at provisioning time. Knowing this list cold is high-yield on the PCNE exam.

Global External Application Load Balancer (gXLB)

Global LBs need to announce one anycast IP from every POP, which is fundamentally a Premium Tier capability. The classic Global HTTP(S) LB and the new Global External Application LB both require --network-tier=PREMIUM on their global forwarding rules. The Regional External Application LB can use Standard, but it gives up anycast and Cloud CDN.

Cloud CDN

Cloud CDN sits on top of Global External Application LBs (or the legacy classic global HTTPS LB), both of which require Premium. There is no Cloud CDN integration with a Standard Tier regional LB. The error message at LB create time is Cloud CDN can only be enabled on Premium Tier backends.

Multi-region Cloud Storage egress

A multi-region GCS bucket (e.g. US, EU, ASIA) serves objects from the closest sub-region to the requester, which only works if traffic is routed across Google's backbone to the right sub-region. Multi-region bucket egress to the internet is billed and routed as Premium Tier. Regional buckets (us-central1-only) can serve via Standard Tier if you front them with a regional LB, but they lose the multi-region availability promise.

Cloud Interconnect VLAN attachments terminating in another region

Cross-region VLAN attachment scenarios (a Dedicated Interconnect in us-east4 reaching a workload in us-west1) rely on Google's backbone, which is Premium territory. The setting is implicit — you do not pick a tier on a VLAN attachment — but the underlying transport is Premium.

Cloud Load Balancing for IPv6

Global IPv6 forwarding rules require Premium Tier; Standard Tier IPv6 is only available regionally and only for specific LB types. PCNE questions often pair "future-proof for IPv6" with "Premium Tier" as the correct answer.

BYOIP for external addresses

Bring-Your-Own-IP for Cloud Load Balancing and Cloud CDN is Premium Tier only. The prefix is announced from every Google POP via Google's global anycast — a Standard Tier regional announcement would defeat the purpose of advertising the prefix globally.

When Standard Tier Is the Right Choice

Standard Tier is not a worse Premium — it is a different product optimised for a narrower set of workloads. The PCNE expects you to recognise these scenarios.

Single-region cost-conscious workloads

A SaaS company serving customers exclusively from asia-east1 to users in Taiwan can put a regional Network Load Balancer on Standard Tier and save 30-50% on egress. The latency penalty is negligible because the user and LB are both in Asia, and the routing path is short. As long as growth plans do not include expanding to Europe or Americas, the tier downgrade is durable.

Static content from a CDN you do not own

If your CDN strategy is to use Cloudflare or Akamai in front of GCP, Cloud CDN is off the table anyway. In that architecture the GCP origin can be a Standard Tier regional LB or VM, because the third-party CDN handles global edge caching. The GCP egress bill drops, and the third-party CDN absorbs the latency variance.

Batch processing and back-office traffic

ETL jobs writing to S3 from a us-central1 VM, or admin tooling that calls third-party APIs, are insensitive to a few extra milliseconds of latency. Provision the VM with --network-tier=STANDARD and the egress costs for those (often massive) data movements drop accordingly.

Migration and lift-and-shift POCs

When evaluating GCP for an existing application, Standard Tier lets engineers test the platform without committing to Premium pricing during the POC. After validating fit, the production cutover can re-provision LBs and IPs in Premium Tier.

Workloads that already pay for transit elsewhere

If your egress is already destined for a paid carrier link (e.g. an MPLS connection back to a corporate data centre via an internet handoff), Premium's backbone benefits are wasted because the corporate side dictates the path anyway. Use Standard and route via the internet handoff to the same MPLS edge.

Switching Tiers Without Downtime

Migrating an existing application from Premium to Standard (or vice versa) is a controlled exercise because IPs cannot be flipped in place.

IP address constraint

A reserved external IP is tier-locked at reservation time. To change tier, you must reserve a new IP in the target tier, attach it to the resource, and then release the old one. This means a DNS-level cutover for any externally referenced IP.

Forwarding rule recreation

Forwarding rules also embed the tier. The migration pattern: create a new forwarding rule with the desired tier pointing at the same backend service, update DNS A/AAAA records to the new IP with a low TTL (300s) ahead of time, watch traffic drain from the old rule, then delete the old forwarding rule.

Validation checklist before flipping

1. Confirm the LB type supports the target tier (e.g. global LBs cannot move to Standard).
2. Confirm Cloud CDN is not enabled on the backend service if moving to Standard.
3. Confirm no IPv6 global forwarding rules are involved if moving to Standard.
4. Update any external allow-lists with the new IP.

Rollback plan

Keep the old (Premium) forwarding rule and IP for at least 7 days after cutover so that DNS caches around the world fully converge. Only release the old IP after monitoring confirms no residual traffic.

Common Misconceptions and Exam Traps

A few patterns appear repeatedly in PCNE-style scenario questions.

Misconception: "Standard Tier means slower internal traffic"

Network Service Tiers apply only to external IP traffic. Internal VPC traffic (VM-to-VM within the same VPC, even across regions) always uses Google's backbone, regardless of tier settings. The same applies to Cloud Interconnect and Cloud VPN — those are governed by their own pricing and SLA, not by tier.

Misconception: "I can save money by setting all VMs to Standard"

VMs without external IPs do not generate tier-billed egress. They egress via Cloud NAT (which is its own SKU) or via a load balancer. Setting --network-tier=STANDARD on a VM that has no external IP is harmless but pointless. Cost savings happen on the resource that holds the external IP.

Misconception: "Standard Tier is fine for ‘internal’ apps with public IPs"

An app reachable from the internet but only used by internal staff still benefits from Premium reliability — those staff are remote users somewhere on the planet, and Premium's predictable latency keeps their sessions stable. Pick Standard only when latency is genuinely irrelevant.

Trap: "Premium Tier has a 99.99% SLA on egress"

The 99.99% number is the VPC SLA, which covers Premium Tier external traffic and internal VPC plumbing. Standard Tier traffic has no Google-provided availability SLA on the public internet path, but the Standard Tier service itself (the egress mechanism) inherits the VPC SLA up to Google's network edge. Distinguishing these matters when reading SLA-related questions.

Trap: "Tier choice affects Cloud Interconnect billing"

Cloud Interconnect and Cloud VPN traffic do not bill against Network Service Tier SKUs. They have their own egress pricing (Interconnect attachment hourly cost + per-GB rates). The tier knob does not appear in Interconnect provisioning.

白話文解釋（Plain English Explanation）

Analogy 1: Driving from San Francisco to New York

Imagine you are driving from San Francisco to New York with valuable cargo. Premium Tier is like being handed the keys to a private express highway Google owns from coast to coast. You enter the on-ramp the moment you leave your driveway in San Francisco and stay on Google's smooth, well-policed road until you reach the loading dock in New York. There is no traffic, no detours, no surprise tolls, and Google's tow truck is on standby if you have a flat tire (the 99.99% SLA). Standard Tier is like taking public roads for the same trip. You start on a nice city street, but a few miles later you are bouncing between county roads, state highways, and federal interstates run by different agencies. Some segments are perfectly fine; others are jammed with traffic, under construction, or detour you through a rural town. You pay no toll, but you also pay for tires (latency spikes), gas (slower throughput), and time (variable arrival).

Analogy 2: International Shipping — DHL vs Local Postal Handoffs

Premium Tier is like shipping a parcel through DHL end-to-end from Taipei to Berlin. DHL controls every leg — Taipei pickup, Hong Kong sort centre, Frankfurt customs clearance, Berlin last-mile delivery. The parcel never leaves DHL's tracking system. The price per kilo is higher but the delivery date is reliable and the tracking is granular. Standard Tier is like shipping the same parcel via the cheapest international option that hands off to local postal services. The first carrier picks it up in Taipei and gets it as far as Frankfurt, then drops it onto Deutsche Post for the final leg. From the moment it lands on Deutsche Post, your sender visibility ends; the parcel might arrive on Tuesday or it might arrive the following Monday because Deutsche Post had a snow day. For a one-off birthday gift to a friend, that is acceptable. For a time-critical contract delivery to a global enterprise customer, it is not.

Analogy 3: VIP Airport Transit vs Connecting Through Public Terminals

Premium Tier is the equivalent of being a frequent-flyer status passenger at an airline hub airport. You enter through the VIP lane in San Francisco, walk Google's private transit corridor that connects to all gates, and exit through the VIP lane in New York. Crowds, security queues, terminal changes — none of those touch you. Standard Tier is connecting through the public terminals of a connecting hub airport. You walk normal corridors, share elevators with everyone, queue at the same TSA stations, and depend on the airport's general operations. It is cheaper (no airline fee) but you might miss your connection because Terminal 4 took ten minutes longer than expected. For an exam analogy: Cloud CDN is the airline's VIP lounge that only frequent-flyer (Premium) travellers can enter; Standard Tier passengers simply do not see that door.

FAQs

Q: Can I change the network tier of an existing static IP address?

A: No. Static external IPs are bound to a tier at reservation time and cannot be flipped. To migrate, reserve a new IP in the target tier with gcloud compute addresses create --network-tier=STANDARD --region=... (or --global for Premium), attach the new IP to your forwarding rule or VM, then release the old IP. Plan a DNS cutover window because the externally visible IP will change.

Q: Does the Network Service Tier affect VM-to-VM traffic inside the same VPC?

A: No. Internal VPC traffic always uses Google's backbone, even across regions. The tier setting only governs traffic that exits Google's network via an external IP to the public internet (or enters via the same path). VM-to-VM traffic over private IPs, traffic over Cloud Interconnect, and traffic over Cloud VPN are all out of scope for Network Service Tiers.

Q: Can Cloud CDN run on Standard Tier?

A: No. Cloud CDN is attached to backend services of a Global External Application Load Balancer (or the classic global HTTP(S) LB), and those LBs require Premium Tier on their global forwarding rules. gcloud compute backend-services update --enable-cdn fails on a Standard Tier-fronted backend with the error Cloud CDN can only be enabled on Premium Tier backends. If you need CDN behaviour with Standard pricing, run a third-party CDN (Cloudflare, Akamai) in front of your Standard Tier regional LB.

Q: How do I tell which tier an existing resource uses?

A: For forwarding rules: gcloud compute forwarding-rules describe NAME --region=REGION --format="value(networkTier)". For addresses: gcloud compute addresses describe NAME --region=REGION --format="value(networkTier)". For project default: gcloud compute project-info describe --format="value(defaultNetworkTier)". In the console, the tier column appears on the External IP addresses and Forwarding rules pages, and it is also visible in the billing SKU description.

Q: Is there a tier choice for Cloud NAT egress?

A: Cloud NAT egresses through external IPs that are tier-bound. When you allocate manual NAT IPs, you choose their tier at reservation. When Cloud NAT auto-allocates IPs, they inherit the project default tier. Heavy NAT egress traffic is one of the largest hidden Premium-Tier line items in many GCP projects — auditing Cloud NAT IPs is a high-leverage cost optimisation move for projects that do not need Premium for NAT'd outbound traffic.

Q: What happens if I set --default-network-tier=STANDARD and then try to create a global LB?

A: The create command fails with a validation error stating that global forwarding rules require Premium Tier. You must explicitly pass --network-tier=PREMIUM on the global forwarding rule create command, or change the project default back. Many teams keep the default at Premium specifically to avoid hitting this confusion when ops engineers spin up new global LBs.

Q: Does egress within the same region cost the same on both tiers?

A: Egress within a region (VM in us-central1 to another VM in us-central1 via internal IPs) is free of tier charges entirely — that is intra-region VPC traffic. Egress from a VM in us-central1 to the public internet in North America is where the tier price kicks in: ~$0.12/GB on Premium (under 1 TB) versus ~$0.085/GB on Standard. The savings widen on inter-continental egress, where Standard Tier can be 40-50% cheaper.

Q: Can I mix tiers within a single load balancer?

A: Not within the same forwarding rule, but yes across multiple forwarding rules of the same LB. A common pattern: one Premium global forwarding rule on the canonical hostname for global users, plus a Standard regional forwarding rule on a "fast-path" hostname for a single high-volume regional customer who wants their own dedicated IP. Both rules can point at the same backend service.