Cloud & Infraestrutura

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

8 min de leitura

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

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

<h2>Launch Templates: Fundação do Auto Scaling</h2>

<p>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.</p>

<h3>Criando um Launch Template</h3>

<p>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:</p>

<pre><code class="language-bash">aws ec2 create-launch-template \

--launch-template-name web-server-template \

--version-description &quot;Versão 1.0 - Nginx com Node.js&quot; \

--launch-template-data &#039;{

&quot;ImageId&quot;: &quot;ami-0c55b159cbfafe1f0&quot;,

&quot;InstanceType&quot;: &quot;t3.micro&quot;,

&quot;KeyName&quot;: &quot;minha-chave&quot;,

&quot;SecurityGroupIds&quot;: [&quot;sg-12345678&quot;],

&quot;IamInstanceProfile&quot;: {&quot;Name&quot;: &quot;EC2-App-Role&quot;},

&quot;UserData&quot;: &quot;IyEvYmluL2Jhc2gKc3VkbyB5dW0gdXBkYXRlIC15CnN1ZG8geXVtIGluc3RhbGwgLXkgbm9kZWpzCmVjaG8gJ2NvbnNvbGUubG9nKCJTZXJ2ZXIgUm9kYW5kbyIpJyA+IHNlcnZlci5qcw==&quot;,

&quot;TagSpecifications&quot;: [{

&quot;ResourceType&quot;: &quot;instance&quot;,

&quot;Tags&quot;: [{&quot;Key&quot;: &quot;Name&quot;, &quot;Value&quot;: &quot;web-server-prod&quot;}]

}]

}&#039;</code></pre>

<p>A string em <code>UserData</code> é 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.</p>

<p>---</p>

<h2>Auto Scaling Policies: Reatividade Sob Demanda</h2>

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

<h3>Target Tracking Scaling</h3>

<p>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.</p>

<pre><code class="language-python">import boto3

autoscaling = boto3.client(&#039;autoscaling&#039;)

response = autoscaling.put_scaling_policy(

AutoScalingGroupName=&#039;meu-asg-prod&#039;,

PolicyName=&#039;cpu-target-tracking&#039;,

PolicyType=&#039;TargetTrackingScaling&#039;,

TargetTrackingConfiguration={

&#039;TargetValue&#039;: 70.0,

&#039;PredefinedMetricSpecification&#039;: {

&#039;PredefinedMetricType&#039;: &#039;ASGAverageCPUUtilization&#039;

},

&#039;ScaleOutCooldown&#039;: 60,

&#039;ScaleInCooldown&#039;: 300

}

)

