How do We Eliminate DTO Fees?

Cloud Costs

April 23, 2025

To eliminate DTO (Data Transfer Out) fees—especially from cloud providers like AWS, GCP, or Azure—you either need to keep your traffic internal (same region or zone), use services that offer zero-cost egress (like Cloudflare R2 or Backblaze), or route through more efficient intermediaries like CDNs or third-party transit providers.

‍

The most straightforward way of looking at it is to dissect where you’re getting DTO charges and redirecting them in a way that doesn’t cost anything.

‍

What Even Are DTO Fees?

‍

When you move data out of your CDN—say from a bucket to the public internet, or from origin to a client—you get charged egress fees. AWS coined this term as Data Transfer Out (DTO).

‍

And these fees add up, fast.

‍

You’re not just paying for compute or storage anymore. You’re paying for how much bandwidth you're using when traffic leaves your server.

‍

Here’s a quick peek at general CDN or cloud transfer pricing (as of now):

‍

First 1 GB out is free (wow, thanks 🙃)
After that, it’s around $0.09/GB to the public internet (typical US regions)
Region-to-region transfer? Usually $0.02–$0.09/GB
Cross-AZ (Availability Zone) traffic? Often $0.01/GB

‍

So, even if your storage is cheap, if people are downloading stuff from it, you’re gonna bleed money on egress fees.

‍

Step 1: Pinpoint Every Source of DTO

‍

You really can’t eliminate DTO until you know exactly what’s generating it. It’s not always obvious. Sometimes it’s a forgotten S3 bucket serving images for your front-end.

‍

Other times it’s a service talking to another over a public IP even though they’re in the same VPC.

‍

Here’s how I approach it:

‍

A. Audit Ingress vs Egress

‍

You might already be monitoring CPU and memory, but make sure you’re logging network bytes in and out. AWS gives you per-resource breakdowns via CloudWatch. Look at:

‍

NetworkOut (for EC2/Lambda)
BytesDownloaded on S3
Data transfer costs in the AWS Cost Explorer (filter by “Data Transfer Out to Internet” and “Data Transfer Inter-Region Out”)

‍

You’d be surprised how much can leak here—especially from automated bots or scraper traffic.

‍

B. Trace Your Pathways

‍

I usually map out my traffic like this:

‍

Source	Destination	Egress Type
EC2 (us-east-1a)	S3 (us-east-1b)	Inter-AZ
S3 (us-east-1)	User (public)	Internet
Lambda (us-west-2)	RDS (us-east-1)	Cross-region
EC2	Third-party API	Internet

‍

Once I have that, I start asking: Can I move this to the same AZ? Can I keep it internal? Can I cache it or proxy it?

‍

C. Validate Your Route Choices

‍

Sometimes DTO costs come from misconfigurations. Like using a public IP inside a VPC even though both services are in the same subnet. That’s why I always double-check:

‍

Is the route table directing to private IPs?
Are DNS entries resolving to VPC-local endpoints?
Am I using NAT Gateway when I don’t need to?

‍

A misrouted DNS record can quietly add hundreds in bandwidth costs.

‍

Step 2: Use a CDN That Reduces Egress from Your Origin

‍

One of the cleanest ways I’ve reduced DTO fees is by putting a CDN in front of my origin—especially for static assets or predictable responses.

‍

When traffic hits the CDN and gets served from cache, it never has to come back to the origin. That cuts down your AWS data transfer bill drastically, even if you’re still using something like S3 or EC2 underneath.

‍

You don’t need to switch cloud providers—just put a smart caching layer in front.

‍

And if you’re serving files from S3, using a pull zone (e.g., with Cloudflare or Bunny) can help shift a lot of the traffic away from S3 directly.

‍

Step 3: Use Zero-Egress Storage for Static Files

‍

This one changed the game for me.

‍

I had a bunch of media files—images, PDFs, and some video—that were sitting in S3, costing more in egress than in storage.

‍

So I moved them to Cloudflare R2, which doesn’t charge egress fees to serve files over the internet.

‍

And if you don’t want to move everything at once, R2 can pull from S3. That means you leave your S3 setup intact, and just start serving traffic from a more bandwidth-friendly source.

‍

You can do something similar with Backblaze B2 and BunnyCDN. Their combo is especially good for larger files and global distribution, and their bandwidth pricing is usually $0.01–$0.02/GB, which is a fraction of typical egress.

‍

So, whether you call it bandwidth optimization or egress offloading—it works.

‍

Step 4: Keep Everything in the Same Region

‍

DTO doesn’t just happen to the public internet. It also happens inside your cloud if you're not careful.

‍

AWS, for example, charges for:

‍

Cross-region traffic
Traffic between AZs
Using public IPs within the same VPC

‍

I’ve had cases where a Lambda talking to an RDS instance across AZs was quietly racking up DTO fees.

‍

To fix that, I started co-locating services in the same AZ or at least the same region, and wherever possible, using private IP routing instead of public endpoints. VPC endpoints or interface endpoints are huge here—they let you keep traffic internal, which means no surprise DTO.

‍

This is where understanding AWS transfer pricing really starts to pay off.

‍

