AWS Resource Access Manager (RAM)

AWS Resource Access Manager (AWS RAM)

RAM resource replication with Arpio

Arpio replicates the following AWS Resource Access Manager resource types to enable disaster recovery of shared resources across your AWS accounts and organizations.

Jump to:

Resource Share
Resource Share Permission
Configuration Tags for RAM

Overview

AWS Resource Access Manager (RAM) enables you to share AWS resources with other AWS accounts, organizational units (OUs), or your entire AWS Organization. When implementing disaster recovery with Arpio, RAM Resource Shares are critical for maintaining cross-account resource access in your recovery environment.

Arpio automatically discovers and replicates RAM Resource Shares that are associated with resources in your application. During recovery, Arpio recreates these shares in the recovery environment, translating resource ARNs and, when configured, principal ARNs to maintain proper access controls.

Resource Share

Arpio replicates RAM Resource Shares to the recovery environment. A Resource Share defines which resources are shared and with which principals (accounts, organizations, or organizational units).

The following attributes are translated during replication:

Attribute	Translation
Resource ARNs	Translated to corresponding resources that Arpio manages in the recovery environment
Account Principals	Account IDs are preserved; recovery account access is maintained
Role Principals	Translated to corresponding roles in the recovery environment
Organization/OU Principals	By default, not translated. Use arpio-config:recovery-principal to specify recovery organization/OU ARNs
Resource Share Permissions	Translated to corresponding permissions in the recovery environment
Tags	Preserved from the primary environment

The following resources are automatically selected into recovery points when a RAM Resource Share is selected:

All resources referenced in the Resource Share
Associated Resource Share Permissions
VPC Subnets, Transit Gateways, or other shareable resources referenced by the share

Resource Share Permission

Arpio replicates RAM Resource Share Permissions to the recovery environment. These permissions define what actions principals can perform on shared resources.

No fields require translation during replication. AWS-managed permissions are automatically available in the recovery region.

Configuration Tags for RAM

Arpio provides configuration tags to control how RAM Resource Shares are recovered. The primary tag for RAM is arpio-config:recovery-principal, which allows you to specify how organization and OU principals should be translated to the recovery environment.

For complete documentation on this tag, including format, parameters, and examples, see Arpio Configuration Tags.

Quick Reference:

Tag Key:   arpio-config:recovery-principal:<org-or-ou-id>

Tag Value: <recovery-org-or-ou-arn>

By default, Arpio does not translate organization/OU principals, which supports scenarios where resources are shared with external organizations. Use this tag when you need to map a primary environment org/OU to a recovery environment equivalent.

Implementing Arpio with RAM Share

Prerequisites

This guide assumes Arpio is already configured in your AWS environment with CloudFormation stacks deployed. Before implementing RAM Share replication, ensure the following:

AWS Organizations is enabled (if using organization-level sharing)
RAM sharing is enabled within your organization (if applicable)
You have identified the resources that use RAM sharing in your primary environment
You have documented the organization/OU structure in both primary and recovery environments

Common Use Cases

1. Shared VPC Subnets

When you share VPC subnets across accounts using RAM, Arpio replicates both the subnet and the associated Resource Share. During recovery, the subnet is recreated in the recovery VPC, and the Resource Share is configured to grant access to the same principals (or translated principals, if configured).

2. Transit Gateway Sharing

Transit Gateways shared via RAM allow multiple accounts to attach their VPCs. Arpio handles Transit Gateway replication and ensures the associated RAM Resource Shares are properly configured in the recovery environment.

Step-by-Step Implementation

Step 1: Identify RAM Resource Shares

Begin by identifying all RAM Resource Shares in your primary environment that are associated with resources you want to protect with Arpio. You can navigate to AWS Console > Resource Access Manager in the AWS UI to identify all RAM Resource Shares in your primary account and region or you can use the following AWS CLI Command below:

Using the AWS CLI:

aws ram get-resource-shares --resource-owner SELF

Step 2: Document Principal Mappings

For each Resource Share, document the principals (accounts, organizations, OUs) that have access. Determine which principals need to be translated to recovery environment equivalents.

Create a mapping table:

Primary Principal	Recovery Principal	Action Required
o-primaryorg	o-recoveryorg	Add config tag
ou-prod-units	ou-dr-units	Add config tag
External vendor org	External vendor org	No action (preserved)

Step 3: Apply Configuration Tags

Apply the arpio-config:recovery-principal tag to RAM Resource Shares that include organization or OU principals requiring translation. This tag is only needed for org/OU principals—account ID principals are preserved automatically and do not require tagging.

