AWS Organizations のメンバーアカウントを他の組織へ移行する: Part 1

AWS のお客様は、AWS が提供するホワイトペーパー「Organizing Your AWS Environment Using Multiple Accounts」で定義されているように、マルチアカウントな AWS 環境の基盤として AWS Organizations を使用しています。Organizations は、複数の AWS アカウントを一元的に管理および統制できる AWS のサービスです。AWS アカウントをある組織から新規、または既存の異なる組織に移行しなければならないシナリオがよくあります。たとえば合併や買収において、企業は複数の組織に存在する AWS アカウントを 1 つの組織に統合する必要があります。

3 部構成の本ブログシリーズでは、AWS Organizations のさまざまな機能について順を追って説明し、AWS Organizations を使用する際や、AWS アカウントをある組織から別の組織に移行する際のガイダンスと考慮事項を提供します。組織間で AWS アカウントを移行するには、当該 AWS アカウントを現行の組織から削除し、AWS アカウントをスタンドアロンにしてから、移行先の組織への招待を受け入れる必要があります。AWS アカウントの移行中および移行後は、すべてのワークロードとサービスが引き続き稼働していることを確認する必要があります。

第 1 部 (本ブログ) では、Organizations のある組織から別の組織に AWS アカウントを移行する際に、ガイダンスと考慮が必要な Organizations のさまざまな機能について説明します。本ブログにおいては、Organizations のポリシー、AWS Resource Access Manager (AWS RAM) による共有、および AWS グローバル条件コンテキストキーに焦点を当てます。第 2 部では、AWS サービスの委任された管理者として登録されている AWS アカウントを移行する場合に行うべきこと、確認すべきことについて見ていきます。第 3 部では、AWS サービスに対する信頼されたアクセスが有効化されている組織内の AWS アカウントを移行する場合の行うべきこと、確認すべきことを見ていきます。

Organizations の組織間で AWS アカウントを移行する前に

組織からメンバーアカウントを削除する前に知っておくべきことについては、「AWS Organizations ユーザガイド」の「組織のアカウントを削除する前に考慮する事項」セクションを確認してください。
現在の組織と移行先組織で有効化されている Organizations の機能セットについて、本ブログ中のガイダンスを利用し考慮してください。
移行対象の AWS アカウントに適用されている Organizations のポリシー（承認ポリシー、管理ポリシー）については、本ブログ中のガイダンスを確認してください。
AWS Resource Access Manager (AWS RAM) のリソース共有機能により、移行対象の AWS アカウントが所有または共有されているリソースについては、本ブログ中のガイダンスを確認してください。
AWS アカウント間のイベントの送受信に関する Amazon CloudWatch Events の設定については、本ブログ中のガイダンスを確認してください。
移行対象 AWS アカウントに適用されているグローバル条件キーについては、本ブログ中のガイダンスを確認してください。
移行先組織の AWS Organizations のクォータについては、本ブログ中のガイダンスを確認してください。
組織の管理アカウントについては、本ブログ中のガイダンスを確認してください。
Organizations の委任された管理者をサポートする AWS サービスについては、第 2 部のガイダンスを確認してください。
Organizations の信頼されたアクセスをサポートする AWS サービスについては、第 3 部のガイダンスを確認してください。
移行対象 AWS アカウントに生じる間接的な影響を Organizations ユーザーガイドの「組織のアカウントを削除する前に考慮する事項」の中にある「組織からアカウントを消去した場合の影響」セクションで確認してください。
Organizations ユーザーガイドの「組織からのメンバーアカウントの削除」と「メンバーアカウントから組織を退会する」を確認してください。
Organizations ユーザーガイドの「組織への AWS アカウントの招待」を確認してください。

本ブログには AWS Command Line Interface (AWS CLI) を利用したコマンド実行例を記載します。実行例を利用するには AWS CLI のインストールと設定を行う必要があります。詳細については、「AWS CLI の最新バージョンを使用してインストールまたは更新を行う」を参照してください。

Organizations の機能セット

