Domande frequenti su AWS Lambda

Per offrire prestazioni migliori, AWS Lambda può mantenere un'istanza della tua funzione e riutilizzarla per gestire una richiesta successiva, invece di creare una nuova copia. Per ulteriori informazioni su come Lambda riutilizza le istanze di funzione, consulta la documentazione. Questo comportamento non deve essere dato sempre per scontato dal codice.

Puoi configurare ciascuna funzione Lambda con il proprio spazio di archiviazione temporaneo compreso tra 512 MB e 10.240 MB, con incrementi di 1 MB. Lo spazio di archiviazione temporaneo è disponibile nella directory /tmp di ciascuna funzione.

Ogni funzione ha accesso a 512 MB di spazio di archiviazione senza alcun costo aggiuntivo. Quando configuri le funzioni con più di 512 MB di spazio di archiviazione temporaneo, l'importo verrà addebitato in base allo spazio configurato e alla durata di esecuzione della funzione, misurata con incrementi di 1 ms. A titolo di confronto, nella regione degli Stati Uniti orientali (Ohio), il prezzo dello spazio di archiviazione temporaneo di AWS Fargate è di 0,000111 USD per GB all'ora o 0,08 USD per GB al mese. Il prezzo del volume di archiviazione gp3 di Amazon EBS negli Stati Uniti orientali (Ohio) è di 0,08 USD per GB al mese. Il prezzo dello spazio di archiviazione temporaneo di AWS Lambda è di 0,0000000309 USD per GB al secondo o 0,000111 USD per GB ora e 0,08 USD per GB al mese. Per ulteriori informazioni, consulta i prezzi di AWS Lambda.

Per monitorare l'utilizzo dello spazio di archiviazione temporaneo, puoi utilizzare i parametri di AWS CloudWatch Lambda Insight. Per maggiori informazioni, consulta la documentazione di AWS CloudWatch Lambda Insights.

Se la tua applicazione necessita di uno spazio di archiviazione duraturo e persistente, considera l'utilizzo di Simple Storage Service (Amazon S3) o Amazon EFS. Se la tua applicazione richiede l'archiviazione dei dati necessari per il codice in una singola chiamata di funzione, considera l'utilizzo dello spazio di archiviazione temporaneo di AWS Lambda come cache transitoria. Per maggiori informazioni, consulta Scelta tra le opzioni di archiviazione dei dati di AWS Lambda nelle app Web.

Sì. Tuttavia, se la tua applicazione necessita di archiviazione persistente, considera l'utilizzo di Amazon EFS o Simple Storage Service (Amazon S3). Se per la funzione abiliti la simultaneità con provisioning, il codice di inizializzazione della funzione viene eseguito durante l’allocazione e ogni poche ore, poiché le istanze in esecuzione della funzione vengono riavviate. Puoi vedere il tempo di inizializzazione nei log e nelle tracce dopo che un'istanza elabora una richiesta. Tuttavia, l'inizializzazione viene fatturata anche se l'istanza non elabora mai una richiesta. Questo comportamento di inizializzazione della simultaneità con provisioning può influire sul modo in cui la funzione interagisce con i dati archiviati nello spazio di archiviazione temporaneo, anche quando la funzione non sta elaborando le richieste. Per ulteriori informazioni sulla simultaneità con provisioning, consulta la relativa documentazione.

Per monitorare l'utilizzo dello spazio di archiviazione temporaneo, puoi utilizzare i parametri di AWS CloudWatch Lambda Insight. Per maggiori informazioni, consulta la documentazione di AWS CloudWatch Lambda Insights.

Se la sintassi in uso è Node.js o Python, è possibile compilare il codice della funzione utilizzando l'editor di codice di cui è dotata la console di AWS Lambda, che permette di scrivere e testare le funzioni e visualizzarne i risultati in un ambiente di tipo IDE. Accedi alla console per iniziare.

Puoi anche creare un pacchetto del codice (e di qualsiasi libreria dipendente) come file ZIP e caricarlo usando la console di AWS Lambda dall'ambiente locale oppure specificare una posizione in Amazon S3 in cui si trova il file ZIP. I caricamenti non devono avere dimensioni maggiori di 50 MB (file compressi). Puoi usare il plug-in AWS per Eclipse per creare e distribuire funzioni Lambda in Java. Puoi usare il plug-in per Visual Studio per creare e distribuire funzioni Lambda in C# e Node.js.

Puoi creare un pacchetto di codice (e di eventuali librerie dipendenti) in formato ZIP e caricarlo usando l'interfaccia a riga di comando di AWS dall'ambiente locale oppure specificare la posizione in Amazon S3 in cui si trova il file ZIP. I caricamenti non devono avere dimensioni maggiori di 50 MB (file compressi). Per iniziare, consulta la guida alle operazioni di base di AWS Lambda.

Sì. Puoi creare e modificare variabili di ambiente tramite la console, l'interfaccia a riga di comando o i kit SDK di AWS Lambda. Per ulteriori informazioni sulle variabili ambientali, consulta la documentazione.

Per informazioni sensibili quali le password di database, consigliamo di utilizzare la crittografia lato client tramite il Sistema AWS di gestione delle chiavi e di archiviare i valori risultanti come testo criptato nella variabile ambientale. Sarà necessario includere nel codice della funzione AWS Lambda la logica necessaria per decrittografare tali valori.

Puoi regolare e proteggere le risorse associate alla tua funzione Lambda utilizzando l'API o la console Lambda. Per ulteriori informazioni, consulta la documentazione.

Sì, puoi inoltre suddividere il codice in pacchetti (framework, SDK, librerie e molto altro) come un livello Lamba e gestirli e condividerli facilmente tra diverse funzioni.

