Compartilhar via

Medição, cobrança e preços de uso para os Aplicativos Lógicos do Azure

  • Artigo

Aplica-se a: Aplicativos Lógicos do Azure (Consumo + Standard)

Aplicativos Lógicos do Azureajudam a criar e executar os fluxos de trabalho de integração automatizados que podem reduzir horizontalmente a nuvem. Este artigo descreve como os modelos de medição, cobrança e de preços funcionam no Aplicativos Lógicos do Azure e nos recursos relacionados. Para obter informações como taxas de preço específicas, planejamento de custos ou ambientes de hospedagem diferentes, examine o seguinte conteúdo:

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 ao criar 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 nos Aplicativos Lógicos do Azure multilocatário:

Componente Medição e cobrança
Operações de gatilho e ação O modelo de Consumo inclui um número inicial de operações 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 a cobrança segue os preços de Ações para o plano de Consumo. Para outros tipos de operação, como conectores gerenciados, a cobrança segue os preços 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 se aplica somente ao consumo de armazenamento relacionado à retenção de dados, como salvar entradas e saídas do histórico de execuções do fluxo de trabalho. A cobrança segue o preço de retenção de dados para o plano de Consumo. Para obter mais informações, confira Operações de armazenamento.
Contas de integração A medição se aplica com base no tipo de conta de integração que você cria e usa com o aplicativo lógico. A cobrança segue os preços da Preços da Conta de Integração. Para obter mais informações, examine as Contas de integração.

Operações de gatilho e ação no modelo de Consumo

Exceto pelo número inicial de execuções de operação interno gratuitas, por assinatura do Azure, que um fluxo de trabalho pode executar, o modelo de Consumo mede e cobra uma operação com base em cada execução, se o fluxo de trabalho geral for executado com êxito, concluído ou até mesmo for 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 tenha suporte para e habilite agrupamento ou paginação para obter grandes quantidades de dados. Se agrupamento ou paginação estiver habilitado, uma execução de operação poderá precisar fazer várias chamadas.

O modelo de Consumo mede e cobra uma operação por execução, não por chamada. Por exemplo, suponha um que fluxo de trabalho inicie com um gatilho de sondagem que obtenha registros fazendo regularmente chamadas de saída para um ponto de extremidade. A chamada de saída será medida e cobrada como uma única execução, mesmo se o gatilho for acionado ou ignorado, como quando um gatilho verifica um ponto de extremidade, mas não encontra dados ou eventos. O estado do gatilho controla se a instância de fluxo de trabalho é criada e executada ou não. Agora, suponha que a operação também dê suporte a e tenha agrupamento ou paginação habilitado. Se a operação tiver que fazer 10 chamadas para concluir a obtenção de todos os dados, a operação ainda será medida e cobrada como uma única execução, apesar de fazer várias chamadas.

Observação

Por padrão, os gatilhos que retornam uma matriz têm uma configuração Split On já habilitada. Essa configuração resulta em um evento de gatilho, que você pode examinar no histórico de gatilhos e em 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 se aplica a todos os eventos de gatilho se o estado do gatilho for Bem-sucedido ou Ignorado. Os gatilhos ainda são faturáveis mesmo em cenários em que não instanciam e iniciam o fluxo de trabalho, mas o estado do gatilho é Bem-sucedido, Com 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 um fluxo de trabalho nos Aplicativos Lógicos do Azure multilocatário:

Tipo de operação Descrição Medição e cobrança
Interno Essas operações são executadas de forma direta e nativa com o runtime dos Aplicativos Lógicos do Azure. No designer, você pode encontrar essas operações no rótulo Interno.

Por exemplo, o gatilho HTTP e o gatilho Solicitação 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 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 de Ações.

Observação: algumas operações de conector gerenciado também estão disponíveis como operações internas, que estão incluídas nas operações gratuitas iniciais. Acima das operações inicialmente gratuitas, a cobrança segue o preço de Ações, não o preço do conector Standard ou Empresarial.
Conector gerenciado Essas operações são executadas separadamente no Azure. No designer, você pode encontrar essas operações no rótulo Standard ou Empresarial. Essas execuções de operação seguem os preços de conector Standard ou Empresarial.

