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

The correct answer is option B. This solution uses a combination of AWS Resource Access Manager (RAM) and automated backups to migrate the Lambda functions and the Aurora database to the Target account while minimizing downtime. In this solution, the Lambda function deployment package is downloaded from the Source account and used to create new Lambda functions in the Target account. The Aurora DB cluster is shared with the Target account using AWS RAM and the Target account is granted permission to clone the Aurora DB cluster, allowing for a new copy of the Aurora database to be created in the Target account. This approach allows for the data to be migrated to the Target account while minimizing downtime, as the Target account can use the cloned Aurora database while the original Aurora database continues to be used in the Source account.

AWS Resource Access Manager (RAM) can only share the follow services:  Amazon Aurora – DB clusters  Amazon EC2 – capacity reservations and dedicated hosts  AWS License Manager – License configurations  AWS Outposts – Local gateway route tables, outposts, and sites  Amazon Route 53 – Forwarding rules  Amazon VPC – Customer-owned IPv4 addresses, prefix lists, subnets, traffic mirror targets, transit gateways, transit gateway multicast domains https://docs.aws.amazon.com/ram/latest/userguide/shareable.html

Lambda function and Aurora cluster can NOT be shared with RAM!

B. Download the Lambda function deployment package from the Source account. Use the deployment package and create new Lambda functions in the Target account. Share the Aurora DB cluster with the Target account by using AWS Resource Access Manager {AWS RAM). Grant the Target account permission to clone the Aurora DB cluster.

A is viable, but as AWS RAM can share Aurora clusters, B is faster. However, AWS RAM can't share lambdas, so C and D are out.

B, C, and D are all out since AWS RAM cannot share either Lambdas or Aurora DB clusters. A is the only viable one - you must use a manual shapshot for the DB, share it, and redeploy any deployment package in the destination account. (The question tries to trip you up by its wording: lambda deployments can't be downloaded, but the same deployment packages used to deploy the lambdas can, for instance from S3 or from source)

Option B is the most accurate and efficient solution based on this AWS article content (https://aws.amazon.com/about-aws/whats-new/2019/07/amazon_aurora_supportscloningacrossawsaccounts-/). It correctly outlines the steps for Lambda migration and utilizes the Aurora DB cluster cloning feature across accounts via AWS RAM, which aligns with the article’s description. This approach ensures minimal downtime and efficient migration by allowing direct cloning of the Aurora database. Option C incorrectly suggests using AWS RAM to share Lambda functions, which is not supported yet based on latest sharable AWS resources: https://docs.aws.amazon.com/ram/latest/userguide/shareable.html

AWS Resource Access Manager (RAM) to share AWS Lambda functions and Aurora DB clusters with another AWS account. AWS RAM allows you to share resources that are created and managed by other AWS services with individual AWS accounts or with the accounts in an organization or organizational units (OUs) in AWS Organizations. To share a Lambda function with another AWS account, you can delegate access to an IAM user (or all users) in the other AWS account so that they can assume a role in your account and invoke the Lambda function in your account. To share an Aurora DB cluster with another AWS account, you can create a resource share in AWS RAM and specify the Amazon Resource Name (ARN) of the Aurora DB cluster as the resource to share. You can then specify the AWS account IDs of the accounts with which you want to share the resource.

A = you can share snapshot to restore DB, but this will introduce some downtime B = correct (cloning a DB allows for very limited downtime) C = if you only share Lambda you are not migrating it, also it appears the Lambda is not a RAM sharable resource https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html D = it appears the Lambda is not a RAM sharable resource and you cannot directly share an automated snapshot, you need first to create a manual snapshot by copying the automated snapshot, and then share that copy https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-share-snapshot.html

There is limit on the number of resources you can share with AWS RAM. AWS RAM does not support direct sharing of Lambda functions between accounts. https://docs.aws.amazon.com/ram/latest/userguide/shareable.html

it's B. In A - automated snapshots are not shareable

Option B minimizes downtime, compared to A, where we only share a snapshot of the cluster. For C we do not migrate the lambdas, we just share them, which is not the idea of the exercise.

The correct answer is option B. This solution uses a combination of AWS Resource Access Manager (RAM) and automated backups to migrate the Lambda functions and the Aurora database to the Target account while minimizing downtime.

They just want to migrate the Lambda and Aurora DB, they dont care about the app itself

The question is about migration and not sharing, so the answer is how to use a RAM feature to help you on the migration. In option D they are not migrating anything, both Lambda and Aurora are being shared with the Target account and not migrated. In option C is a similar situation, the Lambda is not being migrated. Option A seems a good option but might cause a larger downtime. Hence option D is more appropriate because you can use the cluster share with the Target account and clone the database cluster into it. In my view this answer should contemplate in which moment the cutoff from Source to Target would occur.

You can share the following Amazon Aurora resources by using AWS RAM.

B is the way forward