既存アカウントをControl Towerへ登録するときに確認したことをまとめてみる

2022.02.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

Control Towerへ既存のアカウントを登録する際、いくつか事前に確認しておくべきポイントがあったのでまとめてみました。Control Towerでマルチアカウントを運用している環境に、既存アカウントを登録するとなった時の確認用としてご利用下さい。網羅できている自信はないのであくまで参考程度にして頂き、最新の確認事項についてはドキュメントを確認頂ければ幸いです。

既存の AWS アカウントを登録する - AWS Control Tower

実際の登録手順については以下をご参照下さい。

確認しておくこと

Control Tower 管理アカウントと同じOrganizations 組織に存在しているか

Control Towerへの登録条件として、管理アカウントが存在しているOrganizationsの組織配下にアカウントが存在している必要があります。Control Towerへの登録の前に、同じOrganizations組織へ招待しておきましょう。

参考:組織への AWS アカウント の招待 - AWS Organizations

Organizations間でアカウントを移行する場合は以下を確認しておくと良さそうです。特に組織を移動すると、それまでの請求情報(Cost Explorer等)が確認できなくなります。必要であればレポートのダウンロードをしておきましょう。

参考:2 つの AWS Organizations 間でアカウントを移動する

ガードレールのSCPで影響が出るものがないか

既存のアカウントで何かワークロードが動いている場合、SCPで設定しているガードレール起因で影響の出る可能性があります。そのため、設定されるSCPによって制限されるAPIが利用されていないかCloudTrailから確認しておきましょう。

Control Towerのガードレール

Control Towerで設定されるガードレールの「予防」に分類されているものがSCPで設定されるものになります。配置予定のOUで有効化している予防ガードレールを確認しておきましょう。特にリージョン制限するガードレールを設定しているなら、対象のリージョン以外が利用されていないことを確認しておきましょう。

参考:ガードレールリファレンス - AWS Control Tower

独自で実装しているガードレール

もし独自にガードレールとしてSCPを実装している場合は、制限しているAPIが使用されていないか確認が必要です。配置するOUにもよりますが、もしアタッチしているSCPがある場合はControl Tower登録前ではなくOrganizationsへの招待前に確認しておきましょう。

AWS Configが無効化されているか

Control Towerへアカウントを登録するとAWS Configが設定される関係上、既存で設定しているConfigのレコーダーや配信チャネルがあるとエラーとなります。

そのため、登録前にConfigが無効化されているかを確認しておきましょう。全リージョンで無効化したい時は、以下のブログをご参照下さい。

STSエンドポイントが有効化されているか

Control Towerを有効化しているリージョンで、STSエンドポイントが有効化されているか確認します。特に変更していなければ有効化されているはずです。

登録するアカウントで、IAMコンソールの [アカウント設定] → [Security Token Service(STS)]で確認しておきましょう。

Control Tower用のIAM Role(AWSControlTowerExecution)を作成しているか

Control Towerがアカウントを管理するために、AWSControlTowerExecutionというロールを使用します。そのため、Control Towerへ登録する前に以下の設定でIAMロールを作成しておく必要があるので忘れずに作成しておきましょう。

  • ロール名: AWSControlTowerExecution
  • ロールのアクセス許可:AdministratorAccess (AWS管理ポリシー)
  • ロールの信頼関係: Control Tower管理アカウントからのAssumeRole許可
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<管理アカウントID>:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {}
        }
    ]
}

コンソールから作成してもいいですが、面倒な方は上記の条件のIAMロールを作成できるCloudFormationテンプレートを用意しましたのでご利用ください。

AWSTemplateFormatVersion: 2010-09-09
Description: Configure the Execution Role for Control Tower
Parameters:
  ManagementAccountId:
    Description: "Control Tower management account ID"
    Type: String
Resources:
  AWSControlTowerExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: "AWSControlTowerExecution"
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
            Principal:
              AWS:
                - !Ref ManagementAccountId
            Action:
              - "sts:AssumeRole"
      Path: /
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AdministratorAccess

既存のCloudTrailが必要か(任意)

特に登録時に失敗するわけではないので任意としました。

Control Towerへ登録するとCloudTrailの証跡が自動で作成されるため、既存で作成したものがある場合は料金が発生します。Control Towerで作成される証跡と取得しているイベントが同じであれば、既存のものは削除しても良いと思います。

Control Towerで作成される証跡は管理イベント(APIアクティビティの読み取り/書き込み)です。

もちろんデータイベントの取得など、用途が違う場合の証跡は残しておきましょう。

おわりに

Control Towerへの既存アカウント登録時に確認した内容をまとめてみました。Control Towerをこれから利用する方は、既存アカウントの登録も必要になる機会もあると思うので参考になれば幸いです。(他にもここの確認が必要では?ってことがあればぜひ教えて下さい。)

参考