If a RAM Resource Share includes an organization or OU principal that lacks a recovery mapping, Arpio will display an issue alerting you to the missing configuration. Use this as a guide to identify which Resource Shares need the tag.

Using the AWS CLI:

aws ram tag-resource \  --resource-share-arn arn:aws:ram:us-east-1:111111111111:resource-share/abc123 \  --tags "key=arpio-config:recovery-principal:o-primaryorg,value=arn:aws:organizations::222222222222:organization/o-recoveryorg"

Step 4: Select Resources in Arpio

When creating or updating your Arpio application, select the resources that are shared via RAM. Arpio will automatically discover and include the associated RAM Resource Shares in your recovery points.

Step 5: Verify Recovery Configuration

After creating a recovery point, verify the RAM Resource Share configuration in the recovery environment:

Check that Resource Shares exist in the recovery region
Verify principal ARNs are correctly translated
Confirm shared resources are accessible from participant accounts
Test resource access using the AWS Management Console or CLI

Best Practices

Organization Structure Consistency

Maintain a consistent organizational structure between your primary and recovery environments. This simplifies principal mapping and reduces configuration complexity. Consider creating parallel OU structures in both organizations.

External Sharing Considerations

When sharing resources with external organizations (vendors, partners), Arpio preserves these sharing relationships by default. This ensures that during a disaster recovery event, external parties maintain access to shared resources. External sharing is typically configured using account IDs, which Arpio preserves automatically. In the less common case where external parties are referenced by their organization or OU ARN, you can use the arpio-config:recovery-principal tag to control translation behavior.

Testing Recovery

Regularly test your recovery configuration using Arpio's test functionality. Verify that RAM Resource Shares are correctly created and that principals can access shared resources in the recovery environment. Document any issues and update configuration tags as needed.

Documentation

Maintain comprehensive documentation of your RAM sharing configuration, including principal mappings, configuration tags, and any special considerations for your environment. This documentation is critical for troubleshooting and onboarding new team members.

Same Organization, Different OUs

A common architecture pattern is to use the same AWS Organization but separate Organizational Units (OUs) for production and disaster recovery accounts. For example, production workloads may reside in an OU named "Production" while recovery accounts are in an OU named "DR" or "Recovery". This setup has specific implications for RAM share replication.

How RAM Share Principal Configuration Affects Recovery

The behavior during recovery depends on how the RAM Resource Share principals are configured in the primary environment:

Principal Type	Recovery Behavior	Action Required
Entire Organization	Works automatically. Recovery accounts in the same org can access shared resources.	None - sharing applies org-wide
Specific OU (e.g., ou-prod-xxx)	Recovery accounts in a different OU will NOT have access unless principal is translated.	Use arpio-config:recovery-principal to map prod OU to recovery OU
Specific Account IDs	Only the specified accounts have access. Recovery accounts need to be added or mapped.	Add recovery account IDs to the share, or use account-level mapping

Configuring OU-to-OU Principal Translation

When your RAM Resource Share grants access to a specific production OU, you must configure Arpio to translate that principal to your recovery OU. Since both OUs are in the same organization, only the OU ID changes.

Example Scenario:

Organization ID: o-abc123def
Production OU: ou-abc1-produnit (contains production accounts)
Recovery OU: ou-abc1-drunit (contains disaster recovery accounts)
RAM Share: Grants access to the Production OU

Configuration Tag:

Tag Key:   arpio-config:recovery-principal:ou-abc1-produnitTag Value: arn:aws:organizations::111111111111:ou/o-abc123def/ou-abc1-drunit

AWS CLI Example:

aws ram tag-resource \  --resource-share-arn arn:aws:ram:us-east-1:111111111111:resource-share/abc123 \  --tags "key=arpio-config:recovery-principal:ou-abc1-produnit,value=arn:aws:organizations::111111111111:ou/o-abc123def/ou-abc1-drunit"

Recommendations for Same-Org Deployments

Consider these recommendations when using the same organization for production and recovery:

Use Organization-level or Account-level Sharing When Possible Both organization-level sharing and account-scoped sharing (sharing with specific account IDs) are automatically handled by Arpio without requiring configuration tags. Account-scoped sharing is narrower and may be preferred when your security model requires more restrictive access. Only OU-level sharing requires the arpio-config:recovery-principal tag because Arpio needs to know which recovery OU corresponds to the production OU.

Mirror your OU structure

