# EC2 Windows pronta para escalar: sysprep e AMI antes do Auto Scaling

> Como preparar uma EC2 Windows antes de gerar a AMI, com o Ec2 Launch Settings, para recuperar a senha e escalar com Launch Template e Auto Scaling.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-15
- Assuntos: Migração
- URL: https://pages.formacaoaws.com.br/blog/ec2-windows-pronta-para-escalar/
- Aula de origem: "Como preparar uma instância EC2 Windows para escalar na AWS" (https://www.youtube.com/watch?v=kOFv2e58Edg)

Escalar instância Windows na AWS é simples. O difícil é preparar a instância antes de gerar a AMI: se você a imageia do jeito comum, a instância nova sobe sem senha recuperável e você perde o acesso. Aqui está o erro acontecendo, o ajuste que evita o problema e o caminho até o Auto Scaling group.

> **Importante:** esta aula é de dezembro de 2021 e usa o EC2Launch v1. A ferramenta atual para Windows é o EC2Launch v2, e as telas mudaram desde então (por exemplo, a senha do administrador hoje é configurada em "Set Administrator Account"). O raciocínio vale igual; confira as telas atuais na [documentação oficial do EC2Launch v2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2launch-v2-settings.html).

## O problema: AMI de Windows sem preparo

Um caso típico é a aplicação legada que não roda em Linux ou que depende de alguma particularidade do Windows. Você coloca seus recursos numa EC2 Windows e, para ter mais máquinas iguais atendendo à demanda, gera uma imagem (AMI) e liga essa imagem a um Auto Scaling.

Você quer a imagem congelada, mas com a possibilidade de voltar nela para atualizar o aplicativo ou instalar um software mais complexo de atualizar por user data. Para isso, a máquina que nasce da imagem precisa continuar acessível.

A senha do administrador do Windows é gerada quando a instância é lançada. Se você para a máquina e gera a imagem sem preparar nada, essa senha vai junto, "congelada". Na instância nova, o console não entrega uma senha que você consiga recuperar com a chave.

## Passo 1: lançar duas instâncias para comparar

Lancei duas instâncias iguais, para ver o contraste:

- Windows Server 2019 Base, tipo t3a.micro, duas instâncias, com IP público.
- Disco de 30 GB e a tag Name para distinguir uma da outra.
- Security group com entrada RDP liberada só para o meu IP.
- Um par de chaves novo, baixado na máquina.

Conectei nas duas por RDP, recuperando a senha pelo console com a chave. Em cada uma criei uma pasta no disco C: com um arquivo de texto dentro. É o meu "aplicativo de exemplo": o que a instância precisa ter toda vez que subir.

## Passo 2: o caminho que dá errado

Na primeira instância fiz o que muita gente faz: parei a máquina e criei a imagem pelo console (**Image and templates, Create image**). Como a instância já estava parada, não precisei me preocupar com o reboot.

Lancei uma instância nova a partir dessa AMI e fui buscar a senha com **Get password**. O console avisa que a senha não está disponível e pede para esperar pelo menos 4 minutos depois do lançamento.

![Tela Get Windows password com o aviso "Password is not available" e o pedido para aguardar ao menos 4 minutos](https://pages.formacaoaws.com.br/blog/assets/posts/ec2-windows-pronta-para-escalar/senha-nao-disponivel.webp)

Esperei os 4 minutos e tentei de novo. A senha não aparece: a imagem não foi preparada para isso. Sem a senha, não dá para entrar, e uma imagem inacessível não serve para escalar.

Existem saídas fora do caminho padrão, como pegar o snapshot, criar um volume e anexar a outra instância. O caminho natural é preparar antes de gerar a imagem.

## Passo 3: preparar com o Ec2 Launch Settings

Na segunda instância, antes de parar e gerar a imagem, abri o **Ec2LaunchSettings** pelo menu Iniciar do Windows (a janela se chama **Ec2 Launch Settings**). Fiz duas coisas:

1. Em **Administrator Password**, deixei marcada a opção **Random (Retrieve from console)**. Com a senha aleatória, você volta a recuperá-la pelo console.
2. Cliquei em **Shutdown with Sysprep**, confirmei e apliquei.

![Janela Ec2 Launch Settings com Administrator Password em "Random (Retrieve from console)" e o botão Shutdown with Sysprep em destaque](https://pages.formacaoaws.com.br/blog/assets/posts/ec2-windows-pronta-para-escalar/ec2launch-sysprep.webp)

O sysprep faz a limpeza: remove a senha gerada no lançamento original. Quando uma instância é lançada a partir da imagem, ele gera uma senha nova. É o "grande segredo" do processo. O Windows demora um pouco e, ao terminar, desliga a instância sozinho.

> **Importante:** faça isso por último, depois de colocar na máquina tudo o que a imagem precisa ter. Depois do sysprep, a instância desliga.

## Passo 4: gerar a AMI e lançar a instância

Com a instância desligada pelo sysprep, o fluxo é o normal: **Create image**, nome para a AMI e espera até ficar disponível. Depois lance uma instância dessa imagem, com o mesmo tipo, o mesmo security group de RDP e a mesma chave.

O Windows tem uma particularidade: numa instância Linux eu conectaria em 30 ou 40 segundos, e no Windows preciso esperar a janela dos 4 minutos. Às vezes libera antes. Na minha, o **Get password** liberou depois de alguns minutos, e a senha era outra, diferente da usada na instância original.

Conectei por RDP e a pasta e o arquivo do disco C: estavam lá: a instância ficou acessível e com o meu "aplicativo".

Para evoluir a imagem, o ciclo é o mesmo: conecte na instância, faça a melhoria (eu criei uma segunda versão do arquivo), rode **Shutdown with Sysprep** de novo e gere a AMI nova. Como a senha aleatória já ficou marcada, é só aplicar e confirmar.

## Passo 5: Launch Template e Auto Scaling group

Com a AMI pronta, o caminho até a escala é este:

**Fluxo:** EC2 Windows (app instalado) → Ec2 Launch Settings (senha aleatória e sysprep) → AMI (imagem da instância) → Launch Template (modelo da instância) → Auto Scaling group (regras de escala)

1. Crie um **Launch Template** (ou um Launch Configuration) apontando para a AMI e com a rotina que a instância deve executar.
2. Crie o **Auto Scaling group** e ligue o modelo a ele.
3. Defina as regras de escala no grupo.

O Launch Template é o modelo mais flexível; o Launch Configuration foi a primeira versão. Para o passo a passo de criar o modelo e o grupo, veja [Auto Scaling Group com Launch Template](https://pages.formacaoaws.com.br/blog/auto-scaling-group-ec2-launch-template/).

As regras de escala mais convencionais são CPU e latência. No cliente em que passei por essa dor, nenhuma das duas serviu: o que funcionou foi a fila. O cliente faz um pedido num software dele, o pedido vira mensagem numa fila SQS, e o Auto Scaling olha a quantidade de mensagens na fila para lançar as instâncias Windows.

![A AMI alimenta o Launch Template ou o Launch Configuration do Auto Scaling group; CPU e latency são as regras comuns, e no caso do cliente o grupo escala pela quantidade de mensagens da fila SQS, alimentada pelo software dele](https://pages.formacaoaws.com.br/blog/assets/posts/ec2-windows-pronta-para-escalar/escala-por-fila-sqs.svg)

## Se der para sair do Windows, saia

Todo esse processo existe só porque é Windows. Com instância Linux você não tem essa preocupação ao gerar a imagem. Se a sua carga puder mudar para Linux, boa parte desse trabalho some. Trabalhei com Windows por muitos anos, parei em 2018 e recomendo fugir dele quando der.

## Passo 6: limpar o laboratório

Ao final, terminei as duas instâncias e cancelei o registro das AMIs que gerei (**deregister**). Limpando tudo, o custo do laboratório fica praticamente zero.

## Checklist

- Instale na instância Windows tudo o que a imagem precisa ter, antes de gerar a AMI.
- Abra o Ec2LaunchSettings e confira se a senha do administrador está em Random.
- Clique em Shutdown with Sysprep e deixe a instância desligar sozinha.
- Gere a AMI só depois disso, sem parar e imagear a máquina "crua".
- Lance uma instância de teste da AMI e confirme que recupera a senha e que o app está lá.
- Aponte um Launch Template para a AMI e ligue-o a um Auto Scaling group.
- Escolha a regra de escala que combina com a sua carga: CPU, latência ou fila.
- Termine as instâncias de teste e cancele o registro das AMIs.

Escalar Windows na AWS dá certo quando o preparo da imagem vem antes. Se você precisa levar uma aplicação legada para a nuvem e escalar sem perder o acesso às máquinas, é esse ajuste que evita a dor.