# Amazon Connect ativo-ativo: a lição de resiliência

A novidade de 31 de agosto de 2026 muda o modelo mental: duas regiões do Amazon Connect podem receber contatos e agentes de forma ativa, com visão operacional unificada. Eu leio isso menos como uma função de failover e mais como uma correção de uma fragilidade clássica: o standby que ninguém exercita até o dia em que precisa dele.

- URL: https://fernando.moretes.com/blog/amazon-connect-ativo-ativo-a-licao-de-resiliencia-amazon-conne

- Markdown: https://fernando.moretes.com/blog/amazon-connect-ativo-ativo-a-licao-de-resiliencia-amazon-conne/article.md?lang=pt

- Published: 2026-09-01T20:27:37.039Z

- Category: IA & Agentes

- Tags: Amazon Connect, Resilience, DR, Contact Center, Well-Architected, Operations, Financial Services

- Reading time: 7 min

- Source: [Amazon Connect Global Resiliency now supports cross-region routing of contacts across two active AWS regions](https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-connect-global-resiliency-cross-region-routing/)

---

Quando um contact center financeiro falha, o incidente raramente aparece como uma exceção elegante em um log. Ele aparece como clientes bloqueados na URA, agentes autenticados no lugar errado, filas acumulando sem dono claro, integrações de CRM respondendo de uma região e fluxos de voz esperando outra. O anúncio de que o Amazon Connect Global Resiliency agora suporta roteamento de contatos para agentes em duas regiões ativas ataca exatamente esse ponto. Para mim, o valor principal não é dizer que existe uma segunda região. É fazer com que a segunda região trabalhe todos os dias, receba agentes, receba contatos, produza métricas e revele divergências antes do incidente.

## O que realmente mudou

Em 31 de agosto de 2026, a AWS anunciou que o Amazon Connect Global Resiliency passou a suportar roteamento entre regiões de contatos para agentes em duas regiões vinculadas. O exemplo publicado é simples: um contato que entra em US East (N. Virginia) pode ser oferecido ao agente compatível que está há mais tempo disponível, independentemente de esse agente estar em US East ou US West (Oregon). A mesma ideia se aplica aos pares regionais documentados: N. Virginia/Oregon, Frankfurt/London e Osaka/Tokyo.

A mudança é operacionalmente importante porque tira a arquitetura do desenho passivo. Antes, muitos desenhos de DR para contact center dependiam de uma réplica, de números associados a um Traffic Distribution Group e de runbooks para deslocar tráfego. Isso continua existindo, mas o ponto novo é que as duas regiões deixam de ser uma promessa. Elas passam a exercer configuração, autenticação, roteamento, integrações, métricas e busca de contatos como parte da rotina.

Eu trataria essa capacidade como uma evolução de maturidade, não como licença para relaxar engenharia. Ativo-ativo aumenta confiança, mas também aumenta superfície de falha. Tudo que antes podia ficar escondido na região secundária agora aparece em produção: cotas assimétricas, Lambdas com nomes diferentes, fluxos com ARNs fixos, permissões IAM incompletas, integrações SaaS sem allowlist regional e painéis que agregam sem explicar origem.

## Linha do tempo de um incidente que agora fica mais visível

1. **T-30 dias: a réplica existe, mas não é exercitada** — A equipe cria a segunda instância, replica a configuração principal e acredita que o runbook cobre a troca. As cotas, integrações e caminhos de autenticação ainda não foram submetidos ao mesmo volume real.

2. **T-5 dias: uma mudança pequena cria divergência** — Um fluxo passa a chamar uma Lambda nova, mas a função equivalente não existe com o mesmo nome na outra região. Em operação passiva, isso pode ficar invisível até o teste de DR.

3. **T-0: aumento de contatos força redistribuição** — A operação tenta mover novos contatos e agentes para absorver a carga. Se as duas regiões já carregam tráfego, a falha provável vira degradação controlada. Se uma delas nunca recebeu tráfego real, a troca vira experimento em produção.

