AWS Network Access Analyzer: Prove Your Network Is Secure Before Your Auditor Does

You have security groups. You have NACLs. You have route tables — but do you actually know whether an unintended path exists from the internet to your production database?

Abhishek V

Published Jun 17, 2026

Last modified Jun 17, 2026

SECTION 01 - The Problem.

Your Controls Exist. Your Paths Are Unverified.

Most AWS teams build network security in layers: security groups control instance-level access, NACLs guard subnet boundaries, and route tables direct traffic. On paper the architecture looks secure. But controls and paths are two different things.

KEY INSIGHT- None of these tools tell you whether an unintended network path exists across your entire VPC topology.

Consider a common scenario: an engineer adds a temporary default route to an internet gateway during a production incident to restore connectivity quickly. The incident is resolved, the ticket is closed, but the route is never removed. Weeks later, a peering connection is added between a dev VPC and the production VPC. Nobody realises that the combination of these two changes has created a traversable path from the internet to a production RDS instance.

This is the gap AWS Network Access Analyzer fills. It does not just check your rules — it analyses your actual network topology and tells you whether any path exists that violates your security policy.

-------------------------------------------------------------------------------------------------------------

SECTION 02 - CHOOSING THE RIGHT TOOL

Network Access Analyzer vs Similar-Sounding Tools

Before diving in, it is worth clarifying what makes Network Access Analyzer different from the other network visibility tools in AWS. They are frequently confused but answer completely different questions:

Tool	The Question It Answers	When To Use It
Reachability Analyzer	Can instance A reach instance B?	Debugging a specific broken connection
Network Access Analyzer	Does any path exist violating policy X?	Compliance audit, proactive security review
VPC Flow Logs	What traffic actually happened?	Post-incident forensics, traffic monitoring
Security Groups / NACLs	What should be allowed or denied?	Defining and enforcing access controls

-------------------------------------------------------------------------------------------------------------

SECTION 03 - HOW IT WORKS

Topology Analysis Without Sending a Single Packet

Network Access Analyzer reads your VPC configuration - every route table, security group, NACL, peering connection, and Transit Gateway attachment - and performs a graph traversal to find paths matching your defined scope. No traffic is generated. No agents are required. No impact on running workloads.

01	Define a Network Access Scope. A policy describing the paths you want to find. AWS provides pre-built managed templates to get started instantly, or you can build a custom scope using the visual scope builder in the console.

02	AWS analyses your entire VPC topology. It reads all route tables, security groups, NACLs, and peering connections without sending any traffic.

03	Findings are returned. Each finding is a real, traversable network path. AWS shows every hop: IGW -> subnet -> security group -> resource.

04	Remediate or suppress. Fix the misconfiguration and re-run to confirm the finding is cleared. Mark intentional paths as exceptions.

-------------------------------------------------------------------------------------------------------------

SECTION 04 - PREREQUISITES

What You Need Before Starting

To follow the hands-on lab you will need:

· An AWS account with permissions to create VPCs, subnets, route tables, security groups, internet gateways, RDS instances, and VPC peering connections.

· IAM permissions including:
ec2:CreateNetworkInsightsAccessScope,
ec2:StartNetworkInsightsAccessScopeAnalysis, ec2:GetNetworkInsightsAccessScopeAnalysisFindings.

· AWS CLI configured (optional - all steps can be done via the console).

· Estimated lab cost: under $1 USD. The RDS instance is the main cost driver - delete it promptly after the lab.

NOTE: Network Access Analyzer is accessed via AWS Network Manager in the console, not the VPC Console directly. Navigate to Network Manager -> Security and governance -> Network Access Analyzer.

-------------------------------------------------------------------------------------------------------------

SECTION 05 - HANDS-ON LAB

Build a Misconfigured Environment and Catch It

The best way to learn Network Access Analyzer is to run it against a deliberately misconfigured environment. We will create two VPCs - one representing dev, one representing prod - with an RDS instance in the prod VPC that has an intentionally open security group. We will then introduce a bad route to make it internet-reachable, detect it, fix it, and verify the fix.
-------------------------------------------------------------------------------------------------------------

Step 1 - Find Network Access Analyzer in the Console

Network Access Analyzer lives under AWS Network Manager, not the VPC Console. Navigate to:

AWS Console -> Search for 'Network Manager' -> Security and governance -> Network Access Analyzer

You will see the Network Access Analyzer home page shown below, with a 'Get started' button and a diagram explaining how the service works.

Network Access Analyzer home page

-------------------------------------------------------------------------------------------------------------

Step 2 - Create the Lab Infrastructure

Create the following resources in your AWS account (us-east-1 recommended):

· VPC-Dev: Create a VPC with a public subnet. Attach an Internet Gateway and add a default route to it in the subnet route table. This represents your development environment.

· VPC-Prod: Create a second VPC with a private subnet only. No Internet Gateway. This represents your production environment.

· RDS Instance: Launch an RDS MySQL db.t3.micro instance in VPC-Prod's private subnet. Create a dedicated security group allowing inbound port 3306 from anywhere - this is the deliberate misconfiguration.

·VPC Peering: Create a peering connection between VPC-Dev and VPC-Prod. Accept it and add routes in both VPCs so traffic can flow across.

Tag all resources with Environment=dev or Environment=prod as appropriate.

-------------------------------------------------------------------------------------------------------------

Step 3 - Create a Custom Network Access Scope

Go to Network Access Analyzer and click Create scope. You will see the scope template picker shown below. Select 'Identify access from internet gateways' - this template is pre-configured to find paths from internet gateways to resources in your VPCs.

