AWS Organizationsとは?複数アカウント管理の仕組みを初心者向けに徹底解説

AWSを使い始めると、最初は1つのAWSアカウントで何でもやろうとしがちです。しかし企業で本格的にAWSを使うようになると、「開発環境と本番環境を分けたい」「部署ごとにAWSの利用コストを把握したい」「セキュリティポリシーを全アカウントに一括適用したい」という課題が出てきます。こうした複数アカウント管理の悩みを解決するのが「AWS Organizations」というサービスです。今回は、AWS初心者に向けて、AWS Organizationsの仕組みと活用方法を分かりやすく解説します。

そもそもなぜ複数アカウントが必要なのか

AWSを学び始めた段階では、「アカウントは1つあれば十分では?」と感じるかもしれません。しかし企業規模でAWSを運用する場合、1つのアカウントにすべてを詰め込むと、以下のような問題が発生します。

セキュリティリスクの拡大があります。1つのアカウントの中に開発環境・ステージング環境・本番環境がすべて混在していると、開発者が誤って本番のリソースを操作してしまうリスクがあります。アカウントを分けることで、「このアカウントにアクセスできる人は本番に触れない」という明確な境界を作れます。

コストの見える化が難しいという問題もあります。複数の部署やプロジェクトが1つのアカウントを共有していると、「どの部署がいくら使ったか」を把握するのが難しくなります。アカウントを分けることで、アカウント単位でのコスト管理が可能になります。

障害の影響範囲が広がるリスクもあります。1つのアカウント内で設定ミスや障害が発生した場合、他の環境にも影響が波及する可能性があります。アカウントを分離することで、障害の影響範囲をアカウント単位に限定できます。

このような理由から、企業では「マルチアカウント構成」がベストプラクティスとして推奨されています。

AWS Organizationsとは

AWS Organizationsは、複数のAWSアカウントを一元的に管理するためのサービスです。複数のアカウントをまとめて「組織(Organization)」として管理し、ポリシーの一括適用やコストの一元管理を可能にします。

身近な例で言うと、会社の組織図に近いイメージです。会社全体(組織)の中に、部署(OU)があり、その中に社員(アカウント)がいる、という構造です。会社全体のルール(コンプライアンスポリシーなど)は全社員に適用され、部署ごとのルールはその部署の社員だけに適用される、という形で管理できます。

AWS Organizationsの主要な構成要素

マスターアカウント(管理アカウント)

Organizationsには「管理アカウント」と呼ばれる親アカウントが1つ存在します。このアカウントが組織全体の管理を行い、他のアカウントの作成・招待・管理を担当します。管理アカウントは組織の中で最も強い権限を持つため、アクセス管理には特に注意が必要です。実務では、管理アカウントには日常的な業務用のリソースを置かず、組織管理のみに使うという運用が推奨されています。

メンバーアカウント

管理アカウント以外のアカウントを「メンバーアカウント」と呼びます。メンバーアカウントは、管理アカウントによって作成されるか、既存のアカウントを招待することで組織に参加させます。実際の業務システムやアプリケーションは、このメンバーアカウント上に構築します。

OU(組織単位)

OU(Organizational Unit)は、アカウントをグループ化するための「フォルダ」のようなものです。たとえば、以下のようなOU構成が一般的です。

組織(ルート)
├── 管理系OU
│     └── 管理アカウント
├── 本番環境OU
│     ├── 本番Webアカウント
│     └── 本番DBアカウント
├── 開発環境OU
│     ├── 開発アカウント
│     └── テストアカウント
└── セキュリティOU
      └── セキュリティ監査アカウント

OUにポリシーを適用すると、そのOU配下のすべてのアカウントにポリシーが継承されるため、環境ごとの一括管理が効率的に行えます。

SCP(サービスコントロールポリシー)という強力な機能

AWS Organizationsの最も重要な機能の一つが「SCP(Service Control Policy)」です。SCPは、メンバーアカウントで「できること・できないこと」の上限を設定するポリシーです。

