仮想ネットワークとは何か

クラウド上に仮想マシンを作る場合でも、 その仮想マシンがどのネットワークへ所属するのかを決める必要があります。

そのために利用するのが仮想ネットワークです。

代表的な名称として、次のようなものがあります。

名前は違いますが、いずれもクラウド上で IPアドレスや通信経路、リソース間通信を考えるための重要なネットワーク基盤です。

クラウドネットワークの全体像

まず、仮想ネットワークとサブネットの関係を1枚の図で考えます。

最初に大きなIPアドレス空間を仮想ネットワークへ割り当て、 その中を複数のサブネットへ分割します。

サブネットとは何か

例えば、仮想ネットワークに 10.20.0.0/16 を割り当てたとします。

その中から次のようにサブネットを作れます。

重要なのは、 単にIPアドレスを小さく分けることが目的ではない という点です。

サブネットを分けることで、 通信経路やセキュリティポリシー、運用上の役割を整理しやすくします。

CIDRとIPアドレス設計

クラウドの仮想ネットワークでも、 オンプレミスと同じようにCIDR表記を使用してIPアドレス範囲を表します。

例えば次のように設計します。

最初に大きすぎず、小さすぎない範囲を決める

仮想ネットワークを作成するときは、 現在必要なIPアドレスだけを見るのではなく、将来拡張も考えます。

• 仮想マシンは今後増えるか
• ロードバランサーや管理サービスを追加するか
• 開発・検証環境を増設するか
• 別リージョンへ展開する可能性があるか
• オンプレミスと接続する予定があるか
• 別のVPC・VNetと接続する可能性があるか

アドレス重複に注意する

特に重要なのが、 他ネットワークとのIPアドレス重複を避けること です。

単独でクラウドを使っている間は問題にならなくても、 将来VPNや専用線でオンプレミスと接続したり、 別のクラウド環境と接続したりすると問題になります。

そのため、クラウドを新規設計するときは、 クラウドだけを見るのではなく、 企業全体のIPアドレス体系 を確認することが重要です。

なぜサブネットを分割するのか

「全部同じサブネットへ配置した方が簡単ではないか」 と思うかもしれません。

小規模な検証環境なら成立する場合もありますが、 本番環境では複数の観点から分割を検討します。

Public・Privateサブネットの考え方

クラウドネットワークでは、 「Publicサブネット」「Privateサブネット」という言葉をよく使います。

ただし、重要なのは名前ではなく、 実際にどの経路を持ち、どの通信を許可しているのか です。

Public側のイメージ

Private側のイメージ

例えばWebシステムの場合、 データベースをインターネットから直接利用する必要は通常ありません。

そこで、外部公開する入口と内部処理を行うサーバーを分け、 必要な通信だけ通すように設計します。

ルーティングとセキュリティの関係

クラウドネットワークを理解するときに、 特に混同しやすいのが 「通信経路」と「通信許可」 です。

つまり、 経路が存在していることと、通信が許可されていることは別問題 です。

この考え方は、クラウドネットワーク障害を切り分けるときにも非常に重要です。

次の記事では、ルートテーブルとセキュリティ制御を詳しく解説します。

AWS・Azure・Google Cloudでは同じなのか

基本的な考え方には共通点がありますが、 実装やリソースのスコープには違いがあります。

マルチクラウドを扱うネットワークエンジニアには、 製品名だけを覚えるのではなく、 「この機能はネットワークのどの役割を担当しているのか」を整理する力が重要です。

サブネット設計の判断基準

実際の設計では、 「とりあえず/24を何個か作る」のではなく、 要件から理由を持って構成を決めます。

1. 既存ネットワークを確認する オンプレミス、他クラウド、他VPC・VNetなどで使用している IPアドレス範囲を確認します。
2. 必要なリソースを洗い出す Web、AP、DB、ロードバランサー、管理、監視など、 配置予定のリソースを整理します。
3. 通信要件を整理する インターネット公開が必要なのか、 内部通信だけなのか、オンプレミスとの通信が必要なのかを整理します。
4. セキュリティ境界を考える 外部公開系、内部業務系、DB、管理系など、 どの単位で通信を分離したいかを検討します。
5. 可用性を考える 単一障害でサービス全体が停止しないよう、 利用するクラウドの障害領域とサブネット仕様を確認します。
6. 必要IPアドレス数を見積もる 現在だけでなく、将来の仮想マシンやマネージドサービスの増加も考慮します。
7. 将来接続を考える VPN、専用線、VPC間接続、複数アカウント、 マルチクラウドなど将来の接続可能性も考慮します。
8. 設計理由を文書化する 「なぜこのCIDRなのか」「なぜこの単位で分割したのか」を残します。

サブネット設計表の例

仮想ネットワークとサブネット設計でよくある失敗

1．とりあえずデフォルト設定を使う

検証では便利でも、本番環境では既存ネットワークとの重複や、 不要な通信許可がないか確認する必要があります。

2．現在必要なIPアドレス数しか考えない

将来リソースが増え、 アドレス不足によってサブネット追加や再設計が必要になる可能性があります。

3．オンプレミスのアドレスを確認しない

後からVPNや専用線で接続するときにアドレス重複が発覚すると、 移行やNATなど追加対応が必要になる場合があります。

4．Public・Privateを名前だけで判断する

サブネット名ではなく、 実際のルート、ゲートウェイ、IP、通信制御を確認します。

5．サブネットを分ければ安全だと思う

サブネットを分割しただけで、 必ず通信が遮断されるわけではありません。

ルーティングとセキュリティポリシーを合わせて設計します。

6．細かく分割しすぎる

「セキュリティのため」と何でも別サブネットにすると、 アドレス・ルート・セキュリティ設定・運用管理が複雑になります。

分割には 「なぜ分けるのか」という明確な理由 が必要です。

7．クラウドごとの差を無視する

AWS、Azure、Google Cloudでは、 ネットワークやサブネットのスコープ、利用する制御機能などが異なります。

オンプレミスのVLAN構成をそのままクラウドへコピーするのではなく、 利用するクラウドの特性に合わせて設計します。

顧客・上司へ仮想ネットワークとサブネットをどう説明するか

技術に詳しくない相手へ 「VPC」「VNet」「CIDR」といった用語だけで説明しても、 設計の目的は伝わりにくいでしょう。

説明例

技術を業務上のメリットへ変換する

上級工程では、 「10.20.0.0/16にしました」と説明するだけでは不十分です。

なぜその範囲なのか、なぜその分割なのか、 それによって顧客にどのようなメリットがあるのか まで説明できることが重要です。

仮想ネットワークとサブネットで使われる英語表現

よく使われる単語

設計レビューで使える表現

What CIDR block should we use for this virtual network?
この仮想ネットワークでは、どのCIDRブロックを使用しますか？

Does this address range overlap with the on-premises network?
このアドレス範囲はオンプレミスネットワークと重複していませんか？

Which resources need direct internet connectivity?
どのリソースにインターネットへの直接接続が必要ですか？

How should we segment the application and database networks?
アプリケーションとデータベースのネットワークをどのように分割しますか？

Do we have enough address space for future growth?
将来拡張に十分なアドレス空間がありますか？

自分の言葉で説明する課題

後輩エンジニアから次の質問を受けました。