Domande frequenti su AWS Lambda

Il codice che esegui in AWS Lambda viene caricato come "funzione Lambda". A ogni funzione sono associate informazioni di configurazione, come nome, descrizione, punto di ingresso e requisiti in termini di risorse. Il codice deve essere scritto in stile "stateless", ovvero deve presupporre che non vi siano affinità con l'infrastruttura di elaborazione sottostante. L'accesso al file system locale, i processi figlio e artefatti simili possono non estendersi oltre il ciclo di vita della richiesta e qualsiasi stato persistente deve essere archiviato in Amazon S3, Amazon DynamoDB, Amazon EFS o in un altro servizio di archiviazione disponibile in Internet. Le funzioni Lambda possono includere librerie, anche native.

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.

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 utilizzando la console AWS Lambda, l'API AWS Lambda o il modello AWS CloudFormation durante la creazione o l'aggiornamento della funzione.

Sì. Tutti i dati archiviati nello spazio di archiviazione temporaneo vengono crittografati a riposo con una chiave gestita da AWS.

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.

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 utilizzando la console AWS Lambda, l'API AWS Lambda o il modello AWS CloudFormation durante la creazione o l'aggiornamento della funzione.

Sì. Tutti i dati archiviati nello spazio di archiviazione temporaneo vengono crittografati a riposo con una chiave gestita da AWS.

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 una funzione è stateless, AWS Lambda può avviarne rapidamente tutte le copie necessarie in base alla frequenza degli eventi in entrata. Anche se il modello di programmazione di AWS Lambda è stateless, il codice può accedere a dati stateful chiamando altri servizi Web, come Amazon S3 o Amazon DynamoDB.

Sì. AWS Lambda ti permette di usare le normali caratteristiche del linguaggio e del sistema operativo, come la creazione di thread e processi aggiuntivi. Le risorse allocate alla funzione Lambda, inclusi tempo di esecuzione, memoria, disco e utilizzo della rete, devono essere condivise tra tutti i thread/processi usati. Puoi avviare processi usando qualsiasi linguaggio supportato da Amazon Linux.

Lambda tenta di imporre meno limitazioni possibili alle normali attività di sintassi e sistema operativo, ma alcune attività sono disabilitate: le connessioni di rete in entrata vengono bloccate da AWS Lambda e per le connessioni in uscita sono supportati solo i socket TCP/IP e UDP/IP, mentre le chiamate del sistema (di debug) ptrace sono bloccate. Il traffico TCP della porta 25 è anch'esso bloccato come misura contro lo spam.

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.

Non devi dimensionare le tue funzioni, perché questa operazione viene eseguita automaticamente da AWS Lambda. A ogni ricezione della notifica di un evento per la tua funzione, AWS Lambda individua rapidamente la capacità disponibile nel proprio parco istanze di calcolo ed esegue il codice. Poiché il codice è stateless, AWS Lambda può avviare tutte le copie necessarie della funzione senza distribuzioni prolungate o ritardi di configurazione. Il dimensionamento di una funzione è praticamente illimitato. AWS Lambda alloca dinamicamente la capacità in base alla frequenza degli eventi in entrata.

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.

I clienti che eseguono carichi di lavoro ad alta intensità di memoria o di calcolo possono ora utilizzare più memoria per le loro funzioni. Le funzioni di memoria più grandi aiutano le applicazioni multithread a funzionare più velocemente. Ciò le rende ideali per dati e applicazioni ad alta intensità di calcolo come machine learning, lavori batch ed ETL, modellazione finanziaria, genomica, HPC e elaborazione multimediale.

È possibile configurare le funzioni AWS Lambda in modo che possano essere eseguite per massimo 15 minuti. Puoi impostare il timeout su qualsiasi valore compreso tra 1 secondo e 15 minuti.

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

