Restaurando RDS a partir de um Snapshot: Nova Instância ou Sobrescrita?

Uma dúvida recorrente em operações de recuperação de banco de dados na AWS: ao restaurar um snapshot do RDS, o que acontece com a instância existente? Entender esse comportamento antes de executar o processo em produção evita surpresas com endpoints, configurações de segurança e tempo de inatividade não planejado.

TL;DR — Restauração de Snapshot RDS

Pergunta	Resposta
A instância existente é sobrescrita?	Não. Uma nova instância é sempre criada.
O endpoint muda?	Sim. A nova instância recebe um endpoint diferente.
A instância original é deletada?	Não automaticamente. Ela continua rodando até você deletar manualmente.
Security Groups são preservados?	Não por padrão. O grupo padrão da VPC é atribuído.
Parameter Groups são preservados?	Não. O parameter group padrão do engine é atribuído.

Como a Restauração de Snapshot RDS Funciona

O processo de restauração do RDS não é uma operação de 'rollback in-place'. O serviço provisiona um novo cluster de computação, restaura os dados do snapshot para um novo volume de armazenamento e registra um novo endpoint DNS. A instância original permanece intacta e operacional durante todo esse processo.

Isso tem implicações diretas: você pode restaurar um snapshot sem nenhum impacto na instância de produção atual. O risco aparece depois — quando você precisa redirecionar o tráfego da aplicação para o novo endpoint, ou quando esquece de replicar as configurações de rede e segurança.

