# 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:

```
CPU máxima < 30%
```

***

**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.

```
Savings Mensal = Custo Mensal da Instância EC2 Removida
```

Onde:

```
Custo Mensal = Valor Hora da Instância × 730 horas
```

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:

```
0.096 × 730 = $70.08
```

Savings mensal:

```
$70.08
```

Savings anual:

```
$840.96
```

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

```
100 × $0.10 = $10/mês
```

Savings total mensal:

```
70.08 + 10 = $80.08
```

***

**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.