O Amazon RDS (Relational Database Service) é um serviço de banco de dados gerenciado pela AWS que simplifica a configuração, a operação e o escalonamento de bancos relacionais na nuvem. Para um desenvolvedor full stack, ele tira o peso de administrar o servidor (EC2) e deixa o foco nas queries e na estrutura dos dados.

Esta nota tem duas partes. A primeira explica o que o RDS é e quanto custa. A segunda, “como usar de verdade”, mostra como criar uma instância, ligar Multi-AZ, criar réplica de leitura, colocar um RDS Proxy na frente do banco e restaurar dados, com os comandos da AWS CLI e o que cada parâmetro faz.

1. Principais características

O RDS automatiza tarefas administrativas que, num EC2 comum, exigiriam trabalho manual constante.

• Motores suportados: PostgreSQL, MySQL, MariaDB, Oracle, SQL Server e o Amazon Aurora, que é um motor próprio da AWS compatível com MySQL e PostgreSQL.
• Gerenciamento: a AWS aplica patches de sistema operacional e do motor, cuida das atualizações de versão e faz backups automáticos.
• Multi-AZ (alta disponibilidade): com uma opção, o RDS cria uma réplica síncrona numa outra zona de disponibilidade. Se o primário falhar, a AWS promove a réplica, e o sistema volta a responder sem intervenção manual.
• Escalabilidade de leitura: você pode criar réplicas de leitura, que recebem as escritas do primário de forma assíncrona. Consultas pesadas, como relatórios, podem ir para essas réplicas, e o primário fica livre para as escritas.

O diagrama mostra as duas formas de copiar dados. A réplica de standby, em azul, recebe as escritas de forma síncrona e serve só para failover, não para leitura. A réplica de leitura, em verde, recebe as escritas depois, de forma assíncrona, e é a que aceita consultas de relatório. Leia a seta do primário para o standby como “o commit só termina depois que o standby confirma”, e a seta para a réplica como “a réplica chega depois”. Essa diferença explica quase tudo o que a seção de réplicas diz adiante.

2. Precificação (billing)

A cobrança do RDS é parecida com a do EC2, com componentes próprios para o armazenamento.

• Instância: você paga pelo tempo em que a instância fica ligada. Existem classes de uso geral (como as T3) e otimizadas para memória (como as R5), mais indicadas para bancos grandes.
• Armazenamento: você paga pelo espaço alocado por mês. Se você aloca 100 GB e usa 10 GB, paga pelos 100.
• IOPS: em bancos com carga alta, é possível pagar por operações de disco garantidas, para evitar lentidão em pico.
• Transferência de dados: dados que saem do RDS para a internet são cobrados. A transferência entre uma aplicação e o RDS na mesma região costuma ser gratuita, e a documentação de réplicas confirma que a replicação entre o primário e uma réplica na mesma região não tem cobrança de transferência.
• Réplicas: uma réplica é cobrada como uma instância comum da mesma classe.
• Instâncias reservadas: se o sistema vai ficar no ar por anos, é possível reservar a instância por 1 ou 3 anos. O desconto de até 60% citado em versões anteriores desta nota não foi confirmado nesta revisão.

3. Quando usar o RDS?

Use o RDS sempre que o projeto exigir um banco relacional estável.

• Em vez de instalar o banco num EC2: se você não quer fazer backups manuais nem gastar tempo com patches e segurança do motor, o RDS resolve.
• Consistência de dados: em sistemas em que a integridade entre entidades é crítica, como questões, bancas e provas no AutoBanca, o banco relacional com chaves e transações é o que sustenta as regras.
• Crescimento previsível: quando você precisa crescer em armazenamento ou em CPU e memória com poucos cliques e pouca indisponibilidade.

RDS vs Aurora

O Amazon Aurora faz parte da família RDS, mas é um motor reconstruído pela AWS. A AWS fala em desempenho de até 3 vezes o de um PostgreSQL ou MySQL padrão, e esse número depende da carga. Não verifiquei esse valor nesta revisão. Para quem desenvolve, a interface é parecida, mas a arquitetura de armazenamento e a recuperação de falhas são diferentes.

