Network Connectivity Center is a managed hub-and-spoke service that connects many networks to each other through one central resource.

The problem it solves

Large organizations rarely have a single network. They have sites, such as offices, factories, shops and data centers. They have cloud networks, called VPCs in Google Cloud, which are private virtual networks that hold your cloud machines. They may also have networks in other clouds. All of these must exchange traffic privately, safely and reliably.

The old way was to connect each pair directly. With three networks you need three connections. With ten networks you need forty-five. With fifty networks you need over a thousand. Every connection must be built, secured, monitored and repaired. This pattern is called a full mesh of point-to-point links, and it becomes unmanageable very quickly.

What NCC actually is

Network Connectivity Center is an orchestration framework. That means it does not carry data by itself in a separate box. Instead, it coordinates connections you already know, such as VPN tunnels, Interconnect links, third-party router appliances and VPC networks, and makes them work together as one system. You create a hub, which is the central management resource. You attach spokes, which are the connections to each site or network. NCC then helps routes and traffic flow between spokes, using Google’s own global backbone network as the road.

Why teams choose it

• Simplicity: one hub replaces a web of individual links.
• Site-to-site transfer: offices and data centers can talk to each other over Google’s backbone, not only to the cloud.
• One view: a single place to see which networks are connected and what routes they share.
• Flexible spoke types: VPN, Interconnect, router appliances for SD-WAN, and VPC networks all fit.
• Governance: central teams control the hub while other teams own their spokes.

Where NCC lives in the bigger picture

Google Cloud networking has layers. At the bottom are the physical links and the Google backbone. Above them are connection services such as Cloud VPN and Cloud Interconnect. Above those sits routing, handled by Cloud Router. NCC sits on top as the coordinator that ties these pieces into a hub-and-spoke design. It does not replace the lower layers. It organizes them.

Six small ideas unlock everything else in this guide: IP address, subnet, route, gateway, BGP and the backbone.

IP address and subnet

Every device on a network has an IP address, a number such as 10.1.2.3 that works like a house number. A subnet is a block of neighboring addresses, written like 10.1.2.0/24. The slash number says how big the block is. A /24 holds 256 addresses, and a /16 holds 65,536. Companies carve their address space into subnets for different offices and systems.

Private addresses

Some address ranges are reserved for private use inside organizations, such as 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Anyone can use them inside their own network, because they are never routed on the open internet. This also means two different companies, or two different teams, may accidentally choose the same private range. That is called an overlap, and it is one of the biggest sources of trouble in connected networks.

Route

A route is a rule that says, “to reach this destination range, send packets this way”. A packet is a small chunk of data. A routing table is a list of such rules. When a machine sends a packet, the network looks up the destination in the table and follows the best matching rule.

Gateway and router

A gateway is a doorway between one network and another. A router is a device or service that reads packets and decides where to forward them. In Google Cloud, Cloud Router is a managed service that learns and shares routes automatically on your behalf.

BGP

Border Gateway Protocol, or BGP, is the language routers use to tell each other which address ranges they can reach. When a router learns that a new office exists, it announces the office range, and neighbors update their tables. If a link breaks, the announcement disappears and traffic finds another path. BGP uses autonomous system numbers, called ASNs, as identity labels for each routing domain.

Google’s backbone

Google runs a huge private fiber network connecting its data center regions around the world. Traffic that enters this network travels over Google’s own cables rather than hopping across many public internet providers. NCC’s site-to-site feature uses this backbone as a private highway between your sites.

Hybrid, VPN and Interconnect in one minute

Cloud VPN builds encrypted tunnels over the public internet. Cloud Interconnect provides private physical connections between your location and Google, with more predictable speed. Both end at a VLAN attachment or VPN tunnel that connects to a Cloud Router. These become the building blocks for NCC spokes.

NCC has only a few main nouns. Learn them well and the rest follows naturally.

The hub

A hub is the central NCC resource. It is a global resource, which means it is not tied to one region. A hub does not move packets itself. It is the place where spokes register, where policies live, and where routing information is collected and shared. You can think of it as the membership club that every network joins.

Spokes

A spoke is one connection attached to a hub. Each spoke represents a site or a network. Spokes come in several types, which we cover in detail later:

• Hybrid spokes use VPN tunnels or Interconnect VLAN attachments to bring in an on-premises site or another cloud.
• Router appliance spokes use virtual machines running routing software, often SD-WAN products from other vendors.
• VPC spokes bring an entire Google Cloud VPC network into the hub.
• Producer VPC spokes connect networks that host managed services provided to you.

Groups

A group is a collection of spokes inside a hub that share the same connectivity rules. Groups are what make topologies possible. For example, in a mesh every spoke belongs to a default group that can talk to all other members. In a star design, some spokes belong to a center group and others to an edge group, and the rules differ between them.

Route tables

A hub keeps route tables that record which destination ranges each spoke offers and how they should be shared. When a spoke announces its ranges, the hub records them. When another spoke is allowed to see them, it receives them. You can inspect these tables to understand why traffic goes where it does.

Topology

The topology is the shape of the connectivity rules in a hub. A mesh topology lets every spoke reach every other spoke. A star topology restricts edge spokes so they reach only the center, not each other. Choosing the right shape is one of the most important design decisions.

Site-to-site data transfer

