Organizationsとは？SAAの複数アカウント管理

「アカウントが増えて、管理が回らない」
「請求を1つにまとめられない?」
「全社に同じルールを効かせたい」

本番用、開発用、部署ごと。事業が育つほど、AWSアカウントは増えます。

AWS Organizationsとは、複数のAWSアカウントを束ねる管理サービスのことです。増えたアカウントを1つの組織として扱えます。各アカウントは独立して使いながら、請求とルールは全体でまとめて握れる。「分けて使う自由」と「まとめて統べる統制」を、同時に成り立たせる仕組みです。

この記事では、なぜアカウントを分けるのかを実務の流れで押さえ、増えたアカウントをOUで階層に整え、一括請求とSCPという2本柱でまとめて効かせる仕組みを見ます。SAAのセキュア設計で、そのまま問われる範囲です。

1 1. なぜアカウントを分けるのか
2 2. 増えたアカウントをOUで階層に整える
3 3. 一括請求：支払いを1つにまとめる
4 4. SCP：組織に「越えられない枠」をかける
5 5. SAAで問われる角度
- 5.1 次のステップ

1. なぜアカウントを分けるのか

Organizationsを理解する前に、そもそもなぜ1つにまとめず分けるのかを押さえます。理由はシンプルで、分けたほうが安全で、管理しやすいからです。

1つのアカウントに本番もテストも詰め込むと、テストの操作ミスが本番に波及したり、誰がどこまで触れるかが曖昧になったりします。あなたが分ける主な狙いは、次の3つです。

環境の分離：本番とテストを別アカウントにして、事故の巻き添えを防ぐ
権限の分離：部署ごとに触れる範囲を、アカウント単位で区切る
費用の見える化：どのアカウントにいくらかかったかを把握しやすくする

たとえるなら、本社と複数の支社です。各支社は自分の裁量で日々の業務を回しますが、経理の締めと社内規程は本社が一括で統括します。Organizationsも同じで、各アカウントは独立して動かしつつ、請求と共通ルールは組織の親がまとめて握る形です。

2. 増えたアカウントをOUで階層に整える

アカウントをただ並べるだけでは、数が増えたときに迷子になります。そこでOU（Organizational Unit）という、用途ごとのグループにまとめます。「本番用」「開発用」といった箱に、アカウントを入れて階層化する仕組みです。

OUで束ねる利点は、次に出てくる制限のルールをグループ単位でまとめて効かせられる点にあります。「本番OUには一段厳しいルール」「開発OUには緩めのルール」と、箱ごとに方針を貼れる。アカウントが100個に増えても、「どこに何の方針が効いているか」を階層で追えます。1つ1つのアカウント内部の権限管理は AWS IAMとはでつかめます。

OUの発想は、フォルダ整理に近いものです。ファイルを1か所に山積みにせず、目的ごとのフォルダに分けると、後からまとめて操作しやすくなりますよね。あなたがアカウントをOUに分けておくと、「本番だけ・開発だけ」に一括で方針を適用でき、個別に設定して回る手間が消えます。整理そのものが、統制の効率を決めます。

3. 一括請求：支払いを1つにまとめる

Organizationsで最初に効くのが、一括請求（Consolidated Billing）です。組織に属する全アカウントの利用料を、まとめて1つの支払いにできます。

アカウントごとにバラバラに払う手間が消えるだけではありません。利用量を組織全体で合算するため、使った量に応じたボリューム割引が、全体に効きやすくなります。5つのアカウントで少しずつ使うより、まとめて計上したほうが割引の階段を上りやすい、というわけです。あなたが経理の立場でも、支払い先が1本に集約されるので、月末の突合や部門への費用配分が格段に楽になります。

一括請求のうまみは、「手間の削減」と「割引の集約」の2つです。あなたが支払いを1か所に集めると、全社のコストを1枚のダッシュボードで俯瞰でき、しかも量の恩恵も受けやすくなります。バラバラに使うより、束ねたほうが有利になりやすい設計です。

4. SCP：組織に「越えられない枠」をかける

もう1本の柱が、SCP（Service Control Policy）です。SCPは、アカウントが「できることの上限」を定めるルールで、組織やOU単位でまとめて効かせられます。

ここで、あなたが試験でいちばん狙われる勘どころを先に置きます。SCPは権限を”与える”ものではなく、”上限の枠”を定めるものです。実際に何ができるかは、各アカウント内のIAMが許可した範囲と、SCPが許した枠の両方を満たす重なり（積集合）になります。IAMでフルアクセスを与えても、SCPで禁じた操作はできません。逆に、SCPで枠を広げてもIAMが許していなければ、やはりできない。「SCPだけで操作が有効になる」と誤解すると、そこを突かれます。

具体例で置くと、こうです。「東京リージョン以外は使わせない」というSCPを本番OUに貼れば、そのOU配下のどのアカウントも、たとえIAMで全リージョン許可されていても、他リージョンでは操作できません。ガードレールを組織の側から一括で立てられる——これが、アカウントが増えても統制が破綻しない理由です。

SCPのイメージは、会社の全体規程です。各社員（IAM）に細かい職務権限があっても、その手前に「全社で禁じる行為」の枠が立っている。SCPは、この全体にかかる越えられない枠を担います。暗号化方針など、組織でそろえたい設定の一例は AWS KMSとはで確認できます。

5. SAAで問われる角度

SAAでは、「複数アカウントに統一の統制を効かせたい」という要件で、Organizationsが登場します。あなたが押さえておく角度は3つです。

一括請求：全アカウントの支払いをまとめ、ボリューム割引を集約する
SCP：上限の枠を定める（許可ではない）。実権限はIAMとの重なり
OU：アカウントをグループ化し、ルールをまとめて適用する

要件文に「マルチアカウントの統制」「全社共通の制限」が出たら、あなたはOrganizationsと、この一括請求・SCPの2本柱を思い出せば足ります。「分けて使い、まとめて統べる」——この一言が、設計問題を解くときの背骨になります。細部の用語に迷っても、この芯に立ち返れば選択肢を絞り込めます。

次のステップ

Organizationsがセキュア設計のどこに位置づくかは、AWS SAAの試験範囲と勉強法ガイドで全体像を先に眺めておくと、関連する設計問題との距離感がつかめます。

一括請求とSCPの理解を設問で試すなら、AWS SAA セキュア設計の問題集に当たって、要件の読み解きに慣れておくのが確実です。