Generale

D: Cos'è AWS Lambda?

AWS Lambda consente di eseguire codice senza dover effettuare il provisioning né gestire server. Le tariffe sono calcolate in base ai tempi di elaborazione, perciò non viene addebitato alcun costo quando il codice non è in esecuzione. Con Lambda, puoi eseguire codice per qualsiasi tipo di applicazione o servizio di back-end, senza alcuna amministrazione. Una volta caricato il codice, Lambda si prende carico delle azioni necessarie per eseguirlo e dimensionare le risorse con la massima disponibilità. Puoi configurare il codice in modo che venga attivato automaticamente da altri servizi AWS oppure che venga richiamato direttamente da qualsiasi app Web o mobile.

D: Che cos'è l'elaborazione serverless?

L'elaborazione serverless consente di creare ed eseguire applicazioni e servizi senza dover gestire alcun server. In questa modalità, le applicazioni saranno comunque eseguite su server, la cui gestione sarà però a carico di AWS. Alla base dei servizi di elaborazione serverless c'è AWS Lambda, che permette di eseguire codice senza dover effettuare il provisioning o gestire i server.

D: Quali eventi possono attivare una funzione di AWS Lambda?

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

D: In quali casi è più indicato utilizzare AWS Lambda o Amazon EC2?

Amazon Web Services offre un set di servizi di elaborazione per soddisfare un'ampia gamma di esigenze.

Amazon EC2 offre flessibilità grazie a una vasta gamma di tipi di istanze e alla possibilità di personalizzare le impostazioni del sistema operativo, di rete e di sicurezza, nonché l'intero stack del software, permettendoti di spostare facilmente nel cloud le applicazioni esistenti. Con Amazon EC2 sei responsabile del provisioning della capacità, del monitoraggio dello stato e delle prestazioni del parco istanze e della progettazione per tolleranza ai guasti e scalabilità. AWS Elastic Beanstalk offre un servizio di facile utilizzo per la distribuzione e il dimensionamento di applicazioni Web che ti permette di mantenere la proprietà e il controllo completo delle istanze EC2 sottostanti. Amazon EC2 Container Service è un servizio di gestione scalabile che supporta contenitori Docker e ti permette di eseguire con facilità applicazioni distribuite in un cluster gestito di istanze Amazon EC2.

AWS Lambda semplifica l'esecuzione del codice in risposta agli eventi, ad esempio le modifiche a bucket Amazon S3, gli aggiornamenti a una tabella Amazon DynamoDB o gli eventi personalizzati generati dalle applicazioni o dai dispositivi. Con Lambda non devi effettuare il provisioning delle tue istanze, perché questo servizio esegue automaticamente tutte le attività operative e amministrative, tra cui il provisioning della capacità, il monitoraggio dello stato del parco istanze, l'applicazione di patch di sicurezza alle risorse di elaborazione sottostanti, l’implementazione del codice, l'esecuzione di un front-end di servizi Web e il monitoraggio e la registrazione del codice. AWS Lambda offre semplice dimensionamento ed elevata disponibilità per il codice senza impegno aggiuntivo da parte tua.

D: Che tipo di codice può essere eseguito in AWS Lambda?

AWS Lambda offre un semplice metodo per svolgere molte attività nel cloud. Ad esempio, puoi usare AWS Lambda per la creazione di back-end per dispositivi mobili che recuperano e trasformano dati da Amazon DynamoDB e di gestori che comprimono o trasformano oggetti mentre vengono caricati in Amazon S3, per il controllo e la segnalazione delle chiamate API effettuate a qualsiasi soluzione Amazon Web Services e per l'elaborazione non basata su server di dati di streaming con Amazon Kinesis.

D: Quali sintassi supporta AWS Lambda?

AWS Lambda offre supporto nativo a codici Java, Go, PowerShell, Node.js, C#, Python e Ruby e fornisce un'API Runtime che consente di utilizzare qualsiasi altro linguaggio di programmazione per creare le tue funzioni. Leggere la documentazione relativa all'uso di Node.js, Python, Java, Ruby, C#, Go ePowerShell.

D: È possibile accedere all'infrastruttura su cui viene eseguito AWS Lambda?

No. AWS Lambda gestisce per te l'infrastruttura di elaborazione, alla quale permette di eseguire controlli dello stato, applicare patch di sicurezza e svolgere altre attività di manutenzione di routine.

D: In che modo AWS Lambda isola il codice?

Ogni funzione di AWS Lambda viene eseguita nel rispettivo ambiente isolato, con una visualizzazione del file system e risorse proprie. AWS Lambda usa le stesse tecniche di Amazon EC2 per offrire sicurezza e separazione a livello di infrastruttura e di esecuzione.

D: In che modo AWS Lambda protegge il codice?

AWS Lambda archivia il codice in Amazon S3 e lo crittografa su disco. AWS Lambda esegue controlli dell'integrità aggiuntivi mentre il codice è in uso.

D: In quali regioni AWS è disponibile AWS Lambda?

Consulta la Tabella delle regioni per l'infrastruttura globale di AWS.

Funzioni AWS Lambda

D: Che cos'è una funzione di 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.

D: AWS Lambda riutilizza le istanze di funzione?

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.

