マルチアカウント構成の設計 — アカウントをどの単位で分けるか

マルチアカウント構成で最初に問われるのは「どの軸でアカウントを分けるか」という判断です。環境・チーム・課金のどれを分割の主軸に置くかを誤ると、後から再設計するコストは当初の3倍以上に膨らむことがあります。本記事では、現場で繰り返される設計の失敗パターンを踏まえながら、アカウント分割の判断基準・上位統制の引き方・共有リソースと分離リソースの境界線を体系的に解説します。

単一アカウントで走り続けると統制が効かなくなる構造

IAMポリシーの肥大化と権限境界の崩壊

単一アカウントで開発・ステージング・本番の3環境を運用し始めた場合、最初の数か月は問題が表面化しません。チームが5名を超え、リソース数が50件を越えるあたりから、IAMポリシーの管理は一気に難しくなります。各チームが「自分たちのリソースだけ操作できればいい」という要件を持ち込むたびに、ポリシーの条件節（Condition）が複雑化し、半年後には誰も全体像を把握できない状態に陥ります。その結果、「安全のために広めの権限を付与しておく」という逆の判断が常態化し、最小権限の原則は形骸化します。開発者が本番S3バケットを誤って削除するインシデントは、この構造から生まれる典型例です。

本番と開発リソースの混在がもたらすリスク

AWSのリソースタグによる区別は「区別しやすくする」仕組みであって、「物理的に分離する」仕組みではありません。タグに基づくIAMポリシー（Resource-based）はバイパスされやすく、オペレーションミスに対する防護壁として過信するのは危険です。また、本番リソースと開発リソースが同一アカウントに混在すると、CloudTrailのログも混在します。インシデント発生時に「どのログが本番操作のものか」を判別するだけで余分な時間を取られ、構築を任されたある担当者が経験したケースでは、この混在が原因でインシデント調査に3日を要しました。タグ運用を徹底しても、この構造的な問題を解消することはできません。

課金の把握が破綻するタイミング

コスト配分タグを徹底していても、単一アカウントでは「タグが漏れたリソース」の費用が宙に浮きます。プロジェクト数が10を超えると、漏れたコストの集計・按分作業が月次で8〜12時間を消費するという話が現場ではよく聞かれます。さらに、あるプロジェクトのコスト急増が別プロジェクトの予算超過アラートを誤発火させ、全体の把握を難しくするケースも起きます。これは単一アカウントの構造的な限界であり、タグ運用の精度を上げても根本解決にはなりません。アカウント分割による物理的な課金の分離が、唯一確実な対策です。

環境・組織・課金のどの軸でアカウントを分けるか

環境軸（本番／ステージング／開発）で分ける設計判断

環境ごとにアカウントを分ける構成は、最も広く採用されるベースラインです。本番・ステージング・開発の3アカウント構成が出発点になります。この構成の核心は「本番への誤操作を構造的に防ぐ」点にあります。開発アカウントのIAMロールは本番アカウントのリソースに触れない設計になるため、設定ミスの影響範囲が物理的に限定されます。ただし、この軸だけで設計すると、チームが増えたときに1つの開発アカウントをすべてのチームが共有することになり、再びIAMの混乱が起きます。環境軸は分割の必要条件ですが、単体では十分条件になりません。組織の成長に合わせた追加分割を前提とした設計が求められます。

組織軸（チーム・プロダクト・事業部）で分ける設計判断

チームやプロダクト単位でアカウントを分ける構成は、自律的なデプロイと明確な責任境界を実現します。あるプロダクトのデプロイが別プロダクトに影響を与えない設計は、マイクロサービスを運用するチームで特に重要です。ただし、この軸で分けると「環境の概念」をどこに入れるかという問題が残ります。チームごとに本番・ステージング・開発を用意するなら、チームが5つあれば最低15アカウントが必要になります。環境軸と組織軸を両方適用するときは、どちらを上位の分割軸にするかを先に決めなければ、OU階層の設計に一貫性が生まれません。この優先順位の決定が、後の設計ブレを防ぐ鍵になります。

課金軸で分けるのが有効なケース

課金の分離を主目的にアカウントを分ける判断は、事業部・顧客・プロジェクトごとに確実なコスト帰属が求められる場面で有効です。AWS Organizationsの統合請求と組み合わせることで、アカウント単位の費用が自動的に分離され、タグ漏れや按分ミスのリスクをほぼ排除できます。ただし、課金軸のみで分けると環境分離や組織分離の目的を達成できません。「課金のためだけにアカウントを増やす」という判断は、管理コストのみが増える結果になります。課金軸は、環境軸・組織軸と組み合わせて用いる補助的な判断材料として扱うのが適切な位置づけです。

