AWS Inter-AZ Data Transfer Cost: Trace Charges

Reducing cross-Availability Zone network traffic requires a continuous balance between data locality and workload availability. Collapsing an architecture into a single Availability Zone removes inter-AZ charges on private-IP traffic, but it also removes the physical redundancy that keeps production applications online during an infrastructure failure. The practical challenge is deciding which specific traffic paths to localize and which to leave distributed.

Tracing AWS inter-AZ data transfer cost demands mapping an aggregated billing line to a specific set of network endpoints. Once you identify a high-volume path, you evaluate the cost of changing its placement against your redundancy requirements.

FinOps AI does not trace network paths. It shows AWS spend by service, and by Region for accounts connected through its cross-account role (Google Cloud by service), and inter-AZ transfer sits inside the service lines it belongs to, so it shows whether the service line that carries the charge fell after a change, not the transfer charge itself. Find the path itself with AWS-native billing and network data, and make the placement change through your own deployment process: FinOps AI has no action that moves a gateway, changes a load balancer or reschedules pods.

Evaluate the Rate Before Estimating Savings

Because the specific services involved and the direction of the traffic dictate the final charge, predicting the financial impact of an architecture change requires knowing exactly how AWS applies transfer rates. A common mistake is treating all traffic inside a Region as free, or assuming every cross-AZ byte carries the exact same price.

The EC2 On-Demand Instance Pricing page lists a charge of $0.01 per gigabyte in each direction for cross-AZ transfers within a single Region. This applies to eligible traffic between Amazon EC2, Amazon RDS, Amazon Redshift, DynamoDB Accelerator, ElastiCache instances, and Elastic Network Interfaces. While same-AZ transfer is free for specific resource pairs, response traffic and extra network hops can affect the total.

Since that $0.01 rate applies in each direction, a single transfer crossing an Availability Zone boundary often generates a charge at both ends. AWS documents this two-ended behavior in a Network Load Balancer architecture example: when 1 GB of data moves between an EC2 client and an NLB located in different Availability Zones, the sender incurs a $0.01 charge and the receiver incurs a $0.01 charge. The total cost for that 1 GB of cross-AZ traffic equals $0.02.

Intermediary services add another layer to the calculation. When traffic routes through a NAT Gateway, Transit Gateway, or PrivateLink endpoint, those services incur their own hourly and per-gigabyte processing fees. You need to map the entire route before changing it, as moving an endpoint to eliminate a $0.01 per gigabyte transfer charge often introduces new processing costs that cancel out the savings.

Match Billing Evidence to the Specific Workload

An effective investigation separates what AWS invoiced from which network interface generated the traffic. Billing reports establish the financial total, while network logs provide the operational map. Neither source offers complete attribution on its own.

Use Cost Explorer and CUR to Confirm the Billed Amount

Because AWS groups transfer costs under the services associated with the traffic, such as Amazon EC2 or Amazon S3, Cost Explorer doesn't always display data transfer as a universal standalone line item. Locating these charges requires specific query parameters.

The Cost Explorer data table documentation lists grouping dimensions, including AWS services, usage types, and Availability Zones, and notes that data transfer costs are included in the services they're associated with rather than appearing as separate line items.

For granular investigation, use the Cost and Usage Report's lineItem/UsageType column to identify data transfer charges. The Understanding data transfer charges page identifies Region-DataTransfer-Regional-Bytes as the usage type for transfers between Availability Zones in the same Region. A transfer in the US East (Ohio) Region appears as USE2-DataTransfer-Regional-Bytes. Data transfer charges can vary by service and source AWS Region, and AWS records two DataTransfer-Regional-Bytes line items for each resource metered, one for inbound traffic and one for outbound traffic.

Recent changes to VPC peering visibility require looking for different usage types depending on the date of the traffic. Starting in April 2025, AWS began recording intra-Region VPC peering charges under VpcPeering-In-Bytes and VpcPeering-Out-Bytes. Historical reports from early 2025 or before show these same flows categorized under the broader DataTransfer-Regional-Bytes label, making it helpful to include both the old and new patterns when analyzing long-term spend trends.

Use VPC Flow Logs to Map the Traffic Path

Once you confirm the total billed amount and the usage type, use VPC Flow Logs to identify the network interfaces carrying the traffic. Flow logs capture IP traffic going to and from network interfaces in your VPC, exposing the conversation between specific resources.

