Migrating accounts between AWS Organizations from a network perspective

In this post, we’ll discuss the considerations, recommendations, and approach for migrating AWS accounts between AWS Organizations from a networking perspective. We’ll explain the behavior of AWS networking resources when AWS accounts are moved between Organizations. We’ll also analyze the behavior from different viewpoints including service availability, management and governance, as well as commercial and operations.

Organizations helps you centrally manage and govern your environment as you grow and scale your AWS resources. Organizations help customers manage multiple AWS accounts and consolidate billing payments in a central payer account. It’s common for the customer to move certain AWS accounts from one Organization to another. There are multiple reasons for doing so:

1. Mergers and acquisitions – consolidate account in centralized management account
2. Migrating from AWS Landing Zone Solution to AWS Control Tower
3. Internal change of payer account.

We’ve described the method to move an AWS account to a different Organization in this post and this knowledge article. Visit these resources to see the prerequisites and steps required to move the account to different Organizations.

Sometimes customers ask: What would be the impact to the existing networking setup when AWS accounts are moved to a different Organization? Understanding the impact can be difficult when there are multiple AWS accounts involved in network connectivity setup. In this post, we’ll discuss the following networking scenarios:

1. Scenario 1: Cross accounts connectivity using AWS Transit Gateway
2. Scenario 2: Cross accounts connectivity using VPC Peering
3. Scenario 3: Hybrid connectivity using Site-to-site VPN
4. Scenario 4: Hybrid connectivity using AWS Direct Connect
5. Scenario 5: VPC Sharing across multiple accounts
6. Scenario 6: Amazon Route53 Private Hosted Zone cross accounts sharing
7. Scenario 7: Amazon Route53 Resolver Endpoint cross accounts sharing

In each scenario, we’ll use two accounts (Account A and Account B) under the same Organization (let’s call it Organization A). And later we’ll move Account A to the new Organization (let’s call it Organization Z). We’ll examine the behavior of each networking resource when Account A moved to Organization Z. Although the sample will only use two accounts, the same principles also apply when the setup involves more than two accounts.

Scenario 1: Cross account connectivity using AWS Transit Gateway

With AWS Transit Gateway customers can connect multiple Amazon Virtual Private Clouds (Amazon VPC) from the same or different account. To connect VPCs from a different account, customers must share the Transit Gateway using AWS Resource Access Manager (RAM). When you create a resource share like Transit Gateway, you grant a principal that will consume the resource. The principal could be an individual AWS account, Organization, Organizational unit (OU), AWS Identity and Access Management (IAM) user, or IAM role.

Figure 1 – Transit Gateway between two accounts under the same Organization

In the example shown in the figure above, Account A has a Transit Gateway and Account A shared the same Transit Gateway to the entire Organization A. Here’s what will happen when Account A moved to the Organization Z as shown in the following figure:

1. The existing Transit Gateway Attachments will continue to function. Whether attachment to the VPC is in the same account or to the different accounts, there will be no network disruption to the existing connection.
2. In the AWS RAM, the existing principal (i.e., Organization ID) will be disassociated. This means that Account B under Organization A will no longer be able to see the Transit Gateway and its route tables. The creation of new attachments will be unavailable.
3. For the AWS accounts that still have an existing active attachment, like Account B, they can still see their own Transit Gateway attachment.

Figure 2 – Transit Gateway connectivity when Account A moved to Organization Z

To re-enable sharing after Account A moved to Organization Z, Account A as the Transit Gateway owner must re-grant the principals. They must also enable the Allow sharing with anyone option. Remember that the Organization Z’s management account must enable sharing with Organizations.

In regards to billing, the payer account in the new Organization will be responsible for the networking resources owned by the newly moved account. In the example shown in the figure above, this means:

• Transit Gateway cost will be charged to the Organization Z’s payer account.
• Transit Gateway attachment to VPC A1 and VPC A2 will be charged to the Organization Z’s payer account.
• Transit Gateway attachment to VPC B1 remains in the Organization A’s payer account. That also includes the data processing charges for the traffic sent from VPC B1 to the transit gateway.

Scenario 2: Cross accounts connectivity using VPC Peering

You can use VPC Peering to interconnect two VPCs so that you can route the traffic between them. The requestor and acceptor VPC can be from the same or different AWS accounts. The following figure shows the condition when Account A and Account B are still under the same Organization A.

Figure 3 – VPC Peering between Account A and B under the same Organization A

