AWSアカウント設計の考え方：1アカウント/複数VPCから複数アカウントへ — 何を軸に分けるか

かつては1つのAWSアカウントの中に複数のVPCを並べ、開発・本番といった環境を分けるのが定石でした。いまは AWS Organizations と複数アカウントで分けるのが標準になっています。ただ、これを「昔と今」の年表として覚えても現場では線を引けません。本当に効くのは「何を軸に分けるか」という判断軸です。本記事では、課金・権限・ブラスト半径・サービスクォータ・監査境界という観点から分割の軸を整理し、OU設計・SCP・ログ集約・アカウント間ネットワークの実装までをつなげて解説します。

01なぜ「1アカウント/複数VPC」では足りなくなったのか

小規模なうちは、1つのアカウントに開発用VPCと本番用VPCを置き、サブネット・セキュリティグループ・IAMで環境を仕切る構成でも回ります。問題は、規模と関係者が増えたときに「同じ箱の中」でいろいろなものが混ざってしまうことです。AWS公式は、アカウントを「リソースの入れ物であり、リソース分離の境界」と明確に定義しています。逆に言えば、VPCはネットワークを分けますが、課金・サービスクォータ・IAM権限・監査境界・障害の影響範囲（ブラスト半径）までは分けてくれません。請求の内訳を分離できる単位はアカウントであり、サービスクォータもアカウント単位で割り当てられます。ここに VPC 分割だけで環境を仕切ることの限界があります。

大事なのは、VPCが不要になったわけではない、という点です。環境分離の「主役」がVPCからアカウントへ移った、と捉えるのが正確です。

02アカウントは「分離の箱」：ブラスト半径という発想

マルチアカウントを理解する土台は、アカウントを機能ではなく分離境界として見ることです。AWSはアカウントを「リソースコンテナかつ分離境界」と位置づけ、既定ではアカウント間のアクセスは一切許可されません。共有したいものだけを明示的に許可する——このデフォルト遮断が、事故やセキュリティ侵害の影響を1つのアカウント内に閉じ込めます。これが「ブラスト半径の縮小」です。本番と非本番を別アカウントにしておけば、非本番での設定ミスや権限事故が本番へ波及しません。

03何を軸に分けるか：7つの判断軸

ここが本記事の核です。アカウント分割の軸は1つではなく、実務では次の7つが判断材料になります。多くの場合これらは同じ方向を指し、うまい分割は複数の軸を同時に満たします。迷ったら、最も強い軸は環境（本番/非本番）です。ブラスト半径を分ける効果が最大で、他の軸ともほぼ矛盾しないからです。

逆に「組織の報告ラインをそのまま写す」形の分割は避けるべきです。AWSも、OU（後述）は報告構造ではなく機能や共通の統制で束ねることを推奨しています。組織図は変わりますが、統制の要件は残るからです。

04VPCとアカウントの関係を整理する

「アカウントに移った」という話をVPC不要論と誤解しないことが重要です。VPCは今もアカウントの内側で使い続けます。役割分担はこう整理できます。

つまり、本番アカウントの中で「Web層とDB層のネットワークを分ける」「複数システムをVPCで区切る」といった同一環境内の分割は、今もVPCの仕事です。環境そのものの壁だけがアカウントへ格上げされた、と捉えると設計がぶれません。

05OU設計とSCP：ガードレールの効かせ方

複数アカウントは、OU（Organizational Unit）でグループ化して統制します。AWSは、Root直下に「セキュリティ」「インフラ（共有サービス／ネットワーク）」といった基盤OUと、本番／非本番のワークロードを収める Workloads OU を並列に置くことを推奨しています。本番／非本番の区分は Workloads OU の内側で行うもので、基盤OUの配下に置くわけではありません。ここに開発者の実験用の Sandbox OU なども足していきます。ポリシーは個別アカウントではなくOU単位で当てる方が管理も切り分けも楽になります。

