Networking and Operations
VPC — Virtual Private Cloud
A Google Cloud Virtual Private Cloud (VPC) is a global, software-defined private network that provides connectivity for your compute resources. It matters because it serves as the foundational logical boundary for security, routing, and traffic management across your cloud architecture. You should reach for a VPC whenever you need to isolate resources, define custom internal IP ranges, or connect your cloud environment to on-premises data centers.
Understanding the Global VPC Structure
Unlike traditional networking models where networks are restricted to specific physical locations or hardware, a Google Cloud VPC is inherently global. This means you do not have to worry about the underlying physical distance between subnets located in different regions, as they all share the same VPC network. This abstraction is achieved through Google's proprietary Andromeda network virtualization stack, which manages the routing and encapsulation of packets across their high-speed global fiber backbone. When you provision resources, you are placing them into a logical construct that allows low-latency, private communication between instances across different geographic regions without needing to traverse the public internet. This architecture simplifies global scaling significantly, as you can design your application to be distributed geographically while maintaining a unified network policy and internal IP address space that persists regardless of the regional deployment of your specific compute nodes.
# Example of creating a custom VPC network via command line
gcloud compute networks create my-custom-vpc \
--subnet-mode=custom # 'custom' mode gives you full control over IP rangesSubnets and Regional Segmentation
While the VPC itself is global, subnets are regional entities. This design choice is fundamental to how Google Cloud manages availability and fault tolerance. By forcing subnets to reside within a specific region, Google ensures that you can design high-availability architectures that are resilient to regional failures. When you define a subnet, you must specify an IPv4 range using CIDR notation, which must not overlap with other subnets in the network. This segmentation allows you to group resources based on functional roles—such as application tiers or database tiers—and apply specific network policies to those groups. Because routing is controlled at the VPC level, traffic between subnets within the same VPC is routed automatically without requiring complex external gateway configurations. Understanding this regional constraint is critical for latency-sensitive applications, as you must place your compute instances in the same region as your data storage to minimize transmission delays.
# Creating a regional subnet within the custom VPC
gcloud compute networks subnets create my-subnet-us-east1 \
--network=my-custom-vpc \
--range=10.0.1.0/24 \
--region=us-east1Routing and Connectivity Management
Routing within a VPC is managed by the control plane, which automatically creates and maintains routes to ensure connectivity between subnets. When you create a subnet, the platform automatically installs local routes that allow instances to talk to each other. However, for complex requirements—such as sending traffic through a virtual firewall appliance or connecting to an on-premises network—you must define custom routes. These custom routes take precedence over dynamic or default routes based on the destination CIDR match, with the most specific match always winning. This deterministic routing behavior is the backbone of hub-and-spoke networking architectures. By understanding how the routing table processes packets, you can force traffic through specific exit points, which is essential for compliance, inspection, and security auditing. Proper route management ensures that your traffic follows intended paths, preventing data leakage and ensuring that packets always arrive at their intended destination across the virtual fabric.
# Adding a custom static route to the VPC network
gcloud compute routes create route-to-on-prem \
--network=my-custom-vpc \
--destination-range=192.168.0.0/16 \
--next-hop-gateway=default-internet-gatewayFirewall Rules and Security Groups
Firewall rules in Google Cloud are global, stateful, and tied to the VPC network rather than individual instances. This is a massive improvement over traditional legacy network firewalls that rely on hardware placement. Because rules are stateful, if you allow an incoming request, the response traffic is automatically allowed, regardless of the egress rules. You identify which traffic to permit or block using tags or service accounts, which are attached to the compute instances. This decouples your security policy from the IP addresses themselves, allowing you to move or scale instances without reconfiguring your firewall rules. By targeting rules based on service account identities, you create an 'identity-aware' network. This is the cornerstone of a Zero Trust architecture, where network access is granted based on what the service is, rather than where the service is located on the network topology.
# Creating a firewall rule to allow SSH traffic from anywhere
gcloud compute firewall-rules create allow-ssh \
--network=my-custom-vpc \
--allow tcp:22 \
--source-ranges=0.0.0.0/0VPC Peering for Network Expansion
VPC Peering enables two separate VPC networks to communicate using internal private IP addresses as if they were part of the same network. This is not a transitive relationship; if Network A is peered with Network B, and Network B is peered with Network C, Network A cannot communicate with Network C automatically. Peering is highly performant because it relies on the internal private networking infrastructure of the cloud provider, bypassing any public internet hops entirely. This is the preferred method for connecting disparate environments, such as a development VPC and a production VPC, or for sharing services across different organizational business units. Peering does not change the internal IP addresses of instances; it simply updates the routing table of both VPCs so they recognize the address ranges of the other. It is a powerful tool for scaling your architecture while maintaining strict administrative separation and resource-level isolation between different projects or departments.
# Establishing peering between two distinct VPC networks
gcloud compute networks peerings create peer-vpc-a-to-b \
--network=my-custom-vpc \
--peer-network=other-project-vpcKey points
- A VPC is a global resource that provides a private networking space across all regions.
- Subnets are regional, requiring careful planning for high-availability deployments.
- Internal routing is handled automatically, but custom routes allow for advanced traffic steering.
- Firewall rules are stateful and applied at the network level using tags or service accounts.
- Service accounts are preferred over IP ranges for defining firewall access control lists.
- VPC Peering allows private, low-latency communication between two independent VPC networks.
- Routing decisions always favor the most specific CIDR match within the VPC routing table.
- Logical network boundaries can be strictly enforced using custom VPCs instead of using the default network.
Common mistakes
- Mistake: Thinking VPCs are subnet-specific. Why it's wrong: VPCs are global resources, while subnets are regional. Fix: Understand that VPC resources span regions and communicate across them automatically.
- Mistake: Misconfiguring Firewall rules using IP-based security. Why it's wrong: IPs are dynamic and hard to manage. Fix: Use Network Tags or Service Accounts to manage firewall access based on resource identity.
- Mistake: Forgetting that VPCs are 'Custom' by default or 'Auto'. Why it's wrong: Auto mode creates subnets in all regions, which might be overkill. Fix: Choose 'Custom' mode for granular control over IP address ranges and CIDR blocks.
- Mistake: Assuming internal communication works without explicit firewall rules. Why it's wrong: By default, all ingress is blocked, and egress is allowed. Fix: Create ingress firewall rules to permit specific traffic between internal resources.
- Mistake: Neglecting the implicit 'deny all' firewall rule. Why it's wrong: New users often assume ports are open by default. Fix: Always explicitly allow the traffic you need and verify with VPC Flow Logs if connection issues persist.
Interview questions
What is a Google Cloud VPC and why is it considered a foundational component?
A Virtual Private Cloud (VPC) in Google Cloud is a global, software-defined network that provides connectivity for your Compute Engine VM instances, GKE clusters, and App Engine flexible environments. It is foundational because it acts as the primary logical boundary for your cloud resources. By defining subnets, firewall rules, and routes within a VPC, you ensure that your services can communicate securely and efficiently across different regions without traversing the public internet, which minimizes latency and improves overall security posture.
Can you explain the difference between a Custom VPC and a Default VPC in Google Cloud?
A Default VPC is automatically created for every new project and includes a subnet in every GCP region with pre-configured firewall rules for internal traffic and ICMP. While convenient for beginners, it is not recommended for production environments. A Custom VPC provides complete control over your network topology. By creating a custom VPC, you explicitly define your IP address ranges (CIDR blocks) and subnet distribution, which is critical for IP address management, regulatory compliance, and preventing address exhaustion as your infrastructure scales within your organization.
How does Google Cloud handle inter-subnet communication, and is a gateway required?
In Google Cloud, all subnets within a VPC are connected by default regardless of the region. Unlike traditional networking models, you do not need to configure an explicit gateway or router between subnets to allow communication. GCP handles this through its internal software-defined network control plane. As long as your firewall rules allow the traffic, any instance in one subnet can communicate with an instance in another subnet using its internal IP address, provided they reside within the same VPC network.
Compare VPC Peering and Shared VPC: when should you choose one over the other?
VPC Peering connects two independently managed VPCs, allowing them to communicate via internal IP addresses. Shared VPC, conversely, allows an organization to share a single common VPC across multiple projects. Choose VPC Peering when you have autonomous teams or external organizations needing limited connectivity. Choose Shared VPC when you need centralized network administration. Shared VPC is superior for enterprise environments because it allows a host project admin to manage firewall rules and subnets while service project admins focus solely on deploying applications.
How do you secure your VPC using Firewall Rules and VPC Service Controls?
Firewall rules in GCP are stateful and applied at the VPC level to control inbound and outbound traffic to instances based on tags, service accounts, or IP ranges. For example, to allow traffic only from a load balancer, you would define an ingress rule: 'gcloud compute firewall-rules create allow-lb --network=my-vpc --action=ALLOW --direction=INGRESS --source-ranges=130.211.0.0/22,35.191.0.0/16 --rules=tcp:80'. VPC Service Controls adds a perimeter layer that prevents data exfiltration by restricting access to managed services like Cloud Storage or BigQuery, even if an attacker has valid credentials, ensuring traffic stays within your defined network boundary.
Explain the role of Cloud NAT and why it is preferred over assigning external IP addresses to VM instances.
Cloud NAT (Network Address Translation) allows VM instances without external IP addresses to communicate with the internet for updates or API calls. It is preferred for security because it shields VMs from direct unsolicited inbound traffic from the internet. When you assign an external IP to a VM, you expose it to potential scanners. Using Cloud NAT, you maintain a private network posture. You configure it by creating a Cloud Router and a NAT gateway, ensuring your instances remain private while still retaining the ability to download patches from public repositories.
Check yourself
1. An architect needs to connect two VPCs in different projects to share services. Which mechanism provides the most performant, low-latency connection without needing a VPN or public internet?
- A.VPC Peering
- B.Cloud Interconnect
- C.External IP access
- D.Cloud VPN
Show answer
A. VPC Peering
VPC Peering allows internal IP connectivity between networks. Cloud Interconnect is for on-premises connectivity, VPN uses the internet, and external IPs are insecure for internal traffic.
2. A team requires a subnet with a specific CIDR range to adhere to corporate compliance. Which VPC configuration should they select?
- A.Auto-mode VPC
- B.Custom-mode VPC
- C.Global VPC
- D.Shared VPC
Show answer
B. Custom-mode VPC
Custom-mode VPCs allow you to define the exact CIDR ranges. Auto-mode creates default subnets in all regions, which lacks the required precision.
3. Your security policy mandates that instances should only communicate with instances labeled as 'web-server'. How should you configure your firewall rules?
- A.Specify the internal IP address of every web server in the rule
- B.Use network tags on the instances and reference the tag in the firewall rule
- C.Create a subnet for each web server
- D.Open all ports globally and filter traffic at the application level
Show answer
B. Use network tags on the instances and reference the tag in the firewall rule
Network tags provide identity-based security, which is easier to maintain than IP-based rules. Subnets are for network topology, and opening ports globally is a major security risk.
4. You have a VPC network that spans multiple regions. If you have an instance in us-central1 and an instance in europe-west1, how do they communicate using private IPs?
- A.They require a Cloud Router to connect the regions
- B.They require a VPN tunnel between the regions
- C.They communicate natively over Google's internal global network
- D.They cannot communicate because they are in different regions
Show answer
C. They communicate natively over Google's internal global network
Google Cloud VPCs are global, meaning instances across regions are on the same network and route traffic over Google's global backbone. No extra routers or VPNs are needed.
5. Why would an administrator choose to use a Shared VPC instead of VPC Peering?
- A.To increase the speed of network traffic
- B.To centralize network management across multiple projects under a single host project
- C.To bypass the need for firewall rules
- D.To allow communication with on-premises hardware only
Show answer
B. To centralize network management across multiple projects under a single host project
Shared VPC is designed for organizational structure where a central admin team manages the network, while service teams consume subnets. It simplifies management compared to managing multiple peerings.