4. **T+15 minutos: o problema deixa de ser telefonia pura** — A fila pode estar saudável, mas o CRM, o IdP, a gravação, o Lex bot, o enriquecimento por API Gateway ou a escrita analítica podem não estar. A investigação precisa olhar contato, agente, região ativa, integração e quota no mesmo recorte.

> **Causa raiz típica:** A causa raiz não é 'a região caiu'. Em muitos incidentes de continuidade, a causa raiz é a diferença não testada entre o ambiente que atende todos os dias e o ambiente que só existe para salvar o dia. Roteamento ativo-ativo reduz essa diferença, mas só quando configuração, cotas, IAM, identidade, integrações, alarmes e runbooks são tratados como produto, não como artefato de DR.

## Modelo operacional ativo-ativo para Amazon Connect Global Resiliency

A ideia central é separar distribuição de tráfego, distribuição de agentes e isolamento operacional. O desenho abaixo mostra onde eu colocaria os controles que evitam transformar uma mudança regional em incidente.

### 👤 Clientes e agentes

- Cliente voz/chat (user)
- Agente global sign-in (user)

### 🟧 Plano global do Connect

- Traffic Distribution Group 10% increments (network)
- Cross-region routing longest-available match (compute)
- Isolamento controlado UpdateCrossRegionRouting (security)

### 🟦 Região A

- Amazon Connect A fluxos, filas, CCP (compute)
- Integrações A Lambda/API/CRM (compute)

### 🟩 Região B

- Amazon Connect B config equivalente (compute)
- Integrações B mesmos nomes e políticas (compute)

### 📊 Operação

- Métricas e busca visão consolidada (data)
- Service Quotas por região e instância (security)

### Fluxos

- customer -> tdg: entra por número global
- tdg -> connect-a: parcela de tráfego
- tdg -> connect-b: parcela de tráfego
- agent -> routing: disponibilidade do agente
- routing -> connect-a: oferta regional
- routing -> connect-b: oferta entre regiões
- connect-a -> int-a: invoca fluxos e APIs
- connect-b -> int-b: invoca fluxos e APIs
- connect-a -> obs: eventos e contatos
- connect-b -> obs: eventos e contatos
- quotas -> isolation: limiar operacional
- isolation -> routing: desabilita roteamento cruzado

## A remediação começa antes do failover

A primeira mudança que eu faria em uma operação crítica é transformar a região secundária em caminho ordinário, mesmo que com baixa participação inicial. O Global Resiliency permite distribuir tráfego e agentes entre regiões em incrementos de 10%, ou mover tudo de uma vez. Eu começaria com uma fatia pequena e deliberada, por exemplo 10% dos novos contatos em uma fila de menor risco e um grupo de agentes treinado para operar nos dois lados. A meta não é balanceamento perfeito no primeiro dia; é descobrir divergência com impacto controlado.

Essa escolha tem custo e disciplina. Se as duas regiões carregam tráfego, as duas precisam de cotas equivalentes, alarmes úteis, pipelines de configuração, testes de fluxo e integração com identidade. A documentação é explícita em alguns pontos que eu não trataria como detalhe: a instância precisa estar em regiões suportadas, o acesso ao recurso exige contato com a equipe AWS, e a AWS recomenda testes mensais de failover. Também há uma exigência prática forte: para fluxos que chamam Lambda, os nomes das funções devem ser consistentes entre regiões, e ARNs hardcoded precisam sair do caminho sempre que o parâmetro regional for suportado.

Em ambiente financeiro, eu ainda adicionaria uma esteira de validação pós-deploy. Depois de qualquer alteração em fila, routing profile, security profile, flow, Lex bot, Lambda ou integração externa, um canário deveria executar uma jornada mínima em ambas as regiões: entrada, roteamento, enriquecimento, gravação, pós-atendimento e evento analítico.

