Modelos de inicialização e configuração de ASG

Um modelo de inicialização é um projeto com versões que informa aos grupos de Auto Scaling (e diretamente ao EC2) como iniciar instâncias. Ele reúne a AMI ID, o tipo de instância, o par de chaves, os grupos de segurança e os dados do usuário opcionais em um único documento reutilizável. Diferentemente da configuração de inicialização mais antiga, um modelo de inicialização oferece suporte a várias versões e pode ser atualizado sem substituir o ASG.

Você pode criar um modelo de inicialização com a AWS CLI usando create-launch-template. O parâmetro --launch-template-data aceita um objeto JSON que define todas as configurações da instância. O controle de versões permite iterar no modelo sem afetar as instâncias em execução até que você esteja pronto para implantá-lo.

Todo modelo de inicialização começa na versão 1. Ao criar uma nova versão, você pode substituir apenas os campos que foram alterados — todas as outras configurações são herdadas da versão de origem. O ASG pode ser configurado para usar uma versão $Latest (sempre a mais recente) ou uma versão $Default (designada explicitamente). Usar $Default proporciona implantações controladas, enquanto $Latest é conveniente em ambientes de desenvolvimento.

Um grupo do Auto Scaling (ASG) mantém uma frota de instâncias EC2 dentro de limites definidos: mínimo (piso), máximo (teto) e capacidade desejada (quantidade-alvo em qualquer momento). Quando as instâncias falham nas verificações de integridade ou a política de escalabilidade é acionada, o ASG inicia ou encerra instâncias automaticamente para manter a frota na quantidade desejada entre o mínimo e o máximo.

Ao criar um ASG, você faz referência a um modelo de execução (não diretamente a uma AMI específica). Você também especifica as sub-redes da VPC nas quais as instâncias serão iniciadas. Distribuir as instâncias entre várias sub-redes (uma por AZ) oferece redundância integrada entre AZs: se uma AZ falhar, o ASG iniciará automaticamente instâncias substitutas nas AZs restantes.

Por padrão, um ASG usa verificações de integridade do EC2, que só sinalizam uma instância como não íntegra se ela estiver parada, encerrada ou se o hipervisor informar uma falha. Quando você associa um balanceador de carga, deve mudar para verificações de integridade do ELB para que o ASG substitua instâncias que estão em execução, mas retornam erros HTTP 5xx. Esta é uma pergunta comum em exames: sempre escolha as verificações de integridade do ELB quando houver um balanceador de carga na arquitetura.

Definir corretamente os limites de capacidade é fundamental. O mínimo garante que sua aplicação possa sempre atender ao tráfego (nunca fique abaixo desse valor). O máximo impede uma escalabilidade descontrolada que poderia esgotar os limites do serviço ou o orçamento. A capacidade desejada é o alvo inicial; as políticas de escalabilidade a ajustam dinamicamente. Se você definir mínimo=máximo=desejado, o ASG funcionará como um grupo de tamanho fixo, o que é útil para implantações de modelos de execução ou para manter uma capacidade fixa.

Para aplicações da camada web, associe o ASG a um grupo de destino do Application Load Balancer. Cada nova instância iniciada pelo ASG é registrada automaticamente no grupo de destino, e as instâncias encerradas são automaticamente removidas do registro. Isso garante que o tráfego flua somente para instâncias íntegras e em execução. Você também deve definir o tipo de verificação de integridade como ELB para que o ASG reconheça falhas no nível do balanceador de carga.

Dados do usuário são um script de shell (codificado em Base64) executado uma vez quando uma instância é inicializada pela primeira vez. Em um modelo de execução, esse é o local adequado para instalar pacotes, configurar agentes (CloudWatch, SSM) e obter o código da aplicação. Mantenha os dados do usuário idempotentes: scripts que podem ser executados com segurança mais de uma vez evitam problemas durante a atualização de instâncias. Para configurações complexas, chame o AWS Systems Manager ou uma ferramenta de gerenciamento de configuração em vez de incorporar scripts grandes.

Um pool de aquecimento pré-inicializa um conjunto de instâncias EC2 paradas (ou em execução) em estado pronto, fora do ASG. Quando o ASG precisa aumentar a capacidade, ele obtém instâncias do pool de aquecimento em vez de iniciar instâncias do zero, reduzindo drasticamente o tempo necessário para adicionar capacidade. As instâncias no pool de aquecimento geram custos de estado parado (somente EBS, sem cobranças de CPU), o que é muito mais barato do que manter instâncias sobressalentes totalmente em execução.

Quando o ASG reduz a capacidade, ele precisa decidir quais instâncias encerrar. A política de encerramento padrão seleciona primeiro a AZ com mais instâncias (para reequilibrar), depois o modelo de execução mais antigo e, por fim, a instância mais próxima da sua hora de cobrança. Você pode personalizar essa ordem; por exemplo, escolha OldestLaunchTemplate para remover primeiro as instâncias que executam configurações desatualizadas. O ASG também realiza automaticamente o reequilíbrio entre AZs depois que uma sub-rede fica disponível ou após alterações manuais.

Teste sua compreensão dos conceitos de AWS Solutions Architect (SAA-C03) desta lição.

Nesta lição, você aprendeu que: os modelos de execução fornecem um modelo de instância versionado e reutilizável que oferece suporte a várias versões e aos ponteiros de versão $Latest/$Default; os limites de capacidade do ASG (mínimo/máximo/desejado) controlam o tamanho da frota com distribuição automática entre AZs por meio das sub-redes; e as verificações de integridade do ELB devem ser habilitadas quando um ASG está atrás de um balanceador de carga, para que falhas no nível da aplicação acionem substituições. A seguir, exploraremos políticas de escalabilidade, incluindo acompanhamento de destino e escalabilidade por etapas.