This is an option you can switch on for hybrid and router appliance spokes. When enabled, traffic between two of your on-premises sites can cross Google’s backbone through NCC. Without it, your sites can still reach the cloud, but they cannot use Google as a bridge to each other.

Each kind of spoke exists to attach a different kind of thing to the hub.

Hybrid spokes: VPN and Interconnect

A hybrid spoke is how an on-premises location joins. You first build the underlying connection: HA VPN tunnels or VLAN attachments, both terminating on a Cloud Router. Then you add them to a hub as a spoke. Each spoke typically represents one site. The Cloud Router learns the site’s ranges with BGP and shares them with the hub.

If you enable site-to-site data transfer on hybrid spokes in different locations, an office in Mumbai can send traffic to a data center in Frankfurt over Google’s backbone. The traffic leaves Mumbai through its tunnel or link, crosses Google’s network, and exits toward Frankfurt.

Router appliance spokes

Many companies already run SD-WAN, which is software that manages many branch connections intelligently. A router appliance is a virtual machine in your VPC running such software. It builds BGP sessions with a Cloud Router, advertising your branch ranges to Google Cloud and learning cloud routes in return. The appliance spoke lets this third-party system join the same hub as everything else.

VPC spokes

A VPC spoke attaches a VPC network directly to the hub. All VPC spokes in the hub can reach each other’s subnets using Google’s internal network, similar to how peered VPCs communicate, but organized through the hub. VPC spokes also exchange routes with hybrid spokes: for example, a VPC spoke can learn routes to an on-premises site that is attached by a hybrid spoke. Teams in different projects can attach their VPCs to a shared hub, with the hub owner approving them.

Producer VPC spokes

Some Google and partner services run in networks that you do not own, called producer networks, reached through private services access. A producer VPC spoke lets those service networks be reachable from other spokes in the hub, so a managed database in one network can be used by workloads in another VPC spoke. Check the current documentation for which services and combinations are supported, because this area evolves.

Here is the whole system in one picture, followed by a walk through every part.

flowchart LR
  subgraph OnPrem["Your sites"]
    O1["Head office"]
    O2["Data center"]
    O3["Branch SD-WAN"]
  end
  subgraph GC["Google Cloud"]
    CR1["Cloud Router A"]
    CR2["Cloud Router B"]
    RA["Router appliance VM"]
    HUB(("NCC Hub"))
    V1["VPC: Production"]
    V2["VPC: Data"]
  end
  O1 -- "HA VPN" --> CR1
  O2 -- "Interconnect" --> CR2
  O3 --> RA
  CR1 -. "hybrid spoke" .-> HUB
  CR2 -. "hybrid spoke" .-> HUB
  RA -. "appliance spoke" .-> HUB
  V1 -. "VPC spoke" .-> HUB
  V2 -. "VPC spoke" .-> HUB
    

How to read the figure

On the left are your own locations. The head office reaches Google Cloud through an HA VPN tunnel that ends on Cloud Router A. The data center uses an Interconnect link that ends on Cloud Router B. The branch network uses SD-WAN software running on a router appliance VM. In the middle sits the hub. The dotted lines mean “is registered as a spoke”. On the right are two VPC networks that also join as spokes.

Component by component

• Hub: the global coordination resource where spokes register and routes are collected.
• Spokes: the registered connections, each pointing at some underlying resource.
• Groups and topology: rules deciding which spokes may talk to which.
• Cloud Router: the managed BGP speaker for hybrid and appliance spokes.
• VPN gateways and tunnels: encrypted links over the internet.
• VLAN attachments: logical connections over an Interconnect.
• Router appliance instances: virtual machines running vendor routing software.
• VPC networks: the cloud networks with subnets and firewall rules.
• Google backbone: the private network that carries site-to-site and cross-region traffic.

Control plane and data plane

Networking people divide a system into two parts. The control plane is the brain: it learns routes, decides what is allowed and keeps tables updated. The data plane is the muscle: it forwards actual packets. In NCC, the hub and Cloud Routers form the control plane. The links, the VPC networks and Google’s backbone form the data plane. Keeping them separate in your mind makes troubleshooting much easier, because a problem is usually either “the route is missing” or “the packet is blocked”.

Joining is a short conversation between you, the hub, and the underlying connection. Understanding it explains many errors.

The big idea

A spoke is not a new cable. It is a registration that points at something that already exists, such as a VPN tunnel, a VLAN attachment, a router appliance or a VPC. When you create the spoke, NCC links that underlying resource to the hub. After that, the routes known by the resource are shared with other spokes according to the hub’s rules, and the dataplane is programmed so packets can follow those routes.

sequenceDiagram
  participant Admin as Network admin
  participant Hub as NCC Hub
  participant CR as Cloud Router
  participant Site as On-premises router
  participant Other as Other spokes
  Admin->>Hub: Create hub
  Admin->>CR: Build tunnels and BGP session
  Site-->>CR: BGP announces site ranges
  Admin->>Hub: Create spoke pointing at tunnels
  Hub->>Hub: Validate and add spoke to group
  CR-->>Hub: Share learned site ranges
  Hub-->>Other: Offer site ranges per topology rules
  Other-->>Hub: Offer their ranges
  Hub-->>CR: Offer other spokes ranges
  CR-->>Site: BGP advertises cloud and other site ranges
    