print(f&quot;Policy ARN: {response[&#039;PolicyARN&#039;]}&quot;)</code></pre>

<p>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: <code>ASGAverageNetworkIn</code>, <code>ALBRequestCountPerTarget</code>, entre outras.</p>

<h3>Step Scaling</h3>

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

<pre><code class="language-python"># Criar o alarme de CPU alta

cloudwatch = boto3.client(&#039;cloudwatch&#039;)

cloudwatch.put_metric_alarm(

AlarmName=&#039;cpu-alto-prod&#039;,

MetricName=&#039;CPUUtilization&#039;,

Namespace=&#039;AWS/EC2&#039;,

Statistic=&#039;Average&#039;,

Period=300,

EvaluationPeriods=2,

Threshold=75.0,

ComparisonOperator=&#039;GreaterThanThreshold&#039;,

Dimensions=[

{&#039;Name&#039;: &#039;AutoScalingGroupName&#039;, &#039;Value&#039;: &#039;meu-asg-prod&#039;}

]

)

Política com degraus

autoscaling.put_scaling_policy(

AutoScalingGroupName=&#039;meu-asg-prod&#039;,

PolicyName=&#039;cpu-step-scaling&#039;,

PolicyType=&#039;StepScaling&#039;,

AdjustmentType=&#039;ChangeInCapacity&#039;,

MetricAggregationType=&#039;Average&#039;,

StepAdjustments=[

{

&#039;MetricIntervalLowerBound&#039;: 0,

&#039;MetricIntervalUpperBound&#039;: 10,

&#039;ScalingAdjustment&#039;: 1

},

{

&#039;MetricIntervalLowerBound&#039;: 10,

&#039;MetricIntervalUpperBound&#039;: 20,

&#039;ScalingAdjustment&#039;: 2

},

{

&#039;MetricIntervalLowerBound&#039;: 20,

&#039;ScalingAdjustment&#039;: 4

}

]

)</code></pre>

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

<p>---</p>

<h2>Predictive Scaling: Inteligência Artificial no Seu Serviço</h2>

<p>Predictive Scaling usa Machine Learning para analisar padrões históricos de carga e escalar <strong>antes</strong> 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).</p>

<h3>Ativando Predictive Scaling</h3>

<p>Predictive Scaling funciona complementar a Target Tracking. Enquanto Target Tracking reage, Predictive Scaling antecipa. Configure assim:</p>

<pre><code class="language-python">autoscaling.put_scaling_policy(

AutoScalingGroupName=&#039;meu-asg-prod&#039;,

PolicyName=&#039;predictive-scaling-policy&#039;,

PolicyType=&#039;TargetTrackingScaling&#039;,

TargetTrackingConfiguration={

&#039;TargetValue&#039;: 70.0,

&#039;PredefinedMetricSpecification&#039;: {

&#039;PredefinedMetricType&#039;: &#039;ASGAverageCPUUtilization&#039;

},

&#039;ScaleOutCooldown&#039;: 60,

&#039;ScaleInCooldown&#039;: 300

}

)

Ativar modo preditivo no ASG

autoscaling.put_scaling_policy(

AutoScalingGroupName=&#039;meu-asg-prod&#039;,

PolicyName=&#039;predictive-mode&#039;,

PolicyType=&#039;TargetTrackingScaling&#039;,

TargetTrackingConfiguration={

&#039;TargetValue&#039;: 70.0,

&#039;CustomizedMetricSpecification&#039;: {

&#039;MetricName&#039;: &#039;MyCustomMetric&#039;,

&#039;Namespace&#039;: &#039;MyApp&#039;,

&#039;Statistic&#039;: &#039;Average&#039;

}

}

)

Enable Predictive Scaling via describe

response = autoscaling.describe_auto_scaling_groups(

AutoScalingGroupNames=[&#039;meu-asg-prod&#039;]

)

print(response[&#039;AutoScalingGroups&#039;][0])</code></pre>

<blockquote><p><strong>Nota prática:</strong> 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.</p></blockquote>

<p>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.</p>

<p>---</p>

<h2>Boas Práticas e Cenários Reais</h2>

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

<p><strong>Launch Template versionamento:</strong> 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.</p>

<p><strong>Métricas customizadas:</strong> 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.</p>

<pre><code class="language-python">cloudwatch.put_metric_data(

Namespace=&#039;MyApp&#039;,

MetricData=[

{

&#039;MetricName&#039;: &#039;QueueDepth&#039;,

&#039;Value&#039;: 150,

&#039;Unit&#039;: &#039;Count&#039;,

&#039;Timestamp&#039;: datetime.datetime.utcnow()

}

]

)</code></pre>

<p>---</p>

<h2>Conclusão</h2>

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

<p>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.</p>

<p>---</p>

<h2>Referências</h2>

<ul>

<li><a href="https://docs.aws.amazon.com/autoscaling/" target="_blank" rel="noopener noreferrer">AWS EC2 Auto Scaling Documentation</a></li>

<li><a href="https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/launch-templates.html" target="_blank" rel="noopener noreferrer">AWS Launch Templates Best Practices</a></li>

<li><a href="https://docs.aws.amazon.com/autoscaling/ec2/userguide/predictive-scaling.html" target="_blank" rel="noopener noreferrer">Predictive Scaling for EC2</a></li>

<li><a href="https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html" target="_blank" rel="noopener noreferrer">AWS Auto Scaling Policies Guide</a></li>

<li><a href="https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/autoscaling.html" target="_blank" rel="noopener noreferrer">Boto3 AutoScaling Client Reference</a></li>

</ul>

Comentários

Mais em Cloud & Infraestrutura

O que Todo Dev Deve Saber sobre CloudShell e AWS CDK: Infraestrutura como Código Nativa da AWS
O que Todo Dev Deve Saber sobre CloudShell e AWS CDK: Infraestrutura como Código Nativa da AWS

CloudShell e AWS CDK: A Fundação da Infraestrutura como Código A infraestrutu...

Como Usar DynamoDB: Data Modeling, GSIs, LSIs e Capacity Modes em Produção
Como Usar DynamoDB: Data Modeling, GSIs, LSIs e Capacity Modes em Produção

Data Modeling no DynamoDB O DynamoDB é um banco de dados NoSQL totalmente ger...

Como Usar RDS em Profundidade: Multi-AZ, Read Replicas e Parameter Groups em Produção
Como Usar RDS em Profundidade: Multi-AZ, Read Replicas e Parameter Groups em Produção

Arquitetura de Alta Disponibilidade com RDS O Amazon RDS (Relational Database...