AWS Network Firewall — Suricata Rules, TLS Inspection, and Centralized Deployment

Why AWS Network Firewall Matters for ANS-C01

AWS Network Firewall is the managed, stateful, deep-packet-inspection firewall service that the ANS-C01 exam expects you to know cold. Every Domain 4 question that involves blocking outbound traffic by FQDN, performing TLS inspection on egress, or building a centralized inspection VPC ultimately routes through AWS Network Firewall. The exam writers have stuffed this service into roughly one in five Domain 4 questions, because Network Firewall sits at exactly the intersection of routing (Domain 2), monitoring (Domain 3), and security (Domain 4) that the Specialty test is designed to measure.

In this study guide we walk through AWS Network Firewall from the ground up: the architecture (firewall, firewall policy, rule groups), the difference between stateless and stateful rule groups, the Suricata-compatible rule syntax, TLS inspection with ACM-imported certificates, domain filtering versus 5-tuple filtering, distributed versus centralized deployment topologies via Transit Gateway, Firewall Manager organization-wide automation, and logging to S3, CloudWatch, and Kinesis. We will also map every common ANS-C01 trap question to the underlying behavior, including the famous "stateless evaluated first" question that catches half of all candidates the first time.

This is a Specialty-depth note. Expect over 5,400 words, more than 10 H2 sections, FAQ at the end, and Mandarin trap callouts at the bottom. Read it twice, and AWS Network Firewall stops being a black box and becomes a predictable answer pattern on the exam.

AWS Network Firewall Architecture Overview

AWS Network Firewall is composed of three logical objects you need to keep straight: the firewall, the firewall policy, and the rule groups. The firewall is a per-VPC object that contains one or more firewall endpoints — each endpoint is an Elastic Network Interface (ENI) deployed in a specific Availability Zone of the firewall subnet. The firewall policy is a reusable container of rule groups (both stateless and stateful) that defines the inspection logic. Rule groups are themselves reusable; one rule group can be referenced by many firewall policies, and one policy can be applied to many firewalls.

When traffic enters or leaves a VPC through the firewall subnet route table, the route directs the packet to the firewall endpoint ENI for that AZ. The firewall endpoint inspects the packet and either passes it, drops it, or forwards it for further processing. Crucially, AWS Network Firewall is deployed as a transparent inline service: routes determine traffic flow, not security groups, and the firewall endpoint does not consume a routable IP address from your application's perspective. The traffic enters the ENI and exits the ENI; routing is the contract.

The architecture for AWS Network Firewall in production almost always looks like this:

Workload Subnet (10.0.1.0/24)
  │
  │ default route 0.0.0.0/0 → firewall endpoint ENI
  ▼
Firewall Subnet (10.0.0.0/28) ── firewall endpoint (ENI per AZ)
  │
  │ default route 0.0.0.0/0 → IGW or NAT GW
  ▼
Internet Gateway / NAT Gateway

This is the single-VPC distributed pattern. Each VPC has its own firewall, its own firewall subnet, and its own ENIs. AWS Network Firewall scales horizontally by AZ and by traffic volume; AWS automatically provisions additional capacity behind the ENI as throughput grows. You pay per firewall endpoint per hour plus per gigabyte processed, so multi-AZ deployments cost more, but the multi-AZ design is mandatory for any ANS-C01 highly available answer.

Stateless Rule Groups: 5-Tuple Filtering at Wire Speed

AWS Network Firewall stateless rule groups perform 5-tuple matching: source IP, destination IP, source port, destination port, and protocol. Stateless rules do not track connections — every packet is evaluated independently. This makes stateless rules extremely fast, which is exactly why AWS Network Firewall evaluates them first in the inspection pipeline.

A stateless rule has three possible actions: pass (forward to stateful inspection), drop (discard), or forward (send to stateful rule groups regardless of stateful default). Each rule has a priority, and stateless rules are evaluated in priority order until a match fires. If no rule matches, the stateless default action of the firewall policy applies (typically aws:forward_to_sfe, which forwards to the stateful engine).

