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

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

本ブログでは、現在の組織と移行先組織で AWS サービスに対する信頼されたアクセスが有効化されている場合に、当該組織間で AWS アカウントを移行する際に行うべきこと、確認すべきことを見ていきます。

第 1 部と同様に、組織からメンバーアカウントを削除し、 移行先組織で AWS アカウントを招待するための Organizations ユーザーガイドで提供される情報を整理していきます。 組織間でアカウントを移動するには、当該 AWS アカウントを現行の組織から削除し、AWS アカウントをスタンドアロンにしてから、移行先の組織への招待を受け入れる必要があります。 組織からアカウントを削除する前に、組織で AWS サービスに対する信頼されたアクセスが有効化されているかどうかを確認することをお勧めします。

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

AWS Organizations の信頼されたアクセス

互換性のある AWS サービスにおいて信頼されたアクセスを有効化すると、そのサービスは、組織内のすべての AWS アカウントでドキュメントに記載されている操作を実行できます。 AWS アカウントを削除すると、信頼されたサービスはそのアカウントで操作を実行できなくなります。 組織からアカウントを削除して別の組織に移行する前に、信頼されたサービスに関連する AWS アカウントへの影響を理解し、考慮すべきアクションを把握しておく必要があります。

現在、信頼されたアクセスをサポートしている AWS サービスのリストを本ブログに記載しています。AWS サービスの名前またはサービスのプリンシパル名で検索することができます。AWS サービスの名前またはサービスのプリンシパル名で AWS サービスを見つけることができます。サービスのプリンシパル名は、AWS CLI の list-aws-service-access-for-organization コマンドを使用して取得することが可能です。

以下の AWS CLI の例では、お客様の組織において信頼されたアクセスが有効化されている AWS サービスのリストを取得します。

PROMPT> aws organizations list-aws-service-access-for-organization

現在の組織と移行先組織において信頼されたアクセスが有効化された AWS サービスのリストを取得した後、組織間で 1 つ以上のアカウントを移動する場合に必要なアクションを計画することができます。 アカウントを別の組織に移動する際には、信頼されたアクセスが有効になっている AWS サービスと連携するためにアカウントを設定する必要があるかどうかを確認してください。ほとんどの場合、アカウントや AWS サービスを再構成する必要はありません。以下に提示する現在 Organizations の信頼されたアクセスをサポートしている AWS サービスのリストにおいてそのためのガイダンスを提供します。

トでアカウントに代わって自動的に契約を受諾することはできなくなります。削除されたアカウントは、組織によって受諾された AWS Artifact 組織契約にアクセスできなくなり、その対象から外れることになります。管理アカウントは AWS Artifact コンソールの「契約」メニュー内の「組織契約」で組織契約のリストを表示できます。

組織からアカウントを削除する前に、スタンドアロンアカウントや移行先組織で新しい契約を締結する必要があるかを、法務、プライバシー、コンプライアンス等の適切なチームの支援を得て判断してください。移行先組織の複数のアカウントにわたって契約が必要な場合、AWS Artifact で信頼されたアクセスを有効にして、必要な契約を受諾したことを確認してください。

AWS Audit Manager: auditmanager.amazonaws.com

AWS Audit Manager で 信頼されたアクセスを有効にすると、組織内の複数の AWS アカウントを評価の範囲に含めることで、より幅広いソースから証拠を収集することができます。組織からアカウントを削除すると、評価範囲の一部としてそのアカウントから証拠を収集することができなくなります。Audit Manager は、削除に関する通知を受け取り、既存のあらゆる評価の範囲からそのアカウントを自動的に削除します。

アカウントが移行先組織に参加すると、そのアカウントは既存の Audit Manager の評価範囲に自動的には追加されません。既存の評価範囲を見直し、必要に応じてアカウントをリストに追加してください。

AWS CloudFormation StackSets: member.org.stacksets.cloudformation.amazonaws.com

AWS CloudFormation StackSets で 信頼されたアクセスを有効にすると、管理者または委任管理者アカウントは、組織のスタックセットを作成および管理する権限を持っています。組織からアカウントを削除すると、CloudFormation StackSets は、アカウントに関連する権限を持つサービスリンクロールを使用して、そのアカウントにスタックインスタンスをデプロイできなくなります。 アカウント内に StackSet の一部であるスタックがあり、そのスタックを保持したい場合、移行先組織または組織単位（OU）からアカウントを削除するときの StackSet のアカウント削除動作が「スタックを保持」と設定されていることを確認してください。AWS CLI の describe-stack-set コマンドを使用して RetainStacksOnAccountRemoval の値で削除動作を確認します。true に設定されている場合、アカウントが移行先組織または OU から削除されたときにスタックリソースが保持され、false に設定されている場合、スタックリソースは削除されます。

移行先組織の StackSet に引き続きスタックを含める予定の場合、StackSet にスタックをインポートできます。移行先組織では、移行元組織の StackSet に使用されたものと同じテンプレートを使用して新しい StackSet を作成します。StackSet を作成するときは、アカウントが配置される OU を含めるようにします。 アカウントを移行先組織に参加させる前に、StackSet 自動デプロイメントの設定を一時的に無効にしましょう。アカウントが組織に参加した時に、インポート対象と同じ内容のスタックが自動でデプロイされてしまうことを防ぐためです。アカウントが移行先組織に参加すると、作成した StackSet にスタックをインポートできます。 インポート後、アカウント内でスタックにステータス「FAILED」の変更セットが含まれていることに気づくでしょう。これはこのインポートで期待されるステータスであり、「The submitted information didn’t contain changes. Submit different information to create a change set」という理由が添えられています。移行先組織の StackSet に参加してもスタックがすでに存在していたためデプロイされず、その後の変更も必要ないためスタックはデプロイされません。

AWS CloudTrail: cloudtrail.amazonaws.com

AWS CloudTrail の 信頼されたアクセスを有効にすると、その組織内のすべての AWS アカウントのすべてのイベントを記録する組織の証跡を作成できます。組織からアカウントを削除すると、組織の証跡には該当アカウントのイベントが保存されなくなります。そのため、組織から離れる前にアカウントの証跡をセットアップし、イベントのログを取得できるようにします。移行先組織で組織の証跡が有効になっている場合は、イベントは自動的に組織の証跡に含まれるようになるため、移行先組織に参加した後にアカウントでセットアップした証跡を削除することを検討してください。

AWS Compute Optimizer：compute-optimizer.amazonaws.com

