Migração para AWS

Como migrar de outra nuvem para a AWS

Por Audizio Nunes · 8 de outubro de 2026

Migrar de outra nuvem para a AWS (Azure, Google Cloud, Oracle Cloud ou hospedagem em nuvem) segue o caminho de qualquer migração: levantar o que existe, decidir como levar cada parte, ensaiar e só então virar. A AWS tem ferramentas para servidores, bancos e arquivos, mas convém ter um motivo claro para mudar.

Quando faz sentido migrar de outra nuvem para a AWS

Estar em outro provedor não é erro, e a AWS não é a melhor resposta para todos os casos. Motivos possíveis:

• exigência contratual, regulatória ou de cliente quanto ao provedor ou à região;
• serviço necessário ao produto que existe no destino e não no provedor atual;
• consolidação com cargas que já estão na AWS;
• custo total favorável, calculado com dados reais e incluindo a própria mudança.

Se a origem for um servidor próprio, veja migrar do on-premises para a AWS.

O que muda ao trocar de nuvem: rede, identidade e licenças

• Rede. O guia da AWS para quem sai do Azure App Service pede para revisar sub-redes, endpoints privados e resolução de DNS ao configurar a VPC. O AWS Interconnect multicloud liga a AWS por conexão privada a Google Cloud, Oracle Cloud Infrastructure e Azure (em prévia); São Paulo não constava da lista de regiões que consultei em 8 de outubro de 2026.
• Identidade. No mesmo guia, a integração de um app com Azure AD/Entra ID é mapeada para IAM e Amazon Cognito, e a autenticação entre serviços precisa ser refeita.
• Licenças. A AWS recomenda tratar o licenciamento do sistema operacional e dos softwares com os fabricantes antes de migrar.

Como replicar servidores de outra nuvem com o AWS Transform MGN

O AWS Application Migration Service (MGN) passou a se chamar AWS Transform MGN. A AWS o indica para rehospedar servidores de infraestrutura física, VMware, Hyper-V, Amazon EC2 e outras nuvens; entre os exemplos publicados em blogs, com o nome antigo, estão uma VM do Azure e instâncias do Google Compute Engine.

Um agente em cada servidor de origem replica os discos em nível de bloco para uma área de preparação na AWS; com tudo sincronizado, lançam-se instâncias de teste e de virada no Amazon EC2. Requisitos que mais barram servidores:

• sistema operacional na lista de suportados, x86 (no Linux, só 64 bits);
• 2 GB livres (na raiz, no Linux; no disco do Program Files (x86), no Windows), 300 MB de RAM livre e, no Linux, acesso root ou sudo;
• volumes de até 16 TB; sem suporte a Secure Boot (inicialização segura) no Linux nem a servidores totalmente paravirtualizados;
• rede: TCP 443 para a API do MGN e o Amazon S3, e TCP 1500 para a replicação, sem interceptação de SSL.

A AWS fala em servidores de “outras nuvens” sem listar provedores. Para Oracle Cloud e para VPS, valide cada servidor contra a lista de sistemas, os requisitos de rede e os recursos exigidos; se for VPS, veja também migrar de VPS para AWS.

Como migrar banco de dados e arquivos entre nuvens

O AWS Database Migration Service (DMS) lista como origens o Azure SQL Database, o Azure SQL Managed Instance, o Azure Database for PostgreSQL e o Azure Database for MySQL (ambos na modalidade servidor flexível), o Cloud SQL do Google Cloud para PostgreSQL e para MySQL e o OCI MySQL HeatWave.

O DMS não oferece captura de alterações (CDC) com Azure SQL Database. Para SQL Server com destino RDS, veja migrar SQL Server para Amazon RDS.

Para arquivos, o AWS DataSync copia do Google Cloud Storage, do Azure Files e do Azure Blob Storage. Entre o Google Cloud Storage ou o Azure Blob Storage e o Amazon S3, o modo Enhanced dispensa agente; no modo Basic, o agente é necessário.

Equivalência de serviços entre nuvens: exemplos do guia da AWS para o Azure

O guia da AWS para quem sai do Azure App Service traz estas correspondências: Key Vault para Secrets Manager, Azure Monitor para CloudWatch, Azure SQL para Amazon RDS, Blob Storage para Amazon S3 e Service Bus para SQS e SNS. Trate-as como ponto de partida, não como garantia de equivalência.

Para Google Cloud e Oracle Cloud, compare serviço a serviço na documentação dos dois lados.

Custo da transição: os dois ambientes ligados ao mesmo tempo

Durante a migração, origem e destino ficam ativos juntos, e cada um cobra pelo seu uso. Na AWS, o MGN não cobra pelo serviço, por servidor, durante 2.160 horas (90 dias contínuos) a partir da instalação do agente; passado esse período, há cobrança por hora enquanto o servidor continuar replicando. Os recursos de replicação, teste e virada (EC2 e EBS) são cobrados normalmente.

Google Cloud e Azure divulgam, cada um, condições para transferência de saída sem taxa para clientes que deixam o provedor. Elegibilidade e pedido estão nas páginas deles. Para Oracle Cloud e hospedagens, confira as regras de transferência de saída com o provedor. Valores e custo do projeto estão em quanto custa migrar para a AWS.

Como planejar a virada e a reversão

1. Teste: a AWS recomenda testar ao menos duas semanas antes da virada, com usuários validando.
2. Virada: combine a janela, pare as gravações na origem, confirme que a replicação está saudável e sem atraso e só então lance a instância de corte. Reduza antes o TTL do DNS (o tempo que os resolvedores guardam a resposta em cache).
3. Reversão: reverter o corte no MGN só devolve o servidor ao estado de pronto para o corte, sem devolver tráfego nem dados, e o MGN não faz failback (enviar à origem os dados gravados na AWS). O AWS Elastic Disaster Recovery tem esse recurso, mas o failback parte de instâncias de recuperação dele, então a migração teria de ser feita com ele e não com o MGN; é outro serviço, com custo próprio e, fora da AWS, exige que o ambiente de origem consiga iniciar por ISO. Preserve a origem pelo período combinado, sem reiniciá-la nem desligá-la antes da virada, e defina antes como os dados gravados na AWS voltariam.

Quando não migrar agora

• O sistema depende de serviço do provedor atual sem equivalente validado.
• O sistema operacional está fora da lista do MGN, ou o MGN já anunciou o fim do suporte a ele (confira a lista vigente): decida antes se vai atualizar o sistema ou usar outro caminho.

Esta página não cobre reescrita de aplicações nem migração de SaaS. Para avaliar o seu caso, veja o serviço de migração para a AWS.