The Complete AWS Resource Access Manager (RAM) Guide (2025): Cross-Account Resource Sharing, Permissions, and Best Practices

Author: Srikanth Ch, Senior DevOps Engineer
Last Updated: November 2025

---

TL;DR

AWS Resource Access Manager (RAM) lets you securely share AWS resources across accounts without duplicating infrastructure or compromising security. Instead of recreating VPCs, Transit Gateways, or Route53 Resolver rules in every account, you create them once and share them with precise control. This guide walks you through RAM’s architecture, supported resources, integration with AWS Organizations, security best practices, and real-world DevOps use cases that make multi-account architectures both practical and scalable.

“In DevOps, multi-account setups are the backbone of security and scalability. RAM bridges the gap between autonomy and governance, allowing teams to collaborate across accounts without breaking isolation.”

---

Introduction to AWS Resource Access Manager (RAM)

Ever wanted to share your AWS resources securely without giving full account access? That’s exactly what AWS RAM is built for.

Here’s the scenario I ran into back when I was setting up a multi-account landing zone for a fintech client. We had a central networking account with carefully configured VPC subnets, a Transit Gateway connecting multiple regions, and Route53 Resolver rules for internal DNS resolution. The application teams in separate AWS accounts needed access to these network resources, but we didn’t want to recreate the same infrastructure in every single account. That would have been a maintenance nightmare.

AWS Resource Access Manager solved this perfectly. RAM is AWS’s native service for sharing resources across accounts within your organization or with external AWS accounts, all while maintaining security boundaries and proper access controls.

Think of RAM like a shared Wi-Fi network in an apartment building. The building owner (resource owner) sets up one high-quality network infrastructure and shares it with tenants (principals) who can use it based on their specific access permissions. Each tenant gets the benefit without needing to install their own equipment, and the owner maintains central control over who has access and what they can do with it.

Common real-world use cases for AWS RAM include:

• Sharing VPC subnets from a central networking account to workload accounts so applications can launch EC2 instances in shared network spaces
• Distributing Transit Gateway attachments across accounts to enable inter-account communication without complex VPC peering
• Sharing Route53 Resolver rules so all accounts can resolve internal DNS names consistently
• Distributing License Manager configurations to track software licenses centrally while applications run in distributed accounts
• Sharing Resource Groups Tag Editors for consistent tagging strategies across your organization

The beauty of RAM is that it integrates seamlessly with AWS Organizations, making resource sharing almost automatic when you’ve architected your account structure properly. For anyone preparing for the AWS Solutions Architect Associate (SAA-C03) or Security Specialty exams, understanding RAM is crucial because multi-account architectures are now the recommended best practice for virtually every enterprise AWS deployment.

Learn more about AWS RAM from the official documentation →

---

AWS RAM Architecture Overview

Understanding how AWS RAM works requires grasping its fundamental architecture and the relationships between its core components.

When you create a resource share in AWS RAM, you’re essentially establishing a controlled bridge between a resource you own and one or more AWS principals who need to use that resource. The resource never leaves your account physically, but other accounts gain the ability to reference and use it according to permissions you define.

Here are the key architectural components:

Resource Owners are AWS accounts that create and manage the shareable resources. The owner account always retains full control and ownership. If I create a VPC subnet in my networking account and share it via RAM, I remain the owner, I pay for the underlying infrastructure, and I can revoke access at any time.

Principals are the entities receiving shared access. Principals can be individual AWS accounts identified by their account ID, entire Organizational Units (OUs) within AWS Organizations, or your entire AWS Organization. The flexibility here is powerful because you can share with a single development account for testing, then expand to an entire OU when you’re ready to scale.

Resource Shares are the actual sharing configurations you create in RAM. Each resource share specifies which resources you’re sharing and which principals have access. Think of a resource share as a manifest that says “I’m sharing these three VPC subnets with these five accounts under these conditions.”

Shared Resource Types are the AWS services and resources that support RAM sharing. AWS has steadily expanded this list over the years, and as of 2025, dozens of resource types across networking, security, compute, and management services can be shared.

The architectural flow works like this: You create a resource in your account (like a Transit Gateway), then create a resource share in AWS RAM specifying that Transit Gateway and your target principals. If you’re sharing within AWS Organizations with organization-wide sharing enabled, the principals instantly get access. If you’re sharing with external accounts or have organization-wide sharing disabled, the principals receive an invitation they must accept before access is granted.

One critical architectural point that surprises many people at first is that shared resources appear differently in consumer accounts. When I share a VPC subnet with another account, that account doesn’t see it in their VPC console as if they created it. Instead, they see it in a special “shared with me” section, and they can use it when launching resources but cannot modify the subnet configuration itself. This architectural boundary maintains security and prevents one account from accidentally disrupting resources that other accounts depend on.

Integration with AWS Organizations fundamentally changes RAM’s behavior. When you enable organization-wide sharing, any resource shares you create automatically propagate to the specified OUs or the entire organization without requiring manual acceptance. This streamlines operations dramatically in large environments where you might be managing hundreds of accounts.

Deep dive into AWS Organizations integration →

---

Supported Resource Types

AWS RAM supports sharing for a growing list of AWS resources across multiple services. Understanding what you can share is essential for designing effective multi-account architectures.

Here’s a comprehensive breakdown of the major shareable resource types:

Resource Type	AWS Service	Description	Common Use Case
VPC Subnets	Amazon VPC	Share subnets for EC2 instance placement	Central networking account shares subnets with application accounts
Transit Gateway	Amazon VPC	Share TGW for inter-VPC/account routing	Hub-and-spoke network architecture connecting multiple accounts
Transit Gateway Multicast Domain	Amazon VPC	Share multicast domains for TGW	Multicast application traffic between accounts
Route53 Resolver Rules	Amazon Route53	Share DNS resolution rules	Centralized DNS forwarding to on-premises DNS servers
Route53 Resolver Endpoints	Amazon Route53	Share inbound/outbound endpoints	Unified DNS resolution architecture
License Manager Configurations	AWS License Manager	Share license tracking configurations	Centralized software license compliance
Aurora DB Clusters	Amazon Aurora	Share Aurora clusters	Cross-account database access for analytics
EC2 Capacity Reservations	Amazon EC2	Share reserved capacity	Share capacity across accounts during peak loads
EC2 Dedicated Hosts	Amazon EC2	Share dedicated host capacity	Compliance requirements for isolated hardware
Resource Groups	AWS Resource Groups	Share resource groupings	Standardized resource organization
App Mesh	AWS App Mesh	Share service mesh configurations	Microservices communication across accounts
Systems Manager Documents	AWS Systems Manager	Share automation documents	Standardized operational procedures
CodeBuild Projects	AWS CodeBuild	Share build project configurations	Shared CI/CD tooling
Glue Catalogs	AWS Glue	Share data catalog databases	Cross-account data lake access
Image Builder Components	EC2 Image Builder	Share AMI building components	Standardized image creation pipelines
Network Firewall Policies	AWS Network Firewall	Share firewall policies	Centralized network security policies
Outposts	AWS Outposts	Share local gateway resources	Hybrid cloud resource sharing

The resource type that DevOps teams use most frequently is VPC Subnets. Here’s a real-world example from my experience: we had a central networking account that owned all VPC infrastructure including public subnets with carefully configured NAT Gateways, private subnets with specific route tables, and database subnets with restricted access. Rather than recreating this complex network architecture in every application account, we shared the subnets via RAM. Application teams could then launch their EC2 instances, RDS databases, and ECS tasks directly into these shared subnets while the networking team retained control over the underlying network configuration.

Another frequently shared resource is Transit Gateway. In multi-region, multi-account architectures, the Transit Gateway acts as a central routing hub. By creating the Transit Gateway in a connectivity account and sharing it with workload accounts, you enable those accounts to attach their VPCs and participate in the routed network without needing to manage the Transit Gateway itself.

Route53 Resolver Rules are essential when you’re running hybrid architectures. You can create forwarding rules in a central account that resolve specific DNS domains to on-premises DNS servers, then share those rules with all accounts. This ensures consistent DNS resolution across your entire AWS footprint without duplicating configuration.

What’s important to understand about shared resources is that the sharing doesn’t transfer ownership. If I share a Transit Gateway with your account, I still own it, I still pay for it, and I can revoke your access. You gain the ability to use it, but you can’t modify its fundamental configuration. This architectural decision prevents accidental disruptions and maintains clear responsibility boundaries.

Reflection Prompt: Think about your current AWS architecture. Which resources are you duplicating across accounts that could be centralized and shared via RAM? What would the security implications be?

See the complete list of shareable resources →

---

How AWS RAM Works (Step-by-Step)

Let me walk you through exactly how resource sharing works in AWS RAM by using a practical example that mirrors what you’d do in a real DevOps environment.

Scenario: You’re the network administrator with a central networking account (account ID 111122223333). You’ve created a VPC with carefully configured subnets, and you need to share two private subnets with your development team’s AWS account (account ID 444455556666) so they can launch EC2 instances.

Step 1: Resource Owner Creates a Resource Share

First, you navigate to the AWS RAM console in your networking account. You click “Create a resource share” and you’re presented with a configuration form. You give your resource share a descriptive name like “dev-team-private-subnets” because clear naming is crucial for operational visibility.

You then specify the resource type as “Subnets” and select the two specific subnet IDs you want to share. RAM shows you all your available subnets, and you pick the ones in your development VPC that don’t contain sensitive infrastructure.

Step 2: Specify Target Principals

Next, you define who gets access. You have three options here: specify individual AWS account IDs, select an Organizational Unit if you’re using AWS Organizations, or share with your entire organization. For this scenario, you enter the development account ID 444455556666 as the principal.

You can also add multiple principals in a single resource share. If you had five different application teams needing access to the same subnets, you could add all five account IDs here rather than creating separate resource shares for each.

Step 3: Configure Permissions (if applicable)

For certain resource types like Aurora DB Clusters, you can specify additional permissions beyond basic access. For VPC subnets, the permissions are straightforward: the consumer account can launch resources into the subnet but cannot modify the subnet configuration itself.

Step 4: Review and Create

You review your configuration, ensuring the correct subnets are being shared with the correct accounts, then create the resource share. AWS RAM immediately processes your request.

Step 5: Principal Accepts the Share

This step depends on your AWS Organizations configuration. If you’ve enabled organization-wide sharing and you’re sharing within your organization, the development account automatically has access with no acceptance required. This is the streamlined path that makes RAM powerful in enterprise environments.

If you’re sharing with an external account or if organization-wide sharing is disabled, the development account receives an invitation. An administrator in that account must navigate to AWS RAM, view pending invitations, and explicitly accept the resource share before they gain access.

Step 6: Shared Resource Becomes Accessible

Once the share is accepted (or auto-accepted via Organizations), the development account can now use those subnets. When their team launches an EC2 instance, they’ll see those subnets appear in their subnet selection dropdown marked as “shared.” They can launch instances into those subnets, but if they try to modify the subnet configuration (like changing route tables or CIDR blocks), they’ll receive a permission denied error because they don’t own the resource.

Throughout this entire process, you as the resource owner maintain full visibility. You can see which accounts have accepted the share, you can revoke access at any time, and you can add or remove resources from the share as your architecture evolves.

