Skip to content

CONCEPT Cited by 1 source

Centralized network inspection

Centralized network inspection is the architectural shape where a single managed firewall / IDS/IPS point sits between all traffic-producing networks (VPCs, on-prem data centres, the internet) and their destinations — one policy, one log stream, one inspection engine — rather than deploying per-VPC firewalls or relying on per-workload agent policy. Traffic is steered through the central inspection point by routing changes, not by application changes (it is a bump-in-the-wire middlebox at the fabric level).

What "centralized" means

Three properties jointly:

  1. One inspection engine per administrative domain, not one per VPC / account / subnet.
  2. All named traffic flow classes pass through it — east-west (VPC↔VPC), north-south (VPC↔on-prem, VPC↔internet), and the diagonal (on-prem↔internet if that transits the cloud provider).
  3. Inspection is driven by routing, not by endpoint configuration. The packet gets to the inspection device because the source's route table points at a fabric hop (TGW, VXLAN, service-chain) that directs it there; the source application and OS are unchanged.

Canonical AWS shape (2025-11-26 post)

Transit Gateway as the regional hub, with a two-route-table split (see patterns/pre-inspection-post-inspection-route-tables):

 VPC1 attachment ─┐
 VPC2 attachment ─┤──► Pre-inspection RT (0.0.0.0/0 → Firewall attach)
 VPC3 attachment ─┤
 DXGW attachment ─┘          │
                             ▼
                  AWS Network Firewall (TGW-native attachment,
                  Appliance Mode on, managed inspection VPC)
                             │
                             ▼
                  Post-inspection RT (per-destination CIDRs →
                  each VPC / DXGW attachment)

All VPCs + the Direct Connect Gateway attach to the pre-inspection RT; its default route forces traffic into the firewall attachment. The firewall attachment sits on the post-inspection RT, which holds return routes to each original destination. Result: every cross-VPC, VPC-to-on-prem, VPC-to-internet, and on-prem-to- internet packet is inspected by one engine.

Benefits

  • Single point of control. One firewall policy for many VPCs and accounts; avoids the drift of per-VPC security groups / per-subnet NACLs getting out of sync.
  • Unified logging. One alert-log and one flow-log stream for the whole inspection domain; dramatically easier incident response, traffic-pattern analysis, and compliance evidence than stitching per-VPC firewall logs together.
  • Uniform rule enforcement across heterogeneity. VMware workloads (EVS), container workloads (EKS), serverless, and on-prem all pass through the same rule set.
  • Horizontal scaling is the firewall's problem, not the tenant's. In managed implementations like AWS Network Firewall with TGW native attachment, capacity scales inside the inspection VPC without tenants reconfiguring.

Costs and caveats

  • Failure-mode blast radius. A misconfiguration of the central firewall can blackhole every inspected flow simultaneously. Mitigations: stage rule-group changes, monitor rule-drop rates, keep emergency-bypass routes ready (the AWS post's pre-inspection RT can be temporarily repointed).
  • Inspection bandwidth + latency tax. All cross-boundary traffic takes an extra TGW hop and a firewall-endpoint hop. Tolerable for policy-enforced flows but pathological for high-fanout intra-VPC east-west; operators sometimes exempt intra-VPC flows by leaving them on the VPC's local route rather than default-routing them to TGW.
  • Appliance Mode is non-optional for stateful inspection across TGW. Without Appliance Mode, TGW can hash a flow's two directions to different AZ endpoints of the firewall, and stateful connection tracking breaks. The 2025-11-26 post's native TGW ↔ Network Firewall attachment enables Appliance Mode automatically.
  • Asymmetric-routing landmines. The operator must hand- verify that the return path also transits the firewall; it's easy to put the default route on the pre-inspection RT but forget RFC-1918 return routes on an Ingress / Egress VPC's local route table, giving one-way inspection.
  • Overlay networks need help reaching the AWS-native RT. Example: EVS's NSX overlay segments have to be propagated into the VPC RT by VPC Route Server for TGW to know a route to them.

Alternatives

  • Distributed per-workload firewalls — host / container agents enforcing policy at the egress point of each workload (NetworkPolicy on Kubernetes, iptables per host, sidecars). Scales horizontally with the workload; no inspection hop; but multiplies the policy surface and obscures the "show me all egress to external.example.com" query.
  • Per-VPC firewall endpoints — one Network Firewall per VPC, no TGW hub. Simpler blast radius (each VPC's firewall is independent) but multiplies policy + logging surface linearly in VPC count.
  • Service mesh / L7 — Istio / Envoy / App Mesh enforce policy at the application layer. Orthogonal axis, not a replacement: typically deployed in addition to network-layer inspection as defense-in-depth.

Seen in

Last updated · 200 distilled / 1,178 read