Lesson 259 · AWS Learning Path

AWS 259: AWS Resource Access Manager

Anil Jalela · Published Mar 11, 2026 · 17 min read

Why this matters to an architect

Multi-account architecture creates strong boundaries, but teams still need selected shared infrastructure: centrally owned subnets, Transit Gateways, Route 53 Resolver rules, IPAM pools, license configurations, capacity, build components, or other supported resources. AWS Resource Access Manager (AWS RAM) lets an owner expose a supported resource to approved principals without copying it or transferring ownership.

The dangerous misunderstanding is “RAM gives another account access.” Effective access actually depends on the resource share, its managed permission, the consumer's identity policy, Organizations controls, resource/service restrictions, Region, invitation state, and the owning service's behavior. An architect must know who owns, configures, pays for, monitors, and can revoke each part.

Outcomes

By the end, you can:

• explain sharing, ownership, and consumption in plain language;
• distinguish RAM from role assumption, resource-policy-only access, copying, and ownership transfer;
• model a resource share as resources, principals, and one managed permission per resource type;
• choose an account, organization, OU, IAM role/user, or service principal only where supported;
• explain Organizations trusted access, automatic access, external invitations, and membership changes;
• calculate effective access from resource-side and identity-side controls;
• choose and version AWS-managed or customer-managed permissions;
• predict Regional/global behavior, invitation expiry, association states, quotas, and deletion effects;
• assign owner/consumer duties for subnet, Transit Gateway, Resolver, IPAM, and license-sharing patterns;
• monitor CloudTrail and EventBridge evidence and diagnose invisible or unusable shares;
• design safe onboarding, change, revocation, recovery, and decommissioning.

Start with the simplest mental model

Suppose a central networking account owns a subnet and an application account needs to launch EC2 instances into it. RAM does not move or clone the subnet. The network account remains the owner. It creates a resource share that says:

resource:   the subnet ARN owned by Network
principal:  the application account or its OU
permission: the allowed consumer operations for ec2:Subnet

The application account can then discover the shared subnet and authorized application roles can create supported resources in it. The network team still controls the subnet, routes, and network ACL. The application account owns and pays for its instances and network interfaces. Security groups belong to the participant account unless the design uses a separately supported sharing feature.

RAM is therefore a control-plane relationship around a resource owned elsewhere - not a data copy, trust role, network connection, or universal permission grant.

What RAM is - and when to choose something else

Always check the live Shareable AWS resources matrix. Support differs by resource type for external accounts, IAM roles/users, service principals, customer-managed permissions, and Regional/global scope.

The resource-share object

A resource share has three essential parts:

1. Resources - one or more supported resources that the sharing account owns. A resource shared with you cannot be re-shared.
2. Principals - consumers such as an AWS account, your organization, an OU in your organization, and - only for supported resource types - an IAM role/user or service principal.
3. Managed permissions - one permission for each resource type in that share. It defines the maximum operations consumers can perform on resources of that type.

One share can contain several resources and resource types. A managed permission applies to every resource of its type in that share. Separate shares are often clearer when consumers, lifecycle, sensitivity, permission level, or support owners differ.

Important identifiers and state include the share ARN, name, owning account, allowExternalPrincipals, status, resources, principals, permission ARNs/versions, tags, association states, and creation/update times. Names are labels; automation and evidence should retain ARNs.

Ownership never silently moves

The sharing account owns the shared resource and normally controls its configuration, lifecycle, and owning-service bill. The consumer gets only the service operations permitted for that resource type. Resources that a consumer creates while using the shared resource generally belong to and are billed to that consumer; exact behavior is service-specific.

Use a responsibility record rather than assuming “shared means joint”:

Deleting a RAM share removes principals' access but does not delete the shared resources. Deleting or changing the underlying resource can still break every consumer. Remove consumers in a controlled sequence, discover dependencies, notify owners, test alternatives, revoke, verify denied access, and only then retire the resource.

Effective access is an intersection

The RAM managed permission is the resource-side maximum. A role or user in the consuming account also needs an identity-based Allow for the relevant service action and shared resource ARN. Effective access is approximately:

RAM/resource-side allow
INTERSECT consumer identity policy allow
INTERSECT permissions boundary and session policy
INTERSECT Organizations SCP/RCP limits
MINUS any applicable explicit deny
PLUS owning-service prerequisites and state