Le funzioni sono monitorate automaticamente da AWS Lambda, comunicando i parametri in tempo reale tramite Amazon CloudWatch, ad esempio richieste totali, utilizzo simultaneo a livello di account e di funzione, latenza, percentuale di errori e richieste respinte a causa delle limitazioni. È anche possibile visualizzare le statistiche per ogni singola funzione Lambda tramite la console di Amazon CloudWatch o la console di AWS Lambda. Inoltre, è possibile richiamare API di monitoraggio di terze parti in una funzione Lambda.
 

Per ulteriori informazioni, visita la pagina sulla risoluzione dei problemi dei parametri di CloudWatch. Per l'uso dei parametri integrati di Lambda vengono applicate le tariffe standard di AWS Lambda.

AWS Lambda si integra automaticamente con Amazon CloudWatch Logs, creando un gruppo di log per ogni funzione Lambda e offrendo voci di log degli eventi del ciclo di vita delle applicazioni, tra cui la registrazione delle risorse utilizzate per ogni funzione. Puoi inserire istruzioni di registrazione aggiuntive nel tuo codice. Puoi anche chiamare API di registrazione di terza parte nella tua funzione Lambda. Per ulteriori informazioni, visita la pagina sulla risoluzione dei problemi delle funzioni Lambda. Vengono applicate le tariffe dei log di Amazon CloudWatch.

Nel modello di risorsa di AWS Lambda puoi scegliere la quantità di memoria desiderata per la tua funzione perché potenza della CPU e altre risorse vengano allocate in modo proporzionale. Se ad esempio scegli 256 MB di memoria, alla tua funzione Lambda verrà allocato circa il doppio di potenza della CPU rispetto a quanto otterresti richiedendo 128 MB di memoria e circa la metà di potenza della CPU rispetto a una richiesta di 512 MB di memoria. Per ulteriori informazioni, consulta la nostra documentazione sulla configurazione delle funzioni.

Puoi scegliere un'impostazione della memoria da 128 MB a 10.240 MB.

Le tariffe di AWS Lambda vengono addebitate in base all'uso. Per ulteriori informazioni, visita la pagina dei prezzi di AWS Lambda.

Sì. Per impostazione predefinita, a ogni funzione di AWS Lambda è associata un'unica versione corrente del codice. I client della funzione Lambda possono richiamare una versione specifica o ottenere l'implementazione più recente. Consulta la documentazione sul controllo delle versioni delle funzioni Lambda.

AWS Lambda offre scaglioni di prezzo scontati per una durata della funzione on-demand superiore a determinate soglie. I prezzi a scaglioni sono disponibili per le funzioni in esecuzione su entrambe le architetture x86 e Arm. Gli scaglioni di prezzo di Lambda vengono applicati alla durata on-demand 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, gli scaglioni di prezzo vengono applicati alla durata mensile aggregata delle funzioni in esecuzione sulla medesima architettura, nella medesima regione, nei vari account dell'organizzazione. Ad esempio, se esegui funzioni Lambda x86 nella regione Stati Uniti orientali (Ohio), pagherai 0,0000166667 USD per ogni GB/secondo per i primi 6 miliardi di GB/secondo al mese, 0,0000150000 USD per ogni GB/secondo per i successivi 9 miliardi di GB/secondo al mese e 0,0000133334 USD per ogni GB/secondo oltre i 15 miliardi di GB/secondo al mese, in quella regione. I prezzi per le richieste, la simultaneità fornita e la durata della simultaneità fornita rimangono inalterati. Per ulteriori informazioni, consulta la pagina Prezzi di AWS Lambda

Sì. L'utilizzo di Lambda coperto dall'impegno del Savings Plan orario viene fatturato alla tariffa CSP con sconto applicabile. L'utilizzo restante non coperto da tale impegno verrà fatturato alla tariffa corrispondente allo scaglione in cui rientrata la durata della funzione aggregata mensile.

Per un elenco completo delle origini degli eventi, consulta la documentazione.

Gli eventi vengono passati a una funzione Lambda come parametro di input di evento. Per le origini di eventi in cui gli eventi arrivano in batch, come Amazon SQS, Amazon Kinesis e Amazon DynamoDB Streams, il parametro dell'evento può contenere più eventi in una singola chiamata, in base alla dimensione del batch richiesto. Per ulteriori informazioni sulle notifiche degli eventi Amazon S3, visita la pagina Configurazione delle notifiche eventi Amazon S3. Per ulteriori informazioni sui flussi Amazon DynamoDB, consulta la guida per gli sviluppatori di flussi DynamoDB. Per ulteriori informazioni su come richiamare funzioni Lambda con Amazon SNS, consulta la guida per gli sviluppatori Amazon SNS. Per ulteriori informazioni sugli eventi di Amazon Cognito, visita la pagina Amazon Cognito. Per ulteriori informazioni sui log di AWS CloudTrail e le chiamate API di controllo tra servizi AWS, visita la pagina AWS CloudTrail.

AWS Lambda consente di eseguire aggregazioni basate sul tempo (ad esempio conteggio, massimo, somma, media, ecc.), per un breve periodo fino a 15 minuti, per i dati in Amazon Kinesis o flussi Amazon DynamoDB, su una singola partizione logica come uno shard. In questo modo puoi configurare facilmente delle semplici analisi per la tua applicazione basata su eventi senza aggiungere complessità architetturali, poiché la tua logica aziendale e analitica può essere collocata nella stessa funzione. Lambda consente di effettuare aggregazioni su un periodo massimo di 15 minuti di una finestra a cascata, in base al time stamp dell'evento. L'Analisi dei dati Amazon Kinesis consente di creare applicazioni di analisi più complesse che supportano scelte di elaborazione flessibili e una tolleranza agli errori affidabile, con singola elaborazione priva di duplicati, e analisi da eseguire su un intero flusso di dati su più partizioni logiche. Grazie a KDA puoi analizzare i dati su più tipi di finestre di aggregazione (finestra a cascata, finestra sfalsata, finestra scorrevole, finestra di sessione) utilizzando l'orario dell'evento o il tempo di elaborazione.
 