Stateless rules also support custom actions for metric publication. You can attach a custom action that publishes a CloudWatch metric dimension when the rule fires, so you can build dashboards on traffic that hits specific stateless rules without enabling full flow logging. The exam occasionally tests whether stateless rules can perform domain matching — they cannot. Only stateful rules see Layer 7 data.

Stateless rule example

A typical stateless rule group might contain rules like "drop all UDP packets from 10.0.0.0/8 to 0.0.0.0/0 port 53" to block DNS exfiltration to public resolvers, or "drop all TCP packets to ports 23 (Telnet) or 445 (SMB)" to enforce a no-legacy-protocols baseline. These rules execute at line rate and add minimal latency, which makes them ideal for coarse-grained filtering.

Stateful Rule Groups: Suricata Rules and Connection Tracking

Stateful rule groups in AWS Network Firewall are where the deep inspection magic happens. Stateful rules track TCP connection state (the three-way handshake, the FIN/RST teardown, sequence numbers) and can match on Layer 7 attributes like HTTP host headers, TLS Server Name Indication (SNI), and HTTP URI paths. AWS Network Firewall supports three formats of stateful rules: Suricata-compatible rules, AWS-defined 5-tuple rules with state tracking, and domain list rules.

Suricata is the open-source IDS/IPS engine that AWS Network Firewall uses internally. The Suricata rule syntax is the most powerful and most exam-relevant. A Suricata rule looks like this:

alert tls $HOME_NET any -> $EXTERNAL_NET any (msg:"Block uncategorized TLS"; tls.sni; content:"|0d|badsite.example|0d|"; sid:1000001; rev:1;)

drop http $HOME_NET any -> $EXTERNAL_NET any (msg:"Block legacy User-Agent"; http.user_agent; content:"libwww-perl"; sid:1000002; rev:1;)

pass tcp any any -> any 443 (msg:"Allow HTTPS"; flow:established; sid:1000003; rev:1;)

Each rule has an action (alert, drop, pass, reject), a protocol (tcp, udp, http, tls, dns, smb, ftp, ssh, ip), source and destination, and rule options. The sid is the unique signature ID; the rev is the revision number. Suricata rules are evaluated in default order or in strict priority order based on the rule group setting.

AWS-defined 5-tuple stateful rules

If you do not want to write Suricata syntax, AWS Network Firewall offers a friendlier 5-tuple stateful rule format. You provide source IP, source port, destination IP, destination port, protocol, and direction (forward or any), and AWS generates the underlying Suricata rule for you. These rules track connection state automatically — once an outbound TCP SYN is allowed, the inbound SYN-ACK is automatically permitted by the stateful engine, no explicit return rule needed.

Domain list rules

Domain list rules are a third stateful format that match on FQDNs. You provide a list of domains and a target type — HTTP_HOST for plain HTTP, TLS_SNI for HTTPS — and an action (allow or deny). Domain list rules are the easiest way to implement an FQDN-based egress allow-list for outbound traffic. The exam tests this pattern frequently because it is the canonical answer to "block all outbound except approved SaaS providers."

A domain list rule does not perform full TLS decryption to read HTTP host headers. For TLS traffic, the rule reads the SNI from the unencrypted ClientHello at the TLS handshake. This means the domain rule sees the SNI even without TLS inspection enabled, but it cannot validate that the actual destination matches the SNI (a sophisticated attacker can lie in the SNI). For high-assurance environments, combine domain list rules with TLS inspection.

TLS Inspection: Decrypting Traffic for Layer 7 Visibility

TLS inspection is the AWS Network Firewall feature that decrypts TLS traffic, performs deep inspection on the plaintext payload, and re-encrypts the traffic before forwarding. TLS inspection is critical for Domain 4 questions about visibility into encrypted egress traffic, malware command-and-control over HTTPS, and data exfiltration to cloud storage.

AWS Network Firewall TLS inspection works in both directions: outbound (workloads in the VPC to internet destinations) and inbound (internet clients to workloads in the VPC). The two patterns require different certificate handling.

