はじめに
みなさんControl Towerは使ってますか？
マルチアカウント環境を全部まるっとカバーしてくれるサービスで、2021年の4月に東京リージョンにも対応しました。これを受け業務で使う機会に恵まれたので、その感想を共有していきたいと思います。
ここでは業務を通して見えてきたControl Towerのメリットや注意事項などを自分なりに上げ連ねてみます。Control Towerのセットアップ方法については以下の記事に記載していますので、興味のある方はご覧ください。
使ってみた感想
Control Tower、非常によいです。自力で構築するとCloudFormationのテンプレート作ったりスタックセットで展開したりAWS Configルールの定義をたくさん作ったり、、、と果てしなく大変＆運用も非常に煩雑になるのですが、このサービスを使えばほんとにマウスクリックだけで環境が作れてしまいます。
とはいえ扱いに少々癖があり慣れが必要なのと、Control Towerでカバーされていないリージョンや機能があるので一長一短ではありますが、自分で時間をかけて作るよりはこういったサービスを使う方がストレスも少ないですし、他の事に割ける時間も増えるので個人的には良いのではないかと考えています。
そもそもControl Tower＆マルチアカウント環境って何よ？って方はこちらのリンクを参照ください。必要な情報がいい感じに纏められてますので。
メリット
色々あるとは思いますが、ぱっと思いつくところはこんなところです。
環境設定が全て自動で行われる
AWS Config、Cloud Trailの設定、ログアーカイブアカウントへのログ集約、監査用アカウント作成等々、マルチアカウント環境に必要な設定が全自動で行われます。自分でやることは何もありません。マウスポチポチのみ。
さらにAccount Factoryという機能を使えば、新規のAWSアカウントを追加する際にも上記色々めんどくさい設定を全部勝手にやってくれた上で払い出してくれます。ステキ。
AWS SSOがついてくる
使ったことがない人にとっては若干敷居が高い（と思われる）AWS SSOですが、Contorl Towerを使えばこれも自動的に構築して提供してくれます。まあこの辺は「いらねえよ」という人もいるかもですが、いざ使ってみるとこれも相当にステキなサービスです。
マルチアカウント環境だと大きなところでは数十～数百のAWSアカウントを管理するケースも出てくると思いまが、AWS SSOを使わずにこういう大規模な環境を維持していくのは相当きついと思われます。
AWS SSOを使えば権限設定を一カ所に集約できますし、Organizations内の他のアカウントにスイッチするのも非常に楽に行えますので、特に中央管理者（マスターアカウントを管理し、メンバーアカウントに統制を効かせる側の人々）にとってメリットが大きいと思います。
規模やユースケースによるとは思いますが、個人的には中央管理者はAWS SSOを使い、メンバアカウント利用者にはIAMユーザを配る（各々勝手にやってもらう）くらいがちょうどいい使い方なのではないかな、と今のところは考えています。必要なガバナンスはガードレールやSecurity Hub、GuardDutyで効かせる感じで。
Control Towerダッシュボードが付いてくる
マルチアカウント環境の中身をまるっと可視化できるダッシュボードが付いてきます。
このダッシュボードの中でメンバーアカウント一覧、OU一覧、適用済みのガードレール一覧、ガードレールの準拠状況、、、等々を確認することができます。色んな画面を飛ぶ必要がないので地味に便利です。
注意事項
Control Towerを使うにあたって気を付けた方がいい点を以下列挙していきます。若干癖があるので、この辺を受け入れられない場合は独自構築を選択した方がよいかもしれません。
GuardDutyやSecurity Hubには対応していない
Control Towerを使ったとしても、上記サービスは自動で展開してくれません。なので使いたい場合は自分で手動設定する必要があります。全リージョンに展開する場合はまあまあ手間です。とはいえこちらは独自構築するとしても同じ話なので、そんなデメリットになる話でもないですが。
Control Tower自体がSecuryt Hubのセキュリティ基準に引っかかる
これにはまあまあ苦労させられました。Security Hubにはセキュリティ基準という機能があり、AWSの推奨ルールから逸脱するサービスがないか常時チェックしてくれます。で、問題が見つかったらアラートでお知らせしてくれるのですが、これにControl Towerで自動作成されたサービス（Lambda、SNS等々）が引っかかったりするのです。
私の場合は１つずつアラートをチェックしてポチポチ修正していったのですが、結構根気のいる作業でした。スクリプト等を作って修正作業を自動化するなど、工夫が必要な個所かと思います。あと私はSecurity Hubの「AWS 基礎セキュリティのベストプラクティス v1.0.0」をよく使うのですが、Contorl Tower環境下では以下の定義は無効化しても良いのでは、と思っています。
- SNS.1：SNS topics should be encrypted at-rest using AWS KMS（SNSトピックは、AWS KMSを使用して保存時に暗号化する必要があります）
- EC2.10：Amazon EC2 should be configured to use VPC endpoints（Amazon EC2は、VPCエンドポイントを使用するように設定する必要があります）
- Lambda.4：Lambda functions should have a dead-letter queue configured（Lambda関数には、配信不能キューを構成する必要があります）
- KMS.2：IAM プリンシパルには、すべての KMS キーで復号アクションを許可する IAM インラインポリシーがあってはなりません
OUの取り扱いに制約がある
こちらは私が構築作業を行った際の2021年6月頃における内容です。OU関連でこういった制約がありました。
- AWS Control Tower コンソールにネストされた OU を表示することができない。
- AWS Control Tower コンソールからネストされたOUを作成することができない。
- Control Tower配下のOUには、1つあたり最大5個のSCP（ガードレール）までしか適用できない。
- Control Tower配下のOUには、1つあたり最大300アカウントまでしか登録できない。
最近OUのネストが可能になったという記事も見た気がしますが、以下のリンクなど参照して制約を確認した上で使用した方がよいと思います。
既存アカウントをControl Towerに追加する際に注意が必要
Control Towerでは自動的にガードレール（AWS Configルール）が作成され、配下のAWSアカウントに適用されます。このため、既存アカウント（既に運用などで使われている単体アカウント）をControl Tower配下に追加する場合、このガードレールの影響を受けないか事前確認する必要があります。
こちらで色々調べた限りでは、通常の使い方をしている限り影響を受けることはなさそうです。ただ実際影響があるかどうかはケースバイケースなので、既存アカウントを追加する場合は一通り確認しておいた方がよいかと思います。この辺りのURLに情報が記載されています。
一部のリージョンがControl Towerに対応していない
各リージョンにおける、2021/12月現在のContorl Towerの対応状況は以下の通りです。
| リージョン（英語名） | リージョン（日本語名） | 対応状況 |
|---|---|---|
| us-east-2 | 米国東部 (オハイオ) | 〇 |
| us-east-1 | 米国東部（バージニア北部） | 〇 |
| us-west-1 | 米国西部 (北カリフォルニア) | × |
| us-west-2 | 米国西部 (オレゴン) | 〇 |
| af-south-1 | アフリカ (ケープタウン) | × |
| ap-east-1 | アジアパシフィック (香港) | × |
| ap-south-1 | アジアパシフィック (ムンバイ) | 〇 |
| ap-northeast-3 | アジアパシフィック (大阪) | × |
| ap-northeast-2 | アジアパシフィック (ソウル) | 〇 |
| ap-southeast-1 | アジアパシフィック (シンガポール) | 〇 |
| ap-southeast-2 | アジアパシフィック (シドニー) | 〇 |
| ap-northeast-1 | アジアパシフィック (東京) | 〇 |
| ca-central-1 | カナダ (中部) | 〇 |
| eu-central-1 | 欧州 (フランクフルト) | 〇 |
| eu-west-1 | 欧州 (アイルランド) | 〇 |
| eu-west-2 | 欧州 (ロンドン) | 〇 |
| eu-south-1 | ヨーロッパ (ミラノ) | × |
| eu-west-3 | 欧州 (パリ) | × |
| eu-north-1 | 欧州 (ストックホルム) | 〇 |
| me-south-1 | 中東 (バーレーン) | × |
| sa-east-1 | 南米 (サンパウロ) | × |
大阪リージョンが入ってないのは若干悲しいですね。。今後のアップデートに期待です。
なお、非対応リージョンにはAWS Config、CloudTrailが自動展開されません。なので手動で展開するか、運用ルールで当該リージョンを使わないよう縛るなど対応する必要があると思います。
それならSCP（ガードレール）でそのリージョンの利用を禁止すればいいんじゃねえの？という話もありますが、Control Tower環境下にはそのような定義を入れることが推奨されていないようです。ソースはこちらに。赤枠の「重要」欄に注意事項として記載されています。
まとめ
メリットよりも注意事項の方が多くなってしまいました。が、それを上回るメリットがContorl Towerにはあると思います。今年4月から東京リージョンにも対応してますので、気になる方は積極的に使ってみてください。きっと想像しているよりいいサービスですよ。
この記事が誰かのお役に立てると幸いです。