AWS Data Transfer Costs Explained: NAT Gateway, Cross-AZ, and Internet Egress

AWS network cost follows the traffic path. A private instance sending data through a NAT gateway can pay for gateway hours, NAT processing, cross-AZ transfer, internet egress, and public IPv4 addresses. Reducing one meter does not automatically reduce the others. Start with the route and the billing quantities before changing the architecture.

Separate the four billing dimensions

AWS documents NAT availability and data processing separately. Hours accrue while the gateway is available, including quiet periods. Processing follows the bytes passing through it in either direction. Downloads, retries, and responses can therefore drive processing even when application uploads look small.

Network transfer is another dimension: same-AZ private traffic, cross-AZ traffic, cross-Region traffic, and internet traffic follow different rules. Public IPv4 addresses add their own time-based charge to public NAT deployments. A private NAT gateway has no Elastic IP; do not attach that public-address assumption to every NAT design.

Three examples with explicit assumptions

1. Internet traffic through one zonal public NAT

Assume one gateway, one standard AWS-provided public IPv4 address, same-AZ clients, 1,000 billed GB processed, and 1,000 billed GB sent to the internet. Return bytes are negligible in this simplified model. The VPC pricing examples give Ohio rates of $0.045 per gateway-hour, $0.045 per processed GB, and $0.005 per public IPv4-hour. Internet out is modeled at $0.09/GB.

Gateway:     720 × $0.045 = $32.40
Public IPv4: 720 × $0.005 =  $3.60
Processing: 1000 × $0.045 = $45.00
Internet out: 1000 × $0.09 = $90.00
Total:                       $171.00

Assume the monthly free internet-out allowance is already consumed. The EC2 pricing page specifies 100 GB free per month aggregated across AWS services and Regions, excluding China and GovCloud; it is not 100 GB per gateway. With the full allowance available here, internet out would be $81, making the total $162. Larger volumes and other Regions need different rates. Free ingress does not imply free NAT processing.

2. Moving same-Region S3 traffic off NAT

Suppose 2,000 billed GB of same-Region S3 traffic currently passes through that gateway. The processing component is 2,000 × $0.045 = $90. An S3 gateway endpoint can remove that NAT path without endpoint hourly or processing fees. S3 request and storage charges remain. If the gateway still serves third-party APIs, its $32.40 hours and $3.60 public IPv4 charge remain: the modeled reduction is $90, not $126.

This applies to gateway endpoints for S3 and DynamoDB. Their interface endpoint alternatives have different capabilities and pricing. Validate bucket policies, endpoint policies, DNS behavior, and the relevant route tables with a canary workload before redirecting production traffic.

3. Why a paid interface endpoint can cost more

For one supported same-Region service in N. Virginia, assume 500 billed GB processed and an interface endpoint in three AZs. Using PrivateLink pricing of $0.01 per endpoint ENI-hour and $0.01/GB in the first processing tier: 3 × 720 × $0.01 + 500 × $0.01 = $26.60. Compare that with $22.50 of marginal NAT processing at $0.045/GB.

If NAT must remain for other destinations, the endpoint adds $4.10 in this model. The break-even against marginal NAT processing is about 618 GB per month for those three AZs. This assumes local endpoint access, equal measured traffic, and no other transfer differences. Fewer endpoint AZs reduce fixed fees but can add remote paths and change failure behavior. Include every required service endpoint, not just one convenient example.

Cross-AZ cost is an availability decision too

A central zonal NAT gateway can make a diagram look cheaper while routing other AZs through a chargeable hop. More local gateways increase fixed cost and can reduce that traffic. Regional NAT availability is another option; its gateway hours are billed per active AZ. Model the actual mode rather than counting one regional resource as one AZ-hour.

AWS's EKS network guidance discusses $0.01/GB each-way cross-AZ charges. Count chargeable source and destination sides and response bytes for your actual services; managed-service exceptions mean one universal multiplier is unsafe. Keep replica placement and failover requirements intact. Topology-aware routing, batching, and caching may reduce traffic without concentrating every replica in one failure domain.

A practical investigation sequence

Establish a useful denominator before labeling traffic as waste. Track bytes per successful request, completed job, or tenant alongside total spend. A launch that doubles both customers and network volume may have stable unit cost. A retry loop can increase traffic while successful work stays flat. Container image pulls, dependency downloads, verbose telemetry, and repeated object reads are useful places to investigate. Compare payload changes and deployment timing with the billing trend; this gives the owning team a concrete hypothesis to test instead of a generic instruction to reduce egress.

1. Locate the charge. Start with daily costs grouped by service, account, Region, and usage type. Look for patterns such asNatGateway-Hours, NatGateway-Bytes,DataTransfer-Regional-Bytes, and internet-out entries. Prefixes and names vary; VPC peering can have its own usage types.
2. Separate money from quantity. The Cost Explorer API documentation warns that UsageQuantity aggregates incompatible units. Filter to comparable usage types before adding GB; never add gateway hours to bytes. Billing quantities labeled GB and telemetry reported as GiB or raw bytes need consistent conversion before comparison.
3. Trace the workload. Check route tables, gateway AZs, DNS resolution, deployments, and existing NAT metrics. If those cannot identify the destination, use scoped VPC Flow Logs with a defined retention window. Publishing logs adds ingestion and archival costs; storage and queries can add more. Budget for the investigation before enabling broad collection.
4. Change one path and verify. Record the expected meter reduction, owner, rollback, latency, and error-rate checks. Compare billing after it settles against comparable demand. A lower total bill alone cannot attribute the result to this change.

Investigate sudden growth with the anomaly-versus-variance framework. Use the Cost Explorer versus FinOps tools guide to choose your reporting workflow, then distinguish estimated opportunities from verified savings. Network work complements safe rightsizing and multi-cloud cost management; none replaces an explicit traffic-path model.