graph TD S3["Snapshot no S3
gerenciado pela AWS"] --> Restore["Restauração iniciada"] Restore --> NewInstance["Nova instância RDS
novo endpoint DNS"] Restore --> OriginalInstance["Instância original
continua rodando"] NewInstance --> DefaultSG["Security Group padrão
da VPC aplicado"] NewInstance --> DefaultPG["Parameter Group padrão
do engine aplicado"] NewInstance --> NewEndpoint["Novo endpoint:
nome-restaurado.xxx.rds.amazonaws.com"] OriginalInstance --> OriginalEndpoint["Endpoint original
inalterado"] style NewInstance fill:#2d6a4f,color:#fff style OriginalInstance fill:#1d3557,color:#fff style DefaultSG fill:#e63946,color:#fff style DefaultPG fill:#e63946,color:#fff

Snapshot existente: ponto de recuperação armazenado no S3 gerenciado pela AWS.
Nova instância provisionada: compute e storage completamente novos, sem relação com a instância original.
Novo endpoint DNS: a aplicação precisa ser atualizada para apontar para o novo host.
Instância original intacta: continua rodando e acumulando custo até ser deletada manualmente.
Configurações não herdadas: Security Groups, Parameter Groups e Option Groups precisam ser reconfigurados.

O Que é Herdado do Snapshot e o Que Não É

Esse é o ponto onde a maioria dos incidentes acontece. O snapshot captura os dados e algumas configurações do engine, mas não captura toda a infraestrutura ao redor da instância.

Herdado do snapshot

Dados do banco de dados (tabelas, schemas, registros)
Engine version (pode ser alterada durante a restauração)
Tipo de storage (gp2, gp3, io1) — pode ser alterado
Configurações de Multi-AZ — pode ser alterado
Configurações de encryption (se o snapshot é criptografado, a instância restaurada também será)

Não herdado — precisa ser reconfigurado

Security Groups: a instância restaurada recebe o Security Group padrão da VPC
Parameter Groups: o parameter group padrão do engine é aplicado
Option Groups: o option group padrão é aplicado
Subnet Group: precisa ser especificado explicitamente
IAM roles associadas (ex: para Enhanced Monitoring ou S3 integration)
Maintenance window e backup window
Deletion protection
Performance Insights

Pense no snapshot como um backup de disco. Ele guarda os dados, não o rack inteiro. Restaurar um snapshot é como instalar esse disco em um servidor novo — você precisa reconectar os cabos de rede, configurar o firewall e ajustar os parâmetros do sistema operacional manualmente.

Restaurando um Snapshot RDS via AWS CLI

O comando principal é restore-db-instance-from-db-snapshot. O identificador da nova instância deve ser diferente da instância existente — a AWS rejeita nomes duplicados dentro da mesma região e conta.

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier meu-banco-restaurado \
  --db-snapshot-identifier rds:meu-banco-producao-2024-01-15-00-00 \
  --db-instance-class db.t3.medium \
  --db-subnet-group-name meu-subnet-group \
  --vpc-security-group-ids sg-0abc123def456789 \
  --no-publicly-accessible \
  --region us-east-1

Após a restauração, verifique o endpoint da nova instância:

aws rds describe-db-instances \
  --db-instance-identifier meu-banco-restaurado \
  --query 'DBInstances[0].Endpoint' \
  --region us-east-1

O retorno será algo como:

{
    "Address": "meu-banco-restaurado.c9akciq32.us-east-1.rds.amazonaws.com",
    "Port": 5432,
    "HostedZoneId": "Z2R2ITUGPM61AM"
}

Esse endpoint é diferente do endpoint original. Qualquer aplicação que precise apontar para a instância restaurada precisa ser atualizada.

Verificando e Corrigindo Security Groups após a Restauração

A instância restaurada não herda os Security Groups da original — esse comportamento silencioso é a causa mais comum de falhas de conectividade pós-restauração. A aplicação tenta conectar, o timeout aparece, e o primeiro instinto é suspeitar do banco. Na verdade, o problema está na camada de rede.

Verifique quais Security Groups foram atribuídos à instância restaurada:

aws rds describe-db-instances \
  --db-instance-identifier meu-banco-restaurado \
  --query 'DBInstances[0].VpcSecurityGroups' \
  --region us-east-1

Se o resultado mostrar apenas o Security Group padrão da VPC, aplique os grupos corretos:

aws rds modify-db-instance \
  --db-instance-identifier meu-banco-restaurado \
  --vpc-security-group-ids sg-0abc123def456789 sg-0def456abc789012 \
  --apply-immediately \
  --region us-east-1

Verificando e Aplicando o Parameter Group Correto

Se a instância original usava um parameter group customizado — com configurações de max_connections, shared_buffers, ou qualquer outro parâmetro ajustado — a instância restaurada não terá essas configurações. Ela iniciará com os valores padrão do engine, o que pode causar comportamentos inesperados em workloads que dependem desses ajustes.

aws rds describe-db-instances \
  --db-instance-identifier meu-banco-restaurado \
  --query 'DBInstances[0].DBParameterGroups' \
  --region us-east-1

Para aplicar o parameter group correto:

aws rds modify-db-instance \
  --db-instance-identifier meu-banco-restaurado \
  --db-parameter-group-name meu-parameter-group-customizado \
  --apply-immediately \
  --region us-east-1

Parâmetros estáticos exigem reboot da instância para entrar em vigor. Verifique o status do parameter group após a modificação:

aws rds describe-db-instances \
  --db-instance-identifier meu-banco-restaurado \
  --query 'DBInstances[0].DBParameterGroups[0].ParameterApplyStatus' \
  --region us-east-1

Se o retorno for pending-reboot, execute o reboot:

aws rds reboot-db-instance \
  --db-instance-identifier meu-banco-restaurado \
  --region us-east-1

Fluxo Completo de Restauração com Cutover

Em cenários de recuperação de desastre ou rollback planejado, o objetivo final é redirecionar o tráfego da aplicação da instância original para a restaurada. O fluxo abaixo representa as etapas operacionais completas.

graph TD A["Snapshot disponível"] --> B["Executar restore-db-instance-from-db-snapshot"] B --> C["Aguardar status: available"] C --> D["Aplicar Security Groups corretos"] D --> E["Aplicar Parameter Group correto"] E --> F{"Status: in-sync?"} F -- "Não" --> G["Reboot da instância"] G --> F F -- "Sim" --> H["Teste de conectividade"] H --> I{"Conexão OK?"} I -- "Não" --> D I -- "Sim" --> J["Atualizar endpoint na aplicação"] J --> K["Monitorar por período de observação"] K --> L["Deletar instância original"] style A fill:#457b9d,color:#fff style J fill:#2d6a4f,color:#fff style L fill:#6c757d,color:#fff style G fill:#e63946,color:#fff

Snapshot disponível: ponto de partida — snapshot manual ou automatizado já existente.
Restauração iniciada: nova instância provisionada com novo endpoint.
Validação de configuração: Security Groups, Parameter Groups e conectividade verificados antes de qualquer cutover.
Teste de conectividade: conexão de teste confirmada antes de redirecionar tráfego de produção.
Atualização do endpoint na aplicação: variável de ambiente, Secrets Manager, ou Parameter Store atualizado.
Instância original em standby: mantida por um período de observação antes da deleção definitiva.

Experiência de Campo: O Incidente do Parameter Group Silencioso

Em uma restauração de emergência de um banco PostgreSQL em produção, a instância foi restaurada com sucesso, os Security Groups foram corretamente aplicados, a conectividade foi validada. O sistema voltou ao ar. Trinta minutos depois, começaram a aparecer erros de too many connections — algo que nunca havia acontecido na instância original.

O diagnóstico inicial apontou para um pico de tráfego. Não era. O parameter group padrão do PostgreSQL define max_connections com base no tamanho da instância, mas o valor era significativamente menor do que o configurado no parameter group customizado da instância original. A instância restaurada estava operando com um limite de conexões diferente, e ninguém havia verificado isso durante o processo de cutover.

A correção foi aplicar o parameter group correto e reiniciar a instância — mas isso exigiu um segundo período de manutenção não planejado. O snapshot não tinha culpa. A checklist de pós-restauração estava incompleta.

Desde então, qualquer runbook de restauração inclui explicitamente a verificação e aplicação de parameter groups como etapa bloqueante antes do cutover.

IAM Mínimo para Operações de Restauração de Snapshot RDS

Para executar os comandos descritos neste post, o principal IAM precisa das seguintes permissões. A ação rds:RestoreDBInstanceFromDBSnapshot requer permissão tanto no snapshot de origem quanto na instância de destino.

🔽 Clique para expandir — Política IAM mínima para restauração de snapshot

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestoreSnapshot",
      "Effect": "Allow",
      "Action": [
        "rds:RestoreDBInstanceFromDBSnapshot"
      ],
      "Resource": [
        "arn:aws:rds:us-east-1:123456789012:snapshot:*",
        "arn:aws:rds:us-east-1:123456789012:db:*"
      ]
    },
    {
      "Sid": "DescribeAndModify",
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBInstances",
        "rds:ModifyDBInstance",
        "rds:RebootDBInstance",
        "rds:DescribeDBSnapshots"
      ],
      "Resource": "*"
    }
  ]
}

