# RDS: Expiração de Instância Reservada do RDS

> Esta regra identifica Reserved DB Instances do Amazon RDS que estão próximas da data de expiração, com base no período configurado na regra.
>
> O objetivo é permitir planejamento antecipado de renovação, alteração de estratégia ou descontinuação do compromisso financeiro.

***

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

Reserved Instances (RIs) do RDS oferecem desconto significativo em comparação ao modelo On-Demand, em troca de compromisso de 1 ou 3 anos.

Quando uma reserva expira:

* O desconto deixa de ser aplicado.
* A cobrança volta automaticamente para o valor On-Demand.
* Pode ocorrer aumento inesperado no custo mensal.

Sem monitoramento ativo:

* O time financeiro perde previsibilidade.
* O time técnico pode não renovar a reserva a tempo.
* O custo pode aumentar abruptamente no mês seguinte.

Esta regra atua de forma preventiva no ciclo de gestão de compromissos financeiros.

***

**Detalhamento técnico da regra**

A regra executa análise regional das Reserved DB Instances.

***

**Como a regra é executada**

1. Autentica na conta AWS por região.
2. Lista as reservas via `describe_reserved_db_instances`.
3. Aplica filtros de tag (inclusão/exclusão).
4. Para cada reserva:
   * Identifica a duração contratada (`Duration`):
     * 1 ano → 365 dias
     * 3 anos → 1095 dias
   * Calcula a data de expiração:

     ```
     Expiration = StartTime + Duration
     ```
   * Calcula os dias restantes até a expiração.
5. Se:
   * A reserva ainda estiver ativa (`expiration > now`)
   * E os dias restantes forem menores ou iguais ao período configurado → A reserva é sinalizada.

***

**Lógica aplicada**

Uma reserva será sinalizada quando:

```
Dias até expiração ≤ período configurado
E
Reserva ainda não expirou
```

Exemplo:

Se configurado para 30 dias, qualquer reserva que expire nos próximos 30 dias será listada.

***

**Campos analisados**

* `ReservedDBInstancesOfferingId`
* `ReservedDBInstanceId`
* `DBInstanceClass`
* `DBInstanceCount`
* `StartTime`
* `Duration`
* `State`
* `Tags`

Campo calculado:

* `EndTime` (StartTime + Duration)

***

**Parâmetros considerados na busca**

APIs utilizadas:

* `rds:DescribeReservedDBInstances`

Condições técnicas:

* Conversão da duração:
  * 31536000 segundos ou “1” → 365 dias
  * 94608000 segundos ou “3” → 1095 dias
* Comparação de data atual com data de expiração.

***

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

Período Avaliado (Filtro Temporal): A regra avalia o tempo restante até a data de expiração da Reserved Instance.

O intervalo de análise corresponde aos dias configurados no período da regra.

Padrão é configurado para 30 dias, a regra listará todas as reservas que irão expirar nos próximos 30 dias.

Esse parâmetro permite alinhar a antecedência do aviso com o ciclo interno de aprovação financeira.

***

**Intervalo de Análise**

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

***

**Aderência às melhores práticas**

Esta regra é da categoria Economia.

Não representa savings direto, mas previne:

* Perda de desconto contratual.
* Aumento inesperado de custo.
* Desalinhamento de cobertura de capacidade.

Está alinhada com boas práticas de FinOps:

* Gestão ativa de compromissos.
* Planejamento de capacidade.
* Previsibilidade orçamentária.

***

**Impacto financeiro indireto**

Se uma reserva expirar sem renovação:

```
Novo custo = Preço On-Demand – Preço com desconto de RI
```

Dependendo da classe de instância, a diferença pode variar entre:

* 30% a 60% de aumento de custo.

***

**Exemplo prático**

Cenário:

* RDS db.m5.large
* Reserva de 1 ano
* Desconto médio: 40%
* Custo On-Demand: $300/mês
* Custo com RI: $180/mês

Se a reserva expirar:

```
Impacto mensal = 300 – 180
Impacto mensal = $120
Impacto anual = $1.440
```

***

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

* Revisar histórico de utilização antes de renovar.
* Avaliar migração para Savings Plans quando aplicável.
* Verificar se a classe da instância ainda é adequada.
* Planejar renovação com antecedência mínima de 30 a 60 dias.
* Revisar estratégia de pagamento (All Upfront, Partial, No Upfront).
* Avaliar possibilidade de rightsizing antes de renovar o compromisso.

Possíveis exceções:

* Instâncias que serão descontinuadas.
* Migração planejada para arquitetura diferente.
* Substituição por Aurora ou outro engine.

Recomenda-se alinhar decisão com times de FinOps, arquitetura e financeiro.