AWS Network Firewall & Centralized Egress

Recap: From Peered Transit Gateways to a Single Inspection Point

Foundations You'll Need Today

1. Why This Is on the Exam

Every organization that runs more than a handful of VPCs eventually hits the same governance problem: outbound internet access is the single largest uncontrolled surface in the account, and the default answer — a NAT Gateway per VPC — gives you connectivity with no visibility and no policy. A NAT Gateway will happily forward traffic to any destination on any port. It logs nothing about what was requested. If a workload is compromised and starts beaconing to a command-and-control domain, the NAT Gateway is a perfect accomplice. The architectural problem Network Firewall solves is inserting a policy enforcement and inspection point into that path without forcing every VPC to own and operate its own firewall fleet.

This maps most directly to SAP-C02 Domain 1, Design Solutions for Organizational Complexity, and it shows up in two recurring shapes. The first is a governance scenario: a security team wants a single place to enforce egress allowlists, block categories of domains, and produce evidence that inspection happened, across dozens of accounts. The second is a hybrid scenario: traffic from on-premises over Direct Connect or VPN must be inspected before it reaches workload VPCs, and the same inspection layer must handle east-west traffic between VPCs. Both shapes point at the same answer, and the distractors are predictable — per-VPC firewalls, security groups alone, NACLs alone, or a third-party appliance fleet that the question has quietly made operationally infeasible.

The reason this is worth a full day rather than a paragraph is that the exam tests the routing, not the firewall rules. Candidates who understand Suricata syntax but cannot explain why a spoke's route table needs a specific entry will pick the wrong option. The inspection VPC pattern is fundamentally a routing architecture with a firewall sitting inside it, and the questions are written to reward that framing.

2. How Network Firewall Actually Works

A Network Firewall is a managed, highly available appliance that AWS deploys into subnets you designate, one firewall endpoint per Availability Zone. You do not manage instances, patching, or scaling; you manage policy. The firewall is attached to a VPC, and you choose which subnets it lives in — conventionally a dedicated firewall subnet in each AZ of the inspection VPC. Each of those subnets gets an endpoint with its own IP address, and traffic reaches the firewall by being routed to that endpoint's IP. This is the detail that makes the whole pattern work: the firewall is not transparent. It is a routable next hop.

Policy is expressed in a firewall policy, which references stateless rule groups and stateful rule groups, plus a default action for each direction. Stateless rules are evaluated first, in priority order, against individual packets with no connection tracking. They are fast and cheap, and they are the right tool for coarse decisions — drop all traffic to a known-bad CIDR, or pass traffic destined for a specific range without further inspection. Stateful rules are evaluated after, using a flow table that tracks connections, and they are where Suricata-compatible rules live. A stateful rule can match on domain names, TLS SNI, HTTP host headers, and payload signatures, which is what makes domain-based egress control possible at all.

The Suricata compatibility matters more than it first appears. Network Firewall accepts Suricata rule syntax for stateful rule groups, which means an organization with an existing Suricata ruleset or an IDS team already fluent in the format can port rules rather than relearn a proprietary language. AWS also ships managed rule groups maintained by AWS threat intelligence, covering known malicious domains and threat signatures, which you can attach without writing anything. The practical consequence is that a firewall policy is usually a composition: managed rule groups for baseline threat detection, custom Suricata rules for organization-specific allowlists and blocks, and stateless rules for the coarse traffic you want to short-circuit before it reaches the stateful engine.

Logging is a first-class part of the mechanism, not an afterthought. Network Firewall can emit flow logs, alert logs, and TLS logs to CloudWatch Logs, S3, or Kinesis Data Firehose, and the choice of which log types to enable is a real cost and volume decision. Alert logs record traffic that matched a rule with an alert action; flow logs record connection-level metadata; TLS logs record SNI and certificate information for inspected TLS flows. In a centralized inspection VPC, these logs are typically shipped to the same log-archive account that Day 3's Control Tower landing zone provisions, which is how the pattern composes with the rest of the governance baseline.

3. The Core Decision Boundary: Where Does Inspection Live?

The fork every scenario question hinges on is whether inspection is distributed or centralized. Distributed means each VPC owns its own firewall, its own policy, and its own logs. Centralized means one inspection VPC — usually in a dedicated network account — owns the firewall, and every other VPC routes through it. The exam almost always rewards centralized, but the reason is not dogma; it is that the centralized pattern makes policy consistent by construction and makes the audit trail single-sourced. A distributed fleet drifts: one team tightens a rule, another never applies the update, and six months later nobody can answer what the organization's actual egress policy is.

The cost of centralization is that the inspection VPC becomes a critical path. If its route tables are wrong, every spoke loses internet access simultaneously. That is a real tradeoff and the exam does probe it, usually by asking what happens when the inspection VPC's firewall endpoint is unavailable in one AZ. The answer is that traffic in that AZ fails unless the spoke subnets have routes to firewall endpoints in multiple AZs, which is why the pattern always deploys endpoints in every AZ the inspection VPC spans.