Network Access Scope template picker. Select the first option to identify internet gateway access.

On the next screen, configure the scope conditions:

· Source: Internet Gateways (pre-selected by default)

· Destination: Select 'Resource types' and choose 'Network Interfaces'

Give the scope a name such as 'Prod-Access-Analyzer' and click Create.

-------------------------------------------------------------------------------------------------------------

Step 4 - Run the Baseline Analysis

Select your new scope and click Analyze. The analysis takes 2-5 minutes. Once complete, check the Latest analysis tab. At this stage - before introducing any misconfiguration - the result should show No findings detected as shown below. This is your clean baseline.

No findings detected on the baseline analysis. The scope is running correctly but no internet-reachable path to RDS exists yet.

-------------------------------------------------------------------------------------------------------------

Step 5 - Introduce the Misconfiguration

Now simulate a real-world mistake. In VPC-Prod, first create and attach an Internet Gateway. Then go to the private subnet route table and add a route pointing all traffic to that internet gateway.

Additionally, go to the RDS instance -> Modify -> Connectivity and set Public accessibility to Yes. Apply immediately. This combination - a public route plus an open security group plus public RDS accessibility - creates a complete internet-reachable path.

NOTE: In a real environment you would never intentionally do all three of these things together. This lab deliberately combines them to create a finding that clearly demonstrates what Network Access Analyzer catches.

-------------------------------------------------------------------------------------------------------------

Step 6 - Re-run the Analysis and Review the Finding

Go back to Network Access Analyzer, select your scope, and click Analyze again. This time the analysis will return a finding. Click into the finding to see the full hop-by-hop path as shown below.

Finding detail showing the complete hop-by-hop path: Internet Gateway -> Network ACL -> Security Group (port 3306 open to all) -> RDS Network Interface. Each hop shows exactly which resource and rule is involved.

The path visualisation shows every component involved in creating the unintended access: the internet gateway, the network ACL rule that allows traffic, the security group rule that permits port 3306 from anywhere, and finally the network interface of the RDS instance. This is exactly the information you need to identify and fix the root cause.

-------------------------------------------------------------------------------------------------------------

Step 7 - Fix the Misconfiguration and Verify

Fix the two root causes:

· Remove the catch-all route from the VPC-Prod private subnet route table.

· Set the RDS instance Public accessibility back to No (Modify -> Connectivity -> Apply immediately).

Once both changes are applied, go back to Network Access Analyzer and run the analysis one final time. The result should return to No findings detected as shown below, confirming the misconfiguration has been fully remediated.

No findings detected after fixing the misconfiguration. The analysis confirms the internet-reachable path has been closed.

RESULT: This is the remediation loop that makes Network Access Analyzer valuable in practice: detect, fix, verify. The whole cycle - introducing the misconfiguration, detecting it, fixing it, and confirming the fix - took under 10 minutes.

-------------------------------------------------------------------------------------------------------------

Step 8 - Clean Up

To avoid ongoing charges, delete the following resources after completing the lab:

· RDS instance in VPC-Prod (this is the main cost driver).

· DB Subnet Group created for the RDS instance.

· VPC Peering Connection between Dev and Prod.

· Internet Gateway attached to VPC-Prod (detach first, then delete).

· Both VPCs (VPC-Dev and VPC-Prod) and their associated subnets and route tables.

· The Network Access Scope you created (free to keep but good practice to clean up).

-------------------------------------------------------------------------------------------------------------

SECTION 06 - RUNNING IT REGULARLY

Making It Part of Your Workflow

Running an analysis manually is useful for a point-in-time audit. The real value comes from treating it as a consistent part of your engineering workflow.

When to Run	What to Check
Before every production deployment	Run your scopes as a pre-deployment network sanity check.
After any route table or SG change	Re-run to catch any new unintended paths introduced.
After adding VPC peering or TGW routes	Run to detect unintended lateral access between environments.
Weekly scheduled sweep	Run all scopes and review new findings at a standing meeting.
When inheriting an unknown AWS account	Run AWS-managed scopes for a quick baseline of exposure.

-------------------------------------------------------------------------------------------------------------

SECTION 07 - KNOW THE LIMITS

What It Does Not Do

Limitation	What It Means	Mitigation
Not real-time	Analysis runs on-demand - not a continuous live monitor.	Run after key infrastructure changes.
Topology only	Reads config, not traffic. Cannot tell if a path is actively used.	Combine with VPC Flow Logs.
No L7 awareness	WAF rules and ALB routing are invisible to it.	Complement with AWS WAF and Shield.
Org scope needs setup	Cross-account analysis requires delegated admin configuration.	Delegate from the management account.

-------------------------------------------------------------------------------------------------------------

Use Network Access Analyzer When...

· Running a compliance audit - find unintended internet-reachable paths before your auditor does.

· After any infrastructure change touching route tables, peering connections, or security groups.

· Before launching a new environment as part of your production readiness checklist.

· When you inherit an unfamiliar AWS account and need to understand its real network exposure.

· Alongside Reachability Analyzer for a complete two-tool network security picture.
-------------------------------------------------------------------------------------------------------------

BOTTOM LINE Security groups and NACLs define your intent. Network Access Analyzer verifies your reality. Use it regularly and you will catch misconfigurations in minutes, not months.

# advanced-networking # network-security # network-acl # security # security-and-compliance

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

AWS Network Access Analyzer: Prove Your Network Is Secure Before Your Auditor Does

Abhishek V