Migração para AWS

Como migrar SQL Server para o Amazon RDS

Por Audizio Nunes · 2 de outubro de 2026

O Amazon RDS for SQL Server automatiza backups e parte da manutenção; alta disponibilidade exige configurar Multi-AZ. Em troca, você não acessa o Windows nem recebe permissão de sysadmin. Antes de escolher o destino, verifique as dependências do banco, o uso de datas e a janela de migração.

RDS ou SQL Server no EC2?

As duas opções rodam SQL Server na AWS. A diferença é quem administra o quê.

O RDS reduz parte do trabalho de operação. O EC2 oferece mais controle, mas também deixa manutenção, backup e recuperação sob responsabilidade da equipe. A escolha depende das funcionalidades exigidas, do custo e de quem vai operar o banco.

O que o RDS não suporta

Alguns recursos que precisam ser verificados antes da escolha:

• xp_cmdshell e outras procedures estendidas. Rotinas que dependem de comandos do sistema operacional precisam ser substituídas ou podem exigir SQL Server no EC2.
• CLR: não é suportado a partir do SQL Server 2017. Até o 2016, só no modo SAFE.
• FILESTREAM e FileTable. Seu uso exige adaptação dos dados e do código, ou outro destino para o banco.
• Planos de manutenção, log shipping e replicação. É preciso redesenhar essas rotinas. Backups automáticos não dispensam testes de restauração; algumas tarefas podem virar jobs do SQL Server Agent nas edições que oferecem esse serviço.
• Triggers de servidor e a propriedade TRUSTWORTHY.
• Linked servers têm suporte limitado.

Estas consultas são uma triagem inicial no ambiente atual. Elas não detectam chamadas dinâmicas, dependências externas, linked servers nem todos os jobs; revise também o código e a operação:

-- Assemblies CLR criados pelo usuário
SELECT name FROM sys.assemblies WHERE is_user_defined = 1;

-- Arquivos FILESTREAM no banco
SELECT name FROM sys.database_files WHERE type_desc = 'FILESTREAM';

-- Procedures, views e funções que chamam xp_cmdshell
SELECT OBJECT_SCHEMA_NAME(object_id) + '.' + OBJECT_NAME(object_id) AS objeto
FROM sys.sql_modules WHERE definition LIKE '%xp_cmdshell%';

-- Triggers de servidor
SELECT name FROM sys.server_triggers;

Também há limites de tamanho: até 30 bancos por instância nas classes até medium, 16 TiB de armazenamento SSD de uso geral e 10 GB por banco na edição Express.

Decisões que ficam fixas na criação da instância

Fuso horário

O padrão do RDS é UTC, e o fuso não pode ser alterado depois que a instância existe. GETDATE() e SYSDATETIME() seguem o horário da instância. Em outubro de 2026, UTC está três horas à frente do horário de Brasília. Isso causa erro quando a aplicação grava ou interpreta esses valores como se fossem horários locais, especialmente em fluxos fiscais que dependem da data e do horário de emissão.

Antes de criar a instância, escolha conscientemente entre manter UTC na aplicação e usar um fuso local suportado, como E. South America Standard Time (Brasília). Teste gravação, leitura e apresentação das datas; mudar só o fuso do banco não corrige conversões feitas pelo código.

Collation do servidor

A collation padrão do RDS é SQL_Latin1_General_CP1_CI_AS e é definida na criação. Muitos sistemas brasileiros usam outra, como Latin1_General_CI_AI. Restaurar um banco com collation diferente da do servidor é possível, mas o tempdb segue a collation do servidor: comparações de texto com tabelas temporárias podem gerar conflito. Confira a collation do servidor com SELECT SERVERPROPERTY('Collation'); e a do banco com SELECT DATABASEPROPERTYEX(DB_NAME(), 'Collation');. Escolha a collation da instância antes de criá-la e teste as consultas afetadas.

Edição

A Express não tem custo de licença, mas limita cada banco a 10 GB e não tem SQL Server Agent. A Web é bem mais barata que a Standard, mas a licença só permite aplicações web públicas: um ERP interno não se enquadra. Veja o impacto no preço em quanto custa migrar para AWS.

