Delen via


Gebruiksmeter, facturering en prijzen voor Azure Logic Apps

Van toepassing op: Azure Logic Apps (Verbruik + Standard)

Met Azure Logic Apps kunt u geautomatiseerde integratiewerkstromen maken en uitvoeren die in de cloud kunnen worden geschaald. In dit artikel wordt beschreven hoe meter-, facturerings- en prijsmodellen werken voor Azure Logic Apps en gerelateerde resources. Raadpleeg de volgende inhoud voor informatie zoals specifieke prijstarieven, kostenplanning of verschillende hostingomgevingen:

Verbruik (multitenant)

In multitenant Azure Logic Apps volgt een logische app en de bijbehorende werkstroom het verbruiksabonnement voor prijzen en facturering. U maakt dergelijke logische apps op verschillende manieren, bijvoorbeeld wanneer u het resourcetype logische app (verbruik) kiest, gebruikt u de Azure Logic Apps-extensie (Verbruik) in Visual Studio Code of wanneer u automatiseringstaken maakt.

De volgende tabel bevat een overzicht van de manier waarop het verbruiksmodel de meting en facturering voor de volgende onderdelen verwerkt wanneer deze worden gebruikt met een logische app en een werkstroom in Azure Logic Apps voor meerdere tenants:

Onderdeel Meting en facturering
Trigger- en actiebewerkingen Het verbruiksmodel bevat een eerste aantal gratis ingebouwde bewerkingen, per Azure-abonnement, die een werkstroom kan uitvoeren. Boven dit getal is meting van toepassing op elke uitvoering en facturering volgt u de actiesprijzen voor het verbruiksabonnement. Voor andere bewerkingstypen, zoals beheerde connectors, volgt facturering de prijzen van de Standard- of Enterprise-connector voor het verbruiksabonnement. Raadpleeg trigger- en actiebewerkingen in het verbruiksmodel voor meer informatie.
Opslagbewerkingen Meting is alleen van toepassing op opslagverbruik met betrekking tot gegevensretentie, zoals het opslaan van invoer en uitvoer van de uitvoeringsgeschiedenis van uw werkstroom. Facturering volgt de prijzen voor gegevensretentie voor het verbruiksabonnement. Raadpleeg opslagbewerkingen voor meer informatie.
Integratieaccounts Meting is van toepassing op basis van het integratieaccounttype dat u met uw logische app maakt en gebruikt. Facturering volgt de prijzen van het integratieaccount. Raadpleeg integratieaccounts voor meer informatie.

Trigger- en actiebewerkingen in het verbruiksmodel

Met uitzondering van het eerste aantal gratis ingebouwde bewerkingen, per Azure-abonnement, dat een werkstroom kan worden uitgevoerd, kunnen de verbruiksmodelmeters een bewerking factureren op basis van elke uitvoering, ongeacht of de algehele werkstroom met succes wordt uitgevoerd, voltooid of zelfs wordt geïnstantieerd. Een bewerking maakt meestal één uitvoering , tenzij voor de bewerking nieuwe pogingen zijn ingeschakeld. Op zijn beurt maakt een uitvoering meestal één aanroep , tenzij de bewerking ondersteuning biedt voor segmentering of paginering om grote hoeveelheden gegevens op te halen. Als segmentering of paginering is ingeschakeld, moet een bewerking mogelijk meerdere aanroepen uitvoeren.

De verbruiksmodelmeters en factureert een bewerking per uitvoering, niet per aanroep. Stel dat een werkstroom begint met een polling-trigger die records ophaalt door regelmatig uitgaande aanroepen naar een eindpunt te maken. De uitgaande aanroep wordt gefactureerd als één uitvoering, ongeacht of de trigger wordt geactiveerd of wordt overgeslagen, bijvoorbeeld wanneer een trigger een eindpunt controleert, maar geen gegevens of gebeurtenissen vindt. De status van de trigger bepaalt of het werkstroomexemplaren al dan niet worden gemaakt en uitgevoerd. Stel nu dat de bewerking ook ondersteuning biedt voor segmentering of paginering. Als de bewerking 10 aanroepen moet doen om alle gegevens te voltooien, wordt de bewerking nog steeds in rekening gebracht als één uitvoering, ondanks het maken van meerdere aanroepen.

