AWS Organizationsで始める、クラウド統治の現実解

この記事をシェア

気がつくと、アカウントが 20 個ある

クラウド導入のご相談でうかがう企業を回っていると、しばらく前まではあまり聞かなかった話を、最近よく聞きます。

「いつの間にか、社内に AWS アカウントが 20 個近くあって、誰が何のために作ったのか、もう誰も覚えていないんです」

本番、ステージング、検証、データ分析、新規プロジェクト、退職者が作って置いていったもの──。最初は「事業部ごと、システムごとにアカウントを分けたほうが安全だ」という極めて健全な理由で始まったはずなのに、数年経つと 「全体像を誰も把握していない」 という、別種のリスクへすり替わっていく。私が現場でよく 「アカウントの散らかり問題」 と呼んでいる症状です。

本記事では、この散らかりを「整える」のではなく 「束ねる」 という発想で対処する道具、AWS Organizations を中心に、企業のクラウド統治をどう組み立てていくかを、現場目線でまとめてみたいと思います。SCP、OU、Consolidated Billing、Control Tower、AWS Budgets、CloudTrail といった、よく名前は聞くけれど境界がぼやけがちな登場人物たちを、地続きの 1 枚絵として並べ直すのが目的です。

なぜ、放っておけないのか — 4 つの痛点

「アカウントが増えるくらい、別に困っていない」と感じている方もいるかもしれません。ただ、規模が一定を超えると、次のような痛みが 同時多発的に 効いてきます。スライドや書籍ではよく「メリット」として語られますが、私の感覚では、これは「いずれ必ず来る痛みの予告編」と捉えたほうが、判断を間違えにくいです。

1. 可視性：コストが「どこで」かかっているのか分からない

アカウントが分かれているということは、請求書も操作画面も別々ということです。月次でクラウド費用を集計しようとすると、Excel に各アカウントの CSV を貼り合わせ、タグ付け規約のゆらぎを手で吸収する、という作業が静かに始まります。経営層から「うちのクラウド費用、結局なににいくら使っているの？」と聞かれて、答えが出てくるまで 1 週間かかる、というのは、決して珍しい話ではありません。

2. セキュリティ：守るべきラインを、人手で揃えている

「S3 バケットの全公開は禁止」「IAM ユーザーには MFA 必須」「踏み台以外からの SSH は拒否」。こうした方針を、アカウントごとに個別に設定していくと、必ずどこかで取りこぼしが起きます。それも、悪意ある人間ではなく、業務に追われた優秀なエンジニアが、ほんの一瞬の油断で残してしまう、という形で発生します。「全社の最低ラインを、仕組みで担保する」 ことができていない状態は、年を追うごとに地雷の数を増やしていきます。

3. 運用：アカウントの「発行」が、いつまで経っても職人芸

新しいプロジェクトが立ち上がるたび、誰かが手で AWS アカウントを開き、CloudTrail を有効化し、ログを集約バケットへ流す設定をし、踏み台用ロールを切り、IAM の初期構成を整える──。10 工程くらいの儀式を、ベテランの担当者が手順書を見ながら毎回やっている、という光景をよく見ます。属人化の標本のような工程です。

4. スケール：成長が、そのままガバナンス負債になる

事業が伸びれば、アカウントは増えます。M&A で別会社の AWS 環境を引き継ぐこともあります。成長に比例してアカウントの数が増え、ガバナンスのほつれも一緒に増えていく、というのが、ある程度の規模を超えた企業に共通する構造です。スプロール（散らかり）が放置できない理由は、「いま困っているか」ではなく、「来年いまの 2 倍困るかどうか」で判断すべきだと思います。

AWS Organizations が変えること — 「束ねる」という選択

AWS Organizations は、ざっくり言えば 「複数の AWS アカウントを、1 つの組織として扱う」 仕組みです。中央に 管理アカウント（Management Account） を 1 つ置き、その配下にメンバーアカウントを連ねていきます。論点ごとに、Organizations が解いてくれることを並べると、こんな具合です。

アカウント発行の自動化：API 経由で新規アカウントを払い出せる。手作業の儀式から開放される。
グルーピング（OU）：本番／非本番、事業部 A／事業部 B、といった粒度でまとめ、ポリシーをグループ単位で当てられる。
横断的なポリシー制御（SCP）：「組織全体で、これだけは絶対にやらせない」を 1 か所で宣言できる。
請求の統合（Consolidated Billing）：全アカウントの利用が 1 つの請求書にまとまり、ボリュームディスカウントも組織横断で効く。