AWS アカウントを組織間で移行する前に、各組織で有効になっている機能セットを確認してください。Organizations には、組織内の統制を強化する 2 つの機能セットがあります。組織の機能セットが「一括請求」の場合は、AWS アカウントに共有課金機能が提供されます。「すべての機能」の場合は、「一括請求」機能に加えて、AWS アカウントをより細かく制御できる高度な機能が含まれます。有効になっている機能セットを確認することで、移行時に組織間の機能セットの違いを考慮すべきかどうか判断できます。AWS アカウントを「一括請求」が有効になっている組織から「すべての機能」が有効になっている組織に、またはその逆に移行する場合、当該 AWS アカウントを管理できるレベルが変わります。AWS CLI の describe-organization コマンドを使用して、その組織が現在利用できる機能を確認できます。

次の AWS CLI の例では、Organizations の機能セットを含む組織に関する情報を取得します。

PROMPT> aws organizations describe-organization

出力された Organization オブジェクトの「FeatureSet」が「ALL」に設定されている場合、「すべての機能」が有効になっています。「CONSOLIDATED_BILLING」に設定されている場合は、「一括請求」機能のみが利用可能です。

Organizations ポリシー

Organizations のポリシーにより、組織内の AWS アカウントに追加の種類の管理を適用できます。Organizations のポリシーは、機能セットの「すべての機能」が有効になっている場合に使用できます。

AWS アカウントを組織から削除すると、その AWS アカウントは、組織で適用されている承認ポリシーや管理ポリシーの影響を受けなくなります。移行元の組織のポリシーによって課せられているのと同じ制限を AWS アカウントに適用するには、それらのポリシーを特定し、移行先組織に同じポリシーが存在しているかを確認します。必要に応じて移行先組織に同じポリシーを適用したあとに現在の組織から移行します。

承認ポリシー

サービスコントロールポリシー (SCP) は承認ポリシーとして分類され、組織内の AWS アカウントのセキュリティを一元管理する際に役立ちます。SCP の継承とは、Organization root (組織ルート)、組織単位 (OU)、および AWS アカウントに権限を適用できるということです。AWS CLI の list-policies-for-target コマンドを SERVICE_CONTROL_POLICY フィルタとともに利用し、各レベル（組織ルート、OU、および AWS アカウント）で適用されているポリシーを一覧表示することで、AWS アカウントに適用されている SCP を特定できます。

特定した SCP と同じ制限を移行後の AWS アカウントに対しても適用するには、移行先組織で SERVICE_CONTROL_POLICY というポリシータイプを使用して SCP を有効にします。SCP を作成 (存在しない場合) すると、AWS CLI の describe-policy コマンドを使用してポリシーの内容を表示できます。特定した各レベル (組織ルート、OU、または AWS アカウント) に SCP をアタッチします。

SCP が移行先組織にすでに存在している可能性があることを考慮してください。移行する AWS アカウントに適用される SCP と、適用された権限による影響を確認する必要があります。

管理ポリシー

人工知能 (AI) サービスのオプトアウトポリシー、バックアップポリシー、タグポリシーは、管理ポリシーに分類されます。これらは、AWS サービスとその機能を組織内で一元的に設定および管理するのに役立ちます。ポリシーの継承は、管理ポリシータイプと SCP では挙動が異なります。AWS アカウントを移行する前に、有効なポリシーを確認してください。有効なポリシーとは、AWS アカウントが継承するポリシーと、AWS アカウントに直接アタッチされているポリシーを合わせたものを指しています。

AWS CLI の describe-effective-policy コマンドを使用して、AWS アカウントに適用された管理ポリシーを確認します。3 つの管理ポリシータイプそれぞれに対してコマンドを実行します。

次の AWS CLI の例では、ポリシータイプと AWS アカウントの有効なポリシーの内容が返されます。<policy-type> を AISERVICES_OPT_OUT_POLICY、BACKUP_POLICY、または TAG_POLICY のいずれかに、<account-id> は自身の AWS アカウント ID に置き換えてください。

PROMPT> aws organizations describe-effective-policy --policy-type < policy-type > --target-id < account-id >

どのポリシータイプを条件にした場合のコマンド実行結果においても「PolicyContent」が空でない場合は、AWS CLI の list-policies-for-target コマンドを使用して、ポリシーが組織のどのレベルに適用されているかを確認します。

組織からメンバーアカウントを削除すると、既存の AI サービスのオプトアウトポリシー、バックアップポリシー、およびタグポリシーが AWS アカウントから解除されます。

AWS アカウントに対して特定した管理ポリシーを適用するには、移行先組織でポリシータイプを有効にします。移行元組織で適用されたポリシーの内容は、AWS CLI の describe-policy コマンドを使用して表示できます。AWS CLI の create-policy コマンドを使用して、作成するポリシーのタイプを指定し、移行先組織にポリシーを作成できます。作成したポリシーを、AWS CLI の attach-policy コマンドで管理ポリシータイプを指定し、ポリシー用に特定した組織レベルにアタッチします。

AWS アカウントに適用された承認ポリシーまたは管理ポリシーを確認する

この節では、指定されたポリシータイプが適用されている組織ルート、親 OU、AWS アカウントを確認し、AWS アカウントに適用される承認ポリシーまたは管理ポリシーを AWS CLI のコマンドを利用して確認する方法を紹介します。

次の AWS CLI の例では、AWS アカウントに直接アタッチされている、指定されたポリシータイプのポリシーのリストを取得します。<policy-type> を AISERVICES_OPT_OUT_POLICY、BACKUP_POLICY、SERVICE_CONTROL_POLICY、または TAG_POLICY のいずれかに、<account-id> をご自身の AWS アカウント ID に置き換えてください。
```
PROMPT> aws organizations list-policies-for-target --filter < policy-type > --target-id < account-id >
```
次の AWS CLI の例では、AWS アカウントの親 OU を取得します。<account-id> をご自身の AWS アカウント ID に置き換えてください。
```
PROMPT> aws organizations list-parents --child-id < account-id >
```
次の AWS CLI の例では、OU に直接アタッチされている指定されたポリシータイプのポリシーのリストを取得します。<policy-type> を AISERVICES_OPT_OPT_POLICY、BACKUP_POLICY、SERVICE_CONTROL_POLICY、または TAG_POLICY のいずれかに置き換えます。<organization-id> を一つ前のステップで取得した「ORGANIZATIONAL_UNIT」タイプの各「Id」値に置き換えます。すべての OU の Id を確認できるようにコマンドを繰り返し実行します。
```
PROMPT> aws organizations list-policies-for-target --filter < policy-type > --target-id < organization-id >
```
次の AWS CLI の例では、組織ルートのリストを取得します。
```
PROMPT> aws organizations list-roots
```
次の AWS CLI の例では、組織ルートに直接アタッチされている指定されたポリシータイプのポリシーのリストを取得します。<policy-type> を AISERVICES_OPT_OUT_POLICY、BACKUP_POLICY、SERVICE_CONTROL_POLICY、または TAG_POLICY のいずれかに、<root-id> を前のステップで取得した「Id」値に置き換えてください。
```
PROMPT> aws organizations list-policies-for-target --filter < policy-type > --target-id < root-id >
```

AWS RAM リソース共有

AWS Resource Access Manager と AWS Organizations を有効にし、特定の AWS リソースを共有している場合、AWS アカウントは共有リソースの所有者、コンシューマー、またはその両方である可能性があります。AWS RAM のサービスプリンシパルは ram.amazonaws.com です。

AWS アカウントを移行先組織に移行する前に、当該 AWS アカウントが所有している、または当該 AWS アカウントに共有されている AWS RAM リソース共有があるかどうかを確認してください。当該 AWS アカウントがリソースを共有している場合、所有者アカウントとなります。リソースが当該 AWS アカウントに共有されている場合、コンシューマーアカウントとなります。AWS アカウントは所有者およびコンシューマーである可能性があります。

訳者注）AWS RAM はリージョナルサービスであるため、以下 AWS CLI の例については有効化されているすべてのリージョンで実施いただくことを推奨いたします。

次の AWS CLI の例では、自身が所有し、他のユーザーと共有しているリソース共有に関する詳細を取得します。

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