The following figure shows the condition after Account A moved to Organization Z. When one side of the peering is moved to the different Organization, VPC Peering will remain functional. If there are security group references over VPC Peering, they will also remain functional. There will be no traffic disruption either.

Figure 4 – VPC Peering after Account A moved to Organization Z

In terms of cost, there’s no change. Each side of the connection will still be charged for cross availability zones data transfer. For more information, see Amazon EC2 Pricing.

If we refer to the figure above, cross-AZ data transfer charges between VPC A3 and VPC B2 now will be paid by payer account in Organization A and Z respectively.

Scenario 3: Hybrid connectivity using Site-to-site VPN

is a fully-managed service that creates a secure connection between your data center or branch office and AWS, via the internet. You can configure Virtual Private Gateway or Transit Gateway as the target gateway. The following figure shows the hybrid connectivity from the customer’s premise to Account A using Site-to-site VPN.

Figure 5 – Hybrid connectivity using Site-to-Site VPN

Transit VPC architecture also uses the same approach by using IPSec VPN to connect multiple VPCs together. With Transit VPC you must host VPN appliances with that will aggregate multiple Site-to-Site VPNs from all other VPCs (in the same or different accounts).

Figure 6 – Site-to-site VPN when Account A moved to Organization Z

Account movement to a new Organization won’t disrupt Site-to-Site VPN connectivity. In the example shown in the figure above, active VPN tunnels toward Account A will remain connected. In regard to billing, if we refer to the figure above, Site-to-Site VPN hourly charges and the data transfer out will now be paid by Organization Z’s payer account.

Scenario 4: Hybrid connectivity using AWS Direct Connect

AWS Direct Connect is a cloud service that links your network directly to AWS to deliver consistent, low-latency performance.

Figure 7 – Sharing Direct Connect between two accounts using Direct Connect Gateway

There are two ways to share the connection:

1. Share the Direct Connect Gateway – so that another AWS account can associate their Virtual Private Gateway or Transit Gateway. The figure above shows that Account A has active Direct Connect connection and shares it using Direct Connect Gateway to Account B.
2. Allocate the virtual interface to another AWS account.

For both cases, moving the owner account of the Direct Connect connection to another Organization won’t impact the current traffic flow. In the example shown in the following figure, when Account A moved to Organization Z, the Direct Connect connection will remain active and the association between Direct Connect and VPC B2 in Account B will still be intact.

Figure 8 – Direct Connect connection when Account A moved to Organization Z

All costs related to the Direct Connect will remain the same. If we refer to the figure above, the cost for the Connection and data transfer out from VPC A3 will be paid by Organization Z’s payer account. However, Organization A’s payer account will keep paying for the cost of data transfer out from VPC B2. Visit Direct Connect pricing for detailed pricing information.

Scenario 5: VPC Sharing across multiple accounts

With VPC Sharing, you can share VPC subnets to the other principals within the same Organization. You use AWS RAM to share subnets, and you can share to the entire Organization (by specifying Organization ID), to certain OUs, or to individual accounts from the same Organization. The VPC Owner is the entity that owns and shares the subnets. The account that you shared the VPC with will be known as VPC Participant. If we refer to the following figure, Account A is the VPC Owner while Account B is the VPC Participant.

When the VPC Owner leaves the Organization, the subnets that were previously shared will no longer be shared to the other participants. However, any resources that were previously created by VPC Participants will remain active.

Figure 9 – VPC Sharing between two accounts in the same Organization

In the example shown in the figure above, Account B as the VPC Participant has Application Load Balancer (ALB) and EC2 instance (named EC2 Shared 1). Here is what will happen to those resources when Account A is moved to Organization Z as shown in the following figure:

1. Auto Scaling Group will no longer be able to launch new instance(s) since it can’t access the subnets anymore.
2. If an existing EC2 instance becomes unhealthy, then the Auto Scaling Group won’t be able to replace it with the new instance.
3. The ALB will still be available and forward the traffic to the available EC2 instances in the target group.
4. However, when the ALB must scale or undergo maintenance, this will fail. That is because the ALB can’t create new Elastic Network Interfaces, since the shared subnet is no longer available.
5. Unless the VPC Owner deletes the NAT Gateway, it will remain functional.

Figure 10 – VPC Sharing when Account A moved to Organization Z

The same behavior also applies for the opposite scenario, when Account B is moved to the other Organization.

If you want resources created by VPC Participant to remain active, then it’s recommended that you consider moving both the VPC Owner and VPC Participant account together and share the subnets again as soon as possible to minimize the impact.