Step 5: Offload Egress with an Intermediary Server

‍

For high-bandwidth apps (media delivery, APIs, etc.), sometimes it makes sense to route traffic through a cheap external VPS before it hits the public internet.

‍

The architecture looks like this:

‍

Your app pushes data to a VPS (say, hosted on Hetzner or Linode)
The VPS serves traffic to users

‍

This backhauling approach lets you move large files or API responses without incurring high AWS egress fees, because AWS sees only one destination (your VPS), not a thousand end-users.

‍

You still control performance, but shift bandwidth to something cheaper.

‍

It’s not always needed—but for the right use case, it saves a lot.

‍

Step 6: Use Layered Caching

‍

Even if you’re already using a CDN, you can go further.

‍

Start caching intelligently at multiple layers:

‍

CDN edge (with long TTLs)
Application-level (e.g., Fastly Compute, Cloudflare Workers)
Origin-based logic (conditional responses, content shaping)

‍

The goal is simple: reduce how often content has to be pulled from your origin, especially across regions or from high-cost storage.

‍

For things like image thumbnails, auto-generated PDFs, or static JSON endpoints—caching saved me gigs per day in bandwidth, and that translated to pure cost savings.

‍

Step 7: Monitor DTO in Real-Time

‍

This one’s easy to skip, but crucial. DTO costs creep up slowly—until one day, you’re hit with a 4-digit bill.

‍

I set up basic monitoring with:

‍

AWS Cost Explorer (filtered by “Data Transfer”)
CloudWatch metrics on outgoing bytes per EC2/Lambda
Billing alarms when DTO passes a threshold

‍

Once I had that in place, I could see the moment something got noisy. That awareness alone helped reduce overages, just by catching and tweaking routes in real time.

‍

Once you get in the habit of tracing where your data exits, you’ll find a lot of ways to reroute it—without compromising performance or UX.

‍

Step 8: Make Use of Transfer Acceleration Only If It Justifies the Cost

‍

This one’s situational, but I’ve worked with teams that used Amazon S3 Transfer Acceleration without realizing it incurs additional bandwidth charges. If global users are accessing your S3 buckets and you’re trying to serve them fast, a CDN is often more cost-effective.

‍

Transfer Acceleration is optimized for speed, not cost. In most cases, CloudFront or an external CDN does the same job at a much better price point. Only keep it on if you’ve benchmarked the value against actual transfer savings.

‍

Step 9: Don’t Ignore Cross-Cloud or SaaS Integration Costs

‍

If your app talks to Stripe, MongoDB Atlas, or another SaaS product that’s outside your VPC, you’re technically doing public internet egress—even if it feels like part of your stack.

‍

Here’s what I look for:

‍

Are you syncing large volumes of data out (like analytics exports or backups)?
Is traffic going to third-party logging services (like Datadog, Logz.io)?
Are you moving data between cloud vendors (e.g., AWS to Azure)?

‍

In cases like that, I sometimes put a minimal proxy or staging step in place to reduce frequency or volume. For backup syncing, I compress, batch, and push at off-peak times to reduce sustained usage.

‍

It’s less about removing the traffic, more about controlling how and when it happens.

‍

Step 10: Be Intentional With Pre-Signed URLs and API Responses

‍

If you’re handing out pre-signed S3 URLs for public downloads, that traffic counts as direct S3 egress. Same with APIs that return large blobs of data (like JSON exports, CSVs, or video transcodes).

‍

Two things I do here:

‍

Proxy large responses through a CDN, so repeated downloads are cached.
Use streaming where possible instead of dumping full payloads.

‍

I once had a metrics dashboard returning 8MB of JSON every 30 seconds per user. DTO was ridiculous. Rewrote it to stream updates and dropped DTO by 90%.

‍

Step 11: Filter DTO at the Firewall or Load Balancer Layer

‍

This one’s a common blind spot. If you're using application load balancers (ALB) or Cloudflare, you can actually reduce DTO by filtering who even gets access to your infrastructure in the first place.

‍

Scrapers, bots, and fake requests generate real egress.
Even if you're caching content, origin fetches, redirect responses, or error pages still count toward bandwidth pricing.

‍

What I do:

‍

Block known data center IP ranges (ASN filtering)
Use WAF rules to block suspicious user-agents or paths
Leverage Cloudflare’s Bot Management Layer to challenge non-human clients before they ever hit your app
Filter traffic by GeoIP (example: if you're only serving one region, drop the rest)

‍

It’s not a silver bullet, but it’s a simple way to cut waste before it costs.

‍

What About VPC Peering and Transit Gateways?

‍

This is for more advanced setups, but worth mentioning.

‍

If you’re running multi-account AWS setups or have workloads split across VPCs, how you connect them matters:

‍

VPC peering is low-cost but can’t scale well with complex architectures
Transit Gateway gives you central control but has its own per-GB data processing cost

‍

So sometimes, even internal traffic ends up being "paid" traffic. In one case, I shifted high-throughput tasks to a single shared VPC to avoid the TGW toll and still get direct traffic flow.

‍

This isn’t egress in the classic sense, but if you’re doing multi-account networking, DTO can show up in unexpected ways.

‍