この悩みを抱えるエンジニアは少なくありません。
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のIPv6デュアルスタック設計とAWS VPCとの違い
動作確認環境: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は役割は同じだが設定方法と制御の粒度が異なる
・AzureはIPv6 CIDRを自由に指定できるがAWSはAmazonプールからの自動割り当てになる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
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には存在しません。
なお、Azure VNetはIPv4とIPv6のアドレス空間を同一VNet内に共存させる「デュアルスタック」構成を一般提供しています。AWS VPCでもIPv6は対応していますが、AzureはプレフィックスをULA(ユニークローカルアドレス)を含む任意のCIDRで自由に指定できる点が大きく異なります(詳細は「AzureのIPv6デュアルスタック設計」セクションで解説します)。
サブネット設計の比較: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が同一サブネットに入れます。
IPv6設計の観点では、AzureのサブネットはIPv4のCIDRに加えてIPv6 /64 のCIDRを同時に指定するデュアルスタック構成が可能です。AWS VPCのサブネットもIPv6 /64 を追加できますが、VPC側のIPv6プレフィックスがAmazonプールからの割り当てになるため、オンプレミスとの統一したアドレス設計が難しい場合があります。
アドレス設計例(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"} ] }
インターネット接続の仕組みを比較する(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
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
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
AzureのVMが正しくインターネットに出られているか、ポートが想定どおり開いているかをLinuxコマンドで確認する際は、Linux ポート確認の全コマンドも役立ちます。
AzureのIPv6デュアルスタック設計とAWSとの違い
IPv4アドレスの枯渇対応やモダンなネットワーク要件が求められる現場では、IPv6対応が避けられないテーマになっています。Azure VNetは、IPv4とIPv6のアドレス空間を同一VNet内に共存させる「デュアルスタック」構成を一般提供しています。これにより、1枚のNICにIPv4とIPv6のIPアドレスを同時に割り当てることが可能です。1. デュアルスタックVNetとサブネットを構築する
VNetのアドレス空間にIPv4とIPv6を同時に指定するには、--address-prefixes で2つのCIDRを渡します。IPv6プレフィックスはfd00::/48のようなULAを自由に指定できます。# IPv4(10.0.0.0/16)とIPv6(fd00::/48)のアドレス空間を持つVNetを作成 az network vnet create --resource-group rg-compare-demo --name vnet-dualstack --address-prefixes "10.0.0.0/16" "fd00::/48" # IPv4 /24 と IPv6 /64 の両方を持つデュアルスタックサブネットを作成 az network vnet subnet create --resource-group rg-compare-demo --vnet-name vnet-dualstack --name subnet-dualstack --address-prefixes "10.0.1.0/24" "fd00::/64"
# サブネットのIPv4・IPv6両方のCIDRを確認 az network vnet subnet show --resource-group rg-compare-demo --vnet-name vnet-dualstack --name subnet-dualstack --query "{ipv4:addressPrefix,ipv6:ipv6AddressPrefix}" -o table Ipv4 Ipv6 ------------ -------- 10.0.1.0/24 fd00::/64
2. NICにIPv6 IPコンフィグを追加してデュアルスタック化する
Azure VMをデュアルスタック対応にするには、NICにIPv6用のIPコンフィグを追加します。IPv6パブリックIPにはStandard SKUが必須で、Basic SKUは使用できません。# IPv6パブリックIP(Standard SKU・静的割り当て)を作成 az network public-ip create --resource-group rg-compare-demo --name pip-v6 --sku Standard --allocation-method Static --version IPv6 # NICにIPv6用IPコンフィグを追加 az network nic ip-config create --resource-group rg-compare-demo --nic-name nic-vm --name ipv6config --public-ip-address pip-v6 --private-ip-address-version IPv6
# NICのIPコンフィグ一覧でIPv4・IPv6の両方を確認 az network nic show --resource-group rg-compare-demo --name nic-vm --query "ipConfigurations[].{name:name,version:privateIPAddressVersion,privateIP:privateIPAddress}" -o table Name Version PrivateIP ----------- --------- ---------- ipconfig1 IPv4 10.0.1.4 ipv6config IPv6 fd00::4
ip addr show eth0 でIPv4(inet行)とIPv6(inet6行)の両方が割り当てられていることを確認できます。3. AWSのIPv6 VPCとの設計比較
AWSでも同様のIPv6デュアルスタック構成を組めますが、設計思想に大きな違いがあります。| 比較項目 | Azure VNet | AWS VPC |
|---|---|---|
| IPv6プレフィックスの指定 | 任意のIPv6 CIDRを自由に指定可(fd00::/48 等) | Amazonプールから /56 を自動割り当て(BYOIPv6 も可) |
| サブネットのIPv6 CIDR長 | /64 推奨(任意指定可) | /64 固定(/56 から自動分割) |
| パブリックIPv6の割り当て | Standard SKUパブリックIPを明示的に作成・紐づけ | サブネット設定で自動割り当て or Elastic IP |
| インターネット接続の制御 | NSGでポート単位に制御(IPv4・IPv6共通) | Internet Gateway + セキュリティグループ |
| NICへのIPv6追加方法 | az network nic ip-config create |
aws ec2 assign-ipv6-addresses |
| プライベートIPv6の用途 | VNet内の任意CIDRを使用(オンプレ設計と統一しやすい) | Amazonパブリックアドレス(プライベートULAは使えない) |
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で明示定義 |
| IPv6 CIDR(手動追加) | IPv6デュアルスタック(VNet標準対応) | AzureはCIDRを自由に指定可。AWSはAmazonプールから/56を自動割り当て |
--address-prefixes に両プロトコルのCIDRを指定しておくと、後からの追加作業を最小限に抑えられます。Azureのネットワーク設計・セキュリティ設定・VM運用を体系的に学びたい方は、現役エンジニアによる実践ハンズオン講座で手を動かしながら習得できます。
Azure対応セミナーの詳細を見る >>
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます