Como o Colab reconstruiu a observabilidade com CloudWatch, X-Ray e Kiro para quase triplicar a capacidade

Se você é quem configura alarme, lê trace e decide taxa de amostragem no CloudWatch no dia a dia, este caso serve de referência de arquitetura completa: do RUM no navegador do cidadão até o lock no banco de dados. É o que o Colab, GovTech que conecta cidadãos a prefeituras brasileiras, construiu a partir de março de 2026 para sair do monitoramento reativo.

O problema não é tráfego alto, é tráfego imprevisível

E-commerce tem Black Friday. Rede social tem viral. Serviço público municipal tem outro padrão de pico, e ele muda de cidade para cidade:

• Rematrícula escolar e orçamento participativo derrubam portal e canal de mensageria ao mesmo tempo.
• Vencimento de IPTU sobrecarrega a API de emissão de guias por alguns dias no mês.
• Chuva forte ou emergência urbana gera pico instantâneo de chamados de zeladoria no app.

Com 7 aplicações críticas na AWS atendendo dezenas de prefeituras, cada uma com sazonalidade própria, um limiar genérico de CPU ou latência não serve. O Colab precisava de observabilidade que soubesse diferenciar o pico normal da cidade A do incidente real na cidade B.

A arquitetura, do clique do cidadão ao lock no banco

A stack foi desenhada para cobrir a requisição inteira, em camadas:

1. O cidadão abre o portal (inclusive dentro de iframes em sites de prefeitura) ou o app nativo iOS/Android. O CloudWatch RUM captura erro de navegação, latência de carregamento e falha por dispositivo ou navegador, via snippet JavaScript no web e SDK de RUM no mobile.
2. A requisição entra nas 7 aplicações. O AWS X-Ray gera o trace distribuído e o Amazon CloudWatch Application Signals monta o Service Map, isolando qual microsserviço ou chamada de API está lento.
3. Os spans do X-Ray são consolidados no CloudWatch Transaction Search, que junta tracing e métricas num lugar só em vez de exigir uma ferramenta separada de APM.
4. A camada de dados é monitorada por serviço: CloudWatch Database Insights cobre Amazon RDS e Amazon Aurora, observando query lenta, contenção de conexão e deadlock; o Amazon DocumentDB usa Performance Insights para identificar as queries de maior impacto.
5. Em cima de tudo isso, SLOs e SLIs customizados por serviço e por prefeitura, configurados no Application Signals, disparam alarme no Slack da engenharia quando a taxa de sucesso cai abaixo de 99%.

Em resumo: é a pilha nativa de observabilidade da AWS cobrindo front-end, tracing distribuído e banco, com o SLO fazendo o papel que normalmente cabe a uma ferramenta de terceiro.

O alarme que valeu a arquitetura inteira

O teste de verdade veio quando um alarme do CloudWatch, alimentado pelo trace do X-Ray, apontou gargalo de memória e contenção de processamento num dos microsserviços mais críticos: a API de gerenciamento de cache.

O Service Map mostrou a causa raiz: a abstração de cache do pacote cache-manager do NestJS, conectada ao Redis, não aguentava a carga. O diagnóstico técnico era claro, e é um trade-off clássico de Performance Efficiency: trocar a camada abstrata pela biblioteca nativa io-redis, abrindo mão de portabilidade de driver em troca de desempenho sob carga real.

O problema é que essa troca não é cosmética. Ela exigia refatorar mais de 96 arquivos de código, com estimativa de 48 horas contínuas de trabalho manual e risco real de regressão em prefeituras já em produção.

Kiro: da refatoração de 48 horas à validação de 2 horas

Para não travar o time nem a operação, o Colab usou o Kiro, serviço agêntico de desenvolvimento da AWS disponível como IDE, CLI e agente web autônomo. Alimentado com o diagnóstico exato que o X-Ray já tinha produzido, o agente reescreveu a lógica de conexão de cache, aplicando a troca de cache-manager para io-redis nos mais de 96 arquivos, preservando as regras de negócio.

O time de engenharia revisou e validou o código gerado em duas horas, não em 48. Segundo Felipe Emerenciano, CTO do Colab, o ganho não foi só de tempo:

A gestão de serviços públicos digitais exige disponibilidade crítica e precisão contínua. A adoção das ferramentas de observabilidade da AWS nos deu uma visão proativa sem precedentes.

Felipe Emerenciano, CTO do Colab

O resultado da refatoração: 180% de melhoria no desempenho de CPU dos servidores, ou seja, a mesma infraestrutura passou a suportar cerca de 2,8 vezes mais requisições sob a mesma carga de CPU, e nenhum cidadão sentiu indisponibilidade, porque a correção foi preventiva.

Vale nomear o trade-off aqui, porque ele é o ponto mais discutível do case: confiar refatoração em massa a um agente de IA é trocar tempo de engenharia por tempo de revisão humana. Funcionou porque o diagnóstico vinha de dado real de produção (trace do X-Ray), não de suposição, e porque a validação humana continuou no caminho crítico antes do deploy. É Operational Excellence com humano no loop, não automação cega.

Os números que sustentam o caso

O trade-off de custo: amostragem em vez de capturar tudo

Quem opera CloudWatch sabe que tracing completo custa caro e gera ruído. O Colab resolveu isso com taxa de amostragem definida por serviço: 5% no AWS X-Ray e 10% no CloudWatch RUM.

Na prática, isso significa cobrir cerca de 700 milhões de requisições por mês no X-Ray (volume consolidado de todos os clientes num mês de pico), das quais 5% viram trace gravado, cerca de 35 milhões por mês. No RUM, são 30 milhões de navegações monitoradas por mês. Some o monitoramento de banco de dados, e o custo estimado fica em torno de USD 200 por mês, segundo a tabela de preços do Amazon CloudWatch.

É um trade-off explícito entre Cost Optimization e Operational Excellence: amostra menor reduz custo e volume de dado, mas também reduz a chance de capturar o trace exato do incidente raro. O Colab escolheu consolidar tudo no CloudWatch em vez de manter ferramenta de terceiro, o que simplifica orçamento (uma fatura, não várias), mas também significa dependência maior da stack nativa da AWS para qualquer evolução futura de observabilidade.

O que fica em aberto

O material da AWS não detalha como o Colab decide, serviço a serviço, a taxa de amostragem ideal, nem como os SLOs por prefeitura são recalculados quando a sazonalidade histórica de um município muda (uma gestão nova, um serviço novo). Também não há dado sobre quanto do ganho de 95,8% em esforço de incidente vem da observabilidade em si e quanto vem especificamente do Kiro, já que os dois entraram juntos na mesma jornada. Para quem vai replicar esse desenho, essas duas perguntas são o ponto de partida para o próprio Well-Architected Review.

Fonte: AWS Brasil — Blog