以前業務でControlTowerと周辺サービスを設計/構築/運用するプロジェクトに参加させていただく、という貴重な機会をいただきました。
その構築・運用と、プロジェクト参画後も個人的にControlTower構築/運用をしていた中で
得た知見、考えたことを書き残していければと思います。
また、構築後は結構手探りだったので、他の人にも知ってほしいな～と思うことを書きました。
・構築の前や構築中、私自身が得た知識や気をつけたこと
・構築後、実運用に沿って改善したところ
・構築後つまずきやすい運用のポイント
このあたりをガチガチに書けるかはわかりませんが、参考程度に見ていってくれると幸いです。
なお、「【マルチアカウント管理】AWSのベストプラクティスを実現できるControlTowerに取り組んでみる」と第された一連の記事、その他私の執筆した記事は全て個人の思考・見解で書かれているものであり、所属している組織などの見解ではないことをご承知おきください
【マルチアカウント管理】AWSのベストプラクティスを実現できるControlTowerに取り組んでみる
目次
①マルチアカウント管理の利点 ←本記事はここ
②ControlTowerの利点（＆実際かかったコストの画像）
③ひとまず構築しながらControlTowerを理解してみよう（手順付）
④SSOユーザー作成→サインインしてマルチアカウント管理を体感しよう
⑤セキュリティ（SecurityHub）の設定をしてみよう
⑥セキュリティ（GuardDuty）の設定をしてみよう
⑦コントロールのざっくり解説＆設定をしてみよう
(+印付きはオプション 現在執筆中です)
+ベストプラクティスとはいえ、構築後に実運用に沿って変えた設定集
+全アカウントのコスト管理を行う
+アカウント管理者を任命したらやること
+SecurityHubをもっと詳しく
もし今回の記事が参考になったり、いいなと思ったら、よろしければストックやいいねしていただけると非常に嬉しいです🙌
あなたのいいねがとっても励みになり、記事を書くモチベになります。
コメントもぜひ、お待ちしております。
なお、構築にあたり参考にした手順は@tonkatsu_oishiさんの以下記事です。
https://qiita.com/tonkatsu_oishi/items/6890ecc24c3b3bf8ee32
また、上記の補強として、もう一つ@gohanparty_humhumさんの以下手順も参考にしております。
https://qiita.com/gohanparty_humhum/items/1b8bcbba0f9a96b71f1d
お二方とも大変勉強になりました、ありがとうございました……！
なるべく参考にした方々とは別の視点を入れ、2025年2月時点の更新情報込みで書いていければと思います。
はじめに~マルチアカウント管理の第一歩~
ここ数年、AWSのベストプラクティスとして 「マルチアカウント管理」 という単語を見かけます。とはいえ見かけても
「いつもスイッチロールすれば事足りる、クロスアカウント管理だしいっか」
「移行の手間かかるだろうし、何の利点があるんだ？」となり、気づけば忘れ……
ーーそれ、今日から始めませんか？
クロスアカウント管理の課題が、マルチアカウント管理で解決するかもしれません……！
| 項目 | クロスアカウント管理 | マルチアカウント管理 |
|---|---|---|
| セキュリティ | 各アカウントの権限・設定管理を追いきれずリスクが高い。 | 各アカウントが独立し、リスクが分散＆一元的に監視 |
| コスト管理 | それぞれの分析・比較が手動かつ煩雑 | Cost Explorerで集約できれば一元的に可視化 |
| コンプライアンス | ログやリソースの追跡が分散しがち | 全アカウントの証跡を集約さえできれば一元的に管理可能 |
| 運用負担 | ロール追加・リソース構築など手間が多い | 初期構築は必要だが、標準化したテンプレートを各アカウントで使用可能 |
| 拡張性 | アカウント/ロール増加につれ上の項目のデメリットが大きくなる | 枠組みを作ってしまえば数が増えても楽な運用 |
クロスアカウントとは
そもそも以前は、下図のようなクロスアカウント管理がベストプラクティスでした。
パッと見は「一つあれば他にスイッチできるし楽で効率的」に見えますが、具体的にはスイッチ先が増えるにつれ以下のような課題があります。
①セキュリティリスクの増加
最小権限から遠ざかってしまい、セキュリティリスクが上がる。
例えば権限が過剰に与えられたIAMロールを共有ロールとしてしまい、本来管理者権限を持つべきでないユーザーも、みんな管理者権限でリソース作成作業などを行ってしまう。
②コストの不透明性
コストの可視化が困難で、プロジェクトやチームごとのコストを正確に、かつ容易に把握するのが難しい。
コスト情報を見るために毎回スイッチロール→CostExplolerからコスト情報取得→それぞれを資料に起こして比較するという手間がある
③ログ管理とモニタリングの課題
アカウント間のアクセス状況がブラックボックス化しやすく、証跡などコンプライアンス要件の遵守が困難になってしまう。
例えば「〇〇-admin-prod」でなにか不審な動きがあっても、そのロールで動きがあったことはわかるものの、ユーザーの個人名を証跡に残せず、具体的に誰が操作したかがわからない。
④手動運用の負担
スイッチロールや権限設定など、多くの操作が手作業に依存しており、効率が悪く、ヒューマンエラーのリスクが高まってしまう
④拡張性の制限
数十、数百のアカウント/ロールをまたぐ運用を行う場合、さすがに全てをスイッチロールで管理するのは難しく、スケーラビリティが著しく低下してしまう
これらデメリットを補うため、マルチアカウント管理で仕組みを整えることが推奨されています。
2017年のAWS Organizationの導入、2018年のre:InventでのAWS ControlTowerの発表をきっかけにマルチアカウントが広く推奨されるようになっていった認識です。
ただマルチアカウントにも課題が……
ざっくりと以下の感じです。（他にもあると思いますが……）
アカウント間の様々な情報を一元的に集約できるようにしないと、結局クロスアカウントと同じデメリットを被ってしまいま。
・アカウント管理が疎かになる
アカウント数が膨らむにつれ、そもそもどのようなアカウントがどのくらいあるのか把握できない。PWなどもわからなくなってしまう
・ユーザーと権限管理が疎かになる
アカウントごとのIAMユーザーや、それに紐づく権限の内容がわからない
・セキュリティ設定/証跡の所在が疎かになる
各アカウントへ設定、証跡が散らばってしまい、一元的な管理が難しくなる
実はもうちょっとあるのですが、情報を一元的に集約し、これら課題も含めて全て補うための対策が AWS ControlTower（と統合可能な各AWSサービス） となります。
ただ、もう少し具体的な課題/ControlTowerの利点は次回以降の記事で記載していきます。
次回はControlTowerを真面目に検討する方向けに、メリットと実際かかったコストをお伝えできればと思います。
ではまた～
次回記事→