AWS Compute Optimizer の 信頼されたアクセスを有効にすると、組織の Compute Optimizer の推奨事項にアクセスし管理することができます。組織からアカウントを削除すると、Compute Optimizer は管理者または委任管理者アカウントから、そのアカウントの推奨事項にアクセスまたは管理できなくなります。アカウントのオプトインのステータスは、組織の一部であったときの設定が保持されます。 アカウントが移行先組織に参加すると、移行先組織の管理者または委任管理者アカウントの Compute Optimizer は、そのアカウントの推奨事項にアクセスし管理することができます。

AWS Config：config.amazonaws.com

AWS Config の信頼されたアクセスを有効にすると、Config アグリゲータは組織内のアカウントから Config 設定データとコンプライアンスデータを収集できます。組織からアカウントを削除すると、そのアカウントが組織アグリゲータの一部である場合、アグリゲータはそのアカウントから Config 設定データとコンプライアンスデータを収集できなくなります。データは削除される前にアグリゲータアカウントに最大 24 時間保持されます。アカウントに展開された Config ルールやコンフォーマンスパックは削除されます。 AWS Config では、個別アカウントアグリゲータを作成し、1 つ以上のアカウントから Config 設定データおよびコンプライアンスデータを収集する権限をアカウントに付与することができます。 当該権限が付与された AWS アカウントを組織から削除しても、他のアカウントから Config 設定データおよびコンプライアンスデータを収集する権限は変更されません。

アカウントが移行先組織に参加すると、既存の Config 組織アグリゲータに含まれるように、アカウントで Config を有効にする必要があります。アカウントが既存の組織の Config ルールおよびコンフォーマンスパックと連携するためには、Config 設定レコーダが有効になっていることを確認する必要があります。 既存の組織ルールおよびコンフォーマンスパックの展開は、レコーダが使用できない場合、アカウントが移行先組織に追加されてから 7 時間だけ再試行されます。

AWS Control Tower：controltower.amazonaws.com

アカウントが AWS Control Tower に登録されている場合、組織からアカウントを削除する前に、Account Factory から該当アカウントの管理を解除するか、Account Factory for Terraform（AFT）からアカウントを削除してください。

アカウントがスタンドアロンで組織の一部でなくなっている間に、IAM ロール AWSControlTowerExecution の信頼関係を更新します。ロールの信頼ポリシーのプリンシパルを移行先組織の管理アカウント ID に変更する必要があります。 アカウントが移行先組織に参加し、AWS Control Tower にアカウントを登録する場合、既存の AWS アカウントを AWS Control Tower に登録するプロセスに従ってください。

Amazon Detective：detective.amazonaws.com

Amazon Detective で 信頼されたアクセスを有効にすると、組織動作グラフは、組織内のすべてのアカウントのアクティビティを可視化することができます。 組織から削除するアカウントが組織動作グラフのメンバーである場合、そのアカウントはグラフのメンバーとしても削除されます。これは、組織に参加する前に組織動作グラフに招待を受けた場合および組織に参加した後にグラフのメンバーになった場合、いずれの場合も対象となります。招待によってグラフに追加されたアカウントの場合は、そのアカウントがグラフのメンバーであり続けることも、グラフのアカウントメンバーシップを無効にすることも選択することができます。組織動作グラフのメンバーを確認するには、AWS CLI の list-members コマンドを使用してメンバーの一覧を取得したり、組織動作グラフの Amazon リソース名（ARN）を取得するために AWS CLI の list-graphs コマンドを使用できます。どちらのコマンドも、組織の管理アカウントまたは Detective の委任管理者アカウントの資格情報のいずれかを使用する必要があります。

アカウントがグラフのメンバーから削除されると、Detective はデータの取り込みを停止しますが、アカウントから取得した既存のデータはグラフに残ります。 招待による別の組織のグラフへのメンバーシップは、組織に参加または離脱しても影響を受けません。たとえば、アカウントが移行先組織のグラフのメンバーである場合、移行元組織を離れると、そのアカウントは移行元組織のグラフのメンバーではなくなりますが、移行先組織のグラフのメンバーのままとなります。組織からアカウントを削除する際、Detective がアカウントで有効になっている場合、Detective は有効なままで、アカウントの動作グラフの内容と設定はすべて保持されます。 組織間の移動中に組織からアカウントの可視性を保持するには、組織からアカウントを削除する前に、移行先組織のグラフに招待によってアカウントをメンバーとして追加することを検討します。アカウントが動作グラフのメンバーになると、初回の抽出の場合、データは通常 24 時間以内にグラフで利用可能になります。

移行先組織において Detective が新しい組織のアカウントを組織動作グラフのメンバーアカウントとして自動的に有効化にするように構成されている場合、アカウントが組織に参加するとアカウントは「By organization」グラフの有効なメンバーとなります。アカウントが招待によってグラフのメンバーだった場合、アカウントのメンバーシップは保持され、メンバーシップの種類は「By invitation」から「By organization」に変更されます。 アカウントが組織グラフのメンバーとして設定されていない場合、グラフにアカウントを招待することができ、同じ組織の一部であればアカウントは自動的に招待を受け入れます。

Amazon DevOps Guru: devops-guru.amazonaws.com

Amazon DevOps Guru の 信頼されたアクセスを有効にすると、組織全体にわたってインサイトを管理することができます。アカウントが組織を離れ、そのアカウントで DevOps Guru が有効にされている場合、組織の管理アカウントまたは DevOps Guru 委任管理者は、アカウント内のすべての監視対象アプリケーションの健全性に関する全体的なビューを作成するために、アカウントからのインサイトを表示、並べ替え、フィルタリングすることができなくなります。

アカウントが移行先組織に参加し、アカウントで DevOps Guru が有効にされている場合、管理アカウントまたは DevOps Guru 委任管理者は、自動的にアカウントを組織で監視する対象に含めます。

AWS Directory Service：ds.amazonaws.com

AWS Directory Service の信頼されたアクセスを有効にすると、AWS Managed Microsoft Active Directory（AD）ディレクトリを複数のアカウントでシームレスに共有することができます。1 つのディレクトリを同じ組織内の他の信頼済み AWS アカウントと共有したり、組織外の他の AWS アカウントとディレクトリを共有したりできます。 AWS Organizations またはハンドシェイクのいずれの共有方法でもディレクトリの利用者であるアカウントが組織から削除された場合、ディレクトリは引き続きそのアカウントと共有されています。

アカウントが、1 つ以上の AWS Managed Microsoft AD ディレクトリを持つ移行先組織に参加するとき、ディレクトリは自動的にアカウントと共有されません。AWS Directory Services コンソールまたは AWS CLI の share-directory コマンドのいずれかを使用して、アカウントとディレクトリを共有することができます。