AWS CLI の get-resource-shares コマンドの実行結果にリソース共有が含まれている場合は、AWS CLI の get-resource-share-associations コマンドを使用して、リソース共有に関連づけられているプリンシパルのリストを取得できます。プリンシパルとは、AWS アカウント ID 、組織 ID、OU ID、または AWS Identity and Access Management (IAM) のユーザまたはロールの Amazon Resource Name (ARN) を指しています。

PROMPT> aws ram get-resource-share-associations --association-type PRINCIPAL

リストされているリソース共有にプリンシパルが関連付けられている場合、その AWS アカウントはリソース所有者であり、1 つ以上の AWS アカウントが当該共有リソースのコンシューマーである可能性があります。リストされているプリンシパルが組織または OU の場合は、それらが 1 つ以上のコンシューマーアカウントを持っている可能性があります。移行先組織のコンシューマーアカウントと引き続きリソースを共有するには、所有者アカウントまたは共有リソースを同じ組織に移行します。

AWS アカウントがリソース所有者でない場合は、コンシューマーアカウントである可能性があります。AWS CLI の get-resource-shares コマンドを使用して、当該 AWS アカウントと共有されているリソースの有無を確認できます。コマンド出力には、リソース共有所有者の AWS アカウント ID (owningAccountId) が含まれます。

次の AWS CLI の例では、他のユーザーが所有し、お客様に共有されているリソース共有に関する詳細を取得します。

PROMPT> aws ram get-resource-shares --resource-owner OTHER-ACCOUNTS

組織内の所有者アカウントとコンシューマーアカウント、およびリソース共有の種類を特定することで、移行先組織への移行戦略を計画できます。

所有者アカウントとコンシューマーアカウントの両方を移行先組織に移行する場合は、まずコンシューマーアカウントを移行し、次に所有者アカウントを移行します。所有者アカウントが移行先組織に移行される予定がなく、移行元組織で「すべての機能」が有効化されていない場合、リソース共有は「すべてのユーザーとの共有を許可」で作成されていることになります。この場合、リソース共有を変更せずにコンシューマーアカウントを移行先組織に移行できます。

移行元組織で「すべての機能」が有効化されており、リソース共有を [自分の組織内でのみ共有を許可] に設定している場合は、[すべてのユーザーとの共有を許可] に変更し、リソースを共有する AWS アカウント ID を設定してください。

[すべてのユーザーとの共有を許可] をサポートしていない、すなわち組織の外部プリンシパルとの共有を許可しないリソースの共有を行いたい場合には、組織を同一にする必要があるため、所有者アカウントまたはリソースを移行先組織に移行します。外部プリンシパルとの共有を許可しないリソース共有には、AWS Outposts、Amazon Simple Storage Service (Amazon S3) on Outposts、Amazon Virtual Private Cloud (Amazon VPC) のサブネットなどがあります。[すべてのユーザーとの共有を許可] オプションを使用してリソース共有を作成しようとすると、「The resource you are attempting to share can only be shared within your AWS Organization. This error may also occur if you have not enabled sharing with your AWS organization, or that onboarding process is still in progress.」というメッセージが表示されます。

リソース共有が [自分の組織内でのみ共有を許可] に設定されている場合、コンシューマーアカウントが移行元組織を離れるとコンシューマーアカウント ID プリンシパルは所有者アカウントのリソース共有から自動的に削除されます。コンシューマーアカウントとリソース共有所有者アカウント、またはリソースを移行先組織に移行したのち、移行元組織で行っていたリソース共有を再設定してください。

コンシューマーアカウントが AWS RAM リソース共有から削除されると、その AWS アカウントには共有されたリソースに対する権限がなくなります。ただし、共有リソースを使用して既に起動されている AWS サービスは存続します。たとえば、「サブネット」リソース共有から AWS アカウントを削除しても、起動済みの Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを引き続き再起動および停止できます。

CloudWatch Events

あるアカウントと他のアカウント間でイベントを送受信するように CloudWatch Events を設定している場合は、送信側 AWS アカウントと受信側 AWS アカウントの両方の組織の変更を反映するようにイベントバスの権限を調整します。

