# AutoScalingInstanceRefresh no CloudFormation: Dissecando o Padrão

A integração do Instance Refresh como update policy nativa do CloudFormation fecha uma lacuna operacional que forçava equipes a orquestrar deploys de AMI fora do ciclo de IaC. Neste artigo, disseco a anatomia do padrão, seus modos de falha reais e quando ele é — e não é — a escolha certa para ambientes de alta criticidade.

- URL: https://fernando.moretes.com/blog/autoscalinginstancerefresh-no-cloudformation-dissecando-o-padrao-amazon-ec2-a

- Markdown: https://fernando.moretes.com/blog/autoscalinginstancerefresh-no-cloudformation-dissecando-o-padrao-amazon-ec2-a/article.md?lang=pt

- Published: 2026-07-30T09:03:21.031Z

- Category: IA & Agentes

- Tags: ec2-auto-scaling, cloudformation, instance-refresh, deployment-patterns, iac, reliability, financial-grade, devops

- Reading time: 9 min

- Source: [Amazon EC2 Auto Scaling now supports Instance Refresh in CloudFormation](https://aws.amazon.com/about-aws/whats-new/2026/07/ec2-auto-scaling-instance-refresh-cloudformation)

---

Por anos, atualizar instâncias em um Auto Scaling Group via CloudFormation significava escolher entre dois males: o `AutoScalingRollingUpdate` — rígido, sem suporte a checkpoints, cego a alarmes de aplicação — ou orquestrar o Instance Refresh fora da stack, quebrando a atomicidade do IaC e criando drift silencioso. A partir de julho de 2026, o `AutoScalingInstanceRefresh` como update policy nativa resolve esse problema. Mas "resolver" não significa "usar sem pensar". Este é um teardown do padrão.

## O Problema que Este Padrão Resolve

Considere o ciclo de vida típico de uma frota EC2 em um ambiente financeiro: a equipe de segurança publica uma nova AMI endurecida com patches de CVE críticos, e o time de plataforma precisa propagar essa AMI para todos os ASGs de produção com zero downtime, rollback auditável e sem violar SLOs de disponibilidade. Antes desta integração, o fluxo real era assim: o CloudFormation atualizava o Launch Template ou Launch Configuration, mas a política `AutoScalingRollingUpdate` não tinha visibilidade de alarmes CloudWatch nem suporte a checkpoints com bake time. A alternativa era acionar o Instance Refresh via CLI ou SDK em um pipeline separado — o que criava um estado onde a stack do CloudFormation estava "verde" mas as instâncias rodando ainda usavam a AMI antiga. Esse drift entre estado declarado e estado real é um risco de compliance sério em ambientes regulados como PCI-DSS e SOC 2.

O problema composto era o rollback: com `AutoScalingRollingUpdate`, um rollback de stack não revertia instâncias já substituídas. Com o Instance Refresh fora da stack, o rollback era manual e sem rastreabilidade no Change Management. A nova policy `AutoScalingInstanceRefresh` endereça ambos: o refresh é disparado automaticamente quando propriedades que exigem substituição de instância são alteradas na stack, e o rollback é tratado pelo rollback da própria stack do CloudFormation — mantendo o estado declarativo como fonte única de verdade.

## Ciclo de Vida do AutoScalingInstanceRefresh no CloudFormation

Fluxo completo desde a mudança de IaC até o rollback, mostrando checkpoints, alarmes e a estratégia launch-before-terminate

### 🛠️ IaC / CI-CD

- Git Commit AMI / LT change (ci)
- CloudFormation Stack Update (ci)

### 🔄 Instance Refresh Engine

- AutoScalingInstanceRefresh UpdatePolicy (compute)
- Launch-Before- Terminate (compute)
- ReplaceRootVolume (in-place) (storage)
- Checkpoint + Bake Time (compute)

### 📊 Observability / Gates

- CloudWatch Alarm (abort condition) (security)
- ELB Health Check (in-service gate) (network)

### ✅ / ↩️ Outcome

- Stack UPDATE_COMPLETE All instances refreshed (compute)
- CFN Stack Rollback Previous LT restored (ci)

### Fluxos

- git -> cfn: push / pipeline
- cfn -> policy: detecta mudança de propriedade
- policy -> lbt: estratégia padrão
- policy -> rrv: estratégia in-place
- lbt -> chk: após % de instâncias
- chk -> alarm: avalia alarmes no bake time
- elb -> lbt: gate de saúde
- alarm -> success: alarmes OK
- alarm -> rollback: alarme disparado → abort
- rollback -> cfn: stack reverte LT anterior

## Anatomia do Padrão: O Que Realmente Acontece Sob o Capô

Quando o CloudFormation detecta uma mudança em propriedades que exigem substituição de instância — como `ImageId` no Launch Template ou `InstanceType` — e a stack está configurada com `AutoScalingInstanceRefresh`, ele delega o processo de substituição ao motor de Instance Refresh do Auto Scaling em vez de gerenciar o ciclo de vida das instâncias diretamente. Isso é uma distinção arquitetural importante: o CloudFormation passa a ser um orquestrador de intenção, não um executor de substituição.

O motor de Instance Refresh suporta duas estratégias principais nesta integração. A primeira é `Launch-Before-Terminate` (LBT): novas instâncias são lançadas e validadas como `InService` no target group antes que as antigas sejam terminadas. Isso exige capacidade adicional temporária — tipicamente 10% a 100% acima do `DesiredCapacity`, configurável via `MinHealthyPercentage` e `MaxHealthyPercentage`. Para frotas com instâncias grandes (r6i.8xlarge, por exemplo), o custo dessa capacidade extra durante o refresh precisa ser planejado. A segunda estratégia é `ReplaceRootVolume`, anunciada em novembro de 2025, que substitui o volume raiz da instância sem terminá-la — útil quando o estado efêmero da instância (conexões TCP longas, caches quentes) tem custo de reconstrução alto.

Os checkpoints com bake time são o mecanismo de gate mais valioso: você define percentuais de progresso (ex: 20%, 50%, 100%) e um `BakeTimeSeconds` em cada checkpoint. Durante o bake time, o refresh pausa e avalia alarmes CloudWatch configurados como condição de abort. Se qualquer alarme configurado estiver em estado `ALARM`, o Instance Refresh é abortado e o CloudFormation inicia o rollback da stack — restaurando o Launch Template anterior como estado declarado. As scaling policies e health checks do ASG permanecem ativos durante todo o processo, o que significa que o auto scaling reativo a carga continua funcionando mesmo durante o refresh.

## Comparativo: Políticas de Update para ASG no CloudFormation
| Critério | Critério | AutoScalingRollingUpdate | AutoScalingReplacingUpdate | AutoScalingInstanceRefresh (novo) |
| --- | --- | --- | --- | --- |
| Checkpoints com bake time | ❌ Não suportado | ❌ Não suportado | ✅ Suportado | — |
| Alarmes CloudWatch como gate | ❌ Não suportado | ❌ Não suportado | ✅ Abort automático | — |
| Launch-Before-Terminate | Parcial (MinInstancesInService) | ❌ Recria o ASG inteiro | ✅ Nativo e configurável | — |
| Scaling policies ativas durante update | ⚠️ Pode conflitar | ❌ ASG recriado | ✅ Permanecem ativas | — |
| Replace Root Volume (in-place) | ❌ Não suportado | ❌ Não suportado | ✅ Suportado | — |
| Rollback via stack CFN | ⚠️ Parcial (não reverte instâncias já substituídas) | ✅ Recria ASG anterior | ✅ Stack rollback integrado | — |
| Custo de capacidade extra | Baixo (batch size) | Alto (ASG duplicado) | Médio (configurável por %) | — |

## Quando Usar Este Padrão: O Contexto que Justifica a Escolha

Este padrão é a escolha certa em cenários onde três condições se sobrepõem: (1) a frota EC2 é gerenciada integralmente via CloudFormation como fonte de verdade, (2) o processo de atualização precisa de gates de qualidade observáveis — alarmes de erro rate, latência P99, health checks de aplicação — antes de progredir, e (3) o rollback precisa ser auditável e rastreável no mesmo sistema de Change Management que registra a mudança de IaC.

No contexto financeiro, isso se traduz diretamente em pipelines de patch de AMI para frotas de processamento de transações, workers de filas SQS de alta vazão, ou instâncias de batch que rodam jobs noturnos de reconciliação. Nesses casos, o `BakeTimeSeconds` em cada checkpoint não é burocracia — é o tempo necessário para que métricas de negócio como taxa de aprovação de transações ou throughput de mensagens se estabilizem antes de continuar o rollout. Um valor razoável para ambientes de produção financeira é 300-600 segundos por checkpoint, com alarmes baseados em métricas customizadas publicadas via `PutMetricData`.

A estratégia `ReplaceRootVolume` merece atenção especial para instâncias com estado efêmero valioso: servidores de cache L2 que levam 15-20 minutos para aquecer, ou instâncias com conexões de banco de dados persistentes em pool que têm custo de reconexão mensurável. Nesse caso, substituir apenas o volume raiz — preservando a instância, seu IP, suas conexões e seu estado em memória — reduz o impacto operacional do patch significativamente. A contrapartida é que você não obtém a garantia de um ambiente completamente limpo que uma substituição de instância oferece, o que pode ser relevante para compliance em alguns frameworks.

## Anti-Padrões: Quando Este Mecanismo Vai Trabalhar Contra Você

- **Usar sem alarmes de abort configurados**: O valor central do `AutoScalingInstanceRefresh` é a capacidade de parar automaticamente quando métricas de negócio degradam. Configurar a policy sem `AlarmSpecification` é equivalente a fazer um rolling update cego — você perde o diferencial do padrão e ainda carrega a complexidade adicional.
- **Aplicar em ASGs com `DesiredCapacity` = 1**: Com uma única instância, qualquer estratégia de refresh que exija instâncias saudáveis antes de terminar as antigas vai bloquear indefinidamente ou forçar um período de downtime. Para singletons, use Blue/Green com dois ASGs ou aceite uma janela de manutenção explícita.
- **Confundir rollback de stack com rollback de instâncias já em produção**: O rollback do CloudFormation restaura o estado declarado (Launch Template, configurações do ASG), mas instâncias que já foram substituídas com sucesso antes do abort não são automaticamente revertidas para a AMI anterior. O rollback previne que mais instâncias sejam atualizadas, mas o estado da frota pode ser misto.
- **Usar `ReplaceRootVolume` para patches de kernel ou atualizações que requerem reboot**: A estratégia in-place substitui o volume mas não reinicia a instância por padrão. Se o patch exige reboot para ser efetivo (atualizações de kernel, drivers), você terá instâncias com o volume novo mas rodando o kernel antigo em memória — um estado inconsistente que é difícil de detectar sem instrumentação
- **Ignorar o impacto de custo em frotas grandes com `launch-before-terminate`**: Em uma frota de 200 instâncias r6i.4xlarge com `MaxHealthyPercentage` de 110%, você terá até 20 instâncias extras rodando simultaneamente durante o refresh. A ~$1.01/hora por instância, isso pode representar $20/hora de custo adicional.
- **Usar este padrão como substituto de Blue/Green para deploys de aplicação**: O Instance Refresh é um mecanismo de atualização de infraestrutura (AMI, tipo de instância, configuração de launch). Para deploys de código de aplicação em frotas EC2, Blue/Green com dois ASGs e um ALB ainda oferece isolamento mais limpo, traffic shifting granular e rollback instantâneo.

## Design de Referência para Ambientes Financeiros: Configuração Concreta

Para um ambiente financeiro típico — frota de workers de processamento de transações, SLO de 99.9% de disponibilidade, janela de deploy aprovada pelo Change Advisory Board — a configuração que eu usaria no `AutoScalingInstanceRefresh` como update policy combina os seguintes elementos:

**Estratégia**: `Launch-Before-Terminate` com `MinHealthyPercentage: 90` e `MaxHealthyPercentage: 110`. Isso garante que no mínimo 90% da capacidade nominal esteja sempre disponível e limita a capacidade extra a 10% — um trade-off razoável entre velocidade de refresh e custo.

**Checkpoints**: Três checkpoints em 25%, 50% e 100% da frota, com `BakeTimeSeconds: 300` em cada um. Os alarmes de abort devem incluir: (1) um alarme composto de P99 de latência da API de transações acima de 500ms por 3 períodos consecutivos de 60 segundos, (2) taxa de erros 5xx no ALB acima de 0.5% por 2 períodos, e (3) um alarme de negócio customizado baseado em `PutMetricData` monitorando a taxa de aprovação de transações — o mais importante, porque é o único que captura falhas silenciosas de aplicação que não se manifestam como erros HTTP.

**IAM**: A role do CloudFormation precisa de `autoscaling:StartInstanceRefresh`, `autoscaling:DescribeInstanceRefreshes` e `autoscaling:CancelInstanceRefresh`. Use uma condition `aws:ResourceTag` para restringir a ação apenas a ASGs com a tag `Environment: production` — evitando que uma mudança acidental em um stack de dev dispare um refresh em produção.

**Observabilidade**: Configure um EventBridge rule em `EC2 Auto Scaling` events do tipo `EC2 Instance Refresh Status Change` para enviar notificações para o canal de operações e registrar no sistema de Change Management. Isso fecha o loop de auditoria: a mudança de IaC, o progresso do refresh e o resultado final ficam todos rastreáveis sem intervenção manual.

**Encryption**: Se a nova AMI usa uma KMS key diferente da AMI anterior (rotação de chave anual, por exemplo), garanta que a instance profile das instâncias tenha `kms:Decrypt` e `kms:GenerateDataKey` para a nova chave antes de iniciar o refresh — caso contrário, as novas instâncias falharão no boot e o refresh abortará após esgotar as retentativas, potencialmente deixando a frota em estado misto.

## Lente do AWS Well-Architected

- **security**: A integração com CloudFormation mantém o princípio de least privilege centralizado: a role do CFN é o único principal que precisa de permissões de Instance Refresh. Combine com SCPs que negam `autoscaling:StartInstanceRefresh` para qualquer principal que não seja a role do CloudFormation em contas de produção. Valide a KMS key da nova AMI antes do deploy para evitar falhas de boot silenciosas.
- **reliability**: Checkpoints com bake time e alarmes de abort transformam o deploy em um processo de verificação contínua, não uma operação de fé. A manutenção das scaling policies durante o refresh garante que o ASG continue respondendo a picos de carga mesmo durante a atualização — eliminando a janela de vulnerabilidade que existia com `AutoScalingReplacingUpdate`.
- **performance**: A estratégia `ReplaceRootVolume` preserva caches quentes e conexões persistentes, reduzindo o impacto de performance do patch em instâncias com estado efêmero valioso. Para frotas de alto throughput, calibre `InstanceWarmupSeconds` para o tempo real de aquecimento da aplicação — subestimativos causam falsos positivos nos health checks e abortam o refresh prematuramente.

> **Calibre o `InstanceWarmupSeconds` com dados reais, não com intuição:** O erro mais comum que vejo em implementações de Instance Refresh é definir `InstanceWarmupSeconds` com um valor arbitrário (300 segundos é o padrão que aparece em exemplos de documentação). Na prática, meça o tempo real de aquecimento da sua aplicação: do momento em que a instância é marcada como `InService` no target group até o momento em que ela atinge throughput nominal. Faça isso com métricas de `RequestCount` por instância no ALB. Se o aquecimento real é 180 segundos mas você configurou 60, o Instance Refresh vai considerar a instância pronta antes de ela estar — e os alarmes de abort vão disparar no checkpoint seguinte, causando um abort que parece inexplicável sem essa instrumentação.

## O Que Esta Integração Não Resolve: Fronteiras do Padrão

É importante ser honesto sobre o que este padrão não faz, especialmente para evitar que equipes o adotem com expectativas erradas. Primeiro, o `AutoScalingInstanceRefresh` não é um mecanismo de deploy de aplicação. Ele opera na camada de infraestrutura — AMI, tipo de instância, configuração de launch. Se você precisa de deploys de código com traffic shifting granular (ex: 5% → 25% → 100% com análise de Canary), o CodeDeploy com `AllAtOnce`, `HalfAtATime` ou estratégias customizadas ainda é a ferramenta certa, possivelmente em conjunto com o Instance Refresh para a camada de AMI.

Segundo, o rollback integrado ao CloudFormation não é instantâneo. O rollback de stack inicia o cancelamento do Instance Refresh em andamento, mas instâncias já substituídas com sucesso não são revertidas automaticamente. Em um cenário onde 40% da frota foi atualizada antes do abort, você terá 40% das instâncias rodando a nova AMI e 60% rodando a antiga — um estado misto que pode ser problemático para aplicações que não são compatíveis com versões mistas. Isso é fundamentalmente diferente do Blue/Green, onde o rollback é uma mudança de peso no load balancer.

Terceiro, este padrão assume que o CloudFormation é a fonte de verdade para o ASG. Em organizações onde o ASG é gerenciado parcialmente via console, CLI ou automações externas (scripts de scaling de emergência, por exemplo), o estado declarado pode divergir do estado real, e o comportamento do rollback se torna imprevisível. Antes de adotar este padrão, garanta que o ASG tenha drift detection habilitado e que políticas organizacionais impeçam mudanças fora do IaC.

Por fim, a integração não endereça o problema de coordenação entre múltiplos ASGs que formam um serviço. Se você tem um ASG de API servers e um ASG de workers que precisam ser atualizados de forma coordenada (ex: nova versão de protocolo interno), o `AutoScalingInstanceRefresh` em cada stack independente não garante ordering. Para esse caso, Step Functions orquestrando múltiplos stack updates sequenciais ainda é o padrão correto.

> **Nota do Curador:** Na prática, o que eu faria imediatamente é migrar todos os pipelines de patch de AMI que hoje acionam Instance Refresh via CLI fora do CloudFormation para esta nova policy — o ganho em rastreabilidade e atomicidade de rollback sozinho justifica a mudança. O que eu não faria é abandonar os alarmes de negócio customizados em favor apenas dos health checks de infraestrutura: em ambientes financeiros, uma instância pode estar "saudável" do ponto de vista do ELB e ainda processar transações com taxa de erro elevada por um bug específico da nova AMI. A lição que aprendi da forma difícil é que `InstanceWarmupSeconds` subestimado é o maior causador de aborts falsos — meça antes de configurar, sem exceção.

## Veredicto: Adote com Configuração Deliberada

O `AutoScalingInstanceRefresh` como update policy nativa do CloudFormation é uma evolução genuína para equipes que gerenciam frotas EC2 via IaC. Ele fecha a lacuna entre estado declarado e estado real que existia quando o Instance Refresh era orquestrado externamente, e adiciona gates de qualidade — checkpoints, bake time, alarmes de abort — que o `AutoScalingRollingUpdate` nunca teve. Para ambientes financeiros com SLOs rígidos e requisitos de auditabilidade, esta integração é a forma correta de fazer patch de AMI em produção.

A ressalva é que o valor do padrão é proporcional à qualidade dos alarmes de abort configurados. Sem alarmes de negócio bem calibrados, você tem um rolling update mais complexo. Com alarmes de negócio bem calibrados — taxa de aprovação de transações, P99 de latência, throughput de mensagens — você tem um deploy com verificação contínua que pode se defender sozinho. Invista tempo na instrumentação antes de confiar no mecanismo de rollback.

Não use este padrão como substituto de Blue/Green quando o rollback instantâneo é um requisito não negociável, quando múltiplos ASGs precisam ser coordenados, ou quando o ASG não é gerenciado exclusivamente via CloudFormation. Nesses casos, a complexidade adicional do Blue/Green é justificada pelo isolamento que ele oferece.

**Rating:** Adote com configuração deliberada / Adop

## Referências

- [AWS What's New: EC2 Auto Scaling Instance Refresh in CloudFormation (Jul 29, 2026)](https://aws.amazon.com/about-aws/whats-new/2026/07/ec2-auto-scaling-instance-refresh-cloudformation)
- [CloudFormation UpdatePolicy Attribute — AutoScalingInstanceRefresh](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-attribute-updatepolicy.html#cfn-attributes-updatepolicy-instancerefresh)
- [AWS What's New: EC2 Auto Scaling Root Volume Replacement via Instance Refresh (Nov 2025)](https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-ec2-auto-scaling-root-volume-replacement/)
- [EC2 Auto Scaling — Elastic Load Balancing Integration](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
- [AWS What's New: Instance Refresh for Standby and Scale-In Protected Instances (Feb 2023)](https://aws.amazon.com/about-aws/whats-new/2023/02/amazon-ec2-auto-scaling-instance-refresh-standby-scale-in-protected-ec2/)
- [AWS Well-Architected Framework — Reliability Pillar](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)