Reading the sequence

First the administrator creates a hub. Then, separately, they build the underlying connection: tunnels and a BGP session on a Cloud Router. The on-premises router announces its ranges. Next the administrator creates the spoke that points at those tunnels. The hub checks that the request is valid, for example that the resources exist and are in a supported state, and places the spoke into a group. The hub then collects the ranges the spoke offers and shares them with other spokes allowed to see them. In the other direction, the Cloud Router advertises cloud ranges and other sites’ ranges back to your on-premises router.

Approval and projects

Spokes may live in different Google Cloud projects from the hub. This is useful when separate teams own separate networks. In such cases a spoke can be created in its own project and then must be accepted by the hub owner before it joins. A spoke can also be rejected. This approval step lets a central team control membership without taking ownership of every network.

What the hub does not do

The hub does not inspect your traffic, encrypt it or load-balance it. It does not create the underlying tunnels for you. It also does not erase firewall rules. It organizes connectivity, nothing more. This narrow job is why NCC pairs well with other services, such as firewall policies, Cloud NAT, logging and security appliances.

Routing decides which spokes can find each other. This is the heart of NCC.

Where routes come from

• Subnet routes: each VPC automatically knows its own subnet ranges.
• Dynamic routes: learned by Cloud Router from BGP peers, such as on-premises routers or appliances.
• Custom routes: routes you create yourself, for example pointing at a firewall appliance.
• Hub-exchanged routes: routes that NCC passes between spokes according to the topology.

flowchart TD
  A["Spoke announces ranges"] --> B["Hub records ranges in its route table"]
  B --> C{"Topology allows sharing?"}
  C -- "No" --> D["Ranges stay private to that spoke"]
  C -- "Yes" --> E{"Overlap with an existing range?"}
  E -- "Yes" --> F["Conflict handled by overlap rules"]
  E -- "No" --> G["Ranges offered to permitted spokes"]
  G --> H["Receiving spoke installs routes"]
  H --> I["Packets can now follow the new path"]
    

Reading the flow

A spoke announces what it can reach. The hub records this. It then asks whether the topology allows sharing. In a mesh the answer is usually yes; in a star, edge spokes may not see each other. Next the hub checks for overlap with ranges it already knows about. If there is none, the ranges are offered to permitted spokes, which install them as routes. Only then can packets actually follow the new path.

Route preference

When several routes match a destination, Google Cloud picks the best one. The most specific range wins first, called the longest prefix match. A route for 10.1.2.0/24 beats a route for 10.1.0.0/16 for an address inside the smaller block. If two routes are equally specific, priorities and BGP attributes such as MED decide. Equal routes may share load using ECMP, which spreads traffic across equal-cost paths.

Overlapping ranges

Overlap is the classic way to break connected networks. If two spokes announce the same or overlapping ranges, the hub cannot know which spoke owns an address. NCC has behaviors for detecting and handling overlap, especially for VPC spokes, and generally refuses or flags conflicting subnet ranges. Rules differ by spoke type, so confirm current behavior in the documentation. The safe habit is simple: never allow overlap to exist in the first place.

Export and include filters

Not every range must be shared. For some spoke types you can set which ranges the spoke exports to the hub and which it includes, so private test ranges or sensitive subnets stay out of the shared routing domain. Think of these as filters on the way into and out of the clubhouse.

Advertising back to your sites

Cloud Router can advertise Google Cloud and other spokes’ ranges to your on-premises routers. By default it advertises the subnets of its own VPC. For hub-based designs you often need custom advertisements so the on-premises side learns the ranges of other sites and VPC spokes. Keep advertised lists summarized, because routers have limits on how many routes they will accept.

Topology is the shape of who may talk to whom. NCC offers ready-made shapes so you do not have to build rules by hand.

flowchart LR
  subgraph MESH["Mesh: everyone can talk to everyone"]
    M1["VPC A"] --- M2["VPC B"]
    M2 --- M3["VPC C"]
    M1 --- M3
  end
  subgraph STAR["Star: edges talk only to the center"]
    C["Center: shared services"]
    E1["Edge: Team 1"] --- C
    E2["Edge: Team 2"] --- C
    E3["Edge: Team 3"] --- C
  end
    

Mesh topology

In a mesh, all spokes in the default group can exchange routes and traffic with each other. This suits teams that must collaborate freely, such as a set of production services that all need to call each other. It is simple to understand, but it also means a mistake or a compromise in one VPC can reach every other VPC if firewalls do not stop it.

Star topology

In a star, spokes are divided into a center group and an edge group. Center spokes can reach everyone. Edge spokes can reach the center, but not each other. This is excellent for separation. Shared services, such as logging, identity, security scanning or a central firewall, sit in the center. Each team or customer sits on an edge, isolated from the others yet able to use shared services.

Choosing between them

Changing topology later

Topology is chosen at the hub level. Changing it later can affect existing connectivity, so treat it as a planned change, not a casual tweak. If you are unsure, begin with the more restrictive design. Opening connectivity later is far safer than closing it after teams depend on it.

This feature lets your own offices and data centers use Google’s backbone as a private highway between themselves.

