AzureとAWS VPCのネットワーク設計を比較する|VNet・NAT・NSGとVPC・SG・IGWの対応関係をazコマンドで実践

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)Azure > AzureとAWS VPCのネットワーク設計を比較する|VNet・NAT・NSGとVPC・SG・IGWの対応関係をazコマンドで実践
「AWSのVPCはわかっているのに、AzureのVNetに移行したら同じ構成が再現できない」
この悩みを抱えるエンジニアは少なくありません。

AWSとAzureはどちらも仮想ネットワークを提供しますが、インターネット接続の設計・サブネットのルーティング・セキュリティフィルタリングの仕組みが異なります。「VPCはわかるのにVNetが手探り」という状態では、Azureの設計ミスや余計なトラブルを招くことになります。

この記事では、AWS VPCとAzure VNetのネットワークコンポーネントを1対1で比較し、azコマンドとAWS CLIを使った実践例も交えながら対応関係を整理します。
・AWSのVPC・SG・NAT GatewayがAzureで何に対応するか(コンポーネントマッピング)
・サブネット設計とインターネット接続の仕組みの違い
・azコマンドによるVNet・サブネット・NSG構築の実践手順
・AWS経験者がAzureネットワーク設計でつまずく3つのポイント

動作確認環境:Azure CLI 2.61 / RHEL 9.4(Azure VM上で検証)

この記事のポイント

・Azure VNetはAWS VPCと同じリージョン単位の仮想ネットワークだが設計思想が異なる
・AWSのSecurity GroupはAzureではNSGに対応しDENYルールが使える点が大きく違う
・AWS NAT GatewayとAzure NAT Gatewayは役割は同じだが設定方法と制御の粒度が異なる
・azコマンドでVNet・サブネット・NSGを構築する基本コマンドを実機ログ付きで解説


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

AzureのVNetとAWS VPCの基本構造を比較する

まず全体構造から比較します。

AWS VPCはリージョン内に作成し、複数のアベイラビリティゾーン(AZ)にまたがるサブネットを持てます。VPC単体ではインターネットに接続できず、Internet Gateway(IGW)をアタッチして初めてインターネットと通信できます。

Azure VNetも同様にリージョン内に作成し、複数の可用性ゾーンにまたがるサブネットを持てます。ただし、VNetを作成しただけで同一VNet内のリソース間通信はデフォルトで許可されており、外部接続はパブリックIPまたはNAT Gatewayを使う設計です。

コンポーネントの対応関係は次のとおりです。

AWS VPC ≒ Azure VNet:リージョン単位の仮想ネットワーク
AWS Subnet ≒ Azure Subnet:VNet/VPC内のアドレスブロック
AWS Internet Gateway ≒ Azure パブリックIP(VMにアタッチ):インターネット接続の入口
AWS NAT Gateway ≒ Azure NAT Gateway:アウトバウンド専用のNAT
AWS Security Group ≒ Azure NSG(ネットワークセキュリティグループ):ステートフルフィルタリング
AWS Network ACL ≒ Azure NSGのサブネットアタッチ:サブネット単位の制御
AWS Route Table ≒ Azure ルートテーブル(UDR):カスタムルーティング

最大の構造的な違いは「インターネット接続の入口」の設計です。AWSではIGWというリソースをVPCに1つアタッチする方式ですが、AzureではVMに個別にパブリックIPをアタッチする方式(またはNAT Gateway)を使います。IGWという共有エントリポイントの概念はAzureには存在しません。

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

サブネット設計の最大の違いは「パブリック/プライベートの決め方」です。

AWSでは、サブネットにInternet Gatewayへのルート(0.0.0.0/0 → igw-xxxx)があればパブリックサブネット、なければプライベートサブネットです。ルートテーブルの設定でパブリック/プライベートが決まります。

Azureでは、サブネット自体に「パブリック」「プライベート」という区別はありません。VMにパブリックIPをアタッチすればインターネットからアクセスでき、NSGのルール次第で外部との通信を制御します。プライベートなサブネットを実現したい場合は、パブリックIPを付与せずNAT Gatewayをアタッチする構成にします。

また、AWSではサブネットはAZ単位(1サブネット=1AZ)ですが、AzureのサブネットはVNet内のアドレスレンジで定義し、AZをまたいで複数のVMが同一サブネットに入れます。

アドレス設計例(azコマンドで確認):

# VNetのアドレス空間とサブネット一覧を確認 az network vnet show \ --resource-group rg-compare-demo \ --name vnet-prod \ --query "{addressSpace: addressSpace.addressPrefixes, subnets: subnets[].{name:name, prefix:addressPrefix}}" \ -o json

{ "addressSpace": ["10.0.0.0/16"], "subnets": [ {"name": "subnet-public", "prefix": "10.0.1.0/24"}, {"name": "subnet-private", "prefix": "10.0.2.0/24"} ] }

VNetのアドレス空間は10.0.0.0/16で、その中にパブリック用(10.0.1.0/24)とプライベート用(10.0.2.0/24)のサブネットを分割しています。Azureではこのサブネット分割後に、NSGとNAT Gatewayでアクセス制御を重ねる設計が一般的です。

