AWS Resource Access Manager Security Guide: Controlling, Restricting and Auditing Resource Shares

AWS Resource Access Manager (RAM) lets one account hand subnets, transit gateways, private certificate authorities, backup vaults and dozens of other resources to other accounts, and each share quietly writes a resource-based policy that grants access. In a multi-account estate those shares become part of the access model: an organisation-wide share reaches every current and future member account, and a share with an external account ID crosses the organisation boundary. This guide covers the customer-side controls for RAM: how sharing within AWS Organizations works, the external sharing setting, managed permissions, service control policies that constrain sharing, and how to inventory and detect shares. It is written for cloud platform, network and security teams. Role-based access between accounts (trust policies, AssumeRole and external IDs) is covered in the Cross-Account and Cross-Tenant Access Guide; this page covers resource sharing only.

This is an independent guide from NHI Mgmt Group, based on AWS's public documentation as of November 2026. It is not sponsored or reviewed by AWS. Product features change, so confirm settings against AWS's current documentation.

Key takeaways

• Restrict sharing to the organisation unless there is a reason not to. The "Allow sharing with anyone" option is selected by default; choose "Allow sharing only within your organization" (allowExternalPrincipals set to false) for each share that stays internal.
• Enforce the boundary with an SCP. AWS documents a deny on ram:CreateResourceShare and ram:UpdateResourceShare when ram:RequestedAllowsExternalPrincipals is true, plus a deny on ram:AcceptResourceShareInvitation for accounts that should never consume external shares.
• Organisation and OU shares are dynamic. Accounts added to the organisation or OU gain access automatically, and if the scope includes the sharing account, every principal in it gets access because the generated policy uses a wildcard principal.
• Least privilege lives in managed permissions. Each resource type has a default AWS managed permission; use a narrower version or a customer managed permission where the type supports it, and review new default versions, which are not applied to existing shares automatically.
• Inventory both directions. List what each account shares out and what it receives, and alert on CreateResourceShare and AssociateResourceShare events from CloudTrail, because external access analysis does not cover every RAM-shared type.

How RAM sharing works

A resource share has three parts: the resources, the principals and a managed permission. When the share is created, RAM combines the managed permission's policy template with the resource ARNs and principal ARNs and attaches the resulting resource-based policy to each shared resource. Consumers still need identity-based policies that allow the actions on those ARNs, and those cannot exceed what the managed permission grants.

Principal types

Invitations and the organisation boundary

Once sharing with AWS Organizations is enabled, principals inside the organisation get access with no invitation. Principals in external accounts receive an invitation and get access only after accepting it. AWS documents an acceptance window of 12 hours for most resource types and 7 days for some, after which the invitation expires. Because in-organisation shares generate no invitation, an invitation in a production account usually means someone outside the organisation is offering a resource, which is worth a review.

By default, a share within the organisation ends when an account leaves. The RetainSharingOnAccountLeaveOrganization setting, available only at share creation and only when external principals are allowed, keeps access after departure. Treat it as an exception requiring approval.

Enabling sharing within AWS Organizations

Sharing with the organisation and its OUs must be enabled from the management account, with all features turned on in AWS Organizations. The caller needs ram:EnableSharingWithAwsOrganization, iam:CreateServiceLinkedRole, organizations:enableAWSServiceAccess and organizations:DescribeOrganization. Enable it from the RAM console Settings page or the RAM CLI command; enabling trusted access from the Organizations side alone does not create the service-linked role RAM needs. The service-linked role is AWSServiceRoleForResourceAccessManager, assumable only by RAM, with the AWSResourceAccessManagerServiceRolePolicy managed policy for reading organisation information. The setting applies in all Regions where RAM is available.

Enabling organisation sharing is a security improvement in itself: it lets teams share with an OU instead of listing account IDs, and it lets you turn external sharing off entirely. See the AWS Organizations and SCPs Guide for structuring OUs so that share scopes map cleanly to environments.

Choosing share scope and resource types

Some resource types can be shared only within the organisation; others with any account. The table lists common types as documented by AWS.

Decision guidance

• Organisation-wide share: suitable for genuinely global, low-risk resources such as a prefix list of corporate egress ranges. Remember that every new account inherits it.
• OU share: the default for platform resources such as network subnets per environment. Production subnets shared to the production OU, not to the organisation.
• Account share: for one consumer, or for external partners where the type allows it. Pair external shares with an owner, a business reason and an expiry review.
• IAM role principal: where supported, the narrowest scope, for example a private CA shared only to the role that issues certificates in a workload account.
• Small organisations: a single networking account sharing subnets per OU, external sharing denied by SCP, is usually enough. Large estates add a resource-type allow list per sharing account (see the SCP section).

Shared backup vaults deserve particular care because they are part of recovery; see the AWS Backup Security Guide.

Managed permissions and least privilege

Each shareable resource type has one default AWS managed permission named AWSRAMDefaultPermission followed by the type, for example AWSRAMDefaultPermissionSubnet for ec2:Subnet. Some types offer additional AWS managed permissions, such as read-only variants. Customer managed permissions let you write the policy template yourself, with conditions, for types that support them, for example letting developers allocate from an IPAM pool without viewing other accounts' allocations.