Prima di tutto, configura l'allarme per l'invio di notifiche di Amazon SNS. Dalla console di AWS Lambda seleziona quindi una funzione Lambda e associala all'argomento di Amazon SNS. Per ulteriori informazioni sulla configurazione degli allarmi di Amazon CloudWatch, consulta la guida per gli sviluppatori di Amazon CloudWatch.

Dalla console di AWS Lambda, è possibile selezionare una funzione da attivare quando viene sincronizzato un set di dati associato a un pool di identità di Amazon Cognito. La stessa funzionalità è disponibile anche tramite il kit SDK AWS e l'interfaccia a riga di comando. Per ulteriori informazioni su come usare Amazon Cognito per condividere e sincronizzare i dati tra i dispositivi di un utente, visita la pagina dedicata a questo servizio.

Puoi richiamare una funzione Lambda usando un evento personalizzato tramite l'API di chiamata di AWS Lambda. La funzione può essere richiamata solo dal suo proprietario o da un altro account AWS a cui il proprietario abbia concesso il permesso. Per ulteriori informazioni, consulta la Guida per gli sviluppatori Lambda.

Carica il codice che deve essere eseguito da AWS Lambda e quindi richiamalo dall'app mobile usando l'SDK AWS Lambda incluso nell'SDK AWS Mobile. Puoi effettuare sia chiamate dirette (sincrone) per recuperare o controllare i dati in tempo reale sia chiamate asincrone. Puoi anche definire un'API personalizzata tramite Amazon API Gateway e richiamare le funzioni Lambda tramite qualsiasi client compatibile con REST. Per ulteriori informazioni sull'SDK mobile AWS, visita la pagina SDK mobile AWS. Per ulteriori informazioni su Gateway Amazon API, visita la pagina Gateway Amazon API.

Il Repository dell'applicazione serverless AWS offre una raccolta di applicazioni serverless pubblicate da sviluppatori, aziende e partner nella community AWS. Dopo aver individuato un'applicazione, puoi configurarla e implementarla direttamente dalla console Lambda.

È possibile automatizzare il processo di rilascio di applicazioni senza server utilizzando AWS CodePipeline e AWS CodeDeploy. CodePipeline è un servizio di distribuzione continua che consente modellizzazione, visualizzazione e automatizzazione delle fasi necessarie al rilascio delle applicazioni senza server. CodeDeploy offre un motore di automatizzazione delle distribuzioni per le applicazioni basate su Lambda. Questo servizio permette di orchestrare le distribuzioni secondo best-practice consolidate, ad esempio distribuzioni canary o lineari, e aiuta a costruire barriere per verificare che codice appena distribuito sia sicuro, stabile e pronto per andare in produzione.
 

Per ulteriori informazioni su CI/CD serverless, consulta la documentazione.

Per iniziare, visita la console di AWS Lambda e scarica uno dei nostri blueprint. Il download conterrà un file SAM (che definisce le risorse AWS nell'applicazione) e un file .ZIP (che include il codice dell'applicazione). Potrai usare i comandi di AWS CloudFormation per creare pacchetti e implementare l'applicazione senza server scaricata. Per ulteriori informazioni, consulta la documentazione.

È possibile utilizzare AWS Step Functions per coordinare una serie di funzioni AWS Lambda in un ordine specifico. È possibile richiamare più funzioni Lambda in ordine sequenziale, trasferire il risultato dall’una all’altra e/o in parallelo; Step Functions manterrà lo stato durante le esecuzioni per conto dell’utente.

È possibile abilitare il tracciamento di una funzione Lambda utilizzando AWS X-Ray; è sufficiente aggiungere le autorizzazioni per X-Ray nel ruolo di esecuzione della funzione Lambda e modificare il parametro "tracing mode" ("modalità di tracciamento") della funzione in "active" ("attivo"). Quando X-Ray è abilitato per la funzione Lambda, AWS Lambda inoltrerà ad X-Ray le informazioni di traccia riguardanti il carico operativo del servizio al momento della chiamata della funzione. Sarà pertanto possibile ottenere informazioni approfondite tra cui il carico del servizio Lambda nonché i tempi di inizializzazione e di esecuzione della funzione. Inoltre, sarà possibile il kit SDK X-Ray al pacchetto di distribuzione di Lambda per creare segmenti di tracciatura personalizzati, annotare le tracce o visualizzare i segmenti per le chiamate a valle effettuate dalla funzione lambda. I kit SDK X-Ray sono attualmente disponibili per Node.js e Java. Consulta la pagina sulla risoluzione dei problemi delle applicazioni basate su Lambda per ulteriori informazioni. Saranno applicate le tariffe di AWS X-Ray.

Sì. Puoi creare applicazioni serverless altamente scalabili, sicure e basate su Lambda che si connettono a database relazionali utilizzando il Server proxy per Amazon RDS, un proxy di database ad alta disponibilità che gestisce migliaia di connessioni simultanee a database relazionali. Attualmente, RDS Proxy supporta i database MySQL e Aurora. Puoi iniziare utilizzando RDS Proxy tramite la console Amazon RDS o la console AWS Lambda. La fatturazione delle applicazioni serverless che utilizzano pool di connessioni completamente gestite da Server proxy per RDS sarà effettuata in base ai prezzi di Server proxy per RDS.

La specifica è open source sotto licenza Apache 2.0, perciò è possibile utilizzare e integrare AWS SAM in strumenti per creazione di build, sviluppo, monitoraggio e gestione con una licenza commercial-friendly. Puoi accedere al repository AWS SAM su GitHub qui.

Sono tre le differenze principali tra le funzioni create utilizzando gli archivi ZIP e utilizzando le immagini di container:

1. Le funzioni create utilizzando archivi ZIP hanno una dimensione massima del pacchetto di codice pari a 250 MB decompressi, mentre quelle create utilizzando immagini di container hanno una dimensione massima dell'immagine pari a 10 GB. 
2. Lambda utilizza Amazon ECR come storage del codice sottostante per le funzioni definite come immagini di container, pertanto potrebbe non essere possibile richiamare una funzione quando l'immagine sottostante viene eliminata da ECR. 
3. Alle funzioni ZIP vengono applicate automaticamente patch per la sicurezza di runtime e la correzione di bug più recenti. Non è possibile modificare le funzioni definite come immagini di container e i clienti sono responsabili dei componenti inseriti nel pacchetto nella loro funzione. I clienti possono avvalersi delle immagini di base fornite da AWS, che vengono regolarmente aggiornate da AWS utilizzando le patch più recenti disponibili per la sicurezza e la correzione di bug.

Non sono previsti costi aggiuntivi per la creazione di pacchetti e la distribuzione di funzioni come immagini di container in AWS Lambda. Quando richiami la funzione distribuita come immagine di container, paghi il prezzo normale previsto per le richieste e la durata dell'esecuzione. Per ulteriori informazioni, visita la pagina dei prezzi di AWS Lambda. L’archiviazione delle immagini di container in Amazon ECR ti verrà addebitato ai prezzi standard di ECR. Per ulteriori informazioni, visita la pagina dei prezzi di Amazon ECR.

L'emulatore di interfaccia di runtime Lambda è un proxy per l'API Runtime di Lambda che consente ai clienti di testare in locale la loro funzione Lambda impacchettata come immagine di container. È un server web leggero che converte le richieste HTTP in eventi JSON ed emula l'API Runtime di Lambda. Ti consente di testare localmente le tue funzioni utilizzando strumenti consueti come cURL e Docker CLI (durante il test di funzioni impacchettate come immagini di container). Inoltre, semplifica l'esecuzione della tua applicazione su servizi di elaborazione aggiuntivi. Puoi includere il Lambda Runtime Interface Emulator nell'immagine di container affinché accetti le richieste HTTP in modo nativo, al posto degli eventi JSON richiesti per la distribuzione in Lambda. Questo componente non emula lo strumento di orchestrazione di Lambda o le configurazioni di sicurezza e autenticazione. Il Runtime Interface Emulator è disponibile in modalità open source su GitHub. Puoi iniziare scaricandolo e installandolo sul tuo computer locale.

I clienti possono aggiungere Runtime Interface Emulator come punto di ingresso all'immagine di container o impacchettarlo come un sidecar per assicurarsi che l'immagine di container ora accetti richieste HTTP anziché eventi JSON. Ciò semplifica le modifiche necessarie per eseguire l'immagine di container su servizi di elaborazione aggiuntivi. Sarà responsabilità dei clienti assicurarsi di seguire tutte le best practice in materia di sicurezza, prestazioni e concorrenza per l'ambiente prescelto. RIE è pre-impacchettato nelle immagini fornite da AWS Lambda ed è disponibile in AWS SAM CLI come impostazione predefinita. I fornitori di immagini di base possono utilizzare la documentazione per fornire la stessa esperienza alle loro immagini di base.

Puoi distribuire un'applicazione containerizzata in AWS Lambda se soddisfa i seguenti requisiti:

1. L'immagine di container deve implementare l'API Runtime di Lambda. Abbiamo reso open source una serie di pacchetti software, Runtime Interface Clients (RIC), che implementano l'API Runtime di Lambda, consentendoti di estendere senza problemi le tue immagini di base preferite per renderle compatibili con Lambda.
2. L'immagine di container deve essere in grado di funzionare su un filesystem di sola lettura. Il codice della tua funzione può accedere a una memoria di directory scrivibile /tmp pari a 512 MB. Se stai usando un'immagine che richiede una directory root scrivibile, configurala per scrivere nella directory /tmp.
3. I file necessari per l'esecuzione del codice della funzione possono essere letti dall'utente Lambda predefinito. Lambda definisce un utente Linux predefinito con autorizzazioni con privilegi minimi che segue le best practice di sicurezza. È necessario verificare che il codice dell'applicazione non si basi su file con limitazioni imposte da altri utenti Linux relative all'esecuzione.
4. È un'immagine di container basata su Linux.

AWS 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 richiamata, Lambda riprende gli ambienti di esecuzione da questo snapshot preinizializzato invece di inizializzarli da zero, migliorando la latenza di avvio. Per la resilienza, Lambda mantiene le copie memorizzate nella cache dello snapshot e applica automaticamente gli aggiornamenti software, come aggiornamenti di runtime e patch di sicurezza.

Lambda SnapStart è una semplice configurazione a livello di funzione che può essere configurata per funzioni nuove ed esistenti utilizzando l'API Lambda, la Console di gestione AWS, l'interfaccia a riga di comando (CLI) AWS, l'AWS Cloud Development Kit (CDK), AWS CloudFormation e AWS Serverless Application Model (SAM). Quando configuri Lambda SnapStart, ogni versione della funzione pubblicata successivamente beneficia delle migliori prestazioni di avvio offerte da Lambda SnapStart. Per ulteriori informazioni su Lambda SnapStart, consulta la documentazione.

Lambda SnapStart è un'ottimizzazione delle prestazioni che consente alle funzioni di ottenere tempi di avvio più rapidi riducendo la latenza variabile sostenuta durante l'esecuzione di un codice di inizializzazione una tantum. Sebbene Lambda SnapStart riduca la latenza di avvio, funziona come ottimizzazione best-effort e non garantisce l'eliminazione degli avvii a freddo. Se la tua applicazione ha requisiti di latenza rigorosi e richiede tempi di avvio in millisecondi a due cifre, ti consigliamo di utilizzare PC.

Lambda SnapStart supporta più runtime, tra cui Java 11 (e versioni successive), Python 3.12 (e versioni successive) e .NET 8 (e versioni successive). Le versioni future dei runtime saranno supportate dopo il loro rilascio. Per tutti i runtime supportati da Lambda, consulta la documentazione dei runtime Lambda.

