AWS Data Transfer Pricing: Types, Fees and Tracking

Classify AWS transfer charges by service, route and direction. Reconcile billing units, processing fees and rate evidence with a worked tracking example.

Build a transfer ledger before choosing a rate

AWS data transfer pricing depends on the services, route, direction and pricing arrangement involved. A generic US per-GB rate cannot explain a bill containing internet delivery, cross-Region copies, NAT processing and endpoint-hours. Keep those charge families separate, then apply the current rule to each one.

This article helps an engineer or FinOps analyst produce a classified, reproducible ledger. It covers public AWS billing definitions checked on October 19, 2026, with a synthetic arithmetic example. It does not quote current dollar rates, inspect an account or prove which application caused a charge. The egress attribution article owns that later causal investigation. For design alternatives, read transfer costs in common AWS architectures.

Topic cover for AWS transfer billing categories and tracking, not a pricing chart

Separate transfer from the services processing it

Start with four transfer boundaries: internet, Availability Zone, Region and service-specific delivery. Then identify any intermediary processing the traffic. NAT, interface endpoints and load balancers can introduce separate charges even when a particular transfer component is exempt. “Free transfer” never means the whole request or workload is free.

EC2 pricing describes internet outbound tiers and an aggregated monthly allowance with stated Region exclusions. Do not assign the full allowance independently to every workload, Region or service. Establish which account-level rules and pricing terms apply before using an allowance in a forecast. Inbound transfer can have no transfer charge while destination requests, storage or a processing intermediary still cost money.

Within one Region, service-specific exemptions prevent a blanket cross-AZ rule. RDS pricing distinguishes free Multi-AZ replication transfer from chargeable EC2-side cross-AZ application traffic. Record the engine/deployment and actual relationship rather than pricing all database bytes alike. A replica's business purpose does not determine its billing exemption.

Cross-Region traffic needs the source/destination pair and direction. Do not double a charge merely because the export contains both an incoming and outgoing record. Conversely, a separate response or reverse replication flow may need its own rate. The billing record's meaning takes precedence over a visual arrow count.

Public addresses do not define an internet tariff

The shortcut “public IP means internet egress” is unsafe. AWS's EC2 addressing documentation says communication through public NAT addresses can incur regional or internet transfer, depending on whether instances are in the same Region. It also describes cases where public-address traffic stays on AWS's network. Address appearance alone establishes neither the physical path nor its charge.

Public IPv4 address-hours are a separate category from bytes. Keep them in a complete network budget, but do not divide their fixed charge by observed payload and call that a transfer rate. The same discipline applies to NAT hours: they continue while the provisioned resource remains chargeable, even during a low-traffic period.

For PrivateLink, retain endpoint-hours and processing separately. Do not label it universally cheaper than NAT. Endpoint count, enabled zones, retained NAT destinations and volume change the comparison. CloudFront likewise has flat-rate and pay-as-you-go models; identify the actual plan before applying a remembered allowance or a variable delivery rate.

Use Cost Explorer to isolate comparable quantities

Choose a billing period, linked account, currency and cost metric first. Retain that definition in the saved view. Begin with service and usage-type grouping to discover candidate charge families, then filter to a comparable subset before examining usage quantities. Do not assume every transfer-related charge appears under EC2 or a dashboard's “EC2-Other” grouping.

AWS's GetCostAndUsage reference warns that aggregate usage quantities can mix units, such as compute-hours and GB. Filter by usage type or usage-type group before interpreting a quantity. A total of 720 hours plus 1,000 GB is neither 1,720 GB nor a meaningful traffic trend.

Compare quantity and cost separately. A cost change with flat quantity can reflect tiers, pricing terms or adjustments. More quantity with flat cost may reflect an allowance or plan. Neither observation identifies the application responsible. Save the extraction time too, because a current-period bill is not necessarily the final financial record.

Classify export rows with product and usage type together

For a detailed investigation, use an authorized billing export and retain its schema. AWS's data transfer charge reference documents regional, inter-Region and internet usage-type families. Region prefixes are not universal: it describes unprefixed forms for Northern Virginia. Build a reviewed mapping from actual rows, not a filter requiring one remembered prefix.

