# Zone-Aware Routing no ECS Service Connect: O Fim do Trade-off Custo vs. Resiliência O ECS Service Connect ganhou roteamento zone-aware em julho de 2026, priorizando automaticamente endpoints na mesma AZ de origem sem código adicional. Para arquiteturas financeiras com alta frequência de chamadas serviço-a-serviço, isso muda o cálculo econômico de multi-AZ de forma significativa. Neste artigo, analiso o mecanismo, os trade-offs reais e como posicionar essa feature no contexto de plataformas de pagamento e dados em tempo real. - URL: https://fernando.moretes.com/blog/zone-aware-routing-no-ecs-service-connect-o-fim-do-trade-off-custo-vs--amazon-ecs-s - Markdown: https://fernando.moretes.com/blog/zone-aware-routing-no-ecs-service-connect-o-fim-do-trade-off-custo-vs--amazon-ecs-s/article.md?lang=pt - Published: 2026-07-24T09:03:18.598Z - Category: IA & Agentes - Tags: ECS, Service Connect, Zone-Aware Routing, Multi-AZ, FinTech, Cost Optimization, Resiliência, Microservices - Reading time: 10 min - Source: [Amazon ECS Service Connect now supports Zone-Aware routing](https://aws.amazon.com/about-aws/whats-new/2026/07/ecs-service-connect-zone-aware/) --- Por anos, arquitetar microserviços multi-AZ na AWS significava aceitar um custo silencioso: cada chamada serviço-a-serviço que cruzava uma zona de disponibilidade gerava cobrança de transferência de dados — tipicamente US$ 0,01/GB por direção. Em plataformas de pagamento ou sistemas de trading com dezenas de milhões de chamadas por hora, esse custo não é ruído; é linha de orçamento. A resposta canônica era concentrar serviços em menos AZs ou aceitar o custo como preço da resiliência. O ECS Service Connect com zone-aware routing, lançado em 23 de julho de 2026, elimina esse dilema na camada de roteamento — sem mudança de código, sem infraestrutura adicional. ## O Peso Econômico do Tráfego Cross-AZ - **$0.01** — Por GB por direção cross-AZ (us-east-1). Custo de transferência de dados entre AZs na mesma região — bidirecional significa $0.02/GB efetivo - **~1-2ms** — Latência adicional típica em chamadas cross-AZ. Pequena em isolamento, mas composta em cadeias de chamadas síncronas de 10+ saltos - **0** — Custo adicional do zone-aware routing. Feature habilitada por padrão sem cobrança adicional em todas as regiões comerciais e GovCloud - **1x** — Redeployment necessário para serviços existentes. Uma única reimplantação habilita o novo comportamento de roteamento — sem mudança de configuração ou código ## O Sinal: O Que Mudou no Mecanismo de Roteamento O ECS Service Connect opera como uma malha de serviço leve baseada em Envoy, injetando um proxy sidecar em cada tarefa e registrando endpoints em um namespace do AWS Cloud Map. Antes desta feature, o balanceamento de carga entre endpoints era agnóstico à topologia: uma tarefa na `us-east-1a` poderia rotear para réplicas em `us-east-1b` ou `us-east-1c` com igual probabilidade, dependendo apenas da saúde e do peso configurado. Com zone-aware routing, o proxy Envoy de cada tarefa recebe metadados de zona e passa a **priorizar endpoints na mesma AZ** com um peso dinâmico. O mecanismo não é um roteamento estático 100% local — é um algoritmo de peso que ajusta conforme a capacidade disponível localmente. Se a AZ local tem endpoints suficientes e saudáveis para absorver a carga, o tráfego permanece local. Se os endpoints locais ficam abaixo de um limiar de capacidade ou se tornam não saudáveis, o algoritmo redistribui automaticamente para AZs vizinhas, sem intervenção manual e sem overloading de uma zona específica. Esse comportamento espelha o que o Kubernetes implementa com `topologyAwareHints` no EndpointSlice (GA no Kubernetes 1.27) e o que o ALB faz com `routing.http.desync_mitigation_mode` e target group cross-zone load balancing desabilitado. A diferença é que no ECS Service Connect isso é transparente — não requer anotações, não requer configuração de hints, e funciona com o Service Connect DNS nativo sem mudança no código da aplicação. ## Zone-Aware Routing: Fluxo de Tráfego e Failover Tráfego serviço-a-serviço dentro de um cluster ECS multi-AZ. Setas sólidas = caminho preferencial (mesma AZ). Setas tracejadas = failover automático quando endpoints locais ficam abaixo do limiar de capacidade. ### 🟦 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) ### Fluxos - caller_a -> envoy_a: chamada sainte - envoy_a -> payment_a: preferencial (mesma AZ) - envoy_a -> payment_b: failover cross-AZ - envoy_a -> payment_c: failover cross-AZ - caller_b -> envoy_b: chamada sainte - envoy_b -> payment_b: preferencial (mesma AZ) - envoy_b -> payment_a: failover cross-AZ - cloudmap -> envoy_a: endpoints + zona - cloudmap -> envoy_b: endpoints + zona - envoy_a -> flowlogs: métricas de tráfego ## O Que Muda Para Arquitetos de Plataforma - **O modelo de custo multi-AZ muda estruturalmente.** Serviços com alta taxa de chamadas síncronas (ex: 50k req/s em um gateway de pagamentos) que antes geravam GB/hora de tráfego cross-AZ agora mantêm esse tráfego local por padrão. O saving não é marginal — em plataformas com dezenas de microserviços, pode representar centenas de dólares por dia. - **A decisão de desabilitar cross-zone load balancing em ALBs fica mais simples.** Antes, desabilitar cross-zone no ALB para economizar custo criava risco de desbalanceamento se as AZs tivessem capacidade assimétrica. Com zone-aware routing no Service Connect cobrindo o tráfego east-west, o risco se concentra apenas no tráfego north-south — escopo muito mais controlável. - **Observabilidade de zona vira requisito de primeiro nível.** VPC Flow Logs com metadados de AZ agora é o mecanismo recomendado para validar efetividade do roteamento. Isso significa que equipes que não tinham Flow Logs habilitados precisam ativá-los — com impacto em custo de CloudWatch Logs Insights e armazenamento S3. - **O failover automático de zona exige revisão de SLOs de latência.** Quando uma AZ perde capacidade e o tráfego redistribui, a latência p99 vai subir temporariamente. Equipes que definiram SLOs apertados (ex: p99 < 50ms) precisam modelar o comportamento de degradação durante redistribuição e ajustar alertas para distinguir degradação esperada de incidente real. - **Serviços stateful com afinidade de sessão precisam de análise cuidadosa.** Zone-aware routing prioriza localidade, mas não garante afinidade de sessão. Serviços que mantêm estado em memória local (ex: caches de sessão sem Redis) podem ver comportamento inesperado durante redistribuição de carga — o roteamento muda, a sessão não segue. ## Posicionamento em Arquiteturas Financeiras de Alta Frequência Em plataformas de pagamento que opero ou reviso como referência, o padrão típico é um gateway de entrada (ALB ou API Gateway) distribuindo para um serviço de orquestração, que por sua vez chama serviços de autorização, antifraude, ledger e notificação em sequência ou paralelo. Com 3 AZs e 10 tarefas por serviço (aproximadamente 3-4 por AZ), o tráfego cross-AZ antes do zone-aware routing era estatisticamente ~66% das chamadas — duas em cada três chamadas cruzavam uma zona. Com zone-aware routing, esse número cai para próximo de zero em condições normais. Para uma plataforma processando 100 GB/hora de payload em chamadas internas (não incomum em sistemas de liquidação com mensagens de 1-5 KB e 50k req/s), a economia direta é ~US$ 48/hora em transferência cross-AZ eliminada — aproximadamente US$ 35k/mês. Não é o maior item de custo em uma plataforma enterprise, mas é um saving que não exige nenhuma mudança de arquitetura. Mais importante do que o custo, porém, é o impacto na latência composta. Em cadeias de chamadas síncronas com 6-8 saltos (padrão em sistemas de pagamento com separação de responsabilidades), cada 1-2ms de latência cross-AZ se multiplica. Reduzir isso para latência intra-AZ (~0.3ms) em condições normais melhora o p95 da cadeia completa de forma mensurável — especialmente em horários de pico onde a variância de latência aumenta. A ressalva importante para ambientes financeiros é a **assimetria de capacidade entre AZs durante eventos de escalonamento**. Se o autoscaling reagir mais rápido em uma AZ do que nas outras (o que acontece quando os triggers de CPU/memória disparam em momentos ligeiramente diferentes), a AZ com mais capacidade vai receber mais tráfego local — e a AZ com menos capacidade vai redistribuir para as vizinhas. Esse comportamento é correto e esperado, mas precisa estar modelado nos runbooks de resposta a incidentes. ## Observabilidade: VPC Flow Logs Não São Suficientes Sozinhos O anúncio recomenda VPC Flow Logs com metadados de AZ para validar a efetividade do roteamento. Isso é um ponto de partida necessário, mas insuficiente para ambientes de produção financeira. Flow Logs operam no nível de rede — eles confirmam que o tráfego está fluindo dentro da AZ, mas não correlacionam com latência de aplicação, taxa de erro ou comportamento de retry. Para uma stack de observabilidade completa, eu adiciono três camadas sobre os Flow Logs. Primeiro, **métricas do Envoy expostas via ECS Service Connect**: o proxy Envoy já coleta `upstream_cx_total`, `upstream_rq_retry`, e histogramas de latência por cluster de destino. Com o ECS Container Insights habilitado e um exportador de métricas Envoy (ou via AWS Distro for OpenTelemetry), essas métricas chegam ao CloudWatch ou Datadog com granularidade de AZ. Segundo, **traces distribuídos com propagação de contexto de zona**: ao adicionar o atributo `az.id` ao span de cada chamada (via OpenTelemetry SDK), é possível construir heatmaps de latência por par de AZs origem-destino no X-Ray ou Datadog APM — isso torna visível exatamente quando e quanto tráfego cross-AZ ainda ocorre (durante failovers). Terceiro, **alarmes de redistribuição de zona**: um alarme CloudWatch composto que detecta simultaneamente queda de endpoints saudáveis em uma AZ E aumento de latência p99 no serviço destino é um sinal confiável de que redistribuição está ativa — e permite distinguir degradação esperada de falha real. O custo de Flow Logs em ambientes de alta frequência não é trivial. Para 50k req/s com payloads de 1 KB, o volume de logs de fluxo pode chegar a 10-20 GB/hora. Recomendo usar **VPC Flow Logs com formato personalizado** incluindo apenas os campos necessários (`srcaddr`, `dstaddr`, `az-id`, `bytes`, `start`, `end`) e direcionar para S3 com particionamento por hora e AZ — o que reduz custo de armazenamento e viabiliza queries Athena eficientes sem passar pelo CloudWatch Logs. ## Failure Modes Reais e Como Mitigá-los Zone-aware routing resolve um problema real, mas introduz três failure modes que precisam estar no radar de qualquer arquiteto sério. **1. AZ Imbalance Amplificado por Autoscaling Assimétrico.** Se o autoscaling de um serviço downstream escala uma AZ mais rápido que as outras (cenário comum quando métricas de CPU têm janelas de avaliação de 1 minuto e as tarefas não escalam exatamente ao mesmo tempo), a AZ com mais tarefas recebe mais tráfego local — o que aumenta sua carga e pode disparar mais scaling, enquanto as AZs com menos tarefas ficam subutilizadas. O antídoto é configurar **target tracking scaling com métricas de ALB RequestCountPerTarget** em vez de CPU, e garantir que o `minHealthyPercent` e `maximumPercent` do deployment estejam calibrados para manter pelo menos 1 tarefa por AZ durante deploys. **2. Thundering Herd Durante Recuperação de AZ.** Quando uma AZ se recupera após uma falha (endpoints voltam a ficar saudáveis), o Envoy começa a redistribuir tráfego de volta para ela. Se a recuperação for abrupta (todos os endpoints voltam ao mesmo tempo), pode haver um spike de tráfego para a AZ recém-recuperada antes que ela esteja totalmente aquecida — especialmente problemático para serviços com JVM que precisam de JIT warmup. A mitigação é usar **slow start mode** no Envoy (configurável via ECS Service Connect task definition) com uma janela de 30-60 segundos, aumentando gradualmente o peso dos endpoints recém-saudáveis. **3. Invisibilidade de Redistribuição em Dashboards Agregados.** Métricas de latência e erro agregadas por serviço mascaram redistribuições de zona. Uma AZ sobrecarregada com p99 de 200ms pode ser invisível se as outras duas AZs têm p99 de 20ms — a média agregada fica em ~80ms, abaixo de qualquer alarme. A solução é obrigatoriamente quebrar métricas por dimensão de AZ no CloudWatch (usando `AvailabilityZone` como dimensão nos custom metrics) e definir SLOs por AZ, não apenas por serviço. ## Posicionamento Estratégico: ECS Service Connect vs. App Mesh vs. EKS Topology Hints Esta feature fecha uma lacuna competitiva importante entre ECS Service Connect e as alternativas de malha de serviço. O AWS App Mesh (agora em modo de manutenção, com migração recomendada para Service Connect) nunca teve zone-aware routing nativo. O Istio no EKS tem `localityLbSetting` com prioridades de failover configuráveis há anos. O Kubernetes nativo tem `topologyAwareHints` no EndpointSlice desde 1.21 (beta) e 1.27 (GA). O ECS Service Connect estava atrás nessa dimensão específica — e agora alcança paridade funcional, com a vantagem de ser zero-config. Para equipes que estão avaliando ECS vs. EKS para novas plataformas, este lançamento remove um argumento a favor de EKS. A pergunta relevante não é mais 'EKS tem zone-aware e ECS não tem' — é 'qual o custo operacional de gerenciar um cluster Kubernetes vs. usar ECS com Fargate e Service Connect?' Para a maioria das plataformas financeiras que não precisam de customização profunda do scheduler ou de operadores Kubernetes específicos, ECS com Service Connect agora oferece um conjunto de features comparável com significativamente menos overhead operacional. A ressalva é que ECS Service Connect ainda não expõe controles granulares de failover de localidade como o Istio faz. No Istio, é possível definir prioridades explícitas (mesma AZ = prioridade 0, mesma região = prioridade 1, outra região = prioridade 2) com percentuais de spillover configuráveis. No ECS Service Connect, o algoritmo é gerenciado pela AWS — o que é ótimo para simplicidade operacional, mas pode ser limitante para cenários onde você precisa de controle fino sobre o comportamento de degradação. Para esses casos, App Mesh (enquanto ainda suportado) ou Istio no EKS continuam sendo a escolha mais adequada. > **O Verdadeiro Valor Não É o Custo — É a Eliminação do Trade-off:** Antes desta feature, arquitetos de plataforma precisavam fazer uma escolha explícita: aceitar custo cross-AZ como preço da resiliência, ou reduzir resiliência concentrando serviços em menos AZs. Esse trade-off aparecia em ADRs, em revisões de custo e em discussões de capacity planning. Zone-aware routing não apenas reduz custo — ele remove uma decisão arquitetural recorrente da equipe. O valor de longo prazo está na simplificação do espaço de decisão: equipes podem agora distribuir serviços em 3 AZs sem penalidade econômica, o que é a decisão correta de resiliência em quase todos os casos. ## Anti-Padrões a Evitar com Zone-Aware Routing - **Assumir que 'zero cross-AZ' é garantido em produção.** O roteamento é preferencial, não absoluto. Durante scaling events, deploys e falhas de AZ, tráfego cross-AZ ocorre e é esperado. Dimensionar custos assumindo 100% de localidade é um erro de planejamento. - **Desabilitar Flow Logs para economizar custo após ativar zone-aware routing.** Flow Logs são o único mecanismo nativo para validar que o roteamento está funcionando como esperado. Desabilitá-los cria um ponto cego crítico — especialmente durante os primeiros 30 dias após a ativação. - **Ignorar o redeployment necessário para serviços existentes.** O anúncio é claro: serviços existentes precisam de uma reimplantação para ativar o novo comportamento. Equipes que não fizerem isso continuarão com roteamento agnóstico de zona e não verão os benefícios — nem saberão que não estão vendo. - **Usar métricas agregadas de serviço como único SLO.** Com zone-aware routing, problemas em uma AZ específica podem ser mascarados por métricas agregadas saudáveis. SLOs por AZ são obrigatórios para detectar degradação localizada antes que ela escale para falha total. - **Tratar zone-aware routing como substituto de session affinity.** O roteamento prioriza localidade de zona, não afinidade de cliente ou sessão. Serviços que precisam de sticky sessions devem usar Application Load Balancer com stickiness habilitado — não depender do comportamento de localidade do Service Connect. ## Lente Well-Architected: Zone-Aware Routing - **security**: Zone-aware routing não altera o modelo de segurança do Service Connect. TLS mútuo entre tarefas (quando configurado) continua funcionando independentemente do roteamento de zona. VPC Flow Logs com metadados de AZ adicionam visibilidade de rede sem impacto no modelo de ameaças. - **reliability**: Failover automático entre AZs quando endpoints locais ficam abaixo do limiar de capacidade elimina o risco de zona única sem configuração manual. O comportamento de redistribuição precisa estar documentado nos runbooks de resposta a incidentes com SLOs de latência ajustados para o período de redistribuição. - **performance**: Redução de 1-2ms por salto em cadeias síncronas de 6-8 hops melhora p95 da cadeia completa. O ganho é mais significativo em horários de pico onde a variância de latência cross-AZ aumenta. Métricas Envoy por cluster de destino são o instrumento correto para medir o impacto. - **cost**: Eliminação de ~66% do tráfego cross-AZ em condições normais (2 de 3 chamadas cruzavam zona antes). Para plataformas com alto volume de chamadas internas, o saving mensal pode ser significativo. Habilitar VPC Flow Logs para monitoramento adiciona custo — usar formato customizado e S3 com particionamento para minimizá-lo. > **Minha Nota de Curadoria:** Eu ativaria essa feature imediatamente em qualquer plataforma ECS existente — o redeployment é trivial e o risco é mínimo. O que eu faria antes de ativar, porém, é garantir que tenho métricas de latência por AZ já configuradas, porque o valor real dessa feature só fica visível quando você consegue comparar o antes e o depois com dados. A lição que aprendi em anos de otimização de custo em plataformas financeiras é que savings sem instrumentação viram dívida técnica: você não sabe se está funcionando, não sabe quando para de funcionar, e não consegue justificar o investimento em revisões de arquitetura. Habilite a feature, mas instrumente primeiro. ## Veredicto: Ative, Instrumente, Documente Zone-aware routing no ECS Service Connect é uma das features mais pragmaticamente valiosas do ano para equipes que operam microserviços em produção na AWS. Ela resolve um trade-off real — custo vs. resiliência multi-AZ — de forma transparente, sem mudança de código e sem custo adicional. Para plataformas financeiras com alto volume de chamadas serviço-a-serviço, o impacto em custo e latência é mensurável e imediato após o redeployment. A recomendação é clara: ative em todos os serviços ECS Service Connect existentes com um redeployment planejado, habilite VPC Flow Logs com formato customizado para validação, quebre métricas de latência por AZ antes de ativar para ter baseline comparativo, e documente o comportamento de redistribuição de zona nos runbooks de resposta a incidentes. O único cenário onde eu hesitaria é em serviços com estado em memória local sem mecanismo de sessão distribuída — nesses casos, uma análise de impacto do comportamento de redistribuição é necessária antes da ativação. ## Referências - [AWS What's New: Amazon ECS Service Connect now supports Zone-Aware routing](https://aws.amazon.com/about-aws/whats-new/2026/07/ecs-service-connect-zone-aware/) - [AWS Containers Blog: Announcing zone-aware routing in Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/announcing-zone-aware-routing-in-amazon-ecs-service-connect/) - [Classmethod: I tried the new Zone-Aware Routing feature of ECS Service Connect](https://dev.classmethod.jp/en/articles/ecs-service-connect-zone-aware-routing/) - [AWS ECS Service Connect Documentation](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-connect.html) - [Kubernetes: Topology Aware Routing (EndpointSlice Hints)](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/) - [AWS VPC Flow Logs with AZ Metadata](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) - [AWS Well-Architected Framework: Reliability Pillar](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)