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à. # Migliorare le prestazioni di avvio con Lambda SnapStart Lambda SnapStart può fornire prestazioni di avvio anche inferiori al secondo, in genere senza modifiche al codice della funzione. SnapStart semplifica la creazione di applicazioni altamente reattive e scalabili senza fornire risorse o implementare complesse ottimizzazioni delle prestazioni. Il fattore che contribuisce maggiormente alla latenza di avvio (spesso definita tempo di avvio a freddo) è il tempo impiegato da Lambda per inizializzare la funzione, che include il caricamento del codice della funzione, l'avvio del runtime e l'inizializzazione del codice della funzione. Con SnapStart, Lambda inizializza la funzione quando si pubblica una versione della funzione. Lambda utilizza lo snapshot di una [microVM Firecracker](https://aws.amazon.com/blogs/opensource/firecracker-open-source-secure-fast-microvm-serverless/) della memoria e dello stato del disco dell'[ambiente di esecuzione](lambda-runtime-environment.md) inizializzato, crittografa lo snapshot e lo memorizza nella cache in maniera intelligente per ottimizzare la latenza del recupero. Per garantire la resilienza, Lambda conserva diverse copie di ogni snapshot. Lambda aggiorna automaticamente gli snapshot e le relative copie con gli aggiornamenti di runtime e sicurezza più recenti. Quando richiami la versione della funzione per la prima volta e man mano che le chiamate aumentano, Lambda riprende i nuovi ambienti di esecuzione dallo snapshot memorizzato nella cache invece di inizializzarli da zero, migliorando così la latenza di avvio. **Importante** Se le applicazioni dipendono dall'univocità dello stato, è necessario valutare il codice della funzione e verificare che sia resiliente alle operazioni di snapshot. Per ulteriori informazioni, consulta [Gestire l'unicità con Lambda SnapStart](snapstart-uniqueness.md). **Topics** + [ ## Quando usare SnapStart ](#snapstart-use-cases) + [ ## Funzionalità e limitazioni supportate ](#snapstart-runtimes) + [ ## Regioni supportate ](#snapstart-supported-regions) + [ ## Considerazioni sulla compatibilità ](#snapstart-compatibility) + [ ## SnapStart prezzi ](#snapstart-pricing) + [ # Attivazione e gestione di Lambda SnapStart ](snapstart-activate.md) + [ # Gestire l'unicità con Lambda SnapStart ](snapstart-uniqueness.md) + [ # Implementare il codice prima o dopo gli snapshot della funzione Lambda ](snapstart-runtime-hooks.md) + [ # Monitoraggio per Lambda SnapStart ](snapstart-monitoring.md) + [ # Modello di sicurezza per Lambda SnapStart ](snapstart-security.md) + [ # Massimizza le prestazioni Lambda SnapStart ](snapstart-best-practices.md) + [ # Risoluzione degli SnapStart errori per le funzioni Lambda ](snapstart-troubleshooting.md) ## Quando usare SnapStart Lambda SnapStart è progettato per affrontare la variabilità della latenza introdotta dal codice di inizializzazione monouso, come il caricamento di dipendenze o framework dei moduli. Il completamento di queste operazioni a volte può richiedere diversi secondi durante l'invocazione iniziale. Utilizzala SnapStart per ridurre questa latenza da alcuni secondi a meno di un secondo, in scenari ottimali. SnapStart funziona meglio se utilizzato con invocazioni di funzioni su larga scala. Le funzioni richiamate di rado potrebbero non presentare gli stessi miglioramenti delle prestazioni. SnapStart è particolarmente utile per due tipi principali di applicazioni: + **Flussi sensibili alla latenza APIs e agli utenti:** le funzioni che fanno parte degli endpoint API critici o dei flussi rivolti agli utenti possono trarre vantaggio dalla latenza ridotta e dai tempi SnapStart di risposta migliorati. + **Flussi di lavoro di elaborazione dati sensibili alla latenza:** i flussi di lavoro di elaborazione dati con vincoli temporali che utilizzano le funzioni Lambda possono ottenere un throughput migliore riducendo la latenza di inizializzazione delle funzioni anomale. La [simultaneità fornita](provisioned-concurrency.md) mantiene le funzioni inizializzate e pronte a rispondere entro i 100 millisecondi. Utilizza la concorrenza fornita se la tua applicazione ha requisiti di latenza rigorosi per l'avvio a freddo che non possono essere soddisfatti in modo adeguato da. SnapStart ## Funzionalità e limitazioni supportate SnapStart è disponibile per i seguenti runtime [gestiti da Lambda](lambda-runtimes.md): + Java 11 e versioni successive + Python 3.12 e versioni successive + .NET 8 e versioni successive. Se utilizzi il [framework Lambda Annotations per.NET, esegui l'upgrade alla versione [Amazon.Lambda.Annotations](https://www.nuget.org/packages/Amazon.Lambda.Annotations) 1.6.0 o successiva per](csharp-handler.md#csharp-handler-annotations) garantire la compatibilità con. SnapStart Altri runtime gestiti (come `nodejs24.x` e `ruby3.4`), [Runtime solo per il sistema operativo](runtimes-provided.md) e le [immagini di container](images-create.md) non sono supportati. SnapStart non supporta la [concorrenza fornita,](provisioned-concurrency.md) [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/accessing-fs.html) o lo storage temporaneo superiore a 512 MB. **Nota** È possibile utilizzare SnapStart solo versioni di [funzioni pubblicate e [alias](configuration-aliases.md) che rimandano a versioni](configuration-versions.md#configuration-versions-config). Non è possibile utilizzare SnapStart sulla versione non pubblicata di una funzione (\$1LATEST). ## Regioni supportate Lambda SnapStart è disponibile in tutte le [regioni commerciali](https://docs.aws.amazon.com/general/latest/gr/glos-chap.html#region) ad eccezione di Asia Pacifico (Nuova Zelanda) e Asia Pacifico (Taipei). ## Considerazioni sulla compatibilità Con SnapStart, Lambda utilizza una singola istantanea come stato iniziale per più ambienti di esecuzione. Se la funzione utilizza uno dei seguenti elementi durante la [fase di inizializzazione](lambda-runtime-environment.md#runtimes-lifecycle-ib), potrebbe essere necessario apportare alcune modifiche prima di utilizzarla: SnapStart **Unicità** Se il codice di inizializzazione genera contenuti unici inclusi nello snapshot, il contenuto potrebbe non essere più unico quando viene riutilizzato in più ambienti di esecuzione. Per mantenere l'unicità durante l'utilizzo SnapStart, è necessario generare contenuti unici dopo l'inizializzazione. Ciò include segreti unici IDs e unici e l'entropia utilizzata per generare pseudocasualità. Per informazioni su come ripristinare l'unicità, consulta [Gestire l'unicità con Lambda SnapStart](snapstart-uniqueness.md). **Connessioni di rete** Lo stato delle connessioni che la funzione stabilisce durante la fase di inizializzazione non è garantito quando Lambda riprende la funzione da uno snapshot. Convalida lo stato delle connessioni di rete e ristabiliscile se necessario. Nella maggior parte dei casi, le connessioni di rete stabilite da un SDK riprendono automaticamente. AWS Per altre connessioni, consulta le [best practice](snapstart-best-practices.md). **Dati temporanei** Durante la fase di inizializzazione, alcune funzioni scaricano o inizializzano dati effimeri, come credenziali temporanee o timestamp memorizzati nella cache. Aggiorna i dati temporanei nel gestore delle funzioni prima di utilizzarli, anche quando non li usi. SnapStart ## SnapStart prezzi **Nota** Per i runtime gestiti da Java, non sono previsti costi aggiuntivi per SnapStart. L'addebito viene effettuato in base al numero di richieste per le funzioni, al tempo impiegato dal codice per l'esecuzione e alla memoria configurata per la funzione. Il costo di utilizzo SnapStart include quanto segue: + **Memorizzazione nella cache:** per ogni versione della funzione pubblicata con SnapStart abilitata, si pagano i costi della memorizzazione nella cache e della manutenzione dell'istantanea. Il prezzo dipende dalla quantità di [memoria](configuration-memory.md) allocata alla funzione. L'addebito sarà per un minimo di 3 ore. [L'addebito continuerà a essere effettuato finché la funzione rimarrà attiva.](snapstart-activate.md#snapstart-active) Utilizza l'azione [ListVersionsByFunction](https://docs.aws.amazon.com/lambda/latest/api/API_ListVersionsByFunction.html)API per identificare le versioni delle funzioni, quindi utilizza [DeleteFunction](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html)per eliminare le versioni non utilizzate. Per eliminare automaticamente le versioni delle funzioni non utilizzate, consulta il modello [Pulizia della versione Lambda](https://serverlessland.com/workflows/step-functions-lambda-version-cleanup) su Serverless Land. + **Ripristino:** ogni volta che un'istanza di funzione viene ripristinata da uno snapshot, si paga una tariffa di ripristino. Il prezzo dipende dalla quantità di memoria allocata alla funzione. Come per tutte le funzioni Lambda, i costi di durata si applicano al codice eseguito nell'handler delle funzioni. [Per quanto riguarda SnapStart le funzioni, i costi di durata si applicano anche al codice di inizializzazione dichiarato all'esterno del gestore, al tempo impiegato per il caricamento del runtime e a qualsiasi codice eseguito in un hook di runtime.](snapstart-runtime-hooks.md) La durata viene calcolata dal momento in cui il codice inizia a funzionare fino a quando ritorna o termina in altro modo, arrotondato al valore di 1 ms più vicino. Lambda conserva copie memorizzate nella cache dello snapshot per garantire la resilienza e applica automaticamente gli aggiornamenti software, come gli upgrade di runtime e le patch di sicurezza. Gli addebiti si applicano ogni volta che Lambda esegue nuovamente il codice di inizializzazione per applicare gli aggiornamenti software. [Per ulteriori informazioni sui costi di utilizzo SnapStart, consulta AWS Lambda la sezione Prezzi.](https://aws.amazon.com/lambda/pricing/#SnapStart_Pricing) # Attivazione e gestione di Lambda SnapStart Per utilizzarlo SnapStart, attivalo SnapStart su una funzione Lambda nuova o esistente. Quindi, pubblica e richiama una versione della funzione. **Topics** + [ ## Attivazione SnapStart (console) ](#snapshot-console) + [ ## Attivazione SnapStart ()AWS CLI ](#snapshot-cli) + [ ## Attivazione SnapStart (API) ](#snapshot-api) + [ ## Lambda SnapStart e stati funzionali ](#snapstart-function-states) + [ ## Aggiornamento di uno snapshot ](#update-snapshot) + [ ## Utilizzo con SnapStart AWS SDKs ](#snapstart-credentials) + [ ## Utilizzando SnapStart with CloudFormation, e AWS SAM AWS CDK ](#snapstart-cfn-sam) + [ ## Eliminazione di snapshot ](#snapshot-delete) ## Attivazione SnapStart (console) **Attivare SnapStart per una funzione** 1. Aprire la pagina [Functions](https://console.aws.amazon.com/lambda/home#/functions) (Funzioni) della console Lambda. 1. Scegliere il nome della funzione. 1. Scegli **Configuration** (Configurazione), quindi scegli **Configurazione generale**. 1. Nel pannello **General configuration** (Configurazione generale), scegli **Edit** (Modifica). 1. Nella pagina **Modifica impostazioni di base**, per **SnapStart**, scegli **Versioni pubblicate**. 1. Scegli **Save** (Salva). 1. [Pubblica una versione della funzione](configuration-versions.md#configuration-versions-config). Lambda inizializza il codice, crea uno snapshot dell'ambiente di esecuzione inizializzato e quindi memorizza nella cache lo snapshot per l'accesso a bassa latenza. 1. [Invoca la versione della funzione](configuration-versions.md#versioning-versions-using). ## Attivazione SnapStart ()AWS CLI **Da attivare SnapStart per una funzione esistente** 1. Aggiorna la configurazione della funzione eseguendo il [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html)comando con l'**--snap-start**opzione. ``` aws lambda update-function-configuration \ --function-name my-function \ --snap-start ApplyOn=PublishedVersions ``` 1. Pubblica una versione della funzione con il comando [publish-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-version.html). ``` aws lambda publish-version \ --function-name my-function ``` 1. Confermate che SnapStart sia attivata per la versione della funzione eseguendo il [get-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/get-function-configuration.html)comando e specificando il numero di versione. Il seguente esempio specifica la versione 1. ``` aws lambda get-function-configuration \ --function-name my-function:1 ``` Se la risposta mostra che [OptimizationStatus](https://docs.aws.amazon.com/lambda/latest/api/API_SnapStartResponse.html)is `On` e [State](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html#lambda-GetFunctionConfiguration-response-State) è`Active`, allora SnapStart viene attivata e un'istantanea è disponibile per la versione della funzione specificata. ``` "SnapStart": { "ApplyOn": "PublishedVersions", "OptimizationStatus": "On" }, "State": "Active", ``` 1. Richiama la versione della funzione eseguendo il comando [invoke](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/invoke.html) e specificando la versione. L'esempio seguente richiama la versione 1. ``` aws lambda invoke \ --cli-binary-format raw-in-base64-out \ --function-name my-function:1 \ --payload '{ "name": "Bob" }' \ response.json ``` L'**cli-binary-format**opzione è obbligatoria se si utilizza la AWS CLI versione 2. 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*. **Da attivare SnapStart quando si crea una nuova funzione** 1. Crea una funzione eseguendo il comando [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html) con l'opzione **--snap-start**. Per **--role**, specificare il nome della risorsa Amazon (ARN) del tuo [ruolo di esecuzione](lambda-intro-execution-role.md). ``` aws lambda create-function \ --function-name my-function \ --runtime "java25" \ --zip-file fileb://my-function.zip \ --handler my-function.handler \ --role arn:aws:iam::111122223333:role/lambda-ex \ --snap-start ApplyOn=PublishedVersions ``` 1. Crea una versione con il comando [publish-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-version.html). ``` aws lambda publish-version \ --function-name my-function ``` 1. Confermate che SnapStart sia attivata per la versione della funzione eseguendo il [get-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/get-function-configuration.html)comando e specificando il numero di versione. Il seguente esempio specifica la versione 1. ``` aws lambda get-function-configuration \ --function-name my-function:1 ``` Se la risposta mostra che [OptimizationStatus](https://docs.aws.amazon.com/lambda/latest/api/API_SnapStartResponse.html)is `On` e [State](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html#lambda-GetFunctionConfiguration-response-State) è`Active`, allora SnapStart viene attivata e un'istantanea è disponibile per la versione della funzione specificata. ``` "SnapStart": { "ApplyOn": "PublishedVersions", "OptimizationStatus": "On" }, "State": "Active", ``` 1. Richiama la versione della funzione eseguendo il comando [invoke](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/invoke.html) e specificando la versione. L'esempio seguente richiama la versione 1. ``` aws lambda invoke \ --cli-binary-format raw-in-base64-out \ --function-name my-function:1 \ --payload '{ "name": "Bob" }' \ response.json ``` L'**cli-binary-format**opzione è obbligatoria se si utilizza la AWS CLI versione 2. 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*. ## Attivazione SnapStart (API) **Attivare SnapStart** 1. Esegui una delle seguenti operazioni: + Crea una nuova funzione con SnapStart activated utilizzando l'azione [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)API con il [SnapStart](https://docs.aws.amazon.com/lambda/latest/api/API_SnapStart.html)parametro. + Attiva SnapStart per una funzione esistente utilizzando l'[UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)azione con il [SnapStart](https://docs.aws.amazon.com/lambda/latest/api/API_SnapStart.html)parametro. 1. Pubblica una versione della funzione con l'[PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html)azione. Lambda inizializza il codice, crea uno snapshot dell'ambiente di esecuzione inizializzato e quindi memorizza nella cache lo snapshot per l'accesso a bassa latenza. 1. Verifica che SnapStart sia attivata per la versione della funzione utilizzando l'[GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)azione. Specificate un numero di versione per confermare che SnapStart è attivata per quella versione. Se la risposta mostra che [OptimizationStatus](https://docs.aws.amazon.com/lambda/latest/api/API_SnapStartResponse.html)è `On` e [State](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html#lambda-GetFunctionConfiguration-response-State) è`Active`, allora SnapStart viene attivata ed è disponibile un'istantanea per la versione della funzione specificata. ``` "SnapStart": { "ApplyOn": "PublishedVersions", "OptimizationStatus": "On" }, "State": "Active", ``` 1. Richiama la versione della funzione con l'operazione [Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html). ## Lambda SnapStart e stati funzionali I seguenti stati di funzione possono verificarsi quando si utilizza SnapStart. **Pending (In attesa)** Lambda sta inizializzando il codice e acquisendo uno snapshot dell'ambiente di esecuzione inizializzato. Qualsiasi chiamata o altre operazioni API che operano sulla versione della funzione avranno esito negativo. **Attivo** La creazione dello snapshot è completa ed è possibile richiamare la funzione. Per utilizzarla SnapStart, è necessario richiamare la versione della funzione pubblicata, non la versione non pubblicata (\$1LATEST). **Inattivo** Lo `Inactive` stato può verificarsi quando Lambda rigenera periodicamente le istantanee delle funzioni per applicare gli aggiornamenti software. In questo caso, se la funzione non riesce a inizializzarsi, può entrare in uno stato `Inactive`. Per le funzioni che utilizzano un runtime Java, Lambda elimina gli snapshot dopo 14 giorni senza alcuna invocazione. Se si richiama la versione della funzione dopo 14 giorni, Lambda restituisce una risposta `SnapStartNotReadyException` e inizia a inizializzare un nuovo snapshot. Attendi che la versione della funzione raggiunga lo stato `Active`, quindi richiamala di nuovo. **Non riuscito** Lambda ha riscontrato un errore durante l'esecuzione del codice di inizializzazione o la creazione dello snapshot. ## Aggiornamento di uno snapshot Lambda crea uno snapshot per ogni versione della funzione pubblicata. Per aggiornare uno snapshot, pubblica una nuova versione della funzione. ## Utilizzo con SnapStart AWS SDKs Per effettuare chiamate AWS SDK dalla tua funzione, Lambda genera un set temporaneo di credenziali assumendo il ruolo di esecuzione della funzione. Queste credenziali sono disponibili come variabili d'ambiente durante l'invocazione della funzione. Non è necessario fornire le credenziali per l'SDK direttamente nel codice. Per impostazione predefinita, la catena di fornitori di credenziali controlla in sequenza ogni punto in cui è possibile impostare le credenziali e seleziona il primo disponibile, in genere le variabili d'ambiente (`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` e `AWS_SESSION_TOKEN`). **Nota** Quando SnapStart è attivato, il runtime Lambda utilizza automaticamente le credenziali del contenitore (`AWS_CONTAINER_CREDENTIALS_FULL_URI`and`AWS_CONTAINER_AUTHORIZATION_TOKEN`) anziché le variabili di ambiente della chiave di accesso. Ciò impedisce la scadenza delle credenziali prima che la funzione venga ripristinata. ## Utilizzando SnapStart with CloudFormation, e AWS SAM AWS CDK + **AWS CloudFormation:** dichiara l'[SnapStart](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-lambda-function-snapstart.html)entità nel modello. + **AWS Serverless Application Model (AWS SAM):** dichiara la [SnapStart](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html#sam-function-snapstart)proprietà nel modello. + **AWS Cloud Development Kit (AWS CDK):** Usa il [SnapStartProperty](https://docs.aws.amazon.com/cdk/api/v2/java/software/amazon/awscdk/services/lambda/CfnFunction.SnapStartProperty.html)tipo. ## Eliminazione di snapshot Lambda elimina gli snapshot quando: + Si elimina la funzione o la versione della funzione. + **Solo runtime Java**: non si richiama la versione della funzione per 14 giorni. Dopo 14 giorni senza una chiamata, la versione della funzione passa allo stato [Inactive](#snapstart-function-states) (Inattivo). Se si richiama la versione della funzione dopo 14 giorni, Lambda restituisce una risposta `SnapStartNotReadyException` e inizia a inizializzare un nuovo snapshot. Attendi che la versione della funzione raggiunga lo stato [Active](#snapstart-function-states) (Attivo), quindi richiamala di nuovo. Lambda rimuove tutte le risorse associate agli snapshot eliminati in conformità con il Regolamento generale sulla protezione dei dati (GDPR). # Gestire l'unicità con Lambda SnapStart Quando le chiamate aumentano su una SnapStart funzione, Lambda utilizza una singola istantanea inizializzata per riprendere più ambienti di esecuzione. Se il codice di inizializzazione genera contenuti unici inclusi nello snapshot, il contenuto potrebbe non essere più unico quando viene riutilizzato in più ambienti di esecuzione. Per mantenere l'unicità durante l'utilizzo SnapStart, è necessario generare contenuti unici dopo l'inizializzazione. Ciò include segreti unici IDs e unici e l'entropia utilizzata per generare pseudocasualità. Di seguito sono riportate le best practice che consentono di mantenere l'unicità nel codice. Per le funzioni Java, Lambda fornisce anche [uno strumento di SnapStart scansione](#snapstart-scanning) open source per aiutare a verificare la presenza di codice che presuppone l'unicità. Se durante la fase di inizializzazione vengono generati dati univoci, è possibile utilizzare un [hook di runtime](snapstart-runtime-hooks.md) per ripristinare l'unicità. Con gli hook di runtime, puoi eseguire codice specifico immediatamente prima che Lambda esegua uno snapshot o subito dopo che Lambda riprende una funzione da uno snapshot. ## Evitare lo stato di salvataggio che dipende dall'unicità durante l'inizializzazione Durante la [fase di inizializzazione](lambda-runtime-environment.md#runtimes-lifecycle-ib) della funzione, evita di memorizzare nella cache dati destinati a essere univoci, ad esempio la generazione di un ID univoco per la registrazione o l'impostazione di seed per funzioni casuali. Ti consigliamo invece di generare dati univoci o impostare seed per le funzioni casuali all'interno dell'handler delle funzioni o di utilizzare un [hook di runtime](snapstart-runtime-hooks.md). I seguenti esempi mostrano come generare un UUID nell'handler delle funzioni. ------ #### [ Java ] **Example : generazione di un ID univoco nel gestore delle funzioni** ``` import java.util.UUID; public class Handler implements RequestHandler { private static UUID uniqueSandboxId = null; @Override public String handleRequest(String event, Context context) { if (uniqueSandboxId == null) uniqueSandboxId = UUID.randomUUID(); System.out.println("Unique Sandbox Id: " + uniqueSandboxId); return "Hello, World!"; } } ``` ------ #### [ Python ] **Example : generazione di un ID univoco nel gestore delle funzioni** ``` import json import random import time unique_number = None def lambda_handler(event, context): seed = int(time.time() * 1000) random.seed(seed) global unique_number if not unique_number: unique_number = random.randint(1, 10000) print("Unique number: ", unique_number) return "Hello, World!" ``` ------ #### [ .NET ] **Example : generazione di un ID univoco nel gestore delle funzioni** ``` namespace Example; public class SnapstartExample { private Guid _myExecutionEnvironmentGuid; public SnapstartExample() { // This GUID is set for non-restore use cases, such as testing or if SnapStart is turned off _myExecutionEnvironmentGuid = new Guid(); // Register the method which will run after each restore. You may need to update Amazon.Lambda.Core to see this Amazon.Lambda.Core.SnapshotRestore.RegisterAfterRestore(MyAfterRestore); } private ValueTask MyAfterRestore() { // After restoring this snapshot to a new execution environment, update the GUID _myExecutionEnvironmentGuid = new Guid(); return ValueTask.CompletedTask; } public string Handler() { return $"Hello World! My Execution Environment GUID is {_myExecutionEnvironmentGuid}"; } } ``` ------ ## Utilizza generatori di numeri pseudocasuali crittograficamente sicuri () CSPRNGs Se la tua applicazione dipende dalla casualità, ti consigliamo di utilizzare generatori di numeri casuali crittograficamente sicuri (). CSPRNGs Oltre a OpenSSL 1.0.2, i runtime gestiti da Lambda includono anche le seguenti funzionalità integrate: CSPRNGs + **Java:** `java.security.SecureRandom` + **Python:** `random.SystemRandom` + **.NET:** `System.Security.Cryptography.RandomNumberGenerator` Software che ottiene sempre numeri casuali da `/dev/random` o `/dev/urandom` con cui mantiene la casualità. SnapStart AWS Le librerie di crittografia mantengono automaticamente la casualità a SnapStart partire dalle versioni minime specificate nella tabella seguente. Se usi queste librerie con le tue funzioni Lambda, assicurati di utilizzare le seguenti versioni minime o versioni successive: **** | Libreria | Versione minima supportata (x86) | Versione minima supportata (ARM) | | --- | --- | --- | | AWS libcrypto (-LC)AWS | 1.16.0 | 1.30.0 | | AWS libcrypto FIPS | 2.0.13 | 2.0.13 | Se impacchetti le librerie di crittografia precedenti con le funzioni Lambda come dipendenze transitive tramite le seguenti librerie, assicurati di utilizzare le seguenti versioni minime o versioni successive: **** | Libreria | Versione minima supportata (x86) | Versione minima supportata (ARM) | | --- | --- | --- | | AWS SDK for Java 2.x | 2.23.20 | 2,26,12 | | AWS Common Runtime per Java | 0.29.8 | 0,29,25 | | Fornitore di servizi di crittografia Amazon Corretto | 2.4.1 | 2.4.1 | | FIPS Fornitore di servizi di crittografia Amazon Corretto | 2.4.1 | 2.4.1 | Gli esempi seguenti mostrano come CSPRNGs garantire sequenze numeriche univoche anche quando la funzione viene ripristinata da un'istantanea. ------ #### [ Java ] **Example — java.security. SecureRandom** ``` import java.security.SecureRandom; public class Handler implements RequestHandler { private static SecureRandom rng = new SecureRandom(); @Override public String handleRequest(String event, Context context) { for (int i = 0; i < 10; i++) { System.out.println(rng.next()); } return "Hello, World!"; } } ``` ------ #### [ Python ] **Example — casuale. SystemRandom** ``` import json import random secure_rng = random.SystemRandom() def lambda_handler(event, context): random_numbers = [secure_rng.random() for _ in range(10)] for number in random_numbers: print(number) return "Hello, World!" ``` ------ #### [ .NET ] **Example – RandomNumberGenerator** ``` using Amazon.Lambda.Core; using System.Security.Cryptography; [assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))] namespace DotnetSecureRandom; public class Function { public string FunctionHandler() { using (RandomNumberGenerator rng = RandomNumberGenerator.Create()) { byte[] randomUnsignedInteger32Bytes = new byte[4]; for (int i = 0; i < 10; i++) { rng.GetBytes(randomUnsignedInteger32Bytes); int randomInt32 = BitConverter.ToInt32(randomUnsignedInteger32Bytes, 0); Console.WriteLine("{0:G}", randomInt32); } } return "Hello World!"; } } ``` ------ ## SnapStart strumento di scansione (solo Java) Lambda fornisce uno strumento di scansione che aiuta a verificare la presenza di codice che presuppone l'unicità. Lo strumento di SnapStart scansione è un [SpotBugs](https://spotbugs.github.io/)plug-in open source che esegue un'analisi statica rispetto a una serie di regole. Lo strumento di scansione consente di identificare potenziali implementazioni di codice che potrebbero infrangere i presupposti sull'unicità. Per le istruzioni di installazione e un elenco dei controlli eseguiti dallo strumento di scansione, consultate il repository [aws-lambda-snapstart-java-rules su](https://github.com/aws/aws-lambda-snapstart-java-rules). GitHub Per saperne di più sulla gestione dell'unicità con SnapStart, consulta Starting [up faster with AWS Lambda SnapStart](https://aws.amazon.com/blogs/compute/starting-up-faster-with-aws-lambda-snapstart/) sul blog di Compute AWS . # Implementare il codice prima o dopo gli snapshot della funzione Lambda Gli hook di runtime possono essere utilizzati per implementare il codice prima che Lambda crei uno snapshot o dopo che ha ripristinato una funzione da uno snapshot. Gli hook di runtime sono utili per diversi scopi, ad esempio: + **Pulizia e inizializzazione:** prima di creare uno snapshot, è possibile utilizzare un hook di runtime per eseguire operazioni di pulizia o rilascio delle risorse. Dopo il ripristino di uno snapshot, è possibile utilizzare un runtime hook per reinizializzare tutte le risorse o lo stato che non sono stati acquisiti nello snapshot. + **Configurazione dinamica:** è possibile utilizzare gli hook di runtime per aggiornare dinamicamente la configurazione o altri metadati prima della creazione di uno snapshot o dopo il suo ripristino. Ciò può essere utile se la funzione deve adattarsi ai cambiamenti nell'ambiente di runtime. + **Integrazioni esterne:** è possibile utilizzare gli hook di runtime per l'integrazione con servizi o sistemi esterni, ad esempio l'invio di notifiche o l'aggiornamento dello stato esterno, come parte del processo di checkpoint e ripristino. + **Ottimizzazione delle prestazioni:** è possibile utilizzare gli hook di runtime per ottimizzare la sequenza di avvio della funzione, ad esempio precaricando le dipendenze. Per ulteriori informazioni, consulta [Ottimizzazione prestazioni](snapstart-best-practices.md#snapstart-tuning). Le pagine seguenti spiegano come implementare gli hook di runtime per il runtime preferito. **Topics** + [Java](snapstart-runtime-hooks-java.md) + [Python](snapstart-runtime-hooks-python.md) + [.NET](snapstart-runtime-hooks-dotnet.md) # Hook di SnapStart runtime Lambda per Java Gli hook di runtime possono essere utilizzati per implementare il codice prima che Lambda crei uno snapshot o dopo che ha ripristinato una funzione da uno snapshot. Gli hook di runtime sono disponibili come parte del progetto open source Coordinated Restore at Checkpoint (C)CRa. CRaC è in fase di sviluppo per l'[Open Java Development Kit (OpenJDK](https://wiki.openjdk.org/display/crac)). Per un esempio di come usare CRa C con un'applicazione di riferimento, consulta il repository [CRaC](https://github.com/CRaC/docs/blob/master/STEP-BY-STEP.md) su. GitHub CRaC utilizza tre elementi principali: + `Resource`: un'interfaccia con due metodi, `beforeCheckpoint()` e `afterRestore()`. Utilizza questi metodi per implementare il codice che desideri eseguire prima di uno snapshot e dopo un ripristino. + `Context `: per ricevere notifiche relative ai checkpoint e ai ripristini, è necessario registrare una `Resource` con un `Context`. + `Core`: il servizio di coordinamento, che fornisce il `Context` globale predefinito tramite il metodo statico `Core.getGlobalContext()`. Per ulteriori informazioni su `Context` and`Resource`, vedere [Package org.crac nella CRa documentazione C.](https://javadoc.io/doc/io.github.crac/org-crac/latest/index.html) Completa le seguenti operazioni per implementare gli hook di runtime con il [pacchetto org.crac](https://github.com/CRaC/org.crac). Il runtime Lambda contiene un'implementazione di contesto CRa C personalizzata che richiama gli hook di runtime prima del checkpoint e dopo il ripristino. ## Registrazione ed esecuzione di hook di runtime L'ordine in cui Lambda esegue gli hook di runtime è determinato dall'ordine di registrazione. L'ordine di registrazione segue l'ordine di importazione, definizione o esecuzione nel codice. + `beforeCheckpoint()`: eseguito nell'ordine di registrazione inverso + `afterRestore()`: eseguito nell'ordine di registrazione Assicurati che tutti gli hook registrati siano stati importati e inclusi correttamente nel codice della tua funzione. Se registri gli hook di runtime in un file o modulo separato, dovrai assicurarti che il modulo venga importato, direttamente o come parte di un pacchetto più grande, nel file handler della funzione. Se il file o il modulo non viene importato nell'handler della funzione, Lambda ignorerà gli hook di runtime. **Nota** Quando Lambda crea uno snapshot, il codice di inizializzazione può essere eseguito per un massimo di 15 minuti. Il limite di tempo è 130 secondi o il [timeout della funzione configurato](configuration-timeout.md) (massimo 900 secondi), a seconda di quale dei due valori sia più elevato. I tuoi hook di runtime `beforeCheckpoint()` contano ai fini del limite di tempo del codice di inizializzazione. Quando Lambda ripristina uno snapshot, il runtime deve essere caricato e gli hook di runtime `afterRestore()` devono essere completati entro il limite di timeout (10 secondi). Altrimenti, otterrai un. SnapStartTimeoutException ## Fase 1: aggiornamento della configurazione di build Aggiungi la dipendenza `org.crac` alla configurazione della build. Nell'esempio seguente viene utilizzato Gradle. Per esempi di altri sistemi di compilazione, consulta la [documentazione di Apache Maven](https://search.maven.org/artifact/io.github.crac/org-crac/0.1.3/jar). ``` dependencies { compile group: 'com.amazonaws', name: 'aws-lambda-java-core', version: '1.2.1' # All other project dependecies go here: # ... # Then, add the org.crac dependency: implementation group: 'org.crac', name: 'crac', version: '1.4.0' } ``` ## Fase 2: aggiornamento del gestore Lambda Il *gestore* di funzioni Lambda è il metodo nel codice della funzione che elabora gli eventi. Quando viene richiamata la funzione, Lambda esegue il metodo del gestore. La funzione viene eseguita fino a quando il gestore non restituisce una risposta, termina o scade. Per ulteriori informazioni, consulta [Definire l'handler della funzione Lambda in Java](java-handler.md). Il seguente gestore di esempio mostra come eseguire il codice prima del checkpoint (`beforeCheckpoint()`) e dopo il ripristino (`afterRestore()`). Questo gestore registra anche la `Resource` nel `Context` gestito dal runtime. **Nota** Quando Lambda crea uno snapshot, il codice di inizializzazione può essere eseguito per un massimo di 15 minuti. Il limite di tempo è 130 secondi o il [timeout della funzione configurato](configuration-timeout.md) (massimo 900 secondi), a seconda di quale dei due valori sia più elevato. I tuoi hook di runtime `beforeCheckpoint()` contano ai fini del limite di tempo del codice di inizializzazione. Quando Lambda ripristina uno snapshot, il runtime (JVM) deve essere caricato e gli hook di runtime `afterRestore()` devono essere completati entro il limite di timeout (10 secondi). Altrimenti, avrai un SnapStartTimeoutException. ``` ... import org.crac.Resource; import org.crac.Core; ... public class CRaCDemo implements RequestStreamHandler, Resource { public CRaCDemo() { Core.getGlobalContext().register(this); } public String handleRequest(String name, Context context) throws IOException { System.out.println("Handler execution"); return "Hello " + name; } @Override public void beforeCheckpoint(org.crac.Context context) throws Exception { System.out.println("Before checkpoint"); } @Override public void afterRestore(org.crac.Context context) throws Exception { System.out.println("After restore"); ``` `Context` mantiene solo un [https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/WeakReference.html](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/WeakReference.html) all'oggetto registrato. Se per una [https://javadoc.io/static/io.github.crac/org-crac/0.1.3/org/crac/Resource.html](https://javadoc.io/static/io.github.crac/org-crac/0.1.3/org/crac/Resource.html) viene eseguita la rimozione di oggetti inutili (garbage collection), gli hook di runtime non vengono eseguiti. Il codice deve mantenere un forte riferimento alla `Resource` per garantire l'esecuzione dell'hook di runtime. Ecco due esempi di modelli da evitare: **Example : oggetto senza un forte riferimento** ``` Core.getGlobalContext().register( new MyResource() ); ``` **Example : oggetti di classi anonime** ``` Core.getGlobalContext().register( new Resource() { @Override public void afterRestore(Context context) throws Exception { // ... } @Override public void beforeCheckpoint(Context context) throws Exception { // ... } } ); ``` Invece, mantieni un riferimento forte. Nell'esempio seguente, per la risorsa registrata non viene eseguita la rimozione di oggetti inutili (garbage collection) e gli hook di runtime vengono eseguiti in modo coerente. **Example : oggetto con un forte riferimento** ``` Resource myResource = new MyResource(); // This reference must be maintained to prevent the registered resource from being garbage collected Core.getGlobalContext().register( myResource ); ``` # Hook di runtime SnapStart per Lambda per Python Gli hook di runtime possono essere utilizzati per implementare il codice prima che Lambda crei uno snapshot o dopo che ha ripristinato una funzione da uno snapshot. Gli hook di runtime Python sono disponibili come parte della libreria open source [Snapshot Restore for Python](https://pypi.org/project/snapshot-restore-py/), che è inclusa nei runtime gestiti da Python. Questa libreria fornisce due decoratori che possono essere utilizzati per definire i tuoi hook di runtime: + `@register_before_snapshot`: per le funzioni che si desidera eseguire prima che Lambda crei uno snapshot. + `@register_after_restore`: per le funzioni che si desidera eseguire quando Lambda riprende una funzione da uno snapshot. In alternativa, è possibile utilizzare i seguenti metodi per registrare gli elementi chiamabili per gli hook di runtime: + `register_before_snapshot(func, *args, **kwargs)` + `register_after_restore(func, *args, **kwargs)` ## Registrazione ed esecuzione di hook di runtime L'ordine in cui Lambda esegue gli hook di runtime è determinato dall'ordine di registrazione: + Prima dello snapshot: eseguito nell'ordine di registrazione inverso + Dopo lo snapshot: eseguito nell'ordine di registrazione L'ordine di registrazione degli hook di runtime dipende da come vengono definiti gli hook. Quando si utilizzano i decoratori (`@register_before_snapshot` e `@register_after_restore`), l'ordine di registrazione segue l'ordine di importazione, definizione o esecuzione nel codice. Se hai bisogno di un maggiore controllo sull'ordine di registrazione, usa i metodi `register_before_snapshot()` e `register_after_restore()` anziché i decoratori. Assicurati che tutti gli hook registrati siano stati importati e inclusi correttamente nel codice della tua funzione. Se registri gli hook di runtime in un file o modulo separato, dovrai assicurarti che il modulo venga importato, direttamente o come parte di un pacchetto più grande, nel file handler della funzione. Se il file o il modulo non viene importato nell'handler della funzione, Lambda ignorerà gli hook di runtime. **Nota** Quando Lambda crea uno snapshot, il codice di inizializzazione può essere eseguito per un massimo di 15 minuti. Il limite di tempo è 130 secondi o il [timeout della funzione configurato](configuration-timeout.md) (massimo 900 secondi), a seconda di quale dei due valori sia più elevato. I tuoi hook di runtime `@register_before_snapshot` contano ai fini del limite di tempo del codice di inizializzazione. Quando Lambda ripristina uno snapshot, il runtime deve essere caricato e gli hook di runtime `@register_after_restore` devono essere completati entro il limite di timeout (10 secondi). Altrimenti, otterrai un'eccezione SnapStartTimeoutException. ## Esempio Il seguente gestore di esempio mostra come eseguire il codice prima del checkpoint (`@register_before_snapshot`) e dopo il ripristino (`@register_after_restore`). ``` from snapshot_restore_py import register_before_snapshot, register_after_restore def lambda_handler(event, context): # Handler code @register_before_snapshot def before_checkpoint(): # Logic to be executed before taking snapshots @register_after_restore def after_restore(): # Logic to be executed after restore ``` Per altri esempi, consulta [Ripristino di snapshot per Python](https://github.com/aws/snapshot-restore-py/tree/main/examples) nel repository AWS GitHub. # Hook di runtime SnapStart per Lambda per .NET Gli hook di runtime possono essere utilizzati per implementare il codice prima che Lambda crei uno snapshot o dopo che ha ripristinato una funzione da uno snapshot. Gli hook di runtime .NET sono disponibili come parte del pacchetto [Amazon.Lambda.Core](https://www.nuget.org/packages/Amazon.Lambda.Core) (versione 2.5.0 o successiva). Questa libreria fornisce due metodi che possono essere utilizzati per definire i tuoi hook di runtime: + `RegisterBeforeSnapshot()`: codice da eseguire prima della creazione dello snapshot + `RegisterAfterSnapshot()`: codice da eseguire dopo la ripresa di una funzione da uno snapshot **Nota** Se utilizzi il [framework Lambda Annotations per .NET](csharp-handler.md#csharp-handler-annotations), esegui l'upgrade alla versione 1.6.0 o successiva di [Amazon.Lambda.Annotations](https://www.nuget.org/packages/Amazon.Lambda.Annotations) per garantire la compatibilità con SnapStart. ## Registrazione ed esecuzione di hook di runtime Registra i tuoi hook nel codice di inizializzazione. Prendi in considerazione le seguenti linee guida basate sul [modello di esecuzione](csharp-handler.md#csharp-handler-setup) della tua funzione Lambda: + Per l'[approccio all'assembly eseguibile](csharp-handler.md#csharp-executable-assembly-handlers), registra i tuoi hook prima di avviare il bootstrap Lambda con `RunAsync`. + Per l'[approccio basato sulle librerie di classi](csharp-handler.md#csharp-class-library-handlers), registra i tuoi hook nel costruttore della classe handler. + Per le [applicazioni ASP.NET Core](csharp-package-asp.md), registra gli hook prima di chiamare il metodo `WebApplications.Run`. Per registrare gli hook di runtime per SnapStart in .NET, utilizza i seguenti metodi: ``` Amazon.Lambda.Core.SnapshotRestore.RegisterBeforeSnapshot(BeforeCheckpoint); Amazon.Lambda.Core.SnapshotRestore.RegisterAfterRestore(AfterCheckpoint); ``` Quando vengono registrati più tipi di hook, l'ordine in cui Lambda esegue gli hook di runtime è determinato dall'ordine di registrazione: + `RegisterBeforeSnapshot()`: eseguito nell'ordine di registrazione inverso + `RegisterAfterSnapshot()`: eseguito nell'ordine di registrazione **Nota** Quando Lambda crea uno snapshot, il codice di inizializzazione può essere eseguito per un massimo di 15 minuti. Il limite di tempo è 130 secondi o il [timeout della funzione configurato](configuration-timeout.md) (massimo 900 secondi), a seconda di quale dei due valori sia più elevato. I tuoi hook di runtime `RegisterBeforeSnapshot()` contano ai fini del limite di tempo del codice di inizializzazione. Quando Lambda ripristina uno snapshot, il runtime deve essere caricato e gli hook di runtime `RegisterAfterSnapshot()` devono essere completati entro il limite di timeout (10 secondi). Altrimenti, otterrai un'eccezione SnapStartTimeoutException. ## Esempio La seguente funzione di esempio mostra come eseguire il codice prima del checkpoint (`RegisterBeforeSnapshot`) e dopo il ripristino (`RegisterAfterRestore`). ``` public class SampleClass { public SampleClass() { Amazon.Lambda.Core.SnapshotRestore.RegisterBeforeSnapshot(BeforeCheckpoint); Amazon.Lambda.Core.SnapshotRestore.RegisterAfterRestore(AfterCheckpoint); } private ValueTask BeforeCheckpoint() { // Add logic to be executed before taking the snapshot return ValueTask.CompletedTask; } private ValueTask AfterCheckpoint() { // Add logic to be executed after restoring the snapshot return ValueTask.CompletedTask; } public APIGatewayProxyResponse FunctionHandler(APIGatewayProxyRequest request, ILambdaContext context) { // Add business logic return new APIGatewayProxyResponse { StatusCode = 200 }; } } ``` # Monitoraggio per Lambda SnapStart È possibile monitorare le funzioni Lambda SnapStart utilizzando Amazon CloudWatch, AWS X-Ray e l'[Accesso ai dati di telemetria in tempo reale per le estensioni tramite l'API Telemetry](telemetry-api.md). **Nota** Le [variabili di ambiente](configuration-envvars.md#configuration-envvars-runtime) `AWS_LAMBDA_LOG_GROUP_NAME` e `AWS_LAMBDA_LOG_STREAM_NAME` non sono disponibili nelle funzioni Lambda SnapStart. ## Informazioni sul comportamento di registrazione e fatturazione con SnapStart Esistono alcune differenze con il formato del [flusso di log di CloudWatch](monitoring-cloudwatchlogs.md) per le funzioni SnapStart: + **Log di inizializzazione**: quando viene creato un nuovo ambiente di esecuzione, il `REPORT` non include il campo `Init Duration`. Questo perché Lambda inizializza le funzioni SnapStart quando si crea una versione anziché durante l'invocazione della funzione. Per le funzioni SnapStart, il campo `Init Duration` è nel record `INIT_REPORT`. Questo record mostra i dettagli della durata di [Fase di init](lambda-runtime-environment.md#runtimes-lifecycle-ib), inclusa la durata di eventuali [hook di runtime](snapstart-runtime-hooks.md) `beforeCheckpoint`. + **Log di invocazione**: quando viene creato un nuovo ambiente di esecuzione, il `REPORT` include i campi `Restore Duration` e `Billed Restore Duration`: + `Restore Duration`: il tempo impiegato da Lambda per ripristinare uno snapshot, caricare il runtime (JVM) ed eseguire qualsiasi hook di runtime . Il processo di ripristino degli snapshot può includere il tempo dedicato ad attività esterne alla MicroVM. Questo tempo non è riportato in `Restore Duration`. + `Billed Restore Duration`: il tempo impiegato da Lambda per ripristinare uno snapshot, caricare il runtime (JVM) ed eseguire qualsiasi hook di runtime . **Nota** Come per tutte le funzioni Lambda, i costi di durata si applicano al codice eseguito nell'handler delle funzioni. Per le funzioni SnapStart, i costi di durata si applicano anche al codice di inizializzazione dichiarato all'esterno dell'handler, al tempo necessario per il caricamento del runtime e a qualsiasi codice eseguito in un [hook di runtime](snapstart-runtime-hooks.md). La durata dell'avviamento a freddo è la somma di `Restore Duration` e `Duration`. L'esempio seguente è una query Lambda Insights che restituisce i percentili di latenza per le funzioni SnapStart. Per ulteriori informazioni sulle query Lambda Insights, consulta [Esempio di flusso di lavoro utilizzando query per risolvere i problemi di una funzione](monitoring-insights.md#monitoring-insights-queries). ``` filter @type = "REPORT" | parse @log /\d+:\/aws\/lambda\/(?.*)/ | parse @message /Restore Duration: (?.*?) ms/ | stats count(*) as invocations, pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 50) as p50, pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 90) as p90, pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 99) as p99, pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 99.9) as p99.9 group by function, (ispresent(@initDuration) or ispresent(restoreDuration)) as coldstart | sort by coldstart desc ``` ## Tracciamento attivo X-Ray per SnapStart È possibile utilizzare [X-Ray](services-xray.md) per tracciare le richieste alle funzioni Lambda SnapStart. I sottosegmenti X-Ray per le funzioni SnapStart presentano alcune differenze: + Non esiste un sottosegmento `Initialization` per le funzioni SnapStart. + Il sottosegmento mostra il tempo impiegato da Lambda per ripristinare uno snapshot, caricare il runtime (JVM) ed eseguire qualsiasi hook di runtime . Il processo di ripristino degli snapshot può includere il tempo dedicato ad attività esterne alla MicroVM. Questa volta è riportato nel segmento secondario `Restore`. Non ti viene addebitato il tempo trascorso fuori dalla microVM per il ripristino di una snapshot. ## Eventi dell'API di telemetria per SnapStart Lambda invia i seguenti eventi SnapStart all'[API di telemetria](telemetry-api.md): + [`platform.restoreStart`](telemetry-schema-reference.md#platform-restoreStart): mostra l'ora in cui è iniziata la [fase `Restore`](lambda-runtime-environment.md#runtimes-lifecycle-restore). + [`platform.restoreRuntimeDone`](telemetry-schema-reference.md#platform-restoreRuntimeDone): indica se la fase `Restore` è riuscita correttamente. Lambda genera questo messaggio quando il runtime invia una richiesta API di runtime `restore/next`. Ci sono tre stati possibili: riuscito, errore e timeout. + [`platform.restoreReport`](telemetry-schema-reference.md#platform-restoreReport): mostra quanto è durata la fase `Restore` e quanti millisecondi sono stati fatturati durante questa fase. ## Parametri di Gateway Amazon API e della funzione URL Se crei un'API Web [utilizzando Gateway API](services-apigateway.md), puoi utilizzare il parametro [IntegrationLatency](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-metrics-and-dimensions.html) per misurare la latenza end-to-end (il tempo che intercorre tra il momento in cui Gateway API inoltra una richiesta al backend e il momento in cui riceve una risposta dal backend). Se utilizzi [l'URL di una funzione Lambda](urls-configuration.md), puoi utilizzare il parametro [URLRequestLatency](urls-monitoring.md) per misurare la latenza end-to-end (il tempo che intercorre tra il momento in cui la funzione URL riceve una richiesta e il momento in cui restituisce una risposta). # Modello di sicurezza per Lambda SnapStart Lambda SnapStart supporta la crittografia dei dati inattivi. Lambda crittografa gli snapshot con una AWS KMS key. Per impostazione predefinita, Lambda utilizza un Chiave gestita da AWS. Se questo comportamento predefinito si adatta al flusso di lavoro, non è necessario impostare altro. Altrimenti, puoi utilizzare l'opzione `--kms-key-arn` nel comando [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html) o [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html) per fornire una chiave gestita dal cliente AWS KMS. È possibile eseguire questa operazione per controllare la rotazione della chiave KMS o per soddisfare i requisiti dell'organizzazione per la gestione delle chiavi KMS. Le chiavi gestite dal cliente sono soggette a costi AWS KMS standard. Per ulteriori informazioni, consultare [Prezzi di AWS Key Management Service](https://aws.amazon.com/kms/pricing/). Quando si elimina una funzione o la versione di una funzione SnapStart, tutte le richieste `Invoke` relative a tale funzione o versione della funzione avranno esito negativo. Lambda rimuove tutte le risorse associate agli snapshot eliminati in conformità con il Regolamento generale sulla protezione dei dati (GDPR). # Massimizza le prestazioni Lambda SnapStart **Topics** + [ ## Ottimizzazione prestazioni ](#snapstart-tuning) + [ ## Best practice per la rete ](#snapstart-networking) ## Ottimizzazione prestazioni Per massimizzare i vantaggi di SnapStart, prendi in considerazione i seguenti consigli di ottimizzazione del codice per il tuo runtime. **Nota** SnapStart funziona meglio se utilizzato con invocazioni di funzioni su larga scala. Le funzioni richiamate di rado potrebbero non presentare gli stessi miglioramenti delle prestazioni. ### Java Per massimizzare i vantaggi di SnapStart, si consiglia di precaricare le dipendenze e inizializzare le risorse che contribuiscono alla latenza di avvio nel codice di inizializzazione anziché nel gestore delle funzioni. In questo modo la latenza associata al caricamento intensivo delle classi viene rimossa dal percorso di invocazione, ottimizzando le prestazioni di avvio con. SnapStart Se non riesci a precaricare le dipendenze o le risorse durante l'inizializzazione, ti consigliamo di precaricarle con invocazioni fittizie. A tale scopo, aggiornate il codice del gestore delle funzioni, come illustrato nell'esempio seguente, tratto dalla [funzione pet store del repository](https://github.com/awslabs/aws-serverless-java-container/tree/main/samples/spring/pet-store) Labs. AWS GitHub ``` private static SpringLambdaContainerHandler handler; static { try { handler = SpringLambdaContainerHandler.getAwsProxyHandler(PetStoreSpringAppConfig.class); // Use the onStartup method of the handler to register the custom filter handler.onStartup(servletContext -> { FilterRegistration.Dynamic registration = servletContext.addFilter("CognitoIdentityFilter", CognitoIdentityFilter.class); registration.addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST), false, "/*"); }); // Send a fake Amazon API Gateway request to the handler to load classes ahead of time ApiGatewayRequestIdentity identity = new ApiGatewayRequestIdentity(); identity.setApiKey("foo"); identity.setAccountId("foo"); identity.setAccessKey("foo"); AwsProxyRequestContext reqCtx = new AwsProxyRequestContext(); reqCtx.setPath("/pets"); reqCtx.setStage("default"); reqCtx.setAuthorizer(null); reqCtx.setIdentity(identity); AwsProxyRequest req = new AwsProxyRequest(); req.setHttpMethod("GET"); req.setPath("/pets"); req.setBody(""); req.setRequestContext(reqCtx); Context ctx = new TestContext(); handler.proxy(req, ctx); } catch (ContainerInitializationException e) { // if we fail here. We re-throw the exception to force another cold start e.printStackTrace(); throw new RuntimeException("Could not initialize Spring framework", e); } } ``` ### Python Per massimizzare i vantaggi di SnapStart, concentrati sull'organizzazione efficiente del codice e sulla gestione delle risorse all'interno delle tue funzioni Python. Come linea guida generale, esegui attività di calcolo complesse durante la [fase di inizializzazione](lambda-runtime-environment.md#runtimes-lifecycle-ib). Questo approccio elimina dal percorso di invocazione le operazioni che richiedono molto tempo, migliorando le prestazioni complessive delle funzioni. Per implementare questa strategia in modo efficace, consigliamo le seguenti best practice: + Importa le dipendenze al di fuori dell'handler della funzione. + Crea istanze `boto3` al di fuori dell'handler. + Inizializza le risorse o le configurazioni statiche prima che l'handler venga richiamato. + Prendi in considerazione l'utilizzo di un [hook di runtime](snapstart-runtime-hooks-python.md) prima dello snapshot per attività che richiedono molte risorse come il download di file esterni, il precaricamento di framework come Django o il caricamento di modelli di machine learning. **Example — Ottimizza la funzione Python per SnapStart** ``` # Import all dependencies outside of Lambda handler from snapshot_restore_py import register_before_snapshot import boto3 import pandas import pydantic # Create S3 and SSM clients outside of Lambda handler s3_client = boto3.client("s3") # Register the function to be called before snapshot @register_before_snapshot def download_llm_models(): # Download an object from S3 and save to tmp # This files will persist in this snapshot with open('/tmp/FILE_NAME', 'wb') as f: s3_client.download_fileobj('amzn-s3-demo-bucket', 'OBJECT_NAME', f) ... def lambda_handler(event, context): ... ``` ### .NET [Per ridurre i tempi di compilazione just-in-time (JIT) e caricamento degli assiemi, prendete in considerazione la possibilità di richiamare il gestore di funzioni da un hook di runtime. `RegisterBeforeCheckpoint`](snapstart-runtime-hooks-dotnet.md) Grazie al funzionamento della compilazione su più livelli .NET, otterrai risultati ottimali richiamando l'handler più volte, come illustrato nell'esempio seguente. **Importante** Assicurati che l'invocazione della funzione fittizia non produca effetti collaterali indesiderati, come l'avvio di transazioni commerciali. **Example** ``` public class Function { public Function() { Amazon.Lambda.Core.SnapshotRestore.RegisterBeforeSnapshot(FunctionWarmup); } // Warmup method that calls the function handler before snapshot to warm up the .NET code and runtime. // This speeds up future cold starts after restoring from a snapshot. private async ValueTask FunctionWarmup() { var request = new APIGatewayProxyRequest { Path = "/heathcheck", HttpMethod = "GET" }; for (var i = 0; i < 10; i++) { await FunctionHandler(request, null); } } public async Task FunctionHandler(APIGatewayProxyRequest request, ILambdaContext context) { // // Process HTTP request // var response = new APIGatewayProxyResponse { StatusCode = 200 }; return await Task.FromResult(response); } } ``` ## Best practice per la rete Lo stato delle connessioni che la funzione stabilisce durante la fase di inizializzazione non è garantito quando Lambda riprende la funzione da uno snapshot. Nella maggior parte dei casi, le connessioni di rete stabilite da un AWS SDK riprendono automaticamente. Per altre connessioni, consigliamo le seguenti best practice. **Ristabilire le connessioni di rete** Ristabilisci sempre le connessioni di rete quando la funzione riprende da uno snapshot. Si consiglia di ristabilire le connessioni di rete nel gestore delle funzioni. In alternativa, puoi usare un [hook di runtime](snapstart-runtime-hooks.md) dopo il ripristino. **Non utilizzare hostname come identificatore univoco dell'ambiente di esecuzione** Si consiglia di non utilizzare `hostname` per identificare l'ambiente di esecuzione come nodo o container univoco nelle applicazioni. Con SnapStart, una singola istantanea viene utilizzata come stato iniziale per più ambienti di esecuzione. Tutti gli ambienti di esecuzione restituiscono lo stesso valore `hostname` per `InetAddress.getLocalHost()` (Java), `socket.gethostname()` (Python) e `Dns.GetHostName()` (.NET). Per le applicazioni che richiedono un'identità dell'ambiente di esecuzione o un valore `hostname` univoco, si consiglia di generare un ID univoco nel gestore della funzione. Oppure, utilizza un [hook di runtime](snapstart-runtime-hooks.md) dopo il ripristino per generare un ID univoco, quindi utilizza l'ID univoco come identificatore per l'ambiente di esecuzione. **Evitare di collegare connessioni a porte di origine fisse** Si consiglia di evitare di associare le connessioni di rete a porte di origine fisse. Le connessioni vengono ristabilite quando una funzione riprende da uno snapshot e le connessioni di rete legate a una porta di origine fissa potrebbero non riuscire. **Evitare di usare la cache DNS Java** Le funzioni Lambda memorizzano già nella cache le risposte DNS. Se si utilizza un'altra cache DNS con SnapStart, è possibile che si verifichino dei timeout di connessione quando la funzione riprende da un'istantanea. La classe `java.util.logging.Logger` può abilitare indirettamente la cache DNS JVM. Per sovrascrivere le impostazioni predefinite, imposta [networkaddress.cache.ttl](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/net/InetAddress.html#inetaddress-caching-heading) su 0 prima dell'inizializzazione di `logger`. Esempio: ``` public class MyHandler { // first set TTL property static{ java.security.Security.setProperty("networkaddress.cache.ttl" , "0"); } // then instantiate logger var logger = org.apache.logging.log4j.LogManager.getLogger(MyHandler.class); } ``` Per evitare errori `UnknownHostException` nel runtime di Java 11, si consiglia di impostare `networkaddress.cache.negative.ttl` su 0. Nei runtime di Java 17 e successivi, questa operazione non è necessaria. È possibile impostare questa proprietà per una funzione Lambda con la variabile di ambiente `AWS_LAMBDA_JAVA_NETWORKADDRESS_CACHE_NEGATIVE_TTL=0`. La disabilitazione della cache DNS JVM non disabilita la cache DNS gestita da Lambda. # Risoluzione degli SnapStart errori per le funzioni Lambda Questa pagina affronta i problemi più comuni che si verificano durante l'utilizzo di Lambda SnapStart, inclusi errori di creazione di snapshot, errori di timeout ed errori interni del servizio. ## SnapStartNotReadyException **Errore:** si è verificato un errore (SnapStartNotReadyException) durante la chiamata all'operazione Invoke20150331: Lambda sta inizializzando la funzione. Sarà pronta per essere richiamata una volta che lo stato della funzione diventerà ATTIVO. ### Cause comuni Questo errore si verifica quando si prova a richiamare una versione della funzione che si trova nello [stato `Inactive`](snapstart-activate.md#snapstart-function-states). La versione della funzione diventa `Inactive` quando non viene richiamata per 14 giorni o quando Lambda riavvia periodicamente l'ambiente di esecuzione ### Risoluzione Attendi che la versione della funzione raggiunga lo stato `Active`, quindi richiamala di nuovo. ## SnapStartTimeoutException **Problema:** viene visualizzato un messaggio `SnapStartTimeoutException` quando si tenta di richiamare la versione di una funzione. SnapStart ### Cause comuni Durante la fase di [ripristino](lambda-runtime-environment.md#runtimes-lifecycle-restore), Lambda ripristina il runtime Java ed esegue qualsiasi [hook di runtime](snapstart-runtime-hooks.md) successivo al ripristino. Se un hook di runtime post-ripristino viene eseguito per più di 10 secondi, la fase `Restore` scade e viene visualizzato un errore quando si prova a richiamare la funzione. I problemi relativi alla connessione di rete e alle credenziali possono anche causare un timeout per la fase `Restore`. ### Risoluzione [Controlla i CloudWatch registri della funzione per verificare la presenza di errori di timeout verificatisi durante la fase di ripristino.](lambda-runtime-environment.md#runtimes-lifecycle-restore) Assicurati che tutti gli hook post-ripristino vengano completati in meno di 10 secondi. **Example CloudWatch registro** ``` { "cause": "Lambda couldn't restore the snapshot within the timeout limit. (Service: Lambda, Status Code: 408, Request ID: 11a222c3-410f-427c-ab22-931d6bcbf4f2)", "error": "Lambda.SnapStartTimeoutException"} ``` ## Errore interno del servizio 500 **Errore:** Lambda non è riuscito a creare un nuovo snapshot perché è stato raggiunto il limite di creazione simultanea di snapshot. ### Cause comuni Un errore 500 è un errore interno al servizio Lambda stesso e non un problema relativo alla funzione o al codice. Questi errori sono spesso intermittenti. ### Risoluzione Prova a pubblicare nuovamente la versione della funzione. ## 401 - Autorizzazione negata **Errore:** token di sessione o chiave di intestazione errati ### Cause comuni Questo errore si verifica quando si utilizza l'[archivio AWS Systems Manager dei parametri e Gestione dei segreti AWS l'estensione](with-secrets-manager.md) con SnapStart Lambda. ### Risoluzione Il AWS Systems Manager Parameter Store e Gestione dei segreti AWS l'estensione non sono compatibili con SnapStart. L'estensione genera credenziali con cui comunicare Gestione dei segreti AWS durante l'inizializzazione della funzione, il che causa errori di credenziali scadute se utilizzata con. SnapStart ## UnknownHostException (Java) **Errore:** impossibile eseguire la richiesta HTTP: il certificato per `abc.us-east-1.amazonaws.com` non corrisponde a nessuno dei nomi alternativi del soggetto. ### Cause comuni Le funzioni Lambda memorizzano già nella cache le risposte DNS. Se si utilizza un'altra cache DNS con SnapStart, è possibile che si verifichino dei timeout di connessione quando la funzione riprende da un'istantanea. ### Risoluzione Per evitare errori `UnknownHostException` nel runtime di Java 11, si consiglia di impostare `networkaddress.cache.negative.ttl` su 0. Nei runtime di Java 17 e successivi, questa operazione non è necessaria. È possibile impostare questa proprietà per una funzione Lambda con la variabile di ambiente `AWS_LAMBDA_JAVA_NETWORKADDRESS_CACHE_NEGATIVE_TTL=0`. ## Errori di creazione snapshot **Errore: AWS Lambda impossibile richiamare** la funzione. SnapStart Se l'errore persiste, controlla i CloudWatch log della funzione per verificare la presenza di errori di inizializzazione. ### Risoluzione [Controlla i CloudWatch log Amazon della tua funzione per verificare i timeout degli hook di runtime prima di checkpoint.](snapstart-runtime-hooks.md) Puoi anche provare a pubblicare una nuova versione della funzione, che a volte può risolvere il problema. ## Frequenza di creazione degli snapshot **Problema:** quando si pubblica una nuova versione della funzione, la funzione rimane nello [stato](snapstart-activate.md#snapstart-function-states) `Pending` per un lungo periodo. ### Cause comuni Quando Lambda crea uno snapshot, il codice di inizializzazione può essere eseguito per un massimo di 15 minuti. Il limite di tempo è 130 secondi o il [timeout della funzione configurato](configuration-timeout.md) (massimo 900 secondi), a seconda di quale dei due valori sia più elevato. Se la funzione è [collegata a un VPC](configuration-vpc.md#configuration-vpc-attaching), Lambda potrebbe anche dover creare interfacce di rete prima che la funzione diventi `Active`. Se provi a richiamare la versione della funzione mentre la funzione è `Pending`, potresti ottenere un `ResourceConflictException` 409. Se la funzione viene richiamata utilizzando un endpoint Gateway Amazon API, potresti ricevere un errore 500 in API Gateway. ### Risoluzione Attendi almeno 15 minuti per l'inizializzazione della versione della funzione prima di richiamarla.