【AWS】AWS Control Towerについて

最近、複数の AWS アカウントをまとめて管理をすることになったので AWS Control Tower について学習しました。備忘録として解説します。

AWS Control Tower とは何か？

AWS Control Tower は、AWS の複数アカウント（マルチアカウント）をまとめて管理をするために利用します。AWS Organizations を使用して管理する組織向けのマネージドサービスです。1つ1つの AWS アカウントをカスタマイズをして利用する場合は特に不要なサービスです。

しかし最近は4～5人のクラウドエンジニアで10個くらいの AWS アカウントを管理をするようなことがあります。例えば本番環境、ステージング環境、開発環境、テスト環境。これだけで4個のアカウントに分けることができます。

更に会社の「サービスA」、更に新しい「サービスB」などができたら、合計8個になります。更に将来会社が発展していけばサービスが5個、6個と増えていくでしょう。

最終的にガバナンスを効かせ運用することになるとすると、各 AWS アカウントで細かく個別設定をするよりも最初から設計して Control Tower を導入して運用した方が良さそうです。

AWS Control Tower を利用することで数多くの AWS アカウントをまとめて管理することができます。

今までは EC2 インスタンスを「ペット化」して職人芸の技でチューニングしたりカスタマイズをして世界に1台のサーバーを構築していたのが「家畜化」をしてまとめて管理をするといったように変化してきました。

例えば IP アドレス管理帳のようなものを Excel ファイルで作成して Windows で構築したファイルサーバ上で共有ファイルとして保存をする。新規で EC2 インスタンスを構築する時は IP アドレスを払い出してもらい、その IP アドレスを大切に使う。

しかし「EC2 インスタンスならいいけど、ECS でコンテナ環境にするとどうなるんだ？」とか「Auto Scaling にしたらどうなるんだ？」とか Route53 での管理とかクラウドのスピード感についていけなくなり「IP アドレスは変わるもの。EC2 インスタンスは永遠に存在するものではなく都度起動したり停止したりするもの」という考え方になり、最終的には「家畜化」になっていきました。

それと同じような流れが AWS アカウント1つ1つに対しても起こっているわけですね。

各 AWS アカウントごとにカスタマイズをするのではなく、同じ設定を入れる。変わる部分は環境変数で対応すると。サービスだけでなく AWS アカウントレベルでも人間が管理画面からポチポチボタンをクリックして管理するのではなくソフトウェアで管理をするという感じになっていますよね。

この IT インフラをソフトウェアで管理をするという考え方は「SRE（Site Reliability Engineering）」の考え方ですが、AWS アカウントでさえもソフトウェアで管理するのかと思うと、ここ20年くらいのテクノロジーの変化はすごいなと思います。

Sun microsystems の仮想環境を初めて触った時は全く理解できませんでしたが（笑）今はクラウドをソフトウェアで操るのが当然のようになっていますね。

AWS Control Tower の初期設定手順

組織の管理アカウントで Control Tower の管理コンソールにアクセスし、自動生成される「ログアーカイブアカウント」と「監査アカウント」用のメールアドレスを設定します。

次に「ホームリージョン」と「ガバナンス対象リージョン」を設定します。OU 構造と共有アカウントの設定と、CloudTrail の一元化とログ保存期間を設定し、ランティングゾーンのセットアップを開始します。

AWS Control Tower の具体的な機能

AWS Control Tower は各 AWS アカウントのセットアップやガバナンスを一括して自動化してくれるサービスです。

新規で AWS 環境をセットアップするとか、既存環境の AWS 環境を管理する等のオペレーションを自動的にやってくれます。（自動的にやってもらうまでいろいろ設定が必要ですが）

ランディングゾーン

ランディングゾーンは Control Tower が用意するベストプラクティスに基づいて設計された企業向けの標準 AWS 基盤です。別の言葉で言えば、ランディングゾーンはセキュリティとコンプライアンスのベストプラクティスに基づいた、整備済みのマルチアカウント環境です。組織全体の OU、アカウント、ユーザー、各種リソースの土台になります。

企業で AWS を導入すると各チームがバラバラに運用することがあります。しかしセキュリティのリスクや運用の混乱のもとになります。そこで最初にベストプラクティスに基づいた整備済みの基盤を設計・構築します。

既存の Organizations に対して持てるランディングゾーンは1つです。

コントロール（旧ガードレール）

基盤（ランディングゾーン）の上で守らせるルールを言います。AWS 環境全体に継続的なガバナンスを与える高レベルなルールです。以前はガードレールと呼ばれていました。

コントールには以下の3つの種類があります。

• Preventive（予防的）　…　違反する操作・設定を禁止する
• Detective（検出的）　…　違反行為を検出して知らせる
• Proactive（事前的）　…　作成前にチェックして違反ならデプロイさせない

Account Factory

ルールの中で新しいアカウントを量産する払い出し機能（払い出し工場）を言います。

OU で分けることができる

AWS Cotrol Tower を利用すると複数の AWS アカウントを一括して管理ができますが、そうは言ってもちょっとくらい各 AWS アカウントでルールや設定を変えたくなることがあります。

その場合は、OU（Organizational Units）を作り、グルーピングすることによりグループごとに細かく管理をするということもできます。

ここら辺は柔軟ですよね。

AWS Configのルールを活用したい

AWS Config を利用して各リソースの設定をガイドラインに則ったものにしたいです。

• ルールに則っている　←　準拠
• ルールから外れている　←　非準拠

これを全 AWS アカウントでまとめてやろうとすると各 AWS アカウントに Config の設定を入れる必要があります。

しかし数十個も AWS アカウントがあったら面倒くさいですよね。

その場合は AWS Control Tower を活用して一気に全 AWS アカウントに AWS Config のルールを適用させるということもできます。

具体的には AWS Control Tower で Guardrails を作成して、その Guardrails は AWS Config を利用するというイメージです。