Användningsmätning, fakturering och priser för Azure Logic Apps
Gäller för: Azure Logic Apps (Förbrukning + Standard)
Med Azure Logic Apps kan du skapa och köra automatiserade integreringsarbetsflöden som kan skalas i molnet. Den här artikeln beskriver hur mätnings-, fakturerings- och prismodeller fungerar för Azure Logic Apps och relaterade resurser. Information om till exempel specifika priser, kostnadsplanering eller olika värdmiljöer finns i följande innehåll:
- Priser för Azure Logic Apps
- Planera och hantera kostnader för Azure Logic Apps
- En klientorganisation jämfört med flera klientorganisationer
Förbrukning (multitenant)
I Azure Logic Apps med flera klientorganisationer följer en logikapp och dess arbetsflöde förbrukningsplanen för prissättning och fakturering. Du skapar sådana logikappar på olika sätt, till exempel när du väljer resurstypen Logikapp (förbrukning), använder tillägget Azure Logic Apps (förbrukning) i Visual Studio Code eller när du skapar automatiseringsuppgifter.
I följande tabell sammanfattas hur förbrukningsmodellen hanterar mätning och fakturering för följande komponenter när den används med en logikapp och ett arbetsflöde i Azure Logic Apps med flera klientorganisationer:
| Komponent | Mätning och fakturering |
|---|---|
| Utlösar- och åtgärdsåtgärder | Förbrukningsmodellen innehåller ett inledande antal kostnadsfria inbyggda åtgärder per Azure-prenumeration som ett arbetsflöde kan köra. Över det här talet gäller mätningen för varje körning och faktureringen följer prissättningen Åtgärder för förbrukningsplanen. För andra åtgärdstyper, till exempel hanterade anslutningsappar, följer faktureringen standard- eller Enterprise-anslutningsprogrammets priser för förbrukningsplanen. Mer information finns i Utlösare och åtgärdsåtgärder i förbrukningsmodellen. |
| Lagringsåtgärder | Mätning gäller endast för datakvarhållningsrelaterad lagringsförbrukning, till exempel att spara indata och utdata från arbetsflödets körningshistorik. Faktureringen följer prissättningen för datakvarhållning för förbrukningsplanen. Mer information finns i Lagringsåtgärder. |
| Integrationskonton | Mätningen gäller baserat på den integrationskontotyp som du skapar och använder med logikappen. Faktureringen följer prissättningen för integrationskontot. Mer information finns i Integration-konton. |
Utlösar- och åtgärdsåtgärder i förbrukningsmodellen
Förutom det inledande antalet kostnadsfria inbyggda åtgärdskörningar per Azure-prenumeration, som ett arbetsflöde kan köra, mäter förbrukningsmodellen och fakturerar en åtgärd baserat på varje körning, oavsett om det övergripande arbetsflödet körs, slutförs eller till och med instansieras. En åtgärd utför vanligtvis en enda körning såvida inte åtgärden har återförsök aktiverats. I sin tur gör en körning vanligtvis ett enda anrop om inte åtgärden stöder och aktiverar segmentering eller sidnumrering för att hämta stora mängder data. Om segmentering eller sidnumrering är aktiverat kan en åtgärdskörning behöva göra flera anrop.
Förbrukningsmodellen mäter och fakturerar en åtgärd per körning, inte per anrop. Anta till exempel att ett arbetsflöde börjar med en avsökningsutlösare som hämtar poster genom att regelbundet göra utgående anrop till en slutpunkt. Det utgående anropet mäts och faktureras som en enda körning, oavsett om utlösaren utlöses eller hoppas över, till exempel när en utlösare kontrollerar en slutpunkt men inte hittar några data eller händelser. Utlösartillståndet styr om arbetsflödesinstansen skapas och körs. Anta nu att åtgärden också stöder och har aktiverat segmentering eller sidnumrering. Om åtgärden måste göra 10 anrop för att slutföra hämtar alla data, mäts åtgärden fortfarande och faktureras som en enda körning, trots att flera anrop görs.
Kommentar
Som standard har utlösare som returnerar en matris inställningen Dela på som redan är aktiverad. Den här inställningen resulterar i en utlösarhändelse som du kan granska i utlösarhistoriken och en arbetsflödesinstans för varje matrisobjekt. Alla arbetsflödesinstanser körs parallellt så att matrisobjekten bearbetas samtidigt. Faktureringen gäller för alla utlösarhändelser oavsett om utlösartillståndet är Lyckades eller Hoppades över. Utlösare kan fortfarande faktureras även i scenarier där utlösarna inte instansierar och startar arbetsflödet, men utlösartillståndet är Lyckades, Misslyckades eller Hoppades över.
I följande tabell sammanfattas hur förbrukningsmodellen hanterar mätning och fakturering för dessa åtgärdstyper när den används med en logikapp och ett arbetsflöde i Azure Logic Apps med flera klientorganisationer:
| Åtgärdstyp | beskrivning | Mätning och fakturering |
|---|---|---|
| Inbyggd | Dessa åtgärder körs direkt och internt med Azure Logic Apps-körningen. I designern hittar du de här åtgärderna under den inbyggda etiketten. HTTP-utlösaren och utlösaren Förfrågning är till exempel inbyggda utlösare. HTTP-åtgärden och svarsåtgärden är inbyggda åtgärder. Andra inbyggda åtgärder är arbetsflödeskontrollåtgärder som loopar och villkor, dataåtgärder, batchåtgärder och andra. |
Förbrukningsmodellen innehåller ett inledande antal kostnadsfria inbyggda åtgärder per Azure-prenumeration som ett arbetsflöde kan köra. Utöver det här antalet följer inbyggda åtgärdskörningar prissättningen Åtgärder. Obs! Vissa åtgärder för hanterade anslutningsappar är också tillgängliga som inbyggda åtgärder, som ingår i de första kostnadsfria åtgärderna. Utöver de initiala kostnadsfria åtgärderna följer faktureringen prissättningen Åtgärder, inte prissättningen för Standard- eller Enterprise-anslutningsappen. |
| Hanterad anslutningsapp | Dessa åtgärder körs separat i Azure. I designern hittar du dessa åtgärder under etiketten Standard eller Enterprise . | De här åtgärdskörningarna följer prissättningen för Standard- eller Enterprise-anslutningsappen. Obs! Körning av enterprise-anslutningsappar i förhandsversion följer prissättningen för förbrukningsstandardanslutningsappen. |
| Anpassad anslutningsapp | Dessa åtgärder körs separat i Azure. I designern hittar du de här åtgärderna under etiketten Anpassad . Begränsa antalet anslutningsappar, dataflöde och tidsgränser i Anpassade anslutningsappar i Azure Logic Apps. | Dessa åtgärdskörningar följer standardanslutningspriset. |
Mer information om hur förbrukningsmodellen fungerar med åtgärder som körs i andra åtgärder, till exempel loopar, bearbeta flera objekt, till exempel matriser och återförsöksprinciper, finns i Andra åtgärdsbeteenden.
Tips för kostnadsuppskattning för förbrukningsmodellen
Om du vill hjälpa dig att beräkna mer exakta förbrukningskostnader kan du läsa de här tipsen:
Tänk på det möjliga antalet meddelanden eller händelser som kan komma en viss dag, i stället för att basera dina beräkningar på endast avsökningsintervallet.
När en händelse eller ett meddelande uppfyller utlösarvillkoren försöker många utlösare omedelbart läsa andra väntande händelser eller meddelanden som uppfyller kriterierna. Det här beteendet innebär att även när du väljer ett längre avsökningsintervall utlöses utlösaren baserat på antalet väntande händelser eller meddelanden som kvalificerar sig för att starta arbetsflöden. Utlösare som följer det här beteendet inkluderar Azure Service Bus och Azure Event Hubs.
Anta till exempel att du konfigurerar utlösare som kontrollerar en slutpunkt varje dag. När utlösaren kontrollerar slutpunkten och hittar 15 händelser som uppfyller kriterierna utlöses utlösaren och kör motsvarande arbetsflöde 15 gånger. Logic Apps-tjänsten mäter alla åtgärder som dessa 15 arbetsflöden utför, inklusive utlösarbegäranden.
Standard (enskild klientorganisation)
I Azure Logic Apps med en enda klient följer en logikapp och dess arbetsflöden standardplanen för prissättning och fakturering. Du skapar sådana logikappar på olika sätt, till exempel när du väljer resurstypen Logikapp (Standard) eller använder Tillägget Azure Logic Apps (Standard) i Visual Studio Code. Den här prismodellen kräver att logikappar använder en värdplan och en prisnivå, som skiljer sig från förbrukningsplanen eftersom du debiteras för reserverad kapacitet och dedikerade resurser oavsett om du använder dem eller inte.
När du skapar eller distribuerar logikappar med resurstypen Logic App (Standard), och du väljer valfri Azure-region för distribution, väljer du även en arbetsflödesstandardvärdplan. Men om du väljer en befintlig App Service-miljön v3-resurs för distributionsplatsen måste du välja en App Service-plan.
Viktigt!
Följande planer och resurser är inte längre tillgängliga eller stöds inte längre med den offentliga versionen av Standard Logic App-arbetsflöden i Azure Logic Apps med en enda klient: Functions Premium-plan, App Service-miljön v1 och App Service-miljön v2. App Service-planen är tillgänglig och stöds endast med App Service-miljön v3 (ASE v3).
I följande tabell sammanfattas hur Standard-modellen hanterar mätning och fakturering för följande komponenter när den används med en logikapp och ett arbetsflöde i Azure Logic Apps med en enda klientorganisation:
| Komponent | Mätning och fakturering |
|---|---|
| Virtuell PROCESSOR (vCPU) och minne | Standardmodellen kräver att logikappen använder arbetsflödesstandardens värdplan och en prisnivå, som avgör vilka resursnivåer och priser som gäller för beräknings- och minneskapacitet. Mer information finns i Prisnivåer i standardmodellen. |
| Utlösar- och åtgärdsåtgärder | Standardmodellen innehåller ett obegränsat antal kostnadsfria inbyggda åtgärder som arbetsflödet kan köra. Om arbetsflödet använder några åtgärder för hanterade anslutningsappar gäller mätning för varje anrop, medan faktureringen följer samma standard- eller Enterprise-anslutningsprogram som förbrukningsplanen. Mer information finns i Utlösare och åtgärdsåtgärder i standardmodellen. |
| Lagringsåtgärder | Mätning gäller för alla lagringsåtgärder som körs av Azure Logic Apps. Lagringsåtgärder körs till exempel när tjänsten sparar indata och utdata från arbetsflödets körningshistorik. Faktureringen följer den valda prisnivån. Mer information finns i Lagringsåtgärder. |
| Integrationskonton | Om du skapar ett integrationskonto som logikappen ska använda baseras mätningen på den integrationskontotyp som du skapar. Faktureringen följer prissättningen för integrationskontot. Mer information finns i Integration-konton. |
Prisnivåer i standardmodellen
Den prisnivå som du väljer för mätning och fakturering för din Logic App-resurs (Standard) innehåller specifika mängder beräkning i virtuella processorresurser (vCPU) och minnesresurser. Om du väljer en App Service-miljön v3 som distributionsplats och en App Service-plan, särskilt prisnivån Isolerad V2-tjänstplan, debiteras du för de instanser som används av App Service-planen och för att köra dina logikapparbetsflöden. Inga andra avgifter tillkommer. Mer information finns i Prisnivåer för App Service-plan – isolerad V2-tjänstplan.
Om du väljer en Arbetsflödesstandard-värdplan kan du välja mellan följande nivåer:
| Prisnivå | Virtuell PROCESSOR (vCPU) | Minne (GB) |
|---|---|---|
| WS1 | 1 | 3.5 |
| WS2 | 2 | 7 |
| WS3 | 4 | 14 |
Viktigt!
Följande exempel är endast för illustration och innehåller exempeluppskattningar för att i allmänhet visa hur en prisnivå fungerar. Specifika priser för vCPU och minne baserat på specifika regioner där Azure Logic Apps är tillgängligt finns i Standard-planen för en vald region på prissättningssidan för Azure Logic Apps.
Anta att följande resurser har följande timpriser i en exempelregion:
| Resurs | Timtaxa (exempelregion) |
|---|---|
| vCPU | $0.192 per vCPU |
| Minne | 0,0137 USD per GB |
Följande beräkning ger en beräknad månadstakt:
<monthly-rate> = 730 timmar (per månad) * [(<number-vCPU> * <hourly-rate-vCPU>) + (<number-GB-memory> *< hourly-rate-GB-memory>)]
Baserat på föregående information visar följande tabell de uppskattade månatliga priserna för varje prisnivå och resurserna på den prisnivån:
| Prisnivå | Virtuell PROCESSOR (vCPU) | Minne (GB) | Månadskostnad (exempelregion) |
|---|---|---|---|
| WS1 | 1 | 3.5 | $175.16 |
| WS2 | 2 | 7 | $350.33 |
| WS3 | 4 | 14 | $700.65 |
Utlösar- och åtgärdsåtgärder i standardmodellen
Förutom de obegränsade kostnadsfria inbyggda åtgärder som ett arbetsflöde kan köra, mäter standardmodellen och fakturerar en åtgärd baserat på varje anrop, oavsett om det övergripande arbetsflödet körs, slutförs eller till och med instansieras. En åtgärd utför vanligtvis en enda körning såvida inte åtgärden har återförsök aktiverats. I sin tur gör en körning vanligtvis ett enda anrop om inte åtgärden stöder och aktiverar segmentering eller sidnumrering för att hämta stora mängder data. Om segmentering eller sidnumrering är aktiverat kan en åtgärdskörning behöva göra flera anrop. Standardmodellen mäter och fakturerar en åtgärd per anrop, inte per körning.
Anta till exempel att ett arbetsflöde börjar med en avsökningsutlösare som hämtar poster genom att regelbundet göra utgående anrop till en slutpunkt. Det utgående anropet mäts och faktureras, oavsett om utlösaren utlöses eller hoppas över. Utlösartillståndet styr om arbetsflödesinstansen skapas och körs. Anta nu att åtgärden också stöder och har aktiverat segmentering eller sidnumrering. Om åtgärden måste göra 10 anrop för att slutföra hämtar alla data, mäts åtgärden och faktureras per anrop.
I följande tabell sammanfattas hur Standard-modellen hanterar mätning och fakturering för åtgärdstyper när den används med en logikapp och ett arbetsflöde i Azure Logic Apps med en enda klientorganisation:
| Åtgärdstyp | beskrivning | Mätning och fakturering |
|---|---|---|
| Inbyggd | Dessa åtgärder körs direkt och internt med Azure Logic Apps-körningen. I designern hittar du de här åtgärderna i anslutningsgalleriet under Runtime>In-App. HTTP-utlösaren och utlösaren Förfrågning är till exempel inbyggda utlösare. HTTP-åtgärden och svarsåtgärden är inbyggda åtgärder. Andra inbyggda åtgärder är arbetsflödeskontrollåtgärder som loopar och villkor, dataåtgärder, batchåtgärder och andra. |
Standardmodellen innehåller obegränsade kostnadsfria inbyggda åtgärder. Obs! Vissa åtgärder för hanterade anslutningsappar är också tillgängliga som inbyggda åtgärder. Även om inbyggda åtgärder är kostnadsfria, mäter standardmodellen fortfarande och fakturerar hanterade anslutningsåtgärder med samma standard- eller Enterprise-anslutningsprogram som förbrukningsmodellen. |
| Hanterad anslutningsapp | Dessa åtgärder körs separat i delade globala Azure. I designern hittar du de här åtgärderna i anslutningsgalleriet under Körning>delad. | Standardmodellen mäter och fakturerar åtgärder för hanterade anslutningsappar baserat på samma standard- och Enterprise-anslutningsprogram som förbrukningsmodellen. Obs! Förhandsversion av enterprise connector-åtgärder följer prissättningen för förbrukningsstandardanslutningsappen. |
| Anpassad anslutningsapp | För närvarande kan du bara skapa och använda anpassade inbyggda anslutningsåtgärder i arbetsflöden för en klientbaserad logikapp. | Standardmodellen innehåller obegränsade kostnadsfria inbyggda åtgärder. Begränsningar för dataflöde och tidsgräns finns i Anpassade anslutningsgränser i Azure Logic Apps. |
Mer information om hur standardmodellen fungerar med åtgärder som körs i andra åtgärder, till exempel loopar, bearbeta flera objekt, till exempel matriser och försöka principer igen, finns i Andra åtgärdsbeteenden.
Annat åtgärdsbeteende
I följande tabell sammanfattas hur förbruknings- och standardmodellerna hanterar åtgärder som körs i andra åtgärder, till exempel loopar, bearbetar flera objekt, till exempel matriser och återförsöksprinciper:
| Operation | beskrivning | Förbrukning | Standard |
|---|---|---|---|
| Loopåtgärder | En loopåtgärd, till exempel För varje eller Till-loop , kan innehålla andra åtgärder som körs under varje loopcykel. | Förutom det inledande antalet inkluderade inbyggda åtgärder mäts loopåtgärden och varje åtgärd i loopen varje gång loopcykeln körs. Om en åtgärd bearbetar objekt i en samling, till exempel en lista eller matris, används även antalet objekt i mätningsberäkningen. Anta till exempel att du har en För varje loop med åtgärder som bearbetar en lista. Tjänsten multiplicerar antalet listobjekt mot antalet åtgärder i loopen och lägger till åtgärden som startar loopen. Beräkningen för en 10-objektslista är därför (10 * 1) + 1, vilket resulterar i 11 åtgärdskörningar. Prissättningen baseras på om åtgärdstyperna är inbyggda, Standard eller Enterprise. |
Förutom de inbyggda åtgärderna som ingår, samma som förbrukningsmodellen. |
| Återförsöksprinciper | Vid åtgärder som stöds kan du implementera grundläggande undantags- och felhantering genom att konfigurera en återförsöksprincip. | Förutom det inledande antalet inbyggda åtgärder mäts den ursprungliga körningen plus varje ny körning. En åtgärd som till exempel körs med 5 återförsök mäts och faktureras som 6 körningar. Prissättningen baseras på om åtgärdstyperna är inbyggda, Standard eller Enterprise. |
Förutom de inbyggda åtgärderna, samma som förbrukningsmodellen. |
Lagringsåtgärder
Azure Logic Apps använder Azure Storage för alla nödvändiga lagringstransaktioner, till exempel att använda köer för att schemalägga utlösaråtgärder eller använda tabeller och blobar för att lagra arbetsflödestillstånd. Beroende på åtgärderna i arbetsflödet varierar lagringskostnaderna eftersom olika utlösare, åtgärder och nyttolaster resulterar i olika lagringsåtgärder och behov. Tjänsten sparar och lagrar även indata och utdata från arbetsflödets körningshistorik, baserat på logikappresursens kvarhållningsgräns för körningshistorik. Du kan hantera den här kvarhållningsgränsen på logikappens resursnivå, inte på arbetsflödesnivå.
I följande tabell sammanfattas hur förbruknings- och standardmodellerna hanterar mätning och fakturering för lagringsåtgärder:
| Modell | beskrivning | Mätning och fakturering |
|---|---|---|
| Förbrukning (multitenant) | Lagringsresurser och användning är kopplade till logikappresursen. | Mätning och fakturering gäller endast för datakvarhållningsrelaterad lagringsförbrukning och följer prissättningen för datakvarhållning för förbrukningsplanen. |
| Standard (enskild klientorganisation) | Du kan använda ditt eget Azure Storage-konto, vilket ger dig mer kontroll och flexibilitet över arbetsflödets data. | Mätning och fakturering följer prismodellen för Azure Storage. Lagringskostnader visas separat på din Azure-faktureringsfaktura. Tips: Om du vill hjälpa dig att bättre förstå antalet lagringsåtgärder som ett arbetsflöde kan köra och deras kostnader kan du prova att använda Logic Apps Storage-kalkylatorn. Välj antingen ett exempelarbetsflöde eller använd en befintlig arbetsflödesdefinition. Den första beräkningen beräknar antalet lagringsåtgärder i arbetsflödet. Du kan sedan använda dessa siffror för att beräkna möjliga kostnader med hjälp av Priskalkylatorn för Azure. Mer information finns i Uppskatta lagringsbehov och kostnader för arbetsflöden i Azure Logic Apps med en enda klientorganisation. |
Mer information finns i följande dokumentation:
Lokal datagateway
Den lokala datagatewayen är en separat Azure-resurs som du skapar så att logikappens arbetsflöden kan komma åt lokala data med hjälp av specifika anslutningsappar som stöds av gatewayen. Själva gatewayresursen debiteras inte, men åtgärder som körs via gatewayen medför avgifter, baserat på den prissättnings- och faktureringsmodell som används av logikappen.
Integrationskonton
Ett integrationskonto är en separat Azure-resurs som du skapar som en container för att definiera och lagra artefakter från företag till företag (B2B), till exempel handelspartner, avtal, scheman, kartor och så vidare. När du har skapat det här kontot och definierat dessa artefakter länkar du det här kontot till logikappen så att du kan använda dessa artefakter och olika B2B-åtgärder i arbetsflöden för att utforska, skapa och testa integreringslösningar som använder EDI - och XML-bearbetningsfunktioner .
I följande tabell sammanfattas hur förbruknings- och standardmodellerna hanterar mätning och fakturering för integrationskonton:
| Modell | Mätning och fakturering |
|---|---|
| Förbrukning (multitenant) | Mätning och fakturering använder prissättningen för integrationskontot baserat på den kontonivå som du använder. |
| Standard (enskild klientorganisation) | Mätning och fakturering använder prissättningen för integrationskontot baserat på den kontonivå som du använder. |
Mer information finns i följande dokumentation:
Andra objekt som inte har mätats eller fakturerats
I alla prismodeller mäts eller faktureras inte följande objekt:
- Åtgärder som inte kördes eftersom arbetsflödet stoppades innan det slutfördes
- Inaktiverade logikappar eller arbetsflöden eftersom de inte kan skapa nya instanser när de är inaktiva.