flowchart LR
  S1["Office in Mumbai"] -- "HA VPN" --> CR1["Cloud Router, Asia"]
  CR1 --> HUB(("NCC Hub with site-to-site transfer"))
  HUB --> CR2["Cloud Router, Europe"]
  CR2 -- "Interconnect" --> S2["Data center in Frankfurt"]
  S1 -. "Traffic crosses Google backbone" .-> S2
    

The idea

Normally, a branch connected to Google Cloud can reach cloud resources, and that is all. To let two of your sites talk to each other, you would build a separate link between them, or send traffic through some appliance. With site-to-site data transfer, you enable the feature on the hybrid or router appliance spokes. Their routes are then shared, and traffic can enter Google’s network at one site and leave at another.

Why it matters

• Less to build: no separate wide-area network between every pair of sites.
• Speed and consistency: Google’s backbone usually offers steadier performance than a chain of public internet providers.
• Simple growth: a new site needs only one connection to the hub, and it can reach all the others.
• Central policy: one place to see and control the inter-site routes.

Things to check

• Eligibility: the feature applies to specific spoke types. Confirm in the current documentation which combinations are supported.
• Cost: traffic carried between sites is billed as data transfer. Estimate volumes before relying on it.
• Terms of use: Google publishes conditions for this feature, including regional and legal considerations. Read them before use in regulated settings.
• Capacity: each underlying VPN tunnel or attachment still has a bandwidth limit. The hub does not remove it.
• Security: traffic over Interconnect is not encrypted by default. Consider encryption such as HA VPN over Interconnect or MACsec if required.

VPC spokes let many cloud networks join a hub without building and maintaining a web of peerings.

What a VPC spoke is

A VPC spoke attaches a whole VPC network to the hub. Other VPC spokes in the same group can then reach its subnets using private addresses. The traffic stays on Google’s internal network, so it is fast and does not touch the public internet. You do not manage any gateway or tunnel for it.

Compared with VPC Network Peering

VPC Network Peering connects two VPCs directly. It is simple and fast, but each peering is one-to-one, and by default peered networks do not pass routes along to third networks, a limitation known as the transitivity problem. With ten VPCs in a full mesh you would need forty-five peerings, each configured on both sides, and each peered network has quotas that can run out.

A VPC spoke avoids many of these limits. Each VPC makes one connection to the hub, instead of one for each partner. The hub manages route exchange in a consistent way. Adding the eleventh VPC means adding one spoke, not ten peerings.

VPCs in many projects

Large companies place VPCs in separate projects, often under different folders and owners. NCC allows spokes to live in other projects, with the hub owner accepting each one. The central network team controls the hub, while application teams keep ownership of their own VPCs. This division of duties matches how many organizations actually work.

Subnet overlap rules

Because every VPC spoke shares subnet routes through the hub, overlapping subnet ranges between VPC spokes are a problem. Plan unique ranges across all VPCs before onboarding them. If two existing VPCs overlap, you must renumber one, or keep one of them out of the hub, or use an exclusion setting if the product supports it for your case.

How many VPC spokes should you have?

A common question is whether to give each application its own VPC or to keep a few large ones. There is no single answer, but a few guidelines help. Use separate VPCs when teams need different owners, different security rules, or different billing. Keep related services together when they must share a network and change at the same time. Remember that every VPC spoke adds one more member to the shared routing domain, so more VPCs mean more ranges to plan, more firewalls to write, and more routes to watch.

Many organizations settle on one VPC per environment and business unit, often using Shared VPC inside each one so that many projects can use the same network. Each of those networks then joins the hub as a single spoke. This keeps the number of spokes modest while still giving strong separation where it matters.

The arithmetic of growth

Suppose you have twelve VPC networks. Connecting each pair with peering needs sixty-six peerings, and each one has two sides to configure and two sets of quotas to watch. With a hub, you need twelve spokes. If next quarter you add four more networks, peering requires another fifty-four connections, while the hub needs only four new spokes. This simple arithmetic is why hubs become more attractive as an organization grows.

Firewalls and security still apply

Connecting VPCs with a hub does not turn off firewall rules. Each VPC still has its own firewall policy. The default behavior is to deny incoming traffic, so you must explicitly allow the sources, ports and protocols that other spokes should use. Write rules that name specific ranges or service identities, not “everything from anywhere”.

Router appliance spokes let the software your network team already trusts join the hub.

What SD-WAN is

A wide-area network, or WAN, connects far-apart locations. SD-WAN means software-defined WAN. It is software that watches several connections at each branch, such as broadband, mobile data and leased lines, and steers each application over the best one. Many vendors sell SD-WAN products, and many companies run them at hundreds of branches.

How the appliance fits in

The vendor supplies a virtual machine image. You deploy it in a VPC in Google Cloud. The appliance forms a BGP session with a Cloud Router, using the Cloud Router’s interfaces inside the VPC. Through that session the appliance announces the branch ranges it controls, and learns the cloud ranges. You then register the appliance instances as a router appliance spoke on the hub. From that moment the branch networks are part of the hub, and can reach VPC spokes, hybrid spokes and, with site-to-site transfer, each other.

Two appliances for resilience

A single virtual machine is a single point of failure. Production designs usually run at least two appliances, often in different zones, each with its own BGP session. If one fails, the other continues to carry traffic. The Cloud Router handles which routes are preferred, using priorities you set, so that a healthy appliance is used first and the backup takes over when needed.

