The above slide is from the Advanced Architecting on AWS course
Most AWS customers use multiple AWS accounts, which enables account isolation from a security perspective.
In order to make managing multiple accounts easier, AWS organisations was introduced.
However, before VPC sharing, each account had its own VPCs, and in order to connect VPCs together, VPC Peering was introduced, then later, the more scalable Transit Gateway.
VPC sharing allows the sharing of VPCs with other accounts in the Organisation or external to the organisation, including the following benefits, especially for highly interconnected applications:
- Centrally controlled VPC structure, routing and IP address allocation
- Efficient use of VPN and DX
VPC sharing within an Organization makes use of Resource Access Manager, a feature of AWS Organisations.
For a walkthrough, I will use two accounts in an organisation. I will refer to them as Account A and Account B.
Account A will create a shared subnet.
Both accounts will launch an instance in the shared subnet
To verify communication, the Account A instance will be used to ping the Account B instance.
One concept that you will notice in the walkthrough is to do with AZs. If Account A launches an instance in AZ A, this is not necessarily the same group of physical datacentres that Account B is using when Account B also chooses AZ A. The AZ letters are randomized by AWS in order to spread the workloads, otherwise if all customers chose AZ A, then that AZ would be over utilized compared to the others. So now, each AZ is allocated an ID. If you select a subnet, and look at the description, you see something similar to: eu-west-1a (euw1-az3).
Now for the walkthrough, which takes about 15 minutes.
Pre-requisites:
- An AWS organisation with 2 accounts. I will call them Account A and Account B.
- An existing VPC (not the default VPC as you cannot share that one) and a Public Subnet.
From the Master account (for me this is Account A), choose the Resource Access Manager service:
At the organisation level, Resource Sharing needs to be enabled.
Choose Settings: Enable Resource Sharing, Save
From Account A
Create Resource Share. I named it “My Shared Subnet”
Select an existing subnet to share. I used a Public Subnet in AZ A . Choosing a public subnet will make it easier to logon to an instance later to verify communication. In my case the AZ ID was eiw1-az3
Add Principal (note that it could also be an account external to the organization). Add the account number of Account B, Add, Create Resource Share.
From Account B:
Select Shared with me, Resource Shares. You should see the Shared Subnet.
To verify:
Now we will launch an instance in the Shared Subnet in each Account to test that they can communicate. I will use a ping for the test.
From Account A:
Launch an instance. I used AMZ Linux 2, t2.micro. Choose the existing shared VPC and subnet. Enable public IP so we can login to it. I tagged it “Account A instance”. For the security group, I enabled SSH.
From Account B:
Launch an instance. Note that when selecting a VPC and subnet, the shared VPC and subnet will appear (sharing a subnet makes the VPC a shared VPC). Choose the shared VPC and subnet. I tagged it Account B instance. For SG, I allowed All ICMP – ipV4 from anywhere. We will not need to login to it.
Take a note of the private IP of the instance.
From Account A
Note that Account A cannot see the Account B instance from the console. Account A has no permissions to access the resources of Account B, even for resources launched in the shared VPC.
Using the public IP of Account A instance, log in to the instance.
Ping the private IP of the Account B instance. It should work. That proves communication. The data transfer cost is free, as is the case whenever both instances are in the same AZ. Using VPC sharing, the performance is good as both instances are in the same AZ.
To clean up:
Terminate the instances
From Account A
From the RAM console
Select the Shared Subnet and Delete.
