Azure Functions のスケールとホスティングAzure Functions scale and hosting

Azure で関数アプリを作成するときは、アプリのホスティング プランを選択する必要があります。When you create a function app in Azure, you must choose a hosting plan for your app. Azure Functions で利用できる基本のホスティング プランは 3 つあります。従量課金プランPremium プラン専用 (App Service) プランです。There are three basic hosting plans available for Azure Functions: Consumption plan, Premium plan, and Dedicated (App Service) plan. すべてのホスティング プランは、Linux と Windows 仮想マシンの両方で、一般提供 (GA) されています。All hosting plans are generally available (GA) on both Linux and Windows virtual machines.

お客様が選択したホスティング プランによって、次の動作が決まります。The hosting plan you choose dictates the following behaviors:

  • 関数アプリをスケールする方法。How your function app is scaled.
  • 各関数アプリ インスタンスに利用できるリソース。The resources available to each function app instance.
  • Azure Virtual Network 接続などの高度な機能のサポート。Support for advanced features, such as Azure Virtual Network connectivity.

従量課金プランと Premium プランのいずれも、コードの実行時に自動的にコンピューティング能力が追加されます。Both Consumption and Premium plans automatically add compute power when your code is running. アプリは、負荷を処理する必要があるときはスケールアウトされ、コードの実行が停止するとスケールインされます。Your app is scaled out when needed to handle load, and scaled in when code stops running. 従量課金プランの場合、アイドル状態の仮想マシンの料金や、予約容量の事前の料金を支払う必要もありません。For the Consumption plan, you also don't have to pay for idle VMs or reserve capacity in advance.

Premium プランには、Premium コンピューティング インスタンス、無期限にインスタンスをウォーム状態に保つ機能、VNet 接続などの追加機能があります。Premium plan provides additional features, such as premium compute instances, the ability to keep instances warm indefinitely, and VNet connectivity.

App Service プランでは、お客様が管理している専用のインフラストラクチャを利用できます。App Service plan allows you to take advantage of dedicated infrastructure, which you manage. 関数アプリを使用しても、イベントに基づくスケーリングは行われません。つまり、ゼロにスケールインされることはありません。Your function app doesn't scale based on events, which means it never scales in to zero. ([常時接続] を有効にする必要があります)。(Requires that Always on is enabled.)

さまざまなホスティング プラン (Kubernetes ベースのホスティングを含む) の詳細な比較については、ホスティング プランの比較セクションを参照してください。For a detailed comparison between the various hosting plans (including Kubernetes-based hosting), see the Hosting plans comparison section.

従量課金プランConsumption plan

従量課金プランを使用する場合、Azure Functions ホストのインスタンスは、受信イベントの数に基づいて動的に追加および削除されます。When you're using the Consumption plan, instances of the Azure Functions host are dynamically added and removed based on the number of incoming events. このサーバーレス プランではスケーリングが自動的に行われ、関数の実行中にのみコンピューティング リソースに対して料金が発生します。This serverless plan scales automatically, and you're charged for compute resources only when your functions are running. 従量課金プランでは、構成可能な期間が経過すると関数の実行はタイムアウトします。On a Consumption plan, a function execution times out after a configurable period of time.

課金は、実行数、実行時間、およびメモリの使用量に基づいて行われ、Billing is based on number of executions, execution time, and memory used. 使用量は、関数アプリ内のすべての関数にわたって集計されます。Usage is aggregated across all functions within a function app. 詳細については、Azure Functions の価格に関するページを参照してください。For more information, see the Azure Functions pricing page.

従量課金プランは既定のホスティング プランであり、次の利点があります。The Consumption plan is the default hosting plan and offers the following benefits:

  • 関数の実行中にのみ課金されます。Pay only when your functions are running
  • 負荷が高い期間中であっても、自動的にスケールアウトされます。Scale out automatically, even during periods of high load

同じリージョンの関数アプリを同じ従量課金プランに割り当てることができます。Function apps in the same region can be assigned to the same Consumption plan. 同じ従量課金制プランで複数のアプリケーションを実行しても、マイナス面や影響はありません。There's no downside or impact to having multiple apps running in the same Consumption plan. 同じ従量課金プランに複数のアプリを割り当てても、各アプリの回復性、スケーラビリティ、または信頼性には影響しません。Assigning multiple apps to the same Consumption plan has no impact on resilience, scalability, or reliability of each app.

従量課金プランで実行しているときのコストを見積もる方法の詳細については、従量課金プランのコストの概要に関するページを参照してください。To learn more about how to estimate costs when running in a Consumption plan, see Understanding Consumption plan costs.

Premium プランPremium plan

Premium プランを使用すると、従量課金プランと同じように、Azure Functions ホストのインスタンスが、受信イベントの数に基づいて追加および削除されます。When you're using the Premium plan, instances of the Azure Functions host are added and removed based on the number of incoming events just like the Consumption plan. Premium プランは次の機能をサポートします。Premium plan supports the following features:

  • コールド スタートを回避するために常にウォーム状態のインスタンスPerpetually warm instances to avoid any cold start
  • VNet の接続VNet connectivity
  • 無制限の実行期間 (60 分保証)Unlimited execution duration (60 minutes guaranteed)
  • Premium インスタンス サイズ (1 コア、2 コア、4 コアのインスタンス)Premium instance sizes (one core, two core, and four core instances)
  • 予測可能な料金More predictable pricing
  • 複数の関数アプリを含むプランでの高密度アプリ割り当てHigh-density app allocation for plans with multiple function apps

