Converting RAM Organization-Based Shares to Account-ID Shares Before an AWS Organizations Migration

Overview

RAM shares that target an organization or OU break when an account leaves that org. Account-ID shares survive because they reference a specific 12-digit account number with no org dependency.

This article covers how to find org-based shares, build account-ID replacements, validate them, and remove the originals. It pairs with Shared Services Account Migration: Best Practices for AWS Organizations.

Why Convert Before Migration

Org-based shares use an organization ARN or OU ARN as the principal. Access depends on the account being a member of that org. Once the account moves to a new org, membership ends and the share stops working.

Resources commonly affected:

• Route 53 Resolver Rules (centralized DNS)
• Transit Gateway (cross-account networking)
• VPC Subnets (multi-account workloads)
• License Manager configurations
• AWS Network Firewall policies

Note: Account-ID shares are the migration bridge, not the end state. Once all accounts land in the destination org, re-establish org-based shares there and remove the account-ID shares. Org-based sharing is still the better long-term model because new accounts inherit access automatically.

Step 1: Identify Org-Based Shares

List all shares you own:

aws ram get-resource-shares \
  --resource-owner SELF \
  --query "resourceShares[].{Name:name,ARN:resourceShareArn,Status:status}" \
  --output table

For each share, list principals:

aws ram list-principals \
  --resource-owner SELF \
  --resource-share-arns "arn:aws:ram:us-east-1:123456789012:resource-share/12345678-abcd-1234-efgh-123456789012"

Check the id field for each principal:

Principal ID format	Type	Migration risk
arn:aws:organizations::*:organization/o-*	Org-wide	Breaks on migration
arn:aws:organizations::*:ou/o-*/ou-*	OU-scoped	Breaks on migration
123456789012 (12-digit account ID)	Account-specific	Survives migration

Any share with an org or OU principal needs conversion.

Step 2: Identify Consuming Accounts

Share with accounts that actually use the resource. Sharing with every account in the org adds clutter and complicates audits.

Transit Gateway (accounts with active attachments):

aws ec2 describe-transit-gateway-attachments \
  --filters "Name=transit-gateway-id,Values=tgw-0a1b2c3d4e5f67890" \
  --query "TransitGatewayAttachments[].ResourceOwnerId" \
  --output text | tr '\t' '\n' | sort -u

Route 53 Resolver Rules (VPCs with associations):

aws route53resolver list-resolver-rule-associations \
  --query "ResolverRuleAssociations[?ResolverRuleId=='rslvr-rr-0a1b2c3d4e5f67890'].{VPCId:VPCId,Status:Status}" \
  --output table

Cross-reference VPC IDs to owning accounts with aws ec2 describe-vpcs.

VPC Subnets (accounts with ENIs in the shared subnet):

aws ec2 describe-network-interfaces \
  --filters "Name=subnet-id,Values=subnet-0a1b2c3d4e5f67890" \
  --query "NetworkInterfaces[].OwnerId" \
  --output text | tr '\t' '\n' | sort -u

Fallback (when you cannot determine actual consumers):

aws organizations list-accounts \
  --query "Accounts[?Status=='ACTIVE'].Id" \
  --output text

Or for a specific OU:

aws organizations list-accounts-for-parent \
  --parent-id ou-ab12-cd34ef56 \
  --query "Accounts[?Status=='ACTIVE'].Id" \
  --output text

Step 3: Create the Replacement Share

First, check what managed permission the original share uses:

aws ram list-resource-share-permissions \
  --resource-share-arn "arn:aws:ram:us-east-1:123456789012:resource-share/12345678-abcd-1234-efgh-123456789012"

Note the permission ARN if it differs from the default for that resource type.

Create the new share with account-ID principals. Use a clear naming pattern (e.g., <resource>-<env>-<region>-account-share):

aws ram create-resource-share \
  --name "tgw-prod-us-east-1-account-share" \
  --resource-arns "arn:aws:ec2:us-east-1:123456789012:transit-gateway/tgw-0a1b2c3d4e5f67890" \
  --principals "111111111111" "222222222222" "333333333333" \
  --permission-arns "arn:aws:ram::aws:permission/AWSRAMDefaultPermissionTransitGateway"

Omit --permission-arns if the original uses the default permission.

Auto-accept behavior:

• Accounts in the same org: auto-accepted (no action needed from the consumer).
• Accounts outside the org: consumer must run aws ram accept-resource-share-invitation.