Como usar de verdade

Criando uma instância pela CLI

O comando abaixo cria uma instância PostgreSQL com backups automáticos ligados, Multi-AZ e senha gerenciada pelo próprio RDS.

aws rds create-db-instance \
  --db-instance-identifier loja-prod \
  --db-instance-class db.t3.micro \
  --engine postgres \
  --allocated-storage 20 \
  --master-username app_admin \
  --manage-master-user-password \
  --backup-retention-period 7 \
  --multi-az \
  --db-subnet-group-name sg-loja-privada \
  --vpc-security-group-ids sg-0123456789abcdef0 \
  --storage-encrypted

Cada parâmetro tem um motivo. --db-instance-identifier dá o nome da instância dentro da conta. O banco que roda dentro dela recebe outro nome, definido por --db-name. --db-instance-class define CPU e memória, e db.t3.micro é só para testes. --engine postgres escolhe o motor, e a versão exata deve ser escolhida com aws rds describe-db-engine-versions --engine postgres, comando que não executei nesta revisão. --allocated-storage está em GB.

--manage-master-user-password é a opção que eu recomendo sempre. Em vez de você digitar a senha de admin na linha de comando, que fica no histórico do shell, o RDS a gera e a guarda no Secrets Manager. --backup-retention-period 7 define quantos dias de backup automatizado ficam guardados. Qualquer valor acima de zero liga os backups. Zero desliga. A faixa máxima de dias não foi confirmada nesta revisão. --multi-az cria a instância com um standby em outra zona. --db-subnet-group-name e --vpc-security-group-ids colocam a instância numa rede privada, acessível só de dentro da VPC. --storage-encrypted cifra o armazenamento.

O tempo de criação varia com o tamanho e a configuração, e o comando retorna antes de a instância estar pronta. Depois que ela fica disponível, o endpoint aparece em aws rds describe-db-instances --db-instance-identifier loja-prod, no campo Endpoint. Esse endpoint é o nome DNS que a aplicação usa para conectar.

Multi-AZ e failover

Multi-AZ tem duas formas. A Multi-AZ DB instance deployment, que é a usada no comando acima, tem um standby síncrono que não aceita leitura. A Multi-AZ DB cluster deployment tem dois standbys que aceitam leitura, e os motores aceitos são outros. Quando o texto fala “Multi-AZ” sem mais detalhes, está falando da primeira.

Para ligar Multi-AZ numa instância que já existe, use:

aws rds modify-db-instance \
  --db-instance-identifier loja-prod \
  --multi-az \
  --apply-immediately

--apply-immediately aplica a mudança agora, em vez de esperar a próxima janela de manutenção. Essa conversão pode causar uma parada curta.

Para testar o failover em uma instância Multi-AZ, sem esperar uma falha real:

aws rds reboot-db-instance \
  --db-instance-identifier loja-prod \
  --force-failover

O comando reinicia a instância e força a promoção do standby. Use-o num ambiente de homologação antes de qualquer coisa. Em produção, o failover derruba as conexões abertas, e a aplicação precisa abrir conexões novas. O tempo que o processo leva não foi confirmado nesta revisão, e a documentação que consultei não trouxe o trecho com esse número.

O desenho mostra o momento da falha. A aplicação usa o endpoint DNS, um nome que resolve para o endereço atual do banco. Antes da falha, o nome aponta para o primário, na zona A. Quando o primário falha, marcado em rosa, o RDS promove o standby, na zona B, e o nome passa a apontar para ele. A seta tracejada antiga mostra o caminho que deixou de valer. Por isso a aplicação não deve guardar IPs, e sim o endpoint, e deve tentar reconectar quando uma conexão cai.

Réplicas de leitura

Uma réplica de leitura é uma cópia do primário que recebe as mudanças de forma assíncrona. Isso tem duas consequências práticas. A primeira é que a leitura pode estar atrasada em relação à escrita. A segunda é que a réplica não substitui um backup, porque um DELETE no primário também chega à réplica.

