Como criar um Auto Scaling group com launch template e target tracking na AWS

Um roteiro direto para quem sobe EC2 todo dia: criar o launch template, ligar o Auto Scaling group nele e configurar uma política de target tracking que escala pelo uso real de CPU.

Nota da redação: o comando create-auto-scaling-group do Passo 2 contém um erro de quoting em shell no parâmetro --launch-template (o trecho Version='$Latest' está dentro de aspas duplas externas, o que faz $Latest ser expandido pelo shell em vez de passado como string literal). Para funcionar como descrito no texto, use aspas simples envolvendo todo o par (--launch-template 'LaunchTemplateId=...,Version=$Latest') ou escape o cifrão (Version=\$Latest) dentro das aspas duplas. Corrija antes de rodar em qualquer ambiente.

Toda vez que alguém me pergunta como montar Auto Scaling do zero na EC2, a resposta não é "vai no console e clica em avançar". É entender três peças que dependem uma da outra: o launch template (o que a instância é), o Auto Scaling group (quantas instâncias e onde) e a scaling policy (quando subir ou descer). Este é o roteiro que eu seguiria num projeto típico, com AWS CLI, para quem já sobe instância no dia a dia e quer parar de ajustar desired capacity na mão às três da manhã.

A documentação oficial da AWS cobre o fluxo pelo console; aqui vou pelo terminal, porque é o que fica fácil de versionar e repetir. Vou usar uma aplicação web fictícia atrás de um Application Load Balancer, rodando numa instância Graviton, como exemplo concreto.

Por que launch template, não launch configuration

A AWS ainda aceita launch configuration em contas antigas, mas é uma opção mais antiga: hoje, o launch template é a recomendação para quem está criando um Auto Scaling group novo. O launch template também versiona (você pode manter $Default, $Latest ou uma versão fixa), o que facilita manter um histórico de mudanças na configuração da instância, incluindo a possibilidade de usar múltiplos tipos de instância quando necessário.

Em resumo: se você está criando um Auto Scaling group do zero hoje, nem cogite launch configuration. Vá direto de launch template.

Pré-requisitos antes de começar

Antes de digitar o primeiro comando, confira isto:

• AWS CLI v2 instalada e configurada com um profile que tenha as permissões necessárias para criar launch template, Auto Scaling group e scaling policy (por exemplo, ec2:CreateLaunchTemplate, autoscaling:CreateAutoScalingGroup e autoscaling:PutScalingPolicy costumam aparecer nessa lista; confirme a política IAM completa para o seu caso antes de rodar os comandos).
• Uma VPC com pelo menos duas subnets em Availability Zones diferentes na região sa-east-1 (São Paulo), para alta disponibilidade real.
• Um security group já criado, com as portas que sua aplicação usa liberadas.
• Uma AMI válida para a região (vou usar um ID fictício no exemplo; troque pelo ID da sua AMI).
• Se for usar load balancer, o ARN do target group já criado.

Passo 1: criar o launch template

O launch template define o que cada instância vai ser: AMI, tipo de instância, security group, tags, user data. Eu começo salvando a definição num arquivo JSON, porque fica mais fácil revisar em pull request do que digitar tudo inline.

{
  "ImageId": "ami-0abcdef1234567890",
  "InstanceType": "m6g.large",
  "SecurityGroupIds": ["sg-0123456789abcdef0"],
  "TagSpecifications": [
    {
      "ResourceType": "instance",
      "Tags": [{"Key": "Name", "Value": "web-app-asg"}]
    }
  ],
  "UserData": ""
}

Note o m6g.large: é uma instância Graviton (arquitetura arm64). Para um workload web stateless que escala horizontalmente, Graviton costuma ser a primeira opção a testar, mas confirme antes que sua imagem suporta arm64, já que a mesma aplicação sem recompilação específica para essa arquitetura pode não rodar ali.

Com o arquivo pronto, crio o template:

aws ec2 create-launch-template \
  --launch-template-name web-app-template \
  --version-description "v1 - base" \
  --launch-template-data file://launch-template-data.json \
  --region sa-east-1

O retorno traz o LaunchTemplateId. Guarde esse valor, ele vai ser usado no próximo comando.

Passo 2: criar o Auto Scaling group apontando pro template

Aqui é onde entram as subnets, os limites de capacidade e, se houver, o target group do load balancer. Eu sempre especifico --vpc-zone-identifier com subnets de pelo menos duas AZs, porque Auto Scaling group numa AZ só é Auto Scaling group sem a parte de "disponibilidade".

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-app-asg \
  --launch-template "LaunchTemplateId=lt-0123456789abcdef0,Version='$Latest'" \
  --min-size 2 \
  --max-size 6 \
  --desired-capacity 2 \
  --vpc-zone-identifier "subnet-0aaa,subnet-0bbb" \
  --target-group-arns arn:aws:elasticloadbalancing:sa-east-1:123456789012:targetgroup/web-app-tg/abc123 \
  --health-check-type ELB \
  --health-check-grace-period 120 \
  --region sa-east-1

Dois detalhes que eu não deixo passar:

• Version='$Latest' faz o Auto Scaling group sempre pegar a versão mais recente do template quando escalar. Se você prefere travar numa versão testada, troque por um número fixo.
• --health-check-type ELB: eu uso esse parâmetro quando o grupo está atrás de um load balancer. A documentação oficial trata esse tipo de health check em conjunto com o --health-check-grace-period, que define quanto tempo o Auto Scaling espera, depois que a instância entra em InService, antes de checar seu status de saúde. Antes de depender desse comportamento em produção, vale confirmar na documentação oficial exatamente quais verificações entram nesse critério, porque é justamente o tipo de situação em que uma instância pode parecer saudável sem estar realmente respondendo à aplicação.

Passo 3: criar a política de target tracking

Nota da redação: o código desta seção não foi executado em ambiente real. Valide antes de usar em produção.

Com o grupo criado, falta dizer quando ele escala. Target tracking é a opção que eu recomendo começar: pela minha experiência com esse recurso, você define um alvo (por exemplo, 50% de uso médio de CPU) e o Auto Scaling cuida de adicionar ou remover instância sozinho, sem você precisar escrever um alarme do CloudWatch na mão.

{
  "TargetValue": 50.0,
  "PredefinedMetricSpecification": {
    "PredefinedMetricType": "ASGAverageCPUUtilization"
  }
}

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name web-app-asg \
  --policy-name cpu-target-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration file://target-tracking.json \
  --region sa-east-1

Se o workload não for bem representado por CPU (um serviço que gargala em memória ou em requisições por segundo, por exemplo), dá para trocar PredefinedMetricSpecification por CustomizedMetricSpecification apontando para uma métrica sua no CloudWatch, ou usar ALBRequestCountPerTarget quando o grupo está atrás de um ALB.

Como eu verifico que está funcionando

Depois de criar tudo, eu não assumo que está certo só porque o comando retornou sem erro. Confiro nesta ordem:

1. aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names web-app-asg para ver se as instâncias entraram em InService.
2. aws autoscaling describe-policies --auto-scaling-group-name web-app-asg para confirmar que a política de target tracking aparece com o alvo certo.
3. No console do CloudWatch, olho o gráfico de CPUUtilization do grupo nas primeiras horas, para ver se o valor está oscilando perto do alvo definido, sem ficar colado em 100% nem em 5%.
4. Gero carga artificial na aplicação (um ab ou hey simples contra o endpoint, por exemplo) e acompanho se uma instância nova aparece no describe-auto-scaling-groups alguns minutos depois.