Sì. Oltre a risparmiare su Amazon EC2 e AWS Fargate, puoi anche utilizzare il Compute Savings Plans per risparmiare su AWS Lambda. I Compute Savings Plans offrono uno sconto fino al 17% su Durata, Provisioned Concurrency e Durata (Provisioned Concurrency). I Compute Savings Plans non offrono uno sconto sulle richieste nella tua fattura Lambda. L'impegno dei Compute Savings Plans è comunque valido per le richieste alle tariffe standard.

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.

I tempi di distribuzione possono variare a seconda delle dimensioni del codice, ma le funzioni AWS Lambda sono in genere pronte per la chiamata a pochi secondi dal caricamento.

Sì. È possibile includere la copia personale di una libreria (incluso l'AWS SDK) per utilizzare una versione diversa rispetto a quella predefinita fornita da AWS 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.

Un'origine di evento è un servizio AWS o un'applicazione creata da uno sviluppatore che produce eventi che a loro volta attivano l'esecuzione di una funzione di AWS Lambda. Alcuni servizi pubblicano questi eventi in Lambda richiamando direttamente la funzione cloud, ad esempio Amazon S3. Lambda può anche eseguire il polling delle risorse in altri servizi che non pubblicano eventi in Lambda. Ad esempio, Lambda può estrarre record da un flusso Amazon Kinesis o da una coda Amazon SQS ed eseguire una funzione Lambda per ogni messaggio recuperato. Molti altri servizi, come AWS CloudTrail, possono fungere da origini di eventi semplicemente accedendo ad Amazon S3 e utilizzando le notifiche dei bucket S3 per attivare le funzioni AWS Lambda

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.

Dalla console di AWS Lambda puoi selezionare una funzione e associarla alle notifiche provenienti da un bucket Amazon S3. In alternativa, puoi usare la console di Amazon S3 e configurare le notifiche del bucket per l'invio alla funzione di AWS Lambda. La stessa funzionalità è disponibile anche tramite il kit SDK AWS e l'interfaccia a riga di comando.

Puoi attivare una funzione Lambda per gli aggiornamenti di una tabella DynamoDB registrando la funzione Lambda nel flusso DynamoDB associato alla tabella. Puoi associare un flusso DynamoDB a una funzione Lambda usando la console di Amazon DynamoDB, la console di AWS Lambda o l'API registerEventSource di Lambda.

Dalla console di AWS Lambda puoi selezionare una funzione Lambda e associarla a un flusso Amazon Kinesis di proprietà dello stesso account. La stessa funzionalità è disponibile anche tramite il kit SDK AWS e l'interfaccia a riga di comando.

I record dei flussi Amazon Kinesis e DynamoDB inviati alla tua funzione di AWS Lambda vengono serializzati con rigore, per ogni shard. Di conseguenza, se inserisci due record nello stesso shard, Lambda garantisce che la funzione Lambda venga richiamata correttamente con il primo record prima di venire richiamata con il secondo. In caso di timeout della chiamata per un record o se la chiamata è limitata o restituisce qualsiasi altro errore, Lambda riprova fino a quando la chiamata non riesce (o il record non raggiunge la scadenza di 24 ore) prima di passare al secondo record. L'ordine dei record tra shard diversi non è garantito e l'elaborazione di ogni shard avviene in parallelo.

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.
 

	AWS Lambda	Amazon KDA
Finestra a cascata	Sì	Sì
Finestra sfalsata	No	Sì
Finestra scorrevole	No	Sì
Finestra di sessione	No	Sì
Arricchimento	No	Sì
Tabelle di input e di riferimento congiunte	No	Sì
Flusso di input diviso	No	Sì
Elaborazione esattamente una volta	No	Sì
Arco temporale massimo	15 minuti	Nessun limite
Portata dell'aggregazione	Partizione/shard	Flusso
Semantica temporale	Orario dell'evento	Orario dell'evento, tempo di elaborazione

Dalla console di AWS Lambda puoi selezionare una funzione Lambda e associarla a un argomento Amazon SNS. La stessa funzionalità è disponibile anche tramite il kit SDK AWS e l'interfaccia a riga di comando.

Dalla console di Amazon SES puoi configurare la regola di ricezione in modo che Amazon SES recapiti i messaggi a una funzione di AWS Lambda. Questa stessa funzionalità è disponibile tramite l'SDK AWS e l'interfaccia a riga di comando di AWS.

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.

Il servizio AWS Lambda è progettato per elaborare eventi in pochi millisecondi. La latenza sarà maggiore immediatamente dopo la creazione o l'aggiornamento di una funzione Lambda o se la funzione non viene usata per un certo periodo di tempo.

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.

Puoi richiamare una funzione Lambda tramite HTTPS definendo un'API RESTful personalizzata con Amazon API Gateway. In questo modo ottieni un endpoint per la funzione che può rispondere a chiamate REST, come GET, PUT e POST. Consulta le informazioni sull'uso di AWS Lambda con Amazon API Gateway.

Quando vengono chiamate tramite l'SDK AWS Mobile, le funzioni di AWS Lambda sono in grado di acquisire automaticamente informazioni approfondite sul dispositivo e sull'applicazione che hanno effettuato la chiamata tramite l'oggetto "context".

Quando l'app usa l'identità di Amazon Cognito, gli utenti finali possono effettuare l'autenticazione tramite un'ampia gamma di provider di accesso pubblico come Amazon, Facebook, Google e altri servizi compatibili con OpenID Connect. L'identità utente viene quindi presentata in modo automatico e protetto alla funzione Lambda in forma di ID Amazon Cognito, tramite cui può accedere ai dati utente da Amazon Cognito, oppure come chiave per archiviare e recuperare dati in Amazon DynamoDB o in altri servizi Web.

AWS Lambda è integrato in Alexa Skills Kit, una raccolta di API self-service, strumenti, documentazione ed esempi di codice che semplificano la creazione di funzionalità vocali (o "competenze") per Alexa. Una volta caricato il codice della funzione Lambda per la nuova competenza Alexa che desideri creare, AWS Lambda si occupi del resto, eseguendo il codice in risposta alle interazioni vocali di Alexa e gestendo automaticamente le risorse del computer per te. Per ulteriori informazioni, consulta la documentazione di Alexa Skills Kit.

Per le notifiche dei bucket Amazon S3 e gli eventi personalizzati, AWS Lambda tenta l'esecuzione della funzione per tre volte nel caso di una condizione di errore nel codice o quando superi il limite di un servizio o di una risorsa. Per origini di evento ordinate di cui AWS Lambda esegue il polling automaticamente, come i flussi Amazon DynamoDB e i flussi Amazon Kinesis, Lambda continua a tentare l'esecuzione nel caso di un errore del codice dello sviluppatore fino alla scadenza dei dati. Puoi monitorare l'avanzamento tramite le console di Amazon Kinesis e Amazon DynamoDB e tramite i parametri di Amazon CloudWatch generati da AWS Lambda per la tua funzione. Puoi anche impostare allarmi di Amazon CloudWatch in base alla frequenza di throttling dell'esecuzione e degli errori.

Le applicazioni basate su Lambda, o semplicemente applicazioni serverless, sono costituite da funzioni attivate da eventi. Un'applicazione serverless, in genere, è composta da una o più funzioni attivate da eventi, ad esempio il caricamento di oggetti in Amazon S3, una notifica di Amazon SNS o operazioni API. Queste funzioni possono essere autonome o basarsi su altre risorse, ad esempio tabelle DynamoDB o bucket Amazon S3. Le applicazioni serverless più semplici sono composte da una sola funzione.

Per distribuire e gestire applicazioni serverless è possibile usare AWS Serverless Application Model (AWS SAM). AWS SAM è una specifica che stabilisce le regole per il funzionamento di applicazioni serverless in AWS. Questa specifica si adatta alla sintassi utilizzata da AWS CloudFormation e ne è supportata nativamente come set di tipi di risorsa (o "risorse senza server"). Grazie a queste risorse è più semplice per i clienti di AWS utilizzare CloudFormation per configurare e distribuire applicazioni senza server utilizzando le API di CloudFormation esistenti.

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.

AWS Lambda ora consente di creare pacchetti e distribuire funzioni come immagini di container. I clienti possono sfruttare la loro familiarità con gli strumenti per container e la relativa flessibilità, nonché l'agilità e la semplicità operativa di AWS Lambda per creare applicazioni.

Puoi iniziare con un'immagine di base fornita da AWS per Lambda oppure utilizzando una delle tue immagini preferite della community o di un'azienda privata. Quindi, ti basterà utilizzare Docker CLI per creare l'immagine, caricarla su Amazon ECR e quindi creare la funzione utilizzando tutte le interfacce e gli strumenti Lambda consueti, come la Console di gestione AWS, l'interfaccia a riga di comando (CLI) di AWS, l'SDK AWS, AWS SAM e AWS CloudFormation.

Su Lambda puoi distribuire immagini di base Linux di terze parti (ad esempio Alpine o Debian) oltre alle immagini fornite da Lambda. AWS Lambda supporterà tutte le immagini basate sui seguenti formati manifest per le immagini: Docker Image Manifest V2 Schema 2 (usato con Docker versione 1.10 e successive) o specifiche Open Container Initiative (OCI) (v1.0 e successive). Lambda supporta immagini con una dimensione fino a 10 GB.

AWS Lambda fornisce una varietà di immagini di base che i clienti possono estendere. Inoltre, i clienti possono utilizzare le loro immagini basate su Linux preferite con una dimensione fino a 10 GB.

Puoi utilizzare qualsiasi strumento per container purché supporti uno dei seguenti formati manifest per le immagini di container: Docker Image Manifest V2 Schema 2 (utilizzato con Docker versione 1.10 e successive) o specifiche Open Container Initiative (OCI) (v1.0 e successive). Ad esempio, puoi utilizzare strumenti per container nativi (come Docker run, docker compose, Buildah e Packer) per definire le tue funzioni come un'immagine di container e distribuirle su Lambda.

Per le funzioni distribuite come immagini di container puoi utilizzare tutte le funzionalità AWS Lambda esistenti, ad eccezione dei livelli Lambda e della firma del codice. Una volta distribuita, AWS Lambda considererà un'immagine come immutabile. Durante il processo di creazione i clienti possono utilizzare i livelli del container per includere le dipendenze.

No, al momento no. La tua immagine, una volta distribuita su AWS Lambda, sarà immutabile. Il servizio non applicherà patch o aggiornamenti all'immagine. Tuttavia, AWS Lambda pubblicherà immagini di base adatte a tutti i runtime supportati e basati sull'ambiente gestito da Lambda. A queste immagini pubblicate verranno applicati patch e aggiornamenti insieme agli aggiornamenti ai runtime gestiti da AWS Lambda. Puoi estrarre e utilizzare l'ultima immagine di base da DockerHub o Amazon ECR Public, ricostruire l'immagine del tuo container e distribuirla su AWS Lambda tramite Amazon ECR. In questo modo puoi creare e testare le immagini e i runtime aggiornati, prima di implementare l'immagine in fase di produzione

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.

No: AWS Lambda garantisce che i profili delle prestazioni per le funzioni impacchettate come immagini di container siano gli stessi di quelle impacchettate come archivi ZIP, e ciò include tempi di avvio generalmente inferiori al secondo.

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.

L'API Runtime di Lambda nel servizio Lambda in esecuzione accetta eventi JSON e restituisce risposte. Il Lambda Runtime Interface Emulator consente alla funzione impacchettata come immagine di container di accettare richieste HTTP durante i test locali con strumenti come cURL e di farle comparire nella funzione tramite la stessa interfaccia in modo locale. Ti consente di utilizzare il comando docker run o docker-compose up per testare localmente la tua applicazione Lambda.

Puoi utilizzare l'emulatore per verificare se il codice della funzione è compatibile con l'ambiente Lambda, se viene eseguito correttamente e se fornisce il risultato previsto. Ad esempio, puoi simulare eventi di test da diverse origini di eventi. Puoi anche utilizzare l'emulatore per testare estensioni e agenti incorporati nell'immagine di container sull'API delle estensioni Lambda.

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.

No. Lambda SnapStart e PC non possono essere abilitati nello stesso momento sulla stessa funzione.

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.

No. In questo momento, non puoi abilitare Lambda SnapStart con Amazon EFS.

No. In questo momento, non puoi abilitare Lambda SnapStart con uno spazio di archiviazione temporaneo (/tmp) maggiore, oltre i 512 MB.

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.

La durata di inizializzazione massima consentita per Lambda SnapStart corrisponderà alla durata del timeout di esecuzione che hai configurato per la tua funzione. Il limite massimo di timeout di esecuzione configurabile per una funzione è di 15 minuti.

Provisioned Concurrency ti offre maggiore controllo sulle prestazioni delle applicazioni serverless. Quando è abilitato, Provisioned Concurrency mantiene inizializzate le funzionalità e pronte a reagire in meno di cento millisecondi.

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.

Non è necessario modificare il codice per utilizzare Provisioned Concurrency. Funziona perfettamente con le funzionalità e i runtime esistenti. Quando si utilizza Provisioned Concurrency non avviene nessuna modifica al modello di invocazione ed esecuzione di Lambda.

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.

Provisioned Concurrency è ideale per la creazione di applicazioni sensibili alla latenza, come back-end Web o per dispositivi mobili, API invocate simultaneamente e microservizi interattivi. Puoi configurare facilmente il livello di simultaneità in base alle specifiche necessità dell'applicazione. Puoi aumentare il livello di simultaneità durante i momenti di grande richiesta e ridurlo, o disattivarlo completamente, al calare della domanda.

Se la simultaneità di una funzionalità raggiunge il livello configurato, le successive invocazioni della funzione avranno le caratteristiche di latenza e calibro delle funzioni Lambda normali. Puoi restringere la funzione per calibrarne le dimensioni fino al livello configurato. In questo modo si evita che la funzione superi il livello configurato di Provisioned Concurrency. Questo meccanismo serve a evitare la variabilità dell'applicazione quando la domanda supera la quantità prevista.

AWS Lambda ti permette di eseguire le tue funzioni su processori x86 o processori Arm. I processori AWS Graviton2 sono creati e personalizzati da Amazon Web Services con core Arm Neoverse a 64 bit per fornire il miglior rapporto prezzo/prestazioni per i tuoi carichi di lavoro cloud. I clienti ottengono gli stessi vantaggi di AWS Lambda, esecuzione dei codici senza provisioning o server di gestione, scalabilità automatica, elevata disponibilità e possibilità di pagare soltanto per le risorse utilizzate.

Le funzioni di AWS Lambda alimentate dai processori Graviton2, che utilizzano un’architettura per il processore Arm progettata da AWS, sono ideate per ottenere prestazioni in termini di prezzo migliorate del 34%, rispetto alle funzioni eseguite su processori x86, per diversi carichi di lavoro serverless, come back-end Web e mobili, elaborazione e trasmissione di dati. Con una latenza minore, prestazioni migliorate fino al 19%, un prezzo più basso del 20% e l'efficienza a più alta potenza attualmente disponibile presso AWS, le funzioni di Graviton2 possono essere utilizzate per potenziare le applicazioni serverless essenziali per l'organizzazione. I clienti possono configurare sia funzioni esistenti che nuove per il processore Graviton2. Possono implementare funzioni in esecuzione su Graviton2 sia come file in formato zip che come immagini container.

Puoi configurare le funzioni per far sì che vengano eseguite su Graviton2 attraverso la Console di gestione AWS, l’API AWS Lambda, AWS CLI e AWS CloudFormation impostando l’architettura per la tua funzione su “arm64”.

Non vi è alcuna differenza tra le funzioni basate su x86 e le funzioni basate su Arm. È sufficiente caricare il codice tramite la Console di gestione AWS, un file in formato zip o un’immagine container, e AWS Lambda lo eseguirà automaticamente in caso di attivazione, senza che sia necessario effettuare il provisioning o gestire l’infrastruttura.

Un’applicazione può contenere funzioni eseguite su entrambe le architetture. AWS Lambda consente di modificare l’architettura (“x86_64” o “arm64”) della versione corrente della tua funzione. Una volta creata una versione specifica della tua funzione, l’architettura non può essere modificata.

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.

No. Ogni versione della funzione può utilizzare un’unica immagine container.

Sì. I livelli e le estensioni possono essere mirati ad architetture compatibili con “x86_64” o “arm64”. L’architettura di default per le funzioni e i livelli è “x86_64”.

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.

Le funzioni di AWS Lambda alimentate dai processori AWS Graviton2 costano il 20% in meno rispetto alle funzioni Lambda basate su x86. Il piano gratuito di Lambda si applica alle funzioni di AWS Lambda alimentate da architetture basate su x86 e Arm.

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.

Grazie ad Amazon Elastic File System (Amazon EFS) for AWS Lambda, i clienti possono leggere, scrivere e conservare in modo sicuro grandi volumi di dati praticamente su qualsiasi scala utilizzando un file system NFS elastico completamente gestito che può ridimensionarsi su richiesta senza necessità di provisioning o gestione della capacità. In precedenza, gli sviluppatori aggiungevano codice alle loro funzioni per scaricare dati da S3 o database nella memoria temporanea locale limitata a 512 MB. Grazie a EFS for Lambda, gli sviluppatori non devono scrivere codice per scaricare i dati nella memoria temporanea ed elaborarli.

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.

Sì. Le destinazioni di montaggio per Amazon EFS sono associate a una sottorete in un VPC. La funzione AWS Lambda deve essere configurata per accedere a un determinato VPC.

EFS for Lambda è ideale per la creazione di applicazioni di machine learning o il caricamento di file o modelli di riferimento di grandi dimensioni, l'elaborazione o il backup di grandi quantità di dati, l'hosting di contenuti Web o lo sviluppo di sistemi di build interni. I clienti possono anche utilizzare EFS for Lambda per mantenere lo stato tra le invocazioni all'interno di un'architettura a microservizi stateful, in un flusso di lavoro StepFunctions o condividere file tra applicazioni serverless e istanze o applicazioni basate su container.

Sì. La crittografia dei dati in transito impiega il protocollo standard di settore TLS 1.2 per proteggere il traffico dati tra le funzioni AWS Lambda e i file system Amazon EFS.

I clienti possono eseguire il provisioning di Amazon EFS per crittografare i dati inattivi. I dati inattivi vengono crittografati in modo trasparente durante le operazioni di scrittura, e con lo stesso livello di trasparenza vengono decrittografati durante le operazioni di lettura, perciò non è necessario apportare modifiche alle applicazioni. Le chiavi di crittografia sono gestite da AWS Key Management Service (KMS), perciò nemmeno occorre più creare e mantenere una propria infrastruttura di gestione delle chiavi di sicurezza.

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.

No. Ogni funzione Lambda sarà in grado di accedere a un file system EFS.

Sì. Amazon EFS supporta le funzioni Lambda, i container ECS e Fargate e le istanze EC2. È possibile condividere lo stesso file system e utilizzare le policy IAM e gli Access Point per controllare a cosa ha accesso ogni funzione, container o istanza.  

Sì. Le funzioni Lambda possono essere configurate con un URL di funzione, un endpoint HTTPS integrato che può essere richiamato usando il browser, curl, e qualsiasi client HTTP. Gli URL delle funzioni sono un modo semplice per iniziare a costruire funzioni accessibili HTTPS.

È 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.

Le URL della funzione Lambda sono protette per impostazione predefinita dall'autorizzazione IAM. Puoi scegliere di disattivare l'autorizzazione IAM per creare un endpoint pubblico o implementare un'autorizzazione personalizzata come parte della logica di business della funzione.

È possibile richiamare la funzione dal tuo browser Web navigando sull'URL Lambda, dal codice applicazione del tuo client utilizzando una libreria HTTP o dalla riga di comando utilizzando curl.

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.

I nomi di dominio personalizzati non sono attualmente supportati con gli URL delle funzioni. È possibile utilizzare un dominio personalizzato con l'URL della propria funzione creando una distribuzione di Amazon CloudFront e un CNAME per mappare il dominio personalizzato al nome della distribuzione di CloudFront. Quindi, mappa il tuo nome di dominio della distribuzione di CloudFront affinché sia il suo routing abbia come origine l'URL della tua funzione.

Sì, gli URL delle funzioni possono essere usati per invocare una funzione Lambda in un VPC.

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.

AWS Lambda è progettato per usare la replica e la ridondanza in modo da offrire elevata disponibilità per il servizio stesso e per le funzioni Lambda da esso gestite. Né il servizio né le funzioni Lambda sono soggetti a tempi di inattività pianificati o a finestre di manutenzione.

Sì. Quando aggiorni una funzione Lambda, esiste un breve periodo di tempo, in genere inferiore a un minuto, in cui le richieste possono essere gestite dalla versione precedente della funzione o da quella nuova.

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.

In caso di errore, le funzioni Lambda richiamate in modo sincrono rispondono con un'eccezione. Le funzioni Lambda richiamate in modo asincrono vengono ritentate almeno tre volte. 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 Kinesis e DynamoDB mantengono i dati per almeno 24 ore.

Come coda DLQ è possibile configurare una coda Amazon SQS o un argomento Amazon SNS.

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.

I controlli degli accessi possono essere gestiti dal ruolo della funzione Lambda o da un'impostazione delle policy delle risorse nella coda stessa. Se sono presenti entrambe le policy, sarà in vigore quella più restrittiva delle due autorizzazioni.

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.

Puoi abilitare la firma del codice creando una configurazione della firma del codice tramite la Console di gestione AWS, l'API di Lambda, la CLI di AWS, AWS CloudFormation e AWS SAM. La configurazione della firma del codice consente di specificare i profili di firma approvati e di configurare se avvisare o rifiutare le distribuzioni se i controlli della firma non riescono. Le configurazioni della firma del codice possono essere collegate a singole funzioni Lambda per abilitare la funzione di firma del codice. Tali funzioni ora iniziano a verificare le firme durante la distribuzione.

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.

Sì, puoi abilitare la firma del codice per le funzioni esistenti allegando alla funzione una configurazione della firma del codice. Puoi farlo utilizzando la console di AWS Lambda, l'API di Lambda, la CLI di AWS, AWS CloudFormation e AWS SAM.

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.

Lambda offre la build Amazon Linux 1.8 di openjdk.

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.

Sì. Puoi usare il comando pip per installare pacchetti Python.

È possibile creare una funzione Lambda in C# utilizzando IDE Visual Studio e selezionando "Publish to AWS Lambda" nello strumento di esplorazione delle soluzioni. In alternativa, è possibile eseguire direttamente il comando "dotnet lambda publish" dalla CLI dotnet sulla quale è installato [# Lambda CLI tools patch], che crea uno ZIP del codice di origine in C# insieme a tutte le dipendenze NuGet, oltre agli assembly DLL pubblicati di proprietà e li carica automaticamente su AWS Lambda utilizzando il paramento di runtime “dotnetcore1.0”

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. 

Per distribuire una funzione Lambda compilata in Ruby è sufficiente creare un pacchetto in formato ZIP che includa il codice Ruby e i pacchetti gem. Puoi caricare il file ZIP dall'ambiente locale oppure specificare una posizione in Amazon S3 in cui si trova il file ZIP.

È 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.

AWS Lambda si integra con AWS CloudTrail. AWS CloudTrail può registrare e distribuire file di log in un bucket Amazon S3 per memorizzare l'utilizzo dell'API nell'account.

È 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.

Sì, AWS Lambda supporta il set di istruzioni Advanced Vector Extensions 2 (AVX2). Per ulteriori informazioni su come compilare il codice dell'applicazione per indirizzare questo set di istruzioni allo scopo di migliorare le prestazioni, consulta la documentazione per gli sviluppatori AWS Lambda.