Data Transfer Costs for Common AWS Architectures

Compare transfer cost boundaries in multi-AZ apps, EKS, NAT, content delivery and regional recovery, with a worked example and architecture review record.

Price the paths, not the architecture label

A multi-AZ application does not have one data transfer price. Its user responses, application calls, database replication and outbound service requests can follow different billing rules. Build a cost model from those paths before deciding that an architecture is expensive or that a cheaper route is safe.

For a US deployment, “US Region” is still insufficient pricing evidence. Record the exact source and destination Regions, services, direction, endpoint type and pricing plan. This article compares five common designs and supplies a bounded example. It does not quote AWS rates, report customer savings or imply that an AWS environment was tested. Primary service rules were checked on October 19, 2026.

The output is an architecture comparison that names which costs could change and which remain. For bill-to-workload attribution, use the separate egress investigation article. For interpreting billing categories, use AWS data transfer pricing and tracking.

Multi-AZ web applications have several different crossings

Separate client-to-load-balancer, load-balancer-to-target and application-to-database paths. A target in the same zone as its receiving load balancer can still query a database writer in another zone. Moving targets does not automatically move that writer or change database failover behavior.

Do not price managed replication as ordinary application traffic. RDS pricing explicitly makes cross-AZ replication for Multi-AZ deployments free of data transfer charges. It separately describes EC2-to-RDS traffic across zones in one Region: the EC2 side has regional transfer charges, without an additional RDS-side transfer charge. This is a service-specific exception to the tempting but incorrect rule that every cross-zone byte is billed twice.

The load balancer also needs its own classification. Elastic Load Balancing documentation distinguishes cross-zone controls by load-balancer type. Check the applicable pricing separately; a routing setting alone is not a rate. Include load-balancer capacity charges in the complete architecture budget even when the disputed transfer category is exempt.

A single-zone redesign may remove a crossing while creating an unacceptable failure domain. Require surviving capacity, database reachability and accepted outputs during zone impairment before accepting a locality change. The existing cross-zone traffic review covers that rehearsal in depth.

EKS microservices add traffic amplification, not a new universal tariff

Kubernetes placement changes which nodes and zones communicate. It does not make every pod call billable. First identify the nodes, network path and AWS services behind the call. Then apply the documented treatment of that path. An EKS service name is not a billing category.

Look for amplification before changing placement. One customer response may involve several large internal responses, retries and serialization steps. A small request count can coexist with substantial internal transfer. Record bytes per completed business operation alongside total bytes, so traffic growth caused by useful demand remains distinguishable from repeated work.

Locality preferences need fallback rules. If local endpoints disappear, requests must reach appropriate healthy capacity without unbounded retries. A database read also needs the required consistency, not merely a nearby endpoint. Do not pin every dependency into one zone to make a normal-state spreadsheet smaller. Compare matched payloads and successful outputs before and after any separately authorized change.

Private-subnet egress combines processing, placement and fixed costs

A NAT gateway introduces hourly and per-GB processing charges. Depending on the route, transfer charges can apply as well. AWS NAT pricing guidance recommends examining cross-zone placement and supported endpoints. Adding one gateway per zone can reduce a crossing while increasing fixed cost; neither outcome can be inferred from a diagram alone.

For eligible S3 and DynamoDB access, gateway endpoints have no additional endpoint charge. Verify the caller's effective route and supported service/Region boundary before removing NAT from the model. A gateway endpoint is not a general-purpose exit for external APIs. A public destination address alone does not prove that an S3 request used NAT.

Interface endpoints have a different cost structure. PrivateLink pricing includes endpoint-hours by enabled zone and data processing. A fleet of low-volume endpoints across several zones can cost more than the processing it avoids. If NAT remains for unrelated destinations, its fixed hours remain too. Compare avoidable costs, not the whole old gateway bill against only the new endpoint's variable charge.

Content delivery depends on the selected CloudFront plan

