Azure VNet SubnetをAWS Subnetと比べて理解する｜アドレス空間と経路設計の違い

運営：リナックスマスター.JP（代表 宮崎智広）
ＨＯＭＥ ＞ Linux技術 リナックスマスター.JP（Linuxマスター.JP） ＞ Azure ＞ Azure VNet SubnetをAWS Subnetと比べて理解する｜アドレス空間と経路設計の違い
「AWSのVPCサブネット設計は使い慣れているのに、AzureのVNetに移ったとたんに「パブリックサブネット」が見当たらない」
クラウド2つ目を勉強しているエンジニアがよく感じるつまずきです。VNetとVPC、サブネットとサブネット——言葉は似ていても、背後にある設計思想には明確な差があります。この差を曖昧にしたまま構築を進めると、NATゲートウェイの置き場所や経路制御の段階で必ず壁にぶつかります。

この記事では、Azure VNet Subnetの仕組みをAWS Subnetとの比較を軸に解説します。RHEL 9系／Ubuntu 22.04 LTSの端末からazコマンドを実行できる環境を想定しています。アドレス空間の設計から、パブリックサブネット概念の有無、NAT Gateway配置の違い、UDR（ユーザー定義ルート）による経路制御まで、順を追って解説します。

この記事のポイント

・Azure VNet SubnetはすべてデフォルトでプライベートIPのみ
・NATゲートウェイはサブネットに直接アタッチ。中間サブネット不要
・経路制御はAWSがルートテーブル、AzureはUDRでシステムルートを上書き
・VNetは複数のアドレス空間を後から追加可能でCIDR設計が柔軟


「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

AzureのVNetとAWSのVPCはどこが違うのか

AWSのVPCもAzureのVNetも、クラウド内に作る仮想的なプライベートネットワークです。どちらもCIDR表記でIPアドレス範囲を指定し、サブネットに分割して使います。しかし設計の細部には明確な違いがあります。

最大の違いは「パブリックサブネット/プライベートサブネット」という区別がAzureには存在しない点です。AWSではサブネットのルートテーブルにInternet Gateway（IGW）へのルートを加えることでパブリックサブネットを実現しますが、AzureのサブネットはすべてデフォルトでプライベートIPのみです。インターネットへの公開はNIC（ネットワークインターフェース）へのパブリックIPアタッチや、NAT Gatewayを介したアウトバウンド接続で制御します。
概念 AWS VPC Azure VNet
ネットワーク単位 VPC（Virtual Private Cloud） VNet（Virtual Network）
アドレス範囲 プライマリCIDR 1本（/16 ～ /28）+ セカンダリ追加可 アドレス空間（複数定義可）（/8 ～ /29）
サブネット分類 パブリック / プライベートの区別あり 区別なし（すべてプライベートIPのみ）
インターネット接続 Internet Gateway（IGW）+ ルートテーブル パブリックIP / NAT Gateway / LB
経路制御 ルートテーブル（明示的 / 暗黙的） システムルート + UDR（ユーザー定義ルート）

VNetのアドレス空間とサブネット設計の基本

1. アドレス空間（Address Space）の定義

AWSのVPCはCIDRブロックを原則1本で定義します（/16 ～ /28の範囲。セカンダリCIDRの追加は可能ですが制約があります）。一方、AzureのVNetは「アドレス空間」という概念を持ち、1つのVNetに複数のCIDRブロックを同時に定義できます。たとえば 10.0.0.0/16 と 192.168.0.0/24 を同一VNetに共存させることも可能です。後からアドレス空間を追加できるため、VNet設計を変更するときの柔軟性がAWSより高いといえます。

azコマンドでVNetとサブネットを作成する例（出力例は環境により異なります）：

# リソースグループの作成
az group create --name myRG --location japaneast

# VNetの作成（アドレス空間: 10.0.0.0/16）
az network vnet create \
  --resource-group myRG \
  --name myVNet \
  --address-prefix 10.0.0.0/16 \
  --location japaneast

# サブネットの作成
az network vnet subnet create \
  --resource-group myRG \
  --vnet-name myVNet \
  --name mySubnet \
  --address-prefix 10.0.1.0/24

2. サブネット内の予約アドレス

