Zone-Aware Routing in ECS Service Connect: The End of the Cost vs. Resilience Trade-off

For years, architecting multi-AZ microservices on AWS meant accepting a silent cost: every service-to-service call crossing an availability zone incurred data transfer charges, typically $0.01/GB per direction. On payment platforms or trading systems with tens of millions of calls per hour, that cost is not noise; it is a budget line. The canonical answer was to concentrate services in fewer AZs or accept the cost as the price of resilience. ECS Service Connect with zone-aware routing, launched on July 23, 2026, eliminates that dilemma at the routing layer, no code change, no additional infrastructure.

The Economic Weight of Cross-AZ Traffic

$0.01: Per GB per direction cross-AZ (us-east-1). Data transfer cost between AZs in the same region, bidirectional means $0.02/GB effective
~1-2ms: Typical additional latency on cross-AZ calls. Small in isolation, but compounded across synchronous call chains of 10+ hops
0: Additional cost of zone-aware routing. Feature enabled by default at no additional charge across all commercial and GovCloud regions
1x: Redeployment required for existing services. A single redeployment enables the new routing behavior, no configuration or code change required

The Signal: What Changed in the Routing Mechanism

ECS Service Connect operates as a lightweight Envoy-based service mesh, injecting a sidecar proxy into each task and registering endpoints in an AWS Cloud Map namespace. Before this feature, load balancing across endpoints was topology-agnostic: a task in us-east-1a could route to replicas in us-east-1b or us-east-1c with equal probability, depending only on health and configured weight.

With zone-aware routing, each task's Envoy proxy receives zone metadata and prioritizes endpoints in the same AZ with a dynamic weight. The mechanism is not a static 100% local routing, it is a weight algorithm that adjusts based on locally available capacity. If the local AZ has sufficient healthy endpoints to absorb the load, traffic stays local. If local endpoints fall below a capacity threshold or become unhealthy, the algorithm automatically redistributes to neighboring AZs, without manual intervention and without overloading any specific zone.

This behavior mirrors what Kubernetes implements with topologyAwareHints in EndpointSlice (GA in Kubernetes 1.27) and what ALB does with cross-zone load balancing disabled. The difference is that in ECS Service Connect this is transparent, no annotations required, no hints configuration, and it works with native Service Connect DNS without any application code change.

Zone-Aware Routing: Traffic Flow and Failover

Service-to-service traffic within a multi-AZ ECS cluster. Solid arrows = preferred path (same AZ). Dashed arrows = automatic failover when local endpoints fall below capacity threshold.

🟦 AZ-1 (us-east-1a)

Order Service Task (AZ-1) (compute)
Envoy Proxy Zone: us-east-1a (network)
Payment Service Task (AZ-1) (compute)

🟩 AZ-2 (us-east-1b)

Order Service Task (AZ-2) (compute)
Envoy Proxy Zone: us-east-1b (network)
Payment Service Task (AZ-2) (compute)

🟥 AZ-3 (us-east-1c)

Payment Service Task (AZ-3) (compute)

☁️ Control Plane

AWS Cloud Map Endpoint Registry (data)
VPC Flow Logs + AZ Metadata (security)

Flows

caller_a -> envoy_a: outbound call
envoy_a -> payment_a: preferred (same AZ)
envoy_a -> payment_b: cross-AZ failover
envoy_a -> payment_c: cross-AZ failover
caller_b -> envoy_b: outbound call
envoy_b -> payment_b: preferred (same AZ)
envoy_b -> payment_a: cross-AZ failover
cloudmap -> envoy_a: endpoints + zone
cloudmap -> envoy_b: endpoints + zone
envoy_a -> flowlogs: traffic metrics

What Changes for Platform Architects

The multi-AZ cost model changes structurally. Services with high synchronous call rates (e.g., 50k req/s on a payment gateway) that previously generated GB/hour of cross-AZ traffic now keep that traffic local by default. The saving is not marginal, on platforms with dozens of microservices, it can represent hundreds of dollars per day.
The decision to disable cross-zone load balancing on ALBs becomes simpler. Previously, disabling cross-zone on ALB to save cost created imbalance risk if AZs had asymmetric capacity. With zone-aware routing in Service Connect covering east-west traffic, the risk is scoped only to north-south traffic, a much more controllable surface.
Zone-level observability becomes a first-class requirement. VPC Flow Logs with AZ metadata is now the recommended mechanism to validate routing effectiveness. This means teams that did not have Flow Logs enabled need to activate them, with cost impact on CloudWatch Logs Insights and S3 storage.
Automatic zone failover requires review of latency SLOs. When an AZ loses capacity and traffic redistributes, p99 latency will temporarily spike. Teams with tight SLOs (e.g., p99 < 50ms) need to model degradation behavior during redistribution and adjust alerts to distinguish expected degradation from a real incident.
Stateful services with session affinity require careful analysis. Zone-aware routing prioritizes locality, but does not guarantee session affinity. Services that maintain state in local memory (e.g., session caches without Redis) may see unexpected behavior during load redistribution, the routing changes, the session does not follow.

Positioning in High-Frequency Financial Architectures