統制の主役が SCP（サービスコントロールポリシー）です。ここで最初に押さえるべきは、SCPは権限を「付与」しないということ。SCPは各アカウントで使える権限の「上限（ガードレール）」を定義するだけで、実際に何ができるかはSCPとIAMのポリシーが両方で許可した部分の論理積になります。加えて、SCPは管理アカウントのユーザー／ロールには効きませんし、利用には Organizations の全機能有効化が必要です。例えば次のように、組織離脱やCloudTrail停止を禁じるガードレールを当てておくと、統制の土台が崩されにくくなります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeaveOrganization",
      "Effect": "Deny",
      "Action": ["organizations:LeaveOrganization"],
      "Resource": "*"
    },
    {
      "Sid": "ProtectCloudTrail",
      "Effect": "Deny",
      "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail"],
      "Resource": "*"
    }
  ]
}

06ログと監査をログアカウントへ集約する

アカウントを分けると、監査証跡が各アカウントに散らばります。そこで、書き込み専用に近いログアーカイブ用アカウントを1つ用意し、全アカウントの CloudTrail（API操作の記録）と AWS Config（リソース構成の履歴）をそこへ集約します。GuardDuty（脅威検知）などはセキュリティ用アカウントに委任管理者を置いて組織横断で集約する構成が定番です。運用担当者が触れない場所にログを保全することで、事故時の調査可能性と改ざん耐性を確保できます。AWSは、セキュリティOUには必要最小限のセキュリティ用アカウントだけを置き、余計なものを混ぜない「クリーンな状態」を保つことも推奨しています。

07アカウント間ネットワーク：Transit Gateway と共有VPC

アカウントを分けると、今度は「アカウントをまたいだ通信」をどうするかが課題になります。定番は、ネットワーク用アカウントに Transit Gateway を置き、AWS RAM（Resource Access Manager）で組織やOUに共有するハブ&スポーク構成です。各ワークロードアカウントは自分のVPCをアタッチできますが、共有された Transit Gateway のルートテーブルは変更できません。これにより、経路制御はネットワークチームに集中させつつ、VPCの中身は各チームが自律的に運用する——中央集権と分散のバランスが取れます。サブネット自体を参加アカウントへ共有する「共有VPC」も選択肢ですが、まずは Transit Gateway 集約から検討するのが素直です。

08PoCで先に踏み抜いた落とし穴

マルチアカウント設計には、あとから効いてくる罠がいくつかあります。EMWでは、これらを本番投入前のPoC・検証段階で意図的に踏み抜いて設計へ反映し、本番での事故を未然に防いでいます（重大障害0を継続）。代表的なものを3つ挙げます。

(1) 管理アカウントにワークロードを載せてしまう。 検証で管理アカウント上に試しにリソースを立てたところ、前述のとおりSCPが管理アカウントには効かないため、ガードレールの外に本番資産が置かれる危険が見えました。AWSも管理アカウントへのワークロード配置を避け、組織管理に必要な用途に限定するよう推奨しています。設計段階で「管理アカウントは統制専用」と決めておくのが正解でした。

(2) SCPの効き方の誤解。 「SCPを付ければ権限が付与される」「ルートに当てれば安全」という思い込みを検証で洗い出しました。実際はSCPは上限を絞るだけで、テストなしにルートへ広く当てたり FullAWSAccess を外したりすると、必要な操作まで一斉に止まります。段階検証用のOUを設けてから展開する運用に切り替えました。

(3) 後からのアカウント分割は高コスト。 1アカウントに複数環境を詰め込んだ状態から後で分けようとすると、データ移行・IAM再設計・依存関係のほどきに大きな手戻りが出ます。検証でこのコストを実測したうえで、境界は最初に設計する方針を徹底しています。分割は「後で困ったら」ではなく「最初に引く」ものです。

関連記事：マルチ/ハイブリッドクラウドを「ID」で束ねる考え方 ／ AWS・Azure・GCP・オンプレ サービス対応表 ／ AWS Organizationsの仕組みと設計