AWS Resource Access Manager (RAM)

AWS Resource Access Manager (RAM) is a service that allows you to share AWS resources that you own with other AWS accounts. Rather than duplicating resources or complex IAM cross-account roles, RAM provides a native, auditable, and secure way to share resources such as subnets, Transit Gateways, Route53 Resolver rules, License Manager configurations, and more. The primary driver is cost optimization and centralised management: you can create a shared VPC subnet once and allow multiple accounts to launch EC2 instances into it, eliminating the need for VPC peering or Transit Gateway attachments for simple scenarios.

RAM operates on a resource-sharing model. You create a resource share – a container that specifies which resources to share and which principals (AWS accounts, organizational units, or the entire organization) can access them. When you share a resource, RAM grants the principal access to that resource's ARN and permissions to use it according to the resource's own IAM policy. The resource owner retains full ownership and control; the consumer account can only use the resource as permitted by the resource type's sharing rules.

For example, if you share a subnet, the consumer account can see the subnet in its AWS console and launch EC2 instances into it, but cannot delete or modify the subnet. The owner manages any updates (e.g., changing route tables) and those changes are immediately visible to consumers.

RAM integrates with AWS Organizations. If you enable sharing with AWS Organizations in RAM, you can share resources with all accounts in your organization or specific OUs without needing to add each account ARN individually. This simplifies management and scales to hundreds of accounts.

As of the SOA-C02 exam, the following resource types are commonly tested:

Note that you cannot share IAM roles, S3 buckets, or EC2 instances directly via RAM – those use different mechanisms.

To create a resource share via AWS CLI:

aws ram create-resource-share \
    --name MySharedSubnet \
    --resource-arns arn:aws:ec2:us-east-1:123456789012:subnet/subnet-0bb1c79de3EXAMPLE \
    --principals 111111111111

To list resource shares:

aws ram get-resource-shares \
    --resource-owner SELF \
    --region us-east-1

To see associations:

aws ram get-resource-share-associations \
    --association-type RESOURCE \
    --resource-share-arn arn:aws:ram:us-east-1:123456789012:resource-share/xxxxxxxx

RAM uses AWS CloudTrail to log all API calls. You can audit who shared what resource with whom. The resource owner can revoke sharing at any time by deleting the resource share or removing the principal. When revoked, the consumer account loses access immediately; any existing resources (e.g., EC2 instances) in a shared subnet are not terminated but the consumer cannot launch new ones.

Many candidates confuse RAM with cross-account IAM roles. RAM shares the resource itself, not access through a role. With RAM, the consumer account directly accesses the resource; with IAM roles, you assume a role in the owner account to access resources. RAM is simpler for resource sharing but does not grant administrative access to the resource – only usage.

In enterprise environments, AWS RAM is frequently used to implement a shared VPC model. For example, a large financial institution has a central networking team that manages a single VPC with multiple subnets. They use RAM to share subnets with dozens of application accounts. This reduces the complexity of managing separate VPCs, simplifies security group management, and centralizes egress traffic through a single NAT Gateway. The networking team creates a resource share containing all subnets and shares it with the entire AWS Organization. Application teams then launch their EC2 instances and RDS databases directly into the shared subnets. They do not need VPC peering or Transit Gateway attachments for basic connectivity. A common pitfall is that application teams forget to request the necessary security group rules from the networking team, leading to connectivity issues. Also, if the networking team accidentally deletes a subnet, all resources in that subnet are impacted.

Another scenario is centralized Transit Gateway sharing. A company with multiple VPCs across different accounts uses a single Transit Gateway owned by a central account. They share the Transit Gateway via RAM with all other accounts. Each account then attaches its VPCs to the shared Transit Gateway. This avoids the need for each account to create its own Transit Gateway and reduces costs. Performance considerations include the bandwidth limits of the Transit Gateway and the number of attachments. If the Transit Gateway owner modifies routing tables, all attached VPCs are affected. Misconfiguration can lead to routing loops or black holes if route propagation is not properly managed.

A third scenario is License Manager sharing. A software vendor wants to enforce license limits across multiple accounts. They create a license configuration and share it via RAM with all accounts in their organization. Each account can then associate the license configuration with their EC2 instances. The vendor can centrally track license usage and ensure compliance. If the sharing is accidentally revoked, instances may become non-compliant, triggering alerts. The key is to ensure that the license configuration is shared with the correct principals and that the consumer accounts have the necessary IAM permissions to use it.