EC2 Image Builder passa a reaproveitar instâncias de Auto Scaling Group para builds mais rápidos

A AWS anunciou em 19 de outubro de 2026 uma mudança na forma como o EC2 Image Builder provisiona a instância usada para montar uma imagem. Em vez de sempre subir uma instância nova no momento do build, o serviço agora pode puxar uma instância já em execução de um Auto Scaling Group (ASG) configurado pelo usuário, aplicar os componentes de build e gerar a imagem a partir dela.

O ganho é tempo. Toda vez que o Image Builder lança uma instância do zero, o pipeline espera o EC2 subir, o sistema operacional terminar o boot e os agentes necessários ficarem prontos antes mesmo de começar a instalar pacotes ou rodar scripts de build. Com uma instância de ASG já quente e disponível, esse intervalo de provisionamento e bootstrap simplesmente some do caminho crítico do pipeline.

Como funciona na prática

A integração entra na infrastructure configuration do pipeline de Image Builder: em vez de deixar o serviço decidir o tipo de instância e subir uma nova a cada execução, você aponta um Auto Scaling Group existente como fonte de instâncias para o build. Quando o pipeline dispara, o Image Builder seleciona uma instância já em execução nesse ASG, aplica os build components normalmente (pacotes, scripts, hardening, o que estiver na receita) e gera a imagem a partir dela.

O ASG não fica estático: conforme instâncias são consumidas pelos builds, o grupo as repõe automaticamente, mantendo um pool sempre disponível para a próxima execução do pipeline. Isso significa que a responsabilidade de manter capacidade de sobra passa a ser do próprio Auto Scaling Group, com as políticas de escala que ele já suporta, em vez de ficar implícita no tempo de lançamento de cada build.

Por que isso importa para quem roda pipeline de imagem

Time de plataforma que mantém golden AMIs costuma rodar o Image Builder com frequência: a cada patch de segurança, cada atualização de runtime, cada mudança de hardening, o pipeline reconstrói a imagem do zero. Multiplicado por dezenas de pipelines e execuções diárias ou semanais, o tempo de lançar e inicializar uma instância nova vira custo real de espera, mesmo que o trabalho de build em si seja rápido.

Reduzir esse tempo tem efeito direto em dois cenários comuns:

• Pipelines acionados por evento, como atualização automática de AMI assim que uma CVE é corrigida no pacote base, onde cada minuto a menos de build reduz a janela de exposição.
• Esteiras de CI/CD que dependem de imagem atualizada antes de rodar testes de integração, onde o build de imagem hoje é frequentemente o gargalo que atrasa o pipeline inteiro.

Opt-in, sem quebrar o que já existe

A AWS deixa claro que o recurso é totalmente opcional. Pipelines que não configuram um ASG na infrastructure configuration continuam usando o caminho padrão de lançamento, sem nenhuma mudança de comportamento. Quem já tem pipelines de Image Builder em produção não precisa fazer nada: a integração só entra em ação para quem explicitamente aponta um Auto Scaling Group como fonte de instâncias.

Essa escolha de design importa porque builds de imagem costumam estar amarrados a processos de compliance e auditoria: mudar o comportamento padrão sem aviso quebraria a previsibilidade de pipelines que times de segurança já validaram. Com o recurso opt-in, a migração vira decisão deliberada, não efeito colateral de uma atualização do serviço.

Disponibilidade e custo

O recurso está disponível em todas as regiões da AWS, incluindo São Paulo (sa-east-1), sem custo adicional pelo uso da integração em si. O que muda na fatura é a conta do Auto Scaling Group: manter instâncias já em execução esperando por builds significa pagar pelo tempo delas ligadas, mesmo entre uma execução e outra do pipeline, diferente do modelo anterior, em que a instância só existia durante a janela do build.

Na prática, isso desloca o trade-off de velocidade para custo de capacidade ociosa. Faz sentido para quem roda builds com frequência alta e para quem precisa minimizar latência entre o commit de uma correção e a imagem atualizada em produção. Para pipelines esporádicos, o modelo padrão de lançar e terminar a instância a cada build provavelmente continua mais barato.

O que ainda fica em aberto

O anúncio da AWS não detalha políticas de dimensionamento recomendadas para o ASG usado nessa integração, nem como o serviço lida com picos de demanda quando todas as instâncias do grupo estão ocupadas em builds simultâneos. Times que adotarem o recurso vão precisar calibrar na prática o tamanho mínimo e máximo do Auto Scaling Group em função do volume e da concorrência de pipelines, algo que a documentação oficial do EC2 Image Builder deve detalhar à medida que o recurso ganha uso em produção.

Fonte: AWS What's New