The RAM administrator also needs permission to operate RAM and the resource-owning service's PutResourcePolicy or equivalent operation. A successful CreateResourceShare call does not prove that the final workload action works.

When sharing to an entire organization or OU, understand the policy generated by RAM. The resource policy may use "Principal": "*" with organization conditions; if the scope includes the owner account, owner-account principals can fall within that resource-side grant. Keep identity policies least privilege and inspect the generated policy where supported with get-resource-policy.

Principal choices and their blast radius

Individual AWS account

Use when a bounded account needs the resource. The consumer account administrator decides which identities get matching IAM permissions. This is explicit but can create many associations.

Organization or OU

Use only for resources intended for every current and future account in that scope. Child OUs are included when an OU is selected. Organization membership becomes dynamic authorization: moving or adding an account may grant access; removing it normally removes access. Govern OU moves as security changes, not bookkeeping.

Only the organization and OUs containing the sharing account can be selected. You cannot share to somebody else's organization/OU as a principal; use supported individual accounts instead.

IAM role or user

Some resource types permit a specific role/user ARN as principal. This narrows the consumer, but support is not universal. Prefer roles and federation; long-lived IAM users are not a course design recommendation. Verify the current resource matrix before relying on direct principal sharing.

Service principal

Some resources can be shared to an AWS service such as service-id.amazonaws.com. A service-principal share cannot contain other principal types. Restrict and audit this path because the service operates on the customer's behalf; supported source-account context may be added by RAM/service behavior.

Organizations integration and invitations

Enabling RAM sharing with AWS Organizations is performed from the Organizations management account and requires all features. RAM creates AWSServiceRoleForResourceAccessManager and uses Organizations information to resolve organization/OU membership. The CLI operation is global in effect across Regions supported by RAM:

aws ram enable-sharing-with-aws-organization

With this integration enabled, same-organization account/OU/organization shares do not use invitations. Membership changes dynamically grant or remove the RAM relationship. Consumers still need identity permission.

Without that integration, sharing directly to an account - even one in the same organization - uses an invitation. External-account sharing also uses invitations when the resource type supports it. Access begins only after acceptance.

Invitation time is operationally important:

• most supported resource types: 12 hours before expiry and principal disassociation;
• Aurora DB clusters, EC2 capacity reservations/dedicated hosts, License Manager license configurations, and the other resource types in AWS's current exception list: seven days.

Do not memorize the exception list as permanent; verify the creation documentation. Automate recipient notification and acceptance evidence. An expired invitation cannot simply be accepted - repair the association/share as documented.

By default, same-organization access is lost if the consumer account leaves the organization. A newer resource-share option, RetainSharingOnAccountLeaveOrganization, can retain account-to-account access by creating invitation-style semantics. Use it only for a documented separation case; ordinary governance should fail closed when membership ends.

allowExternalPrincipals=false means restrict sharing to your organization where the resource type and integration support it. It does not make every identity inside that organization trusted, and resource types such as VPC subnets can remain organization-only regardless of a permissive setting.

Managed permissions and version control

AWS RAM turns a managed-permission template plus the selected resource and principal into the resource-based authorization used by the owning service.

AWS-managed permissions

Every RAM-supported resource type has at least one default AWS-managed permission. Some have additional permissions, such as read-only and broader operation sets. “Default permission” means the service's default choice for that resource type; “default version” means the current selected version of a particular permission. They are different concepts.

AWS can publish a new version and mark it default. Existing resource shares do not update automatically. Review its actions/conditions and deliberately update shares. Security fixes or new API support can make old versions risky or incomplete.

Customer-managed permissions

For supported resource types, author a narrower permission. They are Regional and apply to one resource type. Current restrictions include one statement and unsupported principal/source/system-tag condition categories; inspect the current limitations before converting an IAM policy. A permission can have up to five versions, and only its default version can be attached to a new share.

Creating or designating a new default does not alter existing shares. Updating a share requires associate-resource-share-permission --replace. Rollback requires making the former or corrected version default, then replacing the share's association again. Test both allowed and denied operations from a real consumer role before broad rollout.

Never assume the permission alone grants access. It sets the consumer ceiling; consumer IAM must still allow the action.

