年末に体調を壊して１週間ほど入院していたSREチームのanecho108と申します。
インフルエンザも流行っていますので今後も体調には気を付けたいですね。

はじめに

今回は、下記の図のようにOrganizations組織のメンバーアカウントを別AWSアカウントのOrganizations組織に加入させたいと思います。実施する機会も少ないと思いますので、その際の手順と注意点を備忘録としてまとめたいと思います。なお、元の組織はControll Towerを利用していません。新組織では利用しています。

はじめに
目次
事前準備
Organizations組織の離脱
サポートプランの変更
請求タイミングについて
組織の離脱とスタンドアロンのルートユーザー
- スタンドアロンのルートユーザーのパスワード
新しい組織への加入
OrganizationAccountAccessRoleの変更
Organizationsで組織へ移動とControll Towerのランディングゾーン登録
最後に

事前準備

スタンドアロンになるとコストと使用状況のデータにはアクセスできない

下記の考慮事項に記載がありますが、スタンドアロン時には請求関連のデータにアクセスできなくなります。
ですので、スタンドアロンになる前にはCost Explorer、Saving PlansおよびRIの使用状況レポートをCSV出力しておくことをおすすめします。

docs.aws.amazon.com

AWS Configは無効化にしておく

AWS Configについて、1リージョンで1つしか設定することが出来ない仕様のようで、新しい組織のControl Tower管理下のOUへ登録する際に既存の設定とControl Towerガードレールによって実行されるAWS Configのプロビジョニングと競合し、OUへの登録が失敗します。
ですので、メンバーアカウントではAWS Configの設定を無効化することが必要です。

既存のCloudTrailの停止

CloudTrailでは競合なく既存設定を残したまま組織移行することが可能ですが、Control Towerガードレールでも全リージョンで CloudTrailのログ証跡が取得されるようになるため、利用料金の重複が発生します。
なお、Control Towerによって設定されたCloudTrailはガードレールでコントロールしておくと停止・変更が行えないため、既存のCloudTrailログの停止しておくこととしました。

STSエンドポイントの有効化

IAMコンソールの [アカウント設定] → [Security Token Service(STS)]で全アカウント全リージョンでアクティブであることを確認します。
この操作を行わないと、ランディングゾーンの設定プロセスの途中で起動が失敗する可能性があります。

SCPの影響確認

新組織のControl TowerガードレールのSCPによる影響確認しておきます。こちらは予防コントロールに抵触するリソース・設定が無いことを確認します。最悪CloudTrailにエラーが出るようなのでそちらでも確認しておきましょう。

組織離脱元の組織について

今回、組織離脱元の管理アカウントも新組織のメンバーアカウント配下に加えます。
注意点としては下記になります。

組織を削除できるのは、すべてのメンバーアカウントが削除された後のみ。
「停止」状態のメンバーアカウントは組織から削除できない

管理アカウント側からメンバーアカウントを削除した場合、90日待たされる状態となります。
ですので、一度組織を離脱してスタンドアロン状態になってから削除するのが望ましいです。このとき、請求が来る可能性もあるのでそちらも留意しておきましょう。

AWSControlTowerExecutionの作成

Control TowerがAWSアカウントを管理する際に、こちらのロールを使います。
組織移動するメンバーアカウントに事前に登録しておきます。

ロール AWSControlTowerExecution の説明

ロール名：AWSControlTowerExecution
ポリシー：AdministratorAccess
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Principal":{
"AWS": "arn:aws:iam::xxxxxxxxxx:root"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}

Organizations組織の離脱

別AWSアカウントのOrganizations組織に加入するには、まず現Organizations組織を離脱する必要があります。

離脱する前にそのメンバーアカウントで下記情報を登録します。現Organizationsを離脱するということは、スタンドアロン状態になります。ですので、Payerアカウントと同様に必要な支払い情報や電話番号を登録する必要があります。必要な情報が登録されていない場合、離脱時にエラーとなりますのでその場合は見直しましょう。

連絡先名と住所
有効な支払い方法
電話番号による確認
サポートプランオプション

参考：メンバーアカウントから組織を脱会する

サポートプランの変更

前述の通り、組織から離脱する場合は一時的にスタンドアロンになります。

