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
A regra autentica na conta AWS e percorre todas as regiões ativas.
Lista instâncias via
rds:DescribeDBInstances.Filtra apenas instâncias:
Com status
available.Com
MultiAZ = False.
Obtém as tags associadas via
list_tags_for_resource.Identifica se o ambiente é Dev com base:
No nome da instância.
No valor das tags.
Aplica filtro temporal baseado na data de criação.
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
DBInstanceIdentifierconté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
DBInstanceIdentifierDBInstanceStatusMultiAZInstanceCreateTimeEngineEngineVersionDBInstanceClassStorageTypeTags
Parâmetros considerados na busca
API:
rds:DescribeDBInstancesAPI:
rds:ListTagsForResourceEscopo: 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
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:
Storage mensal:
Total mensal:
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.
Last updated