{"id":765,"date":"2026-04-16T02:25:29","date_gmt":"2026-04-16T02:25:29","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-network-intelligence-center-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking\/"},"modified":"2026-04-16T02:25:29","modified_gmt":"2026-04-16T02:25:29","slug":"google-cloud-network-intelligence-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-intelligence-center-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking\/","title":{"rendered":"Google Cloud Network Intelligence 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<p>Network Intelligence Center is Google Cloud\u2019s networking observability and troubleshooting suite. It helps you understand how your Google Cloud network is behaving, why connectivity is failing, and where performance or configuration risks exist\u2014without forcing you to stitch together many separate tools.<\/p>\n\n\n\n<p>In simple terms: <strong>Network Intelligence Center answers \u201cCan these two things talk?\u201d and \u201cIf not, why not?\u201d<\/strong> It gives you visual topology, automated connectivity checks, traffic insights (where enabled), and recommendations\/insights to reduce network outages and misconfigurations.<\/p>\n\n\n\n<p>Technically, Network Intelligence Center is a <strong>set of managed experiences (and related APIs) that analyze Google Cloud networking configuration and telemetry<\/strong>\u2014for example VPC routes, firewall rules, load balancers, Cloud VPN\/Interconnect, and (optionally) logs such as VPC Flow Logs. Depending on the feature, it can perform control-plane reachability analysis and\/or use measured telemetry to surface performance and usage patterns.<\/p>\n\n\n\n<p>The problem it solves is common in real environments: as VPCs, Shared VPCs, hybrid connectivity, firewalls, and load balancers grow, <strong>network troubleshooting becomes slow, tribal-knowledge-heavy, and risky<\/strong>. Network Intelligence Center reduces mean time to detect (MTTD) and mean time to resolve (MTTR) by providing a centralized place to investigate connectivity, topology, and network health.<\/p>\n\n\n\n<blockquote>\n<p>Naming check (important): As of this writing, <strong>Network Intelligence Center<\/strong> is the current Google Cloud product name. It is a suite with multiple components (for example, Connectivity Tests and Network Topology). If any component name or availability differs in your org\/region, <strong>verify in official docs<\/strong> linked later in this article.<\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Network Intelligence Center?<\/h2>\n\n\n\n<p>Network Intelligence Center (NIC) is a <strong>Google Cloud Networking<\/strong> service suite focused on <strong>network visibility, troubleshooting, and optimization<\/strong>. Its official purpose is to help teams <strong>monitor, troubleshoot, and improve network health and connectivity<\/strong> across Google Cloud networking constructs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities (high level)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Connectivity troubleshooting:<\/strong> Determine whether a source can reach a destination and identify where\/why it fails.<\/li>\n<li><strong>Topology visualization:<\/strong> Understand how VPCs and network resources connect (VPCs, subnets, VPN, Interconnect, load balancers, etc.) based on what you have access to view.<\/li>\n<li><strong>Performance visibility:<\/strong> View network performance signals (latency, packet loss) in supported scenarios.<\/li>\n<li><strong>Configuration and security insights:<\/strong> Identify risky, unused, or suboptimal networking and firewall configurations (feature availability may vary).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (typical NIC modules)<\/h3>\n\n\n\n<p>Network Intelligence Center is commonly experienced in the Google Cloud Console as several modules. Depending on your account and feature availability, you may see modules such as:\n&#8211; <strong>Connectivity Tests<\/strong> (powered by the Network Management API)\n&#8211; <strong>Network Topology<\/strong>\n&#8211; <strong>Performance Dashboard<\/strong>\n&#8211; <strong>Firewall Insights<\/strong>\n&#8211; <strong>(Optional\/if enabled in your environment)<\/strong> traffic\/flow analytics and automated network insights\/recommendations (names and availability can evolve; verify in official docs)<\/p>\n\n\n\n<p>Because Google Cloud evolves these modules, treat the suite as a <strong>portfolio of capabilities<\/strong> rather than a single monolithic service.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Service type and scope<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Service type:<\/strong> Managed Google Cloud service (console + APIs, where applicable).<\/li>\n<li><strong>Scope:<\/strong> Generally <strong>project-scoped<\/strong> in terms of what you configure and run (for example, tests created in a project). Visualization and insights are limited by <strong>IAM permissions<\/strong> and can reflect resources across multiple projects\/VPCs that you can access (for example, in Shared VPC or multi-project environments).<\/li>\n<li><strong>Regional\/global characteristics:<\/strong> Many networking constructs are global (VPC networks) with regional sub-resources (subnets, Cloud NAT, regional load balancers, Cloud VPN). NIC views and tests reflect the scope of underlying resources. Some dashboards and tests may have regional considerations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Network Intelligence Center complements (not replaces):\n&#8211; <strong>Cloud Logging<\/strong> and <strong>Cloud Monitoring<\/strong> (metrics, logs, alerting)\n&#8211; <strong>VPC Flow Logs<\/strong> (traffic telemetry)\n&#8211; <strong>Firewall Rules Logging<\/strong>\n&#8211; <strong>Cloud Trace<\/strong> \/ application APM tools (application-level latency)\n&#8211; <strong>Network Connectivity Center<\/strong> (connectivity orchestration for hub-and-spoke hybrid; different product\u2014see comparisons later)<\/p>\n\n\n\n<p>NIC\u2019s value is that it focuses on <strong>network intent and reachability<\/strong>, and presents network-specific troubleshooting workflows in one place.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Network Intelligence 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>Reduce outage duration:<\/strong> Faster network triage directly reduces downtime cost and customer impact.<\/li>\n<li><strong>Improve operational efficiency:<\/strong> Less time spent correlating routes, firewalls, VPNs, and load balancers across teams.<\/li>\n<li><strong>Standardize troubleshooting:<\/strong> Repeatable connectivity tests and topology views reduce reliance on \u201cwho knows the network.\u201d<\/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>Reachability analysis:<\/strong> Quickly identify which layer (firewall, route, NAT, VPN\/Interconnect, load balancer path) blocks traffic.<\/li>\n<li><strong>Topology clarity:<\/strong> Visualize complex environments (multiple VPCs, Shared VPC, hybrid connectivity).<\/li>\n<li><strong>Data-driven decisions:<\/strong> Use telemetry-backed insights (where enabled) rather than assumptions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons (SRE\/DevOps)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Lower MTTR:<\/strong> Guided troubleshooting workflows and clear failure points.<\/li>\n<li><strong>Pre-change validation:<\/strong> Run tests before deploying firewall or route changes.<\/li>\n<li><strong>Continuous visibility:<\/strong> Dashboards and insights help you spot regressions over time.<\/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>Identify overly permissive or unused firewall rules<\/strong> (where Firewall Insights and logging are configured).<\/li>\n<li><strong>Support audits:<\/strong> Centralized evidence of intended connectivity and enforcement points.<\/li>\n<li><strong>Least privilege for network operations:<\/strong> Granular IAM permissions can separate test-runners from network admins.<\/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>Scaling networks increases risk:<\/strong> More VPCs, more routes, more firewall rules \u2192 more opportunity for subtle failures.<\/li>\n<li><strong>Performance signals:<\/strong> When available, performance dashboards help distinguish \u201cnetwork is slow\u201d from \u201capplication is slow.\u201d<\/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 Intelligence Center when:\n&#8211; You operate <strong>production VPC networks<\/strong> and need repeatable network troubleshooting.\n&#8211; You have <strong>hybrid networking<\/strong> (VPN\/Interconnect) or multi-project setups.\n&#8211; You frequently change firewall rules, routes, load balancers, or service connectivity patterns.\n&#8211; You need an <strong>operations-friendly, Google-native<\/strong> approach rather than building everything from scratch.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>NIC may not be the right primary tool when:\n&#8211; You only need <strong>basic logs\/metrics<\/strong> and have a very small\/simple single-VPC environment.\n&#8211; Your main issues are <strong>application-layer<\/strong> (database locks, slow queries) rather than network reachability.\n&#8211; You require <strong>deep packet inspection<\/strong> or advanced NPM features that depend on third-party agents everywhere (NIC is not a full replacement for enterprise NPM suites).\n&#8211; You cannot enable required telemetry (for example, VPC Flow Logs) due to cost, policy, or data governance\u2014some NIC insights depend on telemetry.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Network Intelligence Center used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>SaaS and internet services:<\/strong> Multi-region services, load balancers, service-to-service connectivity.<\/li>\n<li><strong>Finance and healthcare:<\/strong> Strict firewall posture and auditability; hybrid connectivity to data centers.<\/li>\n<li><strong>Retail\/e-commerce:<\/strong> Peak traffic periods demand stable network paths.<\/li>\n<li><strong>Media\/gaming:<\/strong> Latency-sensitive traffic and regional performance considerations.<\/li>\n<li><strong>Public sector:<\/strong> Segmentation, Shared VPC, compliance-driven network change controls.<\/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 managing Shared VPC<\/li>\n<li>Network engineering teams adopting cloud-native networking<\/li>\n<li>SRE\/operations teams owning uptime and incident response<\/li>\n<li>Security teams reviewing firewall posture and segmentation<\/li>\n<li>DevOps teams implementing IaC-based network changes<\/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>Microservices on <strong>GKE<\/strong> (cluster-to-service reachability)<\/li>\n<li>VM-based applications on <strong>Compute Engine<\/strong><\/li>\n<li>Serverless services behind load balancers (depending on architecture)<\/li>\n<li>Data platforms using private connectivity (Private Service Connect, VPN\/Interconnect)<\/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>Single VPC with multiple subnets\/environments (dev\/stage\/prod)<\/li>\n<li>Multi-project with Shared VPC host\/service projects<\/li>\n<li>Hub-and-spoke hybrid networks (often with Network Connectivity Center for routing, NIC for visibility)<\/li>\n<li>Multi-region active\/active services with global load balancing<\/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><strong>Production:<\/strong> NIC is most valuable in production where outages are costly and changes frequent.<\/li>\n<li><strong>Dev\/test:<\/strong> Useful for validating connectivity patterns early, especially in IaC pipelines and pre-production.<\/li>\n<\/ul>\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 Intelligence Center is commonly used.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Pre-change reachability validation for firewall updates<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A firewall rule change might block critical traffic.<\/li>\n<li><strong>Why NIC fits:<\/strong> Connectivity Tests can validate reachability before and after changes.<\/li>\n<li><strong>Example:<\/strong> Before tightening ingress rules on a prod subnet, run tests from app VMs to database VMs on required ports.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Troubleshooting \u201cVM A can\u2019t reach VM B\u201d incidents<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Ping\/SSH\/API calls fail between two internal endpoints.<\/li>\n<li><strong>Why NIC fits:<\/strong> Connectivity Tests identify whether the issue is firewall, route, NAT, or other path element.<\/li>\n<li><strong>Example:<\/strong> An app tier in <code>subnet-a<\/code> cannot connect to <code>subnet-b<\/code> on TCP 5432\u2014NIC pinpoints a missing firewall allow rule.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Understanding Shared VPC connectivity boundaries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Teams are unsure how service projects connect within a Shared VPC.<\/li>\n<li><strong>Why NIC fits:<\/strong> Network Topology helps visualize the VPC and attachments you can view.<\/li>\n<li><strong>Example:<\/strong> Platform team reviews topology to confirm which projects\/subnets connect to Cloud VPN and which do not.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Hybrid connectivity troubleshooting (VPN\/Interconnect path)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> On-prem to cloud traffic intermittently fails.<\/li>\n<li><strong>Why NIC fits:<\/strong> Connectivity tests and topology visualization help isolate whether the issue is in cloud routing\/firewalls or edge connectivity.<\/li>\n<li><strong>Example:<\/strong> On-prem app cannot reach a cloud API; NIC highlights route advertisement issues (depending on configuration and visibility).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Diagnosing load balancer backends unreachable<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A load balancer returns 5xx because backends are unhealthy\/unreachable.<\/li>\n<li><strong>Why NIC fits:<\/strong> Reachability analysis helps verify whether backends can be reached and whether health checks are allowed.<\/li>\n<li><strong>Example:<\/strong> Internal HTTP(S) load balancer health checks fail because firewall doesn\u2019t allow the health check ranges.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Network performance regression investigation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Users report increased latency between regions or zones.<\/li>\n<li><strong>Why NIC fits:<\/strong> Performance dashboards can provide network-level latency\/packet loss signals in supported views.<\/li>\n<li><strong>Example:<\/strong> After migrating services across zones, you compare baseline latency across zones.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Finding overly permissive firewall rules (security hardening)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Firewall rules allow broad CIDRs or unused ports.<\/li>\n<li><strong>Why NIC fits:<\/strong> Firewall Insights (with appropriate logging) can surface rules that are unused or risky.<\/li>\n<li><strong>Example:<\/strong> Security team identifies \u201callow 0.0.0.0\/0 to tcp:22\u201d rules and replaces them with IAP-based access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Traffic pattern exploration for capacity planning (where flow analytics is enabled)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need to know top talkers and which services generate the most traffic.<\/li>\n<li><strong>Why NIC fits:<\/strong> Flow-based analytics (when enabled) uses flow telemetry to summarize traffic patterns.<\/li>\n<li><strong>Example:<\/strong> SRE team identifies unexpected east-west traffic spikes between two GKE node pools.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Detecting misconfigurations that cause blackholes or asymmetric routing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Subtle route priorities or overlapping CIDRs cause intermittent failures.<\/li>\n<li><strong>Why NIC fits:<\/strong> Network insights\/recommendations (where available) can flag problematic configurations; connectivity tests can confirm impact.<\/li>\n<li><strong>Example:<\/strong> Two routes overlap; traffic goes to the wrong next hop.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Incident response: prove whether it\u2019s network vs application<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> During an outage, teams argue whether the network is at fault.<\/li>\n<li><strong>Why NIC fits:<\/strong> A clean connectivity test result plus topology evidence can narrow down root cause.<\/li>\n<li><strong>Example:<\/strong> Connectivity tests show the network path is reachable; investigation shifts to service health or DNS.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Validating Private Google Access \/ private service connectivity behavior<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Private access to Google APIs or managed services fails from private subnets.<\/li>\n<li><strong>Why NIC fits:<\/strong> Reachability analysis can help validate relevant egress paths (depending on target type and feature support).<\/li>\n<li><strong>Example:<\/strong> Private subnet can\u2019t access Google APIs; NIC helps validate route\/NAT expectations and firewall posture.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Governance: documenting intended connectivity<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need documentation for auditors and operations.<\/li>\n<li><strong>Why NIC fits:<\/strong> Saved tests and topology views provide reproducible evidence of allowed paths.<\/li>\n<li><strong>Example:<\/strong> For a regulated workload, you maintain a set of tests that demonstrate segmentation.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>Because Network Intelligence Center is a suite, features are best understood as modules. Availability can differ by project, organization policy, and release stage\u2014<strong>verify the module list in official docs<\/strong> if your console differs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Connectivity Tests<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Lets you define and run connectivity tests between a source and a destination (for example, VM-to-VM, VM-to-IP\/hostname, or to certain Google Cloud endpoints depending on support). The result explains whether traffic is reachable and highlights the likely failure point.<\/li>\n<li><strong>Why it matters:<\/strong> Connectivity troubleshooting is one of the most time-consuming operational tasks in cloud networking.<\/li>\n<li><strong>Practical benefit:<\/strong> Faster root cause analysis across firewall rules, routes, and network attachments.<\/li>\n<li><strong>Limitations\/caveats:<\/strong><\/li>\n<li>Test types and supported endpoints vary; some scenarios may be \u201canalysis-only\u201d vs \u201cactive probing.\u201d<\/li>\n<li>Results depend on correct identification of endpoints, ports, and protocols.<\/li>\n<li>Some failures outside Google Cloud (on-prem ISP issues, external DNS, remote service health) may not be fully diagnosable.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network Topology<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Visualizes your network resources and their connections (VPCs, subnets, instances, VPN\/Interconnect attachments, load balancers, etc.) based on what you have permission to view.<\/li>\n<li><strong>Why it matters:<\/strong> Most outages happen because humans misunderstand dependencies.<\/li>\n<li><strong>Practical benefit:<\/strong> Faster orientation during incidents and safer planning for changes.<\/li>\n<li><strong>Limitations\/caveats:<\/strong><\/li>\n<li>Shows resources you have IAM access to; incomplete permissions can produce incomplete topology.<\/li>\n<li>Visualization is not a substitute for formal documentation\/IaC state.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance Dashboard<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides performance views for network latency and packet loss across supported scopes (for example, zonal\/regional connectivity views).<\/li>\n<li><strong>Why it matters:<\/strong> Helps separate network performance issues from application issues.<\/li>\n<li><strong>Practical benefit:<\/strong> Baseline network behavior and spot deviations.<\/li>\n<li><strong>Limitations\/caveats:<\/strong><\/li>\n<li>Scope and granularity are limited to what Google exposes in the dashboard.<\/li>\n<li>Not a replacement for application performance monitoring.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Firewall Insights<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Helps identify firewall rules that may be unused, overly permissive, or otherwise candidates for cleanup (typically based on firewall logging\/telemetry).<\/li>\n<li><strong>Why it matters:<\/strong> Firewall sprawl increases risk and makes future troubleshooting harder.<\/li>\n<li><strong>Practical benefit:<\/strong> Safer hardening and reduced attack surface.<\/li>\n<li><strong>Limitations\/caveats:<\/strong><\/li>\n<li>Generally requires firewall logging and time to collect enough data.<\/li>\n<li>\u201cUnused\u201d might mean \u201crarely used\u201d; do not auto-delete rules without change control.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Flow\/traffic analytics (where available)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Uses flow telemetry (commonly VPC Flow Logs) to summarize traffic patterns (top talkers, protocols, ports, flows by subnet or VM).<\/li>\n<li><strong>Why it matters:<\/strong> You can\u2019t optimize or secure what you can\u2019t measure.<\/li>\n<li><strong>Practical benefit:<\/strong> Capacity planning, anomaly detection, and faster security investigations.<\/li>\n<li><strong>Limitations\/caveats:<\/strong><\/li>\n<li>Requires enabling logs\/telemetry, which has cost and data governance implications.<\/li>\n<li>Visibility is limited by sampling, aggregation, and retention settings.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network insights \/ recommendations (where available)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Surfaces potential misconfigurations, suboptimal designs, or risks (for example, routing anomalies, configuration opportunities).<\/li>\n<li><strong>Why it matters:<\/strong> Preventing incidents is cheaper than responding to them.<\/li>\n<li><strong>Practical benefit:<\/strong> Proactive detection of network hygiene issues.<\/li>\n<li><strong>Limitations\/caveats:<\/strong><\/li>\n<li>Recommendation coverage is not universal; treat as guidance, not absolute truth.<\/li>\n<li>Always validate recommendations against your intent and constraints.<\/li>\n<\/ul>\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 Intelligence Center sits \u201cabove\u201d your VPC and hybrid network resources. It:\n1. <strong>Reads configuration<\/strong> (routes, firewall rules, forwarding rules, subnet info, etc.) using Google Cloud control-plane data.\n2. <strong>Reads telemetry<\/strong> (depending on module): metrics, logs, flow logs, firewall logs.\n3. <strong>Runs analysis<\/strong> for reachability or insights.\n4. <strong>Presents results<\/strong> in the Console (and\/or via APIs where applicable).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Data flow vs control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control flow (management plane):<\/strong><\/li>\n<li>You create or run tests and view dashboards.<\/li>\n<li>Google Cloud APIs evaluate configuration and generate results.<\/li>\n<li><strong>Data flow (your packets):<\/strong><\/li>\n<li>NIC does not sit inline; it does not route your traffic.<\/li>\n<li>Some modules may use probing\/measurement mechanisms, but your application packets still traverse standard VPC routing and firewall enforcement.<\/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:\n&#8211; <strong>Compute Engine \/ VPC:<\/strong> Subnets, instances, routes, firewall rules.\n&#8211; <strong>Cloud VPN \/ Cloud Interconnect:<\/strong> Hybrid connectivity components shown in topology and evaluated in reachability (where supported).\n&#8211; <strong>Cloud Load Balancing:<\/strong> Forwarding rules, backend services, health checks.\n&#8211; <strong>Cloud NAT:<\/strong> Egress NAT path components.\n&#8211; <strong>Cloud Logging \/ Cloud Monitoring:<\/strong> Storage and visualization for logs\/metrics used by insights.\n&#8211; <strong>VPC Flow Logs:<\/strong> Telemetry source for flow-based analytics.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<p>Exact dependencies vary by module, but typical ones are:\n&#8211; <strong>Network Management API<\/strong> for Connectivity Tests (official name in APIs &amp; Services).\n&#8211; <strong>Cloud Logging \/ Monitoring<\/strong> if you use dashboards, logging-based insights, or export telemetry.\n&#8211; <strong>IAM<\/strong> for access control and auditability.<\/p>\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>IAM governs access<\/strong> to create\/run tests and view results.<\/li>\n<li><strong>Audit Logs<\/strong> can record administrative actions (for example, creating tests), subject to your audit configuration.<\/li>\n<li>NIC generally operates on <strong>metadata and telemetry<\/strong>; it does not require you to install agents for core functionality like reachability analysis (verify for any advanced features).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>NIC is not a dataplane service. It does not add hops or become a single point of failure.<\/li>\n<li>It evaluates existing VPC behavior (routes, firewall policy evaluation, next hops, etc.).<\/li>\n<li>For hybrid cases, visibility depends on the cloud-side configuration; NIC cannot \u201csee inside\u201d your on-prem network beyond what is represented in routes\/BGP and reachable endpoints.<\/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>Decide early whether to enable <strong>VPC Flow Logs<\/strong> and <strong>Firewall Rules Logging<\/strong>, and where to export (Cloud Logging, BigQuery).<\/li>\n<li>Set retention and access controls for logs (PII, sensitive endpoints).<\/li>\n<li>Use labels, naming conventions, and change management around tests (treat tests as operational assets).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  U[Operator \/ SRE] --&gt;|Console \/ gcloud| NIC[Network Intelligence Center]\n\n  NIC --&gt;|Reads config| VPC[VPC Network\\nRoutes + Firewall Rules]\n  NIC --&gt;|Reads telemetry (optional)| LOG[Cloud Logging \/ Monitoring]\n  VPC --&gt; VM1[Compute Engine VM A]\n  VPC --&gt; VM2[Compute Engine VM B]\n\n  NIC --&gt;|Connectivity Test result| U\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Org[Google Cloud Organization]\n    subgraph Host[Shared VPC Host Project]\n      VPC1[VPC: prod-shared]\n      FW[Firewall rules \/ policies]\n      RT[Routes \/ dynamic routing]\n      NAT[Cloud NAT]\n      LB[Cloud Load Balancing]\n      VPN[Cloud VPN \/ Interconnect attachments]\n    end\n\n    subgraph SvcA[Service Project A]\n      GKE[GKE workloads]\n      VMApp[App VMs]\n    end\n\n    subgraph SvcB[Service Project B]\n      VMDB[DB VMs]\n      PSC[Private Service Connect endpoints]\n    end\n\n    LOGS[Cloud Logging\\n(VPC Flow Logs, FW logs)]\n    MON[Cloud Monitoring]\n    NIC[Network Intelligence Center\\n(Connectivity Tests, Topology,\\nPerformance, Insights)]\n  end\n\n  OnPrem[On-prem network\\n(BGP, firewalls, routers)] --- VPN\n\n  VMApp --&gt; VPC1\n  VMDB --&gt; VPC1\n  GKE --&gt; VPC1\n  VPC1 --&gt; NAT\n  VPC1 --&gt; LB\n  VPC1 --&gt; PSC\n\n  NIC --&gt; VPC1\n  NIC --&gt; LOGS\n  NIC --&gt; MON\n\n  SRE[SRE \/ NetOps \/ SecOps] --&gt; NIC\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Google Cloud account\/project requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A <strong>Google Cloud project<\/strong> with <strong>Billing enabled<\/strong>.<\/li>\n<li>Permission to create and manage Compute Engine and networking resources for the lab.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles (minimum practical set)<\/h3>\n\n\n\n<p>Exact least-privilege roles vary by org policy, but for this tutorial you typically need permissions for:\n&#8211; Creating VPC networks, subnets, firewall rules, and routes (for example, Compute Network Admin permissions).\n&#8211; Creating VM instances (Compute Instance Admin permissions).\n&#8211; Running connectivity tests (Network Management permissions).<\/p>\n\n\n\n<p>Common roles you may see in Google Cloud include:\n&#8211; <code>roles\/compute.networkAdmin<\/code> (network creation\/firewalls)\n&#8211; <code>roles\/compute.instanceAdmin.v1<\/code> (VMs)\n&#8211; Network Management roles (often <code>roles\/networkmanagement.admin<\/code> \/ <code>roles\/networkmanagement.viewer<\/code>)<br\/>\n<strong>Verify role IDs and the most appropriate roles in official IAM docs<\/strong> for Network Intelligence Center \/ Network Management API.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Connectivity tests and topology visualization are typically low-cost, but costs can still occur due to:<\/li>\n<li>VM runtime<\/li>\n<li>Logs (if you enable flow logs or firewall logging)<\/li>\n<li>Egress (if you generate external traffic)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools needed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Google Cloud CLI (<code>gcloud<\/code>)<\/strong> installed and authenticated: https:\/\/cloud.google.com\/sdk\/docs\/install<\/li>\n<li>Optional: <strong>Cloud Shell<\/strong> (no install required)<\/li>\n<li>Access to the <strong>Google Cloud Console<\/strong><\/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>Compute Engine regions\/zones are widely available.<\/li>\n<li>NIC feature availability can vary; <strong>verify in official docs<\/strong> if a module is not visible in your region\/project.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Compute Engine quotas (CPUs, instances).<\/li>\n<li>API quotas for running tests or reading telemetry.<\/li>\n<li>Logging quotas if you enable logs.\nBecause quota numbers and defaults change, <strong>check<\/strong>:<\/li>\n<li><strong>IAM &amp; Admin \u2192 Quotas<\/strong><\/li>\n<li>Service-specific quota pages in the Console<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services\/APIs<\/h3>\n\n\n\n<p>For the hands-on lab:\n&#8211; Compute Engine API: <code>compute.googleapis.com<\/code>\n&#8211; Network Management API (for Connectivity Tests): <code>networkmanagement.googleapis.com<\/code>\n&#8211; (Optional for IAP SSH without external IPs) IAP API: <code>iap.googleapis.com<\/code><br\/>\nIf you prefer external IP SSH, you can skip IAP, but it\u2019s less secure.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Network Intelligence Center pricing is <strong>feature- and usage-dependent<\/strong>. Google Cloud pricing changes over time, and some NIC modules may be free while others are billed.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Official pricing page (start here): https:\/\/cloud.google.com\/network-intelligence-center\/pricing  <\/li>\n<li>Pricing calculator: https:\/\/cloud.google.com\/products\/calculator<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (typical)<\/h3>\n\n\n\n<p>Depending on the module you use, costs may be driven by:\n&#8211; <strong>Connectivity Tests:<\/strong> number of tests, number of test runs, and\/or advanced test types (pricing units vary\u2014verify on the official pricing page).\n&#8211; <strong>Telemetry-based modules:<\/strong> volume of logs\/metrics analyzed (often indirect costs via Cloud Logging, Monitoring, and BigQuery exports).\n&#8211; <strong>Flow-based analytics:<\/strong> cost depends heavily on <strong>VPC Flow Logs volume<\/strong>, sampling, aggregation interval, retention, and any exports to BigQuery or external SIEM.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier (if applicable)<\/h3>\n\n\n\n<p>Google Cloud sometimes includes limited free usage for certain monitoring\/logging features or includes some NIC modules at no extra charge. Because free tiers and \u201cincluded\u201d features can change:\n&#8211; <strong>Verify the current free tier<\/strong> on the NIC pricing page and on Cloud Logging\/Monitoring pricing pages.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Primary cost drivers (what actually moves your bill)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>VMs you create for testing<\/strong> (Compute Engine runtime).<\/li>\n<li><strong>Logging volume<\/strong> if you enable:\n   &#8211; VPC Flow Logs\n   &#8211; Firewall Rules Logging\n   &#8211; Load balancer logs<\/li>\n<li><strong>Data retention and exports<\/strong>\n   &#8211; Cloud Logging retention beyond default policies\n   &#8211; BigQuery storage and query costs if you export logs<\/li>\n<li><strong>Network egress<\/strong>\n   &#8211; Inter-region egress if you test across regions\n   &#8211; Internet egress if workloads talk externally<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden\/indirect costs to watch<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Turning on VPC Flow Logs for large subnets can generate a lot of data quickly.<\/li>\n<li>Exporting logs to BigQuery is powerful, but query costs can surprise teams without guardrails.<\/li>\n<li>If you keep test VMs running, compute costs dominate (not NIC itself).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost optimization strategies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer <strong>small machine types<\/strong> and delete lab infrastructure after testing.<\/li>\n<li>If enabling flow logs:<\/li>\n<li>Start with targeted subnets or specific environments (dev\/stage first).<\/li>\n<li>Use appropriate sampling and aggregation intervals.<\/li>\n<li>Set clear retention and export policies.<\/li>\n<li>Use IAM and naming conventions to prevent runaway test creation and orphaned resources.<\/li>\n<li>For production, build a cost model that includes logging\/telemetry and egress\u2014NIC insights are often only as good as your telemetry.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (no fabricated numbers)<\/h3>\n\n\n\n<p>A minimal lab typically includes:\n&#8211; 2 small VMs (for a short duration)\n&#8211; A few firewall rules\n&#8211; A few connectivity tests\/runs\n&#8211; No flow logs or exports<\/p>\n\n\n\n<p>The main cost is <strong>Compute Engine VM runtime<\/strong>. If you keep the lab under an hour and delete resources, the cost is usually small, but <strong>use the pricing calculator<\/strong> for your region\/machine type.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, NIC-related spend is often dominated by:\n&#8211; <strong>Logging and telemetry<\/strong> (VPC Flow Logs, firewall logs, load balancer logs)\n&#8211; <strong>BigQuery exports and queries<\/strong> (if used for analytics\/SIEM)\n&#8211; <strong>Cross-region traffic<\/strong> (if your architecture is multi-region)<\/p>\n\n\n\n<p>Build production estimates by modeling:\n&#8211; Number of subnets with flow logs enabled\n&#8211; Expected flows per second and sampling rate\n&#8211; Retention and export destinations\n&#8211; Team query patterns and alerting frequency<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Create a small Google Cloud network and use <strong>Network Intelligence Center (Connectivity Tests + Network Topology)<\/strong> to:\n1. Validate VM-to-VM connectivity\n2. Intentionally break connectivity with a firewall change\n3. Use Connectivity Tests to identify the failure point\n4. Fix the issue and verify recovery<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n&#8211; Create a custom VPC with two subnets\n&#8211; Create two VMs without external IPs (access via IAP SSH)\n&#8211; Allow internal traffic with a firewall rule\n&#8211; Run a Connectivity Test (success)\n&#8211; Remove the firewall rule (failure)\n&#8211; Re-run the test and inspect the failure reason\n&#8211; Restore the firewall rule (success again)\n&#8211; View Network Topology\n&#8211; Clean up everything<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set variables and enable APIs<\/h3>\n\n\n\n<p>Open <strong>Cloud Shell<\/strong> or a terminal with <code>gcloud<\/code> configured.<\/p>\n\n\n\n<p>1) Set your project and default region\/zone:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export PROJECT_ID=\"YOUR_PROJECT_ID\"\nexport REGION=\"us-central1\"\nexport ZONE_A=\"us-central1-a\"\nexport ZONE_B=\"us-central1-b\"\n\ngcloud config set project \"${PROJECT_ID}\"\ngcloud config set compute\/region \"${REGION}\"\ngcloud config set compute\/zone \"${ZONE_A}\"\n<\/code><\/pre>\n\n\n\n<p>2) Enable required APIs:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable compute.googleapis.com \\\n  networkmanagement.googleapis.com \\\n  iap.googleapis.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> APIs enable successfully. If your org restricts API enablement, you may need an admin to do this.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create a custom VPC and two subnets<\/h3>\n\n\n\n<p>Create a VPC and subnets:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute networks create nic-lab-vpc \\\n  --subnet-mode=custom\n\ngcloud compute networks subnets create nic-lab-subnet-a \\\n  --network=nic-lab-vpc \\\n  --region=\"${REGION}\" \\\n  --range=10.10.1.0\/24\n\ngcloud compute networks subnets create nic-lab-subnet-b \\\n  --network=nic-lab-vpc \\\n  --region=\"${REGION}\" \\\n  --range=10.10.2.0\/24\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> A VPC with two subnets exists.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute networks describe nic-lab-vpc\ngcloud compute networks subnets list --filter=\"network:nic-lab-vpc\"\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create firewall rules (internal allow + IAP SSH)<\/h3>\n\n\n\n<p>1) Allow internal traffic within the VPC CIDR (ICMP + common protocols). For a lab, broad internal allow is fine; for production, be more restrictive.<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute firewall-rules create nic-lab-allow-internal \\\n  --network=nic-lab-vpc \\\n  --direction=INGRESS \\\n  --priority=1000 \\\n  --action=ALLOW \\\n  --rules=tcp,udp,icmp \\\n  --source-ranges=10.10.0.0\/16\n<\/code><\/pre>\n\n\n\n<p>2) Allow IAP SSH to instances (since we won\u2019t use external IPs):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute firewall-rules create nic-lab-allow-iap-ssh \\\n  --network=nic-lab-vpc \\\n  --direction=INGRESS \\\n  --priority=1000 \\\n  --action=ALLOW \\\n  --rules=tcp:22 \\\n  --source-ranges=35.235.240.0\/20\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Two firewall rules exist.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute firewall-rules list --filter=\"network:nic-lab-vpc\"\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create two VMs (no external IPs)<\/h3>\n\n\n\n<p>Create VM A in subnet A and VM B in subnet B. Use small machine types to keep cost down.<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances create nic-lab-vm-a \\\n  --zone=\"${ZONE_A}\" \\\n  --subnet=nic-lab-subnet-a \\\n  --machine-type=e2-micro \\\n  --image-family=debian-12 \\\n  --image-project=debian-cloud \\\n  --no-address\n\ngcloud compute instances create nic-lab-vm-b \\\n  --zone=\"${ZONE_B}\" \\\n  --subnet=nic-lab-subnet-b \\\n  --machine-type=e2-micro \\\n  --image-family=debian-12 \\\n  --image-project=debian-cloud \\\n  --no-address\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Two VMs are running with internal IPs only.<\/p>\n\n\n\n<p>Verify internal IPs:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances list --filter=\"name:(nic-lab-vm-a nic-lab-vm-b)\" \\\n  --format=\"table(name,zone,networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs)\"\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Confirm baseline connectivity (SSH + ping)<\/h3>\n\n\n\n<p>1) SSH to VM A using IAP tunneling:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute ssh nic-lab-vm-a --zone=\"${ZONE_A}\" --tunnel-through-iap\n<\/code><\/pre>\n\n\n\n<p>2) From VM A, ping VM B\u2019s internal IP (replace with the IP you listed earlier):<\/p>\n\n\n\n<pre><code class=\"language-bash\">ping -c 3 10.10.2.2\n<\/code><\/pre>\n\n\n\n<p>Exit VM A:<\/p>\n\n\n\n<pre><code class=\"language-bash\">exit\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Ping succeeds (0% packet loss). If it fails, don\u2019t proceed\u2014fix firewall\/IAP first.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Create a Connectivity Test (VM A \u2192 VM B)<\/h3>\n\n\n\n<p>Connectivity Tests are part of Network Intelligence Center. In this lab, you\u2019ll create the test via <code>gcloud<\/code> using the Network Management API.<\/p>\n\n\n\n<p>1) Create the test:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud network-management connectivity-tests create nic-lab-test-a-to-b \\\n  --source-instance=\"projects\/${PROJECT_ID}\/zones\/${ZONE_A}\/instances\/nic-lab-vm-a\" \\\n  --destination-instance=\"projects\/${PROJECT_ID}\/zones\/${ZONE_B}\/instances\/nic-lab-vm-b\" \\\n  --protocol=ICMP\n<\/code><\/pre>\n\n\n\n<p>2) Run the test:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud network-management connectivity-tests run nic-lab-test-a-to-b\n<\/code><\/pre>\n\n\n\n<p>3) Describe the most recent result:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud network-management connectivity-tests describe nic-lab-test-a-to-b\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The test reports <strong>reachable<\/strong> (or equivalent success status) and provides a trace of the evaluated path.<\/p>\n\n\n\n<blockquote>\n<p>Note: Output fields and formatting can evolve. Focus on whether the result indicates reachability and what hops\/policies it evaluated.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Break connectivity by removing the internal allow firewall rule<\/h3>\n\n\n\n<p>Delete the internal allow rule:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute firewall-rules delete nic-lab-allow-internal --quiet\n<\/code><\/pre>\n\n\n\n<p>Now run the connectivity test again:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud network-management connectivity-tests run nic-lab-test-a-to-b\n<\/code><\/pre>\n\n\n\n<p>Describe the test to inspect the failure:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud network-management connectivity-tests describe nic-lab-test-a-to-b\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The test reports <strong>unreachable<\/strong>, and the details point to a firewall-related drop\/deny (or \u201cno matching allow rule\u201d).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Fix connectivity by restoring the firewall rule<\/h3>\n\n\n\n<p>Recreate the internal allow rule:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute firewall-rules create nic-lab-allow-internal \\\n  --network=nic-lab-vpc \\\n  --direction=INGRESS \\\n  --priority=1000 \\\n  --action=ALLOW \\\n  --rules=tcp,udp,icmp \\\n  --source-ranges=10.10.0.0\/16\n<\/code><\/pre>\n\n\n\n<p>Run the test again:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud network-management connectivity-tests run nic-lab-test-a-to-b\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The test returns to <strong>reachable<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 9: View Network Topology in the Console<\/h3>\n\n\n\n<p>1) In the Google Cloud Console, go to:\n&#8211; <strong>Navigation menu \u2192 Network Intelligence Center \u2192 Network Topology<\/strong><br\/>\n  Official entry point: https:\/\/cloud.google.com\/network-intelligence-center\/docs\/network-topology (docs; console is accessible from your project)<\/p>\n\n\n\n<p>2) Select your project and find <code>nic-lab-vpc<\/code>.<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> You can visually identify:\n&#8211; The VPC\n&#8211; The two subnets\n&#8211; The VM nodes\n&#8211; Their relationships within the VPC<\/p>\n\n\n\n<blockquote>\n<p>If topology appears empty or incomplete, it\u2019s usually IAM visibility or filtering.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:\n&#8211; \u2705 VM A can ping VM B when <code>nic-lab-allow-internal<\/code> exists\n&#8211; \u2705 Connectivity test reports <strong>reachable<\/strong>\n&#8211; \u2705 After deleting the internal firewall rule, ping fails and connectivity test reports <strong>unreachable<\/strong> with firewall-related reasoning\n&#8211; \u2705 After restoring the rule, connectivity test returns to <strong>reachable<\/strong>\n&#8211; \u2705 Network Topology shows the VPC\/subnets\/VMs<\/p>\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<p>1) <strong>IAP SSH fails<\/strong>\n&#8211; Symptom: <code>gcloud compute ssh ... --tunnel-through-iap<\/code> fails.\n&#8211; Fix:\n  &#8211; Ensure <code>iap.googleapis.com<\/code> is enabled.\n  &#8211; Ensure the firewall rule allows TCP 22 from <code>35.235.240.0\/20<\/code>.\n  &#8211; Ensure your user has IAP tunneling permissions (often via IAP-secured tunnel user role). <strong>Verify required IAM in official IAP docs<\/strong>.<\/p>\n\n\n\n<p>2) <strong>Connectivity test command not found<\/strong>\n&#8211; Symptom: <code>gcloud network-management ...<\/code> fails due to missing component.\n&#8211; Fix:\n  &#8211; Update gcloud:\n    <code>bash\n    gcloud components update<\/code>\n  &#8211; Ensure the Network Management API is enabled.<\/p>\n\n\n\n<p>3) <strong>Connectivity test shows unreachable but ping works<\/strong>\n&#8211; Causes can include:\n  &#8211; Endpoint mismatch (wrong zone\/instance reference)\n  &#8211; Protocol mismatch (ICMP vs TCP\/UDP)\n  &#8211; Test result referencing a previous run\n&#8211; Fix:\n  &#8211; Re-run the test and re-describe it.\n  &#8211; Validate instance self-links and zones.<\/p>\n\n\n\n<p>4) <strong>Ping fails even with allow rule<\/strong>\n&#8211; Fix:\n  &#8211; Ensure both VMs are in the expected subnets and CIDRs.\n  &#8211; Confirm there isn\u2019t an org policy or hierarchical firewall policy affecting traffic (if used in your org).\n  &#8211; Check firewall priorities and whether other policies apply (in advanced setups).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>Delete all created resources to avoid ongoing costs:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud network-management connectivity-tests delete nic-lab-test-a-to-b --quiet\n\ngcloud compute instances delete nic-lab-vm-a --zone=\"${ZONE_A}\" --quiet\ngcloud compute instances delete nic-lab-vm-b --zone=\"${ZONE_B}\" --quiet\n\ngcloud compute firewall-rules delete nic-lab-allow-internal --quiet\ngcloud compute firewall-rules delete nic-lab-allow-iap-ssh --quiet\n\ngcloud compute networks subnets delete nic-lab-subnet-a --region=\"${REGION}\" --quiet\ngcloud compute networks subnets delete nic-lab-subnet-b --region=\"${REGION}\" --quiet\n\ngcloud compute networks delete nic-lab-vpc --quiet\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> No lab resources remain.<\/p>\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>Design for clarity:<\/strong> Use clear VPC\/subnet separation by environment and function.<\/li>\n<li><strong>Prefer simple routing:<\/strong> Avoid overlapping CIDRs and ambiguous route priorities.<\/li>\n<li><strong>Document connectivity intent:<\/strong> Maintain a catalog of required service-to-service paths; translate those into saved connectivity tests.<\/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>Least privilege:<\/strong> Separate roles for:<\/li>\n<li>People who can view topology\/results<\/li>\n<li>People who can create\/run tests<\/li>\n<li>People who can modify firewall\/routes<\/li>\n<li><strong>Use IAP instead of public SSH:<\/strong> Avoid <code>0.0.0.0\/0<\/code> SSH ingress rules.<\/li>\n<li><strong>Restrict who can change logging settings<\/strong> (flow logs, firewall logs) because of cost and data sensitivity.<\/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>Scope telemetry intentionally:<\/strong> Start with high-value subnets and environments.<\/li>\n<li><strong>Set retention policies:<\/strong> Don\u2019t keep logs forever by default.<\/li>\n<li><strong>Export selectively:<\/strong> Only export what you need to BigQuery\/SIEM; add budgets and alerts.<\/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>Use NIC performance views as <strong>network baseline<\/strong>, then correlate with:<\/li>\n<li>Load balancer metrics<\/li>\n<li>VM\/GKE metrics<\/li>\n<li>Application tracing<\/li>\n<li>Avoid diagnosing everything as \u201cnetwork\u201d without evidence\u2014use connectivity tests plus metrics.<\/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>Treat connectivity tests as <strong>pre-flight checks<\/strong> for major network changes.<\/li>\n<li>Use IaC for firewall\/routes and integrate test runs in CI\/CD (where feasible).<\/li>\n<li>Establish rollback procedures when tightening firewall posture.<\/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 source\/destination and protocol in test names:<\/li>\n<li><code>prod-app-to-prod-db-tcp-5432<\/code><\/li>\n<li><strong>Tag ownership:<\/strong> Use labels\/metadata for teams and environments.<\/li>\n<li><strong>Runbooks:<\/strong> Link NIC test results and topology views in incident runbooks.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use consistent labels: <code>env<\/code>, <code>team<\/code>, <code>service<\/code>, <code>cost-center<\/code>.<\/li>\n<li>Keep resource names stable and descriptive; topology and tests are easier to interpret.<\/li>\n<li>In Shared VPC environments, standardize how service projects request and document connectivity.<\/li>\n<\/ul>\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>NIC access is controlled via <strong>IAM<\/strong>:<\/li>\n<li>Viewing topology\/insights<\/li>\n<li>Creating and running connectivity tests<\/li>\n<li>Accessing underlying telemetry sources (logs\/metrics)<\/li>\n<li>Use IAM conditions where appropriate (time-bound, resource-bound) to reduce risk.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud encrypts data at rest and in transit by default for managed services. For module-specific handling of telemetry and results, <strong>verify in official docs<\/strong>.<\/li>\n<li>If exporting logs to BigQuery or external systems, ensure encryption and access controls meet your compliance requirements.<\/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>NIC does not require exposing services publicly.<\/li>\n<li>The biggest exposure risk often comes from:<\/li>\n<li>Overly permissive firewall rules<\/li>\n<li>Public IPs and unmanaged SSH\/RDP<\/li>\n<li>Unrestricted egress<\/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>NIC itself is not a secrets store.<\/li>\n<li>When troubleshooting, avoid placing credentials in instance metadata or scripts used in tests.<\/li>\n<li>Use Secret Manager for credentials; keep connectivity tests focused on network reachability, not credentialed application checks.<\/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>Changes to firewall rules, routes, VPN\/Interconnect configs<\/li>\n<li>Creation and modification of tests (where audit logs apply)<\/li>\n<li>Centralize logs in a security project and restrict access.<\/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>Telemetry (flow logs) can reveal communication patterns and IPs that might be sensitive.<\/li>\n<li>Apply data classification:<\/li>\n<li>Who can view logs?<\/li>\n<li>How long are logs retained?<\/li>\n<li>Are logs exported cross-border?<\/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>Enabling broad logging\/exports without access controls (leaks sensitive network metadata).<\/li>\n<li>Treating \u201cunused firewall rule\u201d as safe to delete without verifying rare business flows.<\/li>\n<li>Granting broad network admin roles to too many users because troubleshooting is hard\u2014NIC should reduce that pressure.<\/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 IAP for administrative access; no public SSH.<\/li>\n<li>Enable firewall rule logging for key choke points (with careful retention).<\/li>\n<li>Maintain a curated set of NIC tests for:<\/li>\n<li>Critical service dependencies<\/li>\n<li>Hybrid connectivity paths<\/li>\n<li>Load balancer health check paths<\/li>\n<li>Implement change approval for any firewall\/route changes in production.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Because NIC is a suite, limitations vary by module. Common gotchas include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Visibility depends on IAM:<\/strong> Topology may look incomplete if you can\u2019t view certain projects\/resources.<\/li>\n<li><strong>Not a packet sniffer:<\/strong> NIC is not deep packet inspection; it won\u2019t replace packet capture tooling.<\/li>\n<li><strong>Telemetry-dependent insights:<\/strong> Flow\/firewall insights require logs; without them, you\u2019ll have limited visibility.<\/li>\n<li><strong>\u201cUnreachable\u201d can be multi-cause:<\/strong> A connectivity failure might be firewall, route, missing health check allowance, or hybrid-side issue.<\/li>\n<li><strong>Hybrid blind spots:<\/strong> Google Cloud can analyze cloud-side config, but cannot fully model all on-prem devices unless reflected in routing\/attachments.<\/li>\n<li><strong>Time delay for insights:<\/strong> Firewall\/flow insights often require hours or days of data, not minutes.<\/li>\n<li><strong>Cost surprises from logs:<\/strong> The most common \u201cNIC cost\u201d surprise is actually <strong>Cloud Logging \/ VPC Flow Logs volume<\/strong>, not the dashboard itself.<\/li>\n<li><strong>Don\u2019t confuse with Network Connectivity Center:<\/strong> That\u2019s a different product for connectivity orchestration; NIC is for visibility\/insights.<\/li>\n<li><strong>API and console differences:<\/strong> Some features may appear first in Console; others are API-driven. Module availability changes\u2014<strong>verify in docs<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Network Intelligence Center is best compared to other observability and troubleshooting tools.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Options compared<\/h3>\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 Intelligence Center (Google Cloud)<\/strong><\/td>\n<td>Cloud-native network troubleshooting and visibility<\/td>\n<td>Reachability workflows, topology, network-focused insights; integrates with Google Cloud networking<\/td>\n<td>Not full deep packet inspection; some insights depend on telemetry; module availability varies<\/td>\n<td>When you operate Google Cloud VPC\/hybrid and need faster MTTR and better network clarity<\/td>\n<\/tr>\n<tr>\n<td><strong>VPC Flow Logs + Cloud Logging\/BigQuery (Google Cloud)<\/strong><\/td>\n<td>Raw traffic telemetry and custom analysis<\/td>\n<td>Flexible, powerful, integrates with SIEM and analytics<\/td>\n<td>Requires building queries\/dashboards; can be expensive at scale<\/td>\n<td>When you need custom traffic analytics and already have logging pipelines<\/td>\n<\/tr>\n<tr>\n<td><strong>Cloud Monitoring dashboards\/alerts (Google Cloud)<\/strong><\/td>\n<td>Metrics-based monitoring across services<\/td>\n<td>Great for alerting and SLOs<\/td>\n<td>Doesn\u2019t directly explain reachability failures<\/td>\n<td>When you need operational monitoring and alerting; pair with NIC for troubleshooting<\/td>\n<\/tr>\n<tr>\n<td><strong>Network Connectivity Center (Google Cloud)<\/strong><\/td>\n<td>Managing hub-and-spoke hybrid connectivity<\/td>\n<td>Centralized connectivity\/routing management<\/td>\n<td>Not a troubleshooting suite; different goal<\/td>\n<td>When you need connectivity orchestration; use NIC to troubleshoot the resulting network<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Reachability Analyzer \/ Network Manager (AWS)<\/strong><\/td>\n<td>Similar reachability\/topology in AWS<\/td>\n<td>Good for AWS-native environments<\/td>\n<td>Not applicable to Google Cloud; different constructs<\/td>\n<td>Choose if your primary environment is AWS<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Network Watcher (Azure)<\/strong><\/td>\n<td>Similar diagnostics in Azure<\/td>\n<td>Strong Azure-native diagnostics<\/td>\n<td>Not applicable to Google Cloud<\/td>\n<td>Choose if your primary environment is Azure<\/td>\n<\/tr>\n<tr>\n<td><strong>Self-managed NPM (open source\/commercial)<\/strong><\/td>\n<td>Deep network monitoring across heterogeneous environments<\/td>\n<td>Can offer deep packet inspection and unified cross-cloud visibility<\/td>\n<td>Requires agents\/collectors; operational overhead; licensing<\/td>\n<td>Choose when you need enterprise-grade cross-cloud\/on-prem DPI and are willing to operate tooling<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\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 (multi-project Shared VPC + hybrid)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A regulated enterprise runs a Shared VPC with dozens of service projects and hybrid connectivity to data centers. Incidents often involve unclear ownership: is a failure caused by firewall policy, route advertisement, or application misconfiguration?<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Shared VPC host project with standardized subnet layout<\/li>\n<li>Cloud VPN\/Interconnect attachments for hybrid<\/li>\n<li>Centralized logging project for VPC Flow Logs and firewall logs (carefully scoped)<\/li>\n<li>Network Intelligence Center used by NetOps\/SRE:<ul>\n<li>Saved Connectivity Tests for critical service dependencies<\/li>\n<li>Network Topology during incident triage<\/li>\n<li>Firewall Insights to drive quarterly firewall cleanup<\/li>\n<\/ul>\n<\/li>\n<li><strong>Why NIC was chosen:<\/strong><\/li>\n<li>Cloud-native and integrates with Google Cloud networking constructs<\/li>\n<li>Provides consistent troubleshooting workflows without giving everyone broad admin access<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Reduced MTTR for network incidents<\/li>\n<li>Fewer outages caused by unintended firewall\/routing changes<\/li>\n<li>Improved audit posture via documented intended connectivity and controlled changes<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example (single VPC + GKE + a few VMs)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A small team runs GKE and a handful of VMs. They occasionally break service connectivity during rapid iteration (firewall changes, subnet updates, private access changes).<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Single VPC with separate subnets for apps and databases<\/li>\n<li>IAP for administrative access<\/li>\n<li>A small set of NIC Connectivity Tests:<ul>\n<li><code>app \u2192 db (tcp:5432)<\/code><\/li>\n<li><code>bastion\/IAP-admin \u2192 app (tcp:22 as needed)<\/code><\/li>\n<\/ul>\n<\/li>\n<li>Topology used for onboarding new engineers and reviewing changes<\/li>\n<li><strong>Why NIC was chosen:<\/strong><\/li>\n<li>Minimal setup overhead compared to building custom dashboards<\/li>\n<li>Helps generalist engineers troubleshoot quickly<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Faster recovery from self-inflicted networking issues<\/li>\n<li>Clearer understanding of dependencies without hiring a dedicated network engineer early<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Network Intelligence Center a single product or multiple tools?<\/strong><br\/>\nIt\u2019s a <strong>suite<\/strong>. In the Console, it appears as multiple modules (for example, Connectivity Tests and Network Topology) under the Network Intelligence Center umbrella.<\/p>\n\n\n\n<p>2) <strong>Does Network Intelligence Center sit in the data path?<\/strong><br\/>\nNo. It\u2019s an observability and analysis suite. Your packets still traverse VPC routing, firewall enforcement, VPN\/Interconnect, and load balancers normally.<\/p>\n\n\n\n<p>3) <strong>Do I need to install agents on VMs to use Connectivity Tests?<\/strong><br\/>\nCore reachability analysis does not typically require agents. Some advanced measurement scenarios may differ. <strong>Verify in official docs<\/strong> for your specific test type.<\/p>\n\n\n\n<p>4) <strong>Can I use Connectivity Tests for TCP ports (not just ICMP)?<\/strong><br\/>\nConnectivity Tests supports protocol\/port-based tests in many scenarios, but supported endpoint types vary. Check the Connectivity Tests documentation for current support.<\/p>\n\n\n\n<p>5) <strong>Can NIC troubleshoot on-prem connectivity?<\/strong><br\/>\nIt can help by analyzing the cloud-side configuration (routes, VPN\/Interconnect attachments, firewall rules). It cannot fully introspect on-prem routers\/firewalls unless represented in the cloud configuration and reachable endpoint modeling.<\/p>\n\n\n\n<p>6) <strong>Is Network Topology \u201creal time\u201d?<\/strong><br\/>\nTopology is based on discovered configuration and may not be instantaneous. Use it as a visualization and troubleshooting aid, not as a real-time packet tracker.<\/p>\n\n\n\n<p>7) <strong>Why does topology look empty or incomplete?<\/strong><br\/>\nMost commonly due to IAM: you only see resources you can view. Also check filters (project, network, region).<\/p>\n\n\n\n<p>8) <strong>Does NIC replace VPC Flow Logs?<\/strong><br\/>\nNo. Flow logs are a telemetry source. NIC may use that telemetry for insights, but flow logs remain the underlying data capture mechanism.<\/p>\n\n\n\n<p>9) <strong>How do I keep NIC costs low?<\/strong><br\/>\nKeep test infrastructure small and short-lived, and be cautious with enabling VPC Flow Logs broadly. Logging volume is often the biggest cost driver.<\/p>\n\n\n\n<p>10) <strong>Can I run connectivity tests automatically in CI\/CD?<\/strong><br\/>\nConnectivity tests can be triggered via API\/CLI in many cases. Treat tests like operational checks and integrate them carefully with your deployment pipeline.<\/p>\n\n\n\n<p>11) <strong>What\u2019s the difference between Network Intelligence Center and Network Connectivity Center?<\/strong><br\/>\nNetwork Connectivity Center is for <strong>managing connectivity<\/strong> (hub-and-spoke) across hybrid networks. Network Intelligence Center is for <strong>visibility, troubleshooting, and insights<\/strong>.<\/p>\n\n\n\n<p>12) <strong>Can NIC help with load balancer health check failures?<\/strong><br\/>\nYes\u2014reachability analysis can often reveal missing firewall allowances or path issues that affect health checks, depending on the scenario.<\/p>\n\n\n\n<p>13) <strong>Does NIC support Shared VPC?<\/strong><br\/>\nNIC works with the resources you have permission to view\/test. In Shared VPC environments, ensure IAM is designed so platform\/SRE can view necessary components.<\/p>\n\n\n\n<p>14) <strong>What logs should I enable for better network insights?<\/strong><br\/>\nCommonly VPC Flow Logs and firewall rule logging (selectively). Enable with a cost and data governance plan.<\/p>\n\n\n\n<p>15) <strong>Is NIC suitable for compliance evidence?<\/strong><br\/>\nIt can support compliance by providing repeatable tests and visibility, but compliance requirements vary. Combine NIC with audit logs, change management, and documented controls.<\/p>\n\n\n\n<p>16) <strong>What if Connectivity Tests says \u201creachable\u201d but the app still fails?<\/strong><br\/>\nThen network reachability is likely not the issue. Investigate DNS, TLS, application config, service health, or identity\/authorization.<\/p>\n\n\n\n<p>17) <strong>Can I use NIC across multiple projects at once?<\/strong><br\/>\nSome views can reflect multiple projects if you have permissions; however, many objects (like tests) are created in a specific project. <strong>Verify cross-project behavior in official docs<\/strong>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Network Intelligence 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 Intelligence Center docs: https:\/\/cloud.google.com\/network-intelligence-center\/docs<\/td>\n<td>Canonical overview, module list, and concepts<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Connectivity Tests docs: https:\/\/cloud.google.com\/network-intelligence-center\/docs\/connectivity-tests<\/td>\n<td>How to create\/run tests and interpret results<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Network Topology docs: https:\/\/cloud.google.com\/network-intelligence-center\/docs\/network-topology<\/td>\n<td>How topology is built and what it can display<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Performance Dashboard docs: https:\/\/cloud.google.com\/network-intelligence-center\/docs\/performance-dashboard<\/td>\n<td>Network performance views and interpretation<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Firewall Insights docs: https:\/\/cloud.google.com\/network-intelligence-center\/docs\/firewall-insights<\/td>\n<td>How firewall insights work and prerequisites<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>NIC pricing: https:\/\/cloud.google.com\/network-intelligence-center\/pricing<\/td>\n<td>Current billing model by module\/SKU<\/td>\n<\/tr>\n<tr>\n<td>Official tool<\/td>\n<td>Google Cloud Pricing Calculator: https:\/\/cloud.google.com\/products\/calculator<\/td>\n<td>Estimate total solution cost including logging\/compute<\/td>\n<\/tr>\n<tr>\n<td>Official CLI docs<\/td>\n<td>gcloud reference: https:\/\/cloud.google.com\/sdk\/gcloud<\/td>\n<td>Command usage for automation<\/td>\n<\/tr>\n<tr>\n<td>Official networking docs<\/td>\n<td>VPC overview: https:\/\/cloud.google.com\/vpc\/docs\/overview<\/td>\n<td>Core VPC concepts that NIC analyzes<\/td>\n<\/tr>\n<tr>\n<td>Official telemetry docs<\/td>\n<td>VPC Flow Logs: https:\/\/cloud.google.com\/vpc\/docs\/using-flow-logs<\/td>\n<td>Traffic telemetry that can power insights and investigations<\/td>\n<\/tr>\n<tr>\n<td>Official telemetry docs<\/td>\n<td>Firewall Rules Logging: https:\/\/cloud.google.com\/vpc\/docs\/firewall-rules-logging<\/td>\n<td>Required for some firewall visibility workflows<\/td>\n<\/tr>\n<tr>\n<td>Official YouTube<\/td>\n<td>Google Cloud Tech channel: https:\/\/www.youtube.com\/@googlecloudtech<\/td>\n<td>Product walkthroughs and networking best practices (search within channel)<\/td>\n<\/tr>\n<tr>\n<td>Hands-on labs<\/td>\n<td>Google Cloud Skills Boost: https:\/\/www.cloudskillsboost.google\/<\/td>\n<td>Practical labs; search for NIC\/connectivity tests\/networking troubleshooting<\/td>\n<\/tr>\n<tr>\n<td>Community (reputable)<\/td>\n<td>Google Cloud Architecture Center: https:\/\/cloud.google.com\/architecture<\/td>\n<td>Reference architectures for networking patterns NIC commonly supports<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>DevOpsSchool.com<\/strong><br\/>\n   &#8211; <strong>Suitable audience:<\/strong> DevOps engineers, SREs, cloud engineers, platform teams<br\/>\n   &#8211; <strong>Likely learning focus:<\/strong> Cloud operations, DevOps practices, networking fundamentals (check course catalog for NIC-specific coverage)<br\/>\n   &#8211; <strong>Mode:<\/strong> Check website<br\/>\n   &#8211; <strong>Website:<\/strong> https:\/\/www.devopsschool.com\/<\/p>\n<\/li>\n<li>\n<p><strong>ScmGalaxy.com<\/strong><br\/>\n   &#8211; <strong>Suitable audience:<\/strong> DevOps and tooling learners, students, engineers building foundations<br\/>\n   &#8211; <strong>Likely learning focus:<\/strong> DevOps\/SCM, automation, cloud basics (check for Google Cloud networking tracks)<br\/>\n   &#8211; <strong>Mode:<\/strong> Check website<br\/>\n   &#8211; <strong>Website:<\/strong> https:\/\/www.scmgalaxy.com\/<\/p>\n<\/li>\n<li>\n<p><strong>CLoudOpsNow.in<\/strong><br\/>\n   &#8211; <strong>Suitable audience:<\/strong> Cloud operations practitioners and teams<br\/>\n   &#8211; <strong>Likely learning focus:<\/strong> Cloud ops, monitoring\/observability, operational readiness (verify current Google Cloud networking offerings)<br\/>\n   &#8211; <strong>Mode:<\/strong> Check website<br\/>\n   &#8211; <strong>Website:<\/strong> https:\/\/www.cloudopsnow.in\/<\/p>\n<\/li>\n<li>\n<p><strong>SreSchool.com<\/strong><br\/>\n   &#8211; <strong>Suitable audience:<\/strong> SREs, operations, reliability-focused engineers<br\/>\n   &#8211; <strong>Likely learning focus:<\/strong> Reliability engineering, incident response, monitoring and troubleshooting patterns that align well with NIC usage<br\/>\n   &#8211; <strong>Mode:<\/strong> Check website<br\/>\n   &#8211; <strong>Website:<\/strong> https:\/\/www.sreschool.com\/<\/p>\n<\/li>\n<li>\n<p><strong>AiOpsSchool.com<\/strong><br\/>\n   &#8211; <strong>Suitable audience:<\/strong> Operations teams exploring AIOps and automation<br\/>\n   &#8211; <strong>Likely learning focus:<\/strong> AIOps concepts, operational analytics, automation (check for cloud observability integration topics)<br\/>\n   &#8211; <strong>Mode:<\/strong> Check website<br\/>\n   &#8211; <strong>Website:<\/strong> https:\/\/www.aiopsschool.com\/<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>RajeshKumar.xyz<\/strong><br\/>\n   &#8211; <strong>Likely specialization:<\/strong> DevOps\/cloud training topics (verify current Google Cloud networking coverage)<br\/>\n   &#8211; <strong>Suitable audience:<\/strong> Engineers seeking guided training and practical mentoring<br\/>\n   &#8211; <strong>Website:<\/strong> https:\/\/www.rajeshkumar.xyz\/<\/p>\n<\/li>\n<li>\n<p><strong>devopstrainer.in<\/strong><br\/>\n   &#8211; <strong>Likely specialization:<\/strong> DevOps tooling and cloud practices (verify Google Cloud networking offerings)<br\/>\n   &#8211; <strong>Suitable audience:<\/strong> Individuals and teams looking for hands-on DevOps training<br\/>\n   &#8211; <strong>Website:<\/strong> https:\/\/www.devopstrainer.in\/<\/p>\n<\/li>\n<li>\n<p><strong>devopsfreelancer.com<\/strong><br\/>\n   &#8211; <strong>Likely specialization:<\/strong> DevOps consulting\/training-style support resources (verify service listings)<br\/>\n   &#8211; <strong>Suitable audience:<\/strong> Teams needing short-term expert help or training reinforcement<br\/>\n   &#8211; <strong>Website:<\/strong> https:\/\/www.devopsfreelancer.com\/<\/p>\n<\/li>\n<li>\n<p><strong>devopssupport.in<\/strong><br\/>\n   &#8211; <strong>Likely specialization:<\/strong> DevOps support and enablement (verify Google Cloud networking coverage)<br\/>\n   &#8211; <strong>Suitable audience:<\/strong> Ops\/DevOps teams needing practical support resources<br\/>\n   &#8211; <strong>Website:<\/strong> https:\/\/www.devopssupport.in\/<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>cotocus.com<\/strong><br\/>\n   &#8211; <strong>Likely service area:<\/strong> Cloud\/DevOps consulting (verify current Google Cloud networking offerings)<br\/>\n   &#8211; <strong>Where they may help:<\/strong> Networking design reviews, operational readiness, automation\/IaC practices<br\/>\n   &#8211; <strong>Consulting use case examples:<\/strong> Establishing network troubleshooting runbooks; designing IAM and access patterns for network operations; advising on logging\/telemetry cost controls<br\/>\n   &#8211; <strong>Website:<\/strong> https:\/\/www.cotocus.com\/<\/p>\n<\/li>\n<li>\n<p><strong>DevOpsSchool.com<\/strong><br\/>\n   &#8211; <strong>Likely service area:<\/strong> DevOps and cloud consulting\/training (verify service catalog)<br\/>\n   &#8211; <strong>Where they may help:<\/strong> Platform engineering practices, observability rollout, operational processes around networking changes<br\/>\n   &#8211; <strong>Consulting use case examples:<\/strong> Creating standardized connectivity test suites for production dependencies; integrating tests into change management; cost reviews for flow logs and telemetry<br\/>\n   &#8211; <strong>Website:<\/strong> https:\/\/www.devopsschool.com\/<\/p>\n<\/li>\n<li>\n<p><strong>DEVOPSCONSULTING.IN<\/strong><br\/>\n   &#8211; <strong>Likely service area:<\/strong> DevOps consulting (verify current Google Cloud offerings)<br\/>\n   &#8211; <strong>Where they may help:<\/strong> CI\/CD, infrastructure automation, cloud operations<br\/>\n   &#8211; <strong>Consulting use case examples:<\/strong> Building repeatable network validation steps in pipelines; designing least-privilege IAM for network visibility; operational dashboards and alerting integration<br\/>\n   &#8211; <strong>Website:<\/strong> https:\/\/www.devopsconsulting.in\/<\/p>\n<\/li>\n<\/ol>\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 Intelligence Center<\/h3>\n\n\n\n<p>To get real value from NIC, learn Google Cloud networking fundamentals first:\n&#8211; VPCs, subnets, routes, firewall rules\n&#8211; Load balancing basics (internal\/external, health checks)\n&#8211; Cloud NAT and egress patterns\n&#8211; Hybrid connectivity basics (Cloud VPN, Cloud Interconnect)\n&#8211; Cloud Logging and Monitoring basics\n&#8211; IAM fundamentals (roles, least privilege)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Network Intelligence Center<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>VPC Flow Logs deep dive (sampling, aggregation, exports)<\/li>\n<li>BigQuery for network log analytics (partitioning, cost controls)<\/li>\n<li>Organization policy, hierarchical firewall policies (if used)<\/li>\n<li>SRE incident management and postmortems<\/li>\n<li>Network Connectivity Center (if you manage hybrid at scale)<\/li>\n<li>Security operations workflows (SIEM integration, threat modeling)<\/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>Site Reliability Engineer (SRE)<\/li>\n<li>DevOps Engineer \/ Platform Engineer<\/li>\n<li>Cloud Solutions Architect<\/li>\n<li>Security Engineer (network security posture reviews)<\/li>\n<li>Operations \/ NOC teams in cloud-heavy organizations<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>Network Intelligence Center itself is not a standalone certification, but it aligns strongly with:\n&#8211; Google Cloud networking and architecture certification tracks<br\/>\n<strong>Verify current Google Cloud certification names and exam guides<\/strong> on the official certification site: https:\/\/cloud.google.com\/learn\/certification<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a \u201cconnectivity test catalog\u201d for a 3-tier app (web \u2192 app \u2192 db).<\/li>\n<li>Create a Shared VPC mock environment and document intended flows using saved tests.<\/li>\n<li>Enable targeted VPC Flow Logs for one subnet and design a cost-controlled export strategy.<\/li>\n<li>Write an incident runbook: \u201cLB backends unhealthy\u201d and include NIC checks.<\/li>\n<li>Implement a change pipeline step that runs connectivity tests before applying firewall changes (where appropriate).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>VPC (Virtual Private Cloud):<\/strong> A logical private network in Google Cloud with global scope, containing subnets and routing\/firewall rules.<\/li>\n<li><strong>Subnet:<\/strong> Regional IP range within a VPC where VM\/GKE nodes get IP addresses.<\/li>\n<li><strong>Firewall rule:<\/strong> L3\/L4 rule controlling ingress\/egress in a VPC (allow-based in VPC firewall rules; policy-based controls can add complexity).<\/li>\n<li><strong>Route:<\/strong> Defines how traffic is forwarded (next hop) for destination CIDRs.<\/li>\n<li><strong>Connectivity Test:<\/strong> A NIC workflow to evaluate whether a source can reach a destination and where it fails.<\/li>\n<li><strong>Reachability analysis:<\/strong> Control-plane evaluation of network configuration to determine potential packet path outcomes.<\/li>\n<li><strong>Network Topology:<\/strong> Visualization of network resources and their relationships.<\/li>\n<li><strong>VPC Flow Logs:<\/strong> Telemetry describing network flows within\/through VPC constructs.<\/li>\n<li><strong>Firewall Rules Logging:<\/strong> Logging of firewall rule evaluations (allowed\/denied) when enabled.<\/li>\n<li><strong>Cloud NAT:<\/strong> Managed NAT service for private instances to reach the internet or Google APIs (depending on design).<\/li>\n<li><strong>Shared VPC:<\/strong> A model where a host project owns a VPC and service projects attach resources to it.<\/li>\n<li><strong>MTTR:<\/strong> Mean Time To Resolve\/Recover\u2014time to restore service during incidents.<\/li>\n<li><strong>IAM:<\/strong> Identity and Access Management; controls who can do what in Google Cloud.<\/li>\n<li><strong>IAP (Identity-Aware Proxy) TCP forwarding:<\/strong> Secure access method to reach VMs without public IPs (commonly used for SSH\/RDP).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Network Intelligence Center is Google Cloud\u2019s <strong>Networking<\/strong> observability and troubleshooting suite. It helps teams understand <strong>connectivity, topology, and network health<\/strong> using network-aware workflows like <strong>Connectivity Tests<\/strong> and <strong>Network Topology<\/strong>, and\u2014when telemetry is enabled\u2014insights based on logs and performance signals.<\/p>\n\n\n\n<p>It matters because cloud networks scale quickly, and outages often come from small configuration mistakes in firewall rules, routes, hybrid attachments, or load balancer paths. NIC reduces MTTR by making troubleshooting repeatable and evidence-driven.<\/p>\n\n\n\n<p>Cost-wise, NIC is often not the main driver; the bigger cost is typically <strong>telemetry<\/strong> (VPC Flow Logs, firewall logs) and any <strong>exports<\/strong> (BigQuery\/SIEM), plus the compute you run for tests. Security-wise, use least-privilege IAM, prefer IAP over public SSH, and treat insights as guidance that still requires change control.<\/p>\n\n\n\n<p>Use Network Intelligence Center when you need faster, clearer network troubleshooting in Google Cloud. Next step: build a small library of connectivity tests for your most critical service dependencies and align your logging strategy to the level of visibility (and cost) your organization needs.<\/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-765","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\/765","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=765"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/765\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=765"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=765"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=765"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}