On payment platforms I operate or review as reference, the typical pattern is an ingress gateway (ALB or API Gateway) distributing to an orchestration service, which in turn calls authorization, anti-fraud, ledger, and notification services in sequence or parallel. With 3 AZs and 10 tasks per service (roughly 3-4 per AZ), cross-AZ traffic before zone-aware routing was statistically ~66% of calls, two out of every three calls crossed a zone.

With zone-aware routing, that number drops to near zero under normal conditions. For a platform processing 100 GB/hour of payload in internal calls (not uncommon in settlement systems with 1-5 KB messages at 50k req/s), the direct saving is ~$48/hour in eliminated cross-AZ transfer, approximately $35k/month. Not the largest cost item on an enterprise platform, but a saving that requires zero architectural change.

More important than cost, however, is the impact on compound latency. In synchronous call chains with 6-8 hops (standard in payment systems with separation of concerns), each 1-2ms of cross-AZ latency multiplies. Reducing that to intra-AZ latency (~0.3ms) under normal conditions measurably improves the p95 of the full chain, especially during peak hours when latency variance increases.

The important caveat for financial environments is capacity asymmetry between AZs during scaling events. If autoscaling reacts faster in one AZ than others (which happens when CPU/memory triggers fire at slightly different moments), the AZ with more capacity receives more local traffic, and the AZ with less capacity redistributes to neighbors. This behavior is correct and expected, but it needs to be modeled in incident response runbooks.

Observability: VPC Flow Logs Are Not Enough Alone

The announcement recommends VPC Flow Logs with AZ metadata to validate routing effectiveness. This is a necessary starting point, but insufficient for financial production environments. Flow Logs operate at the network level, they confirm traffic is flowing within the AZ, but do not correlate with application latency, error rate, or retry behavior.

For a complete observability stack, I add three layers on top of Flow Logs. First, Envoy metrics exposed via ECS Service Connect: the Envoy proxy already collects upstream_cx_total, upstream_rq_retry, and latency histograms per destination cluster. With ECS Container Insights enabled and an Envoy metrics exporter (or via AWS Distro for OpenTelemetry), these metrics reach CloudWatch or Datadog with AZ granularity. Second, distributed traces with zone context propagation: by adding the az.id attribute to each call's span (via OpenTelemetry SDK), it is possible to build latency heatmaps per AZ origin-destination pair in X-Ray or Datadog APM, making it visible exactly when and how much cross-AZ traffic still occurs (during failovers). Third, zone redistribution alarms: a composite CloudWatch alarm that simultaneously detects a drop in healthy endpoints in one AZ AND a p99 latency increase in the destination service is a reliable signal that redistribution is active, and allows distinguishing expected degradation from a real failure.

The cost of Flow Logs in high-frequency environments is not trivial. At 50k req/s with 1 KB payloads, flow log volume can reach 10-20 GB/hour. I recommend using VPC Flow Logs with custom format including only necessary fields (srcaddr, dstaddr, az-id, bytes, start, end) and directing to S3 with hourly and AZ partitioning, which reduces storage cost and enables efficient Athena queries without going through CloudWatch Logs.

Real Failure Modes and How to Mitigate Them

Zone-aware routing solves a real problem, but introduces three failure modes that need to be on every serious architect's radar.

1. AZ Imbalance Amplified by Asymmetric Autoscaling. If autoscaling of a downstream service scales one AZ faster than others (common when CPU metrics have 1-minute evaluation windows and tasks do not scale at exactly the same time), the AZ with more tasks receives more local traffic, which increases its load and may trigger more scaling, while AZs with fewer tasks remain underutilized. The antidote is configuring target tracking scaling with ALB RequestCountPerTarget metrics instead of CPU, and ensuring the deployment's minHealthyPercent and maximumPercent are calibrated to maintain at least 1 task per AZ during deploys.

2. Thundering Herd During AZ Recovery. When an AZ recovers after a failure (endpoints become healthy again), Envoy begins redistributing traffic back to it. If recovery is abrupt (all endpoints return simultaneously), there may be a traffic spike to the newly recovered AZ before it is fully warmed up, particularly problematic for JVM services that need JIT warmup. The mitigation is using slow start mode in Envoy (configurable via ECS Service Connect task definition) with a 30-60 second window, gradually increasing the weight of newly healthy endpoints.

3. Redistribution Invisibility in Aggregated Dashboards. Latency and error metrics aggregated by service mask zone redistributions. An overloaded AZ with p99 of 200ms can be invisible if the other two AZs have p99 of 20ms, the aggregated average lands at ~80ms, below any alarm threshold. The solution is to mandatorily break metrics by AZ dimension in CloudWatch (using AvailabilityZone as a dimension in custom metrics) and define SLOs per AZ, not just per service.

Strategic Positioning: ECS Service Connect vs. App Mesh vs. EKS Topology Hints

This feature closes an important competitive gap between ECS Service Connect and service mesh alternatives. AWS App Mesh (now in maintenance mode, with migration recommended to Service Connect) never had native zone-aware routing. Istio on EKS has had localityLbSetting with configurable failover priorities for years. Native Kubernetes has had topologyAwareHints in EndpointSlice since 1.21 (beta) and 1.27 (GA). ECS Service Connect was behind on this specific dimension, and now reaches functional parity, with the advantage of being zero-config.