Notitie

Triggers die een matrix retourneren, hebben standaard een instelling Splitsen op die al is ingeschakeld. Deze instelling resulteert in een trigger-gebeurtenis, die u kunt bekijken in de triggergeschiedenis en een werkstroomexemplaren voor elk matrixitem. Alle werkstroomexemplaren worden parallel uitgevoerd, zodat de matrixitems tegelijkertijd worden verwerkt. Facturering is van toepassing op alle triggergebeurtenissen, ongeacht of de triggerstatus is geslaagd of overgeslagen. Triggers zijn nog steeds factureerbaar, zelfs in scenario's waarin de triggers niet instantiëren en de werkstroom starten, maar de triggerstatus is Geslaagd, Mislukt of Overgeslagen.

De volgende tabel bevat een overzicht van de manier waarop het verbruiksmodel de meting en facturering voor deze bewerkingstypen verwerkt wanneer deze worden gebruikt met een logische app en werkstroom in multitenant Azure Logic Apps:

Het type bewerking Beschrijving Meting en facturering
Ingebouwd Deze bewerkingen worden rechtstreeks en systeemeigen uitgevoerd met de Azure Logic Apps-runtime. In de ontwerpfunctie vindt u deze bewerkingen onder het ingebouwde label.

De HTTP-trigger en aanvraagtrigger zijn bijvoorbeeld ingebouwde triggers. De HTTP-actie en antwoordactie zijn ingebouwde acties. Andere ingebouwde bewerkingen omvatten werkstroombeheeracties zoals lussen en voorwaarden, gegevensbewerkingen, batchbewerkingen en andere.

Het verbruiksmodel bevat een eerste aantal gratis ingebouwde bewerkingen, per Azure-abonnement, die een werkstroom kan uitvoeren. Boven dit aantal volgen ingebouwde bewerkingsuitvoeringen de prijzen van acties.

Opmerking: Sommige bewerkingen van een beheerde connector zijn ook beschikbaar als ingebouwde bewerkingen, die zijn opgenomen in de eerste gratis bewerkingen. Boven de eerste gratis bewerkingen volgt facturering de acties, niet de prijzen van de Standard- of Enterprise-connector.

Beheerde connector Deze bewerkingen worden afzonderlijk uitgevoerd in Azure. In de ontwerpfunctie vindt u deze bewerkingen onder het label Standard of Enterprise . Deze bewerkingen volgen de prijzen van de Standard- of Enterprise-connector.

Opmerking: uitvoeringen van preview enterprise-connectorbewerkingen volgen de prijzen van de Consumption Standard-connector.

Aangepaste connector Deze bewerkingen worden afzonderlijk uitgevoerd in Azure. In de ontwerpfunctie vindt u deze bewerkingen onder het aangepaste label. Raadpleeg aangepaste connectorlimieten in Azure Logic Apps voor limieten voor het aantal connectors, doorvoer en time-outs. Deze bewerkingen volgen de prijzen van de Standard-connector.

Voor meer informatie over hoe het verbruiksmodel werkt met bewerkingen die worden uitgevoerd in andere bewerkingen, zoals lussen, meerdere items zoals matrices verwerken en beleid voor opnieuw proberen, bekijkt u Ander bewerkingsgedrag.

Tips voor kostenramingen voor het verbruiksmodel

Bekijk de volgende tips om u te helpen nauwkeurigere verbruikskosten te schatten:

  • Houd rekening met het mogelijke aantal berichten of gebeurtenissen dat op een bepaalde dag kan binnenkomen, in plaats van uw berekeningen te baseren op alleen het polling-interval.

  • Wanneer een gebeurtenis of bericht voldoet aan de triggercriteria, proberen veel triggers onmiddellijk andere wachtende gebeurtenissen of berichten te lezen die voldoen aan de criteria. Dit gedrag houdt in dat ook als u een langere polling-interval selecteert, de trigger wordt geactiveerd op basis van het aantal gebeurtenissen in de wacht of berichten die in aanmerking komen voor het starten van werkstromen. Triggers die dit gedrag volgen, zijn Onder andere Azure Service Bus en Azure Event Hubs.

    Stel dat u een trigger instelt waarmee elke dag een eindpunt wordt gecontroleerd. Wanneer de trigger het eindpunt controleert en er vijftien gebeurtenissen vindt die aan de criteria voldoen, wordt de trigger geactiveerd en wordt de corresponderende werkstroom vijftien keer uitgevoerd. De Logic Apps-service meet alle acties die door deze 15 werkstromen worden uitgevoerd, inclusief de triggeraanvragen.