aws rds create-db-instance-read-replica \
  --db-instance-identifier loja-relatorios \
  --source-db-instance-identifier loja-prod

Esse comando faz o RDS tirar um snapshot do primário e criar a réplica a partir dele. Segundo a documentação, o primário sofre uma suspensão de E/S de cerca de um segundo no início. Se o primário for Multi-AZ, o snapshot é tirado do standby, e essa suspensão não acontece. Para promover a réplica a uma instância independente, por exemplo num cenário de recuperação de desastre:

aws rds promote-read-replica \
  --db-instance-identifier loja-relatorios

Depois de promovida, ela deixa de replicar do primário e passa a aceitar escritas. Não há reversão automática.

O diagrama mostra o problema mais comum. A aplicação atualiza o pedido 42 para “pago” no primário. A réplica ainda mostra “aguardando”, porque a replicação é assíncrona. Se a mesma aplicação lê logo depois da escrita e cai na réplica, ela vê o dado antigo, marcado em rosa. A regra prática é que leituras que precisam refletir uma escrita recente devem ir ao primário. Relatórios, buscas e listagens que toleram atraso podem usar a réplica.

A documentação do RDS para PostgreSQL indica até 15 réplicas diretas por instância de origem na mesma região, segundo o resumo que consultei. Não abri a página completa dessa seção nesta revisão, então confirme o limite antes de dimensionar. O RDS não cria réplicas automaticamente quando a carga sobe: a escala de leitura é manual.

RDS Proxy: muitos ambientes, poucas conexões

Um banco relacional tem um número máximo de conexões simultâneas, configurado no próprio motor. Cada conexão consome memória no servidor. Quando uma aplicação com muitas instâncias ou ambientes abre conexões cada um por conta própria, o total explode. O caso típico é uma função Lambda: cada ambiente de execução abre a sua conexão e, com centenas de ambientes ao mesmo tempo, o banco recusa novas conexões.

O RDS Proxy fica entre a aplicação e o banco. Ele mantém um pool de conexões reais e as reutiliza entre os clientes, e quando o tráfego passa do limite configurado, recusa as conexões excedentes em vez de deixar o banco cair.

Seis ambientes Lambda, cada um com pool de duas conexões, chegam ao proxy. O proxy abre três conexões reais no banco e as reaproveita. O elemento rosa mostra o outro caminho: quando o limite é ultrapassado, a conexão é recusada. Repare que o desenho não tem um número fixo de conexões do lado da aplicação. A pressão cai no proxy, e o banco só vê o que o proxy decide abrir.

Para criar o proxy, é preciso uma role que permita ao proxy ler o segredo com as credenciais do banco:

aws rds create-db-proxy \
  --db-proxy-name proxy-loja \
  --engine-family POSTGRESQL \
  --auth Description="credenciais do banco loja",AuthScheme="SECRETS",SecretArn="arn:aws:secretsmanager:sa-east-1:111122223333:secret:loja-banco-AbCdEf",IAMAuth="DISABLED" \
  --role-arn arn:aws:iam::111122223333:role/rds-proxy-loja \
  --vpc-subnet-ids subnet-0aaa subnet-0bbb \
  --vpc-security-group-ids sg-0123456789abcdef0

--engine-family POSTGRESQL diz o protocolo que o proxy fala com o banco. --auth aponta o segredo com as credenciais, e AuthScheme="SECRETS" indica que o proxy usa o Secrets Manager. IAMAuth="DISABLED" desliga a autenticação IAM neste exemplo, e para exigir token IAM dos clientes é preciso ajustar esse valor, o que não foi conferido nesta revisão. --role-arn é a role que o proxy assume para ler o segredo. --vpc-subnet-ids precisa ser de subnets na mesma VPC do banco, e o proxy não pode ser público.

Depois de criado, o proxy precisa saber qual banco atende. O comando abaixo registra a instância como alvo:

aws rds register-db-proxy-targets \
  --db-proxy-name proxy-loja \
  --db-instance-identifiers loja-prod

Algumas regras da documentação valem decorar. Cada proxy aponta para uma única instância de destino, mas várias instâncias podem ter proxies. Para instâncias em replicação, o proxy só pode apontar para o primário, não para uma réplica de leitura. Cada conta pode ter até 20 proxies, e cada proxy aceita até 200 segredos associados. O proxy fica numa VPC e não é público, então o acesso vem de dentro da rede.

O proxy também tem limites de comportamento. Consultas com texto maior que 16 KB fixam a sessão a uma conexão, e a documentação lista exceções por motor. Esse fixamento, o pinning, é o que faz o proxy perder parte da economia de conexões. Se a sua aplicação usa muitas variáveis de sessão, teste antes de colocar o proxy em produção.

Backups, snapshots e restauração

Com a retenção de backup maior que zero, o RDS guarda um snapshot automático por dia dentro da janela de backup, e registra as transações entre os snapshots. Isso permite restaurar a instância para qualquer momento dentro da janela de retenção. O primeiro snapshot tem o banco inteiro, e os seguintes são incrementais, guardando só o que mudou. Snapshots manuais não são apagados quando a instância é removida, e cada região permite até 100 snapshots manuais.

Para criar um snapshot manual:

aws rds create-db-snapshot \
  --db-snapshot-identifier loja-antes-da-migracao \
  --db-instance-identifier loja-prod

Para restaurar a instância até o último instante recuperável, sem escolher um horário:

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier loja-prod \
  --target-db-instance-identifier loja-prod-restaurada \
  --use-latest-restorable-time

Para um horário específico, troque --use-latest-restorable-time por --restore-time 2026-10-27T14:31:00Z, em UTC. O ponto mais importante é que a restauração cria uma instância nova, com outro identificador e outro endpoint. Ela não sobrescreve a original. Depois de restaurar, você precisa conferir os dados e trocar o endpoint na aplicação, o que é trabalho manual.

O diagrama conta uma história. O snapshot diário guarda o banco inteiro. Os logs de transação guardam tudo o que aconteceu depois. Às 14:32, um DELETE sem WHERE apaga a tabela, e esse erro também vai para o log, em rosa. A restauração usa o snapshot e os logs até 14:31, e portanto não inclui o erro. O resultado é uma instância nova, que a aplicação passa a usar depois de conferida. Quem lê o desenho deve lembrar que a instância original continua com o erro. O conserto está na instância restaurada, e só ela deve receber o tráfego depois de conferida.

A janela de restauração depende da retenção configurada. Se a retenção é de 7 dias, o ponto mais antigo que você consegue restaurar fica a até 7 dias atrás. Por isso, a retenção é uma decisão de custo e de risco, não um detalhe.

Conectando uma função Lambda ao RDS

Uma função Lambda precisa estar na mesma VPC do banco para conseguir conectar. O acesso usa o Secrets Manager para credenciais ou a autenticação IAM. Com IAM, a função gera um token de curta duração e o usa no lugar da senha. Para isso, a role da função precisa da permissão rds-db:connect. Um trecho do exemplo oficial em Go gera o token com o SDK:

authenticationToken, err := auth.BuildAuthToken(
    context.TODO(), dbEndpoint, region, dbUser, cfg.Credentials)

Esse é o trecho que a documentação mostra, e não foi executado nesta revisão. O exemplo completo, com a configuração de TLS e a conexão, está na nota de Lambda, que também explica como o RDS Proxy reduz o número de conexões quando a função escala.

Erros comuns e como resolver

Too many connections. O banco recusou uma conexão porque o limite de conexões foi atingido. Quase sempre a causa é a soma das conexões de muitos clientes. A correção de curto prazo é reduzir o tamanho do pool de cada cliente. A de longo prazo é colocar um RDS Proxy na frente, como mostrado acima.