Why it is worth it

• Keep your tools: you can retain the SD-WAN product and its policies.
• Use Google’s backbone: branches reach other branches over Google’s network, replacing costly leased lines.
• One hub: SD-WAN, VPN, Interconnect and VPC spokes are managed together.

Things to design carefully

• Machine size: appliances need enough CPU and network bandwidth, because they process every packet.
• Source and destination checks: a virtual machine that forwards packets for others must be allowed to do so, which in Google Cloud means enabling IP forwarding on the instance.
• Licensing: vendor software has its own license and cost model.
• Vendor guidance: follow the supported-vendor documentation. Google lists partner solutions that have been validated.

A hub makes it easy to connect everything. It does not remove the physical limits of the links underneath.

Redundancy belongs to the spoke connection

NCC itself is a managed global service, but each spoke depends on a connection you build. That connection must be redundant. For VPN, use HA VPN with two tunnels on both interfaces and a redundant peer device. For Interconnect, follow Google’s recommended patterns for either 99.9 or 99.99 percent availability, which involve multiple links across separate metropolitan areas and edge availability domains. Check Google’s current documentation for the exact requirements of each tier.

Bandwidth

Each VPN tunnel has a capacity limit, roughly a few gigabits per second at best, depending on packet sizes and peer devices. Each Interconnect attachment has a chosen capacity. A router appliance is limited by its machine type and software. If many sites send traffic through one spoke, that spoke’s link becomes the bottleneck. You can add more tunnels or attachments to the same Cloud Router and use ECMP to share load across them.

Latency

Distance matters. A packet from Mumbai to Frankfurt takes longer than one from Mumbai to Singapore, even over Google’s fast backbone. Pick Cloud Router regions near your sites and workloads. When two sites exchange a lot of traffic, think about which regions the traffic will cross and whether the path is sensible.

MTU

MTU, maximum transmission unit, is the largest packet a link carries. VPN tunnels add overhead for encryption, so their usable MTU is smaller. VPC networks have their own MTU setting. Mismatched MTU causes odd symptoms: small requests work and large transfers freeze. Follow Google’s recommendations for each connection type, and test large transfers after setup.

A simple capacity planning method

Capacity planning sounds grand, but it can be done with a few honest questions. First, measure the busiest hour of traffic for each site, not the daily average, because users feel the peak. Second, add growth for the next year, perhaps a third more, unless you know better. Third, decide what must keep working when one link fails. If a site needs four gigabits per second at peak and each tunnel or attachment gives less than that, you need several links sharing the load, plus one spare so that a single failure does not cause congestion.

Write the result in a small table: site, peak traffic, number of links, capacity after one failure, and who approved the decision. Revisit it every few months. Networks that were comfortable a year ago are often crowded today, and the table is how you notice before users complain.

Quotas and limits

Every Google Cloud service has quotas, such as the number of spokes per hub, routes per spoke, tunnels per gateway and BGP sessions per Cloud Router. These numbers are updated from time to time, so we do not quote them here. Before a large rollout, read the current limits and request increases early, because approvals can take time.

Let us follow one request from a branch office to an application in a VPC, and then a second one from branch to branch.

sequenceDiagram
  participant PC as Branch computer
  participant BR as Branch router
  participant VPN as HA VPN tunnel
  participant CR as Cloud Router region
  participant NET as Google network
  participant APP as App in VPC spoke
  PC->>BR: Request to 10.20.1.5
  BR->>VPN: Matches route, encrypt and send
  VPN->>CR: Arrives at Google gateway
  CR->>NET: Route learned via hub points to VPC spoke
  NET->>APP: Firewall allows, delivered
  APP-->>NET: Reply
  NET-->>CR: Return route to branch exists
  CR-->>VPN: Encrypt and send back
  VPN-->>BR: Decrypt
  BR-->>PC: Response
    

Step by step

Branch to branch

With site-to-site data transfer, a packet from the Mumbai office to the Frankfurt data center follows a similar path. It enters Google through the Mumbai tunnel, crosses Google’s backbone based on routes exchanged via the hub, and exits through the Frankfurt Interconnect. The packet does not visit any VPC. It simply transits Google’s network.

Symmetry matters

Requests and replies should travel along matching, preferably identical, paths. If the request goes through one firewall appliance and the reply goes through another that never saw the request, stateful firewalls will drop it. When you use multiple tunnels and ECMP, plan carefully for such asymmetric routing.

Connecting everything is convenient. Connecting everything safely requires deliberate design.

Segmentation: do not trust the hub

A hub joins networks, but it should not make them trust one another. Use zero-trust thinking: assume any connected network may be compromised, and require every request to be explicitly allowed. Use star topology to isolate tenants, firewall rules to limit ports, and separate hubs for separate security zones such as production and development.

Firewalls

Google Cloud offers VPC firewall rules and hierarchical firewall policies that apply across a whole organization or folder. Use the hierarchical ones for rules that must never be overridden, such as blocking known-dangerous ports from on-premises ranges. Use network-level rules for application-specific access. Keep them narrow: name source ranges, destination ranges, protocols and ports.

Encryption

• HA VPN: traffic is encrypted with IPsec across the internet.
• Interconnect: private, but not encrypted by default. Options include MACsec on supported Dedicated links and HA VPN running over Interconnect for IPsec encryption.
• Inside Google’s network: Google encrypts traffic between its data centers at layers beneath your view, but you should still use TLS in your applications for end-to-end protection.

