Amazon SAP-C02: Migration & Modernization — Study Guide
Part of the AWS Solutions Architect Professional SAP-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
Migration strategy and planning
Effective migration begins with disciplined discovery, dependency mapping, and risk-based prioritization. Use AWS Application Discovery Service and AWS Migration Hub to inventory servers, collect performance metrics, and visualize application dependencies; complement with agentless network flow analysis and configuration management data to find hidden stateful links. Translate discovery into landing-zone decisions: choose account strategy with AWS Control Tower and Organizations, define network topology with Transit Gateway, and size destination compute using Compute Optimizer and right-sizing guidelines. Cutover strategy should be chosen per application: big-bang for small, low-risk systems; phased or wave-based for business-critical suites; blue/green or canary for customer-facing services to minimize user impact. Consider data synchronization windows, DNS TTLs, bandwidth constraints, and regulatory constraints when planning cutover. Common traps include underestimating data transfer time and costs, treating lift-and-shift as the final state, neglecting license portability, and failing to plan for rollback. Decision criteria often trade cost against operational effort and resilience: managed services (RDS/Aurora, DocumentDB) increase OPEX predictability and resilience but may require schema changes; replatforming to managed offerings reduces ops burden at the expense of migration complexity.
Lift-and-shift and data migration tools
For rapid rehosting, AWS Application Migration Service (MGN) automates block-level replication from VMware, Hyper-V, and physical servers into EC2, minimizing cutover time and preserving OS-level configurations. Large-volume or offline data migration may require AWS Snow Family or DataSync for files and POSIX/NFS workloads, while Amazon S3 Transfer Acceleration and Direct Connect accelerate object and bulk transfer. Database migration relies on AWS Database Migration Service (DMS) for homogeneous or heterogeneous migrations, paired with the Schema Conversion Tool (SCT) when structural changes are required. Be mindful of DMS limitations: MongoDB source/target behavior has version and feature constraints, large LOB handling, and potential replication lag during CDC. Architect for data integrity: validate with checksums, run full load plus CDC for minimal downtime, and stage cutover during low-traffic windows. Design trade-offs revolve around speed versus fidelity: MGN or rehost minimizes application change but perpetuates legacy operational models; replatforming reduces long-term ops but requires refactor and testing. Common traps include neglecting endpoint security, insufficient pre-cutover validation, and assuming identical IOPS/throughput in cloud storage.
Modernization: containers, serverless, and patterns for refactoring
Modernization options range from replatforming into container orchestration to full refactoring into serverless. Choose Amazon ECS on Fargate for quick containerized deployments with minimal infra management, or Amazon EKS for Kubernetes-native workloads requiring portability and complex orchestration. For event-driven microservices, combine AWS Lambda with API Gateway, EventBridge, and Step Functions to reduce operational overhead and scale per request. Data services should move toward managed backends: Amazon RDS/Aurora for relational databases, Amazon DynamoDB or Amazon DocumentDB for NoSQL/document stores, and ElastiCache for low-latency caching. Trade-offs hinge on operational complexity versus cost and performance predictability: EKS offers control and portability at higher ops cost; Fargate simplifies ops but can be more expensive at scale. Serverless offers cost-efficiency for spiky workloads but introduces cold starts, concurrency limits, and observability challenges. Common architect traps include lifting monoliths into containers without decomposing stateful components, insufficient CI/CD and IaC (CloudFormation, CDK, Terraform) to manage deployments, and ignoring IAM least privilege for task roles and Lambda execution roles.
Cutover, hybrid networking, and post-migration operations
Successful cutover depends on hybrid networking and identity integration plus robust observability and rollback plans. For hybrid DNS resolution between VPCs and on-premises Active Directory, deploy Amazon Route 53 Resolver inbound and outbound endpoints, or use AD Connector/Managed Microsoft AD for domain joins of EC2 Windows instances. Network connectivity choices include AWS Direct Connect and Transit Gateway for scalable multi-account topologies; choose Direct Connect when predictable bandwidth and lower egress costs matter, and Transit Gateway to simplify many-to-many VPC and on-prem connectivity. Post-migration ops must cover monitoring (CloudWatch, X-Ray), centralized logging and analysis (CloudWatch Logs, Kinesis Firehose to a centralized account), backup and cross-region snapshot strategies (AWS Backup, cross-region snapshot copy), and security baselines enforced via AWS Config and IAM boundary policies. Common traps are failing to lower DNS TTLs ahead of cutover, not testing AD integration at scale, and under-provisioning Transit Gateway bandwidth or missing route propagation configurations. Decision criteria here are resilience versus cost: active-active multi-region designs increase availability but multiply replication costs and complexity; active-passive simplifies cost but lengthens RTO.
Practical Problem: Use-Case Scenario
Scenario: Acme Energy, a global research enterprise, has an existing AWS environment with multiple accounts under AWS Organizations and an on-premises data center connected via a private Direct Connect link. They need to migrate a suite of Linux simulation servers, a MongoDB replica set, and nightly image file shares to AWS with minimal disruption.
Challenge: Reduce operational burden and enable elastic scaling while ensuring no more than two hours of cutover downtime for simulations and zero data loss for MongoDB replica set and nightly image ingestion.
Recommended Approach:
- Deploy AWS Application Migration Service (MGN) agents to replicate simulation servers into a dedicated migration account; configure continuous block-level replication with low RPO and schedule a staged cutover wave for noncritical nodes first.
- Use AWS DMS with MongoDB as source and Amazon DocumentDB (with MongoDB compatibility) as target, run full load plus CDC, and validate document-level consistency using checksums and parallel read replicas for verification.
- Migrate nightly images using AWS DataSync to an Amazon S3 bucket backed by S3 Lifecycle rules; provision Amazon FSx for Lustre or Amazon EFS for POSIX-backed workloads that require NFS semantics, and test read/write performance under peak loads.
- Orchestrate cutover with lowered Route 53 TTLs, Route 53 weighted routing for blue/green traffic shift, and finalize DNS swap after successful smoke tests; enforce IAM roles and enable CloudWatch X-Ray, centralized CloudWatch Logs, and AWS Backup for snapshots.
Rationale: This approach minimizes downtime via staged replication and CDC, reduces operational overhead by adopting managed services (DocumentDB, S3, DataSync), and provides safe rollback points and observability to validate correctness before final cutover — aligning with professional architecture best practices for migration and modernization.
← Databases · All domains · Resilience →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →