AWS Network Firewall¶

What Is This Service?¶

Managed AWS stateful network firewall service for inspecting, filtering, and controlling traffic entering, leaving, and moving inside Amazon VPCs.

Mental model:

AWS Network Firewall = Route → Inspect → Evaluate → Allow/Deny → Log

Primary purpose:

Provide centralized Layer 3–Layer 7 traffic inspection and enforcement for VPC environments.

Typical use cases:

centralized egress filtering
east-west segmentation
IDS/IPS
domain filtering
malware prevention
regulatory controls
outbound governance
internet ingress inspection

Why It Matters for Security¶

Security Groups and NACLs determine reachability.

They do not provide:

deep packet inspection
protocol awareness
IDS/IPS
application visibility
domain controls

AWS Network Firewall exists to:

inspect traffic contents
centralize security controls
reduce distributed firewall complexity
enforce organization-wide policy

Security outcomes:

network segmentation
threat prevention
controlled egress
compliance enforcement

MOST TESTED:

Security Groups determine:

Who can connect

Network Firewall determines:

What traffic is allowed

Architecture Example¶

Centralized Egress Inspection with Transit Gateway¶

flowchart TD
    Internet((Internet))

    subgraph TGWLayer[Transit Hub]
        TGW[AWS Transit Gateway - Appliance Mode Enabled]
    end

    subgraph SpokeA[Application VPC A]
        AppA1[Private Subnet AZ-A]
        AppA2[Private Subnet AZ-B]
    end

    subgraph SpokeB[Application VPC B]
        AppB1[Private Subnet AZ-A]
        AppB2[Private Subnet AZ-B]
    end

    subgraph InspectionVPC[Central Inspection VPC]
        IGW[Internet Gateway]

        subgraph AZA[Availability Zone A]
            TGWAttA[TGW Attachment Subnet AZ-A]
            FWA[Network Firewall Endpoint AZ-A]
            NATA[NAT Gateway AZ-A]
        end

        subgraph AZB[Availability Zone B]
            TGWAttB[TGW Attachment Subnet AZ-B]
            FWB[Network Firewall Endpoint AZ-B]
            NATB[NAT Gateway AZ-B]
        end
    end

    AppA1 --> TGW
    AppA2 --> TGW
    AppB1 --> TGW
    AppB2 --> TGW

    TGW --> TGWAttA
    TGW --> TGWAttB

    TGWAttA --> FWA
    FWA --> NATA
    NATA --> IGW

    TGWAttB --> FWB
    FWB --> NATB
    NATB --> IGW

    IGW --> Internet
    Internet --> IGW

Architecture goals:

centralized inspection
AZ-local routing
symmetric flows
internet egress control
shared security services VPC

Workflow(s)¶

Traffic Inspection Flow¶

sequenceDiagram
    participant Client
    participant RouteTable
    participant Firewall
    participant Rules
    participant Destination

    Client->>RouteTable: Send packet
    RouteTable->>Firewall: Forward to firewall endpoint
    Firewall->>Rules: Evaluate policy

    alt Allowed
        Rules->>Destination: Forward traffic
    else Denied
        Rules->>Client: Drop traffic
    end

Stateless to Stateful Evaluation¶

sequenceDiagram
    participant Packet
    participant Stateless
    participant Stateful

    Packet->>Stateless: Evaluate stateless rules

    alt Pass or Forward
        Stateless->>Stateful: Send to stateful engine
    else Drop
        Stateless->>Packet: Drop immediately
    end

    Stateful->>Packet: Final allow or drop decision

IDS/IPS Inspection¶

sequenceDiagram
    participant Traffic
    participant Suricata
    participant Firewall
    participant Logs

    Traffic->>Suricata: Inspect packet/session
    Suricata->>Firewall: Match signature or rule
    Firewall->>Logs: Emit alert or flow log

Core Concepts¶

Firewall Endpoint¶

MOST TESTED

Network Firewall deploys firewall endpoints.

Characteristics:

managed by AWS
AZ-specific
inserted using route tables
used as routing targets

Flow:

Traffic
↓
Route Table
↓
Firewall Endpoint
↓
Destination

MASSIVE EXAM TRAP:

Deploying the firewall does nothing by itself.

Traffic must be routed through firewall endpoints.

Stateless Rule Groups¶

Evaluated first.

Characteristics:

packet-based
no session awareness
low latency

Can inspect:

source IP
destination IP
protocol
port

Actions:

pass
drop
forward to stateful engine

Typical use:

rapid filtering
packet screening
pre-filtering obvious unwanted traffic

Stateful Rule Groups¶

MOST TESTED

Evaluated after stateless processing.

Characteristics:

session aware
connection tracking
deep inspection
application-aware inspection

Supports:

HTTP
DNS
TLS metadata
application signatures

Typical use:

IDS
IPS
application enforcement
domain filtering

Suricata Rule Engine¶

HIGH VALUE