D: È possibile ottenere spazio su disco per una funzione 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. 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 Prezzi di AWS Lambda.

D: Come configuro la mia applicazione per utilizzare lo spazio di archiviazione temporaneo 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.

D: Lo spazio di archiviazione temporaneo di AWS Lambda è crittografato?

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

D: Quali parametri posso utilizzare per monitorare l'uso dello spazio di archiviazione temporaneo 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.

D: Quando dovrei utilizzare lo spazio di archiviazione temporaneo di Simple Storage Service (Amazon S3), Amazon EFS o AWS Lambda per le mie applicazioni serverless?

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.

D: Posso utilizzare l'archiviazione temporanea mentre è abilitata la simultaneità con provisioning per la mia funzione?

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.

D: Come configuro la mia applicazione per utilizzare lo spazio di archiviazione temporaneo 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.

D: Lo spazio di archiviazione temporaneo di AWS Lambda è crittografato?

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

D: Quali parametri posso utilizzare per monitorare l'uso dello spazio di archiviazione temporaneo 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.

D: Perché le funzioni AWS Lambda devono essere stateless?

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.

D: È possibile usare thread e processi nel codice di una funzione di AWS Lambda?

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.

D: Sono previste restrizioni al codice delle funzioni AWS Lambda?

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.

D: In che modo è possibile creare una funzione usando la console di AWS Lambda?

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.

D: In che modo è possibile creare una funzione AWS Lambda usando l'interfaccia a riga di comando di Lambda?

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.

D: AWS Lambda supporta le variabili di ambiente?

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 di ambiente, consulta la documentazione.

D: È possibile memorizzare informazioni sensibili in variabili di ambiente?

Per informazioni sensibili quali le password di database, consigliamo di utilizzare la crittografia lato client tramite AWS Key Management Service e archiviare i valori risultanti come testo crittografato nella variabile di ambiente. Sarà necessario includere nel codice della funzione AWS Lambda la logica necessaria per decodificare tali valori.

D: Come si gestiscono le funzioni AWS Lambda?

Puoi elencare, eliminare, aggiornare e monitorare con facilità le tue funzioni Lambda usando il pannello di controllo nella console di AWS Lambda. Per gestire le funzioni Lambda, puoi usare anche l'interfaccia a riga di comando di AWS e l'SDK AWS. Per ulteriori informazioni, consulta la Guida per gli sviluppatori AWS Lambda.

D: È possibile condividere il codice tra funzioni?

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.

D: In che modo è possibile monitorare una funzione di AWS Lambda?

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.

D: Come si risolvono i problemi relativi agli errori in una funzione 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 di Amazon CloudWatch Logs.

D: In che modo è possibile ricalibrare una funzione AWS Lambda?

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.

D: In che modo le risorse di elaborazione vengono assegnate a una funzione AWS Lambda?

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.

D: Quando dovrei utilizzare le funzioni AWS Lambda con più di 3.008 MB di memoria?

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.

D: Qual è la durata massima di esecuzione di una funzione AWS Lambda?

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

D: Quali sono i costi addebitati per l'uso di funzioni AWS Lambda?

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

D: Posso risparmiare su AWS Lambda con un Compute Savings Plan?

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.

D: AWS Lambda supporta la funzione Versioni multiple?

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.

D: Dopo quanto tempo una funzione AWS Lambda è pronta per l'esecuzione dopo che ne è stato caricato il codice?

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.

D: È possibile usare una versione personale di una libreria supportata?

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.

D: Come funzionano i prezzi a scaglioni?

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.

D: È possibile usufruire sia dei prezzi a scaglioni sia di Savings Plans per il calcolo?

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.

Uso di AWS Lambda per l'elaborazione di eventi AWS

D: Che cos'è un'origine di evento?

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 di Amazon Kinesis o una coda di Amazon SQS ed eseguire una funzione Lambda per ogni messaggio recuperato.

Molti altri servizi, ad esempio AWS CloudTrail, possono operare come origini di evento tramite la semplice registrazione in Amazon S3 e l'uso di notifiche dei bucket S3 per attivare funzioni di AWS Lambda.

D: Quali origini di evento è possibile usare con AWS Lambda?

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

D: Come vengono rappresentati gli eventi in AWS Lambda?

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 di Amazon S3, visita Configurazione delle notifiche eventi Amazon S3. Per ulteriori informazioni sui flussi Amazon DynamoDB, visita 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 Amazon Cognito. Per ulteriori informazioni sui registri di AWS CloudTrail e le chiamate API di controllo tra servizi AWS, visita AWS CloudTrail.

D: In che modo è possibile configurare una funzione AWS Lambda perché risponda alle modifiche in un bucket Amazon S3?

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.

D: In che modo è possibile configurare una funzione AWS Lambda perché risponda agli aggiornamenti di una tabella Amazon DynamoDB?

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.

D: Come si usa una funzione AWS Lambda per elaborare record in un flusso Amazon Kinesis?

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.

D: In che modo AWS Lambda elabora i dati da Amazon Kinesis Streams e flussi Amazon DynamoDB?

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 partizioni diversi non è garantito e l'elaborazione di ogni partizione avviene in parallelo.