Sì. Una funzione Lambda SnapStart può essere configurata per accedere alle risorse in un cloud privato virtuale (VPC). Per ulteriori informazioni su come configurare la funzione con un VPC, consulta la documentazione di Lambda.

Sì. È possibile configurare Lambda SnapStart per le funzioni eseguite su architetture x86 e Arm.

Sì. Se il tuo codice presuppone l'univocità dello stato, devi valutare la resilienza del tuo codice alle operazioni dello snapshot (come la clonazione e la ripresa). Per saperne di più sulle considerazioni sull'unicità con Lambda SnapStart, consulta la documentazione e il blog sulla comprensione dell'unicità negli snapshot delle macchine virtuali con Lambda SnapStart.

Sì. Puoi implementare la tua logica software prima di creare (con un checkpoint) uno snapshot e dopo aver ripristinato uno snapshot utilizzando gli hook di runtime. Per maggiori informazioni, consulta la documentazione di Lambda SnapStart.

Sì, ti verrà 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, ti 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 alla funzione. Per ulteriori informazioni sui prezzi, consulta la pagina Prezzi di AWS Lambda.

I prezzi di SnapStart non si applicano ai runtime gestiti da Java supportati, che possono memorizzare nella cache uno snapshot solo per un massimo di 14 giorni.

Come a tutte le funzioni Lambda, alle funzioni SnapStart si applicano costi di durata. Per le funzioni che utilizzano SnapStart, la durata include il tempo necessario per il caricamento del runtime, qualsiasi codice eseguito in un hook di runtime e il codice di inizializzazione eseguito durante la creazione di copie snapshot per la resilienza.

Con Lambda SnapStart per Python e .NET, gli snapshot delle funzioni rimangono attivi finché la funzione è attiva. Per le funzioni Java, lo snapshot associato a una funzione pubblicata scade se rimane inattivo per più di 14 giorni.

Gli snapshot vengono crittografati per impostazione predefinita con chiavi AWS Key Management Service (KMS) univoche del cliente di proprietà e gestite dal servizio Lambda. I clienti possono crittografare gli snapshot anche utilizzando una chiave KMS di proprietà e gestita dal cliente.

Puoi configurare la simultaneità sulla tua funzionalità attraverso la console di gestione AWS, l'API di Lambda, la CLI AWS e AWS CloudFormation. Il modo più semplice per sfruttare Provisioned Concurrency è tramite l'utilizzo di AWS Auto Scaling. Puoi utilizzare Application Auto Scaling per configurare le pianificazioni o lascia che Auto Scaling regoli automaticamente il livello di Provisioned Concurrency in tempo reale in base alle necessità. Per ulteriori informazioni sulla simultaneità fornita, consulta la documentazione.

Provisioned Concurrency aggiunge una dimensione di prezzi, per Provisioned Concurrency, per mantenere inizializzate le funzioni. Quando abilitato, l'importo verrà calcolato in base alla quantità di simultaneità e alla durata configurate. Quando è in esecuzione una funzione su cui è configurato Provisioned Concurrency, i prezzi sono calcolati anche sulle richieste e sulla durata dell'esecuzione. Per ulteriori informazioni sui prezzi della simultaneità fornita, consulta i prezzi di AWS Lambda.

Generalmente, i linguaggi interpretati come Python, Java e Node non richiedono la ricompilazione, a meno che il tuo codice non faccia riferimento alle librerie che utilizzano componenti specifiche dell’architettura. In tal caso, sarà necessario fornire le librerie in questione ad arm64. Per maggiori informazioni, visita la pagina Nozioni di base su AWS Graviton. Per i linguaggi non interpretati, sarà necessario compilare il codice per l’arm64 di destinazione. Mentre compiler più moderni produrranno un codice compilato per arm64, tu dovrai implementarlo in un ambiente basato su Arm per testarlo. Per maggiori informazioni sull'utilizzo delle funzioni Lambda con Graviton2, consulta la documentazione.

Al momento dell’avvio, i clienti possono utilizzare Python, Node.js, Java, Ruby, Net Core, Custom Runtime (provided.al2) e immagini OCI Base. Per ulteriori informazioni, consulta la documentazione sui runtime di AWS Lambda.

Ogni carico di lavoro è unico e per questo consigliamo ai clienti di testare le loro funzioni per capire quali miglioramenti in termini di prezzo potrebbero riscontrare. Per farlo, consigliamo di utilizzare lo strumento Power Tuning di AWS Lambda. Consigliamo di iniziare con i backend Web e mobili, i dati e l'elaborazione dei flussi durante il test dei carichi di lavoro per potenziali miglioramenti delle prestazioni di prezzo.

Gli sviluppatori possono collegare facilmente un file system EFS esistente a una funzione Lambda tramite un punto di accesso EFS utilizzando la console, la CLI o l'SDK. Quando la funzione viene richiamata per la prima volta, il file system viene automaticamente montato e reso disponibile per il codice funzione. Scopri di più nella documentazione.

Non sono previsti costi aggiuntivi per l'utilizzo di Amazon EFS for AWS Lambda. I costi previsti per i clienti di AWS Lambda e Amazon EFS sono standard. ll trasferimento dei dati con Lambda ed EFS nella stessa zona di disponibilità non comporta alcun costo per i clienti. Tuttavia, l'utilizzo da parte dei clienti delle connessioni peer VPC per l'accesso tra più account comporta costi di trasferimento dei dati. Per ulteriori informazioni, consulta la pagina relativa ai prezzi.

È possibile configurare un URL di funzione per la propria funzione attraverso AWS Management Console, AWS Lambda API, AWS CLI, AWS CloudFormation e AWS Serverless Application Model. Gli URL delle funzioni possono essere abilitati sulla versione non qualificata $LATEST della tua funzione o su qualsiasi alias di funzione. Per saperne di più su come configurare una funzione URL, consulta la documentazione.

