Amazon ECS Service Connect Now Routes In-Zone by Default: How Zone-Aware Routing Cuts the Cross-AZ Bill You Never See
Cross-availability-zone data transfer is the most expensive line item most engineering teams have never looked at. It does not appear as its own charge in the AWS console, it hides inside a regional-bytes usage type that nobody opens, and it grows quietly every time you add a service, a replica, or a node. In early July 2026 AWS shipped a change that attacks this cost directly: Amazon ECS Service Connect now supports zone-aware routing, and it is turned on by default for new and existing services. For any business running microservices on ECS across multiple zones, this is one of those rare AWS updates that can lower a real bill without a single line of new code.
The short answer is this. Zone-aware routing makes ECS Service Connect prefer sending traffic to service endpoints that sit in the same availability zone as the caller, instead of spreading requests evenly across every zone. Because AWS charges for data that crosses a zone boundary but not for data that stays inside one zone, keeping traffic local cuts both your data transfer bill and your latency. AWS says the feature keeps more than 80 percent of traffic within the same zone when endpoints are balanced, and delivers roughly a 24 percent reduction in median network latency in multi-zone deployments. You do not have to rebuild anything. Existing services need one redeployment to pick up the new behaviour, and that is the whole activation step.
Why Cross-AZ Data Transfer Quietly Drains Your Budget
Running across three availability zones is the standard way to make a service resilient. It is also the standard way to run up a data transfer bill, because the two goals pull against each other. Every gigabyte that crosses an availability zone boundary is charged at 0.01 US dollars per gigabyte in each direction, so a single request-and-response round trip between two zones costs 0.02 US dollars per gigabyte, according to AWS cost analysis published by usage.ai and by beSharp in their 2026 data transfer guides. Data transferred between resources in the exact same zone over private addresses is free.
That per-gigabyte number sounds trivial until you multiply it by the traffic a busy service actually moves. usage.ai’s worked example takes a service pushing 263 terabytes a month across zones and lands on roughly 5,260 US dollars a month in cross-AZ charges alone, before you add anything else. And cross-AZ is rarely the only culprit. Once you fold in NAT gateway processing and inter-region replication, usage.ai reports that data transfer frequently accounts for 10 to 20 percent of total AWS spend at mid-to-large scale. That is a meaningful slice of the bill to be spending on bytes moving sideways between zones that a service mesh could have kept local.
The reason this cost hides so well is architectural. When you register a set of tasks behind a service and let a load balancer or a mesh distribute traffic evenly, roughly two thirds of your requests will land in a different zone from the caller in a three-zone setup. Each of those hops is billable. Nobody wrote a bad line of code. The default behaviour of spreading load evenly, the same behaviour that keeps your service resilient, is what generates the charge.
What Zone-Aware Routing Actually Changes
Before this launch, ECS Service Connect distributed requests across all healthy endpoints regardless of zone. Zone-aware routing changes the default so that Service Connect preferentially routes a request to an endpoint in the same zone as the task that made the call. It then adjusts the traffic weights dynamically as endpoints scale up and down, so one zone does not get overloaded while another sits idle.
The safety behaviour matters as much as the savings. If the local endpoints in a zone become unhealthy or drop below a capacity threshold, traffic automatically redistributes across the healthy zones. You do not trade resilience for cost. You keep the multi-zone failover you built ECS for, and you stop paying to cross zones when you did not need to. AWS puts the headline numbers at more than 80 percent of traffic staying in-zone when endpoints are balanced across zones, and about a 24 percent cut in median network latency, which is the same physics working in your favour: a packet that does not leave the zone arrives faster and costs nothing to move.
This is also a case where AWS did the sensible thing and made the better behaviour the default. Zone-aware routing is on by default for both new and existing services. There is no feature flag to hunt for and no new construct to learn. The one catch is that existing services, both the client side and the server side, need a one-time redeployment before the new routing takes effect. Until you redeploy, an already-running service keeps its old even-spread behaviour.
How This Compares to the Older Workarounds
Teams have been fighting cross-AZ costs for years, and the pre-2026 playbook was a collection of partial fixes. On plain EC2 behind an Application Load Balancer, enabling availability-zone affinity reduces cross-AZ traffic by around 70 percent, according to usage.ai. On EKS, people reach for Topology Aware Routing or a full service mesh like Istio to keep traffic local, which works but adds real operational complexity. There is also the classic own-goal that usage.ai flags: using public or Elastic IP addresses for same-region communication triggers the 0.01 US dollars per gigabyte charge in each direction even inside a single zone, so a simple addressing mistake can cost you money for traffic that should have been free.
Set against those options, the ECS change is notable for how little it asks of you. You are not installing a mesh, tuning topology hints, or rewriting service discovery. You get in-zone preference natively, with automatic failover, by redeploying. For a scale-up running a dozen services on ECS, that is the difference between a quarter of platform-engineering work and a redeploy on your next release.
The Numbers, With Sources
Here is the sourced picture a founder or engineering leader needs to make the call. Every figure traces to a named source and the retrieval date is 6 July 2026.
| Item | Figure | What it means | Source |
|---|---|---|---|
| Cross-AZ transfer rate | 0.01 USD per GB each direction (0.02 USD round trip) | Every byte between zones is billed twice, once out and once in | usage.ai; beSharp |
| Same-AZ transfer (private IP) | Free | Traffic kept inside one zone costs nothing to move | beSharp; companybench |
| Data transfer as share of AWS bill | 10 to 20 percent at mid-to-large scale | Cross-AZ, NAT, and inter-region together are a major cost centre | usage.ai |
| Worked example, 263 TB/month cross-AZ | Roughly 5,260 USD per month | Shows how quickly per-GB rates compound at real traffic volumes | usage.ai |
| Traffic kept in-zone by zone-aware routing | More than 80 percent when endpoints are balanced | The share of requests that stop being billable cross-AZ hops | AWS Containers blog |
| Median latency improvement | About 24 percent in multi-AZ deployments | The performance dividend of keeping traffic local | AWS Containers blog |
| ALB zone-affinity (older EC2 workaround) | About 70 percent cross-AZ reduction | Context for how the native ECS feature compares | usage.ai |
| Activation cost | One redeployment per service | The entire effort to switch the behaviour on | AWS Containers blog |
The one honest caveat: your own saving depends on how much of your traffic is genuinely cross-zone today and how evenly your tasks are spread. A service already pinned to one zone has little to gain, while a chatty set of microservices spread across three zones has the most. The 80 percent in-zone figure is AWS’s own measurement for balanced endpoints, so treat it as a strong indicator rather than a guarantee for your specific topology. The rates above are US-region figures and can differ in Asia Pacific and South America, so verify against current AWS pricing before you model a number for the board.
What to Do About It
Start by finding out whether you are paying this bill at all. Open Cost Explorer, filter the usage type for the regional-bytes and inter-zone entries, and look at the trend over the last few months. If cross-AZ transfer is a visible slice of your spend, you have a clear reason to act. Then redeploy your ECS services that use Service Connect so the zone-aware default takes effect, remembering that both the client and server services need the redeployment. After a week, compare the cross-AZ line again and confirm the drop. While you are in there, check for the common own-goal of same-region services talking over public or Elastic IPs, because that charge is pure waste and easy to fix by switching to private addressing. None of this requires an architecture change, and the payback shows up on the very next bill.
If you would rather not spend a sprint tracing data transfer usage types and validating the savings yourself, HAZERCLOUD can do it for you. We run cross-AZ and data transfer cost reviews for teams on ECS and EKS, redeploy services safely to pick up changes like zone-aware routing, and hand you a before-and-after on the bill. Book a free consultation and cost assessment at https://hazercloud.com/contact/ and we will show you exactly where your traffic is crossing zones and what it is costing you.
