Summary
- AzureはAWSと異なり「サービスをVNetにアタッチする」思想であり、ネットワーク設計の前提が異なる
- App Serviceは「実行基盤(Plan)」と「アプリ」が分離された二層構造を持ち、それぞれに管理が必要
- Azureのお作法に則った設計をするとAzureならではの強みを活かせる
やらないこと
- AWSとAzureの優劣比較(どっちが優れている劣っているではない)
- 特定サービスの網羅的な仕様説明
- 料金の詳細比較
本記事のねらい
筆者はパブリッククラウドを活用したシステム開発で、AWSを7年以上、Azureを3年以上経験している。AWSを先に経験した後でAzureを触り始める際に感じた根本的な設計思想の違いを、実際の開発・運用経験から得られた知見をもとに述べる。
AWS・Azureで感じた違い
データベースのレプリカ設計思想の違い
AWSのAurora Read Replicaは、単一のReader Endpointでレプリカへのアクセスを束ね、自動的に分散する仕組みを持つ。
Azure Database for PostgreSQL Flexible Serverは、リードレプリカを複数作成できるものの、各レプリカが独立したエンドポイントを持ち、アプリ側での分散が必要になる。自動スケールアウト機能もない。
ただし、Azureのシングルインスタンス構成はゾーン冗長が裏側で担保されており（稼働率99.99%）、シンプルな構成であればシングルインスタンスで十分なケースも多い。
| 比較軸 | AWS Aurora | Azure PostgreSQL Flexible |
|---|---|---|
| Reader Endpoint | 単一・自動分散 | レプリカごとに個別 |
| スケールアウト | 自動 | 手動・アプリ側対応 |
| 冗長性 | マルチAZ | ゾーン冗長（シングルでも可） |
Azureは「シングルインスタンスでゾーン冗長」という設計思想であり、AWSの「マルチインスタンス分散」とは発想の出発点が異なる。
操作インターフェースの設計思想：Portal完結 vs CLI/API前提
AWSのマネジメントコンソールは、CLIで可能な操作の大半をGUIで提供している。
Azureでも多くの操作がPortalで完結するが、一部の操作はCLI・PowerShell・REST APIを使わなければ実行できない。
代表例：Application Gatewayの起動・停止
- Portalに停止ボタンは存在しない
- しかし停止自体は可能であり、CLI/PowerShell/REST APIで実行できる
- 停止しなければ継続課金される
これは「Portalはあくまでも可視化・操作の一手段」というAzureの設計思想を示している。本格運用ではCLIやIaCツールを前提とした運用設計が推奨される。
ただし、AWSでも新サービスリリース直後はコンソールが追従していなかった可能性もある(うろ覚え)。
筆者が日頃操作するサービスの範疇で、という前提ではAzureのほうがポータル非対応のものがいくつかあった印象です。
後述しますが、App Service Planが停止できない！（AWSはECS on Fargateを停止できる！）に対して、Application Gatewayを停止できる！（AWSはALBを停止できない！）という、それぞれ停止して課金を止められるものとそうでないものがあります。優劣ではなく、設計思想の違いからくる一長一短なんだろうなぁと感じます。
リソースの「管理粒度」の違い：App Service Plan vs ECS on Fargate
AWS ECS on Fargateでは、コンピューティングリソース自体が課金・管理の単位となる。リソースを停止・削除すれば課金も止まる、という直感的な構造だ。
一方、AzureのApp Serviceは二層構造を持つ。
| 概念 | 役割 |
|---|---|
| App Service Plan | VMプールの実行基盤。課金の実態はここ |
| App Service | Plan上で動くアプリケーションの論理単位 |
App Serviceのアプリを「停止」しても、App Service Planは稼働し続ける。課金を止めるにはPlan自体を削除する必要がある。
App serviceにおいては実行環境(プラン)を意識する必要がある。だが、この上で複数のアプリを独立して稼働させることも可能である。
ECS on Fargateでも似たようなことは可能だが、ルーティングやタスク間の依存関係が複雑になりがちであり、1つのコンピュートリソースに複数機能を集約しておきたい場合にはApp Serviceの2層構造は役立つ。
ネットワーク設計思想の違い：VPC閉域 vs VNetアタッチ
AWSでは、VPCというネットワーク空間にリソースを配置する。 「VPCに閉じ込める」 という設計で、通信経路は比較的直感的に把握できる。
Azureでは、サービスをVNetにアタッチするという思想であり、デフォルトではパブリックエンドポイントを持つサービスが多い。プライベート通信を実現するには、Private Endpointを明示的に構成する必要がある。
この差が表面化する典型例が、App Service間のプライベート通信だ。
[App Service A] → Private Endpoint経由 → [App Service B]
Private Endpointを設定しVNet内でDNS名前解決を行うと、PrivateIPが返る。しかしHTTPリクエストのHostヘッダーにPublicドメインを明示しないと404が返るという挙動がある。
これはApp ServiceがHostヘッダーによってインスタンスを振り分けるアーキテクチャを持つためである。AWSのALBターゲットグループ的な発想とは異なる点だ。
Azureのお作法にはまれば便利
設計思想の違いを理解した上で活用すると、Azureには以下の強みがある。
- VS CodeからそのままデプロイできるPaaS連携
- GitHub Actionsとの充実したワークフロー統合
- リソースグループによる「用途・請求単位」の一元管理
特にリソースグループは、AWSのタグ管理と比較して強制力のある管理単位として機能し、コスト管理・権限管理・ライフサイクル管理を一体で行える点は便利だ。
まとめ・所感
AWSとAzureの設計思想の違いを整理すると以下のようになる。
| 観点 | AWS | Azure |
|---|---|---|
| DB冗長性 | マルチインスタンス分散 | シングル+ゾーン冗長 |
| 操作UI | Management Console ≒ CLI | Portal < CLI/API |
| PaaSの構造 | リソース＝課金単位が多い | 基盤(Plan)とアプリが分離 |
| ネットワーク | VPCにリソースを閉じ込める | サービスにVNetをアタッチする |
| 管理単位 | タグベース（任意） | リソースグループ（強制力あり） |
どちらが優れているという話ではなく、設計思想の違いを先に理解してからアーキテクチャを組むことが、予期しない挙動やコスト超過を防ぐ最善策である。「AWSでこうだったから」という前提を一度リセットし、Azureの文脈で設計することが重要である。