Network Firewall uses a Suricata-compatible stateful inspection engine.

Supports:

IDS signatures
IPS signatures
custom rules

Example:

alert tcp any any -> any any

Exam trap:

Suricata rules apply to stateful inspection, not stateless filtering.

Firewall Policies¶

A firewall policy contains:

stateless rule groups
stateful rule groups
stateless default actions
stateful default actions

Structure:

Firewall Policy
↓
Rule Groups
↓
Firewall
↓
Firewall Endpoints

Default Actions¶

MASSIVE EXAM TRAP

Defaults are configured separately for stateless and stateful evaluation.

Strict security posture:

Stateless default:

Forward to stateful rules

Stateful default:

Drop

Reason:

Unknown traffic still receives deep inspection before being denied.

Important Integrations¶

Service	Purpose
VPC	Routing and traffic path control
Transit Gateway	Centralized inspection across VPCs
Firewall Manager	Organization-wide policy deployment
AWS Organizations	Multi-account governance
CloudWatch	Metrics and alarms
Amazon S3	Log destination
KMS	Log encryption
Route 53 Resolver	DNS visibility and control patterns
Security Hub	Security findings visibility
CloudTrail	API auditing
Gateway Load Balancer	Third-party appliance insertion
VPC Flow Logs	Network traffic analysis

Security Features¶

Stateful Inspection¶

Tracks:

sessions
TCP state
application flows

Why it matters:

Stateful inspection allows the firewall to understand whether traffic belongs to a valid connection.

Domain Filtering¶

Supports:

allow lists
deny lists

Example:

*.example.com

Used for:

egress control
malware prevention
compliance restrictions

TLS Inspection¶

HIGH VALUE

Supports encrypted traffic inspection.

Flow:

Decrypt
↓
Inspect
↓
Re-encrypt

Requirements:

certificate authority
trust configuration
explicit TLS inspection setup

Exam trap:

TLS inspection is optional and must be configured.

Intrusion Detection and Prevention¶

Modes:

alert
drop

Capabilities:

signature detection
anomaly inspection
malware indicators
suspicious protocol behavior

Advanced Security and Operational Concepts¶

Control Plane vs Data Plane¶

Control Plane:

create firewall
define rule groups
attach policies
configure logging

Data Plane:

packet inspection
session tracking
traffic enforcement

Exam trap:

Inspection occurs at firewall endpoints, not inside EC2 instances.

Routing Architecture¶

MOST TESTED

flowchart LR
    Subnet[Subnet] --> RouteTable[Route Table]
    RouteTable --> FirewallEndpoint[Firewall Endpoint]
    FirewallEndpoint --> Destination[Destination]

Rule:

No route table change → no inspection.

Asymmetric Routing¶

MASSIVE EXAM TRAP

Because Network Firewall is stateful, it must observe both sides of the conversation.

Required:

Request
+
Response

Bad design:

Outbound traffic → AZ-A Firewall
Return traffic → AZ-B Firewall

Result:

Session dropped

Reason:

The AZ-B firewall endpoint has no connection state for the original session.

Correct pattern:

AZ-A traffic ↔ AZ-A firewall endpoint
AZ-B traffic ↔ AZ-B firewall endpoint

Transit Gateway Appliance Mode¶

HIGH VALUE

Required when using Transit Gateway with stateful inspection.

Purpose:

Preserve symmetric routing through the same inspection appliance path.

flowchart LR
    SpokeVPC1[Spoke VPC 1] --> TGW[Transit Gateway]
    SpokeVPC2[Spoke VPC 2] --> TGW
    TGW --> InspectionVPC[Inspection VPC]
    InspectionVPC --> FirewallEndpoint[Network Firewall Endpoint]
    FirewallEndpoint --> Egress[Internet Egress]

Enable:

Appliance Mode

Without Appliance Mode:

Traffic symmetry can break.

Ingress Routing with IGW Edge Association¶

MOST TESTED

Use VPC Ingress Routing to force internet ingress traffic through Network Firewall before it reaches public subnets.

flowchart LR
    Internet((Internet)) --> IGW[Internet Gateway]
    IGW --> IGWRouteTable[IGW Edge Route Table]
    IGWRouteTable --> FirewallEndpoint[Network Firewall Endpoint]
    FirewallEndpoint --> PublicSubnet[Public Subnet]
    PublicSubnet --> ALB[Application Load Balancer]

Process:

Attach a route table to the Internet Gateway.
Add edge routes for public subnet CIDRs.
Point those routes to firewall endpoints.
Inspect traffic before it reaches public resources.

Use cases:

public EC2 inspection
ingress filtering
inspection before ALB

Exam trap:

IGW route table association is required for ingress routing.

Centralized Inspection with Transit Gateway¶

HIGH VALUE

