AWS Connectivity Testing: Reachability Analyzer and Route Analyzer

This study guide covers the essential tools used in the AWS Advanced Networking Specialty (ANS-C01) for validating network paths, troubleshooting connectivity issues, and automating network intent verification.

Learning Objectives

After studying this guide, you should be able to:

• Differentiate between VPC Reachability Analyzer and Transit Gateway Route Analyzer.
• Explain the "logical model" approach used by Reachability Analyzer versus traditional data plane testing.
• Identify the specific prerequisites and limitations for each tool.
• Select the appropriate tool for a given troubleshooting scenario (e.g., Security Group issues vs. Transit Gateway routing issues).
• Use Transit Gateway Network Manager to visualize and monitor global network health.

Key Terms & Glossary

• Control Plane Analysis: Analyzing network configuration (routing tables, ACLs, SGs) without sending actual data packets.
• Logical Model: A representation of network resources and their relationships created by AWS to simulate traffic flow.
• Reachability Analyzer: A configuration analysis tool that performs hop-by-hop connectivity testing within or between VPCs.
• Route Analyzer: A Transit Gateway utility that validates routes within TGW route tables for specific source and destination IP prefixes.
• Forward Plane (Data Plane): The actual path that user data packets take through the network hardware and software.

The "Big Idea"

In a complex hybrid or multi-account AWS environment, manual troubleshooting using ping or traceroute is often insufficient because security groups, NACLs, and complex routing logic can block ICMP or mask the root cause. AWS provides declarative testing tools like Reachability Analyzer and Route Analyzer to verify that your intended configuration matches the actual logic. Instead of sending traffic, these tools "read the map" of your network to tell you exactly where a packet would be dropped.

Formula / Concept Box

Hierarchical Outline

• I. VPC Reachability Analyzer
  • Functionality: Performs hop-by-hop analysis using a logical model.
  • Scope: Includes VPCs, subnets, ENIs, VPN Gateways, and Peering connections.
  • Features:
    • No traffic sent: Analyzes "code" of the network.
    • Identify blockers: PIN-points specific SG rules or NACL entries.
    • Automation: Can be triggered via SDK/CLI after configuration changes.
• II. Transit Gateway Route Analyzer
  • Functionality: Examines TGW forwarding tables for source/destination IP pairs.
  • Scope: Transit Gateway routes ONLY (supports IPv4 and IPv6).
  • Capabilities: Analyzes both outgoing and return paths.
  • Prerequisite: TGW must be registered; does not see VPC SG/NACL rules.
• III. Global Monitoring & Visualization
  • TGW Network Manager: Dashboard for global WAN traffic.
  • Integrations: Works with SD-WAN vendors (Cisco, Aruba, etc.).
  • Metrics: Packet drops, bytes sent/received, and topology changes.

Visual Anchors

Troubleshooting Logic Flow

The Logical vs. Physical Plane

\begin{tikzpicture}[scale=0.8] \draw[thick, blue] (0,3) rectangle (6,5) node[midway] {Logical Model (Reachability Analyzer)}; \draw[thick, red] (0,0) rectangle (6,2) node[midway] {Data Plane (Actual Traffic)}; \draw[->, thick] (3,2.8) -- (3,2.2) node[midway, right] {\tiny{Discrepancy Check}}; \node at (8,4) {\small{Analyzes Configuration}}; \node at (8,1) {\small{Transmits Packets}}; \draw[dashed] (-1,2.5) -- (9,2.5); \end{tikzpicture}

Definition-Example Pairs

• Hop-by-Hop Analysis: A detailed breakdown of every network gateway or security check a packet passes through.
  • Example: Reachability Analyzer showing traffic leaving an EC2 ENI, passing through Security Group A, then being dropped by NACL B in the destination subnet.
• Return Path Validation: Checking if a response packet can get back from the destination to the source.
  • Example: Using Route Analyzer to find that a TGW has a route to a remote branch, but the return route for that branch's prefix is missing from the TGW table.

Worked Examples

Scenario: EC2 in VPC A cannot reach RDS in VPC B

1. Step 1: Initiation — Open VPC Reachability Analyzer in the AWS Console.
2. Step 2: Configuration — Select the source (Instance ID of VPC A EC2) and destination (Network Interface of RDS).
3. Step 3: Protocol — Specify TCP port 3306 (MySQL).
4. Step 4: Analysis — Run the test. The tool returns a status of "Not Reachable."
5. Step 5: Root Cause — The analysis highlights a specific "Deny" rule in the Outbound NACL of VPC A.
6. Step 6: Resolution — Modify the NACL to allow egress on port 3306 and re-run the test to confirm "Reachable."

Checkpoint Questions

1. Does Reachability Analyzer send actual ICMP packets between instances? Why or why not?
2. Which tool would you use to verify that a Transit Gateway is correctly advertising prefixes to a VPN connection?
3. You run a Route Analyzer test and see a successful forward path but no return path. What does this indicate?
4. Why are VPC Flow Logs still necessary even if you use Route Analyzer?

Muddy Points & Cross-Refs

[!IMPORTANT] Reachability Analyzer vs. Ping: A ping might fail because the OS-level firewall (like Windows Firewall or iptables) blocks ICMP, even if the AWS infrastructure (SGs, NACLs, Routes) is configured correctly. Reachability Analyzer cannot see inside the OS; it only validates the AWS fabric.

• Cross-Ref: For deep-dive packet inspection (Layer 4-7), see the section on VPC Traffic Mirroring.
• Cross-Ref: For monitoring latency trends over time, refer to CloudWatch Network Monitor.

Comparison Tables