はじめに
ついにControl Towerが東京リージョンにリリースされました。
検証用で使っていたControl Towerを一旦廃止して、東京をホームリージョンとしたControl Towerを再作成してみます。
バージョンは以下の通りで、アカウントを最新版にしていないのは意図的です。
このようにバージョンが異なる場合に廃止措置をしても、正常に廃止されるのか確認します。
また、Log archive, Auditアカウントを閉鎖せずにランディングゾーンを再設定します。
環境・前提
- Control Tower Version 2.7
- 個別のアカウントはVersion 2.6
- Control Towerにより作成されたVPCなし
- Log archive, Auditアカウントは閉鎖しない
Log archive, Auditアカウントのメールアドレス、アカウント名の変更
このセクションはControl Towerの再設定時に旧Log archive, Auditアカウントを閉鎖するなら不要です。
Eメールの変更は、Control Tower再設定時のLog archive, AuditアカウントのEメールに、現在のEメールを使用したいからです。
アカウント名の変更は、上記同様Control Tower再設定時のLog archive, Auditアカウントと名前が被ってしまうからです。
エラーになるか分かりませんが、同じOrganizations内に同一のアカウント名のアカウントを作りたくないので変更します。
変更するために、それぞれのアカウントにルートユーザとしてサインインします。
私はパスワードを設定していないので、パスワードをお忘れですか？を押下します。
メールが届きますので、手順に従ってパスワードを設定。
パスワードを設定したら、ルートユーザとしてサインインします。
マネジメントコンソールのナビゲーションバーのアカウント名から、マイアカウントを押下。
アカウント設定の編集を押下します。
名前とEメールを編集から変更し、完了。
Auditのアカウント名はOld Auditにしました。
同様にLog archiveはOld Log archiveにしますが、記事では省略します。
なお、アカウント名、Eメールを変更するとメールが届きます（Eメールは新旧メールアドレス両方で受信）。
Control Towerのコンソールでも、アカウント名とメールアドレスの変更が反映されていることが分かります(メールアドレスは黒塗りしていますが、ちゃんと変更されています。)。
Control Towerの廃止措置
Control TowerのコンソールのLanding zone settingsからDecommision landing zoneを押下します。
以下のことが起きると注意されます。
- アカウントがOrganizationsのルートに移動する*
- Control Towerにより作成されたリソースが削除される。VPCとSSOは削除されない。VPCの削除には追加の手順が必要。
- Organizationsはそのまま
*こちらの注意書きを見ると、アカウントが現在いるOUからルートOUに移動することを示唆しているように見えますが、実際のところアカウントは現在のOUから移動していませんでした。
同意してDecommision landing zoneを押下。
廃止措置に2時間かかるそうです。
その間はControl Towerのアクションはしないように注意しています。
私の場合は1時間もかからず終了しました。
アカウントが少ないからでしょうか。
廃止措置中エラーは発生しなかったので、Control Towerのバージョンとアカウント自体のバージョンが異なっていても、廃止措置には関係ないことが分かりました。
では、何が残っているか確認してみます。
まずはCloudFormationのStackSetです。
2つのStackSetが残っていましたが、これは私がStackSetをControl Tower管理外で操作したことが原因です。
私は、StackSetを使用してCloudTrailとS3バケットを東京リージョンに追加でデプロイしていました。
スタックインスタンスを確認すると、東京リージョンにデプロイしているものが残っています。
つまり、Control Towerの廃止措置で削除するのは、Control Towerが作成したリソースだけだということが分かりました。
廃止措置実行前の注意書きにあったYou're uninstalling resources that AWS Control Tower installed.は言葉通りでしたね。
これらのスタックインスタンスはControl Tower再設定時に邪魔になるので、削除しておきます。
詳細な手順は記載しませんが、StackSetのIAM実行ロールが廃止措置により削除されているため、再作成しなければなりません。
面倒な作業になりますので、私と同様にStackSetをサポート外のリージョンにデプロイしている方は、廃止措置前に削除をした方がいいでしょう。
こちらが本来のControl Tower廃止措置後のあるべき姿です。
StackSetが全て削除された状態です（VPCを作成されている方は、VPCのStackSetのみ残っている状態だと思います。）。
次にOrganizationsを確認すると、廃止措置前後で変わっているのはガードレールのSCPが削除されていることくらいでした。
OU内のアカウント移動はありません。
今度はService Catalogを確認します。
ドキュメントではProvisioned products以外は削除されているとのことでしたが、そのとおりでした。
ドキュメントではProvisioned productsを終了すると、アカウントがルートOUに移動するとなっているので試してみましたが、エラーになりました。
解決方法が分からないので、終了せずに次に進みます。
この処理はControl Towerの再設定には必要のない処理なので、スルーします。
Old Log archiveとOld Auditアカウントを確認したところ、Control Towerにより作成されたリソースが綺麗に掃除されていました（Old Log archiveのS3除く）。
他のアカウントを確認すると、ドキュメントでは残っていると説明されていたCloudWatchLogs LogGroupのaws-controltower/CloudTrailLogsがありませんでした。
削除されているようです。
Control Tower最新バージョンだったらCFnテンプレートでRetain設定をしているのでしょうか。
Control Tower再設定前の準備
Control Towerの再設定前に、いくつか作業を行います。
それは、以下の4つです。
- コアOUとカスタムOUの削除または名前変更
- ロール、ポリシーが削除されていることを確認
- AWS SSOの削除
- CLIの実行
コアOUとカスタムOUの削除または名前変更
今回は、コアOUは名前変更、カスタムOUは削除で対応します。
終了しました。
ロール、ポリシーが削除されていることを確認
以下のロール、ポリシーが削除されていることを確認します。
これらは、ランディングゾーン設定時に作成されるので、残ったままだとおそらくエラーになります。
ロール
-
AWSControlTowerAdmin
-
AWSControlTowerCloudTrailRole
-
AWSControlTowerStackSetRole
ポリシー
-
AWSControlTowerAdminPolicy
-
AWSControlTowerCloudTrailRolePolicy
-
AWSControlTowerStackSetRolePolicy
全て残っていたので、全て削除しました。
AWS SSOの削除
Control Towerのホームリージョンを東京にするため、バージニアのAWS SSOを削除します(Control TowerのホームリージョンとAWS SSOのリージョンは合わせなければなりません。)。
Delete AWS SSO configuration押下。
チェック、入力の上削除。
削除できました。
私はSSOでサインインしていたので、削除して少ししたらサインアウトされました。
CLIの実行
最後に、以下のCLIを実行します。
私はIAMユーザにアクセスキーを発行していなかったので、CloudShellから実行しました。
aws organizations disable-aws-service-access --service-principal controltower.amazonaws.com
念の為以下のコマンドでControl Towerが存在しないか確認。
[cloudshell-user@ip-10-0-8-18 ~]$ aws organizations list-aws-service-access-for-organization
{
"EnabledServicePrincipals": [
{
"ServicePrincipal": "config.amazonaws.com",
"DateEnabled": "2021-01-14T11:51:03.748000+00:00"
},
{
"ServicePrincipal": "member.org.stacksets.cloudformation.amazonaws.com",
"DateEnabled": "2021-02-18T11:35:22.693000+00:00"
},
{
"ServicePrincipal": "securityhub.amazonaws.com",
"DateEnabled": "2021-01-26T12:13:07.004000+00:00"
},
{
"ServicePrincipal": "sso.amazonaws.com",
"DateEnabled": "2021-01-14T11:32:59.692000+00:00"
}
]
}
予想外の設定が見つかりました。
ランディングゾーンの設定時はConfigの信頼できるアクセスを有効にできないので、Organizationsコンソールから無効にしておきます。
Control Towerの再設定
ようやくControl Towerの再設定まで来ました。
必ずホームリージョンにしたいリージョンに移動してからランディングゾーンの設定を行います。
今回、ランディングゾーンは東京のみに設定します。
以前はランディングゾーンを設定するリージョンを選べなかったので嬉しい機能です。
Log archiveとAuditアカウントのEメールには、以前と同一のEメールを設定します。
通常であればエラーが発生しますが、旧Log archiveとAuditアカウントのEメールを変更しているので問題ありません。
無事作成が完了しました。
試しにCloudTrailのStackSetを確認すると、きちんと東京リージョンにデプロイされていました。
AWS SSOも東京リージョンに適切に作成されていました。
SSOのユーザポータルに移動する前に、ユーザポータルの招待メールが届いているので招待を受けます。
こちらの方からパスワードを設定できます。
新Log archive, Auditアカウントも適切に作成されています。
既存OUのControl Towerへの登録
いよいよ最後の作業です。
既存アカウントをControl Tower管理下にするために、既存OUをControl Towerに登録します。
残念ながら失敗しました。
失敗すると、原因などを記載したCSVがダウンロードできるようです。
今回は、一部のアカウントの東京リージョンにConfigが設定されていることが原因でした。
原因を取り除いて再度登録すると、成功しました。
登録されたアカウントを確認したところ、適切にランディングゾーンが設定されていました。
また、各アカウントのEメール宛に、AWS SSOのユーザポータルへの招待が届きます。承認すれば、このSSOユーザのパスワード設定画面に移動します。
おわりに
Control Towerの廃止措置から再設定までやってみましたが、時間がかかるだけで案外簡単でした。
実務で行うことは少ないと思いますが、するなら事前調整をしっかりする必要がありそうです。
CloudTrailが存在しない間の措置をどうするか、古いログのS3バケットの処遇や、SSOの削除期間のサインイン問題など色々と検討・調整することはありそうです。
Control Towerの廃止から再設定を通じて、Control Towerでエラーを起こしても致命的なミスは発生しないのでは？と思いました。
Control Towerを試したことがない方は、気軽に始めてみてはいかがでしょうか。
この記事が誰かのお役に立てれば幸いです。