RDS e Aurora costumam ser o segundo maior bloco da fatura depois de EC2 — e são mais sensíveis a mudanças bruscas. Este guia foca em decisões que você pode aplicar com janela de manutenção e métricas, não em “trocar tudo no fim de semana”.
O que realmente compõe o custo
| Componente | RDS | Aurora |
|---|---|---|
| Instância (compute) | Classe + horas | ACUs ou instâncias |
| Storage | gp2/gp3/io, cresce automaticamente | Volume cluster + I/O |
| IOPS provisionado | gp3/io1 | Incluído no modelo Aurora |
| Backups | Além do free tier do tamanho do DB | Snapshot storage |
| Multi-AZ | ~2× compute em muitos casos | Réplicas de leitura |
| Data transfer | Entre AZs, para apps, snapshots cross-region | Idem |
Antes de reduzir classe, confira se o problema não é storage oversized ou backup retention infinita.
Passo 1: métricas que importam (14 dias)
No CloudWatch, para a instância ou cluster:
CPUUtilization(média e p95)FreeableMemoryDatabaseConnectionsReadIOPS/WriteIOPS/DiskQueueDepthFreeStorageSpace(RDS) ouVolumeBytesUsed(Aurora)
Regra prática: CPU média < 30% e memória folgada → candidate a downsize. DiskQueueDepth alto com IOPS no teto → problema de storage, não de CPU.
Passo 2: storage (ganho rápido e seguro)
RDS em gp2
- Migre para gp3: mesma durabilidade, IOPS desacoplados do tamanho do volume, costuma ficar mais barato.
- Ajuste IOPS provisionado só se métricas justificarem — IOPS ocioso é dinheiro jogado fora.
Aurora
- Revise auto-scaling de ACU (Serverless v2) com teto máximo realista.
- Réplicas de leitura ociosas: cada uma é compute adicional.
Passo 3: right-sizing de instância
- Snapshot manual antes de qualquer mudança.
- Teste em staging com carga sintética ou restore do snapshot.
- Reduza uma classe por vez (ex.:
db.r6g.large→db.r6g.medium). - Janela de manutenção em horário de baixo tráfego.
- Monitore 48–72 h: latência de queries, conexões, deadlocks.
Graviton (r6g/m6g): se ainda está em r5/m5, benchmark em staging — muitas cargas PostgreSQL/MySQL economizam 20–35% no compute.
Passo 4: Multi-AZ e réplicas
- Prod crítico: Multi-AZ continua valendo o custo.
- Dev/staging: instância single-AZ com backup automático costuma bastar.
- Réplicas de leitura: desligue as que não recebem tráfego de leitura (métrica
ReplicaLag+ conexões).
Passo 5: backups e retenção
- Retenção de 35 dias em todos os ambientes multiplica storage de snapshot.
- Política sugerida: 7 dias dev, 14–30 dias prod, conforme compliance.
- Snapshots manuais antigos (“só por garantia”) — liste e apague os órfãos.
Passo 6: compromissos (RI / Savings Plan)
Depois de estabilizar classe e storage:
- Compute de RDS elegível a Reserved Instance (1 ou 3 anos) se baseline estável.
- Compare com Database Savings Plan se mistura RDS + Aurora + outros DBs.
Leia: Reserved Instances vs Savings Plans.
Erros que já vi em produção
- Downsize agressivo em banco com picos de relatório noturno (batch sem auto-scale).
- Aurora Serverless v2 com teto de ACU no máximo “para não ter problema”.
- Logs de aplicação gravados no mesmo volume sem partition/rotate.
- Conexões vazando (pool mal configurado) forçando classe maior.
Ferramentas neste site
- Checklist de auditoria
- Escolher instância EC2 — apps e workers que falam com o banco
- Calculadora de economia
Por Mauricio Nascimento de Oliveira. Teste mudanças em staging; este conteúdo é educacional, não substitui runbook da sua equipe.