もう少しメタな見方をすると、Organizations は 「個別最適のアカウント運用を、組織最適に引き上げるための骨格」 です。アカウントを潰して 1 つにまとめるのではなく、分けたまま、上から束ねる。そこが、ガバナンス施策としては素直だと感じます。

OU 設計：「何で割るか」が運用を決める

Organizations を入れて最初に向き合うことになるのが、OU（Organizational Unit）の設計です。OU はアカウントをまとめる「フォルダ」のようなもので、その単位でポリシーを当てたり、外したりできます。

OU をどう切るかには、絶対の正解はありませんが、私が設計を頼まれたときによく勧めるのは、「軸を 2 〜 3 個に絞り、ツリーは深くしすぎない」 という方針です。具体的には、こんな組み合わせが扱いやすいことが多いです。

環境軸：本番／ステージング／開発／サンドボックス
用途軸：ワークロード／セキュリティ／監査ログ／インフラ共通
事業軸：事業部 A／事業部 B／コーポレート系

注意したいのは、OU は組織図とは別物だということです。組織図にそのまま揃えにいくと、人事異動と部署再編のたびに OU の引っ越しが発生し、SCP の影響範囲が読みにくくなります。OU は「どんなポリシーを当てたい単位か」という観点で切る、と決めておくと迷いが減ります。

SCP — 「やらせない」を仕組みで担保する

OU が定まったら、次は SCP（Service Control Policy） の出番です。SCP は、組織やそのサブ階層に対して、「ここから先は、たとえ管理者でもできない」 という壁を立てるためのポリシーです。IAM ポリシーが「誰に何を許すか」を書くのに対して、SCP は「組織として何を禁じるか」を書く道具と捉えると、頭の整理がしやすいと思います。

現場でよく入れる SCP の例を挙げると、こんなところです。

リージョン制限：業務上使わないリージョンでは、そもそも API を叩けないようにする。シャドー IT 的なリソース立ち上げや、誤操作によるグローバル課金事故を抑えられます。
ルートユーザー操作の制限：日常運用では決して触らせないオペレーションを、組織全体で禁止。
CloudTrail の無効化禁止：監査ログを止める操作そのものをブロック。事故が起きたときに「誰が止めたか」が論点になる事態を構造的に避けます。
暗号化なし S3 バケットの作成禁止、パブリックアクセスの全面禁止：データ流出系の事故の入り口を塞ぐ。

SCP の良いところは、「いざというとき、優秀な担当者の慎重さに頼らずに済む」 点です。人間は疲れていれば操作を間違えますし、新人は知らずに踏みます。設定で禁止しておけば、運用品質を頭数とコンディションに依存させずに済みます。

逆に、注意したい落とし穴もあります。SCP は強力なので、当てる位置を間違えると 「現場が必要な作業まで一切できない」 状況を簡単に作れてしまいます。最初はサンドボックス OU で挙動を確認しながら、ステージング、本番と段階的に展開していくのが安全です。

Consolidated Billing — 請求を 1 つに束ねる

Consolidated Billing（統合請求） は、Organizations に紐づくすべてのアカウントの利用料金を、管理アカウントの 1 通の請求書にまとめてくれる仕組みです。地味な機能名ですが、効き目は大きいです。

支払い窓口の一本化：経理側は「AWS 何件、合計いくら」というシンプルな処理になり、契約担当の手間が一気に減ります。
ボリュームディスカウント：データ転送量や Savings Plans の適用が、アカウントを横断して計算されるため、規模が大きいほど単価が下がりやすくなります。
アカウント単位の内訳：合算した上で、コスト配分タグごと・アカウントごとに分解した内訳を見られる。これが、後述する Budgets と組み合わさると、ぐっと統制が効くようになります。

Excel での自前集計をやめると、それだけで数日／月の作業が消えます。「クラウド費用を、戦略の議論ができる粒度で見る」 ための最低条件と捉えてよいと思います。

Control Tower と Account Factory — アカウント発行を「製品」にする

