AWS RDS (Relational Database Service)

O Amazon RDS é o serviço gerenciado de bancos relacionais da AWS, responsável por provisionar, operar, fazer patching, backup e failover de instâncias de banco sem que o time administre o sistema operacional ou o mecanismo de replicação. Em produção, o RDS é o padrão de partida para sistemas transacionais: remove semanas de trabalho de infraestrutura, embute automações de durabilidade que times internos raramente implementam com a mesma consistência e integra-se nativamente a CloudWatch, IAM, KMS e Secrets Manager. O serviço não elimina a responsabilidade pelo desenho do esquema, pelos índices e pelo tuning de consultas, que continuam sendo a parte do banco que mais causa incidentes. Compreender os componentes administráveis, como classes de instância, tipos de volume, Multi-AZ, backups, parameter groups e janelas de manutenção, é o que separa uma operação de RDS madura de uma instância provisionada por padrão. Este arquivo detalha esses componentes e a lógica de escolha entre engines.

O que o RDS abstrai e o que permanece com o time

O RDS abstrai a camada operacional do banco: instalação, patching do SO e do engine, backups automatizados, replicação e failover, escalonamento de storage e criptografia em repouso. O time mantém a responsabilidade pelo que roda dentro do banco: modelagem de dados, índices, migrações de esquema, tuning de queries, gerenciamento de usuários e definição de parâmetros do engine.

Essa divisão orienta os limites do diagnóstico em incidente: latência de disco e failover são assuntos do serviço e de suas métricas; consultas lentas e locks são do time de aplicação e aparecem nas views do engine e no Performance Insights, não em tickets para o provedor.

Engines suportados

Para sistemas novos, PostgreSQL e MySQL cobrem a imensa maioria dos casos com custo de licença zero; a decisão entre eles é de competência do time e do ecossistema de ferramentas. Oracle e SQL Server entram quando há legado, dependência de features proprietárias ou mandato corporativo, e o preço por hora reflete o licenciamento embutido.

Classes de instância e armazenamento

A classe de instância define CPU e memória: as famílias M são de propósito geral, R favorecem memória para working sets grandes e buffers, e T são burstables adequadas apenas a ambientes não críticos, pois o esgotamento de créditos de CPU em produção é uma armadilha clássica. O armazenamento é gerenciado em três tipos: gp3 permite provisionar IOPS e throughput de forma independente e é o padrão recomendado; io1 e io2 Block Express provisionam IOPS altíssimas para bancos com SLA de latência rigoroso; e os tipos magnéticos antigos não têm lugar em produção.

# Cria uma instância PostgreSQL de produção em Multi-AZ com gp3 e criptografia
aws rds create-db-instance \
  --db-instance-identifier producao-pedidos \
  --engine postgres \
  --engine-version 17.2 \
  --db-instance-class db.r7g.xlarge \
  --allocated-storage 200 \
  --storage-type gp3 \
  --iops 6000 \
  --storage-throughput 500 \
  --multi-az \
  --db-subnet-group-name prod-subnets \
  --vpc-security-group-ids sg-0pedidos \
  --master-username admin \
  --manage-master-user-password \
  --backup-retention-period 14 \
  --storage-encrypted \
  --kms-key-id arn:aws:kms:sa-east-1:123456789012:key/prod-key

O dimensionamento inicial deve partir de métricas do sistema atual, e o alerta essencial é a métrica BurstBalance nos casos de gp2, substituída em gp3 por IOPS provisionadas explícitas, que transformam gargalo de disco em item de configuração observável e previsível.

A migração de gp2 para gp3 é geralmente uma economia imediata com igual ou melhor desempenho, e deve constar de qualquer revisão de custo de produção com instâncias legadas.

Multi-AZ: alta disponibilidade

O Multi-AZ cria uma instância standby sincronizada em outra zona de disponibilidade e mantém a réplica na sombra do primário. O failover é automático: o endpoint de conexão permanece o mesmo, um DNS aponta para a instância ativa, e a troca acontece em minutos quando o primário falha ou durante a janela de manutenção, transformando patches em eventos de mitigação de risco. O standby não serve leituras; sua única função é disponibilidade.

Para escala de leitura, o mecanismo correto são as read replicas, cobertas em arquivo próprio, que podem inclusive operar em combinação com Multi-AZ. A confusão entre os dois é comum e caríssima: Multi-AZ é resiliência, réplica de leitura é escala, e exigências de disponibilidade contratual em produção pedem Multi-AZ habilitado desde o primeiro dia.

Automated backups e snapshots

Os automated backups fazem backup diário completo mais registro de transações para permitir point-in-time recovery com precisão de segundos dentro do período de retenção, configurável até 35 dias. Os snapshots manuais são cópias explícitas que persistem até serem deletadas, úteis antes de migrações arriscadas e para retenção de longo prazo. Ambos são incrementais em nível de bloco e custam storage, o que torna a política de retenção uma decisão de custo real.