Sì. Gli URL delle funzioni Lambda possono essere abilitati su una funzione o un alias di funzione. Se non viene specificato alcun alias, l'URL è indirizzata per modalità predefinita a $LATEST. Le URL di funzione non possono puntare una singola versione di funzione.

Non c'è nessun costo aggiuntivo per l'utilizzo di URL di funzione. Paghi il prezzo standard per AWS Lambda. Per ulteriori informazioni, consulta i prezzi di AWS Lambda.

Lambda@Edge consente di eseguire il codice in tutte le sedi AWS a livello globale senza effettuare il provisioning o gestire i server, inviando risposte agli utenti finali alla latenza di rete più bassa possibile. È sufficiente caricare il codice Node.js o Python in AWS Lambda e configurare la funzione in modo che venga attivata in risposta alle richieste di Amazon CloudFront (ad esempio quando arriva una richiesta di visualizzazione, quando viene inoltrata o ricevuta una richiesta dall'origine e subito prima della risposta all'utente finale). Il codice è quindi pronto per essere eseguito in qualsiasi edge location AWS da cui è stata ricevuta la richiesta, ridimensionando le risorse in base al volume di richieste di CloudFront globali. Per ulteriori informazioni, consulta la nostra documentazione.

Per utilizzare Lambda@Edge è sufficiente caricare il codice su AWS Lambda e associare una versione della funzione da attivare in risposta alle richieste di Amazon CloudFront. Il codice deve soddisfare le limitazioni di servizio di Lambda@Edge. Al momento Lambda@Edge supporta codice Node.js e Python per le chiamate globali da parte di eventi CloudFront. Per ulteriori informazioni, consulta la nostra documentazione.

Lambda@Edge è ottimizzato per i casi d'uso sensibili alla latenza in cui i visualizzatori finali sono distribuiti a livello globale. Idealmente, tutte le informazioni necessarie per prendere una decisione sono disponibili presso una edge location CloudFront, tra funzione e richiesta. Pertanto, nei casi d'uso in cui è necessario prendere decisioni su come distribuire i contenuti in base alle caratteristiche degli utenti (ad esempio, posizione, dispositivo client e così via), l'elaborazione può essere eseguita in prossimità degli utenti, senza dover reindirizzare i dati a un server centralizzato.

È possibile associare funzioni Lambda esistenti con eventi CloudFront per chiamate globali se la funzione soddisfa requisiti e limitazioni di Lambda@Edge. Puoi trovare ulteriori informazioni su come aggiornare le proprietà delle funzioni qui.

Le funzioni disponibili si attiveranno automaticamente in risposta ai seguenti eventi di Amazon CloudFront:

• Richiesta visualizzatore: questo evento si verifica quando un utente finale o un dispositivo collegato a Internet invia una richiesta HTTP(S) a CloudFront e la richiesta arriva alla edge location più vicina all'utente.
• Risposta visualizzatore – Questo evento si verifica quando il server di CloudFront nella edge location è pronto per rispondere all’utente finale o al dispositivo che ha inviato la richiesta.
• Richiesta origine: questo evento si verifica quando il server edge di CloudFront non contiene già l'oggetto richiesto nella propria cache e la richiesta del visualizzatore è pronta per essere inviata al server Web di origine del back-end (ad es. Amazon EC2 o Application Load Balancer o Amazon S3).
• Risposta origine: questo evento si verifica quando il server di CloudFront della edge location riceve una risposta dal server Web di origine del back-end.

La differenza è nella portata: API Gateway e Lambda sono servizi regionali. Con Lambda@Edge e Amazon CloudFront, è possibile eseguire operazioni in diverse sedi AWS in base alla posizione degli utenti finali.

No. AWS Lambda è progettato per l'esecuzione in parallelo di molte istanze delle tue funzioni. AWS Lambda impone tuttavia un limite di sicurezza predefinito di esecuzioni simultanee per account per ogni regione (puoi trovare ulteriori informazioni sui limiti di sicurezza predefiniti qui). È anche possibile controllare il numero massimo di esecuzioni simultanee per singole funzioni AWS Lambda per cui riservare un sottoinsieme di concorrenza del tuo account per le funzioni critiche,, ad esempio per le funzioni più importanti o per porre un tetto al tasso di traffico verso le risorse a valle.

Se desideri inviare una richiesta per aumentare il limite di esecuzioni simultanee, puoi utilizzare Service Quotas per presentare una richiesta di aumento del limite.

Una volta superato il limite massimo di esecuzioni simultanee, le funzioni AWS Lambda richiamate in modo sincrono restituiscono un errore di limitazione (della larghezza di banda della rete) (codice di errore 429). Le funzioni Lambda richiamate in modo asincrono possono assorbire notevoli aumenti di traffico per circa 15-30 minuti, dopo i quali gli eventi in entrata vengono rifiutati come limitati. Se la funzione Lambda viene richiamata in risposta a eventi di Amazon S3, gli eventi rifiutati da AWS Lambda possono essere mantenuti e ritentati da S3 per 24 ore. Gli eventi provenienti da flussi Amazon Kinesis e flussi Amazon DynamoDB vengono ritentati fino a quando la funzione Lambda non riesce o fino allo scadere dei dati. I flussi Amazon Kinesis e Amazon DynamoDB mantengono i dati per 24 ore.

Il limite massimo predefinito di esecuzioni simultanee si applica a livello di account. Tuttavia, è inoltre possibile impostare limiti anche su singole funzioni (vai qui per informazioni sulla simultaneità riservata).