AWS Firewall Manager：fms.amazonaws.com

AWS Firewall Manager の信頼されたアクセスを有効にすると、Firewall Manager 管理者アカウントを使用して、AWS Organizations 内のすべての Firewall Manager セキュリティポリシーを管理することができます。アカウントが組織を離れると、Firewall Manager はアカウント内でサポートされている操作を実行できなくなります。 アカウントが Firewall Manager ポリシーの範囲内にあった場合、アカウントはポリシーと関連付けられなくなり、Firewall Manager 管理者アカウントにコンプライアンスステータスが表示されなくなります。

組織からアカウントを削除する前に、Firewall Manager のポリシーの範囲がアカウント内のリソースや保護を保持するように構成されていることの確認をお勧めします。アカウントが組織から離れると、ポリシーの範囲から離れ、管理されなくなりますが、Firewall Manager が自動的に保護を削除したり、Firewall Manager が管理するリソースを削除しないように設定することができます。 このオプションは「 Resource cleanup 」で設定を行いますが、保護を保持するためには「 Automatically remove protections from resources that leave the policy scope. 」を無効にする必要があります。このオプションは、DNS Firewall、Network Firewall、セキュリティグループ（共通）、WAF などのサポートするポリシータイプで Firewall Manager コンソールから確認できます。 ポリシータイプ WAF Classic、および Shield Advanced には、このオプションはありません。デフォルトでは、リソースに関連付けられている WAF の Web ACL は保持され、リソースを含まない Web ACL は削除されます。

アカウントで Shield Advanced ポリシーが有効化されている場合、そのアカウントが組織を離れると、そのアカウントは Shield Advanced 用に構成された Firewall Manager ポリシーの対象外となります。アカウントで Shield Advanced をサブスクライブしている場合、スコープ内のリソースは引き続き保護されます。組織を離れた後、アカウントは組織の一括請求の対象外となり、Shield Advanced のサブスクリプション料金の日割り料金がアカウントで引き続き発生します。移行元組織のサブスクリプション料金を引き続き支払い、アカウントが移行先組織に参加したときには新規または既存のサブスクリプション料金を支払うことになります。移行元組織を削除する予定がある場合、AWS サポートケースを作成して、移行先組織において Shield Advanced サブスクリプションを統合することができます。

Network Firewall または DNS Firewall ポリシーが設定されている場合、Firewall Manager は AWS Resource Access Manager (AWS RAM) を使用して Network Firewall および DNS Firewall ポリシーで設定されたルールグループを組織全体のアカウントと共有します。 アカウントが組織を離れると、ポリシーで設定したルールグループはそのアカウントと共有されなくなります。Network Firewall または DNS Firewall のポリシー範囲の設定における「 Resource cleanup 」オプションで「 Automatically remove protections from resources that leave the policy scope. 」が無効に設定されている場合、ポリシールールグループの ID と設定は、AWS Network Firewall または Amazon Virtual Private Cloud (VPC) のいずれかの対応するリソースに関連付けられたままとなります。ただし、AWS RAM 共有とアカウントとの関連付けが解除されると、ルールグループを表示する権限が削除されるため、アカウントでルールグループを表示することはできなくなります。

アカウントを移行先組織に移動する前に、移動元組織で特定した各ポリシータイプごとに、移動するアカウントに適用される同等の Firewall Manager ポリシーが作成または更新されていることを確認してください。移行先組織では、WAF および WAF Classic ポリシータイプを設定して、ポリシーの範囲内のリソースに現在関連付けられている既存の Web ACL を置き換えるポリシーアクションを使用することができます。このオプションを使用して移行元組織のポリシーによって適用された Web ACL を置き換えることができます。既存の関連づけられた Web ACL を置き換えることを選択した場合、Firewall Manager は別のアクティブな Firewall Manager ポリシーによって管理されていない Web ACL をポリシーの範囲内のリソースから関連付け解除します。DNS Firewall ポリシー タイプを設定する場合、ルールグループの優先度を移行元組織のポリシーと異なるように設定します。ルールグループの優先度が一致している場合、ルールの優先度が競合するため、移行先組織ポリシーをアカウント内の Amazon VPC に適用することはできません。

移動するアカウントにおいて、移行元と移行先組織のポリシーで作成されたリソースと保護を受け入れるための AWS サービスのクォータを確認する必要もあります。 移行元組織によってアカウントに設定されている現在のポリシー適用リソースや保護の現在の数の少なくとも 2 倍を許容するために、リージョンごとにアカウントの調整可能なクォータを一時的に増やすことを計画します。そのためにはアカウントの現在の使用状況を考慮する必要があり、それには、Network Firewall（調整可能なクォータ）、Amazon VPC（サブネットのクォータ）、セキュリティグループ（AWS リージョンごとの VPC セキュリティグループとネットワークインターフェースごとのセキュリティグループのクォータ）、WAF（Web ACL とルールグループのクォータ）、WAF Classic（Web ACL とルールグループのクォータ）、Shield Advanced（調整可能なクォータ）、Route 53 Resolver DNS Firewall （調整可能なクォータ）などの AWS サービスが含まれます。クォータの増加により、移行元組織のポリシーで作成された既存のリソースや保護、および移行先組織のポリシーで新たに作成されたリソースや保護が共存できるようになります。

移行元組織のポリシー範囲の設定で「 Resource cleanup 」オプションで「 Automatically remove protections from resources that leave the policy scope. 」を無効に設定した場合、移行元組織のポリシーにより作成されたリソースと保護は組織から離脱後も残ります。移行元組織のポリシーによって作成されたリソースが、移行先組織で適用されるポリシーで再利用されることはありません。 アカウントを移行元組織に再度参加させ、Firewall Manager 委任管理者となり、アカウントが移行元組織を離れてから Firewall Manager のポリシーが変更されていない場合、そのポリシーはアカウントが以前組織に所属していたときに作成された既存のリソースを再利用します。

移行先組織のポリシーが移行元組織によって提供されたポリシーリソース構成を複製する場合、移行元組織のポリシーによって作成されたリソースまたは関連する保護を削除することを選択できます。移行元組織のポリシーによって作成されたリソースや保護を発見するには、ポリシーの適用範囲となっているリージョンで、ポリシータイプに適用可能なリソースや保護を確認する必要があります。Firewall Manager ポリシーによって作成されたリソースは、各ポリシータイプごとに特定の命名規則を使用します。これにはプレフィックス「 FMManaged 」が含まれ、ポリシータイプに応じてポリシー名またはポリシー ID、またはその両方を含むことがあります。 ポリシー名 (PolicyName) とポリシー ID (PolicyId) などのポリシーメタデータは、移行元組織の Firewall Manager 管理者アカウントで AWS CLI の list-policies コマンドを使用してポリシーをリストアップし確認することができます。