D: Come posso scegliere tra AWS Lambda e Servizio gestito da Amazon per Apache Flink per le mie esigenze di analisi?

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. Servizio gestito da Amazon per Apache Flink consente di creare applicazioni di analisi più complesse che supportano scelte di elaborazione flessibili e un'affidabile tolleranza agli errori, con elaborazione esattamente una volta senza duplicati e analisi che possono essere eseguite 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
Finestra sfalsata No
Finestra scorrevole No
Finestra di sessione No
Arricchimento No
Tabelle di input e di riferimento congiunte No
Flusso di input diviso No
Elaborazione esattamente una volta No
Arco temporale massimo 15 minuti Nessun limite
Portata dell'aggregazione Partizione/shard Flusso
Semantica temporale Orario dell'evento Orario dell'evento, tempo di elaborazione

D: Come si usa una funzione AWS Lambda per rispondere alle notifiche inviate da Amazon Simple Notification Service (SNS)?

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.

D: Come si usa una funzione AWS Lambda per rispondere alle e-mail inviate da Amazon Simple Email Service (SES)?

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 il kit SDK AWS e l'interfaccia a riga di comando di AWS.

D: Come si usa una funzione AWS Lambda per rispondere ad allarmi di Amazon CloudWatch?

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 Amazon CloudWatch Developer Guide.

D: Come si usa una funzione AWS Lambda per rispondere alle modifiche apportate a dati degli utenti o dei dispositivi gestiti da Amazon Cognito?

È possibile selezionare nella console di AWS Lambda una funzione da attivare quando viene sincronizzato un qualsiasi 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.

D: In che modo un'applicazione può attivare una funzione di AWS Lambda direttamente?

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.

D: Qual è la latenza della chiamata di una funzione di AWS Lambda in risposta a un evento?

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.

D: Come si crea un back-end per dispositivi mobili con AWS 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 AWS Mobile, visita la pagina SDK AWS Mobile. Per ulteriori informazioni su Amazon API Gateway, visita la pagina Amazon API Gateway.

D: Come si richiama una funzione di AWS Lambda tramite HTTPS?

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.

D: In che modo è possibile configurare una funzione AWS Lambda perché abbia comportamenti differenti a seconda del dispositivo e dell'app che effettuano la richiesta?

Quando vengono chiamate tramite il kit 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".

D: In che modo è possibile configurare una funzione AWS Lambda perché abbia comportamenti differenti a seconda dell'identità dell'utente finale di un'applicazione?

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.

D: Come si crea una competenza Alexa con AWS Lambda?

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.

D: Che cosa accade in caso di errori della funzione durante l'elaborazione di un evento?

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.

Utilizzo di AWS Lambda per creare applicazioni

D: Cos'è un'applicazione serverless?

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.

D: In che modo è possibile distribuire e gestire un'applicazione serverless?

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.

D: In che modo è possibile individuare applicazioni senza server esistenti sviluppate dalla community AWS?

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

D: In che modo è possibile automatizzare la distribuzione di un'applicazione senza server?

È 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 senza server, consulta la documentazione.

D: Come si inizia a creare un'applicazione serverless?

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.

D: In che modo è possibile coordinare le chiamate tra più funzioni AWS Lambda?

È possibile utilizzare AWS Step Functions per coordinare una serie di funzioni di 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.

D: In che modo viene eseguita la risoluzione dei problemi di un'applicazione senza server?

È 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" della funzione in "active". 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 Risoluzione dei problemi delle applicazioni basate su Lambda per ulteriori informazioni. Saranno applicate le tariffe di AWS X-Ray.

D: È possibile creare applicazioni serverless che si connettono a database relazionali?

Sì. Puoi creare applicazioni serverless altamente calibrabili, sicure e basate su Lambda che si connettono a database relazionali utilizzando Amazon RDS Proxy, 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 da RDS Proxy totalmente gestite sarà effettuata in base ai prezzi di RDS Proxy.

D: Come funziona la licenza di AWS SAM?

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 in GitHub qui.

Supporto delle immagini di container

D: In che cosa consiste il supporto delle immagini di container per AWS Lambda?

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.

D: Come posso utilizzare il supporto delle immagini di container per AWS Lambda?

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.

D: Quali tipi di immagini di container sono supportati?

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.

D: Quali immagini di base posso utilizzare?

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.

D: Quali strumenti per container posso utilizzare per creare pacchetti e distribuire funzioni come immagini di container?

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.

D: Quali funzionalità di AWS Lambda sono disponibili per le funzioni distribuite come immagini di container?

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.

D: AWS Lambda rilascerà patch e aggiornamenti per la mia immagine di container distribuita?

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 distribuire l'immagine in fase di produzione.

D: Quali sono le differenze tra le funzioni create utilizzando gli archivi ZIP e utilizzando le immagini di container?

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.

D: Esiste una differenza in termini di prestazioni tra le funzioni definite come ZIP e come immagini di container?

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.

D: Come funziona l'addebito della distribuzione delle funzioni Lambda come immagini di container?

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.

D: Che cos'è il Lambda Runtime Interface Emulator (RIE)?

Il Lambda Runtime Interface Emulator è un proxy per l'API Runtime di Lambda che consente ai clienti di testare localmente 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.