Since you are converting pre-migration, all accounts are still in the same org. The new shares auto-accept with no disruption.

Batch migrations: If accounts leave in batches, create the account-ID share before the first batch departs. Accounts that have already left must accept the invitation manually.

Step 4: Validate

Confirm the share is active:

aws ram get-resource-shares \
  --resource-owner SELF \
  --name "tgw-prod-us-east-1-account-share" \
  --query "resourceShares[].{Status:status,ARN:resourceShareArn}"

Confirm principals show ASSOCIATED:

aws ram list-principals \
  --resource-owner SELF \
  --resource-share-arns "arn:aws:ram:us-east-1:123456789012:resource-share/yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"

Then validate functional access from a consuming account:

Route 53 Resolver Rules:

aws route53resolver list-resolver-rules \
  --query "ResolverRules[?OwnerId!='123456789012'].{Id:Id,Name:Name,Status:Status}"

Transit Gateway:

aws ec2 describe-transit-gateways \
  --query "TransitGateways[].{Id:TransitGatewayId,OwnerId:OwnerId,State:State}"

VPC Subnets:

aws ec2 describe-subnets \
  --filters "Name=owner-id,Values=123456789012" \
  --query "Subnets[].{SubnetId:SubnetId,VpcId:VpcId,OwnerId:OwnerId}"

For VPC subnets, go beyond describe. Confirm Auto Scaling can launch in the shared subnet, or launch a test instance. Visibility alone does not prove launch permissions work.

Step 5: Delete the Original Share

Once validation passes, delete the original:

aws ram delete-resource-share \
  --resource-share-arn "arn:aws:ram:us-east-1:123456789012:resource-share/12345678-abcd-1234-efgh-123456789012"

This approach (new share, validate, delete old) gives you a clean rollback path and avoids mixed principal types on a single share.

If the original share has other principals or resources that must stay, remove only the org principal:

aws ram disassociate-resource-share \
  --resource-share-arn "arn:aws:ram:us-east-1:123456789012:resource-share/12345678-abcd-1234-efgh-123456789012" \
  --principals "arn:aws:organizations::123456789012:organization/o-a1b2c3d4e5"

Other principals on the same share remain unaffected.

Rollback

If validation fails in Step 4, delete the new share:

aws ram delete-resource-share \
  --resource-share-arn "arn:aws:ram:us-east-1:123456789012:resource-share/yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"

The original share is still intact. Access continues as before. Common failure causes: missing managed permission, wrong resource ARN, or org sharing not enabled in the management account. Fix the issue and retry with no time pressure.

Important Considerations

Transit Gateway attachments persist after share removal. Existing attachments keep working. The share only controls who can create new ones.

Resolver Rule associations persist after share removal. DNS keeps resolving. The share only controls new associations.

VPC subnet shares carry higher risk. Existing instances and ALBs keep running. But Auto Scaling launches, ALB scaling, and new ENI creation fail if the share breaks. Validate quickly and keep the window tight.

RAM shares are regional. Convert shares in each region where they exist. Global resources (Route 53, IAM) require the share to be in us-east-1.

Management account stays behind. If the management account owns the shared resources and member accounts are migrating out, the account-ID shares continue working across orgs with no extra steps.

Managed permissions must match. If the original share used a non-default permission and you skip --permission-arns on the new share, the new share gets the default. This may grant different access than intended.

At Scale

For environments with many shares across multiple regions, script the pattern. The CLI commands above are designed to compose in a loop:

1. get-resource-shares to list active shares
2. list-principals per share to find org-based principals
3. Resource-specific queries to find actual consumers
4. create-resource-share with account-ID principals
5. list-principals on new share to confirm ASSOCIATED
6. delete-resource-share on the original

Pre-Migration Checklist

• [ ] Inventoried all RAM shares with org or OU principals (all regions)
• [ ] Identified actual consuming accounts per share
• [ ] Verified managed permissions on original shares
• [ ] Created replacement account-ID shares with matching permissions
• [ ] Confirmed principals show ASSOCIATED
• [ ] Validated functional access from consuming accounts
• [ ] Confirmed VPC subnet shares allow instance launches
• [ ] Deleted original org-based shares
• [ ] Documented new share ARNs for post-migration reference

Related Resources

• Shared Services Account Migration: Best Practices for AWS Organizations
• Migrating accounts between AWS Organizations from a network perspective
• Update a resource share in AWS RAM
• Enable sharing with AWS Organizations