Compartir por

Medición, facturación y precios de uso de Azure Logic Apps

  • Artigo

Se aplica a: Azure Logic Apps (consumo + estándar)

Azure Logic Apps ayuda a crear y ejecutar flujos de trabajo de integración automatizados en la nube. En este artículo se describe cómo funcionan los modelos de medición, facturación y precios de Azure Logic Apps y los recursos relacionados. Si necesita información sobre precios específicos, planeamiento de costos o diferentes entornos de hospedaje, por ejemplo, revise el siguiente contenido:

Consumo (multiinquilino)

En Azure Logic Apps multiinquilino, una aplicación lógica y su flujo de trabajo siguen el plan de Consumo para establecer precios y facturar. Estas aplicaciones lógicas se crean de varias maneras, por ejemplo, al elegir el tipo de recurso Logic App (Consumption) (Aplicación lógica [consumo]), cuando se usa la extensión Azure Logic Apps (Consumption) (Azure Logic Apps [consumo]) en Visual Studio Code o cuando se crean tareas de automatización.

En la tabla siguiente se resume cómo el modelo de Consumo controla la medición y la facturación de los siguientes componentes cuando se usa con una aplicación lógica y un flujo de trabajo en Azure Logic Apps multiinquilino:

Componente Medición y facturación
Operaciones de desencadenador y acción El modelo de consumo incluye un número inicial de operaciones integradas gratuitas, por suscripción de Azure, que puede ejecutar un flujo de trabajo. Por encima de este número, la medición se aplica a cada ejecución y la facturación sigue los precios de Acciones del plan de consumo. En el caso de otros tipos de operaciones, como los conectores administrados, la facturación sigue los precios del conector estándar o empresarial del plan de consumo. Para más información, consulte Operaciones de desencadenador y acción en el modelo de consumo.
Operaciones de almacenamiento La medición se aplica solo al consumo de almacenamiento relacionado con la retención de datos, como el almacenamiento de entradas y salidas del historial de ejecución del flujo de trabajo. La facturación sigue los precios de retención de datos del plan de consumo. Para más información, consulte Operaciones de almacenamiento.
Cuentas de integración La medición se aplica en función del tipo de cuenta de integración que cree y use con la aplicación lógica. La facturación sigue los precios de la cuenta de integración. Para más información, consulte Cuentas de integración.

Operaciones de desencadenador y acción en el modelo de consumo

Excepto por el número inicial de ejecuciones de operaciones integradas gratuitas, por suscripción de Azure, que puede ejecutar un flujo de trabajo, el modelo de consumo mide y factura una operación en función de cada ejecución, con independencia de si el flujo de trabajo global se ejecuta correctamente, finaliza o incluso se crea una instancia de él. Normalmente, una operación realiza una única ejecución a menos que tenga habilitados los reintentos. A su vez, una ejecución normalmente realiza una sola llamada a menos que la operación admita y permita la fragmentación o paginación para obtener grandes cantidades de datos. Si está habilitada la fragmentación o paginación, es posible que una ejecución de la operación tenga que realizar varias llamadas.

El modelo de consumo mide y factura una operación por ejecución, no por llamada. Por ejemplo, suponga que un flujo de trabajo comienza con un desencadenador de sondeo que obtiene registros mediante la realización regular de llamadas salientes a un punto de conexión. La llamada saliente se mide y se factura como ejecución única, independientemente de si el desencadenador se activa o se omite, como cuando un desencadenador comprueba un punto de conexión pero no encuentra datos ni eventos. El estado del desencadenador controla si la instancia de flujo de trabajo se crea y ejecuta. Ahora, supongamos que la operación también admite, y tiene habilitada, la fragmentación o la paginación. Si la operación tiene que realizar 10 llamadas para terminar de obtener todos los datos, la operación todavía se mide y se factura como una sola ejecución, a pesar de realizar varias llamadas.

Nota:

De forma predeterminada, los desencadenadores que devuelven una matriz tienen una configuración Split On que ya está habilitada. Esta configuración da como resultado un evento de desencadenador, que puede revisar en el historial de desencadenadores, y una instancia de flujo de trabajo para cada elemento de matriz. Todas las instancias de flujo de trabajo se ejecutan en paralelo para que los elementos de matriz se procesen al mismo tiempo. La facturación se aplica a todos los eventos de desencadenador si el estado del desencadenador es Correcto u Omitido. Los desencadenadores siguen siendo facturables incluso en escenarios en los que no crean instancias ni inician el flujo de trabajo, pero su estaco es Correcto, Erróneo u Omitido.

