Amazon EKS Capability for Argo CD ganha notificações nativas via SQS e EventBridge

O que mudou

A Amazon EKS Capability for Argo CD agora suporta o Argo CD Notifications, anunciado pela AWS em 3 de novembro de 2026. O recurso envia alertas quando uma Application sincroniza, falha ou muda de estado de saúde. Triggers e templates de mensagem são definidos no cluster, e cada Application se inscreve com uma anotação, exatamente como no Argo CD upstream (notifications.argoproj.io/subscribe.<trigger>.<service>).

A novidade para quem roda Argo CD gerenciado pela AWS é o leque de 16 serviços de notificação suportados, incluindo Slack, PagerDuty, Opsgenie, Amazon SQS e Amazon EventBridge. SQS e EventBridge se autenticam usando a IAM Capability Role do cluster: o evento de deploy sai direto para sua fila ou barramento sem que você precise guardar access key, token ou webhook secret dentro do cluster.

Para serviços que exigem credencial de terceiro, caso do token de bot do Slack, a AWS permite apontar um ARN do AWS Secrets Manager no lugar do segredo bruto. A EKS Capability busca o valor automaticamente na hora de disparar a notificação. Em resumo: quem já tinha Argo CD Notifications rodando como add-on separado ganha a mesma funcionalidade dentro da Capability gerenciada, com autenticação via IAM em vez de secret manual.

Onde está disponível

A AWS diz que o Argo CD Notifications está disponível em todas as regiões onde a EKS Capability for Argo CD já existe, sem custo adicional pelo recurso em si. A fonte não lista as regiões nominalmente, então não há confirmação explícita de que a região América do Sul (São Paulo), sa-east-1, já tenha a Capability habilitada no dia do anúncio.

Quem opera cluster EKS em sa-east-1 deve conferir a página de disponibilidade por região da EKS Capability for Argo CD antes de assumir que o recurso já está ativo por aí. Capabilities novas costumam chegar primeiro em us-east-1 e us-west-2 e expandir depois, mas isso não está dito no anúncio.

Quanto custa

O Argo CD Notifications em si não tem cobrança adicional: é um recurso incluído na EKS Capability for Argo CD. O que gera custo são os serviços de destino usados para entregar a notificação, cobrados pelo modelo padrão de cada um.

Se o trigger manda o evento para o Amazon SQS, você paga pela tarifa normal de requisições da fila. Se manda para o Amazon EventBridge, paga pelo volume de eventos publicados na regra. Slack, PagerDuty e Opsgenie seguem o plano contratado com cada fornecedor, fora do escopo de cobrança da AWS.

Como começar

O fluxo segue o padrão do Argo CD Notifications upstream, só que dentro da Capability gerenciada:

1. Defina os triggers e os templates de mensagem no cluster (os mesmos objetos de configuração do Argo CD Notifications upstream, agora reconhecidos pela Capability).
2. Anote a Application que você quer monitorar, por exemplo com notifications.argoproj.io/subscribe.on-sync-succeeded.slack: canal-deploys.
3. Para SQS ou EventBridge, não é preciso criar role nem guardar chave: a Capability usa a IAM Capability Role do cluster para autenticar e publicar o evento.
4. Para Slack ou outro serviço que pede token, troque o valor do secret pelo ARN do recurso correspondente no AWS Secrets Manager.

A fonte não traz um comando de AWS CLI específico para habilitar o recurso; o processo descrito é de configuração dentro do cluster via os mesmos manifests do Argo CD Notifications, aplicados contra a Capability.

O que muda para quem já usa

Quem já roda Argo CD como EKS Capability e até agora monitorava sync e health só pelo painel da UI, ou com um controller de notificações próprio rodando ao lado, pode aposentar essa peça extra. O alerta passa a sair direto da Capability gerenciada pela AWS, com o ciclo de vida do add-on cuidado pelo provedor.

O ganho mais concreto para quem segue o pilar de excelência operacional do Well-Architected é a autenticação via IAM Capability Role para SQS e EventBridge. Antes, rotear evento de deploy para um workflow orientado a evento (uma Lambda disparada por fila SQS, por exemplo) exigia provisionar uma IAM role para service account (IRSA) e gerenciar essa permissão à parte. Agora a própria Capability assume essa role, o que reduz superfície de credencial dentro do cluster.

Fica em aberto, para quem decide adotar agora, confirmar a disponibilidade em sa-east-1 e mapear se os 16 destinos cobrem as ferramentas de observabilidade já usadas no ambiente de produção, antes de desligar a integração de notificação feita por fora.

Fonte: AWS What's New