移行元組織の Firewall Manager ポリシーによって作成されたリソースや保護を削除する前に、同等の移行先組織のポリシーがアカウントに適用されていることを確認してください。ポリシーが移行元組織のセキュリティ設定と一致し、アカウントの Firewall Manager ポリシーの準拠ステータスが「 Compliant 」であることを確認してください。これは、ポリシー範囲に該当するアカウントのすべてのリソースにポリシーが正常に適用されていることを意味します。AWS CLI の list-compliance-status コマンドを使用して、指定したポリシーによって保護されているメンバーアカウントとその準拠ステータスの概要を取得できます。 アカウントが移行元組織の Firewall Manager 管理者の管理下から完全に解除され、移行先組織の Firewall Manager 管理者によって完全に管理されるまで最大 5 時間かかる場合があります。

ポリシーによって作成されたリソースや保護の関連付けを識別するために、サポートされているポリシータイプごとに、ポリシーによって作成されたリソースの命名規則と、アカウント内の適用可能なリソースや関連付けのリストを取得するための AWS CLI コマンドを以下にリストアップしました。

AWS Network Firewall ポリシータイプ

ポリシーによって、FMManagedNetworkFirewall<policy-name><policy-id><vpc-id>の命名規則でファイアウォールが作成されます。<policy-name>、<policy-id>を移行元組織の AWS Network Firewall タイプのポリシーのポリシー名とポリシー ID に置き換えます。アカウント内のファイアウォールの情報は AWS CLI の list-firewalls コマンドを使用して取得できます。

ファイアウォールポリシーは FMManagedNetworkFirewallPolicy<policy-name><policy-id><vpc-id>の命名規則でポリシーによって作成されます。移行元組織の AWS Network Firewall タイプのポリシーのポリシー名とポリシー ID で<policy-name>、<policy-id>を置き換えます。AWS CLI の list-firewall-policies コマンドを使用して、ファイアウォールポリシーの情報を取得できます。AWS Network Firewall ポリシータイプが適用されると、設定されている場合 Network Firewall が使用する VPC エンドポイントを含む Amazon VPC のサブネットが作成されます。サブネットは、AWSFirewallManagerManagedResource を含む命名規則で作成されます。AWS CLI の describe-firewall コマンドを使用して、Network Firewall に関連付けられた 1 つ以上のサブネットを含むファイアウォールの情報を取得することができます。

WAF ポリシータイプ

WAF Web ACL は、FMManagedWebACLV2-<policy-name> の命名規則でポリシーによって作成されます。<policy-name>を移行元組織の WAF タイプのポリシーのポリシー名に置き換えます。AWS CLI の list-web-acls コマンドを使用して、アカウント内の WAF Web ACL を取得することができます。

WAF Classic ポリシータイプ

WAF Classic Web ACL は、FMManagedWebACL<policy-id>の命名規則でポリシーによって作成されます。<policy-id> を移行元組織の WAF Classic タイプのポリシーのポリシー ID に置き換えます。AWS CLI の list-web-acls コマンドを使用して、アカウント内の WAF Classic Web ACL を取得することができます。

Security group – common ポリシータイプ

セキュリティグループは、FMManagedSecurityGroup<policy-id><security-group-id><vpc-id> の命名規則でポリシーによって作成されます。<policy-id> を移行元組織の Security group – common タイプのポリシーのポリシー ID に置き換えます。AWS CLI の describe-security-groups コマンドを使用して、アカウント内のセキュリティグループを取得することができます。セキュリティグループを削除する前に、リソースからセキュリティグループの関連付けを解除しておく必要があります。

Shield Advanced ポリシータイプ

Shield Advanced の保護は、FMManagedShieldProtection<policy-id> の命名規則でポリシーによって作成されます。<policy-id> を移行元組織の Shield Advanced タイプのポリシーのポリシー ID に置き換えます。AWS CLI の list-protections コマンドを使用して、アカウント内の保護を取得することができます。

DNS Firewall ポリシータイプ

ポリシーに関連する DNS Firewall ルールグループは AWS RAM を使用して共有されており、アカウントが組織から離脱する際に削除されます。AWS CLI の list-firewall-rule-group-associations コマンドを使用して Amazon VPC との DNS Firewall ルールグループの関連付けをリストアップすることにより、移行元組織の DNS Firewall ルールグループを特定できます。DNS Firewall ルールグループの CreatorRequestId を移行元組織の DNS Firewall ポリシーのポリシー ID と照合します。その後、発見した DNS Firewall グループの関連 ID を使用し、AWS CLI の disassociate-firewall-rule-group コマンドで移行元組織のルールグループとの関連付けを解除できます。

Amazon GuardDuty：guardduty.amazonaws.com

Amazon GuardDuty の信頼されたアクセスを有効にすると、AWS Organizations を使用して組織内のすべてのアカウントの GuardDuty を管理することにより管理を簡素化することができます。GuardDuty 管理者に関連付けられたアカウントが組織を離れると、関連付けられた各リージョンの管理者から自動的に関連付けが解除されます。GuardDuty 管理者アカウントはもうそれらのアカウントを管理できませんが、各アカウントの GuardDuty のステータスは管理者によって設定されたままとなります。また、各アカウントの GuardDuty の調査結果や使用データは、GuardDuty 管理者アカウントには含まれなくなります。

アカウントが移行先組織に参加する場合、組織の GuardDuty を有効にし、GuardDuty の自動有効化機能を設定した各リージョンで、アカウントは自動的に GuardDuty 管理者のメンバーアカウントとして関連付けられます。アカウントで GuardDuty が有効になり、ソースの設定および S3 Protection や Kubernetes Audit Logs Monitoring のオプションが設定されます。アカウントがメンバーアカウントとして関連付けられていない場合、GuardDuty コンソールや AWS CLI の create-members コマンドを使用して、必要な各リージョンにおいて管理者アカウントから手動でメンバーアカウントとして追加することができます。

追加されたアカウントにおいて AWS CLI の get-administrator-account コマンドを使用し、アカウントの GuardDuty 管理者アカウントの詳細を確認したり、AWS CLI の list-detectors コマンドを使用して GuardDuty の Finding ID を見つけることができます。アカウントがリージョンにおける管理者と関連付けられていない場合、コマンドの出力には管理者のアカウント ID や関連のステータスが「有効」として表示されません。