Premium プランで関数アプリを作成する方法については、「Azure Functions の Premium プラン」を参照してください。To learn how you can create a function app in a Premium plan, see Azure Functions Premium plan.

Premium プランの課金は、実行や消費されたメモリごとの課金ではなく、インスタンス全体に割り当てられているコア秒数とメモリに基づいています。Instead of billing per execution and memory consumed, billing for the Premium plan is based on the number of core seconds and memory allocated across instances. Premium プランの場合、実行料金は発生しません。There is no execution charge with the Premium plan. 1 つのプランにつき、少なくとも 1 つのインスタンスが常に割り当てられている必要があります。At least one instance must be allocated at all times per plan. その結果として、関数がアクティブかアイドル状態かに関係なく、アクティブなプラン別の月あたりコストが最も少なくなります。This results in a minimum monthly cost per active plan, regardless if the function is active or idle. Premium プランのすべての関数アプリで割り当てられたインスタンスが共有されることにご注意ください。Keep in mind that all function apps in a Premium plan share allocated instances.

次のような状況では、Azure Functions の Premium プランを検討してください。Consider the Azure Functions Premium plan in the following situations:

  • 関数を継続的に、またはほぼ継続的に実行したい。Your function apps run continuously, or nearly continuously.
  • 小規模な実行の回数が多く、実行料金が高いが、従量課金プランでの GB 秒の請求額は低い。You have a high number of small executions and have a high execution bill but low GB second bill in the Consumption plan.
  • 従量課金プランで提供されるよりも多くの CPU またはメモリのオプションが必要である。You need more CPU or memory options than what is provided by the Consumption plan.
  • 従量課金プランで許可されている最大実行時間よりも長くコードを実行する必要がある。Your code needs to run longer than the maximum execution time allowed on the Consumption plan.
  • 仮想ネットワーク接続など、Premium プランでのみ利用できる機能が必要である。You require features that are only available on a Premium plan, such as virtual network connectivity.

専用 (App Service) プランDedicated (App Service) plan

関数アプリは、他の App Service アプリ (Basic、Standard、Premium、Isolated SKU) と同じ専用 VM 上でも実行できます。Your function apps can also run on the same dedicated VMs as other App Service apps (Basic, Standard, Premium, and Isolated SKUs).

次のような状況では、App Service プランを検討してください。Consider an App Service plan in the following situations:

  • 既に他の App Service インスタンスを実行している、使用率の低い既存の VM がある。You have existing, underutilized VMs that are already running other App Service instances.
  • 関数を実行するカスタム イメージを提供したい。You want to provide a custom image on which to run your functions.

App Service プランの関数アプリに対する支払いは、Web アプリなどの他の App Service リソースの場合と同じです。You pay the same for function apps in an App Service Plan as you would for other App Service resources, like web apps. App Service プランの仕組みの詳細については、「Azure App Service プランの詳細な概要」を参照してください。For details about how the App Service plan works, see the Azure App Service plans in-depth overview.

App Service プランを使用し、VM インスタンスを追加して、手動でスケールアウトできます。Using an App Service plan, you can manually scale out by adding more VM instances. 自動スケーリングを有効にすることもできます。ただし、自動スケーリングは、Premium プランのエラスティック スケールより遅くなります。You can also enable autoscale, though autoscale will be slower than the elastic scale of the Premium plan. 詳細については、「手動または自動によるインスタンス数のスケール変更」を参照してください。For more information, see Scale instance count manually or automatically. 別の App Service プランを選択してスケールアップすることもできます。You can also scale up by choosing a different App Service plan. 詳細については、 Azure でのアプリのスケールアップ に関するページを参照してください。For more information, see Scale up an app in Azure.

App Service プランで JavaScript 関数を実行する場合は、CPUの少ないプランを選択してください。When running JavaScript functions on an App Service plan, you should choose a plan that has fewer vCPUs. 詳細については、シングルコア App Service プランの選択に関するページをご覧ください。For more information, see Choose single-core App Service plans.

App Service Environment (ASE) で実行すると、関数を完全に分離し、App Service Plan より多い数のインスタンスを活用できます。Running in an App Service Environment (ASE) lets you fully isolate your functions and take advantage of higher number of instances than an App Service Plan.

常にオンAlways On

App Service プランを実行する場合、関数アプリが正常に実行されるように、常時接続 設定を有効にする必要があります。If you run on an App Service plan, you should enable the Always on setting so that your function app runs correctly. App Service プランでは、関数のランタイムは非アクティブな状態が数分続くとアイドル状態となるため、関数を "起こす" ことができるのは HTTP トリガーのみとなります。On an App Service plan, the functions runtime goes idle after a few minutes of inactivity, so only HTTP triggers will "wake up" your functions. 常時接続は App Service プランでのみ使用可能です。Always on is available only on an App Service plan. 従量課金プランでは、関数アプリはプラットフォームにより自動的にアクティブ化されます。On a Consumption plan, the platform activates function apps automatically.

Function App タイムアウト期間Function app timeout duration

関数アプリのタイムアウト期間は、host.json プロジェクト ファイルの functionTimeout プロパティによって定義されます。The timeout duration of a function app is defined by the functionTimeout property in the host.json project file. 次の表は、両方のプランと各種ランタイム バージョンでの既定と最大値 (分単位) を示します。The following table shows the default and maximum values in minutes for both plans and the different runtime versions:

プランPlan ランタイム バージョンRuntime Version DefaultDefault 最大値Maximum
従量課金Consumption 1.x1.x 55 1010
従量課金Consumption 2.x2.x 55 1010
従量課金Consumption 3.x3.x 55 1010
PremiumPremium 1.x1.x 3030 無制限Unlimited
PremiumPremium 2.x2.x 3030 無制限Unlimited
PremiumPremium 3.x3.x 3030 無制限Unlimited
App ServiceApp Service 1.x1.x 無制限Unlimited 無制限Unlimited
App ServiceApp Service 2.x2.x 3030 無制限Unlimited
App ServiceApp Service 3.x3.x 3030 無制限Unlimited

注意

関数アプリのタイムアウト設定に関係なく 230 秒は、HTTP トリガー関数が要求に応答できる最大時間です。Regardless of the function app timeout setting, 230 seconds is the maximum amount of time that an HTTP triggered function can take to respond to a request. これは、Azure Load Balancer の既定のアイドル タイムアウトによるものですThis is because of the default idle timeout of Azure Load Balancer. より長い処理時間では、Durable Functions async pattern の使用を検討するか、実際の作業を遅らせて、即座に応答を返しますFor longer processing times, consider using the Durable Functions async pattern or defer the actual work and return an immediate response.

常時接続が有効になっている場合でも、個々の関数の実行タイムアウトは host.json プロジェクト ファイルの functionTimeout 設定によって制御できます。Even with Always On enabled, the execution timeout for individual functions is controlled by the functionTimeout setting in the host.json project file.

既存のアプリケーションのホスティング プランを決定するDetermine the hosting plan of an existing application

自分の関数アプリで使用されるホスティング プランを確認するには、Azure portal で関数アプリの [概要] タブの [App Service プラン] を表示します。To determine the hosting plan used by your function app, see App Service plan in the Overview tab for the function app in the Azure portal. 価格レベルを表示するには、 [App Service プラン] の名前を選択し、左側のウィンドウから [プロパティ] を選択します。To see the pricing tier, select the name of the App Service Plan, and then select Properties from the left pane.

ポータルでのスケーリング プランの表示

次のように、プランを判断するのに、Azure CLI を使用することもできます。You can also use the Azure CLI to determine the plan, as follows:

appServicePlanId=$(az functionapp show --name <my_function_app_name> --resource-group <my_resource_group> --query appServicePlanId --output tsv)
az appservice plan list --query "[?id=='$appServicePlanId'].sku.tier" --output tsv

このコマンドの出力が dynamic の場合、関数アプリは従量課金プランです。When the output from this command is dynamic, your function app is in the Consumption plan. このコマンドの出力が ElasticPremium の場合、関数アプリは Premium プランです。When the output from this command is ElasticPremium, your function app is in the Premium plan. その他すべての値は、App Service プランの各レベルを示します。All other values indicate different tiers of an App Service plan.

ストレージ アカウントの要件Storage account requirements

どのプランでも、関数アプリを使用するには、Azure BLOB、Queue、Files、Table Storage をサポートする一般的な Azure ストレージ アカウントが必要です。On any plan, a function app requires a general Azure Storage account, which supports Azure Blob, Queue, Files, and Table storage. これは、Azure Functions が、Azure Storage を利用してトリガーの管理や関数実行のログなどの操作を行っているためですが、ストレージ アカウントによってはキューと表はサポートされません。This is because Azure Functions relies on Azure Storage for operations such as managing triggers and logging function executions, but some storage accounts don't support queues and tables. そのようなアカウント (BLOB専用ストレージ アカウント (including premium storage) や、ゾーン冗長ストレージ レプリケーションを備えた汎用ストレージ アカウントなど) は、関数アプリを作成するときに既存の [ストレージ アカウント] の選択肢から除外されます。These accounts, which include blob-only storage accounts (including premium storage) and general-purpose storage accounts with zone-redundant storage replication, are filtered-out from your existing Storage Account selections when you create a function app.

関数アプリで使用されるものと同じストレージ アカウントを、アプリケーション データを格納するためのトリガーとバインドで使用することもできます。The same storage account used by your function app can also be used by your triggers and bindings to store your application data. ただし、ストレージを集中的に使用する操作の場合は、別のストレージ アカウントを使用する必要があります。However, for storage-intensive operations, you should use a separate storage account.

複数の関数アプリでは、同じストレージ アカウントを問題なく共有できます。It's possible for multiple function apps to share the same storage account without any issues. (これの良い例は、1 つのストレージ アカウントのように動作する Azure ストレージ エミュレーターを使用してローカル環境で複数のアプリを開発する場合です。)(A good example of this is when you develop multiple apps in your local environment using the Azure Storage Emulator, which acts like one storage account.)

ストレージ アカウントの種類の詳細については、Azure Storage サービスの概要に関する記事をご覧ください。To learn more about storage account types, see Introducing the Azure Storage services.

リージョンのデータの保存場所In Region Data Residency

顧客データをすべて 1 つのリージョン内に留める必要があるときは、関数アプリに関連付けられているストレージ アカウントは、リージョン内冗長性が与えられたアカウントにする必要があります。When necessary for all customer data to remain within a single region, the storage account associated with the function app must be one with in region redundancy. リージョン内で冗長性を持つストレージ アカウントは、Durable Functions の Azure Durable Functions でも使用が求められることがあります。An in-region redundant storage account would also need to be used with Azure Durable Functions for Durable Functions.

