# CloudWatch Alarm Warm-Up: Fim do Ruído de Startup em Pipelines CI/CD

O CloudWatch agora suporta períodos de warm-up para alarmes, resolvendo um problema clássico de ruído operacional em deploys automatizados. A feature parece simples, mas tem implicações sérias para SLOs, on-call fatigue e design de pipelines em ambientes financeiros. Neste artigo, analiso o mecanismo, os trade-offs reais e como integrar isso de forma responsável em stacks de produção.

- URL: https://fernando.moretes.com/blog/cloudwatch-alarm-warm-up-fim-do-ruido-de-startup-em-pipelines-ci-cd-amazon-cloud

- Markdown: https://fernando.moretes.com/blog/cloudwatch-alarm-warm-up-fim-do-ruido-de-startup-em-pipelines-ci-cd-amazon-cloud/article.md?lang=pt

- Published: 2026-09-01T16:58:58.081Z

- Category: IA & Agentes

- Tags: cloudwatch, observability, alarms, ci-cd, sre, finops, aws, on-call

- Reading time: 10 min

- Source: [Amazon CloudWatch now supports warm-up periods for alarms](https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-cloudwatch-alarms-warmup-period)

---

Todo engenheiro de plantão já viveu isso: é meia-noite, um deploy automatizado sobe um novo microserviço, e o PagerDuty dispara três alertas em sequência — todos `INSUFFICIENT_DATA`. Não há nada errado com o serviço. Ele ainda está inicializando. Mas o alarme foi criado junto com o recurso e avaliou imediatamente, encontrando ausência de dados e interpretando isso como falha. O CloudWatch Alarm Warm-Up Period, anunciado em setembro de 2026, é a resposta direta a esse problema. A feature introduz um estado formal `IN_WARM_UP` que suspende a avaliação do alarme por um período configurável — até 2.880 minutos — enquanto o recurso subjacente ainda não emite métricas de forma estável. É uma mudança cirúrgica, mas com impacto desproporcional em ambientes que operam com alta frequência de deploys e tolerância zero a falsos positivos.

## O Custo Real do Ruído de Alarme em Produção

- **2880** — Minutos máximos de warm-up configurável (2 dias). Cobre até cold starts de serviços com inicialização lenta, como jobs Glue ou instâncias RDS
- **IN_WARM_UP** — Novo estado formal no ciclo de vida do alarme CloudWatch. O alarme permanece em INSUFFICIENT_DATA e não executa ações enquanto o warm-up está ativo
- **~23%** — Dos alertas de on-call são falsos positivos em equipes com deploys frequentes. Startup noise é uma das fontes mais evitáveis de alert fatigue
- **2** — Modos de término do warm-up: duração fixa ou preenchimento da janela de. OnlyStartEvaluatingAfterWarmUpPeriodEnds=true força duração completa; false permite início antecipado com dados suficientes

## O Mecanismo: Mais do que um Timer Simples

A implementação do warm-up period é mais sofisticada do que parece à primeira vista. O parâmetro `WarmUpConfiguration` aceita dois campos: `WarmUpPeriodDurationInMinutes` (1 a 2.880) e `OnlyStartEvaluatingAfterWarmUpPeriodEnds` (booleano, default `false`). Essa combinação cria dois comportamentos distintos que precisam ser escolhidos conscientemente.

Com `OnlyStartEvaluatingAfterWarmUpPeriodEnds: false` (o padrão), o CloudWatch monitora a chegada de dados em tempo real. Assim que a janela de avaliação do alarme estiver completamente preenchida com pontos de dados — independentemente de quanto tempo do warm-up ainda resta — a avaliação começa. Isso é ideal para serviços que sobem rapidamente mas de forma imprevisível: você define um teto de segurança (digamos, 10 minutos) mas o alarme começa a funcionar em 90 segundos se o serviço subir rápido.

