Azure App Serviceとは？PaaSの概要・対応スタック・App Service Plan・価格レベルを解説

「AzureでWebアプリを動かすなら、まず App Service を使え」——学習していると必ず出会うサービスですが、いざ「App Serviceって何？」「App Service Planとどう違うの？」と聞かれると、うまく説明できずに詰まってしまう方は多いはずです。

名前は知ってるし作ったこともあるけど、「Plan」とか「価格レベル」の関係がモヤっとしたまま使ってる…

この記事では、App Serviceの「概要」だけに絞って、次の4つを順番に整理します。読み終えたときに、この4つを自分の言葉で説明できるようになることをゴールにしています。

App Serviceが何か（Web/APIをホストするフルマネージドPaaS）を説明できる
対応スタック（.NET / Node / Python / Java / コンテナ）を把握している
App Service Plan（OS・SKU・スケール単位）の概念を理解している
価格レベル（Free〜Isolated）とスケール上限の違いを理解している

デプロイ手順や細かい設定は別記事に譲り、ここでは「そもそも何者なのか」という土台を固めます。各セクションの最後に「これが説明できればOK」という自己チェックの目安を置いていますので、学習の到達度確認にも使ってください。

App Serviceとは？（Web/APIをホストするフルマネージドPaaS）
対応スタック（.NET / Node / Python / Java / コンテナ）
App Service Plan（OS・SKU・スケール単位）の概念
価格レベル（Free〜Isolated）とスケール上限の違い
まとめ
あわせて読みたい

App Serviceとは？（Web/APIをホストするフルマネージドPaaS）

Azure App Serviceとは、Webアプリ・REST API・モバイルバックエンドを、サーバーの管理なしでホストできるフルマネージドのPaaS（Platform as a Service）です。

ポイントは「フルマネージドのPaaS」という点です。仮想マシン（IaaS）でWebアプリを動かす場合、OSのアップデート、ミドルウェア（IISやnginx）のインストール、パッチ適用、負荷分散の構成…といった「土台の面倒」を全部自分で見る必要があります。App Serviceは、この土台の部分をAzure側がまるごと引き受けてくれます。

身近な例で言うと、賃貸マンションの「サービス付き物件」をイメージすると分かりやすいでしょう。建物の管理・清掃・設備の保守（＝OSやミドルウェアの面倒）は管理会社（＝Azure）がやってくれて、あなたは部屋の中の家具＝アプリのコードを持ち込むだけで住み始められる——それがApp Serviceの世界観です。

App Serviceが担ってくれる代表的な「土台の面倒」は次のとおりです。

OS・パッチ管理（セキュリティ更新も自動）
負荷分散とスケール（インスタンスを増やす／減らすを設定だけで）
HTTPS/TLS・カスタムドメイン、デプロイの仕組み、ログ・監視の統合
高可用性（既定の *.azurewebsites.net ドメインですぐ公開できる）

つまりApp Serviceは、「インフラの管理から解放されて、アプリのコードに集中したい」というニーズにドンピシャで応えるサービスです。Webアプリ（Web Apps）、API（API Apps）、モバイルアプリのバックエンドといった用途を、同じ仕組みでホストできます。

【ここが説明できればOK①】
「App Serviceは、Web/API/モバイルバックエンドをサーバー管理なしでホストできるフルマネージドPaaSである」——これを自分の言葉で言えれば、1つ目のチェックはクリアです。

対応スタック（.NET / Node / Python / Java / コンテナ）

「PaaSだと、使える言語やフレームワークが限られるのでは？」と心配になるかもしれませんが、App Serviceは主要な言語・ランタイムを幅広くサポートしています。大きく分けると、次の2つのデプロイ方法があります。

組み込みランタイム（コードデプロイ）：Azureが用意した言語ランタイム上で、コードをそのまま動かす方式。.NET / .NET Core、Node.js、Python、Java、PHP などが対象。
カスタムコンテナ（コンテナデプロイ）：自分で用意した Dockerイメージ（Web App for Containers）を動かす方式。組み込みにない言語・バージョン・依存関係を使いたいときの逃げ道になる。

ここが重要なポイントで、「まずは組み込みランタイムで手軽に、要件が特殊ならコンテナで柔軟に」という2段構えになっています。標準的なWebアプリなら組み込みランタイムを選ぶだけでOK、「どうしても特定バージョンの言語が必要」「独自のミドルウェアを同梱したい」といったケースではコンテナに切り替える、という使い分けです。

「組み込みで足りなければコンテナ」。この2段構えを覚えておけば、スタック選びで迷わないよ！

なお、App Serviceには Windows と Linux の2つのOSがあり、選んだOSによって使えるスタックや機能に一部差があります（このOSの選択が、次に説明するApp Service Planと深く関わってきます）。対応する言語やバージョンは随時更新されるため、最新の対応状況は必ず公式ドキュメントで確認してください。