プラットフォームで管理されるその他の顧客データは、Load Balancer App Service Environment (ILB ASE) でホストしているとき、そのリージョン内にのみ格納されます。Other platform-managed customer data will only be stored within the region when hosting in an Internal Load Balancer App Service Environment (or ILB ASE). 詳細については ASE ゾーンの冗長性に関するページを参照してください。Details can be found in ASE zone redundancy.

従量課金プランと Premium プランのしくみHow the Consumption and Premium plans work

従量課金プランと Premium プランでは、関数がトリガーされるイベントの数に基づいて Functions ホストのインスタンスを追加することで、Azure Functions インフラストラクチャによって CPU とメモリのリソースがスケーリングされます。In the Consumption and Premium plans, the Azure Functions infrastructure scales CPU and memory resources by adding additional instances of the Functions host, based on the number of events that its functions are triggered on. 従量課金プランの Functions ホストの各インスタンスは、1.5 GB のメモリと 1 個の CPU に制限されています。Each instance of the Functions host in the Consumption plan is limited to 1.5 GB of memory and one CPU. ホストのインスタンスは関数アプリ全体です。つまり、関数アプリ内のすべての関数がインスタンス内のリソースを共有し、同時にスケールされます。An instance of the host is the entire function app, meaning all functions within a function app share resource within an instance and scale at the same time. 同じ従量課金プランを共有する関数アプリは、個別にスケーリングされます。Function apps that share the same Consumption plan are scaled independently. Premium プランでは、プランのサイズにより、そのインスタンス上のそのプランのすべてのアプリで使用可能なメモリと CPU が決まります。In the Premium plan, your plan size will determine the available memory and CPU for all apps in that plan on that instance.

関数コード ファイルは、関数のメイン ストレージ アカウントの Azure Files 共有に格納されます。Function code files are stored on Azure Files shares on the function's main storage account. 関数アプリのメイン ストレージ アカウントを削除すると、関数コード ファイルは削除され、復元できません。When you delete the main storage account of the function app, the function code files are deleted and cannot be recovered.

実行時のスケーリングRuntime scaling

Azure Functions は "スケール コントローラー" と呼ばれるコンポーネントを使用して、イベント レートを監視し、スケールアウトとスケールインのどちらを実行するかを決定します。Azure Functions uses a component called the scale controller to monitor the rate of events and determine whether to scale out or scale in. スケール コントローラーは、トリガーの種類ごとにヒューリスティックを使用します。The scale controller uses heuristics for each trigger type. たとえば、Azure Queue Storage トリガーを使用した場合、拡大縮小はキューの長さや最も古いキュー メッセージの経過時間に基づいて実施されます。For example, when you're using an Azure Queue storage trigger, it scales based on the queue length and the age of the oldest queue message.

Azure Functions のスケールの単位は関数アプリです。The unit of scale for Azure Functions is the function app. 関数アプリがスケールアウトするときは、Azure Functions ホストの複数のインスタンスを実行するための追加リソースが割り当てられます。When the function app is scaled out, additional resources are allocated to run multiple instances of the Azure Functions host. 反対に、コンピューティングの需要が減ると、スケール コントローラーにより、関数ホストのインスタンスが削除されます。Conversely, as compute demand is reduced, the scale controller removes function host instances. 関数アプリ内で関数が何も実行されていない場合、インスタンスの数は最終的に 0 に "スケールイン" されます。The number of instances is eventually scaled in to zero when no functions are running within a function app.

イベントを監視してインスタンスを作成しているスケール コントローラー

コールド スタートCold Start

関数アプリが数分の間アイドル状態になると、プラットフォームによって、アプリが実行されるインスタンスの数が 0 にスケール ダウンされる可能性があります。After your function app has been idle for a number of minutes, the platform may scale the number of instances on which your app runs down to zero. 次の要求には、0 から 1 へのスケーリングの待機時間が追加されています。The next request has the added latency of scaling from zero to one. この待機時間は、コールド スタート と呼ばれます。This latency is referred to as a cold start. 関数アプリによって読み込まれる必要がある依存関係の数は、コールド スタート時間に影響を与える可能性があります。The number of dependencies that must be loaded by your function app can impact the cold start time. コールド スタートは、応答を必ず返す必要がある HTTP トリガーなどの同期操作においては問題です。Cold start is more of an issue for synchronous operations, such as HTTP triggers that must return a response. コールド スタートが関数に影響を与えている場合は、Always On が有効になっている Premium プランまたは専用プランで実行することを検討してください。If cold starts are impacting your functions, consider running in a Premium plan or in a Dedicated plan with Always on enabled.

スケーリングの動作についてUnderstanding scaling behaviors