If you have multiple production OUs (e.g., by team or environment), create corresponding recovery OUs with a consistent naming convention. This makes principal mapping straightforward and easier to maintain.

Document OU mappings

Maintain a mapping document that lists each production OU and its corresponding recovery OU. This is essential for configuring Arpio tags correctly and for onboarding new team members.

Example OU Mapping Document:

Production OU	Recovery OU	Purpose
ou-abc1-produnit	ou-abc1-drunit	Application workloads
ou-abc1-dataunit	ou-abc1-datadru	Data/analytics accounts
ou-abc1-network	ou-abc1-networkdr	Networking accounts

Consider SCPs for recovery isolation

Use Service Control Policies (SCPs) on your recovery OUs to prevent accidental use during normal operations. During a DR event, these policies can be temporarily relaxed to allow recovery workloads to function.

Handling RAM Shares from External Accounts

In many environments, RAM Resource Shares originate from accounts that Arpio does not initially have access to. For example, a central networking account may share Transit Gateways or VPC subnets to application accounts, but only the application accounts are connected to Arpio. In this scenario, Arpio cannot discover or replicate the RAM Resource Share because it resides in an account outside of Arpio's visibility.

There are two approaches to handle this scenario:

Option 1: Connect the Source Account to Arpio (Recommended)

The recommended approach is to connect the source account (where the RAM share originates) to Arpio. This enables Arpio to discover and replicate the RAM Resource Share automatically, providing full disaster recovery automation.

Step 1: Connect the Source Account to Arpio

Work with the team that manages the source account to connect it to Arpio. This involves deploying the Arpio CloudFormation stack in that account, following your standard Arpio onboarding process.

Step 2: Create an Arpio Application for the Source Account

Create a new Arpio application that includes the RAM Resource Share and the underlying shared resources (subnets, Transit Gateways, etc.). This application should be configured with:

The source account as the primary environment
An appropriate recovery account and region
The RAM Resource Share and all resources it shares selected for replication

Step 3: Coordinate Recovery Between Applications

During a disaster recovery event, you will need to recover applications in the correct order:

First, recover the source account application (containing the RAM Resource Share)
Wait for the RAM share to be created and active in the recovery environment
Accept the RAM share invitation in recipient accounts (if required)
Then, recover the recipient account application(s) that depend on the shared resources

Benefits of this approach:

Full automation of RAM share replication
Arpio handles resource translation and principal mapping
Recovery points capture the current state of shared resources
No manual pre-creation of resources required

Option 2: Pre-create and Reference Recovery Resources

If connecting the source account to Arpio is not feasible (due to organizational constraints, security requirements, or other factors), you can manually configure the sharing relationship in the recovery environment and instruct Arpio to use those pre-created resources.

Step 1: Pre-create the RAM Share in the Recovery Environment

Work with the team that manages the owner account to create an equivalent RAM Resource Share in the recovery region. This share should:

Share equivalent resources (subnets, Transit Gateways, etc.) from the recovery region
Grant access to the same recipient accounts or their recovery equivalents
Be accepted by the recipient accounts in the recovery environment

Step 2: Use arpio-config:recovery-resource Tag

Apply the arpio-config:recovery-resource tag to resources in your primary environment that depend on the external RAM share. This tag tells Arpio to use a specific pre-existing resource in the recovery environment instead of attempting to create one.

Example: Shared Subnet from External Account

If your application uses a subnet shared from a central networking account:

Coordinate with the networking team to create an equivalent shared subnet in the recovery region
Accept the RAM share invitation in your recovery account
Note the subnet ID of the shared subnet in the recovery environment
Tag resources in your primary account that reference the shared subnet:

aws ec2 create-tags \  --resources subnet-0abc123def456 \  --tags "Key=arpio-config:recovery-resource,Value=subnet-0xyz789recovery"

Limitations of this approach:

Requires manual coordination with the source account team
Pre-created resources must be maintained and kept in sync
Changes to primary resources require manual updates to recovery resources
Recovery resource mappings (tags) must be updated if recovery resource IDs change

Choosing Between Options

Consider the following factors when deciding which approach to use:

Factor	Option 1 (Connect Account)	Option 2 (Pre-create)
Automation level	Fully automated	Manual setup required
Ongoing maintenance	Low - Arpio manages	High - manual sync needed
Cross-team coordination	Initial setup only	Ongoing coordination
Security/compliance	Requires Arpio access to additional account	No additional account access needed
Recovery time	Faster - sequential app recovery	Depends on manual processes

