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

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.

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.

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.

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?'.

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.