AWS Organizations間のアカウント移行でRAM共有が外れる理由と共有を維持する設定

Posted at 2026-08-01

概要

AWS Organizations配下のアカウントに対してAWS RAM（Resource Access Manager）でTransit Gatewayを共有している環境で、そのアカウントを別のOrganizationへ移行するとRAM共有が外れます。2026年2月27日、この問題に対応する RetainSharingOnAccountLeaveOrganization パラメータがリリースされました。

本記事では、なぜ共有が外れるのか、このパラメータで何が変わるのかを、実際にOrganizationとTransit Gatewayを作成して挙動を確認します。なお、本記事内では実際に別のOrganizationに移行するまでは検証しておりません。

RAM共有の2つの接続方式

RAMでリソースを共有したとき、コンシューマー側がアクセスを得る経路は2つに分かれます。この違いが、Organization移動時に共有が維持されるかどうかを決めます。マニュアルには次のように記載されています。

共有元のアカウントがAWS Organizationsの組織の一部であり、組織内での共有が有効になっている場合、組織内のプリンシパルには、招待を使用せずにリソース共有へのアクセスが自動的に付与される。組織のコンテキスト外で共有するアカウントのプリンシパルは、リソース共有に参加するための招待を受け取り、招待を受け入れた後にのみ、共有リソースへのアクセス権が付与される。

整理すると次のようになります。

方式	アクセスの根拠	招待の承諾
Organization方式	共有元と同じOrganizationのメンバーであること	不要
外部アカウント方式	そのアカウントIDが個別に許可され、招待を承諾していること	必要

Organization方式では、アクセスの根拠が「Organizationのメンバーであること」です。そのため、アカウントがOrganizationを離脱すると根拠そのものが消滅し、アクセスが失われます。こちらもマニュアルに記載があります。

コンシューマーアカウントが組織を離れると、そのアカウントはリソース共有内のリソースにアクセスできなくなる。この制限は、リソースをOU、組織全体、または組織内の個々のアカウントと共有する場合に適用される。

共有先にアカウントIDを直接指定していても外れます。共有先の指定方法ではなく、招待が発生するかどうかで決まります。

検証環境

リソース	内容
親アカウント（管理アカウント）	111111111111
子アカウント（Organization内）	222222222222
別アカウント（Organization外）	333333333333
Transit Gateway	親アカウントで作成
リージョン	ap-northeast-1

なお下記記載の別の親アカウント（444444444444）は移行先として用意したものですが、今回は使用しません。

検証ステップ

Organizations共有が無効な状態でのRAM共有
Organizations共有の有効化
有効化後のRAM共有作成とexternal属性の確認
招待の有無の確認
RetainSharingOnAccountLeaveOrganization有効の共有作成

Step 1：Organizations共有が無効な状態

親アカウントでOrganizationを作成し、子アカウントを払い出しました。親アカウントでTransit Gatewayを作成し、RAMで子アカウントと別アカウントの両方に共有します。

このとき、コンソールのプリンシパル一覧は次のようになりました。

プリンシパルID	プリンシパルタイプ
222222222222	アカウント (外部)
333333333333	アカウント (外部)

同じOrganizationの子アカウントも「アカウント (外部)」と表示されました。想定と違いますが、これは正しい挙動です。マニュアルに記載があります。

AWS Organizations内での共有を有効にしない場合、組織や組織内のOUとリソースを共有することはできない。ただし、組織内の個別のAWSアカウントとリソースを共有することはできる。この場合、これらのプリンシパルは組織の一部としてではなく、外部アカウントとして扱われる。共有リソースにアクセスするには、リソース共有に参加するための招待を受け取り、それを受け入れる必要がある。

Organizationを作成して子アカウントを払い出しただけでは、RAMの組織内共有は有効になりません。有効化していない状態では、組織内のアカウントも外部アカウントとして扱われます。

Step 2：Organizations共有の有効化

親アカウント（管理アカウント）で有効化します。

$ aws ram enable-sharing-with-aws-organization
{
    "returnValue": true
}

ここで注意点があります。同じ有効化をAWS Organizationsコンソールや enable-aws-service-access コマンドで行うと、サービスにリンクされたロールが作成されず、組織内共有が機能しません。マニュアルにも「AWS RAMコンソールまたは enable-sharing-with-aws-organization コマンドを使用する必要がある」と重要事項として記載されています。

そのため、サービスにリンクされたロールが作成されたことを確認します。

$ aws iam get-role --role-name AWSServiceRoleForResourceAccessManager \
    --query "Role.RoleName" --output text
AWSServiceRoleForResourceAccessManager

このロールは管理ポリシー AWSResourceAccessManagerServiceRolePolicy によって、RAMに組織の情報を取得する権限を付与します。RAMがOrganizationsの構造を参照する必要があることが、この権限の存在からうかがえます。

Step 3：有効化後のRAM共有作成

有効化後に、あらためてリソース共有を作成します。
共有先は子アカウントと別アカウントの2つです。コンソールだと下記設定箇所になりますが、RetainSharingOnAccountLeaveOrganization は指定しません（無効）。

$ aws ram create-resource-share \
    --name "test-ram" \
    --resource-arns "arn:aws:ec2:ap-northeast-1:111111111111:transit-gateway/tgw-xxxxxxxx" \
    --principals 222222222222 333333333333 \
    --allow-external-principals \
    --region ap-northeast-1

--allow-external-principals は、Organization外のプリンシパルを共有先に追加できるようにする設定です。今回は別アカウント（Organization外）を含めるため指定しています。コンソールの「任意のユーザーとの共有を許可する」がこれに対応し、デフォルトで有効です。

