AWS Resource Access Manager (RAM) is a service that enables you to share AWS resources across accounts within your AWS Organization or with external accounts. This chapter covers how RAM works, its key components, and how it integrates with other AWS services. For the SAA-C03 exam, RAM is a targeted topic under Secure Architectures (Objective 1.4) appearing in approximately 2-5% of questions, often in scenarios involving multi-account architectures, shared networking, or license management. Understanding RAM is critical for designing cost-effective and secure resource sharing without duplicating resources.
Jump to a section
Imagine a large office building (your AWS Organization) with many separate suites (AWS accounts). Each suite has its own resources: printers, meeting rooms, and storage closets. Normally, employees in Suite A cannot use the printer in Suite B—they are isolated. AWS Resource Access Manager (RAM) is like a building management office that allows you to share specific resources across suites without moving them. For example, you can share a high-end conference room (a subnet) with Suite B and Suite C. The room stays physically in Suite A (the owner account), but employees from B and C can book it and use it as if it were their own. The building management keeps a registry of who can access which shared resources and enforces permissions. Importantly, when Suite B uses the conference room, they do not get a copy of the room; they use the original. If Suite A later decides to revoke access, the room becomes unavailable to B and C immediately. This is exactly how AWS RAM works: you share resources like subnets, transit gateways, or License Manager configurations across accounts, and the resource remains in the owner account with a single set of quotas. The shared accounts can manage and use the resource within the permissions granted, but they never own it.
What is AWS Resource Access Manager?
AWS Resource Access Manager (RAM) is a service that allows you to share AWS resources with other AWS accounts. Instead of creating duplicate resources in each account, you can share a single resource across multiple accounts. The shared resource remains in the owner account, but authorized accounts can use it as if it were their own. This reduces operational overhead and costs.
Why RAM Exists
In a multi-account strategy (e.g., using AWS Organizations), you often need to share resources like VPC subnets, transit gateways, or Route 53 Resolver rules. Without RAM, you would have to create separate resources in each account, leading to duplication, higher costs, and management complexity. RAM enables you to centralize resources while allowing other accounts to consume them.
How RAM Works Internally
RAM works by creating a resource share – a logical container that includes the resources you want to share and the principals (accounts or organizational units) you want to share with. The process is as follows:
The resource owner creates a resource share in the RAM console or via API.
The owner selects the resources to share (e.g., a subnet in a VPC).
The owner specifies the principals: individual AWS account IDs, organizational units (OUs), or entire organizations.
RAM sends an invitation to the target accounts (if they are not part of the same organization) or automatically associates them (if within the same organization).
The target account accepts the invitation (if required) and can then view and use the shared resources.
The target account can now launch instances into the shared subnet, create attachments to the shared transit gateway, etc.
Key Components
Resource Share: A logical grouping of resources and principals. Each resource share has a unique name and ARN.
Principal: An AWS account, OU, or entire organization that receives access to shared resources.
Resource: The actual AWS resource being shared, such as a subnet, transit gateway, or license configuration.
Association: The link between a resource share and a principal. Associations can be automatic (within the same organization) or require acceptance (external accounts).
Invitation: When sharing with an external account, RAM sends an invitation that the target account must accept.
Supported Resources
RAM supports sharing of the following resources (exam-relevant):
Amazon VPC subnets
AWS Transit Gateway
AWS License Manager configurations
Amazon Route 53 Resolver rules
AWS Network Firewall policies
AWS Cloud WAN core network
etc.
Defaults and Limits
You can create up to 1000 resource shares per region per account (soft limit, can be increased).
Each resource share can include up to 1000 principals and 1000 resources.
By default, resource shares within the same organization are automatically associated; no invitation is needed.
For external accounts, the invitation expires after 30 days.
Once a resource share is deleted, all associations are immediately revoked.
Configuration and Verification
To create a resource share via AWS CLI:
aws ram create-resource-share --name MyShare --resource-arns arn:aws:ec2:us-east-1:123456789012:subnet/subnet-0bb1c79de3EXAMPLE --principals 111122223333To accept an invitation:
aws ram accept-resource-share-invitation --resource-share-invitation-arn arn:aws:ram:us-east-1:111122223333:resource-share-invitation/abc123To list resource shares:
aws ram get-resource-shares --resource-owner SELFInteraction with Related Technologies
AWS Organizations: RAM integrates deeply with Organizations. If you share with an OU or the entire organization, accounts within that OU automatically get access without needing to accept invitations. This is the recommended approach for multi-account architectures.
VPC Sharing: When you share a subnet, the target account can launch EC2 instances, RDS databases, Lambda functions, etc., into that subnet. The target account sees the subnet in its own VPC console but cannot modify the VPC or delete the subnet.
Transit Gateway Sharing: You can share a transit gateway with multiple accounts. Those accounts can then attach their VPCs to the shared transit gateway, enabling cross-account network connectivity without creating multiple transit gateways.
License Manager: You can share license configurations across accounts to manage licenses centrally.
Security and Permissions
The resource owner retains full control. The target account can only use the resource within the boundaries of the permissions granted by the owner. For example, if you share a subnet, the target account can create and manage resources in that subnet but cannot delete the subnet or modify its route tables (unless you also share the route table via other means). RAM uses IAM permissions: to share resources, the owner must have ram:CreateResourceShare and permissions on the resource type (e.g., ec2:CreateSubnet). The target account needs ram:AcceptResourceShareInvitation to accept invitations.
Exam Tips
RAM is used to share resources, not to provide cross-account IAM roles or direct access to resources via IAM policies. IAM is for user permissions; RAM is for resource sharing.
Sharing a subnet allows target accounts to launch resources into the subnet, but they do not own the subnet. They cannot modify or delete it.
When sharing with an OU, new accounts added to that OU automatically get access to the shared resources.
Resources shared via RAM are subject to the owner's service quotas. For example, if the owner's VPC has a limit of 256 IP addresses per subnet, that limit applies to all accounts using the subnet.
RAM is free to use; you only pay for the underlying resources consumed.
Create Resource Share
The resource owner navigates to the AWS RAM console or uses the AWS CLI to create a resource share. They specify a name, select the resources to share (e.g., a subnet ARN), and define the principals (account IDs, OUs, or organization). The owner must have appropriate IAM permissions to share the resource type. RAM validates that the resource exists and the owner has access. The resource share is created with an initial status of 'active'.
Associate Principals
The resource share is associated with the specified principals. If the principal is an AWS account within the same organization, the association is automatic and immediate. If the principal is an external account, RAM generates an invitation. The association record is stored in RAM's internal database. The target account does not yet have access until they accept the invitation (if external) or the association is active.
Send Invitation (if external)
For external accounts, RAM sends an invitation to the target account. The invitation includes the resource share ID, the resources being shared, and a message. The invitation appears in the target account's RAM console under 'Invitations'. The invitation expires after 30 days if not accepted. The target account must have the `ram:AcceptResourceShareInvitation` permission to accept.
Accept Invitation (if external)
The target account accepts the invitation via the RAM console or CLI. Upon acceptance, RAM updates the association status to 'active'. The target account can now see the shared resources in their console (e.g., the subnet appears in their VPC console under 'Shared subnets'). The target account can start using the resource immediately. If the invitation is declined, the association is removed.
Use Shared Resource
The target account can now use the shared resource according to the permissions inherent to the resource type. For a shared subnet, the target account can launch EC2 instances, create ENIs, etc. The target account cannot modify or delete the subnet itself. The resource remains in the owner account and is subject to the owner's quotas. The owner can monitor usage via CloudTrail logs.
Enterprise Scenario 1: Centralized Network Infrastructure
A large enterprise uses a hub-and-spoke VPC architecture with a centralized transit gateway in a 'Network' account. They want to allow all application accounts (spokes) to connect to the transit gateway. Without RAM, they would need to create a separate transit gateway in each account and peer them, which is complex and costly. Using RAM, the Network account creates a resource share containing the transit gateway and shares it with the OU containing all application accounts. Each application account then attaches its VPC to the shared transit gateway. This setup enables centralized routing, inspection, and VPN connectivity. Performance considerations: the transit gateway's bandwidth is shared among all attached VPCs. Misconfiguration: if the resource share is accidentally deleted, all attachments become orphaned, breaking connectivity.
Scenario 2: Shared Subnets for Database Tier
A company uses separate AWS accounts for development, testing, and production. They want to use a shared RDS database in a central 'Data' account. They create a subnet in the Data account's VPC and share it with the other accounts. The other accounts can then launch RDS instances into that subnet, but the subnet remains in the Data account. This allows centralized backup and monitoring. Common pitfall: the shared subnet's IP address range is limited; if the Data account's subnet runs out of IPs, all accounts are affected. Scaling: they can share multiple subnets from different Availability Zones.
Scenario 3: License Management
An organization has purchased a block of licenses for commercial software and wants to distribute them across multiple accounts. They use AWS License Manager to create a license configuration and share it via RAM with all accounts in the organization. Each account can then use the licenses from the shared pool. This avoids over-purchasing and ensures compliance. Misconfiguration: if the license share is revoked, running instances using those licenses may be flagged as non-compliant. Performance: license consumption is tracked centrally.
What SAA-C03 Tests on RAM (Objective 1.4)
The exam focuses on understanding when to use RAM versus other cross-account access methods (like VPC Peering, Transit Gateway, or IAM roles). Key scenarios: sharing subnets for multi-account VPC strategies, sharing transit gateways for centralized networking, and sharing License Manager configurations. The exam also tests the automatic association within AWS Organizations vs. invitation-based sharing for external accounts.
Common Wrong Answers
'Use VPC Peering instead of sharing subnets' – Candidates confuse VPC Peering (which connects entire VPCs) with subnet sharing (which allows other accounts to use a subnet directly). Subnet sharing is for launching resources into a subnet owned by another account; VPC Peering is for network connectivity between VPCs. The exam may present a scenario where a company wants to reduce IP address usage by allowing multiple accounts to use the same subnet – the correct answer is RAM subnet sharing.
'Use IAM cross-account roles to grant access to the subnet' – IAM roles grant permissions to users or services, but they do not enable an account to see or use a subnet in another account. RAM is the service designed for resource sharing. IAM is for access control within an account.
'Create a copy of the subnet in each account' – This is the opposite of what RAM is for. The exam tests cost optimization and operational efficiency; duplicating resources is wasteful.
Specific Exam Values
The invitation expiration period is 30 days.
Resource shares can include up to 1000 principals and 1000 resources each (soft limits).
Supported resource types: subnets, transit gateways, License Manager configurations, Route 53 Resolver rules.
Edge Cases
If you share a subnet with an account that already has a VPC with overlapping CIDR, the shared subnet will not be usable because VPCs must have non-overlapping CIDRs.
When sharing with an OU, if you later remove an account from the OU, it loses access to the shared resources.
You cannot share a resource that is already shared via another resource share (though the same resource can be in multiple resource shares).
How to Eliminate Wrong Answers
Focus on the mechanism: RAM shares the actual resource (single instance) across accounts. If the question asks about reducing duplication or centralizing resources, RAM is likely the answer. If the question involves granting users access to resources, it's IAM. If it's about connecting VPCs, it's VPC Peering or Transit Gateway.
AWS RAM enables sharing of supported resources (subnets, transit gateways, License Manager configs, etc.) across accounts.
Resource shares can be created with individual accounts, OUs, or entire organizations.
Sharing within the same AWS Organization is automatic; external accounts require acceptance of an invitation.
Invitations expire after 30 days.
The target account can use the shared resource but does not own it; the owner retains full control.
RAM is free; you only pay for the underlying resources.
Common exam scenario: sharing a subnet to allow multiple accounts to launch EC2 instances into a centralized VPC.
Do not confuse RAM with VPC Peering or IAM cross-account roles – they solve different problems.
When you share a subnet, the target account cannot modify or delete the subnet.
RAM integrates with AWS Organizations for automatic sharing.
These come up on the exam all the time. Here's how to tell them apart.
AWS RAM (Resource Sharing)
Shares individual resources (e.g., subnet, transit gateway) across accounts.
Target account can launch resources directly into a shared subnet.
No need to manage overlapping IP addresses (though shared subnet must not overlap).
Works within an organization automatically or via invitation for external accounts.
Resource remains in owner account; owner controls lifecycle.
VPC Peering
Connects entire VPCs, allowing any resource in one VPC to communicate with any resource in the other.
Does not allow launching resources into another account's VPC; only network connectivity.
Requires non-overlapping CIDR blocks between peered VPCs.
Peering is a one-to-one connection; transitive peering is not supported (use transit gateway).
Each VPC remains independent; no resource sharing.
AWS RAM (Subnet Sharing)
Shares a subnet so multiple accounts can launch resources into the same subnet.
Network traffic within the shared subnet is local to the VPC.
Simplifies IP address management by centralizing subnets.
Target account sees the subnet in its console as 'shared'.
Best for scenarios where multiple accounts need to use the same set of subnets (e.g., shared services VPC).
AWS Transit Gateway
Provides a central hub for connecting multiple VPCs and on-premises networks.
Supports transitive routing between all attached VPCs.
Does not share subnets; each VPC retains its own subnets.
Each account attaches its VPC to the transit gateway.
Best for hub-and-spoke network topologies with many VPCs.
Mistake
RAM allows you to share any AWS resource.
Correct
Only specific resource types are supported. As of the SAA-C03 exam, supported resources include VPC subnets, transit gateways, License Manager configurations, Route 53 Resolver rules, and a few others. You cannot share EC2 instances, S3 buckets, or RDS databases directly via RAM.
Mistake
When you share a subnet, the target account owns the subnet.
Correct
The target account does not own the subnet; it only has permission to use it. The subnet remains under the owner account's management. The target account cannot modify or delete the subnet.
Mistake
Sharing resources via RAM requires the target account to accept an invitation in all cases.
Correct
If the target account is within the same AWS Organization, the association is automatic. No invitation is needed. Invitations are only sent when sharing with external accounts (outside the organization).
Mistake
RAM is a paid service.
Correct
AWS RAM itself is free to use. You only pay for the resources that are shared (e.g., the underlying VPC, transit gateway, etc.). There is no additional charge for using RAM.
Mistake
You can share a resource with an account and then revoke access immediately.
Correct
Yes, you can delete the resource share or remove the principal from the resource share. The revocation takes effect immediately. The target account will lose access to the resource and any resources they launched into a shared subnet may become orphaned (e.g., EC2 instances in a shared subnet will remain but the subnet may be deleted).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
To share a subnet, you create a resource share in the RAM console or CLI. Select the subnet(s) you want to share and specify the target account IDs, OUs, or organization. If the target is within your AWS Organization, they automatically get access. If external, they receive an invitation they must accept. After acceptance, the target account can launch resources into the shared subnet from their own account.
No, EC2 instances are not supported for sharing via RAM. RAM supports specific resources like subnets, transit gateways, and License Manager configurations. To give another account access to an EC2 instance, you would use IAM roles or resource-based policies (e.g., sharing an AMI via the EC2 console).
If the resource share is deleted, the target account loses access to the subnet. Any resources (e.g., EC2 instances) that were launched into the shared subnet will remain running but become orphaned – they will still exist but the subnet may be deleted if the owner deletes it. The instances will no longer be able to communicate if the subnet is deleted. It is recommended to stop or migrate instances before deleting a shared subnet.
No, RAM is regional. You can only share resources within the same region. If you need cross-region sharing, you must create resource shares in each region. However, some resources like transit gateways are regional, so sharing is limited to that region.
Yes, you can share resources with any AWS account by specifying the account ID. The external account will receive an invitation that must be accepted within 30 days. After acceptance, they can use the shared resource. This is useful for collaborating with partners or customers.
To create a resource share, you need permissions for `ram:CreateResourceShare` and permissions on the resource type you are sharing (e.g., `ec2:DescribeSubnets` for subnets). Additionally, you need `ram:AssociateResourceShare` and `ram:AssociateResourceSharePermission` if you are associating principals. The target account needs `ram:AcceptResourceShareInvitation` to accept invitations.
Yes, you can specify the organization ID as a principal. All accounts in the organization will automatically get access to the shared resource. This is often used for sharing a central transit gateway or subnet with all accounts.
You've just covered AWS Resource Access Manager (RAM) — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?