Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Runtime Lambda
Lambda supporta più lingue attraverso l'uso di *runtime*. Un runtime fornisce un ambiente specifico del linguaggio che inoltra gli eventi di chiamata, le informazioni di contesto e le risposte tra Lambda e la funzione. Puoi utilizzare i runtime forniti da Lambda o puoi crearne uno personalizzato.
Lambda è indipendente dalla tua scelta di runtime. Per funzioni semplici, i linguaggi interpretati come Python e Node.js offrono le prestazioni più veloci. Per le funzioni con calcoli più complessi, i linguaggi compilati come Java sono spesso più lenti da inizializzare ma vengono eseguiti rapidamente nell'handler Lambda. La scelta del runtime è influenzata anche dalle preferenze degli sviluppatori e dalla familiarità del linguaggio.
Ogni versione del linguaggio di programmazione principale ha un runtime separato, con un *identificatore di runtime* univoco, ad esempio `nodejs24.x` o `python3.14`. Per configurare una funzione in modo da utilizzare una nuova versione principale del linguaggio, è necessario modificare l'identificatore di runtime. Poiché AWS Lambda non è possibile garantire la retrocompatibilità tra le versioni principali, si tratta di un'operazione gestita dal cliente.
Per una [funzione definita come immagine di container](images-create.md), scegli un runtime e la distribuzione Linux quando crei l'immagine di container. Per modificare il runtime, è necessario creare una nuova immagine di container.
Quando si utilizza un archivio di file con estensione .zip per il pacchetto di implementazione, è necessario scegliere un runtime quando si crea la funzione. Per modificare il runtime, è possibile [aggiornare la configurazione della funzione](configuration-function-zip.md). Il runtime è associato a una delle distribuzioni Amazon Linux. L'ambiente di esecuzione sottostante fornisce ulteriori librerie e [variabili di ambiente](configuration-envvars.md) alle quali è possibile accedere dal codice della funzione.
Lambda richiama la funzione in un [ambiente di esecuzione](lambda-runtime-environment.md). Un ambiente di esecuzione fornisce un ambiente di runtime sicuro e isolato che gestisce le risorse necessarie per eseguire la funzione. Lambda riutilizza l'ambiente di esecuzione da una chiamata precedente, se disponibile, oppure può creare un nuovo ambiente di esecuzione.
Per utilizzare altri linguaggi in Lambda, come [Go](lambda-golang.md) o [Rust](lambda-rust.md), utilizza un [runtime solo per il sistema operativo](runtimes-provided.md). L'ambiente di esecuzione Lambda offre un'[interfaccia di runtime](runtimes-api.md) per ricevere gli eventi di chiamata e inviare le risposte. Puoi implementare altri linguaggi implementando un [runtime personalizzato](runtimes-custom.md) insieme al codice della funzione o in un [livello](chapter-layers.md).
## Runtime supportati
Nella tabella seguente sono elencati i runtime Lambda supportati e le date di ritiro previste. Una volta ritirato un runtime, è ancora possibile creare e aggiornare le funzioni per un periodo limitato. Per ulteriori informazioni, consulta [Utilizzo del runtime dopo la deprecazione](#runtime-deprecation-levels). La tabella fornisce le date attualmente previste per l'obsolescenza del runtime, in base alle nostre. [Policy di deprecazione del runtime](#runtime-support-policy) Tali date vengono indicate a scopo di pianificazione e sono soggette a modifiche.
**Importante**
La fine del ciclo di vita di Amazon Linux 2 è prevista per il 30 giugno 2026. I runtime Lambda e le immagini base dei container per Java 8 (AL2), Java 11, Java 17, Python 3.10, Python 3.11 e provided.al2 continueranno a ricevere patch [per importanti problemi di sicurezza di Amazon Linux 2 critici e selezionati](https://alas.aws.amazon.com/faqs.html), oltre alle patch di runtime del linguaggio, fino alle date di deprecazione indicate nella tabella seguente.
Consigliamo ai clienti di eseguire l'aggiornamento a un runtime basato su Amazon Linux 2023 il prima possibile. Per i clienti che effettuano l'aggiornamento a Java 21 o Java 25, è possibile utilizzare [AWS Transform custom](https://docs.aws.amazon.com/transform/latest/userguide/custom.html) per fornire assistenza con questi aggiornamenti. Per i clienti che non possono aggiornare la loro versione Java, prevediamo di rilasciare i runtime basati su Amazon Linux 2023 per Java 8, Java 11 e Java 17 prima della fine del secondo trimestre 2026.
| Name | Identificatore | Sistema operativo | Data di ritiro | Blocco creazione funzioni | Blocco aggiornamento funzioni |
| --- | --- | --- | --- | --- | --- |
| Node.js 24 | `nodejs24.x` | Amazon Linux 2023 | 30 aprile 2028 | 1 giugno 2028 | 1 luglio 2028 |
| Node.js 22 | `nodejs22.x` | Amazon Linux 2023 | 30 aprile 2027 | 1 giugno 2027 | 1 luglio 2027 |
| Node.js 20 | `nodejs20.x` | Amazon Linux 2023 | 30 aprile 2026 | 31 agosto 2026 | 30 settembre 2026 |
| Python 3.14 | `python3.14` | Amazon Linux 2023 | 30 giugno 2029 | 31 luglio 2029 | 31 agosto 2029 |
| Python 3.13 | `python3.13` | Amazon Linux 2023 | 30 giugno 2029 | 31 luglio 2029 | 31 agosto 2029 |
| Python 3.12 | `python3.12` | Amazon Linux 2023 | 31 ottobre 2028 | 30 novembre 2028 | 10 gennaio 2029 |
| Python 3.11 | `python3.11` | Amazon Linux 2 | 30 giugno 2027 | 31 luglio 2027 | 31 agosto 2027 |
| Python 3.10 | `python3.10` | Amazon Linux 2 | 31 ottobre 2026 | 30 novembre 2026 | 15 gennaio 2027 |
| Giava 25 | `java25` | Amazon Linux 2023 | 30 giugno 2029 | 31 luglio 2029 | 31 agosto 2029 |
| Java 21 | `java21` | Amazon Linux 2023 | 30 giugno 2029 | 31 luglio 2029 | 31 agosto 2029 |
| Java 17 | `java17` | Amazon Linux 2 | 30 giugno 2027 | 31 luglio 2027 | 31 agosto 2027 |
| Java 11 | `java11` | Amazon Linux 2 | 30 giugno 2027 | 31 luglio 2027 | 31 agosto 2027 |
| Java 8 | `java8.al2` | Amazon Linux 2 | 30 giugno 2027 | 31 luglio 2027 | 31 agosto 2027 |
| .NET 10 | `dotnet10` | Amazon Linux 2023 | 14 novembre 2028 | 14 dicembre 2028 | 15 gennaio 2029 |
| .NET 9 (solo contenitore) | `dotnet9` | Amazon Linux 2023 | 10 novembre 2026 | Non programmato | Non programmato |
| .NET 8 | `dotnet8` | Amazon Linux 2023 | 10 novembre 2026 | 10 dicembre 2026 | 11 gennaio 2027 |
| Rubino 3.4 | `ruby3.4` | Amazon Linux 2023 | 31 marzo 2028 | 30 aprile 2028 | 31 maggio 2028 |
| Ruby 3.3 | `ruby3.3` | Amazon Linux 2023 | 31 marzo 2027 | 30 aprile 2027 | 31 maggio 2027 |
| Ruby 3.2 | `ruby3.2` | Amazon Linux 2 | 31 marzo 2026 | 31 agosto 2026 | 30 settembre 2026 |
| Runtime solo per il sistema operativo | `provided.al2023` | Amazon Linux 2023 | 30 giugno 2029 | 31 luglio 2029 | 31 agosto 2029 |
| Runtime solo per il sistema operativo | `provided.al2` | Amazon Linux 2 | 31 luglio 2026 | 31 agosto 2026 | 30 settembre 2026 |
**Nota**
Per le nuove regioni, Lambda non supporterà i runtime per cui è previsto il ritiro entro i prossimi 6 mesi.
Lambda mantiene aggiornati i runtime gestiti e le immagini di base dei container corrispondenti con patch e supporto per le versioni minori. Per ulteriori informazioni, consulta [Aggiornamenti di runtime Lambda](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-update.html).
Per interagire a livello di codice con altre Servizi AWS risorse della funzione Lambda, puoi usare una delle. AWS SDKs I runtime Node.js, Python e Ruby includono una versione dell'SDK. AWS [Tuttavia, per mantenere il pieno controllo delle dipendenze e massimizzare la [compatibilità](runtimes-update.md#runtime-update-compatibility) con le versioni precedenti durante gli aggiornamenti automatici del runtime, ti consigliamo di includere sempre i moduli SDK utilizzati dal codice (insieme a qualsiasi dipendenza) nel pacchetto di distribuzione della funzione o in un livello Lambda.](chapter-layers.md)
Ti consigliamo di utilizzare la versione SDK inclusa nel runtime solo quando non puoi includere pacchetti aggiuntivi nella distribuzione. Ad esempio, quando crei la tua funzione utilizzando l'editor di codice della console Lambda o utilizzando il codice di funzione in linea in un modello. CloudFormation
Lambda aggiorna periodicamente le versioni AWS SDKs incluse nei runtime Node.js, Python e Ruby. Per determinare la versione dell' AWS SDK inclusa nel runtime che stai utilizzando, consulta le seguenti sezioni:
+ [Versioni SDK incluse nel runtime (Node.js)](lambda-nodejs.md#nodejs-sdk-included)
+ [Versioni SDK incluse nel runtime (Python)](lambda-python.md#python-sdk-included)
+ [Versioni SDK incluse nel runtime (Ruby)](lambda-ruby.md#ruby-sdk-included)
Lambda continua a supportare il linguaggio di programmazione Go dopo il ritiro del runtime Go 1.x. *Per ulteriori informazioni, consulta la sezione [Migrazione AWS Lambda delle funzioni dal runtime Go1.x al runtime personalizzato su Amazon Linux 2](https://aws.amazon.com/blogs/compute/migrating-aws-lambda-functions-from-the-go1-x-runtime-to-the-custom-runtime-on-amazon-linux-2/) sul blog di Compute AWS .*
Tutti i runtime Lambda supportati supportano sia le architetture x86\$164 che le architetture arm64.
## Nuovi rilasci di runtime
Lambda fornisce runtime gestiti per le nuove versioni di linguaggio solo quando il rilascio raggiunge la fase di supporto a lungo termine (LTS) del ciclo di rilascio del linguaggio. Ad esempio, per il [ciclo di rilascio di Node.js](https://nodejs.org/en/about/previous-releases), quando il rilascio raggiunge la fase Active LTS.
Prima che raggiunga la fase di supporto a lungo termine, il rilascio rimane in fase di sviluppo e può ancora essere soggetto a modifiche sostanziali. Lambda applica in automatico gli aggiornamenti di runtime per impostazione predefinita, quindi le modifiche sostanziali a una versione di runtime potrebbe impedire alle funzioni di funzionare come previsto.
Lambda non fornisce runtime gestiti per le versioni di linguaggio che non sono pianificate per il rilascio LTS.
L'elenco seguente mostra il mese di lancio previsto per i runtime Lambda futuri. Queste date sono solo indicative e soggette a modifica.
+ **Ruby 3.5** - marzo 2026
+ **Java 8, 11 e 17 nel 2023 - 2° AL2 trimestre 2026**
+ **Node.js 26 - novembre 2026**
+ **Python 3.15** - novembre 2026
## Policy di deprecazione del runtime
I runtime Lambda per gli archivi di file.zip si basano su una combinazione di sistema operativo, linguaggio di programmazione e librerie software soggette a manutenzione e aggiornamenti di sicurezza. In base alla policy di deprecazione standard di Lambda, un runtime diventa obsoleto quando uno dei suoi componenti principali raggiunge la fine del supporto a lungo termine (LTS) della community e gli aggiornamenti di sicurezza non sono più disponibili. In genere si tratta del runtime del linguaggio, anche se in alcuni casi un runtime può diventare obsoleto perché il sistema operativo (OS) raggiunge la fine dell'LTS.
Dopo che un runtime è diventato obsoleto, non AWS possono più applicare patch o aggiornamenti di sicurezza a quel runtime e le funzioni che utilizzano quel runtime non sono più idonee per il supporto tecnico. Tali runtime obsoleti vengono forniti "così come sono", senza alcuna garanzia e possono contenere bug, errori, difetti o altre vulnerabilità.
[https://aws.amazon.com/blogs/compute/managing-aws-lambda-runtime-upgrades/](https://aws.amazon.com/blogs/compute/managing-aws-lambda-runtime-upgrades/)
**Importante**
Occasionalmente, Lambda ritarda la deprecazione di un runtime Lambda per un periodo limitato oltre la data di fine del supporto della versione di linguaggio supportata dal runtime. Durante questo periodo, Lambda applica le patch di sicurezza soltanto al sistema operativo runtime. Una volta raggiunta la data di fine del supporto, Lambda non applica le patch di sicurezza ai runtime dei linguaggi di programmazione.
## Modello di responsabilità condivisa
Lambda è responsabile della cura e della pubblicazione degli aggiornamenti di sicurezza per tutti i runtime gestiti e le immagini dei container supportati. Per impostazione predefinita, Lambda applica automaticamente questi aggiornamenti alle funzioni che utilizzano runtime gestiti. Se l'impostazione predefinita per l'aggiornamento automatico del runtime è stata modificata, consulta il [modello di responsabilità condivisa dei controlli di gestione del runtime](runtime-management-shared.md). Per le funzioni implementate utilizzando immagini di container, l'utente sarà responsabile della ricostruzione dell'immagine di container della funzione dall'immagine di base più recente e della nuova implementazione dell'immagine di container.
Quando un runtime diventa obsoleto, la responsabilità di Lambda per l'aggiornamento del runtime gestito e delle immagini di base del container cessa. L'utente è responsabile dell'aggiornamento delle funzioni per utilizzare un runtime o un'immagine di base supportata.
In tutti i casi, l'utente è responsabile dell'applicazione degli aggiornamenti al codice della funzione, comprese le sue dipendenze. Le tue responsabilità nell'ambito del modello di responsabilità condivisa sono riassunte nella tabella seguente.
| Fase del ciclo di vita di runtime | Responsabilità di Lambda | Le tue responsabilità |
| --- | --- | --- |
| Runtime gestito supportato | Fornisci aggiornamenti di runtime regolari con patch di sicurezza e altri aggiornamenti. Applica automaticamente gli aggiornamenti di runtime per impostazione predefinita (vedi [Modalità di aggiornamento del runtime](runtimes-update.md#runtime-management-controls) per i comportamenti non predefiniti). | Aggiorna il codice della funzione, comprese le dipendenze, per risolvere eventuali vulnerabilità di sicurezza. |
| Immagine di container supportata | Fornisci aggiornamenti di runtime regolari all'immagine di base del container con patch di sicurezza e altri aggiornamenti. | Aggiorna il codice della funzione, comprese le dipendenze, per risolvere eventuali vulnerabilità di sicurezza. Ricostruisci e reimplementa regolarmente l'immagine di container utilizzando l'immagine di base più recente. |
| Runtime gestito prossimo alla deprecazione | Avvisate i clienti prima della deprecazione del runtime tramite documentazione, e-mail e. Health Dashboard Trusted Advisor La responsabilità per gli aggiornamenti del runtime termina quando il runtime diventa obsoleto. | Monitora la documentazione di Lambda Health Dashboard, la posta elettronica o le informazioni sull'obsolescenza in fase Trusted Advisor di esecuzione. Aggiorna le funzioni a un runtime supportato prima che il runtime precedente diventi obsoleto. |
| Immagine di container che si avvicina alla deprecazione | Le notifiche di deprecazione non sono disponibili per le funzioni che utilizzano immagini di container. La responsabilità per gli aggiornamenti dell'immagine di base del container termina quando il runtime diventa obsoleto. | Fai attenzione alle pianificazioni di deprecazione e alle funzioni di aggiornamento a un'immagine di base supportata prima che l'immagine precedente diventi obsoleta. |
## Utilizzo del runtime dopo la deprecazione
Dopo che un runtime è diventato obsoleto, non AWS possono più applicare patch di sicurezza o aggiornamenti a quel runtime e le funzioni che utilizzano quel runtime non sono più idonee al supporto tecnico. Sebbene sia possibile continuare a richiamare le funzioni a tempo indeterminato, si consiglia AWS vivamente di migrare a un runtime supportato. I runtime obsoleti vengono forniti «così come sono», senza alcuna garanzia e possono contenere bug, errori, difetti o altre vulnerabilità. Le funzioni che utilizzano un runtime obsoleto possono inoltre presentare un peggioramento delle prestazioni o altri problemi, come la scadenza del certificato, che possono impedirne il corretto funzionamento.
È possibile aggiornare una funzione per utilizzare un runtime supportato più recente in qualsiasi momento dopo che un runtime è diventato obsoleto. Consigliamo di testare la funzione con il nuovo runtime prima di applicare le modifiche negli ambienti di produzione. Non sarà possibile tornare al runtime obsoleto dopo il blocco degli aggiornamenti delle funzioni. Consigliamo di utilizzare le [versioni](configuration-versions.md) e gli [alias](configuration-aliases.md) delle funzioni per consentire una implementazione sicura con rollback.
La seguente sequenza temporale descrive cosa succede quando un runtime è obsoleto:
| Fase del ciclo di vita di runtime | Quando | What |
| --- | --- | --- |
| Periodo di avviso di obsolescenza | Almeno 180 giorni prima della deprecazione | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/lambda-runtimes.html) |
| Raggiunta obsolescenza | Data di ritiro | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/lambda-runtimes.html) |
| Blocco creazione funzioni | Almeno 30 giorni dopo la deprecazione | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/lambda-runtimes.html) |
| Blocco aggiornamento funzioni | Almeno 60 giorni dopo la deprecazione | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/lambda-runtimes.html) |
**Nota**
Per alcuni runtime, AWS posticipa block-function-update le date di fine oltre i normali 30 block-function-create e 60 giorni dopo la deprecazione. AWS ha apportato questa modifica in risposta al feedback dei clienti per darti più tempo per aggiornare le tue funzioni. Fai riferimento alle tabelle riportate in [Runtime supportati](#runtimes-supported) e [Runtime obsoleti](#runtimes-deprecated) per vedere le date dei runtime. Lambda non inizierà a bloccare la creazione o l'aggiornamento delle funzioni prima delle date indicate in queste tabelle.
## Ricezione di notifiche di ritiro del runtime
Quando un runtime si avvicina alla data di deprecazione, Lambda invia un avviso e-mail se alcune funzioni del runtime utilizzano quel runtime. Account AWS Le notifiche vengono visualizzate anche in e in. Health Dashboard AWS Trusted Advisor
+ Ricezione di notifiche e-mail:
Lambda ti invia un avviso e-mail almeno **180 giorni** prima che un runtime venga ritirato. Questa e-mail elenca le versioni \$1LATEST di tutte le funzioni che utilizzano il runtime. Per visualizzare un elenco completo delle versioni delle funzioni interessate, usa Trusted Advisor o see[Recuperare dati sulle funzioni Lambda che utilizzano un runtime obsoleto](runtimes-list-deprecated.md).
Lambda invia una notifica via e-mail al contatto principale Account AWS del tuo account. Per informazioni sulla visualizzazione o l'aggiornamento degli indirizzi e-mail nel tuo account, consulta la pagina [Aggiornamento delle informazioni di contatto](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html) della *Guida generale di AWS *.
+ Ricezione di notifiche tramite: Health Dashboard
Health Dashboard Visualizza una notifica almeno **180 giorni** prima che un runtime diventi obsoleto. Le notifiche compaiono nella pagina **Stato del tuo account**, in [Altre notifiche](https://health.aws.amazon.com/health/home#/account/dashboard/other-notifications). La scheda **Risorse interessate** della notifica elenca le versioni \$1LATEST di tutte le funzioni che utilizzano il runtime.
**Nota**
Per visualizzare un up-to-date elenco completo delle versioni delle funzioni interessate, usa Trusted Advisor or see. [Recuperare dati sulle funzioni Lambda che utilizzano un runtime obsoleto](runtimes-list-deprecated.md)
Health Dashboard le notifiche scadono 90 giorni dopo che il runtime interessato è diventato obsoleto.
+ Usando AWS Trusted Advisor
Trusted Advisor visualizza una notifica almeno **180 giorni** prima che un runtime diventi obsoleto. Le notifiche compaiono nella pagina [Sicurezza](https://console.aws.amazon.com/trustedadvisor/home#/category/security). Un elenco delle funzioni interessate viene visualizzato in **Funzioni AWS Lambda che utilizzano runtime ritirati**. Questo elenco di funzioni mostra sia le versioni \$1LATEST sia le versioni pubblicate e si aggiorna in automatico per riflettere lo stato attuale delle funzioni.
Puoi attivare le notifiche e-mail settimanali dalla Trusted Advisor pagina [Preferenze](https://console.aws.amazon.com/trustedadvisor/home?#/preferences) della console. Trusted Advisor
## Runtime obsoleti
Per i seguenti runtime è stata raggiunta la fine del supporto:
| Name | Identificatore | Sistema operativo | Data di ritiro | Blocco creazione funzioni | Blocco aggiornamento funzioni |
| --- | --- | --- | --- | --- | --- |
| Python 3.9 | python3.9 | Amazon Linux 2 | 15 dicembre 2025 | 31 agosto 2026 | 30 settembre 2026 |
| Node.js 18 | nodejs18.x | Amazon Linux 2 | 1 settembre 2025 | 31 agosto 2026 | 30 settembre 2026 |
| .NET 6 | dotnet6 | Amazon Linux 2 | 20 dicembre 2024 | 31 agosto 2026 | 30 settembre 2026 |
| Python 3.8 | python3.8 | Amazon Linux 2 | 14 ottobre 2024 | 31 agosto 2026 | 30 settembre 2026 |
| Node.js 16 | nodejs16.x | Amazon Linux 2 | 12 giugno 2024 | 31 agosto 2026 | 30 settembre 2026 |
| .NET 7 (solo container) | dotnet7 | Amazon Linux 2 | 14 maggio 2024 | N/D | N/D |
| Java 8 | java8 | Amazon Linux | 8 gennaio 2024 | 8 febbraio 2024 | 30 settembre 2026 |
| Go 1.x | go1.x | Amazon Linux | 8 gennaio 2024 | 8 febbraio 2024 | 30 settembre 2026 |
| Runtime solo per il sistema operativo | provided | Amazon Linux | 8 gennaio 2024 | 8 febbraio 2024 | 30 settembre 2026 |
| Ruby 2.7 | ruby2.7 | Amazon Linux 2 | 7 dicembre 2023 | 9 gennaio 2024 | 30 settembre 2026 |
| Node.js 14 | nodejs14.x | Amazon Linux 2 | 4 dicembre 2023 | 9 gennaio 2024 | 30 settembre 2026 |
| Python 3.7 | python3.7 | Amazon Linux | 4 dicembre 2023 | 9 gennaio 2024 | 30 settembre 2026 |
| .NET Core 3.1 | dotnetcore3.1 | Amazon Linux 2 | 3 aprile 2023 | 3 aprile 2023 | 3 maggio 2023 |
| Node.js 12 | nodejs12.x | Amazon Linux 2 | 31 marzo 2023 | 31 marzo 2023 | 30 aprile 2023 |
| Python 3.6 | python3.6 | Amazon Linux | 18 luglio 2022 | 18 luglio 2022 | 29 agosto 2022 |
| .NET 5 (solo container) | dotnet5.0 | Amazon Linux 2 | 10 maggio 2022 | N/D | N/D |
| .NET Core 2.1 | dotnetcore2.1 | Amazon Linux | 5 gennaio 2022 | 5 gennaio 2022 | 13 aprile 2022 |
| Node.js 10 | nodejs10.x | Amazon Linux 2 | 30 luglio 2021 | 30 luglio 2021 | 14 febbraio 2022 |
| Ruby 2.5 | ruby2.5 | Amazon Linux | 30 luglio 2021 | 30 luglio 2021 | 31 marzo 2022 |
| Python 2.7 | python2.7 | Amazon Linux | 15 luglio 2021 | 15 luglio 2021 | 30 maggio 2022 |
| Node.js 8.10 | nodejs8.10 | Amazon Linux | 6 marzo 2020 | 4 febbraio 2020 | 6 marzo 2020 |
| Node.js 4.3 | nodejs4.3 | Amazon Linux | 5 marzo 2020 | 3 febbraio 2020 | 5 marzo 2020 |
| Node.js 4.3 edge | nodejs4.3-edge | Amazon Linux | 5 marzo 2020 | 31 marzo 2019 | 30 aprile 2019 |
| Node.js 6.10 | nodejs6.10 | Amazon Linux | 12 agosto 2019 | 12 luglio 2019 | 12 agosto 2019 |
| .NET Core 1.0 | dotnetcore1.0 | Amazon Linux | 27 giugno 2019 | 30 giugno 2019 | 30 luglio 2019 |
| .NET Core 2.0 | dotnetcore2.0 | Amazon Linux | 30 maggio 2019 | 30 aprile 2019 | 30 maggio 2019 |
| Node.js 0.10 | nodejs | Amazon Linux | 30 agosto 2016 | 30 settembre 2016 | 31 ottobre 2016 |
Nella quasi totalità dei casi, la end-of-life data della versione linguistica o del sistema operativo è nota con largo anticipo. I seguenti collegamenti forniscono le end-of-life pianificazioni per ogni lingua supportata da Lambda come runtime gestito.
**Policy di supporto su linguaggio e framework**
+ **Node.js** – [github.com](https://github.com/nodejs/Release#release-schedule)
+ **Python** – [devguide.python.org](https://devguide.python.org/versions/#versions)
+ **Ruby** – [www.ruby-lang.org](https://www.ruby-lang.org/en/downloads/branches/)
+ **Java** [— [www.oracle.com](https://www.oracle.com/java/technologies/java-se-support-roadmap.html) e Corretto FAQs](https://aws.amazon.com/corretto/faqs/)
+ **Go** – [golang.org](https://golang.org/doc/devel/release.html)
+ **.NET** – [dotnet.microsoft.com](https://dotnet.microsoft.com/platform/support/policy/dotnet-core)
# Informazioni su come Lambda gestisce gli aggiornamenti delle versioni di runtime
Lambda mantiene aggiornato ogni runtime gestito con aggiornamenti di sicurezza, correzioni di bug, nuove funzionalità, miglioramenti delle prestazioni e supporto per versioni minori. Questi aggiornamenti di runtime vengono pubblicati come *versioni di runtime*. Lambda applica gli aggiornamenti di runtime alle funzioni migrando la funzione da una versione di runtime precedente a una nuova versione di runtime.
Per impostazione predefinita, Lambda applica automaticamente gli aggiornamenti di runtime alle funzioni che utilizzano runtime gestiti. Con gli aggiornamenti automatici del runtime, Lambda si assume l'onere operativo dell'applicazione di patch alle versioni di runtime. Per la maggior parte dei clienti, gli aggiornamenti automatici sono la scelta ideale. È possibile modificare questo comportamento predefinito [configurando le impostazioni di gestione del runtime](runtime-management-configure-settings.md).
Lambda pubblica inoltre ogni nuova versione di runtime come immagine di container. Per aggiornare le versioni di runtime per le funzioni basate su container, è necessario [creare una nuova immagine di container](images-create.md) dall'immagine di base aggiornata e implementare nuovamente la funzione.
Ogni versione di runtime è associata a un numero di versione e a un nome della risorsa Amazon (ARN). I numeri di versione di runtime utilizzano uno schema numerico definito da Lambda indipendente dai numeri di versione utilizzati dal linguaggio di programmazione. I numeri di versione di runtime non sono sempre sequenziali. Ad esempio, la versione 42 potrebbe essere seguita dalla versione 45. L'ARN della versione di runtime è un identificatore univoco per ogni versione di runtime. È possibile visualizzare l'ARN della versione di runtime corrente della funzione nella console Lambda o nella [riga `INIT_START` dei log della funzione](runtime-management-identify.md).
Le versioni di runtime non devono essere confuse con gli identificatori di runtime. Ogni runtime ha un **identificatore di runtime univoco**, ad esempio `python3.14` o `nodejs24.x`. Questi corrispondono a ciascuna delle principali versioni del linguaggio di programmazione. Le versioni di runtime descrivono la versione patch di un singolo runtime.
**Nota**
L'ARN per lo stesso numero di versione di runtime può variare tra le architetture Regioni AWS della CPU.
**Topics**
+ [
## Compatibilità con le versioni precedenti
](#runtime-update-compatibility)
+ [
## Modalità di aggiornamento del runtime
](#runtime-management-controls)
+ [
## Rollout della versione runtime in due fasi
](#runtime-management-two-phase)
+ [
# Configurazione delle impostazioni di gestione del runtime Lambda
](runtime-management-configure-settings.md)
+ [
# Rollback di una versione di runtime Lambda
](runtime-management-rollback.md)
+ [
# Identificazione delle modifiche alla versione di runtime di Lambda
](runtime-management-identify.md)
+ [
# Informazioni sul modello di responsabilità condivisa per la gestione del runtime Lambda
](runtime-management-shared.md)
+ [
# Controllo delle autorizzazioni di aggiornamento del runtime Lambda per applicazioni ad alta conformità
](runtime-management-hc-applications.md)
## Compatibilità con le versioni precedenti
Lambda fornisce aggiornamenti di runtime compatibili con le versioni precedenti delle funzioni esistenti. Tuttavia, come nel caso delle patch software, ci sono rari casi in cui un aggiornamento del runtime può influire negativamente su una funzione esistente. Ad esempio, le patch di sicurezza possono evidenziare un problema di fondo di una funzione esistente che dipende dal comportamento precedente e non sicuro.
Quando si crea e si distribuisce una funzione, è importante capire come gestire le dipendenze per evitare potenziali incompatibilità con un futuro aggiornamento di runtime. Ad esempio, supponiamo che la funzione dipenda dal pacchetto A, che a sua volta dipende dal pacchetto B. Entrambi i pacchetti sono inclusi nel runtime Lambda (ad esempio, potrebbero far parte dell'SDK o delle sue dipendenze o parti delle librerie del sistema di runtime).
Considerare i seguenti scenari:
| Implementazione | Compatibile con le patch | Motivo |
| --- | --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/runtimes-update.html) | Sì | I futuri aggiornamenti di runtime ai pacchetti A e B sono compatibili con le versioni precedenti. |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/runtimes-update.html) | Sì | La tua distribuzione ha la precedenza, quindi i futuri aggiornamenti di runtime ai pacchetti A e B non hanno alcun effetto. |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/runtimes-update.html) | Sì\$1 | I futuri aggiornamenti di runtime al pacchetto B sono compatibili con le versioni precedenti. \$1Se A e B sono strettamente accoppiati, possono verificarsi problemi di compatibilità. Ad esempio, i `botocore` pacchetti `boto3` and nell' AWS SDK per Python devono essere distribuiti insieme. |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/runtimes-update.html) | No | I futuri aggiornamenti di runtime del pacchetto A potrebbero richiedere una versione aggiornata del pacchetto B. Tuttavia, la versione distribuita del pacchetto B ha la precedenza e potrebbe non essere compatibile con la versione aggiornata del pacchetto A. |
Per mantenere la compatibilità con i futuri aggiornamenti di runtime, segui queste best practice:
+ **Quando possibile, impacchetta tutte le dipendenze: includi tutte le librerie richieste, incluso l' AWS SDK e le sue dipendenze, nel pacchetto** di distribuzione. Ciò garantisce un set di componenti stabile e compatibile.
+ **Usa SDKs con moderazione i pacchetti forniti in fase di esecuzione:** affidati all'SDK fornito in fase di esecuzione solo quando non puoi includere pacchetti aggiuntivi (ad esempio, quando usi l'editor di codice della console Lambda o il codice in linea in un modello). AWS CloudFormation
+ **Evita di sovrascrivere le librerie di sistema:** non distribuire librerie di sistemi operativi personalizzate che potrebbero entrare in conflitto con i futuri aggiornamenti di runtime.
## Modalità di aggiornamento del runtime
Lambda fornisce aggiornamenti di runtime compatibili con le versioni precedenti delle funzioni esistenti. Tuttavia, come nel caso delle patch software, ci sono rari casi in cui un aggiornamento del runtime può influire negativamente su una funzione esistente. Ad esempio, le patch di sicurezza possono evidenziare un problema di fondo di una funzione esistente che dipende dal comportamento precedente e non sicuro. I controlli di gestione del runtime Lambda aiutano a ridurre il rischio di impatto sui carichi di lavoro nel raro caso di incompatibilità delle versioni di runtime. Per ogni [versione della funzione](configuration-versions.md) (`$LATEST`o versione pubblicata), è possibile scegliere una delle seguenti modalità di aggiornamento del runtime:
+ **Auto (default)** (Automatico [impostazione predefinita]): esegue automaticamente l'aggiornamento alla versione di runtime più recente e sicura tramite una [Rollout della versione runtime in due fasi](#runtime-management-two-phase). Consigliamo questa modalità alla maggior parte dei clienti in modo da beneficiare sempre degli aggiornamenti di runtime.
+ **Aggiornamento delle funzioni**: aggiorna alla versione di runtime più recente e sicura quando aggiorni la funzione. Quando aggiorni la funzione, Lambda aggiorna il runtime della funzione alla versione più recente e sicura. Questo approccio sincronizza gli aggiornamenti del runtime con le implementazioni delle funzioni, dando all'utente il controllo su quando Lambda applica gli aggiornamenti del runtime. Con questa modalità, è possibile rilevare e mitigare tempestivamente le rare incompatibilità degli aggiornamenti del runtime. Quando si utilizza questa modalità, è necessario aggiornare regolarmente le funzioni in modo da mantenerne aggiornato il runtime.
+ **Manuale**: aggiorna manualmente la versione del runtime. Specifica una versione di runtime nella configurazione della funzione. La funzione utilizzerà questa versione di runtime a tempo indeterminato. Nel raro caso in cui una nuova versione di runtime non sia compatibile con una funzione esistente, ciò consente di ripristinare la funzione a una versione di runtime precedente. Si consiglia di non utilizzare la modalità **Manual** (Manuale) per cercare di ottenere la coerenza del runtime tra le varie implementazioni. Per ulteriori informazioni, consulta [Rollback di una versione di runtime Lambda](runtime-management-rollback.md).
La responsabilità dell'applicazione degli aggiornamenti di runtime alle funzioni varia in base alla modalità di aggiornamento del runtime scelta. Per ulteriori informazioni, consulta [Informazioni sul modello di responsabilità condivisa per la gestione del runtime Lambda](runtime-management-shared.md).
## Rollout della versione runtime in due fasi
Lambda introduce nuove versioni di runtime nel seguente ordine:
1. Nella prima fase Lambda utilizza la nuova versione di runtime ogni volta che crei o aggiorni una funzione. Una funzione viene aggiornata quando si chiamano le operazioni [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html)o l'[UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)API.
1. Nella seconda fase, Lambda aggiorna qualsiasi funzione che utilizza la modalità di aggiornamento del runtime **Auto** e che non è già stata aggiornata alla nuova versione di runtime.
La durata complessiva del processo di rollout varia in base a diversi fattori, tra cui la gravità di eventuali patch di sicurezza incluse nell'aggiornamento del runtime.
Se si stanno sviluppando e implementando attivamente le funzioni, è molto probabile che vengano acquistate nuove versioni di runtime durante la prima fase. Ciò sincronizza gli aggiornamenti del runtime con gli aggiornamenti delle funzioni. Nel raro caso in cui l'ultima versione di runtime abbia un impatto negativo sull'applicazione, questo approccio ti permette di intraprendere azioni correttive in maniera tempestiva. Le funzioni che non sono in fase di sviluppo attivo ricevono comunque i vantaggi operativi degli aggiornamenti automatici del runtime durante la seconda fase.
Questo approccio non influisce sulle funzioni impostate sulla modalità **Function update** (Aggiornamento della funzione) o **Manual** (Manuale). Le funzioni che utilizzano la modalità **Function update** (Aggiornamento della funzione) ricevono gli aggiornamenti di runtime più recenti solo quando vengono create o aggiornate. Le funzioni che utilizzano la modalità **Manual** (Manuale) non ricevono aggiornamenti di runtime.
Lambda pubblica nuove versioni di runtime in modo graduale e continuo nelle Regioni AWS. Se le funzioni sono impostate sulle modalità **Auto** (Aggiornamento automatico) o **Function update** (Aggiornamento della funzione), è possibile che le funzioni implementate nello stesso momento in regioni diverse o in momenti diversi nella stessa regione abbiano versioni di runtime diverse. I clienti che richiedono una coerenza delle versioni di runtime garantita nei propri ambienti devono [utilizzare le immagini di container per implementare le proprie funzioni Lambda](images-create.md). La modalità **Manuale** è concepita come mitigazione temporanea per consentire il rollback della versione di runtime nel raro caso in cui una versione di runtime non sia compatibile con la tua funzione.
# Configurazione delle impostazioni di gestione del runtime Lambda
È possibile configurare le impostazioni di gestione del runtime utilizzando la console Lambda o AWS Command Line Interface (AWS CLI).
**Nota**
È possibile configurare le impostazioni di gestione del runtime separatamente per ciascuna [versione della funzione](configuration-versions.md).
**Configurazione del modo in cui Lambda aggiorna la versione di runtime (console)**
1. Aprire la pagina [Functions](https://console.aws.amazon.com/lambda/home#/functions) (Funzioni) della console Lambda.
1. Scegliere il nome della funzione.
1. Nella scheda **Code** (Codice), in **Runtime settings** (Impostazioni di runtime), scegli **Edit runtime management configuration** (Modifica configurazione di gestione del runtime).
1. In **Runtime management configuration** (Configurazione di gestione del runtime), scegli una delle seguenti opzioni:
+ Per aggiornare automaticamente la funzione all'ultima versione di runtime, scegli **Auto** (Automatico).
+ Per fare in modo che la funzione venga aggiornata all'ultima versione di runtime quando si modifica la funzione, scegli **Function update** (Aggiornamento della funzione).
+ Perché la funzione venga aggiornata all'ultima versione di runtime solo quando si modifica l'ARN della versione di runtime, scegli **Manual** (Manuale). L'ARN della versione di runtime è disponibile in **Configurazione della gestione del runtime**. L'ARN è disponibile anche nella riga `INIT_START` dei log della funzione.
Per ulteriori informazioni su queste opzioni, consulta [Modalità di aggiornamento del runtime](runtimes-update.md#runtime-management-controls).
1. Selezionare **Salva**.
**Configurazione del modo in cui Lambda aggiorna la versione di runtime (AWS CLI)**
Per configurare la gestione del runtime per una funzione, esegui il comando [put-runtime-management-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/put-runtime-management-config.html) della AWS CLI. Quando si utilizza la modalità `Manual`, è necessario fornire anche l'ARN della versione di runtime.
```
aws lambda put-runtime-management-config \
--function-name my-function \
--update-runtime-on Manual \
--runtime-version-arn arn:aws:lambda:us-east-2::runtime:8eeff65f6809a3ce81507fe733fe09b835899b99481ba22fd75b5a7338290ec1
```
Verrà visualizzato un output simile al seguente:
```
{
"UpdateRuntimeOn": "Manual",
"FunctionArn": "arn:aws:lambda:us-east-2:111122223333:function:my-function",
"RuntimeVersionArn": "arn:aws:lambda:us-east-2::runtime:8eeff65f6809a3ce81507fe733fe09b835899b99481ba22fd75b5a7338290ec1"
}
```
# Rollback di una versione di runtime Lambda
Nel raro caso in cui una nuova versione di runtime non sia compatibile con una funzione esistente, è possibile ripristinare la versione di runtime a una versione precedente. Ciò mantiene l'applicazione funzionante e riduce al minimo le interruzioni, dando il tempo necessario per porre rimedio all'incompatibilità prima di tornare alla versione di runtime più recente.
Lambda non impone un limite per il tempo che è possibile utilizzare una particolare versione di runtime. Tuttavia, consigliamo vivamente di eseguire sempre l'aggiornamento all'ultima versione di runtime il prima possibile per beneficiare delle patch di sicurezza, dei miglioramenti delle prestazioni e delle funzionalità più recenti. Lambda offre la possibilità di ripristinare una versione di runtime precedente solo come mitigazione temporanea nel raro caso in cui si verifichi un problema di compatibilità con gli aggiornamenti del runtime. Le funzioni che utilizzano una versione di runtime precedente per un periodo prolungato possono alla fine presentare un peggioramento delle prestazioni o problemi, come la scadenza del certificato, che possono impedirne il corretto funzionamento.
Puoi eseguire il rollback di una versione di runtime nei seguenti modi:
+ [Utilizzo della modalità manuale per l'aggiornamento del runtime](#runtime-management-rollback-manual)
+ [Utilizzo delle versioni pubblicate della funzione](#runtime-management-rollback-published)
Per ulteriori informazioni, consulta [Introduzione ai controlli di gestione del runtime AWS Lambda](https://aws.amazon.com/blogs/compute/introducing-aws-lambda-runtime-management-controls/) sul blog di AWS Compute.
## Rollback di una versione di runtime tramite la modalità di aggiornamento del runtime Manual (Manuale)
Se utilizzi la modalità di aggiornamento della versione di runtime **Auto** (Automatico) o stai utilizzando la versione di runtime `$LATEST`, puoi ripristinare la versione di runtime precedente utilizzando la modalità **Manual** (Manuale). Per la [versione della funzione](configuration-versions.md) che desideri ripristinare, modifica la modalità di aggiornamento della versione di runtime in **Manual** (Manuale) e specifica l'ARN della versione di runtime precedente. Per ulteriori informazioni su come trovare l'ARN della versione di runtime precedente, consulta [Identificazione delle modifiche alla versione di runtime di Lambda](runtime-management-identify.md).
**Nota**
Se la versione `$LATEST` della funzione è configurata per utilizzare la modalità **Manual** (Manuale), non è possibile modificare l'architettura della CPU o la versione di runtime utilizzata dalla funzione. Per apportare queste modifiche, è necessario passare alla modalità di aggiornamento **Auto** (Automatico) o **Function update** (Aggiornamento della funzione).
## Rollback di una versione di runtime utilizzando le versioni pubblicate della funzione
Le [versioni delle funzioni](configuration-versions.md) pubblicate sono un'istantanea immutabile del codice e della configurazione della funzione `$LATEST` al momento della loro creazione. In modalità **Auto** (Automatico), Lambda aggiorna automaticamente la versione di runtime delle versioni delle funzioni pubblicate durante la seconda fase del rollout della versione di runtime. In modalità **Function update** (Aggiornamento della funzione), Lambda non aggiorna la versione di runtime delle versioni delle funzioni pubblicate.
Le versioni delle funzioni pubblicate che utilizzano la modalità **Function update** (Aggiornamento della funzione) creano quindi un'istantanea statica del codice della funzione, della configurazione e della versione di runtime. Utilizzando la modalità **Function update** (Aggiornamento della funzione) con le versioni delle funzioni, è possibile sincronizzare gli aggiornamenti di runtime con le varie implementazioni. È possibile coordinare il rollback del codice, della configurazione e delle versioni di runtime anche reindirizzando il traffico verso una versione della funzione pubblicata in precedenza. Questo approccio può essere integrato nell'integrazione continua e distribuzione continua (CI/CD) per un rollback completamente automatico nel raro caso di incompatibilità degli aggiornamenti di runtime. Quando si utilizza questo approccio, è necessario aggiornare regolarmente la funzione e pubblicare nuove versioni delle funzioni per avere gli ultimi aggiornamenti di runtime. Per ulteriori informazioni, consulta [Informazioni sul modello di responsabilità condivisa per la gestione del runtime Lambda](runtime-management-shared.md).
# Identificazione delle modifiche alla versione di runtime di Lambda
Il numero di versione di runtime e l'ARN vengono registrati nella riga del log `INIT_START`, che Lambda invia a CloudWatch Logs ogni volta che crea un nuovo . Poiché l'ambiente di esecuzione utilizza la stessa versione di runtime per tutte le chiamate di funzione, Lambda emette la riga di log `INIT_START` solo quando esegue la fase di inizializzazione. Non emette questa riga di log per ogni chiamata di funzione. Lambda invia la riga di log a CloudWatch Logs, ma non è visibile nella console.
**Nota**
I numeri di versione di runtime non sono sempre sequenziali. Ad esempio, la versione 42 potrebbe essere seguita dalla versione 45.
**Example Riga di log INIT\$1START di esempio**
```
INIT_START Runtime Version: python:3.13.v14 Runtime Version ARN: arn:aws:lambda:eu-south-1::runtime:7b620fc2e66107a1046b140b9d320295811af3ad5d4c6a011fad1fa65127e9e6I
```
Anziché lavorare direttamente con i log, è possibile utilizzare [Approfondimenti sulle contribuzioni Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights-CreateRule.html) per identificare le transizioni tra le versioni di runtime. La regola seguente conta le versioni di runtime distinte di ciascuna riga di log `INIT_START`. Per utilizzare la regola, sostituisci il nome del gruppo di log di esempio `/aws/lambda/*` con il prefisso appropriato per la funzione o il gruppo di funzioni.
```
{
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
},
"AggregateOn": "Count",
"Contribution": {
"Filters": [
{
"Match": "eventType",
"In": [
"INIT_START"
]
}
],
"Keys": [
"runtimeVersion",
"runtimeVersionArn"
]
},
"LogFormat": "CLF",
"LogGroupNames": [
"/aws/lambda/*"
],
"Fields": {
"1": "eventType",
"4": "runtimeVersion",
"8": "runtimeVersionArn"
}
}
```
Il seguente report di Approfondimenti sulle contribuzioni CloudWatch mostra un esempio di transizione della versione di runtime acquisita dalla regola precedente. La riga arancione mostra l'inizializzazione dell'ambiente di esecuzione per la versione di runtime precedente (**python:3.13.v12**) mentre la linea blu mostra l'inizializzazione dell'ambiente di esecuzione per la nuova versione di runtime (**python:3.13.v14**).
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/runtime_version_graph.png)
# Informazioni sul modello di responsabilità condivisa per la gestione del runtime Lambda
Lambda è responsabile della cura e della pubblicazione degli aggiornamenti di sicurezza per tutti i runtime gestiti e le immagini dei container supportati. La responsabilità di aggiornare le funzioni esistenti per utilizzare la versione di runtime più recente varia a seconda della modalità di aggiornamento del runtime utilizzata.
Lambda è responsabile dell'applicazione degli aggiornamenti di runtime a tutte le funzioni configurate per l'uso la modalità di aggiornamento del runtime **Auto** (Automatico).
Per le funzioni configurate con la modalità di aggiornamento del runtime **Function update** (Aggiornamento della funzione), l'utente è responsabile dell'aggiornamento regolare della funzione. Lambda è responsabile dell'applicazione degli aggiornamenti di runtime quando si effettuano tali aggiornamenti. Se non aggiorni la funzione, Lambda non aggiorna il runtime. Se non aggiorni regolarmente la tua funzione, ti consigliamo vivamente di configurarla per gli aggiornamenti automatici del runtime in modo da continuare a ricevere aggiornamenti di sicurezza.
Per le funzioni configurate per utilizzare la modalità di aggiornamento del runtime **Manual** (Manuale), l'utente è responsabile dell'aggiornamento della funzione per l'uso della versione di runtime più recente. Si consiglia vivamente di utilizzare questa modalità solo per ripristinare la versione di runtime come mitigazione temporanea nel raro caso di incompatibilità degli aggiornamenti del runtime. Ti consigliamo inoltre di passare alla modalità **Auto** (Automatico) il più rapidamente possibile per ridurre al minimo il tempo in cui le tue funzioni non vengono aggiornate.
Se [per implementare le funzioni, vengono utilizzate le immagini di container](images-create.md), Lambda è responsabile della pubblicazione delle immagini di base aggiornate. In questo caso, l'utente sarà responsabile della ricostruzione dell'immagine di container della funzione dall'immagine di base più recente e della nuova implementazione dell'immagine di container.
Ciò è riassunto nella seguente tabella:
****
| Deployment mode (Modalità distribuzione) | Responsabilità di Lambda | Responsabilità del cliente |
| --- | --- | --- |
| Runtime gestito, modalità Auto (Automatico) | Pubblica nuove versioni di runtime contenenti le patch più recenti. Applica le patch di runtime alle funzioni esistenti. | Torna a una versione di runtime precedente nel raro caso in cui si verifichi un problema di compatibilità con l'aggiornamento del runtime. Segui le migliori pratiche per la [compatibilità con le versioni precedenti](runtimes-update.md#runtime-update-compatibility). |
| Runtime gestito, modalità Function update (Aggiornamento della funzione) | Pubblica nuove versioni di runtime contenenti le patch più recenti. | Aggiorna regolarmente le funzioni per utilizzare la versione di runtime più recente. Passa una funzione alla modalità **Auto** (Automatico) quando questa non viene aggiornata regolarmente. Torna a una versione di runtime precedente nel raro caso in cui si verifichi un problema di compatibilità con l'aggiornamento del runtime. Segui le migliori pratiche per la compatibilità con le [versioni precedenti](runtimes-update.md#runtime-update-compatibility). |
| Runtime gestito, modalità Manual (Manuale) | Pubblica nuove versioni di runtime contenenti le patch più recenti. | Utilizza questa modalità solo per il rollback temporaneo del runtime nel raro caso in cui si verifichi un problema di compatibilità con gli aggiornamenti del runtime. Passa le funzioni alla modalità di aggiornamento **Auto** (Automatico) o **Function update** (Aggiornamento della funzione) e alla versione di runtime più recente il più presto possibile. |
| Immagine di container | Pubblica nuove immagini di container contenenti le patch più recenti. | Implementa nuovamente le funzioni in maniera regolare utilizzando l'immagine di base del container più recente per utilizzare le patch più recenti. |
Per ulteriori informazioni sulla responsabilità condivisa con AWS, consulta [Modello di responsabilità condivisa](https://aws.amazon.com/compliance/shared-responsibility-model/).
# Controllo delle autorizzazioni di aggiornamento del runtime Lambda per applicazioni ad alta conformità
Per soddisfare i requisiti di patch, i clienti Lambda in genere si affidano agli aggiornamenti automatici del runtime. Se la tua applicazione è soggetta a severi requisiti di aggiornamento delle patch, potresti voler limitare l'uso delle versioni di runtime precedenti. È possibile limitare i controlli di gestione del runtime di Lambda utilizzando AWS Identity and Access Management (IAM) per negare agli utenti del proprio account AWS l'accesso all'operazione API [PutRuntimeManagementConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutRuntimeManagementConfig.html). Questa operazione viene utilizzata per scegliere la modalità di aggiornamento del runtime per una funzione. Se si nega l'accesso a questa operazione, tutte le funzioni passeranno automaticamente alla modalità **Auto** (Automatico). È possibile applicare questa limitazione in tutta l'organizzazione utilizzando una [policy di controllo dei servizi](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html). Nel caso in cui sia necessario ripristinare una funzione a una versione di runtime precedente, è possibile concedere un'eccezione alla policy caso per caso.
# Recuperare dati sulle funzioni Lambda che utilizzano un runtime obsoleto
Quando un runtime Lambda sta per diventare obsoleto, Lambda ti avvisa tramite e-mail e fornisce notifiche al termine. Health Dashboard Trusted Advisor Queste e-mail e notifiche elencano le versioni \$1LATEST delle funzioni che utilizzano il runtime. Per elencare tutte le versioni delle funzioni che utilizzano un determinato runtime, puoi usare il () o uno dei AWS Command Line Interface .AWS CLI AWS SDKs
Se disponi di un gran numero di funzioni che utilizzano un runtime destinato a diventare obsoleto, puoi anche usare AWS CLI or AWS SDKs per aiutarti a dare priorità agli aggiornamenti delle funzioni richiamate più comunemente.
Fate riferimento alle seguenti sezioni per imparare a utilizzare AWS CLI e AWS SDKs raccogliere dati sulle funzioni che utilizzano un particolare runtime.
## Elenco delle versioni delle funzioni che utilizzano un determinato runtime
Per utilizzare AWS CLI per elencare tutte le versioni delle funzioni che utilizzano un determinato runtime, esegui il comando seguente. Sostituiscilo `RUNTIME_IDENTIFIER` con il nome del runtime che è diventato obsoleto e scegli il tuo. Regione AWS Per elencare solo le versioni della funzione \$1LATEST, ometti `--function-version ALL` dal comando.
```
aws lambda list-functions --function-version ALL --region us-east-1 --output text --query "Functions[?Runtime=='RUNTIME_IDENTIFIER'].FunctionArn"
```
**Suggerimento**
Il comando di esempio elenca le funzioni nella `us-east-1` regione per una determinata regione. Account AWS Dovrai ripetere questo comando per ogni regione in cui il tuo account ha funzioni e per ognuna delle tue. Account AWS
Puoi anche elencare le funzioni che utilizzano un particolare runtime utilizzando uno dei AWS SDKs. Il codice di esempio seguente utilizza V3 AWS SDK per JavaScript e the AWS SDK per Python (Boto3) per restituire un elenco della funzione ARNs per le funzioni che utilizzano un determinato runtime. Il codice di esempio restituisce anche il gruppo di CloudWatch log per ciascuna delle funzioni elencate. È possibile utilizzare questo gruppo di log per trovare la data dell'ultima invocazione per la funzione. Per ulteriori informazioni, consulta la sezione [Identificazione delle funzioni richiamate più di frequente e più di recente](#runtimes-list-deprecated-statistics) seguente.
------
#### [ Node.js ]
**Example JavaScript codice per elencare le funzioni utilizzando un particolare runtime**
```
import { LambdaClient, ListFunctionsCommand } from "@aws-sdk/client-lambda";
const lambdaClient = new LambdaClient();
const command = new ListFunctionsCommand({
FunctionVersion: "ALL",
MaxItems: 50
});
const response = await lambdaClient.send(command);
for (const f of response.Functions){
if (f.Runtime == ''){ // Use the runtime id, e.g. 'nodejs24.x' or 'python3.14'
console.log(f.FunctionArn);
// get the CloudWatch log group of the function to
// use later for finding the last invocation date
console.log(f.LoggingConfig.LogGroup);
}
}
// If your account has more functions than the specified
// MaxItems, use the returned pagination token in the
// next request with the 'Marker' parameter
if ('NextMarker' in response){
let paginationToken = response.NextMarker;
}
```
------
#### [ Python ]
**Example Codice Python per elencare le funzioni utilizzando un particolare runtime**
```
import boto3
from botocore.exceptions import ClientError
def list_lambda_functions(target_runtime):
lambda_client = boto3.client('lambda')
response = lambda_client.list_functions(
FunctionVersion='ALL',
MaxItems=50
)
if not response['Functions']:
print("No Lambda functions found")
else:
for function in response['Functions']:
if function['PackageType']=='Zip' and function['Runtime'] == target_runtime:
print(function['FunctionArn'])
# Print the CloudWatch log group of the function
# to use later for finding last invocation date
print(function['LoggingConfig']['LogGroup'])
if 'NextMarker' in response:
pagination_token = response['NextMarker']
if __name__ == "__main__":
# Replace python3.12 with the appropriate runtime ID for your Lambda functions
list_lambda_functions('python3.12')
```
------
Per ulteriori informazioni sull'utilizzo di un AWS SDK per elencare le funzioni utilizzando l'[ListFunctions](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctions.html)azione, consulta la [documentazione SDK relativa](https://aws.amazon.com/developer/tools/) al linguaggio di programmazione preferito.
Puoi anche utilizzare la funzionalità Interrogazioni AWS Config avanzate per elencare tutte le funzioni che utilizzano un runtime interessato. Questa query restituisce solo le versioni della funzione \$1LATEST, ma è possibile aggregare le query per elencare le funzioni in tutte le regioni e più regioni Account AWS con un solo comando. *Per ulteriori informazioni, consulta [Interrogazione dello stato di configurazione corrente delle AWS Auto Scaling risorse](https://docs.aws.amazon.com/config/latest/developerguide/querying-AWS-resources.html) nella Guida per gli sviluppatori.AWS Config *
## Identificazione delle funzioni richiamate più di frequente e più di recente
Se il tuo Account AWS file contiene funzioni che utilizzano un runtime che sta per essere obsoleto, potresti voler dare priorità all'aggiornamento delle funzioni che vengono richiamate di frequente o delle funzioni che sono state richiamate di recente.
Se disponi solo di poche funzioni, puoi utilizzare la console CloudWatch Logs per raccogliere queste informazioni esaminando i flussi di registro delle tue funzioni. Per ulteriori informazioni, consulta [Visualizzare i dati di registro inviati ai CloudWatch registri.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData)
Per vedere il numero di chiamate di funzioni recenti, puoi anche utilizzare le informazioni sulle CloudWatch metriche mostrate nella console Lambda. Per visualizzare queste informazioni, completa le seguenti operazioni:
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Seleziona la funzione per la quale desideri visualizzare le statistiche sull'invocazione.
1. Selezionare la scheda **Monitor (Monitora)**.
1. Imposta il periodo di tempo per cui desideri visualizzare le statistiche utilizzando il selettore dell'intervallo di date. Le invocazioni recenti vengono visualizzate nel riquadro **Invocazioni**.
Per gli account con un numero maggiore di funzioni, può essere più efficiente raccogliere questi dati a livello di codice utilizzando AWS CLI o una delle azioni using the e API. AWS SDKs [DescribeLogStreams[GetMetricStatistics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DescribeLogStreams.html)
Gli esempi seguenti forniscono frammenti di codice che utilizzano V3 AWS SDK per JavaScript e AWS SDK per Python (Boto3) per identificare la data dell'ultima chiamata per una particolare funzione e per determinare il numero di chiamate per una particolare funzione negli ultimi 14 giorni.
------
#### [ Node.js ]
**Example JavaScript codice per trovare l'ora dell'ultima chiamata per una funzione**
```
import { CloudWatchLogsClient, DescribeLogStreamsCommand } from "@aws-sdk/client-cloudwatch-logs";
const cloudWatchLogsClient = new CloudWatchLogsClient();
const command = new DescribeLogStreamsCommand({
logGroupName: '',
orderBy: 'LastEventTime',
descending: true,
limit: 1
});
try {
const response = await cloudWatchLogsClient.send(command);
const lastEventTimestamp = response.logStreams.length > 0 ?
response.logStreams[0].lastEventTimestamp : null;
// Convert the UNIX timestamp to a human-readable format for display
const date = new Date(lastEventTimestamp).toLocaleDateString();
const time = new Date(lastEventTimestamp).toLocaleTimeString();
console.log(`${date} ${time}`);
} catch (e){
console.error('Log group not found.')
}
```
------
#### [ Python ]
**Example Codice Python per trovare l'ora dell'ultima invocazione per una funzione**
```
import boto3
from datetime import datetime
cloudwatch_logs_client = boto3.client('logs')
response = cloudwatch_logs_client.describe_log_streams(
logGroupName='',
orderBy='LastEventTime',
descending=True,
limit=1
)
try:
if len(response['logStreams']) > 0:
last_event_timestamp = response['logStreams'][0]['lastEventTimestamp']
print(datetime.fromtimestamp(last_event_timestamp/1000)) # Convert timestamp from ms to seconds
else:
last_event_timestamp = None
except:
print('Log group not found')
```
------
**Suggerimento**
Puoi trovare il nome del gruppo di log della tua funzione utilizzando l'operazione [ListFunctions](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctions.html)API. Per un esempio su come eseguire questa operazione, consulta [Elenco delle versioni delle funzioni che utilizzano un determinato runtime](#runtimes-list-deprecated-versions).
------
#### [ Node.js ]
**Example JavaScript codice per trovare il numero di chiamate negli ultimi 14 giorni**
```
import { CloudWatchClient, GetMetricStatisticsCommand } from "@aws-sdk/client-cloudwatch";
const cloudWatchClient = new CloudWatchClient();
const command = new GetMetricStatisticsCommand({
Namespace: 'AWS/Lambda',
MetricName: 'Invocations',
StartTime: new Date(Date.now()-86400*1000*14), // 14 days ago
EndTime: new Date(Date.now()),
Period: 86400 * 14, // 14 days.
Statistics: ['Sum'],
Dimensions: [{
Name: 'FunctionName',
Value: ''
}]
});
const response = await cloudWatchClient.send(command);
const invokesInLast14Days = response.Datapoints.length > 0 ?
response.Datapoints[0].Sum : 0;
console.log('Number of invocations: ' + invokesInLast14Days);
```
------
#### [ Python ]
**Example Codice Python per trovare il numero di invocazioni negli ultimi 14 giorni**
```
import boto3
from datetime import datetime, timedelta
cloudwatch_client = boto3.client('cloudwatch')
response = cloudwatch_client.get_metric_statistics(
Namespace='AWS/Lambda',
MetricName='Invocations',
Dimensions=[
{
'Name': 'FunctionName',
'Value': ''
},
],
StartTime=datetime.now() - timedelta(days=14),
EndTime=datetime.now(),
Period=86400 * 14, # 14 days
Statistics=[
'Sum'
]
)
if len(response['Datapoints']) > 0:
invokes_in_last_14_days = int(response['Datapoints'][0]['Sum'])
else:
invokes_in_last_14_days = 0
print(f'Number of invocations: {invokes_in_last_14_days}')
```
------
# Modifica dell'ambiente di runtime
È possibile utilizzare le [estensioni interne](lambda-extensions.md) per modificare il processo di runtime. Le estensioni interne non sono processi separati, sono eseguiti nell'ambito del processo di runtime.
Lambda fornisce [variabili di ambiente](configuration-envvars.md) specifiche della lingua che è possibile impostare per aggiungere opzioni e strumenti al runtime. Lambda fornisce anche [Script wrapper](#runtime-wrapper), che consentono a Lambda di delegare l'avvio del runtime allo script. È possibile creare uno script wrapper per personalizzare il comportamento di avvio del runtime.
## Variabili di ambiente specifiche della lingua
Lambda supporta metodi di sola configurazione per abilitare il precaricamento del codice durante l'inizializzazione della funzione tramite le seguenti variabili di ambiente specifiche della lingua:
+ `JAVA_TOOL_OPTIONS`: su Java, Lambda supporta questa variabile di ambiente per impostare ulteriori variabili della riga di comando in Lambda. Questa variabile di ambiente consente di specificare l'inizializzazione degli strumenti, in particolare l'avvio di agenti del linguaggio di programmazione nativo o Java utilizzando le opzioni `agentlib` o `javaagent`. Per ulteriori informazioni, consulta la sezione [Variabili di ambiente `JAVA_TOOL_OPTIONS`](https://docs.aws.amazon.com/lambda/latest/dg/java-customization.html#java-tool-options).
+ `NODE_OPTIONS`: disponibile nei [runtime di Node.js](lambda-nodejs.md).
+ `DOTNET_STARTUP_HOOKS` – Su.NET Core 3.1 e versioni successive, questa variabile di ambiente specifica un percorso ad un assembly (dll) che Lambda può utilizzare.
L'utilizzo di variabili di ambiente specifiche della lingua è il modo preferito per impostare le proprietà di avvio.
## Script wrapper
È possibile creare uno *script wrapper* per personalizzare il comportamento di avvio runtime della funzione Lambda. Uno script wrapper consente di impostare parametri di configurazione che non possono essere impostati tramite variabili di ambiente specifiche della lingua.
**Nota**
Le chiamate potrebbero non riuscire se lo script wrapper non avvia correttamente il processo di runtime.
Gli script wrapper sono supportati su tutti i [runtime Lambda nativi](lambda-runtimes.md). Gli script wrapper non sono supportati su [Runtime solo per il sistema operativo](runtimes-provided.md) (la famiglia di runtime `provided`).
Quando si utilizza uno script wrapper per la funzione, Lambda avvia il runtime utilizzando lo script. Lambda invia allo script il percorso all'interprete e tutti gli argomenti originali per l'avvio del runtime standard. Lo script può estendere o trasformare il comportamento di avvio del programma. Ad esempio, lo script può iniettare e modificare argomenti, impostare variabili di ambiente o acquisire metriche, errori e altre informazioni diagnostiche.
È possibile specificare lo script impostando il valore della variabile di ambiente `AWS_LAMBDA_EXEC_WRAPPER` come percorso del file system di un file binario o di uno script eseguibile.
### Esempio: creare e utilizzare uno script wrapper come layer Lambda
Nell'esempio seguente, si crea uno script wrapper per avviare l'interprete Python con l'opzione `-X importtime`. Quando si esegue la funzione, Lambda genera una voce di log per mostrare la durata del tempo di importazione per ogni importazione.
**Per creare e utilizzare uno script wrapper come livello**
1. Crea una directory per il livello:
```
mkdir -p python-wrapper-layer/bin
cd python-wrapper-layer/bin
```
1. Nella `bin` directory, incollate il codice seguente in un nuovo file denominato`importtime_wrapper`. Questo è lo script wrapper.
```
#!/bin/bash
# the path to the interpreter and all of the originally intended arguments
args=("$@")
# the extra options to pass to the interpreter
extra_args=("-X" "importtime")
# insert the extra options
args=("${args[@]:0:$#-1}" "${extra_args[@]}" "${args[@]: -1}")
# start the runtime with the extra options
exec "${args[@]}"
```
1. Assegnare autorizzazioni eseguibili a tutti gli script.
```
chmod +x importtime_wrapper
```
1. Crea un file .zip per il livello:
```
cd ..
zip -r ../python-wrapper-layer.zip .
```
1. Verifica che il file .zip abbia la seguente struttura di directory:
```
python-wrapper-layer.zip
└ bin
└ importtime_wrapper
```
1. [Create un livello](creating-deleting-layers.md#layers-create) utilizzando il pacchetto.zip.
1. Crea una funzione utilizzando la console Lambda.
1. Aprire la [console Lambda](https://console.aws.amazon.com/lambda).
1. Scegli **Crea funzione**.
1. Immetti un **nome per la funzione**.
1. Per **Runtime**, scegli l'**ultimo runtime supportato** di Python.
1. Scegli **Crea funzione**.
1. Aggiungi il livello alla tua funzione.
1. Scegliere la funzione, quindi scegliere **Codice** se non è già selezionato.
1. Scorri verso il basso fino alla sezione **Livelli**, quindi scegli **Aggiungi un livello**.
1. Per **Layer source**, seleziona **Livelli personalizzati**, quindi scegli il tuo livello dall'elenco a discesa **Livelli personalizzati**.
1. In **Version (Versione)**, selezionare **1**.
1. Scegli **Add** (Aggiungi).
1. Aggiungi la variabile di ambiente wrapper.
1. Scegli **Configurazione**, quindi scegli **Variabili di ambiente**.
1. In **Environment variables (Variabili di ambiente)**, scegliere **Edit (Modifica)**.
1. Scegli **Add environment variable (Aggiungi variabile d'ambiente)**.
1. In **Chiave**, inserire `AWS_LAMBDA_EXEC_WRAPPER`.
1. Per **Value**, inserisci `/opt/bin/importtime_wrapper` (`/opt/`\$1 la struttura delle cartelle del tuo livello.zip).
1. Selezionare **Salva**.
1. Provate lo script wrapper.
1. Seleziona la scheda **Test**.
1. **In **Evento di prova**, scegli Test.** Non è necessario creare un evento di test: l'evento predefinito funzionerà.
1. Scorri verso il basso fino a **Log output**. Poiché lo script wrapper ha avviato l'interprete Python con l'opzione `-X importtime`, i log mostrano il tempo richiesto per ogni importazione. Ad esempio:
```
532 | collections
import time: 63 | 63 | _functools
import time: 1053 | 3646 | functools
import time: 2163 | 7499 | enum
import time: 100 | 100 | _sre
import time: 446 | 446 | re._constants
import time: 691 | 1136 | re._parser
import time: 378 | 378 | re._casefix
import time: 670 | 2283 | re._compiler
import time: 416 | 416 | copyreg
```
# Utilizzo dell'API di runtime Lambda per runtime personalizzati
AWS Lambda [fornisce un'API HTTP per [runtime personalizzati](runtimes-custom.md) per ricevere eventi di chiamata da Lambda e inviare i dati di risposta all'interno dell'ambiente di esecuzione Lambda.](lambda-runtimes.md) In questa sezione è riportato il riferimento API per l'API di runtime Lambda.
**Le istanze gestite Lambda supportano richieste simultanee**
Le istanze gestite Lambda utilizzano la stessa API di runtime delle funzioni Lambda (predefinite). La differenza fondamentale è che le istanze gestite possono accettare `/response` richieste simultanee `/next` e fino al limite configurato. `AWS_LAMBDA_MAX_CONCURRENCY` Ciò consente l'elaborazione simultanea di più chiamate all'interno di un unico ambiente di esecuzione. Per ulteriori informazioni sulle istanze gestite, consulta. [Comprendere l'ambiente di esecuzione di Lambda Managed Instances](lambda-managed-instances-execution-environment.md)
![\[Diagramma di architettura dell'ambiente di esecuzione.\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/telemetry-api-concept-diagram.png)
La specifica OpenAPI per l'API runtime versione **2018-06-01** è disponibile qui: [runtime-api.zip](samples/runtime-api.zip)
Per creare un URL di richiesta API, i runtime ottengono l'endpoint API dalla variabile d'ambiente `AWS_LAMBDA_RUNTIME_API`, aggiungere la versione dell'API e aggiungere il percorso della risorsa desiderato.
**Example Richiesta**
```
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next"
```
**Topics**
+ [
## Chiamata successiva
](#runtimes-api-next)
+ [
## Risposta all'invocazione
](#runtimes-api-response)
+ [
## Errore di inizializzazione
](#runtimes-api-initerror)
+ [
## Errore della chiamata
](#runtimes-api-invokeerror)
## Chiamata successiva
**Percorso** – `/runtime/invocation/next`
**Metodo** – **GET**
Il runtime invia questo messaggio a Lambda per richiedere un evento di chiamata. Il corpo della risposta contiene il payload della chiamata che è un documento JSON contenente i dati dell'evento dal trigger della funzione. Le intestazioni della risposta contengono dati aggiuntivi sulla chiamata.
**Intestazioni di risposta**
+ `Lambda-Runtime-Aws-Request-Id` – L'ID della richiesta che identifica la richiesta che ha attivato la chiamata della funzione.
Ad esempio, `8476a536-e9f4-11e8-9739-2dfe598c3fcd`.
+ `Lambda-Runtime-Deadline-Ms` – La data del timeout della funzione in millisecondi Unix.
Ad esempio, `1542409706888`.
+ `Lambda-Runtime-Invoked-Function-Arn` – L'ARN della funzione Lambda, la versione o l'alias specificato nella chiamata.
Ad esempio, `arn:aws:lambda:us-east-2:123456789012:function:custom-runtime`.
+ `Lambda-Runtime-Trace-Id` – L'[intestazione di tracciamento AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html#xray-concepts-tracingheader).
Ad esempio, `Root=1-5bef4de7-ad49b0e87f6ef6c87fc2e700;Parent=9a9197af755a6419;Sampled=1`.
+ `Lambda-Runtime-Client-Context`— Per le chiamate da AWS Mobile SDK, i dati sull'applicazione client e sul dispositivo.
+ `Lambda-Runtime-Cognito-Identity`— Per le chiamate da AWS Mobile SDK, dati sul provider di identità Amazon Cognito.
Non impostare un timeout sulla richiesta `GET` in quanto la risposta potrebbe essere ritardata. Nell'intervallo di tempo che va dal bootstrap del runtime di Lambda al momento in cui il runtime dispone di un evento da restituire, il processo di runtime potrebbe rimanere bloccato per alcuni secondi.
L'ID della richiesta tiene traccia della chiamata in Lambda. Utilizzalo per specificare la chiamata quando invii la risposta.
L'intestazione di traccia contiene l'ID di traccia, l'ID dell'elemento padre e la selezione per il campionamento. Se la richiesta viene campionata, la richiesta è stata campionata da Lambda o da un servizio upstream. Il runtime deve impostare `_X_AMZN_TRACE_ID` sul valore dell'intestazione. L'X-Ray SDK lo legge per ottenere IDs e determinare se tracciare la richiesta.
## Risposta all'invocazione
**Percorso** – `/runtime/invocation/AwsRequestId/response`
**Metodo** – **POST**
Una volta che la funzione è stata eseguita fino al completamento, il runtime invia una risposta di chiamata a Lambda. Per le chiamate sincrone, Lambda invia la risposta al client.
**Example Richiesta con esito positivo**
```
REQUEST_ID=156cb537-e2d4-11e8-9b34-d36013741fb9
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "SUCCESS"
```
## Errore di inizializzazione
Se la funzione restituisce un errore o il runtime rileva un errore durante l'inizializzazione, il runtime utilizzerà questo metodo per segnalare l'errore a Lambda.
**Percorso** – `/runtime/init/error`
**Metodo** – **POST**
**Headers**
`Lambda-Runtime-Function-Error-Type` – Tipo di errore rilevato dal runtime. Campo obbligatorio: no.
L'intestazione è costituita da un valore stringa. Lambda accetta qualsiasi stringa, ma si consiglia di utilizzare il formato . Esempio:
+ Runtime. NoSuchHandler
+ Tempo di esecuzione. APIKeyNotFound
+ Tempo di esecuzione. ConfigInvalid
+ Tempo di esecuzione. UnknownReason
**Parametri corpo**
`ErrorRequest` – Informazioni sull'errore. Campo obbligatorio: no.
Questo campo è un oggetto JSON con la seguente struttura:
```
{
errorMessage: string (text description of the error),
errorType: string,
stackTrace: array of strings
}
```
NB: Lambda accetta qualsiasi valore per `errorType`.
Nell'esempio seguente viene mostrato un messaggio di errore della funzione Lambda in cui la funzione non è stata in grado di analizzare i dati evento forniti nell'invocazione.
**Example Errore di funzione**
```
{
"errorMessage" : "Error parsing event data.",
"errorType" : "InvalidEventDataException",
"stackTrace": [ ]
}
```
**Parametri del corpo della risposta**
+ `StatusResponse` – Stringa. Informazioni sullo stato, inviate con codici di risposta 202.
+ `ErrorResponse`— Informazioni aggiuntive sull'errore, inviate con i codici di risposta all'errore. ErrorResponse contiene un tipo di errore e un messaggio di errore.
**Codice di risposta**
+ 202 – Accettato
+ 403 – Non consentito
+ 500 – Errore del container. Stato non recuperabile. Il runtime dovrebbe uscire tempestivamente.
**Example Richiesta con errore di inizializzazione**
```
ERROR="{\"errorMessage\" : \"Failed to load function.\", \"errorType\" : \"InvalidFunctionException\"}"
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/init/error" -d "$ERROR" --header "Lambda-Runtime-Function-Error-Type: Unhandled"
```
## Errore della chiamata
Se la funzione restituisce un errore o il runtime rileva un errore, il runtime utilizzerà questo metodo per segnalare l'errore a Lambda.
**Percorso** – `/runtime/invocation/AwsRequestId/error`
**Metodo** – **POST**
**Headers**
`Lambda-Runtime-Function-Error-Type` – Tipo di errore rilevato dal runtime. Campo obbligatorio: no.
L'intestazione è costituita da un valore stringa. Lambda accetta qualsiasi stringa, ma si consiglia di utilizzare il formato . Esempio:
+ Runtime. NoSuchHandler
+ Tempo di esecuzione. APIKeyNotFound
+ Tempo di esecuzione. ConfigInvalid
+ Tempo di esecuzione. UnknownReason
**Parametri corpo**
`ErrorRequest` – Informazioni sull'errore. Campo obbligatorio: no.
Questo campo è un oggetto JSON con la seguente struttura:
```
{
errorMessage: string (text description of the error),
errorType: string,
stackTrace: array of strings
}
```
NB: Lambda accetta qualsiasi valore per `errorType`.
Nell'esempio seguente viene mostrato un messaggio di errore della funzione Lambda in cui la funzione non è stata in grado di analizzare i dati evento forniti nell'invocazione.
**Example Errore di funzione**
```
{
"errorMessage" : "Error parsing event data.",
"errorType" : "InvalidEventDataException",
"stackTrace": [ ]
}
```
**Parametri del corpo della risposta**
+ `StatusResponse` – Stringa. Informazioni sullo stato, inviate con codici di risposta 202.
+ `ErrorResponse`— Informazioni aggiuntive sull'errore, inviate con i codici di risposta all'errore. ErrorResponse contiene un tipo di errore e un messaggio di errore.
**Codice di risposta**
+ 202 – Accettato
+ 400 – Richiesta non valida
+ 403 – Non consentito
+ 500 – Errore del container. Stato non recuperabile. Il tempo di esecuzione dovrebbe uscire tempestivamente.
**Example Richiesta con esito errato**
```
REQUEST_ID=156cb537-e2d4-11e8-9b34-d36013741fb9
ERROR="{\"errorMessage\" : \"Error parsing event data.\", \"errorType\" : \"InvalidEventDataException\"}"
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/error" -d "$ERROR" --header "Lambda-Runtime-Function-Error-Type: Unhandled"
```
# Quando usare i runtime solo per il sistema operativo di Lambda
Lambda fornisce [runtime gestiti](lambda-runtimes.md) per Java, Python, Node.js, .NET e Ruby. Per creare funzioni Lambda in un linguaggio di programmazione non disponibile come runtime gestito, utilizza un runtime solo per il sistema operativo (la famiglia di runtime `provided`). Esistono tre casi d'uso principali per i runtime solo per il sistema operativo:
+ **Compilazione nativa ahead-of-time (AOT)**: linguaggi come Go, Rust, Swift e C\$1\$1 vengono compilati nativamente in un binario eseguibile, che non richiede un runtime linguistico dedicato. Questi linguaggi richiedono solo un ambiente di sistema operativo in cui sia possibile eseguire il file binario compilato. Puoi anche utilizzare i runtime solo per il sistema operativo Lambda per distribuire file binari compilati con.NET Native AOT e Java GraalVM Native Image.
È necessario includere un client dell'interfaccia di runtime nel file binario. Il client dell'interfaccia di runtime chiama [Utilizzo dell'API di runtime Lambda per runtime personalizzati](runtimes-api.md) per recuperare le invocazioni della funzione e quindi esegue la chiamata al gestore della funzione. Lambda fornisce client di interfaccia runtime per [Rust](lambda-rust.md), [Go](golang-package.md#golang-package-mac-linux), [.NET Native AOT](dotnet-native-aot.md), [Swift](https://github.com/awslabs/swift-aws-lambda-runtime) (sperimentale) e [C\$1\$1](https://github.com/awslabs/aws-lambda-cpp) (sperimentale).
Devi compilare il file binario per un ambiente Linux e per la stessa architettura di set di istruzioni che intendi utilizzare per la funzione (x86\$164 o arm64).
+ **Runtime di terze parti**: puoi eseguire funzioni Lambda off-the-shelf utilizzando runtime [come](https://bref.sh/docs/news/01-bref-1.0.html#amazon-linux-2) Bref per PHP.
+ **Runtime personalizzati**: puoi creare il tuo runtime personale per un linguaggio o una versione di linguaggio per cui Lambda non fornisce un runtime gestito, come Node.js 19. Per ulteriori informazioni, consulta [Creazione di un runtime personalizzato per AWS Lambda](runtimes-custom.md). Questo è il caso d'uso meno comune per i runtime solo per il sistema operativo.
Lambda supporta i seguenti runtime solo per il sistema operativo:
| Name | Identificatore | Sistema operativo | Data di ritiro | Blocco creazione funzioni | Blocco aggiornamento funzioni |
| --- | --- | --- | --- | --- | --- |
| Runtime solo per il sistema operativo | `provided.al2023` | Amazon Linux 2023 | 30 giugno 2029 | 31 luglio 2029 | 31 agosto 2029 |
| Runtime solo per il sistema operativo | `provided.al2` | Amazon Linux 2 | 31 luglio 2026 | 31 agosto 2026 | 30 settembre 2026 |
Il runtime Amazon Linux 2023 (`provided.al2023`) offre diversi vantaggi rispetto ad Amazon Linux 2, tra cui un'impronta di implementazione ridotta e versioni aggiornate di librerie come `glibc`.
Il runtime `provided.al2023` utilizza `dnf` come gestore di pacchetti invece di `yum`, che è il gestore di pacchetti predefinito in Amazon Linux 2. Per ulteriori informazioni sulle differenze tra `provided.al2023` e`provided.al2`, consulta [Introducing the Amazon Linux 2023 runtime for AWS Lambda](https://aws.amazon.com/blogs/compute/introducing-the-amazon-linux-2023-runtime-for-aws-lambda/) sul AWS Compute Blog.
# Creazione di un runtime personalizzato per AWS Lambda
È possibile implementare un AWS Lambda runtime in qualsiasi linguaggio di programmazione. Il runtime è un programma che esegue un metodo del gestore della funzione Lambda quando la funzione viene richiamata. Puoi includere il runtime nel pacchetto di implementazione della funzione o distribuirlo in un [livello](chapter-layers.md). Quando crei la funzione Lambda, [scegli un runtime solo per il sistema operativo](runtimes-provided.md) (la famiglia di runtime `provided`).
**Nota**
La creazione di un runtime personalizzato è un caso d'uso avanzato. Se stai cercando informazioni sulla compilazione in un file binario nativo o sull'utilizzo di un off-the-shelf runtime di terze parti, consulta[Quando usare i runtime solo per il sistema operativo di Lambda](runtimes-provided.md).
Per una procedura guidata sul processo di implementazione del runtime personalizzato, consulta [Tutorial: Creazione di un runtime personalizzato](runtimes-walkthrough.md).
**Topics**
+ [
## Requisiti
](#runtimes-custom-build)
+ [
## Implementazione dello streaming delle risposte in un runtime personalizzato
](#runtimes-custom-response-streaming)
+ [
## Creazione di runtime personalizzati per istanze gestite Lambda
](#runtimes-custom-managed-instances)
## Requisiti
I runtime personalizzati devono completare determinate attività di inizializzazione ed elaborazione. Il runtime è responsabile dell'esecuzione del codice di configurazione della funzione, della lettura del nome del gestore da una variabile di ambiente e della lettura degli eventi di richiamo dall'API del runtime Lambda. Il runtime passa i dati dell'evento al gestore della funzioni e invia la risposta dal gestore a Lambda.
### Attività di inizializzazione
Le attività di inizializzazione vengono eseguite una volta [per istanza della funzione](lambda-runtime-environment.md) per preparare l'ambiente a gestire le chiamate.
+ **Recupero delle impostazioni** – Leggi le variabili d'ambiente per ottenere dettagli sulla funzione e sull'ambiente.
+ `_HANDLER` – Il percorso del gestore della configurazione della funzione. Il formato standard è `file.method`, dove `file` è il nome del file senza estensione e `method` è il nome di un metodo o una funzione definita nel file.
+ `LAMBDA_TASK_ROOT` – La directory che contiene il codice della funzione.
+ `AWS_LAMBDA_RUNTIME_API` – L'host e la porta dell'API di runtime.
Per l'elenco completo delle variabili disponibili, consulta la pagina [Variabili di ambiente di runtime definite](configuration-envvars.md#configuration-envvars-runtime).
+ **Inizializzazione della funzione** – Carica il file del gestore ed esegui il codice globale o statico che contiene. Le funzioni devono creare le risorse statiche come i client SDK e le connessioni al database e quindi riutilizzarle per più chiamate.
+ **Gestione degli errori** – Se si verifica un errore, viene chiamata l'API [errore di inizializzazione](runtimes-api.md#runtimes-api-initerror) e viene chiusa la funzione.
L'inizializzazione viene calcolata nella fatturazione del runtime e del timeout. Quando un'esecuzione attiva l'inizializzazione di una nuova istanza della funzione, puoi visualizzare il tempo di inizializzazione nei log e nella [traccia AWS X-Ray](services-xray.md).
**Example log**
```
REPORT RequestId: f8ac1208... Init Duration: 48.26 ms Duration: 237.17 ms Billed Duration: 300 ms Memory Size: 128 MB Max Memory Used: 26 MB
```
### Attività di elaborazione
Durante l'esecuzione, un runtime usa l'[interfaccia del runtime Lambda](runtimes-api.md) per gestire gli eventi in entrata e segnalare gli errori. Dopo aver completato le attività di inizializzazione, il runtime elabora gli eventi in entrata in un ciclo. Nel codice di runtime, eseguire le seguenti fasi in ordine.
+ **Recupero di un evento** – Viene invocata l'API [chiamata successiva](runtimes-api.md#runtimes-api-next) per ottenere l'evento seguente. Il corpo della risposta contiene i dati dell'evento. Le intestazioni di risposta contengono l'ID della richiesta e altre informazioni.
+ **Propagazione dell'intestazione di traccia** – Recupera l'intestazione di traccia X-Ray dall'intestazione `Lambda-Runtime-Trace-Id` nella risposta dell'API. Imposta la variabile di ambiente `_X_AMZN_TRACE_ID` locale allo stesso valore. L'SDK X-Ray utilizza questo valore per associare i dati di tracciamento tra i servizi.
+ **Creazione di un oggetto contesto** – Crea un oggetto con informazioni di contesto dalle variabili di ambiente e dalle intestazioni nella risposta dell'API.
+ **Richiamo del gestore della funzione** – Passa l'evento e l'oggetto contesto al gestore.
+ **Gestione della risposta** – Viene [invocata l'API risposta](runtimes-api.md#runtimes-api-response) della chiamata per pubblicare la risposta del gestore.
+ **Gestione degli errori** – Se si verifica un errore, viene chiamata l'API [errore di chiamata](runtimes-api.md#runtimes-api-invokeerror).
+ **Pulizia** – Rilascia le risorse inutilizzate, invia i dati ad altri servizi o esegui attività aggiuntive prima di ottenere il prossimo evento.
### Entrypoint
Il punto di ingresso di un runtime personalizzato è un file eseguibile denominato `bootstrap`. Il file di bootstrap può essere il runtime oppure può richiamare un altro file che crea il runtime. Se la root del pacchetto di implementazione non contiene un file denominato `bootstrap`, Lambda cerca il file nei livelli della funzione. Se il file `bootstrap` non esiste o non è eseguibile, la funzione restituisce un errore `Runtime.InvalidEntrypoint` in caso di invocazione.
Ecco un `bootstrap` file di esempio che utilizza una versione in bundle di Node.js per eseguire un JavaScript runtime in un file separato denominato. `runtime.js`
**Example bootstrap**
```
#!/bin/sh
cd $LAMBDA_TASK_ROOT
./node-v11.1.0-linux-x64/bin/node runtime.js
```
## Implementazione dello streaming delle risposte in un runtime personalizzato
Per le [funzioni di streaming delle risposte](configuration-response-streaming.md), gli endpoint `response` ed `error` manifestano un comportamento leggermente diverso che consente al runtime di trasmettere risposte parziali al client e restituire i payload in blocchi. Per ulteriori informazioni sul comportamento specifico, consulta le seguenti risorse:
+ `/runtime/invocation/AwsRequestId/response`: propaga l'intestazione `Content-Type` dal runtime per inviarla al client. Lambda restituisce il payload di risposta in blocchi tramite codifica di trasferimento in blocchi HTTP/1.1. Per trasmettere la risposta in streaming a Lambda, il runtime deve:
+ Impostare l'intestazione HTTP `Lambda-Runtime-Function-Response-Mode` su `streaming`.
+ Imposta l'intestazione `Transfer-Encoding` su `chunked`.
+ Scrivere la risposta in conformità alla specifica di codifica del trasferimento in blocchi HTTP/1.1.
+ Chiudere la connessione sottostante dopo la corretta scrittura della risposta.
+ `/runtime/invocation/AwsRequestId/error`: il runtime può utilizzare questo endpoint per segnalare errori di funzione o di runtime a Lambda, che accetta anche l'intestazione `Transfer-Encoding`. Questo endpoint può essere chiamato solo prima che il runtime inizi a inviare una risposta alla chiamata.
+ Segnala gli errori intermedi utilizzando i trailer degli errori in `/runtime/invocation/AwsRequestId/response`: per segnalare gli errori che si verificano dopo aver iniziato a scrivere la risposta alla chiamata, il runtime può facoltativamente collegare intestazioni HTTP finali denominate `Lambda-Runtime-Function-Error-Type` e `Lambda-Runtime-Function-Error-Body`. Lambda considera questa come una risposta riuscita e inoltra i metadati degli errori che il runtime fornisce al client.
**Nota**
Per allegare le intestazioni finali, il runtime deve impostare il valore dell'intestazione `Trailer` all'inizio della richiesta HTTP. Si tratta di un requisito della specifica di codifica di trasferimento in blocchi HTTP/1.1.
+ `Lambda-Runtime-Function-Error-Type`: il tipo di errore rilevato dal runtime. L'intestazione è costituita da un valore stringa. Lambda accetta qualsiasi stringa, ma consigliamo un formato di. ** Ad esempio, `Runtime.APIKeyNotFound`.
+ `Lambda-Runtime-Function-Error-Body`: informazioni sull'errore nella codifica base64.
## Creazione di runtime personalizzati per istanze gestite Lambda
Le istanze gestite Lambda utilizzano la stessa API di runtime delle funzioni Lambda (predefinite). Tuttavia, esistono differenze fondamentali nel modo in cui devono essere implementati i runtime personalizzati per supportare il modello di esecuzione simultanea delle istanze gestite.
### Gestione simultanea delle richieste
La differenza principale nella creazione di runtime personalizzati per le istanze gestite è il supporto per le chiamate simultanee. A differenza delle funzioni Lambda (predefinite) in cui il runtime elabora una chiamata alla volta, le istanze gestite possono elaborare più chiamate contemporaneamente all'interno di un unico ambiente di esecuzione.
Il runtime personalizzato deve:
+ **Supporta `/next` richieste simultanee**: il runtime può effettuare più chiamate simultanee all'API di [chiamata successiva](runtimes-api.md#runtimes-api-next), fino al limite specificato dalla variabile di ambiente. `AWS_LAMBDA_MAX_CONCURRENCY`
+ **Gestisci `/response` le richieste simultanee**[: più chiamate possono chiamare contemporaneamente l'API di risposta alle chiamate.](runtimes-api.md#runtimes-api-response)
+ **Implementa la gestione delle richieste thread-safe**: assicurati che le chiamate simultanee non interferiscano tra loro gestendo correttamente le risorse e lo stato condivisi.
+ **Usa una richiesta univoca IDs**: traccia ogni chiamata separatamente utilizzando l'`Lambda-Runtime-Aws-Request-Id`intestazione per abbinare le risposte alle richieste corrispondenti.
### Modello di implementazione
Un tipico modello di implementazione per i runtime delle istanze gestite prevede la creazione di thread o processi di lavoro per gestire le chiamate simultanee:
1. **Leggi il limite di concorrenza**: al momento dell'inizializzazione, leggi la variabile di `AWS_LAMBDA_MAX_CONCURRENCY` ambiente per determinare quante chiamate simultanee supportare.
1. **Crea un pool di lavoratori**: inizializza un pool di lavoratori (thread, processi o attività asincrone) pari al limite di concorrenza.
1. **Ciclo di elaborazione dei lavoratori**: ogni lavoratore in modo indipendente:
+ Chiamate `/runtime/invocation/next` per ottenere un evento di invocazione
+ Richiama il gestore della funzione con i dati dell'evento
+ Invia la risposta a `/runtime/invocation/AwsRequestId/response`
+ Ripete il ciclo
### Ulteriori considerazioni
+ **Formato di registrazione**: le istanze gestite supportano solo il formato di registro JSON. Assicurati che il runtime rispetti la variabile di `AWS_LAMBDA_LOG_FORMAT` ambiente e utilizzi solo il formato JSON. Per ulteriori informazioni, consulta [Configurazione dei formati di log JSON e testo normale](monitoring-cloudwatchlogs-logformat.md).
+ **Risorse condivise**: fai attenzione quando utilizzi risorse condivise come la `/tmp` directory con chiamate simultanee. Implementa meccanismi di blocco adeguati per prevenire condizioni di gara.
Per ulteriori informazioni sugli ambienti di esecuzione di Lambda Managed Instances, vedere. [Comprendere l'ambiente di esecuzione di Lambda Managed Instances](lambda-managed-instances-execution-environment.md)
# Tutorial: Creazione di un runtime personalizzato
In questo tutorial crei una funzione Lambda con un runtime personalizzato. Si inizia includendo il runtime nel pacchetto di distribuzione della funzione. Quindi lo trasferisci in un livello che gestisci in modo indipendente dalla funzione. Infine, condividi il livello del runtime con tutti aggiornando la policy delle autorizzazioni basate sulle risorse.
## Prerequisiti
Questo tutorial presuppone una certa conoscenza delle operazioni di base di Lambda e della console relativa. Se non lo si è già fatto, seguire le istruzioni riportate in [Creare una funzione Lambda con la console](getting-started.md#getting-started-create-function) per creare la prima funzione Lambda.
Per completare i passaggi seguenti, è necessaria la [AWS CLI versione 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). I comandi e l'output previsto sono elencati in blocchi separati:
```
aws --version
```
Verrà visualizzato l'output seguente:
```
aws-cli/2.13.27 Python/3.11.6 Linux/4.14.328-248.540.amzn2.x86_64 exe/x86_64.amzn.2
```
Per i comandi lunghi viene utilizzato un carattere di escape (`\`) per dividere un comando su più righe.
In Linux e macOS utilizzare la propria shell e il proprio programma di gestione dei pacchetti preferiti.
**Nota**
Su Windows, alcuni comandi della CLI Bash utilizzati comunemente con Lambda (ad esempio, `zip`) non sono supportati dai terminali integrati del sistema operativo. Per ottenere una versione integrata su Windows di Ubuntu e Bash, [installa il sottosistema Windows per Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10). I comandi della CLI di esempio in questa guida utilizzano la formattazione Linux. Se si utilizza la CLI di Windows, i comandi che includono documenti JSON in linea dovranno essere riformattati.
È necessario un ruolo IAM per creare una funzione Lambda. Il ruolo richiede l'autorizzazione per inviare i log a CloudWatch Logs e accedere ai Servizi AWS utilizzati dalla tua funzione. Se non hai un ruolo per lo sviluppo di funzioni, creane uno ora.
**Per creare un ruolo di esecuzione**
1. Apri la pagina [Ruoli](https://console.aws.amazon.com/iam/home#/roles) nella console IAM.
1. Scegliere **Crea ruolo**.
1. Creare un ruolo con le seguenti proprietà.
+ **Trusted entity (Entità attendibile** – **Lambda**
+ **Permissions (Autorizzazioni)** – ** AWSLambdaBasicExecutionRole**.
+ **Role name (Nome ruolo** – **lambda-role**.
La policy **AWSLambdaBasicExecutionRole** dispone delle autorizzazioni delle quali la funzione necessita per scrivere i log in CloudWatch Logs.
## Creazione di una funzione
Crea una funzione Lambda con un runtime personalizzato. Questo esempio include due file: un file `bootstrap` del runtime e un gestore della funzione. Entrambi sono implementati in Bash.
1. Crea una directory per il progetto, quindi passa a quella directory.
```
mkdir runtime-tutorial
cd runtime-tutorial
```
1. Crea un nuovo file denominato `bootstrap`. Questo è il runtime personalizzato.
**Example bootstrap**
```
#!/bin/sh
set -euo pipefail
# Initialization - load function handler
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
# Processing
while true
do
HEADERS="$(mktemp)"
# Get an event. The HTTP request will block until one is received
EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
# Extract request ID by scraping response headers received above
REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
# Run the handler function from the script
RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
# Send the response
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE"
done
```
Il runtime carica uno script di funzione dal pacchetto di distribuzione. Utilizza due variabili per individuare lo script. `LAMBDA_TASK_ROOT` indica il percorso da cui il pacchetto è stato estratto e `_HANDLER` include il nome dello script.
Dopo che il runtime carica lo script della funzione, utilizza l'API del runtime per recuperare un evento di chiamata da Lambda, passa l'evento al gestore e trasmette la risposta a Lambda. Per ottenere l'ID della richiesta, il runtime salva le intestazioni dalla risposta dell'API in un file temporaneo e legge l'intestazione `Lambda-Runtime-Aws-Request-Id` dal file.
**Nota**
I runtime hanno responsabilità aggiuntive inclusa la gestione degli errori e forniscono al gestore le informazioni sul contesto. Per informazioni dettagliate, vedi [Requisiti](runtimes-custom.md#runtimes-custom-build).
1. Crea uno script per la funzione. Lo script di esempio seguente definisce una funzione del gestore che richiede i dati dell'evento, li registra in `stderr` e li restituisce.
**Example function.sh**
```
function handler () {
EVENT_DATA=$1
echo "$EVENT_DATA" 1>&2;
RESPONSE="Echoing request: '$EVENT_DATA'"
echo $RESPONSE
}
```
L'aspetto della directory `runtime-tutorial` dovrebbe essere simile al seguente:
```
runtime-tutorial
├ bootstrap
└ function.sh
```
1. Rendere i file eseguibili e aggiungerli ad un archive ZIP. Questo è il pacchetto di implementazione.
```
chmod 755 function.sh bootstrap
zip function.zip function.sh bootstrap
```
1. Crea una funzione denominata `bash-runtime`. Per `--role`, inserisci l'ARN del tuo [ruolo di esecuzione](lambda-intro-execution-role.md) Lambda.
```
aws lambda create-function --function-name bash-runtime \
--zip-file fileb://function.zip --handler function.handler --runtime provided.al2023 \
--role arn:aws:iam::123456789012:role/lambda-role
```
1. Richiama la funzione.
```
aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
```
L'opzione **cli-binary-format** è necessaria se si utilizza la versione 2 della AWS CLI. Per rendere questa impostazione come predefinita, esegui `aws configure set cli-binary-format raw-in-base64-out`. Per ulteriori informazioni, consulta la pagina [AWS CLI supported global command line options](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) nella *Guida per l'utente di AWS Command Line Interface versione 2*.
Dovresti ottenere una risposta simile a questa:
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
```
1. Verifica la risposta.
```
cat response.txt
```
Dovresti ottenere una risposta simile a questa:
```
Echoing request: '{"text":"Hello"}'
```
## Crea un livello
Per separare il codice del runtime dal codice della funzione, crea un livello che contenga solo il runtime. I livelli consentono di sviluppare le dipendenze della funzione in modo indipendente e possono ridurre l'utilizzo dello storage quando usi lo stesso livello con più funzioni. Per ulteriori informazioni, consulta [Gestione delle dipendenze Lambda con i livelli](chapter-layers.md).
1. Crea un file .zip contenente il file `bootstrap`.
```
zip runtime.zip bootstrap
```
1. Crea un livello con il comando [publish-layer-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-layer-version.html?highlight=nodejs16%20x).
```
aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip
```
In tal modo viene creata la prima versione del livello.
## Aggiorna la funzione
Per utilizzare il livello del runtime nella funzione, configura la funzione affinché utilizzi il livello e rimuovi il codice del runtime dalla funzione.
1. Aggiorna la configurazione della funzione da inserire nel livello.
```
aws lambda update-function-configuration --function-name bash-runtime \
--layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:1
```
Questo aggiunge il runtime alla funzione nella directory `/opt`. Per garantire che Lambda utilizzi il runtime nel livello, è necessario rimuovere il `boostrap` dal pacchetto di implementazione della funzione, come illustrato nei due passaggi successivi.
1. Crea un file .zip contenente il codice della funzione.
```
zip function-only.zip function.sh
```
1. Aggiorna il codice della funzione in modo da includere soltanto lo script del gestore.
```
aws lambda update-function-code --function-name bash-runtime --zip-file fileb://function-only.zip
```
1. Chiama la funzione per verificare che funzioni con il livello del runtime.
```
aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
```
L'opzione **cli-binary-format** è necessaria se si utilizza la versione 2 della AWS CLI. Per rendere questa impostazione come predefinita, esegui `aws configure set cli-binary-format raw-in-base64-out`. Per ulteriori informazioni, consulta la pagina [AWS CLI supported global command line options](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) nella *Guida per l'utente di AWS Command Line Interface versione 2*.
Dovresti ottenere una risposta simile a questa:
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
```
1. Verifica la risposta.
```
cat response.txt
```
Dovresti ottenere una risposta simile a questa:
```
Echoing request: '{"text":"Hello"}'
```
## Aggiorna il runtime
1. Per registrare le informazioni sull'ambiente di esecuzione, aggiorna lo script del runtime sulle variabili di ambiente di output.
**Example bootstrap**
```
#!/bin/sh
set -euo pipefail
# Configure runtime to output environment variables
echo "## Environment variables:"
env
# Load function handler
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
# Processing
while true
do
HEADERS="$(mktemp)"
# Get an event. The HTTP request will block until one is received
EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
# Extract request ID by scraping response headers received above
REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
# Run the handler function from the script
RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
# Send the response
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE"
done
```
1. Crea un file .zip contenente la nuova versione del file `bootstrap`.
```
zip runtime.zip bootstrap
```
1. Crea una nuova versione del livello `bash-runtime`.
```
aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip
```
1. Configura la funzione per utilizzare la nuova versione del livello.
```
aws lambda update-function-configuration --function-name bash-runtime \
--layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2
```
## Condividi il livello
Per condividere un livello con un altro Account AWS, aggiungi una istruzione di autorizzazione multi-account alla [policy basata sulle risorse](access-control-resource-based.md) del livello. Esegui il comando [add-layer-version-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-layer-version-permission.html) e specifica l'ID dell'account come `principal`. In ogni istruzione, puoi concedere l'autorizzazione a un singolo account, a tutti gli account o a un'organizzazione in [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html).
L'esempio seguente concede all'account 111122223333 l'accesso alla versione 2 del livello `bash-runtime`.
```
aws lambda add-layer-version-permission \
--layer-name bash-runtime \
--version-number 2 \
--statement-id xaccount \
--action lambda:GetLayerVersion \
--principal 111122223333 \
--output text
```
Verrà visualizzato un output simile al seguente:
```
{"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2"}
```
Le autorizzazioni si applicano solo a un'unica versione di un livello. Ripeti la procedura ogni volta che crei la nuova versione di un livello.
## Eliminazione
Eliminare ciascuna versione del livello.
```
aws lambda delete-layer-version --layer-name bash-runtime --version-number 1
aws lambda delete-layer-version --layer-name bash-runtime --version-number 2
```
Poiché contiene un riferimento alla versione 2 del livello, la funzione è ancora presente in Lambda. Continua a operare, ma le funzioni non possono più essere configurate per utilizzare la versione eliminata. Se modifichi l'elenco dei livelli sulla funzione, devi specificare una nuova versione oppure omettere il livello eliminato.
Elimina la funzione con il comando [delete-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/delete-function.html).
```
aws lambda delete-function --function-name bash-runtime
```
# Archivi open source
AWS Lambda offre una varietà di strumenti, librerie e componenti open source per aiutarti a creare, personalizzare e ottimizzare le tue applicazioni serverless. Queste risorse includono client di interfaccia di runtime, librerie di eventi, immagini di base di container, strumenti di sviluppo e progetti di esempio gestiti AWS e disponibili su GitHub. Sfruttando questi repository open source, puoi estendere le funzionalità di Lambda, creare runtime personalizzati, elaborare eventi da vari AWS servizi e ottenere informazioni più approfondite sulle prestazioni della tua funzione. Questa pagina fornisce una panoramica dei principali progetti open source che supportano lo sviluppo di Lambda.
## Client di interfaccia Runtime
I Lambda Runtime Interface Client (RICs) sono librerie open source che implementano l'[API Runtime](runtimes-api.md) e gestiscono l'interazione tra il codice della funzione e il servizio Lambda. Questi client gestiscono la ricezione di eventi di chiamata, il passaggio di informazioni di contesto e la segnalazione degli errori.
I client dell'interfaccia di runtime utilizzati dai runtime gestiti e dalle immagini di base dei container di Lambda sono pubblicati come open source. Quando crei runtime personalizzati o estendi quelli esistenti, puoi utilizzare queste librerie open source per semplificare l'implementazione. I seguenti GitHub repository open source contengono il codice sorgente di Lambda: RICs
+ [Client di interfaccia Node.js Runtime](https://github.com/aws/aws-lambda-nodejs-runtime-interface-client)
+ [Client di interfaccia Python Runtime](https://github.com/aws/aws-lambda-python-runtime-interface-client)
+ [Client di interfaccia Java Runtime](https://github.com/aws/aws-lambda-java-libs/tree/main/aws-lambda-java-runtime-interface-client)
+ [Client di interfaccia Ruby Runtime](https://github.com/aws/aws-lambda-ruby-runtime-interface-client)
+ [Client di interfaccia di runtime .NET](https://github.com/aws/aws-lambda-dotnet)
+ [Client di interfaccia Rust Runtime](https://github.com/aws/aws-lambda-rust-runtime)
+ [Client di interfaccia Go Runtime](https://github.com/aws/aws-lambda-go)
+ [Client di interfaccia Swift Runtime](https://github.com/awslabs/swift-aws-lambda-runtime) (sperimentale)
+ [Client di interfaccia Runtime C\$1\$1 (sperimentale](https://github.com/awslabs/aws-lambda-cpp))
+ [Immagini Lambda Base](https://github.com/aws/aws-lambda-base-images)
Per ulteriori informazioni sull'utilizzo di questi client per creare runtime personalizzati, consulta. [Creazione di un runtime personalizzato per AWS Lambda](runtimes-custom.md)
## Librerie di eventi
Le librerie di eventi Lambda forniscono definizioni dei tipi e utilità di supporto per l'elaborazione di eventi da vari servizi. AWS Queste librerie consentono di analizzare e gestire i dati degli eventi in modo sicuro dai tipi, semplificando l'utilizzo di eventi provenienti da servizi come Amazon S3, Amazon DynamoDB e Amazon API Gateway.
Per i linguaggi compilati, AWS fornisce le seguenti librerie di eventi:
+ [Libreria di eventi Java](https://github.com/aws/aws-lambda-java-libs/tree/main/aws-lambda-java-events)
+ [Librerie di eventi.NET](https://github.com/aws/aws-lambda-dotnet/tree/master/Libraries/src)
+ [Libreria eventi Go](https://github.com/aws/aws-lambda-go/tree/main/events)
+ [Libreria di eventi Rust](https://github.com/awslabs/aws-lambda-rust-runtime)
Per linguaggi interpretati come Node.js, Python e Ruby, gli eventi possono essere analizzati direttamente come oggetti JSON senza richiedere una libreria separata. Tuttavia, gli sviluppatori che utilizzano Node.js e Python possono sfruttare powertools for AWS Lambda, che fornisce schemi integrati per AWS eventi che offrono suggerimenti sui tipi, convalida dei dati e funzionalità simili a quelle fornite dalle librerie di linguaggi compilati.
+ [Powertools per TypeScript](https://docs.powertools.aws.dev/lambda/typescript/latest/features/parser/#built-in-schemas)
+ [Powertools per Python](https://docs.powertools.aws.dev/lambda/python/latest/utilities/parser/#built-in-models)
## Immagini di base del contenitore
AWS fornisce immagini di base di container open source che puoi usare come punto di partenza per creare immagini di container per le tue funzioni Lambda. Queste immagini di base includono il client dell'interfaccia di runtime e altri componenti necessari per eseguire le funzioni nell'ambiente di esecuzione Lambda.
Per ulteriori informazioni sulle immagini di base disponibili e su come utilizzarle, consulta l'archivio delle [immagini di base AWS Lambda](https://github.com/aws/aws-lambda-base-images) e. [Creare una funzione Lambda utilizzando un'immagine di container](images-create.md)
## Strumenti di sviluppo
AWS fornisce strumenti di sviluppo open source aggiuntivi per aiutarti a creare e ottimizzare le tue funzioni Lambda:
### Powertools per AWS Lambda
Powertools for AWS Lambda semplifica lo sviluppo senza server con utilità essenziali per prevenire l'elaborazione duplicata e l'elaborazione in batch per la gestione di più record e la libreria di consumo Kafka. Queste funzionalità consentono di ridurre al minimo la complessità del codice e il sovraccarico operativo.
Puoi anche sfruttare la convalida dello schema degli eventi, la registrazione e il tracciamento strutturati e l'integrazione dell'archivio di parametri, progettati per accelerare la creazione di funzioni Lambda pronte per la produzione seguendo al contempo best practice ben architettate. AWS
GitHub archivi:
+ [Python](https://github.com/aws-powertools/powertools-lambda-python)
+ [TypeScript](https://github.com/aws-powertools/powertools-lambda-typescript)
+ [Java](https://github.com/aws-powertools/powertools-lambda-java)
+ [.NET](https://github.com/aws-powertools/powertools-lambda-dotnet)
### strumenti di sviluppo Java
+ [Java Profiler (sperimentale)](https://github.com/aws/aws-lambda-java-libs/tree/main/experimental/aws-lambda-java-profiler): uno strumento per la profilazione delle funzioni Java Lambda.
+ [Librerie Java](https://github.com/aws/aws-lambda-java-libs): un repository che contiene una raccolta completa di librerie e strumenti Java per lo sviluppo di Lambda, inclusi progetti chiave JUnit come utilità di test e strumenti di profilazione.
+ [Serverless Java Container](https://github.com/aws/serverless-java-container): una libreria che consente di eseguire applicazioni Java esistenti su Lambda con modifiche minime.
### Strumenti di sviluppo.NET
L'archivio [AWS Lambda .NET](https://github.com/aws/aws-lambda-dotnet) fornisce librerie.NET e strumenti per lo sviluppo Lambda, inclusi progetti chiave come gli strumenti AWS Lambda per l'interfaccia della riga di comando DI.NET e il server .NET Core per l'hosting di applicazioni.NET Core.
## Progetti di esempio
Esplora una raccolta completa di esempi di progetti e applicazioni Lambda nei repository [Serverless](https://serverlessland.com/repos) Land. Questi esempi illustrano vari casi d'uso, modelli di integrazione e best practice di Lambda per aiutarti a iniziare a utilizzare le tue applicazioni serverless.