Merge pull request #289814 from ecfan/hybrid

[Hybrid] Updates from blog

Author: prmerger-automator[bot]

articles/logic-apps/create-standard-workflows-hybrid-deployment.md

@@ -31,13 +31,12 @@ This how-to guide shows how to create and deploy a Standard logic app workflow u
 
 - The following capabilities currently aren't available in this preview release:
 
-  - The action named **Call local function in this logic app** for running C# .NET Framework code
+  - Managed identity authentication
   - SAP access through the SAP built-in connector
+  - C# custom code with .NET Framework and the built-in action named **Call local function in this logic app**
   - XSLT 1.0 for custom code
-  - Custom code support with .NET Framework
-  - Managed identity authentication
 
-- Azure Arc-enabled Kubernetes clusters currently don't support managed identity authentication for managed API connections. Instead, you must create your own app registration using Microsoft Entra ID. For more information, [follow these steps later in this guide](#authenticate-managed-api-connections).
+  Azure Arc-enabled Kubernetes clusters currently don't support managed identity authentication for managed API connections. Instead, you must create your own app registration using Microsoft Entra ID. For more information, [follow these steps later in this guide](#authenticate-managed-api-connections).
 
 - Some function-based triggers, such as Azure Blob, Cosmos DB, and Event Hubs require a connection to the Azure storage account associated with your Standard logic app. If you use any function-based triggers, in your Standard logic app's environment variables in the Azure portal or in your logic app project's **local.settings.json** file in Visual Studio Code, add the following app setting and provide your storage account connection string:
 

articles/logic-apps/logic-apps-pricing.md