D: Perché durante i test in locale ho bisogno del Lambda Runtime Interface Emulator (RIE)?

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.

D: Quali comportamenti delle funzioni posso testare localmente con l'emulatore?

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.

D: In che modo il Runtime Interface Emulator (RIE) mi aiuta a eseguire la mia immagine compatibile Lambda su servizi di elaborazione aggiuntivi?

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 per le loro immagini di base.

D: Come posso distribuire la mia applicazione containerizzata preesistente su AWS Lambda?

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 Lambda SnapStart

D: Cos'è AWS Lambda SnapStart?
 
AWS Lambda SnapStart per Java offre prestazioni di avvio delle funzioni fino a 10 volte più veloci. Per le funzioni on demand, la fase di inizializzazione (in cui AWS Lambda carica il codice della funzione e inizializza le dipendenze esterne) contribuisce maggiormente alla latenza di avvio e si verifica alla prima chiamata. Con Lambda SnapStart, Lambda inizializza il codice della funzione di inizializzazione una tantum in anticipo quando si pubblica una versione della funzione anziché quando si richiama la funzione per la prima volta. Quindi, Lambda acquisisce un'istantanea e memorizza nella cache la memoria e lo stato del disco dell' ambiente di esecuzione inizializzato. Quando invochi la funzione, e man mano che aumenta, Lambda riprende la funzione dallo snapshot memorizzato nella cache invece di inizializzare la funzione da zero.
 
D: Come faccio a configurare la mia funzione Lambda in modo da utilizzare Lambda SnapStart?
 
Lambda SnapStart è una semplice configurazione a livello di funzione che può essere configurata per funzioni Java nuove ed esistenti utilizzando l'API Lambda, la Console di gestione AWS, AWS Command Line Interface (CLI), l'SDK AWS, 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.
 
D: Come posso scegliere tra Lambda SnapStart e Provisioned Concurrency (PC)?

Lambda SnapStart è un'ottimizzazione delle prestazioni che consente alle funzioni Java di raggiungere tempi di avvio fino a 10 volte più rapidi riducendo la latenza variabile sostenuta durante l'esecuzione del codice di inizializzazione una tantum. Lambda SnapStart funziona ampiamente su tutte le funzioni della tua applicazione o account senza costi aggiuntivi. Quando un cliente pubblica una versione della funzione con Lambda SnapStart, il codice della funzione viene inizializzato in anticipo invece di essere inizializzato alla prima chiamata. Lambda acquisisce quindi uno snapshot dell'ambiente di esecuzione inizializzato e lo mantiene in una cache a più livelli per l'accesso a bassa latenza. Quando la funzione viene prima richiamata e poi dimensionata, Lambda riprende la funzione dallo snapshot memorizzato nella cache invece di inizializzarla da zero, riducendo la latenza di avvio.

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.

D: Quali runtime sono supportati da Lambda SnapStart?
 
Lambda SnapStart supporta il runtime Java 11. Le versioni future di Java saranno supportate dopo il loro rilascio. Per tutti i runtime supportati da Lambda, consulta la documentazione dei runtime Lambda.
 
D: Posso abilitare Lambda SnapStart e PC sulla stessa funzione?

No. Lambda SnapStart e PC non possono essere abilitati nello stesso momento sulla stessa funzione.
 
D: Posso configurare una funzione Lambda SnapStart con un cloud privato virtuale (VPC)?
 
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.
 
D: Posso configurare Lambda SnapStart su entrambe le architetture x86 e Arm?

No. In questo momento, puoi configurare Lambda SnapStart solo per le funzioni in esecuzione sull'architettura x86.
 
D: Posso abilitare Lambda SnapStart con Amazon Elastic File System (EFS)?

No. In questo momento, non puoi abilitare Lambda SnapStart con Amazon EFS.
 
D: Posso abilitare Lambda SnapStart con uno spazio di archiviazione temporaneo (/tmp) maggiore, oltre i 512 MB?
 
No. In questo momento, non puoi abilitare Lambda SnapStart con uno spazio di archiviazione temporaneo (/tmp) maggiore, oltre i 512 MB.
 
D: Il processo di memorizzazione nella cache e ripresa dagli snapshot introduce considerazioni sulla compatibilità del software?

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.

D: Posso eseguire il mio codice prima che venga creato uno snapshot o quando la funzione viene ripresa dallo snapshot?

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.

D: Mi verrà addebitato un costo per Lambda SnapStart?

No. L'abilitazione di Lambda SnapStart non prevede alcun costo aggiuntivo. I costi addebitati dipendono dal numero di richieste per le funzioni e dalla durata dell'esecuzione del codice in base ai prezzi di Lambda correnti. I costi della durata si applicano al codice che viene eseguito nel gestore di una funzione e agli hook di runtime, nonché al codice di inizializzazione dichiarato all'esterno del gestore. Tieni presente che AWS Lambda può riavviare periodicamente gli ambienti di esecuzione con patch di sicurezza ed eseguire nuovamente il codice di inizializzazione. Per maggiori dettagli, consulta la documentazione sul modello di programmazione Lambda.