AWS Health：health.amazonaws.com

AWS Health の信頼されたアクセスを有効にすると、組織内のすべてのアカウントで AWS Health のイベントを集約できます。Health の組織ビューを設定している場合、アカウントが組織を離れると、アカウントからの新しいイベントは組織ビューに含まれなくなります。ただし既存のイベントは 90 日の制限まで照会できるように、組織ビューに残ります。アカウントが移行先組織に参加すると、アカウントからのイベントは有効な Health の組織ビューに含まれるようになります。

AWS IAM Access Analyzer：access-analyzer.amazonaws.com

AWS Identity and Access Management Access Analyzer (IAM Access Analyzer) の 信頼されたアクセス を有効にしている場合、組織全体でリソースベースのポリシーを分析し、信頼ゾーン外のプリンシパルへのアクセスを許可するポリシーを特定できます。アカウントが IAM Access Analyzer の組織における信頼ゾーンの一部である場合、組織を離れると、組織の信頼ゾーンでの調査結果は生成されなくなります。組織の移行中、信頼ゾーンとしてスタンドアロンのアカウントを使用してアナライザーを作成することもできます。アカウントが移行先組織に参加すると、組織を信頼ゾーンとして設定したアナライザーが既に作成されている場合、アカウントは分析されるリソースのセットに含まれます。

AWS IAM Identity Center（AWS Single Sign-On の後継）： sso.amazonaws.com

AWS IAM Identity Center（AWS Single Sign-On の後継）の信頼されたアクセスを有効にすると、ユーザーがシングルサインオン (SSO) で AWS アカウントやクラウドアプリケーションにアクセスする複数の AWS アカウントを選択できます。アカウントが組織を離れると、IAM Identity Center の使用可能なアカウントのリストに含まれなくなり、共通の権限セットをデプロイしたり、管理アカウントまたは委任管理者アカウントからアクセスを管理することができなくなります。IAM Identity Center は、アカウント内の IAM Identity Center のサービスリンクロールを含むアカウントのメタデータやリソースを自動的にクリーンアップします。アカウントは IAM Identity Center とは連携しなくなり、設定されたアイデンティティソース用の AWS アクセスポータルを使用してアカウントにアクセスすることはできなくなります。

アカウントが移行先組織に参加する場合、アカウントの IAM Identity Center でユーザーやグループに対して必要な権限や割り当てを設定する必要があります。

Amazon Inspector：inspector2.amazonaws.com

Amazon Inspector の信頼されたアクセスを有効にすると、組織でアカウントを管理し、組織を代表してタスクを実行することができます。このタスクには、メンバーアカウントのスキャンの有効化または無効化、組織全体で集約された検出結果データの表示、抑制ルールの作成と管理が含まれます。Inspector 管理者に関連付けられたアカウントが組織を離れると、関連付けられた各リージョンの管理者から自動的に関連付けが解除されます。Inspector の管理者アカウントは、アカウントを管理することはできなくなりますが、スキャン設定を含むアカウント内の Inspector のステータスは、管理者によって設定されたままとなります。アカウントの Inspector の検出結果は、Inspector の管理者アカウントには含まれなくなります。

アカウントが移行先組織に参加する場合、組織で Inspector を有効にしてスキャンの自動有効化を設定している各リージョンごとに、アカウントは自動的に Inspector のメンバーアカウントとして関連付けられます。アカウントで Inspector が有効になり、設定されていれば、EC2 のスキャンや ECR のコンテナのスキャンの有効化を含む選択されたスキャンの設定が適用されます。アカウントが関連付けられていない場合、管理者アカウントと各リージョンで Inspector のコンソールや AWS CLI の associate-member コマンドを使用して手動でメンバーアカウントとして登録することができます。追加されたアカウントの権限を使用して、AWS CLI の get-delegated-admin-account コマンドを使用してアカウントに関連づけられた Inspector の管理者アカウントの詳細を確認することができます。アカウントがリージョンの管理者に関連付けられていない場合、コマンドの出力は管理者のアカウント ID や「有効」という関係ステータスを表示しません。

AWS License Manager : license-manager.amazonaws.com , license-manager.member-account.amazonaws.com

AWS License Manager の信頼されたアクセスを有効にすると、組織全体でのライセンス使用とリソース検出を管理するために、クロスアカウントのリソース検出を有効にできます。

アカウントが組織を離れると、License Manager はアカウントのライセンス使用を管理するためのリソース検出を行うことができなくなります。License Manager のセルフマネージドライセンスをアカウントと共有している場合、License Manager によって設定された AWS Resource Access Manager（AWS RAM）の共有は、自動的にアカウントから解除されます。セルフマネージドライセンスは、当該アカウントと共有されなくなります。必要に応じて、License Manager による AWS RAM 共有の設定を変更し、削除されたアカウントを追加してセルフマネージドライセンスの共有を継続することができますが、削除されたアカウントで License Manager の共有の招待を受け入れる必要があります。

アカウントが移行先組織に参加する場合、組織の全アカウントのライセンス使用を管理するために、License Manager のクロスアカウントのリソース検出を有効にした各 AWS リージョンで、アカウントは自動的にリソース検出の範囲に含まれます。組織でセルフマネージドライセンスを共有しており移行したアカウントと共有したい場合、アカウントを含めるために License Manager による AWS RAM 共有の設定を変更する必要があるかもしれません。アカウントは組織のメンバーとして、License Manager の AWS RAM 共有に参加する招待を自動的に受け入れます。このブログシリーズの第 1 部では、オーナーアカウントとコンシューマーアカウントの両方で、組織間の移動時の考慮事項と AWS RAM リソース共有について取り上げています。本ブログでは AWS Marketplace セクションで、License Manager を使用して組織とライセンス許諾を配布する方法についても取り上げています。

Amazon Macie：macie.amazonaws.com

Amazon Macie の信頼されたアクセスを有効にすると、組織内のアカウントの Macie を有効化し集中管理することができます。Macie 管理者として関連づけられたアカウントが組織を離れると、各 AWS リージョンにおいて管理者から自動的に関連付けが解除されます。また、Macie 管理者アカウントは、アカウントの管理を行ったり、特定の Macie の設定、データ、リソースにアクセスすることはできなくなります。アカウントの Macie のステータスは、管理者によって以前に設定されたまま保持されます。アカウントの Macie サマリーと所見は、Macie 管理者アカウントには含まれなくなります。