The decision boundary is therefore not "should we use Network Firewall" but "which traffic must traverse the inspection VPC." A common and exam-relevant refinement is to inspect only egress to the internet and traffic crossing a trust boundary, while allowing intra-VPC traffic and traffic between tightly coupled services to bypass inspection entirely. Routing everything through the hub is simpler to reason about but adds latency and cost to traffic that never needed inspection.

4. Configuration Modes and Their Tradeoffs

The first knob is stateless versus stateful evaluation, and the tradeoff is throughput against expressiveness. Stateless rule groups are evaluated per packet with no flow tracking, so they are the cheapest thing the firewall can do and they run first. A stateless rule can drop traffic to a CIDR, or pass traffic that you have already decided is safe, and by doing so it removes that traffic from the stateful engine's workload. Stateful rule groups maintain a flow table and can match on application-layer attributes — domain, SNI, HTTP host — but they cost more per connection and they are where the interesting policy lives. The practical pattern is to use stateless rules as a coarse filter and stateful rules for the decisions that actually require context.

The second knob is rule group type within the stateful category. Suricata-compatible rule groups give you the full expressive syntax and are the right choice when you have existing rules or need domain and signature matching. Domain list rule groups are a simplified form that takes a list of domains and an allow-or-deny action, which covers the most common egress-control requirement without writing Suricata at all. Both can coexist in one policy, and the exam does not usually care which you pick as long as you understand that domain-based control requires stateful evaluation — a stateless rule cannot see a domain name.

The third knob is the default action for each direction, and this is where most real-world incidents originate. A firewall policy has a default action for stateless and stateful evaluation, and the safe posture is to default to drop and explicitly allow. The dangerous posture is to default to pass and add deny rules, because a missed rule becomes an open door rather than a blocked flow. The exam frames this as a security requirement — "only approved destinations may be reached" — and the answer is always the allowlist posture.

The fourth knob is logging configuration, which is a genuine cost decision. Enabling flow logs on a busy inspection VPC can produce very large volumes, and the exam occasionally tests whether you would enable all log types by default. The defensible answer is to enable alert logs always, enable flow logs where you need connection-level forensics, and treat TLS logs as a targeted tool for specific investigations rather than a permanent setting.

5. Sizing, Limits and Quotas

Network Firewall scales automatically with traffic, but the quotas that matter are about how many policies, rule groups, and endpoints you can have, and how large a rule group can be. Each VPC can have one firewall, and each firewall has one firewall policy. A firewall policy can reference multiple stateless and stateful rule groups, and rule groups can be shared across accounts using AWS Resource Access Manager — which is the mechanism that lets a central security account author policy once and have every spoke account's firewall consume it. That RAM integration is the detail that makes the centralized pattern operationally sane at scale, and it connects directly to Day 6's shared-resource model.

Endpoint placement determines availability. A firewall deployed into N subnets has N endpoints, and traffic only survives an AZ failure if the routing in the source VPC can reach an endpoint in a surviving AZ. The standard design is one firewall subnet per AZ in the inspection VPC, with the spoke's route table pointing at the Transit Gateway and the TGW route table pointing at the inspection VPC attachment, which itself resolves to endpoints in all AZs. The exam-relevant consequence is that a single-AZ inspection VPC is a single point of failure for every spoke's internet access.

Because AWS publishes exact quota values and revises them periodically, the exam-safe approach is to know the shape of the limits — one firewall per VPC, one policy per firewall, endpoints per AZ, rule groups shared via RAM — rather than to memorize a number that may have changed. Where a question gives you a specific number, it is almost always testing whether you recognize that the number is a quota you can request an increase for, not a hard architectural wall.

6. Failure Modes and What They Look Like in Production

The signature failure of this pattern is total egress loss from every spoke, and it almost always traces to a route table. The chain has four links: the spoke subnet route table must send 0.0.0.0/0 to the Transit Gateway; the TGW route table must have a route to the inspection VPC attachment; the inspection VPC's subnet route table must send traffic to the firewall endpoint; and the firewall policy must allow the flow. Break any one and the symptom is identical — connections time out — which is why the first diagnostic move is to walk the chain in order rather than to start reading firewall logs. If the firewall logs show nothing at all, the traffic never arrived, and the problem is upstream in routing.

The second failure mode is asymmetric routing, which produces connections that establish and then hang. This happens when the return path from the internet or from a peered VPC does not traverse the same firewall endpoint that the outbound path used. Network Firewall is stateful, so a flow whose return traffic bypasses the firewall is dropped as out-of-state. The symptom is a connection that completes a TCP handshake and then stalls, and the fix is to ensure the inspection VPC is on both the outbound and return path — typically by making the inspection VPC the only route to the internet for the spokes, so there is no alternate return path.

