Network Intelligence Center: Seeing What Your GCP Network Is Actually Doing
A network that spans dozens of VPCs, hundreds of firewall rules across three different rule systems, multiple regions, and hybrid connections to on-prem infrastructure has a property that’s uncomfortable to admit: past a certain size, nobody actually holds the full picture in their head anymore. Network Intelligence Center is Google’s answer to that specific problem — a suite of tools for visualizing, testing, and monitoring GCP network behavior, built around one core idea: instead of reasoning about network configuration abstractly, simulate and observe what it actually does.
It’s genuinely four related but distinct tools bundled under one name, and knowing which one to reach for is most of what makes the suite useful rather than just another dashboard nobody opens.
The Four Components
┌─────────────────────────┬──────────────────────────────────────┐│ Component │ Answers │├─────────────────────────┼──────────────────────────────────────┤│ Network Topology │ "What does my network actually look ││ │ like right now, across every VPC, ││ │ region, and connection?" ││ Connectivity Tests │ "Can resource A actually reach resource ││ │ B, and if not, exactly which rule or ││ │ route is blocking it?" ││ Performance Dashboard │ "What's my actual network latency and ││ │ packet loss between regions/zones?" ││ Firewall Insights │ "Which of my firewall rules are actually ││ │ being used, and which are shadowed by ││ │ another rule and never matching?" │└─────────────────────────┴──────────────────────────────────────┘Each of these solves a genuinely different problem — Topology is for understanding, Connectivity Tests is for diagnosing a specific reachability question, Performance Dashboard is for capacity and latency planning, and Firewall Insights is for cleaning up rule sprawl. Reaching for the wrong one (trying to diagnose a specific connectivity failure using the Topology visualization, say, instead of running an actual Connectivity Test) wastes time that the right tool would have saved directly.
Connectivity Tests: Simulation, Not Just Observation
This is the tool worth understanding first, because it solves the most common real debugging need — “why can’t this reach that” — without generating actual test traffic:
gcloud network-management connectivity-tests create web-to-db-test \ --source-instance=projects/my-project/zones/us-central1-a/instances/web-server \ --destination-instance=projects/my-project/zones/us-central1-a/instances/db-server \ --destination-port=5432 \ --protocol=TCPResult: UNREACHABLE
Trace:1. Source: web-server (10.0.1.5)2. Route: default route to 10.0.2.0/24 subnet — OK3. Firewall: VPC firewall rule "deny-all-internal" (priority 900) evaluated BEFORE "allow-db-access" (priority 1000) — BLOCKS traffic4. Result: Packet would be dropped at step 3The critical detail is that this is a simulation based on your actual configuration — routes, firewall rules across all three systems, load balancer configuration — not a live packet sent through the network. This means you get a definitive answer, including the exact rule responsible for a block, without needing to actually reproduce a failure condition against live traffic, and without any risk of the test itself causing side effects. For a firewall rule ordering problem specifically — exactly the kind of issue covered in firewall rule evaluation order — this tool turns a manual trace-through-every-rule exercise into a direct answer in seconds.
Network Topology: The Live Map Nobody Draws by Hand
VPC: production-vpc ├── Subnet: us-central1 (10.0.1.0/24) │ ├── Instance: web-server-1 [tag: web] │ ├── Instance: web-server-2 [tag: web] │ └── Load Balancer: prod-lb ──► backends above ├── Subnet: europe-west1 (10.0.2.0/24) │ └── Instance: db-replica-eu ├── Peering: ──► partner-vpc (partner-project) └── VPN Tunnel: ──► on-prem-gateway (203.0.113.1)Network Topology renders this kind of view automatically and keeps it current as the actual configuration changes — genuinely useful for onboarding an engineer to an unfamiliar network, or for a periodic architecture review where “does this match what we think we have” is worth verifying against reality rather than against a diagram someone drew eighteen months ago and never updated. Stale architecture diagrams are one of the most common and most avoidable sources of confusion during an incident; a live, auto-generated topology view doesn’t have that staleness problem by construction.
This live-topology property matters most in the exact moment it’s hardest to trust manual documentation — during an incident, when someone needs to quickly understand what’s actually connected to what, under real time pressure, without wading through a wiki page nobody’s touched since the last team reorg.
Firewall Insights: Finding Rules That Do Nothing
A firewall rule that’s been shadowed by a higher-priority rule matching the same traffic first, or a rule that’s simply never matched any real traffic since it was created, is dead weight — it adds cognitive load to every future review without providing any actual security value.
gcloud recommender insights list \ --project=my-project \ --location=global \ --insight-type=google.compute.firewall.InsightInsight: Rule "allow-legacy-app-port" has not matched any trafficin the last 90 days. Consider reviewing whether this rule isstill needed.
Insight: Rule "allow-broad-internal" (priority 2000) is fullyshadowed by rule "deny-all-internal" (priority 1000) for allmatching traffic — this rule will never take effect.Running this periodically, not just once during an initial cleanup, is what actually keeps a firewall rule set lean over time — rules accumulate naturally as an environment evolves, and without something actively flagging unused or shadowed rules, the rule set only ever grows, never shrinks, until nobody trusts it enough to safely remove anything from it.
Performance Dashboard: Quantifying What “Feels Slow” Actually Means
For diagnosing whether a reported latency issue is a genuine network problem or something else entirely (application logic, a database query, a downstream API), having actual inter-zone and inter-region latency and packet loss data is more useful than guessing:
┌───────────────────────┬───────────────┬──────────────────┐│ Path │ Median latency │ Packet loss │├───────────────────────┼───────────────┼──────────────────┤│ us-central1 → us-east1 │ 28ms │ 0.01% ││ us-central1 → europe-west1│ 118ms │ 0.02% ││ us-central1a → us-central1b│ 0.8ms │ 0.00% │└───────────────────────┴───────────────┴──────────────────┘When a user complains about slowness and the actual measured network latency between the relevant zones is sub-millisecond, that’s a strong, concrete signal to redirect the investigation toward application code or database performance rather than continuing to suspect the network — a genuinely useful piece of evidence for narrowing down where an actual problem lives, especially in a cross-functional incident where different teams might otherwise each assume the problem is “somewhere else.”
Reading a Blocked Connectivity Test Result
It’s worth walking through what actually happens when a Connectivity Test finds a problem, since the trace output is more useful than a simple pass/fail once you know how to read it.
The output identifying the exact rule, its priority, and which of the three firewall systems it belongs to is what makes this genuinely faster than manual debugging — rather than checking hierarchical policies, then network firewall policies, then VPC rules by hand in evaluation order, the tool has already done that trace and tells you precisely where in the chain the block happens. For anyone who’s spent an hour manually tracing firewall evaluation order across multiple systems, the value of getting that answer in a single API call is hard to overstate.
Real-World Use Case: Pre-Deployment Connectivity Validation
Before deploying a new service that needs to reach an existing database across a VPC peering connection, running a Connectivity Test against the planned configuration — source instance to destination, on the specific port the new service will actually use — catches a missing firewall rule or an unexpected route issue before the deployment, rather than during it. This is a cheap, fast validation step that fits naturally into a deployment checklist or CI pipeline (the API is scriptable, not just console-driven), and it consistently catches exactly the kind of configuration gap that would otherwise surface as a confusing failure during an actual deployment window.
Best Practices
- Run Connectivity Tests as part of infrastructure change validation, not only reactively when something’s already broken — catching a gap before deployment is far cheaper than debugging it during one.
- Review Firewall Insights on a recurring schedule, not as a one-time cleanup — rule sprawl is an ongoing process, and keeping it in check needs to be too.
- Use Network Topology during architecture reviews and onboarding, treating it as the authoritative current-state reference rather than maintaining separate, manually-updated diagrams that inevitably drift from reality.
- Baseline Performance Dashboard metrics before an incident, not during one — knowing what “normal” latency looks like between your key regions makes it much faster to confirm or rule out network causes when something actually goes wrong.
Common Mistakes
Treating Connectivity Tests as a live traffic test rather than a configuration simulation. It’s evaluating your actual configuration, which is fast and safe, but it won’t catch a runtime issue that isn’t reflected in configuration (an application-level firewall inside the OS, for instance) — it answers “would this be allowed by GCP’s network configuration,” not “does this actually work end to end.”
Ignoring Firewall Insights findings indefinitely. An unused rule flagged repeatedly and never reviewed defeats the purpose of having the insight generated in the first place.
Not using Performance Dashboard data to set realistic expectations during architecture design. Assuming cross-region latency will be negligible without checking actual measured figures leads to architecture decisions (like chatty cross-region service calls) that perform worse than expected once built.
Frequently Asked Questions
Does running a Connectivity Test generate real network traffic? No — it’s a static analysis simulation against your actual configuration (routes, firewall rules, load balancer settings), not a live packet trace, which is why it’s safe to run against production without any risk of side effects.
Can Network Intelligence Center diagnose issues with on-prem or hybrid connectivity? Yes, Connectivity Tests can trace paths that include VPN tunnels and Interconnect attachments, evaluating the GCP-side configuration of hybrid connections, though it can’t inspect configuration on the on-prem side of that connection.
Is Network Intelligence Center included in standard GCP pricing, or a separate cost? Some components have usage-based pricing (particularly Connectivity Tests at higher volumes), while basic visibility features are often included — checking current pricing for your specific usage pattern is worth doing before assuming it’s entirely free at scale.
How current is the data in Network Topology? It reflects near-real-time configuration state, updating as your actual VPC, routing, and connection configuration changes, rather than a periodic snapshot — this is what makes it more trustworthy than a manually maintained diagram.
A Final Note on Adoption
None of Network Intelligence Center’s four components require a large upfront investment to start getting value — a single Connectivity Test run during the next confusing “why can’t this reach that” debugging session is enough to demonstrate the tool’s worth directly, without needing to commit to a full observability overhaul first. Starting small, with the one component that solves whatever problem is currently most painful, is a more realistic adoption path than trying to roll out all four tools comprehensively before anyone’s actually used any of them in anger.
Summary
Network Intelligence Center’s real value is replacing “I think this should work based on how I remember configuring it” with “I can verify this actually works, and see exactly why if it doesn’t” — a meaningfully different and more reliable basis for operating a network past the size where any single person can hold the full configuration in their head. Connectivity Tests earns its place in any pre-deployment or debugging workflow immediately; Firewall Insights and Performance Dashboard pay off more as ongoing hygiene practices than one-time checks, which is exactly why they’re worth scheduling deliberately rather than treating them as tools you only remember exist once an actual incident is already well underway and time is short.