This chapter covers VPC Reachability Analyzer, a powerful diagnostic tool for analyzing network paths within Amazon VPC. For the SOA-C02 exam, understanding this tool is critical because it tests your ability to troubleshoot network connectivity issues efficiently without generating actual traffic. Expect 5-10% of exam questions to involve Reachability Analyzer, often in scenarios where you need to determine why traffic is blocked or verify connectivity after configuration changes.
Jump to a section
Imagine you are a network engineer in a massive office building with hundreds of rooms, each with its own door, and a complex maze of corridors and security checkpoints. You need to verify if a package can be delivered from room A to room B without actually sending it. Instead of walking the entire path physically, you use a detailed floor plan and a set of rules: each corridor has a direction, each door has a lock with specific key requirements, and each checkpoint has a list of allowed items. You simulate the journey step by step: from room A, you check if the door opens (correct key), then you traverse the corridor (direction allowed), then you encounter a checkpoint (package meets criteria), and so on until you reach room B. If at any step the simulation fails, you know exactly where the problem is. This is exactly what VPC Reachability Analyzer does: it uses a virtual model of your VPC network configuration to simulate the path of a packet between two endpoints, checking all security groups, network ACLs, route tables, and other components along the way, without sending any real traffic. It tells you whether the packet can reach its destination and, if not, which component is blocking it.
What is VPC Reachability Analyzer?
VPC Reachability Analyzer is a network diagnostics tool that performs connectivity tests between two resources in your VPC. It analyzes the configuration of all network components—security groups, network ACLs (NACLs), route tables, VPC peering connections, transit gateway attachments, and more—to determine if a packet can travel from a source to a destination. It does not send any actual traffic; instead, it simulates the packet's journey using the current state of your VPC configuration.
Why It Exists
Before Reachability Analyzer, troubleshooting connectivity required sending real packets (e.g., ping, traceroute) and manually inspecting each network component. This was time-consuming and often required permissions to launch instances or install agents. Reachability Analyzer provides a no-fly, agentless method to test connectivity, which is especially valuable in large, complex VPCs with many components.
How It Works Internally
Reachability Analyzer uses a static analysis approach. It builds a mathematical model of your VPC network topology based on the current configuration. When you initiate a test, it performs a breadth-first search through this model, simulating the packet's path at each hop. The analysis considers:
Source and destination IP addresses (IPv4 or IPv6)
Protocol (TCP, UDP, ICMP)
Source and destination ports (for TCP/UDP)
Security group rules (inbound and outbound)
Network ACL rules (inbound and outbound, both numbered and unnumbered)
Route table entries (including local routes, VPC peering, transit gateway, internet gateway, VPN, etc.)
VPC endpoints (Gateway Endpoints, Interface Endpoints)
AWS PrivateLink and Network Load Balancer
Transit Gateway and VPC peering attachments
The analysis is deterministic: it checks each rule in order (for NACLs, by rule number; for security groups, all rules are evaluated, but the result is the most permissive? Actually, security groups are evaluated as a whole: if any rule allows the traffic, it is allowed; if no rule allows, it is denied. NACLs use first-match: the first rule that matches the traffic determines the outcome. The analyzer correctly models this.
Key Components, Values, Defaults, and Timers
- Source and Destination: Can be an EC2 instance (by instance ID), an elastic network interface (ENI), an internet gateway, a VPC peering connection, a transit gateway, a VPN gateway, a network interface of a NAT gateway, a network interface of a Network Load Balancer, or an IP address (if not associated with any resource). - Protocols: TCP, UDP, ICMP (including ICMPv6). - Ports: For TCP/UDP, you specify source and destination ports. For ICMP, you specify type and code (e.g., Echo Request is type 8 code 0). - Path Components: The analyzer returns a list of components the packet would traverse, including security groups, NACLs, route tables, and network interfaces. For each component, it shows the relevant rules and whether the packet was allowed or denied. - Results: - Reachable: The packet can reach the destination. - Not Reachable: The packet is blocked. The analyzer identifies the first blocking component and the specific rule (or lack thereof) that caused the denial. - Limits: You can run up to 10 concurrent analyses per account per region. The analysis typically completes within seconds, but complex topologies may take up to a minute. - Cost: There is no charge for using VPC Reachability Analyzer.
Configuration and Verification
To use Reachability Analyzer, you must have the appropriate IAM permissions: ec2:CreateNetworkInsightsPath, ec2:StartNetworkInsightsAnalysis, ec2:DescribeNetworkInsightsPaths, ec2:DescribeNetworkInsightsAnalyses, and ec2:DeleteNetworkInsightsPath. You can create a path (source and destination) and then run an analysis. You can also schedule analyses or run them on demand.
Example CLI command to create a path:
aws ec2 create-network-insights-path --source <source-arn> --destination <destination-arn> --protocol tcp --destination-port 443 --source-port 12345Then start an analysis:
aws ec2 start-network-insights-analysis --network-insights-path-id <path-id>View results:
aws ec2 describe-network-insights-analyses --network-insights-analysis-ids <analysis-id>How It Interacts with Related Technologies
Security Groups: Analyzer checks both inbound rules of the destination's security group and outbound rules of the source's security group. It also considers security group rules that reference other security groups (by ID).
Network ACLs: Analyzer evaluates inbound and outbound NACL rules in order (by rule number). It correctly handles ephemeral ports (if the NACL allows outbound high ports, the analyzer accounts for that when simulating return traffic if the test is bidirectional? Actually, Reachability Analyzer tests unidirectional path by default. For bidirectional, you run two tests: source to destination and destination to source.)
Route Tables: Analyzer checks the route table associated with the subnet of the source or intermediate component to determine the next hop. It supports all route targets: local, internet gateway, NAT gateway, transit gateway, VPC peering, VPN, egress-only internet gateway, VPC endpoint, and network interface.
VPC Peering: Analyzer can test paths across VPC peering connections, including transitive routing (though transitive peering is not supported, so it correctly models that).
Transit Gateway: Analyzer supports transit gateway attachments, including route tables and associations.
AWS PrivateLink and VPC Endpoints: Analyzer can test connectivity to interface VPC endpoints and Gateway Load Balancer endpoints.
Network Load Balancer: Analyzer can test paths to NLB targets, considering the NLB's listener rules and target group health (though it does not simulate actual health checks; it assumes targets are healthy).
Important Notes for the Exam
Reachability Analyzer does not test connectivity to or from resources that are not in the same account and region (unless you have cross-account VPC sharing or peering, which is supported).
It does not test internet connectivity from an internet gateway to an external host; it can only test from an internet gateway to an internal resource (or vice versa) but the internet gateway is treated as an endpoint.
It does not support testing between an on-premises network and a VPC via Direct Connect or VPN; you can only test between resources within the VPC or attached gateways.
The analysis is based on the current configuration. If you change a security group rule after starting an analysis, the analysis still uses the old configuration. You must run a new analysis.
You can create paths that are reusable; you can run multiple analyses on the same path with different packet parameters (e.g., different ports or protocols).
The analyzer can also return a visualization of the path in the AWS Management Console, showing each hop and the rules applied.
Troubleshooting with Reachability Analyzer
When a test returns "Not Reachable", the analyzer provides a detailed explanation of where the packet was blocked. For example: - "Security group rule 'sg-12345' does not allow inbound TCP port 443 from source IP 10.0.1.5" - "Network ACL 'acl-67890' denies inbound traffic due to rule number 100" - "No route to destination: the route table 'rtb-abcde' does not have a route matching the destination IP"
This allows you to quickly identify and fix the issue without manual inspection of each component.
Exam Relevance
On the SOA-C02 exam, you will encounter questions that ask you to determine why a specific connectivity test fails. You may be given a scenario with a VPC configuration (e.g., public subnet with internet gateway, private subnet with NAT gateway) and asked which component is blocking traffic. Reachability Analyzer is the tool to use. Also, know that it does not require any agents or changes to your infrastructure.
Identify Source and Destination
First, determine the two endpoints you want to test. The source and destination can be any of the supported resource types: EC2 instance, ENI, internet gateway, NAT gateway, transit gateway, VPC peering connection, VPN gateway, network interface of a Network Load Balancer, or a specific IP address. You must specify the source and destination ARNs or IDs. For example, to test connectivity from an EC2 instance (i-12345) to an internet gateway (igw-67890), you would use those IDs. The analyzer will then simulate a packet traveling from the source to the destination.
Specify Protocol and Ports
You must define the packet characteristics: protocol (TCP, UDP, or ICMP), source port (for TCP/UDP), destination port (for TCP/UDP), and for ICMP, the type and code. These parameters are used to evaluate security group and NACL rules. For example, if you specify TCP port 443, the analyzer checks whether security groups and NACLs allow TCP traffic on port 443. If you omit ports, the analyzer assumes all ports? Actually, you must specify at least the protocol; for TCP/UDP, you must specify destination port; source port is optional but recommended for accuracy, especially with NACLs that have ephemeral port rules.
Create a Network Insights Path
Using the AWS Management Console, CLI, or SDK, create a network insights path object. This path defines the source, destination, and packet parameters. The path is a reusable configuration; you can run multiple analyses on the same path with different packet parameters (e.g., change the port). The CLI command is `create-network-insights-path`. The path is stored in your account and can be listed and described. Paths are not charged.
Start the Reachability Analysis
Once the path is created, start the analysis using `start-network-insights-analysis`. This triggers the simulation. The analysis runs asynchronously and typically completes within seconds. You can optionally specify a filter ARN to limit the analysis to a specific path component (e.g., only check up to a certain point). The analysis ID is returned. You can poll for completion using `describe-network-insights-analyses`.
Interpret the Results
After the analysis completes, you receive a result indicating whether the path is reachable or not. If reachable, you get a list of all components the packet traverses, including security groups, NACLs, route tables, and network interfaces, along with the rules that allowed the traffic. If not reachable, the analyzer identifies the first blocking component and the specific rule (or missing rule) that caused the denial. For example, it might say: 'Network ACL 'acl-12345' denies inbound traffic due to rule 100 (deny rule).' This allows you to directly address the issue.
Enterprise Scenario 1: Troubleshooting a Web Application Connectivity Issue
A large e-commerce company runs a multi-tier web application across public and private subnets. The web servers are in a public subnet with an internet gateway, and the application servers are in a private subnet with a NAT gateway for outbound internet. After a security group update, users report that the web servers cannot communicate with the application servers on TCP port 8080. The network engineer uses VPC Reachability Analyzer to test connectivity from a web server ENI to an application server ENI on port 8080. The analyzer returns 'Not Reachable' and identifies that the security group attached to the application servers does not allow inbound TCP port 8080 from the web server's security group. The engineer quickly adds the missing rule and verifies connectivity with another analysis. This resolved the issue in minutes instead of hours of manual inspection.
Enterprise Scenario 2: Verifying Connectivity After VPC Peering
A company acquires a smaller business and needs to connect two VPCs using VPC peering. After setting up the peering connection and updating route tables, the network team must verify that resources in VPC A (10.0.0.0/16) can reach resources in VPC B (192.168.0.0/16) on specific ports. Instead of deploying test instances, they use Reachability Analyzer to test from an ENI in VPC A to an ENI in VPC B on TCP port 3306 (MySQL). The analyzer confirms reachability, showing the path through the peering connection and the allowed security group rules. This automated verification is part of their CI/CD pipeline for network changes.
Common Misconfigurations and Pitfalls
Ephemeral Ports: When testing from a private subnet to the internet via a NAT gateway, the analyzer correctly models that the NAT gateway uses ephemeral ports. However, if the NACL on the private subnet does not allow outbound high ports (1024-65535), the analysis may fail. Engineers often forget to include these rules.
Security Group Self-Reference: A common mistake is to assume that a security group rule referencing itself allows traffic from the same group. Reachability Analyzer correctly handles this, but candidates on the exam often misinterpret.
Transitive Routing: VPC peering does not support transitive routing. If VPC A is peered to VPC B and VPC B is peered to VPC C, traffic from A to C is not allowed. The analyzer correctly shows this as not reachable, but engineers sometimes expect it to work.
What SOA-C02 Tests on VPC Reachability Analyzer
The SOA-C02 exam tests your ability to use Reachability Analyzer to diagnose connectivity issues in a VPC. Specifically, you should know: - Objective 5.1: Troubleshoot networking connectivity issues. Reachability Analyzer is a primary tool for this. - When to use it: Given a scenario where an application cannot communicate, and you need to identify the blocking component (security group, NACL, route table, etc.), the correct answer is often to use Reachability Analyzer. - Limitations: The exam loves to test what Reachability Analyzer cannot do. It cannot test connectivity to the internet beyond the internet gateway, and it cannot test on-premises connectivity via Direct Connect or VPN. It also cannot test between resources in different accounts unless there is a VPC peering or transit gateway attachment.
Common Wrong Answers and Why Candidates Choose Them
Using VPC Flow Logs: Flow logs show actual traffic, but they require traffic to be generated and may not show the reason for blockage. Candidates often choose flow logs because they are familiar, but Reachability Analyzer is more direct for configuration analysis.
Using ping or traceroute: These send real packets and require instances to be running and accessible. They also may be blocked by security groups. The exam wants you to choose the tool that does not require sending traffic.
Using AWS Config: Config evaluates resource compliance but does not simulate network paths. Candidates might confuse configuration auditing with connectivity testing.
Assuming security groups are stateful: A common trap: security groups are stateful, so if you allow outbound traffic, the return traffic is automatically allowed. But the exam may test a scenario where the problem is in the NACL (stateless) or route table. Candidates often overlook NACL rules.
Specific Numbers, Values, and Terms on the Exam
Concurrent analyses limit: 10 per account per region.
Supported protocols: TCP, UDP, ICMP (including ICMPv6).
Path components: The analyzer returns a list of components; the first blocking component is the one to fix.
No charge: Reachability Analyzer is free.
Edge Cases and Exceptions
IPv6: The analyzer supports IPv6. Ensure you know that both IPv4 and IPv6 are supported.
Multiple security groups: If an instance has multiple security groups, the analyzer evaluates all of them. The rule is that if any security group allows the traffic, it is allowed (security groups are permissive).
NACL rule numbers: NACL rules are evaluated in order from lowest to highest. The first rule that matches determines the action (allow or deny). The analyzer correctly models this.
Transit Gateway route tables: The analyzer supports multiple route tables within a transit gateway, and can show which route table is used.
How to Eliminate Wrong Answers
If the question asks for a tool to diagnose why traffic is blocked without sending traffic, eliminate any answer that involves sending packets (ping, traceroute, hping).
If the question involves on-premises or internet beyond the gateway, eliminate Reachability Analyzer as it cannot test those paths.
If the question involves historical analysis, choose VPC Flow Logs instead.
If the question involves verifying configuration compliance, choose AWS Config.
VPC Reachability Analyzer performs static analysis of VPC configuration without sending any network traffic.
It supports testing between EC2 instances, ENIs, internet gateways, NAT gateways, transit gateways, VPC peering connections, VPN gateways, NLB interfaces, and VPC endpoints.
You must specify protocol (TCP, UDP, ICMP) and for TCP/UDP, the destination port; source port is optional.
The analysis identifies the first blocking component if the path is not reachable, including the specific rule or missing rule.
It is free to use, with a limit of 10 concurrent analyses per account per region.
It cannot test connectivity to the internet beyond the internet gateway or to on-premises networks via Direct Connect or VPN.
It only tests unidirectional paths; for bidirectional testing, run two analyses.
Security groups are stateful and evaluated as a whole; NACLs are stateless and evaluated in rule number order.
Reachability Analyzer is ideal for troubleshooting connectivity issues after configuration changes without impacting production traffic.
On the SOA-C02 exam, know when to use Reachability Analyzer vs. VPC Flow Logs vs. other tools.
These come up on the exam all the time. Here's how to tell them apart.
VPC Reachability Analyzer
No actual traffic required; simulates based on configuration.
Identifies the exact blocking component and rule.
Free to use; no data storage costs.
Can test paths that have never been used.
Cannot capture actual traffic patterns or volumes.
VPC Flow Logs
Captures metadata of actual network traffic (accepted/rejected).
Cannot pinpoint the blocking component; only shows that traffic was rejected.
Incur costs for log storage in CloudWatch Logs or S3.
Only shows traffic that has actually occurred.
Can be used for security analysis and traffic monitoring.
Mistake
Reachability Analyzer sends test packets into the VPC.
Correct
Reachability Analyzer does not send any actual network traffic. It performs a static analysis of the VPC configuration to simulate the packet path. No packets are generated, and no changes are made to the network.
Mistake
Reachability Analyzer can test connectivity to the internet from an instance.
Correct
Reachability Analyzer can only test paths between resources within the VPC or attached gateways (internet gateway, NAT gateway, etc.). It cannot test beyond the internet gateway to an external host. For example, it can test from an instance to an internet gateway, but not from the internet gateway to a web server on the internet.
Mistake
Reachability Analyzer supports all AWS services and resources.
Correct
Reachability Analyzer supports a specific set of resource types: EC2 instances, ENIs, internet gateways, NAT gateways, transit gateways, VPC peering connections, VPN gateways, network interfaces of Network Load Balancers, and VPC endpoints. It does not support testing between, for example, an RDS database and an EC2 instance unless you use the ENI of the RDS instance (which is possible if the RDS instance is in a VPC and you specify its ENI).
Mistake
Reachability Analyzer can test bidirectional connectivity in a single analysis.
Correct
Reachability Analyzer tests a unidirectional path from source to destination. To test bidirectional connectivity, you must run two separate analyses: one from source to destination and another from destination to source. Each analysis returns the path in one direction only.
Mistake
Reachability Analyzer automatically includes return traffic (stateful inspection).
Correct
Reachability Analyzer only simulates the forward path. It does not simulate return traffic. For stateful components like security groups, the return traffic is implicitly allowed if the forward traffic is allowed, but the analyzer does not model the return path. You must run a separate analysis for the reverse direction if you need to verify it.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, as long as both instances are in the same VPC and region. The analyzer will simulate the path across subnets, considering route tables and any intermediate components. If the subnets are in different VPCs, you need a VPC peering connection or transit gateway, and the analyzer supports those as well.
Yes, it supports both IPv4 and IPv6. You can specify IPv6 addresses as source or destination, and the analyzer will evaluate IPv6 security group rules, NACL rules, and route table entries (including egress-only internet gateways).
VPC Reachability Analyzer is free to use. There are no charges for creating paths or running analyses. However, you may incur costs for other services used in conjunction, such as storing analysis results in CloudWatch Logs if you enable logging, but the analyzer itself is free.
Yes, you can test from a private instance to an internet gateway via a NAT gateway. The analyzer will model the NAT gateway's translation and the return path. However, note that the analysis is unidirectional; to test the full round-trip, you need separate analyses for each direction.
The analysis uses the configuration that existed at the time the analysis was started. If you change a security group rule after starting, the analysis result may not reflect the new configuration. You must run a new analysis to get updated results.
Yes, it supports Gateway Endpoints (e.g., S3, DynamoDB) and Interface Endpoints (e.g., API Gateway, CloudWatch). You can test from an instance in a VPC to a VPC endpoint, and the analyzer will consider the endpoint's policy and route table entries.
You can run up to 10 concurrent analyses per account per region. There is no limit on the total number of analyses you can run over time. If you need more concurrency, you can request a limit increase from AWS Support.
You've just covered VPC Reachability Analyzer — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?