Com `OnlyStartEvaluatingAfterWarmUpPeriodEnds: true`, o alarme aguarda a duração completa configurada, independentemente de quando os dados chegam. Esse modo é adequado para serviços com comportamento de startup instável — como uma aplicação Java com JIT warmup que emite métricas erráticas nos primeiros minutos — onde você prefere garantir que o serviço esteja em regime estacionário antes de qualquer avaliação.

Durante todo o período de warm-up, o alarme permanece no estado `INSUFFICIENT_DATA` com o sub-estado `IN_WARM_UP`. Nenhuma ação de alarme é executada — nem SNS, nem Auto Scaling, nem SSM OpsItem. Isso é crítico: significa que políticas de escalonamento baseadas em alarmes CloudWatch também ficam suspensas durante o warm-up, o que pode ser um efeito colateral indesejado em arquiteturas que dependem de scale-out rápido no startup.

## Ciclo de Vida do Alarme CloudWatch com Warm-Up em Pipeline CI/CD

Fluxo desde o deploy até a avaliação estável do alarme, mostrando os dois modos de término do warm-up e as ações bloqueadas durante IN_WARM_UP

### 🚀 CI/CD Pipeline

- CodePipeline / GitHub Actions (ci)
- CloudFormation Stack Deploy (ci)

### ☁️ AWS Resource

- ECS Service (starting up) (compute)
- CloudWatch Metrics Stream (data)

### 🔔 Alarm Lifecycle

- Alarm Created INSUFFICIENT_DATA (security)
- IN_WARM_UP (evaluation blocked) (security)
- Early Exit (window filled) (compute)
- Full Duration Exit (compute)
- State: OK or ALARM (data)

### 🚫 Blocked During Warm-Up

- SNS Notification (messaging)
- Auto Scaling Action (compute)
- PagerDuty Alert (external)

### Fluxos

- pipeline -> cfn: provisiona
- cfn -> ecs: cria recurso
- cfn -> alarm_created: cria alarme simultâneo
- ecs -> metrics: emite métricas (delay)
- alarm_created -> warmup: entra em warm-up
- metrics -> warmup: dados chegando
- warmup -> eval_early: OnlyStart=false
janela preenchida
- warmup -> eval_full: OnlyStart=true
duração completa
- eval_early -> ok: avalia
- eval_full -> ok: avalia
- warmup -> sns: BLOQUEADO
- warmup -> asg: BLOQUEADO
- warmup -> pagerduty: BLOQUEADO
- ok -> sns: dispara se ALARM

## Por que Isso Importa em Ambientes Financeiros de Alta Frequência de Deploy

Em ambientes financeiros onde opero, o problema de startup noise tem consequências que vão além do incômodo operacional. Considere um banco digital que faz dezenas de deploys por dia usando ECS Fargate com CodePipeline. Cada deploy de um novo serviço — ou mesmo uma atualização de task definition que recria o alarme via CloudFormation — pode gerar uma rajada de notificações `INSUFFICIENT_DATA` nos primeiros 60 a 120 segundos. Com 30 serviços e 3 ambientes (staging, UAT, produção), isso se traduz em centenas de notificações espúrias por semana.

O efeito mais pernicioso não é o volume de notificações em si, mas o que ele faz com a cultura de on-call: engenheiros começam a ignorar alertas `INSUFFICIENT_DATA` como ruído esperado. Quando um `INSUFFICIENT_DATA` real aparece — por exemplo, um pod que falhou em inicializar completamente e nunca emitiu uma única métrica — ele é tratado com a mesma indiferença que os falsos positivos de startup. Isso é exatamente o tipo de erosão silenciosa de confiança em alertas que precede incidentes graves.

Além disso, em arquiteturas com Step Functions orquestrando workflows de pagamento, alarmes CloudWatch são frequentemente usados como gates de saúde antes de roteamento de tráfego. Um alarme em `INSUFFICIENT_DATA` logo após um deploy pode bloquear o Route 53 weighted routing ou o CodeDeploy blue/green de completar a transição, causando degradação de disponibilidade desnecessária. O warm-up period resolve isso ao garantir que o alarme não entre em estado de falha antes de ter dados suficientes para uma avaliação legítima.