Central inspection

Many organizations require that traffic between zones pass through a security appliance, such as a next-generation firewall or intrusion detection system. In a hub design, you can place such appliances in a central VPC and steer traffic through them using custom routes and next-hop settings, often with an internal load balancer in front for resilience. Google also provides services such as Cloud IDS and Cloud NGFW, and partners provide virtual appliances. Check current documentation, because inspection patterns with NCC are evolving.

Protecting the control plane

• BGP hygiene: advertise only the ranges needed, and consider MD5 authentication on BGP sessions if your peer supports it.
• Prefix filtering: do not accept unexpected ranges from branch routers.
• Key handling: store VPN shared secrets in a secret manager, and rotate them.
• Change control: a wrong route can redirect traffic. Review route changes like code changes.

Logging for evidence

Turn on audit logs to see who created or changed hubs and spokes. Turn on VPC Flow Logs and firewall logging on sensitive subnets to see who talked to whom. These records answer the questions every incident review asks.

Who may create hubs, attach spokes or change routes is just as important as the packets themselves.

IAM in simple words

Identity and Access Management, or IAM, decides who can do what in Google Cloud. A role is a bundle of permissions, and you grant roles to people, groups or service accounts. NCC has its own roles for hubs and spokes, for example roles that let someone administer hubs, administer spokes, or only view them. Names and details can change, so look up the current role list in the documentation.

Separation of duties

• Central network team: owns the hub, accepts or rejects spokes, and manages shared routing.
• Application teams: own their VPCs, create their spokes, and manage their own firewalls.
• Security team: reviews policy, inspects logs, and can audit changes without needing the power to change them.

Organization policy

Organization policies add guardrails across projects. You can restrict where resources may be created, who may attach spokes to a hub, or which external services may be used. Use them to make bad designs impossible, not merely discouraged.

Naming, labels and documentation

Use consistent names that state the purpose, such as hub-prod-global or spoke-dc-frankfurt. Add labels for owner, environment and cost center. A network that cannot be understood by a new engineer at 3 a.m. is a network waiting for a long outage.

Audit and change management

Treat hub and spoke changes as production changes. Require review, test in a non-production hub first, and keep a rollback plan. Cloud Audit Logs record who changed what and when, so you can reconstruct events afterwards.

Google Cloud offers several ways to connect networks. Choosing well saves money and effort.

VPC Network Peering

Peering joins two VPCs directly. It is simple, low-latency and has no extra gateway cost. But it is one-to-one, not transitive by default, and each side has quotas. Peering is excellent for a small number of connections. NCC is better when the number grows or when you need on-premises reach through shared routing.

Shared VPC

Shared VPC lets many projects use subnets from one central VPC. It is about sharing one network among projects, not about connecting separate networks. The two ideas work together: a company may run several Shared VPCs, one per environment, and attach each to an NCC hub as a spoke.

A hub VPC with VPN and peering

Before NCC, a popular design was a hub VPC holding the VPN gateways, with spoke VPCs peered to it. Because peering is not transitive, spokes needed workarounds to reach on-premises, such as custom route exchange. This works, but is fiddly. NCC with VPC and hybrid spokes is a cleaner, managed alternative.

Cloud VPN or Interconnect alone

If you only need one site connected to one VPC, those services alone are enough. NCC adds value when you have multiple sites, multiple VPCs, or need site-to-site transfer.

Private Service Connect

Private Service Connect exposes a specific service privately to consumers, using a private IP in the consumer’s network. It is for publishing or consuming services, not for joining entire networks. Combine it with NCC when you want both broad connectivity and tightly scoped service exposure.

Comparison table

The exact screens change over time, so this chapter explains the order of work and the reasons behind each step.

flowchart TD
  A["Plan addresses, sites and groups"] --> B["Choose topology: mesh or star"]
  B --> C["Create the hub"]
  C --> D["Build underlying connections: VPN, Interconnect, appliances"]
  D --> E["Configure Cloud Router and BGP"]
  E --> F["Create spokes and add to groups"]
  F --> G["Hub owner accepts cross-project spokes"]
  G --> H["Set advertisements and firewall rules"]
  H --> I["Test routes and traffic both ways"]
  I --> J{"Everything correct?"}
  J -- "No" --> K["Fix and retest"]
  K --> I
  J -- "Yes" --> L["Turn on monitoring and alerts"]
    

The steps

Start small

Do not onboard everything on day one. Begin with two or three spokes, prove the pattern, write a short runbook, and then add more. Each new spoke should follow the same recipe.

Use infrastructure as code

Describe hubs, spokes, Cloud Routers and tunnels in a tool such as Terraform, and keep it in version control. This gives you repeatable builds, peer review, and a record of every change. Manual console work cannot be reviewed or reproduced reliably.

You cannot fix what you cannot see. Good observability turns surprises into routine alerts.

Three kinds of signals

• Metrics: numbers over time, such as bytes sent, tunnel status and BGP session state.
• Logs: written records of events, such as configuration changes and firewall decisions.
• Topology and tests: pictures and probes of how traffic should and does flow.

What to watch

Google Cloud tools

