AWS Shield Network Security Director: Centralized Network Security Posture for Multi-Account Organizations

Why This Matters

If you're running a multi-account AWS environment with Landing Zone Accelerator (LZA), you already know the challenge: dozens of accounts, hundreds of VPCs, thousands of security groups, and no single place to answer "is my network secure?"

Today, getting that answer requires stitching together data from multiple services — Security Hub, GuardDuty, AWS Config, VPC Flow Logs, and manual reviews of WAF configurations. Network Security Director aims to collapse that into a single console with automatic discovery, topology visualization, and prioritized findings.

Announced at AWS re:Inforce 2025 (June 17, 2025) and expanded with multi-account support in December 2025, NSD is still in public preview but already shows the direction AWS is heading: making network security posture as easy to assess as compliance posture is with Security Hub.

What Is Network Security Director?

Network Security Director is a capability within the AWS Shield product family that provides network security posture management (NSPM). It does three things:

1. Discovers — Automatically finds compute, networking, and security resources across your accounts and regions
2. Analyzes — Evaluates configurations against AWS best practices and known threat patterns (DDoS, SQLi, XSS)
3. Recommends — Provides prioritized findings with step-by-step remediation guidance

Think of it as a security-focused version of Resource Explorer, but instead of just finding resources, it tells you what's wrong with how they're configured.

Key Characteristics

Attribute	Detail
Service family	AWS Shield (but independent of Shield Advanced)
Status	Public preview
Cost	Free during preview (pricing TBD at GA)
Requires Shield Advanced?	No
Multi-account support	Yes, via delegated administrator + AWS Organizations
Console URL	console.aws.amazon.com/wafv2/network-security-director/
Analysis type	Continuous (multi-account) or on-demand (single account)
AI integration	Amazon Q Developer for natural-language security queries

What NSD Discovers

NSD's service-linked role has permissions for 94 IAM actions across a wide range of services. Here's what it finds:

Category	Resources
Compute	EC2 instances
Networking	VPCs, Subnets, ENIs, Internet Gateways, NAT Gateways, Route Tables, Transit Gateways (attachments, peerings, route tables), VPC Peering, VPC Endpoints, VPN Gateways, VPN Connections, Customer Gateways, Direct Connect Gateways
Load Balancing	ALBs (listeners, target groups, rules, target health)
CDN	CloudFront distributions
API	API Gateway resources
Network Security	AWS WAF web ACLs (v2 and Classic), WAF rule groups, Managed Rule Groups, AWS Network Firewall (firewalls, policies, rule groups)

What NSD Evaluates

Once resources are discovered, NSD analyzes configurations for these categories of issues:

1. Overly permissive access to EC2 instances — Security groups or NACLs allowing unrestricted access on high-risk ports (SSH/22, RDP/3389)
2. Resources open to the internet — Resources reachable via internet gateways without proper controls
3. Internet-facing resources without WAF protection — Missing WAF, rate-limiting rules, or managed rule groups on ALBs and CloudFront
4. Resources exposed to known threats — Configurations vulnerable to DDoS, SQL injection, or cross-site scripting
5. Unused security services — WAF web ACLs, security groups, or NACLs that aren't protecting any resources

Findings are rated by severity: Critical, High, Medium, Low, and Informational.

Architecture: Multi-Account Setup

NSD follows the same delegated administrator pattern as Security Hub, GuardDuty, and other AWS security services. If you're already running a multi-account LZA environment, this will feel familiar.

Components

• Management account — Designates the delegated administrator. Cannot be the delegated admin itself.
• Delegated administrator account — Runs NSD, creates policies, views findings across all accounts. AWS recommends using the same account you use for Security Hub and GuardDuty.
• Service-linked role — AWSServiceRoleForNetworkSecurityDirector is automatically created in both the management account and delegated admin account.
• Organizations policy — A new policy type controls which accounts, OUs, and regions are enrolled in NSD.

Setup Steps

Step 1: Create IAM Policy in the Delegated Admin Account

The delegated admin needs permissions for NSD operations and Organizations policy management:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["network-security-director:*"],
      "Resource": ["*"]
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:GetRole",
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:aws:iam::*:role/aws-service-role/AWSServiceRoleForNetworkSecurityDirector"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "organizations:ListRoots",
        "organizations:ListOrganizationalUnitsForParent",
        "organizations:ListAccountsForParent",
        "organizations:CreatePolicy",
        "organizations:UpdatePolicy",
        "organizations:DeletePolicy",
        "organizations:AttachPolicy",
        "organizations:DetachPolicy",
        "organizations:EnablePolicyType",
        "organizations:DisablePolicyType",
        "organizations:DescribeOrganization",
        "organizations:DescribePolicy",
        "organizations:ListPolicies",
        "organizations:ListTargetsForPolicy"
      ],
      "Resource": ["*"]
    }
  ]
}

