GCDLChapter 3 of 101Objective 2.1

Google Cloud Infrastructure

This chapter covers Google Cloud's global infrastructure foundation: regions, zones, edge points of presence, and the underlying network fabric. Understanding this physical and logical topology is critical for the GCDL exam, as roughly 15-20% of questions touch on infrastructure concepts, including resource placement, fault tolerance, and latency optimization. We will examine how Google builds and operates its network, how resources are organized, and how you can leverage this architecture for high availability and performance.

25 min read
Intermediate
Updated May 31, 2026

GCP Infrastructure as a Modular Office Building

Imagine Google Cloud infrastructure as a modern office building with multiple floors. The building's foundation and steel frame (global network) span an entire city block, with entrances on every side (edge points of presence). Each floor (region) is a self-contained workspace with its own power, cooling, and elevators (zones). Within a floor, individual offices (VMs) are grouped into suites (subnets) connected by hallways (VPC networks). The building has a central mailroom (Cloud Router) that sorts incoming packages (packets) and delivers them to the correct suite. A security desk (firewall rules) checks IDs at every door. If a suite needs to receive packages from outside, it can request a dedicated loading dock (external IP address) or use the mailroom's shared dock (Cloud NAT). The building manager (Google Cloud Console) monitors everything from a central dashboard. This analogy breaks down when considering software-defined networking, encryption, and global load balancing, but it captures the hierarchical, modular, and interconnected nature of GCP's physical and logical infrastructure.

How It Actually Works

Regions and Zones

Google Cloud Platform (GCP) resources are hosted in regions and zones. A region is a specific geographic location where Google operates a data center campus. Each region contains multiple zones — physically separate data center buildings within that region, typically 2-3 zones per region. Zones are isolated from each other in terms of power, cooling, and network — a failure in one zone does not affect others. This design allows you to deploy applications across zones for high availability. For example, us-central1 has zones a, b, c, and f. As of 2025, there are over 40 regions and 120+ zones globally.

Edge Points of Presence (PoPs)

Google's network extends beyond regions via edge points of presence — over 200 locations worldwide. These are not data centers but network interconnection points where Google peers with ISPs and content providers. Edge PoPs cache content (via Cloud CDN) and terminate user connections close to the user, reducing latency. They also host Cloud Load Balancing and Cloud Armor services, enabling global traffic management and DDoS protection at the network edge.

Global Network

Google operates a private, software-defined global network that connects all regions, zones, and edge PoPs. This network uses Jupiter — a custom-designed switch fabric that provides high bandwidth (petabit-scale) and low latency. Traffic between GCP resources stays on Google's network as much as possible, avoiding the public internet. This improves performance and security. The network uses BGP for routing internally and externally, and supports MPLS for traffic engineering.

Virtual Private Cloud (VPC)

A VPC is a global, isolated virtual network within GCP. Unlike AWS where VPCs are regional, GCP VPCs span all regions. You define subnets (subnetworks) per region, and they can communicate globally within the VPC. VPCs provide network segmentation, firewall rules, and routing. You can create multiple VPCs for production, staging, and development. VPCs are software-defined and do not require physical routers or switches.

Subnets

Subnets are regional IP address ranges within a VPC. Each subnet has a CIDR block (e.g., 10.0.0.0/16). Resources like Compute Engine VMs receive IP addresses from subnets. Subnets can be auto-mode (auto-created with default ranges per region) or custom-mode (manually defined). Auto-mode subnets use a /20 per region, but you can expand them. Custom-mode gives full control.

Firewall Rules

Firewall rules are stateful and applied at the VM instance level, not at the subnet level (though they can target subnets via tags or service accounts). Rules can allow or deny ingress/egress traffic based on source/destination IP, protocol, port, and target. Default rules allow egress, deny ingress, and allow internal traffic within a VPC. Rules are evaluated in order of priority (lower number = higher priority). Ingress rules are evaluated before egress.

Cloud Router and Cloud NAT