Observação: as execuções de operação do conector Empresarial de pré-visualização seguem o preço do conectorConsumo Standard.
Conector personalizado Essas operações são executadas separadamente no Azure. No designer, você pode encontrar essas operações no rótulo Personalizado. Para limitar o número de conectores, a taxa de transferência e o tempo limite, examine Limites de conector personalizado nos Aplicativos Lógicos do Azure. Essas execuções de operação seguem os preços de conector Standard.

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, examine Outro comportamento de operação.

Dicas de estimativa de custo para o modelo de Consumo

Para ajudá-lo a estimar os custos de consumo mais precisos, analise estas dicas:

  • Considere o número possível de mensagens ou de eventos que podem chegar em qualquer dia, em vez de basear os cálculos somente no intervalo de sondagem.

  • Quando um evento ou mensagem atende aos critérios do gatilho, muitos disparadores imediatamente tentam ler todos os outros eventos ou mensagens em espera que atendam aos critérios. Esse comportamento significa que, mesmo quando você seleciona um intervalo de sondagem mais longo, o gatilho dispara com base no número de eventos ou mensagens em espera que qualificam-se para iniciar os 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, vamos supor 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 dispara e executa o fluxo de trabalho correspondente 15 vezes. Os servios dos Aplicativos Lógicos medem todas as ações que estes 15 fluxos de trabalho executam, incluindo as solicitações de gatilho.

Standard (único locatário)

Em Aplicativos Lógicos do Azure de único locatário, um aplicativo lógico e seu fluxo de trabalho seguem o plano Standard 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 (Standard) , ou usa a extensão Aplicativos Lógicos do Azure (Standard) no Visual Studio Code. Esse modelo de preços exige que os aplicativos lógicos usem um plano de hospedagem e um tipo de preço, que se diferem do plano de Consumo, pois 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 (Standard) e selecionar qualquer região do Azure para implantação, você também selecionará um plano de hospedagem de Fluxo de Trabalho Standard. No entanto, se você selecionar um recurso Ambiente do Serviço de Aplicativo v3 existente para o local de implantação, deverá selecionar um Plano do Serviço de Aplicativo.

Importante

A opção de hospedagem híbrida está atualmente em versão prévia. Para obter informações, confira Configurar sua própria infraestrutura para aplicativos lógicos Standard usando a implantação híbrida.

Os planos e recursos a seguir não estão mais disponíveis nem têm suporte com a versão pública dos fluxos de trabalho do aplicativo lógico Standard em Aplicativos Lógicos do Azure de locatário único: o plano Premium do Azure Functions, o Ambiente do Serviço de Aplicativo v1 e o Ambiente do Serviço de Aplicativo v2. O Plano do Serviço de Aplicativo está disponível e tem suporte apenas com o ASE v3 (Ambiente do Serviço de Aplicativo v3).

A tabela a seguir resume como o modelo Standard trata a medição e a cobrança dos seguintes componentes quando usado com um aplicativo lógico e um fluxo de trabalho no Aplicativos Lógicos do Azure de único locatário:

Componente Medição e cobrança
CPU virtual (vCPU) e memória O modelo Standard requer que o aplicativo lógico use o plano de hospedagem Fluxo de Trabalho Standard e um tipo de preço, 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 Tipos de preço no modelo Standard.
Operações de gatilho e ação O modelo Standard inclui um número ilimitado de operações internas gratuitas que o fluxo de trabalho pode executar.

Se o fluxo de trabalho usar qualquer operação de conector gerenciado, a medição se aplicará a cada chamada, enquanto a cobrança seguirá os mesmos preços de conector Standard ou Enterprise que o plano de Consumo. Para obter mais informações, examine Operações de gatilho e ação no modelo Standard.
Operações de armazenamento A medição se aplica a qualquer operação de armazenamento executada pelo Aplicativos Lógicos 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ções do fluxo de trabalho. O custo é baseado no tipo de preço escolhido. Para obter mais informações, confira 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, examine as Contas de integração.

Tipos de preço no modelo Standard

O tipo de preço que você escolhe para medição e cobrança do seu recurso Aplicativo Lógico (Standard) inclui quantidades específicas de computação em CPU virtual (vCPU) e recursos de 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 um tipo de preço de um Plano de Serviço V2 isolado, você será cobrado pelas instâncias usadas pelo Plano do Serviço de Aplicativo e pela execução dos fluxos de trabalho do seu aplicativo lógico. Nenhuma outra cobrança se aplica. Para obter mais informações, consulte Plano do Serviço de Aplicativo – Tipos de preço do Plano de Serviço V2 Isolado.

