Help us to make this transcription better! If you find an error, please
submit a PR with your corrections.
Eoin: Sharing is caring and if you are following the current best practices of using multiple AWS accounts, you'll end up having to share resources between accounts. For some things, you might be able to use resource-based policies to grant access or assume a role in the target account. This isn't suitable for everything, however, but luckily there is another way. Today, we are going to chat about Resource Access Manager and by the end of the episode, you should know what it does and how to use it. I'm Eoin, as always, I'm here with Luciano and this is AWS Bites. AWS Bites is brought to you by fourTheorem, the AWS partner who works with you to build successful projects in the cloud. Check us out at fourtheorem.com. Luciano, maybe you can start and tell us all what kind of problems is Resource Access Manager designed to solve? Yes.
Luciano: So AWS Resource Access Manager or RAM, which is not to be confused with random access memory, by the way, it's the same acronym. So this is a tool that is designed to solve the problem of securely sharing AWS resources across different AWS accounts within an organization or even with external organizations. It is basically designed to do this while it tries to reduce the cost by eliminating, for instance, resource duplications. You can simplify centralized access to resources and it can achieve security and compliance. So RAM allows you to share resources with, as I said, AWS accounts, including the ones outside or inside the organization. It can also share resources with accounts in a specific organization. So depending on the resource type, you can share things with, for instance, the organization itself and organization units with all the accounts inside of it or specific accounts. And you can also share resources with identities like users, roles. The pricing is interesting because effectively there is no additional costs. You only pay for the services that you are actually sharing. So you are creating resources that you share and you're going to be paying for those resources. Now, what are some of the use cases?
Eoin: The most common one you're likely to come across with RAM is VPC subnet sharing. Now, before Resource Access Manager, VPCs in different accounts, if you wanted to share them, it generally meant using something like VPC peering or transit gateway. If you share subnets in a VPC with RAM accounts, then get access to implicit routing in that VPC. So if you have a VPC in the owner account, you share it with participants and participating accounts, then they can use that subnet and it allows them to implicitly route within other resources already in that VPC. The IP address allocation then within the centrally managed subnets can be managed by a network team. So that's one of the advantages of this shared services VPC model.
Accounts with access to the shared resource then can access databases or VPC endpoints or other servers running in the subnets. So how does it work? Well, if you've got this shared services account, you create your VPCs and subnets in it, then you share the subnets with other accounts. Within an organization and participants can then see those shared subnets in their account. Now let's go back to the resource owner account. If they start an EC2 instance in the shared VPC, only they can see it. You're not sharing all of the things in the subnet per se.
Participants can't make networking changes. So only the owner can make changes to the subnets, but participants can provision resources they own into shared subnets. Like they can start their own EC2 instances in the account in the shared subnet. The participant will then own the EC2 instance, even though the shared owner account owns the subnet. I suppose it's worth saying that sharing subnets is very different solution to using VPC peering and Transit Gateway.
And you might use them in combination actually, because sharing with RAM means that you have access to an existing subnet. It doesn't really provide any additional routing. It just allows you to launch resources into existing subnets. If you wanted to have routing into this shared services VPC, you still need to do something like VPC peering or use Transit Gateway to route from one VPC to another, just like you do between any two VPCs. So RAM is not a routing solution, and that's something to be aware of, but you can combine it with things like Transit Gateway and peering. So that's the most common use case, I think, VPC sharing. Apart from networking, there are many other things you can share with RAM. AppSync APIs are one thing. There's code build projects. You can share capacity reservations, which is interesting for optimizing compute capacity costs. You can share FSX volumes. You can share GLUE catalogs, tables, and databases. So if you've got these catalogs in GLUE for access to data on S3, you can share it this way rather than having to duplicate those resources in many accounts. If you have a private certificate authority with the AWS Private CA, you can share that too. One of the things that one of our colleagues, Connor, wrote an article about was using RAM to share Aurora databases.
So he has a really good blog post on that. We're going to link that in the show notes. Another topic for where we wrote a blog was VPC lattice. And VPC lattice is a really cool topic. And if you haven't discovered it or haven't seen our previous episode, I'd recommend you check it out because it leverages RAM highly to share services and service networks. We have the episode on that. We have a blog post, and we have a sample application code. And the links for all three will be in the show notes. Transit gateways themselves are things you can share with RAM. And hot off the press, there is a new resource since last week only, I believe, which is sharing Systems Manager Parameter Store parameters, otherwise known as SSM parameters. This is something which people have been very excited about to hear because previously, you would really have to replicate those parameters. And there wasn't any way to share them across account. Now, if you've got parameters, let's say for custom AMI for an EC2 instance, and you want to share that across multiple accounts, everybody can discover the latest version of the AMI. You can now do that with parameter store. There's a couple of gotchas to know with SSM parameter sharing. It only works for advanced tier ones. So those are, I'm afraid, the more expensive ones, about $0.05 a month each. It doesn't work for the standard tier, which is the free option. So it definitely seems like AWS slipped up in allowing that standard tier to be free. And they're just trying to push all of the features into the advanced tier from now on as a correction measure. Luciano, those are some of the use cases. There are other services you can share with RAM. You can check out the full list in the link in the show notes. But let's say people want to use it. How do you get started?
Luciano: So there are a few steps that you need to follow. So first of all, you need to create a resource share in Resource Access Manager. And by default, every account you share with, so you share something with an account, that account receives an invitation. And to avoid this, you can also enable sharing with the entire AWS organization in the AWS Management Console. Normally, owner accounts have full access control and the shared principles have limited subset of permission. So again, it's still the idea that you are not giving up ownership. You are just allowing another account to see those resources and use them in different ways, depending on the type of resource. When you create a share, you need to specify a few different things. First of all, the resource type, for instance, is it a subnet? Is it a blue catalog? Is it an SSM parameter or something else?
Then you see the list of the resources of that type and you can pick the specific resources that you want to share on that list. And then you need to define the permissions that the recipients will get on the resources you have selected. And this will be either AWS Managed Permission or for some resources, you can even create your own custom managed permissions. Each resource type has different options for sharing within RAM and the supported options vary depending on the resource type.
Options can be things like whether you can share with an account outside the organization or you are maybe limited only to the account inside the specific organization. Whether you can share with IAM users and roles, whether you can share with AWS Service Principles or whether you can use custom managed permissions. So again, there is a guided process if you use the AWS Console and as you go through, you will see different screens and different options depending on the resources that you have selected. We will link to the documentation for more details just to get a better overview of what's possible, which resources can be shared and what options are available for every resource. But just to give you an example, if you want to share a subnet, all of the options that we mentioned are not available for this particular resource. What you cannot do, for instance, you cannot share with accounts outside the organization. So if you're sharing a subnet, that's going to be available only for the accounts inside your organization. You cannot share a subnet with specific IAM users and roles, and you cannot share it with Service Principles. And you have to use default AWS Managed Permissions. So effectively, you can allow participants to launch instances within the subnet, create EAPs and things like that that are predefined in AWS. You cannot really just create your own set of permissions and decide in a fine-grained way what people can do with that subnet.
Eoin: I guess you could, if you wanted to restrict that, use a Service Control Policy. One of the things we talked about recently, if you wanted to narrow down those permissions, but I don't know what your reason for that might be, maybe people can give some suggestions.
Luciano: Yeah, that's a really good point. But I guess the next question would be, once you share something from the ownership side, so you are sharing from a specific account, what would that look like from the participant side? So whoever is receiving access to that particular resource or set of resources.
Eoin: Yeah, so from the participant side, then if you go into RAM, you'll get a complete overview of all the shares and the resources shared within your account. So you can see what people have shared with you. And then when you go to see specific resources, like if you go into the VPC console, select a subnet, you will see the owner account column in the table. And you can see that the owner account is a different identifier than your account. And that's how you know it's an externally managed resource. If you share subnets, you can also see the associated VPC in the VPC console, which is maybe a little bit unexpected, because you haven't explicitly shared the VPC itself. The VPC as a thing is not a shareable resource with RAM. And participants can tag resources with separate tags to the shared resource, which is also probably unexpected, because you might expect that tags are an implicit part of the resource. But tags are almost like a separate resource that's linked to the subnet itself. So when you share a subnet, you don't share the tags, you can give us new tags in the participant account. Another unexpected thing you might see when you start sharing subnets across accounts is that you might share a subnet in us-east-1a, right, availability zone. And when you look at it in the participant account, you might see that it's called us-east-1b. And you will wonder what that's all about, and how they seem to have moved from a different data center 30 miles away.
And the reason for that, you may know, but in case you don't, it's worth stating it. When you create a new AWS account, AWS randomly assigns these availability zone labels to you in a just in a randomized way. So everybody's us-east-1a may be different. And if you want to see if they're actually in the same AZ, there's another identifier called the AZ ID. And this has a format like EUW1-AZ2. And these are physical AZ identifiers, and they do not change per account. So the whole idea with randomizing them is they don't want everybody to just pick the first AZ when they're launching something, and then have unbalanced load across their availability zones. So that's why to randomize them. If you are using availability zones names, then remember, they don't necessarily line up from account to account.
I think one thing you mentioned as well Luciano, which is worth highlighting again, is that sharing within an organization, if you want to make it easier, in fact, for some resources, you have to do this anyway. So it's probably worthwhile doing it, you just go into RAM in the management account, and enable sharing inside the organization. And then when you share resources, the acceptance is automatic, the participating accounts don't have to accept an invitation. So I think RAM is pretty powerful. It's probably a lot less complex than using resource policies or assume role for a lot of different services. And it avoids you having to duplicate resources and change identity as you have to with assume role. And I think that's all we have for today on Resource Access Manager. Let us know what you think. If you have any other neat uses for it. Apart from that, don't forget to share the podcast or the YouTube channel with your friends and colleagues. So thanks very much for listening again, and we'll catch you in the next episode.