Cloud Router uses BGP to dynamically exchange routes between your VPC and on-premises network via VPN or Dedicated Interconnect. Cloud NAT allows private instances to access the internet (for updates, etc.) without external IPs. Cloud NAT is regional and maps private IPs to a pool of public IPs, using port address translation (PAT). It supports up to 64,000 simultaneous connections per NAT IP.

Load Balancing

Google Cloud offers multiple load balancers: Global HTTP(S) Load Balancer (layer 7, for web traffic), Global SSL Proxy (for non-HTTP SSL), Global TCP Proxy (for TCP without SSL), Regional Internal Load Balancer (layer 4, for internal traffic), Regional External Load Balancer (layer 4, for external traffic). Global load balancers use the same anycast IP and distribute traffic across regions, leveraging Google's network and edge PoPs.

Cloud Interconnect and Peering

Dedicated Interconnect provides direct physical connections between your on-premises network and Google's network, supporting 10 Gbps or 100 Gbps per link. Partner Interconnect uses a third-party provider. Direct Peering connects your network to Google at an edge PoP for Google services (not GCP). Carrier Peering uses a partner. All these options reduce latency and increase bandwidth compared to VPN.

Resource Hierarchy

GCP resources are organized hierarchically: Organization -> Folders -> Projects -> Resources. Projects are the fundamental building block, containing all GCP resources. Folders group projects for policy management. Organization node sits at the top, representing your company. IAM policies are inherited down the hierarchy.

Default Values and Limits

VPCs per project: 5 (soft limit, can be increased)

Subnets per VPC: 500 (soft limit)

Firewall rules per VPC: 200 (ingress + egress, soft limit)

VM instances per project: 24 (soft limit, varies by region)

Persistent disk capacity per VM: 257 TB (max)

Internal IP addresses per project: 5,000 (soft limit)

External IP addresses per project: 50 (soft limit)

Interacting Services

Compute Engine (VMs) runs on infrastructure. GKE (Kubernetes) uses Compute Engine instances. Cloud Storage is a global service but data is stored regionally or multi-regionally. Cloud SQL and Spanner are regional. App Engine uses infrastructure but abstracts it. Cloud Functions run in a managed environment. All these services leverage the same network and resource hierarchy.

Verification Commands

Using gcloud CLI:

gcloud compute regions list
gcloud compute zones list
gcloud compute networks list
gcloud compute networks subnets list --region=us-central1
gcloud compute firewall-rules list
gcloud compute routers list
gcloud compute nat gateways list --region=us-central1
gcloud compute addresses list
gcloud compute instances list

Performance Considerations

Latency between zones in same region: < 1ms

Latency between regions: 10-100ms depending on distance

Bandwidth within a region: up to 100 Gbps per VM (using gVNIC)

Bandwidth across regions: limited by VM type and network tier (Premium vs Standard)

Use Premium Tier for global load balancing and lower latency; Standard Tier uses ISP networks.

Security

Data in transit encrypted by default between Google data centers.

Customer-supplied encryption keys (CSEK) or Cloud KMS for data at rest.

VPC Service Controls to prevent data exfiltration.

Private Google Access allows on-premises hosts to reach GCP APIs via private IP.

Billing and Quotas

Resources are billed per second (minimum 1 minute for VMs).

Sustained use discounts for running instances >25% of month.

Committed use contracts (1 or 3 years) for deeper discounts.

Quotas are per project per region: CPU, disk, IP addresses, etc. Soft quotas can be increased by request.

Walk-Through

1

Create a VPC Network

In the Cloud Console, navigate to VPC networks and click 'Create VPC Network'. Choose a name, select 'Custom' mode to manually define subnets. This creates a software-defined network that spans all regions. The VPC has no IP address itself; it is a container for subnets. You can also enable 'Private Google Access' to allow on-premises hosts to reach Google APIs via private IP. The VPC is created instantly because it is virtual.

2

Add Subnets per Region

