AWS Resource Access Manager
This course looks at how you can share resources such as subnets, transit gateways, aurora DB clusters and more, between AWS accounts, or within your AWS Organization using the AWS resource Access Manager
By the end of this course, you will have the knowledge and understanding of how to implement the sharing of resources between different AWS accounts.
This course has been created for those who have an operational responsibility to manage resources across multiple accounts. Within this course, I will be providing an overview of what the AWS Resource Access Manager is and how it’s used to create shared resources between accounts.
To get the most from this course you should be familiar with basic concepts of AWS Organizations for multi-account management.
Hello and welcome to this lecture covering a high-level overview of the AWS Resource Access Manager service. AWS Resource Access Manager, as the name clearly implies, allows you to securely share certain resource types across your AWS organization, or with any AWS account. This helps to minimize administration between your accounts as it negates the need to duplicate resources in each of your AWS accounts. At the time of writing this course, AWS Resource Access Manager, or RAM, supports the sharing of the following. Subnets, transit gateways, resolver rules, capacity reservations, license configurations, Aurora DB clusters, and traffic mirror targets. However, AWS is continually working to add more and more resource types, so be sure to check the AWS documentation for the latest supported resources which can be found here.
To understand how this sharing works, let me look at an example. Let's presume we wanted to share a subnet from one AWS account with another account. From an architectural point of view, what does this mean and how does it work? Well, once the subnet has been shared from the source account, let's call this account A, with another account, let's call this account B, then account B is able to see this subnet from within the management console or via the AWS CLI. This then allows Account B to use and deploy resources in that subnet, for example, having the ability to launch EC2 instances into that shared subnet. However, account B has no administrative control over the shared resource, so it can't delete the subnet or modify it in any way. The only action account B can take with the shared resource is to add or edit tags associated to the subnet. So to be clear, the subnet is not duplicated from account A and then added to Account B. Instead, the resource is simply shared from account A with account B, meaning the subnet itself remains a part of Account A and account A's VPC.
Let me run through a demonstration to show you how this is configured and how it works. In this demonstration, I will perform the following steps. I'll log in to my primary account via the AWS Management Console, I'll create a resource share of a subnet within my VPC of my primary account. I'll then nominate a different account from within my AWS Organization as the principal to this shared subnet resource. I'll then log in to the account that I shared the resource with, view the share from within the management console, and launch a new EC2 instance into the shared subnet.
Okay, let's take a look. As you can see, I'm logged in at the AWS Management Console, and this is going to be my primary account. So my primary account is, as you can see on the top right-hand corner here, is Stu Scott. So that's my primary account. So what I want to do, I want to share a subnet from this AWS account with another account that I have. So firstly, I need to go to the Resource Access Manager. And you can find that under the Security, Identity and Compliance section here. So if we just go to that. Now, if you haven't got any shares created already, then you'll be presented with this welcome screen, and it just gives you a brief overview of the service, use cases, etc. So let's get right into it and start creating our resource share. We can click on this orange button here, create a resource share. Now we've got a number of options that we can select. Firstly, we'll need to give this resource share a name. So we just call this SubnetSharing. Now, as we go down, we can select our resource type. As I mentioned previously, the current resource types that we have are subnets, transit gateways, resolver rules, capacity reservations, license configurations, Aurora DB clusters, and traffic mirror targets. For this demonstration, I'm going to be selecting a subnet. Under here, I have all my subnets in my VPCs. So I'm going to select this subnet here, this Public-Sub. So I can select that subnet. Now I have the subnet selected that I want to share, I can scroll down and allocate who I want to share this with. And this is in the Principals section. As you can see here, we can simply add the AWS account number, or the OU or organization if you're using AWS Organizations. Now, this account is actually part of an organization. So if I click on show organization structure, you can see here that here's my organization and I have two AWS accounts within this organization. So I'm going to select my other account, this CA-Demo account. If you scroll down, we can see that it's added the account number as the principal to share it with. Finally at the bottom, you can add a tag for your share as well, if you want to. That's just an optional value. So I'm just gonna leave that blank. Then I simply click on Create resource share. And now we see at the top in blue, our Resource Share has been successfully created. And that's it. It's as simple as that to create your resource share.
One thing I do want to show you quickly, is just on the left-hand side here under settings. If you do want to use AWS Organizations and select an account within your organization, then you'll need to enable this tick box here, which is enable sharing with your AWS organization. If you just want to configure sharing using the AWS account ID, then you can simply add that, that's no problem. But if you do want to enable sharing with your AWS organization, then do ensure that this tick box is ticked.
Okay. Now what I want to do is log in to the other account that I selected as the principal within this share. So let me just flip over now and go across to that account. Okay, so I'm now in the other account, as you can see up here the account has changed. So if I go across to my VPC configuration and take a look at the subnets, if I take a look at the subnets here, I notice that this bottom subnet wasn't here previously the last time I was logged in. And if I scroll right across to the end, we can see under the owner column that it is the other account, and this is the shared subnet. So it appears on our AWS Management Console as an available subnet to use, and that's exactly what we wanted. Now we can also see here that it's associated to a different VPC. And if I select on that, this shows me the options or the VPC of the primary account. And if we just take a look at the bottom here, we can see that the owner of this VPC is in fact the other account. So by setting up a share of the subnet, it's automatically shared the VPC details as well.
So now, let's go ahead and see if we can launch an EC2 instance in that shared subnet. So if I go across to EC2, Launch instance. Just select a Linux AMI. Go to configure. Let's go across to the network where we can select our VPC. So we have our default VPC, but we also have the shared VPC that's associated to the shared subnet. So we can select that VPC, and this allows us to see any subnets within this VPC that has been shared with us. And we can see here that this is the subnet as it's been highlighted as shared. And then we can simply go ahead and add our storage and tags, etc, and just carry on going through the process of launching an EC2. I'm just gonna accept all the default for the sake of this demonstration, and then launch the instance.
If I go to view instances, I can see that this instance is trying to launch at the moment, it's pending. And there we go, it's now running. So if we take a look at the instance details at the bottom here, we can see the subnet that it's associated to, and that is the shared subnet that's running in the primary account. And if I select on that subnet, it'll take us to the details. And again, if we have a look at the owner options at the bottom here, we can confirm that that is the shared subnet. So just to recap what we've done in this demonstration. In the primary account, I created a share of a subnet that was running in the VPC of that account. I added a secondary account as a principal of that share. I then logged in to that secondary account and confirmed that I could see that subnet available from within my management console, and I then created an EC2 instance and launched it within that same subnet. And that's it. So that's how you can create resource shares using the AWS Resource Access Manager.
That brings me to the end of this course, which explained the principles behind the AWS Resource Access Manager and how to share resources across accounts. If you'd like some additional information on some of the topics I covered in this course, then please take a look at the resources below. Feedback on our courses here at Cloud Academy is valuable to both us as trainers and any students looking to take the same course in the future. If you have any feedback, positive or negative, it'll be greatly appreciated if you can contact firstname.lastname@example.org. Thank you for your time, and good luck with your continued learning of cloud computing. Thank you.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.