## O ponto frágil deixa de ser só voz

A maior armadilha nesse tipo de arquitetura é achar que resiliência do contact center termina quando o contato encontra um agente. Na prática, o atendimento depende de uma cadeia que inclui SAML, CCP/Agent Workspace, CRM, APIs internas, bases de perfil, gravação, transcrição, classificação, antifraude, auditoria e, em alguns casos, jornada conversacional com Lex ou agentes de IA. O Amazon Connect pode rotear o contato corretamente, mas a experiência falha se o agente recebe uma tela vazia ou se a consulta de elegibilidade fica presa em uma API regional.

Por isso eu desenharia as integrações com contratos explícitos de região. Um Lambda chamado pelo flow deve ter o mesmo nome nas duas regiões quando isso for exigido pelo padrão de Global Resiliency. As permissões IAM devem restringir por `aws:RequestedRegion`, `connect:InstanceId` quando aplicável, e recursos nomeados por ambiente, não por improviso. Para APIs próprias atrás de API Gateway, eu usaria idempotency keys baseadas em `contactId`, `initialContactId` e etapa lógica, gravadas em DynamoDB com TTL para evitar cobranças duplicadas em retries ou reofertas.

Também separaria estado operacional de estado analítico. O que é necessário para atender o cliente precisa estar disponível no caminho quente, com latência previsível. O que é necessário para auditoria pode ir por EventBridge, Kinesis ou Firehose para S3 com replicação e reconciliação posterior. Misturar os dois caminhos aumenta acoplamento exatamente durante a falha.

## Observabilidade para o momento em que tudo parece verde

A novidade de visibilidade unificada de analytics e busca de contatos entre regiões é relevante, mas eu não deixaria a operação depender apenas de painéis agregados. Painel agregado é ótimo para gerência; investigação de incidente precisa de recorte por origem, região ativa, fila, perfil de roteamento, fluxo, integração e quota. O próprio modelo de Global Resiliency traz metadados como região de origem, região ativa e Traffic Distribution Group em estruturas de contato, e eu usaria isso como dimensão de telemetria desde o começo.

Meus sinais mínimos seriam: taxa de contatos roteados entre regiões, tempo em fila por região ativa, taxa de erro por bloco de flow, latência p95/p99 das Lambdas chamadas por fluxo, falhas de autenticação SAML, contatos em after-contact work durante mudança de região, throttling de APIs do Connect, utilização de cotas por instância e diferença de capacidade aplicada entre regiões. Em CloudWatch, alarmes de quota não devem esperar 100%; eu normalmente começo em 70% para tendência e 80% para ação, ajustando por criticidade e sazonalidade.

Também gosto de criar eventos operacionais explícitos para mudanças de distribuição: quem mudou, de quanto para quanto, ticket, motivo, janela, rollback esperado e resultado observado 15 e 60 minutos depois. Isso pode ir para EventBridge e para um bucket S3 imutável com Object Lock quando a organização exige trilha de auditoria mais forte. Em incidentes sérios, a pergunta não é só 'voltou?'. É 'sabemos exatamente o que foi deslocado, por quem e com qual efeito?'.

## Capacidade: a conta que aparece depois

Em contact center, capacidade não é apenas concorrência de chamadas. É limite de usuários, filas, perfis, fluxos, números, APIs por segundo, integrações, gravação, armazenamento e limites de terceiros. Um desenho ativo-ativo mal calibrado pode falhar de forma contraintuitiva: a região B recebe apenas 10% do tráfego por meses, mas em uma manhã precisa absorver 100%. Se as cotas de B não foram elevadas no mesmo ritmo de A, o failover funciona no plano de roteamento e falha no plano de capacidade.

