Cutting AWS Egress Costs with a Centralized VPC and Transit Gateway

About the author: I'm Charles Sieg, a cloud architect and platform engineer who builds apps, services, and infrastructure for Fortune 1000 clients through Vantalect. If your organization is rethinking its software strategy in the age of AI-assisted engineering, let's talk.

NAT Gateway costs are the silent budget killer in multi-account AWS environments. I've audited organizations spending $15,000/month on NAT Gateway data processing alone, spread across dozens of VPCs, each with its own pair of NAT Gateways. When I showed them they could cut that by 40-70% with a centralized egress VPC and Transit Gateway, the conversation shifted fast. The architecture is straightforward. The cost math requires attention. The routing setup has genuine gotchas that will break production if you get them wrong.

This article covers the centralized egress pattern: why NAT Gateway costs spiral, how to consolidate egress through a shared VPC using Transit Gateway, when this pattern saves money (and when it costs more), and the operational lessons from running this architecture across production multi-account environments. If you already understand VPC networking basics and want to reduce your AWS networking bill, this is for you.

The NAT Gateway Cost Problem

NAT Gateway pricing is deceptively simple on the surface. Underneath, three separate charges compound into bills that surprise every team I've worked with.

How NAT Gateway Pricing Works

Every NAT Gateway incurs two fixed charges plus a variable charge:

The data processing charge applies to all traffic, including traffic destined for other AWS services. If your Lambda functions pull container images from ECR through a NAT Gateway, you pay $0.045/GB for that internal AWS traffic. If your application writes to S3 through a NAT Gateway, same charge. This is the billing trap that catches most teams.

The Three-Layer Bill

Internet-bound traffic gets charged three times:

A single TB of internet-bound egress costs $138 at minimum. For AWS-service-bound traffic that does not need internet egress, you still pay $46/TB in NAT Gateway data processing. That $46/TB is pure waste for traffic that could route directly to AWS services through VPC endpoints.

Real Cost at Scale

Consider a typical multi-account environment with 10 VPCs, each running NAT Gateways in 2 AZs:

Now scale that to 50 VPCs, or increase per-VPC traffic to 5 TB, and monthly NAT costs easily exceed $10,000. The hourly charges alone for 50 VPCs across 2 AZs: $3,240/month before a single byte transfers.

Centralized Egress Architecture

The centralized egress pattern consolidates all internet-bound traffic through a single "egress VPC" connected to spoke VPCs via Transit Gateway. Instead of running NAT Gateways in every VPC, you run them in one VPC and route traffic through Transit Gateway.

The Core Pattern

flowchart TD
    subgraph SPOKE1["Spoke VPC A"]
        EC2A[Private Subnet
Workloads]
    end
    subgraph SPOKE2["Spoke VPC B"]
        EC2B[Private Subnet
Workloads]
    end
    subgraph SPOKE3["Spoke VPC C"]
        EC2C[Private Subnet
Workloads]
    end
    subgraph TGW["Transit Gateway"]
        RT1[Route Table:
Spoke Associations]
        RT2[Route Table:
Egress Association]
    end
    subgraph EGRESS["Egress VPC"]
        NAT[NAT Gateway
per AZ]
        IGW[Internet Gateway]
    end
    EC2A --> RT1
    EC2B --> RT1
    EC2C --> RT1
    RT1 -->|0.0.0.0/0| NAT
    NAT --> IGW
    IGW -->|return traffic| NAT
    NAT -->|spoke CIDRs| RT2
    RT2 --> EC2A
    RT2 --> EC2B
    RT2 --> EC2C

The architecture uses two Transit Gateway route tables:

Route Table 1 (Spoke Associations): All spoke VPC attachments associate with this table. A single static default route (0.0.0.0/0) points to the egress VPC attachment. A blackhole route for the RFC 1918 range (10.0.0.0/8) prevents spoke-to-spoke communication (unless you intentionally remove it).

Route Table 2 (Egress Association): The egress VPC attachment associates with this table. Spoke VPC attachments propagate their routes here, so return traffic from the internet finds its way back to the correct spoke VPC.