flowchart LR
    AppVPC1[Application VPC 1] --> TGW[Transit Gateway]
    AppVPC2[Application VPC 2] --> TGW
    AppVPC3[Application VPC 3] --> TGW
    TGW --> InspectionVPC[Inspection VPC]
    InspectionVPC --> FirewallEndpoint[Network Firewall]
    FirewallEndpoint --> Internet((Internet))

Benefits:

centralized controls
fewer firewalls
lower operational overhead
consistent governance

Capacity and Auto Scaling¶

HIGH VALUE

AWS manages firewall infrastructure.

Characteristics:

automatic scaling
managed capacity
no EC2 administration

Throughput:

Up to 100 Gbps per firewall endpoint per AZ

Exam trap:

If requirements exceed endpoint limits, reconsider architecture or use Gateway Load Balancer with third-party appliances.

Network Firewall vs Security Groups¶

MOST TESTED

Capability	Network Firewall	Security Groups
Stateful	Yes	Yes
Layer 7 visibility	Yes	No
Deep inspection	Yes	No
Central policy	Yes	Limited
Routing required	Yes	No

Rule:

Security Group = access control

Network Firewall = traffic inspection

Network Firewall vs NACL¶

Capability	Network Firewall	NACL
Stateful	Yes	No
IDS/IPS	Yes	No
Layer 7 inspection	Yes	No
Routing required	Yes	No
Scope	Routed traffic	Subnet boundary

Network Firewall vs Gateway Load Balancer¶

MASSIVE EXAM TRAP

Capability	Network Firewall	Gateway Load Balancer
Managed firewall	Yes	No
Third-party appliance insertion	No	Yes
Suricata-compatible rules	Yes	Depends on appliance
AWS-managed scaling	Yes	GWLB scales, appliances vary

Rule:

Need managed AWS inspection → Network Firewall

Need vendor appliance fleet → Gateway Load Balancer

Logging¶

Supported logs:

flow logs
alert logs

Destinations:

CloudWatch Logs
Amazon S3
Kinesis Data Firehose

Exam trap:

Network Firewall logs are separate from VPC Flow Logs.

High Availability¶

MOST TESTED

Best practice:

One firewall endpoint per AZ

Route traffic to the local firewall endpoint in the same AZ.

Avoid unnecessary cross-AZ inspection.

Why:

improves availability
reduces latency
preserves symmetry
reduces cross-AZ data transfer

Multi-Account Governance¶

flowchart TB
    Organizations[AWS Organizations] --> FirewallManager[AWS Firewall Manager]
    FirewallManager --> Policies[Network Firewall Policies]
    Policies --> Account1[Member Account 1]
    Policies --> Account2[Member Account 2]
    Policies --> Account3[Member Account 3]

Requirements:

AWS Organizations
delegated administrator
AWS Config enabled

Cost Model¶

Primary drivers:

firewall endpoint hours
traffic processed
TLS inspection

Optimization:

centralized inspection
selective TLS inspection
avoid unnecessary endpoints
route only required traffic through inspection

Exam trap:

Idle endpoints still cost money.

Comparisons¶

Service	Primary Role
Network Firewall	Managed network inspection
Security Groups	Instance or ENI access control
NACL	Stateless subnet filtering
Gateway Load Balancer	Third-party appliance insertion
AWS WAF	HTTP/S application filtering
AWS Shield	DDoS protection

Common Exam Traps¶

Firewall deployment alone does nothing.
Route tables activate inspection.
Stateless rules evaluate first.
Stateful rules perform deep inspection.
Suricata powers stateful inspection.
Stateful inspection requires symmetric routing.
Enable TGW Appliance Mode for stateful inspection through Transit Gateway.
Use IGW ingress routing for public internet inspection.
Firewall endpoints are AZ-specific.
Default stateless action should usually forward to stateful inspection.
Strict stateful default action often drops unmatched traffic.
TLS inspection is optional and requires configuration.
Gateway Load Balancer inserts third-party appliances.
Network Firewall logs are separate from VPC Flow Logs.
Deploy one firewall endpoint per AZ.
Traffic should usually stay AZ-local.
Up to 100 Gbps per firewall endpoint per AZ.
AWS manages firewall scaling.
Security Groups still remain necessary.
Network Firewall does not replace WAF.

5-Second Recall¶

Route traffic through firewall endpoints
No route change = no inspection
Stateless → Stateful
Suricata = stateful IDS/IPS
Appliance Mode preserves symmetry
IGW ingress routing inspects inbound traffic
Firewall endpoints are AZ-specific
Up to 100 Gbps per endpoint per AZ
Security Groups ≠ Network Firewall

Quick Revision Notes¶

Route tables control enforcement.
Stateful inspection needs symmetric traffic.
Use Appliance Mode with Transit Gateway.
Use IGW ingress routing for public ingress filtering.
Default stateless action often forwards to stateful.
Strict stateful default action drops unmatched traffic.
Centralize inspection with Transit Gateway.
Suricata powers IDS/IPS signatures.
TLS inspection requires trust configuration.
Deploy firewall endpoints in every used AZ.