Em produção, o padrão maduro combina retenção automatizada de 7 a 14 dias para recuperação operacional, snapshots mensais copiados para outra região com criptografia própria para desastre, e validação periódica de restauração em ambiente de teste, pois backup não testado não é backup. A cópia cross-region de snapshots e a replicação automatizada de backups cobrem o requisito de continuidade sem ferramentas externas.

O custo do storage de backup cresce com a retenção e o volume de mudanças no banco; monitorar a métrica de storage de backup e ajustar a retenção conforme política de conformidade evita surpresas na fatura. Snapshots deletáveis duplicados em regiões e contas de teste são o item mais comum de desperdício identificado em revisões de custo.

Parameter groups, option groups e Performance Insights

Os parameter groups configuram o engine: tuning de conexões, memória por buffer, timeouts e configurações de log. Alterações em parâmetros estáticos exigem reboot, o que exige janela e plano; parâmetros dinâmicos aplicam-se a quente. O option group acrescenta features específicas de engine, como transparent data encryption no SQL Server e Oracle. Ambos devem ser versionados em infraestrutura como código, com um parameter group por ambiente, e nunca alterados direto em produção sem passagem por ambiente de homologação.

O Performance Insights carrega a principal fonte de diagnóstico: dashboards de DB load por query, waits e usuários, com retenção gratuita de um dia e estendida por assinatura. Ele responde a pergunta que o CloudWatch não responde sozinho: qual consulta está consumindo o banco agora. Combinado com as métricas padrão de CPU, IOPS, conexões e espaço em disco, fecha o ciclo de observabilidade do banco gerenciado.

Em MySQL e PostgreSQL, complementar o Performance Insights com slow query log direcionado para CloudWatch Logs permite análise histórica de regressões de consulta, e o Enhanced Monitoring oferece granularidade de SO, com processos e utilização real de memória, quando a investigação exige profundidade além das métricas do engine.

Métricas essenciais e alarmes de produção

Manutenção e upgrade de versão

O RDS aplica patches de segurança na janela de manutenção configurada, e minor version upgrades podem ser automáticos ou manuais. Em Multi-AZ, o patch aplica-se ao standby primeiro, com failover e aplicação no antigo primário, o que reduz a janela efetiva de indisponibilidade. Major version upgrades exigem planejamento próprio: upgrade em réplica ou snapshot restore para validar, teste de compatibilidade de aplicação e plano de rollback com snapshot prévio.

Em produção, a política saudável é: auto minor upgrade habilitado com janela fora de horário de pico, acompanhamento do calendário de deprecação de versões do engine, e um runbook de major upgrade ensaiado antes de executar. Ignorar deprecações até a última hora transforma uma rotina de manutenção em projeto de emergência.

Escolha de engine e forma de consumo por caso

O Aurora merece menção explícita na fronteira do RDS: é compatível com MySQL e PostgreSQL, mas com storage distribuído próprio, failover em segundos e até 15 réplicas de leitura de baixa latência. Vale a migração quando os requisitos superam o RDS clássico e ainda não justificam bancos distribuídos como DynamoDB ou Spanner.

Erros comuns e boas práticas

• Usar instâncias T burstable em produção e sofrer com esgotamento de créditos de CPU em picos; prefira classes M ou R com monitoramento de utilização.
• Habilitar Multi-AZ apenas depois do primeiro incidente de disponibilidade; o custo incremental é pequeno perto do custo de downtime.
• Deixar retenção de backup em 1 dia ou zero; configure 7 a 14 dias conforme política de recuperação, e valide restaurações periodicamente.
• Alterar parameter groups diretamente em produção sem homologação; version os grupos em IaC e teste antes.
• Monitorar apenas CPU; acompanhe conexões, IOPS, throughput de disco, espaço em disco e DB load do Performance Insights.
• Deixar storage com alarme de espaço em disco faltando; o esgotamento congela o banco e causa incidente evitável.
• Aplicar major upgrade direto em produção sem ensaio; teste em clone a partir de snapshot e defina rollback.
• Usar senha de master embutida em IaC em texto plano; prefira manage-master-user-password com integração ao Secrets Manager.
• Expor o banco em sub-rede pública por conveniência; a instância de produção fica em sub-redes privadas com acesso por bastion ou tunneling.

Como prática consolidada, provisione tudo em infraestrutura como código, criptografe sempre em repouso com KMS, isole o banco em sub-redes privadas com security group restrito, gerencie credenciais com o Secrets Manager e trate a combinação de Multi-AZ, backups com retenção definida e Performance Insights como o kit mínimo de produção para qualquer instância RDS que atenda usuários reais.