Docs
Open the console →
Guides

Network reachability

Ask Cloud Control whether traffic can flow between two IPs — and see EVERY layer the packet traverses: security groups, network ACLs, route tables and gateways, plus the stateless return path.

The Reachability analyzer on the Network screen (/network) answers a single, concrete question: *can traffic get from here to there — and if not, which layer is blocking it?* You enter a source IP and a destination IP (or pick a component to prefill an IP), choose a protocol and port, and the platform traces the packet through every network control on the path.

What it checks — every layer, in order

A packet from an instance to another endpoint passes through a fixed sequence of controls. The analyzer evaluates each one and shows an allow / deny / not-applicable verdict with the matched rule and a plain-English reason:

  1. Source security group — egress. Does the source instance's security group allow the traffic out to the destination?
  2. Source subnet network ACL — egress. Does the source subnet's NACL (evaluated in rule-number order) permit it out?
  3. Route table. Which route in the source subnet's route table matches the destination — and what does it point at (local, an internet gateway, a NAT gateway, a peering/transit-gateway connection, or a VPC endpoint)?
  4. Gateway. The gateway hop itself: *local* is same-VPC delivery; an internet gateway needs the source to have a public IP; a NAT gateway is egress-only (outbound works, inbound cannot be initiated); peering / transit gateway carries cross-VPC traffic; a VPC endpoint reaches an AWS service privately.
  5. Destination subnet network ACL — ingress. Does the destination subnet's NACL allow the traffic in?
  6. Destination security group — ingress. Does the destination instance's security group allow it in? (This is the most common blocker.)
  7. Return path. Because network ACLs are stateless, the reply is checked too — the destination NACL egress and the source NACL ingress must permit the return. Security groups are stateful, so their reply is automatically allowed.

Reachable or not — and why

The result is a big REACHABLE or NOT REACHABLE header, a one-line summary, and the full layered diagram top-to-bottom. If the path is blocked, the offending layer is highlighted ("blocked at destination security group — no ingress rule for tcp/443 from 10.0.1.41"), so you go straight to the fix instead of guessing.

Where the data comes from

Security groups and network ACLs are discovered from your connected AWS account (DescribeSecurityGroups, DescribeNetworkAcls) alongside each instance's public IP and security-group membership (DescribeInstances). Like IAM discovery, these calls are best-effort: if the platform's role is missing a describe permission, that data degrades to empty and the account stays healthy — the analyzer simply has less to reason about, and says so.

Security groups and network ACLs are engine inputs, not map clutter

SGs and NACLs are stored as first-class resources but are deliberately NOT drawn on the topology map — they are metadata the reachability engine consumes, not boxes to untangle. The map stays a clean inventory diagram; the analyzer is where their rules come to life.

Limitations

  • Analysis is over your synced topology — connect a cloud account first; a never-connected org gets an honest "no topology yet".
  • IPv4 only; the protocol/port model covers tcp/udp/icmp/all.
  • Cross-VPC reachability follows a peering / VPN / transit-gateway connection when one exists; explicit cross-VPC route-table entries and Azure/Alibaba security models are on the roadmap.
  • It reasons about configuration (SGs, NACLs, routes, gateways), not live packet captures or flow-log byte analysis.