A aplicação não conecta. Confira três coisas: se a aplicação está na mesma VPC, se os security groups do banco e do proxy liberam a porta do motor (5432 no PostgreSQL) para o grupo de origem, e se o endpoint usado é o certo. Um erro de timeout costuma ser rede ou security group. Um erro de autenticação costuma ser senha ou token expirado.

Leitura desatualizada. A aplicação leu da réplica logo depois de escrever no primário e viu o dado antigo. A solução é mandar leituras que dependem de escrita recente para o primário, como descrito na seção de réplicas.

Conexões caídas após o failover. O failover derruba as conexões existentes. Se a aplicação não tenta de novo, o erro aparece para o usuário mesmo com o banco já de volta. Configure reconexão no pool e uma política de retentativa com intervalo crescente.

Restauração que não resolve. Quem restaura espera que o banco original volte aos dados de antes. A restauração cria outra instância. Se a aplicação continuar apontando para a antiga, o erro continua lá. Confira o endpoint depois de cada restauração.

Proxy sem efeito. Um proxy não economiza conexões se cada consulta fixa a sessão, o pinning descrito acima. Veja nas métricas do proxy se o número de conexões do lado do banco cai quando o número de clientes sobe.

Exercícios

1. Crie uma instância de teste com --backup-retention-period 1, faça um snapshot manual, apague uma tabela de teste e restaure a instância para o momento antes do DROP. Confira que a instância restaurada tem outro endpoint.
2. Crie uma réplica de leitura, escreva uma linha no primário e leia na réplica logo depois. Repita com um intervalo de alguns segundos e compare o resultado.
3. Explique por que a conexão de um proxy com seis clientes pode ser de três conexões reais no banco, e o que acontece com o sétimo cliente quando o limite configurado é atingido.

Glossário

• Multi-AZ: configuração com uma réplica síncrona em outra zona de disponibilidade, usada para failover.
• Standby: a réplica de Multi-AZ, que não aceita leitura.
• Read replica: réplica de leitura, que recebe as mudanças de forma assíncrona.
• Failover: promoção do standby quando o primário falha ou é forçado a trocar.
• Endpoint: o nome DNS que a aplicação usa para conectar ao banco.
• RDS Proxy: serviço que mantém um pool de conexões reais e as compartilha entre clientes.
• PITR (point in time recovery): restauração para um instante dentro da janela de retenção, criando uma instância nova.
• Snapshot: cópia completa do armazenamento da instância em um instante.

Fontes

Consultado em 27/10/2026:

• Read replicas (criação e promoção) e criação de réplica: assíncrona, snapshot, suspensão de E/S, backup como pré-requisito para réplicas, e RDS Proxy.
• Multi-AZ DB instance: standby síncrono, sem leitura, e diferença para o cluster Multi-AZ.
• Backups automatizados e restauração e ativação de backups: janela, retenção acima de zero, snapshots incrementais.
• RDS Proxy: pool, IAM e Secrets Manager, limites de proxies, segredos e alvos.
• Lambda com RDS: VPC, RDS Proxy, rds-db:connect e o exemplo em Go.
• Referência de parâmetros: aws rds <comando> help na AWS CLI instalada, versão 2.33.18.
• Limite de réplicas diretas: resumo de busca sobre a documentação do RDS para PostgreSQL, sem leitura da página completa.

Não verificado nesta revisão

• Tempo de failover do Multi-AZ, e se o endpoint DNS muda após o failover.
• Faixa máxima de dias de retenção de backup.
• Limite de réplicas diretas, que aparece num resumo de busca e precisa ser confirmado na página oficial.
• Valores aceitos por IAMAuth no RDS Proxy além de DISABLED.
• Desconto de até 60% em instâncias reservadas e a afirmação de até 3 vezes de desempenho do Aurora.
• Os comandos create-db-instance, create-db-snapshot, restore-db-instance-to-point-in-time, create-db-proxy e as outras linhas de comando foram conferidos pela ajuda local da CLI, com nomes de parâmetros, mas não foram executados numa conta real. Os comandos describe-db-engine-versions e describe-db-instances não foram conferidos.