For outbound TLS inspection, you configure a TLS inspection configuration that references a certificate authority (CA) certificate stored in AWS Certificate Manager. The CA certificate is used to dynamically generate impersonation certificates for the destinations that workloads contact. To make this work, every workload that initiates outbound TLS must trust the CA certificate; otherwise, the workload's TLS handshake fails because the server certificate it receives (the impersonation cert) is signed by an untrusted CA.

For inbound TLS inspection, you import the actual server certificate (the one your workload presents to clients) into ACM, and the firewall uses it to terminate TLS at the firewall and re-encrypt to the backend. The backend may use a different certificate or even plaintext.

TLS inspection performance and privacy

TLS inspection adds CPU cost (decryption + re-encryption) and inspection latency. AWS Network Firewall handles this transparently, but there is a per-gigabyte processing fee that is higher than non-inspected traffic. From a privacy perspective, TLS inspection breaks the end-to-end encryption guarantee; some destinations (banks, healthcare portals) explicitly prohibit man-in-the-middle inspection in their terms of service. AWS Network Firewall supports a "scope" feature that lets you exclude specific destinations from TLS inspection — for example, never inspect *.bank.com traffic.

Centralized vs Distributed Deployment Topologies

AWS Network Firewall can be deployed in two architectural patterns: distributed and centralized. The choice depends on the number of VPCs, the operational model, and cost constraints. ANS-C01 questions frequently ask you to pick the right pattern based on a scenario.

Distributed deployment

In the distributed pattern, every VPC has its own AWS Network Firewall. Each VPC owns its firewall, its firewall policy, its rule groups, and its routing. This pattern is simple to reason about, has no shared blast radius, and is the default starting point for small environments. The downside is cost — every VPC pays for firewall endpoints in every AZ — and rule consistency, which requires Firewall Manager or IaC discipline.

Centralized deployment via Transit Gateway

In the centralized pattern, a single inspection VPC hosts an AWS Network Firewall, and Transit Gateway routes traffic from spoke VPCs through the inspection VPC. This pattern reduces firewall endpoint count from N×AZs to 1×AZs, dramatically reducing cost at scale. It centralizes rule management. It is the canonical answer for "we have 50 VPCs and need consistent egress inspection."

The centralized pattern requires careful Transit Gateway routing. Spoke VPCs send all traffic to the TGW. The TGW route table for spoke attachments points to the inspection VPC attachment. The inspection VPC's TGW attachment must be in appliance mode, which ensures that traffic for a given flow uses the same AZ on the way in and the way out — without appliance mode, return traffic could come back through a different AZ and bypass the firewall (the flow state would not match).

Routing in the centralized pattern

The route table dance for centralized inspection looks like this:

Spoke VPC subnets → 0.0.0.0/0 → TGW
TGW spoke route table → 0.0.0.0/0 → inspection VPC attachment
Inspection VPC firewall subnet → 0.0.0.0/0 → firewall endpoint ENI
Inspection VPC public subnet → 0.0.0.0/0 → IGW or NAT GW
TGW inspection route table → 10.0.0.0/8 → spoke VPC attachments

There are two TGW route tables, intentionally — one for spokes (default route to inspection) and one for the inspection VPC (specific routes back to spokes). This separation prevents traffic from bypassing inspection.

Firewall Manager: Organization-Wide Automation

AWS Firewall Manager is the multi-account, multi-region orchestration layer for AWS Network Firewall, AWS WAF, AWS Shield Advanced, security groups, and Route 53 Resolver DNS Firewall. For ANS-C01, the Network Firewall use case is the most exam-relevant.

A Firewall Manager Network Firewall policy specifies a firewall policy ARN, the AWS Organizations OUs or accounts in scope, and a deployment model (centralized inspection VPC or distributed per-VPC). When new accounts join the organization or new VPCs are created, Firewall Manager automatically creates the firewall, attaches the policy, and remediates configuration drift. Non-compliant resources surface as findings.

Firewall Manager requires AWS Organizations with all features enabled, an AWS Config-enabled member account, and a delegated administrator account. The exam tests whether you remember the prerequisites — answers that propose Firewall Manager without Organizations are wrong.

Logging: Alert Logs and Flow Logs

