仮想ネットワークとサブネット

Azure Virtual Network (VNet) は、Azure クラウド内に構築し、管理できる論理的に分離されたネットワークです。Azure のネットワーク機能の基本的な構成要素であり、仮想マシン、データベース、アプリ サービスなどの Azure リソースが相互に、インターネットやオンプレミス ネットワークと安全に通信できるようにします。VNet は 1 つの Azure リージョンと、作成時に定義する特定の IPv4（必要に応じて IPv6）の CIDR アドレス空間に限定されます。

VNet を作成するときは、CIDR 表記を使用してアドレス空間を割り当てます。CIDR（Classless Inter-Domain Routing）表記では、ネットワーク アドレスと、ネットワーク プレフィックスに使用するビット数の両方を指定します。たとえば、10.0.0.0/16 では 65,536 個の IP アドレス（10.0.0.0 ～ 10.0.255.255）が使用できます。アドレス空間はプライベート IP 範囲（RFC 1918 で定められた 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）のいずれかである必要があります。計画しているすべてのサブネットを収容し、将来の拡張にも対応できる十分な大きさのアドレス空間を選択してください。ただし、ハイブリッド接続を計画している場合は、オンプレミス ネットワークとの重複を避けてください。

サブネットは、VNet のアドレス空間をより小さなネットワーク セグメントに分割します。各サブネットには独自の IP 範囲（VNet のアドレス空間の一部）があり、異なる種類のリソースを含めることができます。サブネットには、整理（関連するリソースのグループ化）と分離（リソース グループごとに異なるセキュリティ規則を適用すること）という 2 つの目的があります。たとえば、Web サーバー用の web-tier サブネット（10.0.1.0/24）、アプリケーション サーバー用の app-tier サブネット（10.0.2.0/24）、データベース用の data-tier サブネット（10.0.3.0/24）を作成できます。

各サブネット内では、Azure が最初の 4 個の IP アドレスと最後の IP アドレスを自身の用途のために予約します。10.0.1.0/24 サブネットの場合、10.0.1.0（ネットワーク アドレス）、10.0.1.1（既定のゲートウェイ）、10.0.1.2 と 10.0.1.3（Azure DNS 用に予約）、10.0.1.255（ブロードキャスト アドレス）が該当します。そのため、/24 サブネットで使用できる IP は 251 個になります。サブネットのサイズを決める際はこの予約を考慮してください。/28 サブネットで使用できるアドレスは 11 個 בלבדです（16 個から予約済みの 5 個を引いた数）。

既定では、同じ VNet 内のリソースは、異なるサブネットにあっても、プライベート IP アドレスを使用して相互に通信できます。VNet 内通信に追加の構成は必要ありません。異なる VNet 内のリソースは既定では通信できないため、VNet Peering を使用して明示的に接続する必要があります。同じサブネット内のリソースは同じネットワーク セグメントを共有するため、Azure のソフトウェア定義ネットワーク層において、相互の通信が最も直接的な経路になります。

VNet 内の VM は、既定でインターネットへの送信接続を開始できます。Azure がマネージド NAT サービスを通じて送信インターネット アクセスを自動的に提供するためです。インターネットからの受信アクセスには、リソースのネットワーク インターフェイスまたはロード バランサーにPublic IP アドレスを割り当てる必要があります。その後、Network Security Group (NSG) の規則を使用して、許可するポートとプロトコルを正確に指定し、受信アクセスを制御します。一般的なアーキテクチャでは、Web サーバーをパブリック IP を持つパブリック サブネットに配置し、アプリケーション サーバーを Web 層からのみアクセスできるプライベート サブネットに配置します。

既定では、Azure がルーティングを自動的に処理します。サブネット間のトラフィックは VNet 内にとどまり、送信インターネット トラフィックは NAT 処理され、Azure サービスへのトラフィックには Azure のバックボーンが使用されます。User-Defined Routes (UDRs) を Route Table に設定すると、この動作を上書きできます。一般的な用途は、すべての送信インターネット トラフィックをハブ VNet 内のNetwork Virtual Appliance (NVA) またはAzure Firewall 経由にして、一元的に検査することです。ルート テーブルを作成し、ルート エントリを追加してから、そのテーブルを 1 つ以上のサブネットに関連付けて適用します。

Azure App Service（VNet Integration）、Azure Kubernetes Service、Azure SQL Managed Instance、Azure Databricks などの一部の Azure サービスでは、そのサービスに委任された専用サブネットが必要です。委任サブネットとは、Azure がユーザーに代わってサービス固有のリソース（ネットワーク インターフェイスや内部 IP アドレスなど）をそのサブネットに注入できるようにしたものです。委任サブネットには他の種類のリソースをデプロイできません。そこは、その Azure サービス専用に予約されます。委任が必要なサービスの利用を計画する場合は、必ず十分な IP アドレス空間を持つ専用サブネットを割り当ててください。

VNet 設計における主なベスト プラクティスは次のとおりです。VNet を作成する前にアドレス空間を計画してください。リソースを再作成しない限り変更できません。各アプリケーション層に個別のサブネットを使用して、それぞれ異なるセキュリティ ポリシーを適用してください。VPN または ExpressRoute 経由で接続する予定がある場合は、オンプレミス ネットワークとのアドレス空間の重複を避けてください。スケーリングが必要なサービス（AKS のノード プールなど）には大きめのサブネットを確保してください。大規模な管理を容易にするため、リソースには分かりやすい名前を付けてください（例：vnet-prod-eastus-001）。適切に設計された VNet は、場当たり的に構築された VNet よりもはるかに容易に保護およびトラブルシューティングできます。

Azure VNet は、次の 2 つの方式でオンプレミス ネットワークに接続できます。VPN Gateway — パブリック インターネット経由の暗号化された IPsec/IKE トンネルです。中程度の帯域幅の要件に適しており、費用対効果に優れています。Azure ExpressRoute — ネットワーク プロバイダー パートナーを介した、プライベートな専用ファイバー接続です。VPN よりも広い帯域幅、低いレイテンシ、予測しやすいパフォーマンスを提供します。機密性の高いワークロードや、帯域幅の保証が必要なシナリオでは ExpressRoute が推奨されますが、大幅に高いコストと、より長いプロビジョニング期間が必要です。

VNet のアドレス空間のサイズを決めるには、現在および将来の要件を計画する必要があります。一般的なエンタープライズ パターンは次のとおりです。VNet のアドレス空間：/16（65,536 アドレス）。サブネット：ワークロード層ごとに /24（それぞれ 251 個の使用可能なアドレス）。/16 の VNet には 256 個の /24 サブネットを含められるため、ほとんどの環境では十分です。非常に大規模な環境では、/8 を使用するか、重複しない複数の範囲を申請してください。常に拡張の余地を残してください。将来 /22 が必要になる可能性があるのに、今日 /24 を割り当てると、後でアドレスの再割り当てに手間がかかります。

このレッスンでは、Azure VNet は、定義された CIDR アドレス空間を持ち、単一のリージョンにスコープされた論理的に分離されたネットワークであること、サブネットは VNet を分割し、整理とセキュリティ ポリシーの分離に使用すること、そしてAzure はサブネットごとに 5 個の IP アドレスを予約し、同じ VNet 内のリソースは追加の設定なしで既定でプライベートに通信できることを学びました。次は、トラフィックのフィルタリングに使用する Network Security Group と Application Security Group について学びます。