Exam AWS Certified Solutions Architect - Professional SAP-C02 topic 1 question 229 discussion

C. The proper way is to use AWS DMS, but the answer here uses S3 (???) which will take forever. So the answer is C.

C https://aws.amazon.com/blogs/database/part-3-migrating-to-amazon-rds-for-sql-server-using-transactional-replication-with-native-backup-and-restore/

By using native database high availability tools and replication methods, you can achieve near-zero downtime during the migration process. The other options may not provide the same level of seamless data replication and minimal downtime as the native SQL Server replication tools. Option B: Use AWS Database Migration Service (AWS DMS) to rehost the database. Set Amazon S3 as a target. Set up change data capture (CDC) replication. When the source and destination are fully synchronized, load the data from Amazon S3 into an Amazon RDS for Microsoft SQL Server DB instance. While AWS DMS can be used for migrations, it introduces additional complexity compared to native SQL Server replication tools. Staging data in Amazon S3 and then loading into the target RDS instance can cause downtime during the final cutover. Native replication tools can directly replicate data to the target RDS instance without an intermediate storage solution.

B look correct to me

B is the AWS way of doing a DB migration. C might work and could be better in some cases, but because the DBs are legacy you might run into compatibility issues or limitations with the tooling. If the databases are very large you really want to use B because you need to ship the bulk of the data with Snowball.

C. Correct, Near-Zero Downtime. A. In-Place Upgrade and Migration to Aurora: This involves multiple steps and the potential for increased downtime during the cutover process. Schema Conversion: Depending on the complexity of the legacy system, converting schemas and ensuring compatibility with Amazon Aurora can be challenging and time-consuming. B. Intermediate Storage in Amazon S3: Adds complexity Two-Step Process: First replicating to Amazon S3 and then loading into Amazon RDS adds additional steps and potential points of failure.

In option C - "Connect the source system to an Amazon RDS for Microsoft SQL Server DB instance", should be target, not source

Use AWS Database Migration Service (AWS DMS) to "rehost" the database???? How you can "rehost" database with DMS

DMS should be the better service for this use case

Answer: C.

AWS Application Migration Service (MGN) is a highly automated lift-and-shift (rehost) solution that simplifies the migration of applications to AWS. It supports near-zero downtime migrations by continuously replicating the source servers to AWS. Repointing the applications to Amazon Aurora Serverless satisfies the migration to the modern data architecture.

Why not A as the question the it should rearchitected from legacy

Native database high availability (HA) tools include the Always On or distributed availability group clusters in Microsoft SQL Server and Oracle’s Data Guard replications. This approach requires a major effort to set up across extended, cross-site HA clusters, and might cause some performance degradation because of the longer latency to achieve fully synchronous active/active deployments. However, this method provides the closest to near-zero downtime during the cutover.

What is "native database high availability tools"????

B. Use AWS Database Migration Service (AWS DMS) to rehost the database. This action is not 'rehost'

C: Use distributed AG, it will work. https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-sql-server-to-aws-using-distributed-availability-groups.html

A. Use AWS Application Migration Service and the AWS Schema Conversion Tool (AWS SCT). Perform an in-place upgrade before the migration. Export the migrated data to Amazon Aurora Serverless after cutover. Repoint the applications to Amazon Aurora. Here's why this approach offers the best advantages: Minimal downtime: In-place upgrade and cutover minimize downtime compared to traditional database migrations. Modernization: AWS Schema Conversion Tool helps modernize legacy schema structures during migration. Serverless architecture: Amazon Aurora Serverless simplifies management and scales effortlessly. Application compatibility: Repointing applications directly to Aurora minimizes disruption.