Standard (één tenant)

In Azure Logic Apps met één tenant volgen een logische app en de bijbehorende werkstromen het Standard-abonnement voor prijzen en facturering. U maakt dergelijke logische apps op verschillende manieren, bijvoorbeeld wanneer u het resourcetype logische app (Standard) kiest of de Azure Logic Apps-extensie (Standard) in Visual Studio Code gebruikt. Voor dit prijsmodel is vereist dat logische apps gebruikmaken van een hostingabonnement en een prijscategorie, die verschilt van het verbruiksabonnement waarin u wordt gefactureerd voor gereserveerde capaciteit en toegewezen resources, ongeacht of u deze gebruikt.

Wanneer u logische apps maakt of implementeert met het resourcetype Logische app (Standard) en u een Azure-regio selecteert voor implementatie, selecteert u ook een Workflow Standard-hostingplan. Als u echter een bestaande App Service Environment v3-resource voor uw implementatielocatie selecteert, moet u vervolgens een App Service-plan selecteren.

Belangrijk

De optie Hybride hosting is momenteel beschikbaar als preview-versie. Zie Uw eigen infrastructuur instellen voor Standaard logische apps met behulp van hybride implementatie.

De volgende plannen en resources zijn niet meer beschikbaar of worden ondersteund met de openbare release van standaardwerkstromen voor logische apps in Azure Logic Apps met één tenant: Functions Premium-plan, App Service Environment v1 en App Service Environment v2. Het App Service-plan is beschikbaar en wordt alleen ondersteund met App Service Environment v3 (ASE v3).

De volgende tabel bevat een overzicht van de manier waarop het Standard-model de meting en facturering voor de volgende onderdelen verwerkt wanneer het wordt gebruikt met een logische app en een werkstroom in Azure Logic Apps met één tenant:

Onderdeel Meting en facturering
Virtuele CPU (vCPU) en geheugen Het Standard-model vereist dat uw logische app gebruikmaakt van het Workflow Standard-hostingabonnement en een prijscategorie, die de resourceniveaus en prijstarieven bepaalt die van toepassing zijn op reken- en geheugencapaciteit. Raadpleeg de prijscategorieën in het Standard-model voor meer informatie.
Trigger- en actiebewerkingen Het Standard-model bevat een onbeperkt aantal gratis ingebouwde bewerkingen die door uw werkstroom kunnen worden uitgevoerd.

Als uw werkstroom gebruikmaakt van bewerkingen voor beheerde connectors, geldt voor elke aanroep meten, terwijl facturering dezelfde prijzen volgt als voor de Standard- of Enterprise-connector als voor het verbruiksabonnement. Raadpleeg trigger- en actiebewerkingen in het Standard-model voor meer informatie.

Opslagbewerkingen Meting is van toepassing op opslagbewerkingen die worden uitgevoerd door Azure Logic Apps. Opslagbewerkingen worden bijvoorbeeld uitgevoerd wanneer de service invoer en uitvoer opslaat uit de uitvoeringsgeschiedenis van uw werkstroom. Facturering volgt de gekozen prijscategorie. Raadpleeg opslagbewerkingen voor meer informatie.
Integratieaccounts Als u een integratieaccount maakt dat uw logische app kan gebruiken, is meting gebaseerd op het type integratieaccount dat u maakt. Facturering volgt de prijzen van het integratieaccount. Raadpleeg integratieaccounts voor meer informatie.

Prijscategorieën in het Standard-model