D: Per quanto tempo gli snapshot per la funzione pubblicata possono rimanere memorizzati nella cache con Lambda SnapStart?

Con Lambda SnapStart, Lambda conserva uno snapshot dell'ambiente di esecuzione inizializzato per le ultime tre versioni della funzione pubblicate, purché le versioni pubblicate continuino a ricevere chiamate. Lo snapshot associato a una versione della funzione pubblicata scade se rimane inattivo per più di 14 giorni.

D. Come posso crittografare gli snapshot dell'ambiente di esecuzione inizializzato creato da Lambda SnapStart?

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.

D. Esiste un limite di tempo per quanto tempo può essere eseguita l'inizializzazione del codice con Lambda SnapStart?

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

D: Cos'è Provisioned Concurrency di AWS Lambda?

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.

D: Come si fa a configurare e gestire Provisioned Concurrency?

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 su Provisioned Concurrency, consulta la documentazione.

D: Devo modificare il codice se desidero utilizzare Provisioned Concurrency?

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.

D: Quali costi vengono addebitati per Provisioned Concurrency?

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 di Provisioned Concurrency, consulta i prezzi di AWS Lambda.

D: In quali casi è indicato utilizzare Provisioned Concurrency?

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.

D: Cosa succede se una funzione riceve invocazioni al di sopra del livello configurato di Provisioned Concurrency?

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.

Le funzioni di AWS Lambda sono alimentate dai processori Graviton2

D: Quali sono le funzioni di AWS Lambda alimentate dai processori Graviton2?

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.

D: Perché dovrei usare le funzioni di AWS Lambda alimentate dai processori Graviton2?

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.

D: Come posso configurare le funzioni per far sì che vengano eseguite sui processori Graviton2?

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

D: Come posso implementare la mia applicazione costruita utilizzando le funzioni alimentate dai processori Graviton2?

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.

D: Un’applicazione può utilizzare sia le funzioni alimentate da processori Graviton2 che le funzioni alimentate da processori x86?

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.

D: AWS Lambda supporta immagini container su architetture multiple?

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

D: Posso creare livelli di AWS Lambda mirati a funzioni con tecnologia AWS Graviton2?

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

D: Quali sono le lingue e i tempi di esecuzione supportati dalle funzioni di Lambda eseguite sui processori Graviton2?

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 tempi di esecuzione di AWS Lambda.

D: Quali sono i costi delle funzioni di AWS Lambda alimentate dai processori Graviton2? Il piano gratuito di AWS Lambda si applica a tutte le funzioni alimentate da Graviton2?

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.

D: Come posso scegliere se eseguire le mie funzioni su processori Graviton2 o processori x86?

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.

D: Ho bisogno di una macchina di sviluppo basata su Arm per creare, costruire e testare le funzioni alimentate dai processori Graviton2 a livello locale?

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 di 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 di Lambda con Graviton2, visita la relativa documentazione.

Amazon EFS for AWS Lambda

D: Cos'è Amazon EFS for AWS Lambda?

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.

D: Come si configura Amazon EFS for Lambda?

Gli sviluppatori possono collegare facilmente un file system EFS esistente a una funzione Lambda tramite un Access Point EFS utilizzando la console, l'interfaccia a riga di comando 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.

D: Devo configurare la mia funzione con le impostazioni VPC prima di poter utilizzare il mio file system Amazon EFS?

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.

D: A chi è destinato Amazon EFS for Lambda?

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.

D: I miei dati in transito verranno crittografati?

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.

D: I dati di cui dispongo sono inattivi?

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ò non occorre nemmeno più creare e mantenere una propria infrastruttura di gestione delle chiavi di sicurezza.

D: Quali sono i costi addebitati per l'uso di Amazon EFS for AWS Lambda?

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.

D: Posso associare più di un file system Amazon EFS alla mia funzione AWS Lambda?

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

D: Posso utilizzare lo stesso file system Amazon EFS su più funzioni, container e istanze?

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.  

Estensioni Lambda

D: Cosa sono le estensioni AWS Lambda?

Le estensioni AWS Lambda consentono di integrare Lambda con i tuoi strumenti preferiti per il monitoraggio, l'osservabilità, la sicurezza e la governance. Le estensioni consentono a te e ai tuoi produttori di strumenti preferiti di inserirvi nel ciclo di vita di Lambda e integrarvi in modo più approfondito nell'ambiente di esecuzione di Lambda.

D: Come funzionano le estensioni Lambda?

Le estensioni sono procedure complementari che vengono eseguite all'interno dell'ambiente di esecuzione di Lambda, ovvero dove viene eseguito il codice della funzione. Inoltre, possono essere eseguite all'esterno dell'invocazione della funzione, ad esempio possono essere avviate prima che la funzione venga inizializzata, possono essere eseguite in parallelo alla funzione, dopo il completamento dell'esecuzione della funzione e anche prima che il servizio Lambda interrompa l'ambiente di esecuzione.

D: A cosa mi possono servire le estensioni Lambda?