The default format records interface-id, srcaddr, dstaddr and bytes. Add instance-id, az-id, interface-type and next-hop-az-id with a custom format: a flow whose az-id differs from its next-hop-az-id crossed an Availability Zone. By correlating the interface IDs and addresses with your inventory, you map the bytes to specific EC2 instances, managed databases, or Kubernetes worker nodes.

Matching Flow Logs across a multi-account environment requires using Availability Zone IDs rather than AZ names. In the oldest Regions, including us-east-1, AWS maps AZ names independently for accounts created before November 2025, so the zone labeled us-east-1a in your development account might be us-east-1b in your production account. Using the static AZ ID, such as use1-az1, ensures you compare traffic in the same physical location.

Treat Flow Logs as operational evidence of a network path, not a financial audit tool. A SKIPDATA log status means AWS skipped some records in that interval because of an internal capacity constraint or error, so flow-log byte totals won't always reconcile with the invoice. Publishing flow logs to CloudWatch or S3 also incurs vended-log ingestion and archival charges. Apply tags to your log destinations to track these monitoring costs alongside your data transfer expenses.

Choose an Optimization Path Based on Service Behavior

Different AWS services route and bill traffic according to their own rules, meaning a structural change that saves money on a load balancer might increase costs on a NAT Gateway. Trace the complete path, including the client, the intermediaries, the destination, and the return traffic, before selecting a new placement strategy.

None of the changes below is one FinOps AI can make for you: it has no action for NAT Gateways, load balancer settings, caches or pod placement. Make them through your own deployment pipeline, and compare the service line that carries the transfer charge before and after in its cost report.

Compare NAT Gateway Placement Options

Private resources usually reach the internet through a NAT Gateway; for Amazon S3 and DynamoDB, a gateway VPC endpoint bypasses it with no hourly or data processing charge. When an EC2 instance in a private subnet sends traffic to a NAT Gateway in a different Availability Zone, the transfer incurs the cross-AZ charge.

AWS Well-Architected guidance recommends placing a NAT Gateway in the same Availability Zone as high-traffic resources to eliminate this extra hop. Doing so requires inspecting your private subnets and updating your route tables to point local traffic to the local gateway. A regional NAT Gateway gives the same locality without per-zone route tables: it expands into each zone that has workloads and is billed per zone-hour.

This localization trade-off comes with an immediate financial penalty, since a NAT Gateway carries a fixed hourly cost regardless of how much traffic it processes. If you deploy a second NAT Gateway to serve a second Availability Zone, you add a fixed monthly charge to your bill. The $0.01 per gigabyte savings must exceed the fixed hourly cost of the new gateway to generate a net reduction.

Evaluate NLB Rules Separately From ALB and CLB

Load balancers dictate how client requests distribute across target compute nodes. Separate the client-to-load-balancer traffic from the load-balancer-to-target traffic to understand the billing impact.

AWS guidance for the Network Load Balancer details the cost of cross-zone load balancing. When an NLB receives a request in Zone A and routes it to a target in Zone B, that hop incurs standard cross-AZ charges. Setting the NLB's client routing policy to Availability Zone affinity makes clients that resolve through Route 53 Resolver favor the NLB node in their own zone; turning cross-zone load balancing off then keeps each node's traffic on targets in that zone.

Disabling cross-zone load balancing requires proportional target capacity. If Zone A receives 80% of the client traffic but holds only 50% of your compute targets, those instances overload while targets in Zone B remain idle.

Application Load Balancers and Classic Load Balancers behave differently. AWS does not charge for data between EC2 instances and a Classic or Application Load Balancer over private IPs in the same VPC, including across zones. Verify the exact load-balancer type before assuming a cross-AZ path represents a billing optimization opportunity.

Review Database Replication and Cache Traffic

Applications communicating with databases often generate the highest volume of internal transfer. Identify chatty service pairs where a web tier repeatedly requests the same static data from a database tier located in a separate zone.

Evaluating this traffic means weighing application-level caching against database placement. Implementing an in-memory cache closer to the compute tier reduces the cross-AZ read volume, but introduces cache invalidation complexity and potential data consistency delays. Moving the compute nodes into the same zone as the primary database writer removes the charge while the writer stays in that zone (after a Multi-AZ failover it moves, and the charge returns), and concentrates your failure domain.

