.GDu3yQvm_1Msmru.jpg)
AWS charges for data that leaves AWS for the internet, for data that moves between Regions, and (in most cases) for data that crosses Availability Zones. It also charges for data that passes through a NAT Gateway, whatever its source or destination. Inbound data is free, and the first 100 GB a month going out to the internet is free. Most surprise bills come from the middle of that list: traffic nobody thought of as “leaving” anything.
This guide covers what each type of data transfer costs, a worked example with numbers, and the changes that cut the bill. It sits alongside Why Your AWS Bill Is Higher Than It Should Be, which covers the other causes.
What AWS charges for, and what it doesn’t
| Traffic | Charged? | What AWS says |
|---|---|---|
| Into AWS from the internet | No | “There is no charge for inbound data transfer across all services in all Regions” |
| Out to the internet | Yes, after the free allowance | 100 GB a month free, aggregated across all services and Regions; tiered per-GB rates above that |
| Between Regions | Yes, per GB | Rate depends on the source and destination Region; for example $0.02 per GB from US West (Oregon) to US East (N. Virginia) |
| Between Availability Zones, same Region | Yes, for most services | Traffic within one AZ is free; across AZs, data transfer charges apply |
| Through a NAT Gateway | Yes | An hourly charge plus a per-GB processing charge on all traffic, “regardless of the traffic’s source or destination” |
| To S3 or DynamoDB through a gateway endpoint | No | “No data processing or hourly charges” for gateway endpoints |
Two details catch people out. First, the internet allowance is pooled across your whole estate, so one chatty workload can use it up before the others have started. Second, the rates are set per originating Region, so a London price is not always the same as the US East figures AWS uses in many of its examples. Price your own Region in the AWS Pricing Calculator before committing to a design.
A worked example
(Illustrative.) A 15-person payments firm runs a microservices application across three Availability Zones in one Region. Each month it sends 2 TB between services in different AZs, pulls 5 TB from S3 through three NAT Gateways, and serves 3 TB of reports and statements to customers over the internet.
Rates used here are list rates quoted by AWS for US East regions. In London (eu-west-2) the internet egress and cross-AZ rates are the same, but NAT Gateway hours and processing cost a little more than the US East example, so treat the NAT lines as a slight underestimate for a UK deployment.
| Line | Calculation | Monthly cost |
|---|---|---|
| Cross-AZ traffic | 2,000 GB × $0.01 sent + $0.01 received (assumed $0.01 per GB each way, the rate AWS states for AZ-crossing VPC peering traffic) | $40 |
| NAT Gateway processing | 5,000 GB × $0.045 (AWS’s US East (Ohio) example rate) | $225 |
| NAT Gateway hours | 3 gateways × 730 hours × $0.045 | $98.55 |
| Internet egress | (3,000 GB − 100 GB free) × an assumed $0.09 per GB | $261 |
| Total | about $625 |
The NAT line is the instructive one. The 5 TB going to S3 does not need a NAT Gateway at all. A gateway endpoint for S3 is free, so moving that traffic onto it removes the $225 processing charge. That is a one-line route-table change, not an architecture project. The three gateways still carry any other outbound traffic, so the $98.55 stays unless they can be consolidated.
How to find where your transfer costs come from
Start in AWS Cost Explorer (see our glossary entry), filter to the service with the largest transfer spend, and group by Usage type. Lines containing DataTransfer-Out-Bytes are internet egress, DataTransfer-Regional-Bytes is cross-AZ traffic, and NatGateway-Bytes is NAT processing. Without a tagging scheme you will know how much, but not which team or application is responsible, which is why cost allocation tags come first.
The levers that cut the bill
| Lever | What it fixes | Watch out for |
|---|---|---|
| Gateway endpoints for S3 and DynamoDB | NAT processing on traffic to those services | Only these two services; other AWS services need interface endpoints, which have their own hourly and per-GB charges |
| A CDN such as CloudFront in front of public content | Repeated egress of the same files | Check the current CloudFront pricing for your usage pattern; its free allowances are separate from the EC2 one |
| Keep chatty services in one AZ where resilience allows | Cross-AZ charges | Trades cost against availability; never do it for a system that needs to survive an AZ failure |
| Compress and cache API responses | Egress volume | Needs engineering time; measure first |
| Review cross-Region replication | Inter-Region charges | Replication is what makes a recovery Region work, so cut volume, not the copy |
The last row matters for regulated firms. A recovery Region means paying to move data into it continuously, and that cost belongs in the disaster recovery business case from day one. A pilot light or warm standby keeps the cost low by replicating only what recovery needs, as covered in the strategies post.
Where to start
- Pull the last three months of Cost Explorer data grouped by usage type and note the three biggest transfer lines.
- Check every NAT Gateway for traffic that is really going to S3 or DynamoDB.
- Check whether public downloads and reports are served straight from S3 or EC2.
- Put the transfer cost of any planned multi-Region design into the estimate, not the run-cost surprise column.
Transfer charges rarely appear on a design diagram, so they are the easiest costs to miss and the easiest to fix once seen. If you would rather have the whole bill read for you, our AWS cost optimisation service prices every saving in pounds a month.
