Migração: Migration Hub, DMS, MGN e DataSync
- ⬜💰 Precificação, Free Tier e Planos de Suporte(AWS Cloud Practitioner)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Quase nenhuma empresa nasce direto na nuvem — a maioria chega até a AWS carregando datacenters, servidores Windows antigos, bancos Oracle de 2 TB e NAS com 300 TB de arquivos. A AWS entende isso e oferece um arsenal dedicado de serviços para cada etapa: descobrir o que existe, planejar a onda, migrar servidores, migrar bancos e transferir dados. No CLF-C02 aparecem perguntas de “qual serviço usar para X” — e a diferença entre MGN, DMS e DataSync precisa estar afiada.
O fluxo de migração em 4 fases
- → alimenta o painel
- → dado para decidir
- Gestão e governança
- Fora da AWS
- Compute
- Banco de dados
- Rede e entrega
- Armazenamento
Quatro fases, e a ordem importa: descobrir, decidir por aplicação, migrar com a ferramenta do tipo de carga, operar. A prova costuma dar um cenário e pedir a fase ou a ferramenta.
- Descobrir vem antes de tudo. Application Discovery Service levanta o que existe, quanto consome e o que depende de quê. Migrar sem inventário é como mudar de casa sem saber quantos móveis tem — e a dependência escondida é o que quebra o cutover.
- Migration Hub acompanha, não migra. Ele é o painel: mostra o progresso de cada aplicação em todas as ferramentas. Confundir Hub com ferramenta de migração é erro comum de prova.
- Os 7 Rs decidem aplicação por aplicação. Retire (desligar o que ninguém usa), Retain (fica onde está), Rehost (mover como está), Relocate, Replatform (trocar por gerenciado), Refactor (reescrever), Repurchase (trocar por SaaS). Não existe resposta única para o datacenter inteiro.
- A ferramenta segue o tipo de carga. Servidor → MGN. Banco → DMS, com SCT se a engine mudar. Arquivo → DataSync. Volume grande demais para o link → Snowball. É a mesma lógica do SAA, num nível mais raso.
- Rehost primeiro, otimizar depois. O padrão que a AWS recomenda: mover como está para sair do datacenter, e só então replataformar. Tentar refatorar tudo durante a migração é o que faz projeto atrasar anos.
Cada etapa tem serviços específicos. O Migration Hub é o painel que amarra tudo: você vê progresso de dezenas de servidores sendo migrados por MGN, bancos por DMS e dados por DataSync em uma tela só.
AWS Migration Hub
Painel central de rastreamento. Consolida progresso de MGN, DMS, Application Discovery e ferramentas de parceiros em um único dashboard. Migration Hub Orchestrator permite automatizar sequências (ex: migrar o banco primeiro, depois os app servers que dependem dele).
Migration Hub não cobra pelo rastreamento — você paga só pelos serviços subjacentes (MGN, DMS, etc.).
AWS Application Discovery Service
A etapa zero da migração: entender o que existe on-prem antes de mover qualquer coisa.
| Modo | Como funciona | Quando usar |
|---|---|---|
| Agentless Discovery (Connector) | VM appliance no VMware vCenter coleta dados de VMs sem agente | Ambiente VMware, quer inventário rápido |
| Agent-based Discovery | ADS Agent instalado em cada servidor (Linux/Windows) | Precisa de dados detalhados: processos, conexões de rede, dependências |
Dados são exportados para Migration Hub ou para S3 (analisáveis com Athena). Permite construir um wave plan — quais apps migrar juntas porque têm dependência forte entre si.
AWS Application Migration Service (MGN)
Substituto oficial do antigo Server Migration Service (SMS). É o serviço de rehost (lift-and-shift) padrão da AWS — replica servidores on-prem inteiros para EC2 com downtime mínimo.
MGN é gratuito por 90 dias após a primeira replicação — você só paga EBS + EC2 do destino. Serve também como DR econômico (mantém réplicas em standby).
AWS Database Migration Service (DMS)
Migração de bancos com mínimo downtime, suportando replicação contínua.
| Tipo | Exemplo | Ferramenta extra |
|---|---|---|
| Homogênea | Oracle → Oracle · MySQL → RDS MySQL | Não precisa |
| Heterogênea | Oracle → Aurora · SQL Server → PostgreSQL | SCT (Schema Conversion Tool) |
SCT (Schema Conversion Tool) converte schema + stored procedures + triggers para o dialeto destino. CDC (Change Data Capture) replica mudanças em curso após a carga inicial — é o que permite cutover com downtime de segundos.
Armadilha clássica: DMS não migra stored procedures sozinho em migrações heterogêneas — você precisa do SCT antes. Para homogênea, SCT é opcional.
Qual serviço replica servidores on-premises inteiros para a AWS, permitindo cutover com downtime de minutos?
AWS DataSync
Transferência de arquivos e objetos entre storage on-prem (NFS, SMB, HDFS) e AWS (S3, EFS, FSx). Faz verificação de integridade, criptografia em trânsito e pode rodar continuamente ou agendado.
| DataSync | Storage Gateway | Snow Family |
|---|---|---|
| Transferência em rede (contínua/agendada) | Acesso híbrido contínuo (mantém on-prem ativo) | Transferência física offline |
| TB até centenas de TB | Cache local + storage na AWS | PB · TB volume sem boa conectividade |
| NFS/SMB/HDFS ↔ S3/EFS/FSx | iSCSI, NFS, SMB, VTL | Snowcone · Snowball Edge · Snowmobile |
AWS Mainframe Modernization
Serviço gerenciado para migrar e modernizar aplicações mainframe (COBOL, Micro Focus) para cloud. Suporta dois padrões: replataforma (roda o código como está em AWS) ou refactor (transpila COBOL → Java). Aparece pouco no CLF-C02 além do nome, mas pode cair em questões de “qual serviço para migrar mainframe”.
Decisão: qual serviço usar?
📋 Migrar 200 servidores Windows/Linux on-prem para EC2 com menor esforço
Rehost automatizado, replicação contínua por blocos, cutover em minutos, gratuito por 90 dias.
Alt: VMware HCX — se já usa VMware Cloud on AWS.
Alt: Scripts custom com AMI Import — menos automatizado.
📋 Migrar banco Oracle 2 TB para Aurora PostgreSQL com downtime < 1 hora
SCT converte schema Oracle → PostgreSQL; DMS faz carga inicial; CDC replica mudanças enquanto app ainda escreve em Oracle; cutover: redireciona conexões.
Alt: Aurora native import — homogêneo PostgreSQL → Aurora PostgreSQL.
Alt: Backup lógico + restore — offline — downtime grande.
📋 Transferir 300 TB de arquivos NAS para S3 via rede em 2 semanas
DataSync paraleliza transferência, verifica integridade, agenda jobs. Se a conectividade for ruim, considere Snowball Edge (caminhão AWS).
Alt: Snowball Edge — offline, melhor acima de 500 TB ou link lento.
Alt: Storage Gateway — não é migração — é acesso híbrido contínuo.
Perguntas típicas (Q&A)
❓ Qual a diferença entre DMS e MGN?
❓ Quando escolher Snow Family em vez de DataSync?
❓ O Migration Hub cobra à parte?
Perguntas frequentes
❓ Qual serviço usar para migrar servidor inteiro?
❓ Como migrar banco de dados sem parar a aplicação?
❓ Como mover volume grande de dado com rede limitada?
Fixando
Qual é o primeiro dos 7 Rs que se deve considerar, e por quê?
Qual serviço dá visibilidade centralizada do progresso de uma migração com várias ferramentas em uso?
Take-aways: MGN = servidores · DMS = bancos · DataSync = arquivos via rede · Snow Family = arquivos offline · Application Discovery = descobrir antes de migrar · Migration Hub = painel central. O SCT é obrigatório em migrações heterogêneas de banco.
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…