AWSとAzureはどちらのサブネットでも先頭4つと末尾1つ、合計5つのIPアドレスがシステムに予約されています。/24サブネット（256アドレス）では 256 - 5 = 251アドレスが使用可能です。

Azure固有の予約内訳は以下の通りです（10.0.1.0/24の場合）：

10.0.1.0   ネットワークアドレス
10.0.1.1   デフォルトゲートウェイ（Azureが使用）
10.0.1.2   Azure DNSにマッピング（Azureが使用）
10.0.1.3   Azureが将来の予約として確保
10.0.1.255 ブロードキャストアドレス
AWSの予約もほぼ同じ構造ですが、AWSでは .2 をDNS用、.3 をAWSが将来の使用のために確保という表現になっています。実務での影響はほとんど同じです。

AWSとAzureのサブネット設計の違い

1. AWSの「パブリックサブネット」の正体

AWSのパブリックサブネットは「サブネット自体の属性」ではありません。ルートテーブルに 0.0.0.0/0 → Internet Gateway（igw-xxx） のルートが存在するサブネットを「パブリック」と呼んでいるだけです。サブネット作成時点では区別がなく、ルートテーブルの変更によってパブリックにもプライベートにもなります。

パブリックIPの自動割り当て設定（Enable auto-assign public IPv4 address）もサブネット側の属性として存在し、有効化しておくと起動したVMインスタンスに自動でパブリックIPが付与されます。

2. Azureにはパブリックサブネットがないことの意味

AzureのVNetサブネットには「パブリック/プライベート」の区別がなく、すべてのサブネットがプライベートIPのみを持つ設計です。インターネットからVMにアクセスするには、VMのNICに「パブリックIPリソース」を直接アタッチします。

インターネットからの受信アクセスは「NICのパブリックIP + NSG（Network Security Group）のインバウンドルール」で制御します。NSGで許可するポートを精査するにはLinuxのポート確認コマンドが役立ちます。ss・lsofを使ったポート確認の全コマンドはこちらを参考にしてください。

3. NATゲートウェイのアーキテクチャの違い

プライベートIPのみを持つVMからインターネットにアウトバウンド接続を行う場合、AWSとAzureではNAT Gatewayの構成が大きく異なります。
比較軸 AWS NAT Gateway Azure NAT Gateway
配置場所 パブリックサブネット内に配置 サブネットに直接アタッチ
前提条件 Internet Gatewayが必要 パブリックIPまたはIPプレフィックス
ルートの変更 プライベートSubnetのルートテーブルに追加 アタッチされたSubnetに自動適用
中間サブネット NAT用パブリックサブネットが必要 不要
AzureのNAT GatewayはパブリックサブネットをVNet内にわざわざ作る必要がなく、アウトバウンドを制御したいサブネットに直接アタッチするだけです。AWSと比べてNATの構成手順がシンプルです。

経路設計の違い｜ルートテーブルとUDR

1. AWSのルートテーブル

AWSのVPCには作成と同時に「メインルートテーブル（暗黙的）」が存在します。サブネットに明示的なルートテーブルをアタッチしない場合、メインルートテーブルが使われます。宛先として最長プレフィックスが優先されるのはAWSもAzureも共通の仕様です。

2. AzureのUDR（ユーザー定義ルート）

AzureのVNetにはデフォルトの「システムルート」が自動的に存在し、VNet内の通信はシステムルートによって最初から可能です。これはAWSのメインルートテーブルに 10.0.0.0/16 → local が自動設定されている状態に近い概念です。

システムルートを上書きしたい場合は、UDR（ユーザー定義ルート）を作成してサブネットにアタッチします。

# ルートテーブルの作成
az network route-table create \
  --resource-group myRG \
  --name myRouteTable \
  --location japaneast

# カスタムルートの追加（オンプレへのルートを仮想アプライアンス経由に）
az network route-table route create \
  --resource-group myRG \
  --route-table-name myRouteTable \
  --name toOnprem \
  --address-prefix 192.168.0.0/24 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.0.2.4

# サブネットへのルートテーブルのアタッチ
az network vnet subnet update \
  --resource-group myRG \
  --vnet-name myVNet \
  --name mySubnet \
  --route-table myRouteTable
