RDS for SQL Server passa a aceitar snapshot direto em réplica de leitura

O que mudou

Desde 19 de outubro de 2026, o Amazon RDS for SQL Server permite criar snapshots diretamente em instâncias de réplica de leitura (read replica). Antes, esse recurso só existia para instâncias standalone e para a instância primária.

Se alguém precisasse de um snapshot de uma réplica, o caminho era promovê-la primeiro, transformando-a num banco independente e encerrando seu papel de réplica. Agora dá pra tirar o snapshot sem esse passo, mudando o fluxo de backup e disaster recovery (DR) de quem mantém réplicas de SQL Server na AWS.

Antes x agora

A diferença fica mais clara lado a lado:

Como funciona na prática

A lista abaixo resume as operações que passam a valer para a réplica de leitura:

• Snapshot manual: disparado a qualquer momento pelo console, pela CLI ou pela API do RDS.
• Backup automatizado: basta configurar um backup retention period maior que zero na própria réplica.
• Retenção pós-exclusão: ao apagar a réplica, dá pra manter os backups automatizados já existentes em vez de perdê-los junto com a instância.
• Point-in-time recovery (PITR): continua indisponível a partir de uma réplica de leitura, segue exclusivo da instância primária.

O recurso vale tanto para réplicas dentro da mesma região (in-region) quanto para réplicas entre regiões (cross-region), dando a mesma capacidade de snapshot independentemente de onde a réplica está localizada.

Por que isso resolve um problema real de DR

Antes dessa mudança, promover uma réplica de leitura para ativar Multi-AZ exigia esperar um snapshot completo terminar antes da conversão começar. Em volumes grandes, a AWS cita configurações io2 de até 64 TiB, esse primeiro snapshot podia demorar bastante, o que tornava o tempo de recuperação de desastre difícil de prever.

Agora, o RDS for SQL Server mantém os dados de snapshot na própria réplica de leitura ao longo de todo o ciclo de vida dela. Isso significa que, quando a réplica é promovida e o Multi-AZ é ligado, o primeiro snapshot pós-promoção completa mais rápido, porque parte do rastreamento de dados já vinha sendo feito antes da promoção.

Na prática, quem precisa transformar uma réplica de leitura num banco Multi-AZ dentro de um cenário de disaster recovery ganha um tempo de habilitação mais curto e mais previsível para planejar exercícios de DR. Isso importa para quem documenta RTO (recovery time objective) em runbook e até agora não conseguia estimar com segurança quanto tempo o primeiro snapshot ia levar.

O que ainda fica de fora

PITR a partir de réplica de leitura segue não suportado. Isso pesa para runbooks que dependem de restaurar para qualquer ponto no tempo dentro da janela de retenção: esse fluxo ainda exige a instância primária ou uma instância já promovida.

Quem tem esse requisito específico no plano de recuperação continua precisando promover a réplica antes de contar com PITR. O snapshot na réplica resolve backup e aceleração de Multi-AZ, mas não substitui esse caso de uso.

Edições, versões e regiões

O recurso é exclusivo do SQL Server Enterprise Edition no RDS. A fonte oficial não detalha a situação das demais edições (Standard, Web, Express), mas, como o anúncio fala apenas em Enterprise Edition, presume-se que elas fiquem de fora por ora. Dentro do Enterprise Edition, funciona em todas as versões do SQL Server que já suportam réplica de leitura no serviço.

A disponibilidade acompanha todas as regiões onde réplicas de leitura do RDS for SQL Server já existem, incluindo as regiões AWS GovCloud (US).

Quanto custa

A fonte oficial não detalha uma política de cobrança específica para snapshots em réplicas de leitura, apenas remete à página de pricing do Amazon RDS for SQL Server para os valores. Vale consultar essa página diretamente antes de assumir que o modelo de cobrança é idêntico ao de snapshots na instância primária.

O que muda pra quem administra SQL Server na AWS

Para DBAs e times de SRE que operam RDS for SQL Server Enterprise Edition, o ganho direto aparece em dois cenários. O primeiro é backup de uma réplica sem sacrificar seu propósito de leitura: antes, tirar um snapshot significava promover e perder a réplica como destino de queries de relatório, por exemplo.

O segundo é previsibilidade em exercício de DR: times que precisam estimar quanto tempo leva para transformar uma réplica cross-region num banco Multi-AZ em caso de desastre agora trabalham com uma janela menor e mais estável. Quem ainda depende de PITR como parte do plano de recuperação continua precisando da instância primária para esse cenário específico, e esse é o ponto que vale revisar no runbook antes de assumir que a réplica cobre todo o fluxo de backup.

Fonte 1: AWS What's New (https://aws.amazon.com/about-aws/whats-new/2026/10/rds-sqlserver-supports-snapshots-on-read-replicas)

Amazon RDS for SQL Server now supports snapshots on read replicas - AWS

Skip to main content

Amazon RDS for SQL Server now supports snapshots on read replicas

Posted on: Oct 19, 2026

Amazon Relational Database Service (Amazon RDS) for SQL Server now supports creating DB snapshots directly on read replica instances. Previously, you could create snapshots only on standalone and primary DB instances. You can now snapshot a read replica without promoting it first, giving you more flexibility in your backup and disaster recovery (DR) workflows.

Previously, enabling Multi-AZ on a promoted read replica meant waiting for an initial full snapshot to finish before the conversion could begin. On larger storage configurations—such as io2 volumes up to 64 TiB—that first snapshot could take a long time, making DR timelines hard to predict. Now, Amazon RDS for SQL Server maintains snapshot data on the read replica throughout its lifecycle, so the first snapshot after promotion completes faster.

This shortens the time to enable Multi-AZ and helps you plan DR exercises with more predictable recovery timelines. You can take manual snapshots of a read replica, turn on automated backups by setting a backup retention period greater than zero, and retain automated backups when you delete the replica; however, point-in-time recovery (PITR) from a read replica isn't supported.

This feature works for both in-region and cross-region read replicas. It's available for SQL Server Enterprise Edition on all SQL Server versions that support read replicas, in all AWS Regions where Amazon RDS for SQL Server read replicas are available, including the AWS GovCloud (US) Regions.

To learn more, see Working with read replicas for Microsoft SQL Server . For pricing details, see Amazon RDS for SQL Server Pricing .

Fonte: AWS What's New