A few simple networking ideas make everything else in this guide easy.

Addresses

Every computer on a network needs an address so that others can find it, just like every house needs a street address. On the internet this address is called an IP address. A familiar example looks like four numbers separated by dots. Computers use these addresses to send small chunks of data, called packets, to each other.

Public and private addresses

Some addresses are public, meaning anyone on the internet can try to reach them. Others are private, reserved for use inside an organization and not reachable directly from the outside world. Home Wi-Fi networks use private addresses: your phone and laptop can talk to each other, but a stranger on the internet cannot reach them directly.

Ranges and CIDR

Networks group addresses into ranges. A range is written in a compact style called CIDR notation, such as a base address followed by a slash and a number. The number after the slash says how big the range is: a smaller number means a bigger range. Planning ranges is one of the most important jobs in network design, because ranges that overlap cannot be connected to each other easily.

Routers and firewalls

A router decides which path a packet should take to reach its destination, like a traffic signpost at a junction. A firewall decides whether a packet is allowed to pass at all, like a security guard checking tickets at a gate.

A virtual, software-defined version of a private network, living inside Google Cloud.

A Virtual Private Cloud network is a logically isolated network that you define inside Google Cloud. It looks and behaves like a traditional data center network, with address ranges, routes and firewalls, except it is created with software instead of cables and switches. Your virtual machines, containers and many managed services attach to it and communicate through it.

Because it is software-defined, creating a network takes seconds, changing it is quick, and you do not manage any physical equipment. Google runs the underlying infrastructure, including its huge private fiber network, and presents it to you as a simple set of building blocks.

A single network that can span the whole world.

In many cloud platforms, a virtual network is tied to one region, and connecting regions requires extra work. In Google Cloud, a VPC network is a global resource. One network can include subnets in many regions, and resources in different regions can communicate with each other using private addresses over Google’s own backbone, without you building special links between them.

The subnets themselves, however, are regional. A subnet lives in one region and spans all the zones in that region. So the structure is: one global network, containing several regional subnets, each holding resources placed in zones within that region.

flowchart TD
    VPC[One Global VPC Network]
    VPC --> R1[Subnet in Mumbai region]
    VPC --> R2[Subnet in Frankfurt region]
    VPC --> R3[Subnet in Iowa region]
    R1 --> V1[VM in zone a]
    R1 --> V2[VM in zone b]
    R2 --> V3[VM in zone a]
    R3 --> V4[VM in zone c]
        

The words you will use every day when working with VPC.

Good address planning prevents painful problems years later.

Auto mode and custom mode

Google Cloud offers two modes for creating networks. An auto mode network automatically creates one subnet in every region, using predefined address ranges. It is convenient for quick experiments, and the default network in a new project works this way. A custom mode network starts empty, and you create exactly the subnets and ranges you want. Custom mode is the recommended choice for production, because it gives you control and avoids clashes with other networks.

Planning ranges

When you create a subnet you choose its primary range. You can later enlarge a subnet’s range, but you cannot shrink it, and ranges within connected networks must not overlap. So the safe habit is to plan a company-wide address scheme first: decide which blocks belong to which environment, region or team, leave generous room to grow, and write it down.

Secondary ranges

A subnet can also have secondary ranges, extra address blocks used for special purposes. A common example is container platforms, where pods and services receive addresses from secondary ranges so they are first-class members of the network.

Every packet needs directions.

A route is a rule that says, “traffic heading to this destination range should go to that next hop.” Google Cloud creates some routes automatically. For each subnet, a route is created so that resources in the network can reach each other. A default route to the internet is also created for the network, which is why a resource with an external address can reach the internet unless you remove or override that route.

You can add your own custom routes. For example, you might send all internet-bound traffic through a security appliance first, or point traffic for your office network toward a VPN tunnel. When several routes could apply, the most specific one wins, and priority numbers break ties.

Cloud Router can learn routes dynamically from other networks, such as your office or another cloud, using a standard protocol, so you do not have to type every route by hand. When your office adds a new network, the route appears in your VPC automatically.

