AWS脳のままAzureを触ると混乱する理由 ─ 管理階層とネットワークの違いから理解する
はじめに
AWSの経験はあるけれど、Azureはこれから...というエンジニア向けにAzureとAWSとの違いを分かりやすく記事にまとめてみたいと思います。
Azureは、2010年にサービスを開始したMicrosoftのパブリッククラウドです。当初はPaaS中心でしたが、2013年からIaaSが追加され、現在ではAWSに次ぐシェアを誇っています。AWSはどちらかというとIaaSからAzureはPaaSからスタートした！この歴史的経緯が、AWSとは少し異なる設計思想に繋がっています。
Web三層アーキテクチャの比較
まずは基本的なWeb三層アーキテクチャで使われるサービスを比較してみましょう。
| 役割 | AWS | Azure |
|---|---|---|
| Compute | EC2 | Virtual Machines (VM) |
| Database | RDS | Azure Database (各種PaaS DB) |
| Storage | S3 | Blob Storage |
基本的な構成要素は似ていることがわかりますね。
Azureの基本概念とAWSとの比較
Azureの全体像を理解するために、管理階層や主要な概念をAWSと比較してみましょう。
| 概念 | AWS | Azure | ポイント |
|---|---|---|---|
| 管理階層 | アカウント / Organization | テナント / サブスクリプション / 管理グループ | Azureはサブスクリプションをグルーピングする管理グループが存在 |
| ID管理 | IAM (IAM User/Role) | Microsoft Entra ID (旧Azure AD) | ユーザーはEntra IDで一元管理。Azure RBACで権限付与 |
| リソースのグループ | Resource Groups (タグベース) | リソースグループ | Azureのリソースは必ずいずれかのリソースグループに所属 |
| 地理的単位 | リージョン | 地域 / リージョンペア | ディザスタリカバリを意識したリージョンペアという概念がある |
| 物理的単位 | アベイラビリティゾーン (AZ) | 可用性ゾーン (AZ) | 物理的に独立したデータセンター群 |
| 仮想ネットワーク | VPC | 仮想ネットワーク (VNet) | 機能はVPCとほぼ同等だが、設計思想に違いあり |
| ネットワーク区画 | サブネット (AZに紐づく) | サブネット (AZに紐づかない) | AzureのサブネットはAZを跨いで構成可能 |
Azureの管理階層
Azureの管理階層は、AWSとは少し異なります。
-
テナント (Microsoft Entra ID)
- 組織全体を表す単位で、ID管理（ユーザー、グループ）の中心。
- Azureポータルへのログインは、基本的にこのテナントに対して行います。
- アクセス権の境界となります。
-
管理グループ
- 複数のサブスクリプションを束ねて、ポリシーやアクセス権をまとめて適用するための階層です。
-
サブスクリプション
- リソースをデプロイするための単位。
- 契約、請求、クォータの境界となります。AWSのアカウントに近い概念です。
-
リソースグループ
- 関連するリソースをまとめるためのコンテナ。
- すべてのAzureリソースは、いずれか1つのリソースグループに所属する必要があります。
- 面白いことに、リソースグループはリージョンを跨いでリソースを持つことができます。（例：リソースグループ自体は東日本に置き、その中に東日本のVMと西日本のVMを混在させる）
ID管理：Entra IDとRBAC
AWSのIAMと異なり、AzureではID管理とリソース管理の権限が明確に分かれています。
- Microsoft Entra ID: ユーザー、グループ、パスワードポリシーなどを管理するID基盤。
- Azure RBAC (ロールベースのアクセス制御): サブスクリプションやリソースグループといったスコープに対して、「共同作成者」「閲覧者」などのロールを割り当て、Azureリソースへの操作権限を管理します。
AWSのスイッチロールのような仕組みはなく、Entra ID上の単一ユーザーが、権限を持つ複数のサブスクリプションに直接アクセスできます。
可用性：AZと可用性セット
- 可用性ゾーン (AZ): AWSのAZと同様、リージョン内で物理的に分離されたデータセンター群です。レイテンシーは2ms未満で相互接続されています。
- 可用性セット: AZが導入される前からある概念で、同一データセンター内での障害（ラック障害や電源障害など）からVMを保護する仕組みです。
- リージョンペア: 同一地域（例: 日本）内の2つのリージョン（東日本と西日本）で構成されます。Azureの計画メンテナンスは、ペアの片方ずつ順次実施されるため、DR構成に利用されます。
ネットワーク：VNetとAWSとの違い
Azureのネットワークは、PaaSから始まった歴史的背景から、AWSとは異なる特徴を持っています。
VNet (仮想ネットワーク)
AWSのVPCに相当するサービスです。ただし、サブネットの扱いに大きな違いがあります。
- AZとサブネットが1:1ではない: AWSではサブネットは特定のAZ内に作成しますが、AzureのサブネットはAZに紐づきません。AZを指定したい場合は、VMなどのリソースをデプロイする際に指定します。これにより、後からサブネットのCIDRを変更することなく、柔軟な構成が可能です。
- サブネット間の自動ルーティング: VNet内のサブネット間は、デフォルトで相互に通信可能です。
VNet間の接続
- VNetピアリング: VNet間をプライベートに接続します。AWSのVPC Peeringと同様ですが、推移的なルーティング（Transitive Routing）はサポートされません。（A-B、B-Cをピアリングしても、AとCは直接通信できない）
- VPN Gateway: VPNを利用してVNet間やオンプレミスと接続します。
セキュリティ：NSG (ネットワークセキュリティグループ)
AWSのセキュリティグループとネットワークACLを組み合わせたような機能を持つステートフルなファイアウォールです。
- サブネットまたはNICにアタッチします。
- IPアドレスとポート番号で通信を制御します。
-
AppServiceやAzureCosmosDBといったサービスタグを宛先として指定できるのが便利です。
インターネット通信
-
アウトバウンド:
- デフォルトのアウトバウンドアクセスは2026/3/31に廃止予定です。今後はNAT Gatewayを利用するのがベストプラクティスです。
- 送信元IPを固定したり、通信を厳密に制御したい場合はAzure FirewallをハブVNetに配置し、UDR (ユーザー定義ルート)で通信を強制的に経由させます。
-
インバウンド:
- Application Gateway (L7): AWSのALBに相当し、WAF機能もアタッチ可能です。
- Load Balancer (L4): AWSのNLBに相当します。
ハブ&スポーク構成とルーティング
大規模な環境では、共有サービスを置くハブVNetと、各ワークロードを置くスポークVNetをピアリングする「ハブ&スポーク」構成が一般的です。
- 課題: スポーク間の通信は、ハブを経由する必要があるが、VNetピアリングは推移的なルーティングをサポートしない。
- 解決策: ハブVNetにAzure FirewallやNVA (Network Virtual Appliance)を配置し、UDRでルーティングを制御します。
- Azure Virtual WAN: オンプレミス拠点やVNet間の接続をシンプルに管理できるマネージドサービスで、AWSのTransit Gatewayに近い役割を果たします。
DNS
-
Azure DNS:
168.63.129.16という特殊なIPアドレスが、Azure内部のDNSリゾルバーとして機能します。 - DNSプライベートリゾルバー: VNetとオンプレミス環境間での名前解決を実現するためのサービスです。
まとめ
AzureはAWSと似たサービスを提供しつつも、管理階層やネットワークの設計思想に独自の特徴があります。
-
管理単位: Azureは
テナント > (管理グループ) > サブスクリプション > リソースグループという階層構造を持つ。 -
ID管理:
Entra IDでユーザーを一元管理し、RBACでリソースへの権限を付与する。 -
ネットワーク:
VNetのサブネットはAZに依存せず柔軟。セキュリティはNSGで制御する。 -
ルーティング: ハブ&スポーク構成が基本。スポーク間通信には
Azure FirewallやVirtual WANを活用する。
AWSの知識をベースにしつつ、Azureについても違いを理解しマルチクラウドを操れるエンジニアにステップアップしたいと思います！