## Onde o Warm-Up Period Realmente Brilha

- **Deploys atômicos via IaC**: Quando CloudFormation ou Terraform cria o recurso e o alarme no mesmo stack/apply, o warm-up elimina a janela de vulnerabilidade entre a criação do alarme e a primeira emissão de métrica — sem necessidade de lógica custom de delay no pipeline.
- **Alarmes de log (PutLogAlarm)**: A feature cobre tanto alarmes de métrica quanto alarmes de log. Para serviços que levam tempo para começar a escrever logs estruturados no CloudWatch Logs — como funções Lambda com cold start em VPC ou containers com inicialização de conexão de banco — isso é igualmente valioso.
- **Integração com CodeDeploy health checks**: Alarmes usados como `DeploymentConfig` health gates no CodeDeploy blue/green agora podem ser configurados com warm-up, evitando rollbacks prematuros causados por ausência temporária de dados durante o startup do ambiente green.
- **Serviços com inicialização lenta**: RDS Custom, instâncias EMR, jobs AWS Glue com inicialização de cluster — todos têm latências de startup que historicamente exigiam alarmes criados manualmente após a inicialização ou lógica de supressão custom. O warm-up torna isso declarativo.
- **Redução de MTTR percebido**: Ao eliminar falsos positivos de startup, a razão sinal/ruído dos alertas melhora. Engenheiros de plantão passam a tratar cada alerta com mais seriedade, o que reduz o tempo de resposta a incidentes reais — um efeito indireto mas mensurável em SLOs de resposta a incidentes.

> **Limitações Reais que Você Precisa Conhecer Antes de Adotar:** **O warm-up bloqueia TODAS as ações, incluindo Auto Scaling.** Se você usa um alarme CloudWatch para acionar scale-out no startup de um serviço (padrão comum em ECS com Application Auto Scaling), o warm-up vai suprimir essa ação durante o período configurado. Isso pode causar under-provisioning exatamente quando o serviço está recebendo tráfego inicial. Separe alarmes de observabilidade (com warm-up) de alarmes de scaling (sem warm-up).

**Não há warm-up em atualizações de alarme existentes sem recriação.** Se você atualiza um alarme existente via `PutMetricAlarm` com `WarmUpConfiguration`, o warm-up é ativado a partir daquele momento. Em pipelines de atualização contínua onde o alarme já existe e apenas o recurso é recriado, o warm-up não é acionado automaticamente — você precisa recriar o alarme ou usar um mecanismo de trigger explícito.

**O estado `IN_WARM_UP` não é visível em todas as ferramentas de terceiros.** Datadog, New Relic e outras ferramentas que sincronizam estado de alarmes CloudWatch via API podem não renderizar `IN_WARM_UP` corretamente até que atualizem seus parsers. Verifique a compatibilidade antes de assumir visibilidade completa no seu observability stack.

**Warm-up não substitui `treat missing data`.** As duas configurações coexistem e se aplicam em momentos diferentes: warm-up controla o período pré-avaliação; `treat missing data` controla o comportamento quando dados estão ausentes durante a avaliação ativa. Você ainda precisa configurar ambos corretamente.

## Integração com IaC: CloudFormation, Terraform e o Problema do Ciclo de Vida

A adoção prática do warm-up period exige atenção ao ciclo de vida de recursos no seu toolchain de IaC. No CloudFormation, o recurso `AWS::CloudWatch::Alarm` agora suporta a propriedade `WarmUpConfiguration` com os campos `WarmUpPeriodDurationInMinutes` e `OnlyStartEvaluatingAfterWarmUpPeriodEnds`. A configuração é declarativa e se aplica na criação do alarme — exatamente o que você quer em um stack que cria recurso e alarme juntos.

