AWS Network Firewall deployment models: Centralised security at scale
AWS Network Firewall is a managed stateful firewall service for your VPCs. You define the rules; AWS runs the firewall infrastructure. The decision that shapes your architecture, cost, and operational complexity is not which rules to write but where to put the firewall endpoints.
Three deployment models exist. Each suits a different combination of traffic patterns, account structure, and operational requirements. Choosing the wrong one means paying for infrastructure you do not need or accepting gaps in traffic inspection.
The three models
Model 1: Distributed (per-VPC) deployment
Each VPC gets its own firewall endpoint deployed in a dedicated subnet. Traffic from the VPC routes to the local firewall endpoint before leaving or entering the VPC. The firewall inspects north-south traffic (to and from the internet, to and from on-premise) for that specific VPC.
Strengths: - Lowest latency: firewall endpoint is in the same VPC as the workload - Strong workload isolation: a misconfiguration in one VPC's firewall rules does not affect others - No Transit Gateway cost or dependency - Simple routing: traffic routes to the firewall endpoint, then to the internet gateway or VPN
Weaknesses: - Cost scales with VPC count: each endpoint is billed independently - East-west traffic (VPC-to-VPC) is not inspected by default - Rule management complexity grows with VPC count unless Firewall Manager is used - Consistent policy enforcement requires Firewall Manager or careful manual synchronisation
Right for: Environments with few VPCs where internet-facing traffic inspection is the primary requirement, or where workload isolation demands separate firewall policies per VPC.
Model 2: Centralised deployment
Firewall endpoints are deployed in a dedicated security VPC. All inspection traffic routes through this VPC via Transit Gateway. Spoke VPCs send traffic to the Transit Gateway; the Transit Gateway routes it to the security VPC's firewall endpoint for inspection before forwarding to the destination.
The routing design is the complexity: each spoke VPC has a route table entry sending all non-local traffic to the Transit Gateway. The Transit Gateway routes to the security VPC. The security VPC's firewall inspects the traffic and forwards it outbound.
Strengths: - Single set of firewall endpoints to manage regardless of how many spoke VPCs exist - East-west traffic (VPC to VPC) is inspectable: all inter-VPC traffic can be routed through the central firewall - Centralised logging: all flow logs and alert logs aggregate in one place - More cost-effective at scale: one set of endpoints versus one set per VPC - Single compliance evidence point for auditors
Weaknesses: - Transit Gateway adds latency (typically 1-2ms for EU regions) and per-GB data processing charges - Complexity in routing design: asymmetric routing causes dropped connections if not carefully planned - Single point of failure unless the security VPC is deployed across multiple Availability Zones - Requires Transit Gateway attachment costs for every spoke VPC
Right for: Multi-account environments, regulated businesses needing centralised audit evidence, environments where east-west inspection is required, and organisations using Firewall Manager for policy governance.
Model 3: Combined deployment
A hybrid architecture: centralised firewall endpoints for east-west (inter-VPC) and hybrid (on-premise) traffic inspection, plus per-VPC distributed endpoints for north-south (internet) traffic.
This model addresses the limitation of pure centralised deployment for internet traffic: in centralised deployment, internet-bound traffic must traverse the Transit Gateway, which adds latency and cost for workloads with high internet traffic volumes. The combined model keeps internet traffic local to each VPC while centralising the inspection that matters most for east-west security.
Right for: Environments with high-volume internet traffic where centralised inspection would make Transit Gateway costs prohibitive, combined with a requirement to inspect inter-VPC traffic centrally.
Choosing the right model
The decision table:
| Question | Yes → | No → |
|---|---|---|
| Do you need to inspect inter-VPC (east-west) traffic? | Centralised or Combined | Distributed is viable |
| Do you have more than 5 VPCs? | Centralised is more cost-effective | Distributed may be simpler |
| Is Transit Gateway already in use? | Centralised adds minimal marginal cost | Consider distributed to avoid new dependency |
| Do regulators require centralised audit evidence? | Centralised simplifies evidence | Either model |
| Do you have high internet traffic volume per VPC? | Combined to avoid Transit Gateway bottleneck | Centralised is simpler |
For most UK SMBs with growing AWS footprints in multi-account structures, centralised deployment is the right starting point. It is operationally simpler at scale, provides the centralised logging that FCA, PCI DSS, and GDPR audits expect, and integrates naturally with AWS Firewall Manager for policy governance.
Firewall endpoint placement and Availability Zones
Regardless of deployment model, firewall endpoints must be deployed in the Availability Zones where the workloads they protect run. Traffic cannot cross Availability Zones to reach a firewall endpoint: if your workload is in eu-west-2a and the firewall endpoint is only in eu-west-2b, traffic will not be inspected.
Deploy one firewall endpoint per Availability Zone used by protected workloads. For a VPC spanning three AZs, that means three firewall endpoints. This is also why centralised deployment costs are lower at scale: in distributed deployment, each of your ten VPCs across three AZs requires three endpoints (30 total); in centralised deployment, the security VPC needs only three.
Rule groups: stateless and stateful
AWS Network Firewall processes traffic through two rule group types in sequence:
Stateless rules evaluate each packet independently using 5-tuple matching (source IP, destination IP, source port, destination port, protocol). Stateless rules make pass/drop/forward decisions quickly. They do not track connection state.
Stateful rules track connection state and can evaluate full traffic streams. Use stateful rules for: domain-based filtering (block *.malware-domain.com), protocol anomaly detection, Suricata-compatible IDS/IPS rules, and inspection that requires multi-packet context.
The recommended approach: use stateless rules as a fast first pass for obviously-allowed or obviously-blocked traffic (permit established connections back through, block RFC1918 source addresses arriving from the internet). Use stateful rules for the substantive inspection logic.
Where Critical Cloud comes in
Network Firewall deployment model decisions are architectural choices with long-lived cost and operational consequences. Getting the routing design right in centralised deployment, particularly avoiding asymmetric routing that drops packets, requires AWS networking expertise. We design and operate AWS networking architecture for regulated businesses, with Network Firewall alert signals surfaced in the same operational view as application and infrastructure health. As the world's first Powered by Datadog accredited partner, we treat firewall alert telemetry as a first-class operational signal. See how Critical Support works.