By default, the network is closed to outsiders, and you open only what you need.

VPC firewall rules control which traffic may enter or leave your resources. They are enforced at the level of each virtual machine’s network interface, so they protect resources even when those resources are in the same subnet. They are also stateful: if you allow a connection to start in one direction, the replies are automatically allowed back, so you do not need a mirror-image rule.

Implied rules

Every network has two built-in rules you cannot delete. One denies all incoming traffic, and one allows all outgoing traffic. They have the lowest priority, so any rule you create overrides them. This is why a new network is safe by default but your resources can still reach out to the world.

Anatomy of a rule

A rule has a direction (ingress for incoming, egress for outgoing), an action (allow or deny), a priority number, a target that says which resources it applies to, a source or destination, and the protocols and ports it covers. A lower priority number means the rule is checked first, so a priority of 100 beats a priority of 1000.

Targeting resources

Rules can target all resources in the network, resources with a particular network tag, or resources running as a particular service account. Using service accounts is generally the stronger choice, because tags can be changed by anyone who can edit a machine, while service accounts are controlled by identity permissions.

Many resources need to reach out, but very few need to be reachable from outside.

External IP addresses

Giving a resource an external address makes it reachable from the internet, subject to firewall rules. That is necessary for some public-facing services, but it increases exposure. A strong security habit is to give external addresses only to the few resources that truly need them.

Cloud NAT

NAT stands for network address translation. Cloud NAT is a managed service that lets resources with only private addresses start connections to the internet, for example to download software updates, while still not being reachable from the internet. It is not a proxy sitting on one machine; it is built into Google’s networking, so it scales without a single point of failure.

Private Google Access

Many Google services, such as storage and data tools, are reached through Google’s public service addresses. Private Google Access lets resources without external addresses reach those Google services using Google’s internal paths. This means a locked-down virtual machine can still read from a storage bucket without ever touching the public internet.

flowchart LR
    VM[VM with only a private address]
    VM -->|Outbound web traffic| NAT[Cloud NAT]
    NAT --> NET[Internet]
    VM -->|Private Google Access| GS[Google APIs and services]
    NET -.->|Unsolicited inbound traffic blocked| VM
        

Real organizations rarely have just one network. Here are the ways to join them.

flowchart TD
    OFFICE[Office or Data Center] -->|Cloud VPN or Interconnect| CR[Cloud Router]
    CR --> HUB[Shared VPC in Host Project]
    HUB --> P1[Service Project: Web]
    HUB --> P2[Service Project: Data]
    HUB -->|VPC Peering| PART[Partner or Other VPC]
    HUB -->|Private Service Connect| SVC[Published Service]
        

How large companies keep networking tidy.

Imagine a company with fifty teams, each with its own Google Cloud project. If every team created its own network, there would be fifty different address plans, fifty sets of firewall habits and fifty separate connections to the office. It would be chaos, and security reviews would be a nightmare.

Shared VPC solves this by splitting responsibilities. A host project owns the network, with its subnets, routes, firewall rules and hybrid connections. Service projects are attached to it, and their resources, such as virtual machines and containers, are placed into subnets of the host’s network. Network administrators manage the shared network centrally, while project teams are granted permission to use only the specific subnets they need.

Networks work with several companion services.

Follow one request from a virtual machine to a database in another region.

sequenceDiagram
    participant A as VM in Mumbai subnet
    participant FW as Firewall check
    participant R as Route lookup
    participant BB as Google backbone
    participant B as Database VM in Frankfurt subnet
    A->>FW: Send packet to private address of database
    FW->>FW: Egress rules allow it
    FW->>R: Find best route
    R->>BB: Subnet route matches
    BB->>B: Deliver over private backbone
    B->>FW: Ingress rules checked
    FW-->>B: Allowed, packet accepted
    B-->>A: Reply returns automatically as the connection is stateful
        

The key lesson is that two decisions are made for each packet: first, is it allowed by firewall rules, and second, is there a route that leads to its destination. If either answer is no, the packet does not arrive. When connectivity problems occur, checking those two things, in both directions, solves most cases.

