AWS Resource Access Manager (RAM) lets you share AWS resources like AMIs, subnets, and Route 53 hosted zones across multiple AWS accounts within your organization.
Here’s an example of sharing a custom AMI. Imagine you have a hardened AMI in AccountA (the producer) that you want to use in AccountB (the consumer).
First, in AccountA, you’d navigate to the RAM console. Under "Create Resource Share," you’d select the AMI you want to share. You can choose to share it with specific AWS accounts by entering their Account IDs, or with an AWS Organization or Organizational Unit (OU). Let’s say you share it with AccountB’s ID: 111122223333.
# In AccountA, after creating the resource share in the console:
aws ram create-resource-share --name MySharedAMI --resource-arns arn:aws:ec2:us-east-1:999988887777:image/ami-0abcdef1234567890 --principals arn:aws:iam::111122223333:root --allow-external-principals
Now, in AccountB, you’d see this shared AMI appear under "Shared with me" in the EC2 console or via the AWS CLI. To use it, you’d simply select it when launching an EC2 instance.
# In AccountB, to list shared AMIs:
aws ec2 describe-images --executable-users self --owners self
# You'd need to filter or look for the AMI ID shared from AccountA
The core problem RAM solves is the manual, error-prone process of copying resources (like AMIs) or manually configuring cross-account access for services. Instead of duplicating AMIs or setting up complex VPC peering and IAM roles for every shared resource, RAM provides a centralized, managed way to grant access. It integrates with AWS Organizations, allowing you to define sharing policies at the organizational level.
Internally, RAM works by creating a "resource share" object. This object acts as a pointer to the resource you want to share and defines who can access it. When you share a resource, RAM doesn’t duplicate the resource itself; it creates permissions in the consumer’s account that allow them to see and use the resource located in the producer’s account. For services like EC2, this means the consumer account can launch instances from a shared AMI without that AMI ever leaving the producer account. For subnets, it means resources in the consumer account can be launched into a subnet that physically resides in the producer account.
The key levers you control are:
- Resource Type: What kind of AWS resource you are sharing (AMI, subnet, Route 53 hosted zone, license, etc.).
- Principals: Who you are sharing with. This can be individual AWS account IDs, AWS Organizations, or specific Organizational Units (OUs).
- Resource Share Name: A descriptive name for your share.
- Allow External Principals: Whether to allow sharing with accounts outside your AWS Organization.
When sharing a subnet, you’re essentially making that subnet appear as if it exists in the consumer account, allowing them to launch resources into it. The actual subnet remains in the producer account, and its lifecycle is managed there.
You can share subnets across accounts. This allows you to centralize your network infrastructure in one account (producer) and then allow other accounts (consumers) to launch their application resources into those shared subnets. This is incredibly useful for managing network security and IP address space consistently across an organization.
You can also share Route 53 Resolver rules and hosted zones. For hosted zones, this means accounts within your organization can resolve DNS queries using a centrally managed hosted zone without needing to replicate DNS records.
The most surprising thing about RAM is how it handles stateful resources like subnets. When you share a subnet, it doesn’t copy the subnet. Instead, it creates a reference in the consuming account that allows resources to be provisioned into that original subnet. The lifecycle of the subnet itself remains entirely under the control of the producing account.
The next step is to understand how to revoke access to shared resources and manage the lifecycle of those resource shares.