AWS Organizationsで始めるマルチアカウント設計 ― 小規模開発チーム向けのベストプラクティス

サービスの開発を進めるにあたり、AWSの初期構築を行いました。

今回は、AWS Organizationsを利用してマルチアカウント環境を構築し、今後TerraformによるIaC（Infrastructure as Code）やGitHub Actionsを利用したCI/CDを前提とした設計を採用しています。

この記事では、実際に構築した構成と、その設計意図をまとめます。

なぜ最初にAWS Organizationsを導入するのか

AWSでは1つのアカウントにすべてのリソースを作成することもできます。

しかし、開発が進むにつれて次のような問題が発生します。

開発環境と本番環境が混在する
誤って本番リソースを削除・変更してしまう
IAM権限が肥大化する
ログやセキュリティを後から分離しにくい
複数案件を運用する際に管理が複雑になる

AWSではこのような課題に対応するため、マルチアカウント構成を推奨しています。AWS Organizations ユーザーガイド

Organizationsとは

AWS Organizationsは、複数のAWSアカウントをまとめて管理するためのサービスです。

OrganizationsにはOU（Organizational Unit）という概念があります。

OUはEC2やS3を配置する場所ではなく、AWSアカウントを整理するためのフォルダのような存在です。

例えば、

Root
├── Infrastructure
└── Workloads

というようにOUを作成し、その中へAWSアカウントを配置していきます。

OUを利用することで、将来的にSCP（Service Control Policies）などのポリシーをまとめて適用できるようになります。AWS Organizations のベストプラクティス

今回採用した構成

今回はAWS Security Reference Architecture（AWS SRA）の考え方を参考にしつつ、小〜中規模の開発チーム向けにシンプルな構成を採用しました。AWS Security Reference Architecture (AWS SRA)

Root
├── Infrastructure
│   ├── Log
│   └── Security
├── Workloads
│   ├── Dev
│   ├── Stg
│   └── Prod
└── Management（管理アカウント）

Infrastructure OU

インフラ運用に必要なAWSアカウントを配置します。

Log

CloudTrailをはじめとする監査ログを集約するためのアカウントです。

AWSではCloudTrailのイベント履歴は標準で90日間参照できますが、長期間保持する場合はS3へ保存する構成が推奨されています。

さらに、一定期間経過後はS3 Glacierへ移行することで保管コストを抑えることができます。

今後はCloudTrailだけでなく、各種監査ログもこのアカウントへ集約する予定です。

Security

Security HubやGuardDuty、AWS Configなどのセキュリティサービスを配置するためのアカウントです。

今回はまだ構築していませんが、

Security Hub
GuardDuty
AWS Config
将来的なCSPM

を集約する予定です。

AWS SRAでも、ログ管理アカウントとセキュリティアカウントを分離する構成が推奨されています。

Workloads OU

アプリケーションを実際に動かす環境です。

今回は

Dev
Stg
Prod

の3つを作成しました。

Dev

Terraformの検証やアプリケーション開発を行う環境です。

Stg

本番リリース前の検証環境です。

Prod

本番環境です。

本番環境を別アカウントにすることで、誤操作や権限設定のミスによる影響範囲を限定できます。

Management Account

Organizationsを作成した最初のAWSアカウントは、自動的にManagement Accountになります。

このアカウントでは、

Organizationsの管理
IAM Identity Center
請求管理

などを行います。

アプリケーションをデプロイするアカウントではありません。

メールアドレスの設計

Organizationsで新しいAWSアカウントを作成する際は、それぞれ異なるメールアドレスが必要になります。

今回はプラスアドレスを利用しました。

これにより、実際には1つのメールボックスで管理しながら、AWSでは別々のアカウントとして扱えます。

IAM Userは作らない

従来はIAM Userを作成してAWSへログインする運用が一般的でした。

しかし現在AWSでは、IAM Identity Center（旧AWS SSO）を利用した認証が推奨されています。IAM Identity Center ユーザーガイド

今後は

人間 → IAM Identity Center
GitHub Actions → OIDC + IAM Role
Terraform → IAM Role

という構成を採用する予定です。