From a DevOps perspective, this workflow enables you to codify resource sharing in your Infrastructure as Code. Using tools like Terraform or CloudFormation, you can define resource shares as code, making them version-controlled, peer-reviewed, and deployable through your CI/CD pipelines just like any other infrastructure component.

Reflection Prompt: Which AWS resources would you share between accounts in your environment? Think about resources you’re currently duplicating that could be centralized. Consider both the operational efficiency gains and the security implications of sharing.

Learn about RAM API operations for automation →

---

Integrating AWS RAM with AWS Organizations

The real power of AWS RAM emerges when you integrate it with AWS Organizations. This integration transforms RAM from a useful account-to-account sharing tool into a foundational element of your multi-account governance strategy.

When you create an AWS Organization, you establish a hierarchical structure of accounts organized into Organizational Units (OUs). You might have OUs for development, testing, production, security, and networking. Each OU can contain multiple accounts, and you can nest OUs within other OUs to create sophisticated structures that mirror your business organization.

Organization-wide sharing is a setting you enable at the organization level that fundamentally changes how RAM behaves. With organization-wide sharing enabled, resource shares you create that target OUs or your entire organization automatically propagate to all accounts within that scope without requiring individual acceptance. This eliminates the invitation workflow entirely for intra-organization sharing.

Here’s how I’ve architected this in production environments: In a central networking account that sits within a “Core” OU, we create all shared infrastructure like VPC subnets, Transit Gateways, and Route53 Resolver rules. We then create resource shares targeting specific OUs. For example, we share development network subnets with the “Development” OU, staging network subnets with the “Staging” OU, and production network subnets with the “Production” OU. As new accounts are added to these OUs (which happens frequently in growing organizations), they automatically inherit access to the appropriate shared resources without any manual intervention.

The security benefit here is significant. Instead of granting broad permissions that allow accounts to create their own network infrastructure (which could lead to compliance violations, security misconfigurations, or cost overruns), we restrict accounts to using only the shared resources. This enforces network architecture standards while still giving application teams the flexibility they need to deploy their workloads.

Comparing organization-wide sharing with manual sharing:

Organization-wide sharing automatically grants access to all accounts within specified OUs or the entire organization. There’s no invitation to accept, no delay, and no risk of sharing requests being missed or forgotten. This is ideal for tightly controlled environments where the organization’s security posture is strong and you trust that shared resources will be used appropriately.

Manual sharing requires explicit invitations that principals must accept. This adds a human-in-the-loop verification step and is more appropriate when sharing with external accounts outside your organization or when you need explicit acknowledgment that a team has accepted responsibility for using a shared resource.

In my experience, the best practice is to enable organization-wide sharing and use it extensively for intra-organization resource distribution, while using manual sharing only when crossing organizational boundaries or when compliance requirements demand explicit acceptance workflows.

One critical architectural consideration: When you enable organization-wide sharing, ensure you have robust AWS Organizations Service Control Policies (SCPs) in place. SCPs can prevent accounts from performing actions that could disrupt shared resources or use them in unintended ways. For example, you might use an SCP to prevent certain accounts from creating EC2 instances in shared subnets that are designated for specific purposes.

🚀 Pro Tip — Enable organization-wide sharing for seamless integration across landing zone accounts. If you’re using AWS Control Tower to manage your multi-account environment, organization-wide sharing integrates perfectly with Control Tower’s account provisioning workflows. New accounts vended through Control Tower automatically inherit the appropriate shared resources based on their OU placement.

Learn how to enable RAM organization sharing →

Understanding AWS Organizations architecture →

---

AWS RAM Permissions & Security

Security is always paramount when you’re sharing resources across AWS accounts, and AWS RAM provides multiple layers of security controls to ensure shared resources are accessed appropriately.

The first thing to understand is that RAM itself doesn’t grant permissions to perform actions on shared resources. RAM grants access to the resource, but the consumer account still needs appropriate IAM permissions to interact with that resource type. This separation is crucial for maintaining security boundaries.

Here’s a concrete example: I share a VPC subnet with your account via RAM. That makes the subnet accessible to your account, but your users still need IAM permissions like ec2:RunInstances and ec2:CreateNetworkInterface to actually launch instances into that subnet. If your IAM policies don’t include these permissions, RAM’s sharing won’t help you.

IAM roles and permission boundaries continue to work exactly as they normally would with shared resources. If I’ve configured an IAM role in your account that allows EC2 instance launches only in subnets tagged with Environment:Development, that restriction still applies to shared subnets. You’d need to launch instances in shared subnets that match that tag, or modify your IAM policy to accommodate the shared subnets.

Best practices for secure resource sharing include:

Share only required resources — Don’t share entire VPCs when you only need to share specific subnets. Don’t share Transit Gateways to accounts that don’t need inter-account routing. Practice resource-level sharing precision.

Use least privilege access principles — In the consumer accounts, grant IAM permissions only for the specific actions needed on shared resources. If an application only needs to launch instances in a shared subnet, don’t give it permissions to modify subnet configurations (which it couldn’t do anyway as a consumer, but the principle stands).

Implement resource-based policies where supported — Some shareable resources like Aurora DB Clusters support resource-based policies that can further restrict what consumer accounts can do. Use these policies to enforce fine-grained access controls.

Monitor with AWS CloudTrail — Every RAM action, including creating resource shares, accepting shares, and accessing shared resources, is logged in CloudTrail. Set up CloudTrail log analysis to detect unusual patterns like unexpected accounts accepting shares or shared resources being accessed from unusual locations.

Leverage AWS IAM Access Analyzer — Access Analyzer can identify resources shared via RAM and highlight potential security risks. It shows you which principals have access to your resources and helps you validate that your sharing configuration matches your security policy.