アカウントが移行先組織に参加する場合、組織の Macie を有効にし、自動有効化を設定した各 AWS リージョンで、Macie はアカウントで有効になり、自動的に Macie 管理者メンバーアカウントとして関連付けられます。アカウントが関連付けられていない場合、管理者アカウントで必要な各 AWS リージョンを使用し、Macie コンソールまたは AWS CLI の create-member コマンドを使用して手動でメンバーアカウントとして追加できます。

追加されたアカウントの権限で AWS CLI の get-administrator-account コマンドを使用し、Macie 管理者アカウントの詳細を確認できます。アカウントが AWS リージョンの管理者と関連付けられていない場合、コマンドの出力には管理者のアカウント ID やステータス「Enabled」は含まれません。

AWS Marketplace : license-management.marketplace.amazonaws.com

AWS Marketplace の信頼されたアクセスを有効にすると、 Marketplace 製品サブスクリプションの付与されたライセンスを組織のメンバーアカウント間で配布することができます。Marketplace の付与されたライセンスは、使用権、つまりエンタイトルメントを配布するために AWS License Manager を使用して組織と共有されます。

アカウントが組織を離れる際、そのアカウントが License Manager で共有された Marketplace 製品から付与されたライセンスエンタイトルメントの受領者である場合、そのエンタイトルメントはアカウントで利用できなくなります。関連する Marketplace サブスクリプションは、組織を離れたアカウントで製品を起動するために使用することはできなくなります。組織または組織単位 (OU) の一部としてアカウントにライセンスが配布された場合、そのアカウントのライセンス付与ステータスは「削除済み」 (付与者によって削除) と表示されます。個々のアカウント ID を使用して配布された場合は、ライセンス付与ステータスは「無効」（使用するためにアクティブ化されていない）と表示されます。サブスクリプションを使用して起動した製品は、Amazon Machine Image（AMI）、コンテナ、機械学習、データ製品に関連する AWS リソースを含めアカウントに残ります。

アカウントが移行先組織に参加すると、License Manager の共有エンタイトルメントが配布され、組織または OU の Marketplace 製品の使用権がアカウントに設定されます。組織の一部として、付与は自動的に受け入れられ、アカウントによって使用されるためにアクティブ化されます。

Marketplace 製品のサブスクライバーアカウントを移行先組織に移動し、License Manager を使用して組織のメンバーアカウントにエンタイトルメントを配布している場合、受領者アカウントが組織から削除されると、ライセンスは受領者アカウントに配布されなくなります。受領者アカウントでライセンスを使用できる能力を示すグラントステータスは「無効」（使用のためにアクティブ化されていない）と表示されます。サブスクライバーと同じ移行先組織にグラントの受領者アカウントを移動する場合、まず受領者アカウントで License Manager を使用してサブスクライバーアカウントからのグラントステータスを確認します。グラントステータスが「無効」であれば、ライセンスをアクティブ化することを選択できます。グラントステータスが「削除済み」であれば、グラントの受領者アカウントに付与するためにサブスクライバーアカウントで新たなグラントを作成することができます。

移行先組織に移動するアカウントが License Manager 委任管理者アカウントである場合、そのアカウントが組織を離れる前に License Manager の委任管理者を解除する必要があります。委任管理者を解除すると、アカウント間のリソース検出とライセンス管理は削除されます。アカウントが Marketplace のサブスクライバーアカウントで、License Manager のグラントを使用して組織、OU、または個々のアカウントにエンタイトルメントを配布している場合、受領者アカウントのグラントステータスは「無効」（使用するためにアクティブ化されていない）と表示されます。アカウントが移行先組織に参加し、License Manager の委任管理者が設定されていない場合、そのアカウントを委任管理者として登録することを選択できます。アカウントを登録すると、組織全体、OU または個々のアカウントに Marketplace ライセンスのエンタイトルメントを配布するためのグラントを作成できます。アカウントを委任管理者に登録しない場合は、組織内の必要な個々のアカウントに対して 1 つ以上のグラントを作成できます。

AWS Network Manager：networkmanager.amazonaws.com

AWS Network Manager の 信頼されたアクセスを有効にすると、任意の AWS アカウントに対して単一のグローバルネットワークを作成し、1 つまたは複数のアカウントから 1 つ以上の AWS Transit Gateway を登録することができます。アカウントが組織を離れると、Network Manager はそのアカウント内のネットワークリソースを一元的に管理、監視、可視化することができなくなります。Network Manager のグローバルネットワークから登録された Transit Gateway は、登録解除されます。Transit Gateway アタッチメント（ VPC、VPN 接続、AWS Direct Connect Gateway など）は、グローバルネットワークに含まれなくなります。

アカウントが移行先組織に参加する場合、Network Manager のグローバルネットワークにアカウントが保持する 1 つまたは複数の Transit Gateway を含めるには、各 Transit Gateway を登録する必要があります。

AWS Security Hub：securityhub.amazonaws.com

AWS Security Hub の 信頼されたアクセスを有効にすると、組織のすべてのアカウントで自動的に Security Hub を有効にし、Security Hub のチェックと検出結果の対象範囲を拡大することができます。Security Hub 管理者に関連付けられているアカウントが組織を離れると、それぞれの AWS リージョンで管理者から自動的に関連づけが解除されます。 Security Hub 管理者アカウントは組織を離れたアカウントを管理できなくなりますが、有効にされた標準やコントロールは管理者が以前に設定したままとなります。アカウントの Security Hub 検出結果やデータは、Security Hub 管理者アカウントに含まれなくなります。

アカウントが移行先組織に参加すると、その組織で Security Hub を有効にし、自動有効化を設定した各 AWS リージョンについて、そのアカウントは自動的に Security Hub 管理者のメンバーアカウントとして関連付けられます。Security Hub はアカウントで有効にされ、設定されている場合は選択された標準とコントロールが有効になります。メンバーアカウントとして関連付けられていない場合は、必要な各 AWS リージョンについて、管理者アカウントの Security Hub コンソールを使用して、手動でメンバーアカウントとして追加することができます。

参加したアカウントの認証情報で AWS CLI の get-administrator-account コマンドを使用して、アカウントの Security Hub 管理者アカウントの詳細を確認できます。 アカウントが AWS リージョンの管理者と関連付けられていない場合、コマンドの出力には管理者のアカウント ID やメンバーステータス「 Enabled 」は含まれません。

Amazon S3 Storage Lens: storage-lens.s3.amazonaws.com

