「サブネットに対してNATを設定する方法がAWSと全然違う。何をどこに設定すればいいのかわからない」
AWS経験者がAzureのネットワーク設計に取り組むとき、最初に感じる違和感の多くはサブネット設計の思想差から来ています。VPCとVNet、NAT GatewayとAzure NAT Gatewayは名前が似ているようで、設計の仕組みがまったく異なります。
この記事では、AWSとAzureのサブネット設計の構造的な違いを整理したうえで、Azure NAT Gatewayをazコマンドで構築する手順を通じてその差を体感できるよう解説します。想定環境はAzure CLI（az）が動作するLinux端末（Ubuntu 22.04～24.04 LTS、Rocky Linux 9系）です。
この記事のポイント
・AWSのサブネットはAZ固定、AzureのサブネットはAZをまたいで配置できる
・Azure NAT GatewayはサブネットにアタッチするだけでSNATが機能する
・SNATポートはIPアドレス1件あたり最大64,512（AWSは55,000/接続先ペア）
・azコマンドでNAT Gatewayを構築する4ステップを順を追って解説する
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
AWSとAzureのサブネット設計思想の違い
AWSとAzureは、どちらも「仮想ネットワーク」「サブネット」「NAT」という同じ言葉を使います。しかし設計思想は大きく異なり、AWSの感覚でAzureを設計しようとすると意図しない構成になりやすい部分があります。1. サブネットとAZの関係性の違い
AWSのサブネットは必ず1つのAZ（Availability Zone）に固定されます。マルチAZ冗長構成を作るには、AZごとに別のサブネット（例: subnet-app-az1、subnet-app-az2）を作成し、それぞれにEC2インスタンスを配置します。AzureのサブネットはAZに固定されません。1つのサブネット（例: subnet-app 10.1.1.0/24）がリージョン内の複数AZにまたがります。Zone 1・Zone 2・Zone 3への分散は、VM作成時の
--zone オプションで指定します。サブネットはシンプルに保ったまま、VMのゾーン指定で冗長化するのがAzureの設計スタイルです。2. パブリック・プライベートの設計方法の違い
AWSのサブネットは、ルートテーブルにInternet Gateway（IGW）向けのルート（0.0.0.0/0 → igw-xxxxx）があれば「パブリックサブネット」として機能します。直感的でわかりやすい設計です。AzureにはAWSのような「パブリックサブネット」という概念が明示的に存在しません。サブネット上のVMがインターネットに出るかどうかは、パブリックIPの割り当ての有無とNSG（Network Security Group）のルールによって決まります。パブリックIPがないVMのアウトバウンドには、NAT Gatewayを明示的に設定する必要があります。
【重要】Azure では2025年9月以降、新規作成したVMのデフォルトアウトバウンドアクセス（非推奨）が無効化されました。本番環境でアウトバウンドが必要なVMには必ずNAT Gatewayまたはパブリックを設定してください。
3. セキュリティ制御の構造差
AWSはサブネット単位のNACL（Network ACL・ステートレス）とインスタンス単位のSecurity Group（ステートフル）の2層構造です。NACLでサブネット境界に粗いフィルタを、SGで細かいフィルタを使い分けます。AzureはNSG（ステートフル）のみで、サブネット単位またはNIC単位に適用します。ステートレスなフィルタが必要な運用場面はAzure Firewallで補完します。この2層・1層の構造差も、AWSからの移行時に設計ミスが出やすいポイントです。
AWSとAzureのNAT Gatewayを比較する
プライベートサブネット上のサーバーからインターネットへのアウトバウンド通信を実現するNAT構成は、AWSとAzureで設計アプローチが大きく異なります。1. AWS NAT Gatewayの動作原理
AWS NAT GatewayはAZに固定されるマネージドサービスです。1つのNAT GatewayはAZをまたがりません。マルチAZ冗長構成では、AZごとにNAT Gatewayを作成し、各AZのプライベートサブネットのルートテーブルに対応するNAT GatewayのIDを設定します。SNATポート（SNAT: Source NAT・送信元アドレス変換）は、同一の送信先ホスト・ポートへの同時接続単位で最大55,000が割り当てられます。大量の短時間接続が集中すると、SNATポート枯渇がボトルネックになりやすい構成です。
2. Azure NAT Gatewayの動作原理
Azure NAT GatewayはAZに固定されないリージョンレベルのリソースです（ゾーン冗長オプションあり）。1つのNAT Gatewayを複数のサブネットに関連付けることができます。SNATポートはパブリックIPアドレス1件につき最大64,512です。NAT Gatewayにパブリックアドレスを最大16件追加できるため、最大で約100万ポートを確保できます。スケールアウトがIPアドレスの追加という直感的な操作で済む点がAWSとの大きな違いです。
3. 設計上の主な比較ポイント
| 比較項目 | AWS NAT Gateway | Azure NAT Gateway |
|---|---|---|
| 配置単位 | AZ固定 | リージョン（ゾーン冗長オプションあり） |
| マルチAZ冗長 | AZごとに1台必要 | 1台でゾーン冗長設定可能 |
| 設定方法 | ルートテーブルに追加する | サブネットに直接アタッチする |
| SNATポート数 | 最大55,000（接続先ペア単位） | IP1件あたり最大64,512 |
| スケールアウト | NAT Gatewayを追加またはEIPを追加 | パブリックIPを追加（最大16件） |
Azure NAT Gatewayをazコマンドで構築する
理論の違いを確認したところで、実際にAzure NAT Gatewayを構築します。AzureのLinux実践コースでは、VNet設計からNAT構成・NSGセキュリティ設計まで体系的に学べます。Azure CLIでサブスクリプションにログイン済みであることを前提とします。
1. リソースグループとVNetを作成する
# リソースグループを作成する（東日本リージョン） az group create --name rg-nat-test --location japaneast # VNetとプライベートサブネットを作成する az network vnet create \ --resource-group rg-nat-test \ --name vnet-test \ --address-prefix 10.1.0.0/16 \ --subnet-name subnet-private \ --subnet-prefix 10.1.1.0/24
{ "newVNet": { "name": "vnet-test", "addressSpace": { "addressPrefixes": ["10.1.0.0/16"] }, "provisioningState": "Succeeded" } }
2. パブリックIPとNAT Gatewayを作成する
NAT GatewayにはStandard SKUのパブリックIPが必要です。Basic SKUは使用できないため注意してください。# Standard SKUのスタティックパブリックIPを作成する az network public-ip create \ --resource-group rg-nat-test \ --name pip-nat-gw \ --sku Standard \ --allocation-method Static \ --location japaneast # NAT Gatewayを作成してパブリックIPを紐付ける az network nat gateway create \ --resource-group rg-nat-test \ --name nat-gw-test \ --public-ip-addresses pip-nat-gw \ --idle-timeout 10 \ --location japaneast
3. サブネットにNAT Gatewayを関連付ける
AWSではルートテーブルにNAT GatewayのIDを記述しますが、AzureではサブネットにNAT Gatewayを直接アタッチします。# subnet-privateにNAT Gatewayを関連付ける az network vnet subnet update \ --resource-group rg-nat-test \ --vnet-name vnet-test \ --name subnet-private \ --nat-gateway nat-gw-test
# サブネットにNAT Gatewayが紐付いているか確認する az network vnet subnet show \ --resource-group rg-nat-test \ --vnet-name vnet-test \ --name subnet-private \ --query natGateway.id \ --output tsv
/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg-nat-test/providers/Microsoft.Network/natGateways/nat-gw-test
4. VMのアウトバウンドIPがNAT GatewayのIPになっているか確認する
subnet-private にパブリックIPなしのVMを作成し、アウトバウンドのグローバルIPを確認します。# パブリックIPなしのVMをsubnet-privateに作成する az vm create \ --resource-group rg-nat-test \ --name vm-private-test \ --image Ubuntu2204 \ --vnet-name vnet-test \ --subnet subnet-private \ --public-ip-address "" \ --admin-username azureuser \ --generate-ssh-keys
curl -s ifconfig.me を実行すると、返ってくるグローバルIPがNAT GatewayのパブリックIP（pip-nat-gw）と一致すればNAT Gatewayが正常に動作しています。VMへのアクセスにはAzure Bastionか az vm run-command invoke を使います。VM内のポート使用状況や接続状態をLinuxコマンドで確認するときは、Linux ポート確認の全コマンドが役に立ちます。
トラブルシュート｜アウトバウンドが通らないときの確認手順
1. NSGでアウトバウンドが遮断されていないか確認する
NSGのデフォルトルールには「AllowInternetOutBound」が含まれていますが、カスタムDenyルールで上書きされている場合があります。本番環境でNATを追加したのに通信が出ない場合は、まずNSGのアウトバウンドルールを確認します。# NSGのアウトバウンドルールを確認する（NSG名は環境に合わせて変更） az network nsg rule list \ --resource-group rg-nat-test \ --nsg-name 対象のNSG名 \ --query "[?direction=='Outbound']" \ --output table
2. NAT Gatewayのプロビジョニング状態を確認する
# NAT Gatewayの状態とパブリックIPを確認する az network nat gateway show \ --resource-group rg-nat-test \ --name nat-gw-test \ --query "{name:name, state:provisioningState, publicIps:publicIpAddresses[].id}" \ --output json
{ "name": "nat-gw-test", "publicIps": [ "/subscriptions/xxxx.../pip-nat-gw" ], "state": "Succeeded" }
3. パブリックIPがStandard SKUか確認する
Basic SKUのIPをNAT Gatewayに割り当てるとプロビジョニングがエラーになります。# パブリックIPのSKUを確認する az network public-ip show \ --resource-group rg-nat-test \ --name pip-nat-gw \ --query "{sku:sku.name, alloc:publicIPAllocationMethod, state:provisioningState}" \ --output json
{ "alloc": "Static", "sku": "Standard", "state": "Succeeded" }
本記事のまとめ
| 比較項目 | AWS | Azure |
|---|---|---|
| サブネットとAZの関係 | 1サブネット = 1AZ（固定） | 1サブネットが複数AZにまたがる |
| パブリック・プライベートの定義 | IGWルートの有無で決まる | パブリックIPの有無とNSGで決まる |
| セキュリティ制御 | NACL（ステートレス）＋SG（ステートフル） | NSG（ステートフル）のみ |
| NAT設定方法 | ルートテーブルで紐付け | サブネットに直接アタッチ |
| SNATポート数 | 最大55,000（接続先ペア単位） | IP1件あたり最大64,512 |
| マルチAZ冗長 | AZごとにNAT Gatewayが必要 | 1台でゾーン冗長設定可能 |
AWSとAzureのサブネット設計の違いは、「AZとサブネットの関係」「パブリック・プライベートの定義方法」「NATの設定経路」の3点に集約されます。AWSに慣れたエンジニアがAzureを触る際は、この3点の違いを最初に押さえると運用上の設計ミスを大幅に減らせます。
AzureのVNet内での名前解決については、Linux DNS 設定の基本を土台としてAzureのプライベートDNSゾーンと組み合わせると、VNet内のサービス間通信をホスト名で管理できるようになります。
AzureのVNet設計・NAT構成・NSGによるセキュリティ制御まで体系的に学べる実践コースを用意しています。
＞＞ AzureのLinux実践コース｜LinuxMaster.JP
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
- 前のページへ：Azure VNet Peeringでオンプレ統合を実現する方法｜トランジットルーティングの注意点
- この記事の属するカテゴリ：Azureへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます