Lesson: Mastering Resource Sharing with AWS Resource Access Manager (RAM)

Introduction: The Architecture of Multi-Account Environments

As organizations grow and adopt cloud computing at scale, the default starting point is often a single AWS account. However, as requirements for isolation, billing transparency, and security boundaries emerge, organizations naturally transition to a multi-account strategy. Using AWS Organizations, companies can manage dozens or even hundreds of accounts efficiently. Yet, a multi-account strategy introduces a significant engineering challenge: how do you share specific infrastructure resources—like subnets, transit gateways, or license configurations—across these isolated accounts without creating redundant, costly, and difficult-to-manage infrastructure silos?

This is where AWS Resource Access Manager (RAM) becomes essential. AWS RAM is a service that allows you to share your resources across AWS accounts, within your organization, or with specific organizational units (OUs). Instead of duplicating a NAT gateway or a VPC endpoint in every single account—which is not only expensive but also creates a massive networking management headache—you can create these resources once in a central account and share them with the accounts that actually need to consume them.

Understanding RAM is not just about knowing which buttons to click in the console; it is about mastering the design patterns of shared services. This lesson will walk you through the mechanics of RAM, the security implications of cross-account sharing, and the practical implementation steps required to build a shared services architecture that is both secure and scalable.

The Core Concept: How AWS RAM Works

At its simplest level, AWS RAM acts as a bridge between the resource owner and the resource consumer. The resource owner creates a "Resource Share," which acts as a container for the resources you wish to share and the accounts or OUs that are permitted to access them.

When you share a resource, you are not moving the resource. The resource remains in the owner account, and the owner retains full administrative control over its configuration, lifecycle, and deletion. The consumer account merely gains the ability to "see" and "use" the resource as if it were local to their own environment. For example, if you share a subnet from your Shared Services VPC, an application team in a separate account can launch an EC2 instance into that subnet, but they cannot modify the routing tables or change the VPC peering configuration associated with that subnet.

Callout: The Principle of Resource Ownership It is critical to understand that AWS RAM does not transfer ownership. The account that creates the resource is the only account that can delete, update, or modify the resource's underlying properties. The consumer account is essentially a "tenant" with limited permissions, defined by the owner, to interact with the resource. This separation of duties is the foundation of secure multi-account design.

Key Components of RAM

• Resource Share: The primary object in RAM that defines what is being shared and who has access to it.
• Principals: The entities that can access the shared resource. This can be an AWS account ID, an Organizational Unit (OU), or the entire Organization.
• Managed Permissions: AWS provides pre-defined permission sets for each resource type. These define exactly what actions the consumer can perform on the resource.
• Resource Owner: The account where the resource was originally created and where the Resource Share is managed.

Practical Use Cases for AWS RAM

To understand why RAM is necessary, we must look at the common scenarios where it is applied. Without RAM, developers often resort to "VPC Peering Mesh" or "Account Bloat," where every account needs its own set of infrastructure components.

1. Centralized Networking

The most common use case is sharing VPC subnets. In a centralized networking model, you create a dedicated "Network Account." You create a VPC with public and private subnets, NAT Gateways, and Internet Gateways in this account. By using RAM, you share these subnets with your application accounts. This allows application teams to deploy workloads into pre-configured, compliant networks without needing to manage the underlying networking infrastructure themselves.

2. AWS Transit Gateway

Managing individual peering connections between VPCs is a management nightmare. By using a Transit Gateway, you can centralize routing. You can share the Transit Gateway across your organization, allowing different VPCs in different accounts to attach to the same gateway, effectively creating a hub-and-spoke network topology that is easy to route and monitor.

3. AWS License Manager

If you have specific software licenses (such as SQL Server or Windows Server) that you have purchased in bulk, you can manage these centrally using License Manager and share the license configurations via RAM. This ensures that you maintain license compliance across the entire organization without needing to track licenses on a per-account basis.

4. Route 53 Resolver Rules

If you have a hybrid cloud environment where your VPCs need to resolve domain names from your on-premises data center, you can configure a Route 53 Resolver outbound endpoint in a central account. You can then share the Resolver Rules that direct traffic to your on-premises DNS servers with all other accounts, ensuring consistent name resolution across the entire cloud footprint.