Transit Gateway Route Table Design

AZ-Aligned Traffic Flow

Transit Gateway preserves AZ affinity. When an EC2 instance in AZ-1 of Spoke VPC A sends traffic to the internet, Transit Gateway routes it through its ENI in AZ-1 of the egress VPC. The egress VPC must have a NAT Gateway in every AZ that Transit Gateway has an ENI.

This AZ alignment matters for two reasons: cross-AZ data transfer costs ($0.01/GB), and fault isolation. If AZ-1 fails, only traffic from AZ-1 sources fails over. The remaining AZs continue routing through their local NAT Gateways.

Egress VPC Subnet Routing

The egress VPC needs precise route table configuration:

The Transit Gateway attachment subnets in the egress VPC should be dedicated, small subnets (a /28 is sufficient). Do not place other resources in these subnets.

When Centralized Egress Saves Money

Centralization reduces NAT Gateway hourly charges but adds Transit Gateway costs. The math is not always favorable.

The Break-Even Calculation

Centralized egress trades NAT Gateway hourly costs for Transit Gateway per-attachment and data-processing costs:

For N VPCs with T total GB of monthly egress:

• Decentralized cost: N x $64.80 + T x $0.045
• Centralized cost: $64.80 + N x $73 + T x $0.067 ($0.045 NAT + $0.02 TGW)

The break-even point depends on your ratio of VPC count to total traffic. With low traffic and many VPCs, centralization wins because you eliminate N-1 sets of NAT Gateways. With high traffic and few VPCs, the extra $0.02/GB TGW charge can exceed the savings from eliminated NAT Gateways.

Scenarios Where Centralization Wins

Scenarios Where Decentralized Wins

Worked Example: 20 VPCs

At 100 GB per VPC, centralization actually costs $342 more. The TGW attachment fees ($1,533) consume the NAT Gateway hourly savings ($1,231). To break even with 20 VPCs, you need fewer than ~15 GB of egress per VPC per month, making the NAT hourly cost dominant.

The economics flip when you factor in VPC endpoints eliminating the bulk of AWS-service traffic from NAT entirely, and when the organization values centralized security posture over raw cost.

VPC Endpoints: The First Line of Defense

Before optimizing NAT Gateway architecture, eliminate traffic that should never touch a NAT Gateway in the first place.

Gateway Endpoints: S3 and DynamoDB

Gateway VPC Endpoints for S3 and DynamoDB are free. No hourly charge. No data processing charge. They route traffic directly from your VPC to the service over AWS's internal network.

Deploy Gateway Endpoints in every VPC that accesses S3 or DynamoDB. There is no reason to route this traffic through NAT. I have seen organizations move 10 TB/month of S3 traffic off NAT Gateways, saving $450/month in data processing alone. In a centralized egress architecture, Gateway Endpoints belong in every spoke VPC, not just the egress VPC. Traffic should never reach Transit Gateway if it is destined for S3 or DynamoDB (AWS DynamoDB: An Architecture Deep-Dive).

Interface Endpoints

Interface Endpoints use PrivateLink to route traffic to AWS services through ENIs in your VPC. They carry an hourly charge (~$0.01/hr per AZ, ~$7.30/month) plus $0.01/GB data processing. Still cheaper than NAT Gateway's $0.045/GB.

Interface Endpoints save money only when per-service traffic volume exceeds the fixed hourly cost. For low-volume services (Secrets Manager, SSM Parameter Store), the endpoint's hourly charge exceeds the NAT Gateway data processing savings. For high-volume services (ECR, CloudWatch Logs, Kinesis), Interface Endpoints pay for themselves quickly.

Endpoint Priority Order

Deploy VPC endpoints in this order based on typical traffic volume and cost impact:

1. S3 Gateway Endpoint (free, usually highest traffic volume)
2. DynamoDB Gateway Endpoint (free)
3. ECR Interface Endpoints (dkr and api) (high container image pull volume)
4. CloudWatch Logs Interface Endpoint (high log volume in observability-heavy architectures)
5. STS Interface Endpoint (frequent in IAM-heavy, cross-account workloads)
6. Other AWS service endpoints (evaluate per-service traffic volume)

