The $1,000 Route Table

The most dangerous phrase in cloud engineering is "It works."

The fastest way to wire a private subnet to S3 is a NAT Gateway. The connectivity is instant. The code runs. The Airflow DAGs turn green.

It is also the fastest way to chew right through your budget.

"Working" and "architected" are two very different things. While the NAT Gateway is the path of least resistance, it imposes a heavy tax on high-volume data.

A single route table change saved CatInCloud Labs over $1,000 this year. Here is why boring networking decisions are the key to calm operations.

The Context: 4TB of "Chaos" Data

I recently expanded the CatInCloud platform to backfill the full history of the 2025 stock market. I wasn't just grabbing daily closes; I was ingesting the entire options chain for the most volatile tickers in the market.

• Volume: 1.99 Billion options contracts.
• Format: Raw, uncompressed JSON.
• Total Size: ~4 Terabytes.

When you are moving data at this scale, the plumbing of your network stops being a minor detail and becomes a major line item on your P&L.

The Trap: The NAT Gateway Tax

S3 lives on the public internet. Even though it is an AWS service, it exists outside your Virtual Private Cloud (VPC). To get data from a private subnet to S3, traffic has to leave your network.

The Default Path (NAT Gateway):

If I had routed this backfill through a standard NAT Gateway, AWS would charge a Data Processing Fee of roughly $0.045 per GB.

That is $180 just to move the data once. If I re-process that data, move it to a marts bucket, or run heavy queries that pull it back through the NAT, the cost doubles or triples. Combined with the hourly run rate of the gateway itself, this configuration would cost the lab over $1,000/year for a service that provides zero additional value.

The Solution: The S3 Gateway Endpoint

AWS offers a specialized resource for this exact problem: the VPC Gateway Endpoint.

Think of a Gateway Endpoint as a wormhole. Instead of routing traffic out to the public internet and back, it punches a hole directly from your VPC into S3, using the internal AWS backbone.

• Endpoint Type: Gateway (specifically com.amazonaws.us-east-2.s3)
• Cost: $0.00
• Security: Traffic never leaves the private network.

The screenshot below is the actual production configuration for the CatInCloud VPC.

The Configuration:

1. The Checkmark: Notice vpce-00dab... is selected. The type is Gateway.
2. The Route Table: Unlike Interface Endpoints (which use ENIs and DNS), Gateway Endpoints operate at the route table level.
3. The Result: Any traffic destined for S3 (pl-63a54009) is immediately routed to the Gateway Endpoint, bypassing the expensive NAT Gateway entirely.

The Nuance: When to Pay (Interface vs. Gateway)

If you look closely at the screenshot above, you will see I am not a free tier absolutist. Below the S3 Gateway, there are several Interface Endpoints that I do pay for.

• vpce-...secretsmanager
• vpce-...ecr.api

Why pay for these?
AWS does not offer free Gateway Endpoints for services like Secrets Manager or ECR. For these, I use Interface Endpoints.

• Cost: ~$7/month per endpoint.
• Value: It ensures my database credentials (Secrets Manager) and Docker images (ECR) never traverse the public internet.

The Strategy: I pay for security on low-volume control plane traffic. I refuse to pay for transit on high-volume data plane traffic.

Conclusion: Calm Architecture Doesn't Show Up on the Bill

Reliability isn't just about uptime. A system that scales technically but breaks financially is not a reliable system.

By adding a single S3 Gateway Endpoint and updating the route tables, the CatInCloud platform ingests massive market volatility without incurring volatility in the AWS bill.