Study Guide: Automating Connectivity Verification with Reachability Analyzer
Automating the verification of connectivity intent as a network configuration changes (for example, Reachability Analyzer)
Automating Connectivity Verification: Reachability Analyzer
This study guide focuses on the automation and use of VPC Reachability Analyzer and related tools to ensure that network configuration changes align with intended connectivity goals. This is a critical skill for the AWS Certified Advanced Networking - Specialty (ANS-C01) exam.
Learning Objectives
After studying this guide, you should be able to:
- Explain the mechanism of VPC Reachability Analyzer and how it differs from traditional tools like ping.
- Identify the network components analyzed during a hop-by-hop reachability test.
- Describe how to automate connectivity verification following infrastructure changes.
- Differentiate between Reachability Analyzer and Route Analyzer (for Transit Gateway).
- Analyze tool output to troubleshoot common misconfigurations (Security Groups, NACLs, Route Tables).
Key Terms & Glossary
- Connectivity Intent: The desired state of network reachability (e.g., "Web Tier must talk to DB Tier on port 3306").
- Logical Model: A software representation of network configuration used to calculate reachability without sending actual packets.
- Hop-by-Hop Analysis: A detailed trace showing every network component (gateways, interfaces, filters) a packet passes through.
- Forwarding Plane: The actual physical or virtual hardware path where data packets travel (which Reachability Analyzer does not use).
The "Big Idea"
In modern cloud networking, especially when using Infrastructure as Code (IaC), network configurations change rapidly. Reachability Analyzer acts as a "unit test" for your network. Instead of waiting for users to report outages, you automate the verification of Connectivity Intent to ensure that every change (like a security group update) does not violate the intended network design.
Formula / Concept Box
| Component | Description |
|---|---|
| Input Parameters | Source ID, Destination ID, Protocol (TCP/UDP), Destination Port. |
| Mechanism | Static analysis of the VPC configuration (Logical Modeling). |
| Result Status | Reachable or Unreachable. |
| Failure Reason | Specific resource blocking traffic (e.g., None of the ingress rules in the security group allow this traffic). |
Hierarchical Outline
- VPC Reachability Analyzer Fundamentals
- Logical Modeling: Analyzes configurations in code; does not send real traffic.
- Scope: Supports VPCs, subnets, ENIs, VPN Gateways, Internet Gateways, and Peering connections.
- The Verification Process
- Configuration: Specify source/destination interfaces and protocols.
- Execution: Initiate the trace via Console, CLI, or SDK.
- Analysis: Review hop-by-hop results and latency estimates.
- Automation of Connectivity Intent
- Post-Deployment Validation: Triggering tests via Lambda or CI/CD after CloudFormation/CDK updates.
- Continuous Monitoring: Periodically running tests to detect "configuration drift."
- Comparison Tools
- Transit Gateway Route Analyzer: Specific to TGW route tables; analyzes forward and return paths.
- Transit Gateway Network Manager: Global visualization and SD-WAN integration.
Visual Anchors
Reachability Analysis Workflow
Network Path Logic
Definition-Example Pairs
- Security Group Analysis
- Definition: Evaluating whether ingress or egress rules allow the specified protocol and port.
- Example: Reachability Analyzer identifies that an EC2 cannot reach an RDS instance because the RDS security group is missing an entry for the EC2's private IP on port 5432.
- Route Table Validation
- Definition: Checking the existence of a valid route to the destination CIDR via the appropriate gateway.
- Example: A test fails because the subnet route table is missing a route to the Internet Gateway (0.0.0.0/0) for a public-facing instance.
Worked Examples
Scenario: Verifying a New Peering Connection
Context: You just established a VPC Peering connection between VPC-A and VPC-B. You need to ensure the Web Server in VPC-A can reach the DB Server in VPC-B.
- Configure Test:
Source:eni-12345(Web Server)Destination:eni-67890(DB Server)Protocol:TCP,Port:3306
- Run Test: The analyzer returns
Unreachable. - Analyze Results: The tool highlights the Route Table in VPC-A.
- Identification: The route for VPC-B's CIDR is missing in VPC-A's route table.
- Resolution: Add the route pointing to the
pcx-xxxx(Peering Connection ID).
Checkpoint Questions
- Does the VPC Reachability Analyzer send actual ICMP packets between instances? (Answer: No, it uses logical modeling).
- Which tool would you use specifically to analyze the routing tables within a Transit Gateway? (Answer: TGW Route Analyzer).
- True or False: Reachability Analyzer provides step-by-step instructions on how to fix identified issues. (Answer: True).
- How can you ensure that a network configuration change hasn't broken connectivity without manual testing? (Answer: Automate Reachability Analyzer tests via CLI/SDK in the CI/CD pipeline).
Muddy Points & Cross-Refs
- Reachability Analyzer vs. Flow Logs: Flow logs show what happened (historical traffic), while Reachability Analyzer shows what is possible (logical path).
- Route Analyzer vs. Reachability Analyzer: Route Analyzer is restricted to Transit Gateway route tables. Reachability Analyzer is broader, covering VPC-level components like SGs and NACLs.
- Latency: Reachability Analyzer provides latency estimates, but for real-time performance metrics, use CloudWatch Network Performance Metrics.
Comparison Tables
| Feature | VPC Reachability Analyzer | TGW Route Analyzer |
|---|---|---|
| Primary Use Case | VPC-level troubleshooting/automation | Transit Gateway path validation |
| Components Checked | SGs, NACLs, RTs, IGW, VGW, Peering | TGW Route Tables only |
| Data Plane Usage | None (Logical Model) | None (Logical Model) |
| Security Group Awareness | Yes | No (Requires Flow Logs for SG/NACL info) |
| Return Path Analysis | Not by default | Yes |