インターネット接続の仕組みを比較する(IGW・NAT Gateway・パブリックIP)

インターネット接続の設計がAWSとAzureで最も大きく異なる部分です。

1. AWSのインターネット接続パターン

AWSでは次の2パターンが基本です。

パブリックサブネットのEC2:IGW経由でインターネットへ直接アクセス
プライベートサブネットのEC2:NAT Gateway経由でアウトバウンドのみアクセス

IGWはVPCに1つだけアタッチするリソースで、パブリックサブネットのルートテーブルに「0.0.0.0/0 → igw-xxxxx」を追加することで有効化されます。

2. AzureのNAT Gatewayでアウトバウンド通信を制御する

AzureのインターネットアクセスはVMにパブリックIPをアタッチする方式が基本ですが、本番環境ではNAT Gatewayを使うことで複数のVMを1つのパブリックIPで管理できます。NAT Gatewayをサブネットにアタッチすると、そのサブネットのVMはすべてNAT Gateway経由でインターネットに出られます。

# NAT Gateway用のパブリックIPを作成 az network public-ip create \ --resource-group rg-compare-demo \ --name pip-natgw \ --sku Standard \ --allocation-method Static # NAT Gatewayを作成 az network nat gateway create \ --resource-group rg-compare-demo \ --name natgw-prod \ --public-ip-addresses pip-natgw \ --idle-timeout 10 # プライベートサブネットにNAT Gatewayをアタッチ az network vnet subnet update \ --resource-group rg-compare-demo \ --vnet-name vnet-prod \ --name subnet-private \ --nat-gateway natgw-prod

# subnet-privateのVMから外部通信テスト [azureuser@vm-private ~]$ curl -s https://ifconfig.me 20.xxx.xxx.87

NAT Gatewayのパブリック IP(20.xxx.xxx.87)経由でアウトバウンド通信が成立していることが確認できます。プライベートサブネットにNAT Gatewayをアタッチすることで、VMにパブリックIPを付与せずにインターネットへ出られます。

AzureのNAT Gatewayとネットワーク設計をさらに深く学びたい方には、現役エンジニアが教えるAzure実践ハンズオン講座も参考になります。

セキュリティグループ(SG)とNSGの違い

AWSのSecurity GroupとAzureのNSGは、どちらもステートフルなパケットフィルタリングを提供します。ただし、いくつかの重要な違いがあります。

1. アタッチ先の違い

AWS SG:インスタンス(のENI)に直接アタッチ。サブネット単位の制御はNetwork ACLで行う
Azure NSG:サブネットまたはNIC(VMのネットワークインターフェース)にアタッチ可能

AzureではNSGをサブネットとNIC両方にアタッチすることもでき、その場合はサブネットのNSG → NICのNSGの順に評価されます。AWS SGはインスタンス単位のみ(Network ACLとは独立)なので、この二重評価はAzure特有の動作です。

2. DENYルールの有無

AWS SGはALLOW(許可)ルールしか書けません。明示的なDENYはなく、一致するALLOWがなければ暗黙的に拒否されます。

AzureのNSGはDENYルールを明示的に書けます。優先度(Priority)の低い番号が先に評価され、ALLOWとDENYを組み合わせて細かく制御できます。

# NSGを作成してSSH(22番)を許可し、その他のインバウンドを拒否する例 az network nsg create \ --resource-group rg-compare-demo \ --name nsg-web # SSH許可(優先度100) az network nsg rule create \ --resource-group rg-compare-demo \ --nsg-name nsg-web \ --name allow-ssh \ --priority 100 \ --direction Inbound \ --source-address-prefixes '*' \ --destination-port-ranges 22 \ --protocol Tcp \ --access Allow # HTTP/HTTPS許可(優先度110) az network nsg rule create \ --resource-group rg-compare-demo \ --nsg-name nsg-web \ --name allow-http-https \ --priority 110 \ --direction Inbound \ --source-address-prefixes '*' \ --destination-port-ranges 80 443 \ --protocol Tcp \ --access Allow # その他すべて拒否(優先度4000) az network nsg rule create \ --resource-group rg-compare-demo \ --nsg-name nsg-web \ --name deny-all-inbound \ --priority 4000 \ --direction Inbound \ --source-address-prefixes '*' \ --destination-port-ranges '*' \ --protocol '*' \ --access Deny

# NSGのルール一覧を確認 az network nsg rule list \ --resource-group rg-compare-demo \ --nsg-name nsg-web \ --output table Name Priority Direction Protocol Access ----------------- ---------- ----------- ---------- -------- allow-ssh 100 Inbound Tcp Allow allow-http-https 110 Inbound Tcp Allow deny-all-inbound 4000 Inbound * Deny

優先度100のSSH許可、110のHTTP/HTTPS許可、4000でDENYという順に評価されます。AWS SGにはないDENYルールを使うことで、許可リスト型のセキュリティポリシーを実装できます。

azコマンドでVNetとサブネットを構築する実践手順

AWSとAzureの対応関係を理解したところで、azコマンドによる実際の構築手順を確認します。

1. リソースグループとVNetを作成する

