# RDS: Migração de RDS GP2 para GP3

> Esta regra identifica instâncias e clusters Amazon RDS que utilizam o tipo de armazenamento `gp2`.
>
> O objetivo é sinalizar oportunidades de migração para `gp3`, que oferece:
>
> * Melhor previsibilidade de performance.
> * Maior eficiência de custo.
> * Separação entre capacidade de armazenamento e IOPS.

***

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

O armazenamento `gp2` foi amplamente utilizado como padrão por muitos anos.

Entretanto:

* O `gp2` vincula performance (IOPS) ao tamanho do volume.
* Para obter mais IOPS, é necessário aumentar o tamanho do storage.
* Isso pode gerar superdimensionamento e custo desnecessário.

O `gp3`:

* Permite configurar IOPS independentemente do tamanho.
* Oferece custo por GB inferior ao gp2 na maioria das regiões.
* Mantém baseline de performance consistente.

Impactos no negócio:

* Potencial redução direta de custo de storage.
* Melhor controle de performance.
* Maior eficiência operacional.

Esta regra identifica oportunidades estruturais de otimização.

***

**Detalhamento técnico da regra**

A regra executa análise regional das instâncias e clusters RDS.

***

**Como a regra é executada**

1. Autentica na conta AWS por região.
2. Lista todas as instâncias RDS via `describe_db_instances`.
3. Lista todos os clusters RDS via `describe_db_clusters`.
4. Aplica filtros de tag (inclusão/exclusão).
5. Para cada recurso:
   * Verifica o campo:

     ```
     StorageType
     ```
   * Se `StorageType == "gp2"`, o recurso é sinalizado.

A regra cobre:

* Instâncias RDS tradicionais.
* Clusters (ex: Aurora com storage compatível).

***

**Lógica aplicada**

Um recurso será sinalizado quando:

```
StorageType = gp2
```

Não há análise de utilização, performance ou idade do recurso nesta implementação.

***

**Campos analisados**

Instâncias:

* `DBInstanceIdentifier`
* `StorageType`
* `Engine`
* `EngineVersion`
* `DBInstanceClass`
* `InstanceCreateTime`
* `DBInstanceArn`
* `TagList`

Clusters:

* `DBClusterIdentifier`
* `StorageType`
* `Engine`
* `EngineVersion`
* `DBClusterArn`
* `TagList`

***

**Parâmetros considerados na busca**

APIs utilizadas:

* `rds:DescribeDBInstances`
* `rds:DescribeDBClusters`

Condição técnica:

* Comparação direta:

  ```
  StorageType == "gp2"
  ```

***

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

Período Avaliado (Filtro Temporal): 15 dias.

Padrão é configurado para realizar a identificação quando essa instância há mais de 15 dias existente com opotunidade de migração.

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

Esta regra é da categoria ECONOMIA.

O savings é baseado na diferença de preço entre `gp2` e `gp3`.

***

**Fórmula Conceitual**

```
Savings Mensal = Tamanho (GB) × (Preço gp2 – Preço gp3)
```

Onde:

* Tamanho = armazenamento provisionado da instância.
* Preço varia conforme região.

Em média, o gp3 pode ser aproximadamente 20% mais barato por GB do que o gp2.

***

**Campo de custo utilizado**

No Billing AWS:

* Service: AmazonRDS
* Usage Type:
  * RDS:StorageUsage
  * EBS:VolumeUsage (quando aplicável)
* Line Item Type: Usage
* Campo financeiro considerado:
  * Unblended Cost
  * Ou Amortized Cost

***

**Elementos considerados**

* Tamanho provisionado (GB).
* Região.
* Tipo de engine.
* Não considera ajuste adicional de IOPS.
* Não há projeção futura automática; trata-se de economia recorrente após migração.

***

**Exemplo aplicado ao Billing**

Cenário:

* Instância com 1000 GB.
* Preço gp2: $0.115/GB.
* Preço gp3: $0.095/GB.

Cálculo:

```
Savings = 1000 × (0.115 - 0.095)
Savings = 1000 × 0.02
Savings = $20/mês
```

Savings anual:

```
20 × 12 = $240
```

Em ambientes com múltiplas instâncias grandes, o impacto pode ser significativo.

***

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

* Avaliar requisitos atuais de IOPS antes da migração.
* Testar em ambiente de homologação.
* Aproveitar a migração para revisar tamanho de storage.
* Verificar compatibilidade do engine.
* Realizar mudança em janela de manutenção.

Possíveis exceções:

* Workloads que dependem de comportamento específico do gp2.
* Instâncias com IOPS provisionado (io1/io2) que não se aplicam.
* Ambientes com política técnica específica.

Recomenda-se validar requisitos de performance antes da alteração.