Puoi utilizzare le estensioni per i tuoi strumenti preferiti di monitoraggio, osservabilità, sicurezza e governance di AWS e dei seguenti partner: AppDynamics, Coralogix, Datadog, Dynatrace, Epsagon, HashiCorp, Honeycomb, Imperva, Lumigo, Check Point CloudGuard, New Relic, Thundra, Splunk, Sentry, Site24x7, Sumo Logic, AWS AppConfig, Amazon CodeGuru Profiler, Amazon CloudWatch Lambda Insights, AWS Distro for OpenTelemetry. Per ulteriori informazioni su queste estensioni, visita il post del blog di lancio.

D: Come faccio a configurare e gestire le estensioni Lambda?

Puoi distribuire le estensioni, utilizzando i livelli, su una o più funzioni Lambda tramite Console, CLI o strumenti Infrastructure as Code come CloudFormation, AWS Serverless Application Model e Terraform. Per iniziare, consulta la documentazione.

D: Con quali runtime posso utilizzare le estensioni AWS Lambda?

Puoi visualizzare l'elenco dei runtime che supportano le estensioniqui.

D: Le estensioni vengono conteggiate nel limite del pacchetto di implementazione?

Sì, le dimensioni totali decompresse della funzione e di tutte le estensioni non possono superare il limite delle dimensioni del pacchetto di distribuzione decompresso pari a 250 MB.

D: L'uso di un'estensione influisce sulle prestazioni?

Le estensioni possono influire sulle prestazioni della tua funzione poiché condividono risorse come CPU, memoria e archiviazione con la funzione e poiché le estensioni vengono inizializzate prima del codice della funzione. Ad esempio, se una funzione svolge operazioni con uso intensivo della memoria, potresti osservare un aumento della durata di esecuzione della funzione poiché l'estensione e il codice della funzione condividono le stesse risorse della CPU. Dato che Lambda alloca una CPU proporzionale in base all'impostazione di memoria scelta, potresti vedere una maggiore durata di esecuzione e inizializzazione con impostazioni di memoria inferiori; questo perché più processi concorrono per le stesse risorse della CPU.

Puoi utilizzare il parametro PostRuntimeExecutionDuration per misurare il tempo aggiuntivo utilizzato dall'estensione dopo l'esecuzione della funzione e puoi utilizzare il parametro MaxMemoryUsed per misurare l'aumento di memoria utilizzata. Per capire l'impatto di una specifica estensione, puoi usare anche il parametro Duration. Attualmente, la risposta di esecuzione della funzione viene restituita al termine dell'esecuzione della funzione e dell'esecuzione dell'estensione. Per ulteriori informazioni, consulta la documentazione per gli sviluppatori Lambda.

D: Come vengono addebitati i costi per l'uso delle estensioni Lambda?

Le estensioni utilizzano lo stesso modello di fatturazione delle funzioni Lambda. Quando utilizzi le funzioni Lambda con le estensioni, paghi per la richiesta salvata e il tempo di elaborazione combinato utilizzato per eseguire il codice e tutte le estensioni, in incrementi da 1 ms. Ti verrà addebitato il tempo di elaborazione in base ai prezzi esistenti per la durata Lambda. Per ulteriori informazioni, consulta prezzi di AWS Lambda.

Il ciclo di vita Lambda è costituito da tre fasi distinte: "init", quando AWS Lambda inizializza la funzione, le dipendenze e le estensioni; "invoke", quando Lambda esegue la funzione e il codice dell'estensione in risposta a trigger; e "shut down", quando l'esecuzione della funzione è terminata ma il codice dell'estensione potrebbe ancora essere in esecuzione e che possono durare fino a due secondi. Ti sarà addebitato il tempo di elaborazione usato per eseguire l'estensione durante tutte e tre le fasi del ciclo di vita Lambda. Per ulteriori informazioni sul ciclo di vita di Lambda, consulta la documentazione sull'ambiente di esecuzione Lambda.

Non vi sono costi aggiuntivi per l'installazione delle estensioni, ma le offerte dei partner potrebbero essere addebitabili. Consulta il sito Web del partner per ulteriori dettagli.

D: Posso creare le mie estensioni Lambda personalizzate?

Sì, utilizzando l'API AWS Lambda Runtime Extensions. Per ulteriori informazioni, consulta la documentazione.

D: Come funzionano le estensioni quanto è abilitato Provisioned Concurrency?

Provisioned Concurrency mantiene inizializzate le funzioni e pronte a reagire in meno di cento millisecondi. Quando abilitato, Provisioned Concurrency inizializza inoltre le estensioni, tenendole pronte a essere eseguite assieme al codice della funzione.

D: Quali autorizzazioni hanno le estensioni?

Dal momento che le estensioni vengono eseguite nello stesso ambiente di una funzione Lambda, queste hanno accesso alle stesse risorse della funzione e le autorizzazioni vengono condivise tra la funzione e le estensioni. Quindi condividono le variabili di credenziali, ruolo e ambiente. Le estensioni hanno accesso in sola lettura al codice della funzione e possono leggere e scrivere in /tmp.

D: Cos'è l'API dei dati di telemetria di AWS Lambda?

L'API dei dati di telemetria di AWS Lambda ti consente di utilizzare le estensioni per acquisire dati di monitoraggio e osservabilità avanzati direttamente da Lambda e inviarli a una destinazione a tua scelta.

D: Come funziona l'API dei dati di telemetria?

