AWS Resource Access Manager (RAM) for Network Engineers

In this post I want to explain and provided examples of why a network engineer working with AWS may need to understand AWS RAM (Resource Access Manager). I recently was dealing with an issue at work, specifically related to cross account resource sharing. It was my first encounter with AWS RAM and the need to share access to a TGW (Transit Gateway) across multiple AWS accounts. In the post below I'll be using purely network related examples because my target audience are network engineers, but this applies to anyone who needs to share access to resources between accounts.

First, for those who are unfamiliar with transit gateways. They basically allow you to create a hub and spoke topology in the cloud. The TGW has its own route table and allows you to connect separate virtual private clouds (VPC) to it. Once you've connected a VPC to a TGW you have the ability to facilitate communication inter-VPC, out of AWS, back on prem, ect. There are a lot of things you can do, but at a high level its just a centralized router that bridge a bunch of VPC's together or route you back on-prem. Further down in the post you'll see me speak about attachments. Just know that in order to connect a VPC to a TGW you'll need to "attach" it to the TGW and that's all that is being referenced when you see the word attachments.

Next lets set the context for this illustration, perhaps your organization has multiple accounts and each account is owned by a particular IT team whether it's a development team, security, sysadmins, etc. In this case, lets say the network team owns all the network transit from on-prem into AWS and within AWS itself between VPC's. In this case it would make sense that network services may own multiple transit gateways which certainly could control all your north/south/east/west traffic. We need to provide access to one of our transit gateways to a core IT service so they can properly route traffic in and out of their VPC. Without such access they would essentially be cut off from any of the required services being offered on-prem or in the cloud by other IT teams.

Order of operations

1. Create the consumer account(this consumer account will simulate a sister team that needs access to all other company resources).
2. Create a Transit Gateway and a VPC in the network services account.
3. Create a VPC in the consumer account.
4. Share the resource between accounts.
5. Request attachments to network services TGW and accept incoming connection attempt.

Walk Through

Consumer account creation.
Notice I have two accounts under the root OU. Friday which is my main account (but will be referred to as NetworkServices from here on out), and ConsumerAccount which is our sister team's account.

Create a transit gateway in the network services account.

Create a VPC in the Network Services account.
This image does not depict the VPC, but instead is an image of the transit gateway route table. This is enough to illustrate the fact that our VPC has been created, is attached to the TGW and its CIDR has been learned by the TGW route table.

Create consumer VPC.
The image below depicts the creation of our ConsumerAccount VPC being created.

Notice the screen shot below. Without RAM our ConsumerAccount cannot see a transit gateway available even though the resources are in the same region and ultimately under the same root OU. The administrative segregation between these accounts blocks them from sharing any resources.

Resource sharing
The first image is just a glimpse of what a shared resource looks like from the perspective of the sharing account, in our example this is from the perspective of the Network Services account. We see its being shared by the Shared by me: Resource share heading on the AWS page.

And below is an example of what the ConsumerAccount would see in their account, a pending invite to accept a resource share. This is a resource needs to be accepted by account before it can be used.

Accept Shared Resource
At this point the resource has been shared from the Network Service account. The ConsumerAccount then needed to accept that resource so it can be used in their account. Now the ConsumerAccount just needs to request to be attached to the Network Services TGW and Network Services needs to accept that TGW attachment invite.

See that our consumer is requesting to attach to the TGW.

Network Services will see that pending invite and must accept it.

Lastly, the only part we care about, it routes! In this final image we now see the route table of our transit gateway. The TGW route table knows the CIDR block of our (Network Services) VPC, it also knows about the CIDR of our ConsumersAccount and will be able to route traffic between these accounts which otherwise would have no routing capabilities between each other.

In conclusion, this is how AWS facilitates accounts to "own" a product or service but share it between accounts as if that consumer account owned the resource.