Medição de uso, cobrança e preços para Aplicativos Lógicos do Azure
Aplica-se a: Aplicativos Lógicos do Azure (Consumo + Padrão)
As Aplicações Lógicas do Azure ajudam-no a criar e executar fluxos de trabalho de integração automatizados que podem ser dimensionados na nuvem. Este artigo descreve como os modelos de medição, cobrança e preços funcionam para os Aplicativos Lógicos do Azure e recursos relacionados. Para obter informações como taxas de preços específicas, planejamento de custos ou diferentes ambientes de hospedagem, revise o seguinte conteúdo:
- Taxas de preços para Aplicativos Lógicos do Azure
- Planejar e gerenciar custos para Aplicativos Lógicos do Azure
- Inquilino único versus multilocatário
Consumo (multilocatário)
Nos Aplicativos Lógicos do Azure multilocatário, um aplicativo lógico e seu fluxo de trabalho seguem o Plano de consumo para preços e cobrança. Você cria esses aplicativos lógicos de várias maneiras, por exemplo, quando escolhe o tipo de recurso Aplicativo Lógico (Consumo), usa a extensão Aplicativos Lógicos do Azure (Consumo) no Visual Studio Code ou quando cria tarefas de automação.
A tabela a seguir resume como o modelo de Consumo lida com a medição e a cobrança dos seguintes componentes quando usado com um aplicativo lógico e um fluxo de trabalho em Aplicativos Lógicos do Azure multilocatário:
| Componente | Medição e faturação |
|---|---|
| Operações de desencadeamento e ação | O modelo de Consumo inclui um número inicial de operações internas gratuitas, por assinatura do Azure, que um fluxo de trabalho pode executar. Acima desse número, a medição se aplica a cada execução e o faturamento segue o preço das Ações para o plano de Consumo. Para outros tipos de operação, como conectores gerenciados, a cobrança segue o preço do conector Standard ou Enterprise para o plano de Consumo. Para obter mais informações, revise Operações de gatilho e ação no modelo de consumo. |
| Operações de armazenamento | A medição aplica-se apenas ao consumo de armazenamento relacionado à retenção de dados, como salvar entradas e saídas do histórico de execução do fluxo de trabalho. A faturação segue o preço de retenção de dados para o plano de Consumo. Para obter mais informações, consulte Operações de armazenamento. |
| Contas de integração | A monitoração se aplica com base no tipo de conta de integração que você cria e usa com seu aplicativo lógico. O faturamento segue o preço da Conta de Integração. Para obter mais informações, consulte Contas de integração. |
Operações de acionamento e ação no modelo de Consumo
Exceto para o número inicial de execuções de operação interna gratuitas, por assinatura do Azure, que um fluxo de trabalho pode executar, o modelo de Consumo mede e fatura uma operação com base em cada execução, independentemente de o fluxo de trabalho geral ser executado, concluído ou mesmo instanciado com êxito. Uma operação geralmente faz uma única execução , a menos que a operação tenha tentativas de repetição habilitadas. Por sua vez, uma execução geralmente faz uma única chamada , a menos que a operação suporte e permita que o chunking ou a paginação obtenham grandes quantidades de dados. Se a fragmentação ou paginação estiver habilitada, a execução de uma operação pode ter que fazer várias chamadas.
O modelo de Consumo mede e fatura uma operação por execução, não por chamada. Por exemplo, suponha que um fluxo de trabalho comece com um gatilho de sondagem que obtém registros fazendo regularmente chamadas de saída para um ponto de extremidade. A chamada de saída é medida e cobrada como uma única execução, independentemente de o gatilho ser acionado ou ignorado, como quando um gatilho verifica um ponto de extremidade, mas não encontra dados ou eventos. O estado de gatilho controla se a instância do fluxo de trabalho é criada e executada ou não. Agora, suponha que a operação também suporta e habilitou o chunking ou a paginação. Se a operação tiver que fazer 10 chamadas para terminar de obter todos os dados, a operação ainda é medida e faturada como uma única execução, apesar de fazer várias chamadas.
Nota
Por padrão, os gatilhos que retornam uma matriz têm uma configuração Dividir em que já está habilitada. Essa configuração resulta em um evento de gatilho, que você pode revisar no histórico de disparos, e uma instância de fluxo de trabalho para cada item de matriz. Todas as instâncias de fluxo de trabalho são executadas em paralelo para que os itens de matriz sejam processados ao mesmo tempo. A cobrança aplica-se a todos os eventos de acionamento, independentemente de o estado do gatilho ser Bem-sucedido ou Ignorado. Os gatilhos ainda são faturáveis mesmo em cenários em que os gatilhos não instanciam e iniciam o fluxo de trabalho, mas o estado do gatilho é Êxito, Falha ou Ignorado.
A tabela a seguir resume como o modelo de Consumo lida com a medição e a cobrança desses tipos de operação quando usado com um aplicativo lógico e fluxo de trabalho em Aplicativos Lógicos do Azure multilocatário:
| Tipo de operação | Description | Medição e faturação |
|---|---|---|
| Incorporado | Essas operações são executadas direta e nativamente com o tempo de execução dos Aplicativos Lógicos do Azure. No designer, você pode encontrar essas operações sob o rótulo Built-in . Por exemplo, o gatilho HTTP e o gatilho Request são gatilhos internos. A ação HTTP e a ação Resposta são ações internas. Outras operações internas incluem ações de controle de fluxo de trabalho, como loops e condições, operações de dados, operações em lote e outras. |
O modelo de Consumo inclui um número inicial de operações internas gratuitas, por assinatura do Azure, que um fluxo de trabalho pode executar. Acima desse número, as execuções de operação internas seguem o preço das Ações. Nota: Algumas operações de conector gerenciado também estão disponíveis como operações internas, que estão incluídas nas operações livres iniciais. Acima das operações inicialmente gratuitas, o faturamento segue o preço das Ações, não o preço do conector Standard ou Enterprise. |
| Conector gerenciado | Essas operações são executadas separadamente no Azure. No designer, você pode encontrar essas operações sob o rótulo Standard ou Enterprise . | Essas execuções de operação seguem os preços do conector Standard ou Enterprise. Nota: As execuções da operação do conector Enterprise Preview seguem os preços do conector Padrão de Consumo. |
| Conector personalizado | Essas operações são executadas separadamente no Azure. No designer, você pode encontrar essas operações sob o rótulo personalizado . Para limitar o número de conectores, a taxa de transferência e o tempo limite, revise Limites de conector personalizados nos Aplicativos Lógicos do Azure. | Essas execuções de operação seguem os preços do conector padrão. |
Para obter mais informações sobre como o modelo de consumo funciona com operações que são executadas dentro de outras operações, como loops, processam vários itens, como matrizes, e políticas de repetição, consulte Outro comportamento de operação.
Dicas de estimativa de custos para o modelo de Consumo
Para ajudá-lo a estimar custos de consumo mais precisos, leia estas dicas:
Considere o possível número de mensagens ou eventos que podem chegar em um determinado dia, em vez de basear seus cálculos apenas no intervalo de sondagem.
Quando um evento ou mensagem atende aos critérios de gatilho, muitos gatilhos tentam ler imediatamente quaisquer outros eventos ou mensagens em espera que atendam aos critérios. Esse comportamento significa que, mesmo quando você seleciona um intervalo de sondagem maior, o gatilho é acionado com base no número de eventos de espera ou mensagens que se qualificam para iniciar fluxos de trabalho. Os gatilhos que seguem esse comportamento incluem o Barramento de Serviço do Azure e os Hubs de Eventos do Azure.
Por exemplo, suponha que você configure o gatilho que verifica um ponto de extremidade todos os dias. Quando o gatilho verifica o ponto de extremidade e encontra 15 eventos que atendem aos critérios, o gatilho é acionado e executa o fluxo de trabalho correspondente 15 vezes. O serviço Aplicativos Lógicos mede todas as ações que esses 15 fluxos de trabalho executam, incluindo as solicitações de gatilho.
Standard (inquilino único)
Nos Aplicativos Lógicos do Azure de locatário único, um aplicativo lógico e seus fluxos de trabalho seguem o plano Padrão para preços e cobrança. Você cria esses aplicativos lógicos de várias maneiras, por exemplo, quando escolhe o tipo de recurso Aplicativo Lógico (Padrão) ou usa a extensão Aplicativos Lógicos do Azure (Padrão) no Visual Studio Code. Esse modelo de preços exige que os aplicativos lógicos usem um plano de hospedagem e uma camada de preço, que difere do plano de Consumo porque você é cobrado pela capacidade reservada e pelos recursos dedicados, independentemente de usá-los ou não.
Ao criar ou implantar aplicativos lógicos com o tipo de recurso Aplicativo Lógico (Padrão) e selecionar qualquer região do Azure para implantação, você também selecionará um plano de hospedagem Padrão de Fluxo de Trabalho. No entanto, se você selecionar um recurso existente do Ambiente do Serviço de Aplicativo v3 para seu local de implantação, deverá selecionar um Plano do Serviço de Aplicativo.
Importante
A opção de hospedagem híbrida está atualmente em visualização. Para obter informações, consulte Configurar sua própria infraestrutura para aplicativos lógicos padrão usando implantação híbrida.
Os seguintes planos e recursos não estão mais disponíveis ou não são suportados com a versão pública dos fluxos de trabalho do aplicativo lógico padrão nos Aplicativos Lógicos do Azure de locatário único: plano Premium do Functions, Ambiente do Serviço de Aplicativo v1 e Ambiente do Serviço de Aplicativo v2. O Plano do Serviço de Aplicativo está disponível e é suportado somente com o Ambiente do Serviço de Aplicativo v3 (ASE v3).
A tabela a seguir resume como o modelo Standard lida com medição e cobrança para os seguintes componentes quando usado com um aplicativo lógico e um fluxo de trabalho em Aplicativos Lógicos do Azure de locatário único:
| Componente | Medição e faturação |
|---|---|
| CPU virtual (vCPU) e memória | O modelo Standard requer que seu aplicativo lógico use o plano de hospedagem Workflow Standard e uma camada de preço, que determina os níveis de recursos e as taxas de preços que se aplicam à capacidade de computação e memória. Para obter mais informações, consulte Níveis de preços no modelo Padrão. |
| Operações de desencadeamento e ação | O modelo Standard inclui um número ilimitado de operações internas gratuitas que seu fluxo de trabalho pode executar. Se o seu fluxo de trabalho usar qualquer operação de conector gerenciado, a medição se aplicará a cada chamada, enquanto a cobrança segue o mesmo preço do conector Standard ou Enterprise do plano de consumo. Para obter mais informações, revise as operações de gatilho e ação no modelo Padrão. |
| Operações de armazenamento | A medição aplica-se a quaisquer operações de armazenamento executadas pelas Aplicações Lógicas do Azure. Por exemplo, as operações de armazenamento são executadas quando o serviço salva entradas e saídas do histórico de execução do fluxo de trabalho. A faturação segue o nível de preços escolhido. Para obter mais informações, consulte Operações de armazenamento. |
| Contas de integração | Se você criar uma conta de integração para seu aplicativo lógico usar, a medição será baseada no tipo de conta de integração que você criar. A cobrança segue o preço da Conta de Integração. Para obter mais informações, consulte Contas de integração. |
Níveis de preços no modelo Standard
A camada de preço escolhida para medição e cobrança do recurso Logic App (Standard) inclui quantidades específicas de computação em recursos de CPU virtual (vCPU) e memória. Se você selecionar um Ambiente do Serviço de Aplicativo v3 como o local de implantação e um Plano do Serviço de Aplicativo, especificamente uma camada de preço do Plano de Serviço V2 Isolado, será cobrado pelas instâncias usadas pelo Plano do Serviço de Aplicativo e pela execução dos fluxos de trabalho do aplicativo lógico. Não se aplicam outras taxas. Para obter mais informações, consulte Plano do Serviço de Aplicativo - Níveis de preços do Plano de Serviço V2 Isolado.
Se você selecionar um plano de hospedagem Workflow Standard , poderá escolher entre as seguintes camadas:
| Escalão de preço | CPU virtual (vCPU) | Memória (GB) |
|---|---|---|
| WS1 | 1 | 3.5 |
| WS2 | 2 | 7 |
| WS3 | 4 | 14 |
Importante
O exemplo a seguir é apenas para ilustração e fornece estimativas de exemplo para geralmente mostrar como um nível de preço funciona. Para obter preços específicos de vCPU e memória com base em regiões específicas onde os Aplicativos Lógicos do Azure estão disponíveis, revise o plano Padrão para uma região selecionada na página de preços dos Aplicativos Lógicos do Azure.
Suponha que, em uma região de exemplo, os seguintes recursos tenham estas taxas horárias:
| Recurso | Taxa horária (região de exemplo) |
|---|---|
| vCPU | $0,192 por vCPU |
| Memória | $0,0137 por GB |
O cálculo a seguir fornece uma taxa mensal estimada:
<taxa mensal = 730 horas (por mês) * [(<número-vCPU> * <taxa horária-vCPU>) + (<número-GB-memória> * <taxa horária-GB-memória)]>>
Com base nas informações anteriores, a tabela a seguir mostra as taxas mensais estimadas para cada nível de preço e os recursos nesse nível de preço:
| Escalão de preço | CPU virtual (vCPU) | Memória (GB) | Taxa mensal (região de exemplo) |
|---|---|---|---|
| WS1 | 1 | 3.5 | $175,16 |
| WS2 | 2 | 7 | $350,33 |
| WS3 | 4 | 14 | $700,65 |
Operações de acionamento e ação no modelo Standard
Com exceção das operações internas gratuitas ilimitadas que um fluxo de trabalho pode executar, o modelo padrão mede e fatura uma operação com base em cada chamada, independentemente de o fluxo de trabalho geral ser executado, concluído ou mesmo instanciado. Uma operação geralmente faz uma única execução , a menos que a operação tenha tentativas de repetição habilitadas. Por sua vez, uma execução geralmente faz uma única chamada , a menos que a operação suporte e permita que o chunking ou a paginação obtenham grandes quantidades de dados. Se a fragmentação ou paginação estiver habilitada, a execução de uma operação pode ter que fazer várias chamadas. O modelo Standard mede e fatura uma operação por chamada, não por execução.
Por exemplo, suponha que um fluxo de trabalho comece com um gatilho de sondagem que obtém registros fazendo regularmente chamadas de saída para um ponto de extremidade. A chamada de saída é medida e faturada, independentemente de o gatilho ser acionado ou ignorado. O estado de gatilho controla se a instância do fluxo de trabalho é criada e executada ou não. Agora, suponha que a operação também suporta e habilitou o chunking ou a paginação. Se a operação tiver que fazer 10 chamadas para terminar de obter todos os dados, a operação é medida e faturada por chamada.
A tabela a seguir resume como o modelo Standard lida com medição e cobrança para tipos de operação quando usado com um aplicativo lógico e fluxo de trabalho em Aplicativos Lógicos do Azure de locatário único:
| Tipo de operação | Description | Medição e faturação |
|---|---|---|
| Incorporado | Essas operações são executadas direta e nativamente com o tempo de execução dos Aplicativos Lógicos do Azure. No designer, você pode encontrar essas operações na galeria de conectores em Runtime>In-App. Por exemplo, o gatilho HTTP e o gatilho Request são gatilhos internos. A ação HTTP e a ação Resposta são ações internas. Outras operações internas incluem ações de controle de fluxo de trabalho, como loops e condições, operações de dados, operações em lote e outras. |
O modelo Standard inclui operações integradas gratuitas ilimitadas. Nota: Algumas operações de conector gerenciado também estão disponíveis como operações internas. Embora as operações internas sejam gratuitas, o modelo Standard ainda mede e fatura as operações gerenciadas do conector usando o mesmo preço do conector Standard ou Enterprise do modelo de Consumo. |
| Conector gerenciado | Essas operações são executadas separadamente no Azure global compartilhado. No designer, você pode encontrar essas operações na galeria de conectores em Runtime>Shared. | O modelo Standard mede e fatura as operações gerenciadas do conector com base no mesmo preço do conector Standard e Enterprise que o modelo de Consumo. Nota: As operações do conector Enterprise Preview seguem os preços do conector Padrão de Consumo. |
| Conector personalizado | Atualmente, você pode criar e usar apenas operações de conector interno personalizadas em fluxos de trabalho de aplicativos lógicos baseados em locatário único. | O modelo Standard inclui operações integradas gratuitas ilimitadas. Para obter limites de taxa de transferência e tempo limite, revise Limites de conector personalizados nos Aplicativos Lógicos do Azure. |
Para obter mais informações sobre como o modelo Standard funciona com operações que são executadas dentro de outras operações, como loops, processam vários itens, como matrizes, e repetem políticas, consulte Outro comportamento de operação.
Outro comportamento de operação
A tabela a seguir resume como os modelos Consumo e Padrão lidam com operações executadas dentro de outras operações, como loops, processam vários itens, como matrizes, e repetem políticas:
| Operation | Description | Consumo | Standard |
|---|---|---|---|
| Ações de loop | Uma ação de loop, como o loop For each ou Until pode incluir outras ações executadas durante cada ciclo de loop. | Exceto para o número inicial de operações internas incluídas, a ação de loop e cada ação no loop são medidos cada vez que o ciclo de loop é executado. Se uma ação processar quaisquer itens em uma coleção, como uma lista ou matriz, o número de itens também será usado no cálculo de medição. Por exemplo, suponha que você tenha um Para cada loop com ações que processam uma lista. O serviço multiplica o número de itens de lista pelo número de ações no loop e adiciona a ação que inicia o loop. Assim, o cálculo para uma lista de 10 itens é (10 * 1) + 1, o que resulta em 11 execuções de ação. O preço baseia-se no facto de os tipos de operação serem incorporados, Standard ou Enterprise. |
Exceto para as operações incorporadas incluídas, iguais ao modelo de Consumo. |
| Políticas de repetição | Em operações com suporte, você pode implementar o tratamento básico de exceções e erros configurando uma política de novas tentativas. | Exceto para o número inicial de operações internas, a execução original mais cada execução repetida são medidos. Por exemplo, uma ação que é executada com 5 repetições é medida e cobrada como 6 execuções. O preço baseia-se no facto de os tipos de operação serem incorporados, Standard ou Enterprise. |
Exceto para as operações incorporadas incluídas, iguais ao modelo de Consumo. |
Operações de armazenamento
Os Aplicativos Lógicos do Azure usam o Armazenamento do Azure para quaisquer transações de armazenamento necessárias, como usar filas para agendar operações de gatilho ou usar tabelas e blobs para armazenar estados de fluxo de trabalho. Com base nas operações em seu fluxo de trabalho, os custos de armazenamento variam porque diferentes gatilhos, ações e cargas úteis resultam em diferentes operações e necessidades de armazenamento. O serviço também salva e armazena entradas e saídas do histórico de execução do fluxo de trabalho, com base no limite de retenção do histórico de execução do recurso do aplicativo lógico. Você pode gerenciar esse limite de retenção no nível de recursos do aplicativo lógico, não no nível do fluxo de trabalho.
A tabela a seguir resume como os modelos Consumo e Padrão lidam com a medição e o faturamento de operações de armazenamento:
| Modelo | Description | Medição e faturação |
|---|---|---|
| Consumo (multilocatário) | Os recursos de armazenamento e o uso são anexados ao recurso do aplicativo lógico. | A medição e a faturação aplicam-se apenas ao consumo de armazenamento relacionado com a retenção de dados e seguem os preços de retenção de dados para o plano de Consumo. |
| Standard (inquilino único) | Você pode usar sua própria conta de armazenamento do Azure, o que lhe dá mais controle e flexibilidade sobre os dados do seu fluxo de trabalho. | A medição e a faturação seguem o modelo de preços do Armazenamento do Azure. Os custos de armazenamento aparecem separadamente na sua fatura de faturação do Azure. Dica: para ajudá-lo a entender melhor o número de operações de armazenamento que um fluxo de trabalho pode executar e seu custo, tente usar a calculadora de armazenamento de aplicativos lógicos. Selecione um fluxo de trabalho de exemplo ou use uma definição de fluxo de trabalho existente. O primeiro cálculo estima o número de operações de armazenamento em seu fluxo de trabalho. Em seguida, você pode usar esses números para estimar possíveis custos usando a calculadora de preços do Azure. Para obter mais informações, consulte Estimar necessidades e custos de armazenamento para fluxos de trabalho em Aplicativos Lógicos do Azure de locatário único. |
Para obter mais informações, consulte a seguinte documentação:
Gateway de dados no local
O gateway de dados local é um recurso separado do Azure que você cria para que seus fluxos de trabalho de aplicativo lógico possam acessar dados locais usando conectores específicos com suporte de gateway. O recurso de gateway em si não incorre em encargos, mas as operações executadas através do gateway incorrem em encargos, com base no modelo de preços e cobrança usado pelo seu aplicativo lógico.
Contas de integração
Uma conta de integração é um recurso separado do Azure que você cria como um contêiner para definir e armazenar artefatos B2B (business-to-business), como parceiros comerciais, contratos, esquemas, mapas e assim por diante. Depois de criar essa conta e definir esses artefatos, vincule-a ao seu aplicativo lógico para que você possa usar esses artefatos e várias operações B2B em fluxos de trabalho para explorar, criar e testar soluções de integração que usam recursos de processamento EDI e XML.
A tabela a seguir resume como os modelos Consumo e Padrão lidam com medição e cobrança para contas de integração:
Para obter mais informações, consulte a seguinte documentação:
- Criar e gerenciar contas de integração
- Limites de conta de integração em Aplicativos Lógicos do Azure
Outros itens não medidos ou faturados
Em todos os modelos de preços, os seguintes itens não são medidos ou faturados:
- Ações que não foram executadas porque o fluxo de trabalho parou antes da conclusão
- Desabilitou aplicativos lógicos ou fluxos de trabalho porque eles não podem criar novas instâncias enquanto estão inativos.