A practical recipe for a clean, secure first design.

Defense works best in layers.

Layer 1: Reduce exposure

Resources with no external address cannot be contacted directly from the internet. Use private addresses wherever possible, and place public-facing entry points behind load balancers with protections such as Cloud Armor.

Layer 2: Control traffic precisely

Write firewall rules that allow only necessary ports from necessary sources. Avoid broad rules that open everything to everyone. Use hierarchical policies for company-wide must-haves, such as blocking dangerous ports everywhere.

Layer 3: Separate environments

Keep production apart from development and testing, using separate networks or at least separate subnets and strict rules. Mistakes made in a test environment should never be able to touch live data.

Layer 4: Protect access to managed services

Use Private Google Access and Private Service Connect so traffic to Google and partner services stays off the public internet, and consider VPC Service Controls around sensitive data services.

Layer 5: Watch everything

Flow logs record samples of the connections crossing your network, firewall logs record rule hits, and audit logs record changes. Together they help detect attacks, prove compliance and investigate incidents.

flowchart TD
    A[Few or no external addresses] --> B[Load balancer and Cloud Armor at the edge]
    B --> C[Precise firewall rules and policies]
    C --> D[Separated environments and subnets]
    D --> E[Private access to Google services]
    E --> F[Flow logs, firewall logs and audit logs]
        

Networks are invisible until something breaks, so build visibility early.

Logging everything all the time can be costly, so tune sampling rates and choose where detailed logs are truly needed, such as sensitive subnets and boundaries between environments. Alerts on unusual traffic spikes, blocked connection surges and tunnel failures give early warnings before users notice problems.

The network itself is mostly free, but the traffic and add-ons are not.

Creating a VPC network, subnets and basic firewall rules generally does not carry a charge by itself. Costs come from what flows through and what you attach. Data leaving Google Cloud to the internet is charged. Traffic between regions is charged, and traffic between zones can be charged in certain cases, while traffic within a single zone using internal addresses is usually free. Managed components such as Cloud NAT, Cloud VPN, Cloud Interconnect, load balancers and external IP addresses each have their own pricing, and logging adds storage costs. Because rates and rules change, always check Google Cloud’s current pricing pages.

A balanced look at Google Cloud’s approach.

Habits that keep networks healthy.

Best practices at a glance

Anti-patterns to avoid

The VPC network itself is global. Its subnets are regional, and each subnet spans all zones in its region.

Yes. Within one VPC network, resources in different regions communicate using internal addresses over Google’s backbone, as long as routes and firewall rules allow it.

Auto mode is fine for learning. For production, custom mode is recommended because you control ranges and avoid overlaps with other networks.

Incoming traffic is denied by default unless you add allow rules. Be careful with default networks, which may include convenient but permissive rules, and review them.

Peering connects two separate networks so they can exchange traffic. Shared VPC lets many projects use one centrally managed network. Peering links networks; Shared VPC shares a single network.

VPC peering is not transitive. Each connection works only between the two networks directly joined. To connect A and C you would peer them directly or use a hub-style design.

Use Cloud NAT for outbound internet access, or Private Google Access for reaching Google services, without making the machine reachable from the internet.

Yes. VPC firewall rules are enforced at each machine’s network interface, so they can control traffic even between machines in the same subnet.

VPN is quick and affordable for modest, less critical traffic. Interconnect suits large, steady or sensitive traffic and gives more predictable performance. Many organizations use both, one as a backup for the other.

You can expand a subnet’s primary range, but you cannot shrink it, and the new range must not overlap with others. This is why careful planning up front matters.

A VPC is the foundation of almost everything you do in Google Cloud. It is a global, software-defined private network, made up of regional subnets, routes and firewall rules, which gives your resources private addresses, controlled paths and a secure-by-default posture. With Cloud NAT and Private Google Access, resources can stay private while still using the internet and Google services. With peering, Shared VPC, VPN, Interconnect and Private Service Connect, networks can be joined in the way your organization needs. Good results come from planning address ranges early, writing narrow firewall rules, keeping environments separate, adding visibility and watching traffic costs.