My 2026 Egress Costs: What Im Doing to Cut Cloud Spend

Hey everyone, Jules Martin here, back on agntmax.com. It’s April 12, 2026, and I’ve been spending way too much time staring at my billing reports again. Not because they’re bad, but because I’m always looking for ways to make them better. Specifically, I’m talking about cloud spend, and lately, the silent killer: egress costs.

We all talk about compute, storage, databases – the big-ticket items. We spin up instances, provision disks, set up managed services. We even get pretty good at rightsizing those. But then, quietly, in the background, data starts moving. Out of our primary region, between availability zones, to a CDN, to a user’s browser. And each byte often comes with a tiny, almost imperceptible price tag. Until you get the bill, and suddenly those tiny tags add up to a significant chunk of your operating budget.

Today, I want to dive deep into something I’ve been wrestling with for the past few months across a few projects: optimizing egress costs in a multi-cloud, multi-region setup. It’s not just about saving money; it’s about building smarter, more efficient architectures from the ground up. And trust me, the difference can be startling.

The Egress Enigma: Why We Overlook It (and Why We Shouldn’t)

I remember one project last year where we were migrating a sizable analytics platform from an on-premise data center to AWS. We did all the usual calculations: instance types, storage tiers, database engine costs. We had a pretty solid estimate. Then, three months in, the bill arrived, and it was about 15% higher than our worst-case scenario.

My first thought was, “Did we forget something big?” We hadn’t. After a deep dive with the team, it turned out nearly half of that 15% overrun was pure egress. Data moving from S3 buckets to EC2 instances in different AZs for processing, results moving from EC2 back to S3, and then aggregated reports moving out to an external BI tool. Each hop, each byte, adding up.

The problem is that egress is often a percentage play. It’s not a fixed cost like an instance. It scales with your usage, often in ways that are hard to predict if you’re not explicitly tracking data transfer patterns. Cloud providers make it cheap to put data in, but they charge you to take it out. It’s a fundamental part of their business model, and frankly, it makes sense. Their infrastructure has a cost, and moving data across the internet isn’t free.

But that doesn’t mean we have to just accept it.

My Recent Egress Nightmare (and How We Woke Up)

Just a few months ago, I was working with a client building a global SaaS product. They had users worldwide, and their initial architecture was pretty straightforward: a central backend in us-east-1 (AWS), with edge locations for content delivery (CloudFront). Data was stored primarily in S3 in us-east-1, and their main application servers were there too.

The issue? Their users in Europe and Asia were experiencing noticeable latency. And when we looked at the CloudFront bill, the egress from CloudFront back to us-east-1 for origin fetches was substantial. Even worse, database queries from regional read replicas were still often hitting the primary in us-east-1 if the replica didn’t have the data, or if writes were involved. This was a classic “centralized brain, distributed limbs” problem, and the limbs were getting expensive and slow.

Our solution wasn’t a complete re-architecture overnight, but a phased approach focusing on data locality and smarter caching.

Phase 1: Localizing Static Assets and API Gateways

The lowest hanging fruit was always static content. We were already using CloudFront, but we weren’t being smart enough about invalidations and caching headers.

We started by auditing our S3 buckets for public assets. Many were served directly from S3, which meant every user request, even for static files, was potentially incurring direct S3 egress or hitting an origin in us-east-1 via CloudFront if not cached.

Practical Example: Optimizing S3 + CloudFront

First, ensure your S3 bucket policies are set up correctly. For public assets, it’s often better to serve them exclusively via CloudFront. We configured CloudFront distributions to point to S3 as the origin. The key here was setting appropriate cache-control headers on the S3 objects. This tells CloudFront how long it should keep an object in its cache before re-validating with the origin.

// Example S3 PUT Object with Cache-Control header (using AWS SDK for JavaScript)
const AWS = require('aws-sdk');
const s3 = new AWS.S3();

async function uploadFileWithCacheControl(bucketName, key, body, contentType) {
 const params = {
 Bucket: bucketName,
 Key: key,
 Body: body,
 ContentType: contentType,
 CacheControl: 'public, max-age=31536000, immutable' // Cache for 1 year
 };

 try {
 await s3.putObject(params).promise();
 console.log(`Successfully uploaded ${key} to ${bucketName} with Cache-Control.`);
 } catch (err) {
 console.error(`Error uploading ${key}:`, err);
 }
}

// Usage example:
// uploadFileWithCacheControl('my-static-assets-bucket', 'images/logo.png', fs.readFileSync('./logo.png'), 'image/png');

For frequently updated assets, we used shorter `max-age` values and sometimes triggered invalidations programmatically after deployments. For immutable assets (like versioned JavaScript bundles), `max-age=31536000, immutable` is your friend. It tells browsers and CDNs that this file won’t change, reducing re-validation requests significantly.

Beyond static files, we also started deploying regional API Gateways. Instead of all API requests hitting us-east-1 directly, users in Europe would hit an API Gateway in eu-central-1. This API Gateway would then forward requests to the us-east-1 backend. While this still incurred inter-region egress for the backend calls, it pushed the initial connection closer to the user, reducing latency for the user and offloading some connection overhead from the central region. The egress from the API Gateway back to the user was then regional, not inter-region from us-east-1.

Phase 2: Data Locality and Read Replicas

This was the trickier part. Our main database was PostgreSQL, hosted on Amazon RDS in us-east-1. We had read replicas in eu-central-1 and ap-southeast-2. However, application logic wasn’t always smart about using them. Often, a query would go to the primary even if a replica had the data, or a complex join required data from different tables, some of which might not be fully replicated or up-to-date on a replica.

The immediate fix was to enforce read replica usage for all read-only operations. This required a small change in our ORM configuration and some developer discipline.

Practical Example: Smart Database Connection Routing (simplified)