Region and global-resource rules

RAM and resource shares are Regional. A Regional share can include Regional resources from that same Region. Consumers call the owning service in that Region. A missing share is often just the wrong Console/CLI Region.

Supported global resources are managed in RAM's designated home Region, us-east-1. Their share is viewed/modified there, while the resource remains globally usable according to its owning service. A share in us-east-1 can mix supported global resources with us-east-1 Regional resources; one share cannot combine Regional resources from several Regions.

For multi-Region architecture, create separate shares, naming/tagging/evidence, monitoring, and rollback per Region. RAM does not replicate a Regional resource or provide disaster recovery.

Association and asynchronous state

Creating or modifying a share starts asynchronous associations. Do not treat API acceptance as completed access. Inspect resource/principal association status and statusMessage. Common lifecycle states include ASSOCIATING, ASSOCIATED, FAILED, DISASSOCIATING, and DISASSOCIATED; newer source-association APIs also expose suspended/restoring states.

Automation should:

1. submit an idempotent change;
2. record request/share/resource/principal identifiers;
3. poll until a terminal state with bounded backoff;
4. fail on FAILED and preserve statusMessage;
5. verify consumer discoverability and an allowed action;
6. verify a forbidden action remains denied;
7. emit evidence and an owner alert.

Eventual propagation can briefly make owner and consumer views disagree. A retry budget is appropriate; silently ignoring a failed state is not.

Service-specific architecture patterns

RAM supplies a common sharing control plane, but the owning service defines data plane and responsibilities.

VPC subnet sharing

The network account owns the VPC, subnet, route tables, gateways, and network ACLs. Participant accounts create supported resources such as instances/interfaces in the shared subnet and own their resources and security groups. Subnets are organization-scoped; RAM does not permit arbitrary external subnet sharing. Define IP allocation, AZ/route/egress/DNS behavior, security-group references, flow-log access, quotas, chargeback, and detachment/deletion order.

Transit Gateway sharing

The owner controls the Transit Gateway and RAM share; participants create/accept or operate attachments according to service settings and permission. TGW route tables, propagation/association, appliance mode, bandwidth, attachment/data-processing charges, and deletion responsibilities require a separate contract. A visible TGW does not prove routing or security.

Route 53 Resolver rules

The owner manages outbound endpoints and forwarding rules; consumers associate a shared rule with their VPC as permitted. Define domain ownership, endpoint capacity, target reachability, loops, query logging, failure response, and association lifecycle. Sharing a rule does not share a private hosted zone or automatically configure every VPC.

VPC IPAM pools

Central IPAM can share pools so consumer accounts allocate CIDRs under policy. Define allocation scope, locale/Region, netmask rules, tags, utilization alarms, reclaim/quarantine, and overlap control. Customer-managed permissions can support narrower actions where the resource type supports them.

Capacity, licenses, Aurora, and other services

Capacity reservations, dedicated hosts, license configurations, Aurora clusters, Parameter Store advanced parameters, Network Firewall resources, build artifacts, and many other types have different invitation windows, operation sets, billing, and deletion behavior. Never generalize from subnet sharing. Read both the RAM matrix and owning-service sharing documentation for each type.

Safe creation workflow

1. Record business owner, consumers, resource type/ARN, Region, data class, operations, SLO, cost, and revocation date.
2. Confirm the resource is RAM-supported and owned by the sharing account.
3. Verify allowed principal types and whether external/role/user/service-principal sharing is supported.
4. Select the narrowest managed permission and inspect its exact version/template.
5. Decide account versus OU/organization scope; forecast future membership.
6. Keep external principals disabled unless an approved requirement and supported type demand them.
7. Create the share through reviewed IaC/API, with tags and idempotency token where available.
8. Wait for associations; accept external invitations before expiry.
9. Add narrow consumer IAM permissions and verify applicable SCPs, boundaries, session policies, and service prerequisites.
10. Test discovery, one authorized action, one unauthorized action, owner monitoring, cost attribution, and revocation.
11. Register the dependency and review permission versions, principals, membership, use, and expiry periodically.

Example structure - do not run with placeholders:

aws ram create-resource-share \
  --region ap-south-1 \
  --name prod-network-subnets \
  --no-allow-external-principals \
  --resource-arns arn:aws:ec2:ap-south-1:111122223333:subnet/subnet-example \
  --principals arn:aws:organizations::111122223333:ou/o-example/ou-example \
  --permission-arns arn:aws:ram::aws:permission/AWSRAMDefaultPermissionSubnet

Do not copy an example permission ARN without using list-permissions --resource-type to confirm the current permission and version.

Read-only evidence audit

The no-create path works in a single approved account. Start by proving caller and Region; redact account IDs and sensitive resource ARNs from submissions:

aws sts get-caller-identity --query Arn --output text
aws ram get-resource-shares --region ap-south-1 --resource-owner SELF \
  --query 'resourceShares[].{Name:name,Arn:resourceShareArn,Status:status,External:allowExternalPrincipals}'
aws ram get-resource-shares --region ap-south-1 --resource-owner OTHER-ACCOUNTS
aws ram get-resource-share-associations --region ap-south-1 \
  --association-type PRINCIPAL --resource-share-arns replace-with-share-arn
aws ram get-resource-share-associations --region ap-south-1 \
  --association-type RESOURCE --resource-share-arns replace-with-share-arn
aws ram list-principals --region ap-south-1 --resource-owner SELF \
  --resource-share-arns replace-with-share-arn
aws ram list-resources --region ap-south-1 --resource-owner SELF \
  --resource-share-arns replace-with-share-arn
aws ram list-resource-share-permissions --region ap-south-1 \
  --resource-share-arn replace-with-share-arn
aws ram list-resource-share-invitations --region ap-south-1
aws ram list-permissions --region ap-south-1 --resource-type ec2:Subnet

Repeat in us-east-1 for global-resource shares. Follow pagination. Then inspect the owning service, consumer identity policy, SCP/boundary, CloudTrail event, and a documented behavior test; RAM inventory alone is incomplete evidence.

Monitoring and incident evidence

CloudTrail records RAM API calls such as CreateResourceShare, AssociateResourceShare, invitation actions, permission changes, and Organizations integration. Retain a multi-Region trail outside the operator's deletion boundary and correlate actor, source identity/IP, request parameters, share ARN, Region, time, and result.

EventBridge receives near-real-time RAM state-change events with source aws.ram. Alert on failed associations and high-risk principal/permission/share changes. Direct RAM events are best effort, so reconcile periodically from RAM APIs rather than treating events as a complete ledger.

Monitor the owning service as well: a RAM association can be healthy while routing, capacity, DNS, keys, license limits, or service configuration fails. Owner and consumer need linked incident records and contact paths.

Troubleshooting decision tree

Consumer cannot see the resource

Check exact account/role, Region (us-east-1 for global shares), resource-type support, invitation status/expiry, principal association state/message, Organizations sharing integration/membership, allowExternalPrincipals, and owning-service discoverability. A resource-policy-only grant may work by ARN without appearing in normal listings.

Resource is visible but the operation is denied

Compare the attached managed permission/version with consumer identity policy, permissions boundary, session policy, SCP/RCP, explicit denies, resource ARN, and service prerequisites. Use CloudTrail in both accounts where relevant; “RAM says ASSOCIATED” proves only the relationship.

No invitation arrived

Same-organization sharing with Organizations integration intentionally sends none. Otherwise verify recipient account/role, supported external principal type, Region, list-resource-share-invitations, expiry, and association status rather than waiting for email.

Share creation or association fails

Inspect statusMessage, CloudTrail, ownership, resource ARN/Region, quotas, PutResourcePolicy authority, permission/resource compatibility, external-sharing support, organization IDs, and service prerequisites. EventBridge can alert on asynchronous failures that the initial call did not show.

Access disappeared after an OU/account change

Check Organizations movement/removal, direct versus OU/organization principal, retain-on-leave setting, SCP changes, invitation semantics, and association state. Restore only after confirming the intended governance boundary.

A subnet/TGW/rule is shared but traffic fails

RAM is not routing. Inspect attachments, associations/propagation, route tables, network ACLs, security groups, endpoints, DNS, appliances, AZ/Region, and return path in the owning service.

Quotas and scale