【ここが説明できればOK②】
「App Serviceは.NET/Node/Python/Java等の組み込みランタイムに加え、カスタムコンテナ（Web App for Containers）でもデプロイできる」——これを言えれば、2つ目のチェックはクリアです。

App Service Plan（OS・SKU・スケール単位）の概念

App Serviceを理解するうえで一番の山場が、この App Service Plan です。ここを押さえると、App Serviceの全体像が一気にクリアになります。

App Service Planとは、アプリを動かす「コンピューティングの土台（サーバー群）」を定義する単位です。OS（Windows/Linux）・SKU（性能とスペック）・リージョン・インスタンス数を、このPlanが決めます。

ここで大切なのが、「Web App（アプリ本体）」と「App Service Plan（土台）」は別物だということです。両者の関係を図にすると、こうなります。

 ┌──────────────────────────────────────────────┐
 │        App Service Plan（土台・サーバー群）      │
 │   OS: Linux / SKU: P1v3 / インスタンス数: 3    │
 │                                                │
 │   ┌──────────┐ ┌──────────┐ ┌──────────┐      │
 │   │ Web App A │ │ Web App B │ │  API App  │  … │
 │   │ (本番サイト)│ │ (管理画面) │ │ (バックエンド)│    │
 │   └──────────┘ └──────────┘ └──────────┘      │
 │        ▲ 同じPlan上の複数アプリが                 │
 │          土台のCPU/メモリを共有する               │
 └──────────────────────────────────────────────┘

ポイントは「1つのApp Service Planの上に、複数のアプリ（Web App）を載せられる」という点です。マンションの例えに戻すと、App Service Plan＝建物（何階建てで、どんな設備か）、Web App＝各部屋（住人）のイメージです。1棟のマンション（Plan）に複数の部屋（アプリ）が入り、建物の広さやグレード（SKU）を全部屋で共有します。

App Service Planが決めるものを整理すると、次の3つです。

OS：WindowsかLinuxか（Planを作るときに決まり、後から変更できない）
SKU（価格レベル）：1インスタンスあたりのCPU・メモリ・使える機能。これが料金と性能を決める（次のセクションで詳述）
インスタンス数（スケール単位）：同じ土台を何台に増やすか（スケールアウト）。この台数分の料金がかかる

そして課金はこのApp Service Plan単位で発生します。「Web Appを1個作ったから課金」ではなく、「そのアプリが載っているPlanのSKU × インスタンス数」で料金が決まる、という点は必ず押さえておきましょう。同じPlanに10個アプリを載せても、Planが1つなら土台の料金は1つ分です（ただしCPU/メモリは共有なので、詰め込みすぎると互いに遅くなります）。

【ここが説明できればOK③】
「App Service Planは、OS・SKU・インスタンス数を定めるコンピューティングの土台で、課金はPlan単位。1つのPlanに複数のアプリを載せられる」——これを説明できれば、3つ目のチェックはクリアです。

価格レベル（Free〜Isolated）とスケール上限の違い

App Service Planを作るときに選ぶ SKU＝価格レベル（Pricing tier） は、性能・料金・使える機能・スケール上限を一括で決める、いわば「グレードの選択」です。大きく次のような階層になっています（下にいくほど高機能・高価格）。

Free / Shared：無料〜低価格のお試し・検証用。他の利用者と土台を共有（共有コンピューティング）。スケールアウト不可、カスタムドメインやSLAなどに制約が多い。学習の最初の一歩向け。
Basic：専用インスタンスになる入門レベル。カスタムドメイン・独自TLSが使えるが、自動スケールやデプロイスロットは未対応。小規模・開発環境向け。
Standard：本番運用の標準。自動スケール（スケールアウト）、デプロイスロット、日次バックアップなどが解禁される、実務でよく使うライン。
Premium（v2/v3）：高性能・高スケール。より強力なインスタンスと多くのスケールアウト上限、より多くのデプロイスロットに対応。本番の主力。
Isolated（App Service Environment）：専用の隔離環境。自分専用のネットワーク（VNet）内にApp Serviceを丸ごと閉じ込められる、最大のスケール上限とセキュリティ。金融・大企業などの厳格な要件向け。

ここで理解すべき本質は、「価格レベルは単なる料金の差ではなく、”使える機能”と”スケール上限”の差でもある」という点です。たとえば——

自動スケール（スケールアウト）やデプロイスロットを使いたい → Standard以上が必要
スケールできる最大インスタンス数の上限は、レベルが上がるほど大きくなる（Freeは1台固定、Premiumはより多く）
閉域ネットワークに完全隔離したい → Isolatedでしか実現できない要件がある

つまり「機能が足りない」と感じたら、まず価格レベルを上げる（スケールアップ）ことで解決するケースが多い、という構造になっています。具体的なインスタンス数の上限や料金は世代・リージョンで変わり、随時改定されるため、正確な数値は必ず公式の料金ページで最新情報を確認してください（この記事の階層イメージはあくまで全体像の把握用です）。