// シス担のミカタ
クラウドネットワーキング

マルチアカウントネットワーク設計 まるちあかうんとねっとわーくせっけい

AWS OrganizationsTransit GatewayVPCランディングゾーンネットワーク分離クラウドガバナンス
マルチアカウントネットワーク設計について教えて

簡単に言うとこんな感じ！

クラウドを「部署ごとに別々の部屋（アカウント）」に分けて使う会社で、その部屋どうしをどうつなぐか・どう守るかを設計することだよ。大きなオフィスビルの「フロアレイアウトと内線電話の設計」みたいなイメージ！

マルチアカウントネットワーク設計とは

マルチアカウント構成とは、AWS・Azure・Google Cloudなどのクラウドを1つの会社が複数のアカウント（＝テナント）に分割して利用する構成のことです。たとえば「開発環境用アカウント」「本番環境用アカウント」「セキュリティ監査用アカウント」のように、目的・部署・セキュリティ要件ごとにアカウントを分けることで、権限・コスト・障害の影響範囲を明確に分離できます。

マルチアカウントネットワーク設計とは、こうして分割された複数のアカウントを「どのネットワーク経路でつなぐか」「どのトラフィックを許可・遮断するか」「インターネット出口をどこに集約するか」を体系的に決める設計作業です。ガバナンス（統制）・セキュリティ・運用効率の三つを同時に満たすことが求められます。

大企業がクラウドを本格活用し始めると、アカウント数が数十〜数百に膨れ上がることも珍しくありません。その時点で「アカウントごとにバラバラにネットワークを作っていた」では管理が破綻します。マルチアカウントネットワーク設計は、クラウド移行・DX推進の基盤となるインフラ設計であり、後から変更するコストが非常に大きいため、初期段階での正しい設計が事業継続性に直結します。

マルチアカウント構成の基本構造

構成要素役割代表的なAWSサービス
管理アカウント（Payer）全アカウントの請求・ポリシー管理AWS Organizations
ネットワークハブアカウントVPC間通信・インターネット出口を集約Transit Gateway, AWS Network Firewall
セキュリティアカウントログ集約・脅威検知・監査AWS Security Hub, GuardDuty
共有サービスアカウントDNS・ディレクトリなど共通リソース提供Route 53 Resolver, AWS Directory Service
ワークロードアカウント実際のアプリ・DBなどを動かすVPC, EC2, RDS など

ハブ＆スポーク モデルで覚える

ネットワーク構成の基本形は「ハブ＆スポーク（Hub & Spoke）」です。自転車のタイヤをイメージしてください。中心のハブ（ネットワークアカウント）に全スポーク（ワークロードアカウント）を接続します。スポーク同士が直接話したい場合もハブを経由させることで、経路の見通しが良くなりセキュリティポリシーを一箇所で管理できます。

アカウント分割の主な軸

  • 環境軸：本番 / ステージング / 開発 / 検証
  • 組織軸：事業部 / プロジェクト / 製品ライン
  • 機能軸：ネットワーク / セキュリティ / 共有サービス / ワークロード
  • 規制軸：PCI DSS対象 / HIPAA対象 / 一般業務

歴史と背景

  • 2012年頃：AWSが企業向け利用を本格化。当初は1アカウントで全リソースを管理するケースが多く、権限管理が混乱しやすかった
  • 2016年：AWSがマルチアカウント戦略を公式推奨。「アカウント＝セキュリティ境界」という考え方が広まる
  • 2017年：AWS Organizations リリース。複数アカウントの階層管理・SCP（サービスコントロールポリシー）による一括制御が可能に
  • 2019年：AWS Transit Gateway リリース。それまでVPC間接続に使っていたVPCピアリングをスター型に集約でき、マルチアカウントネットワーク設計が大幅に簡略化された
  • 2020年：AWS Control Tower でランディングゾーン（後述）の自動構築が容易に。Azure Landing Zone・Google Cloud Landing Zoneも同時期に整備
  • 2022年以降：金融・医療・公共機関のクラウド移行加速により、マルチアカウント設計はエンタープライズクラウド導入の必須要件として定着

主要コンポーネントと接続パターン

マルチアカウント ハブ＆スポーク ネットワーク構成 ネットワークハブアカウント Transit Gateway Network Firewall / インターネット出口 本番アカウント VPC (10.1.0.0/16) 開発アカウント VPC (10.2.0.0/16) ステージング VPC (10.3.0.0/16) 共有サービス DNS / Directory セキュリティ ログ集約 / GuardDuty 管理アカウント Organizations / Control Tower インターネット NAT Gateway / IGW AWS Organizations 管理境界

Transit Gateway（TGW）とVPCピアリングの違い

比較項目VPCピアリングTransit Gateway
接続形式1対1（メッシュ）多対多（スター）
アカウント数が増えたとき接続数が爆発的に増加ハブ追加のみでOK
ルーティング集中管理❌ 各VPCで設定が必要✅ TGWルートテーブルで一元管理
帯域幅無制限（同リージョン）最大50Gbps/アタッチメント
コストデータ転送料のみアタッチメント料金＋転送料
推奨規模小規模・数VPC中〜大規模・マルチアカウント

ランディングゾーン（Landing Zone）

ランディングゾーンとは、マルチアカウント環境を安全・標準的に構築するための「初期設定済みの土台」のことです。航空機が安全に着陸できる滑走路を整備しておく、というイメージです。AWSでは Control Tower、Azureでは Azure Landing Zone、GCPでは Google Cloud Foundation としてテンプレートが提供されています。

典型的なランディングゾーンが提供するもの：

  • アカウント階層の自動構築（OU構成）
  • SCPによるガードレール（禁止操作の強制）
  • ログ集約設定（CloudTrail・Config）
  • ネットワーク基本構成（TGW・共有VPC）
  • SSO（シングルサインオン）との統合

IPアドレス設計：マルチアカウントで失敗しやすいポイント

マルチアカウント構成で最も後悔しやすいのが IPアドレス（CIDR）の重複です。VPCピアリングやTGWで接続するVPC同士はIPアドレスが重複していてはなりません。

【CIDR設計例：/8 を組織全体で確保して分割する】

10.0.0.0/8  ← 組織全体で確保
  ├── 10.0.0.0/12   本番環境帯
  │     ├── 10.0.0.0/16   本番アカウントA（VPC）
  │     ├── 10.1.0.0/16   本番アカウントB（VPC）
  │     └── ...
  ├── 10.16.0.0/12  開発環境帯
  │     ├── 10.16.0.0/16  開発アカウントA（VPC）
  │     └── ...
  ├── 10.32.0.0/12  ステージング帯
  └── 10.48.0.0/12  共有サービス帯

後からCIDRは変更できない（VPCの再作成が必要）ため、初期設計で余裕を持たせることが重要です。組織全体のアドレス計画を「IPAMツール（IP Address Management）」で管理することが推奨されます（AWS VPC IPAMなど）。

関連する規格・RFC

規格・RFC番号内容
RFC 1918プライベートIPアドレス空間の定義（10.x.x.x, 172.16.x.x, 192.168.x.x）
RFC 4632CIDR（クラスレスドメイン間ルーティング）の定義
RFC 4271BGP-4（Transit Gatewayのクロスリージョン接続で利用）

関連用語