CloudWatch passa a aceitar API keys para autenticar traces OpenTelemetry

O que mudou

O Amazon CloudWatch passou a aceitar autenticação por bearer token, usando API keys, como opção adicional para enviar traces OpenTelemetry ao endpoint OTLP (OpenTelemetry Protocol) do AWS X-Ray. O anúncio é de 3 de novembro de 2026. Até então, quem queria mandar traces para esse endpoint precisava assinar as requisições com AWS Signature Version 4 (SigV4), o que exige AWS SDK ou credenciais de curta duração emitidas pela AWS.

Com a mudança, qualquer cliente OTLP/HTTP capaz de montar um cabeçalho Authorization, incluindo o OpenTelemetry Collector e os exporters do OpenTelemetry SDK, pode autenticar com um token estático em vez de assinar cada requisição. Isso resolve um problema concreto: workloads que não têm como usar o AWS SDK ou credenciais temporárias, como aplicações on premises, cargas rodando em outra nuvem, pipelines de CI/CD e ferramentas de terceiros que só suportam um header Authorization fixo.

A AWS deixa claro que o SigV4 continua sendo o método recomendado, e os SDKs do AWS Distro for OpenTelemetry (ADOT) seguem usando SigV4 por padrão, sem nenhuma mudança necessária para quem já está nesse caminho. Traces enviados por qualquer um dos dois métodos chegam com os mesmos recursos no CloudWatch: Transaction Search, Application Signals e CloudWatch Omni.

Onde está disponível

A autenticação por bearer token para traces está disponível em todas as Regiões comerciais da AWS onde o endpoint OTLP de traces do X-Ray já existe. A fonte não publica uma lista explícita de regiões neste anúncio: a regra é que, onde o endpoint OTLP do X-Ray já roda, o bearer token também funciona ali.

Para quem opera na região América do Sul (São Paulo), sa-east-1, isso significa checar a documentação do AWS X-Ray Developer Guide para confirmar que o endpoint OTLP está ativo nessa região antes de planejar a migração de autenticação. A fonte deste anúncio não traz esse detalhe regional específico, só a regra geral de que o recurso acompanha onde o endpoint OTLP já está disponível.

Quanto custa

A fonte não traz uma tabela de preço para este anúncio. O recurso é um método de autenticação adicional para um endpoint que já existe, não um serviço novo com cobrança própria: não há menção a custo extra por usar bearer token em vez de SigV4.

Isso sugere que o custo de ingestão de traces segue o modelo de cobrança já praticado pelo X-Ray e pelo CloudWatch para traces, independente de como a requisição foi autenticada. Como a fonte não detalha valores, quem for mudar o método de autenticação deve conferir a página de preços do X-Ray antes de assumir que nada muda na fatura.

Como começar

A AWS aponta a documentação "Setting up bearer token authentication for traces" no AWS X-Ray Developer Guide como o caminho oficial para configurar o recurso. O fluxo geral, para quem já trabalha com OpenTelemetry Collector, é gerar a API key e apontar o exporter OTLP HTTP para o endpoint do X-Ray com o token no cabeçalho Authorization, como neste exemplo ilustrativo de configuração:

exporters:
 otlphttp:
 endpoint: https://xray.sa-east-1.amazonaws.com/v1/traces
 headers:
 Authorization: "Bearer ${CLOUDWATCH_API_KEY}"

Quem já usa o ADOT SDK não precisa fazer nada: o padrão continua sendo SigV4, e a troca para bearer token é opcional, pensada justamente para os casos em que SigV4 não é viável. O ponto de atenção prático é onde guardar e rotacionar essa API key, já que ela vira um segredo estático em vez de uma credencial de curta duração.

O que muda para quem já usa

Para arquitetos e times de DevOps/SRE que mantêm CloudWatch como central de observabilidade, o ganho real aparece em cenário híbrido e multi-nuvem. Um cluster Kubernetes on premises, uma carga rodando em outra nuvem pública ou um pipeline de CI/CD no GitHub Actions ou GitLab CI agora conseguem mandar traces direto para o X-Ray sem precisar embarcar AWS SDK nem gerenciar credenciais temporárias, bastando um header Authorization fixo.

Isso simplifica a arquitetura de observabilidade de ambientes que hoje dependem de um relay ou gateway dentro da AWS só para assinar requisições com SigV4 em nome de workloads externas. Com bearer token, esse intermediário pode sumir em vários casos, reduzindo um ponto de falha e de manutenção.

O trade-off é de segurança, não de funcionalidade: traces chegam com os mesmos recursos (Transaction Search, Application Signals, CloudWatch Omni) por qualquer um dos dois métodos, mas um token estático exposto em um pipeline de CI/CD ou em uma configuração on premises é um segredo a mais para proteger e rotacionar, diferente de uma credencial de curta duração que expira sozinha. Para workloads que já rodam dentro da AWS com papel IAM disponível, como EC2, Lambda ou ECS com role atribuída, a AWS recomenda manter SigV4; o bearer token é a porta de entrada para quem está fora desse perímetro.

Fonte: AWS What's New