• Choose the narrowest permission: start from the managed permissions library in the RAM console, which lists each permission and the shares using it.
• Track versions: a managed permission can have several versions; new shares always use the default. When AWS publishes a new default version, existing shares are not updated automatically. The console shows when one is available and lets you review the differences. AWS recommends updating promptly, so schedule a periodic review.
• Keep consumer policies tight too: the managed permission is a ceiling. Consumer identity policies should still allow only the specific resource ARNs a workload needs. See the AWS IAM Policies and Roles Guide.

Service control policies for RAM

SCPs are the preventive layer: they constrain what principals in member accounts can do with RAM regardless of their IAM permissions. AWS publishes six example patterns, all Deny statements.

Two details from AWS's examples matter in practice. Use the IfExists form of an operator for resource type conditions so requests without the key are still evaluated. With a Deny and a negated operator such as StringNotEquals, the statement denies when the key is absent, which is why AWS pairs it with a Null condition. For when to use SCPs rather than permissions boundaries, see Permission Boundaries vs SCPs.

Implementation: a phased rollout

1. Inventory current shares. In every account and Region, list resource shares owned by the account and shares received, using the RAM console or the GetResourceShares and ListPrincipals API operations with the owner set to self and to other accounts. Record share name, resource types, principals, allowExternalPrincipals and the managed permission version.
2. Classify each share. Mark it internal-organisation, internal-OU, account-level or external. Assign an owner and a business reason; anything without one goes on a review list.
3. Enable organisation sharing from the management account if it is not already on, then re-scope account-by-account internal shares to OUs where that reduces maintenance.
4. Turn off external sharing on internal shares by setting "Allow sharing only within your organization" for each.
5. Pilot the SCPs. Attach the external-share deny and the invitation deny to a test OU first. Confirm legitimate operations still work and that a test external share fails. Then attach to production OUs, leaving an exception OU for approved external sharing accounts.
6. Add resource-type controls so only the networking account can share subnets and transit gateways, and only the PKI account can share private CAs.
7. Turn on detection (next section) and review managed permission versions quarterly.

Rollback: SCPs take effect on attachment and are removed by detaching them, so keep the previous policy version and change ticket ready. Disassociating a principal from a share removes its access, so confirm consumer dependencies (route tables, attached subnets, certificate issuance) before removing a share in production.

Detection and measurement

RAM records every API call in AWS CloudTrail with the event source ram.amazonaws.com. Send the organisation trail to a central log account and alert on these events.

Do not rely solely on IAM Access Analyzer for RAM. Its external access analysis covers resource-based policies for a defined list of resource types, and AWS states that findings do not include RAM shares of Amazon RDS DB clusters. A RAM inventory remains the authoritative view. See the IAM Access Analyzer Guide for what it does cover.

Metrics that show the controls are working:

• External shares: count of shares with allowExternalPrincipals true, each with an approved owner and reason; target is zero outside the exception OU.
• Organisation-wide shares: count and resource types; each reviewed at least annually.
• Stale shares: shares whose resources or principals no longer exist, or with no owner tag.
• Outdated permission versions: shares not on the current default managed permission version.
• SCP coverage: percentage of member accounts covered by the external-share deny.

Where identity fits

Every RAM share is an access grant to non-human principals: the roles in consumer accounts that attach to a shared subnet, issue from a shared CA or write to a shared vault. Treat shares as entitlements, with owners, reviews and removal on decommission. When a workload account is closed or moved between OUs, its access to shared resources changes automatically, so include RAM in joiner, mover and leaver procedures for accounts. See AWS IAM Roles vs IAM Users for choosing role principals.

Framework mapping

Common failure patterns

• Default external sharing left on: internal shares created with "Allow sharing with anyone" selected, so a mistyped account ID can reach outside the organisation.
• Organisation-wide shares for environment-specific resources: production subnets or a production CA shared to the whole organisation, reaching sandbox accounts.
• Sharing account inside the OU scope: every principal in the sharing account gains access through the wildcard principal, which nobody intended.
• Permission versions never reviewed: shares stay on old managed permission versions because existing shares are not updated automatically.
• Retained shares after divestment: RetainSharingOnAccountLeaveOrganization used without approval, so a divested business keeps access.
• Inventory from Access Analyzer only: RAM-shared resource types outside its scope never appear in findings.

Practitioner checklist

• Enable sharing with AWS Organizations from the management account using the RAM console or CLI.
• Inventory shares owned and received in every account and Region; assign an owner to each.
• Set "Allow sharing only within your organization" on every internal share.
• Attach SCPs denying external shares and external invitation acceptance, with an exception OU.
• Restrict sensitive resource types to named sharing accounts by SCP.
• Prefer OU and IAM role principals over organisation-wide shares.
• Use the narrowest managed permission and review new default versions quarterly.
• Deny RetainSharingOnAccountLeaveOrganization except by approval.
• Alert on CreateResourceShare, AssociateResourceShare, UpdateResourceShare and AcceptResourceShareInvitation.
• Include RAM shares in account move, closure and divestment procedures.

Standards and references

• AWS: Sharing your AWS resources (AWS RAM User Guide)
• AWS: Example service control policies for AWS RAM
• AWS: Managing permissions in AWS RAM
• AWS: Shareable AWS resources
• AWS: Logging AWS RAM API calls with AWS CloudTrail
• AWS: Resource types for IAM Access Analyzer
• NIST: SP 800-53 Rev 5, Security and Privacy Controls for Information Systems and Organizations

Related NHI Mgmt Group resources: Cross-Account and Cross-Tenant Access Guide · AWS Backup Security Guide · AWS Organizations and SCPs Guide · IAM Access Analyzer Guide