Il servizio Lambda acquisisce automaticamente i dati di telemetria e li invia in streaming ad Amazon CloudWatch e AWS X-Ray. L'API dei dati di telemetria fornisce una semplice interfaccia HTTP o TCP per consentire alle estensioni di ricevere gli stessi dati di telemetria insieme agli eventi del ciclo di vita dell'ambiente di esecuzione Lambda e ai parametri a livello di chiamata di funzione. Le estensioni possono utilizzare l'API dei dati di telemetria per utilizzare questi flussi di telemetria direttamente da Lambda, e quindi elaborarli, filtrarli e inviarli a qualsiasi destinazione preferita.

D: Come si inizia a usare l'API dei dati di telemetria?

Puoi distribuire le estensioni abilitate per l’API dei dati di telemetria per le tue funzioni Lambda, utilizzando la console AWS Lambda, AWS CLI o strumenti Infrastructure as Code come AWS CloudFormation, AWS Serverless Application Model (SAM) e Terraform. Non è necessario apportare modifiche al codice per utilizzare un'estensione abilitata per l'API dei dati di telemetria con la funzione Lambda. Aggiungi semplicemente un'estensione dal fornitore di strumenti di tua scelta alla tua funzione Lambda.  Per iniziare con le estensioni dei partner APN, segui i link forniti nel post del blog di lancio. Puoi anche creare la tua estensione che utilizza l'API dei dati di telemetria. Per sapere come, consulta la Guida per gli sviluppatori AWS Lambda.

D: L'uso dell'API dei dati di telemetria influisce sulle prestazioni?

Puoi utilizzare l'API dei dati di telemetria soltanto all'interno delle estensioni AWS Lambda. Le estensioni possono influire sulle prestazioni della tua funzione poiché condividono risorse come CPU, memoria e archiviazione con la funzione. L'uso della memoria aumenta in modo lineare con l'aumentare del numero di iscrizioni all'API dei dati di telemetria perché ogni iscrizione apre un nuovo buffer di memoria per archiviare i dati di telemetria. Puoi tuttavia ottimizzare l'utilizzo della memoria regolando la configurazione del buffer nella richiesta di iscrizione all'API dei dati di telemetria. Si consiglia ai fornitori di estensioni di pubblicare il consumo di risorse previsto per facilitare agli sviluppatori di funzioni la scelta di un'estensione adatta. Consulta la documentazione del fornitore di estensioni per comprendere il potenziale sovraccarico delle prestazioni dato dall’uso della rispettiva estensione.

D: Come vengono addebitati i costi per l'uso dell'API dei dati di telemetria?

Non sono previsti costi aggiuntivi per l'utilizzo dell'API dei dati di telemetria di AWS Lambda. Le estensioni che utilizzano l'API dei dati di telemetria condividono lo stesso modello di fatturazione delle altre estensioni e funzioni Lambda. Per ulteriori informazioni sui prezzi delle estensioni, consulta la pagina dei prezzi Lambda.

D: Utilizzare l'API dei dati di telemetria disattiva l'invio dei log ai file di log Amazon CloudWatch?

No, per modalità predefinita, il servizio Lambda invia tutti i dati di telemetria a CloudWatch Logs e utilizzare l'API dei dati di telemetria non disattiva il traffico verso CloudWatch Logs.

URL di funzione Lambda

D: Le funzioni AWS Lambda supportano gli endpoint HTTPS?

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.

D: Come posso configurare l'URL di una funzione Lambda per la mia funzione?

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

D: Come posso proteggere l'URL della mia funzione Lambda?

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.

D: Come posso richiamare la mia funzione con una URL di funzione Lambda?

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

D: Le URL della funzione Lambda funzionano con le versioni e gli alias della funzione?

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.

D: Posso abilitare domini personalizzati per l'URL della mia funzione Lambda?

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.

 D: PGli URL delle funzioni Lambda possono essere usati per invocare una funzione in un VPC?

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

D: Quanto costano le URL di funzione Lambda?

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

D: Cos'è Lambda@Edge?

Lambda@Edge permette di eseguire codice nelle regioni AWS in tutto il mondo senza effettuare il provisioning o gestire i server, inviando le 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 si riceve 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.

D: Come si usa Lambda@Edge?

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.

D: In quali casi è indicato usare Lambda@Edge?

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.

D: È possibile distribuire le funzioni Lambda esistenti per chiamate globali?

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

D: Quali eventi Amazon CloudFront è possibile utilizzare per attivare le funzioni?

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.

D: Quali sono le differenze di utilizzo tra AWS Lambda@Edge e AWS Lambda di Amazon API Gateway?

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 e alla propria.

Scalabilità e disponibilità

D: Qual è il livello di disponibilità offerto dalle funzioni AWS Lambda?

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.

D: Le funzioni AWS Lambda conservano la disponibilità anche dopo eventuali modifiche al codice o alla configurazione?

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.

D: È previsto un limite al numero di funzioni AWS Lambda che è possibile eseguire contemporaneamente?

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, che possono essere utilizzate per riservare un sottoinsieme del limite di concorrenza dell'account per le funzioni principali o per limitare la velocità 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. 