Step-by-Step: Sharing a Subnet via RAM

Let’s walk through the process of sharing a subnet from a central Networking account to an application account.

Step 1: Enable Resource Sharing in AWS Organizations

Before you can share resources across your organization, you must enable this feature in your AWS Organizations management account.

1. Sign in to the AWS Organizations management account.
2. Navigate to the RAM console.
3. Select Settings.
4. Ensure the checkbox for "Enable sharing with AWS Organizations" is checked.

Note: If you do not enable this at the Organization level, you will only be able to share resources with individual AWS account IDs manually, which is not sustainable for large environments.

Step 2: Create the Resource Share

Now, move to the account that owns the subnet (the "Network Account").

1. In the RAM console, click Create a resource share.
2. Give your share a descriptive name (e.g., prod-vpc-subnets).
3. Under Resources, select the VPC and the specific subnets you wish to share.
4. Under Principals, select the OU or the specific AWS account IDs you want to grant access to.
5. Review the Permissions. RAM will automatically select the default managed permission for the resource type (e.g., AWSRAMDefaultPermissionSubnet).
6. Finalize and create the share.

Step 3: Verify in the Consumer Account

Once the share is created, log into the application account.

1. Navigate to the VPC console.
2. Select Subnets.
3. You will now see the shared subnet listed. It will be clearly marked as "Shared" in the resource attributes.
4. Attempt to launch an EC2 instance. When selecting the subnet, the shared subnet will be available in the dropdown menu.

Understanding RAM Permissions

When you share a resource, you are implicitly granting a set of permissions. AWS provides "Managed Permissions" that are specific to each resource type. It is vital to understand that you cannot create custom permissions for RAM; you must use the managed permissions provided by AWS.

The Anatomy of a Managed Permission

A managed permission defines the scope of what the consumer can do. For a subnet, the default permission allows the consumer to:

• Describe the subnet.
• Create network interfaces (ENIs) within that subnet.
• Delete network interfaces that the consumer created.

The consumer cannot delete the subnet itself, nor can they modify the Route Table associated with the subnet. This is a critical security feature. It ensures that the "Network Account" maintains total authority over the network topology, while the "Application Account" maintains the ability to deploy compute resources.

Callout: Managed Permissions vs. IAM Policies It is a common mistake to confuse RAM permissions with IAM policies. RAM permissions control the access to the shared resource object itself. However, even if an account has access to a shared subnet via RAM, the individual user in that account still requires an IAM policy that allows them to perform actions like ec2:RunInstances within that subnet. You need both the RAM share to exist and the IAM permissions to be configured correctly to successfully use the resource.

Best Practices for Multi-Account Resource Sharing

1. Use Organizational Units (OUs) for Access Control

Never share resources with individual account IDs if you can avoid it. Instead, structure your AWS Organizations into OUs based on environment (e.g., Prod-OU, Dev-OU, Shared-Services-OU). Share your resources with the entire OU. This way, when you add a new account to the Dev-OU, it automatically gains access to the dev resources without requiring manual intervention.

2. Implement a "Centralized Networking" Account

Do not share subnets from random accounts. Designate a specific account as your "Network Hub." All VPCs that are intended to be shared should reside in this account. This simplifies auditing, as you only need to look in one place to see which resources are being shared and who has access to them.

3. Monitor Access with CloudTrail

Since sharing resources is a cross-account activity, it is a high-visibility event. Ensure that you have AWS CloudTrail enabled in all accounts. You can track the CreateResourceShare and AssociateResourceShare events to audit who is creating shares and what is being shared. This is an essential part of your security compliance posture.

4. Tagging for Visibility

When you share a resource, the consumer account sees the resource ID, but they may not know its purpose. Use descriptive tags on your shared resources (e.g., Environment: Production, Owner: Network-Team, Project: Core-Networking). These tags propagate to the consumer account and help developers understand what they are using.

5. Avoid Over-Sharing

The principle of least privilege applies to resource sharing. Do not share an entire VPC if you only need to share a specific subnet. Do not share resources with the entire Organization if only one specific department needs them. Periodically audit your resource shares to ensure that the access is still required.