@@ -82,6 +82,10 @@ In single-tenant Azure Logic Apps, a logic app and its workflows follow the [**S
 When you create or deploy logic apps with the **Logic App (Standard)** resource type, and you select any Azure region for deployment, you'll also select a Workflow Standard hosting plan. However, if you select an existing **App Service Environment v3** resource for your deployment location, you must then select an [App Service Plan](../app-service/overview-hosting-plans.md).
 
 > [!IMPORTANT]
+>
+> The **Hybrid** hosting option is currently in preview. For information, see 
+> [Set up your own infrastructure for Standard logic apps using hybrid deployment](set-up-standard-workflows-hybrid-deployment-requirements.md#how-billing-works).
+>
 > The following plans and resources are no longer available or supported with the public release of Standard 
 > logic app workflows in single-tenant Azure Logic Apps: Functions Premium plan, App Service Environment v1, 
 > and App Service Environment v2. The App Service Plan is available and supported only with App Service Environment v3 (ASE v3).
@@ -160,8 +164,8 @@ The following table summarizes how the Consumption and Standard models handle op
 
 | Operation | Description | Consumption | Standard |
 |-----------|-------------|-------------|----------|
-| [Loop actions](logic-apps-control-flow-loops.md) | A loop action, such as the **For each** or **Until** loop, can include other actions that run during each loop cycle. | Except for the initial number of included built-in operations, the loop action and each action in the loop are metered each time the loop cycle runs. If an action processes any items in a collection, such as a list or array, the number of items is also used in the metering calculation. <p><p>For example, suppose you have a **For each** loop with actions that process a list. The service multiplies the number of list items against the number of actions in the loop, and adds the action that starts the loop. So, the calculation for a 10-item list is (10 * 1) + 1, which results in 11 action executions. <p><p>Pricing is based on whether the operation types are built-in, Standard, or Enterprise. | Except for the included built-in operations, same as the Consumption model. |
-| [Retry policies](logic-apps-exception-handling.md#retry-policies) | On supported operations, you can implement basic exception and error handling by setting up a [retry policy](logic-apps-exception-handling.md#retry-policies). | Except for the initial number of built-in operations, the original execution plus each retried execution are metered. For example, an action that executes with 5 retries is metered and billed as 6 executions. <p><p>Pricing is based on whether the operation types are built-in, Standard, or Enterprise. | Except for the built-in included operations, same as the Consumption model. |
+| [Loop actions](logic-apps-control-flow-loops.md) | A loop action, such as the **For each** or **Until** loop, can include other actions that run during each loop cycle. | Except for the initial number of included built-in operations, the loop action and each action in the loop are metered each time the loop cycle runs. If an action processes any items in a collection, such as a list or array, the number of items is also used in the metering calculation. <p><p>For example, suppose you have a **For each** loop with actions that process a list. The service multiplies the number of list items against the number of actions in the loop, and adds the action that starts the loop. So, the calculation for a 10-item list is (10 * 1) + 1, which results in 11 action executions. <p><p>Pricing is based on whether the operation types are built in, Standard, or Enterprise. | Except for the included built-in operations, same as the Consumption model. |
+| [Retry policies](logic-apps-exception-handling.md#retry-policies) | On supported operations, you can implement basic exception and error handling by setting up a [retry policy](logic-apps-exception-handling.md#retry-policies). | Except for the initial number of built-in operations, the original execution plus each retried execution are metered. For example, an action that executes with 5 retries is metered and billed as 6 executions. <p><p>Pricing is based on whether the operation types are built in, Standard, or Enterprise. | Except for the built-in included operations, same as the Consumption model. |
 
 <a name="storage-operations"></a>
 

articles/logic-apps/set-up-standard-workflows-hybrid-deployment-requirements.md

@@ -6,7 +6,7 @@ ms.service: azure-logic-apps
 ms.suite: integration
 ms.reviewer: estfan, azla
 ms.topic: how-to
-ms.date: 10/14/2024
+ms.date: 11/04/2024
 # Customer intent: As a developer, I need to set up the requirements to host and run Standard logic app workflows on infrastructure that my organization owns, which can include on-premises systems, private clouds, and public clouds.
 ---
 
@@ -19,9 +19,13 @@ ms.date: 10/14/2024
 > This capability is in preview, incurs charges for usage, and is subject to the
 > [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
 
-Azure Logic Apps supports scenarios where you need to use and manage your own infrastructure to deploy and host Standard logic app workflows by offering a hybrid hosting option. This hybrid deployment model provides the capabilities for hosting integration solutions in partially connected environments that require local processing, storage, and network access. Standard logic app workflows are powered by the Azure Logic Apps runtime that is hosted on premises as an Azure Container Apps extension.
+Sometimes you have to set up and manage your own infrastructure to meet specific needs for regulatory compliance, data privacy, or network restrictions. Azure Logic Apps offers a *hybrid deployment model* so that you can deploy and host Standard logic app workflows in on-premises, private cloud, or public cloud scenarios. This model gives you the capabilities to host integration solutions in partially connected environments when you need to use local processing, data storage, and network access. With the hybrid option, you have the freedom and flexibility to choose the best environment for your workflows.
 
-The following architectural overview shows where Standard logic app workflows are hosted and run in the hybrid model. The partially connected environment includes the following resources for hosting and working with your Standard logic apps, which deploy as Azure Container Apps resources:
+## How hybrid deployment works
+
+Standard logic app workflows with the hybrid deployment option are powered by an Azure Logic Apps runtime that is hosted in an Azure Container Apps extension. In your workflow, any [built-in operations](../connectors/built-in.md) run locally with the runtime so that you get higher throughput for access to local data sources. If you need access to non-local data resources, for example, cloud-based services such as Microsoft Office 365, Microsoft Teams, Salesforce, GitHub, LinkedIn, or ServiceNow, you can choose operations from [1,000+ connectors hosted in Azure](/connectors/connector-reference/connector-reference-logicapps-connectors) to include in your workflows. For more information, see [Managed (shared) connectors](../connectors/managed.md). Although you need to have internet connectivity to manage your logic app in the Azure portal, the semi-connected nature of this platform lets you absorb any temporary internet connectivity issues.
+
+For example, if you have an on-premises scenario, the following architectural overview shows where Standard logic app workflows are hosted and run in the hybrid model. The partially connected environment includes the following resources for hosting and working with your Standard logic apps, which deploy as Azure Container Apps resources:
 
 - Azure Arc-enabled Azure Kubernetes Service (AKS) clusters
 - A SQL database to locally store workflow run history, inputs, and outputs for processing
@@ -41,6 +45,16 @@ For more information, see the following documentation:
 
 This how-to guide shows how to set up the necessary on-premises resources in your infrastructure so that you can create, deploy, and host a Standard logic app workflow using the hybrid deployment model.
 
+## How billing works
+
+With the hybrid option, you're responsible for the following items:
+
+- Your Azure Arc-enabled Kubernetes infrastructure
+- Your SQL Server license
+- A billing charge of $0.18 USD per vCPU/hour to support Standard logic app workloads
+
+In this billing model, you pay only for what you need and scale resources for dynamic workloads without having to buy for peak usage. For workflows that use Azure-hosted connector operations, such as Microsoft Teams or Microsoft Office 365, [existing Standard (single-tenant) pricing](https://azure.microsoft.com/pricing/details/logic-apps/#pricing) applies to these operation executions.
+
 ## Limitations
 
 - Hybrid deployment is currently available and supported only for the following Azure Arc-enabled Kubernetes clusters:
@@ -68,9 +82,9 @@ Your Kubernetes cluster requires inbound and outbound connectivity with the [SQL
 > [!NOTE]
 >
 > You can also create a [Kubernetes cluster on Azure Stack HCI infrastructure](/azure-stack/hci/overview) 
-> or [Kubernetes cluster on Windows Server](/azure/aks/hybrid/overview) and apply the steps in this how-to guide 
-> to connect your cluster to Azure Arc and set up your connected environment. For more information 
-> about Azure Stack HCI and AKS on Windows Server, see the following resources:
+> or [Kubernetes cluster on Windows Server](/azure/aks/hybrid/overview) and apply the steps in this guide 
+> to connect your cluster to Azure Arc and set up your connected environment. For more information about 
+> Azure Stack HCI and AKS on Windows Server, see the following resources:
 >
 > - [About Azure Stack HCI](/azure-stack/hci/deploy/deployment-introduction)
 > - [Deployment prerequisites for Azure Stack HCI](/azure-stack/hci/deploy/deployment-prerequisites)