O problema surge com `UpdateStack`: se o alarme já existe e você adiciona `WarmUpConfiguration` em uma atualização, o CloudFormation faz um `PutMetricAlarm` com os novos parâmetros. O warm-up é ativado a partir daquele momento, mas o recurso subjacente já está rodando e emitindo métricas. Nesse cenário, o warm-up pode mascarar uma degradação real que ocorreu durante a janela de atualização. Minha recomendação: use `DeletionPolicy: Retain` com cuidado e, em pipelines de atualização, prefira recriar o alarme explicitamente quando mudar a configuração de warm-up.

No Terraform, o provider AWS ainda estava incorporando o suporte ao `WarmUpConfiguration` no momento desta análise. A abordagem mais segura é usar o recurso `aws_cloudwatch_metric_alarm` com `lifecycle { replace_triggered_by }` apontando para o recurso monitorado — assim, quando o recurso é recriado, o alarme também é recriado e o warm-up é ativado corretamente. Isso transforma o warm-up em uma propriedade do ciclo de vida do recurso, não apenas do alarme.

Para ambientes com múltiplos alarmes por serviço (p95 latency, error rate, saturation — o golden signals pattern), considere um módulo Terraform ou um CloudFormation nested stack que encapsule o recurso + conjunto de alarmes com warm-up padronizado. Isso garante consistência e evita que um engenheiro esqueça de configurar warm-up em um dos alarmes do conjunto.

## Observabilidade do Próprio Warm-Up: Monitorando o Monitor

Uma lacuna que vejo frequentemente em implementações de observabilidade é a ausência de visibilidade sobre o estado dos próprios alarmes. Com a introdução do `IN_WARM_UP`, isso se torna ainda mais relevante. Você precisa saber: quantos alarmes estão atualmente em warm-up? Por quanto tempo? Algum ficou preso em warm-up além do esperado?

O CloudWatch Events (EventBridge) emite eventos de mudança de estado de alarme, incluindo transições para e de `IN_WARM_UP`. Uma regra EventBridge que captura `detail.state.value = "INSUFFICIENT_DATA"` com `detail.state.reason` contendo `WarmUp` pode alimentar um dashboard operacional ou uma métrica customizada que mostra o número de alarmes em warm-up por serviço e ambiente. Isso é especialmente útil em ambientes com centenas de alarmes gerenciados por plataformas internas.

Para OpenTelemetry practitioners: o Collector da AWS com o receptor CloudWatch pode ser configurado para exportar métricas de estado de alarme para seu backend de observabilidade (Datadog, Grafana Cloud, etc.). Criar um SLI de "alarmes em warm-up há mais de X minutos além do configurado" é uma forma de detectar alarmes com configuração incorreta de warm-up ou recursos que falharam em inicializar e nunca saíram do estado `IN_WARM_UP`.

Um padrão que adoto em ambientes financeiros é criar um alarme composto (Composite Alarm) que agrega o estado de todos os alarmes de um serviço. O alarme composto não precisa de warm-up — ele avalia os alarmes filhos, que já têm warm-up configurado individualmente. Isso dá uma visão única de saúde do serviço sem multiplicar a complexidade de configuração de warm-up no nível composto.

## Como Adotar Warm-Up Period de Forma Responsável em Produção

1. **Audite seus alarmes existentes por startup noise** — Use CloudWatch Alarm History para identificar alarmes que transitam para INSUFFICIENT_DATA ou ALARM nos primeiros 5 minutos após criação. Filtre por `StateReason` contendo 'Insufficient Data'. Esses são os candidatos prioritários para warm-up. Em ambientes com muitos alarmes, automatize isso com uma query Athena sobre os logs de CloudTrail.

2. **Meça o startup time real dos seus serviços** — Antes de configurar `WarmUpPeriodDurationInMinutes`, meça o tempo real entre a criação do recurso e a primeira emissão de métrica. Para ECS, use o evento `RUNNING` do ECS Task como ponto de partida e o primeiro datapoint da métrica `CPUUtilization` como ponto de chegada. Adicione 20% de margem de segurança. Não use o valor máximo (2.880 min) por preguiça — isso mascara falhas reais de inicialização.