スケーリングはさまざまな要因によって異なる可能性があり、選択したトリガーと言語に基づいて異なる方法でスケールします。Scaling can vary on a number of factors, and scale differently based on the trigger and language selected. スケーリング動作には、注意が必要な複雑な作業がいくつかあります。There are a few intricacies of scaling behaviors to be aware of:

  • 1 つの関数アプリがスケールアウトされるのは、最大 200 インスタンスまでのみとなります。A single function app only scales out to a maximum of 200 instances. 1 つのインスタンスで一度に複数のメッセージや要求を処理できるので、同時実行の数に上限は設定されていません。A single instance may process more than one message or request at a time though, so there isn't a set limit on number of concurrent executions. 必要な場合は最大値を下げてスケーリングを制限できます。You can specify a lower maximum to throttle scale as required.
  • HTTP トリガーの場合、新しいインスタンスは最大で 1 秒間に 1 回割り当てられます。For HTTP triggers, new instances are allocated, at most, once per second.
  • HTTP 以外のトリガーの場合、新しいインスタンスは最大で 30 秒ごとに 1 回割り当てられます。For non-HTTP triggers, new instances are allocated, at most, once every 30 seconds. Premium プランで実行しているときは、スケーリングが速くなります。Scaling is faster when running in a Premium plan.
  • Service Bus トリガーの場合、最も効率的なスケーリングを行うためには、リソースに対して "管理" 権限を使用します。For Service Bus triggers, use Manage rights on resources for the most efficient scaling. "リッスン" 権限では、スケーリングの決定を通知するためにキューの長さを使用できないため、スケーリングが正確ではありません。With Listen rights, scaling isn't as accurate because the queue length can't be used to inform scaling decisions. Service Bus アクセス ポリシーで権限を設定する方法の詳細については、「共有アクセス承認ポリシー」を参照してください。To learn more about setting rights in Service Bus access policies, see Shared Access Authorization Policy.
  • イベント ハブのトリガーについては、リファレンス記事のスケーリングのガイダンスを参照してください。For Event Hub triggers, see the scaling guidance in the reference article.

スケールアウトを制限するLimit scale out

アプリをスケールアウトするインスタンス数を制限したい場合があります。You may wish to restrict the number of instances an app scales out to. これは、データベースなどのダウンストリーム コンポーネントのスループットに制限があるケースで最も一般的です。This is most common for cases where a downstream component like a database has limited throughput. 既定では、従量課金プランの関数は最大 200 インスタンスにスケールアウトでき、Premium プランの関数は最大 100 インスタンスにスケールアウトできます。By default, consumption plan functions will scale out to as many as 200 instances, and premium plan functions will scale out to as many as 100 instances. 特定のアプリで最大値を下げるには、functionAppScaleLimit 値の指定を変更します。You can specify a lower maximum for a specific app by modifying the functionAppScaleLimit value. functionAppScaleLimit は、0、(制限しない場合は) null、1 からアプリの最大値間の有効値に設定できます。The functionAppScaleLimit can be set to 0 or null for unrestricted, or a valid value between 1 and the app maximum.

az resource update --resource-type Microsoft.Web/sites -g <resource_group> -n <function_app_name>/config/web --set properties.functionAppScaleLimit=<scale_limit>

スケーラブルなアプリのベスト プラクティスとパターンBest practices and patterns for scalable apps

関数アプリには、スケールに影響を及ぼすさまざまな側面 (ホスト構成、ランタイム フットプリント、リソースの効率など) があります。There are many aspects of a function app that will impact how well it will scale, including host configuration, runtime footprint, and resource efficiency. 詳細については、パフォーマンスの考慮事項に関する記事のスケーラビリティのセクションをご覧ください。For more information, see the scalability section of the performance considerations article. 関数アプリがスケールするにつれて、接続がどのように変化するかを認識する必要もあります。You should also be aware of how connections behave as your function app scales. 詳細については、「How to manage connections in Azure Functions」(Azure Functions で接続を管理する方法) を参照してください。For more information, see How to manage connections in Azure Functions.

Python と Node.js のスケールインの詳細については、「Azure Functions の Python 開発者向けガイド - スケーリングとコンカレンシー」および Azure Functions Node.js 開発者ガイド - スケーリングとコンカレンシーに関するページを参照してください。For more information on scaling in Python and Node.js, see Azure Functions Python developer guide - Scaling and concurrency and Azure Functions Node.js developer guide - Scaling and concurrency.

課金モデルBilling model

各プランの課金の詳細については、Azure Functions の価格に関するページを参照してください。Billing for the different plans is described in detail on the Azure Functions pricing page. 使用量は Function App レベルで集計され、関数コードが実行されている期間のみカウントされます。Usage is aggregated at the function app level and counts only the time that function code is executed. 課金の単位は、次のとおりです。The following are units for billing:

  • ギガバイト/秒 (GB/秒) 単位でのリソース使用量Resource consumption in gigabyte-seconds (GB-s). メモリ サイズと、関数アプリ内の全関数の実行時間の組み合わせとして計算されます。Computed as a combination of memory size and execution time for all functions within a function app.
  • 実行回数Executions. イベント トリガーに応じて関数が実行されるたびにカウントされます。Counted each time a function is executed in response to an event trigger.

従量課金の請求を理解する方法についての便利なクエリと情報については、請求に関する FAQ をご覧ください。Useful queries and information on how to understand your consumption bill can be found on the billing FAQ.

ホスティング プランの比較Hosting plans comparison

次の比較表は、Azure Functions アプリ ホスティングプランを選ぶ上で役立つすべての重要な側面を示しています。The following comparison table shows all important aspects to help the decision of Azure Functions App hosting plan choice:

プラン概要Plan summary

従量課金プランConsumption plan 自動的にスケールし、関数が実行されている際のコンピューティング リソースに対してのみ課金されます。Scale automatically and only pay for compute resources when your functions are running. 従量課金プランでは、Functions ホストのインスタンスは、受信イベントの数に基づいて動的に追加および削除されます。On the Consumption plan, instances of the Functions host are dynamically added and removed based on the number of incoming events.
✔ 既定のホスティング プランです。✔ Default hosting plan.
✔ 関数の実行中にのみ課金されます。✔ Pay only when your functions are running.
✔ 負荷が高い期間中であっても、自動的にスケールアウトされます。✔ scale-out automatically, even during periods of high load.
Premium プランPremium plan 需要に応じて自動的にスケーリングを行いながら、事前ウォーミングされたワーカーを使用して、アイドル状態になっても遅延なくアプリケーションを実行したり、より強力なインスタンスで実行したり、VNET に接続したりすることができます。While automatically scaling based on demand, use pre-warmed workers to run applications with no delay after being idle, run on more powerful instances, and connect to VNETs. 次の状況では、App Service プランのすべての機能に加えて、Azure Functions Premium プランを検討してください。Consider the Azure Functions Premium plan in the following situations, in addition to all features of the App Service plan:
✔ 関数を継続的に、またはほぼ継続的に実行したい。✔ Your function apps run continuously, or nearly continuously.
✔ 小規模な実行の回数が多く、実行料金が高いが、従量課金プランでの GB 秒の請求額は低い。✔ You have a high number of small executions and have a high execution bill but low GB second bill in the Consumption plan.
✔ 従量課金プランで提供されるよりも多くの CPU またはメモリのオプションが必要である。✔ You need more CPU or memory options than what is provided by the Consumption plan.
✔ 従量課金プランで許可されている最大実行時間よりも長くコードを実行する必要がある。✔ Your code needs to run longer than the maximum execution time allowed on the Consumption plan.
✔ 仮想ネットワーク接続など、Premium プランでのみ利用できる機能が必要である。✔ You require features that are only available on a Premium plan, such as virtual network connectivity.
専用プラン 1Dedicated plan1 App Service プラン内で、関数を通常の App Service プラン料金で実行します。Run your functions within an App Service plan at regular App Service plan rates. 長期の操作や、より予測的なスケーリングやコストが必要な場合に適しています。Good fit for long running operations, as well as when more predictive scaling and costs are required. 次のような状況では、App Service プランを検討してください。Consider an App Service plan in the following situations:
✔ 既に他の App Service インスタンスを実行している、使用率の低い既存の VM がある。✔ You have existing, underutilized VMs that are already running other App Service instances.
✔ 関数を実行するカスタム イメージを提供したい。✔ You want to provide a custom image on which to run your functions.
ASE 1ASE1 App Service Environment (ASE) は、App Service アプリを大規模かつ安全に実行するために完全に分離された専用の環境を提供する、Azure App Service の機能です。App Service Environment (ASE) is an App Service feature that provides a fully isolated and dedicated environment for securely running App Service apps at high scale. ASE は、以下を必要とするアプリケーション ワークロードに最適です。ASEs are appropriate for application workloads that require:
✔ 高スケール。✔ Very high scale.
✔ コンピューティングの完全分離とセキュリティで保護されたネットワーク アクセス。✔ Full compute isolation and secure network access.
✔ 高いメモリ使用率。✔ High memory utilization.
KubernetesKubernetes Kubernetes は、Kubernetes プラットフォーム上で実行される完全に分離された専用の環境を提供します。Kubernetes provides a fully isolated and dedicated environment running on top of the Kubernetes platform. Kubernetes は、以下を必要とするアプリケーション ワークロードに最適です。Kubernetes is appropriate for application workloads that require:
✔ ハードウェア要件のカスタマイズ。✔ Custom hardware requirements.
✔ 分離およびセキュリティで保護されたネットワーク アクセス。✔ Isolation and secure network access.
✔ ハイブリッド環境またはマルチクラウド環境で実行可能。✔ Ability to run in hybrid or multi-cloud environment.
✔ 既存の Kubernetes アプリケーションやサービスと並行して実行。✔ Run alongside existing Kubernetes applications and services.

1 各種 App Service プラン オプションに固有の制限については、App Service プランの制限に関する記事を参照してください。1 For specific limits for the various App Service plan options, see the App Service plan limits.

オペレーティング システム/ランタイムOperating system/runtime

Linux1Linux1
コードのみCode-only
Windows2Windows2
コードのみCode-only
Linux1、3Linux1,3
Docker コンテナーDocker container
従量課金プランConsumption plan .NET Core.NET Core
Node.jsNode.js
JavaJava
PythonPython
.NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
サポートなしNo support
Premium プランPremium plan .NET Core.NET Core
Node.jsNode.js
JavaJava
PythonPython
.NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
.NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
PythonPython
専用プラン 4Dedicated plan4 .NET Core.NET Core
Node.jsNode.js
JavaJava
PythonPython
.NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
.NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
PythonPython
ASE 4ASE4 .NET Core.NET Core
Node.jsNode.js
JavaJava
PythonPython
.NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
.NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
PythonPython
KubernetesKubernetes 該当なしn/a 該当なしn/a .NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
PythonPython

1Linux は、Python ランタイム スタックでサポートされている唯一のオペレーティング システムです。1Linux is the only supported operating system for the Python runtime stack.
2Windows は、PowerShell ランタイム スタックでサポートされている唯一のオペレーティング システムです。2Windows is the only supported operating system for the PowerShell runtime stack.
3Linux は、Docker コンテナーでサポートされている唯一のオペレーティング システムです。3Linux is the only supported operating system for Docker containers. 4 各種 App Service プラン オプションに固有の制限については、App Service プランの制限に関する記事を参照してください。4 For specific limits for the various App Service plan options, see the App Service plan limits.

スケールScale