The third failure mode is a rule that is syntactically valid but semantically wrong, most commonly a Suricata rule with an action that does not match its intent, or a domain rule that matches a subdomain when the intent was the apex. These show up as alert logs full of entries for traffic you believed you were allowing, or as a specific application failing while everything else works. The diagnostic move is to enable alert logging temporarily and read what the firewall thinks it matched, rather than to reason about the rule in the abstract.

The fourth is endpoint capacity in a single AZ. If the inspection VPC has endpoints in only one AZ and that AZ has an issue, every spoke loses egress even though the firewall itself is healthy. This is not a firewall failure at all; it is a routing and placement failure that the firewall's health metrics will not reveal.

7. The Operational and SRE Angle

Because the inspection VPC sits on the critical path for every spoke's internet access, it deserves the same SLO treatment as a production database. The availability target for the inspection layer is effectively the availability target for every workload that needs egress, and that framing changes what you monitor. CloudWatch metrics for the firewall expose received and dropped packet counts, and a sudden drop to zero received packets is the clearest possible signal that routing has broken upstream — it is a better alarm than any error-rate metric on the applications themselves, because it fires before the applications start failing.

The alarm set that matters is small. An alarm on firewall endpoint availability per AZ catches the placement failure. An alarm on received packets dropping to zero catches the routing failure. An alarm on the volume of alert-log entries catches a rule that is suddenly matching far more traffic than expected, which is often the first sign of a compromised workload attempting to reach blocked destinations. And an alarm on the Transit Gateway attachment state catches the case where the inspection VPC has become unreachable from the hub. Together these four cover the failure modes from the previous section without generating noise.

The runbook shape follows the routing chain. Step one is to confirm whether traffic is arriving at the firewall at all, using the received-packets metric. If it is not, the runbook walks the four route-table links in order. If it is arriving and being dropped, the runbook moves to the policy and reads the alert logs. If it is arriving and passing but the application still fails, the runbook checks for asymmetric routing on the return path. Writing this down matters more than usual here, because the failure is total and the pressure to guess is high.

Change management is the other SRE concern. A firewall policy change is a change to every spoke's connectivity, so it should go through the same pipeline as application code — versioned, reviewed, and deployed with a rollback path. The exam does not usually ask about this directly, but it does ask about operational excellence, and "policy changes are deployed through a pipeline with automated rollback" is the answer that fits the Well-Architected framing from Day 41.

8. Edge Cases and Exam Gotchas

The most common trap is assuming Network Firewall inspects traffic automatically once it exists. It does not. The firewall is a routable endpoint, and traffic only reaches it if route tables send it there. A question that describes a firewall deployed correctly but with unchanged spoke route tables is describing a firewall that is doing nothing, and the answer is to fix the routing.

The second trap is confusing Network Firewall with security groups and NACLs. Security groups are stateful and instance-level; NACLs are stateless and subnet-level; neither can inspect domain names or payload signatures. A question that requires blocking a specific domain or detecting a signature cannot be answered with security groups, no matter how the options are phrased.

The third trap is the direction of inspection. Network Firewall inspects traffic in both directions, but the routing must be symmetric for stateful inspection to work. A design that routes outbound traffic through the inspection VPC but lets return traffic come back directly will fail, and the exam will describe exactly that symptom — connections that establish and then hang.

The fourth trap is the relationship to Gateway Load Balancer. Both can insert inspection into a path, but Network Firewall is a managed service with its own policy model, while Gateway Load Balancer is a mechanism for distributing traffic to third-party appliance fleets. A question that specifies a third-party firewall vendor is pointing at Gateway Load Balancer; a question that specifies AWS-native inspection with Suricata rules is pointing at Network Firewall.

The fifth trap is log volume and cost. Enabling every log type on a high-traffic inspection VPC is expensive, and a question that mentions cost sensitivity alongside logging requirements is testing whether you would enable alert logs and targeted flow logs rather than everything.

9. Network Firewall vs. the Alternatives

The alternatives fall into three groups: native AWS controls that cannot inspect, third-party appliances that can inspect but require you to run them, and the managed service that does both. Placing a scenario into the right group is most of the work.

The rule of thumb: if the requirement is "control what can be reached," Network Firewall is the answer. If the requirement is "reach AWS services without touching the internet," a VPC endpoint is cheaper and faster and removes the traffic from the inspection path entirely — which is itself an exam-relevant optimization, because the best way to reduce inspection cost is to not send traffic through the inspector. If the requirement names a third-party vendor, Gateway Load Balancer is the insertion mechanism and Network Firewall is the wrong answer.

Hands-on Lab: Centralized Egress Through an Inspection VPC

Scenario Question Drills

Peek into Tomorrow

Sources