Resolving RAM Share Conflicts Across Multiple Applications

In environments where a shared account provides resources to multiple teams via RAM, you may encounter conflicts when different Arpio applications depend on the same RAM Resource Share but recover to different accounts. This section explains how to identify and resolve these conflicts.

Understanding the Conflict

Consider this scenario where a shared operations account (Shared-Services) provides RAM-shared resources to multiple application teams:

Application	Primary Environment	Recovery Environment
Application-A	111111111111/us-east-1	333333333333/us-west-2
Shared-Services-DR	222222222222/us-east-1 (shared)	444444444444/us-west-2

If Application-A depends on a RAM Resource Share in the shared Shared-Services account (222222222222), but Shared-Services-DR is already replicating that share to a different recovery account (444444444444), Arpio will display an error:

Resource Share [share-name] is not owned by this account (111111111111) and cannot yet be recovered. To restore this shared resource, please ensure that the RAM resource share [share-name] in 222222222222 exists in another Arpio application and is recovered simultaneously with this application.

This occurs because Arpio cannot replicate the same source resource to multiple different recovery accounts simultaneously.

Solution 1: Create a Lightweight Subset Application

Create a minimal Arpio application that contains only the RAM Resource Share (and its direct dependencies), using the same recovery account as your dependent application. This avoids dragging unrelated resources into your failover.

Steps:

Create a new Arpio application for the shared account
Configure it with the SAME recovery account as your dependent application
Select ONLY the RAM Resource Share and its required dependencies
During failover, recover both applications simultaneously

Example Configuration:

Application	Primary Environment	Recovery Environment
Application-A	111111111111/us-east-1	333333333333/us-west-2
Shared-Services-RAM (new)	222222222222/us-east-1	333333333333/us-west-2 (same)

This lightweight application serves as a dedicated vehicle to replicate only the RAM share to the correct recovery account, without interfering with the existing Shared-Services-DR application.

Solution 2: Remove the Dependency

If the RAM Resource Share is not critical to your disaster recovery requirements, you can remove it from your application. Use the Arpio console to understand the dependency chain and uncheck the appropriate resources.

Understanding Dependency Chains:

In the Arpio console, hover over resource checkboxes to see the dependency chain. For example, a Route53 Resolver Rule shared via RAM might have this chain:

VPC → Resolver Rule (weak dependency) → RAM Resource Share (strong dependency)

To remove the dependency:

Open your application in the Arpio console
Navigate to resource selection
Uncheck the intermediate resource (e.g., Resolver Rule)
Uncheck the RAM Resource Share

Note: Before removing dependencies, verify that your application can function in the recovery environment without the shared resources. Some resources (like Route53 Resolver Rules) may be required for DNS resolution.

Solution 3: Align Recovery Accounts

If organizationally feasible, coordinate with other teams to use the same recovery account. This eliminates the conflict entirely and allows all dependent applications to recover together.

This approach is ideal when:

Multiple applications share significant infrastructure dependencies
Teams are willing to coordinate their DR strategies
A single recovery account can accommodate all workloads
Simultaneous failover of related applications is acceptable

Choosing the Right Solution

Use this decision guide to select the appropriate solution:

Scenario	Recommended Solution
RAM share is critical and must recover to your specific account	Solution 1: Create subset application
RAM share is not required for DR functionality	Solution 2: Remove the dependency
Multiple teams can coordinate on a shared recovery strategy	Solution 3: Align recovery accounts
Source account already connected to Arpio by another team	Solution 1: Create subset app with your recovery account

Troubleshooting

Resource Share Not Created in Recovery

If a RAM Resource Share is not created in the recovery environment, verify that the shared resources are included in your Arpio application. Arpio automatically discovers Resource Shares associated with selected resources.

Principal Translation Not Working

If organization or OU principals are not being translated, check that the arpio-config:recovery-principal tag is correctly formatted and applied to the Resource Share in the primary environment. The tag key must include the exact short ID of the primary principal.

Access Denied After Recovery

If principals cannot access shared resources after recovery, verify that the recovery organization or OU ARN is correct and that the principal account is a member of the specified organization or OU. Also ensure that RAM sharing is enabled in the recovery organization.

Related Resources

Arpio Configuration Tags - Complete reference for all Arpio configuration tags
AWS Resource Overview - Full list of supported AWS resource types
Performing a Recovery - Guide to executing disaster recovery with Arpio
AWS RAM Documentation - Official AWS Resource Access Manager documentation
Disaster Recovery Planning Checklist - Comprehensive DR planning guide