AWS Admin

EC2 Auto Scaling: Launch Templates, Policies e Predictive Scaling: Do Básico ao Avançado Já leu

Launch Templates: Fundação do Auto Scaling Um Launch Template é um blueprint que define como as instâncias EC2 serão criadas no Auto Scaling Group (ASG). Ele substitui o deprecated Launch Configuration com funcionalidades superiores: versionamento, reutilização entre múltiplos ASGs e compatibilidade com Spot Instances. Criando um Launch Template O Launch Template encapsula: tipo de instância, AMI, security groups, volumes EBS, IAM roles e user data. Você pode versionar templates e fazer rollback instantaneamente. Eis um exemplo prático usando AWS CLI: A string em é Base64. Decodificando, ela instala Node.js e cria um servidor básico. O versionamento permite testar novas configurações sem afetar instâncias rodando com versões anteriores. --- Auto Scaling Policies: Reatividade Sob Demanda As policies definem quando e como escalar. Existem três tipos principais: Target Tracking (mais simples), Step Scaling (granular) e Simple Scaling (legado). Cada uma resolve problemas diferentes. Target Tracking Scaling Target Tracking monitora uma métrica (CPU, memória, requisições) e mantém um alvo. Se a métrica excede

Launch Templates: Fundação do Auto Scaling

Um Launch Template é um blueprint que define como as instâncias EC2 serão criadas no Auto Scaling Group (ASG). Ele substitui o deprecated Launch Configuration com funcionalidades superiores: versionamento, reutilização entre múltiplos ASGs e compatibilidade com Spot Instances.

Criando um Launch Template

O Launch Template encapsula: tipo de instância, AMI, security groups, volumes EBS, IAM roles e user data. Você pode versionar templates e fazer rollback instantaneamente. Eis um exemplo prático usando AWS CLI:

aws ec2 create-launch-template \
  --launch-template-name web-server-template \
  --version-description "Versão 1.0 - Nginx com Node.js" \
  --launch-template-data '{
    "ImageId": "ami-0c55b159cbfafe1f0",
    "InstanceType": "t3.micro",
    "KeyName": "minha-chave",
    "SecurityGroupIds": ["sg-12345678"],
    "IamInstanceProfile": {"Name": "EC2-App-Role"},
    "UserData": "IyEvYmluL2Jhc2gKc3VkbyB5dW0gdXBkYXRlIC15CnN1ZG8geXVtIGluc3RhbGwgLXkgbm9kZWpzCmVjaG8gJ2NvbnNvbGUubG9nKCJTZXJ2ZXIgUm9kYW5kbyIpJyA+IHNlcnZlci5qcw==",
    "TagSpecifications": [{
      "ResourceType": "instance",
      "Tags": [{"Key": "Name", "Value": "web-server-prod"}]
    }]
  }'

A string em UserData é Base64. Decodificando, ela instala Node.js e cria um servidor básico. O versionamento permite testar novas configurações sem afetar instâncias rodando com versões anteriores.


Auto Scaling Policies: Reatividade Sob Demanda

As policies definem quando e como escalar. Existem três tipos principais: Target Tracking (mais simples), Step Scaling (granular) e Simple Scaling (legado). Cada uma resolve problemas diferentes.

Target Tracking Scaling

Target Tracking monitora uma métrica (CPU, memória, requisições) e mantém um alvo. Se a métrica excede o alvo, novos servidores são adicionados automaticamente. É a opção recomendada para 80% dos casos.

import boto3

autoscaling = boto3.client('autoscaling')

response = autoscaling.put_scaling_policy(
    AutoScalingGroupName='meu-asg-prod',
    PolicyName='cpu-target-tracking',
    PolicyType='TargetTrackingScaling',
    TargetTrackingConfiguration={
        'TargetValue': 70.0,
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'ASGAverageCPUUtilization'
        },
        'ScaleOutCooldown': 60,
        'ScaleInCooldown': 300
    }
)

print(f"Policy ARN: {response['PolicyARN']}")

Este código mantém CPU média em 70%. Se exceder, escala para cima em 60 segundos. Se cair abaixo, aguarda 300 segundos antes de descer (evita churn). Outras métricas predefinidas: ASGAverageNetworkIn, ALBRequestCountPerTarget, entre outras.

Step Scaling

Step Scaling oferece mais granularidade. Define degraus: se CPU entre 70-80%, adiciona 1 instância; se 80-90%, adiciona 2; se >90%, adiciona 4. Exige um CloudWatch Alarm como gatilho.

# Criar o alarme de CPU alta
cloudwatch = boto3.client('cloudwatch')