# リソースグループ作成(AWSのリージョン指定に相当) az group create \ --name rg-compare-demo \ --location japaneast # VNet作成(AWSでは: aws ec2 create-vpc --cidr-block 10.0.0.0/16) az network vnet create \ --resource-group rg-compare-demo \ --name vnet-prod \ --address-prefixes 10.0.0.0/16 # パブリックサブネット作成 az network vnet subnet create \ --resource-group rg-compare-demo \ --vnet-name vnet-prod \ --name subnet-public \ --address-prefixes 10.0.1.0/24 # プライベートサブネット作成 az network vnet subnet create \ --resource-group rg-compare-demo \ --vnet-name vnet-prod \ --name subnet-private \ --address-prefixes 10.0.2.0/24

# 作成確認 az network vnet show \ --resource-group rg-compare-demo \ --name vnet-prod \ --query "{name:name, addressSpace:addressSpace.addressPrefixes, location:location}" \ -o json { "addressSpace": ["10.0.0.0/16"], "location": "japaneast", "name": "vnet-prod" }

2. NSGを作成してサブネットにアタッチする

# NSGをサブネットにアタッチ(AWSでは: Network ACLをサブネットに関連付け) az network vnet subnet update \ --resource-group rg-compare-demo \ --vnet-name vnet-prod \ --name subnet-public \ --nsg nsg-web # アタッチ確認 az network vnet subnet show \ --resource-group rg-compare-demo \ --vnet-name vnet-prod \ --name subnet-public \ --query "networkSecurityGroup.id" \ -o tsv /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg-compare-demo/providers/Microsoft.Network/networkSecurityGroups/nsg-web

NSGのIDが表示されれば、サブネットへのアタッチが完了しています。

AzureのVMが正しくインターネットに出られているか、ポートが想定どおり開いているかをLinuxコマンドで確認する際は、Linux ポート確認の全コマンドも役立ちます。

AWS経験者がAzureネットワーク設計でつまずく3つのポイント

AWS VPCを使い慣れたエンジニアがAzureに移行したときに起きやすいトラブルと対処法をまとめます。

1. 「IGWがないとインターネットに出られない」という思い込み

AWSではIGWをVPCにアタッチしないとインターネット通信ができません。そのためAzureでも「何かInternet Gatewayに相当するものをVNetにアタッチしなければ」と考えがちです。

しかしAzureでは、VMにパブリックIPをアタッチするか、NAT Gatewayをサブネットに設定するだけでインターネットに出られます。VNet全体に適用するIGWという概念はなく、VMまたはサブネット単位で接続を制御する設計です。

2. NSGをNICとサブネット両方にアタッチして二重評価が起きる

AzureではNSGをNIC(VM)とサブネットの両方にアタッチできます。両方にNSGがアタッチされている場合、インバウンドはサブネットNSG → NIC NSGの順に評価されます。AWSの「SG単体で完結する」感覚でいると、「NSGでALLOWしたのに通信できない」という事態が起きます。

対処法:どちら側のNSGで通信を管理するかを設計段階で決め、両方にアタッチする場合は評価順序を意識したルール設計を行います。

3. デフォルトのアウトバウンドインターネット接続への依存(廃止予定)

Azureでは従来、VMにパブリックIPがなくてもデフォルトのアウトバウンドインターネット接続が存在していました。しかしこの機能は新規VMに対して順次廃止される予定となっており、明示的なNAT GatewayかパブリックIPの設定が必要です。

AWSはプライベートサブネットのEC2はデフォルトでインターネットに出られないため、この挙動はAWS経験者には驚きになります。本番環境ではNAT Gatewayを使う設計を標準とし、デフォルトの暗黙的なアウトバウンド接続に依存しないことが重要です。

本記事のまとめ(AWSとAzureのネットワークコンポーネント対応表)

AWSコンポーネント Azureの対応コンポーネント 主な違い
VPC VNet 基本構造は同じ。AzureはAZ単位のサブネット制約なし
Internet Gateway パブリックIP(VMアタッチ) AzureはVNet共有IGWなし。VM単位でパブリックIPを制御
NAT Gateway NAT Gateway 役割は同じ。AzureはサブネットにアタッチしてVM個別設定が不要
Security Group NSG(ネットワークセキュリティグループ) AzureはDENYルール使用可・NICとサブネット両方にアタッチ可
Network ACL NSG(サブネットアタッチ) AzureはNSG一本でNICとサブネット両方を制御
Route Table ルートテーブル(UDR) 概念は同じ。AzureはUser Defined Routeで明示定義
AWS VPCのネットワーク設計経験があれば、Azureへの移行は「IGWなし・NSGのDENY活用・NAT Gateway必須化」の3点を押さえることでスムーズになります。

Azureのネットワーク設計・セキュリティ設定・VM運用を体系的に学びたい方は、現役エンジニアによる実践ハンズオン講座で手を動かしながら習得できます。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、20年以上の運用経験を持つ現役エンジニアが基礎から教えます。
Azure対応セミナーの詳細を見る >>

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

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

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

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

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

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

登録10秒/合わなければ解除3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。