Fucntionsの料金プラン変更について

Question

ある関数（料金プラン：Standard S2）を表示した際、

画面の上部に以下のようなメッセージが表示されます。

「同じ価格でパフォーマンスの向上と機能の追加が可能です!Premium V2 を確認してください。」

「Standard S2」と「Premium v2 P1V2」を確認したところ、

同じ価格で、「Premium v2 P1V2」の方が

ACU/vCPU、リモート記憶域、スケール（インスタンス）で優れているのがわかります。

このとき、「Premium v2 P1V2」に変更するのにあたり、留意することはありますか？

「Premium v2 P1V2」のスケール（インスタンス）が「Standard S2」より3倍となっており、

関数の実行タスクが多いので、利用金額が3倍になってしまわないか気にしています。

Answer 1

こんにちは @dla-d ！状況を整理すると、Azure Functions のホスティングプランで Standard S2 → Premium V2（Elastic Premium） のように上位プランへ切り替える検討をされていて、「スケール（インスタンス）が増える＝利用金額が3倍になるのでは？」が不安、という相談ですね。

結論から言うと、Premium v2 へ変えると**“実行された回数ごと課金”ではなく “インスタンス（ホスト）に割り当てるリソース前提の課金”**の考え方になるため、単純に「3倍のインスタンス＝3倍請求」とは限りません。ただし Premium プランはアイドル時でも最低1インスタンスは課金対象になります。

変更時に留意するポイント（Premium v2 への移行/切り替え）

1) Premium（Elastic Premium）は課金モデルが違う

Premium プランは 実行回数（execution）課金がなく、 Premiumプランは “core seconds とメモリ” を、インスタンス数に応じて課金する形です。 そのため、Consumption のように「使った分だけ（実行ごとに）増える」感覚とはズレます。

• Premium プラン：実行（execution）課金なし
• さらに：Premiumプランは常に少なくとも1つのアクティブ（課金対象）インスタンスがある → アイドル時でも最小費用が発生しやすいです。

2) “最大スケール”は上限で、実際に常時3倍稼働するとは限らない

Premium でも イベント需要に応じてホスト（インスタンス）を追加/削除します（Consumption/Flex と同様の考え方）。 また、同一 App Service Plan 内でも アプリごとにスケールは独立し、可能な範囲で VM リソースを共有してコストを抑えます。

加えて、Premium には

• plan の最大バースト（burst）に加えて
• per-app の最大（app scale limit）を設定可能 があります。

つまり「最大で3倍になる可能性」はあっても、実際の増え方は負荷と上限設定次第です。

3) “Premium v2” が Elastic Premium なのか（Dedicated Premium ではないか）を要確認

ドキュメント上の重要注意点として、App Service プラットフォームでは SKU 名により挙動が変わります。

• SKU が “EP1 のように E で始まる”：Elastic Premium（Premium plan の自動スケールの対象）
• SKU が “P1V2 のように P で始まる”：Dedicated hosting（動的スケールしない可能性があり、コストが増える要因になり得ます）

今回の比較で出ている “Premium v2 P1V2” が、もし P で始まる Dedicated 系なら、意図している「Elastic Premium と同様のスケール抑制」ではなく、想定よりコストが増える方向に働く可能性があります。 → ここは切り替え前に必ず確認した方が安全です。

4) スケール上限は設定しておくのが安心

Premium には per-app の最大スケールアウト上限を設定できます（app scale limit）。 この上限は プラン側の最大 burst instances を超えられません。

「高負荷時に性能が欲しいが、課金が膨らみすぎるのが怖い」という場合は、ここをチューニングするのが現実的です。こんにちは！状況を整理すると、Azure Functions のホスティングプランで Standard S2 → Premium V2（Elastic Premium） のように上位プランへ切り替える検討をされていて、「スケール（インスタンス）が増える＝利用金額が3倍になるのでは？」が不安、という相談ですね。

結論から言うと、Premium v2 へ変えると**“実行された回数ごと課金”ではなく “インスタンス（ホスト）に割り当てるリソース前提の課金”**の考え方になるため、単純に「3倍のインスタンス＝3倍請求」とは限りません。ただし Premium プランはアイドル時でも最低1インスタンスは課金対象になります。

変更時に留意するポイント（Premium v2 への移行/切り替え）

1) Premium（Elastic Premium）は課金モデルが違う

Premium プランは 実行回数（execution）課金がなく、

Premiumプランは “core seconds とメモリ” を、インスタンス数に応じて課金する形です。

そのため、Consumption のように「使った分だけ（実行ごとに）増える」感覚とはズレます。

• Premium プラン：実行（execution）課金なし
• さらに：Premiumプランは常に少なくとも1つのアクティブ（課金対象）インスタンスがある → アイドル時でも最小費用が発生しやすいです。

2) “最大スケール”は上限で、実際に常時3倍稼働するとは限らない

Premium でも イベント需要に応じてホスト（インスタンス）を追加/削除します（Consumption/Flex と同様の考え方）。

また、同一 App Service Plan 内でも アプリごとにスケールは独立し、可能な範囲で VM リソースを共有してコストを抑えます。

加えて、Premium には

• plan の最大バースト（burst）に加えて
• per-app の最大（app scale limit）を設定可能 があります。

つまり「最大で3倍になる可能性」はあっても、実際の増え方は負荷と上限設定次第です。

3) “Premium v2” が Elastic Premium なのか（Dedicated Premium ではないか）を要確認

ドキュメント上の重要注意点として、App Service プラットフォームでは SKU 名により挙動が変わります。

• SKU が “EP1 のように E で始まる”：Elastic Premium（Premium plan の自動スケールの対象）
• SKU が “P1V2 のように P で始まる”：Dedicated hosting（動的スケールしない可能性があり、コストが増える要因になり得ます）

今回の比較で出ている “Premium v2 P1V2” が、もし P で始まる Dedicated 系なら、意図している「Elastic Premium と同様のスケール抑制」ではなく、想定よりコストが増える方向に働く可能性があります。

→ ここは切り替え前に必ず確認した方が安全です。

4) スケール上限は設定しておくのが安心

Premium には per-app の最大スケールアウト上限を設定できます（app scale limit）。

この上限は プラン側の最大 burst instances を超えられません。

「高負荷時に性能が欲しいが、課金が膨らみすぎるのが怖い」という場合は、ここをチューニングするのが現実的です。 こんにちは @dla-d

この回答がご質問の解決につながりましたら、「回答を承認（Accept Answer）」し、「この回答は役に立ちましたか？」という質問に対して「はい（Yes）」を選択していただければ幸いです。また、他に何かご質問がございましたら、お気軽にお知らせください。