The Egress VPC Pattern for Centralised Internet Access

Many VPCs each with their own NAT gateway is wasteful. The egress VPC pattern centralises and saves.

Structure

The egress VPC pattern centralizes outbound internet traffic from many VPCs through one dedicated egress VPC. Instead of every spoke VPC having its own NAT gateways and egress controls, one egress VPC handles the egress for all spokes. The pattern saves significant cost at scale and simplifies egress filtering.

What the structure looks like:

• Dedicated VPC for internet egress.: One VPC is designated for egress. It hosts NAT gateways, internet gateway, and any egress filtering infrastructure (firewalls, proxies, traffic inspection). The egress VPC is the single hub for outbound traffic.
• Other VPCs route via Transit Gateway.: Spoke VPCs do not have their own internet egress paths. Their default route for internet traffic points at the Transit Gateway, which forwards to the egress VPC. The TGW is the connectivity layer.
• Single set of NAT gateways serves all spoke VPCs.: The NAT gateways in the egress VPC handle outbound traffic from all spokes. Cross-AZ for redundancy; same set of gateways regardless of how many spoke VPCs are added. The economics improve as the spoke count grows.
• Centralized egress filtering.: Egress firewalls (AWS Network Firewall, third-party appliances behind Gateway Load Balancer) sit in the egress VPC. Traffic is inspected once on its way to the internet; the policy is enforced consistently across all spokes.
• Egress VPC sized for the aggregate.: The egress VPC's NAT gateways must handle the aggregate traffic of all spokes. Sizing accounts for total throughput; oversizing is cheap relative to the savings from consolidation.

The structure is the foundation. The savings and the operational benefits both come from getting the structure right.

Savings

The egress VPC pattern produces real cost savings at scale. The savings come from two sources: fewer NAT gateways and centralized egress filtering instead of per-VPC duplication.

• Fewer NAT gateways.: Each NAT gateway has a per-AZ hourly baseline cost (currently around $32 per gateway per month plus per-GB processing). Without the egress pattern, each spoke VPC has its own NAT gateways per AZ. With the pattern, the spokes share the egress VPC's gateways.
• Per-AZ baseline cost saved.: A 10-VPC environment in 3 AZs without the pattern has 30 NAT gateways. With the pattern, it has 3. The hourly cost difference is roughly $864 per month at 10 VPCs; the savings scale with the spoke count.
• Centralized egress filtering.: One place to enforce policy. One firewall configuration; one set of rules; one audit surface. The operational savings are real: changes apply once, not per VPC.
• Reduced data transfer for cross-VPC.: Traffic between spoke VPCs that needs internet egress no longer traverses NAT in each VPC; it routes through the central egress. The cost of transit is bounded.
• Single audit and compliance surface.: Auditors and compliance reviewers look at one egress configuration, not many. The conversation is shorter; the controls are demonstrably consistent.

The savings are real and measurable. At low spoke counts, the cost difference is modest; at high spoke counts, it is significant.

Trade-offs

The egress VPC pattern is not free. The trade-offs are real and should be understood before adopting the pattern. The pattern is the right choice when the trade-offs are acceptable; not all environments fit.

• Single point of failure.: The egress VPC concentrates the egress path. Failures in the egress VPC affect all spokes. The pattern requires careful redundancy: NAT gateways in multiple AZs, redundant firewalls, redundant TGW attachments. Without redundancy, the central egress is fragile.
• Design for redundancy.: The redundancy is not free; it is the cost of consolidating. Multi-AZ NAT, active-active firewall pairs, careful route table design. The redundancy cost reduces but does not eliminate the savings.
• Cost of cross-VPC traffic via TGW.: Transit Gateway processes traffic at a per-GB rate. Traffic that would have stayed in a single VPC under the per-VPC pattern now crosses the TGW. The TGW cost partially offsets the NAT savings.
• Calculate the crossover.: The economics depend on traffic patterns. Heavy egress (much more egress than inter-VPC traffic) favors the central egress pattern. Heavy inter-VPC traffic with light egress can make the per-VPC pattern cheaper. The team calculates the crossover for their workload.
• Operational complexity.: The pattern requires Transit Gateway configuration, route table discipline, careful management of the egress VPC. The complexity is higher than per-VPC; the operational benefit comes from doing the complex work once instead of per-VPC.

The egress VPC pattern is a significant architectural decision with real trade-offs. Nova AI Ops integrates with cloud network telemetry, surfaces egress traffic patterns and NAT costs, and helps teams understand whether the pattern fits their workload's actual behavior.