// Pseudo-code for a database connection pool that prefers read replicas
class DatabaseRouter {
 constructor(primaryConfig, replicaConfigs) {
 this.primaryPool = new pg.Pool(primaryConfig);
 this.replicaPools = replicaConfigs.map(config => new pg.Pool(config));
 this.currentReplicaIndex = 0;
 }

 async query(sql, params, isReadOnly = false) {
 if (isReadOnly && this.replicaPools.length > 0) {
 // Rotate through replicas for load balancing and availability
 const pool = this.replicaPools[this.currentReplicaIndex];
 this.currentReplicaIndex = (this.currentReplicaIndex + 1) % this.replicaPools.length;
 try {
 return await pool.query(sql, params);
 } catch (e) {
 console.warn("Replica query failed, trying primary.", e.message);
 // Fallback to primary if replica fails (e.g., connection issue, replica lag)
 return await this.primaryPool.query(sql, params);
 }
 } else {
 return await this.primaryPool.query(sql, params);
 }
 }
}

// Usage in an application service
// const dbRouter = new DatabaseRouter(primaryDbConfig, [replica1Config, replica2Config]);
// const users = await dbRouter.query('SELECT * FROM users WHERE active = true', [], true); // Read-only
// await dbRouter.query('INSERT INTO orders (item, qty) VALUES ($1, $2)', ['widget', 5]); // Write

This simple pattern, while not foolproof, dramatically reduced the number of read queries hitting the primary database across regions. The egress for these read queries was then contained within the regional boundary of the replica, rather than traversing the Atlantic or Pacific.

For more complex scenarios, we explored multi-region database solutions, but that was a larger architectural shift. For now, optimizing read replicas was a significant win.

Phase 3: Inter-Service Communication and VPC Peering

One common egress trap is data moving between services in different Availability Zones (AZs) within the same region, or worse, between different VPCs without proper peering. While intra-region, inter-AZ egress is usually cheaper than inter-region, it’s still not free.

We had a microservice architecture, and services were often communicating via internal APIs. Some services were deployed in different subnets or even different VPCs for security reasons.

The fix here was two-pronged:

1. Keep related services in the same AZ where possible: This isn’t always feasible for high availability, but for services that have very tight coupling and high data transfer, co-locating them in the same AZ can reduce intra-region egress. We re-evaluated our AZ distribution strategies.
2. Use VPC Peering or Transit Gateway for inter-VPC communication: If services absolutely had to be in different VPCs, we ensured they were connected via VPC Peering or, for more complex network topologies, a Transit Gateway. This routes traffic directly over the AWS backbone, avoiding public internet egress charges that might occur if services were communicating over public IPs (even if within AWS).

It’s a subtle point, but if service A in VPC1 talks to service B in VPC2 over service B’s public IP, even if both VPCs are in the same region, you’re paying egress. If they talk over a private IP via VPC peering, it’s typically free or significantly cheaper (usually considered intra-VPC traffic).

We also found some services were pulling large datasets from S3, processing them, and then pushing them back to S3. If the EC2 instance doing the processing was in a different AZ from the S3 bucket, that’s inter-AZ egress. The solution was to ensure our processing instances were in the same AZ as the primary S3 bucket for that data, or to use S3 VPC endpoints to keep traffic private and avoid gateway charges.

The Cost Savings: A Pleasant Surprise

After about three months of implementing these changes, we saw a measurable impact. The client’s egress bill dropped by approximately 20% month-over-month. That’s not insignificant when you’re talking about a multi-thousand dollar cloud bill.

More importantly, the user experience improved. Latency for users outside of us-east-1 decreased, leading to better engagement metrics. It reinforced my belief that performance and cost optimization are often two sides of the same coin.

Actionable Takeaways for Your Agent Performance

So, what can you do today to tackle your own egress monster?

• Audit Your Data Transfer Patterns:

  This is step one. Go through your cloud provider’s billing reports. Most providers break down egress by service and destination. Look for the largest chunks of data moving out of your primary region, or even between AZs. Tools like AWS Cost Explorer, Google Cloud Billing reports, or Azure Cost Management are your friends here. Pay attention to “Data Transfer Out” line items.

• Prioritize Static Content and CDN Usage:

  Ensure all your static assets (images, CSS, JS, videos) are served via a CDN (CloudFront, Cloudflare, Akamai, etc.). Set aggressive `Cache-Control` headers for immutable assets. For dynamic content, consider edge caching where appropriate.

• Embrace Regionalization and Data Locality:

  If you have users globally, consider deploying your application closer to them. This might mean regional deployments, read replicas, or even multi-region databases. The goal is to minimize the distance data has to travel from its origin to the user.

• Optimize Inter-Service Communication:

  For services within the same region, try to keep them within the same AZ if data transfer is very high (balancing with HA needs). If services are in different VPCs, always use VPC Peering or a Transit Gateway to keep traffic private and avoid public internet egress charges.

• Be Smart About S3/Object Storage Access:

  If EC2 instances or containers are frequently pulling large amounts of data from S3, try to co-locate them in the same AZ as the S3 bucket. Use S3 VPC Endpoints to route traffic privately and avoid NAT Gateway charges for S3 access. This is a subtle but important point for services with high S3 interaction.

• Monitor and Iterate:

  Egress patterns can change as your application evolves. Make egress cost a regular review item. Set up billing alerts to notify you of unexpected spikes. Treat it as an ongoing optimization effort, not a one-time fix.

Egress costs are often the forgotten line item on the cloud bill, but they can quickly add up. By being intentional about data movement and leveraging the architectural patterns available to us, we can build more efficient, performant, and cost-effective systems.

That’s it for me today. Go check those bills! Until next time, keep building smart.

🕒 Published: April 12, 2026