--next-hop-type にはVirtualNetwork、Internet、None、VirtualAppliance、VnetLocal、ExpressRouteGatewayなど複数の選択肢があります。AWSのルートエントリの「Target」に相当します。

3. VNetピアリングとアドレス空間の重複

AWSのVPCピアリングもAzureのVNetピアリングも、デフォルトではトランジティブルーティング（A↔B↔CのようにBを経由してA-C間通信）はサポートされていません。AWSではTransit Gateway、AzureではVirtual WANまたはAzure Firewallを中継点として使います。

VNetピアリング設定時にアドレス空間が重複していると作成が拒否されます。AzureのVNetは複数のアドレス空間を持てるため、意図せず重複が入っていないかを事前に確認しておく必要があります。IPv6デュアルスタックの設定も組み合わせる場合はIPv6 設定の参考も合わせて参照してください。

トラブルシュートとよくある間違い

「パブリックサブネットをどう作るか」という問いが間違い

AWSから移行したエンジニアが最もよく迷うのが「Azureにどうやってパブリックサブネットをつくるか」という問いかけ自体が誤りである点です。Azureにはパブリックサブネットという概念がなく、インターネットへの公開はNICへのパブリックIPアタッチとNSGルールで実現します。「サブネット＝パブリック」という構造から「VM/NICにパブリックIPを持たせる」という構造に発想を切り替えることが重要です。

NSGのアウトバウンドルールによるNAT Gatewayブロック

NAT GatewayをサブネットにアタッチしたのにVMからアウトバウンド通信が出ない場合、NSGのアウトバウンドルールを確認します。Azureのデフォルトアウトバウンドルールには AllowInternetOutBound（優先度65001）が存在しますが、それより優先度（数値が小さい）の高い DenyAll カスタムルールが追加されていると通信がブロックされます。

VNetアドレス空間の重複によるピアリング失敗

VNetピアリング設定時に「アドレス空間が重複している」と拒否されることがあります。AzureのVNetは複数のアドレス空間を定義できるため、不要なアドレス空間が残っていないか確認します。

# VNetのアドレス空間を確認
az network vnet show \
  --resource-group myRG \
  --name myVNet \
  --query "addressSpace.addressPrefixes"

# 出力例（環境により異なります）
[
  "10.0.0.0/16"
]

まとめ

Azure VNet SubnetとAWS Subnetの主な違いをまとめます。
比較ポイント AWS Subnet Azure VNet Subnet
パブリック/プライベート区別 ルートテーブルのIGWルートで決まる 区別なし。すべてプライベートIPのみ
インターネット公開 IGW + パブリックIP + ルートテーブル NICへのパブリックIPアタッチ + NSG
アウトバウンドNAT NAT GatewayをパブリックSubnetに配置 NAT GatewayをSubnetに直接アタッチ
デフォルト経路 メインルートテーブル（暗黙的） システムルート（自動）
カスタム経路 ルートテーブルを作成してSubnetに関連付け UDRを作成してSubnetにアタッチ
アドレス予約数 5（先頭4 + 末尾1） 5（先頭4 + 末尾1）
複数アドレス空間 セカンダリCIDR追加（制約あり） 複数アドレス空間を後から自由に追加可
AWSのVPC/Subnet設計の知識はAzureに転用できる部分も多いですが、「パブリックサブネットの概念がない」「NAT Gatewayをサブネット直接にアタッチする」「経路はUDRでシステムルートを上書きする」という3点がAzureならではの設計思想です。AzureのVNet設計をハンズオンで体系的に学びたい方はAzureサーバー構築研修のご案内もご覧ください。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、
AzureのVNet設計・サブネット分割・UDRによる経路制御まで、手を動かして理解できるハンズオン研修を用意しています。
＞＞ Azureサーバー構築ハンズオン研修の詳細はこちら

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録

運営

リナックスマスター.JP（代表 宮崎智広）

株式会社イーネットマーキュリーが運営するLinux教育サイトです。代表の宮崎智広は現役のLinuxサーバー管理者として20年以上の実務経験を持ち、累計3,100名以上のエンジニアを指導してきました。実践型のLinuxセミナーや無料マニュアルの配布を通じてLinux人材の育成に取り組んでいます。