- Newest
- Most votes
- Most comments
You're correct in your understanding that directly transferring ownership of a shared VPC from one account to another is not possible in AWS. The process you've outlined is indeed the recommended approach for this situation. Here's a more detailed explanation of the steps:
-
Account B should create a new VPC within their own account.
-
Migrate all resources from the shared VPC (owned by Account A) to the newly created VPC in Account B. This includes EC2 instances, RDS databases, Lambda functions, and any other AWS resources that were deployed in the shared subnets.
-
Once all resources have been migrated and verified in the new VPC, Account A can unshare the VPC with Account B.
-
After unsharing, Account B will no longer be able to create new resources in the previously shared subnets, but they will still be able to modify, describe, and delete any remaining resources they might have in those subnets.
-
It's important for Account B to ensure all their resources are removed from the shared VPC before Account A unshares it. This is because Account A cannot delete the shared subnet or the shared-subnet VPC if participants still have resources in the unshared subnet.
There isn't a direct workaround or alternative method to transfer VPC ownership between accounts. This process, while potentially time-consuming, ensures a clean separation of resources and maintains the integrity of the VPC ownership model in AWS.
To minimize disruption during this migration, careful planning and potentially using AWS migration tools or services could be beneficial. Also, consider using features like VPC peering or AWS Transit Gateway to maintain any necessary connectivity between the old and new VPCs during the migration process.
Sources
Working with shared subnets - Amazon Virtual Private Cloud
Share your VPC subnets with other accounts - Amazon Virtual Private Cloud
Relevant content
- asked 10 months ago