Compare direct delivery and CloudFront using viewer geography, requests, origin behavior and the actual plan. CloudFront pricing currently offers flat-rate plans as well as pay-as-you-go. Their allowances and included features differ. A remembered free-transfer allowance from one pricing model is not a universal CloudFront budget assumption.

Keep origin traffic separate from viewer delivery. AWS documents waived transfer between CloudFront and AWS origins when serving through CloudFront, but that does not erase origin requests, compute or other charges outside the waiver. Cacheability and request volume still affect the design. Model misses and uncacheable responses rather than assuming every byte is served from cache.

Check authorization before caching user-specific responses. A cheaper delivery path that returns one customer's private object to another customer fails regardless of its bill. Preserve cache-key, access-control and invalidation requirements in the comparison. For a private API with little reusable content, assess latency and security benefits separately from any unproven financial benefit.

Regional recovery and hybrid links need a directional model

A secondary Region can receive replication, copied backups and restored data, then send traffic back during recovery. Price each intended direction using the responsible service and exact Region pair. A source-to-destination rate is not evidence for the reverse direction. Keep destination storage, requests and recovery compute separate from transfer.

For example, RDS documents transfer charges for cross-Region snapshot copies and automated-backup replication, alongside destination snapshot storage. That is a different path from its exempt Multi-AZ replication. Retain the recovery point and retention requirements before reducing copy frequency or scope.

Hybrid designs also require the selected connection's price structure. Direct Connect pricing separates port-hours and data transfer out, with location-related factors. Include provider connectivity costs separately when applicable. Do not treat a private connection as free transfer, or remove a redundant path before the network owner accepts the changed failure behavior.

Work a bounded NAT comparison before estimating savings

Consider fictional workers in two zones of us-east-1. They process 10,000 GB through one zonal NAT gateway during a stipulated 720-hour month. Of those GB, 8,000 are eligible same-Region S3 traffic and 2,000 go to an external API. The exercise stipulates 4,000 GB of separately identified, chargeable cross-zone metered usage. These are synthetic billing quantities, not packet captures.

All input rates are invented teaching values, not AWS quotes: $0.04 per gateway-hour, $0.05 per processed GB and $0.01 per chargeable regional GB. Baseline modeled cost is $28.80 + $500 + $40 = $568.80. Internet transfer, address charges and other architecture costs are excluded and unchanged within this comparison.

Option A retains the gateway and moves only the eligible S3 path to a gateway endpoint. Assume 2,000 processed GB and 800 chargeable regional GB remain. Modeled cost becomes $28.80 + $100 + $8 = $136.80, a $432 difference within this boundary. This requires route evidence; endpoint existence alone does not establish it.

Option B instead adds a second zonal gateway without changing destinations. With 1,440 total gateway-hours, unchanged processing and zero stipulated cross-zone usage, modeled cost is $57.60 + $500 = $557.60. The difference is only $11.20. Neither option has demonstrated savings: actual rates, metered quantities, permissions and reliability still require validation.

These are alternative cases, not cumulative savings. Their included components are limited to the three stipulated meters above.

Keep an architecture decision record

Copy the following fields into the team's controlled review record. Use UNKNOWN when evidence is unavailable rather than filling gaps with the intended design.

Flow and owner

Producer, consumer, business output, application owner and observation period.

Effective path

Accounts, exact Regions/zones, address family, endpoints and intermediates; dated configuration or observation reference.

Price provenance

Service pricing URL, checked date, direction, unit, tier/plan and any applicable exemption. Record fixed and variable components separately.

Baseline and alternative

Comparable output volume, each metered quantity, avoidable costs, retained infrastructure and new operating costs.

Failure contract

Zone or route failure behavior, surviving capacity, consistency, partner allowlists, safety limits and reversal owner.

Disposition

Supported comparison or HOLD, missing evidence, next bounded check and acceptance criteria.

Start with one large flow whose service and route are known. Replace every synthetic input with dated evidence, retain the required failure behavior, and reconcile the subsequent bill before reporting savings. Ampity's AWS consulting and migration service can review those decisions, but the record is usable without submitting private billing or network data.