For teams evaluating ECS vs. EKS for new platforms, this launch removes one argument in favor of EKS. The relevant question is no longer 'EKS has zone-aware and ECS does not', it is 'what is the operational cost of managing a Kubernetes cluster vs. using ECS with Fargate and Service Connect?' For most financial platforms that do not need deep scheduler customization or specific Kubernetes operators, ECS with Service Connect now offers a comparable feature set with significantly less operational overhead.

The caveat is that ECS Service Connect still does not expose granular locality failover controls like Istio does. In Istio, it is possible to define explicit priorities (same AZ = priority 0, same region = priority 1, other region = priority 2) with configurable spillover percentages. In ECS Service Connect, the algorithm is managed by AWS, which is excellent for operational simplicity, but can be limiting for scenarios where you need fine-grained control over degradation behavior. For those cases, App Mesh (while still supported) or Istio on EKS remain the more appropriate choice.

The Real Value Is Not the Cost: It Is the Elimination of the Trade-off: Before this feature, platform architects had to make an explicit choice: accept cross-AZ cost as the price of resilience, or reduce resilience by concentrating services in fewer AZs. That trade-off appeared in ADRs, cost reviews, and capacity planning discussions. Zone-aware routing does not just reduce cost, it removes a recurring architectural decision from the team. The long-term value is in simplifying the decision space: teams can now distribute services across 3 AZs without economic penalty, which is the correct resilience decision in almost all cases.

Anti-Patterns to Avoid with Zone-Aware Routing

Assuming 'zero cross-AZ' is guaranteed in production. The routing is preferential, not absolute. During scaling events, deploys, and AZ failures, cross-AZ traffic occurs and is expected. Sizing costs assuming 100% locality is a planning error.
Disabling Flow Logs to save cost after enabling zone-aware routing. Flow Logs are the only native mechanism to validate that routing is working as expected. Disabling them creates a critical blind spot, especially during the first 30 days after activation.
Ignoring the required redeployment for existing services. The announcement is clear: existing services need a redeployment to activate the new behavior. Teams that skip this will continue with zone-agnostic routing and will not see the benefits, nor will they know they are not seeing them.
Using aggregated service metrics as the only SLO. With zone-aware routing, problems in a specific AZ can be masked by healthy aggregated metrics. Per-AZ SLOs are mandatory to detect localized degradation before it escalates to total failure.
Treating zone-aware routing as a substitute for session affinity. The routing prioritizes zone locality, not client or session affinity. Services requiring sticky sessions should use Application Load Balancer with stickiness enabled, not rely on Service Connect locality behavior.

Well-Architected Lens: Zone-Aware Routing

security: Zone-aware routing does not alter the Service Connect security model. Mutual TLS between tasks (when configured) continues working regardless of zone routing. VPC Flow Logs with AZ metadata add network visibility without impact on the threat model.
reliability: Automatic failover between AZs when local endpoints fall below capacity threshold eliminates single-zone risk without manual configuration. Redistribution behavior needs to be documented in incident response runbooks with latency SLOs adjusted for the redistribution period.
performance: Reduction of 1-2ms per hop in synchronous chains of 6-8 hops improves p95 of the full chain. The gain is most significant during peak hours when cross-AZ latency variance increases. Envoy metrics per destination cluster are the correct instrument to measure impact.
cost: Elimination of ~66% of cross-AZ traffic under normal conditions (2 of 3 calls crossed zones before). For platforms with high internal call volume, monthly savings can be significant. Enabling VPC Flow Logs for monitoring adds cost, use custom format and S3 with partitioning to minimize it.

My Curation Note: I would enable this feature immediately on any existing ECS platform, the redeployment is trivial and the risk is minimal. What I would do before enabling it, however, is ensure I have per-AZ latency metrics already configured, because the real value of this feature only becomes visible when you can compare before and after with data. The lesson I have learned from years of cost optimization on financial platforms is that savings without instrumentation become technical debt: you do not know if it is working, you do not know when it stops working, and you cannot justify the investment in architecture reviews. Enable the feature, but instrument first.

Verdict: Enable, Instrument, Document

Zone-aware routing in ECS Service Connect is one of the most pragmatically valuable features of the year for teams operating microservices in production on AWS. It solves a real trade-off, cost vs. multi-AZ resilience, transparently, without code changes and without additional cost. For financial platforms with high service-to-service call volume, the cost and latency impact is measurable and immediate after redeployment. The recommendation is clear: enable on all existing ECS Service Connect services with a planned redeployment, enable VPC Flow Logs with custom format for validation, break latency metrics by AZ before enabling to have a comparative baseline, and document zone redistribution behavior in incident response runbooks. The only scenario where I would hesitate is for services with local in-memory state without a distributed session mechanism, in those cases, an impact analysis of redistribution behavior is required before activation.

References

Originally published at fernando.moretes.com. By Fernando F. Azevedo: Senior Solutions Architect.