Let me share a real-world security scenario: We were sharing a Transit Gateway with multiple accounts to enable inter-account communication. However, we didn’t want all accounts to be able to route traffic to all other accounts indiscriminately. We implemented this by using Transit Gateway route tables (which are separate from VPC route tables). Each account’s VPC attachment was associated with a specific Transit Gateway route table that contained only the routes to other accounts that this particular account was authorized to communicate with. We also used AWS Network Firewall in the networking account to inspect traffic passing through the Transit Gateway and block unauthorized protocols or destinations.

Permission boundaries and RAM shares interact in an interesting way. If you’re using IAM permission boundaries in consumer accounts to restrict what roles and users can do, those boundaries apply to actions on shared resources. This gives you defense-in-depth: RAM controls access to the resource itself, IAM policies control what actions can be performed, and permission boundaries provide an additional guardrail.

Example scenario: Securing a shared Transit Gateway

You’ve shared a Transit Gateway from a networking account to application accounts. You want these application accounts to be able to attach their VPCs to the Transit Gateway, but you don’t want them to modify Transit Gateway route tables or change Transit Gateway configurations.

Here’s how you’d secure this:

In the networking account, the Transit Gateway resource itself has settings that control attachments. You can configure the Transit Gateway to require approval for new attachments, giving the networking team a chance to review each attachment request before it becomes active.

In the consumer accounts, you grant IAM permissions that allow ec2:CreateTransitGatewayVpcAttachment but specifically deny ec2:ModifyTransitGateway and ec2:DeleteTransitGateway. The deny policies ensure that even if someone gains elevated privileges in the consumer account, they cannot disrupt the shared Transit Gateway.

You enable VPC flow logs on all VPCs that attach to the Transit Gateway, sending those logs to a centralized logging account. This gives you visibility into all traffic patterns and helps you detect anomalous behavior.

You implement Transit Gateway route table policies that control which VPCs can route to which destinations, enforcing network segmentation at the routing layer rather than relying solely on security groups.

Quiz Question: Can AWS RAM share resources between different AWS regions? Think about the architectural implications before answering.

Answer: No, AWS RAM resource sharing is region-specific. A resource share created in us-east-1 can only share resources that exist in us-east-1. If you need to share similar resources across regions, you need to create separate resource shares in each region. Some resource types like Transit Gateways can be shared in one region to allow cross-region routing (with Transit Gateway peering), but the sharing itself is region-bound. This regional constraint is important for exam questions and architectural designs.

Understand IAM policies for shared resources →

AWS CloudTrail logging for RAM →

---