For each region where you need resources, add a subnet. Specify a name, region, and IP address range (CIDR). For example, 10.0.1.0/24 in us-central1. You can also set private Google access and flow logs per subnet. Each subnet is regional; resources in different subnets can communicate via internal IPs. Subnets cannot overlap across regions within the same VPC. Auto-mode subnets are created automatically per region with /20 ranges, but custom mode gives you control.

3

Configure Firewall Rules

Create firewall rules to allow or deny traffic. For example, allow ingress SSH (tcp:22) from any source (0.0.0.0/0) with priority 1000. Rules are stateful: if you allow ingress, the corresponding egress is automatically allowed. You can target VMs by tags (e.g., 'web-server') or service accounts. Default rules allow all egress and deny all ingress. Rules are evaluated in order of priority; lower number = higher priority. The last rule is a deny-all if no match.

4

Deploy Compute Engine VMs

Create VM instances in specific zones. Choose a machine type, boot disk, and attach them to a VPC subnet. Each VM gets a primary internal IP from the subnet range. Optionally assign an external IP (ephemeral or static). VMs in the same VPC can communicate via internal IPs even across regions. Use tags to apply firewall rules. For high availability, deploy VMs in multiple zones within a region.

5

Set Up Cloud NAT for Internet Access

If VMs need to access the internet but have no external IPs, create a Cloud NAT gateway in the region. Specify the VPC, region, and optionally assign NAT IPs (can be auto-allocated or manual). Cloud NAT uses port address translation (PAT) to map internal IPs to external IPs. It supports up to 64,000 simultaneous connections per NAT IP. Configure router (Cloud Router) for dynamic routing if needed.

What This Looks Like on the Job

Enterprise Scenario 1: Global E-commerce Platform A large retailer deploys its web application across multiple regions (us-central1, europe-west1, asia-east1) using global HTTP(S) Load Balancer. The load balancer anycast IP terminates user connections at the nearest edge PoP, then routes traffic over Google's private network to the closest healthy backend. This minimizes latency and provides automatic failover if a region goes down. The backend VMs are in managed instance groups across zones within each region. Cloud CDN caches static assets at edge PoPs. Cloud Armor provides WAF and DDoS protection. The database is Cloud Spanner, which is globally distributed and strongly consistent. This architecture handles millions of requests per second with 99.99% availability. Common misconfigurations: not enabling health checks on backends, incorrect firewall rules blocking load balancer health probes (130.211.0.0/22, 35.191.0.0/16), or using Standard Tier instead of Premium Tier, causing higher latency.

Scenario 2: Hybrid Cloud with Dedicated Interconnect A financial services firm connects its on-premises data center to GCP via Dedicated Interconnect, with two 10 Gbps links for redundancy. Cloud Router establishes BGP sessions to exchange routes. The on-premises network advertises a /16 range, and GCP advertises VPC subnets. Firewall rules on-premises and in GCP control traffic. The firm uses Private Google Access so on-premises hosts can access Google APIs (e.g., Cloud Storage) via private IP. They also use VPC Service Controls to prevent data exfiltration. Common issues: BGP session flapping due to misconfigured timers (default hold time 90s, keepalive 30s), or exceeding BGP route limits (100 routes per VPC by default).

Scenario 3: Media Streaming with CDN and Load Balancing A video streaming service uses Cloud CDN to cache content at edge PoPs. Origin content is stored in Cloud Storage multi-region bucket. Global HTTP(S) Load Balancer routes user requests to the nearest cache. If cache miss, request goes to origin. They use signed URLs for access control. The infrastructure uses Premium Tier for lowest latency. They also use Cloud Armor to block malicious traffic. Scaling: CDN can handle terabits per second. Misconfigurations: not setting cache TTLs properly (default 1 hour), or enabling CDN on buckets with public access disabled incorrectly.

How GCDL Actually Tests This

The GCDL exam tests understanding of GCP infrastructure at a conceptual level, not deep configuration. Key objective codes: 2.1 (Define the infrastructure components of Google Cloud: regions, zones, edge points of presence, and the global network). You must know:

Regions vs Zones: Zones are isolated failure domains within a region. A region has at least 2 zones (often 3).

Edge PoPs: Used for CDN, load balancing, and peering. They are NOT data centers for compute.

Global VPC: Unlike AWS, VPCs are global. Subnets are regional.

Firewall rules: Stateful, applied at VM level, evaluated by priority.

Cloud NAT: For private instances to access internet. Regional, uses PAT.

Load balancing types: Global vs Regional, External vs Internal, Layer 4 vs Layer 7.

Interconnect options: Dedicated (direct physical), Partner (via provider), VPN (over internet).

Premium vs Standard Tier: Premium uses Google's network; Standard uses internet.

Common wrong answers: 1. 'Zones are geographic locations' — WRONG. Zones are within a region, regions are geographic. 2. 'VPCs are regional' — WRONG. GCP VPCs are global. 3. 'Cloud NAT provides static external IPs for VMs' — WRONG. Cloud NAT provides outbound internet access, not inbound. For inbound, use external IPs or load balancer. 4. 'Edge PoPs host compute instances' — WRONG. Edge PoPs are for caching and network functions, not general compute. 5. 'Firewall rules are applied at subnet level' — WRONG. They are applied at VM instance level via tags or service accounts.

Specific numbers: Regions >40, Zones >120, Edge PoPs >200. Default firewall rules: allow egress, deny ingress. Cloud NAT max connections per IP: 64,000. Interconnect speeds: 10 Gbps or 100 Gbps. VMs per project soft limit: 24.

Exam tips: When given a scenario about high availability, choose multi-zone deployment within a region. For global latency, choose Premium Tier and global load balancer. For private internet access, choose Cloud NAT. For hybrid connectivity, choose Dedicated Interconnect or VPN with Cloud Router. Always prefer Google's network over internet for performance.

Key Takeaways

GCP has over 40 regions and 120+ zones globally, with each region containing at least 2 zones.

Edge points of presence (200+) provide CDN caching, load balancing, and peering, not compute.

VPCs in GCP are global; subnets are regional.

Firewall rules are stateful, applied at VM level via tags or service accounts, evaluated by priority.

Cloud NAT provides outbound internet access for private VMs; supports up to 64,000 connections per NAT IP.

Premium Tier uses Google's private network for lower latency; Standard Tier uses internet.

Dedicated Interconnect offers 10 Gbps or 100 Gbps physical connections with 99.99% SLA.

Global load balancers use anycast IP and route traffic across regions via Google's network.

Default firewall rules allow all egress and deny all ingress.

Resource hierarchy: Organization > Folders > Projects > Resources with IAM inheritance.

Easy to Mix Up

These come up on the exam all the time. Here's how to tell them apart.

Premium Tier

Traffic uses Google's private global network from edge PoP to destination.

Lower latency and higher performance.

Supports global load balancing with anycast IP.

Costs more per GB of egress.

Recommended for latency-sensitive applications.

Standard Tier

Traffic uses public internet after leaving Google's edge.

Higher latency, variable performance.

Only supports regional load balancing.

Lower cost per GB of egress.

Suitable for cost-sensitive, non-latency-critical apps.

Dedicated Interconnect

Direct physical connection between on-prem and Google.

Supports 10 Gbps or 100 Gbps per link.

Higher reliability and lower latency.

Requires physical colocation or provider.

SLA of 99.99% availability.

VPN

Encrypted tunnel over public internet.

Bandwidth limited by internet connection (typically 1-10 Gbps).

Variable latency and reliability.

No physical setup; uses Cloud VPN gateway.

SLA of 99.9% availability.

Global HTTP(S) Load Balancer

Layer 7 load balancing for HTTP/HTTPS traffic.

Global anycast IP, routes to nearest healthy backend.

Supports content-based routing, SSL offload.

Backends can be in multiple regions.

Uses Premium Tier for global routing.

