Business Challenge
“Network Access Analyzer is a feature that identifies unintended network access to your resources on AWS.” It works differently from every manual review of security groups and route tables, and the difference is stated plainly:
“Network Access Analyzer uses automated reasoning algorithms to analyze the network paths that a packet can take between resources in an AWS network. It then produces findings for paths that match a customer defined Network Access Scope.”
So it reasons rather than probes: “Network Access Analyzer performs a static analysis of a network configuration, meaning that no packets are transmitted in the network as part of this analysis.”
That is a genuinely different kind of answer from a connectivity test. It is also bounded in ways worth knowing before you treat a clean run as a clean bill of health.
The definition of a finding is narrow and precise:
“A Network Access Analyzer finding is a network path that a packet can take in a network.”
And elsewhere on the same page, the sentence that decides what a result means:
“Network Access Analyzer makes a best effort attempt to return a diverse, representative set of findings from among all possible findings.”
Read those together. A finding is positive evidence — this path exists. The set of findings is described as representative rather than complete, which means the tool is not offering to list every path that matches your scope.
That matters because of what people do with the output. "We ran Network Access Analyzer and it found three paths, we fixed all three, the next run was clean" is a sequence that feels like closure and is not the same as "there are no paths". The documented claim supports the first reading and not the second.
FixUse it to find things, not to prove their absence. A finding is actionable on its own; an empty result is a weaker statement than it looks, and the right next question is whether the scope was drawn to match what you were worried about. Where you need an assertion about absence, the control that produces one is a policy that prevents the configuration, not a scan that did not report it.
“Not all AWS network configurations are supported by Network Access Analyzer.” The list is specific, and two entries on it are the kind of thing a security review is usually about.
“Network Access Analyzer does not produce network paths through resources that are associated with Amazon API Gateway, AWS Global Accelerator, Traffic Mirroring, AWS Wavelength, or AWS Direct Connect.”
“Network Access Analyzer can't produce network paths containing customer managed Amazon EC2 instances that modify packet forwarding behavior.”
That second one covers anything you run yourself that forwards traffic. And on the edge: “Network Access Analyzer supports internet gateways and virtual private gateways at the beginning or end of a path, but does not report paths that pass through internet gateways or virtual private gateways.” Plus “does not support NAT reflection at internet gateways”, “does not support advanced forwarding rules” on Application Load Balancers, and no support for “nested Resource Groups”.
Each exclusion is defensible — AWS explains the gateway one as resources being “outside of AWS networking and therefore out of scope”. The point is cumulative rather than individual: the unsupported list is the second reason an empty result is not a proof.
FixWrite the unsupported list down next to your scope definitions, and check it against your own topology once. If you run a forwarding appliance on EC2, or reach workloads through Direct Connect or API Gateway, you know which part of your network this tool is not describing — and that is a more useful thing to know than any single finding.
“A Network Access Scope defines outbound and inbound traffic patterns, including sources, destinations, paths, and traffic types.” Structurally: “Each Network Access Scope consists of one or more match conditions, and zero or more exclusion conditions.”
The combination rule is what to hold onto: “It identifies network paths in the Network Access Scope that match at least one of the match conditions, and none of the exclude conditions.” And across multiple matches: “it produces findings for any path that satisfies at least one of the match conditions.”
So matches are a union and exclusions veto. Which means an exclusion condition is the most powerful
thing in the scope — and the through field is the broadest of those:
“It excludes paths that contain the specified network component anywhere along the
path, not just at the beginning or end.”
A through exclusion naming a firewall is exactly how you ask "show me paths that bypass
the firewall", which is the right use. It is also how a scope can return nothing while paths exist,
if the excluded component is more common along your paths than whoever wrote the scope expected.
Treat the scope as the artifact under review, not just the findings. Before accepting an empty result, read the exclusions and ask what fraction of your paths they remove. A scope with a broad through exclusion and no findings has told you very little.
Architecture
A reasoning engine over configuration, a scope that poses the question, and two bounds on what the answer covers.
What static analysis buys, and what it sets aside
The trade is explicit: “Because Network Access Analyzer only considers the state of the network as described in the network configuration, packet loss that is due to transient network interruptions or service failures is not considered in the analysis.”
That is the right trade for the question being asked. A connectivity test tells you whether a packet got through at one moment; reasoning over configuration tells you whether the configuration permits a packet at all. The second is the security question, and it does not require the path to be exercised — which is why it can find paths nobody has used yet.
Where a path may start, and where it may pass
Two different lists, and the start-or-end list is the shorter one. Findings “can only produce findings for network paths that start or end at” internet gateways, network interfaces, transit gateway attachments, the VPC endpoint types, VPC peering connections and virtual private gateways.
Paths may pass through a wider set, which adds load balancers, NAT gateways, network ACLs, network firewalls, route tables, security groups, target groups and transit gateway route tables.
Reading those two lists against each other is the quickest way to see what kind of question the tool is built to answer: endpoints are interfaces and gateways, and the middle of a path is where the controls live.
One is about completeness: the result is “a diverse, representative set… from among all possible findings”. The other is about coverage: “Not all AWS network configurations are supported”.
A scan can therefore miss a path either because it did not enumerate it or because that class of path is not analysed. Neither is a defect, and both are reasons to read an empty result as "nothing surfaced" rather than "nothing exists".
Why This Architecture Holds Up
Saying "best effort" and "representative" in the documentation is the honest choice
A service doing automated reasoning over a large configuration space could easily describe its output as "all paths matching your scope" and leave the sampling unstated. This one does the opposite, in the overview of how it works rather than in a limitations appendix. That sentence is what lets a reader calibrate the result instead of over-trusting it.
The same applies to the unsupported list. It is long, specific, and includes items that are uncomfortable to disclose — API Gateway and Direct Connect are not obscure.
Making exclusions veto rather than subtract is the right rule
Matches union and exclusions veto, and the through field reaches
“anywhere along the path”. That combination is what makes the useful question
expressible: show me paths from the internet to this subnet that do not traverse the firewall.
A subtractive rule scoped only to endpoints could not ask it.
The cost is that the same expressiveness lets a scope be accidentally narrow, which is why the scope belongs in review alongside the findings.
Not transmitting packets is what makes it safe to run broadly
“no packets are transmitted in the network as part of this analysis” means the analysis has no blast radius. There is no scan traffic, nothing to whitelist, and no risk of a probe being mistaken for an intrusion. For a control you want running against production regularly, that property is worth more than it sounds.
Key Architecture Decisions
| Decision | Choice | Reasoning |
|---|---|---|
| What a finding means | Evidence that a path exists | “a network path that a packet can take in a network”. |
| What an empty result means | Nothing surfaced — not nothing exists | The set is “a diverse, representative set… from among all possible findings”. |
| Using it for compliance evidence | Cite findings, not their absence | Both documented bounds apply to an empty run. |
| Self-run forwarding appliances | Expect them to be invisible | No paths “containing customer managed Amazon EC2 instances that modify packet forwarding behavior”. |
| Direct Connect and API Gateway reachability | Out of scope; use another method | Both are on the unsupported list. |
| Paths crossing the internet | Not reported | Gateways are supported at the ends, not as transit. |
| Scope review | Review the scope as well as the findings | Exclusions veto, and through reaches anywhere along a path. |
| Run frequency | As often as you like | No packets are transmitted, so there is no blast radius. |
| Transient failures | Not modelled, and should not be | The question is what the configuration permits. |
The audit worth running
Take the unsupported list and walk your own topology against it once. Do you run an EC2 instance that forwards packets? Do you reach anything over Direct Connect, or through API Gateway, or behind Global Accelerator? Each yes marks a region of your network this tool is not describing, and that map is worth more than any individual finding because it tells you where to use something else.
Then read every Network Access Scope you have and total up its exclusion conditions, paying attention to
any through entry. A scope that excludes a component sitting on most of your paths will
return few findings for a reason that has nothing to do with your security posture.
Closing Thought
The useful thing about this service is the question it can answer that a security group review cannot: not "is this rule correct" but "does a packet have a route". Automated reasoning over configuration can surface paths nobody has exercised, and it does it without sending anything.
The thing to carry is the shape of the answer. A finding is a positive claim and a strong one. An empty result is bounded twice over — once by sampling, once by coverage — and AWS writes both bounds into the page that explains how the tool works rather than leaving them to be discovered.
That makes it the opposite of the pattern the last several posts have found. In #89 and #88 the risk was a mechanism that looked like a guarantee. Here the mechanism is weaker than it looks and says so, which puts the whole burden on the reader to not over-read a clean run.
Security & Identity — AWS Firewall Manager: what a policy actually does on an account that already has conflicting configuration, why remediation is a setting rather than a default, and what happens to protected resources when an account leaves the organization.
Official AWS Reference
- How Network Access Analyzer works — the automated reasoning description, the definition of a finding, the static-analysis statement and what it sets aside, the best-effort representative-set sentence, the supported start, end and path resource lists, and the unsupported resources and network configurations including API Gateway, Global Accelerator, Traffic Mirroring, Wavelength, Direct Connect, customer managed forwarding instances, gateway transit, NAT reflection, ALB advanced forwarding rules and nested Resource Groups
- Network Access Scopes — what a scope defines, its composition from match and exclusion conditions, and the rule that findings must match at least one match condition and none of the exclude conditions
- Match conditions — that a scope must specify at least one, and that multiple match conditions produce findings for any path satisfying at least one of them
- Exclusion conditions — the optional source, destination and through fields, and that a through entry excludes paths containing the component anywhere along the path
- What is Network Access Analyzer — the service description and the requirement-verification framing
- Example Network Access Scopes — further reading on scope authoring; no claims in this post are drawn from it
Comments