Designing Egress in AWS: NAT Gateways, Transit Gateways, and Cost Analysis

Introduction

AWS networking is fairly straightforward in a small setup. As a singular environment, you will generally have a single VPC that consists of:

• Subnets

• Route tables

• Network ACLs (NACLs)

• Security groups

• An Internet Gateway (IGW)

• NAT Gateway(s)

There are other components, and even some of the ones mentioned here may not be required. You might have a single subnet for all of your resources. Likewise, a NAT Gateway may not even be necessary (this is rare — and anyone exposing private workloads to the internet unnecessarily is not following best practice).

But what about in more sophisticated setups, where you have multiple isolated networks in the form of several VPCs across different AWS accounts? You may need to introduce a shared services layer — an isolated VPC (or multiple, depending on your use case) that houses applications used to support your environment. Rather than duplicating these components inside each VPC, we share them (hence the name). To share these components, the VPCs need to be interconnected. AWS provides a service called Transit Gateway (TGW) to achieve exactly that, at scale.

Building on the shared services concept, NAT Gateways provide a solution that allows private subnets to connect to the internet for outbound (egress) traffic. They are deployed into public subnets (with a default route to an IGW) so that resources can route through the NAT Gateway to access the internet. NAT Gateways aren’t strictly bound to the VPC they are deployed in — you can use them across different VPCs if you choose, by leveraging a TGW.

With all of this context in mind, at what point does it make sense to use a NAT Gateway in each VPC (decentralised egress) versus using a TGW to route all internet traffic through a single VPC and set of NAT Gateways (centralised egress)? Which option is more cost-effective? Let’s find out.

Architecture: Centralised vs decentralised

Let’s begin by outlining each of the solutions and what they look like architecturally.

Centralised

• VPC count: 4

  • Workload VPCs: 3

  • Egress VPC: 1

• Transit Gateway count: 1

  • Transit Gateway attachments: 4

  • Transit Gateway route tables: 1

• NAT Gateway count: 2 (both deployed into the Egress VPC)

Each VPC will be associated with a single Transit Gateway (TGW) route table and propagate its routes accordingly. A default route will be configured to point to the egress VPC, enabling a centralised egress pattern.

Each VPC will be created in a separate AWS account, except for the egress VPC, which (along with the TGW) will reside in a dedicated networking account. The TGW will be shared via AWS Resource Access Manager (RAM) to each respective AWS account, allowing TGW attachments to be created for each VPC.

This is what the architecture looks like:

Decentralised

• VPC count: 3 (Workload VPCs only)

• Transit Gateway count: 1

  • Transit Gateway attachments: 3

  • Transit Gateway route tables: 1

• NAT Gateway count: 6 (2 in each workload VPC)

Each VPC will be associated with a single TGW route table and will propagate its routes accordingly. This route table will not contain a default route, as traffic will exit locally via each VPCs NAT Gateways before reaching the TGW.

Each VPC will be created in separate AWS accounts. The TGW will again be created in the networking account and RAM shared to each AWS account to allow for TGW attachments per VPC.

This is what the architecture looks like:

Now that the architectures are defined, let’s dig deeper into the pricing of each component.

Pricing models

NAT Gateways

NAT Gateways have a simple pricing model. You pay for two main things:

• Hourly cost per NAT Gateway

• Data processed (in GB) by the NAT Gateway

The source or destination of the traffic is irrelevant — if the data passes through the NAT Gateway, you’re paying for it.

In addition to NAT Gateway costs, there are data transfer fees for services like EC2. This includes:

• Traffic going out to the internet

• Traffic sent to other AWS regions

• Traffic sent between Availability Zones (AZs) within the same region

It’s also worth mentioning that VPCs themselves are free. While components inside a VPC (like NAT Gateways) may incur costs, the VPC construct has no cost on its own. So for this comparison, we’ll only factor in the pricing for NAT Gateways.

Transit Gateways

Transit Gateways follow a similar pricing model to NAT Gateways. You pay for:

• Hourly cost per Transit Gateway attachment

• Data processed (in GB) by the Transit Gateway

As with NAT Gateways, data transfer fees for services like EC2 still apply and should be considered — especially for inter-AZ or inter-region traffic.

Cost breakdown

To calculate actual costs, we need to use the pricing from an AWS region. For this exercise, we’ll use the AWS Sydney region (ap-southeast-2). Based on this region, the pricing is as follows:

• NAT Gateway

  • Hourly fee: $0.059

  • Per GB of data processed: $0.059

• Transit Gateway:

  • Hourly fee (per attachment): $0.07

  • Per GB of data processed: $0.02

For both the centralised and decentralised solutions already outlined, we’ll assume 100 GB of data processed in total. We’ll also assume a billing duration of 30 days (720 hours) for the hourly costs.

Although both solutions will incur data transfer fees (e.g. to the internet, to other AWS regions, or between AZs within a region), these are identical in both cases. As such, we’ve excluded them from this comparison to focus only on the NAT and Transit Gateway pricing.

Centralised cost breakdown

Decentralised cost breakdown

Findings

With the findings in tow, it’s clear which solution is more cost-effective based on the defined setup. The centralised egress solution comes out ahead in terms of cost when compared to the decentralised one — as long as the assumptions hold.

However, there are edge cases worth exploring. Also, note that we used a “magic number” of 6 NAT Gateways in the decentralised setup — something we’ll expand on shortly.

What if fewer VPCs needed egress?

Suppose only one of the three workload VPCs in the decentralised solution actually required egress access (and therefore NAT Gateways). If you removed 4 of the 6 NAT Gateways, your total would drop to $244.06 — cheaper than the centralised solution.

What If You Removed the Transit Gateway?

Now imagine removing the Transit Gateway from the decentralised solution entirely, and each of the three VPCs had their own local NAT Gateways, but no interconnection. In that case, the total cost would come to $260.78 — not as low as the previous example, but still cheaper than the centralised solution (at $294.46).

Why We Used 3 VPCs as a Baseline

The reason we compared three workload VPCs and 6 NAT Gateways is that this configuration represents a cost-efficiency threshold. Beyond this point, the decentralised approach starts to suffer from diminishing returns.

While it may seem obvious to adopt a centralised solution, there’s a case to be made for starting with decentralised egress — especially in early-stage AWS environments that aren’t yet interconnected. If the VPCs remain isolated, decentralised egress might be more cost-effective. But as soon as inter-VPC connectivity is required, the decentralised model becomes significantly less economical.

Additional cost scenarios

Here are some expanded scenarios to help illustrate the cost impact at scale:

As shown above, once you pass three VPCs, the centralised model quickly becomes more attractive from a cost perspective.

Centralised solution benefits

While the primary focus of this blog is cost, not everything comes down to price. Ultimately, the real question is: what are you willing to pay for best practice and a secure, scalable setup?

AWS provides several services that enhance security at the networking layer. Two key examples include:

• AWS Network Firewall – a fully managed stateful firewall service

• Gateway Load Balancer (GWLB) – supports third-party firewalls in a “bump-in-the-wire” architecture

Both of these services are designed to operate in a centralised model, enabling consistent inspection of traffic — whether it’s north/south (in and out of the AWS network) or east/west (between VPCs/subnets). Any traffic that bypasses these centralised inspection points risks being unauthorised or even malicious. Without a centralised architecture, enforcing an inspection solution across multiple VPCs becomes near impossible.

If you needed any more reasons to lean toward a centralised model — regardless of cost — the ability to integrate services like AWS Network Firewall and Gateway Load Balancer should be near the top of the list.

Conclusion

Egress traffic in AWS must traverse some kind of gateway to reach the internet. For private subnets, this means using a NAT Gateway. As we’ve explored, NAT Gateways can either be local to each VPC or located in a centralised egress VPC, connected via a Transit Gateway.

Centralised solutions work best at scale and offer stronger alignment with AWS’s security services. Decentralised solutions, on the other hand, are often more suitable for smaller environments — either early in their cloud journey or intentionally minimal in scope.

The next time you’re designing how traffic should leave your AWS environment, consider the long-term direction, cost implications, security posture, and — most importantly — what the environment needs to function effectively.

Cover image generated by DeepAI