Default quotas can change, so query Service Quotas/current docs. At review time RAM documents 25,000 resource shares per Region, 5,000 resource associations per share, 5,000 principal associations per share, 1,500 customer-managed permissions, ten per resource type, and five versions per customer-managed permission. The same resource in ten shares consumes ten association-count units; an organization ID is one principal association even though it expands to many accounts.

Scale is not only quota. Model policy size, owner API throttling, consumer discovery, OU churn, blast radius, event volume, permission-version rollout, incident fan-out, and decommission dependencies. Prefer stable scopes and purpose-specific shares over one universal share.

Cost model

AWS RAM and resource shares have no additional RAM charge. That does not mean the architecture is free. Price the owning resource, consumer-created resources, requests, data processing/transfer, cross-AZ/Region paths, logs, EventBridge/SNS automation, CloudTrail data storage/query, support, licenses, NAT/TGW/Resolver endpoints, and engineering operations according to each owning service.

Document who receives each bill and how shared cost is allocated. RAM can make a centralized resource cheaper through reuse or more expensive through hidden data paths and a larger failure domain.

Revocation and decommissioning

Revocation is a production change:

1. inventory consumers and dependent resources/traffic;
2. notify owners and freeze new use;
3. provide migration/replacement and test it;
4. remove the principal/resource association or share;
5. poll for disassociation and test denied access;
6. remove consumer IAM permissions, routes, DNS, grants, and stale automation;
7. retain audit evidence and update cost/catalog records;
8. delete the owner resource only after service-specific dependency checks and retention approval.

An emergency revoke can skip notice to contain compromise, but must have an incident owner, blast-radius decision, evidence capture, and recovery path.

Practical lab

Download the AWS259 RAM architecture pack. It contains:

• RESOURCE_SHARE_DESIGN_WORKBOOK.md for owner, consumer, permission, Region, lifecycle, and cost decisions;
• SUPPLIED_RAM_CASES.md with eight failure scenarios;
• PERMISSION_AND_EVIDENCE_MATRIX.md for two-sided authorization and audit proof;
• REVOCATION_AND_GAMEDAY.md for safe change and recovery;
• ANSWER_DIRECTIONS.md, opened only after independent diagnosis.

Design four shares for a multi-account enterprise: subnets, Transit Gateway, Resolver rules, and IPAM pools. Add one external-account case that must be accepted or rejected from current resource support. Submit ownership/RACI, principal scope, permission/version, IaC workflow, allowed/denied tests, Region/invitation handling, telemetry, cost allocation, quota forecast, revocation, and game-day evidence.

Knowledge check

1. Why is RAM sharing neither resource copying nor ownership transfer?
2. What are the three required parts of a resource share?
3. Why can an ASSOCIATED share still produce AccessDenied?
4. When does a recipient receive no invitation, a 12-hour invitation, or a seven-day invitation?
5. What changes when sharing with an OU instead of an account?
6. Why can an OU move become an authorization event?
7. What does allowExternalPrincipals=false protect, and what does it not prove?
8. How do “default permission” and “default permission version” differ?
9. Why do existing shares not automatically use a newly published permission version?
10. What limits apply to customer-managed permissions?
11. Why must global-resource shares be managed in us-east-1?
12. Which responsibilities remain with a shared-subnet owner and participant?
13. Why does sharing a Transit Gateway or Resolver rule not create working traffic/DNS?
14. What evidence should an asynchronous association workflow retain?
15. Why must EventBridge alerts be paired with reconciliation?
16. What survives when a resource share is deleted?
17. Which costs remain even though RAM itself has no extra charge?
18. What sequence makes planned revocation safe?

Lesson acceptance

Pass requires a correct share/ownership explanation; decision comparison; current resource-support check; four service-specific designs; principal and Organizations/invitation analysis; two-sided permission matrix; AWS/customer-managed permission version plan; Regional/global model; asynchronous state handling; read-only evidence plan; CloudTrail/EventBridge controls; quotas/cost/RACI; eight supplied diagnoses; positive/negative/revocation tests; and a dependency-safe decommission runbook.

Official sources

• What is AWS RAM?
• Terms and concepts
• Shareable AWS resources
• Share resources that you own
• Managing permissions
• Customer-managed permissions
• Regional and global resources
• Access resources shared with you
• Delete a resource share
• CloudTrail logging
• EventBridge monitoring
• Troubleshooting AWS RAM
• AWS RAM quotas