Nobody sets out to spend money on data transfer, yet on a real bill it routinely hides 10–30% of the total across a dozen line items nobody can read: internet egress, cross-AZ chatter, inter-region replication, and the NAT surcharge stacked on top of all of them. This is the complete pricing map — every path a byte can take and what AWS charges for it — plus how to find your number in the CUR, the four offenders that dominate, and the fixes that cut it 40–90% without touching performance.
Every other AWS cost answers a simple question — how many instance-hours, how many gigabytes stored, how many requests. Data transfer answers a question nobody is tracking: which physical path did each byte take? That single difference is why it is the hardest cost to predict, the easiest to ignore, and the one that quietly compounds into 10–30% of a mature bill.
Compute and storage are billed against a thing you provisioned — you chose an m5.xlarge, you can see it in the console, you can reason about its cost. Data transfer is billed against an event you did not provision and cannot see: a packet leaving one subnet for another, a replica syncing to a second Region, an API response streaming out to a browser. No dashboard tile says "you moved 4 TB across Availability Zones last month." It surfaces only in aggregate, on the invoice, after the fact, under usage-type codes most engineers have never decoded.
It is also priced by geography of movement, not by service. The same gigabyte costs nothing if it stays in one Availability Zone over private IPs, about a cent each way if it crosses to a sibling AZ, around two cents if it hops to another Region, and roughly nine cents if it leaves AWS for the public internet — before NAT Gateway adds its own ~$0.045/GB surcharge on the egress path. The service that generated the traffic (RDS, ElastiCache, your app tier, S3) is almost irrelevant to the price; the route is everything. That inversion is why a "database cost" investigation so often ends at a networking charge, and why teams optimizing instance sizes miss the line that is actually growing.
The last reason it hides: the defaults that generate it are all correct. Multi-AZ generates cross-AZ traffic; private subnets generate NAT egress; cross-Region replication generates inter-Region transfer; serving users globally generates internet egress. None are mistakes — which is exactly why nobody questions them, and why the spend accumulates unchallenged until a cost audit lines it up against the architecture and asks, charge by charge, "does this byte need to take this path?"
There are only a handful of paths a byte can travel, and once you can name them, the whole bill becomes legible. Here is every one, with representative 2026 US-Region rates — always confirm the current per-Region numbers on the AWS pricing pages, since exact figures vary by Region and step down at volume.
Two rules make the whole map memorable. First, charges stack: the paths above layer rather than exclude. A byte leaving a private subnet for the internet pays NAT data processing AND internet egress; a byte sent cross-AZ to a service reached over a public IP can pay cross-AZ AND lose the free same-AZ rate. A surprising transfer bill is almost always two or three charges on the same traffic, not one. Second, the cheapest correct path nearly always exists and is usually free — same-AZ private addressing, VPC endpoints for AWS services, and CloudFront for internet egress are the three levers that move bytes off the metered paths. Optimization is rarely "send less data" (often you can't); it is "send the same data by a cheaper route."
Data INTO AWS is free; data staying in one AZ on private IPs is free; everything else — cross-AZ, inter-Region, internet egress, the NAT surcharge — is metered and stacks. So the entire game is moving each kind of traffic onto its cheapest correct path: AWS-to-AWS onto VPC endpoints, internal services into the same AZ, and internet egress behind CloudFront.
You cannot fix what you cannot attribute, and data transfer is invisible until you decode the usage-type codes. Cost Explorer gets you the totals in five minutes; the Cost and Usage Report (CUR) gets you the byte-level attribution that tells you exactly which path to fix.
Open Cost Explorer, set monthly granularity over the last 3–6 months, and group by Usage Type. Data transfer hides in codes you can now read: DataTransfer-Out-Bytes (internet egress), DataTransfer-Regional-Bytes (cross-AZ within a Region — billed both directions), DataTransfer-Inter-Region-Out/In (Region-to-Region), and per-Region prefixes like USE1- that tell you which Region the charge lives in. NAT shows separately as NatGateway-Bytes. Add a filter for the "Data Transfer" usage-type group to isolate the whole category at once.
Read the shape. A large DataTransfer-Out-Bytes points at internet egress and CloudFront as the lever. A large DataTransfer-Regional-Bytes points at cross-AZ chatter and AZ placement. A large inter-Region line points at replication you may be able to trim or compress. Group additionally by linked account and by Cost Allocation Tag to see which team or service owns each path — and set a Cost Anomaly Detection monitor on the transfer usage types so the next time a new workload starts moving terabytes cross-AZ, you hear about it in days, not at month close.
Cost Explorer tells you which path; the CUR tells you which resource. The CUR is AWS's line-item-level export (to S3, queryable with Athena or loaded into a BI tool), and its lineItem/UsageType, lineItem/ResourceId, and product/* columns let you group transfer cost by the exact resource and usage type — answering "which load balancer / which NAT Gateway / which S3 bucket / which replica is generating this." A single Athena GROUP BY on usage type and resource id, ordered by unblended cost descending, ranks your transfer spend by cause.
For the in-VPC paths (cross-AZ and NAT egress), pair the CUR with VPC Flow Logs: publish them to S3, then aggregate bytes by source/destination subnet and AZ to see exactly which service pairs are talking across AZ boundaries, and which destinations dominate the NAT path. The two together produce a sentence you can act on — "We spend $X/mo on data transfer; 44% is cross-AZ between the app tier and Redis, 31% is internet egress that belongs on CloudFront, 18% is S3 over NAT" — which is precisely the artifact a CloudRoute partner produces on day one of an audit.
Across audits the same four patterns generate the overwhelming majority of data-transfer spend. Knowing which one dominates your bill tells you which fix to reach for first — and the CUR breakdown from the last section maps directly onto this list.
The throughline across all four: most of the volume is traffic taking a more expensive path than it needs to. Cross-AZ traffic that could be same-AZ, AWS-to-AWS traffic that could be on a VPC endpoint, internet egress that could be cached at the edge, replication that could be smaller or scoped. Genuinely irreducible egress — unique responses to real external users — is usually the minority of the bill, and the part you optimize (compress, cache) rather than reroute.
The quietest of the four and often the largest. Spreading services across Availability Zones is the correct HA pattern, but every request that hops AZ boundaries pays ~$0.01/GB in each direction. A high-throughput app tier talking to a database, cache, message broker, or search cluster in another AZ — multiplied by every request, both ways, all month — turns into thousands of dollars of "internal" traffic, with cross-AZ replication between database nodes and cache members adding to it. Because it feels like private plumbing, nobody suspects it until Flow Logs rank the service-to-service pairs and the cross-AZ volume is staring back.
NAT is the surcharge that lands on AWS-to-AWS traffic that never needed the internet path. S3 reads, ECR image pulls, DynamoDB calls, and other AWS API traffic from private subnets routing out through NAT pay ~$0.045/GB for bytes a VPC endpoint would carry for free (S3/DynamoDB Gateway endpoints) or for ~$0.01/GB (interface endpoints) — and if any of it also reaches the internet, internet egress stacks on top. It is the single most common "we found $X,000/month" finding in a transfer audit. (The NAT-specific mechanics, diagnosis, and fixes get the full treatment on the dedicated NAT Gateway cost page; here it is one offender among four.)
Serving content and API responses straight from EC2, an Application Load Balancer, or S3 to end users pays the full ~$0.09/GB egress rate on every byte out. For anything cacheable or high-volume — static assets, media, downloads, even cacheable API responses — that is the wrong path. CloudFront egress is priced lower than direct EC2/S3 egress, and traffic from your origin into CloudFront is free, so putting the CDN in front both reduces the per-GB rate and offloads repeat requests to the edge cache entirely. The bytes you never re-serve from origin are the cheapest bytes of all.
Disaster-recovery and latency architectures replicate continuously, and every replicated byte pays ~$0.02/GB inter-Region — forever, not once. S3 Cross-Region Replication, cross-Region RDS/Aurora read replicas, multi-Region DynamoDB global tables, and cross-Region snapshot copies are the usual sources. The traffic is legitimate, so the lever is not "stop replicating" but "replicate less and smaller": replicate only the buckets/prefixes/tables that genuinely need a second Region, compress before transfer, and confirm you are not paying to replicate logs, temp data, or rebuildable artifacts that do not warrant cross-Region durability.
Once the CUR and Flow Logs tell you which path dominates, the fixes are mechanical and low-risk. They are ordered below roughly by return-on-effort — the first two are free and frequently remove the majority of the spend.
Add Gateway VPC endpoints for S3 and DynamoDB — they are completely free, no hourly or per-GB charge — and their traffic immediately leaves the NAT/internet path for the AWS private network, dropping its transfer cost to zero. For other high-volume AWS services (ECR, CloudWatch, Secrets Manager, SSM, STS, SQS, KMS), add interface endpoints (PrivateLink): a small hourly fee per endpoint per AZ plus ~$0.01/GB, about a quarter of the NAT rate, so any service moving real volume is cheaper on one. This is the single highest-leverage change in AWS networking cost and it has no performance or security downside.
Attack cross-AZ chatter at the source. Co-locate tightly-coupled, high-throughput service pairs — app tier and its cache, app tier and a database read replica — in the same Availability Zone so their traffic rides the free same-AZ private path, while keeping a second AZ for failover rather than steady-state chatter. Use AZ-aware client configuration and topology-aware routing (keeping reads local to the zone) so requests prefer the in-AZ replica, and make sure internal traffic uses private IPs, not public or Elastic IPs that forfeit the free same-AZ rate. This is a placement and configuration change, not a rewrite, and it directly zeroes out the largest hidden line on many bills.
Put CloudFront in front of anything cacheable or high-volume served to users. Origin-to-CloudFront transfer is free, CloudFront's per-GB egress is lower than direct EC2/S3 egress, and edge caching means repeat requests never touch your origin at all — so you cut both the rate and the volume. Static sites, media, downloads, and cacheable API responses are the obvious wins; even partially-cacheable APIs benefit from offloading the cacheable slice. For S3-hosted assets specifically, CloudFront in front of the bucket is close to a default best practice for cost and latency alike.
When services in different VPCs or accounts (yours, a partner's, a SaaS vendor's) need to talk, AWS PrivateLink keeps that traffic on the AWS private network instead of routing it out to the internet and back. Beyond the security benefit, it avoids stacking NAT and internet egress charges on cross-account service traffic that would otherwise take the public path. For service-to-service integrations at volume, the private path is both safer and cheaper than exposing and consuming public endpoints.
For traffic you genuinely cannot reroute — real internet egress, necessary inter-Region replication — shrink the bytes. Gzip/Brotli on HTTP responses, compressing payloads before cross-Region replication, and efficient serialization all cut billed volume directly, often 50–80% on text-like data. One deliberate tradeoff to flag: S3 Transfer Acceleration speeds long-distance uploads by routing them over the CloudFront edge network, but it adds a per-GB acceleration fee on top of normal transfer — it buys upload speed, not savings, so enable it only where latency genuinely matters, never as a cost optimization. The rule: reroute what you can (free), compress what you can't, and pay for acceleration only when speed is the actual requirement.
Pulling it together into a repeatable sequence. This is the exact order a competent cost audit follows — quantify, attribute, reroute the free wins first, then optimize what remains — and it is the order in which a CloudRoute partner works a transfer engagement.
The discipline is sequencing: free reroutes before paid optimizations, attribution before action. Teams that skip straight to "turn on compression" leave the bigger Gateway-endpoint and same-AZ wins on the table; teams that act before attributing fix the wrong path. Quantify, attribute, reroute, optimize, instrument — in that order — and a sprawling transfer bill becomes a short, ranked remediation backlog.
Everything above is doable in-house if you have the time and VPC/CUR expertise to decode usage types, Athena-query Flow Logs, map service pairs to AZs, and deploy endpoints and CloudFront without breaking connectivity. Most teams with a surprising bill do not. That is the gap CloudRoute closes.
CloudRoute routes you to a vetted AWS partner who runs the full loop: a cost audit quantifying your transfer spend in Cost Explorer, a CUR + Flow Logs analysis attributing it path by path and resource by resource, then the remediation — Gateway and interface endpoints, same-AZ placement for the worst cross-AZ pairs, CloudFront for cacheable egress, PrivateLink for cross-account traffic, and compression where bytes are irreducible — all validated so nothing breaks. You get the savings without spending your own cycles on the intricacies of transfer pricing.
The part that makes this nearly free: AWS funds partner-led cost-optimization and Well-Architected work for qualifying engagements. A Well-Architected Review (its cost-optimization pillar covers exactly this transfer/endpoint/CDN pattern) can unlock AWS remediation credits, and AWS pays the partner through its funding programs — so for credit-eligible engagements you frequently cut the bill for $0. Honest framing: AWS-funding applies to qualifying engagements; where it does not, this is a vetted-partner referral that pays for itself in the first month, since the recurring transfer savings typically dwarf any one-time fee.
And it does not stop at data transfer. The same audit surfaces the adjacent wins — idle and zombie resources, EC2 right-sizing, commitment coverage (Savings Plans / Reserved Instances), and storage-class and EBS cleanup — so an engagement that started with "why is my data-transfer bill so high?" usually returns more than the transfer line alone.
For qualifying, credit-eligible engagements, AWS funds the partner and a Well-Architected Review can unlock remediation credits — so you cut your bill for $0. For everything else, it is a vetted-partner referral whose recurring savings pay for the work, fast. Either way, CloudRoute is paid by the partner, not by you.
The fastest way to internalize the map is to see each common scenario next to its rate and its remedy. Rates are representative 2026 US-Region figures — verify current per-Region pricing, since exact numbers vary by Region and step down at volume.
| Scenario (the path a byte takes) | Representative rate | Why it happens | The fix |
|---|---|---|---|
| Inbound from internet (upload / ingest) | $0/GB | AWS never charges for data in | Nothing — already free |
| Same-AZ over private IPs | $0/GB | Resources co-located in one AZ, private addressing | Keep internal traffic same-AZ + private-IP |
| S3 / DynamoDB read from a private subnet | $0 with endpoint vs ~$0.045/GB via NAT | Default routes the request out through NAT | Free Gateway VPC endpoint (zeroes it) |
| Other AWS API (ECR, CloudWatch, Secrets Mgr) via NAT | ~$0.045/GB via NAT vs ~$0.01/GB endpoint | AWS service reached over public path through NAT | Interface endpoint (PrivateLink) |
| Cross-AZ service chatter (app ↔ DB/cache) | ~$0.01/GB each direction | Services split across AZs for HA, talking constantly | Same-AZ placement for hot pairs |
| Internet egress straight from EC2 / ALB / S3 | ~$0.09/GB (first tier) | Serving users/responses directly from origin | CloudFront in front (lower rate + cache) |
| Cross-account / partner service traffic | NAT + internet egress stacked | Reaching another VPC/account over the public path | PrivateLink keeps it on AWS private net |
| Inter-Region replication (S3 CRR, read replicas) | ~$0.02/GB, continuously | DR / latency replication on every byte, forever | Scope + compress; replicate only what needs it |
| Egress through NAT to the internet | ~$0.045 NAT + ~$0.09 internet | Private subnet sending real internet traffic via NAT | Compress; keep NAT only for true internet egress |
| Long-distance upload with S3 Transfer Acceleration | Normal transfer + acceleration fee | Enabled for speed (sometimes by mistake, for "cost") | Use only when latency matters — it is not a saving |
Situation: The bill had grown faster than usage and nobody could explain it. Cost Explorer showed a large, climbing set of data-transfer usage types but no single obvious driver. Decoding them, data transfer was running ~$3,600/month — about 26% of the bill — across three paths: heavy cross-AZ chatter between the app tier and a Redis/RDS pair split across AZs for HA, S3 + ECR traffic routing through NAT, and full-rate internet egress serving cacheable assets and API responses straight from the load balancer. The platform lead suspected networking but had no time to Athena-query the CUR and Flow Logs while shipping.
What CloudRoute did: CloudRoute matched them within 19 hours to a US-East partner with a Well-Architected cost-optimization track record. Day 1: the partner attributed the spend in the CUR and Flow Logs — 41% cross-AZ, 29% S3/ECR over NAT, 24% direct internet egress. Day 2–4: deployed free S3 + DynamoDB Gateway endpoints and an ECR interface endpoint, moved the hot app↔cache and app↔read-replica pairs into the same AZ (keeping a standby AZ for failover), and put CloudFront in front of the cacheable assets and API responses — validating everything in staging before cutting production routes. Filed as an AWS-funded Well-Architected remediation.
Outcome: Data transfer dropped from ~$3,600/mo to ~$970/mo — a 73% cut, ~$31,500/year recurring — with zero change to availability or latency (the CloudFront layer improved it). The review also flagged uncommitted compute and unattached EBS volumes, adding ~$1,400/mo more savings the team actioned next. The engagement was AWS-funded; the customer paid $0, and CloudRoute was paid by the partner.
time-to-match: <24h · audit-to-fix: 4 days · transfer spend cut: 73% (~$31.5K/yr) · cost to customer: $0
CloudRoute matches you with a vetted AWS partner who maps your transfer spend in the CUR, reroutes it onto the cheap paths, and adds CloudFront where it pays. Often AWS-funded — you frequently cut the bill for $0. Otherwise the savings pay for the work in the first month.