【AWS】AWS Control Towerについて

公開日時：2023年07月30日　/　最終更新日時：2023年07月30日

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

備忘録として解説します。

AWS Control Tower とは何か？

AWS の複数アカウントをまとめて管理をするために利用します。

1つ1つの AWS アカウントをカスタマイズをして利用する場合は特に不要なサービスです。

しかし最近は4～5人のクラウドエンジニアで10個くらいの AWS アカウントを管理をするようなことがあります。

例えば本番環境、ステージング環境、開発環境、テスト環境。これだけで4個のアカウントに分けることができます。

更に会社の「サービスA」、更に新しい「サービスB」などができたら、合計8個になります。

更に将来会社が発展していけばサービスが5個、6個と増えていくでしょう。

こうなると1個1個の AWS アカウントで細かく個別設定をしていったらクラウドエンジニアがいくらいても足りません。

（現場のクラウドエンジニアからしたらたくさんエンジニアがいればいるほど嬉しいものですが…）

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