AWS Network Firewall produces two log types: alert logs and flow logs. Alert logs record events from stateful rules that have an alert or drop action — these are the security-relevant findings. Flow logs record metadata for every connection that passes through the firewall — these are the network-visibility records. Both can be sent to S3, CloudWatch Logs, or Kinesis Data Firehose.

Alert logs are the primary source for SIEM integration. A typical alert log entry includes the firewall ARN, the source and destination IP addresses and ports, the protocol, the matched signature ID (sid), the rule message, and the action. You can use Amazon Athena to query alert logs in S3 with partition projections for time-based filtering.

Flow logs are similar in structure to VPC Flow Logs but with extra fields specific to firewall processing — the inspection result (pass, drop, alert), the rule group that matched, and connection state. Flow logs are voluminous; for large environments, send them to Kinesis Firehose with compression to control storage cost.

Common Rule Patterns and Use Cases

Here are six rule patterns that ANS-C01 candidates should know by heart.

Pattern 1: Egress FQDN allow-list

Use a domain list stateful rule group with TLS_SNI and HTTP_HOST target types. List the approved domains (*.amazonaws.com, *.salesforce.com, github.com). Set the default stateful action to drop established. Outbound traffic to any other FQDN is blocked at the firewall.

Pattern 2: Block known-bad IPs

Use a stateless rule group with destination IP set to the AWS-managed prefix list of known-bad IPs (or a custom prefix list you maintain). Stateless drops are fast and do not consume connection-tracking resources.

Pattern 3: IDS-only mode

Set all stateful rules to action alert instead of drop. The firewall observes traffic and produces alert logs without blocking. This is the recommended onboarding mode; you observe for a week, validate that legitimate traffic does not generate false-positive alerts, then flip the actions to drop.

Pattern 4: Outbound TLS inspection for compliance

Enable TLS inspection with an imported CA certificate. Configure a Suricata rule that drops traffic with specific TLS JA3 fingerprints associated with malware. Distribute the CA certificate to all workloads via SSM State Manager.

Pattern 5: East-west inspection

Use the centralized inspection VPC pattern with TGW appliance mode, but configure rules that match on RFC 1918 source and destination addresses. This inspects VPC-to-VPC traffic, not just outbound to the internet.

Pattern 6: Blocking DNS over HTTPS (DoH)

Combine domain list rules (deny dns.google, cloudflare-dns.com) with stateless rules dropping outbound to known DoH server IP ranges. This forces all DNS resolution through Route 53 Resolver where DNS Firewall can inspect queries.

Scenario Walkthroughs

Two scenarios that mirror the ANS-C01 question style:

Scenario A: Block all outbound traffic except approved FQDNs across 50 VPCs

Requirement: a financial services company has 50 production VPCs in 3 AWS Regions. The security team must enforce a single allow-list of approved SaaS domains for all outbound HTTPS traffic. Adding new domains must propagate within minutes. Compliance auditors require central reporting.

Correct answer: Build an AWS Network Firewall policy with a domain list rule group (TLS_SNI target, allow action) listing approved domains, and a default stateful action of drop established. Use AWS Firewall Manager to deploy the policy across the AWS Organization with a centralized inspection VPC per region (TGW + appliance mode). Logging to a central S3 bucket via Kinesis Firehose. Domain updates propagate via the rule group ARN — Firewall Manager re-evaluates within minutes.

Incorrect answer: NACLs (cannot match on FQDN), security groups (cannot match on FQDN), or per-VPC distributed firewalls without Firewall Manager (operational drift inevitable).

Scenario B: TLS inspection on egress for malware C2 detection

Requirement: a healthcare SaaS provider needs to detect malware command-and-control over HTTPS in outbound traffic from EC2 workloads. The security team has a list of malicious JA3 fingerprints from threat intel.

Correct answer: Enable AWS Network Firewall TLS inspection on the egress firewall. Import a CA certificate (from AWS Private CA) into ACM and reference it in the TLS inspection configuration. Distribute the CA cert to EC2 workloads via Systems Manager. Add Suricata rules with tls.ja3.hash matching to drop known-bad fingerprints. Send alert logs to a central security S3 bucket for SIEM ingestion.