D: Cosa succede se un account supera il limite predefinito di esecuzioni simultanee?

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

D: I limiti massimi predefiniti di esecuzioni simultanee si applicano a livello di singola funzione?

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

D: Quanto velocemente si dimensionano le funzioni AWS Lambda?

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.

D: Che cosa succede in caso di errori della funzione Lambda durante l'elaborazione di un evento?

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.

D: Che cosa succede se le chiamate a una funzione Lambda superano i limiti stabiliti nella relativa policy?

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. Se si supera la policy di ripetizione tentativi per le invocazioni basate sui flussi, i dati sarebbero già scaduti e pertanto rifiutati.

D: Quali risorse è possibile configurare come coda DLQ per una funzione Lambda?

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

Sicurezza e controllo degli accessi

D: In che modo è possibile consentire a una funzione AWS Lambda di accedere ad altre risorse AWS?

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 Configurazione di AWS Lambda.

D: In che modo è possibile verificare quali bucket Amazon S3 possono richiamare le varie funzioni 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 per le risorse e i controlli degli accessi per le funzioni Lambda, consulta la Guida per gli sviluppatori di AWS Lambda.

D: In che modo è possibile verificare di quali tabelle Amazon DynamoDB o flussi Amazon Kinesis può eseguire il polling una funzione AWS 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.

D: Come si controlla la coda di Amazon SQS di cui una funzione di AWS Lambda può eseguire il polling?

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.

D: Come posso accedere alle risorse in Amazon VPC dalla mia funzione 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.

D: In che cosa consiste la firma del codice per AWS Lambda?

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 gli elementi di codice con firma digitale e per configurare le funzioni Lambda per verificare le firme durante l’implementazione. La firma del codice per AWS Lambda è attualmente disponibile solo per le funzioni impacchettate come archivi ZIP.

D: Come faccio a creare elementi di codice con firma digitale?

Puoi creare elementi 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.

D: Come faccio a configurare le funzioni Lambda per abilitare la firma del codice?

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.

D: Quali controlli della firma esegue AWS Lambda in fase di implementazione?

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.

D: Posso abilitare la firma del codice per le funzioni esistenti?

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.

D: Sono previsti costi aggiuntivi per l'utilizzo di firma del codice per 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.

Controlli di registrazione avanzati

D: Quali controlli di registrazione avanzati sono supportati su Lambda?

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.

D: Per cosa posso usare i controlli di registrazione avanzati?

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. Puoi anche 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.

D: Come si utilizzano i controlli di registrazione avanzati?

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.

D: Posso usare le mie librerie di registrazione per generare log strutturati JSON per la mia funzione 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.

D: Come mi verrà addebitato l'utilizzo dei controlli di registrazione avanzati?

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.

Funzioni AWS Lambda in Java

D: Come si compila il codice Java di una funzione AWS 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.

D: Quale ambiente JVM viene usato da Lambda per l'esecuzione di una funzione?

Lambda offre la build Amazon Linux 1.8 di openjdk.

Funzioni AWS Lambda in Node.js

D: È possibile usare pacchetti con AWS Lambda?

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

D: È possibile eseguire altri programmi da una funzione AWS Lambda scritta in Node.js?

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.

D: È possibile usare moduli nativi con funzioni AWS Lambda scritte in Node.js?

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.

D: È possibile eseguire file binari con AWS Lambda scritti in Node.js?

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.

D: In che modo è possibile distribuire il codice di una funzione AWS Lambda scritta in Node.js?

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.

Funzioni AWS Lambda in Python

D: È possibile usare pacchetti Python con AWS Lambda?

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

Funzioni AWS Lambda in C#

D: In che modo è possibile includere in pacchetti e distribuire una funzione AWS Lambda in C#?

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

Funzioni AWS Lambda in PowerShell

In che modo è possibile distribuire il codice di una funzione AWS Lambda scritta in PowerShell?

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.

In che modo è possibile distribuire il codice di una funzione AWS Lambda scritta in PowerShell?  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.
In che modo è possibile distribuire il codice di una funzione AWS Lambda scritta in PowerShell?  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.

Funzioni AWS Lambda in Go

D: In che modo è possibile includere in pacchetti e distribuire una funzione AWS Lambda in Go 

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

Funzioni AWS Lambda in Ruby

Q: In che modo è possibile distribuire il codice di una funzione AWS Lambda scritta in Ruby? 

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.

Altri argomenti

D: Quali versioni di Amazon Linux, Node.js, Python, JDK, .NET Core, SDK e altre librerie supporta AWS Lambda?

È possibile visualizzare l'elenco delle versioni supportate qui.

D: È possibile modificare la versione di Amazon Linux o un runtime del linguaggio?

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.

D: In che modo è possibile registrare e controllare le chiamate effettuate all'API AWS 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.

D: In che modo è possibile coordinare le chiamate tra più funzioni 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.

D: AWS Lambda supporta Advanced Vector Extensions 2 (AVX2)?

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 per migliorare le prestazioni, consulta la documentazione per sviluppatori AWS Lambda.

Ulteriori informazioni sui prezzi di AWS Lambda

Visita la pagina dei prezzi
Sei pronto per iniziare?
Registrati
Hai altre domande?
Contattaci