AWS VPC Sharing

We have talked about connection options between AWS VPCs previously. Even we have multiple options to connect VPCs together, when the number of VPCs increases to a point, it becomes an overhead for maintenance and increases security risks. What if we change the design thinking and ask ourselves whether we can reduce the number of VPCs? The answer is yes. AWS provides us another option, VPC Sharing.

Prerequisites

When we talk about sharing a VPC, we should have at least two accounts. And the common way to manage multiple accounts in AWS is to use AWS Organization. So a multi-account environment managed under the AWS Organization is the first prerequisite.

The second one is the AWS Resource Access Manager (RAM). It’s the function that makes the resource sharing possible, including VPC sharing. And we must enable it in the master account within the AWS Organization to make it function. This “turn-on button” is located in the Resource Access Manager’s Settings page of the master account, as shown below.

Note that the checkbox will be greyed out once enabled. To disable it again, we’ll need to go to the master account->AWS Organizations->Services->RAM page to disable the trusted access.

Once we have these two prerequisites ticked, we can start to share VPCs. It’s existing to get hands dirty, but let’s hold it a little bit more and take a look at how VCP sharing works before we start the configuration.

Architecture Overview

To present the VPC sharing architecture, we’ll use a typical three-tier application architecture as an example, i.e. a load balancer in the public subnet, application server instances in the private subnet and a database instance in the restricted subnet. And we’ll start with one workload account that doesn’t use the VPC sharing first.

Without VPC Sharing

When not using the VPC sharing, the workload account uses its own VPC to host the application related instances across the three-tier subnets. If we have 10 workload accounts, we’ll have 10 VPCs, so on and so forth. For companies that manage a large number of workload accounts, this 1-vpc-to-1-account structure can bring a massive maintenance overhead to the service management team.

With VPC Sharing

On the other hand, if we choose to use VPC sharing, we can centrally manage the VPC from a shared service account (e.g. a shared network account), and share the subnets with the other workload accounts. Firstly, let’s bring in one workload account to take a look at the architecture design.

In this VPC sharing design, there are two accounts and one VPC. The shared network account owns and shares the VPC. The workload account hosts the application related instances, and allocates them in the shared subnets. Now, let’s bring in another workload account, but make it a little different. Let’s make the second workload account’s application not public facing, i.e. no load balancer in the public subnet. We can allocate both accounts’ application instances in the shared subnets, as shown below.

In this VPC sharing case, both workload accounts’ application instances are allocated within the same type of subnets, e.g. both workload accounts’ EC2 instances are set within the same private subnet. This architecture pattern is suitable for companies that want to take the max use of their IP ranges. However, from the isolation point of view, this pattern may not be the best way. So there is another common VPC sharing pattern that caters for this security requirement.

In this pattern, separate subnets have been created to host instances from different workload accounts to achieve the isolation purpose. In both VPC sharing patterns, there is still only one VPC under the shared network account but different number of subnets. The workload accounts don’t have any VPC set up locally. The network team can now centrally manage the VPC and subnets. They can apply different subnet allocation patterns or a combo of them based on the actual network and security requirements.

Hopefully the diagrams shed enough lights on the architecture part of VPC sharing. Now let’s get hands dirty.

Hands On

Having the “Enable sharing” option enabled in the master account (as we mentioned in the Prerequisites section) is not enough. We must configure the shared network account as well, to allow the other workload accounts to see the shared subnets. The steps are as below.

1. Log in to the shared network account (or the account that is set as the VPC owner account) as an admin user.
2. Open the RAM console at https://console.aws.amazon.com/ram/.
3. In the navigation pane, choose Resource shares.
4. Click the Create resource share button, to open the 4-step resource share creation page.
5. On the Step 1 page, enter the name, select resource type as Subnets, and then choose the subnets that you want to share. Tags are optional, but recommended. Click Next to move to Step 2.
6. On the Step 2 page, there is only one permission available, and it’s already prefilled, so we can click Next directly.
7. On the Step 3 page, choose the sharing scope and target(s). For scope, we can choose to share either within the organization or both inside and outside of the organization. For target, we can choose to share with different type of principals, i.e. Account, Org, OU, IAM user or role. Remember to click the Add button to pop the entry to the Selected principals list.
8. Once step 3 is completed, click Next to do a final review. If all good, click the Create resource share button.

To verify whether the subnets are shared as expected, we can check it from both the shared network account and workload accounts.

• From the shared network account, go to the VPC console, select the shared subnet from the subnet list, click the Sharing tab. We should be able to see the resource share item we just created in the list.
• From a workload account, go to the VPC console, we should be able to see the shared VPC in the VPC list. This VPC will also appear in the network configuration section when we create application instances. For example, when we create a new EC2 instance, we’ll be able to see the shared VPC and subnets in the network and subnet drop-down list.

In addition to this approach, we can also start the subnet sharing from the VPC console. By selecting a subnet from the subnet list, we can choose the Share subnet from the action list to initiate the VPC sharing. For more information about the VPC sharing configurations, permission and limitations, see Work with shared VPCs.

Summary

As we’ve discussed in the VPC connection options article, the introduction of Transit Gateway can reduce the number of VPC-to-VPC connections. But it doesn’t and can’t fully replace VPC peering. Similarly, VPC sharing can reduce the number of VPCs, but it’s not an almighty structure that can fit for all scenarios.

VPC sharing provides a centralised solution, which is a good add-on to the repository of the network topology design. Both centralised and decentralised designs have their own pros and cons. Based on the environment and business requirements, we can choose the most suitable one to apply, or combine them together to achieve the goal.