Amazon S3 Storage Lens の 信頼されたアクセスを有効にすると、組織内のすべての AWS アカウントでストレージ、使用状況、アクティビティのメトリクスを収集および分析できます。 アカウントが組織を離れると、組織のスコープで作成したダッシュボードはそのアカウントからのデータは更新されなくなりますが、Amazon S3 Storage Lens の保持期間に従って過去のデータが参照可能です。アカウントのデフォルトダッシュボードは、アカウントのデータによって引き続き更新されます。

アカウントが移行先組織に参加すると、ダッシュボードのスコープに組織内の全アカウントが含まれる場合、そのアカウントは自動的に S3 Storage Lens ダッシュボードに含まれるようになります。

AWS Service Catalog：servicecatalog.amazonaws.com

AWS Service Catalog の 信頼されたアクセスを有効にすると、組織全体でポートフォリオの共有や製品のコピーを簡単に行うことができます。 移行元組織で Service Catalog 共有ポートフォリオを利用している場合、アカウントが組織を離れてもプロビジョニングされた製品は保持されます。組織のエンティティ（組織のルート、組織単位（ OU ）、または組織アカウントなど）を使用して共有された Service Catalog ポートフォリオは、そのアカウントから自動的に共有解除されます。組織からアカウントを削除した後、そのアカウントでプロビジョニングされた Service Catalog 製品の管理を続ける必要がある場合、個別のアカウント用にポートフォリオ共有を作成できます。共有されたアカウントでは、ポートフォリオをインポートし、アカウント内のプリンシパルで製品に対する権限を更新する必要があります。このブログシリーズの第 2 部では、Service Catalog 共有製品を別の組織に移行する方法について説明しています。

Service Catalog AppRegistry は、AWS Resource Access Manager (AWS RAM) を使用してアプリケーションと属性グループを共有します。アカウントが組織を離れると、組織エンティティを使用して共有された Service Catalog AppRegistry リソースは、そのアカウントから共有解除されます。共有アプリケーションに追加されたアカウントの関連リソースコレクションや属性グループはすべて削除されます。このブログシリーズの第 1 部では、所有者と消費者アカウントの両方に対して、組織間で移動する際の AWS RAM リソース共有と考慮事項について説明しています。

アカウントが移行先組織に参加すると、組織ルート、組織単位、組織アカウントなどの組織エンティティを使用して共有されている Service Catalog ポートフォリオ、AppRegistry アプリケーション、属性グループリソースは自動的にアカウントに共有されます。

Service Quotas：servicequotas.amazonaws.com

Service Quotas の信頼されたアクセスを有効にすると、アカウント作成時に自動的にクォータ増加をリクエストするためのクォータリクエストテンプレートを作成することができます。アカウントが組織を離れた場合、クォータリクエストテンプレートから適用されたクォータリクエストは影響を受けません。クォータリクエストテンプレートは、組織内で新しく作成されたアカウントにのみ適用されます。

アカウントが移行先組織に参加した場合、既存のアカウントのクォータは影響を受けません。

AWS Systems Manager: ssm.amazonaws.com , opsdatasync.ssm.amazonaws.com

AWS Systems Manager の 信頼されたアクセスを有効にすると、組織内のすべての AWS アカウントで Systems Manager Explorer、Change Manager、OpsCenter の機能を使用できます。

複数のアカウントからデータを収集するために、Systems Manager Explorer リソースデータ同期を作成した場合、アカウントが組織を離れると、そのアカウントはリソースデータ同期の対象から除外され、Systems Manager Explorer ダッシュボードに同期される運用データに含まれなくなります。アカウントが移行先組織に参加すると、そのアカウントの Change Manager 変更要求は Systems Manager Explorer の既存のリソースデータ同期に含まれるようになります。

Systems Manager Change Manager を設定した場合、複数の AWS アカウントおよび AWS リージョン全体で変更を管理できます。アカウントが組織を離れると、そのアカウントに対する変更管理フレームワークを使用することはできなくなり、アプリケーションの設定やインフラストラクチャへの運用変更のリクエスト、承認、実装、報告ができなくなります。承認された後すぐに、またはスケジュールされた時間に実行されるよう設定された既存の変更リクエストは、そのアカウントを対象としなくなります。アカウントが対象の組織に参加すると、アカウント ID が指定されているか、変更リクエストで指定された組織単位（OU）の一部である場合に、Change Manager の変更リクエストはスケジュール通り、または承認されたとおりに実行されます。

組織メンバーアカウント間で OpsCenter を使用して OpsItems を操作するための Systems Manager OpsCenter を設定した場合、アカウントが組織を離れると、OpsCenter はそのアカウントの OpsItems を作成、表示、更新したり、OpsItems で指定された AWS リソースの詳細情報を表示したり、Systems Manager Automation ランブックを開始することはできなくなります。

アカウント間で OpsItems を操作するための権限を設定し、AWS Systems Manager ユーザーガイドにあるアカウント間で OpsItems を操作するためのアクセスと権限を設定するガイドに従った場合、アカウント間で OpsItems を操作するための権限は AWS CloudFormation スタックセットを使用して設定され、アカウント間で OpsItems を操作するためのアクセス許可をユーザーに与える OpsItemGroup リソースポリシーと IAM 実行ロールを作成します。スタックセットは組織管理アカウントで作成され、各組織メンバーアカウントにポリシー OpsItemCrossAccountResourcePolicy を持つ OpsItemCrossAccountExecutionRole が作成されます。

• 組織からアカウントを削除する前に、組織管理アカウントを使用して AWS CloudFormation コンソールで StackSet の自動デプロイ設定を確認し、必要に応じて「アカウント削除動作」を「スタックの削除」に設定します。これにより、組織からアカウントが削除された場合、アカウント内のスタックインスタンスが削除されます。これにより、組織管理アカウントと設定済みの Systems Manager 委任管理者アカウントで操作するために設定された OpsItemGroup リソースポリシー、および構成された Systems Manager 委任管理者アカウントが削除されます。
• アカウントが対象組織に参加すると、Systems Manager ガイドに従っている場合、StackSet はアカウント ID がスコープ内であれば自動的にデプロイされ、移行先組織の管理アカウントおよび Systems Manager 委任管理者アカウントで操作するために、 OpsItemGroup リソースポリシーと IAM 実行ロールが設定されます。

Systems Manager ガイド（アカウント間で OpsItems を操作するためのアクセスと権限を設定する）を使用せずにアカウント間で OpsItems を操作する権限を設定した場合、アカウント間で OpsItems を操作する権限を更新する必要があります。これには、作成された AWS IAM ロールと OpsItemGroup リソースポリシーが含まれます。

