Skip to content

SYSTEM Cited by 2 sources

AWS Resource Access Manager (RAM)

Definition

AWS Resource Access Manager (RAM) is the AWS service that shares resources across AWS accounts without requiring resource duplication. Customers can share specific resources (transit gateways, subnets, license configurations, recovery points, etc.) with other accounts in their AWS Organization or with specific external accounts.

In cyber-resilience designs, RAM is the mechanism by which the Recovery Account shares logically-air-gapped-vault recovery points with the IRE for restore operations.

Verbatim from the canonicalising source:

"Share recovery points through AWS Resource Access Management (AWS RAM) for restore. You share recovery points across accounts through AWS RAM. You can initiate restores from the owning account or from any account with which you share the vault. This is how the Recovery Account makes recovery points available to the IRE." (Source: sources/2026-05-20-aws-cyber-resilience-on-aws-a-reference-approach-for-recovery-from-ransomware-and-destructive-events)

Role in the three-account topology

Account RAM role
Production Pushes backups to the Recovery Account vault (writes are cross-account; sharing is one-way)
Recovery Account Owns the vault; shares it via RAM with the IRE
IRE Receives shared vault access from RAM; initiates restores into IRE infrastructure

What RAM provides

  • Resource share — a named container of shared resources + principal grants (which accounts can use them).
  • Cross-account access without duplicating the resource.
  • Granular permissions on what shared accounts can do (e.g. read-only access to a recovery point).

Composition with logically air-gapped vault

The vault → IRE access pattern:

  1. Recovery Account creates a logically air-gapped vault.
  2. Recovery Account creates a resource share in RAM that includes the vault.
  3. Recovery Account adds the IRE account ID as a principal on the share.
  4. IRE account accepts the share invitation.
  5. IRE can now initiate restores from the shared vault.

The MPA gate still applies — IRE-initiated restores still require MPA approval before proceeding. RAM grants access, not authorisation to bypass MPA.

Association types: org-bound vs external (account-migration behavior)

A second major wiki shape for RAM — beyond cyber-resilience vault sharing — is its behavior when a consumer account moves between AWS Organizations. RAM associations come in two kinds with opposite durability:

  • Organization-bound — trust is derived from org membership (created automatically when "sharing with AWS Organizations" is enabled, even when the share names a bare account ID). RAM removes the association when the account leaves the source org.
  • External principal — formed via invitation/accept; survives the account move because it does not depend on org membership.

Losing an org-bound association is a control-plane loss (see concepts/control-plane-data-plane-separation): existing attachments keep working (data plane intact) but the account can no longer change the shared resource. In the canonical migration a terraform apply against a shared Transit Gateway failed while traffic flowed and no alarm fired.

Enabling settings: RetainSharingOnAccountLeaveOrganization (RAM, 2026-02-27) marks principals external after accept, but applies only to new shares — it does not retrofit existing shares. allowExternalPrincipals alone is not sufficient; both flags are required on a bridge share.

Migration mechanism: because a resource can belong to more than one share, the retained bridge-share pattern creates a parallel external share to carry access through the move, then restores the original (the Lake Formation-managed source of truth) and deletes the bridge.

Observability: RAM emits resource-share state-change events to EventBridge; CloudTrail records DisassociateResourceShare API calls for audit.

(Source: sources/2026-08-24-aws-preserving-ram-shares-and-lake-formation-permissions-during-organizations-migration)

Generalisation beyond AWS

Equivalent cross-account / cross-tenant resource sharing:

  • GCP — IAM cross-project bindings for resources.
  • Azure — Azure RBAC across subscriptions.
  • On-prem — directory services (LDAP) with cross-domain trust.

The structural property: declarative cross-tenant sharing of specific resources with granular access controls.

Seen in

  • systems/aws-backup — sibling backup primitive.
  • systems/aws-backup-logically-air-gapped-vault — the resource shared via RAM in cyber-resilience.
  • systems/aws-organizations — the multi-account container RAM operates within.
  • systems/aws-lake-formation — governance service whose cross-account grants are implemented as RAM shares.
  • organization-bound-resource-share — the association type that breaks on account move.
  • external-principal-association — the durable association type the bridge relies on.
  • retained-bridge-share-migration — the account-migration continuity pattern.
  • cyber-resilience — the parent posture.
  • three-account-cyber-recovery-topology — the topology RAM enables.
Last updated · 766 distilled / 2,225 read