Merge pull request #289898 from ggailey777/flex-ga-ignite

[Functions][Flex] Final GA updates for Ignite sign-off

Author: prmerger-automator[bot]

articles/azure-functions/flex-consumption-plan.md

@@ -95,9 +95,7 @@ Deployments in the Flex Consumption plan follow a single path. After your projec
 
 The minimum billable execution period for both execution modes is 1,000 ms. Past that, the billable activity period is rounded up to the nearest 100 ms. You can find details on the Flex Consumption plan billing meters in the [Monitoring reference](monitor-functions-reference.md?tab=flex-consumption-plan#metrics).
 
-For details about how costs are calculated when you run in a Flex Consumption plan, including examples, see [Consumption-based costs](functions-consumption-costs.md?tabs=flex-consumtion-plan#consumption-based-costs). 
-
-For the most up-to-date information on execution pricing, always ready baseline costs, and free grants for on demand executions, see the [Azure Functions pricing page](https://azure.microsoft.com/pricing/details/functions/).  
+For details about how costs are calculated when you run in a Flex Consumption plan, including examples, see [Consumption-based costs](functions-consumption-costs.md?tabs=flex-consumtion-plan#consumption-based-costs).   
 
 ## Supported language stack versions
 

articles/azure-functions/functions-consumption-costs.md

@@ -1,7 +1,7 @@
 ---
 title: Estimating consumption-based costs in Azure Functions
 description: Learn how to better estimate the costs that you might incur when running your function app in either the Consumption plan or the Flex Consumption plan in Azure Functions.
-ms.date: 5/05/2024
+ms.date: 11/05/2024
 ms.topic: conceptual
 ms.custom:
   - build-2024
@@ -54,26 +54,16 @@ This diagram represents how on-demand costs are determined in this plan:
 
 In addition to execution time, when using one or more always ready instances, you're also billed at a lower, baseline rate for the number of always ready instances you maintain. Execution time for always ready instances might be cheaper than execution time on instances with on demand execution.   
 
->[!IMPORTANT]
->In this article, prices are only provided to help understand example calculations. Always check the [Azure Functions pricing page](https://azure.microsoft.com/pricing/details/functions/) when estimating costs you might incur while running your functions in the Flex Consumtion plan. 
-
-For the examples in this section, consider the discounted preview pricing in this table for pay-as-you-go in East US.
-
-| Mode        | Meter             | Free monthly grants        | Consumption rates        |
-| ------------| ----------------- | -------------------------- | ------------------------ | 
-| On-demand | Execution time (GB-s)   | `100,000`              | `$0.000016` per GB-s         |
-| On-demand | Executions (count)  | `250,000` | `$0.20` per million executions              |
-| Always ready | Baseline (idle) time (GB-s)  | \-         | `$0.000004` per GB-s               |
-| Always ready | Execution time (GB-s)        | \-         | `$0.000009` per GB-s               |
-| Always ready | Executions (count)           | \-         | `$0.20` per million executions |
+> [!IMPORTANT]
+> In this article, on-demand pricing is used to help understand example calculations. Always check the current costs in the [Azure Functions pricing page](https://azure.microsoft.com/pricing/details/functions/) when estimating costs you might incur while running your functions in the Flex Consumption plan. 
 
 Consider a function app that is comprised only of HTTP triggers with and these basic facts:
 
 + HTTP triggers handle 40 constant requests per second.
 + HTTP triggers handle 10 concurrent requests.
 + The instance memory size setting is `2048 MB`. 
 + There are _no always ready instances configured_, which means the app can scale to zero.
-
+<!--- Update these example calculations after 12/1 based on GA pricing -->
 In a situation like this, the pricing depends more on the kind of work being done during code execution. Let's look at two workload scenarios:
 
 + **CPU-bound workload:** In a CPU-bound workload, there's no advantage to processing multiple requests in parallel in the same instance. This means that you're better off distributing each request to its own instance so requests complete as a quickly as possible without contention. In this scenario, you should set a low [HTTP trigger concurrency](./functions-concurrency.md#http-trigger-concurrency) of `1`. With 10 concurrent requests, the app scales to a steady state of roughly 10 instances, and each instance is continuously active processing one request at a time. 
@@ -88,7 +78,7 @@ In a situation like this, the pricing depends more on the kind of work being don
 
     Because consumption charges are based only on the memory of each active instance, the consumption charge calculation is simply `2 GB * 3600 s = 7200 GB-s`, which at the assumed on-demand execution rate (without any free grants applied) is `$0.1152 USD` per hour for the single instance.
 
-    As in the CPU-bound scenario, the on-demand per-execution charge (without any free grants) of 40 requests per second is equal to `40 * 3600 = 144,000` or 0.144 million executions per hour. This makes the total (grant-free) hourly cost of executions `0.144 * $0.20`, which is `$0.0288` per hour.
+    As in the CPU-bound scenario, the on-demand per-execution charge (without any free grants) of 40 requests per second is equal to `40 * 3600 = 144,000` or 0.144 million executions per hour. In this case, the total (grant-free) hourly cost of executions `0.144 * $0.20`, which is `$0.0288` per hour.
 
     In this scenario, the total hourly cost of running on-demand on a single instance is `$0.1152 + $0.0288 = $0.144 USD`. 
 
@@ -114,15 +104,15 @@ The following behaviors of your functions can affect the execution time:
 
 + **Triggers and bindings**: The time taken to read input from and write output to your [function bindings](functions-triggers-bindings.md) is counted as execution time. For example, when your function uses an output binding to write a message to an Azure storage queue, your execution time includes the time taken to write the message to the queue, which is included in the calculation of the function cost. 
 
-+ **Asynchronous execution**: The time that your function waits for the results of an async request (`await` in C#) is counted as execution time. The GB-second calculation is based on the start and end time of the function and the memory usage over that period. What is happening over that time in terms of CPU activity isn't factored into the calculation. You may be able to reduce costs during asynchronous operations by using [Durable Functions](durable/durable-functions-overview.md). You're not billed for time spent at awaits in orchestrator functions.
++ **Asynchronous execution**: The time that your function waits for the results of an async request (`await` in C#) is counted as execution time. The GB-second calculation is based on the start and end time of the function and the memory usage over that period. What is happening over that time in terms of CPU activity isn't factored into the calculation. You might be able to reduce costs during asynchronous operations by using [Durable Functions](durable/durable-functions-overview.md). You're not billed for time spent at awaits in orchestrator functions.
 
 ## Viewing cost-related data
 
 In [your invoice](../cost-management-billing/understand/download-azure-invoice.md), you can view the cost-related data of **Total Executions - Functions** and **Execution Time - Functions**, along with the actual billed costs. However, this invoice data is a monthly aggregate for a past invoice period. 
 
 ### Function app-level metrics
 
-To better understand the cost impact of your functions, you can use Azure Monitor to view cost-related metrics currently being generated by your function apps. 
+To better understand the costs of your functions, you can use Azure Monitor to view cost-related metrics currently being generated by your function apps. 
 
 [!INCLUDE [functions-monitor-metrics-consumption](../../includes/functions-monitor-metrics-consumption.md)]
 

articles/azure-functions/functions-event-grid-blob-trigger.md

@@ -18,7 +18,7 @@ This article shows how to create a function that runs based on events raised whe
 > * Create an event-based Blob Storage triggered function in a new project.
 > * Validate locally within Visual Studio Code using the Azurite emulator.
 > * Create a blob storage container in a new storage account in Azure.
-> * Create a function app in the Flex Consumption plan (preview).
+> * Create a function app in the Flex Consumption plan.
 > * Create an event subscription to the new blob container.
 > * Deploy and validate your function code in Azure.
 

articles/azure-functions/functions-reference-python.md

@@ -46,7 +46,7 @@ As a Python developer, you might also be interested in these topics:
 
 ## [Hosting options](#tab/hosting)
 
-+ [Flex Consumption plan](./flex-consumption-plan.md): Linux-based serverless hosting option that features full support for managed identities, virtual networks, and flexible deployments. This plan is currently in preview.
++ [Flex Consumption plan](./flex-consumption-plan.md): Linux-based serverless hosting option that features full support for managed identities, virtual networks, and flexible deployments. 
 + [Container hosting options](container-concepts.md): Run and deploy your Python functions on Linux in a Docker container, including integrated [Azure Container Apps hosting](functions-container-apps-hosting.md).
 + [Compare hosting options...](functions-scale.md) 
 

includes/functions-flex-consumption-billing-table.md

@@ -4,7 +4,7 @@ ms.service: azure-functions
 ms.custom:
   - build-2024
 ms.topic: include
-ms.date: 05/13/2024
+ms.date: 11/05/2024
 ms.author: glenga
 ---
 There are two modes by which your costs are determined when running your apps in the Flex Consumption plan. Each mode is determined on a per-instance basis.
@@ -13,3 +13,5 @@ There are two modes by which your costs are determined when running your apps in
 | ---- | ---- |
 | **On Demand** | When running in _on demand_ mode, you are billed only for the amount of time your function code is executing on your available instances. In on demand mode, no minimum instance count is required. You're billed for:<br/><br/>• The total amount of memory provisioned while each on demand instance is _actively_ executing functions (in GB-seconds), minus a free grant of GB-s per month.<br/>• The total number of executions, minus a free grant (number) of executions per month. |
 | **Always ready** | You can configure one or more instances, assigned to specific trigger types (HTTP/Durable/Blob) and individual functions, that are always available to be able handle requests. When you have any always ready instances enabled, you're billed for:<br/><br/>• The total amount of memory provisioned across all of your always ready instances, known as the _baseline_ (in GB-seconds).<br/>• The total amount of memory provisioned during the time each always ready instance is _actively_ executing functions (in GB-seconds).<br/>• The total number of executions.<br/><br/>In always ready billing, there are no free grants. |
+
+For the most up-to-date information on execution pricing, always ready baseline costs, and free grants for on demand executions, see the [Azure Functions pricing page](https://azure.microsoft.com/pricing/details/functions/#pricing).