Transit Gateway Architecture Details

Bandwidth and Throughput

Transit Gateway supports substantial throughput, but the limits matter for egress-heavy architectures:

NAT Gateway bandwidth scales from 5 Gbps to 100 Gbps automatically. If your centralized egress VPC serves 50 spoke VPCs, aggregate egress through the NAT Gateways can exceed single-gateway throughput. Deploy multiple NAT Gateways per AZ and use separate route tables per subnet to distribute traffic across them, or accept that NAT Gateway auto-scaling handles the burst.

Connection Limits and Port Exhaustion

Each NAT Gateway supports 55,000 simultaneous connections to a single destination IP and port combination. In a centralized model, all spoke VPCs share these 55,000 connections per destination. If 20 VPCs all call the same external API, you will exhaust connections faster than in a decentralized model.

Mitigation: assign up to 8 Elastic IP addresses per NAT Gateway, multiplying the connection pool to 440,000 per destination. If a single destination endpoint requires more, you need multiple NAT Gateways with application-level distribution.

Adding Network Firewall

AWS Network Firewall integrates with centralized egress to inspect outbound traffic before it reaches the NAT Gateway:

flowchart LR
    subgraph SPOKE["Spoke VPCs"]
        S1[VPC A]
        S2[VPC B]
        S3[VPC C]
    end
    subgraph TGW["Transit Gateway"]
        T[Route Tables]
    end
    subgraph EGRESS["Egress VPC"]
        FW[Network Firewall
Endpoints per AZ]
        NAT[NAT Gateways
per AZ]
        IGW[Internet
Gateway]
    end
    S1 --> T
    S2 --> T
    S3 --> T
    T --> FW
    FW -->|allowed traffic| NAT
    NAT --> IGW

Network Firewall adds its own costs: $0.395/hour per endpoint (~$288/month per AZ) plus $0.065/GB data processing. For security-conscious organizations, the combined Transit Gateway + Network Firewall + NAT Gateway architecture provides centralized inspection, logging, and egress control across all spoke VPCs. The cost premium is justified by the security posture, particularly for regulated industries.

Alternative Approaches

NAT Instances

A NAT instance is an EC2 instance configured to perform NAT. You manage the instance, patching, monitoring, and failover. In exchange, you pay EC2 pricing instead of NAT Gateway pricing.

NAT instances eliminate the $0.045/GB data processing charge entirely. For high-traffic workloads, this produces dramatic savings. The open-source project fck-nat runs on t4g.nano instances at ~$3/month with automatic failover, offering 90%+ cost savings over NAT Gateway for workloads within its bandwidth limits.

The trade-off is operational responsibility. NAT Gateway is a managed service with built-in HA and automatic scaling. NAT instances require health checks, auto-recovery configuration, and manual or scripted failover. For organizations with strong platform engineering teams, NAT instances are a legitimate cost optimization. For teams that value operational simplicity, the NAT Gateway premium is worth it.

IPv6 Egress-Only Internet Gateway

If your workloads can operate on IPv6, the Egress-Only Internet Gateway provides outbound internet access with no hourly charge and no data processing charge. You pay only standard data transfer rates.

IPv6 eliminates two of the three NAT cost layers. The challenge: many third-party APIs, SaaS endpoints, and on-premises systems still require IPv4. Dual-stack deployments can route IPv6-capable traffic through the Egress-Only IGW and fall back to NAT Gateway for IPv4-only destinations. This is the direction AWS is pushing, and every new architecture should plan for IPv6 even if it deploys IPv4 today.

Failure Modes and Operational Lessons

Connection Exhaustion

In a centralized model, all spoke VPCs share NAT Gateway connection pools. A single spoke VPC running a web scraper or making thousands of connections to one destination can exhaust the 55,000 connection limit, causing connection drops for every other spoke VPC. Monitor ErrorPortAllocation in CloudWatch. If it fires, add Elastic IPs to the NAT Gateway or isolate the high-connection workload into its own NAT Gateway.

AZ Failure and Asymmetric Routing

If an AZ fails, Transit Gateway stops routing through its ENI in that AZ. Traffic from instances that fail over to another AZ will route through the new AZ's Transit Gateway ENI and NAT Gateway. The failure mode is clean if you have NAT Gateways in every AZ. If you skipped an AZ to save $32/month, failover traffic crosses AZ boundaries or, worse, has no NAT Gateway to reach.

Transit Gateway Route Table Propagation Delays

Route propagation from spoke VPC attachments to the egress route table is not instant. When you attach a new spoke VPC, allow 1-2 minutes for routes to propagate. During this window, return traffic for the new spoke VPC may be dropped because the egress route table does not yet contain the return route.

Spoke VPC Routing Mistakes

The most common operational failure I see: someone adds a route table entry in a spoke VPC pointing 0.0.0.0/0 at a local IGW or NAT Gateway instead of the Transit Gateway. Traffic bypasses the centralized egress path, skipping firewall inspection and breaking the security model. Use AWS Config rules or Service Control Policies to prevent spoke VPC accounts from creating Internet Gateways or NAT Gateways.

DNS Resolution and Split-Horizon

If your egress VPC runs DNS resolvers or if spoke VPCs use Route 53 Resolver endpoints, ensure DNS resolution for external domains returns public IPs that route correctly through the NAT Gateway. Misconfigured DNS can cause traffic to attempt direct internet access from spoke VPCs that have no IGW, resulting in silent packet drops.

Pricing Quick Reference

Key Patterns

Deploy Gateway VPC Endpoints everywhere, first. Before redesigning your egress architecture, deploy free S3 and DynamoDB Gateway Endpoints in every VPC. This is the highest-ROI networking optimization on AWS. Zero cost, zero risk, immediate savings.

Centralize egress when you have 10+ VPCs with low-to-moderate traffic. The break-even math favors centralization when NAT Gateway hourly charges across many VPCs exceed Transit Gateway attachment fees plus data processing surcharges. Run the numbers for your specific environment before committing.

Keep NAT Gateways decentralized for high-traffic VPCs. If a single VPC pushes 5+ TB/month through NAT, the Transit Gateway $0.02/GB surcharge on that volume will exceed the savings from eliminating one NAT Gateway. Hybrid architectures (centralized for most VPCs, decentralized for heavy hitters) are common and practical.

Deploy NAT Gateways in every AZ of the egress VPC. Saving $32/month by skipping an AZ creates a single point of failure that will cost far more during an incident. Match AZ deployment to wherever Transit Gateway has ENIs.

Plan for IPv6. Every new VPC should be dual-stack. IPv6 with Egress-Only Internet Gateway eliminates NAT costs entirely for IPv6-capable destinations. The migration is incremental: start routing IPv6-ready traffic through the Egress-Only IGW while keeping IPv4 traffic on NAT.

Monitor ErrorPortAllocation and ConnectionEstablishedCount on centralized NAT Gateways. Connection pool exhaustion in a centralized model affects every spoke VPC. Set CloudWatch Alarms on these metrics with aggressive thresholds.

Use SCPs to prevent shadow egress paths. Spoke VPC accounts should not be able to create Internet Gateways or NAT Gateways. Service Control Policies (or AWS Config rules with auto-remediation) enforce the centralized egress model at the organizational level.

Additional Resources

• Building a Scalable and Secure Multi-VPC AWS Network Infrastructure
• Using NAT Gateway for Centralized IPv4 Egress
• Creating a Single Internet Exit Point from Multiple VPCs Using AWS Transit Gateway
• AWS Transit Gateway Pricing
• Reduce Cost and Increase Security with Amazon VPC Endpoints
• Transit Gateway Quotas
• Overview of Data Transfer Costs for Common Architectures
• Centralized Egress: AWS Prescriptive Guidance
• Flexible Cost Allocation for AWS Transit Gateway