Amazon SAP-C02: Migração e Modernização — Guia de estudos

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Faz parte do AWS Solutions Architect Professional SAP-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Estratégia e planejamento de migração

Uma migração eficaz começa com descoberta disciplinada, mapeamento de dependências e priorização baseada em riscos. Use o AWS Application Discovery Service e o AWS Migration Hub para inventariar servidores, coletar métricas de desempenho e visualizar dependências de aplicações; complemente com análise de fluxo de rede sem agente (agentless) e dados de gerenciamento de configuração para encontrar links com estado (stateful) ocultos. Traduza a descoberta em decisões de landing zone: escolha a estratégia de contas com o AWS Control Tower e o Organizations, defina a topologia de rede com o Transit Gateway e dimensione a computação de destino usando o Compute Optimizer e as diretrizes de right-sizing. A estratégia de cutover deve ser escolhida por aplicação: big-bang para sistemas pequenos e de baixo risco; em fases (phased) ou em ondas (wave-based) para suítes de missão crítica; blue/green ou canary para serviços voltados ao cliente para minimizar o impacto no usuário. Considere as janelas de sincronização de dados, os TTLs de DNS, as restrições de largura de banda e as restrições regulatórias ao planejar o cutover. As armadilhas comuns incluem subestimar o tempo e os custos de transferência de dados, tratar o lift-and-shift como o estado final, negligenciar a portabilidade de licenças e falhar em planejar o rollback. Os critérios de decisão frequentemente trocam custo por esforço operacional e resiliência: serviços gerenciados (RDS/Aurora, DocumentDB) aumentam a previsibilidade do OPEX e a resiliência, mas podem exigir alterações de schema; o replatforming para ofertas gerenciadas reduz a carga operacional ao custo da complexidade da migração.

Ferramentas de lift-and-shift e migração de dados

Para um rehosting rápido, o AWS Application Migration Service (MGN) automatiza a replicação em nível de bloco de servidores VMware, Hyper-V e físicos para o EC2, minimizando o tempo de cutover e preservando as configurações no nível do sistema operacional. A migração de grandes volumes de dados ou offline pode exigir o AWS Snow Family ou o DataSync para arquivos e workloads POSIX/NFS, enquanto o Amazon S3 Transfer Acceleration e o Direct Connect aceleram a transferência de objetos e em massa (bulk). A migração de banco de dados depende do AWS Database Migration Service (DMS) para migrações homogêneas ou heterogêneas, combinado com o Schema Conversion Tool (SCT) quando são necessárias alterações estruturais. Esteja ciente das limitações do DMS: o comportamento de origem/destino do MongoDB tem restrições de versão e de recursos, manuseio de LOBs grandes e possível latência de replicação (replication lag) durante o CDC. Arquitete para a integridade dos dados: valide com checksums, execute uma carga completa (full load) mais CDC para tempo de inatividade mínimo e programe o cutover durante janelas de baixo tráfego. Os trade-offs de design giram em torno de velocidade versus fidelidade: o MGN ou o rehost minimizam as alterações na aplicação, mas perpetuam modelos operacionais legados; o replatforming reduz as operações de longo prazo, mas exige refatoração (refactor) e testes. As armadilhas comuns incluem negligenciar a segurança de endpoints, validação pré-cutover insuficiente e presumir IOPS/throughput idênticos no armazenamento em nuvem.

Modernização: contêineres, serverless e padrões para refatoração

As opções de modernização variam desde o replatforming para orquestração de contêineres até a refatoração completa para serverless. Escolha o Amazon ECS on Fargate para implantações rápidas em contêineres com gerenciamento mínimo de infraestrutura, ou o Amazon EKS para workloads nativos de Kubernetes que exigem portabilidade e orquestração complexa. Para microsserviços orientados a eventos, combine o AWS Lambda com o API Gateway, o EventBridge e o Step Functions para reduzir a sobrecarga operacional e escalar por requisição. Os serviços de dados devem migrar para backends gerenciados: Amazon RDS/Aurora para bancos de dados relacionais, Amazon DynamoDB ou Amazon DocumentDB para armazenamentos NoSQL/de documentos e ElastiCache para cache de baixa latência. Os trade-offs dependem da complexidade operacional versus custo e previsibilidade de desempenho: o EKS oferece controle e portabilidade a um custo operacional mais alto; o Fargate simplifica as operações, mas pode ser mais caro em escala. O modelo serverless oferece eficiência de custos para workloads com picos de uso (spiky), mas introduz cold starts, limites de concorrência e desafios de observabilidade. As armadilhas comuns de arquitetura incluem migrar monólitos para contêineres sem decompor componentes com estado (stateful), CI/CD e IaC (CloudFormation, CDK, Terraform) insuficientes para gerenciar implantações e ignorar o princípio de menor privilégio (least privilege) do IAM para task roles e Lambda execution roles.