AWS グローバル条件コンテキストキー

AWS Identity and Access Management (IAM) では、AWS Organizations の組織の ID を使用して AWS リソースへのアクセスを制御できます。プリンシパルまたはリソースがどの組織に属しているか、プリンシパルまたはアクセスされるリソースの AWS Organizations パスを制御に利用できます。

一部のサービスでは、リソースベースのポリシーを使用して、リソースにアクセスできる AWS アカウントとプリンシパル、およびリソースに対して実行できるアクションを制限します。

プリンシパルが AWS にリクエストを行うと、AWS はそのリクエスト情報をリクエストコンテキストに収集します。JSON ポリシーの Condition 要素を使用して、リクエストコンテキストのキーと、ポリシーで指定したキーの値を比較できます。組織に関連する条件キーである、aws:PrincipalOrgID、aws:PrincipalOrgPaths、aws:ResourceOrgID、aws:ResourceOrgPaths を使用して、リクエストコンテキストに含まれるプリンシパルを検証できます。Condition は IAM ポリシーのオプション要素であり、ポリシーがアクセス権限を付与または拒否する特別な状況を指定できます。Condition には、条件キー、演算子、および条件の値が含まれます。

メンバーアカウントを削除する前に、これらの条件キーを使用している IAM ポリシーを確認し、場合によっては更新する必要があります。ポリシーを更新しない場合、AWS アカウントが組織を離れる際に、その AWS アカウントのユーザーとロールがリソースにアクセスできなくなる可能性があります。aws:PrincipalOrgID 条件キーは単一の値のみをサポートしているので、移行元の組織から AWS アカウントを移行したあとに、移行先組織の ID に更新してください。

aws:PrincipalOrgPaths、aws:ResourceOrgID、aws:ResourceOrgPaths 条件キーは複数の値をサポートしているので、更新により移行元組織と移行先組織の両方を含めることができます。

組織の管理アカウント

組織の管理アカウントを移行する場合は、組織を削除し、管理アカウントをスタンドアロンアカウントにする必要があります。メンバーアカウントをすべて組織から削除したら、Organizations ユーザーガイド内の「組織の削除」の手順に従ってください。

管理アカウントを組織から削除する前に、AWS のコストを詳細に追跡するように設定したコスト配分タグをすべて控えておいてください。移行先組織において、AWS 生成のコスト配分タグと控えておいたユーザー定義のコスト配分タグをすべて適用して有効にします。すべてのタグが請求およびコスト管理コンソールに表示されるまでに最大 24 時間かかる場合があることを考慮してください。

Organizations のクォータ

移行先組織の Organizations のクォータを考慮してください。「組織の AWS アカウント数」について、移行先組織に移行する AWS アカウントの数が増えても問題ないように変更が済んでいることを確認してください。

まとめ

本ブログでは、Organizations のさまざまな機能について説明し、AWS アカウントをある組織から別の組織に移行するために必要なガイダンスと考慮事項について説明しました。承認ポリシーと管理ポリシー、AWS グローバル条件コンテキストキー (aws:PrincipalOrgID、aws:PrincipalOrgPaths、aws:ResourceOrgID、aws:ResourceOrgPaths)、AWS RAM リソース共有など、Organizations の機能を使用している AWS アカウントの移行に関する考慮事項について学習しました。また、有効化されている組織の機能、管理ポリシー、AWS RAM リソース共有を確認する AWS CLI の利用例を見てきました。

本ブログシリーズでは、Organizations のさまざまな機能について説明し、Organizations を使用する場合や、AWS アカウントをある組織から別の組織に移行する際のガイダンスと考慮事項を示します。

第 2 部では、組織の委任された管理者を確認し、AWS サービスの委任された管理者として登録されている AWS アカウントを移行する場合に行うべきこと、確認すべきことに関してご案内します。第 3 部では、組織内で信頼されたアクセスが有効化されている AWS サービスを確認し、AWS アカウントを移行する前に行うべきこと、確認すべきことを特定するお手伝いをします。

ブログ著者について

翻訳は Solutions Architect 北川が担当しました。原文はこちらです。

Amazon Web Services ブログ