Moving accounts attached to Transit Gateway from Account to Org Level Resource Share

Hello, I have gone ahead and tested this scenario in my account. I created an Account A and shared a TGW from another account (part of Organization B) with it via Account level Resource Share. I then created a VPC in that account, created VPC attachment to the TGW, and gave it a route table on the TGW. I tested connectivity to another VPC on the TGW and it was successful.

I then added Account A to Org B (to which the TGW is already shared) and went ahead and removed the Account level resource share from the TGW. I verified that all connectivity remained, and all API calls to list the VPC attachments in both accounts still worked.

There was no interruption of services. Also yes, the Account level resource share can be removed as long as there is a separate Org level resource share for the Org that the account was moved to.

Here is an additional link that has some more information on moving the Transit Gateway itself between Orgs, a slightly different scenario but may still add some value: https://repost.aws/questions/QUZvUI9UALR2qhjl-d0YUFjQ/transit-gateway-behavior-while-moving-its-account-from-one-organization-to-another

Thank you

When moving accounts with VPCs attached to a Transit Gateway from one organization to another, there are a few important considerations regarding network connectivity and resource sharing:

1. Network Connectivity: There should be no interruption of network services for the VPC attachments during the process of moving Account A and Account B from Org 2 to Org 1. The Transit Gateway attachments will remain functional even when the accounts are being transferred between organizations. This means that the network connectivity through the Transit Gateway should continue uninterrupted during and after the migration.

2. Resource Sharing: Since the Transit Gateway is already shared with all of Org 1 using AWS Resource Access Manager (RAM), once Account A and Account B are moved into Org 1, they will automatically have access to the shared Transit Gateway through the organization-level share. This means that the individual account-level shares that were previously set up for these accounts when they were in Org 2 are no longer necessary.

3. Cleaning up RAM shares: After the migration is complete and Account A and Account B are successfully moved to Org 1, you can safely remove the account-level resource shares in RAM. This cleanup step is recommended to maintain a clean and organized resource sharing structure. Removing these individual account shares will not affect the accounts' ability to use the Transit Gateway, as they will now be accessing it through the organization-level share.

4. Best Practices: It's a good practice to verify that the accounts have successfully joined Org 1 and that they can still access and use the Transit Gateway resources as expected before removing the old account-level shares. This ensures a smooth transition and helps avoid any potential issues.

In summary, the migration of accounts between organizations should not cause any network interruptions for the VPC attachments to the Transit Gateway. Once the accounts are in Org 1, they will automatically have access to the shared Transit Gateway, and you can safely clean up the old account-level resource shares in RAM.
Sources
Work with transit gateways using Amazon VPC Transit Gateways - Amazon VPC
Architecture 3.1: Transit Gateway with AWS RAM - AWS Prescriptive Guidance