Cutover, rede híbrida e operações pós-migração

O sucesso do cutover depende da rede híbrida e da integração de identidades, além de planos robustos de observabilidade e rollback. Para resolução de DNS híbrida entre VPCs e o Active Directory on-premises, implante pontos de extremidade (endpoints) de entrada e saída do Amazon Route 53 Resolver, ou use o AD Connector/Managed Microsoft AD para o ingresso de instâncias EC2 Windows no domínio. As opções de conectividade de rede incluem o AWS Direct Connect e o Transit Gateway para topologias multi-account escaláveis; escolha o Direct Connect quando a largura de banda previsível e custos de egresso mais baixos forem importantes, e o Transit Gateway para simplificar a conectividade muitos-para-muitos entre VPCs e o ambiente on-prem. As operações pós-migração devem cobrir monitoramento (CloudWatch, X-Ray), centralização de logs e análise (CloudWatch Logs, Kinesis Firehose para uma conta centralizada), estratégias de backup e snapshots entre regiões (AWS Backup, cópia de snapshots entre regiões) e baselines de segurança aplicados via AWS Config e políticas de limite (boundary policies) do IAM. Armadilhas comuns incluem falhar em reduzir os TTLs do DNS antes do cutover, não testar a integração com o AD em escala e subprovisionar a largura de banda do Transit Gateway ou omitir configurações de propagação de rota. Os critérios de decisão aqui são resiliência versus custo: arquiteturas multirregionais ativo-ativas aumentam a disponibilidade, mas multiplicam os custos de replicação e a complexidade; a abordagem ativo-passiva simplifica o custo, mas aumenta o RTO.

Problema Prático: Cenário de Caso de Uso

Cenário: A Acme Energy, uma empresa global de pesquisa, possui um ambiente AWS existente com várias contas no AWS Organizations e um data center on-premises conectado por um link privado do Direct Connect. Eles precisam migrar um conjunto de servidores de simulação Linux, um replica set do MongoDB e compartilhamentos de arquivos de imagem noturnos para a AWS com o mínimo de interrupção.

Desafio: Reduzir a carga operacional e permitir o escalonamento elástico, garantindo no máximo duas horas de tempo de inatividade (downtime) durante o cutover para as simulações e perda zero de dados para o replica set do MongoDB e a ingestão de imagens noturnas.

Abordagem Recomendada:

1. Implantar agentes do AWS Application Migration Service (MGN) para replicar os servidores de simulação em uma conta de migração dedicada; configurar a replicação contínua em nível de bloco com um RPO baixo e agendar uma onda de cutover em etapas para os nós não críticos primeiro.
2. Usar o AWS DMS com o MongoDB como origem e o Amazon DocumentDB (com compatibilidade com MongoDB) como destino, executar a carga completa mais o CDC (Change Data Capture) e validar a consistência em nível de documento usando checksums e réplicas de leitura paralelas para verificação.
3. Migrar as imagens noturnas usando o AWS DataSync para um bucket do Amazon S3 com o suporte de regras do S3 Lifecycle; provisionar o Amazon FSx for Lustre ou o Amazon EFS para cargas de trabalho baseadas em POSIX que exigem semântica NFS e testar o desempenho de leitura/escrita sob cargas de pico.
4. Orquestrar o cutover com TTLs do Route 53 reduzidos, roteamento ponderado (weighted routing) do Route 53 para a mudança de tráfego blue/green e finalizar a troca de DNS após testes de fumaça (smoke tests) bem-sucedidos; aplicar roles do IAM e habilitar o CloudWatch X-Ray, a centralização de logs do CloudWatch e o AWS Backup para snapshots.

Justificativa: Esta abordagem minimiza o tempo de inatividade por meio da replicação em etapas e do CDC, reduz a sobrecarga operacional ao adotar serviços gerenciados (DocumentDB, S3, DataSync) e fornece pontos de rollback seguros e observabilidade para validar a correção antes do cutover final — alinhando-se com as melhores práticas de arquitetura profissional para migração e modernização.

← Bancos de Dados e Analytics · Todos os domínios · Resiliência →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Amazon →