{"id":764,"date":"2026-04-16T02:20:13","date_gmt":"2026-04-16T02:20:13","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-network-connectivity-center-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking\/"},"modified":"2026-04-16T02:20:13","modified_gmt":"2026-04-16T02:20:13","slug":"google-cloud-network-connectivity-center-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-network-connectivity-center-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking\/","title":{"rendered":"Google Cloud Network Connectivity Center Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Networking"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Networking<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What this service is<\/h3>\n\n\n\n<p><strong>Network Connectivity Center<\/strong> is Google Cloud\u2019s hub-and-spoke connectivity management service for building and operating <strong>hybrid and multi-network connectivity<\/strong> in a centralized, scalable way.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">One-paragraph simple explanation<\/h3>\n\n\n\n<p>If you have multiple networks\u2014like on-prem sites connected with VPN or Interconnect, plus multiple VPC networks in Google Cloud\u2014Network Connectivity Center lets you connect them using a <strong>hub<\/strong> and <strong>spokes<\/strong>, so you can avoid complex point-to-point designs and manage routing and connectivity in one place.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">One-paragraph technical explanation<\/h3>\n\n\n\n<p>Technically, Network Connectivity Center provides a control plane to attach multiple network \u201cspokes\u201d (for example, <strong>Cloud VPN<\/strong>, <strong>Cloud Interconnect VLAN attachments<\/strong>, <strong>router appliances<\/strong>, and (where supported) <strong>VPC network spokes<\/strong>) to a <strong>hub<\/strong>. It orchestrates <strong>route exchange<\/strong> between these spokes, enabling <strong>transitive routing<\/strong> across networks in a controlled hub-and-spoke model. Data traffic continues to flow over the underlying Google Cloud networking primitives (VPN, Interconnect, Cloud Router\/BGP, VPC routing), while Network Connectivity Center coordinates connectivity and routing policy at scale.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What problem it solves<\/h3>\n\n\n\n<p>Without Network Connectivity Center, organizations often build brittle \u201cmeshes\u201d of VPNs, VPC peering, or custom routing appliances. This leads to:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Too many point-to-point links to manage<\/li>\n<li>Inconsistent route propagation and routing policy<\/li>\n<li>Higher operational risk during changes<\/li>\n<li>Hard-to-audit connectivity between environments<\/li>\n<li>Scaling limits (route tables, BGP sessions, peering sprawl)<\/li>\n<\/ul>\n\n\n\n<p>Network Connectivity Center is designed to reduce that complexity by providing a <strong>central connectivity construct (hub)<\/strong> and standardized <strong>attachments (spokes)<\/strong> with controlled route exchange.<\/p>\n\n\n\n<blockquote>\n<p>Service status and naming: <strong>Network Connectivity Center<\/strong> is an active Google Cloud Networking service. If you encounter older references to \u201ctransit hub\u201d patterns or third\u2011party \u201ctransit VPC\u201d designs, those are architectural concepts; the product name remains <strong>Network Connectivity Center<\/strong>. Always verify the latest supported spoke types and features in the official documentation.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Network Connectivity Center?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>Network Connectivity Center\u2019s purpose is to provide <strong>centralized, policy-driven connectivity<\/strong> between multiple networks across Google Cloud and on\u2011premises environments using a hub-and-spoke model.<\/p>\n\n\n\n<p>Official documentation (start here):<br\/>\nhttps:\/\/cloud.google.com\/network-connectivity-center\/docs\/overview<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<p>At a high level, Network Connectivity Center helps you:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create a <strong>hub<\/strong> as a central connectivity domain.<\/li>\n<li>Attach different types of <strong>spokes<\/strong> (connectivity endpoints).<\/li>\n<li>Enable and control <strong>route exchange<\/strong> between spokes.<\/li>\n<li>Scale hybrid connectivity while keeping routing manageable.<\/li>\n<li>Reduce the need for full mesh VPNs\/peerings.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<p>While exact feature names evolve, Network Connectivity Center generally revolves around:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Hub<\/strong><\/li>\n<li>The central connectivity construct.<\/li>\n<li>Where routing exchange and connectivity policy are applied.<\/li>\n<li><strong>Spokes<\/strong><\/li>\n<li>Attachments that represent connectivity endpoints.<\/li>\n<li>Common spoke types include:<ul>\n<li><strong>VPN spokes<\/strong> (Cloud VPN \/ HA VPN tunnels)<\/li>\n<li><strong>Interconnect spokes<\/strong> (VLAN attachments for Dedicated\/Partner Interconnect)<\/li>\n<li><strong>Router appliance spokes<\/strong> (third-party or self-managed routing appliances, often BGP-based)<\/li>\n<li><strong>VPC spokes<\/strong> (where supported; used to connect VPC networks through the hub model\u2014verify current availability and constraints in official docs)<\/li>\n<\/ul>\n<\/li>\n<li><strong>Route exchange \/ route propagation controls<\/strong><\/li>\n<li>Controls which routes are shared across which spokes (for example using route tables\/associations if supported in your release\u2014verify in official docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<p>Network Connectivity Center is primarily a <strong>managed networking control-plane service<\/strong> that coordinates connectivity and routing across underlying data-plane constructs such as:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Router (BGP)<\/strong><\/li>\n<li><strong>HA VPN<\/strong><\/li>\n<li><strong>Cloud Interconnect<\/strong><\/li>\n<li><strong>VPC routing<\/strong><\/li>\n<\/ul>\n\n\n\n<p>Traffic does not \u201cterminate\u201d at Network Connectivity Center like a traditional firewall; instead, NCC orchestrates how routes are exchanged so that traffic can flow between networks through supported connectivity.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Scope: regional\/global and resource boundaries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Network Connectivity Center is designed to manage connectivity <strong>across regions<\/strong> and <strong>across multiple networks<\/strong>.<\/li>\n<li>Many underlying attachments (VPN tunnels, VLAN attachments, Cloud Routers) are <strong>regional<\/strong> resources.<\/li>\n<li>Hubs\/spokes are managed at the project level and may be treated as <strong>global<\/strong> constructs with <strong>regional attachments<\/strong> depending on spoke type.<\/li>\n<\/ul>\n\n\n\n<p>Because the exact scoping and availability can change (and differs by spoke type), <strong>verify hub\/spoke scope and constraints<\/strong> in the official docs for your intended design:\nhttps:\/\/cloud.google.com\/network-connectivity-center\/docs\/concepts\/overview (navigate from overview)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Network Connectivity Center sits in the Google Cloud Networking portfolio alongside:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>VPC networks<\/strong> (your private IP networks)<\/li>\n<li><strong>Cloud Router<\/strong> (dynamic routing\/BGP)<\/li>\n<li><strong>Cloud VPN \/ HA VPN<\/strong> (encrypted tunnels)<\/li>\n<li><strong>Cloud Interconnect<\/strong> (private, high-throughput connectivity)<\/li>\n<li><strong>Network Intelligence Center<\/strong> (connectivity tests, topology, performance insights)<\/li>\n<li><strong>Cloud DNS, Cloud NAT, firewall rules, and routing policies<\/strong> (traffic control)<\/li>\n<\/ul>\n\n\n\n<p>Network Connectivity Center\u2019s value is not replacing these services, but <strong>organizing them into a scalable connectivity architecture<\/strong>.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Network Connectivity Center?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Faster network expansion:<\/strong> Add new sites or environments as spokes without redesigning a mesh.<\/li>\n<li><strong>Standardized connectivity:<\/strong> A repeatable hub-and-spoke pattern reduces ad hoc networking.<\/li>\n<li><strong>Reduced outage risk:<\/strong> Central policies and consistent routing reduce change-related incidents.<\/li>\n<li><strong>Supports mergers and multi-environment growth:<\/strong> Easier to connect newly acquired networks or new business units.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Hub-and-spoke routing at scale:<\/strong> Avoid N\u00d7(N\u22121)\/2 connectivity growth inherent in full mesh designs.<\/li>\n<li><strong>Transitive connectivity (where supported):<\/strong> Connect on\u2011prem \u2194 cloud \u2194 other sites without building point-to-point links everywhere.<\/li>\n<li><strong>Route exchange orchestration:<\/strong> Central place to manage which routes are shared and with whom (feature specifics depend on your NCC capabilities\u2014verify in official docs).<\/li>\n<li><strong>Leverages Google Cloud\u2019s routing stack:<\/strong> Integrates with Cloud Router\/BGP, VPN, and Interconnect.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Central inventory:<\/strong> A hub provides a clear view of what\u2019s connected.<\/li>\n<li><strong>Change management:<\/strong> Add\/remove spokes predictably.<\/li>\n<li><strong>Easier troubleshooting:<\/strong> Standardized constructs simplify connectivity tests and incident response (often paired with Network Intelligence Center).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Segmentation by design:<\/strong> Use separate hubs or route exchange controls to limit which networks can talk.<\/li>\n<li><strong>Auditability:<\/strong> Control-plane actions are typically visible in <strong>Cloud Audit Logs<\/strong> (verify logs available for NCC resources in your environment).<\/li>\n<li><strong>Reduced \u201cshadow connectivity\u201d:<\/strong> Fewer ad hoc VPNs\/peerings.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Scales better than peering meshes:<\/strong> Especially when connecting many VPCs and many sites.<\/li>\n<li><strong>Works with high-throughput connectivity:<\/strong> Interconnect spokes can provide private high bandwidth links, while NCC organizes routing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose Network Connectivity Center when you have:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Multiple on-prem locations connecting to Google Cloud via VPN\/Interconnect<\/li>\n<li>Multiple VPC networks that need controlled connectivity<\/li>\n<li>A need for transitive routing and centralized connectivity governance<\/li>\n<li>A desire to reduce complexity of \u201chub routers\u201d you manage yourself<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When they should not choose it<\/h3>\n\n\n\n<p>Network Connectivity Center may not be the best fit if:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You only have <strong>one<\/strong> VPC and <strong>one<\/strong> on-prem site (a simple HA VPN or Interconnect + Cloud Router may be sufficient).<\/li>\n<li>You require <strong>advanced traffic inspection<\/strong> (you\u2019ll need separate security appliances or cloud firewalls; NCC is not a firewall).<\/li>\n<li>Your design depends on unsupported route policies or spoke types (verify NCC feature support first).<\/li>\n<li>You need direct service-to-service private publishing (consider <strong>Private Service Connect<\/strong> for producer\/consumer service connectivity).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Network Connectivity Center used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<p>Network Connectivity Center is common in industries with many sites and strict network controls:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Financial services (branch connectivity, segmentation, audit requirements)<\/li>\n<li>Retail (store networks to central apps)<\/li>\n<li>Healthcare (multi-site clinics, compliance-driven segmentation)<\/li>\n<li>Manufacturing (plants, OT\/IT separation, central analytics)<\/li>\n<li>Media\/entertainment (distributed production sites)<\/li>\n<li>Government\/public sector (multi-agency connectivity domains)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud platform teams building landing zones<\/li>\n<li>Network engineering teams modernizing WAN connectivity<\/li>\n<li>DevOps\/SRE teams operating multi-environment connectivity<\/li>\n<li>Security teams designing segmentation and connectivity governance<\/li>\n<li>Enterprise architects standardizing hybrid patterns<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Shared services (identity, logging, monitoring, CI\/CD)<\/li>\n<li>Centralized data platforms (data lakes, analytics)<\/li>\n<li>SAP and enterprise apps<\/li>\n<li>Kubernetes clusters spanning multiple environments<\/li>\n<li>Internal APIs consumed across networks<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Hybrid hub-and-spoke (on-prem \u2194 cloud)<\/li>\n<li>Multi-VPC hub-and-spoke (many VPCs, fewer peerings)<\/li>\n<li>Multi-region connectivity using regional attachments (VPN\/Interconnect) organized centrally<\/li>\n<li>Segmented hubs (prod hub, non-prod hub, partner hub)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Migrating a legacy MPLS + on-prem DMZ into Google Cloud with controlled connectivity<\/li>\n<li>Consolidating multiple VPN topologies into standardized NCC hubs<\/li>\n<li>Connecting many branch sites to cloud-based shared services<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production:<\/strong> NCC is typically used to enforce repeatable connectivity patterns with strong change control.<\/li>\n<li><strong>Dev\/test:<\/strong> Common when teams are prototyping hybrid connectivity or validating routing\/segmentation policies before production rollout.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Network Connectivity Center is typically a strong fit.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Central hub for many on-prem sites using HA VPN<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Dozens of branches need secure access to cloud workloads; mesh VPN is unmanageable.<\/li>\n<li><strong>Why NCC fits:<\/strong> Each site becomes a spoke; hub centralizes route exchange.<\/li>\n<li><strong>Example:<\/strong> 60 retail stores connect to a shared services VPC hosting inventory APIs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Central hub for Dedicated\/Partner Interconnect VLAN attachments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Multiple Interconnect VLAN attachments across regions need consistent routing and governance.<\/li>\n<li><strong>Why NCC fits:<\/strong> Attach VLAN attachments as spokes; manage route exchange centrally.<\/li>\n<li><strong>Example:<\/strong> Two Interconnect locations provide redundant connectivity for a data center to multiple cloud environments.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Connect third-party router appliances to Google Cloud for advanced routing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need specialized routing\/segmentation features not handled solely by basic cloud routing.<\/li>\n<li><strong>Why NCC fits:<\/strong> Router appliance spokes can integrate routing appliances into the hub model.<\/li>\n<li><strong>Example:<\/strong> A virtual router appliance terminates BGP and advertises segmented routes into NCC.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Multi-VPC connectivity without peering sprawl (where VPC spokes are supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> 20 VPCs need shared services; peering becomes complex and error-prone.<\/li>\n<li><strong>Why NCC fits:<\/strong> Hub-and-spoke connectivity replaces many peerings.<\/li>\n<li><strong>Example:<\/strong> Shared logging and CI\/CD VPC connects to many application VPCs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Controlled transitive routing (site A \u2194 site B via cloud)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Two sites must communicate, but you don\u2019t want to build site-to-site VPN directly.<\/li>\n<li><strong>Why NCC fits:<\/strong> NCC can enable transitive route exchange across spokes (subject to supported configuration).<\/li>\n<li><strong>Example:<\/strong> A DR site needs access to primary site services through cloud connectivity.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Segmented connectivity domains (prod vs non-prod)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Production and non-production must never exchange routes.<\/li>\n<li><strong>Why NCC fits:<\/strong> Use separate hubs (or route control features if available) to enforce segmentation.<\/li>\n<li><strong>Example:<\/strong> Shared tooling exists in non-prod, but prod uses a separate hub and separate connectivity.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Gradual migration from legacy WAN to cloud-based connectivity<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You must migrate in phases while keeping sites connected.<\/li>\n<li><strong>Why NCC fits:<\/strong> Add spokes incrementally; central hub simplifies phased routing changes.<\/li>\n<li><strong>Example:<\/strong> Over 12 months, each region migrates to Interconnect spokes while older VPN spokes remain.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Centralized governance for network changes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Multiple teams create VPNs\/peerings independently causing outages.<\/li>\n<li><strong>Why NCC fits:<\/strong> Platform team controls hub\/spoke attachment via IAM and change process.<\/li>\n<li><strong>Example:<\/strong> Only the network platform group can attach spokes to the production hub.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Standard pattern for M&amp;A network integration<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Newly acquired company networks must connect quickly but safely.<\/li>\n<li><strong>Why NCC fits:<\/strong> Attach new connectivity as isolated spokes; gradually open routes.<\/li>\n<li><strong>Example:<\/strong> Acquire a subsidiary; initially only allow connectivity to identity and email services.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Multi-region hybrid architecture with consistent routing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Different regions have different connectivity methods; routing becomes inconsistent.<\/li>\n<li><strong>Why NCC fits:<\/strong> Common hub constructs and standardized spoke attachments reduce drift.<\/li>\n<li><strong>Example:<\/strong> US uses Dedicated Interconnect; EU uses Partner Interconnect; APAC uses HA VPN\u2014managed centrally.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Central hub for shared services + data platform access<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Many application networks need access to a central data platform with least privilege routing.<\/li>\n<li><strong>Why NCC fits:<\/strong> Use hub route exchange controls (where supported) and segmentation boundaries.<\/li>\n<li><strong>Example:<\/strong> Only selected application spokes import routes to BigQuery connector services and internal APIs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Operational visibility and troubleshooting standardization<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Troubleshooting many tunnels\/attachments is slow and inconsistent.<\/li>\n<li><strong>Why NCC fits:<\/strong> NCC provides a consistent model to attach networks; pair with Network Intelligence Center for tests\/topology.<\/li>\n<li><strong>Example:<\/strong> Standard runbooks for diagnosing route advertisement vs firewall vs tunnel issues.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<blockquote>\n<p>Note: Feature availability can differ by spoke type and release track. Always confirm supported spoke types, limits, and routing behaviors in the official documentation.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Hub-and-spoke connectivity model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Lets you create hubs and attach spokes to build a structured connectivity topology.<\/li>\n<li><strong>Why it matters:<\/strong> Replaces unmanageable full-mesh connectivity.<\/li>\n<li><strong>Practical benefit:<\/strong> Adding a new site often means adding one spoke, not configuring peerings to every other network.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Hub\/spoke scoping and supported attachments vary\u2014verify in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Spoke types for hybrid connectivity<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Supports attaching different connectivity endpoints (commonly VPN, Interconnect VLAN attachments, router appliances; sometimes VPC spokes depending on feature set).<\/li>\n<li><strong>Why it matters:<\/strong> A single operating model across different transport types.<\/li>\n<li><strong>Practical benefit:<\/strong> Consistent governance and change process for new connectivity.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Each spoke type has prerequisites (Cloud Router\/BGP, specific regions, redundancy expectations).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Centralized route exchange (transitive routing)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Exchanges routes between spokes through the hub so networks can communicate transitively.<\/li>\n<li><strong>Why it matters:<\/strong> Enables on-prem \u2194 VPC \u2194 on-prem patterns without extra point-to-point links.<\/li>\n<li><strong>Practical benefit:<\/strong> Fewer tunnels and simpler routing domains.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Overlapping IP ranges and route conflicts can prevent intended propagation. Some routing control features may require specific hub configurations\u2014verify in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Routing policy controls (route tables \/ selective exchange)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> In supported configurations, lets you control which spokes can exchange which routes (for segmentation).<\/li>\n<li><strong>Why it matters:<\/strong> Not all networks should see all routes.<\/li>\n<li><strong>Practical benefit:<\/strong> Implement \u201cshared services\u201d patterns safely.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Exact mechanisms (route tables, associations, filters) depend on your NCC capabilities\u2014verify in official docs and test in non-prod.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integration with Cloud Router and BGP<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Uses Cloud Router for dynamic routing for VPN\/Interconnect\/router appliances.<\/li>\n<li><strong>Why it matters:<\/strong> Dynamic routing is the foundation for scalable hybrid connectivity.<\/li>\n<li><strong>Practical benefit:<\/strong> Faster failover and simpler route management than static routes.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> BGP session limits, route advertisement limits, and timer behaviors still apply.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Centralized connectivity operations (control plane)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides an API\/console surface to manage attachments and connectivity domains.<\/li>\n<li><strong>Why it matters:<\/strong> Enables Infrastructure-as-Code and standardized operations.<\/li>\n<li><strong>Practical benefit:<\/strong> You can treat connectivity as code using Terraform or gcloud (where supported).<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Underlying services (VPN, Interconnect) still have their own operational lifecycle and monitoring.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Works with Google Cloud\u2019s global network (via underlying transports)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Organizes connectivity that ultimately traverses Google\u2019s network using VPN\/Interconnect.<\/li>\n<li><strong>Why it matters:<\/strong> Global reach and consistent performance model.<\/li>\n<li><strong>Practical benefit:<\/strong> Hybrid traffic can take advantage of Google\u2019s backbone (especially with Interconnect).<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Data path characteristics depend on the underlying transport and region pair; egress charges still apply.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM-based governance<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Uses Google Cloud IAM to control who can create hubs\/spokes and attach resources.<\/li>\n<li><strong>Why it matters:<\/strong> Connectivity changes are high risk.<\/li>\n<li><strong>Practical benefit:<\/strong> Enforce least privilege and approval workflows.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> You often need permissions on both NCC resources and the underlying networking resources.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>Network Connectivity Center provides a central \u201chub\u201d where multiple \u201cspokes\u201d attach. Spokes represent connectivity endpoints like VPN tunnels, Interconnect VLAN attachments, router appliances, and (in supported cases) VPC networks. Routes learned from one spoke can be propagated to other spokes based on hub configuration.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Control flow vs data flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane (NCC):<\/strong><\/li>\n<li>You define hubs\/spokes and how routes should be exchanged.<\/li>\n<li>NCC coordinates routing exchange policies.<\/li>\n<li><strong>Data plane (underlying services):<\/strong><\/li>\n<li>Actual packets flow over VPN tunnels, Interconnect, and VPC routing.<\/li>\n<li>Cloud Router participates in BGP for dynamic route exchange for VPN\/Interconnect\/router appliances.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<p>Common integrations include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud VPN \/ HA VPN<\/strong>: Encrypted connectivity from sites to Google Cloud.<\/li>\n<li><strong>Cloud Interconnect (Dedicated\/Partner)<\/strong>: Private high-throughput connectivity.<\/li>\n<li><strong>Cloud Router<\/strong>: BGP for dynamic routing to VPN\/Interconnect\/router appliances.<\/li>\n<li><strong>VPC networks<\/strong>: Where your workloads run; may be attached as spokes depending on current NCC support.<\/li>\n<li><strong>Network Intelligence Center<\/strong>: Connectivity tests and topology mapping for troubleshooting.<\/li>\n<li><strong>Cloud Logging \/ Cloud Audit Logs<\/strong>: Governance and auditing of configuration changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<p>Your NCC design typically depends on:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>VPC networks and subnets<\/li>\n<li>Cloud Router (for BGP-based spokes)<\/li>\n<li>HA VPN gateways and tunnels (for VPN spokes)<\/li>\n<li>Interconnect attachments (for Interconnect spokes)<\/li>\n<li>Firewall rules, routes, and possibly Cloud NAT (for workload access patterns)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Administration access<\/strong> is governed by <strong>Google Cloud IAM<\/strong>.<\/li>\n<li><strong>Data plane security<\/strong> (encryption, integrity, segmentation) depends on:<\/li>\n<li>VPN encryption for Cloud VPN<\/li>\n<li>Private nature of Interconnect (note: Interconnect traffic is not encrypted by default; you can encrypt at higher layers if required)<\/li>\n<li>VPC firewall rules and network policies<\/li>\n<li>Any router appliances you deploy<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Routing is fundamental.<\/strong> A correct NCC deployment is mostly about:<\/li>\n<li>Non-overlapping CIDR planning<\/li>\n<li>Route advertisement boundaries<\/li>\n<li>Avoiding asymmetric routing<\/li>\n<li>Ensuring firewall rules allow intended traffic<\/li>\n<li><strong>NCC doesn\u2019t replace firewalls.<\/strong> Use:<\/li>\n<li>VPC firewall rules<\/li>\n<li>Network Firewall policies (where applicable)<\/li>\n<li>Third-party or Cloud NGFW solutions for inspection<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Monitor the <strong>underlying<\/strong> connectivity:<\/li>\n<li>VPN tunnel status, BGP session state (Cloud Router)<\/li>\n<li>Interconnect attachment status and capacity<\/li>\n<li>VPC Flow Logs for actual traffic verification<\/li>\n<li>Audit NCC configuration changes using <strong>Cloud Audit Logs<\/strong>.<\/li>\n<li>Use Network Intelligence Center for connectivity tests and topology (recommended for ops).<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Simple architecture diagram (conceptual)<\/h4>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  OnPrem[On\u2011prem \/ Branch Sites] --&gt;|HA VPN \/ Interconnect| Spoke1[Spoke: VPN\/Interconnect]\n  VPC1[VPC Network A] --&gt; Spoke2[Spoke: VPC (if supported)]\n  VPC2[VPC Network B] --&gt; Spoke3[Spoke: VPC (if supported)]\n\n  Spoke1 --&gt; Hub[Network Connectivity Center Hub]\n  Spoke2 --&gt; Hub\n  Spoke3 --&gt; Hub\n\n  Hub --&gt;|Route exchange| Spoke1\n  Hub --&gt;|Route exchange| Spoke2\n  Hub --&gt;|Route exchange| Spoke3\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">Production-style architecture diagram (hybrid + segmentation)<\/h4>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Sites[On\u2011prem Sites]\n    DC1[Primary DC]\n    DC2[DR DC]\n    Branches[Branches]\n  end\n\n  subgraph GCP[Google Cloud]\n    subgraph Prod[Prod Environment]\n      HubProd[NCC Hub: prod-hub]\n      VPCProd1[Prod VPC: payments]\n      VPCProd2[Prod VPC: core-services]\n      InterconnectSpoke[Spoke: Interconnect VLAN attachments]\n      VPNSpoke[Spoke: HA VPN (backup)]\n    end\n\n    subgraph NonProd[Non-Prod Environment]\n      HubNonProd[NCC Hub: nonprod-hub]\n      VPCDev[Dev VPC]\n      VPCTest[Test VPC]\n    end\n\n    Sec[Security Controls:\\nFirewall rules \/ policies\\n(plus optional NGFW)]\n    Obs[Operations:\\nCloud Logging\\nCloud Monitoring\\nNetwork Intelligence Center]\n  end\n\n  DC1 --&gt;|Dedicated\/Partner Interconnect| InterconnectSpoke --&gt; HubProd\n  DC1 --&gt;|HA VPN backup| VPNSpoke --&gt; HubProd\n  DC2 --&gt;|HA VPN| VPNSpoke\n  Branches --&gt;|HA VPN| VPNSpoke\n\n  VPCProd1 --&gt; HubProd\n  VPCProd2 --&gt; HubProd\n\n  VPCDev --&gt; HubNonProd\n  VPCTest --&gt; HubNonProd\n\n  HubProd --&gt; Sec\n  HubNonProd --&gt; Sec\n  HubProd --&gt; Obs\n  HubNonProd --&gt; Obs\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/project requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A Google Cloud project with <strong>Billing enabled<\/strong>.<\/li>\n<li>An Organization is strongly recommended for enterprise governance (not strictly required for basic labs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>You typically need:\n&#8211; Permissions to manage Network Connectivity Center:\n  &#8211; Example roles (verify exact role names in IAM):\n    &#8211; <code>roles\/networkconnectivity.admin<\/code> (admin)\n    &#8211; <code>roles\/networkconnectivity.viewer<\/code> (read-only)\n&#8211; Permissions to create and manage underlying network resources:\n  &#8211; VPC networks\/subnets\/firewall rules: <code>roles\/compute.networkAdmin<\/code> (or narrower custom role)\n  &#8211; VM creation for test instances: <code>roles\/compute.instanceAdmin.v1<\/code>\n  &#8211; Service account permissions: <code>roles\/iam.serviceAccountUser<\/code><\/p>\n\n\n\n<p>Principle: give <strong>least privilege<\/strong> and separate duties (network platform vs app teams).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>NCC itself may have per-spoke and\/or per-data-processing charges (see Pricing section).<\/li>\n<li>Underlying components (VMs, VPN gateways, Cloud Router, Interconnect, egress) generate costs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Optional but recommended:<\/li>\n<li><strong>Google Cloud CLI (<code>gcloud<\/code>)<\/strong>: https:\/\/cloud.google.com\/sdk\/docs\/install<\/li>\n<li>For verification tests:<\/li>\n<li>SSH client<\/li>\n<li>Basic networking tools (ping, traceroute)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Underlying services are regional (VPN gateways, Cloud Routers, VLAN attachments).<\/li>\n<li>NCC availability and spoke type support can vary by region.<\/li>\n<li><strong>Verify current region support<\/strong> in the official docs before production rollout.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<p>You may encounter limits on:\n&#8211; Number of hubs\/spokes per project\n&#8211; Number of routes exchanged\/propagated\n&#8211; BGP session limits (Cloud Router)\n&#8211; VPN tunnel counts and throughput limits\n&#8211; Interconnect attachment counts and capacity<\/p>\n\n\n\n<p>Always check the current limits here (and in NCC docs):\n&#8211; Quotas page in the console: <strong>IAM &amp; Admin \u2192 Quotas<\/strong>\n&#8211; NCC documentation for service-specific limits (verify in official docs)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services\/APIs<\/h3>\n\n\n\n<p>Enable relevant APIs:\n&#8211; Network Connectivity API (NCC)\n&#8211; Compute Engine API (for VPCs\/VMs)\n&#8211; Cloud Resource Manager API (often needed for IAM\/project operations)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Official pricing (start here and verify current SKUs):<br\/>\nhttps:\/\/cloud.google.com\/network-connectivity-center\/pricing<\/p>\n\n\n\n<p>Pricing calculator (to model full solution cost):<br\/>\nhttps:\/\/cloud.google.com\/products\/calculator<\/p>\n\n\n\n<blockquote>\n<p>Pricing changes over time and can differ by region and SKU. Do not rely on blog posts for exact numbers\u2014use the official pricing page and calculator.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (typical model)<\/h3>\n\n\n\n<p>Network Connectivity Center pricing commonly involves some combination of:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Spoke attachment charges<\/strong><br\/>\n   &#8211; A recurring cost per spoke (often hourly).<\/li>\n<li><strong>Data processing \/ traffic through NCC<\/strong><br\/>\n   &#8211; A per\u2011GB cost for traffic that traverses connectivity enabled by NCC (in some models).<\/li>\n<li><strong>Underlying connectivity costs (separate)<\/strong>\n   &#8211; HA VPN charges (tunnel and\/or gateway)\n   &#8211; Cloud Router charges\n   &#8211; Interconnect port and VLAN attachment charges\n   &#8211; Standard network egress charges (internet egress, inter-region egress, etc.)<\/li>\n<\/ol>\n\n\n\n<p>Because SKUs and definitions can evolve, <strong>confirm which NCC traffic is billable and how it\u2019s measured<\/strong> in the pricing docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>NCC generally does <strong>not<\/strong> advertise a broad \u201cfree tier\u201d comparable to some serverless products.<\/li>\n<li>Some customers may have limited free usage for trials\/promotions, but <strong>assume billable<\/strong> and verify.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Key cost drivers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Number of spokes<\/strong> attached to hubs<\/li>\n<li><strong>Traffic volume<\/strong> between spokes (GB processed, if applicable)<\/li>\n<li><strong>Choice of transport<\/strong>:<\/li>\n<li>VPN (lower fixed costs, potentially lower throughput)<\/li>\n<li>Interconnect (higher fixed cost, high throughput\/low latency)<\/li>\n<li><strong>Egress charges<\/strong>:<\/li>\n<li>Inter-region traffic<\/li>\n<li>Traffic to\/from on-prem (depending on setup)<\/li>\n<li><strong>VM and appliance costs<\/strong> if you use router appliances<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs to plan for<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>High Availability requirements<\/strong>:<\/li>\n<li>HA VPN typically uses multiple tunnels\/gateways; redundancy multiplies components.<\/li>\n<li>Redundant Interconnect requires dual attachments and diverse paths.<\/li>\n<li><strong>Observability costs<\/strong>:<\/li>\n<li>VPC Flow Logs (log volume can be large)<\/li>\n<li>Logging retention<\/li>\n<li><strong>Security controls<\/strong>:<\/li>\n<li>If you insert traffic inspection appliances, you add compute\/licensing costs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<p>Even if NCC simplifies routing, <strong>data transfer pricing still matters<\/strong>:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Traffic between regions can incur <strong>inter-region egress<\/strong>.<\/li>\n<li>Traffic leaving Google Cloud to on-prem may have costs depending on service and direction (verify current network pricing).<\/li>\n<li>Interconnect pricing differs for Dedicated vs Partner Interconnect.<\/li>\n<\/ul>\n\n\n\n<p>Network pricing overview (verify current):<br\/>\nhttps:\/\/cloud.google.com\/vpc\/network-pricing<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Minimize unnecessary spoke count (don\u2019t attach networks \u201cjust in case\u201d).<\/li>\n<li>Use <strong>segmentation<\/strong> to avoid unintended cross-network traffic (which can increase billable processing and egress).<\/li>\n<li>Keep high\u2011churn dev\/test environments on a separate hub and shut down nonessential connectivity.<\/li>\n<li>Prefer <strong>regional locality<\/strong> where possible to reduce inter-region egress.<\/li>\n<li>If using router appliances, right-size instances and consider committed use discounts (where applicable).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual)<\/h3>\n\n\n\n<p>A \u201cstarter lab\u201d cost is typically dominated by:\n&#8211; 2 small VM instances for testing\n&#8211; Minimal logging (Flow Logs off)\n&#8211; Possibly NCC spoke charges (if billed)\n&#8211; Minimal data transfer<\/p>\n\n\n\n<p>Because exact NCC and VM pricing is region-dependent and changes over time, use the calculator and keep the lab duration short (1\u20132 hours). <strong>Do not leave resources running overnight<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For production, plan a cost model that includes:\n&#8211; Number of hubs (prod, non-prod, partner)\n&#8211; Spoke count (sites, VPCs, attachments)\n&#8211; Expected east-west traffic volume across spokes\n&#8211; Underlying transport mix (VPN vs Interconnect)\n&#8211; Logging\/monitoring strategy and retention\n&#8211; HA topology (redundant tunnels\/attachments\/routers)\n&#8211; Growth over 12\u201336 months<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab demonstrates a practical, beginner-friendly pattern: <strong>connect two VPC networks using Network Connectivity Center<\/strong> and validate private IP connectivity between test VMs.<\/p>\n\n\n\n<blockquote>\n<p>Important: The exact UI labels and spoke options can vary by release and organization policy. If you do not see \u201cVPC spoke\u201d as an option in your environment, use this lab as a conceptual walkthrough and switch to a VPN\/Interconnect spoke-based lab instead (verify current supported spoke types in official docs).<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Create:\n&#8211; Two isolated VPC networks (<code>vpc-a<\/code>, <code>vpc-b<\/code>)\n&#8211; One Network Connectivity Center <strong>hub<\/strong>\n&#8211; Two <strong>spokes<\/strong> (one per VPC, if supported)\n&#8211; Verify that a VM in <code>vpc-a<\/code> can reach a VM in <code>vpc-b<\/code> using <strong>private IP<\/strong><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Prepare the project and enable APIs\n2. Create two VPC networks and subnets\n3. Create two test VMs (one in each VPC)\n4. Configure firewall rules for ICMP\/SSH\n5. Create an NCC hub\n6. Attach both VPCs as spokes (or the nearest equivalent supported spoke type)\n7. Validate connectivity\n8. Clean up everything<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set up your project, region, and APIs<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Select or create a Google Cloud project.<\/li>\n<li>Set a default region (example: <code>us-central1<\/code>)\u2014choose a region that supports the resources you need.<\/li>\n<\/ol>\n\n\n\n<p>Enable APIs (Console):\n&#8211; Go to <strong>APIs &amp; Services \u2192 Library<\/strong>\n&#8211; Enable:\n  &#8211; <strong>Network Connectivity API<\/strong>\n  &#8211; <strong>Compute Engine API<\/strong><\/p>\n\n\n\n<p>Optional CLI setup:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud auth login\ngcloud config set project YOUR_PROJECT_ID\ngcloud config set compute\/region us-central1\ngcloud config set compute\/zone us-central1-a\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; APIs enabled\n&#8211; <code>gcloud<\/code> points to the correct project\/region\/zone<\/p>\n\n\n\n<p>Verification:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services list --enabled | grep -E \"networkconnectivity|compute\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create two VPC networks and subnets<\/h3>\n\n\n\n<p>Create two custom-mode VPCs (so you control subnets):<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>vpc-a<\/code> with subnet <code>subnet-a<\/code> CIDR <code>10.10.0.0\/24<\/code> in <code>us-central1<\/code><\/li>\n<li><code>vpc-b<\/code> with subnet <code>subnet-b<\/code> CIDR <code>10.20.0.0\/24<\/code> in <code>us-central1<\/code><\/li>\n<\/ul>\n\n\n\n<p>Console path:\n&#8211; <strong>VPC network \u2192 VPC networks \u2192 Create VPC network<\/strong>\n&#8211; Choose <strong>Custom<\/strong>\n&#8211; Add subnet with the CIDR above<\/p>\n\n\n\n<p>Optional CLI:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute networks create vpc-a --subnet-mode=custom\ngcloud compute networks create vpc-b --subnet-mode=custom\n\ngcloud compute networks subnets create subnet-a \\\n  --network=vpc-a --range=10.10.0.0\/24 --region=us-central1\n\ngcloud compute networks subnets create subnet-b \\\n  --network=vpc-b --range=10.20.0.0\/24 --region=us-central1\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; Two isolated VPCs with non-overlapping IP ranges<\/p>\n\n\n\n<p>Verification:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute networks list\ngcloud compute networks subnets list --regions=us-central1\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create test VMs in each VPC<\/h3>\n\n\n\n<p>Create:\n&#8211; <code>vm-a<\/code> in <code>subnet-a<\/code> (private IP like <code>10.10.0.x<\/code>)\n&#8211; <code>vm-b<\/code> in <code>subnet-b<\/code> (private IP like <code>10.20.0.x<\/code>)<\/p>\n\n\n\n<p>Console path:\n&#8211; <strong>Compute Engine \u2192 VM instances \u2192 Create instance<\/strong>\n&#8211; Networking:\n  &#8211; Choose the correct VPC\/subnet\n&#8211; Use small machine types to reduce cost.\n&#8211; You can use a standard public image (Debian\/Ubuntu).<\/p>\n\n\n\n<p>Optional CLI:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances create vm-a \\\n  --zone=us-central1-a \\\n  --subnet=subnet-a \\\n  --machine-type=e2-micro \\\n  --image-family=debian-12 \\\n  --image-project=debian-cloud\n\ngcloud compute instances create vm-b \\\n  --zone=us-central1-a \\\n  --subnet=subnet-b \\\n  --machine-type=e2-micro \\\n  --image-family=debian-12 \\\n  --image-project=debian-cloud\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; Two VMs running, each reachable by SSH (depending on your access method)\n&#8211; Each VM has a private IP in its own subnet<\/p>\n\n\n\n<p>Verification:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances list --filter=\"name:(vm-a vm-b)\" \\\n  --format=\"table(name,zone,networkInterfaces[0].networkIP)\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Add firewall rules to allow testing traffic<\/h3>\n\n\n\n<p>You need to allow:\n&#8211; SSH (tcp:22) from your admin IP range (or use IAP-based SSH to avoid opening SSH broadly)\n&#8211; ICMP between the two subnet CIDRs so ping tests work<\/p>\n\n\n\n<p>A simple lab firewall approach (be cautious in production):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute firewall-rules create allow-ssh-iap \\\n  --network=vpc-a \\\n  --allow=tcp:22 \\\n  --source-ranges=35.235.240.0\/20 \\\n  --direction=INGRESS \\\n  --description=\"Allow SSH from IAP to vm-a\"\n\ngcloud compute firewall-rules create allow-ssh-iap \\\n  --network=vpc-b \\\n  --allow=tcp:22 \\\n  --source-ranges=35.235.240.0\/20 \\\n  --direction=INGRESS \\\n  --description=\"Allow SSH from IAP to vm-b\"\n<\/code><\/pre>\n\n\n\n<p>If you will SSH from your own IP instead, replace the source range accordingly.<\/p>\n\n\n\n<p>Allow ICMP between subnets:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute firewall-rules create allow-icmp-from-peer \\\n  --network=vpc-a \\\n  --allow=icmp \\\n  --source-ranges=10.20.0.0\/24 \\\n  --direction=INGRESS\n\ngcloud compute firewall-rules create allow-icmp-from-peer \\\n  --network=vpc-b \\\n  --allow=icmp \\\n  --source-ranges=10.10.0.0\/24 \\\n  --direction=INGRESS\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; Firewall permits ICMP between the subnets (once routing exists)\n&#8211; SSH access is possible via IAP (recommended for labs) or your chosen method<\/p>\n\n\n\n<p>Verification:\n&#8211; In the console, check <strong>VPC network \u2192 Firewall<\/strong> for the rules.\n&#8211; Ensure rules are in the correct VPC (rules are per VPC).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Create a Network Connectivity Center hub<\/h3>\n\n\n\n<p>Console path:\n&#8211; <strong>Network Connectivity Center \u2192 Hubs \u2192 Create hub<\/strong><\/p>\n\n\n\n<p>Choose:\n&#8211; Hub name: <code>lab-hub<\/code>\n&#8211; Description: \u201cLab hub connecting vpc-a and vpc-b\u201d\n&#8211; Any required routing\/association defaults (use defaults for a beginner lab)<\/p>\n\n\n\n<p>Optional CLI (syntax can change; verify with help in your environment):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud network-connectivity hubs create lab-hub --description=\"Lab hub\"\n# If flags differ, run:\ngcloud network-connectivity hubs create --help\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; A hub exists and is ready to accept spokes<\/p>\n\n\n\n<p>Verification (CLI):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud network-connectivity hubs list\ngcloud network-connectivity hubs describe lab-hub\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Create spokes and attach the VPC networks (if supported)<\/h3>\n\n\n\n<p>Console path:\n&#8211; <strong>Network Connectivity Center \u2192 Spokes \u2192 Create spoke<\/strong>\n&#8211; Spoke name: <code>spoke-a<\/code>\n&#8211; Hub: <code>lab-hub<\/code>\n&#8211; Spoke type: choose <strong>VPC network<\/strong> (if available)\n&#8211; Select VPC: <code>vpc-a<\/code>\n&#8211; Configure route export\/import settings as prompted (use defaults for the lab)<\/p>\n\n\n\n<p>Repeat for:\n&#8211; Spoke name: <code>spoke-b<\/code>\n&#8211; VPC: <code>vpc-b<\/code><\/p>\n\n\n\n<p>If your environment does <strong>not<\/strong> offer VPC network spokes:\n&#8211; Stop here and switch to a supported spoke type (VPN or router appliance) and adapt the lab.\n&#8211; Official docs will show current spoke types and setup steps:\n  https:\/\/cloud.google.com\/network-connectivity-center\/docs<\/p>\n\n\n\n<p>Optional CLI (highly dependent on current API; verify flags):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud network-connectivity spokes create spoke-a --hub=lab-hub\ngcloud network-connectivity spokes create spoke-b --hub=lab-hub\n# Then attach VPCs via the supported flags (verify via --help).\ngcloud network-connectivity spokes create --help\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; <code>vpc-a<\/code> and <code>vpc-b<\/code> are attached to <code>lab-hub<\/code> as spokes\n&#8211; Routes for each subnet become available for exchange (subject to config)<\/p>\n\n\n\n<p>Verification:\n&#8211; In NCC console, confirm both spokes show <strong>Active\/Ready<\/strong>.\n&#8211; Check effective routes in each VPC.<\/p>\n\n\n\n<p>Check routes for <code>vm-a<\/code> and <code>vm-b<\/code> (Console):\n&#8211; <strong>VPC network \u2192 Routes<\/strong>\n&#8211; Filter by network <code>vpc-a<\/code> and look for a route to <code>10.20.0.0\/24<\/code>\n&#8211; Filter by network <code>vpc-b<\/code> and look for a route to <code>10.10.0.0\/24<\/code><\/p>\n\n\n\n<p>CLI route check (works for many route sources, but may not show all dynamic sources uniformly\u2014still useful):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute routes list --filter=\"network:vpc-a AND destRange:10.20.0.0\/24\"\ngcloud compute routes list --filter=\"network:vpc-b AND destRange:10.10.0.0\/24\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Test private connectivity between VMs<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Find private IPs:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">VM_A_IP=$(gcloud compute instances describe vm-a --zone=us-central1-a --format=\"value(networkInterfaces[0].networkIP)\")\nVM_B_IP=$(gcloud compute instances describe vm-b --zone=us-central1-a --format=\"value(networkInterfaces[0].networkIP)\")\necho \"vm-a: $VM_A_IP\"\necho \"vm-b: $VM_B_IP\"\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"2\">\n<li>SSH to <code>vm-a<\/code> (use IAP if configured, or standard SSH if allowed):<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute ssh vm-a --zone=us-central1-a --tunnel-through-iap\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"3\">\n<li>From <code>vm-a<\/code>, ping <code>vm-b<\/code> private IP:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">ping -c 5 VM_B_PRIVATE_IP\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; Pings succeed with low latency\n&#8211; This confirms routing + firewall rules allow ICMP<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Spokes<\/strong> show ready\/active in NCC.<\/li>\n<li><strong>Routes<\/strong> exist:<\/li>\n<li><code>vpc-a<\/code> can route to <code>10.20.0.0\/24<\/code><\/li>\n<li><code>vpc-b<\/code> can route to <code>10.10.0.0\/24<\/code><\/li>\n<li><strong>Firewall<\/strong> allows ICMP from the opposite CIDR.<\/li>\n<li><strong>Ping<\/strong> from <code>vm-a<\/code> to <code>vm-b<\/code> private IP works.<\/li>\n<\/ul>\n\n\n\n<p>Optional deeper validation:\n&#8211; Run a TCP test (e.g., <code>nc<\/code>) if you add firewall rules for a test port.\n&#8211; Enable VPC Flow Logs temporarily to confirm flows (be mindful of log cost).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and fixes:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>No route to the other subnet<\/strong>\n   &#8211; Confirm both spokes are attached to the <strong>same hub<\/strong>.\n   &#8211; Confirm route exchange\/import\/export settings in NCC.\n   &#8211; Check if your org policy restricts route export\/import.\n   &#8211; Verify that VPC spokes are supported in your environment\/region.<\/p>\n<\/li>\n<li>\n<p><strong>Ping fails but routes exist<\/strong>\n   &#8211; Check firewall rules in both VPCs (ICMP allowed from peer CIDR).\n   &#8211; Confirm VM OS firewall (iptables\/ufw) isn\u2019t blocking ICMP.\n   &#8211; Confirm you\u2019re pinging the correct <strong>private<\/strong> IP.<\/p>\n<\/li>\n<li>\n<p><strong>Spoke stuck in provisioning<\/strong>\n   &#8211; Ensure the Network Connectivity API is enabled.\n   &#8211; Check IAM: you need NCC admin permissions plus rights on the attached resources.\n   &#8211; Review Cloud Audit Logs for denied permissions.<\/p>\n<\/li>\n<li>\n<p><strong>SSH access fails<\/strong>\n   &#8211; If using IAP, ensure:<\/p>\n<ul>\n<li>You used <code>--tunnel-through-iap<\/code><\/li>\n<li>Your user has IAP permissions (verify: <code>roles\/iap.tunnelResourceAccessor<\/code>)<\/li>\n<li>Firewall allows SSH from IAP IP range <code>35.235.240.0\/20<\/code><\/li>\n<li>Alternatively, use serial console access for debugging.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing costs, delete resources in this order:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Delete NCC spokes<\/li>\n<li>Delete NCC hub<\/li>\n<li>Delete VMs<\/li>\n<li>Delete firewall rules<\/li>\n<li>Delete subnets and VPCs (or delete VPCs directly if they have no dependent resources)<\/li>\n<\/ol>\n\n\n\n<p>CLI cleanup example:<\/p>\n\n\n\n<pre><code class=\"language-bash\"># NCC (verify commands\/flags in your environment)\ngcloud network-connectivity spokes delete spoke-a --quiet\ngcloud network-connectivity spokes delete spoke-b --quiet\ngcloud network-connectivity hubs delete lab-hub --quiet\n\n# VMs\ngcloud compute instances delete vm-a vm-b --zone=us-central1-a --quiet\n\n# Firewall rules (adjust names if you used different ones)\ngcloud compute firewall-rules delete allow-icmp-from-peer --quiet || true\ngcloud compute firewall-rules delete allow-ssh-iap --quiet || true\n\n# Subnets and networks\ngcloud compute networks subnets delete subnet-a --region=us-central1 --quiet\ngcloud compute networks subnets delete subnet-b --region=us-central1 --quiet\ngcloud compute networks delete vpc-a --quiet\ngcloud compute networks delete vpc-b --quiet\n<\/code><\/pre>\n\n\n\n<p>If deletion fails, it\u2019s usually because a dependent resource still exists (routes, forwarding rules, connectors, etc.). The error message will name the blocker.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Plan IP addressing early:<\/strong> Avoid overlapping CIDRs across all networks that may connect via NCC. Overlaps are one of the most common causes of route conflicts and blocked propagation.<\/li>\n<li><strong>Design segmentation intentionally:<\/strong><\/li>\n<li>Separate hubs for prod\/non-prod\/partner is often simpler than complex conditional policies.<\/li>\n<li>If using route tables\/associations, document them like you would firewall rules.<\/li>\n<li><strong>Prefer dynamic routing for hybrid:<\/strong> Use Cloud Router\/BGP for VPN and Interconnect spokes to support failover and scale.<\/li>\n<li><strong>Avoid \u201caccidental transit\u201d:<\/strong> Ensure that only intended spokes can exchange routes; don\u2019t attach sensitive networks to broad hubs without segmentation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Separate duties:<\/strong> Network platform team controls hubs\/spokes; app teams control their VPC workloads.<\/li>\n<li><strong>Least privilege:<\/strong> Use viewer roles for most users; restrict create\/update\/delete on NCC resources tightly.<\/li>\n<li><strong>Use change control:<\/strong> Connectivity changes should follow approvals and maintenance windows where appropriate.<\/li>\n<li><strong>Audit routinely:<\/strong> Review Cloud Audit Logs for NCC and underlying network changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Right-size connectivity:<\/strong> Don\u2019t attach every environment everywhere; attach what you need.<\/li>\n<li><strong>Keep dev\/test lean:<\/strong> Separate hubs and shut down ephemeral environments quickly.<\/li>\n<li><strong>Measure traffic patterns:<\/strong> High east-west traffic between spokes can increase overall network costs (including egress\/inter-region).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Use Interconnect for high throughput\/low jitter needs.<\/strong><\/li>\n<li><strong>Keep traffic regional when possible<\/strong> to reduce latency and inter-region costs.<\/li>\n<li><strong>Test failover:<\/strong> For VPN and Interconnect, validate behavior under link failure and route withdrawal.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Design redundancy:<\/strong><\/li>\n<li>HA VPN with recommended redundancy<\/li>\n<li>Dual Interconnect attachments and diverse paths<\/li>\n<li><strong>Avoid single points:<\/strong> Don\u2019t rely on one Cloud Router, one tunnel, or one attachment for critical paths.<\/li>\n<li><strong>Document dependencies:<\/strong> NCC depends on underlying resources\u2014monitor them.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Standard naming:<\/strong> Include env\/region\/function in hub and spoke names.<\/li>\n<li><strong>Use labels\/tags:<\/strong> Apply consistent labels for cost allocation and inventory.<\/li>\n<li><strong>Create runbooks:<\/strong> Include checks for routes, BGP session state, tunnel status, firewall, and Flow Logs.<\/li>\n<li><strong>Use Network Intelligence Center<\/strong> for connectivity tests and topology in troubleshooting workflows.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<p>A practical naming scheme:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Hubs: <code>hub-&lt;env&gt;-&lt;domain&gt;<\/code> (e.g., <code>hub-prod-shared<\/code>, <code>hub-nonprod-shared<\/code>)<\/li>\n<li>Spokes: <code>spoke-&lt;type&gt;-&lt;siteOrVPC&gt;-&lt;region&gt;<\/code> (e.g., <code>spoke-vpn-branch17-uscentral1<\/code>)<\/li>\n<\/ul>\n\n\n\n<p>Label examples:\n&#8211; <code>env=prod|nonprod<\/code>\n&#8211; <code>owner=net-platform<\/code>\n&#8211; <code>cost_center=...<\/code>\n&#8211; <code>connectivity_domain=shared|partner|restricted<\/code><\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Network Connectivity Center is configured via <strong>IAM-controlled APIs<\/strong>.<\/li>\n<li>Use:<\/li>\n<li>Organization policies (if available) to restrict who can create\/attach connectivity resources.<\/li>\n<li>Custom roles if built-in roles are too broad.<\/li>\n<\/ul>\n\n\n\n<p>Recommended approach:\n&#8211; Only a small group can create\/modify hubs\/spokes.\n&#8211; Separate read-only visibility (<code>viewer<\/code>) for app teams and security teams.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud VPN (HA VPN):<\/strong> Provides encryption in transit for tunnels.<\/li>\n<li><strong>Interconnect:<\/strong> Provides private connectivity, but encryption is not automatic at the link layer; use application-layer encryption or IPsec overlays if required by compliance.<\/li>\n<li>Within Google Cloud, traffic between VMs is protected by Google\u2019s infrastructure security; still, your compliance requirements may demand additional encryption.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>NCC itself is not an internet-facing endpoint, but it can enable <strong>reachability<\/strong> between networks.<\/li>\n<li>Risks often come from:<\/li>\n<li>Overly broad route propagation<\/li>\n<li>Overly permissive firewall rules<\/li>\n<li>Accidental connectivity between prod and dev<\/li>\n<li>Overlapping CIDRs causing unintended routing<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>NCC configuration typically doesn\u2019t store application secrets, but related components might:<\/li>\n<li>VPN shared secrets (if using classic VPN configurations)<\/li>\n<li>Router appliance credentials<\/li>\n<li>Store secrets in <strong>Secret Manager<\/strong> and restrict access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable and review <strong>Cloud Audit Logs<\/strong> for:<\/li>\n<li>NCC hub\/spoke creation\/deletion\/updates<\/li>\n<li>IAM policy changes<\/li>\n<li>Underlying VPN\/Interconnect\/Cloud Router changes<\/li>\n<li>Use VPC Flow Logs selectively to validate traffic paths.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Document:<\/li>\n<li>Which networks exchange routes<\/li>\n<li>Why connectivity is needed<\/li>\n<li>What controls (firewalls, inspection) exist<\/li>\n<li>Who can change it and how changes are approved<\/li>\n<li>For regulated environments, ensure encryption requirements are met for on-prem \u2194 cloud links.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Attaching a sensitive VPC to a broad hub without route restrictions.<\/li>\n<li>Allowing <code>0.0.0.0\/0<\/code> routes or broad RFC1918 routes to propagate unintentionally.<\/li>\n<li>Using permissive firewall rules \u201ctemporarily\u201d and never reverting them.<\/li>\n<li>Not testing failover\u2014leading to emergency changes that bypass security review.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use separate hubs for strong isolation.<\/li>\n<li>Apply route exchange controls where supported.<\/li>\n<li>Insert inspection where required (firewall appliances, Cloud NGFW) and ensure symmetric routing.<\/li>\n<li>Enforce IAP-based admin access rather than exposing SSH to the internet.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<blockquote>\n<p>Always confirm limits and behaviors in the official documentation, as they change over time.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations (typical)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Spoke type availability varies<\/strong> by region and by feature release.<\/li>\n<li><strong>Overlapping CIDRs<\/strong> across spokes can break intended routing and may be rejected or lead to nondeterministic outcomes.<\/li>\n<li><strong>Route scale constraints<\/strong> exist:<\/li>\n<li>Maximum number of routes exchanged<\/li>\n<li>Maximum number of spokes<\/li>\n<li>Limits inherited from Cloud Router\/BGP and VPC routing<\/li>\n<li><strong>Propagation delay:<\/strong> Route updates are not always instantaneous; allow time for convergence during validation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Hubs\/spokes per project<\/li>\n<li>Route counts<\/li>\n<li>API request quotas<\/li>\n<\/ul>\n\n\n\n<p>Check current quotas in:\n&#8211; Google Cloud console quotas\n&#8211; NCC documentation (verify in official docs)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>VPN gateways, Cloud Routers, and VLAN attachments are regional, which affects design and failover planning.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>NCC charges (spoke and\/or data processing) can add up with many spokes or high east-west traffic.<\/li>\n<li>Inter-region egress can be significant if you connect spokes across regions and move a lot of data.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Some advanced routing scenarios (multiple overlapping advertisements, complex filtering) may require router appliances or additional design work.<\/li>\n<li>Certain transitive routing patterns might be limited depending on spoke types\u2014verify your desired pattern.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>\u201cRoutes exist\u201d \u2260 \u201ctraffic flows.\u201d<\/strong> Firewalls, OS ACLs, and asymmetric routing still block traffic.<\/li>\n<li><strong>Change blast radius:<\/strong> Updating a hub policy can affect many spokes; treat changes like core network changes.<\/li>\n<li><strong>Troubleshooting requires multiple layers:<\/strong> NCC attachment status, Cloud Router BGP, VPN tunnel state, VPC routes, firewall, VM OS.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Migrating from a peering mesh or legacy WAN requires:<\/li>\n<li>IP plan review<\/li>\n<li>staged cutover<\/li>\n<li>route advertisement controls<\/li>\n<li>rollback plan<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Vendor-specific nuances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If you use third-party router appliances, routing behavior depends on vendor configuration (BGP attributes, MED\/localpref, ECMP).<\/li>\n<li>Validate interoperability with Cloud Router and your appliance\u2019s BGP implementation.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Network Connectivity Center is one of several ways to build connectivity. The right choice depends on scale, routing needs, governance, and cost.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Alternatives within Google Cloud<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>VPC Network Peering<\/strong><\/li>\n<li>Good for simple VPC-to-VPC connectivity.<\/li>\n<li>Not transitive; peering meshes get complex at scale.<\/li>\n<li><strong>Shared VPC<\/strong><\/li>\n<li>Best for centrally governed networks where multiple projects share a single VPC.<\/li>\n<li>Not a hybrid connectivity solution by itself.<\/li>\n<li><strong>Cloud VPN \/ HA VPN + Cloud Router (without NCC)<\/strong><\/li>\n<li>Works well for a small number of sites.<\/li>\n<li>Harder to scale and govern for many sites\/VPCs.<\/li>\n<li><strong>Cloud Interconnect + Cloud Router (without NCC)<\/strong><\/li>\n<li>Excellent performance; still needs a scalable topology and governance model.<\/li>\n<li><strong>Private Service Connect<\/strong><\/li>\n<li>Best for private service publishing\/consumption, not general transitive routing between networks.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Alternatives in other clouds<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS Transit Gateway<\/strong><\/li>\n<li>Similar hub-and-spoke concept for VPCs and VPN\/Direct Connect.<\/li>\n<li><strong>Azure Virtual WAN<\/strong><\/li>\n<li>Managed hub for connectivity including VPN\/ExpressRoute and branch connectivity.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Open-source\/self-managed alternatives<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Self-managed transit using NVAs<\/strong><\/li>\n<li>Deploy routing appliances (FRR, VyOS, vendor routers) and build transit yourself.<\/li>\n<li>More control, more operational burden, more patching and scaling responsibility.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Comparison table<\/h4>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Network Connectivity Center (Google Cloud)<\/strong><\/td>\n<td>Hybrid + multi-network hub-and-spoke with centralized governance<\/td>\n<td>Central model, scalable attachments, route exchange, integrates with VPN\/Interconnect\/Cloud Router<\/td>\n<td>Requires learning NCC model; charges may apply; feature availability depends on spoke types<\/td>\n<td>Many sites\/VPCs, need transitive routing and centralized control<\/td>\n<\/tr>\n<tr>\n<td><strong>VPC Network Peering<\/strong><\/td>\n<td>Small number of VPC-to-VPC connections<\/td>\n<td>Simple, low latency, no extra gateway appliances<\/td>\n<td>Not transitive; mesh complexity; governance sprawl<\/td>\n<td>2\u20135 VPCs with simple connectivity needs<\/td>\n<\/tr>\n<tr>\n<td><strong>Shared VPC<\/strong><\/td>\n<td>Centralizing networking for many projects<\/td>\n<td>Strong governance, fewer VPCs, simpler security boundaries<\/td>\n<td>Doesn\u2019t connect external networks by itself; org structure requirements<\/td>\n<td>Platform teams standardizing network for many app projects<\/td>\n<\/tr>\n<tr>\n<td><strong>HA VPN + Cloud Router (no NCC)<\/strong><\/td>\n<td>A few sites, straightforward hybrid<\/td>\n<td>Mature, encrypted, relatively quick to set up<\/td>\n<td>Operational complexity grows with many sites and multiple VPCs<\/td>\n<td>Small hybrid footprint, limited growth<\/td>\n<\/tr>\n<tr>\n<td><strong>Interconnect + Cloud Router (no NCC)<\/strong><\/td>\n<td>High throughput private hybrid<\/td>\n<td>Performance and reliability; private connectivity<\/td>\n<td>Still needs scalable topology; higher fixed costs<\/td>\n<td>Data center \u2194 cloud at scale, predictable traffic<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Transit Gateway \/ Azure Virtual WAN<\/strong><\/td>\n<td>Similar problems in other clouds<\/td>\n<td>Native hub constructs in their ecosystems<\/td>\n<td>Not applicable inside Google Cloud<\/td>\n<td>You are architecting primarily on AWS\/Azure<\/td>\n<\/tr>\n<tr>\n<td><strong>Self-managed NVA transit<\/strong><\/td>\n<td>Highly customized routing\/inspection needs<\/td>\n<td>Maximum control, custom routing policies<\/td>\n<td>High ops burden, patching, HA design complexity<\/td>\n<td>You require features beyond managed constructs and accept operational overhead<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: Global retailer with branches and segmented environments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A retailer has 800 stores and 3 regional data centers. They are migrating POS analytics and inventory services to Google Cloud. They need secure connectivity from stores to cloud services, and strict separation between prod and non-prod.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li><code>hub-prod-shared<\/code> for production connectivity:<ul>\n<li>Interconnect spokes to regional data centers<\/li>\n<li>HA VPN spokes for branch aggregation or backup<\/li>\n<li>Attach production shared services VPC (where supported) or connect via approved patterns<\/li>\n<\/ul>\n<\/li>\n<li><code>hub-nonprod-shared<\/code> for dev\/test:<ul>\n<li>Separate VPN connectivity and separate VPC attachments<\/li>\n<\/ul>\n<\/li>\n<li>Centralized firewall policy and inspection at controlled choke points (as required)<\/li>\n<li>Network Intelligence Center for topology and connectivity tests<\/li>\n<li><strong>Why Network Connectivity Center was chosen:<\/strong><\/li>\n<li>Reduces operational overhead of managing hundreds of branch VPNs and multiple cloud environments.<\/li>\n<li>Provides a clear governance boundary with separate hubs.<\/li>\n<li>Enables scalable route exchange without peering meshes.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Faster onboarding of new stores (standard spoke template)<\/li>\n<li>Reduced outage risk from ad hoc routing changes<\/li>\n<li>Easier audits: \u201cwhat is connected to prod and why\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: SaaS company with shared services and future hybrid plans<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A growing SaaS startup has separate VPCs for <code>prod<\/code>, <code>staging<\/code>, and <code>shared-tools<\/code>. Today they use minimal peering, but they expect to add a customer-managed on-prem connector and a partner network soon.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>A single NCC hub for non-sensitive connectivity initially (or separate hubs later)<\/li>\n<li>Attach shared-tools and staging VPC as spokes (if supported), keeping prod isolated<\/li>\n<li>When adding customer connectivity, use HA VPN spokes with strict route controls and firewall policies<\/li>\n<li><strong>Why Network Connectivity Center was chosen:<\/strong><\/li>\n<li>Provides a scalable \u201cfuture-ready\u201d pattern without rebuilding networking later.<\/li>\n<li>Avoids peering sprawl as environments grow.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Predictable growth path<\/li>\n<li>Clear separation between environments<\/li>\n<li>Less networking rework when hybrid connectivity arrives<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Network Connectivity Center a data-plane router or a control-plane service?<\/strong><br\/>\nIt is primarily a <strong>control-plane<\/strong> service that orchestrates connectivity and route exchange. Actual packet forwarding uses underlying services like VPC routing, Cloud VPN, Interconnect, and Cloud Router.<\/p>\n\n\n\n<p>2) <strong>Does Network Connectivity Center replace Cloud Router?<\/strong><br\/>\nNo. For BGP-based connectivity (VPN\/Interconnect\/router appliances), <strong>Cloud Router<\/strong> is still the primary BGP endpoint. NCC coordinates how networks connect and how routes are exchanged at a higher level.<\/p>\n\n\n\n<p>3) <strong>Do I still need HA VPN or Interconnect if I use NCC?<\/strong><br\/>\nYes. NCC organizes and manages connectivity; VPN\/Interconnect provide the actual transport.<\/p>\n\n\n\n<p>4) <strong>Can I connect multiple VPC networks with NCC?<\/strong><br\/>\nOften yes using VPC-related spoke capabilities, but <strong>availability and constraints vary<\/strong>. Verify current support and requirements in the official docs.<\/p>\n\n\n\n<p>5) <strong>Is VPC Network Peering the same as NCC?<\/strong><br\/>\nNo. Peering is a direct VPC-to-VPC connection and is not transitive. NCC is a hub-and-spoke connectivity model designed to scale and support hybrid patterns.<\/p>\n\n\n\n<p>6) <strong>Can NCC help me avoid a full mesh of VPN tunnels?<\/strong><br\/>\nYes\u2014this is one of its main benefits. Instead of connecting every site to every other site, you connect sites as spokes to a hub.<\/p>\n\n\n\n<p>7) <strong>How do I segment prod and non-prod connectivity?<\/strong><br\/>\nThe simplest approach is separate hubs (prod hub, non-prod hub). If your NCC feature set supports route tables\/associations or selective route exchange, you can implement more granular segmentation\u2014verify your options in official docs.<\/p>\n\n\n\n<p>8) <strong>Does NCC inspect or filter traffic like a firewall?<\/strong><br\/>\nNo. NCC is not a firewall. Use VPC firewall rules, network firewall policies, or dedicated inspection appliances\/services.<\/p>\n\n\n\n<p>9) <strong>How do I troubleshoot when routes look correct but traffic fails?<\/strong><br\/>\nCheck, in order:\n&#8211; Spoke attachment status in NCC\n&#8211; Underlying BGP session state (Cloud Router)\n&#8211; VPC routes and priorities\n&#8211; Firewall rules and OS-level firewalls\n&#8211; VPC Flow Logs and connectivity tests (Network Intelligence Center)<\/p>\n\n\n\n<p>10) <strong>What\u2019s the biggest design mistake with NCC?<\/strong><br\/>\nPoor IP planning (overlapping ranges) and attaching too many networks to a hub without segmentation, resulting in unintended reachability.<\/p>\n\n\n\n<p>11) <strong>Does NCC support high availability?<\/strong><br\/>\nHigh availability comes from the underlying connectivity design (redundant tunnels, routers, attachments). NCC supports managing multiple redundant spokes\/attachments, but you must architect HA properly.<\/p>\n\n\n\n<p>12) <strong>Will NCC reduce latency?<\/strong><br\/>\nNCC itself doesn\u2019t \u201caccelerate\u201d traffic; performance depends on VPN vs Interconnect, region placement, and routing. NCC can improve operational efficiency and consistency, which indirectly helps performance management.<\/p>\n\n\n\n<p>13) <strong>Is traffic through NCC billable?<\/strong><br\/>\nNCC pricing may include per-spoke and\/or per-GB processing. Always check the official pricing page for current SKUs and definitions.<\/p>\n\n\n\n<p>14) <strong>Can I use Infrastructure-as-Code with NCC?<\/strong><br\/>\nYes. Many teams use Terraform and\/or <code>gcloud<\/code> for NCC and related networking resources. Verify provider\/resource support and API versions in your tooling.<\/p>\n\n\n\n<p>15) <strong>How does NCC relate to Network Intelligence Center?<\/strong><br\/>\nNCC is for building and managing connectivity. Network Intelligence Center is for <strong>observability and testing<\/strong> (topology, connectivity tests, performance). They are complementary.<\/p>\n\n\n\n<p>16) <strong>Can NCC connect to third-party appliances?<\/strong><br\/>\nYes, via router appliance spokes in supported configurations. The exact requirements depend on your appliance and NCC support\u2014verify in official docs.<\/p>\n\n\n\n<p>17) <strong>What should I monitor most?<\/strong><br\/>\nMonitor underlying transports: VPN tunnel health, BGP session state, Interconnect attachment health, throughput, packet loss, and VPC Flow Logs for traffic verification.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Network Connectivity Center<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Network Connectivity Center documentation<\/td>\n<td>Primary source for concepts, spoke types, configuration, limits, and best practices. https:\/\/cloud.google.com\/network-connectivity-center\/docs<\/td>\n<\/tr>\n<tr>\n<td>Official overview<\/td>\n<td>Network Connectivity Center overview<\/td>\n<td>Quick orientation to hubs\/spokes and supported patterns. https:\/\/cloud.google.com\/network-connectivity-center\/docs\/overview<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Network Connectivity Center pricing<\/td>\n<td>Current SKUs and pricing dimensions. https:\/\/cloud.google.com\/network-connectivity-center\/pricing<\/td>\n<\/tr>\n<tr>\n<td>Pricing tool<\/td>\n<td>Google Cloud Pricing Calculator<\/td>\n<td>Model end-to-end solution costs (NCC + VPN\/Interconnect + egress). https:\/\/cloud.google.com\/products\/calculator<\/td>\n<\/tr>\n<tr>\n<td>Related networking docs<\/td>\n<td>Cloud VPN documentation<\/td>\n<td>Required for VPN-based spokes and hybrid encryption. https:\/\/cloud.google.com\/network-connectivity\/docs\/vpn<\/td>\n<\/tr>\n<tr>\n<td>Related networking docs<\/td>\n<td>Cloud Interconnect documentation<\/td>\n<td>Required for Interconnect-based spokes. https:\/\/cloud.google.com\/network-connectivity\/docs\/interconnect<\/td>\n<\/tr>\n<tr>\n<td>Related routing docs<\/td>\n<td>Cloud Router documentation<\/td>\n<td>BGP fundamentals for hybrid routing. https:\/\/cloud.google.com\/network-connectivity\/docs\/router<\/td>\n<\/tr>\n<tr>\n<td>Troubleshooting\/visibility<\/td>\n<td>Network Intelligence Center<\/td>\n<td>Connectivity tests and topology help validate NCC designs. https:\/\/cloud.google.com\/network-intelligence-center\/docs<\/td>\n<\/tr>\n<tr>\n<td>CLI reference<\/td>\n<td>gcloud network-connectivity reference<\/td>\n<td>Command reference for NCC resources (verify commands per version). https:\/\/cloud.google.com\/sdk\/gcloud\/reference\/network-connectivity<\/td>\n<\/tr>\n<tr>\n<td>Training platform (official)<\/td>\n<td>Google Cloud Skills Boost catalog search<\/td>\n<td>Find current labs\/quests related to NCC and hybrid networking. https:\/\/www.cloudskillsboost.google\/catalog?keywords=Network%20Connectivity%20Center<\/td>\n<\/tr>\n<tr>\n<td>Videos (official)<\/td>\n<td>Google Cloud Tech (YouTube)<\/td>\n<td>Official talks and demos across Google Cloud networking topics. https:\/\/www.youtube.com\/@googlecloudtech<\/td>\n<\/tr>\n<tr>\n<td>Architecture center<\/td>\n<td>Google Cloud Architecture Center<\/td>\n<td>Reference architectures for hybrid networking (browse\/search for NCC patterns). https:\/\/cloud.google.com\/architecture<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams, cloud beginners<\/td>\n<td>DevOps + cloud operations; may include Google Cloud networking fundamentals<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Students and early-career engineers<\/td>\n<td>SCM\/DevOps foundations; may include cloud and automation topics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations and platform teams<\/td>\n<td>CloudOps practices, operations, monitoring, reliability<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs and reliability-focused engineers<\/td>\n<td>SRE practices, incident response, monitoring, reliability engineering<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams adopting AIOps<\/td>\n<td>AIOps concepts, automation for operations, observability<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>Cloud\/DevOps training content (verify specific topics on site)<\/td>\n<td>Individuals seeking guided training<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training services (verify catalog)<\/td>\n<td>DevOps engineers, SREs, platform teams<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps enablement (verify offerings)<\/td>\n<td>Teams needing short-term expert help<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support\/training (verify scope)<\/td>\n<td>Ops teams needing practical troubleshooting and support<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify service lines)<\/td>\n<td>Architecture, implementation support, migrations<\/td>\n<td>Designing hybrid connectivity patterns; setting up IaC; operational runbooks<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps and cloud consulting (verify service lines)<\/td>\n<td>Platform engineering, DevOps transformation, training + advisory<\/td>\n<td>Standardizing network governance; enabling CI\/CD for infra; operational maturity<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify scope)<\/td>\n<td>DevOps automation and cloud operations<\/td>\n<td>Cloud adoption planning; automation pipelines; operational monitoring setup<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Network Connectivity Center<\/h3>\n\n\n\n<p>To be successful with NCC on Google Cloud Networking, learn:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>VPC fundamentals<\/strong><\/li>\n<li>Subnets, routes, firewall rules, private IP design<\/li>\n<li><strong>Hybrid connectivity basics<\/strong><\/li>\n<li>Cloud VPN \/ HA VPN concepts<\/li>\n<li>Interconnect basics (Dedicated vs Partner)<\/li>\n<li><strong>Dynamic routing<\/strong><\/li>\n<li>BGP concepts (ASN, route advertisement, MED\/localpref basics)<\/li>\n<li>Cloud Router operations<\/li>\n<li><strong>Security basics<\/strong><\/li>\n<li>IAM fundamentals and least privilege<\/li>\n<li>Network segmentation principles<\/li>\n<li><strong>Troubleshooting tools<\/strong><\/li>\n<li>VPC Flow Logs, traceroute, ping, TCP tests<\/li>\n<li>Network Intelligence Center connectivity tests (recommended)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Network Connectivity Center<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Advanced segmentation and routing policy (route control features, if available)<\/li>\n<li>Network security architectures:<\/li>\n<li>Inspection insertion patterns<\/li>\n<li>Cloud NGFW options and third-party firewalls<\/li>\n<li>Multi-region hybrid design and failover testing<\/li>\n<li>Infrastructure as Code for networking (Terraform modules, CI\/CD)<\/li>\n<li>Governance at scale:<\/li>\n<li>Org policies, folder\/project structure, shared VPC design<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Network Engineer<\/li>\n<li>Platform Engineer (networking-heavy)<\/li>\n<li>Site Reliability Engineer (hybrid operations)<\/li>\n<li>Cloud Solutions Architect<\/li>\n<li>Security Engineer (network segmentation\/governance)<\/li>\n<li>Network Architect (WAN modernization)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>Google Cloud certifications change over time; commonly relevant certifications include:\n&#8211; <strong>Professional Cloud Network Engineer<\/strong>\n&#8211; <strong>Professional Cloud Architect<\/strong>\n&#8211; <strong>Associate Cloud Engineer<\/strong><\/p>\n\n\n\n<p>Verify current certification offerings here:<br\/>\nhttps:\/\/cloud.google.com\/learn\/certification<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Build a two-hub model (prod\/non-prod) with strict separation and documented route exchange.<\/li>\n<li>Simulate branch connectivity using HA VPN and Cloud Router with dynamic routing and failover tests.<\/li>\n<li>Build a shared services connectivity domain and test least-privilege routing to only required services.<\/li>\n<li>Automate hub\/spoke creation using Terraform and enforce guardrails with policy checks.<\/li>\n<li>Create an operational dashboard:\n   &#8211; VPN tunnel health\n   &#8211; BGP session status\n   &#8211; Flow log sampling for key paths<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Network Connectivity Center (NCC):<\/strong> Google Cloud service to manage hub-and-spoke connectivity and route exchange across networks.<\/li>\n<li><strong>Hub:<\/strong> The central NCC resource representing a connectivity domain.<\/li>\n<li><strong>Spoke:<\/strong> An attachment to a hub representing a network endpoint (VPN, Interconnect attachment, router appliance, or VPC where supported).<\/li>\n<li><strong>VPC (Virtual Private Cloud):<\/strong> A logically isolated network in Google Cloud.<\/li>\n<li><strong>Subnet:<\/strong> A CIDR range within a VPC in a specific region.<\/li>\n<li><strong>Route exchange \/ propagation:<\/strong> Sharing routes learned from one spoke to other spokes via the hub.<\/li>\n<li><strong>Cloud Router:<\/strong> Managed BGP router for dynamic routing with VPN\/Interconnect\/router appliances.<\/li>\n<li><strong>BGP (Border Gateway Protocol):<\/strong> Routing protocol used for exchanging routes dynamically between networks.<\/li>\n<li><strong>ASN (Autonomous System Number):<\/strong> Identifier used in BGP.<\/li>\n<li><strong>HA VPN:<\/strong> High availability Cloud VPN, typically using redundant tunnels and Cloud Router.<\/li>\n<li><strong>Cloud Interconnect:<\/strong> Private connectivity between on-prem and Google Cloud (Dedicated or Partner).<\/li>\n<li><strong>VLAN attachment:<\/strong> A logical attachment for Interconnect connectivity into a VPC via Cloud Router.<\/li>\n<li><strong>Router appliance:<\/strong> A virtual or physical routing device (often third-party) that can participate in BGP and routing policies.<\/li>\n<li><strong>Transitive routing:<\/strong> Traffic can flow from one network to another through an intermediate connectivity domain (hub), not just direct peers.<\/li>\n<li><strong>VPC firewall rules:<\/strong> Stateful rules controlling ingress\/egress traffic to VM instances in a VPC.<\/li>\n<li><strong>VPC Flow Logs:<\/strong> Logs of network flows for troubleshooting and security analytics.<\/li>\n<li><strong>Cloud Audit Logs:<\/strong> Logs recording administrative actions and access patterns for Google Cloud resources.<\/li>\n<li><strong>Network Intelligence Center:<\/strong> Google Cloud suite for network observability (topology, connectivity tests, performance).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Network Connectivity Center is Google Cloud\u2019s centralized <strong>hub-and-spoke<\/strong> service for managing <strong>hybrid and multi-network connectivity<\/strong> in the Networking category. It helps you scale beyond point-to-point VPNs and peering meshes by attaching networks as <strong>spokes<\/strong> to a <strong>hub<\/strong> and coordinating <strong>route exchange<\/strong> so connectivity is consistent and governable.<\/p>\n\n\n\n<p>Key takeaways:\n&#8211; <strong>Where it fits:<\/strong> NCC sits above Cloud VPN, Interconnect, Cloud Router, and VPC routing to provide a scalable connectivity model.\n&#8211; <strong>Cost:<\/strong> Expect costs driven by <strong>spoke count<\/strong>, <strong>traffic volume<\/strong> (if data processing is billed), and underlying services (VPN\/Interconnect, egress, logging).\n&#8211; <strong>Security:<\/strong> NCC is not a firewall\u2014use segmentation (separate hubs or route controls), least-privilege IAM, and strong firewall\/inspection patterns.\n&#8211; <strong>When to use:<\/strong> Choose NCC when you have many networks\/sites\/VPCs and need centralized governance and scalable routing.\n&#8211; <strong>Next learning step:<\/strong> Deepen your hybrid routing skills with <strong>Cloud Router + BGP<\/strong>, then practice troubleshooting with <strong>Network Intelligence Center<\/strong> and VPC Flow Logs using controlled labs.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Networking<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[51,50],"tags":[],"class_list":["post-764","post","type-post","status-publish","format-standard","hentry","category-google-cloud","category-networking"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/764","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=764"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/764\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=764"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=764"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=764"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}