Métodos de migração

Backup nativo pelo S3

É uma opção direta quando a janela de parada permite. O backup leva os objetos e dados do banco, como tabelas, índices, procedures, views, triggers e usuários do banco, mas não configurações da instância. Antes, crie um bucket S3 na mesma região da instância, uma role do IAM com acesso a ele e adicione a opção SQLSERVER_BACKUP_RESTORE ao option group da instância.

-- 1. No servidor atual
BACKUP DATABASE [MeuBanco] TO DISK = 'D:\backup\MeuBanco.bak' WITH STATS = 10;

-- 2. Copie o arquivo para o S3 (AWS CLI)
-- aws s3 cp D:\backup\MeuBanco.bak s3://meu-bucket/MeuBanco.bak

-- 3. No RDS
EXEC msdb.dbo.rds_restore_database
  @restore_db_name = 'MeuBanco',
  @s3_arn_to_restore_from = 'arn:aws:s3:::meu-bucket/MeuBanco.bak',
  @type = 'FULL',
  @with_norecovery = 0; -- use 1 se for restaurar diferenciais depois

-- 4. Acompanhe até lifecycle = SUCCESS
EXEC msdb.dbo.rds_task_status @db_name = 'MeuBanco';

Para usar um diferencial, restaure antes o backup completo com @with_norecovery = 1 (diferente do exemplo acima). Na virada, interrompa as gravações, gere e envie o diferencial, e restaure com rds_restore_database, @type = 'DIFFERENTIAL' e @with_norecovery = 0. Se optar por backups de log, a cadeia e as procedures são diferentes e precisam de um ensaio próprio. Um snapshot entre o backup completo e o diferencial pode invalidar essa sequência.

Limites que costumam aparecer: no máximo 5 TB por arquivo (bancos maiores usam backup em vários arquivos), até 10 arquivos por restauração e nenhum backup de versão mais nova do SQL Server restaurado numa versão mais antiga.

AWS DMS

O DMS pode fazer carga inicial e replicação contínua das mudanças, mas a latência varia e deve ser monitorada antes da virada. As exigências de recuperação, log e CDC ou replicação dependem da configuração do SQL Server de origem. Se você deixar o DMS criar as tabelas no destino, ele cria apenas objetos necessários à carga, como tabelas e chaves primárias; índices secundários, chaves estrangeiras, procedures, views e usuários exigem migração separada. O DMS não oferece SQL Server Web ou Express como destino. Compare o esforço dessa opção com o de backup e restauração no seu cenário.

O que não vem junto com o banco

• Logins: ficam no servidor, não no banco. Crie os logins no RDS e religue os usuários do banco com ALTER USER [usuario] WITH LOGIN = [usuario];.
• Jobs do SQL Server Agent: o RDS não importa o banco msdb. Gere o script dos jobs no servidor atual e recrie no RDS.
• Linked servers e Database Mail: não vêm no backup do banco e precisam ser reconfigurados conforme os recursos e limites do RDS. Parâmetros de instância compatíveis são gerenciados por parameter groups.
• Autenticação Windows: é suportada com Active Directory, mas exige configuração própria e não vem no backup do banco.

Como fazer a virada

1. Crie a instância com o fuso, a collation e a edição certos, em sub-rede privada, sem acesso público.
2. Restaure uma cópia, aponte um ambiente de teste da aplicação para o RDS e rode os fluxos principais, inclusive relatórios e rotinas noturnas.
3. Recrie logins e jobs, e confira o desempenho das consultas mais pesadas.
4. No dia da virada, interrompa as gravações, conclua o backup ou a replicação escolhida, confira o atraso e a integridade dos dados, troque a string de conexão e valide os fluxos essenciais.
5. Mantenha o servidor antigo disponível e defina critérios para voltar antes da virada. Depois que o RDS receber novas gravações, voltar à origem sem reconciliação pode perder dados; o plano deve tratar esse cenário.

Perguntas frequentes

Veja também os cuidados para migrar a aplicação .NET e o checklist para migrar de VPS para AWS.