Control Towerを廃止して東京リージョンで再設定してみた

# はじめに

ついに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内に同一のアカウント名のアカウントを作りたくないので変更します。

変更するために、それぞれのアカウントにルートユーザとしてサインインします。

![スクリーンショット 2021-04-13 19.38.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/da4d99dd-37ed-6fd7-51d7-d4d05acd1920.png)

私はパスワードを設定していないので、`パスワードをお忘れですか？`を押下します。

![スクリーンショット 2021-04-13 19.41.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/ce1634df-c392-875f-0f33-dc82df512c7c.png)

メールが届きますので、手順に従ってパスワードを設定。
パスワードを設定したら、ルートユーザとしてサインインします。
マネジメントコンソールのナビゲーションバーのアカウント名から、マイアカウントを押下。

![スクリーンショット 2021-04-13 20.14.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/7aecd1e9-5824-adcb-736b-b72ef50b2039.png)

アカウント設定の編集を押下します。

![スクリーンショット 2021-04-13 20.17.26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/8b2933ea-eec4-2308-16cd-76f697837ccd.png)

名前とEメールを編集から変更し、完了。

![スクリーンショット 2021-04-13 20.19.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/02b6b84f-5045-aa1a-82db-9a0986360494.png)

Auditのアカウント名は`Old Audit`にしました。
同様にLog archiveは`Old Log archive`にしますが、記事では省略します。

![スクリーンショット 2021-04-13 20.22.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/34f1a792-2659-f0d4-415c-5dc05bca3488.png)

なお、アカウント名、Eメールを変更するとメールが届きます（Eメールは新旧メールアドレス両方で受信）。

Control Towerのコンソールでも、アカウント名とメールアドレスの変更が反映されていることが分かります(メールアドレスは黒塗りしていますが、ちゃんと変更されています。)。

![スクリーンショット 2021-04-13 20.34.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/9840be93-ff41-1f1f-20c9-c8ac425a3750.png)


# Control Towerの廃止措置

Control Towerのコンソールの`Landing zone settings`から`Decommision landing zone`を押下します。

![スクリーンショット 2021-04-13 20.38.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/d5ce4343-5b76-3b27-25e9-01ecdb1fd638.png)

以下のことが起きると注意されます。

- アカウントがOrganizationsのルートに移動する*
- Control Towerにより作成されたリソースが削除される。VPCとSSOは削除されない。VPCの削除には追加の手順が必要。
- Organizationsはそのまま

*こちらの注意書きを見ると、アカウントが現在いるOUからルートOUに移動することを示唆しているように見えますが、実際のところアカウントは現在のOUから移動していませんでした。

![スクリーンショット 2021-04-13 20.38.45.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/dff12f89-6d10-7aea-bbba-47ae2f3655d7.png)

同意して`Decommision  landing zone`を押下。


![スクリーンショット 2021-04-13 20.44.23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/96b94fc4-17a7-d632-a910-33e38254d006.png)

廃止措置に2時間かかるそうです。
その間はControl Towerのアクションはしないように注意しています。
私の場合は1時間もかからず終了しました。
アカウントが少ないからでしょうか。


![スクリーンショット 2021-04-13 21.14.06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/3c831151-b03e-3d95-9977-cb6db03e15a5.png)

廃止措置中エラーは発生しなかったので、Control Towerのバージョンとアカウント自体のバージョンが異なっていても、廃止措置には関係ないことが分かりました。

では、何が残っているか確認してみます。

まずはCloudFormationのStackSetです。

![スクリーンショット 2021-04-13 21.15.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/1cefcb82-b709-2be8-b156-a60256a4c345.png)

2つのStackSetが残っていましたが、これは私がStackSetをControl Tower管理外で操作したことが原因です。
私は、StackSetを使用してCloudTrailとS3バケットを東京リージョンに追加でデプロイしていました。

スタックインスタンスを確認すると、東京リージョンにデプロイしているものが残っています。

![スクリーンショット 2021-04-13 21.17.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/22de29cb-a04c-cd24-cdae-9b6de5daadb5.png)

つまり、Control Towerの廃止措置で削除するのは、Control Towerが作成したリソースだけだということが分かりました。
廃止措置実行前の注意書きにあった`You're uninstalling resources that AWS Control Tower installed.`は言葉通りでしたね。

これらのスタックインスタンスはControl Tower再設定時に邪魔になるので、削除しておきます。

詳細な手順は記載しませんが、StackSetのIAM実行ロールが廃止措置により削除されているため、再作成しなければなりません。
面倒な作業になりますので、私と同様にStackSetをサポート外のリージョンにデプロイしている方は、廃止措置前に削除をした方がいいでしょう。

こちらが本来のControl Tower廃止措置後のあるべき姿です。
StackSetが全て削除された状態です（VPCを作成されている方は、VPCのStackSetのみ残っている状態だと思います。）。

![スクリーンショット 2021-04-13 21.46.03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/5e0a16ae-6c5b-0f41-c1ea-356af59f5889.png)

次にOrganizationsを確認すると、廃止措置前後で変わっているのはガードレールのSCPが削除されていることくらいでした。
OU内のアカウント移動はありません。

今度はService Catalogを確認します。
ドキュメントではProvisioned products以外は削除されているとのことでしたが、そのとおりでした。

![スクリーンショット 2021-04-13 21.55.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/068eb089-6442-9b6c-3c14-911c705ea848.png)

ドキュメントではProvisioned productsを終了すると、アカウントがルートOUに移動するとなっているので試してみましたが、エラーになりました。


