Misurazione dell'utilizzo, fatturazione e prezzi per App per la logica di Azure
Si applica a: App per la logica di Azure (a consumo e standard)
App per la logica di Azure facilita la creazione ed esecuzione di flussi di lavoro di integrazione automatizzati scalabili nel cloud. Questo articolo descrive come funzionano i modelli di misurazione, fatturazione e tariffari per App per la logica di Azure e le risorse correlate. Per informazioni quali tariffe specifiche, pianificazione dei costi o ambienti di hosting diversi, vedere il contenuto seguente:
- Tariffe dei prezzi per App per la logica di Azure
- Pianificare e gestire i costi per App per la logica di Azure
- Single-tenant e multi-tenant
A consumo (multi-tenant)
In App per la logica di Azure multi-tenant, un'app per la logica e il relativo flusso di lavoro seguono il piano A consumo per i prezzi e la fatturazione. Queste app per la logica vengono create in vari modi, ad esempio quando si sceglie il tipo di risorsa App per la logica (A consumo), usare l'estensione App per la logica di Azure (A consumo) in Visual Studio Code o quando si creano attività di automazione.
La tabella seguente riepiloga il modo in cui il modello A consumo gestisce la misurazione e la fatturazione per i componenti seguenti quando vengono usati con un'app per la logica e un flusso di lavoro in App per la logica di Azure multi-tenant:
Componente | Misurazione e fatturazione |
---|---|
Operazioni di attivazione e azione | Il modello A consumo include un numero iniziale di operazioni predefinite gratuite, per sottoscrizione di Azure, che un flusso di lavoro può essere eseguito. Al di sopra di questo numero, la misurazione si applica a ogni esecuzione e la fatturazione segue i prezzi delle Azioni per il piano A consumo. Per altri tipi di operazione, ad esempio i connettori gestiti, la fatturazione segue i prezzi dei connettori Standard o Enterprise per il piano A consumo. Per altre informazioni, vedere Operazioni di attivazione e azione nel modello A consumo. |
Operazioni di archiviazione | La misurazione si applica solo al consumo di archiviazione correlato alla conservazione dei dati, ad esempio il salvataggio di input e output dalla cronologia di esecuzione del flusso di lavoro. La fatturazione segue i prezzi di conservazione dei dati per il piano A consumo. Per altre informazioni, vedere Operazioni di archiviazione. |
Account di integrazione | La misurazione si applica in base al tipo di account di integrazione creato e usato con l'app per la logica. La fatturazione segue i prezzi dell'account di integrazione. Per altre informazioni, vedere Account di integrazione. |
Operazioni di attivazione e azione nel modello A consumo
Ad eccezione del numero iniziale di esecuzioni di operazioni predefinite gratuite, per sottoscrizione di Azure, che un flusso di lavoro può essere eseguito, il contatore del modello A consumo e fattura un'operazione in base a ogni esecuzione, indipendentemente dal fatto che il flusso di lavoro complessivo venga eseguito correttamente, venga completato o anche creato un'istanza. Un'operazione in genere esegue una singola esecuzione a meno che l'operazione non disponga di tentativi abilitati. A sua volta, un'esecuzione esegue in genere una singola chiamata a meno che l'operazione non supporti e non consenta la suddivisione in blocchi o l'impaginazione per ottenere grandi quantità di dati. Se la suddivisione in blocchi o l'impaginazione è abilitata, potrebbe essere necessario eseguire più chiamate.
Il contatore del modello A consumo e fattura un'operazione per esecuzione, non per chiamata. Si supponga, ad esempio, che un flusso di lavoro inizi con un trigger di polling che ottiene i record effettuando regolarmente chiamate in uscita a un endpoint. La chiamata in uscita viene misurata e fatturata come singola esecuzione, indipendentemente dal fatto che il trigger venga attivato o ignorato, ad esempio quando un trigger controlla un endpoint ma non trova dati o eventi. Lo stato del trigger controlla se l'istanza del flusso di lavoro viene creata o meno ed eseguita. Si supponga ora che l'operazione supporti anche la suddivisione in blocchi o l'impaginazione e l'abbia abilitata. Se l'operazione deve effettuare 10 chiamate per completare l'acquisizione di tutti i dati, l'operazione viene ancora misurata e fatturata come singola esecuzione, nonostante l'esecuzione di più chiamate.
Nota
Per impostazione predefinita, i trigger che restituiscono una matrice hanno un'impostazione Dividi al già abilitata. Questa impostazione genera un evento trigger, che è possibile esaminare nella cronologia dei trigger e un'istanza del flusso di lavoro per ogni elemento dell'array. Tutte le istanze del flusso di lavoro vengono eseguite in parallelo in modo che gli elementi della matrice vengano elaborati contemporaneamente. La fatturazione si applica a tutti gli eventi di trigger se lo stato del trigger è Operazione completata o Operazione ignorata. I trigger sono ancora fatturabili anche negli scenari in cui i trigger non creano un'istanza e avviano il flusso di lavoro, ma lo stato del trigger è Operazione completata, Operazione non riuscitao Operazione ignorata.
La tabella seguente riepiloga il modo in cui il modello A consumo gestisce la misurazione e la fatturazione per questi tipi di operazione quando vengono usati con un'app per la logica e un flusso di lavoro in App per la logica di Azure multi-tenant:
Tipo di operazione | Descrizione | Misurazione e fatturazione |
---|---|---|
Predefinito | Queste operazioni vengono eseguite direttamente e in modo nativo con il runtime di App per la logica di Azure. Nella finestra di progettazione è possibile trovare queste operazioni sotto l'etichetta Predefinita. Ad esempio, il trigger HTTP e il trigger Richiedi sono trigger predefiniti. L'azione HTTP e quella Risposta sono azioni predefinite. Altre operazioni predefinite includono azioni di controllo del flusso di lavoro, ad esempio cicli e condizioni, operazioni di dati, operazioni batch e altre. |
Il modello A consumo include un numero iniziale di operazioni predefinite gratuite, per sottoscrizione di Azure, che un flusso di lavoro può essere eseguito. Al di sopra di questo numero, le esecuzioni di operazioni predefinite seguono i prezzi delle Azioni. Nota: alcune operazioni del connettore gestito sono disponibili anche come operazioni predefinite, incluse nelle operazioni gratuite iniziali. Sopra le operazioni inizialmente gratuite, la fatturazione segue i prezzi delle Azioni, non i prezzi dei connettori Standard o Enterprise. |
Connettore gestito | Queste operazioni vengono eseguite separatamente in Azure. Nella finestra di progettazione è possibile trovare queste operazioni sotto l'etichetta Standard o Enterprise. | Queste esecuzioni di operazioni seguono i prezzi dei connettori Standard o Enterprise. Nota: le esecuzioni delle operazioni del connettore Enterprise di anteprima seguono i prezzi del connettore A consumo Standard. |
Connettore personalizzato | Queste operazioni vengono eseguite separatamente in Azure. Nella finestra di progettazione è possibile trovare queste operazioni sotto l'etichetta Personalizzata. Per limitare il numero di connettori, velocità effettiva e timeout, vedere Limiti dei connettori personalizzati in App per la logica di Azure. | Queste esecuzioni di operazioni seguono i prezzi del connettore Standard. |
Per altre informazioni sul funzionamento del modello A consumo con operazioni eseguite all'interno di altre operazioni, ad esempio cicli, elaborare più elementi, ad esempio matrici e criteri di ripetizione dei tentativi, vedere Altro comportamento dell'operazione.
Suggerimenti per la stima dei costi per il modello A consumo
Per aiutarti a stimare i costi di consumo più accurati, consulta questi suggerimenti:
Prendere in considerazione il numero di messaggi o eventi che potrebbero arrivare ogni giorno, invece di basare i calcoli solo sull'intervallo di polling.
Quando un evento o un messaggio soddisfa i criteri di trigger, molti trigger provano immediatamente a leggere gli eventuali altri eventi in attesa o i messaggi che soddisfano i criteri. Questo comportamento significa che anche quando si seleziona un intervallo di polling più lungo, il trigger viene attivato in base al numero di eventi in attesa o di messaggi che soddisfano le condizioni per l'avvio dei flussi di lavoro. I trigger che seguono questo comportamento includono il Bus di servizio di Azure e l'hub eventi di Azure.
Si supponga, ad esempio, di configurare un trigger che controlla un endpoint ogni giorno. Quando il trigger controlla l'endpoint e trova 15 eventi che soddisfano i criteri, il trigger viene attivato ed esegue il flusso di lavoro corrispondente 15 volte. Il servizio App per la logica conteggia tutte le azioni eseguite da questi 15 flussi di lavoro, incluse le richieste del trigger.
Standard (tenant singolo)
In App per la logica di Azure a tenant singolo, un'app per la logica e i relativi flussi di lavoro seguono il piano Standard per i prezzi e la fatturazione. Queste app per la logica vengono create in vari modi, ad esempio quando si sceglie il tipo di risorsa App per la logica (Standard) o si usa l'estensione App per la logica di Azure (Standard) in Visual Studio Code. Questo modello di determinazione prezzi richiede che le app per la logica usino un piano di hosting e un piano tariffario, che differiscono dal piano A consumo in quanto vengono fatturate per la capacità riservata e le risorse dedicate indipendentemente dal fatto che vengano usate o meno.
Quando si creano o distribuiscono app per la logica con il tipo di risorsa App per la logica (Standard) e si seleziona un'area di Azure per la distribuzione, si selezionerà anche un piano di hosting Standard del flusso di lavoro. Tuttavia, se si seleziona una risorsa esistente dell'Ambiente del servizio app v3 per il percorso di distribuzione, è necessario selezionare un Piano di servizio app.
Importante
L'opzione di hosting ibrido è attualmente in anteprima. Per informazioni, vedere Configurare un'infrastruttura personalizzata per le app per la logica Standard usando la distribuzione ibrida.
I piani e le risorse seguenti non sono più disponibili o supportati con la versione pubblica dei flussi di lavoro delle App per la logica Standard in App per la logica di Azure a tenant singolo: piano Funzioni Premium, Ambiente del servizio app v1 e Ambiente del servizio app v2. Il piano di servizio app è disponibile e supportato solo con l'ambiente del servizio app v3 (ASE v3).
La tabella seguente riepiloga il modo in cui il modello Standard gestisce la misurazione e la fatturazione per i componenti seguenti quando vengono usati con un'app per la logica e un flusso di lavoro in App per la logica di Azure a tenant singolo:
Componente | Misurazione e fatturazione |
---|---|
CPU virtuale (vCPU) e memoria | Il modello Standard richiede che l'app per la logica usi il piano di hosting e un piano tariffario Standard flusso di lavoro, che determina i livelli di risorse e le tariffe dei prezzi applicabili alla capacità di calcolo e memoria. Per altre informazioni, vedere Piani tariffari nel modello Standard. |
Operazioni di attivazione e azione | Il modello Standard include un numero illimitato di operazioni predefinite gratuite che il flusso di lavoro può eseguire. Se il flusso di lavoro usa qualsiasi operazione del connettore gestito, la misurazione si applica a ogni chiamata, mentre la fatturazione segue gli stessi prezzi dei connettori Standard o Enterprise del piano A consumo. Per altre informazioni, vedere Operazioni di attivazione e azione nel modello Standard. |
Operazioni di archiviazione | La misurazione si applica a qualsiasi operazione di archiviazione eseguita da App per la logica di Azure. Ad esempio, le operazioni di archiviazione vengono eseguite quando il servizio salva input e output dalla cronologia di esecuzione del flusso di lavoro. La fatturazione segue il piano tariffario scelto. Per altre informazioni, vedere Operazioni di archiviazione. |
Account di integrazione | Se si crea un account di integrazione per l'app per la logica da usare, la misurazione si basa sul tipo di account di integrazione creato. La fatturazione segue i prezzi dell'account di integrazione. Per altre informazioni, vedere Account di integrazione. |
Piani tariffari nel modello Standard
Il piano tariffario scelto per la misurazione e la fatturazione per la risorsa App per la logica (Standard) include quantità specifiche di calcolo nelle risorse di CPU virtuale (vCPU) e memoria. Se si seleziona un ambiente del servizio app v3 come percorso di distribuzione e un piano di servizio app, in particolare un piano tariffario piano di servizio Isolated V2, vengono addebitati i costi per le istanze usate dal piano di servizio app e per l'esecuzione dei flussi di lavoro dell'app per la logica. Non si applicano altri addebiti. Per altre informazioni, vedere Piano di servizio app - piani tariffari del Piano di servizio V2 isolato.
Se si seleziona un piano di hosting Standard flusso di lavoro, è possibile scegliere tra i livelli seguenti:
Piano tariffario | CPU virtuale (vCPU) | Memoria (GB) |
---|---|---|
WS1 | 1 | 3.5 |
WS2 | 2 | 7 |
WS3 | 4 | 14 |
Importante
L'esempio seguente è solo per l'illustrazione e fornisce stime di esempio per mostrare in genere il funzionamento di un piano tariffario. Per prezzi specifici di vCPU e memoria in base a aree specifiche in cui è disponibile App per la logica di Azure, esaminare il piano Standard per un'area selezionata nella paginadei prezzi di App per la logica di Azure.
Si supponga che in un'area di esempio le risorse seguenti abbiano queste tariffe orarie:
Conto risorse | Frequenza oraria (area di esempio) |
---|---|
vCPU | 0.192 per vCPU |
Memory | 0,0137 USD per GB |
Il calcolo seguente fornisce una tariffa mensile stimata:
<tariffa mensile> = 730 ore (al mese) * [(<numero-vCPU> * <tariffa-oraria-vCPU >) + (<numero-GB-memoria> * <tariffa-oraria-GB-memoria>)]
In base alle informazioni precedenti, la tabella seguente mostra le tariffe mensili stimate per ogni piano tariffario e le risorse nel piano tariffario:
Piano tariffario | CPU virtuale (vCPU) | Memoria (GB) | Tariffa mensile (area di esempio) |
---|---|---|---|
WS1 | 1 | 3.5 | $175.16 |
WS2 | 2 | 7 | $350.33 |
WS3 | 4 | 14 | $700.65 |
Operazioni di attivazione e azione nel modello Standard
Ad eccezione delle operazioni predefinite gratuite illimitate che un flusso di lavoro può essere eseguito, il contatore del modello Standard e fattura un'operazione in base a ogni chiamata, indipendentemente dal fatto che il flusso di lavoro complessivo venga eseguito correttamente, venga completato o anche creato un'istanza. Un'operazione in genere esegue una singola esecuzione a meno che l'operazione non disponga di tentativi abilitati. A sua volta, un'esecuzione esegue in genere una singola chiamata a meno che l'operazione non supporti e non consenta la suddivisione in blocchi o l'impaginazione per ottenere grandi quantità di dati. Se la suddivisione in blocchi o l'impaginazione è abilitata, potrebbe essere necessario eseguire più chiamate. Il modello Standard contatore e fattura un'operazione per chiamata, non per esecuzione.
Si supponga, ad esempio, che un flusso di lavoro inizi con un trigger di polling che ottiene i record effettuando regolarmente chiamate in uscita a un endpoint. La chiamata in uscita viene misurata e fatturata, indipendentemente dal fatto che il trigger venga attivato o ignorato. Lo stato del trigger controlla se l'istanza del flusso di lavoro viene creata o meno ed eseguita. Si supponga ora che l'operazione supporti anche la suddivisione in blocchi o l'impaginazione e l'abbia abilitata. Se l'operazione deve effettuare 10 chiamate per completare l'acquisizione di tutti i dati, l'operazione viene misurata e fatturata per chiamata.
La tabella seguente riepiloga il modo in cui il modello Standard gestisce la misurazione e la fatturazione per i tipi di operazione quando vengono usati con un'app per la logica e un flusso di lavoro in App per la logica di Azure a tenant singolo:
Tipo di operazione | Descrizione | Misurazione e fatturazione |
---|---|---|
Predefinito | Queste operazioni vengono eseguite direttamente e in modo nativo con il runtime di App per la logica di Azure. Nella finestra di progettazione è possibile trovare queste operazioni nella raccolta connettori in Runtime>In-App. Ad esempio, il trigger HTTP e il trigger Richiedi sono trigger predefiniti. L'azione HTTP e quella Risposta sono azioni predefinite. Altre operazioni predefinite includono azioni di controllo del flusso di lavoro, ad esempio cicli e condizioni, operazioni di dati, operazioni batch e altre. |
Il modello Standard include operazioni predefinite gratuite illimitate. Nota: alcune operazioni del connettore gestito sono disponibili anche come operazioni predefinite. Anche se le operazioni predefinite sono gratuite, il modello Standard continua a contatore e fattura le operazioni del connettore gestito usando lo stesso prezzo del connettore Standard o Enterprise del modello A consumo. |
Connettore gestito | Queste operazioni vengono eseguite separatamente in Azure globale condiviso. Nella finestra di progettazione è possibile trovare queste operazioni nella raccolta connettori in Runtime>Condiviso. | I contatori del modello Standard e fatturano le operazioni del connettore gestito in base allo stesso prezzo del connettore Standard ed Enterprise del modello A consumo. Nota: le operazioni del connettore Enterprise di anteprima seguono i prezzi del connettore Standard A consumo. |
Connettore personalizzato | Attualmente, è possibile creare e usare solo operazioni del connettore predefinito personalizzato nei flussi di lavoro dell'app per la logica basata su tenant singolo. | Il modello Standard include operazioni predefinite gratuite illimitate. Per i limiti relativi alla velocità effettiva e al timeout, vedere Limiti del connettore personalizzato in App per la logica di Azure. |
Per altre informazioni sul funzionamento del modello Standard con operazioni eseguite all'interno di altre operazioni, ad esempio cicli, elaborare più elementi, ad esempio matrici e criteri di ripetizione dei tentativi, vedere Altro comportamento dell'operazione.
Altro comportamento dell'operazione
Nella tabella seguente viene riepilogato il modo in cui i modelli A consumo e Standard gestiscono le operazioni eseguite all'interno di altre operazioni, ad esempio cicli, elaborano più elementi, ad esempio matrici e criteri di ripetizione dei tentativi:
Operazione | Descrizione | Consumo | Standard |
---|---|---|---|
Azioni ciclo | Un'azione ciclo, ad esempio ciclo Per ogni o Fino a, può includere altre azioni eseguite durante ogni ciclo. | Ad eccezione del numero iniziale di operazioni predefinite incluse, l'azione ciclo e ogni azione nel ciclo vengono misurate ogni volta che viene eseguito il ciclo del ciclo. Se un'azione elabora elementi in una raccolta, ad esempio un elenco o una matrice, viene utilizzato anche il numero di elementi nel calcolo della misurazione. Si supponga, ad esempio, di avere un ciclo Per ogni con azioni che elaborano un elenco. Il servizio moltiplica il numero di elementi dell'elenco rispetto al numero di azioni nel ciclo e aggiunge l'azione che avvia il ciclo. Pertanto, il calcolo per un elenco di 10 voci è (10 * 1) + 1, da cui risultano 11 esecuzioni di azioni. I prezzi si basano sul fatto che i tipi di operazione siano incorporati, Standard o Enterprise. |
Ad eccezione delle operazioni predefinite incluse, come il modello A consumo. |
Criteri di ripetizione dei tentativi | Nelle operazioni supportate è possibile implementare la gestione delle eccezioni e degli errori di base configurando un criterio di ripetizione. | Ad eccezione del numero iniziale di operazioni predefinite, l'esecuzione originale più ogni esecuzione ritentata viene misurata. Ad esempio, un'azione eseguita con 5 tentativi viene misurata e fatturata come 6 esecuzioni. I prezzi si basano sul fatto che i tipi di operazione siano incorporati, Standard o Enterprise. |
Ad eccezione delle operazioni incluse predefinite, come il modello A consumo. |
Operazioni di archiviazione
App per la logica di Azure usa Archiviazione di Azure per tutte le transazioni di archiviazione necessarie, ad esempio l'uso di code per la pianificazione delle operazioni di trigger o l'uso di tabelle e BLOB per l'archiviazione degli stati del flusso di lavoro. In base alle operazioni nel flusso di lavoro, i costi di archiviazione variano perché trigger, azioni e payload diversi comportano diverse operazioni e esigenze di archiviazione. Il servizio salva e archivia anche input e output dalla cronologia di esecuzione del flusso di lavoro, in base al limite di conservazione della cronologia di esecuzione della risorsa dell'app per la logica. È possibile gestire questo limite di conservazione a livello di risorsa dell'app per la logica, non a livello di flusso di lavoro.
La tabella seguente riepiloga il modo in cui i modelli A consumo e Standard gestiscono la misurazione e la fatturazione per le operazioni di archiviazione:
Modello | Descrizione | Misurazione e fatturazione |
---|---|---|
A consumo (multi-tenant) | Le risorse di archiviazione e l'utilizzo vengono collegati alla risorsa dell'app per la logica. | La misurazione e la fatturazione si applicano solo al consumo di archiviazione correlato alla conservazione dei dati e seguono i prezzi di conservazione dei dati per il piano A consumo. |
Standard (tenant singolo) | È possibile usare il proprio account di archiviazione di Azure, che offre maggiore controllo e flessibilità sui dati del flusso di lavoro. | La misurazione e la fatturazione seguono il modello tariffario di Archiviazione di Azure. I costi di archiviazione vengono visualizzati separatamente nella fattura di fatturazione di Azure. Suggerimento: per comprendere meglio il numero di operazioni di archiviazione che un flusso di lavoro potrebbe eseguire e i relativi costi, provare a usare il calcolatore dell'archiviazione dell'app per la logica. Selezionare un flusso di lavoro di esempio o usare una definizione del flusso di lavoro esistente. Il primo calcolo stima il numero di operazioni di archiviazione nel flusso di lavoro. È quindi possibile usare questi numeri per stimare i costi possibili usando il calcolatore prezzi di Azure. Per altre informazioni, vedere Stimare le esigenze e i costi di archiviazione per i flussi di lavoro in App per la logica di Azure a tenant singolo. |
Per altre informazioni, vedere la documentazione seguente:
- Visualizzare le metriche per le esecuzioni e l'utilizzo dell'archiviazione
- Limiti nelle app per la logica di Azure
Gateway dati locale
Il gateway dati locale è una risorsa di Azure separata creata in modo che i flussi di lavoro dell'app per la logica possano accedere ai dati locali usando connettori specifici supportati dal gateway. La risorsa gateway stessa non comporta addebiti, ma le operazioni eseguite tramite il gateway comportano addebiti, in base al modello di determinazione prezzi e fatturazione usato dall'app per la logica.
Account di integrazione
Un account di integrazione è una risorsa di Azure separata creata come contenitore per definire e archiviare elementi business-to-business (B2B), ad esempio partner commerciali, accordi, schemi, mappe e così via. Dopo aver creato questo account e definito questi artefatti, collegare questo account all'app per la logica in modo che sia possibile usare questi artefatti e varie operazioni B2B nei flussi di lavoro per esplorare, compilare e testare soluzioni di integrazione che usano funzionalità di elaborazione EDI e XML.
La tabella seguente riepiloga il modo in cui i modelli A consumo e Standard gestiscono la misurazione e la fatturazione per gli account di integrazione:
Modello | Misurazione e fatturazione |
---|---|
A consumo (multi-tenant) | La misurazione e la fatturazione usano i prezzi dell'account di integrazione, in base al livello di account usato. |
Standard (tenant singolo) | La misurazione e la fatturazione usano i prezzi dell'account di integrazione, in base al livello di account usato. |
Per altre informazioni, vedere la documentazione seguente:
- Creare e gestire account di integrazione
- Limiti degli account di integrazione in App per la logica di Azure
Altre voci non misurate o fatturate
In tutti i modelli tariffari, gli elementi seguenti non vengono misurati o fatturati:
- Azioni che non sono state eseguite perché il flusso di lavoro è stato arrestato prima del completamento
- App per la logica o flussi di lavoro disabilitati perché non possono creare nuove istanze mentre sono inattive.