There are no changes regarding billing, the VPC Participant account is still responsible for the charges incurred from the resources that they created. In the sample diagram in the figure above, Organization A’s payer account will still be charged for the ALB and EC2 Shared 1.

Scenario 6: Amazon Route53 Private Hosted Zone cross accounts sharing

You can use private hosted zones (PHZ) to store DNS entries for a private domain name that will only be resolved from associated VPCs. We can also share a PHZ to VPCs that belong to the different accounts. The following figure shows the sample configuration when Account A shares its PHZ to Account B. It also shows VPC B1 in the Account B already associated to that PHZ.

Figure 11 – Sharing Private Hosted Zone between accounts in the same Organization

When the owner of the private hosted zone is moved to a different Organization, any accounts that still have the private hosted zone associated to VPCs will remain able to resolve the respective domain. In a similar scenario, where an account that has a VPC with a private hosted zone association leaves the Organization, the zone will remain associated and the respective domain will continue to be resolvable. Referring to the following figure, after Account A has been moved to Organization Z, the private hosted zone association to VPC B1 will remain active. Therefore, EC2 B1 can still query the Private Hosted Zone. In short, the private hosted zone association will remain functioning regardless of the account movement activity.

Figure 12 – Private Hosted Zone sharing after Account A moved to Organization Z

Regarding billing, all of the costs related to the private hosted zone will remain the same. Visit the Route 53 Pricing page for more details regarding pricing.

Scenario 7: Amazon Route53 Resolver Endpoint cross accounts sharing

Route 53 Outbound Resolver endpoints can forward DNS queries to the remote network based on Route 53 Resolver rules. There are two types of Route 53 Resolver endpoints:

1. Outbound endpoints conditionally forward queries from within the VPC to resolvers on your network (e.g., to the on-premises network).
2. Inbound endpoints are used by remote networks to forward DNS queries to the Route 53 Resolver.

You can share Resolver rules to multiple VPCs (in the same or different accounts). You must use AWS RAM to share the rule to other principals (e.g., single account or Organization). The following figure shows that Account A has Route 53 resolver and shares its Resolver rule to Account B.

To learn about sharing Resolver rules, you can visit this article from AWS Premium Support.

Figure 13 – Route 53 resolver for hybrid connectivity

Here’s what will happen when an account that has a Resolver rule leaves an Organization:

1. If you share the rule to the entire Organization or to the OU, all accounts in that Organization will lose access to the Resolver rule. That means outbound requests won’t be processed by the rule and thus can’t resolve the respective domain anymore. Organization principals will be disassociated from the shared rules. If we refer to the following figure, Account A shares the rule to the entire Organization A. After Account A moves to Organization Z, resources inside VPC B1 can’t query the remote domain via the same Route 53 resolver anymore.
2. If you share the rule to the single account, then the shared rule will still work. The account can still resolve the domain. If we refer to the following figure, in the case Account A explicitly shares the rule to the Account B, then nothing changed when Account A moves to Organization Z. The resources inside VPC B1 can still query the remote domain via Account A’s Route 53 resolver.

Figure 14 – Route 53 resolver rule sharing when Account A moved to Organization Z

You can explicitly specify Account IDs as the principal prior to a migration. This approach is recommended to keep the rule available when the rule’s owner is moved to another Organization.

For the Inbound endpoint, as long as the remote network still has connectivity to the Inbound Endpoint’s IP addresses, it will remain functional.

All of the cost related to the Route 53 Resolver endpoints and resolver rules will remain the same. Visit the Route 53 Pricing page for detailed pricing information.

Considerations

If you’re migrating accounts outside of the Organization, then any shared resources that are deployed should be terminated to make sure of no unauthorized access to resources.

Another factor to consider is that AWS accounts belonging to an Organization can’t be invited to another Organization until they’ve left the previous Organization. Before the member account can leave the Organization, it must be configured with the information required to operate as a standalone account, and there are no Service Control Policies (SCP) that prevent member accounts from leaving the Organization.

Depending on the resources that are provisioned in the account, charges may be incurred during the period after leaving the original Organization and joining another. To learn more about AWS member accounts leaving an Organization, visit removing a member account from your Organization in the documentation.

Conclusion

In this post, we discussed the impact to AWS networking resources when moving AWS accounts to another Organization. Planning and preparation for AWS account migration will minimize the impact to the network connectivity. Visit How do I move accounts between organizations in AWS Organizations article to learn more about moving accounts between Organizations.