3. **Separe alarmes de observabilidade de alarmes de scaling** — Crie dois conjuntos de alarmes: um para notificação/paging (com warm-up configurado) e outro para Auto Scaling policies (sem warm-up, com `treat missing data: ignore`). Isso evita o efeito colateral de under-provisioning durante startup enquanto ainda protege o on-call de falsos positivos.

4. **Implemente via IaC com módulo padronizado** — Crie um módulo Terraform ou CloudFormation macro que encapsule o padrão recurso + alarmes com warm-up. O módulo deve aceitar `startup_time_seconds` como input e calcular `WarmUpPeriodDurationInMinutes` automaticamente. Use `replace_triggered_by` no Terraform para garantir que o alarme seja recriado quando o recurso for recriado.

5. **Configure observabilidade do warm-up via EventBridge** — Crie uma regra EventBridge que capture transições de estado de alarme envolvendo IN_WARM_UP e publique uma métrica customizada `AlarmWarmUpCount` por serviço e ambiente. Crie um alarme sobre essa métrica para detectar alarmes presos em warm-up além do tempo esperado (threshold: warm-up duration + 10 minutos).

6. **Valide em staging antes de produção** — Execute um deploy completo em staging com warm-up configurado e verifique: (1) nenhuma notificação espúria durante startup, (2) o alarme transiciona corretamente para OK ou ALARM após o warm-up, (3) ações de Auto Scaling funcionam como esperado (se separadas corretamente). Só então promova para produção.

## Warm-Up Period vs. Abordagens Anteriores para Suprimir Startup Noise
| Critério | Abordagem | Complexidade de Implementação | Confiabilidade | Visibilidade Operacional | Custo Adicional |
| --- | --- | --- | --- | --- | --- |
| Warm-Up Period (nativo) | Baixa — parâmetro declarativo no IaC | Alta — gerenciado pelo CloudWatch | Alta — estado IN_WARM_UP visível na API | Zero — sem custo adicional | — |
| Delay manual no pipeline (sleep/wait) | Média — requer lógica no pipeline | Baixa — delay fixo não adapta ao startup real | Baixa — nenhuma visibilidade de estado | Médio — aumenta duração do pipeline | — |
| Criar alarme após inicialização (script) | Alta — requer lógica de polling e criação tardia | Média — janela sem alarme durante startup | Baixa — sem alarme = sem visibilidade no período | Baixo — mas com risco operacional | — |
| Alarm Suppression (SNS filter policy) | Alta — requer filtros por metadado e lógica de tempo | Média — ações ainda executam, apenas notificação suprimida | Média — notificação suprimida mas ações visíveis | Baixo — mas complexidade operacional alta | — |

## Anti-Padrões que Vejo em Produção

- **Usar warm-up como substituto para `treat missing data: ignore`**: Os dois mecanismos têm propósitos diferentes. Warm-up é para o período pré-avaliação. `treat missing data` é para ausências durante a avaliação ativa. Usar apenas warm-up e deixar `treat missing data: breaching` vai causar alarmes falsos em períodos de baixo tráfego pós-startup.
- **Configurar warm-up máximo (2.880 min) para todos os alarmes**: Isso mascara falhas reais de inicialização por até 2 dias. Um serviço que falhou em subir completamente ficará silencioso por esse período. Calibre o warm-up com base no startup time medido, não no máximo disponível.
- **Aplicar warm-up em alarmes de Auto Scaling sem separação**: Como discutido, isso causa under-provisioning durante startup. Alarmes de scaling precisam de uma estratégia diferente — geralmente `treat missing data: ignore` com período de avaliação curto.
- **Não monitorar o estado IN_WARM_UP**: Sem observabilidade sobre alarmes em warm-up, você não sabe se um serviço está demorando mais do que o esperado para inicializar. Isso transforma o warm-up de uma feature de redução de ruído em um ponto cego operacional.

## Análise pelo Lens do AWS Well-Architected Framework