Root Userは緊急時のみ利用します。

今後の構築予定

Organizationsの構築が完了したため、次は以下を進めます。

IAM Identity Centerの有効化
Permission Set（Administrator / ReadOnly）の設計
AWS CLIのSSO設定
TerraformによるIaC
GitHub ActionsとOIDCの連携
CloudTrailのLogアカウントへの集約
Security Hub・GuardDutyの導入

まとめ

AWSは後からでも構成を変更できますが、アカウント構成や権限設計は最初に整えておくほど、運用コストを抑えられます。

今回構築したマルチアカウント構成は、AWSのベストプラクティスやAWS Security Reference Architectureを参考にしつつ、小〜中規模の開発チームでも運用しやすいようにシンプル化したものです。

今後はこの構成をベースに、Terraform・CI/CD・監査ログ・権限管理を組み合わせ、安全で継続的に運用できるAWS環境を構築していきます。

参考資料

この記事をシェア

投稿日: 2026年7月23日

カテゴリ: AWS

タグ:

coiai

この記事もおすすめ

【WSL入門】Ubuntu on WSL2 に開発ツールを一式そろえる — Git / nvm / pnpm / AWS CLI / Terraform

前回の記事では、Windows に WSL2 を導入して Ubuntu が動くところまでを扱いました。ただ、素の Ubuntu はあくまで「まっさらな Linux」です。ここから実際に開発を始めるには、バージョン管理・ランタイム・クラウド操作のツールを自分で入れていく必要があります。この記事では、すべて公式ドキュメントに載っている手順だけを使って、次のツールを順番にセットアップします。各セクションの末尾に出典 URL を置いてあるので、手順が古くなったと感じたらそこを見に行ってください。記事末尾には出典一覧もまとめています。検証環境Windows 11 / WSL2 / Ubuntu 24.04 LTS（x86_64）確認日：2026年7月28日バージョン番号は執筆時点のものです。インストールコマンド自体は基本的に「常に最新を取ってくる」形になっているので、そのまま実行して問題ありません。はじめに：WSL開発の大原則コマンドに入る前に、ひとつだけ。Microsoft の公式ドキュメントが繰り返し書いている重要な原則があります。使う予定のツールと同じ OS 側にファイルを置く。Linux ツールで Linux コマンドラインから作業しているなら、最速のパフォーマンスを出すためにファイルは WSL ファイルシステムに格納します。具体的には、プロジェクトは次の場所に置きます。 /mnt/c/ 配下はファイルシステムをまたぐため、npm install や git status が体感でわかるほど遅くなります。第2弾でこれから入れるツールも、すべて Linux 側のホームディレクトリを前提に使ってください。出典：WSL 開発環境を設定する — Microsoft Learn 1. まずは基本ツール Ubuntu を起動したら、最初にやることはパッケージの更新です。Microsoft の公式ドキュメントにもこう書かれています。ディストリビューションの優先パッケージマネージャーを使用して、パッケージを定期的に更新およびアップグレードすることをお勧めします。Windows […]

WindowsでWSL2をセットアップしてUbuntuを使えるようにする