Se você selecionar um plano de hospedagem Fluxo de Trabalho Standard, poderá escolher entre os seguintes tipos de preço:

Tipo de preço vCPU (CPU virtual) Memória (GB)
WS1 1 3,5
WS2 2 7
WS3 4 14

Importante

O exemplo a seguir serve apenas para ilustração e fornece estimativas de exemplo para mostrar geralmente como um tipo de preço funciona. Para vCPU específico e preços de memória com base em regiões específicas em que o Aplicativos Lógicos do Azure está disponível, examine o plano Standard de uma região selecionada na página de preços do Aplicativos Lógicos do Azure.

Suponha que, em uma região de exemplo, os seguintes recursos tenham estas taxas por hora:

Recurso Taxa por hora (região de exemplo)
vCPU US$ 0,192 por vCPU
Memória US$ 0,0137 por GB

O cálculo a seguir fornece uma taxa mensal estimada:

<taxa mensal> = 730 horas (por mês) * [(<número de vCPUs> * <taxa por hora por vCPU>) + (<número de GB de memória> * <taxa por hora da memória em GB>)]

Com base nas informações anteriores, a tabela a seguir mostra a taxa mensal estimada para cada tipo de preço e os respectivos recursos nesse tipo de preço:

Tipo de preço vCPU (CPU virtual) Memória (GB) Taxa mensal (região de exemplo)
WS1 1 3,5 US$ 175,16
WS2 2 7 US$ 350,33
WS3 4 14 US$ 700,65

Operações de gatilho e ação no modelo Standard

Exceto para as operações internas ilimitadas gratuitas que um fluxo de trabalho pode executar, o modelo Standard mede e cobra uma operação com base em cada chamada, se o fluxo de trabalho geral for executado com êxito, concluído ou até mesmo for 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 tenha suporte para e habilite agrupamento ou paginação para obter grandes quantidades de dados. Se agrupamento ou paginação estiver habilitado, uma execução de operação poderá precisar fazer várias chamadas. O modelo Standard mede e cobra uma operação por chamada, não por execução.

Por exemplo, suponha um que fluxo de trabalho inicie com um gatilho de sondagem que obtenha registros fazendo regularmente chamadas de saída para um ponto de extremidade. A chamada de saída é medida e cobrada, independentemente se o gatilho for disparado ou ignorado. O estado do gatilho controla se a instância de fluxo de trabalho é criada e executada ou não. Agora, suponha que a operação também dê suporte a e tenha agrupamento ou paginação habilitado. Se a operação tiver que fazer 10 chamadas para concluir a obtenção de todos os dados, a operação será limitada e cobrada por chamada.

A tabela a seguir resume como o modelo Standard trata a medição e a cobrança dos seguintes tipos de operação quando usado com um aplicativo lógico e fluxo de trabalho no Aplicativos Lógicos do Azure de único locatário:

Tipo de operação Descrição Medição e cobrança
Interno Essas operações são executadas de forma direta e nativa com o runtime dos Aplicativos Lógicos do Azure. No designer, você pode encontrar essas operações na galeria de conectores em Runtime>No Aplicativo.

Por exemplo, o gatilho HTTP e o gatilho Solicitação 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 internas gratuitas ilimitadas.

Observação: algumas operações de conector gerenciadas também estão disponíveis como operações internas. Embora as operações internas sejam gratuitas, o modelo Standard ainda mede e cobra as operações do conector gerenciado usando o mesmo preço de conector Standard ou Empresarial que o 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>Compartilhado. O modelo Standard mede e cobra as operações do conector gerenciado com base no mesmo preço de conector Standard ou Empresarial que o modelo de Consumo.

Observação: as operações do conector Empresarial de pré-visualização seguem o preço de conector Consumo Standard.
Conector personalizado No momento, você pode criar e usar somente operações de conector internas personalizadas em fluxos de trabalho de aplicativo lógico baseados em único locatário. O modelo Standard inclui operações internas gratuitas ilimitadas. Para limitar o número de conectores, a taxa de transferência e o tempo limite, examine Limites de conector personalizado no 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 políticas de repetição, examine Outro comportamento de operação.

