7 ways to slash AWS cross-region data transfer costs

Cross-region data transfers cost money. Lots of money. Moving 1TB monthly between regions costs £840 per year. Most teams don't even know they're doing it. Invisible traffic flows between regions, quietly draining the budget. You can cut these costs 20 to 40 percent without cutting availability. You just need to be deliberate about when and why data crosses regions.

1. Track and measure first

You can't optimise what you don't see. Start here. Use AWS Cost Explorer to break down your bill by service and region. Filter for data transfer costs. Look at your last 3 months. See where the money is going.

CloudWatch gives you real-time visibility. Set up dashboards that show NetworkIn and NetworkOut per region per service. Watch for spikes. Unusual spikes mean something's wrong, usually unintended inter-region communication.

VPC Flow Logs capture every IP conversation. Enable them across your regions. Parse the logs. Find which applications are talking to which regions. Some of it's intentional. Some isn't. Kill the unintentional traffic.

AWS Cost and Usage Reports export into S3. Query them with Athena. Build custom reports that show you exactly where data is flowing and why. The data is usually noisy, but the big flows are obvious.

Do this for a week. You'll find at least one unexpected cross-region transfer that costs £10-100 per month.

2. Consolidate workloads into fewer regions

Many teams run applications across multiple regions "for resilience" or "because it made sense at the time." Usually it's just scattered. A database here, an application there, microservices spread across three continents.

Every inter-region communication costs money. Consolidate tightly coupled services into the same region. If your application and database need to talk frequently, put them in the same region. Kill cross-region communication for that path.

Be deliberate about multi-region. Use it for actual disaster recovery or global distribution. Don't use it as a default.

Pick 1-2 regions and concentrate your workloads there. Most applications don't need three regions. Most don't even need two. If you have data residency requirements, consolidate within regions that meet them. UK and Ireland? Pick eu-west-1 and eu-west-2. Your disaster recovery copy goes to eu-central-1, that's it.

Consolidation also improves latency and simplifies operations. The same engineers manage fewer environments. Less complexity, lower costs.

3. Use CloudFront and edge caching

CloudFront costs money (per request, per GB). Data transfer out of CloudFront also costs money. But it typically costs less than shipping data cross-region from your origin.

Put CloudFront in front of your static assets (images, CSS, JS, videos, API responses). CloudFront caches at edge locations near your users. A user in Singapore requests an image. CloudFront fetches it from your eu-west-1 bucket once. Then serves it 1,000 times from the Singapore edge location. You pay for one cross-region transfer, not 1,000.

Pair CloudFront with application-level caching. Use ElastiCache (Redis or Memcached) in your origin region. Cache hot data there. Fewer database queries means fewer inter-region calls to databases in other regions.

Set cache TTLs carefully. Higher TTL reduces origin requests but serves stale data longer. For product prices or inventory, staleness hurts. For user avatars, 1 hour stale is fine.

The cost is complexity. Caching adds failure modes. You now have three places data can live. Stale data can confuse users. Cache invalidation is hard. Worth it for high-volume reads, not worth it for low-volume dynamic data.

4. Use S3 Multi-Region Access Points

S3 Multi-Region Access Points give you one DNS endpoint that routes traffic to the closest S3 bucket. Users in London hit your London bucket. Users in Frankfurt hit Frankfurt. All through the same URL. No manual routing needed.

It's smart routing. It accounts for latency, bucket availability, and replication status. If replication is lagging from London to Frankfurt, the system routes London users to London temporarily.

Cost is lower because users hit the closest copy. Transfer costs are only for initial replication, not for every read.

Setup is moderate complexity. Create buckets in multiple regions. Enable replication between them. Create the Multi-Region Access Point. Monitor replication lag. The main gotcha is stale data. If you're writing to London and a Frankfurt user reads before replication completes, they see old data. Handle this in application logic or accept short windows of staleness.

Works well for content distribution, backup repositories, disaster recovery. Doesn't work for hot data that changes constantly.

5. Improve replication methods

Traditional replication copies entire datasets. Database changed? Copy the whole thing. 10GB changed out of 1TB? Copy all 1TB.

Delta replication (change data capture) copies only what changed. Same 10GB of changes, not the whole 1TB. AWS DataSync detects changes and copies only updated data. AWS Database Migration Service uses change data capture for databases.

Combine with compression. Gzip text data before transfer. Reduces size 3-10x depending on content. Decompress at the destination.

Batch replication. Don't replicate continuously. Replicate during off-peak hours when network is quieter and transfer speeds are faster.

Delta replication with compression can reduce cross-region transfer volumes by 50-70%. Downside is operational complexity. You now track what changed, manage versioning, handle conflicts when multiple regions write simultaneously.

Use this for databases with high change rates, large datasets, frequent backups.

6. Choose budget-friendly regions

AWS pricing varies by region. Northern Virginia (us-east-1) is cheap. London (eu-west-2) is expensive. Transferring data out of us-east-1 costs £0.05-0.09 per GB. Transferring between US regions costs £0.01 per GB.

New workloads? Start in us-east-1 if geography allows. Existing workloads? Moving is expensive. But for new disaster recovery copies, new dev environments, anything greenfield, put it in a cheap region.

Tradeoff is latency. Cheap regions are cheap for a reason. Usually they're farther from your users. Run new backups in us-east-1 to save money, but keep active services geographically close to users.

Works well for backups, archives, dev/test environments. Doesn't work for user-facing applications.

7. Compress data before transfer

Gzip text-based data (logs, JSON, SQL dumps, configs). Achieves 5-10x compression. Small file size, faster transfer, lower cost.

Binary data (images, videos) is already compressed. Don't bother.

Enables compression in database replication. PostgreSQL can compress WAL files. MySQL can compress binlogs. One checkbox, 30-50% reduction in replication data.

It costs CPU to compress and decompress. Modern instances handle it fine. For high-throughput scenarios, might need to scale up slightly.

Trivial to implement. Huge impact for log-heavy applications.

Putting it together

Start with monitoring and compression. Low effort, low risk, meaningful savings.

Next, look at consolidation. Can you move tightly coupled services into the same region? Do it.

Then look at caching. Static content? Put it behind CloudFront. Hot reads? Cache them in ElastiCache.

Finally, redesign for multi-region only if you actually need multi-region. Most teams don't.

Where Critical Cloud comes in

Cost optimisation only works if you have confidence in the numbers. Tracking cross-region costs is easy. Knowing whether your replication strategy is working as intended is harder.

We're a Powered by Datadog accredited partner. We instrument data transfer patterns, replication lag, and cost per GB into Datadog. You get complete visibility into whether your cost optimisation is actually working.

If you're running complex multi-region architectures or you're unsure where your data transfer costs are going, see how Critical Support works.