Cross-Region Egress Patterns: S3→Internet vs VPC→VPC Traps

Sudden increases in cloud spend are most commonly caused by unintended data transfer paths.

In AWS architectures, two routing patterns account for a disproportionate percentage of cost overruns:

1. Object storage accessed through a NAT Gateway.
2. Cross-boundary VPC communication.

First off, cloud providers don’t charge you to bring data into their network. The financial penalty occurs because moving data around or out of the environment results in metered egress charges. A lot of folks treat cloud networks like old-school flat networks, and that’s where projects quietly start bleeding money. Data egress charges add up fast if you don’t pay attention.

I dove deep into this in the Physics of Data Egress, focusing on why AWS bandwidth costs so much and the exact mechanics behind these two major traps.

The Object Storage Trap: S3 → Internet via NAT Gateway

Let’s start with why this is such a common pitfall. Engineers love “secure by default.” The standard move is to put EC2 instances in private subnets—no public IPs. Need those instances to reach the outside world for patches or APIs? Route their outbound traffic through a Managed NAT Gateway.

But here’s the kicker: when your instance has to pull data from S3 to serve to the internet, this setup totally backfires.

The Routing Reality Check

• What engineers think is happening: The instance grabs data from S3 internally, then serves it out to users.
• What’s really happening: S3 → NAT Gateway → Instance → Internet.

Amazon S3 is a public service endpoint. Without a VPC Gateway Endpoint, traffic from a private subnet is routed to the Internet Gateway through the NAT Gateway. The transfer is billed as internet-bound traffic even though the destination remains inside AWS.

Let’s talk numbers. Downloading 10 TB a day through this route results in a 20 TB billed processing path. You pay for the NAT Gateway’s hourly uptime, every GB processed, and the usual internet egress fee.

For the nitty-gritty on spotting these billing surprises, check out our Cloud Cost Increases 2026 Analysis.

Billing Path Comparison

The Fix: VPC Endpoints

To dodge this trap, you have to shorten the path. When you compare a VPC endpoint to a NAT Gateway, it’s all about the math. If you set up a VPC Gateway Endpoint for S3, your traffic stays inside AWS’s internal backbone. The NAT Gateway gets skipped, and your internal transfer cost for that data drops to zero.

The VPC Peering Trap: Routing Physics

Here’s the big takeaway for anyone designing multi-account setups: a peered VPC isn’t a shared network. It’s a routed boundary.

Cross-AZ Billing

Even if everything sits in the same geographic region, you still get hit with egress charges when data moves between Availability Zones over a VPC peering link. The network might look flat, but the fiber between data centers isn’t free—and AWS charges for it.

Cross-Region Billing

The architectural consequence of moving data across regions is that costs skyrocket. Replicating a database from US-East to EU-West? Those inter-region transfer fees can quickly outpace what you’re paying for compute.

Cross-Boundary Billing Rules

The Transit Gateway Escalation

As things get more complex, teams start using Transit Gateways (TGW). Let’s be clear: Transit Gateway doesn’t save you money on routing; it helps you scale. It’s a central hub, and AWS charges you for every VPC attached and every GB that goes through it. It keeps your architecture clean, but you have to budget for it—hard.

Verifying the Physics (Global Modeling)

You can (and really should) model all this before you deploy anything.

Plug your expected monthly traffic into the upcoming Rack2Cloud Cloud ROI Estimator (Coming Soon). Run the numbers: what does routing 50TB through a NAT Gateway cost versus a free VPC Gateway Endpoint? What do cross-region charges look like? You’ll know right away if your design is financially sound—before you even touch Terraform.

The Architect’s Verdict: A Routing Decision Framework

If you want real infrastructure maturity, you need to predict your bill straight from your architecture diagrams. Use this three-step approach to stay in control:

• Step 1: Map out every boundary your data crosses. Are you going across a subnet, an AZ, a region, or the public internet?
• Step 2: Ask if you can keep the workload closer to where the data lives. Can you avoid the transfer altogether?
• Step 3: If the data has to move, use backbone shortcuts like VPC Endpoints to skip metered paths whenever possible.

That’s how you keep your cloud bill from spiraling out of control.

About The Architect

R.M.

Senior Solutions Architect with 25+ years of experience in HCI, cloud strategy, and data resilience. As the lead behind Rack2Cloud, I focus on lab-verified guidance for complex enterprise transitions. View Credentials →