Because managed database replication traffic follows service-specific pricing rules, do not assume all database traffic appears on the bill as ordinary EC2 transfer. Amazon RDS does not charge for replicating a Multi-AZ deployment between zones, but application-to-database traffic across zones is billed on the EC2 side only, at $0.01 per GB in and out of the instance, with nothing charged on the RDS side. Check the pricing documentation for the specific database engine.

Confirm EKS Pod Paths Before Moving Nodes

Containerized environments add a layer of abstraction over the physical network, so when inspecting Kubernetes cost, node-level visibility alone obscures the originating pod. An EC2 worker node might host twenty different application pods, making it difficult to know which microservice is responsible for the outgoing bytes.

Use the packet-level fields pkt-srcaddr and pkt-dstaddr (custom format), which show a pod's own IP for traffic inside the VPC; for traffic leaving the VPC, the Amazon VPC CNI translates the pod's address to the node's by default. Map these endpoints to your Kubernetes deployment manifests to confirm that a specific pod communicates across an AZ boundary. Only after proving the pod path should you consider topology-aware routing or trafficDistribution: PreferSameZone (Kubernetes 1.34 and later; use PreferClose on 1.31 to 1.33) on the Service, which make kube-proxy prefer same-zone endpoints and fall back to other zones; pod affinity and topology spread constraints control where pods run.

Decision Aid: Prioritizing Cross-AZ Traffic Interventions

Compare your suspected traffic paths against this matrix to determine the most effective intervention and the corresponding risk.

Weigh Net Savings Against Availability Needs

Reducing the total bytes crossing an Availability Zone boundary does not automatically yield a cheaper or more resilient system. The optimization process demands comparing the financial savings against the engineering effort and the resulting failure behavior.

Estimate the Complete Cost of a Placement Change

A valid business case requires a clear accounting of the complete impact. To estimate the net savings of an architecture change, subtract the added costs from the avoided transfer charges.

Take the avoided transfer charge from the cost of the matching DataTransfer-Regional-Bytes line items, which already cover both directions. Then, total the added costs: new NAT Gateways, Transit Gateway processing fees, additional load balancer hourly rates, redundant compute nodes, and the operational time required to maintain the new configuration.

In US East (N. Virginia) a second NAT Gateway costs about $32.85 a month ($0.045 an hour; the same in Ohio and Oregon, more in every other Region). Divide that by what the cross-AZ hop costs per GB in your Cost and Usage Report, counting requests and responses: at $0.01 per GB the break-even is about 3,300 GB a month, and at $0.02 (billed at both ends) about 1,650 GB. A high-volume video processing workload easily clears this threshold, while a low-traffic internal reporting tool loses money on the change.

Keep Failover and Capacity Targets Intact

Locality optimizations need to respect your disaster recovery objectives, because running all compute, storage, and database primary nodes in a single Availability Zone creates a single point of failure. When that zone experiences an impairment, the entire application goes offline.

The AWS Well-Architected Reliability Pillar's REL11-BP05 recommends static stability for critical workloads: enough capacity in each zone to carry the workload if one zone is lost, which in a two-AZ design means 100% per zone.

This resilience objective requires distributing targets evenly. Turning cross-zone load balancing off fits it only if each zone is sized to absorb its own clients plus failover; an NLB withdraws a zone's IP from DNS when that zone fails its health check. Reserve locality changes for unnecessary, chatty traffic paths, leaving failover routing in place for critical user requests.

Apply a Bounded Change and Verify the Result

Modifying network paths and compute placement carries risk, making safe execution the final step in addressing AWS inter-AZ data transfer cost.

Establish a baseline by recording the current billed usage and the application's average response time. Next, scope the proposed change to a single workload and a specific traffic path, then obtain formal approval from the service owner. Applying blast-radius limits helps keep the change from affecting neighboring systems.

After the change, monitor the resulting network traffic and your response-time baseline, and compare the billed DataTransfer-Regional-Bytes usage with your estimate once a full billing period has passed. FinOps AI's multi-cloud cost view shows the account's spend by service beside your other AWS and Google Cloud costs, so you can see whether the service line that carries the charge moved; the transfer charge itself is in the Cost and Usage Report. It does not make network changes, so a change like this one does not appear in its savings ledger, which records only the AWS changes FinOps AI executes.

This measured approach helps eliminate waste while preserving the availability your users expect.

---

See where your AWS and Google Cloud spend goes, by account and service, and run the AWS changes FinOps AI can make through approval and rollback, at getfinops.cloud.