AWS RAM lets you share resources across your AWS accounts, but it’s not just a simple "on" switch for permissions.
Let’s see how this actually looks. Imagine you have a VPC peering connection in AccountA that you want to share with AccountB.
First, in AccountA, you’d create a Resource Share.
{
"Name": "MyVpcPeeringShare",
"ResourceShareArn": "arn:aws:ram:us-east-1:111122223333:resource-share/a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"AllowExternalPrincipals": false,
"Tags": {}
}
Then, you associate the resource you want to share. In this case, it’s the VPC peering connection.
aws ram associate-resource-share-permission --resource-share-arn arn:aws:ram:us-east-1:111122223333:resource-share/a1b2c3d4-e5f6-7890-abcd-ef1234567890 --permission-arn arn:aws:ram::aws:permission/AWSRAMPermissionVPCPeering
And finally, you specify who can access it. You can share with specific AWS accounts by their Account ID, or with AWS Organizations’ Organizational Units (OUs) or the entire organization.
aws ram associate-resource-share --resource-share-arn arn:aws:ram:us-east-1:111122223333:resource-share/a1b2c3d4-e5f6-7890-abcd-ef1234567890 --resource-arns arn:aws:ec2:us-east-1:111122223333:vpc-peering-connection/pcx-0123456789abcdef0
aws ram associate-principal-with-resource-share --resource-share-arn arn:aws:ram:us-east-1:111122223333:resource-share/a1b2c3d4-e5f6-7890-abcd-ef1234567890 --principal "arn:aws:iam::444455556666:root"
In AccountB, you’ll see this shared resource appear in the AWS RAM console under "Shared with me". For the VPC peering connection to actually be usable, the receiving account (AccountB) must also accept the peering connection request. RAM only handles the sharing of the resource object, not the inherent cross-account acceptance mechanisms of that resource type.
The core problem RAM solves is centralizing the management and distribution of resources that are inherently difficult to grant permissions for across account boundaries. Think of AWS Organizations’ Service Control Policies (SCPs) or even IAM policies themselves; while powerful, they can become complex to manage at scale for specific, granular resource sharing. RAM provides a dedicated service for this, abstracting away some of the underlying IAM complexity by creating resource share associations that link a resource to specific principals (accounts, OUs, or the entire organization). It’s essentially a controlled delegation mechanism for specific AWS resources.
When you share a resource, RAM creates a new, read-only version of that resource’s ARN that is prefixed with the RAM ARN. For example, a VPC peering connection ARN pcx-0123456789abcdef0 might be referenced in the shared resource as arn:aws:ec2:us-east-1:111122223333:vpc-peering-connection/pcx-0123456789abcdef0. The receiving account (AccountB) uses this RAM-prefixed ARN in its own IAM policies or resource configurations to access the shared resource. This indirection is key; AccountB doesn’t get direct IAM permissions to the resource in AccountA. Instead, it gets permissions to access the shared resource via RAM.
A common point of confusion is that sharing a resource via RAM doesn’t automatically grant the receiving account permission to use that resource in the way it expects if that resource has its own cross-account acceptance flow. For example, a shared VPC peering connection still needs to be explicitly accepted by the target account. Similarly, sharing an AMI doesn’t mean the other account can launch an EC2 instance from it without also granting the necessary IAM permissions to perform EC2 actions. RAM is about making the resource visible and addressable across accounts, but the resource’s native operational permissions still apply.
The most surprising true thing about AWS RAM is that the permissions you grant to a principal on a shared resource are not IAM policies. Instead, RAM uses its own permission model that is associated with the resource share. When you create a resource share, you can attach a specific RAM permission (like AWSRAMPermissionVPCPeering). This permission defines what operations can be performed on the shared resource by the principals associated with that share. This means you don’t directly attach IAM policies to the shared resource itself; you manage permissions at the resource share level within RAM.
The next concept you’ll likely encounter is managing the lifecycle of these shared resources, particularly when resources are updated or deleted in the owning account.