アカウントと組織構造

文書基準: 2026年8月

なぜアカウント構造が重要なのか

オンプレミスで部署ごとにサーバーを分離する理由を考えてみましょう。同じサーバーを共有すると、あるチームのミスが他のチームに影響を与え、コストも区別できず、権限も混在してしまいます。クラウドでも一つのアカウントにすべてのリソースを入れると、同じ問題が発生します。

問題	マルチアカウントで解決される理由
セキュリティ境界の欠如	アカウントが分離単位 — あるアカウントの事故が他のアカウントに波及しない
コスト追跡の困難	アカウント/プロジェクト単位でコストが自動的に分離される
権限管理の複雑さ	アカウント別の独立したIAM + 組織ポリシーで最大範囲を制限
サービスクォータの共有	アカウント別クォータが独立 — 一つのチームが使い切っても他のチームには無関係

これらの問題を解決するため、各ベンダーともマルチアカウント構造を推奨しています。

概念	AWS	Azure	Google Cloud	OCI
組織	Organization	Tenant	Organization	Tenancy
中間グループ	OU (Organizational Unit)	Management Group	Folder	Compartment（入れ子）
分離単位	Account	Subscription	Project	Compartment
リソースグループ	—（タグで代替）	Resource Group	—（ラベルで代替）	—
組織ポリシー	SCP	Azure Policy	Organization Policy	Compartment Policy

Organization → OU → Account

アカウント分離だけでは不十分です。3つの階層が連携して機能する必要があります。

階層	役割	例
アカウント分離	障害/事故のblast radiusを制限	Account、Subscription、Project、Compartment
組織ポリシー（ガードレール）	アカウントが実行できる最大範囲を制限	SCP、Azure Policy、Organization Policy
IAM（権限付与）	ユーザー/サービスに実際の権限を付与	IAM Policy、RBAC、IAM Binding

例: SCPで「許可されたリージョンのみ使用」を設定すると、IAMでどれだけ広い権限を付与しても、他のリージョンにはアクセスできません。

ベンダー	権限境界	コスト境界	関係
AWS	Account	Account	同一 — アカウントを分けるとコストも自動的に分離される
Azure	Subscription	Billing Account / Profile	分離 — 複数のSubscriptionを一つの請求にまとめることが可能
Google Cloud	Project	Billing Account	分離 — Projectを別のBilling Accountに移動可能
OCI	Compartment	Tenancy	分離 — Compartmentで分離し、コストはTenancyで統合

規模	AWS	Azure	Google Cloud	OCI
スタートアップ	3 Account（dev/stg/prod）	1 Subscription + 3 Resource Group	3 Project + 1 Billing Account	3 Compartment
中堅企業	チーム別Account + 共有サービスAccount	チーム別Subscription + Management Group	チーム別Folder + サービス別Project	チーム別Compartmentの入れ子
大企業/公共機関	法人別Orgまたは Billing Transfer	法人別Billing Profile + 中央MG	法人別Billing Account + 中央Org	法人別Tenancy

項目	AWS	Azure	Google Cloud	OCI
コスト配分	タグベース	Resource Group + タグ	ラベル + Project	Compartment + タグ
予算アラート	AWS Budgets	Azure Budgets	Budget Alerts	OCI Budgets
請求移管	Billing Transfer（2025）	Subscription Transfer	Billing Accountの変更	Cross-Tenancy

アカウントごとにリソースの上限があります（リージョンごとのVPC数、インスタンス数、API呼び出し/秒など）。アカウントを分離すると、クォータも独立します。

アカウントを分離すると分離は実現できますが、共有サブネット・中央イメージ・共通DNSなど、アカウント間の共有が必要になる場合があります。

ベンダー	サービス	共有対象の例
AWS	RAM (Resource Access Manager)	サブネット、Transit Gateway、AMI
Azure	VNet Peering + RBAC	VNet、DNS Zone、Image Gallery
Google Cloud	Shared VPC	ホストプロジェクトのサブネット → サービスプロジェクト
OCI	Cross-Tenancy Policy + DRG	VCN、Object Storageバケット

「アカウント一つで十分だ」 — 小規模であってもdev/prodを分離しないと、開発中のミスが本番環境に影響を及ぼします。アカウント分離は規模に関係なく基本です。
「タグさえ付ければコスト追跡ができる」 — タグは付け忘れが起きやすく、強制も困難です。アカウント/プロジェクト単位の分離が最も確実なコスト境界です。
「後で構造を変えればよい」 — リソースが蓄積した後にアカウント構造を変更するのは、マイグレーションに相当する作業です。初期に設計する方がはるかに容易です。