En la tabla siguiente se resume cómo el modelo de Consumo controla la medición y la facturación de estos tipos de operación cuando se usa con una aplicación lógica y un flujo de trabajo en Azure Logic Apps multiinquilino:

Tipo de operación Descripción Medición y facturación
Integrada Estas operaciones se ejecutan de forma directa y nativa con el entorno de ejecución de Azure Logic Apps. En el diseñador, puede encontrar estas operaciones en la etiqueta Integrado.

Por ejemplo, el desencadenador HTTP y el desencadenador de solicitud son desencadenadores integrados. La acción HTTP y la acción de respuesta son acciones integradas. Otras operaciones integradas incluyen acciones de control de flujo de trabajo, como bucles y condiciones, operaciones de datos, operaciones por lotes, etc.

 El modelo de consumo incluye un número inicial de operaciones integradas gratuitas, por suscripción de Azure, que puede ejecutar un flujo de trabajo. Por encima de este número, las ejecuciones de operaciones integradas siguen los precios de Acciones.

Nota: Algunas operaciones de conectores administrados también están disponibles como operaciones integradas, que se incluyen en las operaciones gratuitas iniciales. Por encima de las operaciones inicialmente gratuitas, la facturación sigue los precios de Acciones, no los precios de los conectores estándar o empresarial.
Conector administrado Estas operaciones se ejecutan de forma independiente en Azure. En el diseñador, puede encontrar estas operaciones bajo la etiqueta Estándar o Empresarial. Estas ejecuciones de operación siguen los precios del conector estándar o empresarial.

Nota: Las ejecuciones de operación del conector empresarial en versión preliminar siguen los precios del conector estándardel plan de consumo.
Conector personalizado Estas operaciones se ejecutan de forma independiente en Azure. En el diseñador, puede encontrar estas operaciones en la etiqueta Personalizado. Para ver los límites de número de conectores, rendimiento y tiempo de espera, revise Límites de los conectores personalizados en Azure Logic Apps. Estas ejecuciones de operación siguen los precios del conector estándar.

Para más información sobre cómo funciona el modelo de consumo con operaciones que se ejecutan dentro de otras operaciones, como bucles, procesamiento de varios elementos (por ejemplo, matrices) y directivas de reintento, consulte Comportamiento de otras operaciones.

Sugerencias de estimación de costos para el modelo de consumo

Para ayudarle a estimar de manera más precisa los costos de consumo, revise estas sugerencias:

  • Piense en el número de mensajes o eventos posibles que podrían llegar cualquier día, en lugar de basar sus cálculos únicamente en el intervalo de sondeo.

  • Cuando un evento o mensaje cumple los criterios del desencadenador, muchos desencadenadores intentan leer inmediatamente todos los otros eventos o mensajes de espera que cumplen los criterios. Este comportamiento significa que incluso cuando se selecciona un intervalo de sondeo más largo, el desencadenador se activa en función del número de eventos o mensajes de espera que pueden iniciar los flujos de trabajo. Los desencadenadores que siguen este comportamiento son Azure Service Bus y Azure Event Hubs.

    Por ejemplo, suponga que configura un desencadenador que comprueba un punto de conexión cada día. Cuando el desencadenador comprueba el punto de conexión y busca 15 eventos que satisfacen los criterios, se activa y ejecuta el flujo de trabajo correspondiente 15 veces. El servicio Logic Apps mide todas las acciones que realizan esos 15 flujos de trabajo, incluidas las solicitudes del desencadenador.

Estándar (inquilino único)

En Azure Logic Apps de inquilino único, una aplicación lógica y su flujo de trabajo siguen los precios y la facturación del plan estándar. Estas aplicaciones lógicas se crean de varias maneras, por ejemplo, cuando se elige el tipo de recurso Logic App (Standard) (Aplicación lógica [estándar]) o se usa la extensión Azure Logic Apps (Standard) (Azure Logic Apps [estándar]) en Visual Studio Code. Este modelo de precios requiere que las aplicaciones lógicas usen un plan de hospedaje y un plan de tarifa, lo que difiere del plan de consumo, ya que se le factura por la capacidad reservada y los recursos dedicados, tanto si los usa como si no.

Al crear o implementar aplicaciones lógicas con el tipo de recurso de aplicación lógica (Estándar) y seleccionar cualquier región de Azure para la implementación, también seleccionará un plan de hospedaje Estándar de flujo de trabajo. Sin embargo, si selecciona un recurso de App Service Environment v3 existente para la ubicación de implementación, debe seleccionar un plan de App Service.

