# RDS: Migração do RDS para Graviton

> Esta regra identifica instâncias Amazon RDS que podem ser migradas para classes baseadas em **AWS Graviton (arquitetura ARM)**, visando redução de custo e melhoria de performance por dólar investido.
>
> A regra avalia compatibilidade de engine, versão e classe atual da instância.

***

**Contexto da regra e impacto no negócio**

Instâncias RDS baseadas em Graviton (ex: `db.m6g`, `db.r6g`, `db.t4g`) oferecem:

* Melhor relação custo-performance
* Redução média de custo entre 15% e 30%
* Eficiência energética superior

Muitas instâncias antigas (`m4`, `m5`, `r4`, `r5`, `t2`, `t3`, etc.) continuam em execução mesmo quando já existem equivalentes Graviton compatíveis.

Impacto direto:

* Oportunidade clara de redução de custo
* Modernização da infraestrutura
* Melhor aproveitamento financeiro do RDS

***

**Detalhamento técnico da regra**

A regra realiza varredura regional das instâncias RDS e aplica validações técnicas para determinar elegibilidade para migração.

***

**Como a regra é executada**

1. Autentica na conta AWS por região.
2. Executa:

   ```
   rds:DescribeDBInstances
   ```
3. Aplica filtros de tag (inclusão/exclusão).
4. Para cada instância:
   * Verifica filtro temporal de criação.
   * Valida se `DBInstanceStatus = available`.
   * Ignora engines Windows.
   * Consulta:

     ```
     rds:DescribeOrderableDBInstanceOptions
     ```

     para validar se a versão do engine suporta a classe Graviton correspondente.
   * Consulta tabela interna de mapeamento (`MAP_INSTANCES`) para determinar classe recomendada.
5. Se compatível, a instância é sinalizada.

***

**Lógica aplicada**

Uma instância será sinalizada quando:

```
Status = available

Engine não contém "windows"

Existe mapeamento para classe Graviton equivalente

EngineVersion é suportada pela classe Graviton recomendada

Atende ao filtro temporal configurado
```

Exemplo de mapeamento:

```
db.m5.large → db.m6g.large
db.r5.xlarge → db.r6g.xlarge
db.t3.medium → db.t4g.medium
```

***

**Campos analisados**

RDS Instance:

* `DBInstanceIdentifier`
* `DBInstanceClass`
* `Engine`
* `EngineVersion`
* `DBInstanceStatus`
* `InstanceCreateTime`
* `DBInstanceArn`
* `TagList`
* Região

Campo adicional gerado:

* `RecommendedGravitonClass`

***

**Parâmetros considerados na busca**

APIs utilizadas:

* `rds:DescribeDBInstances`
* `rds:DescribeOrderableDBInstanceOptions`

Validações:

* Status = available
* Compatibilidade de engine
* Compatibilidade de versão
* Mapeamento de classe existente

***

**Período Avaliado (Filtro Temporal)**

Período Avaliado: 15 dias

A regra considera a data de criação:

```
InstanceCreateTime
```

O filtro é aplicado conforme configuração:

* `greater_than X 15dias` ou
* `less_than X 15dias`

O Padrão configurado e que identifique as instâncias do RDS que podem ser migradas para o Graviton dentro do período de 15 dias.

> Esse parâmetro de avaliação pode ser ajustado nas configurações das regras.

***

**Intervalo de Análise**

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

***

**Cálculo de Savings**

O savings estimado considera redução média de **10%** na migração para instâncias Graviton equivalentes.

***

**Fórmula Oficial de Savings**

```
Savings = sum("lineitem/unblendedcost") * 0.1
```

***

**Campo de custo utilizado**

No Billing AWS:

* Service: AmazonRDS
* Line Item Type: Usage
* Usage Types:
  * InstanceUsage
* Campo financeiro considerado:
  * `lineitem/unblendedcost`

***

**Interpretação**

A regra assume economia média estimada de **10%** sobre o custo atual da instância RDS elegível.

Exemplo:

Se o custo mensal atual for:

```
$30.000
```

Aplicando a fórmula:

```
Savings = 30.000 * 0.1
Savings = $3.000/mês
```

Novo custo estimado:

```
$27.000/mês
```

***

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

* Validar compatibilidade da aplicação com arquitetura ARM.
* Testar em ambiente de homologação antes da migração.
* Verificar extensões específicas de banco.
* Avaliar impacto em Performance Insights.
* Planejar janela de manutenção adequada.

Possíveis exceções:

* Engines ou versões específicas não suportadas.
* Workloads com dependência de arquitetura x86.
* Ambientes com restrições regulatórias.

Recomenda-se migração gradual e validada tecnicamente antes da adoção definitiva.