Step 2: Designate the Delegated Administrator

From the management account, open the NSD console and select your delegated admin account. This is a one-time operation.

Step 3: Create a Region and Account Policy

From the delegated admin account, create a policy that specifies which OUs, accounts, and regions NSD should analyze. You can target the entire organization or specific OUs.

Policy inheritance is automatic — accounts joining an OU with an attached NSD policy are automatically enrolled.

Step 4: Analysis Begins

Once the policy is attached, NSD starts continuous analysis. Results appear in the Summary Dashboard with findings, severity ratings, and the network topology map.

The Network Topology Map

This is NSD's standout feature. The console renders an interactive visual graph showing:

• Resource nodes — Each discovered resource (EC2, ALB, VPC, etc.) appears as a node
• Connections — Lines showing how resources are connected (subnet membership, route paths, load balancer targets)
• Internet exposure — A globe icon on any resource with internet gateway connectivity, immediately highlighting public exposure
• Security findings — Click any resource node to see its ID, type, tags, and associated findings

You can filter the topology by resource type, severity level, and resource tags. For a multi-account environment with hundreds of VPCs, this is the first AWS-native service that gives you a visual "map" of your network without third-party tooling.

Amazon Q Developer Integration

After an analysis completes, you can query your network security posture using natural language through Amazon Q Developer. Access it from the NSD Dashboard via the Q button.

Example queries:

• "Are any of my internet-facing resources vulnerable to DDoS?"
• "What are my most critical network security configuration issues?"
• "Do I have any resources without WAF protection?"
• "Which resources are not protected from common web vulnerabilities?"
• "What are the common network security issues on my EC2 instances?"
• "Do I have any WAF web ACLs that aren't protecting anything?"
• "Summarize the network security of my environment"
• "Identify my top network security findings in account 123456789010"

How NSD Relates to Shield Standard and Shield Advanced

NSD is part of the Shield product family but serves a fundamentally different purpose:

Aspect	Shield Standard	Shield Advanced	Network Security Director
Cost	Free (all AWS customers)	$3,000/month + data transfer	Free during preview
Focus	Automatic DDoS protection (L3/L4)	Enhanced DDoS protection (L3-L7) + DRT access	Network security posture management
Scope	All resources automatically	Resources you designate	All discovered resources across accounts
Action	Passive detection/mitigation	Active protection + response team	Discovery + analysis + recommendations
Requires Shield Advanced?	N/A	N/A	No

NSD complements both tiers by identifying resources that should have protection but don't, detecting misconfigurations in existing security controls, and providing topology visibility that neither Shield tier offers.

How NSD Fits with Palo Alto + GWLB Centralized Inspection

This is where it gets interesting for anyone running the kind of centralized inspection architecture I described in my Palo Alto + GWLB post. NSD and a Palo Alto centralized inspection setup are complementary, not competing.

What NSD Can See in Your Palo Alto Architecture

NSD's service-linked role has permissions for elasticloadbalancing:Describe*, ec2:Describe*, and Transit Gateway APIs. This means it will discover:

• Your Gateway Load Balancer — The GWLB itself, its target group, and its listeners
• GWLB Endpoints — Both North-South and East-West GWLB endpoints (they're VPC endpoints of type GatewayLoadBalancer)
• Palo Alto EC2 instances — The VM-Series firewall instances, their ENIs, security groups
• Transit Gateway — The TGW, its attachments, route tables, peering connections
• Inspection VPC topology — All six subnet types, route tables, NAT Gateways, Internet Gateway
• Spoke VPC connectivity — How spoke VPCs connect through TGW to the inspection VPC
• AWS Network Firewall — If you're also running Network Firewall alongside Palo Alto, NSD will analyze its rules and policies

The topology map will show the full path: Spoke VPC → TGW → Inspection VPC → GWLB Endpoints → Palo Alto instances. This gives you a visual confirmation that traffic is flowing through the correct inspection path.

What NSD Cannot See

This means NSD can tell you:

• "You have EC2 instances with security groups allowing all inbound on port 6081" (the GENEVE port for GWLB) — which is expected and correct
• "Your internet-facing ALB doesn't have WAF" — but the Palo Alto may already be inspecting that traffic at Layer 7

It cannot tell you:

• Whether your Palo Alto security policies are correctly blocking SQL injection
• Whether your Palo Alto threat prevention signatures are up to date
• Whether the GWLB health checks are properly configured for the Palo Alto data interface
• Whether TGW appliance mode is enabled (critical for stateful inspection)

The Complementary Model

Here's how I see NSD and Palo Alto working together in a multi-account environment:

Layer	Tool	What It Does
Network posture	NSD	Discovers topology, identifies missing AWS-native protections (WAF, Shield, Security Groups), visualizes internet exposure
Inline inspection	Palo Alto + GWLB	Deep packet inspection, IPS/IDS, threat prevention, URL filtering, SSL decryption on all traffic
Palo Alto posture	Panorama / Prisma Cloud	Palo Alto configuration compliance, policy audit, signature updates
AWS config compliance	Security Hub + AWS Config	CIS benchmarks, custom rules, configuration drift detection
Threat detection	GuardDuty	Runtime threat detection from VPC Flow Logs, DNS logs, CloudTrail

NSD fills the gap between "I deployed firewalls" and "I can prove my network architecture is sound." It validates the AWS infrastructure around your Palo Altos — the VPCs, route tables, security groups, and TGW configuration — while Palo Alto handles the actual traffic inspection.

Practical Integration Points

1. Validating the Inspection Architecture

NSD's topology map can visually confirm that all spoke VPCs route through the inspection VPC. If someone accidentally adds a direct internet gateway to a spoke VPC (bypassing the Palo Alto inspection path), NSD will flag it with a globe icon showing internet exposure and generate a finding about unprotected internet-facing resources.

In the centralized inspection model, spoke VPCs should never have internet gateways — all internet traffic should flow through the inspection VPC's NAT Gateways after Palo Alto inspection. NSD's topology view makes architecture violations immediately visible.

2. Catching Security Group Drift

In a Palo Alto + GWLB architecture, security groups on the firewall data interfaces need to allow all traffic (the Palo Alto handles the actual filtering). But security groups on other resources (EC2 instances in spoke VPCs, ALBs) should still follow least-privilege principles. NSD will catch overly permissive security groups on non-firewall resources that may have been opened as "temporary" fixes and never tightened.

3. WAF Layer Defense in Depth

Even with Palo Alto doing deep packet inspection, AWS WAF on ALBs provides an additional defense layer. NSD will identify ALBs without WAF web ACLs and recommend specific managed rule groups (SQL injection, XSS, known bad inputs). This gives you defense in depth: WAF at the edge + Palo Alto inline inspection.

4. Identifying Unprotected Resources

In a growing multi-account org, new accounts and VPCs get created regularly. If a new spoke VPC doesn't get properly attached to the TGW (or gets attached but to the wrong route table), its traffic might bypass inspection entirely. NSD's cross-account visibility helps catch these gaps before they become security incidents.

5. Using Amazon Q for Architecture Questions

With the Amazon Q integration, you can ask questions that span the entire org:

• "Which EC2 instances have direct internet access?" — Should return zero for spoke VPCs in a centralized inspection model
• "Are any of my internet-facing resources vulnerable to DDoS?" — Identifies resources that should have Shield Advanced but don't
• "Do I have any resources without WAF protection?" — Finds ALBs and CloudFront distributions missing WAF, even behind Palo Alto

The Good

• Free during preview. No cost to try it. No Shield Advanced subscription required. Just enable it and start analyzing.
• Multi-account native. Uses the same delegated administrator pattern as Security Hub and GuardDuty. If you've set those up, NSD is the same workflow.
• Topology visualization. The first AWS-native service that draws your network topology across accounts. No more Visio diagrams that go stale the day after you draw them.
• Continuous analysis. The December 2025 update added continuous analysis for multi-account setups, so findings stay current as your environment changes.
• Amazon Q integration. Natural-language security posture queries are genuinely useful for quick audits and executive reporting.
• Automatic policy inheritance. New accounts joining an OU with an NSD policy are automatically enrolled. No manual onboarding per account.
• Comprehensive resource discovery. 94 IAM actions means it sees a wide range of networking and security resources, including Transit Gateways and Direct Connect.

The Bad

• No third-party firewall analysis. This is the biggest gap for anyone running Palo Alto, Fortinet, Check Point, or any non-AWS firewall. NSD sees the EC2 instances but not their configurations. You still need Panorama or Prisma Cloud for Palo Alto posture management.
• Limited regional availability. Only 7 regions as of December 2025: US East (N. Virginia), Europe (Stockholm, Ireland, Frankfurt), Asia Pacific (Hong Kong, Singapore), and Australia (Sydney). Notable absences include US West (Oregon), US East (Ohio), and Tokyo.
• Amazon Q limited to us-east-1. The natural-language query feature only works in N. Virginia, even if your NSD analysis covers other regions.
• No IPv6 analysis. NSD does not evaluate IPv6 configurations at all. If you're running dual-stack VPCs, IPv6 security gaps won't be flagged.
• Preview means instability. Features may change, disappear, or have different pricing at GA. Don't build critical processes around preview features.
• No CLI/API/CloudFormation documented yet. The preview is console-only. The network-security-director:* IAM action namespace exists, but no CLI subcommand or CloudFormation resources have been documented. IaC teams will have to wait for GA.
• Findings expire after 90 days. Analysis results are only valid for 90 days. If you're not running continuous analysis, old findings disappear.

The Gotchas

1. Management Account Cannot Be the Delegated Admin

Like most AWS security services, the management account cannot serve as the delegated administrator. You must use a member account. If you try to designate the management account, it will fail silently or with a generic error.

2. Requires AWS Organizations — No Standalone Support

NSD cannot function with a standalone AWS account. You must have AWS Organizations configured. This is different from some other security services that offer single-account functionality.

3. False Positives from Firewall Security Groups

If you're running Palo Alto VMs behind GWLB, the firewall data interfaces need permissive security groups (allow all on GENEVE port 6081, and potentially all traffic depending on your NAT configuration). NSD may flag these as overly permissive. You'll need to triage these as expected/acceptable for your architecture.

4. Disable Takes Precedence Over Enable

If a region appears in both an enable and disable policy through OU inheritance, the disable policy wins. This can lead to unexpected gaps in analysis if you have complex OU hierarchies with conflicting policies.

5. 200 Amazon Q Prompts Per Month

The default quota for Amazon Q prompts is 200 per organization per month. In a large org with multiple security engineers, this can get consumed quickly. Plan your queries strategically rather than using Q for every investigation.

6. 300,000 Resource Limit Per Scan

Each analysis can process a maximum of 300,000 resources. Large organizations with thousands of accounts and hundreds of VPCs could hit this limit, especially when including all resource types across all regions.

Quotas

Resource	Default Limit	Adjustable?
Maximum resources processed per scan	300,000	TBD
Maximum edges per resource	200	TBD
Maximum accounts enabled per region/org	15,000	TBD
Amazon Q prompts per org per month	200	TBD
Findings validity	90 days	N/A

Regional Availability

Region	Available Since
US East (N. Virginia)	June 2025 (launch)
Europe (Stockholm)	June 2025 (launch)
Europe (Ireland)	December 2025
Europe (Frankfurt)	December 2025
Asia Pacific (Hong Kong)	December 2025
Asia Pacific (Singapore)	December 2025
Australia (Sydney)	December 2025

NSD vs. Other AWS Security Services

Capability	NSD	Security Hub	GuardDuty	AWS Config
Focus	Network security posture	Compliance posture	Threat detection	Configuration compliance
Topology map	Yes	No	No	No
Multi-account	Yes	Yes	Yes	Yes
AI-powered queries	Yes (Amazon Q)	No	No	No
Analyzes network paths	Yes	No	No	No
Runtime threat detection	No	Aggregates from GuardDuty	Yes	No
Cost	Free (preview)	Free tier + per finding	Per event volume	Per config item

Best Practices

1. Use the same delegated admin account as Security Hub and GuardDuty for consistent governance and fewer accounts to manage.
2. Start with a single OU during preview to understand findings quality before rolling out to the entire organization.
3. Triage firewall false positives early. If you're running Palo Alto + GWLB, expect findings about permissive security groups on firewall data interfaces. Document these as accepted risks.
4. Combine NSD with Panorama. NSD validates AWS infrastructure posture; Panorama validates Palo Alto policy posture. Together they cover the full stack.
5. Use Amazon Q prompts strategically. With only 200/month, save Q for cross-account investigations and executive summaries rather than single-resource lookups.
6. Enable continuous analysis for multi-account setups so findings stay current as your environment changes.
7. Watch for GA pricing. NSD is free during preview, but pricing at GA is unknown. Don't build it into compliance workflows without a budget contingency.

My Take

For anyone running multi-account AWS environments with centralized security tooling, NSD is worth enabling today — it's free, it's low-effort to set up, and the topology visualization alone provides value I haven't found in any other AWS-native service.

The third-party firewall blind spot is a real limitation. If your primary inspection layer is Palo Alto (and mine is), NSD can only validate the infrastructure around the firewalls, not the firewalls themselves. But that's still valuable — it catches the spoke VPC that accidentally got an internet gateway, the security group that someone opened to 0.0.0.0/0 "temporarily," or the ALB that's missing WAF even though it sits behind Palo Alto inspection.

Think of it this way: Palo Alto tells you what's in the packets. NSD tells you whether the packets are taking the right path. You need both.

I'll update this post when NSD reaches general availability with pricing details and any new capabilities.

Further Reading

• AWS Shield Network Security Director Documentation
• AWS Blog: New Shield Feature Discovers Network Security Issues (Preview)
• What is Network Security Director?
• Setting Up Network Security Director
• Using the Network Topology Map
• Analyze Network Security with Amazon Q Developer
• My Post: Centralized Network Inspection with Palo Alto and GWLB