• Cloud Monitoring: dashboards and alert policies for metrics.
• Cloud Logging: collects audit logs, VPN logs, firewall logs and flow logs.
• Network Intelligence Center: includes Network Topology to visualize connections, Connectivity Tests to check whether a path should work, and performance and firewall analysis tools.
• VPC Flow Logs: samples of traffic between machines, useful for investigations and capacity planning.

Alerts that matter

• Any tunnel or BGP session down for more than a few minutes.
• Redundancy lost: only one of two paths is up. This is the most valuable alert, because the second failure becomes the outage.
• Bandwidth above about seventy percent of capacity for a sustained period.
• A large change in the number of learned routes.
• Any hub or spoke configuration change outside the change window.

Work from the bottom up: physical link, routing, hub membership, firewall, then application.

A reliable method

1. Is the underlying link up? Check the tunnel or attachment status.
2. Is BGP established? Check the session state and the routes learned.
3. Is the spoke active in the hub? Look for pending, rejected or inactive states.
4. Are routes present both ways? Check the source side, the destination side and the return path.
5. Is a firewall blocking? Check cloud and on-premises rules and logs.
6. Is the application listening? Check the service itself last.

Symptom table

Useful tools

• Connectivity Tests: analyze the configuration and tell you where a path stops.
• Route views: inspect the effective routes of a VPC and the Cloud Router’s learned and advertised routes.
• Firewall logs: show allowed and denied connections.
• Packet captures on the peer device: useful when you suspect tunnel or MTU trouble.

Every system fails sometimes. Good designs fail gracefully and recover quickly.

Failure scenarios

Design for graceful failure

• Two of everything for critical paths: tunnels, peers, appliances and regions.
• Different providers and physical paths where possible.
• Route priorities that prefer the primary path and use the backup only when needed.
• Fast failure detection, such as BFD, on links where it is supported.
• Capacity planning for the surviving path.

Maintenance

Google performs maintenance on VPN gateways and other infrastructure from time to time, designed to be non-disruptive when you run redundant tunnels. Your own maintenance, such as updating a peer router or appliance, should be done one device at a time, with traffic drained first. Never update both members of a redundant pair at once.

Recovery steps

Prices change, so this chapter explains what you pay for, not exact amounts. Always check Google’s current pricing page.

What can cost money

• Underlying connections: VPN tunnel hours, Interconnect port or attachment fees, and partner charges.
• Router appliances: virtual machine costs and vendor software licenses.
• Data transfer: traffic leaving a region, crossing regions, leaving Google Cloud, or moving between your sites through the hub.
• Hub-specific charges: NCC has charges for some features, for example data transfer between sites through spokes. Confirm which items are billed in your situation.
• Supporting services: logging volume, flow logs, inspection appliances and monitoring.

Ways to keep costs sensible

• Estimate traffic volumes between sites and regions before relying on site-to-site transfer.
• Place workloads near the data they use, to avoid cross-region transfer.
• Right-size appliances, and review them after real traffic is measured.
• Sample logs and flow logs sensibly, instead of capturing everything forever.
• Compare against alternatives: a direct Interconnect between two data centers may be cheaper for very heavy, steady traffic.
• Use labels so you can attribute costs to teams.

Cost versus value

NCC can reduce the labor cost of building and running many connections, which is often the largest hidden cost in big networks. Include engineer time in your comparison, not just the bill from Google.

A fair look at strengths and limits helps you decide when NCC is the right tool and when something simpler will do.

The central trade-off: convenience versus blast radius

The very thing that makes a hub useful, that everything is connected, also means that a mistake travels far. A wrong route advertised by one spoke could disturb traffic for many. A permissive firewall rule could expose many networks. The answer is not to avoid hubs but to design with containment: separate hubs for separate risk zones, star topologies for isolation, route filters, narrow firewalls and careful change control.

When NCC is a strong choice

• You have several sites and several VPCs that must all communicate.
• You want to use Google’s backbone between sites.
• You operate SD-WAN and want it integrated with Google Cloud.
• Many teams own networks and need central governance.

When something simpler is better

• One site to one VPC: use VPN or Interconnect directly.
• Two or three VPCs: peering may be enough.
• One shared network for many projects: Shared VPC.
• Exposing a single service: Private Service Connect.

Patterns are proven recipes. Anti-patterns look reasonable but cause pain later.

Patterns worth knowing

Anti-patterns to avoid

If you remember only one chapter for real work, make it this one.

A practical order of work for production

Common mistakes beginners make

• Overlapping ranges between sites or VPCs.
• Forgetting the return route, so connections start but never finish.
• Assuming a hub opens firewalls, when it only creates routes.
• One tunnel or one appliance for a critical site.
• Not enabling site-to-site transfer and wondering why sites cannot see each other.
• Forgetting to advertise hub routes back to on-premises routers with custom advertisements.
• Advertising too many tiny routes and hitting limits.
• Mesh when star was needed, giving every team access to every other.
• Ignoring MTU, then losing days to mysterious freezes.
• Leaving pending spokes unapproved and not noticing.
• No alert for lost redundancy, so a second failure becomes the outage.
• Not reading current documentation, since features and limits change.

These are common ways organizations use hub-and-spoke networking, based on typical industry practice. Google publishes customer stories for named examples, and you should consult them for current details.