cloudwatch.put_metric_alarm(
    AlarmName='cpu-alto-prod',
    MetricName='CPUUtilization',
    Namespace='AWS/EC2',
    Statistic='Average',
    Period=300,
    EvaluationPeriods=2,
    Threshold=75.0,
    ComparisonOperator='GreaterThanThreshold',
    Dimensions=[
        {'Name': 'AutoScalingGroupName', 'Value': 'meu-asg-prod'}
    ]
)

# Política com degraus
autoscaling.put_scaling_policy(
    AutoScalingGroupName='meu-asg-prod',
    PolicyName='cpu-step-scaling',
    PolicyType='StepScaling',
    AdjustmentType='ChangeInCapacity',
    MetricAggregationType='Average',
    StepAdjustments=[
        {
            'MetricIntervalLowerBound': 0,
            'MetricIntervalUpperBound': 10,
            'ScalingAdjustment': 1
        },
        {
            'MetricIntervalLowerBound': 10,
            'MetricIntervalUpperBound': 20,
            'ScalingAdjustment': 2
        },
        {
            'MetricIntervalLowerBound': 20,
            'ScalingAdjustment': 4
        }
    ]
)

Use Step Scaling quando comportamento de carga é previsível em etapas. Target Tracking é mais simples; escolha baseado na complexidade necessária.


Predictive Scaling: Inteligência Artificial no Seu Serviço

Predictive Scaling usa Machine Learning para analisar padrões históricos de carga e escalar antes da demanda chegar. Treina com 14 dias de dados e prevê até 48 horas à frente. É game-changer para picos previsíveis (fim de expediente, horários de pico).

Ativando Predictive Scaling

Predictive Scaling funciona complementar a Target Tracking. Enquanto Target Tracking reage, Predictive Scaling antecipa. Configure assim:

autoscaling.put_scaling_policy(
    AutoScalingGroupName='meu-asg-prod',
    PolicyName='predictive-scaling-policy',
    PolicyType='TargetTrackingScaling',
    TargetTrackingConfiguration={
        'TargetValue': 70.0,
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'ASGAverageCPUUtilization'
        },
        'ScaleOutCooldown': 60,
        'ScaleInCooldown': 300
    }
)

# Ativar modo preditivo no ASG
autoscaling.put_scaling_policy(
    AutoScalingGroupName='meu-asg-prod',
    PolicyName='predictive-mode',
    PolicyType='TargetTrackingScaling',
    TargetTrackingConfiguration={
        'TargetValue': 70.0,
        'CustomizedMetricSpecification': {
            'MetricName': 'MyCustomMetric',
            'Namespace': 'MyApp',
            'Statistic': 'Average'
        }
    }
)

# Enable Predictive Scaling via describe
response = autoscaling.describe_auto_scaling_groups(
    AutoScalingGroupNames=['meu-asg-prod']
)

print(response['AutoScalingGroups'][0])

Nota prática: Predictive Scaling exige mínimo 2 semanas de dados. Nos primeiros 14 dias, use Target Tracking tradicional. Após histórico suficiente, o ML começa a prever.

Vantagens concretas: em padrões recorrentes (segundo turno tem 40% mais carga), o ASG cresce 10-15 minutos antes, evitando timeout de usuários. Economia: reduz scaling desnecessário fora de padrão, economizando ~15% em instâncias ociosas.


Boas Práticas e Cenários Reais

Combinação de policies: Use Predictive + Target Tracking juntos. Predictive dimensiona proativamente; Target Tracking corrige desvios imprevistos em tempo real.

Launch Template versionamento: Sempre teste novas versões em um ASG de staging antes de mover para produção. Use feature flags dentro da aplicação para gradualmente habilitar novas funcionalidades.

Métricas customizadas: Se sua aplicação tem padrão único (filas, requisições internas), passe métrica customizada para Predictive Scaling via CloudWatch. Exemplo: escalar baseado em tamanho de fila SQS.

cloudwatch.put_metric_data(
    Namespace='MyApp',
    MetricData=[
        {
            'MetricName': 'QueueDepth',
            'Value': 150,
            'Unit': 'Count',
            'Timestamp': datetime.datetime.utcnow()
        }
    ]
)

Conclusão

Três aprendizados principais: (1) Launch Templates são versionáveis e reutilizáveis, superior ao Configuration deprecated; (2) Target Tracking resolve 80% dos casos, use Step Scaling apenas quando padrões de carga requerem granularidade; (3) Predictive Scaling antecipa demanda com ML, economizando recursos em padrões recorrentes — ative após 2 semanas de histórico.

Próximos passos: implemente em staging, monitore CloudWatch metrics por 2-4 semanas, valide economia, depois mova para produção. Auto Scaling bem configurado reduz downtime e custos simultaneamente.


Referências


Artigos relacionados