Organizations だけでも、API でアカウントを払い出すことはできます。ただ、その先にある 「監査ログを集約バケットへ流す」「踏み台ロールを切る」「ベースラインの IAM を入れる」 といった一連の作法を、毎回手で揃えるのは、それなりの労力です。

ここを引き受けてくれるのが、AWS Control Tower と、その中で動く Account Factory です。Control Tower は、Organizations の上に「ベストプラクティスの初期設定」を被せるサービスで、Account Factory はそのうち 「セルフサービスでアカウントを発行する窓口」 にあたります。

イメージとしては、こんな流れになります。

事業部の担当者が、社内ポータル経由で「新規アカウント発行」を申請する。
Account Factory が、組織のテンプレートに沿って新しいアカウントを払い出し、所定の OU に配置する。
同時に、CloudTrail、AWS Config、ログ集約、IAM ベースライン、SCP が自動的に適用される。
担当者には、出来上がった「すぐ使える」アカウントのアクセス情報だけが渡される。

つまり、アカウント発行が 「ベテラン担当者の儀式」から、「社内製品としてのセルフサービス」 に変わるわけです。これが効くと、新規プロジェクトの初動が、目に見えて速くなります。属人化に頼らず、しかも品質が揃う、というのは、運用部門としても評価のしどころでしょう。

AWS Budgets と CloudTrail — 「お金」と「操作」に目を行き渡らせる

束ねる仕組みが整うと、その上で 日々の見張り を組み立てる段階に入ります。ここで主役になるのが、AWS Budgets と CloudTrail です。

AWS Budgets：「予算」をクラウドの言葉で持つ

Budgets は、月次や四半期の予算を設定し、しきい値を超えそうな場合にアラートを飛ばしてくれるサービスです。Organizations と組み合わせると、組織全体・OU 単位・アカウント単位・タグ単位 といった、欲しい粒度で予算を切れます。

現場でよくやる設計はこんな形です。

組織全体の月次予算に、80% / 100% / 120% のアラートを仕込む。
本番 OU と非本番 OU に別々の予算を割り当て、非本番がいきなり跳ねたらすぐ気付けるようにする。
事業ライン別のタグで予算を切り、PL に近い粒度で見えるようにする。

予算が 「経理の Excel」から「クラウドの設定」 に降りてくると、当事者である開発チームが、自分たちの使い過ぎを自分たちで感じ取れるようになります。「使う側」と「払う側」の感覚が一致するのは、コスト統制の出発点です。

CloudTrail：「誰が、いつ、何をしたか」を残す

CloudTrail は、AWS 上のあらゆる API 操作を記録してくれる、いわば クラウドの監査ログ です。Organizations から「組織レベルの証跡（Organization Trail）」を一発で有効化できるのが現代的なところで、メンバーアカウントが個別に CloudTrail を止めることもできなくなります（先ほどの SCP と組み合わせると、より強固です）。

監査ログは、平時にはほとんど誰も見ません。ただ、何かが起きた瞬間、これがあるかないかで状況把握のスピードが桁で変わります。「あのアカウントの S3 が公開になっていた」「誰かが本番の IAM ロールを書き換えた」──。こうした問い合わせに、分単位で答えを出せる体制かどうかは、有事のレピュテーションに直結します。

5 つの観点で、何が手に入るのか

ここまでの道具立てを、最初に挙げた 4 つの痛点に 「スケール」 を 1 本足し、5 つの観点で並べ直すと、Organizations 中心の構成が何をもたらしてくれるのかが見やすくなります。

可視性：Consolidated Billing と Budgets により、組織全体・OU・タグ単位でコストを 1 か所から見られる。経営会議で議論可能な粒度のデータが、定型作業なしで揃う。
セキュリティ：SCP がガードレール、CloudTrail が監査ログ、Control Tower がベースライン。守るべきラインを、人手ではなく仕組みで担保できる。
運用：Account Factory がアカウント発行を製品化し、初動工数を大幅に削る。ベテランの儀式から、セルフサービスへ。
コスト統制：Budgets による予算超過の早期検知と、Consolidated Billing でのボリュームディスカウント。コストを「全社の数字」と「現場の数字」の両軸で扱える。
スケール：OU と SCP の設計が機能していれば、アカウントの増加がそのままガバナンス負債に変わらない。M&A や新規事業立ち上げのスピードに、統治がついてこられる。