Common Pitfalls and Troubleshooting

Even with a well-designed architecture, you will encounter challenges when working with RAM. Here are the most frequent issues and how to solve them.

Pitfall 1: The "IAM vs. RAM" Confusion

As mentioned earlier, users often get frustrated because they see the shared resource in the console but receive an "Access Denied" error when trying to use it.

• The Fix: Check both the RAM share status and the IAM policy of the IAM user or role. Ensure the IAM policy includes the necessary permissions to use the resource (e.g., ec2:CreateNetworkInterface for subnets).

Pitfall 2: Resource Dependency

Some resources have dependencies. For example, you cannot share a subnet if the VPC it belongs to is not also shared or if there are specific requirements for the route tables.

• The Fix: Always share the VPC alongside the subnets if your architecture requires the consumer to have visibility into the VPC configuration.

Pitfall 3: Deleting Shared Resources

If you attempt to delete a shared resource (like a subnet) while it is still being used by a consumer account, the deletion will fail.

• The Fix: You must first remove the consumer account from the Resource Share or delete the Resource Share entirely. Once the association is broken, you can proceed to delete the underlying resource.

Pitfall 4: Limitations on Resource Types

Not all AWS resources support RAM. For instance, you cannot use RAM to share S3 buckets or IAM roles directly.

• The Fix: Always check the AWS RAM documentation to confirm if the resource type you intend to share is supported. If a resource is not supported, you must use alternative methods, such as cross-account IAM roles or resource-based policies (which are distinct from RAM).

Comparison: RAM vs. Other Cross-Account Access Methods

It is important to know when to use RAM and when to use other methods.

Warning: Do not use Cross-Account IAM Roles for infrastructure sharing. While it is technically possible to give an account access to a VPC by assuming a role in the owner account, this is a security risk. It gives the consumer account broad administrative power over the owner account's resources. RAM is a much safer, "read-only" style approach for sharing infrastructure.

Advanced Architecture: The Shared Services Hub

To synthesize everything we have discussed, let’s look at a concrete example of a "Shared Services Hub" architecture.

In a large enterprise, you might have:

1. Network Account: Houses the Transit Gateway, shared subnets, and Route 53 Resolver endpoints.
2. Security Account: Houses centralized logging (CloudTrail, VPC Flow Logs) and security tooling.
3. App Accounts: Dozens of accounts where individual business units run their applications.

By using RAM, the Network Account shares subnets and the Transit Gateway with the App Accounts. The App Accounts are then configured to route all traffic through the Transit Gateway. Because the Network Account owns the Transit Gateway, they can implement centralized traffic inspection by routing traffic through a firewall appliance (like AWS Network Firewall) located in the Network Account.

This architecture provides:

• Governance: The Security Team controls the firewall and network routes.
• Isolation: The App Teams cannot modify the network configuration, preventing "shadow IT" networking.
• Cost Efficiency: You only pay for one set of NAT Gateways and one set of Transit Gateway attachments, rather than duplicating them in every account.

Code Snippet: Sharing a Resource with Terraform

If you are using Infrastructure as Code (IaC), you can automate the creation of resource shares. Here is an example of how to create a resource share for a subnet using Terraform.

# Define the resource share
resource "aws_ram_resource_share" "subnet_share" {
  name                      = "prod-subnet-share"
  allow_external_principals = false

  tags = {
    Environment = "Production"
  }
}

# Associate the subnet with the share
resource "aws_ram_resource_association" "subnet_association" {
  resource_arn       = aws_subnet.shared_subnet.arn
  resource_share_arn = aws_ram_resource_share.subnet_share.arn
}

# Define the principals (the OU or Account IDs)
resource "aws_ram_principal_association" "org_association" {
  principal          = "arn:aws:organizations::123456789012:ou/o-exampleorgid/ou-examplestructure"
  resource_share_arn = aws_ram_resource_share.subnet_share.arn
}

This code is a standard way to ensure your infrastructure sharing is version-controlled and repeatable. By putting this in your Terraform modules, you ensure that every time a new environment is spun up, the necessary network resources are automatically shared with the correct accounts.

The Security Implications of Sharing

Security is often the primary concern when discussing cross-account resource sharing. There is a fear that by sharing a resource, you are opening the door to the entire owner account. This is a misconception.

RAM is designed with a "Blast Radius" approach. When you share a resource, you are only exposing that specific resource to the consumer. The consumer has no visibility into other resources in the owner account. For example, if you share a subnet, the consumer cannot see the EC2 instances, RDS databases, or Lambda functions that might be running in other subnets within the same VPC. They are strictly limited to the subnet they have been granted access to.

However, you must be careful with Implicit Trust. If a consumer account is compromised, the attacker can use the shared resource as a pivot point. For example, if they have access to a shared subnet, they can launch instances in that subnet and attempt to scan or attack other resources that are also attached to that VPC.

Best practices for mitigating this risk:

1. Security Groups: Always enforce strict security groups on any resource created in a shared subnet. Never rely on the subnet boundary alone.
2. Network ACLs: Use Network ACLs to add a second layer of defense, restricting traffic between subnets even if they are within the same VPC.
3. Monitoring: Use VPC Flow Logs to monitor traffic patterns within shared subnets. If you see unusual traffic from an application account to a sensitive database in the network account, you can quickly identify the source and revoke access.

Frequently Asked Questions (FAQ)

1. Does RAM cost extra?

No, there is no additional charge for using AWS RAM. You only pay for the underlying resources you are sharing (like the VPC, Transit Gateway, or License Manager configurations).

2. Can I share resources across different AWS Regions?

Some resources are global, while others are regional. For regional resources like subnets, you can only share them within the same region. You would need to create a resource share for each region where you have resources you wish to share.

3. What happens if I delete a resource share?

If you delete a resource share, the consumer accounts will immediately lose access to the shared resources. If they have active resources (like an EC2 instance) running in a shared subnet, those instances will continue to run, but the consumer will no longer be able to modify the network interfaces of those instances or create new ones in that subnet.

4. Can I share resources with accounts outside of my AWS Organization?

Yes, you can share resources with AWS accounts outside of your organization by providing the account ID. However, you must enable this feature in the RAM settings. Note that this is generally not recommended for enterprise environments due to the difficulty of managing compliance and security across external boundaries.

5. How do I know who has access to my resources?

You can use the RAM console to view the "Principals" tab for any Resource Share. This will list all the OUs and Account IDs that currently have access to that share.

Summary and Key Takeaways

AWS Resource Access Manager (RAM) is a fundamental tool for any architect working in a multi-account AWS environment. By moving away from resource duplication and toward a model of shared infrastructure, you can significantly reduce costs, simplify network management, and improve the consistency of your cloud footprint.

To succeed with RAM, keep these key points in mind:

• Design for Centralization: Always aim to house shared infrastructure like networking and licensing in dedicated "Hub" accounts. This simplifies governance and auditing.
• Use Organizational Units: Leverage AWS Organizations to manage access at scale. Sharing with OUs is far more sustainable than managing individual account IDs.
• Understand the Permissions Model: Recognize that RAM provides the "permission to access" the resource, but IAM policies provide the "permission to perform actions" on the resource. Both must be correctly configured.
• Security is a Shared Responsibility: While RAM provides isolation, you must still enforce security at the resource level (Security Groups) and the network level (NACLs) to prevent lateral movement.
• Infrastructure as Code is Essential: Use tools like Terraform or CloudFormation to manage your Resource Shares. This ensures that your sharing configuration is versioned, peer-reviewed, and easily reproducible.
• Audit Regularly: Use CloudTrail to monitor resource sharing events. Periodically review your Resource Shares to ensure that access is still necessary and that the scope of the share matches the current needs of your organization.
• Respect the Lifecycle: Understand that resources cannot be deleted until the Resource Share is removed. Build this into your decommissioning processes to avoid operational friction.

By mastering these concepts, you can build a robust, scalable, and secure cloud environment that grows with your organization. RAM is not just a convenience; it is a critical component of a mature, well-architected multi-account strategy. As you move forward, focus on automating your resource shares and maintaining a clean, well-documented architecture that empowers your application teams while maintaining the guardrails necessary for enterprise-grade security.