De prijscategorie die u kiest voor meting en facturering voor uw Logic App-resource (Standard) bevat specifieke hoeveelheden rekenkracht in virtuele CPU (vCPU) en geheugenresources. Als u een App Service Environment v3 selecteert als de implementatielocatie en een App Service-plan, met name een prijscategorie Isolated V2 Service Plan, worden er kosten in rekening gebracht voor de exemplaren die door het App Service-plan worden gebruikt en voor het uitvoeren van uw werkstromen voor logische apps. Er zijn geen andere kosten van toepassing. Zie De prijscategorieën App Service Plan - Isolated V2 Service Plan voor meer informatie.

Als u een Workflow Standard-hostingabonnement selecteert, kunt u kiezen uit de volgende lagen:

Prijscategorie Virtuele CPU (vCPU) Geheugen (GB)
WS1 1 3.5
WS2 2 7
WS3 4 14

Belangrijk

Het volgende voorbeeld is alleen ter illustratie en bevat voorbeeldschattingen om te laten zien hoe een prijscategorie werkt. Voor specifieke vCPU- en geheugenprijzen op basis van specifieke regio's waar Azure Logic Apps beschikbaar is, bekijkt u het Standard-plan voor een geselecteerde regio op de pagina met prijzen voor Azure Logic Apps.

Stel dat in een voorbeeldregio de volgende resources de volgende uurtarieven hebben:

Bron Uurtarief (voorbeeldregio)
vCPU $ 0,192 per vCPU
Geheugen $ 0,0137 per GB

De volgende berekening biedt een geschat maandelijks tarief:

<maandtarief = 730 uur (per maand) * [(<number-vCPU> * <hourly-rate-vCPU>) + (<number-GB-memory> * <hourly-rate-GB-memory>)]>

Op basis van de voorgaande informatie toont de volgende tabel de geschatte maandelijkse tarieven voor elke prijscategorie en de resources in die prijscategorie:

Prijscategorie Virtuele CPU (vCPU) Geheugen (GB) Maandelijks tarief (voorbeeldregio)
WS1 1 3.5 $ 175,16
WS2 2 7 $ 350,33
WS3 4 14 $ 700,65

Trigger- en actiebewerkingen in het Standaardmodel

Met uitzondering van de onbeperkte gratis ingebouwde bewerkingen die een werkstroom kan uitvoeren, worden de standaardmodelmeters gefactureerd op basis van elke aanroep, ongeacht of de algehele werkstroom wel of niet is uitgevoerd, voltooid of zelfs wordt geïnstantieerd. Een bewerking maakt meestal één uitvoering , tenzij voor de bewerking nieuwe pogingen zijn ingeschakeld. Op zijn beurt maakt een uitvoering meestal één aanroep , tenzij de bewerking ondersteuning biedt voor segmentering of paginering om grote hoeveelheden gegevens op te halen. Als segmentering of paginering is ingeschakeld, moet een bewerking mogelijk meerdere aanroepen uitvoeren. De standaardmodelmeters en factureert een bewerking per aanroep, niet per uitvoering.

Stel dat een werkstroom begint met een polling-trigger die records ophaalt door regelmatig uitgaande aanroepen naar een eindpunt te maken. De uitgaande oproep wordt gemeten en gefactureerd, ongeacht of de trigger wordt geactiveerd of wordt overgeslagen. De status van de trigger bepaalt of het werkstroomexemplaren al dan niet worden gemaakt en uitgevoerd. Stel nu dat de bewerking ook ondersteuning biedt voor segmentering of paginering. Als de bewerking 10 aanroepen moet doen om alle gegevens te voltooien, wordt de bewerking gemeten en gefactureerd per aanroep.

De volgende tabel bevat een overzicht van de manier waarop het Standard-model meten en facturering voor bewerkingstypen verwerkt wanneer deze worden gebruikt met een logische app en werkstroom in Azure Logic Apps met één tenant:

Het type bewerking Beschrijving Meting en facturering
Ingebouwd Deze bewerkingen worden rechtstreeks en systeemeigen uitgevoerd met de Azure Logic Apps-runtime. In de ontwerpfunctie vindt u deze bewerkingen in de connectorgalerie onder Runtime>In-App.