Importante

La opción de hospedaje de híbrida está actualmente en versión preliminar. Para obtener información, consulte Configuración de su propia infraestructura para aplicaciones lógicas estándar mediante la implementación híbrida.

Los siguientes planes y recursos ya no están disponibles ni se admiten con la versión pública de flujos de trabajo de aplicaciones lógicas estándar en Azure Logic Apps de un solo inquilino: plan Premium de Functions, App Service Environment v1 y App Service Environment v2. El plan de App Service está disponible y solo se admite con App Service Environment v3 (ASE v3).

En la tabla siguiente se resume cómo el modelo estándar controla la medición y la facturación de los siguientes componentes cuando se usa con una aplicación lógica y un flujo de trabajo en Azure Logic Apps de inquilino único:

Componente Medición y facturación
CPU virtual (vCPU) y memoria El modelo estándar requiere que la aplicación lógica use el plan de hospedaje Workflow Standard (Flujo de trabajo estándar) y un plan de tarifa, que determina los niveles de recursos y las tarifas de precios que se aplican a la capacidad de proceso y memoria. Para más información, consulte Planes de tarifa en el modelo estándar.
Operaciones de desencadenador y acción El modelo estándar incluye un número ilimitado de operaciones integradas gratuitas que el flujo de trabajo puede ejecutar.

Si el flujo de trabajo usa operaciones de conectores administrados, la medición se aplica a cada llamada, mientras que la facturación sigue los mismos precios del conector estándar o empresarial que el plan de consumo. Para más información, consulte Operaciones de desencadenador y acción en el modelo de estándar.
Operaciones de almacenamiento La medición se aplica a las operaciones de almacenamiento ejecutadas por Azure Logic Apps. Por ejemplo, las operaciones de almacenamiento se ejecutan cuando el servicio guarda las entradas y salidas del historial de ejecución del flujo de trabajo. La facturación sigue el plan de tarifa elegido. Para más información, consulte Operaciones de almacenamiento.
Cuentas de integración Si crea una cuenta de integración para que la use la aplicación lógica, la medición se basa en el tipo de cuenta de integración que cree. La facturación sigue los precios de la cuenta de integración. Para más información, consulte Cuentas de integración.

Planes de tarifa del modelo estándar

El plan de tarifa que elija para la medición y facturación de su recurso de aplicación lógica (Estándar) incluye cantidades específicas de proceso en recursos de CPU virtual (vCPU) y memoria. Si selecciona un App Service Environment v3 como ubicación de implementación y un plan de App Service, concretamente un plan de tarifa de un plan de servicio V2 aislado, se le cobrarán las instancias usadas por el plan de App Service y por ejecutar los flujos de trabajo de su aplicación lógica. No se aplica ningún otro cargo. Para obtener más información, consulte Plan de App Service: plan de tarifa de plan de servicio V2 aislado.

Si selecciona un plan de hospedaje Estándar de flujo de trabajo, puede elegir entre los siguientes niveles:

Plan de tarifa CPU virtual (vCPU) Memoria (GB)
WS1 1 3,5
WS2 2 7
WS3 4 14

Importante

El ejemplo siguiente es solo ilustrativo y proporciona estimaciones de ejemplo para mostrar cómo funciona en general un plan de tarifa. Para ver los precios específicos de vCPU y memoria en función de las regiones concretas en las que Azure Logic Apps está disponible, revise el plan estándar para una región seleccionada en la página de precios de Azure Logic Apps.

Supongamos que, en una región de ejemplo, los siguientes recursos tienen estas tarifas por hora:

Resource Tarifa por hora (región de ejemplo)
vCPU 0,192 USD por vCPU
Memoria 0,0137 USD por GB

El cálculo siguiente proporciona una estimación de la tarifa mensual:

<monthly-rate> = 730 horas (al mes) * [(<number-vCPU> * <hourly-rate-vCPU>) + (<number-GB-memory> * <hourly-rate-GB-memory>)]

En función de la información anterior, en esta tabla se muestran las tarifas mensuales estimadas para cada plan de tarifa y los recursos incluidos en él:

Plan de tarifa CPU virtual (vCPU) Memoria (GB) Tarifa mensual (región de ejemplo)
WS1 1 3,5 175,16 USD
WS2 2 7 350,33 UDS
WS3 4 14 700,65 USD

Operaciones de desencadenador y acción en el modelo estándar