TerraformやAWS CLI、Dockerを快適に使うために、WindowsにWSL2を導入しました。この記事では、実際に行ったセットアップ手順と、途中で遭遇したエラーへの対処方法をまとめます。なぜWSLを使うのか？ WSL（Windows Subsystem for Linux）は、Windows上でLinux環境を動かすための仕組みです。 AWSやTerraform、Dockerなど、多くの開発ツールはLinux環境との相性が良いため、Windowsで開発する場合でもWSL2を利用するのが一般的です。今回の開発環境では以下のような構成を想定しています。 1. WSLをインストール PowerShell（管理者）を開き、以下を実行します。 2. Ubuntuの初回セットアップ Ubuntuを起動すると、Linuxユーザー名とパスワードの設定を求められます。例好きなユーザー名を入力します。続いてパスワードを設定します。 ※入力中は文字が表示されませんが正常な動作です。 3. パッケージを更新 Ubuntuを起動したら、まず最新状態へ更新します。 4. エラーが表示されたアップグレード中に次のようなメッセージが表示されました。一見エラーに見えますが、今回は最後までと表示され、更新自体は正常に完了していました。 WSLではsystemd関連の処理で、このような警告が表示されることがあります。 5. WSLの状態を確認 PowerShellで以下を実行します。今回はとなっていました。 6. Docker DesktopとUbuntuの違いここで少し混乱しやすいポイントがあります。 Docker Desktopをインストールすると、docker-desktopというWSLディストリビューションが作成されます。しかし、これはDockerが内部で利用するためのもので、普段の開発を行う場所ではありません。おすすめの構成は次の通りです。開発はUbuntuで行い、Docker Desktopはコンテナ実行基盤として利用します。 7. Ubuntuを既定のディストリビューションに変更現在登録されているWSLを確認します。 Ubuntuがインストールされていることを確認したら、を実行します。これでだけでUbuntuが起動するようになります。今後インストール予定 WSL環境では今後以下を導入していきます。この環境をベースに、AWS Organizations、IAM […]

AWS CLIでIAM Identity Center（AWS SSO）を設定する

これまでの記事で、まで構築しました。今回は、ローカルPCからAWSを操作するために、AWS CLIをIAM Identity Center（AWS SSO）へ接続します。これにより、長期アクセスキーを発行せず、安全にAWS CLIやTerraformを利用できるようになります。なぜアクセスキーを使わないのか以前はAWS CLIを利用する際、IAM Userを作成し、を発行していました。しかし、この方法にはいくつかの課題があります。現在AWSでは、人によるAWSへのアクセスには**IAM Identity Center（旧AWS SSO）**を利用することが推奨されています。 IAM Identity CenterとAWS CLIの仕組み AWS CLIは、IAM Identity Centerへログインし、一時的な認証情報（Temporary Credentials）を取得します。つまり、という、安全性の高い認証方式になります。 aws configure sso を実行まずAWS CLI v2をインストールします。インストール後、次のコマンドを実行します。すると、対話形式で設定が始まります。 SSO Session Name ここはローカルPC上だけで利用する設定名です。今回はとしました。好きな名前で問題ありません。 SSO Start URL IAM Identity CenterのアクセスポータルURLを入力します。例このURLは IAM […]

AWS IAM Identity Centerとは？IAM Userを使わないAWS認証・権限管理のベストプラクティス

AWS Organizationsによるマルチアカウント環境を構築した後、次に設定したのがAWS IAM Identity Centerです。以前はAWSへログインするためにIAM Userを作成することが一般的でしたが、現在AWSでは、人がAWSへログインする場合はIAM Identity Centerの利用を推奨しています。今回は、IAM Identity Centerを導入した理由と、実際の設定内容についてまとめます。 IAM Identity Centerとは IAM Identity Center（旧 AWS Single Sign-On）は、複数のAWSアカウントやAWSアプリケーションへの認証・認可を一元管理するサービスです。従来のように各AWSアカウントへIAM Userを作成する必要はなく、というメリットがあります。 AWS Organizationsと組み合わせることで、マルチアカウント環境の運用が大幅に容易になります。なぜIAM UserではなくIdentity Centerなのか以前は、このような構成が一般的でした。しかし、この方法ではといった課題があります。 Identity Centerを利用すると、ユーザー情報は一元管理され、各AWSアカウントには必要な権限だけを割り当てる運用になります。 AWS Well-Architected Frameworkでも、人によるアクセスにはフェデレーション認証を利用し、長期認証情報（IAM Userのアクセスキーなど）をできる限り利用しないことが推奨されています。今回の構成今回は次のようなシンプルな構成にしました。グループ Administrators AWS環境全体を管理するメンバーです。現在はを所属させる予定です。 Developers アプリケーションやインフラ開発を行うメンバー向けです。今回はまだ利用していませんが、開発メンバーが増えた際に使用します。将来的にはなどを割り当てる予定です。 ReadOnly 閲覧専用グループです。監査やレビュー、外部アドバイザー向けとして利用します。今回は技術メンターにReadOnly権限を付与することを想定しています。 Permission […]