A ação rds:DescribeDBInstances requer Resource: * — isso é um comportamento documentado do serviço, não uma concessão excessiva de permissão.

Checklist de Pós-Restauração de Snapshot RDS

Use esta lista como etapa bloqueante antes de qualquer cutover de tráfego:

☐ Instância restaurada com status available
☐ Endpoint da nova instância anotado
☐ Security Groups corretos aplicados e verificados
☐ Parameter Group correto aplicado — status in-sync confirmado
☐ Option Group correto aplicado (se aplicável)
☐ Conectividade de teste bem-sucedida a partir da camada de aplicação
☐ Backup automático habilitado na nova instância (desabilitado por padrão em algumas configurações de restauração)
☐ Deletion protection habilitado se for instância de produção
☐ Instância original mantida em standby até confirmação de estabilidade

Próximos Passos e Restauração de Snapshot RDS na Prática

Restaurar um snapshot do RDS é uma operação segura e não destrutiva — a instância original nunca é afetada. O risco real está nas configurações que não são herdadas automaticamente e no redirecionamento do endpoint da aplicação.

Para ambientes de produção, considere automatizar o processo de restauração e validação com AWS Systems Manager Automation ou Step Functions, garantindo que a checklist de pós-restauração seja executada de forma consistente a cada operação.

Documentação oficial de referência:

Glossário

Termo	Definição
DB Snapshot	Backup completo e point-in-time de uma instância RDS, armazenado no S3 gerenciado pela AWS. Pode ser manual ou automatizado.
Endpoint RDS	Endereço DNS único atribuído a cada instância RDS. Cada nova instância restaurada recebe um endpoint diferente.
Parameter Group	Container de parâmetros de configuração do engine de banco de dados (PostgreSQL, MySQL, etc.). Não é herdado durante a restauração de snapshot.
Security Group	Firewall virtual que controla o tráfego de entrada e saída de uma instância RDS. Precisa ser reaplicado após restauração.
Cutover	Momento em que o tráfego de produção é redirecionado de uma instância para outra — neste contexto, da instância original para a instância restaurada.

Pesquisar este blog

SW BBANG P