Virtual Private Cloud in Google Cloud: Your Private Network Inside a Global Platform
A complete, plain-English guide to Google Cloud VPC: how global networks, regional subnets, routes, firewall rules, NAT, peering, Shared VPC and hybrid connectivity fit together, and how to design a secure, scalable network from the ground up.
Imagine you rent a floor in a gigantic office tower owned by someone else. The building has its own roads, power and security staff, but your floor is yours alone: you decide which rooms exist, which doors are locked, who may enter, and which corridors lead to the outside world. Nobody from another company can wander into your rooms unless you let them. A Virtual Private Cloud, or VPC, is exactly that private floor, but for your computers in Google Cloud. It is a software-defined network that gives your virtual machines, containers and managed services a safe, organized place to talk to each other, to your office, and to the internet. In this guide we will start from the very first idea and build up to the design choices that large companies use in production.
1What Is a VPC?
Before touching any settings, let us get a clear picture of what a VPC is and why every Google Cloud project depends on one.
A network made of software
A network normally means cables, switches and routers in a room. In the cloud you cannot walk up to those devices, so the provider builds the same ideas in software. A VPC is a virtual version of a physical network that runs inside Google’s own global network. It gives your resources private IP addresses, rules about who can talk to whom, and paths to other networks. You never touch any hardware, yet you get the behavior of a well-run data center network.
Think of a gated neighborhood inside a large city. The city roads are Google’s global backbone. Your neighborhood has its own streets (subnets), its own gate with a guard (firewall rules), and street signs that tell cars which way to go (routes). People inside can visit each other freely if the guard allows it, and outsiders need permission to enter.
Why it matters
Almost every Google Cloud service that runs on virtual machines, from Compute Engine to Google Kubernetes Engine, attaches to a VPC network. Even many managed services reach your resources through one. A good network design keeps data private, limits the damage of mistakes, makes troubleshooting easier, and avoids expensive redesigns later. A poor design is one of the hardest things to change once many teams depend on it.
The word “VPC” is used in two slightly different ways. It can mean the network resource you create in your project, or the general idea of a private virtual network. In Google Cloud documentation, “VPC network” means the actual resource, and that is how we use it here.
2Why Google’s VPC Is Different
If you have used other clouds, one Google Cloud idea will surprise you: the network is global.
One network, many regions
In many cloud platforms, a virtual network lives inside a single region, and connecting regions means building extra links between separate networks. In Google Cloud, a single VPC network is a global resource. You can place subnets in Tokyo, Frankfurt and Iowa inside the same VPC, and machines in those subnets can reach each other over private IP addresses without any extra gateways. Traffic between regions travels over Google’s own private backbone, not the public internet.
| Concept | Scope in Google Cloud | What It Means |
|---|---|---|
| VPC network | Global | One network can span all regions |
| Subnet | Regional | Each subnet lives in one region and covers all zones in it |
| Firewall rules | Global (per network) | Rules apply across regions in that network |
| Routes | Global (per network) | Routing decisions are shared across the network |
| VM instance | Zonal | Each VM runs in one zone inside a region |
Picture one company with offices in many cities, all sharing one private phone system. An employee in London can call a colleague in Sydney using a short internal extension, and the call never touches the public phone network. Other clouds often give each city its own separate phone system that you must wire together by hand.
Practical benefits of a global design
Simpler Multi-Region
Deploy the same application in several regions without building and managing links between separate networks.
Consistent Policy
Firewall rules and routes are defined once for the whole network, reducing drift between regions.
Private Backbone
Cross-region private traffic rides Google’s own fiber network, which tends to be fast and predictable.
Easier Failover
Moving a workload to another region means launching it in another subnet of the same network, not building a new one.
A global network does not mean everything is automatically open. Resources still need firewall rules that allow traffic, and cross-region traffic can incur network charges. Global reachability and global permission are two different things.
3Core Building Blocks
A VPC is made of a handful of simple pieces. Learn these and the rest of the topic becomes much easier.
VPC Network
The top-level container that holds subnets, routes and firewall rules for a set of resources.
Subnet
A regional slice of the network with its own range of IP addresses where resources are placed.
IP Address
The numeric address of a resource. Internal addresses are private; external addresses are reachable from the internet.
Route
A rule telling the network where to send traffic bound for a particular destination range.
Firewall Rule
A rule that allows or denies traffic to or from resources based on direction, protocol, port and source or target.
Network Interface
The connection point that attaches a virtual machine to a subnet. A VM can have more than one.
How the pieces fit together
You create a network, add subnets in the regions you need, and launch resources into those subnets. Routes decide where packets go, and firewall rules decide whether they are allowed to go there. Everything else in this guide, from NAT to peering, is an extension of these basics.
flowchart TD
P[Google Cloud Project] --> V[VPC Network - Global]
V --> S1[Subnet in Region A]
V --> S2[Subnet in Region B]
V --> R[Routes]
V --> F[Firewall Rules]
S1 --> VM1[VM Instances]
S2 --> VM2[VM Instances]
If the VPC is a company campus, subnets are the individual buildings, IP addresses are the room numbers, routes are the signposts between buildings, and firewall rules are the security guards at each door.
4IP Addresses and CIDR Made Simple
Every network decision starts with addresses. Here is the minimum you need to know, explained without jargon.
What is an IP address?
An IP address is a number that identifies a device on a network, like a house number on a street. A common form, IPv4, looks like four numbers separated by dots. Each machine needs its own address so that data knows where to go.
What is CIDR notation?
CIDR is a short way to describe a block of addresses. It looks like an address followed by a slash and a number, for example a range starting at 10.0.0.0 with a slash and 24. The number after the slash says how many bits of the address are fixed, which in turn tells you the size of the block. A smaller number after the slash means a bigger block. A slash 24 gives about 256 addresses, a slash 16 gives about 65,000, and a slash 8 gives about 16 million.
Think of postal codes. A short code covers a whole city, while a longer code narrows down to a single street. CIDR does the same with addresses: a short prefix covers a huge block, and a long prefix covers a small one.
Private ranges you will use
Internal addresses in a VPC come from the standard private ranges defined for internal networks: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Google Cloud also allows some additional private-use ranges in certain cases. Because these ranges are reused by countless organizations, two networks you want to connect must never overlap, or traffic will not know where to go.
Reserved addresses in each subnet
In the primary range of every subnet, Google Cloud reserves a few addresses for its own use: the network address, the default gateway, the second-to-last address reserved for future use, and the broadcast address. That means a small subnet loses four addresses to overhead, which matters when you plan sizes for tiny ranges.
| Prefix | Approximate Addresses | Typical Use |
|---|---|---|
| /28 | 16 | Very small, special-purpose ranges |
| /24 | 256 | A small application tier |
| /20 | 4,096 | A medium environment |
| /16 | 65,536 | A large environment or whole region |
| /8 | 16 million | An entire organization’s address plan |
Choosing address ranges casually, such as always picking the same default range for every project, leads to overlaps later when you try to connect networks together or link to your office. Plan one organization-wide address scheme before creating many networks.
Internal, external and ephemeral addresses
Internal IP
Private address inside the VPC, used for communication between your own resources. Usually assigned automatically from the subnet range.
External IP
Public address that lets a resource be reached from, and reach, the internet directly.
Ephemeral IP
Temporary address that is released when the resource stops or is deleted.
Static IP
Reserved address that stays the same until you release it, useful for allow-lists and DNS records.
IPv6 support
Google Cloud supports IPv6 in subnets that are configured as dual-stack, meaning they carry both IPv4 and IPv6, and in some cases IPv6-only. Adopting IPv6 helps with address exhaustion and with serving users on networks that prefer it, but many teams still start with IPv4 and add IPv6 where there is a clear need.
5Subnets and Network Modes
Subnets are where your resources actually live, and how you create them depends on the network mode you choose.
What a subnet does
A subnet is a regional range of internal IP addresses. All zones in that region can use the same subnet, so a machine in one zone and a machine in another zone of the same region can sit in the same subnet. When you create a VM you choose a subnet, and the VM receives an internal address from that subnet’s range.
Auto mode versus custom mode
Google Cloud offers two modes for creating a VPC network, and the choice shapes everything that follows.
Auto Mode
- Creates one subnet in every region automatically
- Uses a predefined block of addresses, so setup is instant
- Great for quick experiments and learning
- New regions get subnets added automatically
Custom Mode
- You create only the subnets you need, with ranges you choose
- Full control over address planning
- The right choice for production and any network that will connect to others
- Requires a little more planning up front
Auto mode networks use the same predefined ranges every time, so two auto mode networks will overlap with each other. That makes them unsuitable for peering or for connecting to an on-premises network. Production environments should use custom mode. An auto mode network can be converted to custom mode, but the change cannot be reversed.
The default network
New projects have often come with a pre-created network named default, an auto mode network with a few permissive firewall rules already in place. It is handy for a first experiment, but its broad rules and predictable ranges are not ideal for serious workloads. Many organizations use an organization policy to stop the default network from being created and build their own custom networks instead.
Subnet behavior worth knowing
Expandable, Not Shrinkable
You can enlarge a subnet’s primary range by lowering its prefix length, but you cannot make it smaller without recreating it.
Secondary Ranges
A subnet can carry extra named ranges, commonly used by Kubernetes for pod and service addresses.
Alias IP Ranges
A VM can be given a whole range of additional internal addresses, useful for running many containers on one machine.
Special-Purpose Subnets
Some features, such as managed proxy load balancers and Private Service Connect, require dedicated subnets with a specific purpose.
Flow Logs per Subnet
Traffic logging is switched on at the subnet level, so you can log only the subnets you care about.
Leave generous room when you size subnets. Running out of addresses inside a subnet forces painful workarounds, while unused space inside a private range costs nothing.
6Routes: How Traffic Finds Its Way
Routes are the street signs of your network. They decide the next stop for every packet that leaves a machine.
What a route contains
Each route has a destination range, written in CIDR form, and a next hop, which is the place to send traffic that matches the range. When a VM sends a packet, the network compares the packet’s destination to the available routes and picks the best match. The most specific match wins, so a route for a small range beats a route for a huge one.
Imagine a delivery driver with a list of rules: “Packages for this street go to the local depot; everything else goes to the main sorting hub.” The driver picks the most specific rule that fits the address on the package. Routes work the same way.
Types of routes
Subnet Routes
Created automatically for every subnet range so resources inside the network can reach each other. You do not manage these directly.
Default Route
A catch-all route that sends traffic bound for the internet to the default internet gateway. It exists in new networks and can be deleted if you want no direct internet path.
Static Routes
Routes you create by hand for a specific destination, pointing to a gateway, an instance or a tunnel.
Dynamic Routes
Routes learned automatically from on-premises networks through Cloud Router and the BGP protocol, updating as the other side changes.
Peering Routes
Routes exchanged with a peered network so that two VPCs can reach each other’s subnets.
How a route is chosen
Find Matching Routes
The network lists all routes whose destination range contains the packet’s destination address.
Prefer the Most Specific
Among matches, the route with the longest prefix, meaning the narrowest range, wins.
Break Ties with Priority
If several routes tie on specificity, the one with the lowest priority number is used.
Forward to the Next Hop
The packet is sent to the chosen next hop, such as a subnet, a gateway or a VPN tunnel.
Network tags and routes
Static routes can be limited to only some machines by using network tags. A tag is a simple label attached to a VM. A route that names a tag applies only to machines carrying that tag, which is a handy way to send traffic from one group of machines through a special appliance while others use the normal path.
Deleting the default internet route while expecting machines to still reach the internet is a classic surprise. Without a route, there is no path, even if firewall rules and external addresses are in place. Routes and firewall rules must both agree before traffic flows.
7Firewall Rules and Policies
Routes say where traffic can go. Firewall rules say whether it is allowed to. Together they form the heart of VPC security.
How VPC firewall rules work
VPC firewall rules are enforced at the level of each virtual machine’s network interface, not at a central choke point. That means a rule protects a VM even when the traffic comes from another VM in the same subnet. Rules are stateful: if you allow a connection in one direction, the replies are automatically allowed back, so you do not need a separate rule for return traffic.
The anatomy of a rule
Direction
Ingress for traffic coming in to a resource, or egress for traffic going out.
Action
Allow or deny the matching traffic.
Priority
A number from 0 to 65535. Lower numbers are evaluated first. The default is 1000.
Match
Protocol and ports, plus a source (for ingress) or destination (for egress) range.
Target
Which resources the rule applies to: all in the network, those with a given tag, or those running as a given service account.
Implied rules
Every VPC network comes with two built-in rules you cannot delete. One allows all outgoing traffic, and one denies all incoming traffic. Both have the lowest possible priority, so any rule you write overrides them. In practice this means a new network is closed to inbound traffic until you open specific doors, while outbound traffic is open until you restrict it.
Think of a building where anyone inside may freely walk out, but nobody from the street may walk in unless the guard has their name on a list. Each rule you write adds a name to the list, or removes a privilege from someone inside.
Targeting with tags and service accounts
You can aim a rule at machines using network tags or the service account a machine runs as. Tags are quick and flexible, but anyone who can edit a machine can change its tags. Service accounts are stronger because changing the identity of a machine requires higher permission. For sensitive tiers, prefer service accounts. Newer secure tags, managed through IAM, offer an even more controlled way to group resources.
| Targeting Method | Strength | Weakness |
|---|---|---|
| Network tags | Simple and quick | Anyone who can edit a VM can change them |
| Service accounts | Tied to identity and IAM permissions | Each VM has one service account, limiting flexibility |
| Secure tags | Governed by IAM, usable in modern policies | Newer feature that needs policy planning |
| All instances | Easy to apply broadly | Easy to over-expose |
Firewall policies
Beyond individual rules, Google Cloud offers firewall policies, which group many rules and can be attached at several levels. A hierarchical policy attaches to an organization or folder, letting a central security team enforce rules that every project below must follow, such as blocking a risky protocol everywhere. A network firewall policy attaches to a single VPC and supports richer matching, including fully qualified domain names and geographic regions in some cases. Policies are evaluated in a defined order: organization first, then folder, then the network.
flowchart TD
A[Incoming Packet] --> B[Organization Policy Rules]
B --> C[Folder Policy Rules]
C --> D[VPC Firewall Policy and Rules]
D --> E{Allowed?}
E -->|Yes| F[Packet Delivered to VM]
E -->|No| G[Packet Dropped]
Problem
Creating broad allow rules that open all ports to the whole internet, just to make something work quickly.
Why It’s Harmful
Exposed management ports and databases are quickly found and attacked by automated scanners, and the temporary rule is often forgotten.
Correct Approach
Allow only the specific ports and source ranges needed, use identity-aware ways to reach machines instead of open remote access ports, and review rules regularly.
Turn on firewall rules logging for rules you care about. It records which rule allowed or denied a connection, which makes it far easier to answer the question “why can’t these two machines talk?”
8Reaching the Internet: External IPs, Cloud NAT and Private Google Access
Private machines still need to download updates and call outside services. There are safe ways to allow that without exposing them.
Direct external IP addresses
The simplest way for a VM to reach the internet is to give it an external IP address. This also makes the VM reachable from the internet, subject to firewall rules. It is fine for a public web server, but most back-end machines should not have one, because every public address is a possible target.
Cloud NAT
Cloud NAT lets machines without external addresses make outbound connections to the internet. NAT stands for network address translation: the service swaps the machine’s private address for a shared public address on the way out, and swaps it back for replies. Importantly, it allows only connections that the machine itself starts. The internet cannot start a connection to a machine behind NAT.
Cloud NAT is like a company receptionist who places calls on behalf of employees using the company’s main phone number. Outsiders see only the main number and can answer calls the employee started, but they cannot dial directly into an individual’s desk.
sequenceDiagram
participant VM as Private VM
participant NAT as Cloud NAT
participant NET as Internet Server
VM->>NAT: Request using private address
NAT->>NET: Request using shared public address
NET-->>NAT: Reply
NAT-->>VM: Reply forwarded to private VM
Cloud NAT is a regional, managed service tied to a Cloud Router. It is software-defined, so it is not a single machine that can become a bottleneck or point of failure. You configure which subnets it serves and how many public addresses it uses, and you should watch the number of connections to avoid exhausting available ports under heavy load.
Private Google Access
Many Google Cloud services, such as Cloud Storage and BigQuery, are reached through Google’s public API addresses. Private Google Access lets a VM that has no external address reach those Google services using its internal address only. It is switched on per subnet and lets locked-down machines still use Google’s managed services without any path to the wider internet.
| Need | Best Option | Notes |
|---|---|---|
| Public web server reachable by everyone | External IP behind a load balancer | Expose only the load balancer where possible |
| Private VM downloads updates from the internet | Cloud NAT | Outbound only |
| Private VM calls Google APIs | Private Google Access | No internet path required |
| Private access to a partner or Google-published service | Private Service Connect | Uses an internal endpoint |
Putting external IP addresses on every VM “to make things work” removes the main advantage of a private network. Start with no external addresses and add Cloud NAT or Private Google Access as needed.
9Connecting Networks: VPC Peering
Sooner or later, two networks need to talk to each other. Peering is the simplest way to connect VPCs in Google Cloud.
What peering does
VPC Network Peering connects two VPC networks so that machines in each can reach machines in the other using internal addresses. Traffic stays on Google’s private network and does not cross the public internet. The two networks can belong to different projects or even different organizations. Both sides must create their half of the peering for it to become active.
graph LR
A[VPC Network A] |Peering| B[VPC Network B]
B |Peering| C[VPC Network C]
A -. No automatic path .- C
Key rules of peering
No Overlapping Ranges
Peered networks cannot have subnets with overlapping address ranges.
Not Transitive
If A peers with B and B peers with C, A still cannot reach C. A direct peering between A and C is needed.
Separate Control
Each network keeps its own firewall rules, routes and administrators. Peering does not merge them.
Firewall Still Applies
Peering only creates the path. Firewall rules on each side must still allow the traffic you want.
Quotas Apply
There are limits on peerings per network and on combined resources across a peered group, so large designs need planning.
Peering is like building a private bridge between two neighboring companies. Employees can cross to visit each other, but each company keeps its own security and its own rules. If a third company has a bridge to your neighbor, that does not mean you can walk through your neighbor to reach them.
Advantages
- Low latency over Google’s private network
- No gateways or tunnels to manage
- No extra charge for the peering itself, though normal network traffic charges apply
- Works across projects and organizations
Disadvantages / Trade-offs
- Not transitive, so full meshes need many peerings
- Overlapping address ranges are not allowed
- Limits on the number of peerings and shared resources
- Policy is managed separately in each network
10Shared VPC: One Network, Many Projects
Large organizations rarely run everything in one project. Shared VPC lets many projects use one centrally managed network.
The host and service project idea
With Shared VPC, one project is designated the host project, and it owns the network, subnets, routes and firewall rules. Other projects, called service projects, are attached to it. Teams in service projects can create resources such as virtual machines inside the shared subnets, but they do not control the network itself. A central network team manages the network, and application teams manage their own workloads.
flowchart TD
H[Host Project: Shared VPC Network] --> S1[Subnet 1]
H --> S2[Subnet 2]
SP1[Service Project: Team A] --> S1
SP2[Service Project: Team B] --> S1
SP3[Service Project: Team C] --> S2
Think of a shared office building with a building manager. The manager looks after the lobby, elevators and security. Each company rents its own offices and runs its own business, but everyone uses the same well-managed infrastructure and follows the same building rules.
Why organizations choose Shared VPC
Central Control
One team defines address plans, firewall policy and routing for everyone, ensuring consistency.
Delegated Freedom
Application teams keep their own projects, billing and permissions without owning network infrastructure.
Easy Internal Communication
Resources in different service projects talk over internal addresses with no peering needed.
Fewer Connections
One set of hybrid links, such as VPN or Interconnect, serves every attached project.
Shared VPC versus peering
| Aspect | Shared VPC | VPC Peering |
|---|---|---|
| Network ownership | One central network, many projects | Separate networks, each with its own owner |
| Policy control | Centralized | Independent per network |
| Best for | Teams within one organization | Connecting separate organizations or independent networks |
| Address planning | One plan | Must avoid overlap between networks |
| Transitivity | Everything is in one network | Not transitive |
Shared VPC requires the projects to belong to the same organization. It is a common building block of enterprise landing zones, often combined with separate host projects for production and non-production environments.
11Hybrid Connectivity: VPN, Interconnect and Cloud Router
Most companies still have offices and data centers. Hybrid connectivity joins them to your VPC.
Cloud VPN
Cloud VPN creates an encrypted tunnel over the public internet between your VPC and another network. The high availability version, HA VPN, offers a strong uptime commitment when configured with redundant tunnels, and it is the recommended choice. VPN is quick to set up and relatively inexpensive, but its bandwidth and reliability depend on the internet path between the two ends.
Cloud Interconnect
Cloud Interconnect provides a dedicated, private connection between your network and Google, bypassing the public internet. It comes in two main forms. Dedicated Interconnect gives you a direct physical link to Google at a colocation facility. Partner Interconnect reaches Google through a supported service provider when you cannot connect directly. Both offer higher bandwidth and more consistent performance than VPN, at higher cost and with longer setup times. A related option, Cross-Cloud Interconnect, connects Google Cloud directly to other cloud providers.
| Option | Path | Setup Speed | Typical Use |
|---|---|---|---|
| HA VPN | Encrypted tunnel over the internet | Fast | Smaller workloads, backup links, quick starts |
| Partner Interconnect | Private link through a service provider | Medium | Moderate to high bandwidth without a direct presence |
| Dedicated Interconnect | Direct physical link to Google | Slower | High bandwidth, steady performance, large data movement |
| Cross-Cloud Interconnect | Direct link to another cloud | Slower | Multicloud architectures |
Cloud Router and BGP
Cloud Router is a managed service that exchanges routes between your VPC and your outside network using BGP, the standard protocol networks use to tell each other which addresses they can reach. When you add a new subnet in your VPC, Cloud Router can advertise it automatically to your office, and when your office adds a network, the VPC learns about it without anyone editing routes by hand. This dynamic behavior makes hybrid networks much easier to run and recover.
VPN is like sending a locked briefcase through the regular postal service. Interconnect is like having your own private road straight to the destination. Cloud Router is the dispatcher on both ends who keeps the map of roads up to date as buildings are added or removed.
flowchart LR
OP[On-Premises Network] |HA VPN or Interconnect| CR[Cloud Router]
CR V[VPC Network]
V --> S1[Subnet A]
V --> S2[Subnet B]
Building a single tunnel or single link for something critical creates a single point of failure. Use redundant tunnels or links, ideally on separate paths, and test failover before you depend on it.
Network Connectivity Center
When you have many sites, VPCs and clouds, managing individual links becomes a maze. Network Connectivity Center acts as a central hub: you attach your various networks as spokes, and the hub helps them exchange routes, making it easier to build a coherent, manageable topology at scale.
12Private Access to Services: Private Service Connect and Private Services Access
Many services live outside your VPC, in Google’s or a partner’s network. These features let you reach them privately.
Private Service Connect
Private Service Connect lets you reach a service through an internal endpoint, which is simply a private IP address inside your own subnet. Traffic to that address is carried privately to the service, whether it is a Google API, a service published by another team, or a third-party offering. Because the consumer sees only a local address, there is no need to peer networks or worry about overlapping ranges.
Google APIs
Create an internal endpoint to reach Google APIs with an address of your own choosing, useful for strict, private-only designs.
Published Services
A producer publishes a service behind a load balancer, and consumers connect to it through their own endpoint.
Managed Services
Several managed Google Cloud services use this approach to give you private, address-conflict-free access.
Private services access
Private services access is an older but still widely used method. You reserve a block of internal addresses and create a private connection to a Google-managed network, which hosts services like some managed databases. The connection is built on VPC peering behind the scenes. You need to reserve a range that does not overlap with your own, and the service gets internal addresses from it.
Private Service Connect is like installing a dedicated phone extension in your office that rings straight into a partner’s service desk. You dial a local number, and nobody needs to know the partner’s internal phone system or worry whether it clashes with yours.
Reaching serverless products
Serverless products such as Cloud Run and Cloud Functions run outside your VPC by default. To let them reach private resources like a database on an internal address, you connect them through a serverless VPC connector or the newer direct VPC egress option, which places their outbound traffic into your network. The reverse direction, letting private clients call a serverless service, is handled through internal load balancing or Private Service Connect.
Prefer Private Service Connect for new designs where it is available, as it avoids address-range coordination. Keep private services access in mind for existing services that still depend on it.
13Load Balancing and DNS in the Network
Two services sit next to the VPC in almost every design: load balancers to spread traffic, and DNS to give things names.
Load balancing options
Google Cloud offers a family of load balancers. External ones receive traffic from the internet, and internal ones serve traffic only from inside your network or connected networks. Some operate at the application level and understand web requests, while others work at the connection level. Choosing between them depends on whether traffic is public or private, whether it is web traffic, and whether it is regional or global.
| Load Balancer Style | Audience | Typical Use |
|---|---|---|
| Global external application load balancer | Internet users worldwide | Public websites and APIs with a single global address |
| Regional external application load balancer | Internet users, one region | Public apps with regional data requirements |
| Internal application load balancer | Clients inside the VPC or connected networks | Private microservices |
| External network load balancer | Internet, connection-level | Non-web protocols and very high performance |
| Internal network load balancer | Inside the VPC | Private connection-level traffic such as databases |
Expose load balancers rather than individual machines. Backends can sit in private subnets with no external addresses while the load balancer handles the public face, health checks and traffic spreading.
Cloud DNS and internal names
Machines in a VPC automatically get internal DNS names, so they can find each other by name instead of by address. For more control, Cloud DNS lets you create private zones that resolve only inside chosen networks, and forwarding zones that send certain name lookups to your on-premises DNS servers. This is essential for hybrid designs where cloud machines must find office servers by name and the reverse.
DNS is the company phone directory. Instead of memorizing everyone’s extension, you look up a name. A private zone is an internal directory that outsiders cannot read, and a forwarding zone is a rule saying “for names in the other office, ask their receptionist.”
14Internal Working: How a Packet Travels
Let us follow a packet from one VM to another to see how routes, firewalls and the underlying fabric cooperate.
The software-defined fabric
Behind the scenes, Google’s network is not a set of boxes you could point to. It is a distributed, software-defined system. Each physical host runs networking software that applies your routes and firewall rules locally to the virtual machines on that host. Because enforcement happens at the edge, close to each VM, there is no central firewall appliance that all traffic must squeeze through, which removes a common bottleneck.
VM Sends a Packet
An application on a VM sends data to another VM’s internal address.
Egress Check
The host applies egress firewall rules for the sending VM. If an egress rule denies the traffic, it stops here.
Route Lookup
The network finds the best route for the destination, usually the automatic subnet route for internal traffic.
Transport Across the Fabric
The packet travels across Google’s data center network, or across the global backbone if the destination is in another region.
Ingress Check
The receiving host applies ingress firewall rules for the destination VM. Without a matching allow rule, the packet is dropped.
Delivery and Return Traffic
The packet is delivered. Because rules are stateful, the reply travels back automatically.
sequenceDiagram
participant A as VM A
participant H1 as Host Networking A
participant F as Google Fabric
participant H2 as Host Networking B
participant B as VM B
A->>H1: Send packet
H1->>H1: Check egress rules and route
H1->>F: Forward packet
F->>H2: Deliver to destination host
H2->>H2: Check ingress rules
H2->>B: Deliver packet
B-->>A: Reply allowed by connection tracking
Packet size and MTU
The maximum transmission unit, or MTU, is the largest packet a network will carry in one piece. Google Cloud VPC networks default to a standard size slightly smaller than the typical 1500 bytes used elsewhere, and you can configure a larger size for networks that benefit from it. When connecting to other networks, mismatched sizes can cause mysterious slowdowns or failures with large transfers, so it is worth checking the MTU on both sides of any hybrid link.
If small requests work but large downloads hang over a VPN or Interconnect link, suspect an MTU mismatch before blaming the application.
15Security Beyond Firewalls
Firewalls are the first layer. Good network security uses several overlapping layers so one mistake does not become a breach.
IAM and Network Roles
Control who can create networks, change firewall rules and attach projects. Separate network administration from application administration.
Organization Policies
Guardrails that apply across many projects, such as forbidding external IP addresses on VMs or blocking creation of default networks.
VPC Service Controls
Builds a security perimeter around supported Google services, reducing the risk of data being copied out of approved boundaries even by someone with valid credentials.
Identity-Aware Access
Reach machines through identity-checked tunnels rather than exposing remote administration ports to the internet.
Cloud Armor
Protection against web attacks and floods for applications behind external load balancers.
Advanced Firewall Services
Cloud Next Generation Firewall features offer deeper inspection and threat detection when you need more than simple port and address rules.
Segmentation
Segmentation means dividing a network into zones so that a problem in one cannot easily spread to others. In a VPC you can segment by subnet, by tags or service accounts, by separate networks, or by separate projects. A common pattern separates web, application and data tiers, allowing the web tier to talk to the application tier, and only the application tier to talk to the data tier. Production and development are kept in different networks or at least different policy sets.
A ship has watertight compartments. If one fills with water, the others stay dry and the ship floats. Segmentation does the same for your network: a compromised machine in one compartment cannot freely reach everything else.
Problem
A flat network where every machine can reach every other machine on every port, relying on the internet-facing firewall alone.
Why It’s Harmful
One compromised machine gives an attacker a free path to everything, including databases and internal tools.
Correct Approach
Apply least privilege between tiers, deny by default, allow only required flows, and separate environments.
16Monitoring, Logging and Troubleshooting
When something cannot connect, you need clear evidence. Google Cloud provides several tools for seeing what your network is doing.
| Tool | What It Shows | Best Used For |
|---|---|---|
| VPC Flow Logs | Samples of network flows between machines, with addresses, ports and volumes | Traffic analysis, security investigations, cost understanding |
| Firewall Rules Logging | Which rule allowed or denied each connection | Explaining blocked or unexpected traffic |
| Connectivity Tests | A simulated path between two endpoints, showing where it succeeds or fails | Diagnosing “why can’t A reach B” |
| Network Topology | A visual map of your network and traffic between parts | Understanding and documenting architecture |
| Firewall Insights | Rule usage, shadowed rules and overly permissive rules | Cleaning up and tightening policy |
| Cloud Monitoring metrics | Throughput, packet counts, VPN and Interconnect health | Alerts and dashboards |
| Packet Mirroring | Copies of actual packets sent to an inspection tool | Deep inspection, intrusion detection |
A simple troubleshooting routine
Confirm the Basics
Are both resources running, in the expected subnets, with the addresses you think they have?
Check the Route
Is there a route that matches the destination, and does it lead where you expect?
Check Firewall Rules
Is there an allow rule for the direction, port and source or destination, and is a higher priority deny rule overriding it?
Run a Connectivity Test
Let the tool trace the path and point to the exact step that fails.
Look Beyond the Network
If the network path is fine, check the application, its listening port, host-level firewalls and DNS.
Enabling flow logs on every subnet at full sampling can generate large log volumes and costs. Turn them on where you need them and tune the sampling rate and metadata fields to balance visibility and cost.
17Network Design Patterns
Experienced teams reuse a small set of proven layouts. Here are the most common ones and when each fits.
Single VPC for a Small Application
One custom mode network with a few subnets for web, application and data tiers. Cloud NAT provides outbound access for private machines, and a load balancer fronts the public face. Simple, easy to reason about, and a good starting point for a single team.
Environment Separation
Separate networks, often in separate projects, for development, testing and production. This limits the blast radius of mistakes, allows different policies per environment, and prevents test traffic from touching production data.
Hub and Spoke
A central hub network holds shared services such as security appliances, DNS and hybrid connections, while spoke networks hold workloads and connect to the hub. Network Connectivity Center or carefully designed peering supports this layout, and it keeps hybrid links and inspection in one place.
Shared VPC Landing Zone
A host project per environment owns the networks, while many service projects hold team workloads. Organization policies and hierarchical firewall policies enforce guardrails. This is the most common pattern for mid-sized and large organizations.
Hybrid Extension of the Data Center
The VPC is connected to the on-premises network through redundant HA VPN or Interconnect and Cloud Router, with non-overlapping address plans and DNS forwarding so that names resolve in both directions.
Multi-Region Active-Active
The same application runs in subnets across several regions of one global network, fronted by a global load balancer. Users are routed to the nearest healthy region, and failover is largely automatic.
18Advantages, Disadvantages and Trade-offs
Every design choice has a cost. Here is an honest look at what Google Cloud’s VPC model gives and what to watch for.
Advantages
- Global network simplifies multi-region designs
- Software-defined, so no hardware to buy or maintain
- Distributed firewall enforcement avoids central bottlenecks
- Rich connectivity options: peering, Shared VPC, VPN, Interconnect and Private Service Connect
- Strong centralized governance through policies and organization controls
- Deep visibility with flow logs and connectivity tests
Disadvantages / Trade-offs
- Address planning mistakes are hard to fix later
- Peering is not transitive and has quotas
- Auto mode and default networks are unsuitable for production
- Network egress and cross-region traffic can add noticeable cost
- Firewall rule sprawl can become hard to audit without discipline
- Some services need special subnets or connectors, adding design complexity
Most of the disadvantages are about planning, not about the technology. Teams that invest early in address plans, naming standards and policy as code seldom suffer from them.
19Cost Considerations
Creating a VPC itself is free, but the services and traffic around it are not. Knowing where costs come from helps you avoid surprises.
Network Egress
Data leaving Google Cloud to the internet is charged. Traffic between regions and between some zones can also be charged, while traffic inside the same zone over internal addresses is generally free.
Cloud NAT
Charged for gateway usage and for data processed. Heavy outbound traffic makes this noticeable.
VPN and Interconnect
Tunnel or port charges apply, plus traffic charges. Interconnect often lowers egress rates for large volumes.
Load Balancers
Charged for forwarding rules and for data processed.
External IP Addresses
Public addresses can carry hourly charges, especially reserved ones that are not in use.
Logging and Mirroring
Flow logs, firewall logs and packet mirroring create data volume that is billed through logging and processing charges.
Keep Chatty Services Together
Place components that exchange lots of data in the same region, and where possible the same zone, to avoid transfer charges.
Use Private Paths for Google Services
Private Google Access keeps traffic to Google APIs on Google’s network.
Release Unused Addresses
Delete reserved external addresses and idle load balancers you no longer need.
Tune Logging
Sample flow logs sensibly and export only what you need to analyze.
Pricing changes over time and varies by region and service. Always confirm current rates on the official Google Cloud pricing pages before estimating a budget.
20Real-World Examples
Seeing how organizations use VPC features makes the concepts easier to remember.
An Online Retailer During a Sale
A retailer runs web servers in several regions behind a global load balancer. Back-end services and databases sit in private subnets with no external addresses. Cloud NAT lets them fetch updates, and Private Google Access lets them use storage and analytics services. When a sale drives a spike, extra machines launch into existing subnets without any network changes.
A Bank Meeting Strict Compliance Rules
A bank uses a Shared VPC landing zone where a central team owns the network. Hierarchical firewall policies block risky protocols everywhere, VPC Service Controls wrap sensitive data services, and Dedicated Interconnect links the data center. Every flow is logged and reviewed, and there are no external IP addresses on workloads.
A Software Company with Many Teams
A growing company gives each team its own service project attached to a Shared VPC host project. Teams move fast and manage their own resources, while the platform team keeps address plans, DNS and security rules consistent for everybody.
A Manufacturer Connecting Factories
Factories in several countries connect to Google Cloud through redundant HA VPN tunnels and Cloud Router. Sensor data flows into the cloud for analysis, and dynamic routing means new factory networks are learned automatically as they are added.
A Startup Serving a Partner
A startup offers an internal data service to a large customer. Instead of peering networks and worrying about address clashes, it publishes the service through Private Service Connect, and the customer reaches it using a single private endpoint in their own network.
21Best Practices and Common Mistakes
A short checklist to carry into every network design.
Best Practices
- Create an organization-wide IP address plan before building networks
- Use custom mode networks for production
- Avoid external IP addresses by default; use Cloud NAT and Private Google Access
- Follow least privilege and deny by default in firewall rules
- Target firewall rules with service accounts or secure tags for sensitive tiers
- Use Shared VPC to centralize control in larger organizations
- Build redundant hybrid connections and test failover
- Enable logging and connectivity tests where they add value
- Use organization policies to enforce guardrails
- Document networks and manage them as code for repeatability
Common Mistakes
- Leaving the default network in place for real workloads
- Overlapping address ranges that block later connections
- Assuming peering is transitive
- Opening management ports to the whole internet
- Single tunnels or links for critical connectivity
- Forgetting that routes and firewall rules must both allow traffic
- Choosing subnet ranges too small to grow
- Ignoring egress costs in architecture decisions
A quick decision guide
flowchart TD
Q1{Connecting to another network?} -->|No| A1[Single custom mode VPC]
Q1 -->|Yes| Q2{Same organization and managed centrally?}
Q2 -->|Yes| A2[Shared VPC]
Q2 -->|No| Q3{Need to reach a specific service only?}
Q3 -->|Yes| A3[Private Service Connect]
Q3 -->|No| Q4{On-premises or other cloud?}
Q4 -->|Yes| A4[HA VPN or Interconnect with Cloud Router]
Q4 -->|No| A5[VPC Peering]
22Frequently Asked Questions
The VPC network itself is a global resource, while its subnets are regional. Machines in different regions of the same VPC can reach each other over internal addresses.
No, the network resource itself is free. You pay for the resources and traffic that use it, such as network egress, NAT, VPN, Interconnect and load balancers.
Auto mode creates one predefined subnet in every region for you, which is convenient but can cause overlaps. Custom mode lets you create only the subnets you need with ranges you choose, which is the right option for production.
No, they apply to the network and target resources through tags, service accounts or the whole network, and they are enforced at each VM’s network interface. They are not attached to subnets.
Not necessarily. The default implied rule blocks incoming traffic, so you need an allow rule for the traffic you want, even within a subnet. The default network includes permissive internal rules, but custom networks do not.
No. If network A peers with B and B peers with C, A cannot reach C through B. You would need a direct peering between A and C, or a hub design.
Use Cloud NAT for outbound internet access without external addresses, and Private Google Access for Google services. The internet cannot start connections to machines behind NAT.
Choose Shared VPC when many projects in one organization should use one centrally managed network. Choose peering to connect independent networks, especially across organizations.
Use HA VPN for fast, moderate-bandwidth connections or as a backup. Use Interconnect when you need high bandwidth, steady performance and a private path, and accept the longer setup and higher cost.
You can expand a subnet’s primary range, but you cannot shrink it, and you must avoid overlapping other ranges. Generous planning up front avoids painful changes.
Check routes and firewall rules, enable firewall rules logging, and run a Connectivity Test, which traces the path and shows the step where it breaks.
Yes. Services such as Cloud Run and Cloud Functions can send traffic into a VPC through a serverless connector or direct VPC egress, so they can reach private resources.
23Summary and Key Takeaways
A Google Cloud VPC is a global, software-defined private network that gives your resources addresses, paths and protection. Regional subnets hold your machines, routes decide where traffic goes, and distributed firewall rules decide whether it is allowed. Around this core sit powerful options: Cloud NAT and Private Google Access for safe outbound access, peering and Shared VPC for connecting networks and teams, VPN and Interconnect with Cloud Router for hybrid links, and Private Service Connect for private access to services. Success comes less from clever features than from careful early decisions about address ranges, boundaries and least-privilege policy, backed by good visibility and redundancy.
Key Takeaways
- The network is global, subnets are regional — one VPC can span every region over Google’s private backbone.
- Plan addresses first — use custom mode networks and a non-overlapping, organization-wide IP plan, since address mistakes are costly to fix.
- Routes and firewalls work together — traffic flows only when a route exists and a firewall rule allows it; new networks deny inbound by default.
- Stay private by default — avoid external IPs, and use Cloud NAT, Private Google Access and Private Service Connect for controlled access.
- Choose the right connection method — Shared VPC for central control inside an organization, peering for independent networks (not transitive), VPN or Interconnect with Cloud Router for hybrid.
- Layer your security — combine firewall policies, IAM, organization policies, VPC Service Controls and segmentation.
- Build in visibility and redundancy — use flow logs, firewall logging and Connectivity Tests, and never rely on a single tunnel or link for critical traffic.