スケール アウトScale out 最大インスタンス数Max # instances
従量課金プランConsumption plan イベント ドリブン。Event driven. 負荷が高い期間中であっても、自動的にスケールアウトされます。Scale out automatically, even during periods of high load. Azure Functions インフラストラクチャでは、関数がトリガーされるイベントの数に基づいて Functions ホストのインスタンスを追加することで、CPU とメモリのリソースがスケーリングされます。Azure Functions infrastructure scales CPU and memory resources by adding additional instances of the Functions host, based on the number of events that its functions are triggered on. 200200
Premium プランPremium plan イベント ドリブン。Event driven. 負荷が高い期間中であっても、自動的にスケールアウトされます。Scale out automatically, even during periods of high load. Azure Functions インフラストラクチャでは、関数がトリガーされるイベントの数に基づいて Functions ホストのインスタンスを追加することで、CPU とメモリのリソースがスケーリングされます。Azure Functions infrastructure scales CPU and memory resources by adding additional instances of the Functions host, based on the number of events that its functions are triggered on. 100100
専用プラン 1Dedicated plan1 手動/自動スケールManual/autoscale 10 - 2010-20
ASE 1ASE1 手動/自動スケールManual/autoscale 100100
KubernetesKubernetes KEDA を使用した Kubernetes クラスターのイベント ドリブン自動スケーリング。Event-driven autoscale for Kubernetes clusters using KEDA.  クラスター によって 異なります。 Varies by cluster.  

1 各種 App Service プラン オプションに固有の制限については、App Service プランの制限に関する記事を参照してください。1 For specific limits for the various App Service plan options, see the App Service plan limits.

コールド スタートの動作Cold start behavior

従量課金 プランConsumption plan アプリが一定期間アイドル状態になった場合、0 にスケーリングされます。つまり、一部の要求の起動時に追加の待機時間が発生する可能性があります。Apps may scale to zero if idle for a period of time, meaning some requests may have additional latency at startup. 従量課金プランには、コールド スタート時間を短縮するためのいくつかの最適化があります。これには、既に関数ホストと言語プロセスが実行されている、事前ウォーミングされたプレースホルダー関数からのプルが含まれます。The consumption plan does have some optimizations to help decrease cold start time, including pulling from pre-warmed placeholder functions that already have the function host and language processes running.
Premium プランPremium plan コールド スタートを回避するためにインスタンスを常にウォーム状態に維持します。Perpetually warm instances to avoid any cold start.
専用プラン 1Dedicated plan1 専用プランで実行していると、Functions ホストを継続的に実行できます。つまり、コールド スタートは問題にならないということです。When running in a Dedicated plan, the Functions host can run continuously, which means that cold start isn’t really an issue.
ASE 1ASE1 専用プランで実行していると、Functions ホストを継続的に実行できます。つまり、コールド スタートは問題にならないということです。When running in a Dedicated plan, the Functions host can run continuously, which means that cold start isn’t really an issue.
KubernetesKubernetes KEDA の構成に依存します。Depends on KEDA configuration. アプリは、常に実行可能でコールド スタートにならないよう設定したり、新しいイベントの際にコールド スタートになる 0 にスケーリングされるよう設定することもできます。Apps can be configured to always run and never have cold start, or configured to scale to zero, which results in cold start on new events.

1 各種 App Service プラン オプションに固有の制限については、App Service プランの制限に関する記事を参照してください。1 For specific limits for the various App Service plan options, see the App Service plan limits.

サービスの制限Service limits

リソースResource 従量課金プランConsumption plan Premium プランPremium plan 専用プランDedicated plan ASEASE KubernetesKubernetes
既定のタイムアウトまでの時間 (分)Default timeout duration (min) 55 3030 301301 3030 3030
最大のタイムアウトまでの時間 (分)Max timeout duration (min) 1010 無制限7unbounded7 無制限2unbounded2 unboundedunbounded unboundedunbounded
最大送信接続数 (インスタンスあたり)Max outbound connections (per instance) アクティブ 600 (合計 1200)600 active (1200 total) unboundedunbounded unboundedunbounded unboundedunbounded unboundedunbounded
最大要求サイズ (MB)3Max request size (MB)3 100100 100100 100100 100100 クラスターに応じるDepends on cluster
クエリ文字列の最大長3Max query string length3 40964096 40964096 40964096 40964096 クラスターに応じるDepends on cluster
要求 URL の最大長3Max request URL length3 81928192 81928192 81928192 81928192 クラスターに応じるDepends on cluster
インスタンスあたりの ACUACU per instance 100100 210 ~ 840210-840 100 ~ 840100-840 210 から 2508210-2508 AKS の価格AKS pricing
最大メモリ (インスタンスあたりの GB)Max memory (GB per instance) 1.51.5 3.5 ~ 143.5-14 1.75 ~ 141.75-14 3.5 から 143.5 - 14 すべてのノードがサポートされていますAny node is supported
プランあたりの関数アプリFunction apps per plan 100100 100100 無制限4unbounded4 unboundedunbounded unboundedunbounded
App Service プランApp Service plans リージョンあたり 100100 per region リソース グループあたり 100100 per resource group リソース グループあたり 100100 per resource group - -
ストレージ5Storage5 5 TB5 TB 250 GB250 GB 50 ~ 1000 GB50-1000 GB 1 TB (テラバイト)1 TB 該当なしn/a
アプリケーションごとのカスタム ドメイン数Custom domains per app 50065006 500500 500500 500500 該当なしn/a
カスタム ドメインの SSL サポートCustom domain SSL support 無制限の SNI SSL 接続が含まれるunbounded SNI SSL connection included 無制限の SNI SSL 接続と 1 件の IP SSL 接続が含まれるunbounded SNI SSL and 1 IP SSL connections included 無制限の SNI SSL 接続と 1 件の IP SSL 接続が含まれるunbounded SNI SSL and 1 IP SSL connections included 無制限の SNI SSL 接続と 1 件の IP SSL 接続が含まれるunbounded SNI SSL and 1 IP SSL connections included 該当なしn/a

1 既定では、App Service プランでの Functions 1.x ランタイムのタイムアウトは無制限です。1 By default, the timeout for the Functions 1.x runtime in an App Service plan is unbounded.
2 App Service プランが Always On に設定されている必要があります。2 Requires the App Service plan be set to Always On. 標準料金でのお支払い。Pay at standard rates.
3 これらの制限はホストで設定されます。3 These limits are set in the host.
4 実際にホストできる関数アプリの数は、アプリのアクティビティ、マシン インスタンスのサイズ、対応するリソース使用量によって異なります。4 The actual number of function apps that you can host depends on the activity of the apps, the size of the machine instances, and the corresponding resource utilization.
5 ストレージの上限は、同じ App Service プランのすべてのアプリにまたがる一時ストレージ内の合計コンテンツ サイズです。5 The storage limit is the total content size in temporary storage across all apps in the same App Service plan. 従量課金プランでは、Azure Files を一時ストレージに使用します。Consumption plan uses Azure Files for temporary storage.
6 関数アプリが従量課金プランでホストされている場合、CNAME オプションのみがサポートされます。6 When your function app is hosted in a Consumption plan, only the CNAME option is supported. Premium プランまたは App Service プランの関数アプリでは、CNAME または A レコードを使用してカスタム ドメインをマップできます。For function apps in a Premium plan or an App Service plan, you can map a custom domain using either a CNAME or an A record.
7 60 分まで保証されます。7 Guaranteed for up to 60 minutes.
8 ワーカーは、お客様のアプリをホストする役割です。8 Workers are roles that host customer apps. ワーカーは、3 つの固定サイズで使用できます。1 vCPU/3.5 GB RAM。2 vCPU/7 GB RAM。4 vCPU/14 GB RAM。Workers are available in three fixed sizes: One vCPU/3.5 GB RAM; Two vCPU/7 GB RAM; Four vCPU/14 GB RAM.

ネットワーク機能Networking features

特徴量Feature 従量課金プランConsumption plan Premium プランPremium plan 専用プランDedicated plan ASEASE KubernetesKubernetes
受信 IP の制限とプライベート サイト アクセスInbound IP restrictions and private site access ✅はい✅Yes ✅はい✅Yes ✅はい✅Yes ✅はい✅Yes ✅はい✅Yes
仮想ネットワークの統合Virtual network integration ❌いいえ❌No ✅はい (リージョン)✅Yes (Regional) ✅はい (リージョンとゲートウェイ)✅Yes (Regional and Gateway) ✅はい✅Yes ✅はい✅Yes
仮想ネットワーク トリガー (非 HTTP)Virtual network triggers (non-HTTP) ❌いいえ❌No ✅はい✅Yes ✅はい✅Yes ✅はい✅Yes ✅はい✅Yes
ハイブリッド接続 (Windows のみ)Hybrid connections (Windows only) ❌いいえ❌No ✅はい✅Yes ✅はい✅Yes ✅はい✅Yes ✅はい✅Yes
送信 IP の制限Outbound IP restrictions ❌いいえ❌No ✅はい✅Yes ✅はい✅Yes ✅はい✅Yes ✅はい✅Yes

課金Billing

従量課金プランConsumption plan 関数が実行された時間に対してだけ支払います。Pay only for the time your functions run. 課金は、実行数、実行時間、およびメモリの使用量に基づいて行われ、Billing is based on number of executions, execution time, and memory used.
Premium プランPremium plan Premium プランは、必要なインスタンスや事前ウォーミングされたインスタンスで使用されたコア秒数とメモリに基づいています。Premium plan is based on the number of core seconds and memory used across needed and pre-warmed instances. プランごとに少なくとも 1 つのインスタンスが常にウォーム状態である必要があります。At least one instance per plan must be kept warm at all times. このプランでは、より予測可能な価格が提供されます。This plan provides more predictable pricing.
専用プラン 1Dedicated plan1 App Service プランの関数アプリに対する支払いは、Web アプリなどの他の App Service リソースの場合と同じです。You pay the same for function apps in an App Service Plan as you would for other App Service resources, like web apps.
ASE 1ASE1 インフラストラクチャの支払いを行うための ASE には一定の月額料金があり、ASE のサイズが変化しても料金は変わりません。there's a flat monthly rate for an ASE that pays for the infrastructure and doesn't change with the size of the ASE. それに加えて、App Service プランの vCPU あたりのコストがあります。In addition, there's a cost per App Service plan vCPU. ASE でホストされているすべてのアプリは、分離された価格 SKU に含まれます。All apps hosted in an ASE are in the Isolated pricing SKU.
KubernetesKubernetes お支払いは Kubernetes クラスターのコストだけです。関数に対する追加の課金はありません。You pay only the costs of your Kubernetes cluster; no additional billing for Functions. 関数アプリは、通常のアプリと同じように、クラスターのアプリケーションのワークロードとして実行されます。Your function app runs as an application workload on top of your cluster, just like a regular app.

1 各種 App Service プラン オプションに固有の制限については、App Service プランの制限に関する記事を参照してください。1 For specific limits for the various App Service plan options, see the App Service plan limits.

次のステップNext steps