Build Resource Access Manager share configurations for cross-account resource sharing.
Build Resource Access Manager share configurations for cross-account resource sharing.
Required Fields
NameResourceArnsPrincipalsOutput will appear here...The builder validates that Name, ResourceArns, and Principals all resolve before accepting the JSON as a valid CreateResourceShare request, the fields RAM needs to know what's being shared, with whom, and under what name; it doesn't validate that the specific ResourceArns are actually shareable resource types or that the Principals reference valid accounts/OUs, that's checked only against the live API.
Build an AWS Resource Access Manager share that grants cross-account access to a resource (subnets, Transit Gateways, License Manager configurations, and other shareable types) without duplicating the resource itself. AllowExternalPrincipals: false restricts sharing to principals within your AWS Organization, the safer default for internal cross-account sharing, while setting it true opens sharing to arbitrary AWS account IDs outside your org, which needs a deliberate, reviewed decision rather than a default flip, since it's the boundary between an internal platform-team share and exposing a resource to an account you don't control.
Sharing to an Organizations OU ARN rather than individual account IDs means new accounts added to that OU automatically gain access, which is convenient for a growing platform team but means an OU-scoped share needs the same governance rigor as adding a new IAM policy attachment, not a one-time decision.
AllowExternalPrincipals: true should be treated as a flag requiring explicit security sign-off in any change-review process, not a routine sharing option, since it's the one setting in this resource that crosses your AWS Organization's trust boundary.
A share with an overly broad PermissionArns (using a custom permission rather than a scoped AWS managed permission) can grant more access than the sharing team intended, prefer the narrowest AWS managed permission that satisfies the actual use case.
No, only the access level defined by the attached PermissionArns, which for most resource types is deliberately scoped (for a shared subnet, typically the ability to launch resources into it, not to modify or delete the subnet itself). The owning account retains full control and can revoke the share at any time; the recipient's capability is bounded by the specific RAM managed permission attached.
It permits sharing with AWS accounts outside your Organization entirely, accounts you have no organizational control over. For a resource like a Transit Gateway or a subnet, that means a third party you don't administratively control gains network-level access into your shared infrastructure, a decision that should go through the same security review as any other external network trust boundary, not be a default toggle.
No, PermissionArns and what they actually grant differ by resource type, a permission scoped for subnet sharing isn't interchangeable with one for License Manager configurations or Transit Gateway attachments. Check the specific managed permission's documented grant for the resource type you're sharing, don't assume a permission ARN's name alone tells you everything it allows.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.