AWS Egress Cost Guide: Internet, Cross-Region, Cross-AZ, and CDN-Origin Charges

Use these AWS-focused tools when you need to diagnose which outbound transfer line moved, then model one boundary at a time.

First-screen triage: the bill went up, what changed first?

1. What changed first: transfer volume, transfer boundary, or effective rate.
2. Which bill path moved and what AWS usage type drove the increase.
3. Confirm whether the cost belongs to internet egress, cross-region, cross-AZ, or CDN origin fill.
4. How to check first: billing usage types and service-specific transfer lines.
5. What to validate next: traffic source, unit assumptions, and peak-window behavior.

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. Back to transfer boundary guide if you 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 actually explaining?

• 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.

This is what teams usually mean by AWS egress pricing. 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 calculator first when you already know the boundary or path and can model a known rate with confidence.
• Use this guide first when the bill is still unclear and you need diagnosis before modeling.
• Use the boundary guide first when "AWS egress" still means several possible transfer paths.
• 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.

High-value mistakes that break egress estimates

• Mixing CDN edge bandwidth and origin egress as one stream, then applying a single rate to both.
• Using one blended $/GB across internet, cross-region, and cross-AZ traffic instead of separate boundary-specific rows.
• Ignoring retry storms, launch traffic, or failover windows and trusting only calm-week averages.
• Assuming billing exports and app telemetry share the same unit without checking GB vs GiB conversions.
• Skipping usage-type validation and mapping the wrong service line to your egress model.

Monthly planning checklist before you trust the number

1. Identify the billable boundary for each row (internet, cross-region, cross-AZ, or origin-to-CDN).
2. Confirm the unit and source of volume (billing exports, service metrics, or request-size estimation).
3. Split baseline and peak periods instead of using one blended monthly average.
4. Validate each row against AWS billing usage types or service-specific transfer line items.
5. Only then move to calculator scenarios and interpretation for budget decisions.

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.

Warning signals before monthly sign-off

• If one blended rate still covers multiple boundaries, stop and split the model into separate rows.
• If the spike month still uses calm-week averages, rerun with baseline and peak windows separated.
• If usage types do not map cleanly to your rows, pause and re-classify the billed path before pricing.
• If units are mixed across telemetry and billing, reconcile GB vs GiB before finalizing the estimate.

Guide vs calculator: keep the workflow clean

• This guide owns: diagnosis, mistake prevention, workflow routing, and boundary clarification.
• The calculator owns: inputs, scenarios, result interpretation, and next-step actions after calculation.
• If boundary or bill mapping is unclear, stay in guide mode. If the boundary is known, move to calculator mode.

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.

Related tools

More egress guides

Related guides

Related calculators

FAQ