Computing

カテゴリ概要

Azure のコンピューティングサービスは、IaaS の Virtual Machines から PaaS の App Service、サーバーレスの Azure Functions まで幅広い選択肢を提供している。AWS のコンピューティングサービスと多くの部分で 1:1 対応があるが、特に App Service は AWS の Elastic Beanstalk とは位置づけが大きく異なり、Azure では本番ワークロードの主力 PaaS として広く利用されている。また、Azure Functions の Durable Functions は AWS Step Functions 相当のオーケストレーション機能を内包しており、サーバーレスの設計パターンにも違いがある。

サービスマッピング一覧

主要サービス詳細

Azure Virtual Machines（AWS: EC2）

Azure 上で仮想マシンを起動・管理する IaaS サービスで、EC2 と同等の位置づけ。

AWS エンジニアが知っておくべき違い:

• VM サイズの命名体系が異なる — AWS の m5.xlarge のような命名に対し、Azure は Standard_D4s_v5 のように「ファミリー + vCPU 数 + 機能フラグ + 世代」で表現する。D は汎用（m 系相当）、E はメモリ最適化（r 系相当）、F はコンピューティング最適化（c 系相当）に対応する
• 可用性セット（Availability Set）は Azure 固有の概念 — 障害ドメイン（Fault Domain: 物理ラック単位の分離）と更新ドメイン（Update Domain: メンテナンス時のローリング更新単位）を定義する。AWS の AZ 分散とは異なるアプローチで冗長性を確保する仕組みだが、現在は可用性ゾーン（Availability Zone）の利用が推奨されている
• OS ディスクとデータディスクが明確に分離されている — EC2 では EBS ボリュームを自由にアタッチするが、Azure VM では OS ディスク（Managed Disk）が必ず 1 つ存在し、追加のデータディスクを別途アタッチする構成が標準
• AMI に相当するのは VM イメージ / Shared Image Gallery — Azure Marketplace のイメージまたは独自のカスタムイメージを使用する。Shared Image Gallery（Azure Compute Gallery）でイメージのバージョン管理やリージョン間レプリケーションが可能
• 停止状態には 2 種類ある — OS からの停止（Stopped）と Azure Portal / CLI からの停止（Deallocated）がある。Deallocated のみ課金が停止する。EC2 の「停止」は Azure の Deallocated に相当する

Azure Functions（AWS: Lambda）

イベント駆動のサーバーレスコンピューティングサービスで、Lambda と同等の位置づけ。

AWS エンジニアが知っておくべき違い:

• Durable Functions で Step Functions 相当の機能を内包 — 関数チェーン、ファンアウト・ファンイン、非同期 HTTP API、モニターパターンなどのオーケストレーション機能を、Functions の拡張機能として同一のプログラミングモデル内で実装できる。AWS では Lambda + Step Functions の 2 サービス構成が必要な処理を、Azure では Functions 単体で完結できる
• ホスティングプランが 3 種類ある — 従量課金の「消費プラン」（Lambda の標準モデルに相当）、事前プロビジョニングの「Premium プラン」（Provisioned Concurrency に近いがより柔軟）、App Service 上で動作する「専用プラン」がある。Premium プランでは常時ウォーム状態のインスタンスを維持でき、VNet 統合も可能
• 実行時間の上限が異なる — 消費プランでは最大 10 分（Lambda は 15 分）、Premium プランおよび専用プランでは実質無制限に設定可能
• バインディング機能で統合が宣言的 — Lambda ではイベントソースマッピングやコード内で SDK を呼び出すのに対し、Azure Functions は入出力バインディングを宣言的に定義することで、Blob Storage や Cosmos DB などとの連携コードを大幅に削減できる
• ローカル開発体験が充実 — Azure Functions Core Tools でローカル環境での完全な実行・デバッグが可能。Lambda のローカルテスト（SAM CLI）より統合度が高い

Azure App Service（AWS: Elastic Beanstalk に近いが高機能）

Web アプリケーション、REST API、モバイルバックエンドをホスティングするフルマネージドの PaaS サービス。

AWS エンジニアが知っておくべき違い:

• Azure の主力 PaaS であり、本番利用が一般的 — AWS では Elastic Beanstalk は開発・検証用途で使われることが多く、本番では EC2 + ALB や ECS が主流だが、Azure では App Service が本番ワークロードの第一選択肢として広く採用されている
• App Service Plan でリソースを共有 — 1 つの App Service Plan（インスタンスサイズとスケール設定を定義）上に複数の Web App をデプロイできる。EC2 のように 1 対 1 のリソース割り当てではなく、Plan 単位でコストとスケーリングを管理する
• デプロイスロットでブルー/グリーンデプロイが標準機能 — ステージングスロットにデプロイし、スワップ操作で本番に切り替える。AWS では CodeDeploy や ALB のターゲットグループ切り替えで実現する機能が、App Service に組み込まれている
• 組み込みの認証機能（Easy Auth） — Microsoft Entra ID、Google、Facebook 等の認証プロバイダーとの統合がコード変更なしで可能。AWS では Cognito + ALB 認証や API Gateway の認証設定が必要
• カスタムドメインと TLS 証明書の管理が統合 — App Service Managed Certificate で無料の TLS 証明書を自動発行・更新できる。AWS では ACM + ALB / CloudFront の構成が必要