De HTTP-trigger en aanvraagtrigger zijn bijvoorbeeld ingebouwde triggers. De HTTP-actie en antwoordactie zijn ingebouwde acties. Andere ingebouwde bewerkingen omvatten werkstroombeheeracties zoals lussen en voorwaarden, gegevensbewerkingen, batchbewerkingen en andere.

Het Standard-model bevat onbeperkte gratis ingebouwde bewerkingen.

Opmerking: Sommige beheerde connectorbewerkingen zijn ook beschikbaar als ingebouwde bewerkingen. Hoewel ingebouwde bewerkingen gratis zijn, worden met het Standard-model nog steeds meters berekend en worden beheerde connectorbewerkingen gefactureerd met dezelfde standard- of Enterprise-connectorprijzen als het verbruiksmodel.

Beheerde connector Deze bewerkingen worden afzonderlijk uitgevoerd in gedeelde globale Azure. In de ontwerpfunctie vindt u deze bewerkingen in de connectorgalerie onder Runtime>Shared. De standaardmodelmeters en factureert beheerde connectorbewerkingen op basis van dezelfde standard- en Enterprise-connectorprijzen als het verbruiksmodel.

Opmerking: Preview Enterprise-connectorbewerkingen volgen de prijzen van de Consumption Standard-connector.
Aangepaste connector Op dit moment kunt u alleen aangepaste ingebouwde connectorbewerkingen maken en gebruiken in werkstromen voor logische apps met één tenant. Het Standard-model bevat onbeperkte gratis ingebouwde bewerkingen. Raadpleeg aangepaste connectorlimieten in Azure Logic Apps voor limieten voor doorvoer en time-outs.

Voor meer informatie over hoe het Standaardmodel werkt met bewerkingen die worden uitgevoerd binnen andere bewerkingen, zoals lussen, meerdere items zoals matrices verwerken en beleid voor opnieuw proberen, bekijkt u Ander bewerkingsgedrag.

Ander bewerkingsgedrag

De volgende tabel bevat een overzicht van de manier waarop de verbruiks- en standaardmodellen bewerkingen verwerken die worden uitgevoerd in andere bewerkingen, zoals lussen, meerdere items zoals matrices verwerken en beleid voor opnieuw proberen:

Operation Omschrijving Verbruik Standaard
Lusacties Een lusactie, zoals de lus For each of Until , kan andere acties bevatten die tijdens elke luscyclus worden uitgevoerd. Met uitzondering van het initiële aantal ingebouwde bewerkingen worden de lusactie en elke actie in de lus gemeten telkens wanneer de luscyclus wordt uitgevoerd. Als een actie items in een verzameling verwerkt, zoals een lijst of matrix, wordt het aantal items ook gebruikt in de berekening van de meting.

Stel dat u een voor elke lus hebt met acties die een lijst verwerken. De service vermenigvuldigt het aantal lijstitems met het aantal acties in de lus en voegt de actie toe waarmee de lus wordt gestart. De berekening voor een lijst met 10 items is dus (10 * 1) + 1, wat resulteert in 11 uitvoeringen van acties.

Prijzen zijn gebaseerd op de vraag of de bewerkingstypen zijn ingebouwd, Standard of Enterprise.

Met uitzondering van de ingebouwde bewerkingen, hetzelfde als het verbruiksmodel.
Beleid voor opnieuw proberen Bij ondersteunde bewerkingen kunt u eenvoudige uitzonderings- en foutafhandeling implementeren door een beleid voor opnieuw proberen in te stellen. Behalve het eerste aantal ingebouwde bewerkingen, wordt de oorspronkelijke uitvoering plus elke nieuwe uitvoering gemeten. Een actie die wordt uitgevoerd met 5 nieuwe pogingen, wordt bijvoorbeeld gemeten en gefactureerd als 6 uitvoeringen.

Prijzen zijn gebaseerd op de vraag of de bewerkingstypen zijn ingebouwd, Standard of Enterprise.

Met uitzondering van de ingebouwde opgenomen bewerkingen, hetzelfde als het verbruiksmodel.

Opslagbewerkingen