A documentação de requisitos do Global Resiliency orienta solicitar que todas as cotas da réplica correspondam às cotas da origem. Um artigo recente da AWS sobre quotas reforça um ponto que considero crítico: solicitações de Service Quotas são regionais e, depois da replicação inicial, aumentos precisam ser mantidos em sincronia por região. Esse é um bom exemplo de dívida operacional invisível. A equipe aumenta capacidade no lado que está sofrendo pressão diária e esquece o outro lado porque ele parece calmo.

Eu resolveria isso com automação declarativa: inventário diário de cotas aplicadas por instância e região, diff automático, alerta quando a diferença passar de zero para recursos críticos e bloqueio de mudança quando uma distribuição planejada exceder a capacidade estimada. A regra prática é simples: se a região B precisa receber 100% amanhã, ela deve ser medida como capaz de receber 100% hoje.

## Leitura Well-Architected

- **security**: Global sign-in e integrações regionais precisam de IAM mínimo, SAML bem governado, KMS consistente para gravações e dados analíticos, e trilha auditável para mudanças de distribuição ou isolamento.
- **reliability**: O ganho real vem de exercitar continuamente as duas regiões, validar failover mensalmente, eliminar configuração hardcoded e manter cotas simétricas. Eu definiria RTO/RPO por jornada de atendimento, não apenas por instância do Connect.

## Antipadrões que eu removeria do desenho

- Réplica regional criada uma vez e nunca mais validada com tráfego real.
- Fluxos com ARNs fixos de Lambda, Lex ou recursos regionais sem estratégia de substituição.
- Cotas aumentadas apenas na região primária porque é nela que a dor aparece primeiro.
- Dashboards globais sem drill-down por região ativa, região de origem e Traffic Distribution Group.
- Runbook de failover que depende de um único administrador, uma única sessão de console ou um único endpoint regional.

> **Minha nota de curadoria:** Eu não colocaria um contact center regulado em ativo-ativo no primeiro fim de semana. Eu começaria por filas controladas, mediria erros por região e só aumentaria a distribuição depois que cotas, identidade, fluxos e integrações passassem por testes repetidos. A lição que aprendi em ambientes críticos é que DR não falha no diagrama; falha no detalhe que ninguém exercitou sob carga. Esta novidade é valiosa justamente porque força esse detalhe a aparecer mais cedo.

## Referências

- [AWS What's New: Amazon Connect Global Resiliency cross-region routing](https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-connect-global-resiliency-cross-region-routing/)
- [Amazon Connect Administrator Guide: Set up Connect Customer Global Resiliency](https://docs.aws.amazon.com/connect/latest/adminguide/setup-connect-global-resiliency.html)
- [Amazon Connect Administrator Guide: Get started with Global Resiliency](https://docs.aws.amazon.com/us_en/connect/latest/adminguide/get-started-connect-global-resiliency.html)
- [Amazon Connect Administrator Guide: Global Resiliency requirements](https://docs.aws.amazon.com/connect/latest/adminguide/connect-global-resiliency-requirements.html)
- [AWS Contact Center Blog: Scale your contact center with Service Quotas](https://aws.amazon.com/blogs/contact-center/scale-your-contact-center-effectively-with-amazon-connect-and-service-quotas/)
- [AWS Contact Center Blog: Amazon Connect Service Quota Monitor](https://aws.amazon.com/blogs/contact-center/amazon-connect-service-quota-monitor/)
- [Amazon Connect Streams: Global Resiliency documentation](https://github.com/amazon-connect/amazon-connect-streams/blob/master/Documentation-GR.md)

## Veredito

Minha recomendação é tratar o roteamento entre regiões do Amazon Connect Global Resiliency como um programa operacional, não como uma chave de DR. Use tráfego real em ambas as regiões, comece pequeno, mantenha cotas e integrações em paridade, registre cada mudança de distribuição e teste isolamento antes de precisar dele. Para organizações financeiras, essa é a diferença entre um failover que parece bonito em apresentação e uma operação que continua atendendo clientes quando a infraestrutura deixa de colaborar.

**Rating:** recommended-with-operational-discipline