- **security**: Neutro para a maioria dos casos. Atenção: alarmes usados como gates de segurança (ex: detectar acesso não autorizado em novos recursos) não devem ter warm-up configurado, pois isso cria uma janela de cegueira de segurança durante o startup.
- **reliability**: Reduz falsos positivos que levam a rollbacks prematuros em pipelines de deploy, melhorando a confiabilidade do processo de entrega. O risco é mascarar falhas reais de inicialização se o warm-up for superdimensionado — calibração cuidadosa é essencial.

> **Minha Nota de Curadoria:** Eu esperava por essa feature há pelo menos dois anos — e a razão é simples: o problema de startup noise é um dos mais frequentes que vejo em revisões de arquitetura de observabilidade em ambientes financeiros, e as soluções existentes eram todas workarounds com trade-offs sérios. O que me agrada na implementação é o modo de término adaptativo (default `false`) — em vez de um timer fixo cego, o CloudWatch monitora ativamente a chegada de dados e termina o warm-up cedo quando possível. Isso é o design certo. O que eu faria imediatamente: criar um módulo Terraform interno que encapsula o padrão `recurso + alarmes com warm-up calibrado + EventBridge rule para monitorar IN_WARM_UP`, tornando o comportamento correto o comportamento padrão para qualquer novo serviço. A lição dura aprendida: features de supressão de ruído, quando mal configuradas, se tornam supressores de sinal real — e esse risco é maior do que o problema que resolvem.

## Veredicto: Uma Feature Cirúrgica com Impacto Desproporcional

O CloudWatch Alarm Warm-Up Period é uma das adições mais práticas ao ecossistema de observabilidade da AWS nos últimos anos. Não é glamourosa — não há ML, não há dashboards novos, não há integrações com Bedrock. É simplesmente a solução correta para um problema concreto que afeta equipes de engenharia que operam com alta frequência de deploys. A implementação é bem pensada: dois modos de término (adaptativo e fixo), cobertura tanto de metric alarms quanto de log alarms, e integração declarativa com IaC via `WarmUpConfiguration`.

As limitações existem e são reais — especialmente o bloqueio de Auto Scaling actions durante warm-up e a necessidade de calibração cuidadosa para evitar transformar o warm-up em um ponto cego. Mas essas são limitações gerenciáveis com design correto, não razões para evitar a feature.

Minha recomendação: adote imediatamente em qualquer ambiente com deploys automatizados via IaC onde alarmes são criados junto com recursos. Priorize serviços com startup time variável ou lento. Separe alarmes de observabilidade de alarmes de scaling. E, acima de tudo, monitore o próprio estado IN_WARM_UP — não crie pontos cegos ao tentar eliminar ruído.

**Rating: 4.5/5** — Perde meio ponto pela ausência de warm-up automático em atualizações de recursos existentes sem recriação do alarme, e pela potencial incompatibilidade com ferramentas de observabilidade de terceiros que ainda não renderizam IN_WARM_UP corretamente.

## Referências

- [Amazon CloudWatch now supports warm-up periods for alarms (AWS What's New, Sep 1 2026)](https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-cloudwatch-alarms-warmup-period)
- [Alarm warm-up periods — CloudWatch Documentation](https://docs.amazonaws.cn/en_us/AmazonCloudWatch/latest/monitoring/alarm-warm-up.html)
- [CloudWatch Alarm Evaluation — IN_WARM_UP state reference](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/alarm-evaluation.html)
- [AWS::CloudWatch::Alarm WarmUpConfiguration — CloudFormation Reference](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-properties-cloudwatch-alarm-warmupconfiguration.html)
- [Create an alarm that uses a warm-up period — CloudWatch Documentation](https://docs.amazonaws.cn/en_us/AmazonCloudWatch/latest/monitoring/Create_WarmUp_Alarm.html)
- [Site Reliability Engineering: How Google Runs Production Systems (Beyer et al.) — Alert fatigue and signal/noise ratio](https://sre.google/sre-book/table-of-contents/)
- [AWS Well-Architected Framework — Operational Excellence Pillar](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html)