Azure Batch（AWS: AWS Batch）

大規模な並列コンピューティングやハイパフォーマンスコンピューティング（HPC）ジョブをスケジュール・実行するマネージドサービス。

AWS エンジニアが知っておくべき違い:

• 概念と機能はほぼ同等 — プール（コンピューティングノードの集合）、ジョブ、タスクという階層構造は AWS Batch と類似している
• ノードプールの管理がより明示的 — AWS Batch ではコンピュートリソースが自動管理されるが、Azure Batch ではプール内のノード数やスケーリングルールをより細かく制御する
• Batch Explorer（GUI ツール）が提供されている — ジョブの監視やデバッグ用のデスクトップアプリケーションが公式に提供されている

VM Scale Sets / VMSS（AWS: Auto Scaling Group）

同一構成の VM インスタンスをグループとして管理し、負荷に応じて自動スケーリングするサービス。

AWS エンジニアが知っておくべき違い:

• スケールセット自体がリソースとして独立 — AWS の Auto Scaling Group は起動テンプレートと組み合わせて使用するが、VMSS はイメージ、ネットワーク設定、スケーリングポリシーを単一リソースとして管理する
• Flexible オーケストレーションモードが推奨 — 従来の Uniform モードに加え、Flexible モードでは異なる VM サイズの混在や可用性ゾーンへの分散がより柔軟に行える
• オーバープロビジョニング機能 — スケールアウト時に要求数より多くの VM を起動し、先に準備完了したものを採用して残りを削除することで、デプロイ成功率を向上させる Azure 固有の機能がある

Azure Spot VMs（AWS: EC2 Spot Instances）

Azure の余剰キャパシティを割引価格で利用できる VM インスタンス。

AWS エンジニアが知っておくべき違い:

• エビクションポリシーが選択可能 — 退避時に VM を停止（Deallocate）するか削除するかを選択できる。EC2 Spot は終了（Terminate）が基本
• 最大価格の設定が可能 — 現在の Spot 価格が設定した最大価格を超えると退避される。EC2 Spot も同様の仕組みだが、Azure では「現在の従量課金価格まで」をデフォルトとして設定できる
• VMSS との統合 — VM Scale Sets 内で通常の VM と Spot VM を混在させることが可能。EC2 の混合インスタンスポリシーに相当する

Azure Dedicated Host（AWS: EC2 Dedicated Hosts）

物理サーバーを専有し、その上に VM をデプロイするサービス。

AWS エンジニアが知っておくべき違い:

• 概念と用途はほぼ同一 — ライセンス持ち込み（BYOL）、コンプライアンス要件、物理的な分離要件で使用する
• ホストグループで管理 — 複数の Dedicated Host をホストグループとしてまとめ、可用性ゾーンやメンテナンスポリシーを一括管理できる
• 自動配置機能 — ホストグループに対して VM の自動配置を有効にすると、空きのある Dedicated Host に自動的に VM が配置される

AWS との主要な違い

App Service 中心のアーキテクチャ

AWS では Web アプリケーションのホスティングに EC2 + ALB、ECS / Fargate、Lambda + API Gateway など複数の選択肢があり、ユースケースに応じて使い分ける。Azure では App Service が PaaS の主力サービスとして広く採用されており、「まず App Service で要件を満たせるか検討し、満たせない場合に VM や Container Apps を検討する」というアプローチが一般的。Elastic Beanstalk が AWS で本番利用されるケースは少ないが、App Service は Azure の本番ワークロードで最も利用されるコンピューティングサービスの一つである。

サーバーレスオーケストレーションの統合度

AWS では Lambda（関数実行）と Step Functions（オーケストレーション）が別サービスとして提供されるが、Azure では Durable Functions として Functions の拡張機能に統合されている。このため、関数の実行とワークフローの定義を同一のコードベース・プログラミングモデルで実装でき、学習コストとインフラ管理のオーバーヘッドが小さい。一方、Step Functions のようなビジュアルワークフローエディタは Durable Functions にはなく、コードベースでの定義が前提となる。

VM サイズの命名体系

AWS のインスタンスタイプ（例: m5.xlarge）は「ファミリー + 世代 + サイズ」で構成され直感的に理解しやすいが、Azure の VM サイズ（例: Standard_D4s_v5）は「ファミリー + vCPU 数 + 機能フラグ + 世代」で構成される。機能フラグには s（Premium Storage 対応）、d（ローカルディスク付き）、a（AMD プロセッサ）、p（ARM プロセッサ）などがあり、組み合わせで性能特性が決まる。慣れるまでは Azure VM サイズのドキュメントを参照することを推奨する。

可用性モデルの違い

AWS は Availability Zone（AZ）による物理的な分離を冗長性の基本としているが、Azure にはこれに加えて可用性セット（Availability Set）という独自の概念がある。可用性セットは障害ドメイン（物理ラック単位）と更新ドメイン（メンテナンス時のローリング更新単位）を定義し、同一データセンター内での冗長性を確保する。ただし、現在は Azure でも可用性ゾーン（AZ）を使った分散が推奨されており、新規設計では可用性ゾーンを基本とするのがベストプラクティスである。

サービス選定の指針