Cloud Internet Egress Paths

The six egress paths

Direct via internet gateway

For instances with public IPs in public subnets, outbound traffic goes through the VPC's internet gateway directly. The IGW does nothing on the data plane beyond mapping the instance's private IP to its public IP (1:1 NAT, not many-to-one). There is no per-GB processing charge — only the standard data transfer rates.

Use cases: public-facing services that need both inbound and outbound internet, load balancers, NAT gateways themselves (they sit in public subnets), bastion hosts.

NAT gateway

The default for private subnets. A managed NAT service handles many-to-one translation: every private instance's outbound traffic shares the NAT gateway's public IP. Inbound from the internet is blocked entirely.

The economics: NAT gateway charges per hour (small) plus per GB processed (substantial at volume). For high-volume egress, the per-GB charge often dominates the bill. A workload pushing 10 TB/month through a NAT pays a meaningful amount in processing alone, before data transfer.

NAT instance

The self-managed alternative. You run an EC2 instance configured to do NAT for the subnet. Lower per-byte cost than the managed NAT gateway, but you handle availability, scaling, and patching yourself. Rarely worth the operational overhead today; the managed service has improved enough to be the default choice.

Centralized egress via transit gateway

For organizations with many VPCs, a hub-and-spoke pattern centralizes egress:

1. Each spoke VPC has no internet gateway and no NAT. Default route in private subnets points at the transit gateway.
2. The TGW routes the traffic to a central egress VPC.
3. The egress VPC has a NAT gateway and IGW. Traffic exits there.
4. Return traffic follows the reverse path.

Benefits: one NAT gateway pool serves many VPCs (cost amortization), one set of public IPs to give to partners for allowlisting, a single chokepoint where firewall inspection can run.

Drawbacks: traffic takes one extra hop, the egress VPC becomes a critical dependency, costs concentrate but don't always reduce.

Egress via VPN / Direct Connect to on-prem

Some organizations require all internet traffic to traverse the on-prem perimeter for inspection. The pattern:

1. VPC default routes point at the VPN tunnel or Direct Connect to on-prem.
2. On-prem firewall inspects and forwards to the internet.
3. Return traffic follows the reverse path.

Heavy operational and cost overhead — every byte of cloud-originated internet traffic is paying for both cloud egress and on-prem internet capacity. Used in regulated industries where it's mandated; otherwise expensive.

Private endpoints bypass the egress path

For traffic destined to cloud services (S3, DynamoDB, etc.) or PrivateLink-enabled SaaS, the traffic never touches the internet egress path at all. The endpoint routes the traffic privately within the cloud provider's network. The NAT gateway's data-processing charge does not apply.

For high-volume cloud-to-cloud-service traffic, moving to private endpoints can substantially reduce the NAT bill. See private endpoints explained.

Choosing the right egress for each workload

Egress IP allowlists

Partners often allowlist specific source IPs for incoming traffic. The egress path determines which IP your traffic appears to come from:

• Direct IGW: the instance's public IP.
• NAT gateway: the NAT gateway's IP.
• Central egress: the central egress NAT gateway's IP.

For partners requiring stable IPs, allocate Elastic IPs (or equivalent) to your NAT gateways and never reassign them.

Inspecting egress traffic

For compliance or security, you may want to inspect outbound traffic. Options:

• Network Firewall service in the cloud provider's stack.
• Third-party security appliance VPC.
• SASE / cloud-delivered security gateway.
• On-prem inspection via VPN backhaul.

Centralized egress through a hub VPC is the natural place to insert inspection — every spoke's traffic passes through the hub, making one inspection point cover everything.

Frequently Asked Questions

What is the default egress path from a VPC?

It depends on the subnet's route table. A public subnet has a default route (0.0.0.0/0) pointing at the internet gateway — traffic from instances with public IPs goes out directly. A private subnet's default route typically points at a NAT gateway, which lets the private instances reach the internet outbound but blocks any incoming traffic to them.

What are the egress path options?

Six common paths: direct via internet gateway (public IP required), NAT gateway (managed), NAT instance (self-managed), transit gateway to a central egress VPC, VPN tunnel to on-prem or another network, and private endpoints to specific cloud services. Each has different cost, performance, and security characteristics.

Why centralize egress through a transit gateway?

With many VPCs each needing internet egress, running a NAT gateway in every VPC is expensive and fragmented. Centralizing egress through a hub VPC with one set of NAT gateways consolidates cost, makes outbound IP allowlisting simpler (one set of IPs to give to partners), and enables centralized inspection of all egress traffic by a firewall in the hub.

What is the cost difference between NAT gateway and direct egress?

Direct egress through an internet gateway has no per-instance gateway cost — you pay only the standard data transfer charges. NAT gateway has an hourly charge plus a per-GB data processing charge on top of data transfer. For high-volume workloads, the NAT processing charge can be substantial — often exceeding the data transfer charge itself.

When does egress traffic skip the NAT?

When the destination is a private endpoint (PrivateLink) for that service, when the route is a peering or transit gateway path to another VPC, when the traffic stays in the same VPC, or when the instance has a public IP and lives in a public subnet. In each case, the NAT gateway is bypassed and its data-processing charge doesn't apply.