Incorrect answer: AWS WAF (does not inspect outbound traffic), CloudWatch alarms on flow logs (no TLS visibility), GuardDuty alone (detects known threats but cannot perform inline inspection or blocking).

Common Exam Traps and Anti-Patterns

Other anti-patterns:

• Forgetting to enable appliance mode on the centralized inspection VPC TGW attachment.
• Trying to use ACM-requested public certificates as a CA for TLS inspection (ACM does not issue CA certs; you must import).
• Placing the firewall in a public subnet directly attached to the IGW — the firewall must be in its own dedicated subnet with explicit routes.
• Assuming that stateful rules block every packet equally — the stateful default action must be set to drop established or drop strict to actually block by default.
• Missing the flow:established keyword in Suricata rules, which causes the rule to match SYN packets without state.
• Forgetting that Suricata rules with sid collisions silently fail to load.
• Believing that AWS Network Firewall can decrypt any TLS traffic — it can only decrypt traffic where workloads trust the CA and the SNI is not pinned.

Pricing and Quotas

AWS Network Firewall is billed per firewall endpoint per hour (~ $0.395/hour per endpoint, varies by region) plus per-gigabyte processed (~ $0.065/GB). TLS inspection adds incremental processing charges. With three AZs of redundancy, the per-firewall hourly cost is roughly $850/month before traffic charges. For 50 VPCs in distributed mode, that is over $40,000/month — exactly why centralized inspection is so attractive.

Quota limits to remember: 30 stateless rules per rule group (default), 30 stateful rule groups per firewall policy, 1 TLS inspection configuration per firewall policy, 30,000 Suricata rules per stateful rule group (managed limit). For high-rule-count environments, request limit increases through Service Quotas.

Integration with Other AWS Services

AWS Network Firewall integrates tightly with AWS services:

• VPC: firewall endpoints are ENIs in a dedicated firewall subnet; routing tables determine traffic flow.
• Transit Gateway: inspection VPC pattern with appliance mode for centralized east-west and north-south inspection.
• Route 53 Resolver DNS Firewall: complementary service that filters DNS queries; pair with Network Firewall for full DNS + IP/L7 coverage.
• Firewall Manager: organization-wide policy deployment and drift remediation.
• CloudWatch Logs / S3 / Kinesis: log destinations for alerts and flow logs.
• Security Hub: alert logs feed into Security Hub findings.
• Lambda + EventBridge: automated remediation when high-severity alerts fire (for example, isolate compromised ENI).

FAQ

Q1: Is AWS Network Firewall stateful or stateless?

Both. AWS Network Firewall has two evaluation engines: a stateless engine that performs 5-tuple matching at line rate, and a stateful engine that runs Suricata-compatible rules with connection tracking. Traffic is always evaluated by the stateless engine first; if the stateless action is "forward to SFE" (the default), the packet proceeds to the stateful engine. The combination gives you fast filtering plus deep Layer 7 inspection.

Q2: Can AWS Network Firewall replace AWS WAF?

No. AWS WAF is a Layer 7 web application firewall that protects HTTP/HTTPS endpoints (CloudFront, ALB, API Gateway) against application-layer threats like SQLi, XSS, and bot abuse. AWS Network Firewall is a Layer 3-7 firewall that protects entire VPCs against network-layer threats and enforces FQDN-based egress policies. They serve different purposes — most production architectures use both: WAF at the edge in front of the load balancer, Network Firewall on the VPC routing path.

Q3: What is the difference between Network Firewall domain list rules and Route 53 Resolver DNS Firewall?

Route 53 Resolver DNS Firewall filters DNS queries at the resolver — it returns NXDOMAIN or a custom IP for blocked domains. AWS Network Firewall domain list rules filter actual TCP/HTTP/TLS traffic — they let DNS resolve normally but block the subsequent connection. DNS Firewall is cheaper and prevents the workload from learning the IP, which is usually preferred. Network Firewall domain rules catch traffic that uses hard-coded IPs or external DNS resolvers (DoH).

