この記事は、 「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」 の第38回です。
第36回ではオンプレミスとクラウドをVPNで接続する方法、 第37回では専用線によるクラウド接続を学びました。 今回はクラウド環境が増えたときに、 複数のネットワークをどう集約し、どう分離するかを考えます。
複数クラウド・複数アカウント接続とは？
ハブ＆スポーク・経路制御・設計ポイントを解説
クラウド利用が拡大すると、 「VPCやVNetを1つ接続すれば終わり」ではなくなります。 本番・開発環境、部門、子会社、AWS・Azure・Google Cloud、 オンプレミスなど、多数のネットワークを安全かつ運用しやすく接続する設計が必要です。 今回は、複数クラウド・複数アカウント環境を設計するときの基本的な考え方を学びます。
クラウド環境を使い始めたばかりの企業では、 1つのクラウドアカウントに1つの仮想ネットワークだけ、 という構成も珍しくありません。
しかし利用が拡大すると、 本番用、開発用、検証用、共通基盤用、部門用などに環境を分けるようになります。 さらにAWSとAzureを併用したり、オンプレミスも残したりすると、 ネットワーク同士の接続関係は急速に複雑になります。
そこで重要になるのが、 「すべてをつなぐ」のではなく、「必要な通信だけを整理してつなぐ」 という設計です。
この記事を読み終えるとできること
- 複数アカウントに分ける理由を説明できる
- フルメッシュ接続の問題点を説明できる
- ハブ＆スポーク構成を説明できる
- 共有サービス用ネットワークを設計できる
- 本番・開発環境を経路レベルで分離できる
- IPアドレス重複のリスクを説明できる
- マルチクラウド接続方式を比較できる
- 設計理由を顧客へ説明できる
複数クラウド・複数アカウント接続とは
複数クラウド・複数アカウント接続とは、 複数のクラウド環境や管理単位に存在するネットワークを、 必要な通信だけ許可しながら相互接続するネットワーク設計です。
ここでいう「複数アカウント」は、 AWSだけを意味するものではありません。
| クラウド | 主な管理単位の例 | 仮想ネットワークの例 |
|---|---|---|
| AWS | Account | VPC |
| Microsoft Azure | Subscription | Virtual Network |
| Google Cloud | Project | VPC Network |
企業では、これらを1つだけ利用するとは限りません。
企業ネットワークが複雑化するイメージ
このとき必要なのは、 単純に「相互通信できる状態」にすることではありません。
- 本番環境から開発環境へ通信させるのか
- 開発環境から本番DBへ接続できてよいのか
- インターネット接続を各環境に持たせるのか
- DNS・NTP・監視・認証などを共通化するのか
- オンプレミスへの経路をどこへ集約するのか
- クラウド間通信を直接行うのか
重要： 複数アカウント設計では、 「何を接続するか」と同じくらい 「何を接続しないか」が重要です。
なぜクラウド環境を複数アカウントへ分けるのか
「管理が面倒なら、すべて1つのアカウントへ置けばよいのでは？」 と考えるかもしれません。
しかし実務では、 セキュリティや運用の境界を作るために環境を分離することがあります。
本番と開発を分離する
開発者の操作ミスや設定変更が、 本番システムへ影響する範囲を小さくします。
部門・システムごとに責任を分ける
管理者、予算、変更権限、運用責任などの境界を明確にできます。
セキュリティ境界を作る
重要システムと一般システムを異なる管理単位に分離できます。
障害や誤操作の影響範囲を限定する
1つの環境で発生した設定ミスが、 全社環境へ広がるリスクを減らします。
コストを把握しやすくする
システム・部門・環境単位で利用料金を整理しやすくなります。
会社・組織の境界を分ける
子会社、海外拠点、共同プロジェクトなどを 別の管理境界として扱えます。
アカウントを分けることと、ネットワークを分離することは同じではありません。
管理単位を分けても、ネットワーク接続を許可すれば通信できる構成を作れます。 逆に、同じクラウド環境でもルーティングやセキュリティ制御によって 通信を分離できます。
ネットワークが増えると何が難しくなるのか
2つのネットワークを接続するだけなら、 接続関係は非常に単純です。
2ネットワークなら接続関係は1本
しかしネットワーク数が増えるほど、 接続、ルート、セキュリティルール、監視対象も増えていきます。
特に確認すべきなのは次の項目です。
- どのネットワークとどのネットワークが通信するか
- 経路情報をどこで管理するか
- インターネット接続をどこへ置くか
- オンプレミス接続をどこへ置くか
- ファイアウォールをどこへ配置するか
- DNS・NTP・認証などの共通機能をどこへ置くか
- ログをどこへ集約するか
ネットワークが増えたときに、 その場しのぎで1本ずつ接続を追加すると、 数年後には「誰も全体の通信経路を説明できない」構成になりやすくなります。
すべてを直接接続するフルメッシュ構成の問題
各ネットワークを直接相互接続する方法を考えてみましょう。
フルメッシュ接続のイメージ
実際のフルメッシュでは、各ネットワーク間に多数の接続関係が発生します。
少数であれば直接接続でも管理できます。 しかし規模が拡大すると、次の問題が発生します。
| 問題 | 内容 |
|---|---|
| 接続数の増加 | ネットワーク追加のたびに既存環境との接続設定が増える |
| ルート管理の複雑化 | 各接続で個別に経路を管理する必要がある |
| セキュリティ制御の分散 | 通信制御が各所に分散し、全体像を把握しにくい |
| 運用負荷 | 追加・削除・変更時の確認箇所が増える |
| トラブルシューティング | 実際にどの経路を通っているか追跡しにくくなる |
環境数が増える場合は、 個別接続を増やすよりも 接続を集約するポイントを作る考え方が重要になります。
ハブ＆スポーク構成で接続を集約する
ハブ＆スポークとは、 中央のハブへ複数のネットワークを接続し、 ハブを中心に通信や経路を管理する構成です。
ハブ＆スポーク構成
HUB
ハブが担当する役割
- スポーク間のルーティング
- オンプレミスへの経路集約
- 他クラウドへの接続
- ファイアウォールによる通信検査
- 共有サービスへのアクセス
- 経路の分離・制御
スポークが担当する役割
スポーク側には、 業務システムやアプリケーションなどのワークロードを配置します。
たとえば、
- 販売システム
- 会計システム
- 開発環境
- データ分析環境
- 部門別システム
などです。
ハブ＆スポークの目的は、 すべての通信を許可することではありません。
中央に集約することで、 「本番→共有サービスは許可」 「開発→本番は拒否」 といった通信方針を整理しやすくすることが目的です。
本番・開発などの経路を分離する
ハブへ接続すると、 すべてのスポーク同士が自由に通信できるようにする必要はありません。
むしろ実務では、 経路テーブルを分けて通信可能範囲を制御する ことが重要です。
| 送信元 | 宛先 | 通信方針例 |
|---|---|---|
| 本番 | 共有サービス | 許可 |
| 開発 | 共有サービス | 許可 |
| 本番 | 開発 | 原則禁止 |
| 開発 | 本番DB | 禁止 |
| 本番 | オンプレミス業務システム | 必要ポートのみ許可 |
ルーティングとファイアウォールは役割が違う
ここで重要なのが、 経路制御とセキュリティ制御を混同しないことです。
| 制御 | 主な役割 |
|---|---|
| ルートテーブル | 宛先へどの経路で到達するかを決める |
| Firewall / Security Policy | 通信を許可・拒否する |
セキュリティ上重要な通信については、 「ルートがないから通信できない」だけに依存せず、 ファイアウォールなどでも明示的に制御する設計を検討します。
ルーティング設計の基本については、 「13. ルーティング設計」 もあわせて確認してください。
複数クラウドで特に重要なIPアドレス設計
複数クラウド・複数アカウント設計で、 後から問題になりやすいのが IPアドレスの重複です。
例
AWS本番：10.10.0.0/16
Azure本番：10.10.0.0/16
この2つを後から接続しようとすると、 「10.10.1.20」がどちらのクラウドに存在するのか 単純なルーティングでは判断できません。
最初から全社IPアドレス計画を作る
| 用途 | アドレス例 |
|---|---|
| オンプレミス | 10.0.0.0/12 |
| AWS | 10.16.0.0/12 |
| Azure | 10.32.0.0/12 |
| Google Cloud | 10.48.0.0/12 |
実際のアドレス範囲は、 現行環境や将来計画に合わせて決定します。
大切なのは、 クラウドごとに担当者が勝手にCIDRを決めないことです。
サマライズできるようにする
アドレスを規則的に割り当てると、 経路情報を集約しやすくなります。
たとえばAWS環境の複数ネットワークを 1つの大きなプレフィックスへまとめられれば、 オンプレミス側へ大量の細かい経路を通知せずに済む場合があります。
IPアドレス設計については、 「11. IPアドレス設計」 も復習してください。
AWS・Azureなど複数クラウドをどう接続するか
ここまでの「複数アカウント」は、 同一クラウド内だけでも発生する問題でした。
次に、 AWSとAzureなど異なるクラウドを利用する マルチクラウドを考えます。
方式1：オンプレミスを経由する
オンプレミス経由
既存WANやデータセンターを中心に構成できる反面、 AWSからAzureへ通信するだけなのに オンプレミスを経由する非効率な経路になる可能性があります。
方式2：クラウド間をVPNで接続する
クラウド間VPN
比較的導入しやすい方式ですが、 インターネット経由となる場合は、 帯域、遅延、可用性、VPN装置やゲートウェイの制約を確認します。
方式3：専用線・接続サービスを利用する
大容量通信や安定した接続が必要な場合は、 通信事業者やクラウド接続サービスを組み合わせ、 複数クラウドへの閉域接続を集約する方式も検討できます。
専用線接続の考え方は、 「37. 専用線接続の基本」 で詳しく解説しています。
方式4：クラウドWAN・SD-WANなどで集約する
拠点、クラウド、データセンターが多数存在する場合は、 中央のネットワーク基盤から接続を統合する設計も候補になります。
| 方式 | メリット | 注意点 |
|---|---|---|
| オンプレ経由 | 既存構成を利用しやすい | 遠回りの通信経路になりやすい |
| クラウド間VPN | 比較的導入しやすい | 性能・冗長化・運用確認が必要 |
| 専用線・閉域接続 | 大容量・安定性を確保しやすい | 費用・納期・冗長化設計が必要 |
| 統合WAN基盤 | 多拠点・多クラウドを集約しやすい | 製品依存・コスト・設計複雑度を確認 |
主要クラウドのハブ型サービスをイメージする
クラウドによってサービス名は異なりますが、 「複数ネットワークを中央へ集約する」という考え方には共通点があります。
| クラウド | 代表的な仕組み・サービス例 | 考え方 |
|---|---|---|
| AWS | Transit Gateway | 複数VPCやオンプレミス接続を中央のトランジット基盤へ集約 |
| Microsoft Azure | Hub-Spoke / Azure Virtual WAN | Hubを中心に複数VNetや拠点接続を集約 |
| Google Cloud | Network Connectivity Center | HubとSpokeの考え方で複数ネットワーク接続を集約 |
上級編ではサービス名の暗記よりも、 「中央集約」「経路制御」「分離」「共有サービス」 という設計原則を理解することを優先してください。
セキュリティ検査をどこで行うか
ハブ型構成を採用するときは、 通信をハブへ集約するだけでなく、 どの通信をファイアウォールへ通すか も設計します。
中央ファイアウォールを経由させる例
中央集約のメリット
- セキュリティポリシーを統一しやすい
- ログをまとめやすい
- 各スポークへ個別にFWを配置する必要を減らせる
- 通信経路を監査しやすい
中央集約の注意点
- ファイアウォールがボトルネックにならないか
- 障害時の影響範囲が大きくならないか
- 冗長化されているか
- 通信が遠回りにならないか
- クラウド内の通信料金が増えないか
- 戻り通信が同じ検査経路を通るか
「中央FWを導入したのに、一部の戻り通信が別経路を通る」 という非対称ルーティングは、 ステートフルファイアウォールを利用する構成で 通信障害につながることがあります。
複数クラウド・複数アカウント接続で決める設計項目
実際の設計では、 次の順番で整理すると考えやすくなります。
- 管理単位を整理する 本番、開発、共有サービス、部門、子会社など、 どの単位で環境を分けるか確認します。
- 通信要件を整理する どこからどこへ、何の通信が必要なのかを一覧化します。
- IPアドレスを整理する 現在と将来のクラウド利用を考慮し、 重複しないCIDRを割り当てます。
- 接続方式を決める 個別接続、ハブ＆スポーク、VPN、専用線などを比較します。
- ルーティングを設計する 経路伝播、スタティックルート、BGP、 デフォルトルートなどを決めます。
- セキュリティ境界を設計する 本番・開発、社内・外部など、 通信を許可する境界を定義します。
- 共有サービスを設計する DNS、NTP、認証、監視、ログなどを 共通化するか個別配置するか決めます。
- 冗長化と障害時経路を設計する ハブ、VPN、専用線、FWなどの障害時に どの経路へ切り替わるか確認します。
- 運用方法を決める 誰が経路追加を承認し、 誰が接続変更を実施するのかを明確にします。
- 監視・ログを設計する 接続状態、経路、通信量、FWログなどを どこで監視するか決めます。
通信マトリクスを作る
複雑な環境では、 構成図だけで通信要件を管理しようとすると限界があります。
そこで、次のような通信マトリクスを作成します。
| 送信元 | 宛先 | 用途 | Protocol / Port | 経路 | 許可 |
|---|---|---|---|---|---|
| AWS本番 | オンプレDNS | 名前解決 | DNS | Hub → 専用線 | ○ |
| AWS開発 | AWS本番DB | なし | – | – | × |
| Azure業務 | AWS API | システム連携 | HTTPS | クラウド間接続 | ○ |
複数クラウド設計でよくある失敗
1．CIDRをクラウドごとに勝手に決める
後から相互接続するとIPアドレスが重複し、 ルーティングできなくなる可能性があります。
2．すべてのネットワークを相互通信可能にする
接続できることを優先し、 本来不要な本番・開発間通信まで許可してしまいます。
3．直接接続を増やし続ける
初期は簡単でも、 環境数が増えるとルートと接続関係が複雑化します。
4．戻り経路を確認しない
行きと戻りで経路が異なり、 FWやNATを正しく通過できない場合があります。
5．共有基盤を単一障害点にする
DNSやFWを集中させた結果、 その障害で全システムへ影響する場合があります。
6．通信料金を確認しない
動作上は正しくても、 大量のクラウド間・リージョン間通信によって 想定以上のコストになる場合があります。
7．ネットワーク追加手順を決めない
新規アカウント追加のたびに個別判断すると、 設計ルールが崩れていきます。
8．DNSを後回しにする
IPでは通信できるのに名前解決できず、 アプリケーションが利用できない問題につながります。
複数クラウド環境では、 接続設計・IP設計・ルーティング・セキュリティ・DNSを 別々に考えないことが重要です。
顧客・上司へどう説明するか
技術に詳しくない相手へ 「Transit Gateway」「Virtual WAN」などのサービス名から説明しても、 設計意図は伝わりにくい場合があります。
説明例
「現在はクラウド環境が少ないため個別接続でも管理できますが、 今後、本番・開発・複数クラウドへ環境が増えると、 接続と経路の管理が複雑になります。
そこで中央にネットワークの接続拠点を設け、 各クラウド環境をそこへ接続します。 これにより、オンプレミス接続やセキュリティチェックを集約しながら、 本番と開発のように通信させたくない環境は分離できます。」
技術をビジネス上の効果へ変換する
| 技術設計 | 相手へ伝える価値 |
|---|---|
| ハブ＆スポーク | クラウド追加時の接続・運用を標準化しやすい |
| 本番・開発分離 | 誤操作や不正アクセスの影響範囲を限定する |
| 共有サービス | 重複設備や運用作業を減らせる |
| 中央FW | セキュリティルールとログを一元管理しやすい |
| IPアドレス統合管理 | 将来のクラウド追加時の接続トラブルを防ぐ |
上級エンジニアには、 「技術的に実現できる」だけでなく、 その構成が運用・コスト・リスクへどのような効果を持つか を説明する力が求められます。
複数クラウド設計で使われる英語表現
よく使われる単語
| 英語 | 意味 |
|---|---|
| Multi-cloud | 複数クラウドの利用 |
| Multi-account | 複数アカウント構成 |
| Hub-and-spoke | ハブ＆スポーク構成 |
| Transit network | 中継ネットワーク |
| Shared services | 共有サービス |
| Route propagation | 経路伝播 |
| Routing domain | ルーティングを分離した領域 |
| Network segmentation | ネットワーク分離 |
| Overlapping CIDR | 重複するCIDR |
| Centralized inspection | 通信検査の中央集約 |
| East-west traffic | システム・ネットワーク間の横方向通信 |
| North-south traffic | 外部・内部間の通信 |
設計確認で使える表現
Which networks need to communicate with each other?
どのネットワーク同士が通信する必要がありますか？
Are there any overlapping IP address ranges?
IPアドレス範囲の重複はありますか？
Should production and development environments be isolated?
本番環境と開発環境は分離する必要がありますか？
Where should shared services be hosted?
共有サービスはどこへ配置しますか？
Should traffic pass through a centralized firewall?
通信は中央ファイアウォールを経由させる必要がありますか？
理解度チェック
サービス名ではなく、 複数クラウドネットワークの設計原則を理解できているか確認しましょう。
問題1． ハブ＆スポーク構成の主な目的として最も適切なものはどれですか。
- すべてのネットワーク間通信を無条件で許可する
- ネットワーク接続や経路を中央へ集約し、管理しやすくする
- すべてのサーバーを1つのサブネットへ配置する
- IPアドレスを使用しないネットワークを構築する
解答を見る
ハブ＆スポークでは接続・ルーティング・セキュリティなどを 中央へ集約し、環境追加時にも管理しやすい構成を作ります。
問題2． 複数クラウド接続でCIDR重複が問題になる主な理由は何ですか。
解答を見る
同じ宛先プレフィックスが複数のネットワークに存在すると、 通常のルーティングで宛先を一意に判断できなくなるためです。
問題3． 次のうち、共有サービス用ネットワークへ配置する候補として 最も自然なものはどれですか。
- すべての業務アプリケーション
- DNS・NTP・監視・認証など複数環境から利用するサービス
- 開発者個人の検証サーバー
- 各システム固有のデータベースだけ
解答を見る
複数環境から共通利用するDNS、NTP、認証、 監視などは共有サービスとして集約する候補になります。
問題4． 本番環境と開発環境の両方を同じハブへ接続した場合、 必ず相互通信できるようにしなければならないでしょうか。
解答を見る
同じハブへ接続しても、 経路テーブルやセキュリティポリシーを分けることで、 本番・開発間を分離できます。
問題5． 中央ファイアウォール構成で、 行きと戻りの通信経路を確認すべき理由を説明してください。
解答例を見る
ステートフルファイアウォールでは通信状態を管理するため、 戻り通信が別経路を通るとセッションとして正しく処理できず、 通信障害が発生する可能性があるためです。
実践演習：3つのクラウド環境を接続する構成を設計する
あなたは、企業のクラウドネットワーク設計を担当しています。
現在の環境
| 環境 | 用途 | CIDR |
|---|---|---|
| AWS本番 | Web・業務システム | 10.20.0.0/16 |
| AWS開発 | 開発・検証 | 10.21.0.0/16 |
| Azure | 社内業務システム | 10.30.0.0/16 |
| オンプレミス | AD・DNS・既存システム | 10.0.0.0/16 |
要件
- AWS本番からオンプレミスへ通信できること
- Azureからオンプレミスへ通信できること
- AWS開発からオンプレミスDNSを利用できること
- AWS開発からAWS本番システムへの直接通信は禁止する
- 今後クラウド環境が10個以上へ増える予定
- 通信ログをできるだけ中央で確認したい
課題1．接続構成を考える
個別のフルメッシュ接続と、 ハブ型構成のどちらが適しているか考えてください。
理由：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
解答例を見る
採用例：ハブ型構成
今後環境が10個以上へ増えるため、 各環境を個別接続すると接続・経路管理が複雑化します。 中央のネットワークハブへ接続を集約することで、 新規環境追加時の設計を標準化しやすくなります。
課題2．通信マトリクスを完成させる
| 送信元 | 宛先 | 許可／拒否 |
|---|---|---|
| AWS本番 | オンプレミス | ＿＿＿＿ |
| Azure | オンプレミス | ＿＿＿＿ |
| AWS開発 | オンプレDNS | ＿＿＿＿ |
| AWS開発 | AWS本番 | ＿＿＿＿ |
解答を見る
- AWS本番 → オンプレミス：許可
- Azure → オンプレミス：許可
- AWS開発 → オンプレDNS：必要なDNS通信のみ許可
- AWS開発 → AWS本番：拒否
課題3．経路分離を考える
AWS本番とAWS開発を同じハブへ接続しながら、 AWS開発から本番への通信を禁止するには どのような考え方が必要でしょうか。
解答例を見る
本番系と開発系でルーティング領域やルートテーブルを分離し、 必要な経路だけを伝播・登録します。 さらにファイアウォールなどのセキュリティ制御でも 開発から本番への通信を拒否する設計が考えられます。
課題4．構成図を作る
次の要素を使い、 自分で論理構成図を書いてください。
- AWS本番
- AWS開発
- Azure
- Network Hub
- Firewall
- オンプレミス
- DNS
課題5．設計理由を文章にする
顧客に対して、 なぜ各クラウドを直接接続するのではなく ハブ型構成を採用するのか説明してください。
説明例を見る
今回は、今後クラウド環境が10個以上へ増える計画があるため、 各環境を個別に相互接続するのではなく、 中央のネットワークハブへ接続を集約します。
これにより、新規環境追加時の接続方式を標準化しながら、 本番・開発間の通信を分離し、 オンプレミス接続や通信ログの確認も中央へ集約しやすくします。
自分の言葉で説明する課題
後輩エンジニアから、 「クラウド同士を全部直接つなげばいいのに、 なぜハブを作るんですか？」 と質問されました。
1分程度で説明してください。
説明例を見る
クラウド環境が少ないうちは直接接続でも管理できますが、 環境が増えると接続数やルート設定が増えて管理が複雑になります。
中央にハブを作って各環境をそこへ接続すると、 オンプレミス接続やルーティング、セキュリティを集約できます。 また、同じハブへ接続していても、 本番と開発のように不要な通信は分離できます。
つまりハブ型構成は、 「たくさんのネットワークをつなぎながら、 接続関係を管理可能な状態に保つための設計」です。
まとめ
- 複数クラウド・複数アカウント接続では、 多数のクラウドネットワークを必要な範囲で相互接続する
- 本番・開発・部門・システムなどの管理境界として クラウド環境を分割することがある
- ネットワークが増えるほど、 個別のフルメッシュ接続は管理が複雑になる
- ハブ＆スポークでは、 接続・ルーティング・オンプレ接続・セキュリティなどを中央へ集約できる
- 同じハブへ接続しても、 すべてのスポーク間通信を許可する必要はない
- 本番・開発などはルーティング領域やセキュリティポリシーを分離する
- DNS・NTP・認証・監視などは共有サービスとして集約する方法がある
- 複数クラウドではIPアドレス重複を避けるため、 全社的なCIDR設計が重要
- マルチクラウド接続では、 VPN、専用線、オンプレ経由、統合WANなどを 性能・可用性・コスト・運用性で比較する
- 中央ファイアウォールを使う場合は、 非対称ルーティングやボトルネックにも注意する
複数クラウドネットワーク設計で重要なのは、 「全部つなぐこと」ではありません。 必要な通信だけを、将来増えても管理できる形でつなぐことです。
上級編では、要件定義、基本設計、BGP、クラウド、 セキュリティ、自動化、設計レビュー・顧客提案までを順番に学びます。
コメント