AWS Egress Cost Guide: Internet, Cross-Region, Cross-AZ, and CDN-Origin Charges
Use these AWS-focused tools when you already suspect the bill is an outbound transfer charge and want to validate the billing surface before modeling prices.
Short answer: why egress estimates fail
- Traffic boundaries are mixed into one blended rate.
- CDN edge bandwidth and origin egress are treated as the same path.
- Retry and incident traffic is excluded from peak scenarios.
This is the egress decision and billing page. Use it when you already believe the traffic is an outbound transfer charge and need to decide which egress bill you are modeling, how to estimate GB/month, and when to go straight to pricing.
Go back to the network transfer boundary guide if you still have not identified the transfer path and need to sort internet egress, cross-AZ, cross-region, CDN edge delivery, or origin-to-CDN traffic before pricing.
Fast answer: which AWS outbound charge are you trying to explain?
- Internet egress: data leaving AWS to users or external systems.
- Cross-region transfer: replication, DR, and multi-region reads.
- Cross-AZ transfer: east-west traffic between Availability Zones.
- Origin-to-CDN: cache-fill traffic from AWS origin to CDN.
AWS egress pricing: what users usually mean
- Internet egress: data leaving AWS to users or third-party systems.
- Cross-region transfer: replication, DR traffic, or multi-region reads.
- Cross-AZ transfer: east-west traffic between services in different Availability Zones.
- Origin-to-CDN transfer: AWS-origin traffic sent to a CDN during cache fill.
If you already know which one you are modeling, jump straight to the egress cost calculator. If not, keep reading and map the boundary first.
1) Match the estimate to an AWS billing surface
- Internet egress: check whether the billed path is data transfer out to the internet or to external consumers.
- Cross-region transfer: confirm whether replication, failover sync, or remote reads are being billed separately from internet delivery.
- Cross-AZ transfer: check whether east-west traffic inside AWS is inflating the bill before you call it egress.
- Origin-to-CDN: confirm whether the AWS-origin path is the billed outbound charge instead of CDN edge bandwidth.
2) Pick the right unit (GB vs GiB)
Billing is often in decimal GB/TB, while OS tools might show GiB/TiB. Convert before estimating costs. Use the Units Converter if you're unsure.
Quick egress formula
- Monthly egress cost = sum(each transfer path GB x path-specific $/GB).
- Path examples: internet egress, cross-region replication, cross-AZ east-west traffic, origin-to-CDN transfer.
- Rule: do not blend all traffic into one rate unless your billing data proves it.
AWS billing usage types to check before you trust the estimate
- AWS billing usage types: match the outbound charge to the actual service and direction before you copy a headline $/GB rate.
- Service-level pricing rules: check whether the charge belongs to EC2 data transfer, VPC transfer, CloudFront-origin traffic, or another AWS billing surface.
- Boundary mismatches: if the usage type suggests intra-AZ or cross-region movement, go back to the boundary guide before treating it as plain internet egress.
Guide first or calculator first?
- Use the boundary guide first when "AWS egress" still means several possible transfer paths.
- Use the calculator first when you already know the GB/month and effective $/GB for a specific path.
- Use provider guides next when the path is known but the provider-specific billing rule is still unclear.
3) Estimate GB per month (quick methods)
- From billing/metrics: use measured bytes sent or transfer GB in billing exports.
- From API volume: requests/day x average response KB -> GB/month (use API response transfer).
- From throughput: Mbps x utilization x time -> GB/month (use Units Converter).
4) Model cost with simple assumptions first
Start with "GB/month x $/GB". You can refine later for tiering and free allowances. Tools: Egress, CDN bandwidth, cross-region transfer.
5) Validate (avoid double counting)
- Separate CDN edge bandwidth from origin egress (cache fill).
- Separate cross-AZ from internet egress (they are different boundaries).
- Re-check during incident windows: retries/timeouts can multiply traffic and create spikes.
Common pitfalls
- Tiered pricing: your average $/GB changes as traffic grows.
- Double counting: CDN bandwidth may not equal origin egress.
- Replication direction: some services bill only outbound, others have nuances.
- Cross-AZ traffic: load balancers and multi-AZ clients can create steady east-west transfer.
AWS egress charges checklist before you trust the number
- Match each transfer path to an AWS billing usage type or service-level pricing rule.
- Keep internet, cross-region, cross-AZ, and CDN-origin traffic in separate rows.
- Test a baseline week and a peak week before using one blended monthly rate.
- Re-check after architecture changes, CDN changes, or failover drills.
Boundary map template (do this before modeling rates)
- Path A: internet delivery to end users.
- Path B: cross-region replication and failover sync.
- Path C: cross-AZ service-to-service traffic.
- Path D: origin-to-CDN cache fill traffic.
What to check when AWS egress spikes
- Compare a normal week to the spike window before trusting a single monthly average.
- Check whether cache misses, failover traffic, retries, or chatty multi-AZ paths drove the increase.
- Verify that the spike came from the same AWS billing usage type you are modeling now.
- If the spike source is unclear, go back to the network transfer boundary guide before changing the price model.
Failure patterns that create 2x to 10x errors
- Using a single $/GB for internet and private transfer paths.
- Counting CDN edge bandwidth and origin egress as the same stream.
- Ignoring retry storms and timeout loops during incidents.
- Estimating with daily averages only and missing burst windows.
Validation checklist for monthly planning
- Match each transfer path to a specific billing usage type.
- Verify units (GB vs GiB) and conversion assumptions.
- Compare baseline and peak windows separately.
- Recalculate effective $/GB for each boundary every month.
Optimization order by boundary
- Internet egress first: compress payloads, improve cache strategy, trim large responses.
- Cross-region second: reduce replication fan-out and move chatty services closer.
- Cross-AZ third: reduce east-west traffic and improve service locality.
- Origin-to-CDN path: focus on cache hit rate and invalidation discipline.