# RDS: RDS sem start/stop - Ambientes não produtivos

> Esta regra identifica instâncias Amazon RDS classificadas como ambiente de desenvolvimento (Dev, Homologação, Staging ou similares) que:
>
> * Estão em estado `available`.
> * Não utilizam configuração Multi-AZ.
> * Possuem idade superior ao período definido no filtro temporal da regra.
>
> O objetivo é detectar bancos de dados não produtivos que permanecem ativos por longos períodos sem necessidade operacional clara.

***

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

Ambientes de desenvolvimento e homologação são criados para:

* Testes temporários.
* Validação de novas funcionalidades.
* POCs e experimentações.
* Projetos de curta duração.

Entretanto, é comum que esses ambientes não sejam desativados após o término do projeto.

**Impactos diretos:**

* Consumo desnecessário de compute (instância RDS).
* Custos recorrentes de armazenamento.
* Custos de backup automático.
* Custos de I/O.
* Risco de exposição de dados sensíveis em ambientes menos controlados.

Além do impacto financeiro, há impacto de governança:

* Ambientes Dev frequentemente não seguem padrões rigorosos de segurança.
* Podem conter dados mascarados incorretamente.
* Podem permanecer fora de compliance por longos períodos.

Essa regra permite identificar oportunidades claras de desligamento ou consolidação.

***

**Detalhamento técnico da regra**

A regra executa varredura regional nas instâncias RDS da conta AWS.

**Como a regra é executada**

1. A regra autentica na conta AWS e percorre todas as regiões ativas.
2. Lista instâncias via `rds:DescribeDBInstances`.
3. Filtra apenas instâncias:
   * Com status `available`.
   * Com `MultiAZ = False`.
4. Obtém as tags associadas via `list_tags_for_resource`.
5. Identifica se o ambiente é Dev com base:
   * No nome da instância.
   * No valor das tags.
6. Aplica filtro temporal baseado na data de criação.
7. Caso todos os critérios sejam atendidos, a instância é sinalizada.

***

**Lógica aplicada para identificar ambiente Dev**

A regra classifica como ambiente de desenvolvimento quando:

* O `DBInstanceIdentifier` contém palavras como:
  * dev
  * desenvolvimento
  * hml
  * homol
  * homologacao
* Ou quando alguma tag possui valores contendo:
  * dev
  * development
  * staging
  * stg
  * hml
  * homol

A verificação é case insensitive.

***

**Campos analisados**

* `DBInstanceIdentifier`
* `DBInstanceStatus`
* `MultiAZ`
* `InstanceCreateTime`
* `Engine`
* `EngineVersion`
* `DBInstanceClass`
* `StorageType`
* `Tags`

***

**Parâmetros considerados na busca**

* API: `rds:DescribeDBInstances`
* API: `rds:ListTagsForResource`
* Escopo: Regional
* Condições técnicas:
  * Instância disponível (`available`)
  * Não MultiAZ
  * Identificada como ambiente Dev
  * Idade compatível com filtro temporal

***

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

Período Avaliado (Filtro Temporal): A regra avalia a data de criação da instância (`InstanceCreateTime`). O intervalo de análise corresponde ao operador do período do filtro (ex: "maior que") combinado com os dias do período do filtro definidos na configuração da regra. Se configurado para "Maior que 15 dias", a regra analisará apenas instâncias criadas há mais de 15 dias que sejam classificadas como ambiente de desenvolvimento e estejam ativas.

> Esse parâmetro pode ser customizado conforme a necessidade do cliente, permitindo alinhamento com políticas internas de retenção de ambientes temporários.

***

**Intervalo de Análise**

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

***

**Cálculo de Savings**

Esta regra é da categoria ECONOMIA.

O savings é calculado considerando o custo mensal recorrente da instância RDS identificada como desnecessária.

***

**Fórmula Conceitual**

```
Savings Mensal = Custo Compute + Custo Armazenamento + Custo Backup + Custo I/O
```

Onde:

* Compute = valor horário da classe da instância × 730 horas.
* Armazenamento = GB provisionado × preço por GB.
* Backup = armazenamento adicional de backup (quando aplicável).
* I/O = dependendo do tipo de storage.

***

**Campo de custo utilizado**

No Billing AWS, os principais campos são:

* Service: AmazonRDS
* Line Item Type: Usage
* Usage Type:
  * InstanceUsage
  * RDS:StorageUsage
  * RDS:ChargedBackupUsage
* Campo financeiro considerado:
  * Unblended Cost
  * Ou Amortized Cost, conforme modelo financeiro adotado.

***

**Elementos considerados**

* Classe da instância (`DBInstanceClass`).
* Região.
* Tipo de armazenamento.
* Tamanho provisionado.
* Horas mensais médias (730h).
* Não há projeção futura automática, o cálculo representa economia recorrente mensal caso a instância seja desativada.

***

**Exemplo aplicado ao Billing**

Cenário:

Instância Dev:

* Classe: db.t3.medium
* Custo: $0.067 por hora
* Armazenamento: 100 GB
* Preço storage: $0.115 por GB

Compute mensal:

```
0.067 × 730 = $48.91
```

Storage mensal:

```
100 × 0.115 = $11.50
```

Total mensal:

```
48.91 + 11.50 = $60.41
```

Savings potencial:

* $60.41 por mês
* $724.92 por ano

Impacto percentual dependerá do total de custo RDS da conta.

***

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

* Priorizar instâncias Dev com maior classe (maior impacto financeiro).
* Implementar desligamento automático fora do horário comercial.
* Utilizar Aurora Serverless ou RDS Serverless para ambientes temporários.
* Aplicar políticas de lifecycle para ambientes Dev.
* Garantir mascaramento de dados sensíveis.
* Validar dependências antes de desligar (jobs, integrações, BI).
* Avaliar conversão para snapshot antes da exclusão definitiva.

Possíveis falsos positivos:

* Ambientes Dev permanentes utilizados para integração contínua.
* Ambientes de teste de carga de longa duração.

Recomenda-se validação com o time responsável antes da desativação.

***