This chapter covers VPC Network Access Analyzer, a feature that helps you identify unintended network access to your resources on AWS. For the SOA-C02 exam, understanding how to use this tool to verify security group and network ACL configurations is essential, as questions on network security and compliance appear frequently—approximately 10-15% of the exam touches VPC security and analysis topics. You will learn the internal workings, configuration steps, and how to interpret findings to secure your AWS environment.
Jump to a section
Imagine you are a security auditor for a large office building with multiple floors, each floor containing several rooms. The building has a main entrance, fire escapes, and internal doors. Your job is to verify that the building's security policies are correctly enforced—meaning that only authorized people can enter certain rooms, and that there are no unintended paths from outside to sensitive areas. You do this by walking through every possible route: you start at the main entrance, try every door, take every stairwell, and note each door that is unlocked or ajar. You also check that locked doors are actually locked and that alarms are functional. This is exactly what VPC Network Access Analyzer does: it systematically explores all possible network paths between resources in your VPC and external networks, checking each path against your security policies (like security groups and network ACLs). It reports any path that violates your intended rules—for example, a security group rule that accidentally allows SSH from 0.0.0.0/0, or a network ACL that permits inbound traffic on port 443 from any IP. Just as the auditor's walkthrough reveals security gaps without actually exploiting them, Network Access Analyzer uses a static analysis of your VPC configuration to find unintended access without sending any live traffic.
What is VPC Network Access Analyzer?
VPC Network Access Analyzer is a feature within Amazon VPC that enables you to identify unintended network access to your resources. It performs a static analysis of your VPC configurations—including security groups, network ACLs, route tables, and VPC endpoints—to determine which network paths are possible between your resources and external networks. The analyzer does not send live traffic; instead, it uses the AWS network configuration to model all possible paths and checks them against your specified network access requirements. This helps you detect overly permissive rules, such as a security group allowing SSH from 0.0.0.0/0, or a network ACL that permits inbound traffic from anywhere on port 22.
Why It Exists
Before Network Access Analyzer, administrators had to manually review security group rules and network ACLs, which is error-prone at scale. For example, a single misconfigured security group rule can expose an EC2 instance to the internet. Network Access Analyzer automates this audit, providing a comprehensive report of findings that can be integrated into compliance workflows (e.g., AWS Security Hub, AWS Config). The exam expects you to know when to use this tool versus other analysis methods like VPC Flow Logs or Reachability Analyzer.
How It Works Internally
Network Access Analyzer uses the concept of a network access scope. This scope defines the source and destination endpoints and the traffic direction (ingress or egress). The analyzer then examines the VPC configuration to determine all possible paths between those endpoints. It considers:
Security group rules (inbound and outbound)
Network ACL rules (inbound and outbound)
Route tables (including subnet associations and main route table)
VPC peering connections
Transit gateway attachments
VPC endpoints (Gateway and Interface endpoints)
Internet gateways, NAT gateways, virtual private gateways
The analysis is performed without sending any packets; it is a logical deduction based on the configuration. The result is a list of findings that indicate whether a path is allowed or denied. Each finding includes details such as the source, destination, protocol, port range, and the specific rules that allow or deny the traffic.
Key Components and Defaults
- Network Access Scope: A container that defines the scope of the analysis. It includes:
- Source: Can be a VPC, subnet, network interface, or an external IP range.
- Destination: Similar to source.
- Traffic Direction: Ingress (into the destination) or egress (out of the source).
- Protocol and Port Range: Optional filters to narrow the analysis.
- Findings: Each finding represents a network path that matches the scope. Findings have a status: PASS (no unintended access) or FAIL (unintended access detected). For FAIL, the analyzer provides a list of reasons, such as a specific security group rule.
- Default Limits: You can create up to 100 scopes per region per account. Each scope can have up to 1000 findings. These limits are adjustable via Service Quotas.
- Cost: There is no additional charge for using Network Access Analyzer; you only pay for standard VPC resources.
Configuration and Verification
To use Network Access Analyzer, you must first create a network access scope. This can be done via AWS Management Console, AWS CLI, or SDK. Below is an example using AWS CLI:
aws ec2 create-network-insights-access-scope \
--match-paths 'Source={"ResourceStatement":{"ResourceTypes":["AWS::EC2::VPC"]}}' \
--destination '{"ResourceStatement":{"ResourceTypes":["AWS::EC2::VPC"]}}' \
--protocol 6 --port-ranges From=22,To=22This creates a scope that analyzes TCP port 22 (SSH) traffic between any two VPCs in the account. After creation, you can start the analysis:
aws ec2 start-network-insights-access-scope-analysis --network-insights-access-scope-id scope-1234567890abcdef0The analysis returns a list of findings. To view findings:
aws ec2 describe-network-insights-access-scope-analyses --network-insights-access-scope-id scope-1234567890abcdef0Findings include the status and a list of PathComponents that detail each hop in the path.
Interaction with Related Technologies
Network Access Analyzer complements other VPC analysis tools:
VPC Flow Logs: Capture actual traffic, useful for monitoring but not for proactive auditing. Analyzer is proactive.
Reachability Analyzer: Tests specific paths by sending synthetic traffic (using AWS infrastructure). It is more targeted and can test paths that may not be in the configuration (e.g., after a change). Analyzer is broader and checks all possible paths within a scope.
AWS Config: Can evaluate security group rules against desired configurations, but does not analyze network paths. Analyzer provides path-level insights.
On the exam, you may be asked to choose the right tool for a scenario. For example, if the question asks for a way to identify all EC2 instances that are accessible from the internet on port 22, Network Access Analyzer is the correct choice because it can scan all paths from external IPs to your instances.
Detailed Steps of Analysis
The analyzer follows these internal steps: 1. Gather Configuration: Retrieve all relevant VPC resources (security groups, NACLs, route tables, etc.) for the specified scope. 2. Model Network Graph: Construct a logical graph of all possible paths between source and destination, considering all routing and filtering rules. 3. Evaluate Rules: For each possible path, check each firewall rule (security group, NACL) to determine if traffic is allowed. 4. Generate Findings: For each path that matches the scope, create a finding with PASS or FAIL status. If FAIL, include the specific rules that cause the unintended access. 5. Report: Findings are stored and can be retrieved via API or console.
Common Pitfalls and Edge Cases
Transitive Routing: The analyzer considers transitive routing through VPC peering or transit gateway. For example, if VPC A is peered with VPC B, and VPC B is peered with VPC C, the analyzer will consider paths from A to C via B if routing allows.
Security Group Statefulness: The analyzer correctly models that security groups are stateful—if you allow outbound traffic, the corresponding return traffic is automatically allowed. However, the analyzer only reports on the direction specified in the scope.
Network ACL Statelessness: NACLs are stateless, so both inbound and outbound rules must allow traffic. The analyzer checks both directions.
External IPs: You can specify an external IP range as source or destination. The analyzer will check paths that traverse an internet gateway or NAT gateway.
Performance and Scale
For large VPCs with many resources, the analysis may take several minutes. The analyzer has a maximum of 1000 findings per scope. If your configuration has more than 1000 paths, you may need to narrow the scope using filters (e.g., specific protocol, port, or subnet).
Security Best Practices
Regularly run Network Access Analyzer to audit your VPCs, especially after changes.
Integrate findings with AWS Security Hub for centralized alerting.
Use the analyzer to validate that security groups follow the principle of least privilege.
Combine with AWS Config rules to enforce that security groups do not have overly permissive rules.
Exam Relevance
The SOA-C02 exam tests your ability to:
Identify the correct use case for Network Access Analyzer (proactive auditing of network paths).
Distinguish it from Reachability Analyzer (on-demand path testing) and VPC Flow Logs (monitoring actual traffic).
Interpret findings to determine which resources are exposed.
Recognize that the analyzer does not send live traffic and does not affect performance.
Know that there is no additional cost for the analyzer itself.
Summary
VPC Network Access Analyzer is a powerful tool for security auditing. It provides a comprehensive view of all possible network paths, helping you identify and remediate unintended access. For the exam, focus on its purpose, how it differs from similar tools, and how to configure and interpret its findings.
Define Network Access Scope
Create a network access scope that specifies the source, destination, traffic direction, and optionally protocol/port. The source and destination can be VPCs, subnets, network interfaces, or external IP ranges. For example, to check for SSH access from the internet to all EC2 instances, set source to 0.0.0.0/0, destination to your VPC, protocol TCP, port 22. This scope acts as the filter for the analysis.
Start the Analysis
Initiate the analysis using the AWS CLI, SDK, or Console. The analyzer will gather the current VPC configuration, including all security groups, NACLs, route tables, and attachments. It does not send any packets; it performs a static analysis of the configuration. The analysis may take some time depending on the size of the VPC. You can run multiple analyses on the same scope.
Model All Possible Paths
Internally, the analyzer builds a graph of all possible network paths between the source and destination. It considers every combination of routes and firewall rules. For each path, it checks if traffic is allowed based on security group and NACL rules. It also accounts for transitive routing via VPC peering or transit gateway. The result is a set of findings, each representing a unique path.
Review Findings
Once the analysis completes, you can retrieve the findings. Each finding has a status: PASS (no unintended access) or FAIL (unintended access detected). For FAIL findings, the analyzer provides details such as the specific security group rule or NACL rule that allows the traffic. It also shows the network path components (e.g., internet gateway, subnet, ENI). You can view findings in the Console or via CLI.
Remediate and Re-analyze
Based on the findings, modify your security group or NACL rules to remove unintended access. For example, if a security group allows SSH from 0.0.0.0/0, change it to allow only specific IPs. After making changes, rerun the analysis on the same scope to verify that the findings are now PASS. This iterative process helps ensure your VPC is secure.
Enterprise Scenario 1: Compliance Audit for Financial Services
A financial services company must comply with PCI DSS, which requires that all cardholder data environments (CDE) are isolated from the internet. The company has multiple VPCs, some containing CDE resources. Using Network Access Analyzer, they create a scope that checks for any path from 0.0.0.0/0 to the CDE VPC on any protocol. The analyzer reveals that a developer accidentally added a security group rule allowing HTTP (port 80) from 0.0.0.0/0 to a web server in the CDE VPC. The team remediates by removing the rule and re-analyzes to confirm no internet access. This automated audit saves hours of manual review and ensures compliance evidence is available for auditors.
Enterprise Scenario 2: Multi-account VPC Peering Security
A large enterprise uses a hub-and-spoke VPC architecture with a transit gateway. They want to ensure that no spoke VPC can directly access another spoke VPC unless explicitly allowed. They create a Network Access Analyzer scope that checks for paths between spoke VPCs. The analysis finds that a route table in one spoke VPC has a route to the transit gateway that inadvertently allows traffic to another spoke VPC's CIDR. The security team updates the route table to add a more specific route that denies the inter-spoke traffic. This proactive detection prevents potential data leaks.
Common Misconfigurations and Pitfalls
Overly Permissive Security Groups: The most common finding is a security group rule that allows 0.0.0.0/0 on SSH or RDP. This is often left from testing. Network Access Analyzer catches this immediately.
Incorrect NACL Rules: Since NACLs are stateless, you must ensure both inbound and outbound rules allow traffic. A common mistake is allowing inbound on port 443 but forgetting the outbound ephemeral port range. The analyzer will flag this as a FAIL because the path is incomplete.
Transitive Routing Surprises: With VPC peering, you might not realize that a path exists through a peered VPC to another VPC. The analyzer reveals these hidden paths.
Performance Considerations
In large environments with hundreds of VPCs and thousands of security group rules, the analysis can take up to 10 minutes. To manage this, scope the analysis narrowly—for example, by specific subnet or protocol. Also, note that findings are limited to 1000 per scope; if you exceed that, you must refine the scope.
What the SOA-C02 Exam Tests
The SOA-C02 exam (Objective 5.1) expects you to understand the purpose and use of VPC Network Access Analyzer. Specifically, you should be able to:
Differentiate between Network Access Analyzer, Reachability Analyzer, and VPC Flow Logs.
Identify scenarios where Network Access Analyzer is the correct tool (e.g., proactive auditing of all paths).
Interpret findings to determine which resources are exposed.
Know that it does not send live traffic and does not incur additional costs.
Common Wrong Answers
Choosing VPC Flow Logs instead of Network Access Analyzer: Candidates often think flow logs can identify unintended access, but flow logs only show actual traffic; they cannot predict paths that haven't been used. Network Access Analyzer is proactive.
Thinking Reachability Analyzer is the same: Reachability Analyzer tests specific paths between two resources, but it does not scan all possible paths. Network Access Analyzer is designed for broad audits.
Believing it sends test traffic: Some candidates think the analyzer sends packets to test connectivity. In reality, it is a static analysis of configuration.
Assuming it can modify security groups: The analyzer is read-only; it only reports findings. Remediation is manual or via other tools like AWS Config.
Key Numbers and Terms
Scope: The container for analysis.
Findings: Each finding has a status: PASS or FAIL.
PathComponents: Details of each hop in the path.
Default limit: 100 scopes per region, 1000 findings per scope.
No additional cost: You only pay for standard VPC resources.
Edge Cases
VPC Endpoints: The analyzer considers Gateway Endpoints (S3, DynamoDB) and Interface Endpoints. For example, if an S3 Gateway Endpoint is attached to a subnet, the analyzer will consider paths that use it.
Egress-only Internet Gateway: For IPv6, the analyzer can check paths through egress-only internet gateways.
NAT Gateway: The analyzer correctly models that NAT gateways allow outbound traffic but not inbound from the internet.
How to Eliminate Wrong Answers
If the question asks for a way to find all resources accessible from the internet, eliminate options that mention specific path testing (Reachability Analyzer) or actual traffic (Flow Logs).
If the question mentions proactive auditing or compliance, Network Access Analyzer is the answer.
If the question mentions cost, remember that Network Access Analyzer is free.
Exam Tips
Always read the scenario carefully: if it says "identify all network paths" or "audit for unintended access," choose Network Access Analyzer.
If it says "test connectivity between two specific instances," choose Reachability Analyzer.
If it says "capture traffic logs for analysis," choose VPC Flow Logs.
VPC Network Access Analyzer performs static analysis of VPC configurations to identify unintended network access.
It does not send live traffic; it models all possible paths based on security groups, NACLs, route tables, and attachments.
The analysis is defined by a network access scope, which specifies source, destination, direction, and optional protocol/port.
Findings have status PASS or FAIL; FAIL findings include the specific rules causing unintended access.
Default limits: 100 scopes per region, 1000 findings per scope (adjustable via Service Quotas).
There is no additional cost for using Network Access Analyzer.
It is ideal for proactive security audits and compliance, unlike Reachability Analyzer (specific path testing) and VPC Flow Logs (actual traffic monitoring).
The analyzer considers transitive routing through VPC peering and transit gateways.
Use the AWS CLI command 'start-network-insights-access-scope-analysis' to initiate analysis.
The analyzer is read-only; remediation of findings must be done manually or via automation.
These come up on the exam all the time. Here's how to tell them apart.
VPC Network Access Analyzer
Scans all possible paths within a defined scope (e.g., all paths from internet to VPC).
Static analysis; no live traffic sent.
Best for proactive security audits and compliance checks.
Reports findings as PASS/FAIL with details on permissive rules.
No additional cost.
VPC Reachability Analyzer
Tests a specific path between two resources (e.g., from EC2 A to EC2 B).
Sends synthetic traffic using AWS infrastructure to verify connectivity.
Best for troubleshooting specific connectivity issues.
Returns reachable or not reachable with hop-by-hop details.
No additional cost.
Mistake
Network Access Analyzer sends test packets to verify connectivity.
Correct
It performs a static analysis of the VPC configuration without sending any live traffic. It models all possible paths based on security groups, NACLs, route tables, etc.
Mistake
Network Access Analyzer can automatically remediate security group rules.
Correct
It is a read-only tool that only reports findings. Remediation must be done manually or through automation using other services like AWS Config or Lambda.
Mistake
Network Access Analyzer and Reachability Analyzer are the same service.
Correct
Reachability Analyzer tests specific paths between two resources by sending synthetic traffic. Network Access Analyzer scans all possible paths within a scope and is used for broad audits.
Mistake
Network Access Analyzer incurs additional charges per analysis.
Correct
There is no additional cost for using Network Access Analyzer. You only pay for the underlying VPC resources.
Mistake
Network Access Analyzer only works for EC2 instances.
Correct
It works for any resource with an elastic network interface (ENI), including RDS, Lambda (in VPC), and ALB/NLB. It also considers VPC endpoints and external IP ranges.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Network Access Analyzer scans all possible paths within a defined scope (e.g., all paths from the internet to your VPC) to identify unintended access. It is a static analysis that does not send traffic. Reachability Analyzer tests a specific path between two resources by sending synthetic traffic. Use Network Access Analyzer for security audits and compliance; use Reachability Analyzer for troubleshooting specific connectivity issues.
No, there is no additional charge for using VPC Network Access Analyzer. You only pay for the underlying VPC resources such as EC2 instances, NAT gateways, etc. The analysis itself is free.
No, it is a read-only tool. It reports findings but does not modify any configuration. You must manually update security groups, NACLs, or route tables based on the findings, or use automation tools like AWS Config or Lambda to remediate.
First, create a network access scope using 'create-network-insights-access-scope'. Then start the analysis with 'start-network-insights-access-scope-analysis'. For example: aws ec2 start-network-insights-access-scope-analysis --network-insights-access-scope-id scope-1234567890abcdef0. Use 'describe-network-insights-access-scope-analyses' to view findings.
It supports any resource with an elastic network interface (ENI), such as EC2 instances, RDS databases, Lambda functions in a VPC, Application Load Balancers, Network Load Balancers, and VPC endpoints. It also considers internet gateways, NAT gateways, virtual private gateways, VPC peering connections, and transit gateway attachments.
Yes. You can create a scope with source set to an external IP range (e.g., 0.0.0.0/0) and destination set to your VPC. The analyzer will check all paths that could originate from the internet, including through an internet gateway or a NAT gateway (for outbound-only scenarios).
A FAIL finding indicates that there is a network path that matches your scope and that traffic is allowed by the current configuration. This typically means there is unintended access. The finding includes details such as the specific security group rule or NACL rule that allows the traffic, along with the network path components.
You've just covered VPC Network Access Analyzer — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?