Como reduzir custos na AWS e no RDS PostgreSQL sem criar uma indisponibilidade

Otimização de custos não é comprar um desconto uma vez. É um ciclo: atribuir gastos, explicar a demanda, remover desperdício, aumentar eficiência, comprometer apenas a base estável e comprovar que a confiabilidade não piorou. Em bancos, a ordem é decisiva porque um downsize agressivo transforma economia em incidente.

Monte um modelo de custo que a engenharia explique

Separe o custo mensal em horas de instância, storage, IOPS/throughput provisionados, backups e snapshots, transferência, monitoramento e suporte. Aloque por contas e tags de custo ativadas. Quando possível, acompanhe custo por cliente, requisição, transação ou GB; uma fatura maior pode ser eficiente se a carga útil cresceu mais.

Use economia unitária para separar crescimento de desperdício

Custo de banco por unidade = custo mensal atribuível / unidades úteis. A unidade pode ser pedido, tenant ativo, pagamento liquidado ou milhão de chamadas. Se o gasto cresce 20%, as unidades 40% e o SLO permanece, a eficiência melhorou. Se o gasto fica estável e as transações caem 30%, o custo unitário piorou. Mantenha overhead compartilhado visível e documente a alocação; escondê-lo em um produto cria falsos vencedores.

Meça antes do rightsizing

Analise pelo menos um ciclo completo do negócio. CPU não basta: observe freeable memory e swap, pico de conexões, IOPS e throughput, queue depth, latência de storage, arquivos temporários, cache, WAL e lag. Compare p95 e p99, não só médias. Redimensione em janela, com rollback testado, e acompanhe os planos após mudar CPU e memória.

Defina política de folga por modo de falha. CPU tolera picos curtos; memória ou conexões podem esgotar abruptamente; storage cheio pode bloquear escrita; lag pode invalidar recuperação. O tamanho candidato precisa passar pico normal e um cenário degradado, como um reader indisponível ou manutenção sobreposta. Use a granularidade da falha: média diária de CPU não valida risco de saturação por cinco minutos.

Otimize em ordem crescente de compromisso

1. Elimine desperdício: snapshots órfãos, réplicas sem uso, bancos de teste abandonados e retenção excessiva.
2. Agende não produção: pare recursos elegíveis fora do expediente e automatize exceções.
3. Faça rightsizing: altere família/tamanho e storage com base na folga observada.
4. Melhore a carga: corrija queries caras, índices ausentes, conexões excessivas, bloat e vacuum ineficaz que exigem infraestrutura maior.
5. Comprometa a base: compre Reserved DB Instances somente para uso estável e compreendido.

O Cost Optimization Hub reúne recomendações de exclusão, scale-in, rightsizing, gerações novas, Graviton e reservas. Elas alimentam a análise da engenharia; não são aprovação automática.

Trate cada recomendação como proposta de mudança

Registre baseline, alteração, economia esperada, SLOs afetados, janela, rollback e período de observação. Migração para Graviton exige extensões/agentes compatíveis e carga representativa. Mudança de storage exige validar latência e throughput durante checkpoint, vacuum e backup. Automação pode criar o ticket; o gate de evidência aprova produção.

Entenda o que a reserva não desconta

Reserved DB Instances podem reduzir o compute elegível com opções sem adiantamento, adiantamento parcial ou integral. A AWS informa que a reserva não desconta storage, backup ou I/O. Compre para a base permanente, preserve flexibilidade para picos e confirme engine, Region, classe e tipo de deployment antes do compromisso.

Acompanhe cobertura (quanto do uso elegível recebe benefício) e utilização (quanto do compromisso comprado é consumido). Cobertura alta e utilização baixa significa capacidade pré-paga ociosa. Faça rightsizing e elimine desperdício antes de comprometer; senão o desconto congela a ineficiência anterior.

Deixe o PostgreSQL mais barato, não apenas menor

• Use pg_stat_statements para ordenar tempo acumulado, chamadas, I/O temporário e blocos.
• Corrija índices ausentes ou redundantes com planos antes/depois; índice desnecessário também cobra escrita, vacuum e storage.
• Controle bloat e ajuste autovacuum por tabela grande ou com muita alteração.
• Use pool de conexões e timeouts realistas na aplicação.
• Separe requisito de retenção de “guardar todo snapshot para sempre”.

Priorize SQL pela oportunidade total, não pela execução isolada mais lenta. Uma query de 20 ms chamada 50 milhões de vezes pode consumir mais CPU que um relatório de dez segundos executado duas vezes. Compare chamadas × tempo médio, blocos lidos, bytes temporários e WAL. Valide índice com seletividade e custo de escrita; remover um redundante reduz ao mesmo tempo storage, WAL, cache e vacuum.

Faça uma revisão FinOps mensal

Dê a cada ação um responsável, economia mensal prevista, custo de implementação, risco e métrica de validação. Revise previsto versus realizado, anomalias, ociosos, candidatos a rightsizing e cobertura/utilização dos compromissos. Registre recomendações recusadas e o motivo. Economia sem controle durável costuma desaparecer no mês seguinte.

Como o PG Monitoring ajuda a reduzir custo com segurança

O PG Monitoring conecta a demanda AWS aos mecanismos PostgreSQL que a criam. Ele ordena workload ao longo do tempo, detecta regressões, mostra I/O temporário e pressão de conexões, encontra dívida de vacuum/bloat, acompanha replicação e prevê capacidade. Assim, uma recomendação FinOps vira mudança testável: registrar baseline, corrigir ou redimensionar, comparar os mesmos fingerprints e sinais de SLO e continuar procurando regressão.