Prezzi di AWS Lambda

Calcolo serverless per ogni carico di lavoro

Panoramica

AWS Lambda è un servizio di calcolo serverless con pagamento in base all’utilizzo. Il prezzo delle funzioni degli eventi Lambda si basa sul numero di richieste e sulla durata dell’esecuzione. I prezzi delle microVM Lambda si intendono per istanza-secondo. Il prezzo delle funzioni web Lambda è calcolato in base alle richieste e al tempo di attività della CPU.
  • funzioni degli eventi

  • Prezzi delle funzioni degli eventi Lambda

    Il prezzo delle funzioni degli eventi di Lambda viene calcolato in base al numero di richieste servite e alla durata di esecuzione del codice, misurata in GB-secondi. Scegli la memoria allocata alla tua funzione e ottieni CPU e risorse proporzionali. Il piano gratuito include un milione di richieste e 400.000 GB-secondo al mese.

    Evento asincrono (inclusi eventi da S3, SNS, EventBridge, StepFunctions, Cloudwatch Logs): ti viene addebitata 1 richiesta per ogni evento asincrono per i primi 256 KB. Per dimensioni di evento individuali superiori a 256 KB viene addebitata una richiesta addizionale ogni 64 KB di blocco, fino a un massimo di 1 MB.

    Il costo della durata dipende dalla quantità di memoria allocata per la funzione. Puoi allocare alla funzione qualsiasi quantità di memoria compresa tra 128 MB e 10.240 MB, in incrementi di 1 MB. La tabella sottostante contiene alcuni esempi del prezzo per 1 ms associato a diverse dimensioni di memoria per un utilizzo che rientra nel primo scaglione di prezzo, ad esempio fino a 6 miliardi di GB-secondi al mese negli Stati Uniti Orientali (Ohio).

    • Prezzo x86
    • Prezzo di Arm

    Le fasce di prezzo per la durata on demand di Lambda vengono applicate alla durata mensile aggregata delle funzioni in esecuzione sulla medesima architettura (rispettivamente x86 o Arm), nella medesima regione, all’interno dell’account. Se si utilizza la fatturazione consolidata in AWS Organizations, le fasce di prezzo vengono applicate alla durata mensile aggregata delle funzioni in esecuzione sulla medesima architettura, nella medesima regione, nei vari account dell’organizzazione.

    Istanze gestite di Lambda

    Le istanze gestite di Lambda consentono di eseguire funzioni degli eventi di Lambda su istanze EC2 completamente gestite nel tuo VPC, combinando l’esperienza di sviluppatore serverless di Lambda con l’efficienza dei costi e la flessibilità hardware di EC2. Questa funzionalità è ideale per carichi di lavoro stazionari e ad alto volume in cui si desidera ottimizzare i costi mantenendo la semplicità operativa di Lambda.

    Con le istanze gestite di Lambda puoi scegliere tra un’ampia gamma di tipi di istanze EC2 di generazione attuale per soddisfare i requisiti del tuo carico di lavoro, beneficiare delle opzioni di prezzo di EC2, tra cui Savings Plans per le istanze EC2, Savings Plans per il calcolo e istanze riservate, ed elaborare più richieste contemporaneamente all’interno dello stesso ambiente di esecuzione per massimizzare l’utilizzo delle risorse. Lambda gestisce automaticamente il provisioning, il ridimensionamento, l’applicazione di patch e la gestione del ciclo di vita delle istanze, mantenendo il familiare modello di programmazione Lambda e la perfetta integrazione con sorgenti di eventi come SQS, Kinesis e Kafka.

    Prezzi:
    Il prezzo delle istanze gestite Lambda è composto da tre componenti:

    1. Costi delle richieste: 0,20 $ per milione di richieste
    2. Costo di gestione del calcolo: premio del 15% sul prezzo delle istanze EC2 on demand per le istanze fornite e gestite da Lambda (premio per ogni tipo di istanza fornito di seguito)
    3. Costi delle istanze EC2: Il prezzo standard delle istanze EC2 si applica alle istanze fornite nel provider di capacità. È possibile ridurre i costi utilizzando i Savings Plans per il calcolo, le istanze riservate o altre opzioni di prezzo EC2

    Tieni presente che le funzioni delle istanze Lambda gestite non pagheranno separatamente la durata di esecuzione di ogni richiesta, a differenza delle funzioni di tipo di calcolo Lambda (per impostazione predefinita).

    Strumenti di mappatura dell’origine degli eventi: Per i carichi di lavoro che utilizzano EPU (Event Poller Units) predisposte con origini di eventi come Kafka o SQS, si applicano i prezzi standard delle EPU.

    Commissioni di gestione
    • Supponiamo di utilizzare un servizio API ad alto traffico che elabora 100 milioni di richieste al mese con una durata media di 200 ms per richiesta. Configuri il tuo provider di capacità di istanze gestite di Lambda per utilizzare le istanze m7g.xlarge (4 vCPU, 16 GB di memoria, Graviton3) e utilizzi un Savings Plan per il calcolo triennale per il massimo risparmio sui costi.

      Costi mensili

      Costi delle richieste
      Richieste mensili: 100 milioni di richieste
      Prezzo della richiesta: 0,20 $ per milione di richieste
      Costi mensili delle richieste: 100 milioni / 1 milione × 0,20 $ = 20 $

      Costi di calcolo
      Tipo di istanza: m7g.xlarge
      Prezzo EC2 on demand: 0,1632 $ all’ora (Stati Uniti orientali, Virginia settentrionale)
      Con uno sconto triennale Savings Plans per il calcolo (72%): 0,0457 $ all’ora
      Ore stimate necessarie per l’istanza: circa 2.000 ore al mese (in base al modello di carico di lavoro e alla multi-concorrenza)
      Costi mensili per le istanze EC2: 2.000 × 0,0457 $ = 91,40 $

      Commissioni di gestione
      Commissione di gestione: 15% del prezzo on demand di EC2
      Commissione di gestione oraria: 0,1632 $ × 0,15 = 0,02448 $ all’ora
      Commissione di gestione mensile: 2.000 × 0,02448 $ = 48,96 $

      Costi mensili totali
      Costi totali = Costi delle richieste + Costi per le istanze EC2 + Commissioni di gestione
      Costi totali = 20 $ + 91,40 $ + 48,96 $ = 160,36 $

    Prezzi delle Funzioni Durature Lambda

    Le funzioni durature Lambda semplificano la creazione di applicazioni affidabili in più fasi e flussi di lavoro IA direttamente all’interno del modello di programmazione esistente di Lambda, consentendo carichi di lavoro resilienti ed economici di lunga durata. Nelle funzioni durature si utilizzano operazioni durevoli come “passaggi” e “attese”, vale a dire punti di controllo con dati opzionali memorizzati per periodi prolungati, consentendo alla funzione di riprendere l’esecuzione dopo le interruzioni. Quando le funzioni riprendono, il sistema esegue la riproduzione, rieseguendo automaticamente il gestore di eventi dall’inizio, saltando i punti di controllo completati e continuando dal punto di interruzione. Il ciclo di vita può includere sotto-invocazioni multiple (invocazioni di funzioni Lambda che si verificano quando si riprende l’attività dopo operazioni di attesa, tentativi o guasti dell’infrastruttura) per completare l’esecuzione. 

    Si applicano i costi di calcolo Lambda esistenti, compresi quelli relativi alle sotto-invocazioni dalle riproduzioni. Quando si utilizzano le operazioni di attesa, la funzione sospende l’esecuzione e, per le funzioni on demand, non vengono addebitati costi di durata fino alla ripresa dell’esecuzione. Inoltre, ti vengono addebitati i costi per le operazioni durature (come l’avvio delle esecuzioni, il completamento dei passaggi e la creazione di attese). Ti verrà addebitata anche la quantità di dati scritti da queste operazioni (in GB) e la conservazione dei dati durante e dopo l’esecuzione (in GB-mese, proporzionalmente). Il periodo di conservazione dopo il completamento è configurabile da 1 a 90 giorni (per impostazione predefinita 14 giorni). 

    Per un elenco completo e una descrizione dettagliata delle operazioni durature, consulta la Guida per gli sviluppatori di Lambda.

    • Un sistema di elaborazione delle richieste di risarcimento assicurativo utilizza le funzioni durature Lambda per analizzare le richieste al fine di individuare eventuali frodi, coordinare la revisione umana delle richieste di alto valore ed elaborare i pagamenti approvati. Il processo inizia con una fase di analisi dei documenti che richiede 30 secondi per eseguire il rilevamento delle frodi e la valutazione del rischio basati sui modelli LLM. L’esecuzione utilizza quindi un’attesa per sospendere l’esecuzione e consentire una revisione umana (in genere 7 giorni di attesa) in cui un perito esamina le richieste di sinistri che superano le soglie di approvazione automatiche. Infine, una fase di pagamento che richiede 2 secondi per elaborare la decisione di approvazione per avviare il pagamento. Il sistema elabora 1.000.000 di richieste di risarcimento assicurativo al mese. Ogni esecuzione utilizza un payload di invocazione di 8 KB e un payload di 32 KB per l’analisi delle richieste di risarcimento (fase 1), le decisioni di approvazione (attesa) e l’elaborazione del pagamento finale (fase 2). La funzione è configurata con 1 GB di memoria su un processore basato su ARM. I registri delle richieste di risarcimento completate vengono mantenuti per 14 giorni a fini di audit e conformità. Nota: gli esempi si basano sui prezzi nella regione degli Stati Uniti orientali (Virginia settentrionale). Tutte le esecuzioni partono dall’inizio del mese e tutti i passaggi vengono eseguiti correttamente al primo tentativo senza riprovare ulteriormente, per semplificare i calcoli.

      Nota: gli esempi si basano sui prezzi nella regione degli Stati Uniti orientali (Virginia settentrionale). Tutte le esecuzioni partono dall’inizio del mese e tutti i passaggi vengono eseguiti correttamente al primo tentativo senza riprovare ulteriormente, per semplificare i calcoli.

      Costi mensili di calcolo

      Calcolo totale (secondi) 1.000.000 × 32 s = 32.000.000 secondi
      Calcolo totale (GB-s) 32.000.000 × 1 GB = 32.000.000 GB-s
      Calcolo fatturabile 32.000.000 - 400.000 livello gratuito = 31.600.000 GB-s
      Costi di calcolo 31.600.000 × 0,0000133334 $ = 421,34 $

      Costi mensili delle richieste

      Richieste totali 2 invocazioni (iniziale + dopo l’attesa) × 1.000.000 = 2.000.000 richieste
      Richieste fatturabili 2.000.000 - 1 milione del livello gratuito = 1.000.000
      Costo della richiesta 1 milione × 0,20/milioni di dollari = 0,20 $


      Costi mensili delle funzioni durature

      Operazioni 1 milione × (1 avvio esecuzione + 2 passaggi + 1 attesa) = 4 milioni
      Costo delle operazioni 4 milioni × 8,00/milione di dollari = 32,00 $
      Dati scritti 1 milione × (8 KB invocazione + 3 × 32 KB passaggi/attese) = 104 GB
      Costo di scrittura dei dati 104 GB × 0,25 $/GB = 26,00 $
      Archiviazione (in esecuzione con 7 giorni di attesa) 104 GB × (7/30) = 24,27 GB-mese
      Archiviazione (mantenuti per 14 giorni) 104 GB × (14/30) = 48,53 GB-mese
      Costo di conservazione dei dati (24,27 + 48,53) GB-mese × 0,15 $/GB-mese = 10,92 $

       

      Costi mensili totali

      Totale complessivo 421,34 $ + 0,20 $ + 32,00 $ + 26,00 $ + 10,92 $ = 490,46 $

    Costi di isolamento tenant

    Abilita la modalità di isolamento tenant per isolare l’elaborazione delle richieste per singoli utenti finali o tenant che invocano le tue funzioni degli eventi Lambda. Gli ambienti di esecuzione sottostanti per una funzione Lambda isolata per tenant sono sempre associati a un particolare tenant e non vengono mai utilizzati per eseguire richieste da altri tenant che invocano la stessa funzione. Questa funzionalità semplifica lo sviluppo e la manutenzione di applicazioni multi-tenant che elaborano codice o dati specifici del tenant con severi requisiti di isolamento tra i tenant. Quando Lambda crea un nuovo ambiente di esecuzione isolato per tenant per soddisfare una richiesta, viene addebitato un costo, a seconda della quantità di memoria allocata alla funzione e dell’architettura della CPU utilizzata. Per saperne di più sulla funzionalità di isolamento tenant di Lambda, leggi la documentazione.

    • Applicazione SaaS multi-tenant

      Supponiamo che tu stia creando una piattaforma di automazione che esegue il codice fornito dall’utente in risposta agli eventi. Ad esempio, un team IT potrebbe voler eseguire un flusso di lavoro automatizzato quando un nuovo dipendente entra a far parte della propria organizzazione o si trasferisce tra i reparti. Come altro esempio, un team DevOps potrebbe voler attivare un flusso di lavoro CI/CD quando uno sviluppatore esegue il commit delle modifiche al codice nel proprio repository di codice sorgente. La tua piattaforma di automazione è multi-tenant, il che significa che serve più utenti finali. Poiché ti aspetti un’elevata variazione della domanda, in base all’ora del giorno e per ogni utente finale o tenant, crei la tua piattaforma utilizzando servizi serverless tra cui AWS Lambda.

      La tua piattaforma di automazione supporta la capacità di eseguire codice fornito dall’utente in risposta agli eventi. Poiché non controlli il codice fornito dagli utenti, abiliti la modalità di isolamento tenant per garantire che le chiamate alle funzioni Lambda per ciascun utente finale vengano elaborate in ambienti di esecuzione separati e isolati l’uno dall’altro.

      Supponiamo di aver configurato la funzione Lambda con 1.024 MB di memoria e architettura CPU x86. Durante un mese tipico, la funzione elabora 10 milioni di invocazioni con una durata media di 2 secondi per invocazione. La tua piattaforma SaaS viene utilizzata da 1.000 utenti finali o tenant. Per semplicità, supponiamo che in media ogni tenant generi 10.000 invocazioni al mese e Lambda crei 200 ambienti di esecuzione per tenant (ovvero un tasso di avvio a freddo del 2% per tenant).

      I costi vengono calcolati come segue:

      Costi delle richieste
      La tua funzione viene eseguita 10 milioni di volte al mese.

      Costi mensili delle richieste: 10 milioni × 0,2 $/milione = 2 $.

      Costi di calcolo
      La tua funzione viene eseguita 10 milioni di volte al mese con una durata media di 2 secondi. La memoria configurata della funzione è di 1.024 MB.

      Durata del calcolo mensile (secondi): 10 milioni × 2 s = 20 milioni di secondi
      Calcolo mensile (GB-s): 20 milioni di secondi × 1.024 MB / 1.024 MB = 20 milioni di GB-s
      Costi mensili di calcolo: 20 milioni × 0,0000166667 $ = 333,34 $

      Costi di isolamento tenant
      Al mese, in media, la tua funzione serve 1.000 tenant unici. Ogni tenant invoca la funzione 10.000 volte con una media di 200 ambienti di esecuzione creati per tenant (ovvero un tasso medio di avvio a freddo del 2% per ogni tenant).

      Ambienti di esecuzione mensili creati per 1.000 tenant: 200 × 1.000 = 200.000
      Costi mensili di isolamento tenant: 200.000 × 0,000167 $ × 1.024 MB / 1.024 MB = 33,4 $

      Costi mensili totali
      Costi totali = Costi delle richieste + Costi di calcolo + Costi di isolamento tenant
      Costi totali = 2 $ + 333,34 $ + 33,4 $ = 368,74 $

    Prezzi dello spazio di archiviazione temporaneo di Lambda

    Il costo dello spazio di archiviazione temporaneo dipende dallo spazio di archiviazione temporaneo allocato alla funzione evento e dalla durata dell’esecuzione della funzione, misurata in millisecondi. Puoi allocare alla funzione qualsiasi quantità di spazio di archiviazione aggiuntivo compreso tra 512 MB e 10.240 MB, in incrementi di 1 MB. Puoi configurare lo spazio di archiviazione temporaneo per le funzioni in esecuzione su entrambe le architetture x86 e Arm. Per ogni funzione Lambda sono disponibili 512 MB di spazio di archiviazione temporaneo senza alcun costo aggiuntivo. Pagherai solo per lo spazio di archiviazione temporaneo aggiuntivo che configuri.

    Tutti gli esempi seguenti si basano sui prezzi nella regione degli Stati Uniti orientali (Virginia settentrionale).

    Prezzi della simultaneità fornita

    Abilita la simultaneità fornita per le funzioni degli eventi Lambda per un maggiore controllo sulle prestazioni delle applicazioni serverless. Quando è abilitata, la simultaneità fornita mantiene le funzioni già inizializzate e pronte a rispondere in millisecondi a due cifre. Paghi per la quantità di simultaneità che configuri e per il periodo di tempo in cui la configuri. Quando la simultaneità fornita è abilitata ed eseguita per una determinata funzione, paghi inoltre le richieste e la durata in base ai prezzi sottostanti. Se la tua funzione supera la simultaneità configurata, ti verrà addebitata l’eccedenza di esecuzione della funzione alla tariffa indicata nella sezione Prezzi di AWS Lambda precedente. Puoi abilitare la simultaneità fornita per eseguire le funzioni su entrambe le architetture x86 e Arm. Per saperne di più sulla simultaneità fornita, leggi la documentazione.

    La simultaneità fornita viene calcolata dal tempo di abilitazione sulla funzione fino alla sua disabilitazione, arrotondato ai 5 minuti più vicini. Il prezzo dipende dal volume di memoria allocata alla funzione e dal totale di simultaneità configurata. La durata viene calcolata a partire dal momento in cui viene avviata l’esecuzione del codice e fino al momento in cui restituisce o comunque termina, arrotondata al millisecondo più vicino**. Il prezzo dipende dalla quantità di memoria allocata per la funzione.

    ** I costi della durata valgono per il codice in esecuzione nel gestore di una funzione e per il codice di inizializzazione dichiarato al di fuori del gestore. Per le funzioni degli eventi Lambda con estensioni AWS Lambda, la durata include anche il tempo impiegato dal codice nell’ultima estensione in esecuzione per terminare l’esecuzione durante la fase di chiusura. Per le funzioni configurate con la simultaneità fornita, AWS Lambda ricicla periodicamente gli ambienti di esecuzione e riesegue il codice di inizializzazione. Per ulteriori dettagli, consulta la documentazione sui modelli di programmazione Lambda.

    Il piano gratuito di Lambda non si applica alle funzioni che abilitano la simultaneità fornita. Quando la simultaneità fornita è abilitata per una determinata funzione e viene eseguita, ti vengono addebitate le richieste e la durata sulla base dei prezzi sottostanti.

    Tutti gli esempi seguenti si basano sui prezzi nella regione degli Stati Uniti orientali (Virginia settentrionale).

    • Supponiamo che tu sia uno sviluppatore di app per dispositivi mobili che sta sviluppando un’applicazione mobile per ordinare cibo. I clienti possono usare l’applicazione per ordinare cibo da uno specifico luogo di ristorazione, ricevere aggiornamenti sullo stato dell’ordine e ritirare il cibo quando l’ordine è pronto. Poiché ti aspetti grandi variazioni nella domanda della tua applicazione, sia per momento della giornata sia per luogo di ristorazione, costruisci il tuo backend per dispositivi mobili utilizzando servizi serverless, tra cui AWS Lambda.

      Per semplicità, supponiamo che la tua applicazione elabori tre milioni di richieste al mese. La
      durata media di esecuzione della funzione è di 120 ms. Hai configurato la tua funzione con 1.536 MB di memoria su un processore basato su x86.

      Stai avviando una nuova versione della tua applicazione per dispositivi mobili che hai ampiamente promosso. Prevedi un picco di domanda il giorno del lancio, da mezzogiorno alle 20:00. Vuoi che la tua applicazione per dispositivi mobili sia reattiva anche quando le richieste aumentano e diminuiscono velocemente, quindi abiliti la simultaneità fornita nelle tue funzioni degli eventi Lambda. Stabilisci la simultaneità fornita a 100.

      Durante queste otto ore le tue funzioni ricevono 500.000 richieste. La durata media di esecuzione di funzione
      mentre la simultaneità fornita è abilitata è di 100 ms. Durante il resto del mese la tua applicazione riceve altri 2,5 milioni di richieste aggiuntive e le tue funzioni vengono eseguite in risposta senza la simultaneità fornita abilitata.

      I costi vengono calcolati come segue:

      Prezzi della simultaneità fornita:
      Il prezzo della simultaneità fornita è di 0,0000041667 $ per GB-s
      Periodo di tempo totale per il quale la simultaneità fornita è abilitata (secondi): 8 ore × 3.600 secondi = 28.800 secondi
      Simultaneità totale configurata (GB): 100 × 1.536 MB/1.024 MB = 150 GB
      Totale simultaneità fornita (GB-s): 150 GB × 28.800 secondi = 4.320.000 GB-s
      Costi della simultaneità fornita: 4,32 milioni di GB-s × 0,0000041667 $ = 18 $

      Costi delle richieste:
      il costo mensile delle richieste è di 0,20 $ per 1 milione di richieste; il piano gratuito include 1 milione di richieste al mese.
      Richieste totali - Richieste incluse nel piano gratuito = Richieste fatturabili al mese
      3.000.000 di richieste - 1 milione di richieste incluse nel piano gratuito = 2.000.000 di richieste fatturabili al mese
      Costi mensili delle richieste = 2 × 0,20 USD = 0,40 USD

      Costi di calcolo quando la simultaneità fornita è abilitata:
      Il prezzo di calcolo è 0,0000097222 $ per GB-s
      Durata totale del calcolo (secondi) = 500.000 × 100 ms = 50.000 secondi
      Totale del calcolo (GB-s) = 50.000 secondi × 1.536 MB / 1.024 MB = 75.000 GB-s.
      Costi di calcolo totali = 75.000 GB-s × 0,0000097222 $ = 0,73 $

      Costi di calcolo quando la simultaneità fornita è disabilitata:
      Il prezzo di calcolo mensile è di 0,0000166667 $ per GB-s e il piano gratuito offre 400.000 GB-s.
      Calcolo totale (secondi) = 2,5 milioni × 120 ms = 300.000 secondi
      Calcolo totale (GB-s) = 300.000 × 1.536 MB / 1.024 MB = 450.000 GB-s
      Calcolo totale - Calcolo del piano gratuito = Calcolo fatturabile mensilmente (GB-s)
      450.000 GB-s - 400.000 GB-s del piano gratuito = 50.000 GB-s
      Costi mensili di calcolo = 50.000 × 0,0000166667 $ = 0,83 $

      Costi mensili totali:
      Costi totali = Costi della simultaneità fornita + Costi delle richieste + Costi di calcolo con simultaneità fornita abilitata + Costi di calcolo con simultaneità fornita disabilitata
      Costi totali = 18 $ + 0,40 $ + 0,73 $ + 0,83 $ = 19,96 $

    • Supponiamo che tu sia un rivenditore al dettaglio che organizza una grande promozione durante il Cyber Monday, una festività dell’e-commerce organizzata il lunedì dopo il giorno del Ringraziamento negli Stati Uniti. I tuoi clienti possono chattare in tempo reale con il servizio clienti attraverso l’applicazione per dispositivi mobili che fornisci. Decidi di implementare un modello di elaborazione del linguaggio naturale (NLP).

      In tal caso, stai usando il famoso modello Bidirectional Encoder Representations from Transformers (BERT) su AWS Lambda. Il modello ti aiuta a eseguire il parsing, analizzare e capire le interazioni del servizio clienti tramite l’app per dispositivi mobili al fine di mostrare contenuti di supporto pertinenti o di indirizzare il cliente all’agente del servizio clienti più appropriato. Riceverai molte più richieste di supporto dai clienti quel giorno rispetto al normale, quindi decidi di abilitare la simultaneità fornita nelle tue funzioni degli eventi Lambda affinché la tua applicazione sia reattiva anche in occasione di picchi di traffico.

      Supponiamo che le tue funzioni ricevano due milioni di richieste durante le 24 ore dell’evento di vendita, mentre la simultaneità fornita è abilitata. La durata media di esecuzione della funzione è di 280 ms. Configuri la tua funzione con 4.096 MB di memoria su un processore basato su x86 e imposti la simultaneità fornita a sette.

      I costi vengono calcolati come segue:

      Prezzi della simultaneità fornita:
      Il prezzo della simultaneità fornita è di 0,0000041667 $ per GB-s.
      Il periodo di tempo totale nel quale la simultaneità fornita è abilitata (secondi) = 24 ore × 3.600 secondi = 86.400 secondi
      Simultaneità totale configurata (GB): 7 × 4.096 MB / 1.024 MB = 28 GB
      Quantità totale di simultaneità fornita (GB-s) = 28 GB × 86.400 secondi = 2.419.200 GB-s
      Costi della simultaneità fornita = 2.419.200 GB-s × 0,0000041667 $ = 10,08 $

      Costi di calcolo quando la simultaneità fornita è abilitata:
      Il costo di calcolo è 0,0000097222 $ per GB-s.
      Durata totale di calcolo (secondi) = 2.000.000 × 280 ms = 560.000 secondi
      Calcolo totale (GB-s) = 560.000 secondi × 4.096 MB/1.024 MB = 2.240.000 GB-s.
      Costi di calcolo totali = 2.240.000 GB-s × 0,0000097222 $ = 21,78 $

      Costi mensili delle richieste:
      Il prezzo mensile per le richieste è di 0,20 $ per 1 milione di richieste
      Costi mensili delle richieste = 2 milioni × 0,2 $/M = 0,40 $

      Costi mensili totali:
      Costi totali = Costi della simultaneità fornita + Costi di calcolo quando la simultaneità fornita è abilitata + Costi della richiesta = 10,08 $ + 21,78 $ + 0,40 $ = 32,26 $

    Prezzi di SnapStart

    SnapStart può migliorare le prestazioni di avvio da alcuni secondi a meno di un secondo per le applicazioni sensibili alla latenza. Il funzionamento di SnapStart si basa sulla creazione di uno snapshot dello stato della memoria (e del disco) inizializzata della funzione e sulla memorizzazione di tale snapshot nella cache per un accesso a bassa latenza. In seguito, quando la funzione viene invocata, Lambda riprende gli ambienti di esecuzione da questo snapshot preinizializzato invece di inizializzarli da zero, migliorando la latenza di avvio.

    Si crea uno snapshot ogni volta che si pubblica una nuova versione della funzione con SnapStart abilitato. Viene addebitato il costo della memorizzazione nella cache di uno snapshot nel periodo in cui la versione della funzione è attiva, per un minimo di 3 ore e successivamente per millisecondo. Il prezzo dipende dalla quantità di memoria allocata per la funzione. Inoltre, viene addebitato un costo ogni volta che Lambda riprende un ambiente di esecuzione ripristinando lo snapshot. In questo caso, il prezzo dipende dalla quantità di memoria allocata per la funzione.

    I prezzi di SnapStart non si applicano a runtime Java gestiti supportati.

    • Supponiamo che la tua sia un’azienda di logistica con un parco veicoli sul campo, ognuno dei quali è dotato di sensori e connettività 4G/5G per emettere dati di telemetria in un flusso di dati Amazon Kinesis. Vuoi utilizzare modelli di machine learning (ML) che hai sviluppato per dedurre lo stato di salute del veicolo e prevedere quando la manutenzione di componenti specifici possa essere necessaria.

      Supponiamo tu abbia 10.000 veicoli sul campo, ognuno dei quali emette telemetria una volta all’ora in maniera sfalsata con jitter sufficiente. Hai intenzione di eseguire questa inferenza su ogni payload per assicurarti che la programmazione della manutenzione dei veicoli venga eseguita tempestivamente e per garantire la salute ottimale del tuo parco veicoli.

      Supponiamo che il modello ML sia preparato insieme alla funzione e abbia dimensioni pari a 512 MB. Per l’inferenza, hai configurato la funzione con 1 GB di memoria e la durata di esecuzione fatturata è in media di due secondi su un processore basato su x86. Si mantiene un’unica versione della funzione. Per semplicità, supponiamo che l’1% di tutte le richieste porti alla creazione di nuovi ambienti di esecuzione.

      L’elaborazione end-to-end richiede diversi secondi per questo 1% di richieste. Ciò è dovuto al fatto che l’inizializzazione della funzione richiede diversi secondi, in quanto si importano moduli software di grandi dimensioni e il modello ML durante l’inizializzazione. Vuoi ridurre il tempo di elaborazione end-to-end per queste richieste, quindi abiliti SnapStart sulla tua funzione e pubblichi una nuova versione.

      I costi vengono calcolati come segue:

      Costi delle richieste
      I veicoli emetteranno 10.000 × 24 × 31 = 7.440.000 messaggi al mese, che saranno elaborati dalla funzione Lambda.

      Costi mensili delle richieste: 7,44 milioni × 0,20 $/milione = 1,49 $

      Costi mensili di calcolo
      Ogni mese, la funzione verrà eseguita una volta ad ogni messaggio per due secondi.

      Durata del calcolo mensile (secondi): 7,44 milioni x 2 secondi = 14,88 milioni di secondi
      Calcolo mensile (GB-s): 14,88 milioni di secondi × 1.024 MB / 1.024 MB = 14,88 milioni di GB-s
      Costi mensili di calcolo: 14,88 milioni di GB-s × 0,0000166667 $ = 248,00 $

      Costi di SnapStart:

      Periodo di tempo totale durante il quale la versione della funzione è attiva (secondi): 24 ore x 31 giorni x 3.600 secondi = 2.678.400 secondi
      Memoria della funzione allocata: 1.024 MB/1.024 MB -> 1 GB
      Cache SnapStart totale utilizzata: 1 GB × 2.678.400 s -> 2.678.400 GB-s
      Costi della cache SnapStart: 2,68 milioni di GB-s × 0,0000015046 $ = 4,03 $

      Numero di richieste che utilizzano il ripristino SnapStart: 1% di 7,44 milioni = 74.400
      Ripristino SnapStart totale utilizzato: 74.400 x 1 GB = 74.400 GB
      Costi del ripristino SnapStart: 74.400 GB x 0,0001397998 $ = 10,4 $

      Costi totali di SnapStart: Costi della cache SnapStart + Costi del ripristino SnapStart
      Costi totali di SnapStart: 4,03 $ + 10,4 $ = 14,43 $

      Costi mensili totali

      Costi totali = Costi delle richieste + Costi di calcolo + Costi di SnapStart
      Costi totali = 1,49 $ + 248,00 $ + 14,43 $ = 263,92 $

    Prezzi del flusso di risposta HTTP Lambda

    Le funzioni degli eventi di AWS Lambda possono restituire un flusso di risposta HTTP quando vengono invocate tramite l’API InvokeWithResponseStream o tramite un URL di funzione utilizzando la modalità di invocazione ResponseStream. Il flusso di risposta HTTP può migliorare le prestazioni di TTFB (Time to First Byte) e supporta payload superiori a 6 MB. Quando utilizzi il flusso di risposta HTTP, viene addebitato un costo per ogni GB scritto nel flusso di risposta dalla funzione. Puoi trasmettere i primi 6 MB per richiesta senza alcun costo.

    Tutti gli esempi seguenti si basano sui prezzi nella regione degli Stati Uniti orientali (Virginia settentrionale).

    Prezzo della modalità con provisioning per lo strumento di mappatura dell’origine degli eventi (ESM)

    La modalità con provisioning per lo strumento di mappatura dell’origine degli eventi (ESM) consente di ottimizzare il throughput dell’ESM allocando un numero minimo e massimo di risorse denominate event poller e scalando automaticamente tra i limiti minimi e massimi configurati. Un event poller è la risorsa configurabile alla base di un ESM in modalità con provisioning. I prezzi si basano sugli event poller minimi con provisioning e su quelli utilizzati durante il dimensionamento automatico. I costi vengono calcolati utilizzando un’unità di fatturazione denominata EPU (Event Poller Unit). Il pagamento viene calcolato in base al numero e alla durata delle unità EPU utilizzate, misurati in EPU-ora.

    SQS ESM: Un’EPU supporta un event poller, ciascuno dei quali fornisce un throughput fino a 1 MB/s. Ogni SQS ESM richiede un minimo di 2 event poller.

    MSK o Kafka autogestito (SMK) ESM: Ogni EPU supporta una capacità di throughput fino a 20 MB/s per il polling degli eventi, con un valore predefinito di 10 event poller. ogni event poller può scalare verticalmente fino a 5 MB/s di throughput. Il numero di event poller allocati su un’EPU dipende dalla capacità di calcolo consumata da ciascun event poller. Puoi raggruppare più ESM all’interno dello stesso Amazon VPC per condividere capacità e costi EPU. Per saperne di più sulla modalità con provisioning per Kafka ESM, leggi la documentazione. 

    Trasferimento dei dati: riceverai la fattura alle tariffe di trasferimento dei dati AWS standard.

    Durata: le tariffe vengono calcolate al secondo con un minimo di 1 minuto.

    • Esempio: analisi dei dati di streaming in tempo reale con Kafka

      Supponiamo di essere un fornitore globale di soluzioni per centri di assistenza alla clientela e di disporre di pipeline che emettono metadati relativi all’esperienza di chiamata ai topic di Amazon MSK (Kafka) per l’analisi in tempo reale. Poiché il traffico può presentare picchi ed essere imprevedibile, è consigliabile utilizzare la modalità con provisioning per l’ESM per eseguire il fine-tuning delle prestazioni del proprio ESM. Supponiamo che la funzione Lambda che elabora questi messaggi sia configurata con 1.024 MB di memoria per processore x86 e riceva 1 milione di invocazioni al giorno con una durata media di 2 secondi. Supponiamo di aver attivato la modalità con provisioning per l’ESM con 1 event poller predefinito e che l’ESM scali verticalmente fino a consumare 800 ore EPU al mese negli Stati Uniti orientali (Virginia settentrionale).

      Costi mensili di calcolo
      Il prezzo mensile del calcolo è di 0,0000166667 $ per GB-s e il piano gratuito fornisce 400.000 GB-s
      Calcolo totale (secondi) = 1.000.000 × 30 × 2 secondi = 60.000.000 secondi
      Calcolo totale (GB-s) = 60.000.000 × 1.024 MB/1.024 = 60.000.000 GB-s
      Calcolo totale - Calcolo del piano gratuito = GB-s di calcolo fatturabile mensilmente
      60.000.000 GB-s - 400.000 GB-s di piano gratuito = 59.600.000 GB-s
      Costi mensili di calcolo = 59.600.000 × 0,0000166667 $ = 993,3 $

      Costi mensili delle richieste
      Il prezzo mensile per le richieste è di 0,20 $ per 1 milione di richieste.
      Costi mensili delle richieste = 60 milioni di richieste × 0,20 $ = 12,00 $

      Costi mensili della modalità con provisioning per ESM
      Costi EPU = 800 ore EPU × 0,185 $ = 148 $
      Costi mensili della modalità con provisioning per ESM = 148 $

      Costi totali
      Costi totali = Costi di calcolo + Costi della richiesta + Costi della modalità con provisioning dell’ESM
      Costi totali = 993,3 $ + 12 $ + 148 $ = 1.153,3 $

       

    • Esempio: Elaborazione degli eventi in tempo reale con Amazon SQS

      Supponiamo che tu sia una società di servizi finanziari che elabora feed di dati di mercato ed esegue transazioni finanziarie utilizzando microservizi basati sugli eventi per applicazioni finanziarie rivolte ai clienti in tempo reale. Poiché il traffico può presentare picchi ed essere imprevedibile, è consigliabile utilizzare la modalità con provisioning per ESM per eseguire il fine-tuning delle prestazioni del proprio ESM. Supponiamo che la funzione Lambda che elabora questi eventi sia configurata con 1.024 MB di memoria per processore x86 e riceva 1 milione di invocazioni al giorno con una durata media di 1 secondo. Hai un TPS massimo di eventi di 100 che desideri elaborare con una latenza massima di 0,2 secondi. Per ottenere queste prestazioni di latenza, hai attivato la modalità con provisioning per il tuo SQS ESM con un minimo di 10 event poller e il tuo ESM è scalabile fino a consumare 8.000 ore EPU al mese nella regione degli Stati Uniti orientali (Virginia settentrionale) per gestire il traffico a bassa latenza soggetto a picchi.

      Costi mensili di calcolo
      Il prezzo del calcolo mensile è di 0,0000166667 $ per GB-s
      Calcolo totale (secondi) = 1.000.000 × 30 × 1 secondo = 30.000.000 secondi
      Calcolo totale (GB-s) = 30.000.000 × 1.024 MB / 1.024 = 30.000.000 GB-s
      Calcolo totale = calcolo fatturabile mensilmente (GB-s) × 0,0000166667 $
      Costi mensili di calcolo = 30.000.000 × 0,0000166667 $ = 500 $

      Costi mensili delle richieste
      Il prezzo mensile per le richieste è di 0,20 $ per 1 milione di richieste
      Costi mensili delle richieste = 30 milioni di richieste × 0,20 $ = 6 $

      Costi mensili della modalità con provisioning per SQS ESM
      Il prezzo dell’EPU è di 0,00925 $ per ora EPU
      Addebiti EPU = 8.000 ore EPU × 0,00925 $ = 74 $
      Costi mensili della modalità con provisioning per ESM = 74 $

      Costi totali
      Costi totali = Costi di calcolo + Costi delle richieste + Costi della modalità con provisioning dell’ESM
      Costi totali = 500 $ + 6 $ + 74 $ = 580 $

    • Supponiamo di essere un fornitore globale di soluzioni per centri di assistenza alla clientela e di disporre di pipeline che emettono metadati relativi all’esperienza di chiamata a decine di topic di Amazon MSK (Kafka) ognuno con acquisizione di messaggi dai vari prodotti disponibili. Ogni topic acquisisce un massimo di 500 messaggi al secondo, con una dimensione media dei messaggi di 3 KB e un throughput di 1,5 MB/s. Poiché il traffico può presentare picchi ed essere imprevedibile, è consigliabile utilizzare la modalità con provisioning per l’ESM per eseguire il fine-tuning delle prestazioni del proprio ESM. Supponiamo che la funzione Lambda che elabora questi messaggi sia configurata con 1.024 MB di memoria per processore x86 e riceva 1 milione di invocazioni al giorno con una durata media di 0,2 secondi. Hai creato 10 Kafka ESM per l’elaborazione di eventi con <1,5 MB/s di throughput per ESM e hai deciso di raggrupparli nello stesso gruppo Poller per ottimizzare i costi. Supponiamo di aver attivato la modalità con provisioning per il tuo ESM con 1 poller event predefinito e di utilizzare tutti i 10 ESM all’interno dello stesso gruppo di poller negli Stati Uniti orientali (Virginia settentrionale).

      Costi mensili di calcolo
             Il prezzo mensile del calcolo è di 0,0000166667 $ per GB-s e il piano gratuito fornisce 400.000 GB-s
      Calcolo totale (secondi) = 1.000.000 × 30 × 0,2 secondi = 6.000.000 di secondi
      Calcolo totale (GB-s) = 6.000.000 × 1.024 MB/1.024 = 6.000.000 GB-s
      Calcolo totale (GB-s) per tutti i 10 ESM = 6.000.000 GB-s × 10 = 60.000.000 GB-s
      Costi mensili di calcolo = 60.000.000 × 0,0000166667 $ = 1.000 $
      Costi mensili delle richieste
      Il prezzo mensile per le richieste è di 0,20 $ per 1 milione di richieste.
      Totale delle richieste mensili per tutti i 100 ESM = 1 milione × 30 giorni × 10 ESM = 300 milioni di richieste
      Costi mensili delle richieste = 300 milioni di richieste × 0,20 $ = 60,00 $
      Costi mensili della modalità con provisioning per ESM
      Il prezzo delle ore EPU è di 0,185 $/ora e supporta 10 event poller per EPU.
      Numero totale di event poller all’ora = 1 event poller × 10 ESM = 10 event poller
      EPU utilizzate = 10 event poller utilizzati/10 event poller supportati per EPU = 1 EPU
      EPU totali al mese = 1 EPU × 720 ore al mese = 720 ore EPU
      Addebiti EPU = 720 ore EPU × 0,185 $ = 133,2 $
      Modalità con provisioning mensile per gli addebiti ESM = 133,2 $
      Costi totali
      Costi totali = Costi di calcolo + Costi delle richieste + Modalità con provisioning per ESM
      Costi totali = 1.000 $ + 60 $ + 133,2 $ = 1.193,2 $ al mese per 10 ESM
      Costi mensili per ESM = 1.193,2 $/10 = 119,3 $ al mese per ESM

    Trasferimento dati e altri costi

    Trasferimento dati
    I dati trasferiti in entrata e in uscita dalle funzioni degli eventi di AWS Lambda, dall’esterno della regione in cui è stata eseguita la funzione, verranno addebitati in base alle tariffe di trasferimento dati di Amazon EC2 elencate in "Trasferimento dati".

    Il trasferimento di dati con le funzioni degli eventi di AWS Lambda è gratuito nella stessa regione AWS tra i seguenti servizi: Amazon Simple Storage Service (S3), Amazon Glacier, Amazon DynamoDB, Amazon Simple Email Service (SES), Amazon Simple Queue Service (SQS), Amazon Kinesis, Amazon Elastic Container Registry (ECR), Amazon Simple Notification Service (SNS), Amazon Elastic File System (EFS) e Amazon SimpleDB.

    L’utilizzo del cloud privato virtuale (VPC) Amazon o del peering VPC con le funzioni degli eventi di AWS Lambda comporterà costi aggiuntivi, come spiegato nella pagina dei prezzi on demand di Amazon Elastic Compute Cloud (EC2). Una connessione peering VPC è una connessione di reti fra due VPC che ti permette di instradare il traffico fra i due utilizzando indirizzi IPv4 privati o indirizzi IPv6. 

    Costi aggiuntivi
    Se la funzione Lambda utilizza altri servizi AWS o il trasferimento di dati, potrebbero essere addebitati costi aggiuntivi. Ad esempio, se la funzione Lambda legge e scrive dati da o verso Amazon S3, saranno addebitate le richieste di lettura/scrittura e l’archiviazione dei dati in Amazon S3.

    Per ulteriori informazioni sui prezzi dei servizi AWS, consulta la sezione dei prezzi nelle pagine di descrizione dei servizi AWS pertinenti.

    Prezzi di Lambda@Edge

    La durata delle funzioni Lambda@Edge è calcolata con una granularità di 1 ms

    • Se la funzione Lambda@Edge viene eseguita 10 milioni di volte in un mese, ogni volta per 10 ms, i costi vengono calcolati come segue:

      Costi mensili di calcolo

      Il prezzo mensile di calcolo è di 0,00000625125 $ per 128 MB-secondo

      Calcolo totale (secondi) = 10 milioni × (0,01 s) = 100.000 secondi

      Costi mensili di calcolo = 100.000 × 0,00000625125 $ = 0,63 $


      Costi mensili delle richieste

      Il costo mensile delle richieste è di 0,60 $ per 1 milione di richieste.

      Costi mensili delle richieste = 10 milioni × 0,6 $/milione = 6,00 $
       

      Costi mensili totali

      Costi totali = Costi di calcolo + Costi delle richieste = 0,63 $ + 6,00 $ = 6,63 $ al mese

  • MicroVM

  • Prezzi delle microVM Lambda

    I prezzi di AWS Lambda microVMs si basano sulle risorse di calcolo utilizzate, sulle operazioni di lettura/scrittura di snapshot, e sullo spazio di archiviazione e sul trasferimento dei dati alle tariffe AWS standard.

    Calcolo

    Le microVM Lambda eliminano la necessità di dimensionare correttamente ogni ambiente di calcolo per i picchi di attività. Configuri una baseline impostando la memoria e la CPU viene allocata in un rapporto memoria/CPU di 2:1 (il valore predefinito è 2 GB/1 vCPU). Durante i picchi di attività, la microVM può scalare verticalmente fino a 4 volte la baseline (fino a 8 GB/4 vCPU), senza che tu debba intraprendere alcuna azione.
     
    Paghi per le risorse di calcolo della baseline mentre la microVM è in esecuzione. Quando il carico di lavoro consuma risorse superiori alla baseline, ti viene addebitata solo la durata attiva della memoria e della vCPU aggiuntive consumate, non la capacità massima. Questo significa che puoi effettuare la configurazione per il tuo carico di lavoro tipico e lasciare a Lambda la gestione dei picchi. L’utilizzo del calcolo viene fatturato al secondo. Per informazioni dettagliate sul dimensionamento della tua microVM, consulta  creare un’immagine microVM.
    • x86
    • Graviton (ARM)

    Snapshot

    Le microVM di Lambda utilizzano gli snapshot per garantire un avvio quasi istantaneo e ridurre i costi di inattività. Un’immagine microVM è un’istantanea dello stato preinizializzato dell’applicazione. Invece di avviarsi a freddo da zero, la microVM viene avviata da questa immagine. Durante i periodi di inattività, puoi sospendere una microVM in esecuzione per un massimo di 8 ore, preservandone la memoria e lo stato del disco senza pagare costi di calcolo. Quando il traffico riprende, la microVM sospesa riprende rapidamente, automaticamente o programmaticamente. Ti verranno addebitati l’archiviazione degli snapshot, la lettura dei dati degli snapshot (all’avvio o alla ripresa) e i dati degli snapshot scritti (in sospensione).
    * L’archiviazione di immagini microVM prevede un periodo minimo di conservazione di 1 settimana.

    Trasferimento dati

    Vengono addebitati i costi di trasferimento dei dati alle tariffe di trasferimento dei dati AWS standard. Ti vengono inoltre addebitati i costi per il trasferimento dei dati tra le microVM di Lambda e Amazon VPC, come indicato in  Trasferimento dei dati all’interno della stessa regione AWS.

    MicroVM di Lambda - Esempi di prezzi

    Tutti gli esempi seguenti si basano sui prezzi negli Stati Uniti orientali (Virginia settentrionale), utilizzando l’architettura ARM (Graviton). Per ogni GB di memoria configurato, le microVM Lambda allocano la vCPU in un rapporto 2:1 (ad esempio, la configurazione di 8 GB di memoria alloca 4 vCPU).
    • Supponiamo che tu stia creando una piattaforma che fornisce a ogni sviluppatore un ambiente Linux isolato e in sandbox per la codifica assistita dall’intelligenza artificiale. Ogni ambiente viene eseguito in una microVM Lambda configurata con una baseline di 2 GB di memoria e 1 vCPU che può scalare verticalmente fino a 8 GB di memoria e 4 vCPU per operazioni ad alta intensità di risorse, come la compilazione e l’esecuzione di test. La tua organizzazione gestisce 5 immagini microVM standard (Rust, Python, Node.js, Java, Go), ciascuna da 2 GB. Ogni sviluppatore avvia un ambiente al giorno da un’immagine da 2 GB.​​​​​ ​​​​​​In una giornata lavorativa di 8 ore, ogni ambiente viene utilizzato per 2,5 ore: utilizzando le risorse di base assegnate per il 75% di questo periodo (2 GB e 1 vCPU) e scalando verticalmente fino al picco delle risorse per il 25% di questo periodo (8 GB e 4 vCPU). Durante le restanti 5,5 ore di inattività della giornata lavorativa (quando gli sviluppatori si allontanano o passano ad altre attività) l’ambiente si sospende automaticamente, preservando 2 GB di stato, ad esempio directory di lavoro, stato del processo e cache dei file. Ogni ambiente subisce 6 cicli di sospensione/ripresa al giorno man mano che gli sviluppatori passano dalla codifica alle altre attività. Con la sospensione/ripresa, eviti di pagare per un calcolo sempre attivo durante i periodi di inattività, preservando al contempo lo stato operativo completo. Gli sviluppatori riprendono esattamente da dove avevano lasciato senza riavviare l’ambiente o reinizializzare lo stato. ​ Il tuo team è composto da 100 sviluppatori, ognuno dei quali utilizza la piattaforma di sviluppo per 20 giorni al mese. I costi mensili vengono calcolati come segue:

      Costi mensili di calcolo

      Ricapitolando, il 75% del tempo di calcolo viene impiegato per il consumo di risorse di base e il 25% per il consumo massimo di risorse.

      Secondi di utilizzo di picco: 100 sviluppatori × 20 giorni × 2,5 ore × 25% = 4,5 milioni di secondi
      Costi per l’utilizzo di picco:
      vCPU: 4,5 milioni di secondi × 4 vCPU × 0,0000276944 $/vCPU-secondo = 498,50 $
      Memoria: 4,5 milioni di secondi × 8 GB di memoria × 0,0000036667 $/GB-secondo = 132,00 $
      Totale: 630,50 $

      Secondi di utilizzo di base: 100 sviluppatori × 20 giorni × 2,5 ore × 75% = 13,5 milioni di secondi
      Costi per l’utilizzo di base:
      vCPU: 13,5 milioni di secondi × 1 vCPU × 0,0000276944 $/vCPU-secondo = 373,87 $
      Memoria: 13,5 milioni di secondi × 2 GB di memoria × 0,0000036667 $/GB-secondo = 99,00 $
      Totale: 472,88 $

      Costi mensili di calcolo: 630,50 $ + 472,88 $ = 1.103,38 $

      Costi mensili degli snapshot

      Lettura/scrittura di snapshot:
      Cicli mensili di sospensione/ripresa: 100 sviluppatori × 20 giorni × 6 cicli = 12.000 cicli
      Costi di scrittura (sospensione) degli snapshot: 12.000 cicli × 2 GB × 0,0038 $/GB = 91,20 $
      Costi di lettura (ripresa) degli snapshot: 12.000 cicli × 2 GB × 0,00155 $/GB = 37,20 $

      Avvii mensili: 100 sviluppatori × 1 avvio al giorno × 20 giorni = 2.000 avvii
      Costi di lettura (avvio) degli snapshot: 2.000 lanci × 2 GB × 0,00155 $/GB = 6,20 $

      Costi mensili totali di lettura/scrittura degli snapshot: 91,20 $ + 37,20 $ + 6,20 $ = 134,60 $

      Archiviazione degli snapshot:
      Costi di archiviazione delle immagini microVM: 5 immagini × 2 GB × 0,08 $/GB al mese = 0,80 $
      Costi delle microVM sospese: 100 sviluppatori × 2 GB × (5,5 ore di inattività al giorno × 20 giorni/720 ore) × 0,08 $/GB/mese = 2,44 $

      Costi mensili di archiviazione degli snapshot: 3,24 $  

      Costi mensili totali

      Costi totali = Costi di calcolo + Costi di lettura/scrittura di snapshot + Costi di archiviazione degli snapshot = 1.103,38 $ + 134,60 $ + 3,24 $ = 1.241,22 $

      Costo mensile per sviluppatore: 1.241,22 $/100 = 12,41 $

    • Supponiamo che tu stia creando una piattaforma che esegue scansioni di sicurezza o processi CI/CD per conto di più utenti finali. Ogni processo esegue codice non attendibile o semi-attendibile: installazione delle dipendenze, script di build, scanner di vulnerabilità. Per questo motivo, ogni processo richiede un proprio ambiente isolato a livello hardware. Il traffico è imprevedibile, quindi in precedenza si manteneva in standby un ampio pool di ambienti inattivi per soddisfare i requisiti di latenza. Con le microVM di Lambda gli ambienti si avviano rapidamente a partire dagli snapshot, quindi non è più necessario un pool inattivo. Ogni ambiente è configurato con una baseline di 8 GB di memoria e 4 vCPU che può essere scalata verticalmente fino a 32 GB e 16 vCPU per fasi di compilazione o scansione ad alta intensità di risorse. I processi vengono completati in un’unica operazione; non è necessario sospenderli o riprenderli. Ogni processo viene eseguito per una media di 10 minuti, di cui il 10% al picco (32 GB e 16 vCPU) e il 90% alla baseline (8 GB e 4 vCPU). Mantieni una singola immagine microVM standard (2 GB). Grazie all’avvio basato su snapshot non devi più pagare per i pool di standby inattivi: ogni ambiente si avvia rapidamente su richiesta e termina quando il processo viene completato. La tua piattaforma esegue 10.000 processi al mese. I costi vengono calcolati come segue:

      Costi mensili di calcolo

      Ricapitolando, il 90% del tempo di calcolo viene impiegato per il consumo di risorse di base e il 10% per il consumo massimo di risorse.

      Secondi di utilizzo di picco: 10.000 processi × 600 secondi × 10% = 600.000 secondi
      Costi per l’utilizzo di picco:
      vCPU: 600.000 secondi × 16 vCPU × 0,0000276944 $/vCPU-secondo = 265,87 $
      Memoria: 600.000 secondi × 32 GB di memoria × 0,0000036667 $/GB-secondo = 70,40 $
      Totale: 336,27 $

      Secondi di utilizzo di base: 10.000 processi × 600 s × 90% = 5,4 milioni di secondi
      Costi per l’utilizzo di base:
      vCPU: 5,4 milioni di secondi × 4 vCPU × 0,0000276944 $/vCPU-secondo = 598,20 $
      Memoria: 5,4 milioni di secondi × 8 GB di memoria × 0,0000036667 $/GB-secondo = 158,40 $
      Totale: 756,60 $

      Costi mensili di calcolo: 336,27 $ + 756,60 $ = 1.092,87 $

      Costi mensili degli snapshot

      Lettura/scrittura di snapshot:
      Avvii mensili: 10.000 processi × 1 avvio ciascuno = 10.000 avvii
      Costi di lettura (avvio) degli snapshot: 10.000 avvii × 2 GB × 0,00155 $/GB = 31 $

      Costi mensili totali di lettura/scrittura degli snapshot: 31 $

      Archiviazione degli snapshot:
      Costi di archiviazione delle immagini microVM: 1 immagine × 2 GB × 0,08 $/GB al mese = 0,16 $

      Costi mensili di archiviazione degli snapshot: 0,16 $

      Costi mensili totali

      Costi totali = Costi di calcolo + Costi di lettura/scrittura di snapshot + Costi di archiviazione degli snapshot = 1.092,87 $ + 31 $ + 0,16 $ = 1.124,03 $

      Costo per processo: 1.124,03 $ / 10.000 = 0,112 $​  

  • Funzioni Web

  • Prezzi delle Funzioni Web Lambda

    I prezzi delle funzioni web Lambda si basano sul numero di richieste servite, sul tempo in cui la CPU rimane attiva, sulla memoria consumata e sul trasferimento dati AWS standard.

    Paghi in base alle richieste, al tempo di CPU utilizzata attivamente dal tuo codice e alla memoria consumata da ciascun ambiente di esecuzione per tutto il tempo in cui viene eseguito. Il calcolo viene fatturato con una granularità di 1 ms. Poiché un singolo ambiente di esecuzione può soddisfare più richieste simultanee, l’utilizzo del calcolo e della memoria è condiviso tra tali richieste.

    • Graviton (ARM)
    Richieste

    Il costo viene calcolato in base al numero totale di richieste alle tue funzioni da tutte le origini.

    Trasferimento dati

    Vengono addebitati i costi di trasferimento dei dati alle tariffe di trasferimento dei dati AWS standard. Ti vengono inoltre addebitati i costi per il trasferimento dei dati tra le funzioni web di Lambda e Amazon VPC, come indicato in Trasferimento dei dati all’interno della stessa regione AWS.

    Funzioni web Lambda - Esempi di prezzi

    Gli esempi seguenti mostrano come viene calcolata una fattura mensile per carichi di lavoro rappresentativi. Tutti gli esempi si basano sui prezzi negli Stati Uniti orientali (Virginia settentrionale) su Arm ed escludono il piano gratuito e il trasferimento dei dati per semplificare i calcoli. Il calcolo viene fatturato con una granularità di 1 ms. Ogni ambiente di esecuzione viene fatturato in base alla memoria che consuma, per tutto il tempo di esecuzione, incluso il tempo tra le richieste. Lambda aumenta e riduce il numero di ambienti di esecuzione in base al traffico. Per semplificare i calcoli, questi esempi presuppongono che il traffico sia distribuito uniformemente su un mese di 30 giorni (2.592.000 secondi) e che le richieste arrivino abbastanza spesso da garantire che sia sempre in esecuzione esattamente un ambiente di esecuzione e gestisca tutto il traffico.

    • Supponiamo che tu esegua un’applicazione web renderizzata lato server in cui ogni pagina viene renderizzata sul server al momento della richiesta. L’applicazione serve 15 milioni di richieste al mese. Ogni richiesta richiede 150 ms end-to-end, di cui 40 ms di CPU attiva. L’ambiente di esecuzione consuma circa 500 MB (0,49 GB) di memoria.

      Costi mensili di calcolo

      Il prezzo della vCPU attiva è 0,0000276944 $ per vCPU-secondo e il prezzo della memoria è 0,0000036667 $ per GB-secondo.

      • vCPU attiva: 15.000.000 × 0,040 s = 600.000 vCPU-secondi × 0,0000276944 $ = 16,62 $.
      • Memoria: 0,49 GB × 2.592.000 s = 1.270.080 GB-secondo × 0,0000036667 $ = 4,66 $.

      Costi mensili delle richieste

      • Richieste: 15.000.000 × 0,30 $ per milione = 4,50 $.

      Costi mensili totali

      Costi totali = Costi di calcolo + Costi delle richieste = (16,62 $ + 4,66 $) + 4,50 $ = 25,78 $

    • Supponiamo di eseguire un backend API che trascorre la maggior parte di ogni richiesta in attesa di un database o di un’API downstream. Il servizio gestisce 10 milioni di richieste al mese. Ogni richiesta richiede 200 ms end-to-end, di cui solo 50 ms di CPU attiva. L’ambiente di esecuzione consuma circa 300 MB (0,29 GB) di memoria.

      Costi mensili di calcolo

      • vCPU attiva: 10.000.000 × 0,050 s = 500.000 vCPU-secondi × 0,0000276944 $ = 13,85 $.
      • Memoria: 0,29 GB × 2.592.000 s = 751.680 GB-secondo × 0,0000036667 $ = 2,76 $.

      Costi mensili delle richieste

      • Richieste: 10.000.000 × 0,30 $ per milione = 3,00 $.

      Costi mensili totali

      Costi totali = Costi di calcolo + Costi delle richieste = (13,85 $ + 2,76 $) + 3,00 $ = 19,61 $
      Poiché la CPU viene fatturata mentre il codice è in fase di calcolo attivo, i 50 ms di lavoro attivo sono a pagamento.

    • Supponiamo di eseguire un programma di autorizzazione leggero che viene eseguito a ogni richiesta dell’applicazione. Il servizio gestisce 100 milioni di richieste al mese. Ogni richiesta richiede 50 ms end-to-end, di cui 12 ms di CPU attiva. L’ambiente di esecuzione consuma circa 145 MB (0,14 GB) di memoria.

      Costi mensili di calcolo

      • vCPU attiva: 100.000.000 × 0,012 s = 1.200.000 vCPU-secondi × 0,0000276944 $ = 33,23 $
      • Memoria: 0,14 GB × 2.592.000 s = 362.880 GB-secondi × 0,0000036667 $ = 1,33 $

      Costi mensili delle richieste

      • Richieste: 100.000.000 × 0,30 $ per milione = 30,00 $

      Costi mensili totali

      Costi totali = Costi di calcolo + Costi delle richieste = (33,23 $ + 1,33 $) + 30,00 $ = 64,56 $

    • Supponiamo che tu esegua un servizio che trasmette in streaming i token da un modello linguistico di grandi dimensioni tramite una connessione di lunga durata. Il servizio gestisce 5 milioni di richieste al mese. Ogni richiesta rimane aperta per 3.000 ms end-to-end, e in 200 ms di questi la CPU rimane attiva. L’ambiente di esecuzione consuma circa 512 MB (0,50 GB) di memoria.

      Costi mensili di calcolo

      • vCPU attiva: 5.000.000 × 0,200 s = 1.000.000 vCPU-secondi × 0,0000276944 $ = 27,69 $.
      • Memoria: 0,50 GB × 2.592.000 s = 1.296.000 GB-secondi × 0,0000036667 $ = 4,75 $.

      Costi mensili delle richieste

      • Richieste: 5.000.000 × 0,30 $ per milione = 1,50 $.

      Costi mensili totali

      Costi totali = Costi di calcolo + Costi delle richieste = (27,69 $ + 4,75 $) + 1,50 $ = 33,94 $
      È qui che la fatturazione con CPU attiva è più importante. Ogni richiesta rimane aperta per 3 secondi, ma paghi solo per i 200 ms durante i quali la CPU rimane attiva. La gestione simultanea delle richieste riduce anche il costo della memoria. Poiché ogni richiesta rimane in attesa la maggior parte del tempo anziché utilizzare la CPU, un singolo ambiente di esecuzione può gestire molte richieste contemporaneamente. Con circa sei richieste in corso, esse condividono la memoria di un ambiente, perciò paghi per un ambiente anziché sei.

Risorse aggiuntive sui prezzi

Calcolatore dei prezzi AWS

Calcola facilmente i tuoi costi mensili con AWS

Ottieni assistenza sui prezzi

Contatta gli specialisti AWS per ricevere un preventivo personalizzato