AWS Resource Access Manager (RAM) for Network Engineers
Tags: aws, networking, networkengineering, cloud
Published: 2023-10-27 19:46:55

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.
![Accounts Page](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9u71isfj4x61oq4sy4dw.png)

**Create a transit gateway in the network services account.**

![Network Services TGW](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/whltuyib62ckqe33md9j.png)
**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.

![Network Services TGW Route Table](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6wo18ois0w1qf579iqys.png)
**Create consumer VPC.**
The image below depicts the creation of our `ConsumerAccount` VPC being created.
![Consumer VPC](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qtbeki6kvlrgeng4unxl.png)
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.

![Consumer Account TGW](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/veqvmhi67nd3q38dkvos.png)
**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.

![Provider Shared Resource](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/clg3hpk6sd922bcz391h.png)
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.

![Consumer Shared Resource](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/941w3vxxtebhtlp2nwx0.png)
**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.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hvsjm8a5x7y3b0nmhykw.png)

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/131j64pwm9nopxtadnyp.png)

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.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/g609zaiouko9srvanwin.png)

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.