比較表：単一／環境別／チーム別アカウント構成の向き不向き

構成パターン	向いているケース	向いていないケース	主な落とし穴
単一アカウント	PoC・個人開発・5名以下の小規模チーム・本番運用なし	複数チーム・本番運用・コンプライアンス要件あり・プロジェクト数10以上	IAM肥大化、本番誤操作、課金按分困難、ログ混在によるインシデント調査遅延
環境別アカウント（本番／ステージング／開発）	単一プロダクト・チームが少数・環境間の分離が最優先	チームが4つ以上・マイクロサービス・プロダクト間の責任分離が必要	開発アカウントが再び共有化されIAMが混乱する。組織成長に伴い再設計が必要になる
チーム／プロダクト別アカウント	自律的デプロイが必要・マイクロサービス・明確なコスト帰属が求められる	チーム間で共有リソース（VPC等）が多い・運用担当者が少ない・導入初期	アカウント数×環境数で管理対象が爆発する。運用体制が追いつかなくなる
ハイブリッド（環境軸＋組織軸）	中〜大規模・複数プロダクト・コンプライアンスと自律性を両立したい	分割軸の優先順位が未決定・IaCによる自動化が整っていない段階	分割軸の優先順位が曖昧なまま設計すると整合性が崩れ、再編コストが3倍以上になる

ガードレール（統制）を上位で効かせる設計判断

管理アカウント（ルートOU）の設計思想

AWS Organizationsを利用するマルチアカウント構成では、管理アカウントに本番ワークロードを一切置かないことが設計の大前提です。管理アカウントはOrganizationsの操作・SCPの定義・統合請求の管理に特化させます。ここにリソースを作り始めると、後から切り離すコストが非常に大きくなります。管理アカウントへのアクセスは、緊急時のbreak-glassアクセスを除き、通常の開発者には付与しないポリシーを組織レベルで定めておく必要があります。管理アカウントのルートクレデンシャルは多要素認証を必須とし、物理的に保管場所を分けるのが現場の慣例です。この設計を最初に固めておくことで、組織のOU階層を後から追加・変更する際の影響範囲を最小化できます。

SCPの適用範囲と設計の落とし穴

SCP（サービスコントロールポリシー）はOU（組織単位）に対して適用されるため、どのOU階層に何のポリシーを当てるかの設計が重要です。よくある落とし穴は「全体OUに過剰な制限をかけて、開発者の正当な作業が止まる」ケースです。本番OUには特定リージョン外のリソース作成禁止・パブリックS3バケット作成禁止・MFAなしのルートアクセス禁止などを厳しく適用し、開発OUには最低限の制限に留める、という段階的な設計が現場で機能しやすいです。SCPは「最大権限の上限を定める」仕組みであり、IAMポリシーの代替ではありません。この役割を混同すると、制御できているつもりで実際には抜け穴が生まれるため、IAMポリシーとSCPの責任範囲を設計書に明記しておくことが重要です。

ログ・監査基盤を共有サービスアカウントに集約する判断

CloudTrailのログ・セキュリティイベント（GuardDuty等）・Config記録は、各アカウントで個別管理するのではなく、ログアーカイブ専用アカウントに集約する設計が標準です。各アカウントのログを集約アカウントのS3バケットに転送し、集約アカウント自体へのアクセス権を最小化することで、ログの改ざんリスクを下げられます。「ログアーカイブアカウント」と「セキュリティ監査（Security Tooling）アカウント」を分けるかどうかは、コンプライアンス要件の強度によって判断します。SOC2対応やISO27001が求められる環境では、それぞれの担当者が異なるケースもあり、アカウントを分けて権限を分離しておく構成が安全な選択になります。集約設計を後から追加するには全アカウントの設定変更が必要になるため、初期設計で盛り込んでおく判断が重要です。

共有リソースと分離リソースの境界の引き方

ネットワーク（VPCとTransit Gateway）の共有か分離か

ネットワークを共有するか分離するかは、マルチアカウント設計の中で最も議論が多い判断の一つです。Transit Gatewayを使って各アカウントのVPCをハブ・アンド・スポーク型で接続する構成は、共有NATゲートウェイや共有踏み台サーバーの運用コストを削減できます。一方で、アカウント間でネットワークが接続されることで、あるアカウントからの意図しない通信が別アカウントに到達するリスクも生まれます。本番VPCと開発VPCをTransit Gateway経由で接続することは、セキュリティ境界を崩す判断であり、原則として避けるべき設計です。ネットワーク共有の範囲は「同じセキュリティ境界内にあるアカウントのみ」に絞るのが安全な基準になります。この判断を設計初期に文書化しておくことで、後からの接続追加依頼を設計基準として断れる体制が整います。

認証・シークレット管理の共有と分離

