Lesson 2: Network Tiers, High Availability and Scale

Why this level matters

Section 1.1 of Google's exam guide starts with two items: "Differentiating between network tiers (e.g., Premium and Standard)" and "Designing for high availability, failover, disaster recovery, and scale." They belong together because your network tier decides which failover tools you can use. Pick Standard Tier and global load balancing is off the table, along with automatic failover between regions.

A reminder from Level 1: the exam guide is Google's own document, it is free on Google's certification page, and it is not reproduced here. Check Google's exam page for length, price and languages. This course is independent of Google, not endorsed by it, and no course can promise a pass.

Premium vs Standard Tier: where your packets travel

Think of Google's network as a private motorway and the public internet as local roads.

• Premium Tier (the default). Traffic from a user enters Google's network at a point of presence (PoP) as close as possible to the user, then travels on Google's global backbone. Outbound traffic also rides the backbone. You get lower, steadier latency and global external IP addresses.
• Standard Tier. Traffic enters Google's network at a PoP close to the region where your resource lives. Until then it crosses ordinary ISP networks. Outbound traffic leaves through peering or transit local to that region. Google positions it as the cost-optimised choice, and it is available in all regions for resources with regional external IPs.

The rule that decides most exam questions: all global external IP addresses must use Premium Tier. Here is what follows from that:

Gotcha: the tier applies to external traffic. Traffic inside your VPC between regions always uses Google's network whatever tier you choose.

Walkthrough: setting the tier

You set a default for the project, and individual resources can override it. The resource-level tier wins.

# Check the project's default tier (PREMIUM unless someone changed it)
gcloud compute project-info describe \
    --format="value(defaultNetworkTier)"
# PREMIUM

# Change the project default. Existing resources keep their tier;
# only NEW resources created without an explicit tier use it.
gcloud compute project-info update --default-network-tier=STANDARD

# Override per resource: a cheap batch VM in one region on Standard Tier
gcloud compute instances create report-batch-1 \
    --zone=europe-west2-a \
    --network-tier=STANDARD

# A regional Standard Tier IP for a regional external Application LB
gcloud compute addresses create web-eu-ip \
    --region=europe-west2 \
    --network-tier=STANDARD

In the console, the tier appears as a drop-down whenever you reserve an external IP address or set up a load balancer's frontend.

Trade-off: Standard Tier is a sensible choice for a regional workload whose users sit near the region, or for bulk egress where some latency jitter does no harm. It is a poor choice for a global audience, or for any design that needs one anycast IP serving several regions.

Designing for high availability, failover and scale

Work from the failure you have to survive.

# Regional MIG: spreads 3 VMs across zones in europe-west2
gcloud compute instance-groups managed create web-mig-eu \
    --region=europe-west2 \
    --template=web-template \
    --size=3 \
    --health-check=web-hc \
    --initial-delay=120   # give VMs time to boot before autohealing

# Scale on load rather than guessing a size
gcloud compute instance-groups managed set-autoscaling web-mig-eu \
    --region=europe-west2 \
    --min-num-replicas=3 --max-num-replicas=12 \
    --target-cpu-utilization=0.6

Repeat this in us-east1 and put both MIGs behind one global external Application Load Balancer. If health checks fail in Europe, the load balancer sends users to the US backends. The IP address stays the same and no DNS change is needed. (Level 3 covers how to choose between load balancers.)

Disaster recovery: RTO and RPO drive the design

• RTO is the longest your application can be offline.
• RPO is the largest window of data you can afford to lose.

Google's DR guidance groups designs as cold, warm and hot:

• Cold. Backups only, and you rebuild after the disaster. RTO is hours or more, and the cost is lowest.
• Warm. A scaled-down standby in a second region. You scale it up and redirect traffic. RTO is minutes to an hour.
• Hot. Active-active in two or more regions behind a global LB, with replicated data. RTO is near zero, and the cost is highest.

Worked example: a retailer needs RTO 5 minutes and RPO near zero for checkout. A warm standby that needs scaling and manual DNS changes would struggle to meet that. The fit is a hot design: regional MIGs in two regions behind a Premium Tier global external Application LB, plus a database with cross-region replication.

Hunting single points of failure

When you read a scenario, walk the request path and ask at each hop: "if this one thing dies, what happens?" Common culprits:

• A zonal MIG or a single VM. Fix: a regional MIG.
• All backends in one region. Fix: a second region behind a global LB.
• A Standard Tier regional IP fronting a "global" app. Fix: Premium Tier and a global LB.
• One hybrid link or one VPN tunnel. Fix: redundant connections (covered in the hybrid levels).

What the exam asks about this

Expect scenarios such as "cut egress cost for a regional app" (answer: Standard Tier) or "global users, single anycast IP, CDN" (answer: Premium Tier). You may get "they switched to Standard Tier and now the global LB can't be created" (reason: global IPs need Premium). There will also be RTO/RPO prompts where you match cold, warm or hot to the stated targets, and "remove the single point of failure" questions where the right answer is the cheapest change that covers the failed domain.

Key takeaways

• Premium Tier is the default. It uses Google's backbone close to the user and supports global IPs, global LBs and Cloud CDN.
• Standard Tier is regional and cheaper. It routes over ISP networks to a PoP near the region and supports only regional/passthrough external LBs.
• The resource-level tier overrides the project default. Changing the default affects only new resources.
• Match each failure domain to a mechanism: autohealing, regional MIG, multi-region with a global LB, DNS failover.
• RTO and RPO choose the pattern: cold, warm or hot.