Outro comportamento de operação

A tabela a seguir resume como os modelos de Consumo e Standard lidam com operações executadas dentro de outras operações, como loops, e processam vários itens, como matrizes e políticas de repetição:

Operação Descrição Consumo Standard
Ações de loop Uma ação de loop, como loop Para cada ou Até, pode incluir outras ações executadas durante cada ciclo de loop. Exceto pelo número inicial de operações internas incluídas, a ação de loop e cada ação no loop são medidas sempre que o ciclo de loop é executado. Se uma ação processar qualquer item em uma coleção, como uma lista ou matriz, o número de itens também será usado no cálculo da medição.

Por exemplo, suponha que você tenha um loop Para cada com ações que processem uma lista. O serviço multiplica o número dos itens de lista em comparação com número de ações no loop e adiciona a ação que inicia o loop. Portanto,o cálculo para uma lista de 10 itens é (10 * 1) + 1, o que resulta em 11 execuções de ações.

O preços tem como base se os tipos de operação são internos, Standard ou Enterprise.

 Exceto para as operações internas incluídas, igual ao modelo de Consumo.
Políticas de repetição Em operações com suporte, você pode implementar tratamento básico de exceções e erros configurando uma política de repetição. Exceto pelo número inicial de operações internas, a execução original mais cada execução repetida são medidas. Por exemplo, uma ação executada com 5 repetições é medida e cobrada como 6 execuções.

O preços tem como base se os tipos de operação são internos, Standard ou Enterprise.

 Exceto para as operações internas incluídas, igual ao modelo de Consumo.

Operações de armazenamento

Aplicativos Lógicos do Azure usa o Armazenamento do Azure para qualquer transação de armazenamento necessária, como uso de filas para agendar operações de gatilho ou uso de 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 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 recurso do aplicativo lógico, não no nível do fluxo de trabalho.

A tabela a seguir resume como os modelos Consumo e Standard lidam com medição e cobrança para operações de armazenamento:

Modelo Descrição Medição e cobrança
Consumo (multilocatário) Recursos de armazenamento e o uso são anexados ao recurso de aplicativo lógico. A medição e a cobrança se aplicam somente ao consumo de armazenamento relacionado à retenção de dados e seguem o preço de retenção de dados para o plano de Consumo.
Standard (único locatário) Você pode usar sua própria conta de armazenamento do Azure, que oferece mais controle e flexibilidade sobre os dados do fluxo de trabalho. A medição e a cobrança seguem o modelo de preços do Armazenamento do Azure. Os custos de armazenamento aparecem separadamente em sua fatura de cobrança do Azure.

Dica: para ajudá-lo a entender melhor o número de operações de armazenamento que um fluxo de trabalho pode executar, bem como seu custo, usando 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. 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 as necessidades de armazenamento e os custos para fluxos de trabalho em Aplicativos Lógicos do Azure de locatário único.

Para mais informações, consulte a seguinte documentação:

Gateway de dados local

Um gateway de dados local é um recurso do Azure separado que você cria para que os fluxos de trabalho dos aplicativos lógicos possam acessar os 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 que são executadas por meio do gateway incorrem em encargos, com base no modelo de cobrança e preços usados pelo seu aplicativo lógico.

Contas de integração

Uma conta de integração é um recurso do Azure separado 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 essa conta ao seu aplicativo lógico para que você possa usar esses artefatos e várias operações B2B em fluxos de trabalho para explorar, compilar e testar soluções de integração que usam recursos de EDI e processamento XML.

A tabela a seguir resume como os modelos Consumo e Standard lidam com medição e cobrança de contas de integração:

Modelar Medição e cobrança
Consumo (multilocatário) A medição e a cobrança usam o preço da conta de integração, com base na camada de conta que você usa.
Standard (único locatário) A medição e a cobrança usam o preço da conta de integração, com base na camada de conta que você usa.

Para mais informações, consulte a seguinte documentação:

Outros itens não medidos ou cobrados

Dentre todos os modelos de preços, os seguintes itens não são medidos ou cobrados:

  • Ações que não são executadas porque o fluxo de trabalho parou antes da conclusão
  • Aplicativos lógicos ou fluxos de trabalho desativados, porque não podem criar novas instâncias enquanto estiverem desativados.

Próximas etapas