プリンシパルの状態を確認します。

$ aws ram get-resource-share-associations \
    --association-type PRINCIPAL \
    --resource-share-arns arn:aws:ram:ap-northeast-1:111111111111:resource-share/xxxxxxxx \
    --region ap-northeast-1 \
    --query "resourceShareAssociations[].{Principal:associatedEntity,External:external,Status:status}" \
    --output table
---------------------------------------------
|       GetResourceShareAssociations        |
+----------+----------------+---------------+
| External |   Principal    |    Status     |
+----------+----------------+---------------+
|  False   |  222222222222  |  ASSOCIATED   |
|  True    |  333333333333  |  ASSOCIATING  |
+----------+----------------+---------------+

コンソールから確認すると下記の表示となります。

1つのリソース共有に2つのプリンシパルを同時に指定しただけですが、状態が異なります。

プリンシパル	External	Status	解釈
子アカウント	False	ASSOCIATED	招待なしで即座にアクセスが成立
別アカウント	True	ASSOCIATING	招待送信済み、承諾待ち

external は、そのプリンシパルがリソース共有を所有するAWSアカウントと同じOrganizationに属しているかを表すフィールドです。値の対応は次のとおりです。

external	意味	コンソール表示
`false`	所有アカウントと同じOrganizationに属している	アカウント
`true`	所有アカウントと同じOrganizationに属していない（外部）	アカウント (外部)

Step 1では両方が true でしたが、Organizations共有を有効化したことで子アカウントが false になりました。

Step 4：招待の有無の確認

3つのアカウントそれぞれで、招待を受け取っているか確認します。

親アカウント（共有の所有者）。

$ aws ram get-resource-share-invitations --region ap-northeast-1
{
    "resourceShareInvitations": []
}

子アカウント（Organization内）。

$ aws ram get-resource-share-invitations --region ap-northeast-1
{
    "resourceShareInvitations": []
}

別アカウント（Organization外）。

$ aws ram get-resource-share-invitations --region ap-northeast-1
{
    "resourceShareInvitations": [
        {
            "resourceShareInvitationArn": "arn:aws:ram:ap-northeast-1:111111111111:resource-share-invitation/xxxxxxxx",
            "resourceShareName": "test-ram",
            "resourceShareArn": "arn:aws:ram:ap-northeast-1:111111111111:resource-share/xxxxxxxx",
            "senderAccountId": "111111111111",
            "receiverAccountId": "333333333333",
            "invitationTimestamp": "2026-07-31T23:20:03.677000+00:00",
            "status": "PENDING"
        }
    ]
}

別アカウントにのみ PENDING の招待が届いていました。子アカウントには招待がありません。コンソールから確認すると下記のようになります。子アカウントは自動的にアクティブになりますが、別アカウントは承諾待ちのステータスになります。

ここまでで、2つの方式の違いがAPIの応答として確認できました。子アカウントは承諾という行為を経ずにアクセスが成立しています。つまりアクセスの根拠はOrganizationのメンバーであることだけです。このことから、Organizationからの離脱によって共有が外れると考えられます。

Step 5：RetainSharingOnAccountLeaveOrganization有効の共有

同じTransit Gatewayを対象に、RetainSharingOnAccountLeaveOrganization を有効にした2つ目のリソース共有を作成します。共有先はStep 3と同じ2アカウントです。

$ aws ram create-resource-share \
    --name "test-ram-retain" \
    --resource-arns "arn:aws:ec2:ap-northeast-1:111111111111:transit-gateway/tgw-xxxxxxxx" \
    --principals 222222222222 333333333333 \
    --allow-external-principals \
    --resource-share-configuration '{"retainSharingOnAccountLeaveOrganization":true}' \
    --region ap-northeast-1

プリンシパルの状態を確認します。

$ aws ram get-resource-share-associations \
    --association-type PRINCIPAL \
    --resource-share-arns arn:aws:ram:ap-northeast-1:111111111111:resource-share/yyyyyyyy \
    --region ap-northeast-1 \
    --query "resourceShareAssociations[].{Principal:associatedEntity,External:external,Status:status}" \
    --output table
---------------------------------------------
|       GetResourceShareAssociations        |
+----------+----------------+---------------+
| External |   Principal    |    Status     |
+----------+----------------+---------------+
|  True    |  222222222222  |  ASSOCIATING  |
|  True    |  333333333333  |  ASSOCIATING  |
+----------+----------------+---------------+

子アカウントが External: True になりました。Organizationのメンバーであるにもかかわらず外部アカウントとして扱われ、ASSOCIATING のまま承諾待ちになっています。子アカウントにも招待が届きます。

What's Newの記述通りの挙動となりました。

有効にすると、RAMは組織のアカウントを外部アカウントとして扱い、明示的な招待の承諾を必要とすることで、組織間のアカウント移動時にリソースへのアクセスを維持する。

同一の子アカウントが、共有の設定によって別の方式で接続されることが確認できました。

共有	Retain設定	子アカウントのexternal	招待
test-ram	無効	False	不要
test-ram-retain	有効	True	必要

まとめ

Organization方式では招待の承諾が発生しない。アクセスはOrganizationのメンバーであることを根拠に自動付与されるため、離脱するとその根拠が失われる
RetainSharingOnAccountLeaveOrganization を有効にすると、組織内のアカウントも external: true として扱われ、招待の承諾が必要になる。アクセスの根拠が承諾に移るため、Organizationへの依存が切れる

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up