search

ELB: ELBs com Instâncias EC2 subutilizadas

Esta regra identifica Elastic Load Balancers (Classic ELB – v1 e Application/Network Load Balancer – v2) que:

  • Possuem mais de uma instância EC2 associada.

  • Todas as instâncias estão em estado running.

  • Todas as instâncias apresentam baixa utilização de CPU (abaixo de 30%) no período analisado.

O objetivo é detectar cenários de possível superdimensionamento de capacidade atrás do Load Balancer.

Contexto da regra e impacto no negócio

Load Balancers são componentes críticos de alta disponibilidade e escalabilidade. No entanto, ambientes frequentemente mantêm múltiplas instâncias associadas mesmo quando a carga real é baixa.

Isso gera:

  • Superprovisionamento de compute.

  • Custos desnecessários de EC2.

  • Custos adicionais de EBS.

  • Potencial desperdício de licenciamento atrelado à instância.

A regra não sugere remover o Load Balancer em si, mas sim avaliar se:

  • O número de instâncias pode ser reduzido.

  • A classe das instâncias pode ser reduzida.

  • O Auto Scaling Group pode ser reconfigurado.

Se não tratado, o ambiente permanece com custo recorrente acima da necessidade real.

Detalhamento técnico da regra

A regra executa análise regional cruzando dados de ELB, EC2 e CloudWatch.

Como a regra é executada

  1. A regra autentica na conta AWS e percorre todas as regiões ativas.

  2. Lista todos os Load Balancers:

    • Classic ELB (describe_load_balancers – v1)

    • Application/Network Load Balancer (elbv2:describe_load_balancers)

  3. Para cada ELB:

    • Obtém instâncias associadas.

    • Verifica se há mais de uma instância vinculada.

    • Confirma se todas estão em estado running.

    • Consulta métricas de CPU no CloudWatch.

  4. Avalia se todas as instâncias mantiveram CPU máxima inferior a 30% no período analisado.

  5. Caso todos os critérios sejam atendidos, o ELB é sinalizado.

Lógica aplicada

Um ELB será sinalizado quando:

  • Número de instâncias associadas > 1.

  • Todas as instâncias estão em execução.

  • Para cada instância:

    • Métrica CPUUtilization (Maximum) < 30% durante todo o período avaliado.

Se qualquer instância atingir 30% ou mais, o ELB não é considerado subutilizado.

Campos analisados

  • LoadBalancerName

  • LoadBalancerArn

  • InstanceId

  • InstanceState

  • CPUUtilization

  • Tags

  • Version (v1 ou v2)

Parâmetros considerados na busca

APIs utilizadas:

  • elb:DescribeLoadBalancers

  • elbv2:DescribeLoadBalancers

  • elb:DescribeInstanceHealth

  • elbv2:DescribeTargetHealth

  • ec2:DescribeInstances

  • cloudwatch:GetMetricStatistics

Métrica CloudWatch:

  • Namespace: AWS/EC2

  • MetricName: CPUUtilization

  • Statistic: Maximum

  • Period: 86400 segundos (agregação diária)

Threshold fixo aplicado:

Período Avaliado (Filtro Temporal)

Período Avaliado (Filtro Temporal): A regra avalia a métrica de CPU das instâncias associadas ao ELB no intervalo definido. O intervalo de análise corresponde ao operador do período do filtro combinado com os dias do período do filtro definidos na configuração da regra. Padrão é configurado para "Maior que 15 dias", a regra analisará a CPU máxima diária das instâncias nos últimos 15 dias e considerará subutilizadas aquelas que não ultrapassaram 30% em nenhum dia do período.

Esse parâmetro pode ser customizado conforme a necessidade do cliente, permitindo maior ou menor sensibilidade na detecção de subutilização.

Intervalo de Análise

Execução padrão: a cada 8 horas.

Cálculo de Savings

O savings potencial é calculado considerando a possibilidade de:

  • Reduzir número de instâncias.

  • Reduzir classe das instâncias.

  • Ajustar Auto Scaling.

Fórmula Conceitual

Cenário mais comum: redução de uma instância.

Onde:

Pode incluir também:

  • Armazenamento EBS associado.

  • IOPS provisionado.

  • Licenciamento adicional (Windows, SQL, etc.).

Campo de custo utilizado

No Billing AWS:

  • Service: AmazonEC2

  • Usage Type:

    • InstanceUsage

    • EBS:VolumeUsage

  • Line Item Type: Usage

  • Campo financeiro considerado:

    • Unblended Cost

    • Ou Amortized Cost (caso haja Savings Plans ou RI)

Elementos considerados

  • Tipo da instância.

  • Região.

  • Modelo de compra (On-Demand, RI, Savings Plan).

  • Horas médias mensais (730).

  • Não há projeção futura automática; trata-se de economia recorrente caso haja ajuste de capacidade.

Exemplo aplicado ao Billing

Cenário:

ELB com 3 instâncias m5.large:

  • Custo por hora: $0.096

  • CPU máxima observada: 18%

Se for possível reduzir de 3 para 2 instâncias:

Compute mensal por instância:

Savings mensal:

Savings anual:

Se também houver EBS de 100GB por instância:

Savings total mensal:

Dicas de uso e boas práticas para o usuário

  • Validar tráfego sazonal antes de reduzir capacidade.

  • Verificar picos fora do horário comercial.

  • Cruzar com métricas de:

    • RequestCount

    • Latency

    • NetworkIn/Out

  • Avaliar ajuste via Auto Scaling Group.

  • Considerar migração para instâncias menores (rightsizing).

  • Priorizar ambientes não produtivos para ajustes imediatos.

  • Verificar se há dependência de HA obrigatória.

Possíveis falsos positivos:

  • Ambientes preparados para picos sazonais.

  • Workloads com baixa CPU mas alto uso de memória.

  • Instâncias que executam tarefas críticas com baixa carga constante.

Recomenda-se análise técnica antes de qualquer redução.

Pode enviar a próxima regra mantendo exatamente esse padrão estruturado.

PreviousEKS: Versões de EKSNextELB: ELB sem solicitações

Last updated