Control Towerを廃止して東京リージョンで再有効化してみた – 廃止編
こんにちは、臼田です。
みなさん、AWSのアカウント管理してますか?(挨拶
AWS Control Towerはマルチアカウント管理に役に立つサービスです。最近東京リージョンをホームリージョンとして利用することができるようになったので、注目している方も多いかと思います。
今回はもともと東京リージョンをホームリージョンとして使っていなかった環境を、東京リージョンに切り替えるという作業の記録です。ちょっと長くなりすぎたのでまず廃止についてまとめます。
背景と概要
廃止廃止と書いていますが、Control Towerは有効化はするものの、ぱっと無効化できるものではありません。最近まではAWSサポートへの問い合わせが必須でした。
最近(v2.7あたり)しれっと廃止ボタンが追加されました。
あまりこれ専用でアップデートのAWSブログなどは上がっていないのですが、ユーザーガイドに説明があったのでやってOKだと判断しました。
やってみた結果、途中つっかえたところもありましたが無事廃止までできました。
廃止をする上で大事なことは以下の観点です。
- 期間に余裕を持つ
- ユーザーガイドをよく読む
- サポートに頼れるようにしておく
サポートに問い合わせなくても廃止できるようになりましたが、逆に言うとそういうレベルの作業であるという意識が大事だと現段階では思っています。(こう思わなくて良くなっていくとも思いますが)
というわけで私も2021/05/28時点のユーザーガイドを見ながら記事を書いていますが、多分皆さんが作業するときのほうがもっと情報が増えていたりすると思うのでそちらを確実に確認してください。
廃止の流れ
こんな流れです。
- Control Towerの追加要素の無効化・削除
- 子アカウントへの一時的なIAM作成
- 子アカウントのService Catalog製品削除
- Control Tower廃止
- Control Tower IAM Role/Policy削除
- CloudWatch Logsグループ削除
- AWS SSOの削除
- OrganizationsでのControl Tower統合の無効化
重要なポイントはService Catalogの製品削除を事前に行うことです。現状明確にドキュメントにかかれていませんが、Control Tower廃止後には削除できなくなっているため、サポート対応必須です(1敗)。
Control Towerの廃止は最低限の設定・リソースしか削除しません。例えばAWS Organizationsは削除されず維持されます。もともとControl Towerで作成したOrganizationsかどうかは関係ありません。他にもAWS SSOやSecurity(旧Core) OU配下のアカウントやその上のS3(ログ)なども保持されます。詳細は以下で確認できます。
Resources not removed during decommissioning - AWS Control Tower
一方で、今回の目的のように再度Control Towerを有効化する場合には、残っているものを手動で削除などしていく必要があります。
やってみた
Control Towerの追加要素の無効化・削除
まずは他の作業が可能なように、カスタマイズしているControl Towerの各要素を外していきます。例えばControl Tower外で追加しているSCPやリージョン拡張、他にも後続の作業で邪魔になるものは一通り無効化や削除を行いましょう。
特にSCPは各作業の失敗要因となるのでよく確認しましょう。
子アカウントへの一時的なIAM作成
ホームリージョンを変更する作業の場合、AWS SSOも作り変えるため一旦無効化します。
そのため各子アカウントへのアクセス方法を確保しておく必要があります。IAM UserやIAM Roleを作成しておきます。
子アカウントのService Catalog製品削除
問題の作業です。管理アカウントのホームリージョンでService Catalogコンソールを開き、プロビジョニングされた製品の画面から子アカウントの製品を選択して「アクション」から「終了」します。
なお、Control Tower廃止後にこれをやろうとすると、以下のようにエラーとなり、消せなくなります。絶対事前にやろうね!
万が一消せなくなってしまったらサポートに連絡しましょう。
なお、Service CatalogにアクセスするIAMによってはプロビジョニングされた製品が表示されたりされなかったりするので、その場合にはアクセスフィルターを切り替えると表示されると思います。
Control Tower廃止
管理アカウントからControl Towerを廃止します。Control Towerのコンソールにある「ランディングゾーン設定」画面の「廃止」タブを開き「ランディングゾーンの廃止」を選択します。
廃止の確認画面が出るのでそれぞれチェックし廃止します。
有効化時と同じように処理中の画面がでます。
しばらくすると完了します。
Control Tower IAM Role/Policy削除
Control Tower廃止時に残したもののうち、再有効化の障壁になるものを取り除いていきます。
こちらの既存アカウントのControl Tower登録要件(というかエラーが出る条件)を確認するといいです。
そしてこちらのセットアップも確認します。
管理アカウントのIAMリソースはAWSControlTower
と検索すると残っているリソースを確認できます。IAM Roleの画面では以下3つを削除します。
- AWSControlTowerAdmin
- AWSControlTowerCloudTrailRole
- AWSControlTowerStackSetRole
IAM Policyでも以下3つを削除します。(こちらは1つずつ削除)
- AWSControlTowerAdminPolicy
- AWSControlTowerCloudTrailRolePolicy
- AWSControlTowerStackSetRolePolicy
CloudWatch Logsグループ削除
管理アカウントにはCloudTrailのログがCloudWatch Logsに残っています。aws-controltower/CloudTrailLogs
を選択して削除します。
AWS SSOの削除
AWS SSOを削除します。前述の各アカウントへのアクセス経路の確保をお忘れなく。
削除はSSOのコンソールから「設定」を開き「AWS SSOの設定を削除」からです。
確認画面が出ますのですべてチェックを入れて削除します。
OrganizationsでのControl Tower統合の無効化
再有効化のために、OrganizationsのAWSサービス統合を無効化します。これは現状CLIのみのためCloudShellを起動してコマンドを実行します。
詳細はこちらのドキュメントを参照してください。
無効化のコマンド自体はレスポンスがないので、前後でlist-aws-service-access-for-organization
を利用して状態を確認します。以下のようになります。
[cloudshell-user@ip-10-0-15-97 ~]$ aws organizations list-aws-service-access-for-organization { "EnabledServicePrincipals": [ { "ServicePrincipal": "config.amazonaws.com", "DateEnabled": "2020-09-29T02:12:47.173000+00:00" }, { "ServicePrincipal": "controltower.amazonaws.com", "DateEnabled": "2020-04-27T03:42:54.144000+00:00" }, { "ServicePrincipal": "member.org.stacksets.cloudformation.amazonaws.com", "DateEnabled": "2020-09-29T02:12:41.219000+00:00" }, { "ServicePrincipal": "sso.amazonaws.com", "DateEnabled": "2020-04-27T03:43:20.255000+00:00" } ] } [cloudshell-user@ip-10-0-15-97 ~]$ [cloudshell-user@ip-10-0-15-97 ~]$ aws organizations disable-aws-service-access --service-principal controltower.amazonaws.com [cloudshell-user@ip-10-0-15-97 ~]$ aws organizations disable-aws-service-access --service-principal sso.amazonaws.com [cloudshell-user@ip-10-0-15-97 ~]$ aws organizations disable-aws-service-access --service-principal config.amazonaws.com [cloudshell-user@ip-10-0-15-97 ~]$ aws organizations list-aws-service-access-for-organization { "EnabledServicePrincipals": [ { "ServicePrincipal": "member.org.stacksets.cloudformation.amazonaws.com", "DateEnabled": "2020-09-29T02:12:41.219000+00:00" } ] }
Control TowerとConfigの連携と、どこにも書かれていなかったですが、SSOも後でControl Towerから再有効化されることを考慮して、SSOの連携も無効化しておきました。これが必要かはわかりませんが、やっておくに越したことはなさそうです。
残ったリソース確認表
2021/05/31現在のControl Towerの廃止時に残ったリソースを表にしておきました。これ以外にもチェックする箇所はありますが、ドキュメントに明示されたものの一覧という位置づけでご利用ください。今回再有効化のためにどう対応するかの観点も書いておきました。
種別 | 残っているリソース | 再作成時の対応 |
AWS Organizations | AWS Control Towerコンソールから作成したOU | そのまま |
AWS Organizations | SecurityOU(CoreOU)とSundboxOU(CustomOU) | 必要があれば重複しないようにリネーム |
AWS Organizations | Organizations | そのまま |
AWS Organizations | 各AWSアカウント(移動も削除もしない) | そのまま、SecurityOUのアカウントを保持しないならアカウント削除 |
AWS SSO | Account Factoryで作成されたユーザー | ホームリージョンが違うのですべて削除 |
AWS SSO | AWS Control Towerによって作成されたグループ | ホームリージョンが違うのですべて削除 |
AWS SSO | AWS Control Towerによって作成されたアクセス権限セット | ホームリージョンが違うのですべて削除 |
AWS SSO | AWSアカウントとアクセス権限セットの関連付け | ホームリージョンが違うのですべて削除 |
AWS SSO | AWS SSOディレクトリ | ホームリージョンが違うのですべて削除 |
S3 | Log Archiveアカウントのログ設定及びログ保管用S3バケット | 別の共有アカウントを作成するためそのまま |
S3 | ログ保管用S3バケットの内容 | 別の共有アカウントを作成するためそのまま |
共有アカウント | AWS ControlTowerのセットアップ中に作成された共有アカウント | 別の共有アカウントを作成するためそのまま |
共有アカウント | OrganizationAccountAccessRoleは通常のOrganizations用に再作成 | 別の共有アカウントを作成するためそのまま |
共有アカウント | (AWSControlTowerExecutionは削除されます) | - |
作成されたアカウント | Service Catalogで作成した製品(製品を削除するとRootOUに移動する) | Control Tower廃止前に削除 |
作成されたアカウント | Control Towerから作成したVPC及びそのStackSet | 特に構築してないのでそのまま |
作成されたアカウント | OrganizationAccountAccessRoleは通常のOrganizations用に再作成 | そのまま |
作成されたアカウント | (AWSControlTowerExecutionは削除されます) | - |
CloudWatch Logs | ロググループ「aws-controltower/CloudTrailLogs」 | 事前に削除する |
まとめ
以上で一通りの廃止・無効化作業は終了です。
次は東京リージョンでの再有効化をしていきます。続きは以下です。