Image Suggestion 4:
File: aws-ram-security-layers.png
Description: A layered security diagram showing defense-in-depth for RAM. Visualize concentric circles or layers: outer layer “AWS Organizations SCPs” in royal blue (#2A65F5), middle layer “RAM Resource Shares” in cyan (#00D9F5), inner layer “IAM Policies” in white, core “Shared Resource” icon in the center. Add small lock icons at each layer. Use dark navy (#0C1A2B) background with subtle gradient.

---

Monitoring, Logging & Compliance

Visibility into resource sharing activities is essential for maintaining security, troubleshooting issues, and meeting compliance requirements. AWS provides several native services that integrate with RAM to give you comprehensive monitoring capabilities.

AWS CloudTrail is your primary audit log for RAM activities. Every action taken through RAM is recorded as a CloudTrail event, including creating resource shares, deleting resource shares, accepting invitations, and rejecting invitations. These events capture who performed the action, when it happened, from which IP address, and what the result was.

In production environments, I always configure CloudTrail to deliver logs to a dedicated security account with strict access controls. You don’t want application teams to have the ability to delete or modify audit logs related to resource sharing. CloudTrail logs should be treated as immutable security artifacts.

Here are the key RAM events you should monitor in CloudTrail:

• CreateResourceShare — Indicates someone created a new resource share, potentially exposing resources to other accounts
• AcceptResourceShareInvitation — Shows when an account accepted access to shared resources
• RejectResourceShareInvitation — Indicates an account declined shared access
• DeleteResourceShare — Someone removed a resource share, potentially disrupting dependent accounts
• DisassociateResourceShare — Resources were removed from an existing share
• AssociateResourceShare — New resources were added to an existing share

You can set up CloudWatch alarms based on CloudTrail events to receive notifications when sensitive RAM actions occur. For example, I configure alerts for any DeleteResourceShare events so the security team is immediately notified if someone removes a resource share that other accounts depend on.

AWS Config provides compliance monitoring for RAM configurations. Config continuously tracks the configuration state of your resource shares and can evaluate them against compliance rules you define. You might create a Config rule that ensures all resource shares are created with specific tags that indicate business purpose and cost center. If someone creates a resource share without proper tags, Config marks it as non-compliant and can trigger automated remediation.

Config also maintains a configuration history timeline. If you’re troubleshooting an issue where an account suddenly lost access to a shared resource, you can examine the Config timeline to see exactly when and how the resource share configuration changed.

AWS Trusted Advisor includes checks related to resource sharing that can identify potential security or cost optimization opportunities. Trusted Advisor might flag resource shares that are exposing resources to a large number of accounts when you intended more limited sharing, or identify shared resources that aren’t actually being used by consumer accounts (indicating you could revoke the share and simplify your architecture).

For comprehensive monitoring, I recommend implementing a centralized logging and monitoring architecture:

Set up CloudTrail in all accounts with logs delivered to a central security account’s S3 bucket. Enable CloudTrail log file integrity validation to detect any tampering. Configure S3 bucket policies that prevent anyone except the security team from accessing or modifying these logs.

Deploy AWS Config in all accounts with aggregated views in a central compliance account. This lets your security team see the compliance status of RAM configurations across your entire organization without having to log into individual accounts.

Use AWS Security Hub to aggregate security findings from multiple sources including Config, CloudTrail, and Access Analyzer. Security Hub provides a unified view of security posture related to resource sharing.

Real-world monitoring scenario: We had an incident where an application account lost access to shared VPC subnets, causing application deployments to fail. By examining CloudTrail logs in the networking account, we discovered that a well-intentioned administrator had deleted the resource share thinking it was no longer needed, not realizing other accounts were actively using those subnets. We restored the resource share, updated our operational runbooks to require validation before deleting shares, and implemented a CloudWatch alarm that pages the on-call engineer whenever resource shares are deleted.

Reflection Question: How would you audit which accounts currently have shared access to your VPCs? What combination of AWS services would give you the most complete visibility?

Approach: You’d use AWS RAM’s GetResourceShares and GetResourceShareAssociations API calls to list all resource shares and see which principals are associated with each share. You’d cross-reference this with AWS Config to verify the configuration state. You’d examine CloudTrail logs to understand the history of how these shares were created and by whom. For VPC-specific visibility, you’d use VPC flow logs to see which accounts are actually generating traffic in your shared subnets. This multi-service approach gives you both configuration state and runtime behavior insights.

AWS Config rules for compliance →

CloudTrail event reference for RAM →

---

Real-World DevOps Use Cases

Theory is valuable, but understanding how AWS RAM solves real production challenges is what makes you effective as a DevOps engineer. Let me walk you through several architecture patterns I’ve implemented in enterprise environments.

Multi-Account Network Hub Architecture Using VPC Sharing

This is the most common RAM use case in well-architected AWS environments. You create a central networking account that owns all VPC infrastructure including subnets, route tables, NAT Gateways, Internet Gateways, and network security components like Network Firewalls. Application accounts are deliberately limited in their networking capabilities—they cannot create VPCs, subnets, or NAT Gateways at all.

When an application team needs to deploy resources, they launch them into shared subnets from the networking account. Public-facing applications launch into shared public subnets that route outbound traffic through centrally managed NAT Gateways. Backend services launch into shared private subnets with restricted routing. Databases launch into shared database subnets with no internet access whatsoever.

This architecture delivers several benefits: The networking team maintains complete control over network topology, routing, and security. Application teams get the network resources they need without needing deep networking expertise. Costs are optimized because you’re not duplicating NAT Gateways across every account. Security is enhanced because there are fewer network paths to secure and monitor.

The practical implementation looks like this: In the networking account, you create VPCs with carefully designed CIDR blocks that avoid overlap with on-premises networks and allow for future expansion. You create subnets across multiple Availability Zones for high availability. You configure route tables with appropriate routes to Transit Gateways, NAT Gateways, and VPC endpoints. Then you create RAM resource shares targeting specific OUs in your organization, sharing the appropriate subnets with each OU based on their environment type.

Centralized Transit Gateway for Inter-Account Communication

Transit Gateway is often called the “network router in the cloud,” and it’s one of the most powerful use cases for RAM. In traditional architectures, connecting multiple VPCs required complex VPC peering relationships that became difficult to manage at scale. Transit Gateway solves this by acting as a central hub that VPCs attach to.

Here’s how I’ve architected this: We create a Transit Gateway in a connectivity account (sometimes the same as the networking account, sometimes separate for organizational reasons). We share this Transit Gateway with all application accounts via RAM. Each application account can then attach its VPCs to the shared Transit Gateway.

The key to making this work securely is Transit Gateway route tables. We create multiple route tables within the Transit Gateway, each representing a security zone. Development account attachments associate with a development route table that only contains routes to other development accounts and shared services. Production account attachments associate with a production route table that contains routes to production accounts and shared services, but not to development accounts. This implements network segmentation at the routing layer.

We place AWS Network Firewall between the Transit Gateway and the internet egress path, inspecting all traffic leaving the organization for malicious content and enforcing egress control policies. This centralized inspection point is more cost-effective and manageable than deploying firewalls in every account.

Shared License Manager Configurations Across Accounts

Software licensing compliance is a real challenge in multi-account environments where different teams are spinning up EC2 instances with commercial software. AWS License Manager helps track license usage, and RAM lets you share license configurations across accounts.

We create license configurations in a central license management account defining the license rules for each software package (number of licenses, license types, usage restrictions). We share these configurations with application accounts via RAM. When teams launch instances with licensed software in their accounts, those launches are tracked against the shared license configuration, giving us centralized visibility into license consumption and ensuring we don’t exceed our license entitlements.

Integrating with Control Tower and Organizations

AWS Control Tower is AWS’s best-practice multi-account governance service, and it integrates beautifully with RAM. When you set up a Control Tower landing zone, you establish a multi-account structure with core accounts for logging, security, and shared services.

I configure RAM resource shares as part of the landing zone setup so that newly vended accounts automatically get access to shared resources based on their OU placement. When Control Tower provisions a new application account in the Production OU, that account automatically gains access to production network subnets, shared Transit Gateway attachments, and relevant DNS resolver rules without any manual intervention.

This integration means your multi-account environment is self-service for application teams. They can request new accounts through Control Tower’s Account Factory, and those accounts come pre-configured with access to all necessary shared infrastructure. This accelerates development velocity while maintaining governance and security standards.

AWS Reference Architecture for Multi-Account Networking →

AWS Control Tower and Landing Zone design →

---

AWS RAM Best Practices

Having worked with AWS RAM across numerous enterprise deployments, I’ve identified patterns that consistently lead to success and pitfalls that consistently cause problems. Here are the battle-tested best practices that will serve you well.

Follow the principle of least privilege religiously — Share only the specific resources that are needed, and share them only with the specific accounts or OUs that need access. Resist the temptation to share resources organization-wide “just in case.” Over-sharing creates unnecessary security exposure and makes it harder to understand your actual resource dependencies.

When creating resource shares, use descriptive names that indicate what’s being shared and with whom. Instead of “resource-share-1,” use names like “prod-vpc-subnets-to-prod-apps-ou” that make the purpose immediately clear to anyone reviewing the configuration.

Use AWS Organizations for simpler, safer sharing — Enable organization-wide sharing and leverage OU-based targeting. This eliminates invitation workflows and ensures that new accounts added to OUs automatically inherit the appropriate shared resources. It also means you can manage sharing at the OU level rather than having to update resource shares every time a new account is created.

Organize your OUs thoughtfully with sharing in mind. Having separate OUs for development, staging, and production environments makes it natural to share environment-appropriate resources with each OU. This organizational structure enforces separation of concerns and reduces the risk of accidentally sharing production resources with development accounts.

Regularly review resource shares and principal lists — Resource sharing configurations tend to accumulate over time. Teams request access for specific projects, but when those projects end, the shared access often remains. Schedule quarterly reviews where you audit all active resource shares, verify that principals still need access, and revoke shares that are no longer necessary.

Use AWS Config rules to enforce this. Create a rule that flags resource shares older than 90 days for review, or flags shares with more than a certain number of principals. Automated governance helps you maintain hygiene as your environment scales.

Avoid unnecessary cross-region or cross-account exposure — Remember that RAM sharing is region-specific. If you create resource shares in multiple regions, you’re managing multiple configuration surfaces. Where possible, consolidate resources in specific regions and architect your applications to work with region-specific sharing boundaries.

When sharing across regions is unavoidable (like with multi-region Transit Gateway peering architectures), document the cross-region dependencies clearly. Future maintainers of your infrastructure need to understand these complex relationships.

Document and tag shared resources meticulously — Every shared resource should have tags indicating its ownership, purpose, sharing status, and which accounts it’s shared with. Use tags like ResourceOwner:NetworkingTeam, SharedVia:RAM, SharedWith:ProductionOU, and Purpose:ApplicationSubnets.

Maintain documentation that maps your resource shares to business purposes. When an incident occurs and you need to understand impact, you want to quickly answer questions like “which applications will be affected if we need to revoke access to this shared subnet?”

Implement automated monitoring and alerting — Don’t rely on manual checks to maintain visibility into resource sharing. Set up CloudWatch alarms for critical RAM events, configure AWS Config to evaluate compliance continuously, and integrate RAM findings into your security information event management (SIEM) system.

Create operational runbooks that team members can follow when RAM-related alerts trigger. What should someone do if they’re paged at 2 AM because a critical resource share was deleted? Having documented procedures reduces incident response time.

Test your resource sharing architecture — Before promoting RAM configurations to production, test them in non-production environments. Verify that consumer accounts can access shared resources as expected, that IAM permissions work correctly, and that monitoring and logging capture the events you need.

Include RAM sharing in your disaster recovery tests. If you need to rebuild your networking account from backup or deploy to a new region, can you recreate your resource shares quickly? Having Infrastructure as Code for RAM configurations makes this testable and repeatable.

🧠 Security Tip — Treat resource shares as part of your security boundary. A misconfigured resource share can expose critical infrastructure to unauthorized accounts just as surely as a misconfigured security group can expose an EC2 instance to the internet. Apply the same rigor to reviewing and approving RAM configurations as you do to other security controls.

Consider the operational model — Decide which team owns resource shares in your organization. In most cases, the team that owns the shared resource should also own the resource share configuration. The networking team should manage VPC subnet shares, the connectivity team should manage Transit Gateway shares, and so on. This aligns ownership with expertise.

Use AWS Service Control Policies (SCPs) to enforce guardrails. You might create an SCP that prevents anyone except the networking team from creating or deleting resource shares for VPC resources. This prevents accidental or malicious sharing of critical infrastructure.

AWS Well-Architected Framework on resource sharing →

---

Common Mistakes to Avoid

Learning from mistakes is valuable, but learning from other people’s mistakes is even better. Here are the most common RAM pitfalls I’ve seen DevOps teams encounter, and how to avoid them.

Sharing critical resources with overly broad principals — The number one mistake is sharing VPCs, Transit Gateways, or other foundational infrastructure with your entire organization when you meant to share only with specific OUs or accounts. Always double-check the principals before creating a resource share. A single typo or misclick can expose production network infrastructure to development accounts, creating security compliance violations.

Use the principle of progressive sharing: start by sharing with a small test account, verify it works as expected, then expand to the target OU. Don’t go straight to organization-wide sharing until you’re absolutely certain the configuration is correct.

Forgetting to revoke shares after project completion — Projects end, team structures change, and accounts are repurposed, but resource shares tend to linger. An application team might have needed access to specific shared subnets for a six-month project, but that access remains years later even though the project is long since decommissioned.

Implement lifecycle management for resource shares. When creating a share, document the business justification and expected lifetime. Set calendar reminders to review long-lived shares. Use AWS Organizations tags to track which shares are associated with specific projects or initiatives.

Not enabling CloudTrail for audit logging — Some teams treat RAM as a simple configuration tool and don’t realize that comprehensive auditing is essential. Without CloudTrail enabled, you have no record of who created resource shares, when they were created, or which accounts accepted them. This makes security investigations and compliance audits extremely difficult.

Enable CloudTrail in all accounts, ensure logs are delivered to a secure central location, and configure log file integrity validation. Treat CloudTrail logs as critical security artifacts with strict access controls and retention policies.

Overlooking service limits and regional constraints — AWS imposes service quotas on RAM, including limits on the number of resource shares per account and the number of principals per resource share. If you’re building a large-scale multi-account environment, verify these limits early and request quota increases if needed.

Remember that RAM sharing is region-specific. You cannot create a single resource share in us-east-1 that shares resources from both us-east-1 and eu-west-1. Understanding this constraint is crucial for designing multi-region architectures.

Misunderstanding that RAM doesn’t transfer ownership — Some teams expect that when they share a VPC subnet, the consumer account becomes a co-owner who can modify the subnet configuration. That’s not how it works. The owner retains full control and ownership. The consumer gains only the ability to use the resource according to the permissions granted.

This matters for cost attribution and operational responsibility. If I share a Transit Gateway with your account, I still pay for the Transit Gateway itself. You pay for the data transfer charges associated with your VPC attachments, but the underlying infrastructure cost remains with me. Make sure your financial models reflect this cost allocation correctly.

Not testing IAM permissions in consumer accounts — RAM grants access to the resource, but the consumer account still needs appropriate IAM permissions to use it. Teams sometimes assume that accepting a resource share is sufficient, then they’re confused when their applications still can’t launch instances into shared subnets.

Test the complete flow: share the resource via RAM, accept it in the consumer account, and verify that IAM roles in the consumer account have the necessary permissions to interact with the shared resource. Document these IAM requirements so application teams know what permissions they need.

Ignoring dependencies when modifying or deleting resource shares — Before removing resources from a share or deleting a share entirely, understand which accounts are actively using those resources. If you delete a resource share for VPC subnets that have running EC2 instances, those instances continue running but the accounts lose the ability to manage them properly.

Implement a change control process for RAM configurations. Require teams to verify that no active workloads depend on a resource share before deletion is permitted. Use VPC flow logs and CloudTrail to identify which accounts are actively using shared resources.

Overlooking the implications of shared resource limitations — When you share a VPC subnet, the consumer accounts share the available IP address space. If you’ve shared a /24 subnet that provides 251 usable IP addresses, and ten accounts are all launching instances into that subnet, you can quickly exhaust the available IPs.

Plan your CIDR allocations with sharing in mind. Understand how many accounts will use each shared subnet and how many resources each account will launch. Monitor IP address utilization across shared subnets to catch exhaustion before it impacts applications.

Not integrating RAM with other governance tools — RAM shouldn’t exist in isolation. It should be integrated with AWS Organizations SCPs, AWS Config rules, AWS Security Hub, and your Infrastructure as Code pipelines. Teams sometimes manage RAM configurations manually through the console, leading to configuration drift and undocumented changes.

Codify your resource shares in Terraform, CloudFormation, or your preferred IaC tool. Store the code in version control, require peer review for changes, and deploy through CI/CD pipelines just like any other infrastructure component.

---

Pricing & Cost Considerations

One of the most attractive aspects of AWS RAM is its pricing model: AWS RAM itself is completely free. You’re not charged for creating resource shares, accepting shares, or the act of sharing resources across accounts.

However, there’s an important nuance here that you need to understand for proper cost management: while RAM is free, the underlying shared resources may incur their normal service-specific costs, and those costs are attributed based on which account is responsible for what part of the architecture.

Let me break down the cost implications for common shared resource types:

VPC Subnets — When you share VPC subnets, the owner account pays for the underlying network infrastructure like NAT Gateways, Internet Gateways, and VPC endpoints that might be associated with those subnets. Consumer accounts pay for the resources they launch into the shared subnets (EC2 instances, ENIs, EBS volumes) and for data transfer charges associated with their usage.

For example, if the networking account shares a subnet with a NAT Gateway, the networking account continues to pay the hourly NAT Gateway charge and the NAT Gateway data processing charge. If an application account launches EC2 instances in that shared subnet and those instances generate traffic through the NAT Gateway, the data processing charge for that specific traffic is billed to the application account based on the resources they own.

Transit Gateway — The account that owns the Transit Gateway pays the hourly attachment fees for Transit Gateway itself. Consumer accounts that attach their VPCs to the shared Transit Gateway pay for their specific VPC attachments (hourly attachment charge per VPC) and for data transfer charges based on traffic flowing through their attachments.

This cost model is actually quite fair because it attributes infrastructure costs to the owner who manages the shared resource and usage costs to the consumers who benefit from the resource. However, it requires careful cost allocation planning.

Route53 Resolver Endpoints — The owner account pays for the inbound and outbound resolver endpoints (hourly charges per endpoint and per Availability Zone). There are also query charges based on DNS queries processed. These query charges are typically associated with the account generating the queries, which means consumer accounts using shared resolver rules pay for their DNS query volume.

License Manager Configurations — License tracking itself doesn’t incur charges, but the underlying licenses being tracked obviously have their own costs. When you share license configurations, you’re centralizing visibility into license usage across accounts, which helps you optimize license purchases and avoid over-buying.

Real-world cost optimization scenario: We had a situation where application teams in separate accounts were each running their own NAT Gateways for internet egress. Each NAT Gateway cost about $32/month in hourly charges plus data processing fees, and we had 15 accounts, resulting in about $480/month just in NAT Gateway costs before data processing.

By consolidating to a shared VPC subnet architecture where the networking account owned NAT Gateways in shared public subnets, we reduced this to three NAT Gateways (one per AZ in a single VPC) for about $96/month. The data processing charges were still incurred based on actual usage, but the hourly infrastructure charges dropped by 80%. Over a year, this saved nearly $5,000 in NAT Gateway costs alone.

Reflection Question: Who pays the data transfer cost when a Transit Gateway is shared across accounts and one account’s VPC sends traffic to another account’s VPC?

Answer: Both accounts share the cost based on their traffic direction. The sending account pays the Transit Gateway data processing charge for traffic leaving their VPC attachment. The receiving account doesn’t pay an additional data processing charge for traffic arriving (you only pay once for Transit Gateway processing). However, if either VPC has inter-AZ traffic costs or cross-region traffic costs related to where the VPCs are located, those costs are billed to the respective account that owns the VPC. This cost model encourages efficient network design and makes accounts responsible for the traffic they generate.

Cost allocation tagging is crucial for tracking costs associated with shared resources. Make sure shared resources are tagged with cost center information, and ensure consumer accounts tag the resources they launch into shared subnets. This enables accurate chargeback or showback models in your financial reporting.

AWS RAM does not incur charges →

Understanding data transfer costs with shared resources →

---

Image Suggestion 6:
File: aws-ram-cost-attribution.png
Description: An infographic showing cost splits for shared resources. Divide into two columns: “Owner Account Pays” (left, royal blue #2A65F5) and “Consumer Account Pays” (right, cyan #00D9F5). List items under each with dollar sign icons. Owner side: NAT Gateway hourly fees, Transit Gateway hourly fees, Infrastructure costs. Consumer side: EC2 instance costs, Data transfer charges, Per-use fees. Use dark navy (#0C1A2B) background with clean icons.

---

Conclusion & Next Steps

AWS Resource Access Manager transforms the way you architect multi-account AWS environments. Instead of treating each account as an isolated island that must replicate all necessary infrastructure, RAM enables you to create centralized, shared resources that multiple accounts can use while maintaining security boundaries and clear ownership.

The architectural philosophy behind RAM reflects AWS’s maturity in multi-account thinking: organizations have moved beyond single-account deployments and now embrace dozens or hundreds of accounts organized by workload, environment, team, or business unit. Without RAM, this multi-account strategy would be operationally overwhelming because you’d need to duplicate foundational infrastructure in every account. With RAM, you centralize where it makes sense and distribute access where it’s needed.

Security teams appreciate RAM because it reduces the attack surface by consolidating critical infrastructure in fewer, more carefully controlled accounts. Instead of having NAT Gateways, Transit Gateways, and complex network configurations scattered across every application account (each representing a potential misconfiguration), these resources exist in dedicated networking or connectivity accounts managed by specialists.

Application teams appreciate RAM because it gives them the resources they need without requiring deep expertise in networking, DNS, or other infrastructure domains. They can focus on their application code while consuming shared infrastructure that just works.

Finance teams appreciate RAM because it optimizes costs by eliminating resource duplication and makes cost attribution clearer through AWS’s careful design of which account pays for what.

As you continue your AWS journey, think about resource sharing as a foundational design pattern rather than an optional feature. When you’re architecting a new multi-account environment or refactoring an existing one, ask yourself: which resources should be centralized and shared? Which resources should remain local to individual accounts? The answers will vary based on your organization’s size, security requirements, compliance needs, and operational maturity, but the questions are universal.

For AWS certification preparation, especially the Solutions Architect Associate (SAA-C03) and Security Specialty exams, make sure you understand RAM’s integration with AWS Organizations, how sharing works across accounts, what resource types can be shared, and how IAM permissions interact with shared resources. Exam questions often present multi-account scenarios where RAM is the elegant solution that avoids complex workarounds.

Your next learning steps should include hands-on practice. Set up a multi-account environment using AWS Organizations, create resource shares for VPC subnets and Transit Gateways, and verify that consumer accounts can use the shared resources. Break things intentionally: try to modify a shared resource from a consumer account and observe the permission denial. Delete a resource share and understand what happens to running workloads. This experimentation builds the intuition that makes you effective in production environments.

AWS RAM turns resource sharing from a manual headache into a secure, scalable part of your AWS architecture. Master it, and you’ll be equipped to design elegant multi-account solutions that balance security, operational efficiency, and cost optimization.

---

👉 Continue Your AWS Multi-Account Journey

Ready to dive deeper into AWS multi-account architectures? Check out these related guides on thedevopstooling.com:

• AWS Organizations: Complete Multi-Account Management Guide — Learn how to structure your AWS accounts using Organizational Units, Service Control Policies, and centralized governance
• AWS Control Tower: Landing Zone Setup and Best Practices — Discover how Control Tower automates multi-account setup and integrates with RAM for seamless resource sharing
• AWS Transit Gateway: Inter-Account Networking Architecture — Master Transit Gateway design patterns and understand how RAM sharing enables hub-and-spoke network topologies
• AWS Identity Center (SSO): Centralized Access Management — Configure single sign-on across your multi-account environment with integrated access controls

Want to accelerate your AWS certification prep? Explore our comprehensive courses:

• AWS Solutions Architect Associate (SAA-C03) Mastery
• AWS Security Specialty Deep Dive
• AWS Networking Fundamentals for DevOps

---

Frequently Asked Questions (FAQs)

---

About theDevOpsTooling.com

This guide is brought to you by Srikanth Ch, a Senior DevOps Engineer and AWS Solutions Architect specializing in cloud architecture, multi-account governance, and infrastructure automation. Through thedevopstooling.com, Srikanth shares practical DevOps knowledge gained from hands-on experience architecting production AWS environments for enterprises worldwide.

Connect & Learn:

• Explore more AWS guides and tutorials at thedevopstooling.com
• Follow for regular DevOps insights and cloud architecture patterns
• Join our community of DevOps engineers mastering AWS, Kubernetes, and cloud-native technologies

Last updated: November 2025 | Aligned with AWS SAA-C03 and Security Specialty exam objectives