AWS Multi-Account Transit Gateway Security: Centralized Egress Firewalls & Network Firewall Rules

Provisioning individual NAT Gateways and internet egress routes across dozens of AWS member accounts inflates cloud costs and shatters enterprise security visibility. The industry standard pattern for multi-account AWS organizations leverages AWS Transit Gateway (TGW) paired with a centralized Inspection & Egress VPC powered by AWS Network Firewall. In this end-to-end architecture guide, we construct a production hub-and-spoke topology that enforces centralized Suricata TLS domain filtering, isolates development and production traffic across segmented TGW route tables, and achieves a 65% reduction in NAT gateway infrastructure spend.

1. The Multi-Account Architecture Challenge

In decentralized AWS environments, each workload VPC typically deploys its own public subnets, NAT Gateways, and Internet Gateways. This leads to two critical operational issues:

• Cost Inefficiency: Each AWS NAT Gateway incurs an hourly base charge plus data processing costs. Maintaining redundant NAT gateways across 20 accounts results in thousands of dollars in wasted baseline expenditure.
• Lack of Central Egress Governance: Security teams cannot enforce consistent outbound domain allowlists or inspect data exfiltration attempts when each VPC routes directly to the internet.

2. Hub-and-Spoke Topology with Inspection VPC

The centralized egress pattern directs all outbound internet traffic from spoke VPCs through AWS Transit Gateway into a dedicated Security Inspection VPC containing AWS Network Firewall and a high-availability pool of centralized NAT Gateways:

Spoke VPC (Prod)   ---> [ TGW Prod Route Table ]
                                |
Spoke VPC (Dev)    ---> [ TGW Dev Route Table  ]
                                |
                                v
                   [ AWS Transit Gateway ]
                                |
                                v
               [ TGW Attachment in Inspection VPC ]
                                |
                                v
              [ AWS Network Firewall (Stateful IPS) ]
                                |
                                v
               [ Centralized NAT Gateways (Multi-AZ) ]
                                |
                                v
                    [ Internet Gateway (IGW) ]

3. Terraform Blueprint: Centralized AWS Network Firewall

Deploy a stateful AWS Network Firewall rule group enforcing strict TLS Server Name Indication (SNI) allowlisting for outbound egress traffic:

# Define Suricata Stateful Rule Group for Egress Filtering
resource "aws_networkfirewall_rule_group" "egress_domain_filter" {
  capacity = 1000
  name     = "nfw-egress-domain-allowlist"
  type     = "STATEFUL"

  rule_group {
    rules_source {
      rules_source_list {
        generated_rules_type = "ALLOWLIST"
        target_types         = ["TLS_SNI", "HTTP_HOST"]
        targets = [
          ".amazon.com",
          ".amazonaws.com",
          ".github.com",
          ".docker.com",
          "cloudknowledge.in"
        ]
      }
    }
  }
}

# AWS Network Firewall Policy
resource "aws_networkfirewall_firewall_policy" "central_security_policy" {
  name = "nfw-central-inspection-policy"

  firewall_policy {
    stateless_default_actions          = ["aws:forward_to_sfe"]
    stateless_fragment_default_actions = ["aws:forward_to_sfe"]
    stateful_rule_group_reference {
      resource_arn = aws_networkfirewall_rule_group.egress_domain_filter.arn
    }
  }
}

4. Route Table Segregation: Preventing East-West Lateral Compromise

To ensure non-production environments cannot communicate directly with production databases across Transit Gateway, configure segregated TGW route tables:

• TGW Spoke Prod Route Table: Associated with Production Spoke VPCs. Contains route 0.0.0.0/0 pointing to the Inspection VPC attachment. Disables cross-propagation to the Dev TGW route table.
• TGW Spoke Dev Route Table: Associated with Development Spoke VPCs. Outbound traffic routes strictly to Inspection VPC. Production subnets are completely unreachable.
• TGW Post-Inspection Route Table: Receives inspected return traffic and forwards packets back to the originating spoke VPC.

5. Troubleshooting Asymmetric Routing & Blackholes

When implementing centralized firewall inspection with Transit Gateway, the most common operational failure is asymmetric routing (where outbound packets pass through the firewall endpoint in AZ-a, but return packets traverse AZ-b). AWS Network Firewall is stateful; if it does not observe both directions of the TCP handshake on the same endpoint, it drops the connection.

Remediation: Deploy dedicated TGW subnets in the Inspection VPC with strict 1:1 AZ mapping to Network Firewall endpoints and NAT Gateways. Ensure each AZ route table directs return traffic strictly to its local Transit Gateway attachment ENI.