SCPの特徴として、アカウントの管理者(Admin)であっても、SCPで拒否された操作はできなくなるという点があります。つまり、組織全体のセキュリティルールを、各アカウントの管理者が勝手に変更できない形で強制できます。

企業での活用例として代表的なのは以下のようなパターンです。

特定リージョン以外での操作を禁止する設定では、「東京リージョンと大阪リージョン以外でリソースを作成できないようにする」というSCPを組織全体に適用することで、意図しないリージョンへのリソース作成を防げます。データの保管場所を国内に限定しなければならないコンプライアンス要件がある場合などに有効です。

特定のサービスの使用を制限する設定では、「開発環境アカウントではコスト管理のためにEC2の特定のインスタンスタイプしか使えないようにする」といった制限をかけることができます。

S3バケットのパブリックアクセスを禁止する設定では、全アカウントに対してS3バケットのパブリック公開を禁止するSCPを適用することで、設定ミスによる情報漏えいのリスクを組織全体で防ぐことができます。

SCPはIAMポリシーと混同されることがありますが、役割が異なります。IAMポリシーは「そのアカウント内のユーザーやロールに権限を付与する」ものであり、SCPは「アカウント全体として実行できる操作の上限を定める」ものです。SCPで拒否された操作は、IAMポリシーでどれだけ権限を付与しても実行できません。

コスト管理の一元化

AWS Organizationsを使うと、組織全体のコストを一元管理できます。管理アカウントから全メンバーアカウントの利用料金をまとめて確認・支払いができる「一括請求(Consolidated Billing)」機能が標準で利用できます。

一括請求のメリットは支払い管理だけではありません。AWSでは利用量が多くなるほど単価が下がる「ボリュームディスカウント」があります。各アカウントが個別に契約するより、組織全体の利用量を合算することで、より多くのディスカウントを受けられる可能性があります。

また、AWS Cost Explorerを使って「アカウントごとのコスト」「OUごとのコスト」をタグやアカウント単位で可視化できるため、「どの部署がどれくらいAWSを使っているか」を把握しやすくなります。

AWS Control Tower:Organizationsをさらに使いやすくするサービス

AWS Organizationsを自分で一から設定するのはやや複雑です。そこで、マルチアカウント環境のベストプラクティスをまとめて自動セットアップしてくれるサービスが「AWS Control Tower」です。

Control Towerを使うと、以下のような設定を自動的に行ってくれます。

Organizations単体で頑張って設定するよりも、Control Towerを使ってベースを自動構築し、その上でカスタマイズしていくアプローチが、実務では効率的です。

実際の企業でのマルチアカウント構成例

企業が実際にどのようなアカウント構成を取るかをイメージとして整理します。

小規模な企業・スタートアップでよく見られる最小構成は、管理アカウント・本番アカウント・開発アカウントの3アカウント構成です。開発と本番を分離するだけでも、誤操作による本番障害のリスクを大幅に下げられます。

中規模以上の企業では、本番・ステージング・開発・セキュリティ監査・ログアーカイブ・ネットワーク管理など、役割ごとにアカウントを分けた構成が一般的です。セキュリティ監査アカウントは全アカウントのCloudTrailログを集約し、不審な操作を一元的に監視する役割を担います。

まとめ

AWS Organizationsは、複数のAWSアカウントをセキュアかつ効率的に管理するための基盤となるサービスです。SCPによるガードレールの設定、一括請求によるコスト管理、OUを使った階層的な管理など、企業規模でAWSを運用する上で欠かせない機能が揃っています。クラウドエンジニアとしてキャリアを積む上で、マルチアカウント設計の考え方を理解しておくことは、設計力の高さを示す重要なスキルの一つです。まずは「なぜアカウントを分けるのか」という考え方を押さえた上で、SCPとOUの使い方を手を動かしながら学んでいくと理解が深まりやすいと思います。