• アカウントが組織の一部でなくなった場合、IAM ロールの信頼関係を更新し、信頼されたエンティティのプリンシパルおよび条件を移行先組織の管理アカウント ID、および設定されている場合は委任管理者アカウント ID に設定します。また、AWS アカウントが OpsCenter の運用作業項目（OpsItems）を表示および操作できるようにする OpsItemGroup リソースポリシーも更新する必要があります。リソースベースの JSON ポリシー内のプリンシパル要素を変更し、移行先組織アカウント ID および設定されている場合は Systems Manager 委任管理者アカウント ID を指定します。AWS CLI の get-resource-policies コマンドを使用して OpsItemGroup リソースポリシーを表示し、put-resource-policy コマンドを使用してリソースポリシーを作成または更新できます。両方のコマンドで、OpsItemGroup リソースポリシーの Amazon リソースネーム（ARN）を指定します。これは、arn:aws:ssm:<region>:<account-ID>:opsitemgroup/default の形式で、<region> はポリシーを適用する OpsItemGroup リソースの AWS リージョン、<account-ID> はリソースポリシーを更新する AWS アカウント ID です。Systems Manager OpsCenter で OpsItemGroup リソースポリシーをサポートする各 AWS リージョンでリソースポリシーを更新する必要があります。
• アカウントが移行先組織に参加すると、アカウント間で OpsItems を操作する権限を設定した場合、管理アカウントまたは Systems Manager 委任管理者アカウントは、アカウント内の OpsItems を操作するために IAM ロールとリソースポリシーを設定できます。

AWS Trusted Advisor：reporting.trustedadvisor.amazonaws.com

AWS Trusted Advisor の 信頼されたアクセスを有効にすると、組織内のすべてのアカウントの Trusted Advisor のチェック結果を受け取り、チェックの概要と影響を受けるリソースを確認するためのレポートをダウンロードすることができます。組織ビューを有効にしている場合、組織からアカウントを削除すると、Trusted Advisor はそのアカウントのチェックを表示または報告できなくなります。アカウントが移行先組織に参加すると、そのアカウントは有効な Trusted Advisor 組織ビューに含まれます。

AWS Well-Architected Tool：wellarchitected.amazonaws.com

AWS Well-Architected Tool の 信頼されたアクセスを有効にすると、AWS Well-Architected Tool リソースを組織の他のメンバーと共有するプロセスを簡単にすることができます。ワークロードまたはカスタムレンズに対して Well-Architected Tool 組織または OU 共有を作成した場合、アカウントが組織を離れると、ワークロードまたはカスタムレンズはそのアカウントとの共有が解除されます。ワークロードまたはカスタムレンズをアカウントと共有し続ける必要がある場合は、対象の AWS アカウント ID またはアカウントの IAM ユーザーを使用して共有を作成できます。ワークロードまたはカスタムレンズを共有しているアカウントが組織を離れると、そのワークロードまたはカスタムレンズは組織または OU との共有が解除されます。組織メンバーアカウントとの共有を継続する必要がある場合は、対象の AWS アカウント ID またはアカウントの IAM ユーザーを使用して共有を作成できます。 個々の AWS アカウントや IAM ユーザーに対して作成されたワークロードまたはカスタムレンズの共有は、共有アカウントが組織を離れても削除されません。

アカウントが移行先組織に参加すると、組織または該当する OU に対して作成された既存のワークロードまたはカスタムレンズ共有に含まれるようになります。

Amazon VPC IP Address Manager（IPAM）： ipam.amazonaws.com

Amazon VPC IP Address Manager (IPAM) の信頼されたアクセスを有効にすると、組織全体で IP アドレス使用状況を監視し、メンバーアカウント間で IP アドレスプールを共有することができます。組織メンバーアカウントからのデータレプリケーションを許可するオプションを使用して IPAM を作成した場合、アカウントが組織を離れると、IPAM はそのアカウント内の IP 使用量を監視できなくなります。 アカウントリソースは IPAM スコープに含まれなくなりますが、IPAM プールからの CIDR 割当はアカウントリソースに割り当てられたままであり、IPAM プールによって使用されます。組織からアカウントを削除する前に、必要に応じて、IPAM コンソールまたは AWS CLI release-ipam-pool-allocation コマンドを使用して、IPAM プールから CIDR 割り当てを削除できます。アカウントが組織に属していない場合、プールから CIDR 割り当てを削除することはできません。IPAM プールから CIDR 割り当てを削除しても、アカウントリソースに割り当てられた CIDR は削除されません。組織間の移行中は、 IP 使用状況を継続して監視するためにスタンドアロンアカウントに IPAM を作成できます。

アカウントが移行先組織に参加すると、組織メンバーアカウントからのデータレプリケーションを許可するために作成された IPAM によって、アカウントは自動的に IP アドレス使用状況の監視対象となります。組織にアカウントを移動する前に、IPAM プールの IPAM CIDR 管理が「自動的に発見されたリソースをインポートする」に設定されていることを確認します。組織に追加するアカウントの発見されたリソースをインポートするために、自動インポートを許可することをお勧めします。リソースに対する重複しない CIDR は IPAM プールから割り当てられますが、アカウント内のリソースの CIDR は変更されません。アカウントリソースの CIDR が IPAM プールからプロビジョニングされていないか割り当てられていない場合、CIDR の IPAM コンプライアンスステータスは管理されていない状態になります。このブログシリーズの第 2 部では、IPAM の委任管理者アカウントと、これがアカウントリソースの IPAM プール割り当て CIDR にどのように影響するか議論します。

結論

本ブログでは、AWS Organizations の信頼されたアクセスをサポートする AWS サービスについて説明しました。1 つ以上の互換性のある AWS サービスが、組織で信頼されたサービスとして構成されているかどうかを識別する方法を学びました。また、組織からアカウントを削除し、別の組織に追加する場合、信頼されたアクセスを有効にした AWS サービスに関して、考慮すべき点とアクションを学びました。

このブログシリーズでは、Organizations のさまざまな機能を順を追って説明し、Organizations を使用して AWS アカウントをある組織から別の組織に移動する場合のガイダンスと考慮事項を提供します。

シリーズの第 1 部では、Organizations のさまざまな機能を説明し、Organizations を使用して AWS アカウントを組織から別の組織に移動する場合のガイダンスと考慮事項を提供しました。 シリーズの第 2 部では、AWS Organizations の委任管理者を特定し、1 つ以上の互換性のある AWS サービスの委任管理者として登録されているアカウントを移動したい場合の影響とアクションについて説明しました。

ブログ著者について :