IAMロールのクロスアカウントアクセスとSecrets Managerの共有は、設計によっては便利に見えますが、環境間の壁を溶かすリスクがあります。開発者が開発用のロールからAssumeRoleを経由して本番のシークレットにアクセスできる設定は、意図せず「環境分離を無効化する」設計になります。シークレットは原則としてアカウントごとに分離して管理し、クロスアカウントのアクセスは明示的に必要と判断した場合のみ許可する設計が安全です。シークレットのローテーションをどのアカウントに置くか（共有サービスアカウントか各アカウントか）は、運用担当者の体制とあわせて決める必要があります。自動ローテーションが止まっても誰も気づかない状態を防ぐ監視設計も、あわせて検討します。

DNSと証明書管理の配置判断

Route53のホストゾーン管理を集中するか分散するかは、ドメイン構造とチームの自律性のバランスで決まります。親ドメインをネットワーク共有アカウント（またはプラットフォーム共有アカウント）に置き、サブドメインの委任（Delegation）を各チームのアカウントに行う構成は、多くのケースで有効な判断です。ACMの証明書はリソースを使うリージョン・アカウントに作成する必要があるため、集中管理が難しく「誰が証明書の更新を管理するか」の運用設計を先に決めておかないと、更新漏れによる本番障害につながります。Route53ホストゾーンとACM証明書の責任者を一覧化し、更新アラートの通知先を明確にしておくことで、設計を後から見直す手間を省けます。

分けすぎて運用が回らなくなる境界の見極め

アカウント数が増えると発生する管理オーバーヘッド

アカウントが増えるほど、各アカウントへのSSOプロビジョニング・セキュリティベースラインの適用・コスト監視の設定・ログ集約の設定など、1アカウントあたりの初期セットアップコストが積み上がります。TerraformなどのIaCで自動化を徹底しても、アカウント1個あたり初期構築に2〜4時間の作業は見込む必要があります。チームが5名以下の運用体制で20アカウントを超えると、セキュリティ設定の更新やパッチ適用が追いつかなくなるケースが現場では報告されています。「アカウントを分ければ分けるほど安全になる」という感覚は、運用の実態と乖離します。管理できないガードレールは、実質的にないのと同じです。分割の意思決定には、必ず運用体制の規模と照らし合わせる工程が必要です。

統合と分離のバランスを決める判断基準

アカウントを分ける判断の材料として、「このアカウントが侵害されたとき、被害範囲を他のリソースから切り離せるか」という問いが有効です。侵害時にアカウントを即座に隔離・削除できる設計になっているなら、分離の投資は正当化されます。逆に、共有しているリソースが多すぎて隔離が現実的でないなら、アカウントを分けた意味が薄れます。もう一つの判断基準は「担当チームが独立したデプロイサイクルを持っているか」です。デプロイのタイミングや頻度が大きく異なるチームを同じアカウントに同居させると、変更管理が複雑になり、片方のデプロイがもう片方の運用を止めるリスクが生まれます。この2つの問いに「どちらもNO」であれば、アカウントを統合する方向で検討する判断が合理的です。

マルチアカウント設計チェックリスト

1. アカウント分割の主軸を「環境・組織・課金」のどれにするか決定し、OU階層の設計に反映している
2. どちらを上位の分割軸にするか（環境優先か組織優先か）を明示し、設計書に記録している
3. 管理アカウントにはワークロードリソースを置かず、Organizations管理・SCP適用・統合請求の専用アカウントとして運用する設計になっている
4. SCPは「本番OU」「開発OU」「共有サービスOU」で適用範囲とルールを分けて設計しており、過剰制限による開発者ブロックのリスクを評価している
5. ログアーカイブ専用アカウントを設け、CloudTrail・GuardDuty・Configのログを集約する設計になっている
6. ネットワーク（Transit Gateway／VPC Peering）の接続範囲を「同一セキュリティ境界内」に絞り、本番と開発を接続しない設計にしている
7. シークレットはアカウントごとに分離して管理し、クロスアカウントアクセスは例外的・明示的な許可のみにしている
8. Route53のゾーン委任・ACM証明書の更新責任者を一覧化し、更新アラートの通知先が明確になっている
9. アカウント1個あたりの初期構築・継続運用コストを見積もり、運用チームの体制でカバーできる上限アカウント数を確認している
10. アカウントが侵害された場合に即座に隔離・削除できる設計か、共有依存関係が隔離を妨げていないか確認している
11. IaCテンプレート（Terraform等）でアカウントの初期セットアップを自動化し、セキュリティベースラインの適用漏れが起きない仕組みになっている
12. チームのデプロイサイクルが独立しているかどうかを基準に、統合か分離かを再評価するタイミングをロードマップに組み込んでいる