AWS Network Firewall can protect one VPC directly or become part of a centralized inspection architecture that filters traffic across many VPCs and accounts. Centralization promises consistent policy and fewer duplicated appliances, but it also introduces a critical networking requirement: stateful firewalls must see both directions of a flow. If Transit Gateway, VPC routing, or Availability Zone behavior sends return traffic around the firewall, the security policy may fail even though every individual route looks plausible.<\/p>\n
The current AWS Certified Advanced Networking \u2013 Specialty (ANS-C01)<\/a> exam includes AWS Network Firewall, Transit Gateway, VPC routing, security appliances, and network operations in its advanced networking scope. A centralized inspection design therefore requires more than knowing rule syntax. Candidates should understand endpoint placement, route tables, appliance mode, symmetry, segmentation, failure behavior, and the operational evidence needed to prove that traffic was actually inspected.<\/p>\n A common centralized pattern places AWS Network Firewall in a dedicated inspection VPC. Workload VPCs attach to Transit Gateway, Transit Gateway routes send selected traffic toward the inspection VPC, and the inspection VPC routes traffic through Network Firewall endpoints before returning it to Transit Gateway or forwarding it toward an internet, hybrid, or other destination.<\/p>\n This separation keeps firewall endpoints and inspection routes under a platform or security team while workload teams retain their application subnets. It also makes the inspection path explicit. Do not place unrelated shared services in the inspection VPC merely because it already participates in many routes. Mixing DNS, directory services, management tools, and firewall endpoints in one routing domain can make failures and ownership ambiguous.<\/p>\n The basic network segmentation<\/a> principle applies: boundaries should reflect trust and function. An inspection VPC is most valuable when its purpose is clear and its routes can be audited independently from the workloads it protects.<\/p>\n Document the exact endpoint used for each Availability Zone. Centralized firewalls can become difficult to troubleshoot when route tables point to endpoints by opaque identifiers with no human-readable mapping. Tag endpoint-related subnets and maintain a simple AZ-to-endpoint inventory so operators can tell whether a route is keeping traffic local or sending it across zones.<\/p>\n AWS Network Firewall creates endpoints in selected Availability Zones. The VPC route tables must steer inspected traffic through those endpoints. For east-west inspection, both sides of the flow need routes that cause the packet and its return to traverse the inspection path. For north-south traffic, the inspection VPC may sit between Transit Gateway and an internet gateway or between Transit Gateway and hybrid connectivity.<\/p>\n Do not validate only the forward path. A packet may travel from a workload VPC to the firewall and then to the destination while the return path chooses a more direct route. Stateful inspection then sees only one direction and can drop or misclassify the flow. Draw the return path explicitly for every inspection pattern, including failover and cross-AZ behavior.<\/p>\n Route tables should be purpose-specific. Inspection subnets, Transit Gateway attachment subnets, and internet-edge subnets often need different tables. Reusing one table everywhere can create shortcuts that bypass the firewall. Name and tag tables by role so operators can distinguish \u201cTGW-to-firewall\u201d from \u201cfirewall-to-egress\u201d without opening every route entry.<\/p>\n When a centralized stateful appliance sits behind a Transit Gateway VPC attachment, appliance mode is a critical design setting. It helps Transit Gateway keep a flow mapped to the same network interface in the appliance VPC for the lifetime of the flow, supporting symmetric routing through the same stateful inspection path.<\/p>\n Without appliance mode, Transit Gateway normally attempts to preserve Availability Zone affinity between attachments. That behavior can conflict with centralized inspection when the firewall path spans zones or when forward and return traffic arrive through different attachment characteristics. The result can be intermittent drops that look like firewall rule problems even though the real issue is flow symmetry.<\/p>\n Appliance mode is not a magic fix for all asymmetry. The architecture still needs correct VPC routes, Transit Gateway route tables, and consistent ingress and egress paths. It also has documented constraints when traffic reaches the inspection VPC from different gateways. Treat appliance mode as one part of a complete symmetry design rather than a checkbox that excuses route analysis.<\/p>\n Return routing from egress components needs equal attention. If an internet gateway, NAT gateway, or hybrid attachment returns traffic to a route table that bypasses the firewall, stateful sessions can fail or traffic can escape inspection. Centralized inspection diagrams should show the egress-side route table explicitly instead of ending the picture at the firewall.<\/p>\n Transit Gateway route tables determine which attachments can reach which destinations. A centralized firewall architecture can use separate route tables for spoke VPCs, inspection, shared services, and egress. Spoke VPCs can send broad destinations to the inspection attachment, while the inspection side can route approved traffic onward after filtering.<\/p>\n Segmentation is stronger when routing itself prevents direct spoke-to-spoke communication. If every workload attachment propagates into one global route table, the firewall may be bypassed by a more direct Transit Gateway route. Use associations and propagations deliberately so the only allowed path between security zones is the one that crosses inspection.<\/p>\n The AWS Certified Solutions Architect \u2013 Professional (SAP-C02)<\/a> perspective helps here: centralized routing should serve organizational architecture, not just firewall convenience. Account boundaries, business units, shared services, and hybrid connections may require different route domains even when they share one Transit Gateway.<\/p>\n Rule capacity and policy size are operational constraints. As managed and custom rule groups grow, teams should track quotas and avoid accumulating disabled or obsolete rules indefinitely. A smaller, well-owned policy is easier to test and explain than a historical collection whose order and interaction nobody fully understands.<\/p>\n AWS Network Firewall supports stateless and stateful inspection. Stateless rules evaluate packets without connection context and can pass, drop, or forward traffic for stateful processing depending on policy. Stateful rules track flows and can evaluate protocol and application behavior using supported rule formats and managed rule groups.<\/p>\n Use stateless rules for deterministic packet-level decisions that do not require connection context, and stateful rules when the policy depends on the flow or application protocol. Avoid duplicating the same intent across multiple layers without a clear reason; otherwise operators may not know which rule actually caused a drop.<\/p>\n Managed rule groups can accelerate common protections, but they still need change control and testing. A rule update can block legitimate traffic across every VPC that uses the centralized policy. Stage policy changes, monitor alerts before switching to drops where appropriate, and maintain exception governance. A centralized firewall amplifies both good policy and mistakes.<\/p>\n Consider how autoscaling workloads react to zonal disruption. New instances may launch in a healthy zone while their traffic still follows routes designed around the failed zone. Failure testing should include route-table state, endpoint availability, and actual workload placement rather than treating Network Firewall endpoints as isolated appliances.<\/p>\n Centralized inspection should avoid forcing traffic through a single Availability Zone. Deploy firewall endpoints across the zones that the architecture requires and design routes so traffic can use local inspection capacity where appropriate. Cross-AZ routing can increase latency and data-transfer cost, and a zonal failure can become a larger outage if all flows depend on one endpoint path.<\/p>\n High availability requires more than multiple endpoints. Route tables, Transit Gateway attachments, and egress paths must still function when one zone is impaired. Test what happens to new flows and existing stateful sessions when an endpoint or zone becomes unavailable. Some sessions may reset even though the architecture recovers quickly for new connections.<\/p>\n Cost is part of the design as well. Centralized inspection can simplify administration but may add Transit Gateway processing, firewall processing, and cross-AZ data transfer. Compare those costs with distributed firewalls and account-level policy. The cheapest topology on a diagram can be expensive once east-west traffic volume is included.<\/p>\n A security platform team may own baseline protections such as known malicious domains, prohibited protocols, and mandatory logging. Application teams still understand business-specific destinations and change windows better. Build an exception process that preserves central governance while allowing workload context to be reviewed rather than forcing every change through an opaque global rule set.<\/p>\n Tags, rule-group naming, and policy versioning should identify owners and intent. When an application is blocked, the operator should be able to determine which rule group matched and which team can approve a change. A giant undifferentiated policy may technically centralize security while making incident response slower.<\/p>\nSeparate the inspection VPC from workload routing<\/h3>\n
Route traffic through firewall endpoints in both directions<\/h3>\n
Enable Transit Gateway appliance mode for stateful inspection<\/h3>\n
Use Transit Gateway route tables to enforce segmentation<\/h3>\n
Design stateless and stateful rule groups for different jobs<\/h3>\n
Plan Availability Zones and failure behavior<\/h3>\n
Centralize policy without centralizing every exception<\/h3>\n