This chapter covers Google Cloud Virtual Private Cloud (VPC) networking fundamentals, which is a core topic for the ACE exam, appearing in approximately 15-20% of questions. You will learn about VPC design, subnets, firewall rules, routing, and connectivity options like Cloud NAT, VPN, and Interconnect. Understanding VPC networking is essential for planning and deploying secure, scalable applications on Google Cloud, and the ACE exam tests both conceptual knowledge and hands-on configuration.
Jump to a section
Think of a Google Cloud VPC as a private office building. The building itself (VPC) is isolated from the outside world—no one can just walk in from the street. Inside, there are multiple floors (subnets), each with its own set of rooms (instances). Each floor has a designated area (IP address range) that defines where rooms can be placed. Doors between floors are controlled by security guards (firewall rules) who check badges (source IP and port) before allowing entry. The building has a main reception (Cloud NAT) that allows employees to call out to the public phone network (internet) using a single shared phone number (external IP), but outside callers cannot reach employees directly unless the employee has a dedicated phone line (external IP address). For secure connections to another building across town (on-premises network), a dedicated private tunnel (Cloud VPN or Dedicated Interconnect) is built. The building's internal phone directory (Cloud DNS) lets employees find each other by name (hostname) rather than remembering extension numbers (IP addresses). Every time someone enters or leaves, a log is recorded (VPC Flow Logs) for security review. The building manager (Google Cloud) handles the physical security and infrastructure, while the tenant (you) is responsible for configuring access, subnets, and firewall rules.
What is a VPC?
A Virtual Private Cloud (VPC) is a logically isolated section of Google Cloud where you can launch resources in a virtual network that you define. Unlike traditional on-premises networks, GCP VPCs are global in scope—a single VPC can span multiple regions worldwide. This global nature means subnets are regional resources, but routes and firewall rules can apply across the entire VPC. Each VPC exists within a project, and you can have multiple VPCs per project. The VPC is the foundation for all networking in GCP; every Compute Engine instance, GKE node, or other resource that requires network connectivity must be associated with a VPC and a subnet.
Subnets
Subnets are regional subdivisions of a VPC. Each subnet is defined by an IP address range in CIDR notation (e.g., 10.0.0.0/16). When you create a subnet, you specify the region and the primary IP range. Optionally, you can add secondary IP ranges for alias IPs (used by containers or services). Resources within the same region can be placed in the same subnet, and they communicate using private IPs. Subnets are not tied to a specific zone; they span all zones in the region. You can create up to 10 subnets per VPC per region (default quota, can be increased).
Firewall Rules
Firewall rules control traffic to and from instances. They are stateful: if you allow inbound traffic, the outbound response is automatically allowed (and vice versa). Rules are evaluated based on priority (0-65535, with lower numbers having higher priority). The implicit default rules: - default-allow-internal: Allows all traffic within the VPC (all protocols/ports) between instances. Priority 65534. - default-allow-ssh: Allows TCP 22 from 0.0.0.0/0. Priority 65534. - default-allow-rdp: Allows TCP 3389 from 0.0.0.0/0. Priority 65534. - default-allow-icmp: Allows ICMP from 0.0.0.0/0. Priority 65534. - default-deny-ingress: Denies all ingress traffic not explicitly allowed. Priority 65535. - default-allow-egress: Allows all egress traffic. Priority 65535.
You can create custom rules using tags (target tags) or service accounts as source/target. Firewall rules are applied at the instance level, not the subnet level. They are global to the VPC.
Routes
Routes tell instances how to send traffic. Each VPC has a default route for internet access (0.0.0.0/0) that points to the default internet gateway. You can create custom routes for specific destinations. Routes are applied to instances based on the network tag or the subnet. The most specific route (longest prefix match) wins. If no route matches, traffic is dropped. Routes can be static or dynamic (via Cloud Router).
Cloud NAT
Cloud NAT (Network Address Translation) allows instances without external IP addresses to access the internet. It translates private source IPs to a pool of external IPs. You configure a Cloud NAT gateway in a region, associate it with a Cloud Router, and specify the subnets or tags that should use it. NAT is not a one-to-one mapping; it uses port address translation (PAT) to multiplex many internal connections over a few external IPs. Cloud NAT supports configurable timeout values (e.g., TCP established idle timeout default 1200 seconds, UDP idle timeout default 30 seconds).
Private Google Access
Private Google Access allows instances without external IPs to reach Google APIs and services (e.g., Cloud Storage, BigQuery) using private IPs. You enable it per subnet. Traffic goes through Google's internal network, not the internet. This is separate from Cloud NAT—you can have Private Google Access without NAT.
VPC Peering
VPC peering connects two VPCs (in same or different projects) so that resources can communicate using internal IPs. Peering is not transitive—if VPC A is peered with B, and B with C, A cannot talk to C via B. You must create separate peerings. Routes are exchanged automatically. Firewall rules still apply; you must allow traffic via firewall rules. Peering can be within the same organization or across organizations.
Shared VPC
Shared VPC allows you to share a VPC from a host project with service projects. The host project owns the VPC, subnets, and firewall rules. Service projects can create instances in those subnets. This is useful for centralized networking management. IAM roles control who can use which subnets. The host project and service projects must be in the same organization.
Cloud VPN and Interconnect
Cloud VPN: Site-to-site IPSec VPN tunnel between on-premises and GCP. Supports 1.5 Gbps per tunnel (with HA VPN). Classic VPN (deprecated) supports 3 Gbps per tunnel. HA VPN provides 99.99% SLA using two external IP addresses and two tunnels.
Dedicated Interconnect: Direct physical connection between on-premises and Google Cloud. Provides 10 Gbps or 100 Gbps per circuit. Requires a colocation facility and Google partner.
Partner Interconnect: Connectivity through a supported service provider. Speeds from 50 Mbps to 10 Gbps.
Cloud Router
Cloud Router is a managed BGP speaker that exchanges routes between your VPC and on-premises network over VPN or Interconnect. It supports dynamic routing, so you don't need to manage static routes. You can advertise custom IP ranges and learn routes from on-premises.
VPC Flow Logs
Flow logs capture information about IP traffic going to and from network interfaces. They can be used for network monitoring, forensics, and security analysis. Logs are sampled (default 50% of flows) and aggregated. You can enable or disable per subnet. Flow logs do not affect performance but incur costs.
Networking Pricing
VPC: No charge for VPCs, subnets, firewall rules, or routes.
Cloud NAT: Charged per hour for NAT gateway + data processing per GB.
VPC Peering: No charge for peering, but egress costs apply.
VPN: Charged per tunnel per hour + data transfer.
Interconnect: Monthly fee per circuit + data transfer.
Flow Logs: Charged per GB of logs generated.
Configuration Examples
Create a VPC with custom subnets:
gcloud compute networks create my-vpc --subnet-mode=custom
gcloud compute networks subnets create my-subnet --network=my-vpc --region=us-central1 --range=10.0.1.0/24Create a firewall rule allowing SSH from a specific IP:
gcloud compute firewall-rules create allow-ssh-admin --network=my-vpc --allow=tcp:22 --source-ranges=203.0.113.0/24Enable Private Google Access on a subnet:
gcloud compute networks subnets update my-subnet --region=us-central1 --enable-private-ip-google-accessCreate a Cloud NAT:
gcloud compute routers create my-router --network=my-vpc --region=us-central1
gcloud compute routers nats create my-nat --router=my-router --region=us-central1 --nat-all-subnet-ip-ranges --auto-allocate-nat-external-ipsDesign VPC and Subnets
First, determine the IP address plan. Choose a CIDR range that does not overlap with on-premises networks or other VPCs you might peer with. Decide whether to use auto-mode (default subnets per region) or custom-mode (full control). Auto-mode assigns /20 subnets per region, but you cannot delete them; you can add custom subnets. Custom-mode is recommended for production. Create subnets in regions where you will deploy resources. Each subnet requires a primary IP range (e.g., /24) and optionally secondary ranges. Consider future growth: leave room for expansion. Also decide if you need Private Google Access enabled per subnet.
Configure Firewall Rules
Start with the principle of least privilege. Review default rules; you may want to delete default-allow-ssh and default-allow-rdp if not needed, or restrict source ranges. Create custom rules using target tags for granularity. For example, tag web servers with 'web' and create a rule allowing TCP 80/443 from 0.0.0.0/0 to instances with that tag. For backends, allow only from the web server tag. Remember that firewall rules are stateful; you do not need separate outbound rules for responses. Rules are evaluated in priority order; the first matching rule (lowest priority number) is applied. Use deny rules sparingly; default deny ingress covers most cases.
Set Up Internet Access
Decide how instances will access the internet. If instances need external IPs for inbound access (e.g., web servers), assign ephemeral or static external IPs. For outbound-only access (e.g., updates, API calls), use Cloud NAT. Create a Cloud Router and NAT gateway in the same region as the subnets. Configure NAT to use all subnet IP ranges or specific ranges. If instances also need to reach Google APIs without external IPs, enable Private Google Access on the subnet. Note: Cloud NAT and Private Google Access can coexist; NAT handles non-Google internet traffic, while Private Google Access handles Google APIs.
Connect to On-Premises
Choose a connectivity method based on bandwidth and SLA requirements. For small sites (<1.5 Gbps) or testing, use HA VPN. Create a Cloud Router in the same region as the VPN gateway. Configure BGP sessions with the on-premises router. Advertise the VPC subnets and on-premises subnets. For higher bandwidth or dedicated connection, use Dedicated Interconnect (10/100 Gbps) or Partner Interconnect (50 Mbps-10 Gbps). Set up VLAN attachments and BGP sessions via Cloud Router. Ensure no IP overlap between VPC and on-premises. Test connectivity by pinging an instance private IP from on-premises.
Implement Monitoring and Logging
Enable VPC Flow Logs on subnets to capture traffic metadata. Use logs for troubleshooting connectivity issues, detecting anomalies, or compliance. Be aware that flow logs are sampled (default 50%) and aggregated every 5 seconds. They do not capture every packet. Set up log sinks to export logs to BigQuery or Cloud Storage for analysis. Also configure Cloud Monitoring alerts for high packet loss or latency. For VPN tunnels, monitor tunnel status and BGP session state. Use Network Intelligence Center for topology visualization and performance tests.
Scenario 1: Multi-tier Web Application A company deploys a three-tier web application (web, app, database) in a single VPC. They use custom-mode subnets: web-subnet (us-central1, 10.0.1.0/24), app-subnet (10.0.2.0/24), db-subnet (10.0.3.0/24). Firewall rules: allow TCP 80/443 from 0.0.0.0/0 to instances with tag 'web', allow TCP 8080 from tag 'web' to tag 'app', allow TCP 3306 from tag 'app' to tag 'db'. Web instances have external IPs (for user traffic) and use Cloud NAT for outbound updates. App and DB instances have no external IPs; they use Cloud NAT only for updates and Private Google Access for API calls. VPC Flow Logs enabled on all subnets for security auditing. This design minimizes attack surface and provides clear traffic isolation.
Scenario 2: Hybrid Cloud with Shared VPC A large enterprise uses Shared VPC to centralize networking. The host project contains the VPC with subnets in multiple regions. Service projects (e.g., dev, prod) create instances in these subnets. The network team manages firewall rules, Cloud NAT, and VPN connections. On-premises connectivity via Dedicated Interconnect with Cloud Router exchanging BGP routes. Each service project has limited permissions (compute.networkUser) to use specific subnets. This model enforces consistent security policies and reduces administrative overhead. Common issues include IP address exhaustion if subnets are too small, and firewall rule conflicts when multiple teams add rules. Proper planning and quota monitoring are critical.
Scenario 3: E-commerce Platform with Global Load Balancing An e-commerce platform uses a global external HTTP(S) load balancer with backends in multiple regions. The load balancer distributes traffic to instance groups in different subnets. Each backend instance has no external IP; they rely on Cloud NAT for outbound traffic (e.g., payment gateway calls). Private Google Access is used to store session data in Cloud Memorystore. The VPC spans us-east1, europe-west1, and asia-east1. Firewall rules allow health check probes from Google's health check ranges (35.191.0.0/16, 130.211.0.0/22) to all backends. Misconfiguration often occurs when health check ranges are not allowed, causing backend instances to be marked unhealthy. Also, if Cloud NAT is not configured, backend instances cannot reach external services, causing transaction failures.
The ACE exam tests VPC networking under objective 2.1 (Planning Solutions). Key areas: 1. VPC types: Auto vs custom mode. Auto-mode creates subnets in every region automatically; custom-mode gives full control. Exam question: "Which VPC mode allows you to create subnets only in specific regions?" Answer: custom-mode. 2. Firewall rules: Understand statefulness, priority, target tags, and service accounts. Common wrong answer: thinking firewall rules are applied per subnet (they are applied per instance). Another trap: believing that deny rules override allow rules based on order (they are evaluated by priority, not order of creation). 3. Cloud NAT vs Private Google Access: Many candidates confuse them. Cloud NAT provides outbound internet for non-Google destinations. Private Google Access allows access to Google APIs without external IPs. They are independent but often used together. 4. VPC Peering: Non-transitive nature is a frequent exam point. Question: "You have VPC A peered with B, and B peered with C. Can A communicate with C?" Answer: No, unless you create direct peering or use a VPN/Interconnect. 5. Shared VPC: Know that host project owns the VPC, service projects can use subnets. IAM roles: compute.networkUser grants access to use subnets. Common mistake: thinking service projects can create their own subnets in the shared VPC (only host project can). 6. Connectivity: HA VPN vs Classic VPN. HA VPN provides 99.99% SLA, requires two tunnels. Classic VPN (deprecated) has no SLA. Know that Cloud Router is required for dynamic routing with VPN or Interconnect. 7. VPC Flow Logs: Sampled at 50% by default, aggregated every 5 seconds. They do not capture every packet. Useful for troubleshooting but not real-time. 8. Pricing: VPC itself is free; you pay for data transfer, NAT gateway hours, VPN tunnels, Interconnect, and flow logs.
Edge cases: When using Cloud NAT, if you need to whitelist your external IPs, you must reserve static external IPs for the NAT gateway. Also, if you have instances with external IPs, they do not use Cloud NAT for outbound traffic (they use their own IP). Exam loves to test this: "An instance with an external IP is trying to reach the internet; will it use Cloud NAT?" No.
Eliminating wrong answers: For questions about connectivity, check if the scenario requires private IPs only or public. If private, eliminate options that assign external IPs. If the question mentions "no external IPs" but needs internet access, Cloud NAT is required. If only Google APIs, Private Google Access is sufficient.
VPCs are global; subnets are regional. A single VPC can span multiple regions.
Firewall rules are stateful, evaluated by priority (0-65535), and applied per instance using target tags or service accounts.
Cloud NAT provides outbound internet access for instances without external IPs; it does not allow inbound connections.
Private Google Access allows instances to reach Google APIs via private IPs, enabled per subnet.
VPC peering is non-transitive; you cannot route through a peered VPC to reach another VPC.
Shared VPC allows central management of network resources from a host project; service projects can use subnets with appropriate IAM.
HA VPN provides 99.99% SLA with two tunnels and requires Cloud Router for dynamic routing.
VPC Flow Logs are sampled (default 50%) and aggregated every 5 seconds; they are not real-time.
Auto-mode VPCs create /20 subnets in every region automatically; custom-mode gives full control.
To connect on-premises to GCP, use Cloud VPN for smaller bandwidths or Interconnect for higher bandwidth and lower latency.
These come up on the exam all the time. Here's how to tell them apart.
Auto-mode VPC
Creates subnets in each region automatically (one /20 subnet per region)
Cannot delete auto-created subnets
Suitable for quick testing or simple deployments
Less control over IP address ranges
Subnets are created with default ranges (e.g., 10.128.0.0/20 for us-central1)
Custom-mode VPC
No subnets created automatically; you define all subnets
Full control over IP ranges and regions
Recommended for production and complex architectures
Must create at least one subnet before deploying resources
Allows use of any private IP range (RFC 1918) or custom ranges
Cloud NAT
Provides outbound internet access for instances without external IPs
Uses PAT to multiplex connections over external IPs
Required for accessing non-Google services (e.g., third-party APIs)
Configurable timeouts and IP allocation
Charged per hour + data processing
Private Google Access
Provides access to Google APIs and services only (e.g., Cloud Storage, BigQuery)
Traffic stays on Google's internal network
Does not require any NAT or external IPs
Enabled per subnet
No additional cost for the feature itself (only data transfer)
HA VPN
IPSec VPN tunnels over the internet
Up to 1.5 Gbps per tunnel (with HA VPN)
99.99% SLA with two tunnels
Lower cost, easier to set up
Latency and bandwidth depend on internet connection
Dedicated Interconnect
Direct physical connection to Google Cloud
10 Gbps or 100 Gbps per circuit
99.99% SLA available
Higher cost, requires colocation facility
Consistent low latency and high bandwidth
Mistake
Firewall rules are applied at the subnet level.
Correct
Firewall rules are applied at the instance level based on target tags or service accounts. They are not tied to subnets. A rule allowing traffic to tag 'web' applies to any instance with that tag, regardless of subnet.
Mistake
VPC peering is transitive.
Correct
VPC peering is non-transitive. If VPC A is peered with B, and B with C, A cannot talk to C via B. You must create a direct peering between A and C or use a VPN/Interconnect.
Mistake
Cloud NAT provides inbound access to instances.
Correct
Cloud NAT only provides outbound connectivity. It does not allow inbound connections from the internet. For inbound, you need external IP addresses on instances or a load balancer.
Mistake
Private Google Access allows access to all Google services including the internet.
Correct
Private Google Access only allows access to Google APIs and services (e.g., Cloud Storage, BigQuery) using private IPs. It does not provide general internet access. For non-Google destinations, use Cloud NAT.
Mistake
Auto-mode VPCs cannot be converted to custom-mode.
Correct
You can convert an auto-mode VPC to custom-mode by changing the subnet mode, but the auto-created subnets remain. You cannot delete them, but you can add custom subnets. However, you cannot go from custom to auto-mode.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, you cannot change the primary IP range of a subnet after it is created. You must delete the subnet and recreate it with the desired range. However, you can add secondary IP ranges to existing subnets. Plan your IP addressing carefully before deployment to avoid rework.
You cannot directly reach an instance without an external IP from the internet. To allow inbound traffic, you must either assign an external IP to the instance, use a load balancer (which has an external IP and forwards to the instance via private IP), or use Cloud VPN/Interconnect from on-premises. Firewall rules alone cannot enable inbound internet access without an external IP.
A route determines the path that packets take (next hop), while a firewall rule determines whether packets are allowed or denied. Routes are used for forwarding decisions; firewall rules are used for access control. For example, a route might send traffic to the internet gateway, but a firewall rule must allow that traffic to actually exit.
Yes, but instances with external IPs will use their own external IP for outbound traffic, not Cloud NAT. Cloud NAT only applies to instances without external IPs that are in the configured subnets. If you want all outbound traffic to go through NAT (e.g., for centralized logging), you should not assign external IPs to instances.
The default quota is 10 VPC networks per project (including the default VPC). This can be increased by requesting a quota increase. Each VPC can have up to 10 subnets per region by default. For large deployments, consider using Shared VPC to centralize resources.
Cloud Router is a managed BGP speaker that enables dynamic routing between your VPC and on-premises network over Cloud VPN or Interconnect. It exchanges routes automatically, so you don't need to manage static routes. It is required for HA VPN and Interconnect.
No, VPC Flow Logs are not real-time. They are aggregated and exported every 5 seconds. Additionally, only a sample of flows (default 50%) is captured. For real-time monitoring, consider using Packet Mirroring or third-party agents.
You've just covered GCP VPC and Networking — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?