AWS Network Firewall for multi-account setups: Unified security policy

A single AWS account is easy to secure. You deploy one firewall, define rules, and enforce them. A multi-account structure, the correct architecture for any organisation with multiple environments, teams, or workloads, introduces a coordination problem: how do you enforce consistent network security policy across every account without managing rules independently in each one?

AWS Network Firewall with AWS Firewall Manager answers this. Firewall Manager acts as the central policy authority. Policies defined once in the management account propagate automatically to member accounts across your AWS Organisation. When a new account is created, it inherits the baseline firewall policy immediately. When you update a rule, it applies everywhere. This guide covers the design and deployment of that architecture.

Foundation: AWS Organisations and account structure

Network Firewall multi-account deployment depends on AWS Organisations. All member accounts must be part of the same Organisation, and AWS Firewall Manager must be enabled in the Organisation's management account (or a designated delegated administrator account).

The account structure determines how firewall policies apply. AWS recommends grouping accounts into Organisational Units (OUs) by function: a Security OU for centralised security tooling, an Infrastructure OU for shared services, and workload-specific OUs for production, pre-production, and development environments.

Firewall Manager policies can be scoped to the entire Organisation or to specific OUs. A policy scoped to the Production OU applies only to production accounts. A policy scoped to the root Organisation applies everywhere. Define your OU structure before deploying Firewall Manager policies: it determines the granularity of policy control.

For UK organisations with GDPR obligations, the Security OU is also where you centralise compliance monitoring: AWS Security Hub, Amazon GuardDuty, and CloudTrail log aggregation belong here, alongside the Network Firewall deployment.

Deployment model choice: distributed vs centralised vs combined

AWS Network Firewall supports three deployment models. The right choice depends on your traffic patterns and operational requirements.

Distributed deployment places a firewall endpoint in each VPC. Each account manages its own firewall within the policy constraints set by Firewall Manager. This model provides the lowest latency (no cross-account traffic hops) and the strongest workload isolation. The cost is higher: each endpoint incurs a separate hourly charge, and rule management is per-VPC even with Firewall Manager coordinating baselines.

Centralised deployment places all firewall endpoints in a dedicated security account. Traffic from spoke VPCs routes to the centralised firewall via Transit Gateway before reaching its destination. This reduces the number of firewall endpoints, simplifies inspection point management, and provides a single place for centralised logging and analysis. It introduces Transit Gateway data processing charges and slightly higher latency on inspected traffic.

Combined deployment uses centralised east-west inspection (traffic between VPCs via Transit Gateway) alongside distributed north-south inspection (internet-bound and inbound traffic at the VPC level). This hybrid addresses scenarios where inter-VPC traffic must be inspected centrally but internet traffic benefits from distributed enforcement closer to the workload.

For most UK SMBs building multi-account structures, centralised deployment strikes the right balance: lower operational overhead, single inspection point for compliance evidence, and Transit Gateway costs that are justified by the management simplification.

Configure Firewall Manager for multi-account policy

Enable Firewall Manager in the management account by accepting the service role. Navigate to the Firewall Manager console and confirm the service-linked role is active.

Create a Network Firewall policy in Firewall Manager:

  1. Navigate to Firewall Manager > Security Policies > Create Policy
  2. Select AWS Network Firewall as the policy type
  3. Choose the deployment model (centralised or distributed)
  4. Define the firewall policy: rule groups, stateful and stateless rules
  5. Set the policy scope: which accounts and OUs the policy applies to
  6. Enable automatic remediation so Firewall Manager deploys the firewall to new accounts automatically

The firewall policy defines the actual security rules. Firewall Manager manages where the policy is deployed; the Network Firewall policy defines what it enforces.

Key stateful rules to include in a baseline policy:

  • Allow established TCP connections (permit return traffic for allowed outbound sessions)
  • Block traffic to known malicious IP addresses using AWS managed threat intelligence rule groups
  • Block outbound traffic on ports 25 (SMTP) and 22 (SSH) to the internet except from designated management accounts
  • Log all denied traffic to CloudWatch Logs for security analysis

IAM and permission requirements

Firewall Manager requires specific IAM permissions across accounts. The management account needs the AWSFMAdminFullAccess managed policy for the Firewall Manager administrator role. Member accounts need the AWSFMMemberReadOnlyAccess policy to allow Firewall Manager to read account state and deploy resources.

For the Network Firewall service itself, a service-linked role (AWSServiceRoleForNetworkFirewall) is created automatically in each account where Network Firewall resources are deployed. Do not delete this role.

Apply the principle of least privilege to any IAM roles that manage firewall rules or policies. Firewall rule modifications should require MFA and should be logged via CloudTrail. Under FCA and GDPR audit requirements, demonstrating who changed a security rule and when is a routine request.

Monitoring across accounts

Centralised logging is the primary operational benefit of multi-account Network Firewall deployment. Configure each firewall to log to a central S3 bucket in the Security account:

  • Flow logs: every accepted and rejected connection
  • Alert logs: rule matches for threat intelligence and custom rules
  • TLS inspection logs (if TLS inspection is configured)

Route the centralised bucket to a SIEM (Amazon Security Lake, Microsoft Sentinel, or a third-party platform) for cross-account threat detection. Firewall alert logs that appear only in one account's VPC may not be notable. The same alert pattern appearing across five accounts in the same hour is a different story.

Use AWS Firewall Manager's compliance dashboard to monitor policy compliance across accounts. Non-compliant resources (VPCs without firewall protection, accounts where the policy has drifted) appear in the dashboard with remediation actions.

Where Critical Cloud comes in

Multi-account Network Firewall architecture is foundational security infrastructure. Getting the deployment model wrong, or deploying without centralised logging and cross-account compliance monitoring, means the controls exist in name but not in substance. We design and operate AWS security architecture for regulated and technology-led businesses. As the world's first Powered by Datadog accredited partner, we surface Network Firewall alerts and policy compliance signals in the same operational view as application and infrastructure health. See how Critical Support works.