Ogni funzione Lambda richiamata in modo sincrono può dimensionare a una velocità fino a 1000 esecuzioni simultanee ogni 10 secondi. Sebbene la velocità di dimensionamento di Lambda sia adeguata alla maggior parte dei casi d'uso, risulta particolarmente adatta a quelli con picchi di traffico prevedibili o imprevedibili. Ad esempio, l'elaborazione dei dati associati all'accordo sul livello di servizio (SLA) richiede un dimensionamento prevedibile ma rapido per soddisfare la domanda di elaborazione. Allo stesso modo, la pubblicazione di articoli su ultime notizie o su vendite lampo può generare livelli di traffico imprevedibili in un breve periodo di tempo. La velocità di dimensionamento di Lambda può facilitare i casi d'uso in questione senza configurazioni o strumenti aggiuntivi. Inoltre, il limite di dimensionamento della simultaneità è un limite a livello di funzione, il che significa che ogni funzione dell'account si dimensiona indipendentemente dalle altre funzioni.

Se si supera la policy di ripetizione tentativi per le invocazioni asincrone, è possibile configurare una coda DLQ all'interno della quale verrà inserito l'evento; in assenza di una coda DLQ configurata, l'evento potrebbe essere rifiutato. Quando si supera la policy di ripetizione tentativi per le invocazioni basate sui flussi, i dati sarebbero già scaduti e pertanto rifiutati.

Puoi concedere alla tua funzione Lambda i permessi necessari per accedere ad altre risorse usando un ruolo IAM. AWS Lambda assume il ruolo durante l'esecuzione della funzione Lambda, assicurandoti sempre il controllo completo e sicuro esattamente su tutte le risorse AWS che possono essere usate dalla funzione. Per ulteriori informazioni sui ruoli, visita la pagina Configurazione di AWS Lambda.

Quando configuri un bucket Amazon S3 per l'invio di messaggi a una funzione di AWS Lambda, viene creata una regola di policy per le risorse per la concessione dell'accesso. Per ulteriori informazioni sulle policy delle risorse e dei controlli degli accessi per le funzioni Lambda, consulta la Guida per gli sviluppatori di Lambda.

I controlli degli accessi vengono gestiti tramite il ruolo della funzione Lambda. Il ruolo assegnato alla funzione Lambda determina anche le risorse di cui AWS Lambda può eseguire il polling per conto della funzione. Per ulteriori informazioni, consulta la Guida per gli sviluppatori AWS Lambda.

Puoi abilitare le funzioni Lambda per accedere alle risorse nel tuo VPC specificando la sottorete e il gruppo di sicurezza come parte della configurazione della funzione. Le funzioni Lambda configurate per accedere alle risorse in un cloud privato virtuale specifico non hanno di default accesso a Internet. Per concedere Internet a queste funzioni, utilizza i gateway Internet. Per impostazione predefinita, le funzioni Lambda comunicano con le risorse in un VPC dual stack su IPv4. Puoi configurare le tue funzioni per accedere alle risorse in un VPC dual stack su IPv6. Per maggiori dettagli sulle funzioni Lambda configurate con VPC, consulta Rete privata Lambda con VPC.

La firma del codice per AWS Lambda offre controlli di affidabilità e integrità che ti consentono di verificare che nelle funzioni Lambda venga distribuito solo codice inalterato proveniente da sviluppatori approvati. Puoi utilizzare AWS Signer, un servizio di firma del codice completamente gestito, per firmare digitalmente gli artefatti di codice e configurare le funzioni Lambda al fine di verificare le firme durante l'implementazione. La firma del codice per AWS Lambda è attualmente disponibile solo per le funzioni impacchettate come archivi ZIP.

Puoi creare artefatti di codice con firma digitale utilizzando un profilo di firma tramite la console AWS Signer, l'API del firmatario, la CLI SAM o la CLI di AWS. Per ulteriori informazioni, consulta la documentazione per AWS Signer.

Durante l’implementazione AWS Lambda può eseguire i seguenti controlli della firma:

• Firma corrotta: si verifica se l'elemento di codice è stato modificato dopo la firma.
• Firma non corrispondente: si verifica se l'elemento di codice è firmato da un profilo di firma non approvato.
• Firma scaduta: si verifica se la firma ha superato la data di scadenza configurata.
• Firma revocata: si verifica se il proprietario del profilo di firma revoca le attività di firma.

Per ulteriori informazioni, consulta la documentazione su AWS Lambda.

Non sono previsti costi aggiuntivi per l'utilizzo di firma del codice per AWS Lambda. Paghi il prezzo standard per AWS Lambda. Per ulteriori informazioni, consulta la pagina relativa ai prezzi.

Per offrirti un'esperienza di registrazione semplificata e migliorata di default, AWS Lambda offre controlli di registrazione avanzati come la capacità di acquisire nativamente i log delle funzioni Lambda in formato strutturato JSON, controllare il filtraggio a livello di log dei log delle funzioni Lambda senza apportare modifiche al codice e personalizzare il gruppo di log di Amazon CloudWatch a cui Lambda invia i log.

Puoi acquisire i log delle funzioni Lambda in formato strutturato JSON senza dover utilizzare le tue librerie di registrazione. I log strutturati JSON semplificano la ricerca, il filtraggio e l'analisi di grandi volumi di voci di log. È possibile controllare il filtraggio a livello di log dei log delle funzioni Lambda senza apportare modifiche al codice, il che consente di scegliere il livello di granularità di registrazione richiesto per le funzioni Lambda senza setacciare grandi volumi di log durante il debug e la risoluzione degli errori. Inoltre, puoi impostare a quale gruppo di log di Amazon CloudWatch Lambda invia i log, semplificando l'aggregazione dei log di più funzioni all'interno di un'applicazione in un'unica posizione. È quindi possibile applicare le policy di sicurezza, governance e conservazione ai log a livello di applicazione anziché singolarmente a ciascuna funzione.

Puoi specificare controlli di registrazione avanzati per le tue funzioni Lambda utilizzando l'API AWS Lambda, la console AWS Lambda, AWS CLI, AWS Serverless Application Model (SAM) e AWS CloudFormation. Per saperne di più, leggi il post sul blog di lancio per i controlli di registrazione avanzati o la Guida per gli sviluppatori di Lambda.