Q4: Why is appliance mode mandatory for centralized inspection?

Without appliance mode, Transit Gateway hashes traffic flows across AZs randomly. A single TCP connection might enter the inspection VPC through AZ-a but the return traffic could come back through AZ-b. The stateful firewall in AZ-b has no record of the original connection (state lives in AZ-a), so it drops the packet as out-of-state. Appliance mode pins a flow to one AZ for both directions, ensuring the same firewall endpoint sees the entire connection.

Q5: Can I use AWS Network Firewall to inspect VPC-to-VPC traffic?

Yes, via the centralized inspection VPC pattern. Spoke VPCs route inter-VPC traffic to Transit Gateway; TGW routes the traffic to the inspection VPC firewall endpoint; the firewall inspects and forwards back to TGW; TGW routes to the destination spoke. East-west inspection is one of the most common centralized inspection use cases.

Q6: How does Network Firewall handle traffic that uses non-standard TLS or custom protocols?

Stateful Suricata rules support generic TCP and IP matching, so you can block traffic by 5-tuple even without protocol-specific parsing. For non-TLS encrypted protocols, you cannot inspect payload content without protocol-specific decryption (which AWS Network Firewall does not provide for non-TLS). The fallback is to allow-list known-good IPs and block everything else.

Q7: What logging mode should I enable for ANS-C01-style production?

Both alert logs and flow logs. Send alert logs to S3 for long-term retention and SIEM ingestion (typical retention: 1 year for compliance). Send flow logs to Kinesis Firehose with parquet conversion to S3 for ad-hoc Athena queries. Alarms on alert log volume detect attack waves; flow log volume detects baseline traffic anomalies.

Q8: How do I migrate from a third-party firewall appliance to AWS Network Firewall?

Phase 1: deploy Network Firewall in IDS-only mode (alert action everywhere) alongside the existing appliance. Phase 2: validate alert logs match expected traffic patterns; refine rules. Phase 3: switch alert to drop in the inspection rules. Phase 4: remove the third-party appliance from the routing path. The IDS-only phase is critical to avoid blocking legitimate traffic during cutover.

Q9: Does Network Firewall support High Availability across AZs?

Yes — AWS Network Firewall is designed to be deployed with one firewall endpoint per AZ. Each endpoint is highly available within its AZ (AWS manages capacity behind the ENI). For multi-AZ resilience, deploy endpoints in at least two AZs and configure subnet route tables to direct traffic to the AZ-local endpoint. The exam expects multi-AZ for any production-grade answer.

Q10: Can Network Firewall block lateral movement within a single VPC?

Indirectly. Network Firewall sits on routing paths between subnets, so traffic that traverses a subnet boundary can be inspected. For lateral movement within the same subnet (instance-to-instance), use security groups with referenced source SGs. The combination of subnet-level routing through Network Firewall plus instance-level security groups gives you full lateral movement protection.

Summary: AWS Network Firewall Answer Patterns

When you read an ANS-C01 question that involves Network Firewall, run through this checklist:

• Is the requirement to block egress by FQDN? → AWS Network Firewall domain list rule group with TLS_SNI/HTTP_HOST.
• Is the requirement to inspect TLS payloads for malware? → AWS Network Firewall TLS inspection with imported CA cert.
• Is the requirement to enforce rules across 10+ VPCs? → AWS Firewall Manager with Network Firewall policy.
• Is the requirement to centralize inspection cost-efficiently? → Centralized inspection VPC + TGW with appliance mode.
• Is the question about why a stateful rule does not fire? → Check stateless engine first (it may be dropping or not forwarding).
• Is the question about asymmetric routing between AZs? → Appliance mode on TGW attachment.
• Is the question about TLS inspection certificate setup? → Import CA cert into ACM (cannot request).

AWS Network Firewall is the predictable answer for VPC-level deep packet inspection, FQDN-based egress filtering, and TLS visibility. Master the stateless-first evaluation order, the appliance mode requirement, the imported CA certificate flow, and the Firewall Manager organization model, and Domain 4 questions on Network Firewall become pattern-matching exercises.