今回実施した手順では、メンバーアカウントはエンタープライズサポートプランですのでそのままの状態で離脱すると、エンタープライズサポートプランが維持された状態になると思いました。その際の請求が怖かったので、スタンドアロンでは請求が来ないようBasicプランに変更しました。

なお、サポートプランの変更ですが、下記の通り、Enterprise On-Ramp またはエンタープライズサポートプランを利用している場合は自身でサポートプランの変更ができないため、サポートにプラン変更の連絡が必要です。

AWS Support プランの変更

また、問合せする際はメンバーアカウントではなく、Organizationsの管理アカウントから問合せが必要でした。サポートプラン変更のリードタイムは、担当者の割当てから1時間以内でした。

サポートのカテゴリは、「アカウント, その他アカウントに関する問題」を選択し、下記内容で申請しました。なお、申請する下記のフォーマットはAWSサポートから聞きました。

ご申請理由：
Organizationsから離脱 -Yes
・離脱予定日：Basic プランへの変更が終了次第すぐ
・Yesの場合は以下情報も併せてお知らせください
　離脱後のサポートレベル：Basic
　離脱後のアカウントロール：Regular

※Regularとはスタンドアロンを意味します。

請求タイミングについて

今回の手順は、実際にはスタンドアロン状態の期間は10分程度の手順になります。
この間は出来れば、スタンドアロンで登録した支払い情報先には請求されたくありませんが、スタンドアロン内は各種AWSサービスが存在しているので従量課金で請求が発生すると考えていました。

しかし、請求されるタイミングについては、UTCが影響するかどうか不明ですが日を跨ぐ0:00を起点に請求されるようです。ですので、こういった手順の場合はその日の業務時間中に行えばスタンドアロン状態の支払い情報先に請求されることはなさそうです。
このため、前述のサポートプラン変更は不要かもしれませんが念の為実施しています。

組織の離脱とスタンドアロンのルートユーザー

必要な準備が整ったら、Organizationsの組織から離脱します。
Organizationsの管理アカウント側、もしくは離脱するメンバーアカウントのOrganizationsから離脱します。

スタンドアロンのルートユーザーのパスワード

ここでふと疑問に思いまして、スタンドアロンになるということはルートユーザーの登録が必要です。メンバーアカウントで生成したスタンドアロンは、ルートユーザーのメールアドレスは登録しましたがパスワードは登録していません。

では、スタンドアロン状態になった場合にルートユーザーのパスワードはどうなっているのでしょうか。

実はメンバーアカウントを生成した時点でAWS側で自動的にルートユーザーのパスワードを生成しています。しかし、このパスワードは我々ユーザには伝えられていないためスタンドアロンになった後、AWS アカウントのルートユーザーパスワードを忘れた場合の手順と同様にしてパスワードをリセットする必要があります。 AWS Organizations を使用して組織内のメンバーアカウントにアクセスする

なお、メンバーアカウントとして生成しておらず、スタンドアロン状態から組織加入して離脱する場合は、スタンドアロン時に作成したルートユーザーとパスワードをそのまま利用します。忘れてしまった場合はリセットですね。

また、ルートユーザーでログイン後はMFAの登録も忘れずにしておきましょう。

新しい組織への加入

ようやく新しい組織への加入ですね。事前に新Organizations組織から招待しておきます。基本的には新しい組織に入るということはOrganizationsとControll Towerが有効になっていると思います。新しい組織のOrganizationsからスタンドアロンのAWSアカウントを招待し、ルートユーザーでスタンドアロンにログインして組織に加入します。

OrganizationAccountAccessRoleの変更

スタンドアロンには離脱したOrganizations組織元で
OrganizationAccountAccessRoleというロールが自動的に作られていました。
このロールは、メンバーアカウントへの管理アクセスを管理アカウントのユーザーに付与するものです。

こちらのIAMロールの信頼性ポリシーにはOrganizationsのAWSアカウントが指定されていますので、新しい組織のOrganizations管理アカウントを変更しましょう。
（Controll Towerで作ったメンバーアカウントには上記ロールは生成されていなかったので、Controll Towerを使ってないOrganizationsでメンバーアカウントを作成した場合に作られるロールかもしれません。）

参考：AWS Organizations によるアカウント招待の管理

参考：AWS Organizations を使用した OrganizationAccountAccessRole を持つメンバーアカウントへのアクセス