👒

AWS Control Tower で設定した管理アカウントの移行

2021/12/28に公開

「よしなに」という言葉を重宝しており、なんとなくで使っていたので意味を調べてみました。いい言葉ですね。これからも重宝しようと思います。

よしなにとは、よい塩梅になるように、よい状況になるようにという意味の副詞である。

参考:weblio


さて、今回AWS のマルチアカウント環境を「よしなに」セキュアに作成してくれるAWS Control Towerというサービスがあり、その際に「えいや」でやってしまったミスからの復旧方法を残しておきます。本件は、AWS Supportの方に教わった内容を多く含みます。多謝。

TL;DR

間違ったアカウント[1]でControlTowerの設定をしてしまった後の、ベストプラクティス[2]に沿う改修までの軌跡

主に

  • Control Tower設定の解除、影響、不要なリソース削除
  • 新たな管理アカウントでのControlTowerの設定
  • 既存OUへの対応

経緯と課題

聞いたことがあるくらいで、実際に使ったことがなかったControlTowerを実際に設定してみてみました。

ただし、そのアカウントは開発ワークロードでのAWSアカウントです。結果として生まれたのはリソース管理があるアカウントがマスターアカウント、という環境をデリバリーしてしまいました。

ベストプラクティスとして、組織のマスターアカウントはリソース管理を行わないということは記憶の片隅にあったので設定した後に後悔しました。

方針

幸い私の場合は、ControlTowerでの自動設定を全て解除することが可能だったので下記方針でやっていきます。

  • Control Tower ランディングゾーンの廃止
  • 新規AWSアカウントXを作成
  • アカウントXを管理アカウントとするControl Towerのセットアップ
  • OUにて3で作成したControl Towerの有効化

対応

1. 管理アカウントとしているControl Tower ランディングゾーンの廃止

まずは、下記のドキュメントを参考に管理アカウントのランディングゾーンを廃止します。

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

30分くらいかかりました

次にランディングゾーン廃止後の不要なリソースの削除をしていきます。手動対応リソースは下記になります。

https://docs.aws.amazon.com/controltower/latest/userguide/resources-not-removed.html

2. 既存Organizationsの設定を変更(組織削除)

組織削除の為に、メンバーアカウントの除外が必要

前提として、組織の削除のためにメンバーアカウントが除外(組織を離れる)されている状態となる必要があります。

そこで、メンバーアカウントにてマスターログインを行いOrganizations組織を離れます。この作業を×メンバーアカウント分行う必要があります。つまり、Control tower初期設定でのデフォルトだとaudit,logアカウントにてこの作業は必要となります。

また、組織を離れる為にアカウントが独立した状態である必要があるため

  • カード等支払い情報の登録
  • Pinコードでの認証

を終える必要があります。コンソール上でどこから設定するか探しましたが、各メンバーアカウントにてマスターログイン、Organization→組織を離れるにて、サインアップ完了フローが出るのでそれに沿った形で設定すれば、組織を離れる為の準備が完了します。

3. ロールとポリシー削除の確認

Cloudwatch logsに下記があるのでそちらも削除

管理アカウントに既存のロググループがある場合、セットアップは失敗します。
aws-controltower/CloudTrailLogs

4.新規AWSアカウントを作成しそのアカウントでControl Towerのセットアップ

5.Organization(親OU)から既存アカウントの招待

4.のControl Towerで作成された親OUから、既存のアカウントを招待します。

  1. AWS Organizationsへログインし親OUから既存アカウントを招待
  2. メールにて招待が届く(Accept Invitationをクリック)
  3. 既存アカウントのマスターアカウントでログイン
  4. 招待を承認
  5. AWS Organizationsで招待したアカウントのステータスがACCEPTEDとなる

6.OU設計を行い、既存アカウントを設計済みOUへ移動

下記の記事を参考に、OU設計を行いました。

https://dev.classmethod.jp/articles/aws-organizations-best-practice/

後の運用も想定しつつ、現時点でのミニマムな実装を弊社では求められていたので現時点では下記のような構成となっています

- Root

	- Sandbox
		- Individual A
		- Individual B
		- etc.
	- Security
		- Audit
		- Log
	- Workloads
		- Product A
			- prod
			- SDCL
		- Product B
			- prod
			- SDCL

参考ドキュメント

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

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

https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/existing-orgs.html

https://aws.amazon.com/jp/organizations/faqs/

https://docs.aws.amazon.com/controltower/latest/userguide/importing-existing.html#common-eg-failures

https://docs.aws.amazon.com/controltower/latest/userguide/importing-existing.html

https://docs.aws.amazon.com/controltower/latest/userguide/how-to-register-existing-ou.html

脚注
  1. 開発関連のリソースを含んだアカウント ↩︎

  2. Best Practices for Organizational Units with AWS Organizations ↩︎

Discussion