Se a instância nova não aparece mesmo com CPU acima do alvo, o primeiro lugar que eu olho é o --health-check-grace-period: se estiver curto demais para o tempo que sua aplicação leva para inicializar, o Auto Scaling pode marcar a instância como não saudável e derrubá-la antes mesmo dela aparecer no agregado de CPU usado pelo target tracking.

Os tropeços que pegam todo mundo

Alguns pontos da documentação da AWS passam batido na primeira leitura e custam caro depois:

• Default instance warmup: se você não configurar esse valor, o CloudWatch pode usar dados de uma instância ainda subindo para calcular a métrica agregada, distorcendo a decisão de escalar. Vale configurar com o tempo real de boot da sua aplicação.
• Distribuição por Availability Zone: o Auto Scaling group usa a estratégia de distribuição configurada para tentar balancear instâncias entre as AZs das subnets informadas. Vale acompanhar esse comportamento nas primeiras execuções, porque uma eventual falta de capacidade numa AZ específica pode não aparecer como erro óbvio, só como uma contagem de instâncias diferente do esperado.
• Versão do launch template: usar $Latest é conveniente, mas significa que uma mudança não testada no template vira instância nova no próximo evento de scaling. Para produção, eu prefiro fixar um número de versão e promover manualmente depois de validar.
• Scale-in protection: se a instância guarda estado local (sessão, cache), vale habilitar proteção contra scale-in nela antes de drenar, ou a instância pode ser terminada no meio de um processamento.

Nenhum desses pontos aparece como erro no create-auto-scaling-group; eles aparecem como comportamento estranho dias depois, quando o tráfego varia de verdade. Vale revisar cada um antes de apontar esse grupo para produção.

Fonte 1: Documentação do Amazon EC2 Auto Scaling (https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-launch-template.html)

Create an Auto Scaling group using a launch template - Amazon EC2 Auto Scaling

View a markdown version of this page Create an Auto Scaling group using a launch template - Amazon EC2 Auto Scaling Documentation Auto Scaling User Guide Create an Auto Scaling group using a launch template When you create an Auto Scaling group, you must specify the necessary information to configure the Amazon EC2 instances, the Availability Zones and VPC subnets for the instances, the desired capacity, and the minimum and maximum capacity limits.

To configure Amazon EC2 instances that are launched by your Auto Scaling group, you can specify a launch template or a launch configuration. The following procedure demonstrates how to create an Auto Scaling group using a launch template.

Prerequisites

You must have created a launch template. For more information, see Create a launch template for an Auto Scaling group .

To create an Auto Scaling group using a launch template (console)

Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/ , and choose Auto Scaling Groups from the navigation pane.

On the navigation bar at the top of the screen, choose the same AWS Region that you used when you created the launch template.

Choose Create an Auto Scaling group .

On the Choose launch template or configuration page, do the following:

For Auto Scaling group name , enter a name for your Auto Scaling group.

For Launch template , choose an existing launch template.

For Launch template version , choose whether the Auto Scaling group uses the default, the latest, or a specific version of the launch template when scaling out.

Verify that your launch template supports all of the options that you are planning to use, and then choose Next .

On the Choose instance launch options page, if you're not using multiple instance types, you can skip the Instance type requirements section to use the EC2 instance type that is specified in the launch template.

To use multiple instance types, see Auto Scaling groups with multiple instance types and purchase options .

Under Network , for VPC , choose a VPC. The Auto Scaling group must be created in the same VPC as the security group you specified in your launch template.

For Availability Zones and subnets , choose one or more subnets in the specified VPC. Use subnets in multiple Availability Zones for high availability. For more information, see Considerations when choosing VPC subnets .

For Availability Zone distribution , select a distribution strategy. For more information, see Auto Scaling group Availability Zone distribution .

If you created a launch template with an instance type specified, then you can continue to the next step to create an Auto Scaling group that uses the instance type in the launch template.

Alternatively, you can choose the Override launch template option if no instance type is specified in your launch template or if you want to use multiple instance types for auto scaling. For more information, see Auto Scaling groups with multiple instance types and purchase options .

