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環境を構築していきます。
参考資料
coiai
この記事もおすすめ
この記事を書いた会社
株式会社coiaiは、「想像できることを美しく実現」を掲げ、XR・Web・アプリ・システム開発およびDX支援を行う会社です。 創業2022年、東京都練馬区に本社を置き、要件のヒアリングからPoC（概念実証）、本番運用まで一貫して伴走します。 まずはお気軽にご相談ください。
主なご相談内容
- Webサイト・Webアプリの設計・開発
- スマートフォンアプリ（iOS / Android）の開発
- XR・AR・VRを活用した体験設計・開発
- DX推進・業務システムの企画・開発
- PoC（概念実証）から本番運用までの伴走支援
- マーケティング・コンサルティング
詳しい会社情報は会社概要ページでご覧いただけます。