Serverless migration question. Is this scoped to Serverless v1?

[duckkk]

Hi team,

I’m working through the SAA-C03 practice set and hit the question.

Question: An online registration system hosted in an Amazon EKS cluster stores data to db.t4g.medium Amazon Aurora DB cluster. The database performs well during regular hours but is unable to handle the traffic surge that occurs during flash sales. A solutions architect must move the database to Aurora Serverless while minimizing downtime and the impact on the operation of the application. Which change should be taken to meet the objective?

• Use AWS Database Migration Service (AWS DMS) to migrate to a new Aurora Serverless database.
• Take a snapshot of the DB cluster. Use the snapshot to create a new Aurora DB cluster.
• Change the Aurora Instance class to Serverless
• Add an Aurora Replica to the cluster and set its instance class to Serverless. Failover to the read replica and promote it to primary.

The keyed answer is AWS DMS. I think that only holds under Aurora Serverless v1, and I’d like to check the intended scope.

1. THE EXPLANATION FOR “CHANGE THE AURORA INSTANCE CLASS TO SERVERLESS” STATES THIS IS NOT POSSIBLE.

That was true for v1, where serverless was a cluster mode. It is no longer true. AWS documents converting a provisioned writer or reader to serverless via the standard modify-instance procedure, and explicitly notes that converting an instance is how you minimize downtime as the first step of a switchover:

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-administration.html#aurora-serverless-v2-converting-from-provisioned

2. THE AURORA REPLICA + FAILOVER OPTION IS REJECTED FOR CAUSING A SHORT WRITE OUTAGE — BUT AWS DOCUMENTS THIS AS THE RECOMMENDED APPROACH.

Under the heading “Using Aurora serverless for existing provisioned workloads”, AWS describes adding serverless readers to an existing provisioned cluster and using the failover mechanism to promote one to writer, stating that this lets you switch over with minimal downtime and without changing the endpoint that your client applications use:

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html

AWS re:Post gives the same procedure for this exact scenario — add a serverless reader, then force a failover to promote it:

https://repost.aws/knowledge-center/aurora-migrate-provisioned-serverless

Also worth noting: a DMS cutover also requires quiescing writes and letting CDC drain, so “brief write unavailability” doesn’t actually distinguish the two options.

3. DMS HAS APPLICATION-SIDE IMPACT THAT THE FAILOVER APPROACH DOESN’T.

DMS creates a new target cluster, and therefore a new cluster endpoint. For an app on EKS that means editing the connection string in a ConfigMap/Secret and rolling the Deployment — unless you additionally rename the clusters or front the endpoint with a Route 53 CNAME. The failover approach leaves the cluster endpoint unchanged, so nothing on the application side changes.

Since the stem asks to minimize “the impact on the operation of the application”, endpoint stability seems like the stronger reading of that phrase.

My question: is this question intentionally scoped to Aurora Serverless v1? If so, could that be stated in the stem, and could the explanation for the Aurora Replica option say it’s unsupported under v1 rather than “valid but incurs a brief write outage”? As written, the two distractor explanations give different reasons for what is really the same v1 constraint.

Thanks! Just want to make sure I’m building the right mental model rather than memorizing an answer key.