Networking on Google Cloud

A Virtual Private Cloud (VPC) is a logically isolated section of Google Cloud where you can launch resources. Unlike traditional on-premises networking where you manage physical routers and switches, Google Cloud's VPC is global and software-defined. A single VPC can span multiple regions and zones without explicit inter-region peering. This is a key differentiator from AWS and Azure, where VPCs are region-specific. GCDL tests your understanding that VPCs are global resources.

Subnets are regional resources that define IP address ranges (CIDR blocks) within a VPC. Each subnet must have a unique IP range (e.g., 10.0.1.0/24) and cannot overlap with other subnets in the same VPC. Subnets can be auto-mode or custom-mode. Auto-mode subnets are created automatically in each region with a /20 range (10.128.0.0/9 overall), while custom-mode gives you full control. GCDL expects you to know that auto-mode subnets use predefined IP ranges and are not recommended for production because they waste IP space and limit customization.

Firewall rules control ingress and egress traffic at the instance level (not subnet level like AWS NACLs). Rules are stateful, meaning if you allow outbound traffic, the return traffic is automatically allowed regardless of inbound rules. This is a critical exam point. Firewall rules are defined by priority (0–65535, lower number = higher priority), direction (INGRESS or EGRESS), action (allow or deny), source/destination IP ranges, protocols, and ports. The implied deny rule (priority 65535) blocks all traffic not explicitly allowed. There is also an implied allow egress rule (priority 65535) that allows all outbound traffic. GCDL tests that firewall rules are applied at the VPC level and can target instances via service accounts or tags.

Routes tell instances how to send traffic. Every VPC has default routes for each subnet that direct traffic within the subnet. There is also a default route (0.0.0.0/0) that points to the internet gateway. Routes can be static (manually created) or dynamic (learned via Cloud Router and BGP). The most specific route (longest prefix match) wins. GCDL focuses on understanding that VPC routing tables are managed automatically for subnets but need manual configuration for custom destinations (e.g., on-premises networks).

Cloud NAT (Network Address Translation) allows private instances (without external IPs) to access the internet for updates, patches, or API calls. It translates private IPs to a pool of public IPs. Key parameters include:

Cloud NAT is regional and can be configured per subnet. It does not support inbound connections; it is outbound-only. GCDL tests that Cloud NAT is used when private instances need internet access without public IPs.

Google Cloud offers several load balancers:

All load balancers are managed, scalable, and support health checks. GCDL emphasizes that global load balancers use Google's global network to route traffic to the nearest region, reducing latency.

Google Cloud provides multiple options for hybrid connectivity:

GCDL tests that Cloud Interconnect provides higher bandwidth and more reliable connections than VPN, but at a higher cost. Cloud Router is essential for automatic route exchange.

VPC peering allows two VPCs to communicate using internal IPs as if they were on the same network. Peering is not transitive—if VPC A peers with B and B peers with C, A cannot communicate with C through B. This is a common exam trap. Peering supports up to 25 Gbps per connection.

Shared VPC allows an organization to host a common VPC in a host project and share its subnets with other service projects. This is useful for centrally managed network infrastructure. The host project owns the VPC and subnets, while service projects can create instances in those subnets. GCDL tests that Shared VPC simplifies network administration and security policy enforcement.

Private Google Access allows on-premises or VM instances without external IPs to reach Google APIs and services (e.g., Cloud Storage, BigQuery) using private IPs. It works by routing traffic through a VPC and using the default internet gateway but with destination filtering. This is different from Private Services Access, which provides private connectivity to Google-managed services (e.g., Cloud SQL). GCDL expects you to differentiate these two.

Cloud CDN uses Google's global edge cache to deliver content closer to users. It works with the global external HTTP(S) load balancer. Cache hit ratio and time-to-live (TTL) settings are key concepts. GCDL tests that Cloud CDN reduces latency and offloads backend servers.

Google Cloud offers two network service tiers:

GCDL tests that Premium Tier is recommended for latency-sensitive applications, while Standard Tier can be cost-effective for bulk data transfer.

Firewall Insights provide visibility into firewall rule usage, identifying unused or overly permissive rules. Network Intelligence Center offers topology and performance monitoring. These are operational tools that GCDL may mention as best practices for network optimization.

Packet Mirroring clones traffic from specified instances and sends it to a collector for security monitoring. It works by applying a mirroring policy to a VPC. This is useful for intrusion detection systems (IDS). GCDL tests that Packet Mirroring is used for security analysis, not for load balancing or failover.

Pricing for network egress varies by tier. Premium Tier egress to internet is higher than Standard Tier. However, inter-region traffic within Google's network is free for Premium Tier (except for certain destinations). GCDL expects you to understand cost implications of tier choice.

Networking integrates with Compute Engine (VM instances), GKE (Kubernetes clusters), Cloud SQL (private IP), Cloud Load Balancing, Cloud CDN, and Cloud Armor (WAF). GCDL tests how network design affects these services. For example, Private Services Access enables Cloud SQL to use private IPs, and VPC-native clusters in GKE use alias IP ranges.

A multinational e-commerce company uses Google Cloud to host its web application across us-central1 and europe-west1. They use a global external HTTP(S) load balancer to route traffic to the nearest region, reducing latency. The backend consists of managed instance groups in each region. Firewall rules allow HTTP/HTTPS traffic only from the load balancer's IP ranges (130.211.0.0/22 and 35.191.0.0/16). Cloud NAT is configured for private instances that need to fetch updates from the internet. The company uses Cloud Interconnect (10 Gbps) to connect to their on-premises database. Cloud Router exchanges routes via BGP, enabling seamless communication. Misconfiguration of firewall rules (e.g., allowing all traffic from 0.0.0.0/0) would expose instances to the internet, leading to security incidents. Overlapping IP ranges between VPC and on-premises would break connectivity, requiring re-IPing. The network engineer must monitor Cloud NAT port exhaustion—if the number of concurrent connections exceeds available ports, connections fail. They adjust the minimum ports per VM to 128 to handle peak load. Another scenario: a healthcare startup uses Shared VPC to centralize networking. The host project has a VPC with subnets for dev, test, and prod. Service projects deploy instances in these subnets. This ensures consistent firewall and routing policies. However, they must avoid overlapping subnet ranges between environments. A common mistake is creating subnets in different regions with overlapping CIDRs, which is not allowed. They also use Private Google Access to allow VMs without external IPs to access BigQuery APIs, reducing data exfiltration risk. The network engineer configures Private Services Access for Cloud SQL to use private IPs, improving security. They also set up VPC peering between the Shared VPC and a partner's VPC for data exchange. Non-transitive peering is a pitfall—they must establish direct peering with each partner VPC.