個別に見るとどれも当たり前のことに見えますが、これらを 1 つの組織の上で、矛盾なく束ねられる という点に、Organizations の価値があります。逆に、ここを別々のツールで頑張ろうとすると、整合性の維持に運用が引きずられて、本来やるべき仕事に時間が回せなくなりがちです。

次にやること — 導入の第一歩

「うちでも入れてみたい」と思ったとき、最初の一歩で迷う方が多いので、現場感覚で進めやすい順番を書いておきます。いきなり全部を一気にやらなくて構いません。

ステップ 1：現状の棚卸し

まず、いまある AWS アカウントを、すべてリストアップします。発行された経緯、責任者、用途、停止していいかどうか。たいてい、誰のものか分からないアカウントが数個出てきます。ここで「整理」までやろうとせず、見える化に徹するのがコツです。

ステップ 2：OU の試案を 2 〜 3 個作る

環境軸（本番／非本番）と、必要に応じて事業軸／用途軸で、OU の試案を紙の上で書きます。複雑に作り込みすぎず、最初は「本番／非本番／サンドボックス／監査ログ集約用」くらいの粒度から始めるのが現実的です。

ステップ 3：Organizations を有効化し、既存アカウントを招待

本番アカウントから入れるのは怖いので、サンドボックスや検証用のアカウントを 1 〜 2 個から Organizations に組み込みます。OU に配置し、CloudTrail（組織レベル）と Budgets を最初に当てておくのが定石です。

ステップ 4：軽い SCP から始める

いきなり強い SCP を当てると現場が止まるので、まずは 「未使用リージョンの API 拒否」「ルートユーザー操作の禁止」 といった、影響範囲が読みやすく、なおかつ効果の大きいものから入れます。サンドボックス OU で挙動を確認したうえで、ステージング、本番へと広げていきます。

ステップ 5：Control Tower と Account Factory の評価

新規アカウント発行の頻度が月数件以上ある、あるいは今後増える見込みがあるなら、Control Tower の導入を検討します。Account Factory による発行フローをセルフサービス化できると、運用部門の負荷が一段下がります。逆に、年に数件しか発行しないのであれば、Organizations + SCP + 手順書で十分まかなえることも多いです。「使うべきかどうか」は、量で決めると判断しやすいです。

ステップ 6：見張りの定常化

最後に、Budgets のアラート設計と、CloudTrail の保管・監査フローを整えます。アラートを「飛ばすけど誰も見ない」状態にしないために、宛先の Slack チャンネルや、対応フローまでセットで決めておくのがおすすめです。

クラウド統治は、「散らかってから」では遅い

Organizations 周りの話は、技術的に派手な要素が少なく、後回しになりがちです。新しいワークロードを動かしたい、AI のサービスを試したい、というニーズに比べると、どうしても優先度が下がります。

ただ、私が現場で何度も見てきたのは、「散らかってから整える」コストが、「整えてから散らかさない」コストよりずっと高い という、ごく当たり前の事実です。アカウントが 30 個、50 個と増えてからの再編は、関係者調整だけで数か月かかります。

逆に、まだアカウントが片手で数えられるうちに Organizations の骨格を敷いてしまえば、その後の成長は、ガバナンス負債ではなく、「束ねる仕組みの中で増えていくアカウント」 として扱えます。クラウド統治は、規模が小さいうちにやるほど投資対効果が高い、という珍しい領域でもあります。

もし社内で「アカウント、ちょっと多すぎるよね」という会話が出始めているなら、それは Organizations を真剣に検討してよいタイミングだと思います。最初の OU 設計や SCP の置き方は失敗しても十分にやり直せますので、まずは小さく敷いてみるところから始めてみてください。

気がつくと、アカウントが 20 個ある
なぜ、放っておけないのか — 4 つの痛点
AWS Organizations が変えること — 「束ねる」という選択
OU 設計：「何で割るか」が運用を決める
SCP — 「やらせない」を仕組みで担保する
Consolidated Billing — 請求を 1 つに束ねる
Control Tower と Account Factory — アカウント発行を「製品」にする
AWS Budgets と CloudTrail — 「お金」と「操作」に目を行き渡らせる
5 つの観点で、何が手に入るのか
次にやること — 導入の第一歩
クラウド統治は、「散らかってから」では遅い