Azure Logic Apps maakt gebruik van Azure Storage voor vereiste opslagtransacties, zoals het gebruik van wachtrijen voor het plannen van triggerbewerkingen of het gebruik van tabellen en blobs voor het opslaan van werkstroomstatussen. Op basis van de bewerkingen in uw werkstroom variëren de opslagkosten omdat verschillende triggers, acties en nettoladingen leiden tot verschillende opslagbewerkingen en behoeften. De service slaat ook invoer en uitvoer op uit de uitvoeringsgeschiedenis van uw werkstroom, op basis van de bewaarlimiet voor de uitvoeringsgeschiedenis van de logische app-resource. U kunt deze bewaarlimiet beheren op resourceniveau van de logische app, niet op werkstroomniveau.

De volgende tabel bevat een overzicht van de manier waarop de verbruiks- en standaardmodellen de meting en facturering voor opslagbewerkingen verwerken:

Modelleren Beschrijving Meting en facturering
Verbruik (multitenant) Opslagresources en -gebruik worden gekoppeld aan de resource van de logische app. Meting en facturering zijn alleen van toepassing op gegevensretentiegerelateerd opslagverbruik en volgen de prijzen voor gegevensretentie voor het verbruiksabonnement.
Standard (één tenant) U kunt uw eigen Azure-opslagaccount gebruiken, waardoor u meer controle en flexibiliteit hebt over de gegevens van uw werkstroom. Meting en facturering volgen het prijsmodel van Azure Storage. Opslagkosten worden afzonderlijk weergegeven op uw Azure-factureringsfactuur.

Tip: Gebruik de Logic Apps Storage-calculator om meer inzicht te krijgen in het aantal opslagbewerkingen dat een werkstroom kan uitvoeren en de bijbehorende kosten. Selecteer een voorbeeldwerkstroom of gebruik een bestaande werkstroomdefinitie. In de eerste berekening wordt het aantal opslagbewerkingen in uw werkstroom geschat. U kunt deze getallen vervolgens gebruiken om mogelijke kosten te schatten met behulp van de Azure-prijscalculator. Raadpleeg voor meer informatie de opslagbehoeften en -kosten voor werkstromen in Azure Logic Apps met één tenant.

Raadpleeg de volgende documentatie voor meer informatie:

On-premises gegevensgateway

De on-premises gegevensgateway is een afzonderlijke Azure-resource die u maakt, zodat uw logische app-werkstromen toegang hebben tot on-premises gegevens met behulp van specifieke connectors die door gateways worden ondersteund. Voor de gatewayresource zelf worden geen kosten in rekening gebracht, maar voor bewerkingen die via de gateway worden uitgevoerd, worden er kosten in rekening gebracht op basis van de prijzen en het factureringsmodel dat door uw logische app wordt gebruikt.

Integratieaccounts

Een integratieaccount is een afzonderlijke Azure-resource die u maakt als een container voor het definiëren en opslaan van B2B-artefacten (business-to-business), zoals handelspartners, overeenkomsten, schema's, kaarten enzovoort. Nadat u dit account hebt gemaakt en deze artefacten hebt gedefinieerd, koppelt u dit account aan uw logische app, zodat u deze artefacten en verschillende B2B-bewerkingen in werkstromen kunt gebruiken om integratieoplossingen te verkennen, te bouwen en te testen die gebruikmaken van EDI- en XML-verwerkingsmogelijkheden.

De volgende tabel bevat een overzicht van de manier waarop de verbruiks- en standard-modellen meting en facturering voor integratieaccounts omgaan:

Modelleren Meting en facturering
Verbruik (multitenant) Meten en facturering gebruiken de prijzen van het integratieaccount, op basis van de accountlaag die u gebruikt.
Standard (één tenant) Meten en facturering gebruiken de prijzen van het integratieaccount, op basis van de accountlaag die u gebruikt.

Raadpleeg de volgende documentatie voor meer informatie:

Andere items niet naar gebruik of gefactureerd

In alle prijsmodellen worden de volgende items niet in rekening gebracht of gefactureerd:

  • Acties die niet zijn uitgevoerd omdat de werkstroom vóór voltooiing is gestopt
  • Logische apps of werkstromen zijn uitgeschakeld omdat ze geen nieuwe exemplaren kunnen maken terwijl ze inactief zijn.

Volgende stappen