Use product code alongside usage type. CloudFront transfer names can resemble other internet outbound names, while the product distinguishes them. Keep operation, description, quantity, unit and cost alongside that classification. A broad text search for “DataTransfer” is a discovery aid, not a complete network-cost inventory: processing and fixed-hour rows need separate review.

The line-item definitions also explain that resource IDs may be blank for data transfer. Tags cannot recover an identity the export does not contain. Preserve an unallocated category until another permitted evidence source supports the mapping. Do not assign every blank-resource row to the largest application.

Worked example: reconcile a synthetic transfer ledger

Assume a fictional month in us-east-1, with a cross-Region copy to us-west-2. Every quantity and rate below is a teaching input, not an AWS quote or account observation. Quantities are already normalized to each stipulated billing unit; this is not a conversion from packet logs. No free allowance, tier discount, credit or tax is applied.

Synthetic meterQuantityInvented unit rateModeled charge
Internet outbound1,000 GB$0.08 per GB$80.00
Chargeable regional transfer2,000 GB$0.012 per GB$24.00
Cross-Region outbound500 GB$0.025 per GB$12.50
Corresponding incoming record500 GB$0 per GB$0.00
NAT processing3,000 GB$0.04 per GB$120.00
NAT provisioned time720 hours$0.03 per hour$21.60

The corresponding 500 GB incoming record has a stipulated zero transfer charge. It is retained for reconciliation, not priced again at the outbound rate. These quantities describe overlapping billing meters, not disjoint payload totals.

Separate intermediary rows show 3,000 NAT-processed GB at an invented $0.04, giving $120, plus 720 gateway-hours at $0.03, giving $21.60. The modeled total is $258.10: $80 + $24 + $12.50 + $0 + $120 + $21.60. It is not valid to sum these heterogeneous quantities into a traffic total. Some payload can contribute to both a transfer category and processing.

Suppose finance's same-scope charge total is instead $270.10. The $12 difference remains unresolved. Check omitted charge families, cost basis, period and adjustments; do not edit traffic measurements until the totals match. If the 500 GB incoming record were incorrectly priced again, it would add $12.50 and produce $270.60, which still would not explain the $270.10 record. Near agreement is not evidence of correct classification.

Corroborate paths without turning telemetry into billing

Use existing authorized flow logs, application metadata and route history only after identifying the disputed billing family. These sources can support a path hypothesis; they do not automatically carry AWS's priced unit or exemption. Avoid adding source-interface and gateway observations of the same payload together.

VPC Flow Logs limitations include traffic omissions and skipped records. An empty result therefore cannot prove zero traffic. A denied log read cannot prove the route was absent. Preserve the gap and ask the authorized evidence owner rather than expanding privileges, collecting payloads or enabling paid telemetry without approval.

Watch costs and quantities in their own units after an accepted change. Retain delivery completeness and demand measures as well. Lower spend during missing exports or lower customer activity is not demonstrated optimization. Alerts can prompt investigation, but their threshold does not prove a cause or authorize a route change.

Save a rate-provenance record the next analyst can use

Scope and financial basis
Billing period, extraction time, account scope, currency, cost metric, adjustments included and export/schema reference.
Charge identity
Product, usage type, operation, description and resource reference or UNKNOWN. Keep transfer, processing and fixed hours distinct.
Route applicability
Source/destination service and Region, direction, zone relationship, endpoint or delivery plan, and evidence supporting the mapping.
Rate evidence
Primary pricing URL, checked date, applicable unit, tier, allowance or exemption, and account-specific terms if authorized. Missing rate evidence means HOLD for the estimate.
Reconciliation
Quantity by compatible unit, modeled cost, billed cost on the same basis, supported difference and unresolved remainder.
Next action
Named evidence owner, bounded check, review date and conditions that invalidate the mapping. Keep implementation authorization separate.

Begin with one charge family, reproduce its arithmetic and explain any remainder before changing infrastructure. Keep private exports in the team's approved evidence store. Ampity's AWS consulting and migration service can review the model without turning this public worksheet into a request to upload billing records.

Related services