![スクリーンショット 2021-04-13 22.05.43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/8eb7d8ef-9539-bb4f-85f2-a00f5019100d.png)

解決方法が分からないので、終了せずに次に進みます。
この処理は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の削除または名前変更

https://docs.aws.amazon.com/controltower/latest/userguide/decommission-landing-zone.html

今回は、コアOUは名前変更、カスタムOUは削除で対応します。

![スクリーンショット 2021-04-13 22.30.46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/575d9d45-29eb-a4e0-6963-dff80032717b.png)

終了しました。

![スクリーンショット 2021-04-13 22.33.35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/ea9f1a0f-e738-13c2-07f3-7f693bffd9e9.png)

## ロール、ポリシーが削除されていることを確認

https://docs.aws.amazon.com/controltower/latest/userguide/known-issues-decommissioning.html

以下のロール、ポリシーが削除されていることを確認します。
これらは、ランディングゾーン設定時に作成されるので、残ったままだとおそらくエラーになります。

ロール

- AWSControlTowerAdmin

- AWSControlTowerCloudTrailRole

- AWSControlTowerStackSetRole

ポリシー

- AWSControlTowerAdminPolicy

- AWSControlTowerCloudTrailRolePolicy

- AWSControlTowerStackSetRolePolicy

全て残っていたので、全て削除しました。

## AWS SSOの削除

Control Towerのホームリージョンを東京にするため、バージニアのAWS SSOを削除します(Control TowerのホームリージョンとAWS SSOのリージョンは合わせなければなりません。)。

`Delete AWS SSO configuration`押下。

![スクリーンショット 2021-04-13 22.44.52.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/25c237bb-eac8-c901-eac6-245cbf270e53.png)

チェック、入力の上削除。

![スクリーンショット 2021-04-13 22.46.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/bf2ec59e-3e64-3039-f07f-292b2bfff0e0.png)

削除できました。
私はSSOでサインインしていたので、削除して少ししたらサインアウトされました。

## CLIの実行

https://docs.aws.amazon.com/controltower/latest/userguide/how-to-decommission.html

最後に、以下のCLIを実行します。
私はIAMユーザにアクセスキーを発行していなかったので、CloudShellから実行しました。

```sh:
aws organizations disable-aws-service-access --service-principal controltower.amazonaws.com
```

念の為以下のコマンドでControl Towerが存在しないか確認。

```sh:
[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メールを変更しているので問題ありません。

![スクリーンショット 2021-04-13 23.04.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/bc4e2efd-4477-2af8-ef84-22c7d2f68efa.png)
![スクリーンショット 2021-04-13 23.07.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/69358865-af00-5591-4d67-13dbbbddffe4.png)

無事作成が完了しました。

![スクリーンショット 2021-04-13 23.38.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/cd8bba61-0a1e-f0c1-244c-9d3b5e84016a.png)

試しにCloudTrailのStackSetを確認すると、きちんと東京リージョンにデプロイされていました。

![スクリーンショット 2021-04-13 23.39.13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/acb739a8-aa07-ea4a-547e-25ac03c7abdf.png)

AWS SSOも東京リージョンに適切に作成されていました。
SSOのユーザポータルに移動する前に、ユーザポータルの招待メールが届いているので招待を受けます。
こちらの方からパスワードを設定できます。

新Log archive, Auditアカウントも適切に作成されています。

![スクリーンショット 2021-04-14 18.56.14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/e491e08d-7f1a-1307-f957-7fa7c5a81812.png)


# 既存OUのControl Towerへの登録

いよいよ最後の作業です。
既存アカウントをControl Tower管理下にするために、既存OUをControl Towerに登録します。

![スクリーンショット 2021-04-13 23.52.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/3419b7f3-c882-7590-1cdc-e50dc7d43937.png)



残念ながら失敗しました。

![68747470733a2f2f71696974612d696d6167652d73746f72652e73332e61702d6e6f727468656173742d312e616d617a6f6e6177732e636f6d2f302f3334343731312f65666664363832372d653131612d656662652d383632632d3234383061333233333332612e706e67.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/795d5d4e-62cd-54ad-d341-6d1993a4bfe5.png)

失敗すると、原因などを記載したCSVがダウンロードできるようです。
今回は、一部のアカウントの東京リージョンにConfigが設定されていることが原因でした。

![スクリーンショット 2021-04-14 0.04.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/d44b5c69-4ce1-f2c1-000f-f44c331a7238.png)

原因を取り除いて再度登録すると、成功しました。

![スクリーンショット 2021-04-14 0.22.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/344711/884e8f64-9236-1699-42e1-fdb5297c9160.png)

登録されたアカウントを確認したところ、適切にランディングゾーンが設定されていました。

また、各アカウントのEメール宛に、AWS SSOのユーザポータルへの招待が届きます。承認すれば、このSSOユーザのパスワード設定画面に移動します。

# おわりに

Control Towerの廃止措置から再設定までやってみましたが、時間がかかるだけで案外簡単でした。
実務で行うことは少ないと思いますが、するなら事前調整をしっかりする必要がありそうです。

CloudTrailが存在しない間の措置をどうするか、古いログのS3バケットの処遇や、SSOの削除期間のサインイン問題など色々と検討・調整することはありそうです。

Control Towerの廃止から再設定を通じて、Control Towerでエラーを起こしても致命的なミスは発生しないのでは？と思いました。

Control Towerを試したことがない方は、気軽に始めてみてはいかがでしょうか。
この記事が誰かのお役に立てれば幸いです。