Once the basics are solid, these topics make large networks smoother and safer.

Migrating from peering to a hub

flowchart TD
  A["Inventory VPCs, peerings and routes"] --> B["Check address overlaps"]
  B --> C["Create hub and test group"]
  C --> D["Attach a low-risk VPC as spoke"]
  D --> E["Test traffic and firewall rules"]
  E --> F{"Healthy?"}
  F -- "No" --> G["Fix and retest"]
  G --> E
  F -- "Yes" --> H["Attach next VPCs in waves"]
  H --> I["Confirm all paths work via hub"]
  I --> J["Remove old peerings one at a time"]
    

Do not delete old connections first. Build the hub path beside them, test it, move workloads in waves, and retire peerings only once monitoring proves the hub path is carrying traffic correctly. Check the current documentation for how routes from peering and from the hub interact during the overlap period, because the more specific route and the rules about priority decide which path traffic follows.

DNS across the hub

People reach systems by name, not number. Names such as “billing.internal” must resolve everywhere. Cloud DNS supports private zones, forwarding zones that send questions to on-premises DNS servers, and policies that let on-premises servers ask Google Cloud for names. In a hub design, decide where DNS lives, often in the center of a star, and make sure every spoke can reach it.

Central traffic inspection

When policy requires every cross-zone flow to be inspected, place security appliances in a central VPC, steer traffic to them with routes, and put an internal load balancer in front for resilience. Keep return paths symmetric so stateful firewalls see both directions. The details vary by product, so follow current reference architectures.

Fast failure detection

BGP can take tens of seconds to notice a dead neighbor. Bidirectional Forwarding Detection sends tiny frequent probes and can detect failures in about a second. It speeds failover but can create false alarms on noisy links, so tune it with testing.

IPv6

As organizations adopt IPv6, plan ranges for both address families. Check current support for IPv6 on each spoke type and on Cloud Router, because it differs by product and may change. Keep firewall rules consistent across both families.

Multi-region design

A hub is global, but Cloud Routers, tunnels and attachments live in specific regions. A good design places connection points in the regions closest to your sites, and also in at least two regions for important sites. If one region has trouble, the site still reaches the hub through the other. Use route priorities so that traffic prefers the nearest healthy region, and test what happens when that region is taken away.

Think about where your workloads run, too. If a branch in Mumbai talks mostly to an application in a Mumbai region VPC, enter Google in Mumbai. Sending that traffic through a faraway region adds delay and cross-region cost for no benefit.

A worked example: a growing retailer

Let us follow an imaginary retailer named FreshMart to see the pieces working together. FreshMart has a head office, one data center, two hundred shops running SD-WAN, and four cloud networks: production, data, shared services and development.

1. Address plan. The network team writes a register. Shops get ranges from one big block, the data center and head office get their own blocks, and each cloud network gets a unique block. They find that development accidentally overlaps with the data center, and renumber development before doing anything else.
2. Two hubs. They create one hub for production and one for non-production. A mistake in test routing cannot affect shops.
3. Star topology. In the production hub, shared services form the center group. Production and data VPCs sit on the edge, and so do the hybrid spokes. Shops reach shared services and the production application, but cannot reach each other, which is exactly what the security team asked for.
4. Redundant connections. The data center uses two Interconnect attachments in separate locations, with an HA VPN as backup at a lower priority. Shops connect through pairs of router appliances in two zones, each pair in the region nearest the shop.
5. Narrow firewalls. Payment systems accept connections only from specific application ranges on specific ports. Shop ranges cannot reach the data VPC at all.
6. Monitoring. Dashboards show each spoke. Alerts fire when a pair loses one of its two appliances, long before shops notice anything.
7. Failure drill. Every quarter the team switches off one Interconnect attachment during a quiet hour, checks that traffic shifts to the backup, and writes down what they learned.

The result is a network that new shops join in an afternoon by following the same recipe, that auditors can understand from one diagram, and that survives the common failures without a phone call at midnight.

Questions to ask before every change

• Which spokes and routes will this change touch, and who owns them?
• Can it create an overlap, a loop or a black hole?
• What is the rollback, and how long will it take?
• Which alert will tell us quickly if it goes wrong?
• Have we tested it first in a non-production hub?

Operating at scale

• Quotas: watch limits on spokes, routes, tunnels and BGP sessions. Request increases early.
• Route summarization: advertise one range per region or site instead of many small ones.
• Automation: create spokes from templates and run overlap and quota checks in a pipeline.
• Change windows: routing changes follow a calendar, reviewed and with rollback plans.
• Documentation: diagrams, address registers and contacts are kept current and stored where on-call engineers can find them.

Network Connectivity Center gives you one managed meeting point for many networks. You create a hub, attach spokes for VPN tunnels, Interconnect links, router appliances and VPC networks, and let the hub coordinate routes among them. Mesh and star topologies express who may talk to whom, and site-to-site data transfer lets your own offices and data centers use Google’s backbone as a private highway. Behind the scenes, Cloud Router and BGP learn and share routes, while firewalls, IAM and logging keep the system safe and accountable. The hub does not erase the limits of the links below it, so redundancy, capacity, MTU and cost still need planning. With a clean address plan, narrow firewalls, automation, monitoring and rehearsed recovery, a hub turns a tangle of connections into a calm, understandable network.