Regional Internal Load Balancer

Layer 4 load balancing for TCP/UDP traffic.

Regional, uses internal IP addresses.

No content awareness; simple traffic distribution.

Backends must be in same region.

Uses Andromeda software-defined networking.

Watch Out for These

Mistake

GCP regions and zones are the same as AWS availability zones.

Correct

GCP zones are analogous to AWS AZs, but GCP regions typically have 2-3 zones, while AWS often has 3-6. Also, GCP VPCs are global, not regional like AWS.

Mistake

Edge points of presence can run compute workloads like VMs.

Correct

Edge PoPs are network interconnection points with caching (CDN) and load balancing. They do not host general compute instances like Compute Engine VMs.

Mistake

Cloud NAT allows inbound connections to private VMs.

Correct

Cloud NAT is for outbound-only. Inbound connections require an external IP or load balancer. Cloud NAT translates internal IPs to external for outgoing traffic only.

Mistake

Firewall rules are applied at the subnet level in GCP.

Correct

Firewall rules are applied at the VM instance level via tags or service accounts, not at the subnet. However, you can target instances in a subnet by using a tag applied to all instances in that subnet.

Mistake

Google Cloud's network is the same as the public internet.

Correct

Google's network is a private, software-defined global network separate from the public internet. Traffic between GCP resources stays on this network, providing better performance and security.

Do You Actually Know This?

Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.

Frequently Asked Questions

What is the difference between a region and a zone in GCP?

A region is a geographic location (e.g., us-central1) containing multiple zones. A zone is an isolated data center building within a region. Zones are designed to be independent failures—if one zone goes down, others in the same region remain operational. Deploying resources across zones provides high availability. For the exam, remember that regions are geographic, zones are failure domains within a region.

Can I create a VPC that spans multiple regions?

Yes, GCP VPCs are global by default. You can create subnets in multiple regions within the same VPC. Resources in different subnets can communicate via internal IPs. This differs from AWS where VPCs are regional. On the exam, remember that GCP VPCs are global.

What is Cloud NAT and when should I use it?

Cloud NAT allows private Compute Engine instances (without external IPs) to access the internet for outbound connections, such as downloading updates or accessing APIs. It uses port address translation (PAT) and supports up to 64,000 simultaneous connections per NAT IP. Use it when you want to avoid giving instances public IPs for security reasons. It does not allow inbound connections.

How does Google's Premium Tier differ from Standard Tier?

Premium Tier routes traffic over Google's private global network from the edge point of presence to the destination, reducing latency and improving performance. Standard Tier uses the public internet after the edge. Premium Tier costs more but is recommended for latency-sensitive applications. It also enables global load balancing with anycast IP. Standard Tier is cheaper but provides variable performance.

What are the options for connecting an on-premises network to GCP?

Options include: Cloud VPN (IPsec tunnel over internet), Dedicated Interconnect (direct physical connection up to 100 Gbps), Partner Interconnect (via third-party provider), and Direct Peering (at edge PoP for Google services). Dedicated Interconnect offers highest bandwidth and reliability with 99.99% SLA. VPN is simpler but lower performance. The exam expects you to know the differences and use cases.

Are firewall rules in GCP stateful?

Yes, GCP firewall rules are stateful. If you allow an ingress connection, the corresponding egress traffic is automatically allowed. Similarly, if you allow egress, return traffic is allowed. This simplifies rule management. Rules are applied at the VM instance level via tags or service accounts, not at the subnet level.

What is the resource hierarchy in GCP?

The hierarchy is: Organization node (top-level, representing your company) -> Folders (group projects) -> Projects (container for resources) -> Resources (VMs, storage, etc.). IAM policies are inherited downwards. This structure allows centralized management and policy enforcement. The exam may ask about inheritance or where to apply policies.

Terms Worth Knowing

Ready to put this to the test?

You've just covered Google Cloud Infrastructure — now see how well it sticks with free GCDL practice questions. Full explanations included, no account needed.

Done with this chapter?