Sì, puoi utilizzare le tue librerie di registrazione per generare log Lambda in formato strutturato JSON. Per garantire che le tue librerie di registrazione funzionino perfettamente con la funzionalità di registrazione strutturata JSON nativa di Lambda, Lambda non codificherà due volte i log generati dalla tua funzione che sono già codificati in JSON. Puoi anche utilizzare la libreria Powertools for AWS Lambda per acquisire i log Lambda in formato strutturato JSON.

Non sono previsti costi aggiuntivi per l'utilizzo dei controlli di registrazione avanzati su Lambda. L'importazione e l'archiviazione dei log Lambda continueranno a essere addebitati da File di log Amazon CloudWatch. Consulta la pagina dei prezzi di CloudWatch per i dettagli sui prezzi dei log.

CloudWatch Application Signals è una soluzione di monitoraggio delle prestazioni delle applicazioni (APM, Application Performance Monitoring) che consente a sviluppatori e operatori di monitorare facilmente l’integrità e le prestazioni delle applicazioni serverless create con Lambda. Application Signals fornisce dashboard predefinite e standardizzate per i parametri critici delle applicazioni, le tracce correlate e le interazioni tra le funzioni Lambda e le relative dipendenze, il tutto senza richiedere strumentazione manuale o modifiche al codice da parte degli sviluppatori.

Puoi abilitare Application Signals per la tua funzione con un solo clic nella sezione degli strumenti operativi e di monitoraggio nella scheda Configurazione nella console Lambda. Dopo aver abilitato Application Signals, puoi visualizzare dashboard predefinite, mappe dei servizi e altro ancora e analizzare le prestazioni e l’integrità delle tue applicazioni serverless nella console CloudWatch. Per saperne di più, consulta la Guida per gli sviluppatori AWS Lambda e l’Application Signals developer guide. Visita la pagina dei prezzi di CloudWatch per saperne di più su come ti viene addebitato l'utilizzo di Application Signals con le funzioni Lambda.

CloudWatch Logs Live Tail è una funzionalità interattiva di streaming e analisi dei log che fornisce visibilità in tempo reale nei log, semplificando lo sviluppo e la risoluzione dei problemi delle funzioni Lambda. Ciò consente agli sviluppatori di testare e convalidare rapidamente le modifiche al codice o alla configurazione in tempo reale, accelerando il ciclo author-test-deploy (noto anche come "ciclo di sviluppo interno") durante la creazione di applicazioni con Lambda. Inoltre, l'esperienza Live Tail consente agli operatori e ai team DevOps di rilevare ed eseguire il debug di guasti ed errori critici nel codice della funzione Lambda, riducendo il tempo medio di ripristino durante la risoluzione degli errori della funzione Lambda.

Per utilizzare Live Tail per la tua funzione Lambda, vai alla console Lambda e fai clic sul pulsante "Apri CloudWatch Live Tail" nell'editor del codice. Per ulteriori informazioni, consulta il documento Guida per gli sviluppatori AWS Lambda. Visita la pagina dei prezzi di CloudWatch per saperne di più su come ti viene addebitato l'utilizzo di Live Tail con le funzioni Lambda.

Per compilare una funzione Lambda, è possibile avvalersi di strumenti come Maven o Gradle. Il processo di compilazione deve simulare lo stesso processo che useresti per compilare qualsiasi codice Java che dipende dall'SDK AWS. Esegui il compilatore Java nei file di origine e includi l'SDK AWS versione 1.9 o successiva con dipendenze transitive dal classpath. Per ulteriori informazioni, consulta la documentazione.

Sì. Puoi usare pacchetti NPM e pacchetti personalizzati. Ulteriori informazioni sono disponibili qui.

Sì. La sandbox integrata di Lambda ti permette di eseguire script in batch ("shell"), runtime di altri linguaggi, routine di utility ed eseguibili. Ulteriori informazioni sono disponibili qui.

Sì. Tutti i moduli nativi a collegamento statico, nonché tutti i moduli a collegamento dinamico compilati con un percorso rpath che punta alla directory root della funzione Lambda, possono essere inclusi nel file ZIP caricato. Ulteriori informazioni sono disponibili qui.

Sì. Puoi usare il comando child_process di Node.js per eseguire un file binario incluso nella funzione o qualsiasi eseguibile di Amazon Linux visibile per la funzione. In alternativa, sono disponibili diversi pacchetti NPM che includono file binari per la riga di comando, ad esempio node-ffmpeg. Ulteriori informazioni sono disponibili qui.

Per distribuire una funzione Lambda compilata in Node.js è sufficiente creare un pacchetto in formato ZIP che includa il codice JavaScript e le librerie dipendenti. Puoi caricare il file ZIP dall'ambiente locale oppure specificare una posizione in Amazon S3 in cui si trova il file ZIP. Per ulteriori informazioni, consulta la documentazione.

Un pacchetto di distribuzione PowerShell Lambda è un file ZIP contenente lo script PowerShell, i moduli PowerShell necessari per lo script PowerShell e gli assembly necessari per ospitare PowerShell Core. Puoi quindi usare il modulo PowerShell AWSLambdaPSCore che è possibile installare da PowerShell Gallery per creare il pacchetto di distribuzione PowerShell Lambda.

Carica l'artefatto eseguibile Go in formato ZIP nella CLI di AWS o nella console Lambda e seleziona il runtime go1.x. Con Lambda puoi usare gli strumenti nativi di Go per sviluppare e confezionare il codice. Per ulteriori dettagli consulta la documentazione. 

È possibile visualizzare l'elenco delle versioni supportate qui.

No. AWS Lambda offre un'unica versione del sistema operativo e del runtime del linguaggio gestito per tutti gli utenti del servizio. Puoi importare il runtime del linguaggio da usare in Lambda.

È possibile utilizzare Amazon Step Functions per coordinare più funzioni di richiamo Lambda. È possibile richiamare più funzioni Lambda in ordine seriale, trasferire il risultato dall'una all'altra o in parallelo. Per ulteriori informazioni, consulta la documentazione.