Choose Next to continue to the next step.

Or, you can accept the rest of the defaults, and choose Skip to review .

(Optional) On the Integrate with other services page, configure the following options, and then choose Next :

For Load balancing , choose whether to attach your Auto Scaling group to a load balancer. For more information, see Elastic Load Balancing .

For VPC Lattice integration options , choose whether to use VPC Lattice. For more information, see Manage traffic flow with a VPC Lattice target group .

For Amazon Application Recovery Controller (ARC) zonal shift , select the checkbox to enable zonal shift. For more information, see Auto Scaling group zonal shift .

If you enable zonal shift, for Health check behavior , select Ignore unhealthy or Replace unhealthy. For more information, see How zonal shift works for Auto Scaling groups .

Under Health checks , for Additional health check types , select Turn on Amazon EBS health checks . For more information, see Monitor Auto Scaling instances with impaired Amazon EBS volumes using health checks .

For Health check grace period , enter the amount of time, in seconds. This amount of time is how long Amazon EC2 Auto Scaling needs to wait before checking the health status of an instance after it enters the InService state. For more information, see Set the health check grace period for an Auto Scaling group .

(Optional) On the Configure group size and scaling page, configure the following options, and then choose Next :

Under Group size , for Desired capacity , enter the initial number of instances to launch.

Under Scaling , Scaling limits , if your new value for Desired capacity is greater than Min desired capacity and Max desired capacity , the Max desired capacity is automatically increased to the new desired capacity value. You can change these limits as needed. For more information, see Set scaling limits for your Auto Scaling group .

For Automatic scaling , choose whether you want to create a target tracking scaling policy. You can also create this policy after your create your Auto Scaling group.

If you choose Target tracking scaling policy , follow the directions in Create a target tracking scaling policy to create the policy.

Under Instance maintenance policy , choose whether you want to create an instance maintenance policy. You can also create this policy after your create your Auto Scaling group. Follow the directions in Set an instance maintenance policy to create the policy.

Under Additional capacity settings , Capacity Reservation preference , choose whether you want to use a Capacity Reservation preference. For more information, see Use Capacity Reservations in your Auto Scaling group .

Under Additional settings , Instance scale-in protection , choose whether to enable instance scale-in protection. For more information, see Use instance scale-in protection to control instance termination .

For Monitoring , choose whether to enable CloudWatch group metrics collection. These metrics provide measurements that can be indicators of a potential issue, such as number of terminating instances or number of pending instances. For more information, see Monitor CloudWatch metrics for your Auto Scaling groups and instances .

For default instance warmup , select this option and choose the warmup time for your application. If you are creating an Auto Scaling group that has a scaling policy, the default instance warmup feature improves the Amazon CloudWatch metrics used for dynamic scaling. For more information, see Set the default instance warmup for an Auto Scaling group .

(Optional) On the Add notifications page, configure the notification, and then choose Next . For more information, see Amazon SNS notification options for Amazon EC2 Auto Scaling .

(Optional) On the Add tags page, choose Add tag , provide a tag key and value for each tag, and then choose Next . For more information, see Tag Auto Scaling groups and instances .

On the Review page, choose Create Auto Scaling group .

To create an Auto Scaling group using the command line

You can use one of the following commands:

create-auto-scaling-group (AWS CLI)

New-ASAutoScalingGroup (AWS Tools for Windows PowerShell) Document Conventions Create Auto Scaling groups using launch templates Create a group using the EC2 launch wizard Did this page help you? - Yes Thanks for letting us know we're doing a good job! If you've got a moment, please tell us what we did right so we can do more of it. Did this page help you? - No Thanks for letting us know this page needs work. We're sorry we let you down. If you've got a moment, please tell us how we can make the documentation better.

Fonte: Documentação do Amazon EC2 Auto Scaling