Migração para o Arquiteto: DMS, SCT, MGN e DRS
- ⬜🗃️ Bancos: Multi-AZ, Read Replicas e DynamoDB(AWS Solutions Architect Associate)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
No Practitioner vimos os serviços de migração na altura do nome. Aqui vamos ao nível em que o SAA-C03 cobra: padrões arquiteturais. Qual combinação de MGN + DMS + DataSync faz sentido pra um cenário específico? Como dimensionar replication instance do DMS? Quando usar DRS em vez de Backup para DR? Qual a diferença real entre Transfer Family, DataSync e Storage Gateway? Essas decisões são o coração do domínio Resilient + Cost-Optimized do exame.
As 7 estratégias (7 Rs) — o framework
| Estratégia | O que faz | Esforço | Exemplo |
|---|---|---|---|
| Retire | Descontinua a aplicação | Nenhum | App legado sem uso |
| Retain | Mantém on-prem por ora | Nenhum | Sistema com compliance restrita |
| Rehost | Lift-and-shift para EC2 | Baixo | MGN replica VM para EC2 sem mudar código |
| Relocate | Move hypervisor para AWS sem mudanças | Baixo | VMware Cloud on AWS |
| Replatform | Lift-and-reshape com pequenas otimizações | Médio | Oracle em EC2 → Aurora PostgreSQL |
| Repurchase | Migra para SaaS | Médio | CRM custom → Salesforce |
| Refactor | Reescreve cloud-native | Alto | Monolito Java → Lambda + DynamoDB |
O exame cobra muito a diferença Rehost vs Replatform vs Refactor — quase sempre aparece num caso de uso com restrição de tempo ou budget. Menor esforço = Rehost. Melhor custo-benefício a médio prazo = Replatform. Melhor longo prazo e elasticidade = Refactor.
DMS + SCT: migração de bancos heterogêneos
| Componente | Papel |
|---|---|
| SCT (Schema Conversion Tool) | Converte schema, stored procedures, triggers, views, índices entre dialetos (Oracle → PostgreSQL, SQL Server → Aurora MySQL, etc.). Gera assessment report com tudo que precisa conversão manual. |
| DMS Replication Instance | EC2 gerenciada que executa o job. Dimensionar: memória para tabelas largas, rede para alto throughput. Classes dms.r5/r6 para heavy workloads. |
| DMS Task Full Load | Carga inicial das tabelas. Pode rodar em paralelo (LOB mode: inline, full, limited). |
| DMS Task CDC | Replica log transacional (redo log Oracle, binlog MySQL) em tempo quase-real. |
| DMS Fleet Advisor | Recomenda dimensionamento e estima custo a partir de métricas do banco origem. |
Armadilha: DMS não migra stored procedures em migração heterogênea. SCT é obrigatório antes. Em migração homogênea (Oracle → Oracle), SCT é opcional e você pode usar (Data Pump) combinado com DMS CDC.
AWS MGN: lift-and-shift em escala
MGN (Application Migration Service) substitui o antigo SMS/CloudEndure Migration. Replica servidores inteiros (Windows/Linux, VMware/Hyper-V/físico) para AWS com downtime mínimo. Fluxo:
- Instala replication agent no servidor origem
- Replica blocos para área de staging (EBS) na AWS continuamente
- Configura Launch Template (instance type, VPC, SG, IAM profile)
- Test launch: sobe EC2 de teste a partir da réplica sem afetar produção
- Cutover: janela de manutenção, sobe EC2 final, redireciona tráfego
Os primeiros 90 dias de replicação são gratuitos — paga só EBS + EC2 do teste. MGN também pode ser usado como DR barato (manter réplicas em standby).
AWS DRS: Disaster Recovery contínuo
AWS Elastic Disaster Recovery (ex-CloudEndure DR) é o primo do MGN focado em DR. Diferença prática:
| Aspecto | MGN (migração) | DRS (DR) |
|---|---|---|
| Objetivo | Uma vez — cutover e parar | Contínuo — failover sempre disponível |
| Custo | Grátis 90 dias + EBS staging | Contínuo: EBS staging pequeno + licenças |
| RTO | Minutos no cutover | Minutos no failover |
| RPO | Segundos | Segundos (sub-segundo em média) |
| Failback | — | Sim — volta para origem após incidente |
DRS é a recomendação atual da AWS para DR de EC2 e on-prem em Pilot Light / Warm Standby. Para Backup & Restore pura use AWS Backup. Para Multi-Site Active/Active use replicação nativa do banco (Aurora Global, DynamoDB Global Tables).
Uma empresa precisa transferir 300 TB de um NAS on-premises para o S3. O link de saída é de 500 Mbps e a janela é de 30 dias. O que fazer?
Transferência de dados: matriz de decisão
| Serviço | Uso | Protocolo / Interface |
|---|---|---|
| DataSync | Transferência contínua/agendada on-prem ↔ AWS ou AWS ↔ AWS | NFS, SMB, HDFS, S3, EFS, FSx |
| Storage Gateway — File Gateway | Expor buckets S3 localmente como NFS/SMB (cache local) | NFS v3/v4.1, SMB |
| Storage Gateway — Volume Gateway | Volume iSCSI respaldado por S3 (cache ou stored mode) | iSCSI |
| Storage Gateway — Tape Gateway | Substitui tape library física (VTL backup) | iSCSI VTL |
| Storage Gateway — FSx File Gateway | Acesso cache local a shares FSx for Windows | SMB |
| Transfer Family | Usuários externos trocando arquivos via SFTP/FTPS/FTP/AS2 | SFTP, FTPS, FTP, AS2 |
| Snowball Edge | Transferir PB sem rede — appliance que AWS envia | NFS · S3 API local |
| Snowcone | Edge compute + storage leve (2TB SSD · 8TB HDD) | NFS · batch |
| Snowmobile | Caminhão com 100 PB (casos especiais) | — |
- → arquivo
- → acesso contínuo
- → banco
- → servidor
- → volume alto / link ruim
- Fora da AWS
- Rede e entrega
- Armazenamento
- Banco de dados
- Compute
Duas contas resolvem quase toda questão de migração: que TIPO de dado é (arquivo, banco, servidor) e se o volume CABE no link dentro do prazo. Só depois entram os 7 Rs.
- A primeira pergunta é: o que é o dado?. Arquivo em NAS → DataSync. Banco → DMS. Servidor inteiro com SO e aplicação → MGN. Cada serviço existe para um tipo, e a alternativa errada costuma oferecer o serviço do tipo vizinho.
- A segunda é: cabe no link, no prazo?. Faça a conta: 100 TB num link de 1 Gbps saturado leva mais de uma semana. Se o volume dividido pela banda estoura a janela, a resposta é Snowball — e a prova sempre dá banda e volume juntos para você fazer essa divisão.
- DMS com SCT quando a engine muda. DMS sozinho migra Oracle→Oracle. Para Oracle→PostgreSQL você precisa do Schema Conversion Tool antes, porque procedure e tipo não são compatíveis. "Migrar de comercial para open source" implica os dois.
- CDC é o que permite cutover curto. DMS faz carga inicial e depois captura as mudanças em andamento. Você mantém os dois lados em sincronia e vira a chave numa janela de minutos, em vez de parar a operação durante toda a cópia.
- Storage Gateway é para ficar híbrido. Ele não é ferramenta de migração pontual: é para operação permanente em que a aplicação on-prem continua lendo local com cache e o dado vive no S3. Se a questão diz "manter acesso local de baixa latência", é ele.
Cenários arquiteturais
📋 Migrar 500 servidores VMware para EC2 em 6 meses com cutover programado por wave
MGN automatiza replicação por bloco para 500 servidores. Migration Hub Orchestrator agenda waves, validações e cutover. Grátis 90 dias.
Alt: VMware HCX + VMware Cloud on AWS — se quer manter vSphere.
Alt: Refactor por onda — muito mais longo e caro.
📋 DR cross-region para aplicações críticas com RTO de 5 minutos e RPO de 30 segundos
DRS mantém réplicas EC2 em standby de baixo custo com failover rápido. Aurora Global replica banco com RPO < 1s. Backup & Restore não atenderia RTO.
Alt: Multi-Site Active/Active — RPO ~0 mas muito mais caro.
Alt: AWS Backup + manual restore — RPO/RTO altos.
📋 Fornecedor externo precisa enviar arquivos CSV diariamente para processamento
Transfer Family expõe endpoint SFTP gerenciado com autenticação IAM/Active Directory/service-managed. Arquivo cai em S3, EventBridge dispara Lambda.
Alt: EC2 rodando OpenSSH — overhead operacional.
Alt: DataSync — não expõe endpoint externo.
📋 Backup de fita legado (LTO) precisa ser substituído por storage em nuvem sem mudar app
Tape Gateway apresenta endpoints iSCSI VTL compatíveis com NetBackup/Veeam. Fitas virtuais vão para S3/Glacier automaticamente.
Alt: AWS Backup — se pode reescrever o fluxo.
Alt: Custom com S3 direto — mais trabalho.
Perguntas típicas (Q&A)
❓ MGN ou DRS para mover workloads para AWS?
❓ Como dimensionar a DMS Replication Instance?
❓ Qual diferença entre Snowball Edge Storage Optimized e Compute Optimized?
❓ DMS suporta NoSQL?
Perguntas frequentes
❓ Como migrar banco de dados entre motores diferentes?
❓ Como escolher entre mover como está e reescrever?
❓ Quando usar transporte físico de dado?
Fixando
Uma migração de Oracle on-premises para Aurora PostgreSQL precisa de janela de corte de poucos minutos. Quais ferramentas?
Qual estratégia dos 7 Rs se aplica a "trocar o Oracle self-managed por Amazon RDS, sem reescrever a aplicação"?
Take-aways: 7 Rs = framework de escolha · MGN = migrar servidores · DRS = DR contínuo · DMS+SCT+CDC = bancos heterogêneos · Transfer Family = SFTP gerenciado · DataSync = transferência em rede · Storage Gateway = acesso híbrido · Snow Family = petabytes offline · Migration Hub = painel central.
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…