伴菜先生のITラボ — Hannah’s IT Lab
Cloud｜第1回｜2026年11月14日 更新
はじめに
こんにちは、伴菜です。
AWSに慣れている人が初めてAzureを触るとき、まず気になるのは「EC2はAzureだと何？」「VPCに相当するサービスは？」といった、サービス名の違いですよね。私も、新しいクラウドを学ぶときは、すでに知っているサービスと比べるところから始めます。
でも、実際に構成を考え始めると、名前を覚えるだけでは答えが出ないことがあります。たとえば、AWSでWebサーバーを二つのAvailability Zone（AZ）に置くなら、サブネットもAZごとに用意しますよね。Azureで同じ構成を考えるときは、サブネットを分けずにVMを別々のAZに配置することもできます。
今回は、2021年9月に公開した「MS Azureを学ぶ (0) 用語比較」をもとに、サービス名の対応表と、名前だけでは分からない4つの違いを整理します。
第1部｜AWSとAzureのサービス名の対応表
Azureで何を調べればよいか迷ったときの早見表です。機能が近いサービスを並べているので、実際の構成を決めるときは「伴菜のメモ」も見てくださいね。
1. 管理・運用
| AWS | Azure | 伴菜のメモ |
|---|---|---|
| AWS OrganizationsのOU | 管理グループ | アカウントやサブスクリプションを階層化する |
| AWSアカウント | サブスクリプション | リソース管理や課金を考えるうえで重要な単位 |
| AWS Resource Groups | リソースグループ | グループを削除したときの動作に注意 |
| CloudFormation | ARMテンプレート / Bicep | リソースをコードで定義・展開する |
| CloudFormation Stack | Azure Deployment Stacks | デプロイしたリソースのライフサイクルを管理する |
| CloudWatch | Azure Monitor | メトリクス、ログ、アラートなどを扱う |
| AWS Config | Azure Policy | 構成や準拠状況の評価を比較できる。構成履歴やルールの強制は機能ごとに確認する |
2. コンピュート
| AWS | Azure | 伴菜のメモ |
|---|---|---|
| EC2 | Azure Virtual Machines | 仮想マシン |
| EC2 Auto Scaling | Virtual Machine Scale Sets | VMの台数を負荷などに応じて増減する |
| Lambda | Azure Functions | サーバーレスでコードを実行する |
| EKS | Azure Kubernetes Service（AKS） | マネージドKubernetes |
| ECS | Azure Container Appsなど | コンテナの実行先を比較する出発点。実行環境などの要件で選ぶ |
3. ネットワーク
| AWS | Azure | 伴菜のメモ |
|---|---|---|
| VPC | Virtual Network（VNet） | 仮想ネットワーク |
| Security Group | Network Security Group（NSG） | どちらもステートフル。NSGには明示的な拒否ルールもある |
| Network ACL | サブネットに関連付けたNSG | 適用単位は近い。戻り通信の扱いは異なる |
| NAT Gateway | Azure NAT Gateway | 主にインターネット向けの送信接続 |
| VPC Route Table | Route Table / UDR | Azureのユーザー定義ルートをUDRと呼ぶ |
| VPC Peering | Virtual Network Peering | 仮想ネットワーク間を接続する |
| Transit Gateway | Azure Virtual WAN / Virtual Hub | ハブ型接続の比較候補。接続先や経路制御要件を確認する |
| Site-to-Site VPN | VPN Gateway | 拠点とクラウド間をIPsec VPNで接続する |
| Direct Connect | ExpressRoute | クラウドへのプライベート接続 |
| VPC Endpoint / AWS PrivateLink | Private Endpoint / Azure Private Link | AWS側のエンドポイント種別によって対応は異なる |
| Route 53のホストゾーン | Azure DNS | DNSゾーンを管理する |
| Route 53のDNSルーティング | Traffic Manager | DNSベースで接続先を振り分ける |
| Application Load Balancer | Application Gateway | HTTP/HTTPSのL7ロードバランシング |
| Network Load Balancer | Azure Load Balancer（Standard） | TCP/UDPのL4ロードバランシング |
| CloudFront | Azure Front Door | グローバルなWeb配信の比較候補。キャッシュ、ルーティング、WAFなどは要件ごとに確認する |
| VPC Flow Logs | Virtual Network Flow Logs | ネットワークフローを記録する |
伴菜のメモ
Azure Basic Load Balancerはリタイア済みです。既存環境で使っている場合は、Standard Load Balancerへの移行を確認してください。
4. ストレージ
| AWS | Azure | 伴菜のメモ |
|---|---|---|
| S3 | Azure Blob Storage | オブジェクトストレージ |
| S3 Glacier Instant Retrieval | Blob StorageのCold層 | 低頻度アクセス向け。必要なときにすぐ読み出せる |
| S3 Glacier Flexible Retrieval / Deep Archive | Blob StorageのArchive層 | 長期保管向け。取り出しには復元やリハイドレートが必要 |
| EBS | Azure Managed Disks | VM用ブロックストレージ |
| EFS | Azure Files | マネージドファイル共有。NFS、SMBなどの要件を確認する |
同じ低頻度アクセス向けでも、すぐ読めるか、読み出す前に復元が必要かで選び方が変わります。AzureのCoolとColdはオンライン層で、Archiveはオフライン層です。
5. ID・セキュリティ
| AWS | Azure | 伴菜のメモ |
|---|---|---|
| IAM / IAM Identity Centerなど | Microsoft Entra ID + Azure RBAC | IDの管理とAzureリソースへの権限を分けて考える |
| EC2 Instance Profile / IAM Role | Managed Identity | ワークロードにIDを持たせ、必要な権限を付与する |
| KMS | Azure Key Vault / Managed HSM | 暗号鍵を管理する |
| Secrets Manager | Azure Key Vault | シークレットを管理する |
| Certificate Manager（ACM） | Azure Key Vault Certificatesなど | 発行、更新、サービスへの適用は個別に確認する |
| AWS Network Firewall | Azure Firewall | マネージドネットワークファイアウォール |
第2部｜名前だけでは分からない4つの違い
違い1｜Azureでは、リソースグループがライフサイクルの管理単位になる
AWSではアカウントがリソース管理の大きな境界です。Azureではサブスクリプションの下にリソースグループがあり、VMやVNetなどをまとめて管理できます。
AWS
AWS Organizations OU AWSアカウント EC2 / VPC / S3
Azure
テナントルート管理グループ 管理グループ サブスクリプション リソースグループ VM / VNet / Storage
図は典型的な構成例です。Azureの管理階層はMicrosoft Entraテナントに関連付けられます。EntraテナントはユーザーやアプリケーションのIDを管理する境界でもあります。
たとえば、検証用WebアプリのVM、VNet、ストレージを一つのリソースグループにまとめ、グループ単位でAzure RBACを割り当てたり、コストを集計したりできます。グループ自身のリージョンは管理情報の保存場所で、中のリソースは別リージョンにも配置できます。
| 操作 | 削除対象 |
|---|---|
| AWS Resource Groupsのグループを削除 | グループ自体。メンバーのEC2やVPCなどは残る |
| Azureのリソースグループを削除 | グループと、その中のリソース |
伴菜のメモ
誰が管理するか、いつ一緒に変更・削除するかを考えてグループを分けましょう。検証用と本番用を分けると片付ける対象を見分けやすくなります。権限や運用の境界をさらに分けたい場合は、サブスクリプションの分離も検討します。
違い2｜Azureのサブネットは単一AZに固定されない
AWSの場合
AWSでは、一つのサブネットは一つのAZに属します。EC2を二つのAZに配置するなら、それぞれにサブネットを用意します。
VPC · 東京リージョン
AZ A Subnet A EC2 A
同じVPC
AZ C Subnet C EC2 C
Azureの場合
AzureのVNetはリージョン内の複数のAZにまたがります。対応するリソースであれば、同じサブネットを使いながら別々のAZに配置できます。
VNet · Japan East
Subnet-Web VM A（Zone 1）／ VM B（Zone 2）／ VM C（Zone 3）
| 項目 | AWS | Azure |
|---|---|---|
| サブネットの範囲 | 単一AZ | リージョン内で単一AZに固定されない |
| 複数AZへのVM配置 | AZごとのサブネットを使う | 対応するVMなら同じサブネットを使える |
| サブネットを分けるとき | AZとワークロードの役割を考える | ワークロードの役割や通信制御の単位を考える |
インターネットへの送信経路も確認しよう
AWSではVPCにInternet Gatewayをアタッチします。プライベートサブネットから外部へ出る構成ではNAT Gatewayなどを使います。AzureではVNetにInternet Gatewayをアタッチする手順はありません。送信接続には、Azure NAT Gateway、VMのパブリックIP、Standard Load Balancerのアウトバウンドルール、Azure Firewall経由などから選びます。
2026年の既定動作の変更
2026年3月31日より後にリリースされたAPIバージョンで作成する新規VNetでは、サブネットの defaultOutboundAccess が既定で false になります。既存VNetへの一律適用はなく、以前のAPIバージョンを使うデプロイでは従来の既定動作が残ります。
伴菜のメモ
VMからOSの更新、パッケージのダウンロード、外部APIへの接続が必要なら、最初から送信経路を設計に入れておきましょう。
違い3｜Azure NSGはステートフルで、許可と拒否の両方を設定できる
AzureのNetwork Security Group（NSG）は、AWSのSecurity Group（SG）と同じくステートフルで、Network ACL（NACL）のように明示的な拒否ルールも設定できます。
| 項目 | AWS SG | AWS NACL | Azure NSG |
|---|---|---|---|
| ステートフル | はい | いいえ | はい |
| 許可ルール | あり | あり | あり |
| 明示的な拒否ルール | なし | あり | あり |
| ルールの評価順 | 優先順位なし | ルール番号順 | 優先度の小さい順 |
| 適用先 | ENI | サブネット | サブネット / NIC |
AWS
受信通信 NACL（サブネット） Security Group（ENI） EC2
Azure
受信通信 NSG（サブネットに設定した場合） NSG（NICに設定した場合） VM
NSGは優先度の小さいルールから評価する
カスタムルールの優先度は100〜4096です。数字の小さいルールから評価し、最初に一致したルールが適用されます。
| 優先度 | 送信元 | 宛先ポート | 動作 |
|---|---|---|---|
| 100 | 10.1.0.0/16 | TCP 443 | Allow |
| 200 | Any | TCP 443 | Deny |
| 300 | Any | TCP 22 | Deny |
10.1.0.0/16からのHTTPS通信は優先度100で許可され、それ以外は優先度200で拒否されます。カスタムルールに一致しない通信には、VNet内からの受信を許可するルールなどの既定ルールも評価されます。
サブネットとNICの両方にNSGを設定したら？
受信はサブネット側、NIC側の順に評価され、送信はその逆です。両方に設定しているならどちらでも通信が許可される必要があります。NSGはステートフルなので、許可された通信の応答に別の許可ルールは通常必要ありません。
伴菜のメモ
サブネット側で許可していてもVMへ届かないときは、NIC側のNSGも確認しましょう。VMの役割ごとにルールを書きたいときは、Application Security Group（ASG）を使うと「Webサーバー」「Appサーバー」といった論理グループを指定できます。
違い4｜Azureでは「誰に」「何を」「どの範囲で」を分けて考える
Azureで「この人がVMを作成できるか」を調べるときは、Microsoft Entra IDで管理するIDと、Azure RBACで割り当てるリソースへの権限を分けて考えると整理しやすくなります。
| 項目 | AWS | Azure |
|---|---|---|
| ユーザーやグループ | IAM / IAM Identity Centerなど | Microsoft Entra ID |
| リソース操作の権限 | IAMポリシーなど | Azure RBAC |
| 権限を考える単位 | アカウントやリソースなど | 管理グループ、サブスクリプション、リソースグループ、リソース |
| VMなどのワークロード | IAM Role / Instance Profile | Managed Identityと対象サービスへの権限付与 |
AWS
IAMプリンシパル IAMポリシーなどで権限を評価 AWSリソース
Azure
Entra ID上のプリンシパル Azure RBACのロール割り当て 割り当てのスコープ Azureリソース
Azure RBACのロール割り当ては三つの要素で決まる
| 要素 | 例 |
|---|---|
| 誰に | ユーザー、グループ、サービスプリンシパル、マネージドID |
| どのロールを | Owner、Contributor、Reader |
| どの範囲で | 管理グループ、サブスクリプション、リソースグループ、個別リソース |
開発担当者に検証用リソースグループのContributorを割り当てると、グループ内の多くのリソースを管理できます。この割り当てから本番用リソースグループへの権限が付くことはありません。
EntraのGlobal Administratorなら、AzureのVMも操作できる？
Global AdministratorはMicrosoft Entraのディレクトリ管理用ロールです。VMを操作できるかはAzureリソース側の権限で決まります。Global Administratorには、必要に応じてAzureリソースへのアクセスを管理する権限を昇格させる仕組みがあります。
伴菜のメモ
ユーザーを作る操作、VMを作る操作、Blobの中身を読む操作では、確認する権限が違います。Azure RBACはサービスによってデータアクセスにも使われるので、操作対象のサービスの権限モデルまで確認してください。
まとめ｜AWSの知識をAzureの理解につなげよう
| AWSの知識をAzureに持ち込むとき | 確認すること |
|---|---|
| リソースをまとめて管理したい | リソースグループを削除すると、中のリソースも削除対象になる |
| VMを複数のAZに配置したい | 対応するVMなら同じサブネットを使える |
| 通信を許可・拒否したい | NSGはステートフル。優先度と、サブネット・NICそれぞれの設定を見る |
| 人やアプリに権限を付けたい | Entra IDのIDとAzure RBACのロール割り当てを確認する |
サービス名が分かったら、次は「どこに設定する？」「どこまで効く？」「消したら何が消える？」と考えてみてください。AWSで身につけた設計の視点が、そのままAzureを学ぶときの手がかりになります。
それでは、また次回！
伴菜でした。
参考資料
AzureのVNetとサブネット — Microsoft Learn
Azureの既定の送信アクセス — Microsoft Learn