Excepto por las operaciones integradas gratuitas ilimitadas que puede ejecutar un flujo de trabajo, el modelo estándar mide y factura una operación en función de cada llamada, con independencia de si el flujo de trabajo global se ejecuta correctamente, finaliza o incluso se crea una instancia de él. Normalmente, una operación realiza una única ejecución a menos que tenga habilitados los reintentos. A su vez, una ejecución normalmente realiza una sola llamada a menos que la operación admita y permita la fragmentación o paginación para obtener grandes cantidades de datos. Si está habilitada la fragmentación o paginación, es posible que una ejecución de la operación tenga que realizar varias llamadas. El modelo estándar mide y factura una operación por llamada, no por ejecución.

Por ejemplo, suponga que un flujo de trabajo comienza con un desencadenador de sondeo que obtiene registros mediante la realización regular de llamadas salientes a un punto de conexión. La llamada saliente se mide y se factura, independientemente de si el desencadenador se activa o se omite. El estado del desencadenador controla si la instancia de flujo de trabajo se crea y ejecuta. Ahora, supongamos que la operación también admite, y tiene habilitada, la fragmentación o la paginación. Si la operación tiene que realizar 10 llamadas para terminar de obtener todos los datos, la operación se mide y se factura por llamada.

En la tabla siguiente se resume cómo el modelo estándar controla la medición y la facturación de los tipos de operación cuando se usa con una aplicación lógica y un flujo de trabajo en Azure Logic Apps de inquilino único:

Tipo de operación Descripción Medición y facturación
Integrada Estas operaciones se ejecutan de forma directa y nativa con el entorno de ejecución de Azure Logic Apps. En el diseñador, puede encontrar estas operaciones en la galería de conectores en Tiempo de ejecución>Desde la aplicación.

Por ejemplo, el desencadenador HTTP y el desencadenador de solicitud son desencadenadores integrados. La acción HTTP y la acción de respuesta son acciones integradas. Otras operaciones integradas incluyen acciones de control de flujo de trabajo, como bucles y condiciones, operaciones de datos, operaciones por lotes, etc.

 El modelo estándar incluye operaciones integradas gratuitas ilimitadas.

Nota: Algunas operaciones de conectores administrados también están disponibles como operaciones integradas. Aunque las operaciones integradas son gratuitas, el modelo estándar todavía mide y factura las operaciones de conectores administrados con los mismos precios del conector estándar o empresarial que el modelo de consumo.
Conector administrado Estas operaciones se ejecutan de forma independiente en una instancia compartida global de Azure. En el diseñador, puede encontrar estas operaciones en la galería de conectores en Tiempo de ejecución>Recursos compartidos. El modelo estándar mide y factura las operaciones de conectores administrados con los mismos precios de conector estándar o empresarial que el modelo de consumo.

Nota: Las operaciones de conector empresarial en versión preliminar siguen los precios del conector estándardel plan de consumo.
Conector personalizado Actualmente, solo puede crear y usar operaciones de conector integradas personalizadas en flujos de trabajo de aplicaciones lógicas basadas en un único inquilino. El modelo estándar incluye operaciones integradas gratuitas ilimitadas. Para ver los límites de rendimiento y tiempo de espera, consulte Límites de los conectores personalizados en Azure Logic Apps.

Para más información sobre cómo funciona el modelo estándar con operaciones que se ejecutan dentro de otras operaciones, como bucles, procesamiento de varios elementos (por ejemplo, matrices) y directivas de reintento, consulte Comportamiento de otras operaciones.

Comportamiento de otras operaciones

En la tabla siguiente se resume cómo los modelos Consumo y Estándar controlan las operaciones que se ejecutan dentro de otras operaciones, como bucles, procesar varios elementos como matrices y directivas de reintento:

Operación Descripción Consumo Estándar
Acciones de bucle Una acción de bucle, como el bucle For each o Until, puede incluir otras acciones que se ejecutan durante cada ciclo del bucle. Excepto por el número inicial de operaciones integradas incluidas, la acción de bucle y cada acción en el bucle se miden cada vez que se ejecuta el ciclo del bucle. Si una acción procesa elementos de una colección, como una lista o una matriz, el número de elementos también se usa en el cálculo de medición.

Por ejemplo, supongamos que tiene un bucle For each con acciones que procesan una lista. El servicio multiplica el número de elementos de la lista por el número de acciones del bucle, y agrega la acción que inicia el bucle. Por lo tanto, el cálculo de una lista de 10 elementos es (10x1)+1, lo que da como resultado 11 ejecuciones de acción.

Los precios dependen de si los tipos de operación son integradas, estándar o empresariales.

 Excepto por las operaciones integradas incluidas, es igual que el modelo de consumo.
Directivas de reintentos En operaciones admitidas, puede implementar el control básico de excepciones y errores mediante la configuración de una directiva de reintentos. Excepto por el número inicial de operaciones integradas, se mide la ejecución original más cada ejecución reintentada. Por ejemplo, una acción que se ejecuta con 5 reintentos se mide y se factura como 6 ejecuciones.

Los precios dependen de si los tipos de operación son integradas, estándar o empresariales.

 Excepto por las operaciones integradas incluidas, es igual que el modelo de consumo.

Operaciones de almacenamiento

Azure Logic Apps usa Azure Storage para las transacciones de almacenamiento necesarias, como el uso de colas para programar operaciones de desencadenador o el uso de tablas y blobs para almacenar estados de flujo de trabajo. En función de las operaciones del flujo de trabajo, los costos de almacenamiento varían porque diferentes desencadenadores, acciones y cargas tienen como resultado diferentes operaciones y necesidades de almacenamiento. El servicio también guarda y almacena entradas y salidas del historial de ejecución del flujo de trabajo, en función del límite de retención del historial de ejecución del recurso de aplicación lógica. Este límite de retención se puede administrar en el nivel de recurso de aplicación lógica, pero no en el nivel de flujo de trabajo.

En la tabla siguiente se resume cómo los modelos Consumo y estándar controlan la medición y la facturación de las operaciones de almacenamiento:

Modelo Descripción Medición y facturación
Consumo (multiinquilino) Los recursos y el uso de almacenamiento están asociados al recurso de aplicación lógica. La medición y la facturación solo se aplican al consumo de almacenamiento relacionado con la retención de datos y siguen los precios de retención de datos del plan de consumo.
Estándar (inquilino único) Puede usar su propia cuenta de almacenamiento de Azure, lo que le proporciona más control y flexibilidad sobre los datos del flujo de trabajo. La medición y la facturación siguen el modelo de precios de Azure Storage. Los costos de almacenamiento se enumeran por separado en la factura de Azure.

Sugerencia: Para comprender mejor el número de operaciones de almacenamiento que podría ejecutar un flujo de trabajo y su costo, pruebe la calculadora de almacenamiento de Logic Apps. Seleccione un flujo de trabajo de ejemplo o use una definición de flujo de trabajo existente. El primer cálculo estima el número de operaciones de almacenamiento en el flujo de trabajo. Luego, puede usar estos números para calcular los posibles costos mediante la calculadora de precios de Azure. Para más información, revise Estimación de las necesidades de almacenamiento y los costos de los flujos de trabajo de Azure Logic Apps de inquilino único.

Para más información, revise la siguiente documentación:

Puerta de enlace de datos local

Una puerta de enlace de datos local es un recurso de Azure independiente que se crea para que los flujos de trabajo de las aplicaciones lógicas puedan acceder a los datos locales mediante conectores específicos compatibles con la puerta de enlace. El recurso de puerta de enlace en sí no genera cargos, pero sí lo hacen las operaciones que se ejecutan a través de la puerta de enlace, según el modelo de precios y facturación que usa la aplicación lógica.

Cuentas de integración

Una cuenta de integración es un recurso de Azure independiente que se crea como contenedor para definir y almacenar artefactos de empresa a empresa (B2B), como socios comerciales, acuerdos, esquemas, mapas, etc. Después de crear esta cuenta y definir estos artefactos, vincule la cuenta a la aplicación lógica para que pueda usar estos artefactos y varias operaciones B2B en los flujos de trabajo para explorar, compilar y probar soluciones de integración que usan funcionalidades de intercambio electrónico de datos y procesamiento de XML.

En la tabla siguiente se resume cómo los modelos Consumo y estándar controlan la medición y la facturación de las cuentas de integración:

Modelo Medición y facturación
Consumo (multiinquilino) Para la medición y la facturación se usan los precios de la cuenta de integración, en función del nivel de cuenta que se use.
Estándar (inquilino único) Para la medición y la facturación se usan los precios de la cuenta de integración, en función del nivel de cuenta que se use.

Para más información, revise la siguiente documentación:

Otros elementos que no se miden ni se facturan

En todos los modelos de precios, los siguientes elementos no se miden ni se facturan:

  • Acciones que no se ejecutaron porque el flujo de trabajo se detuvo antes de finalizar.
  • Aplicaciones lógicas o flujos de trabajo deshabilitados, ya que, al estar inactivos, no pueden crear más instancias.

Pasos siguientes