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

# Personalizzazione al livello di edge con Lambda@Edge
<a name="lambda-at-the-edge"></a>

Lambda @Edge è un'estensione di. AWS Lambda Lambda @Edge è un servizio di elaborazione che consente di eseguire funzioni che personalizzano i contenuti forniti da Amazon. CloudFront Puoi creare funzioni Node.js o Python nella console Lambda in una Regione AWS, Stati Uniti orientali (Virginia settentrionale).

Dopo aver creato la funzione, puoi aggiungere i trigger utilizzando la console CloudFront o la console Lambda in modo che le funzioni vengano eseguite AWS in posizioni più vicine al visualizzatore, senza effettuare il provisioning o gestire i server. Facoltativamente, puoi utilizzare le operazioni Lambda CloudFront e API per configurare funzioni e trigger a livello di codice.

Lambda@Edge è in grado di adattare automaticamente la capacità, da alcune richieste al giorno fino a migliaia di richieste al secondo. L'elaborazione delle richieste in AWS posizioni più vicine al visualizzatore anziché sui server di origine riduce significativamente la latenza e migliora l'esperienza dell'utente.

**Nota**  
Lambda@Edge non è supportata con le richieste gRPC. Per ulteriori informazioni, consulta [Usare gRPC con le distribuzioni CloudFront](distribution-using-grpc.md).

**Topics**
+ [Come funziona Lambda@Edge con richieste e risposte](lambda-edge-event-request-response.md)
+ [Modi per usare Lambda@Edge](lambda-edge-ways-to-use.md)
+ [Nozioni di base sulle funzioni Lambda@Edge (console)](lambda-edge-how-it-works.md)
+ [Configurazione di ruoli e autorizzazioni IAM per Lambda@Edge](lambda-edge-permissions.md)
+ [Scrivere e creare una funzione Lambda@Edge](lambda-edge-create-function.md)
+ [Aggiunta di trigger per una funzione Lambda@Edge](lambda-edge-add-triggers.md)
+ [Test e debug delle funzioni Lambda@Edge](lambda-edge-testing-debugging.md)
+ [Eliminazione delle funzioni e delle repliche Lambda@Edge](lambda-edge-delete-replicas.md)
+ [Struttura dell'evento Lambda@Edge](lambda-event-structure.md)
+ [Utilizzo di richieste e risposte](lambda-generating-http-responses.md)
+ [Esempi di funzioni Lambda@Edge](lambda-examples.md)

# Come funziona Lambda@Edge con richieste e risposte
<a name="lambda-edge-event-request-response"></a>

Quando associ una CloudFront distribuzione a una funzione Lambda @Edge, CloudFront intercetta le richieste e le risposte nelle edge location. CloudFront È possibile eseguire funzioni Lambda quando si verificano i seguenti CloudFront eventi:
+ Quando CloudFront riceve una richiesta da un visualizzatore (richiesta del visualizzatore)
+ Prima CloudFront inoltra una richiesta all'origine (richiesta di origine)
+ Quando CloudFront riceve una risposta dall'origine (origin response)
+ Before CloudFront restituisce la risposta allo spettatore (risposta del visualizzatore)

Se si utilizza AWS WAF, la richiesta del visualizzatore Lambda @Edge viene eseguita dopo l'applicazione di qualsiasi AWS WAF regola.

Per ulteriori informazioni, consultare [Utilizzo di richieste e risposte](lambda-generating-http-responses.md) e [Struttura dell'evento Lambda@Edge](lambda-event-structure.md).

# Modi per usare Lambda@Edge
<a name="lambda-edge-ways-to-use"></a>

L'elaborazione di Lambda @Edge con la tua CloudFront distribuzione Amazon può essere utilizzata in molti modi, come i seguenti esempi:
+ Una funzione Lambda può ispezionare i cookie e riscriverli URLs in modo che gli utenti visualizzino diverse versioni di un sito per i test. A/B 
+ CloudFront può restituire oggetti diversi agli spettatori in base al dispositivo che stanno utilizzando controllando l'`User-Agent`intestazione, che include informazioni sui dispositivi. Ad esempio, CloudFront possono restituire immagini diverse in base alle dimensioni dello schermo del dispositivo. Allo stesso modo, la funzione potrebbe considerare il valore dell'`Referer`intestazione e CloudFront far sì che le immagini vengano restituite ai bot con la risoluzione più bassa disponibile. 
+ In alternativa, puoi controllare i cookie per altri criteri. Ad esempio, su un sito Web di vendita al dettaglio che vende abbigliamento, se si utilizzano i cookie per indicare il colore scelto dall'utente per una giacca, una funzione Lambda può modificare la richiesta in CloudFront modo da restituire l'immagine di una giacca nel colore selezionato.
+ Una funzione Lambda può generare risposte HTTP quando si verificano eventi di richiesta del CloudFront visualizzatore o di richiesta di origine.
+ Una funzione può controllare le intestazioni o i token di autorizzazione e inserire un'intestazione per controllare l'accesso ai contenuti prima di CloudFront inoltrare la richiesta all'origine.
+ Una funzione Lambda può anche effettuare chiamate di rete a risorse esterne per verificare le credenziali utente o recuperare ulteriore contenuto per personalizzare una risposta.

Per ulteriori informazioni, incluso codice di esempio, consulta [Esempi di funzioni Lambda@Edge](lambda-examples.md).

Per ulteriori informazioni sulla configurazione di Lambda@Edge nella console, consulta [Tutorial: creazione di una funzione Lambda@Edge di base (console)](lambda-edge-how-it-works-tutorial.md).

# Nozioni di base sulle funzioni Lambda@Edge (console)
<a name="lambda-edge-how-it-works"></a>

Con Lambda @Edge, puoi usare i CloudFront trigger per richiamare una funzione Lambda. Quando associ una CloudFront distribuzione a una funzione Lambda, CloudFront [intercetta le richieste e le risposte nelle posizioni CloudFront periferiche ed](https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html) esegue la funzione. Le funzioni Lambda possono migliorare la sicurezza o personalizzare le informazioni vicine ai visualizzatori per migliorare le prestazioni.

L'elenco seguente fornisce una panoramica di base su come creare e utilizzare le funzioni Lambda con. CloudFront

**Panoramica: creazione e utilizzo di funzioni Lambda con CloudFront**

1. Crea una funzione Lambda nella Regione Stati Uniti orientali (Virginia settentrionale).

1. Salvare e pubblicare una versione numerata della funzione.

   Per apportare modifiche alla funzione è necessario modificare la versione \$1LATEST della funzione nella regione Stati Uniti orientali (N. Virginia). Quindi, prima di configurarlo per funzionare CloudFront, pubblicate una nuova versione numerata.

1. Associate la funzione a un comportamento CloudFront di distribuzione e cache. Specificate quindi uno o più CloudFront eventi (*trigger*) che causano l'esecuzione della funzione. Ad esempio, è possibile creare un trigger per l'esecuzione della funzione quando CloudFront riceve una richiesta da un visualizzatore.

1. Quando si crea un trigger, Lambda crea repliche della funzione nelle posizioni AWS in tutto il mondo.

**Suggerimento**  
Per ulteriori informazioni, consultate [la creazione e l'aggiornamento delle funzioni](lambda-edge-create-function.md), [la struttura degli eventi](lambda-event-structure.md) e [l'aggiunta di CloudFront trigger](lambda-edge-add-triggers.md). Puoi inoltre trovare ulteriori idee e ottenere esempi di codice in [Esempi di funzioni Lambda@Edge](lambda-examples.md).

Per un step-by-step tutorial, consultate il seguente argomento:

**Topics**
+ [Tutorial: creazione di una funzione Lambda@Edge di base (console)](lambda-edge-how-it-works-tutorial.md)

# Tutorial: creazione di una funzione Lambda@Edge di base (console)
<a name="lambda-edge-how-it-works-tutorial"></a>

Questo tutorial mostra come iniziare a usare Lambda @Edge creando e configurando una funzione Node.js di esempio che viene eseguita in. CloudFront Questo esempio aggiunge intestazioni di sicurezza HTTP a una risposta quando CloudFront recupera un file. Questo può migliorare la sicurezza e la privacy di un sito web.

Per questo tutorial non è necessario avere un proprio sito web. Tuttavia, quando scegli di creare una soluzione Lambda@Edge, segui passaggi simili e scegli tra le stesse opzioni.

**Topics**
+ [Passaggio 1: iscriviti a Account AWS](#lambda-edge-how-it-works-tutorial-AWS)
+ [Fase 2: Creare una CloudFront distribuzione](#lambda-edge-how-it-works-tutorial-cloudfront)
+ [Fase 3: creare la tua funzione](#lambda-edge-how-it-works-tutorial-create-function)
+ [Fase 4: Aggiungere un CloudFront trigger per eseguire la funzione](#lambda-edge-how-it-works-tutorial-add-trigger)
+ [Fase 5: verificare che la funzione venga eseguita](#lambda-edge-how-it-works-tutorial-verify)
+ [Fase 6: risolvere i problemi](#lambda-edge-how-it-works-tutorial-troubleshoot)
+ [Fase 7: eliminare le risorse di esempio](#lambda-edge-how-it-works-tutorial-cleanup-resources)
+ [Informazioni correlate](#lambda-edge-how-it-works-tutorial-resources)

## Passaggio 1: iscriviti a Account AWS
<a name="lambda-edge-how-it-works-tutorial-AWS"></a>

Se non l’hai ancora fatto, registrati per ottenere un Account AWS. Per ulteriori informazioni, consulta [Registrati per un Account AWS](setting-up-cloudfront.md#sign-up-for-aws).

## Fase 2: Creare una CloudFront distribuzione
<a name="lambda-edge-how-it-works-tutorial-cloudfront"></a>

Prima di creare la funzione di esempio Lambda @Edge, è necessario disporre di un CloudFront ambiente con cui lavorare che includa un'origine da cui distribuire il contenuto.

Per questo esempio, crei una CloudFront distribuzione che utilizza un bucket Amazon S3 come origine per la distribuzione. Se disponi già di un ambiente da utilizzare, puoi saltare questa fase.<a name="lambda-edge-how-it-works-tutorial-cf-proc"></a>

**Per creare una CloudFront distribuzione con un'origine Amazon S3**

1. Crea un bucket Amazon S3 con un file o due, ad esempio file di immagini, come contenuti di esempio. Se hai bisogno di aiuto, puoi procedere come descritto in [Caricamento dei contenuti su Amazon S3](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.html#GettingStartedUploadContent). Assicurati di impostare le autorizzazioni per assegnare l'accesso pubblico in lettura agli oggetti nel bucket.

1. Crea una CloudFront distribuzione e aggiungi il tuo bucket S3 come origine, seguendo i passaggi in [Creare una CloudFront ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.html#GettingStartedCreateDistribution) distribuzione web. Se disponi già di una distribuzione, puoi aggiungere il bucket come origine di quella distribuzione.
**Suggerimento**  
Annota l'ID della tua distribuzione. Più avanti in questo tutorial, quando aggiungi un CloudFront trigger per la tua funzione, devi scegliere l'ID per la tua distribuzione in un elenco a discesa, ad esempio. `E653W22221KDDL`

## Fase 3: creare la tua funzione
<a name="lambda-edge-how-it-works-tutorial-create-function"></a>

In questa fase, devi creare una funzione Lambda, a partire da un modello blueprint nella console Lambda. La funzione aggiunge il codice per aggiornare le intestazioni di sicurezza nella tua distribuzione CloudFront. <a name="lambda-edge-how-it-works-tutorial-create-function-blueprint-proc"></a>

**Come creare una funzione Lambda**

1. Accedi a Console di gestione AWS e apri la console all' AWS Lambda indirizzo. [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/)
**Importante**  
**Assicurati di trovarti negli Stati Uniti orientali 1 (**Virginia settentrionale) ( Regione AWS us-east-1).**** È necessario essere in questa regione per creare funzioni Lambda@Edge.

1. Selezionare **Create function (Crea funzione)**.

1. Nella pagina **Crea funzione**, scegli **Usa un blueprint, quindi filtra i blueprint** inserendoli nel campo di CloudFront ricerca. **cloudfront**
**Nota**  
CloudFront **i blueprint sono disponibili solo nella **regione US-east-1 (Virginia settentrionale) (us-east-1).****

1. Scegli il blueprint **Modifica intestazione risposta HTTP** come modello per la funzione.

1. Immettere le seguenti informazioni sulla funzione:
   + **Nome funzione**: immetti un nome per la funzione.
   + **Ruolo di esecuzione**: scegli come impostare le autorizzazioni per la funzione. Per utilizzare il modello di policy di autorizzazione di base consigliato da Lambda @Edge, scegli **Crea un nuovo ruolo dai AWS ** modelli di policy.
   + **Nome ruolo**: immetti un nome per il ruolo creato dal modello di policy.
   + **Modelli di policy**: Lambda aggiunge automaticamente i **permessi del modello di policy Basic Lambda @Edge** perché hai scelto un CloudFront blueprint come base per la tua funzione. Questo modello di policy aggiunge le autorizzazioni per i ruoli di esecuzione che consentono di CloudFront eseguire la funzione Lambda per te CloudFront in diverse località del mondo. Per ulteriori informazioni, consulta [Configurazione di ruoli e autorizzazioni IAM per Lambda@Edge](lambda-edge-permissions.md).

1. Scegli **Crea funzione** nella parte inferiore della pagina.

1. Nel riquadro **Implementa in Lambda@Edge** visualizzato, scegli **Annulla**. Per questo tutorial, devi modificare il codice della funzione prima di implementarla in Lambda@Edge.

1. Scorri fino alla sezione **Origine del codice** della pagina.

1. Sostituire il codice modello con una funzione che modifica le intestazioni di sicurezza restituite dall'origine. Ad esempio, puoi usare un codice simile a quanto segue:

   ```
   'use strict';
   export const handler = (event, context, callback) => {
   
       //Get contents of response
       const response = event.Records[0].cf.response;
       const headers = response.headers;
   
       //Set new headers
       headers['strict-transport-security'] = [{key: 'Strict-Transport-Security', value: 'max-age= 63072000; includeSubdomains; preload'}];
       headers['content-security-policy'] = [{key: 'Content-Security-Policy', value: "default-src 'none'; img-src 'self'; script-src 'self'; style-src 'self'; object-src 'none'"}];
       headers['x-content-type-options'] = [{key: 'X-Content-Type-Options', value: 'nosniff'}];
       headers['x-frame-options'] = [{key: 'X-Frame-Options', value: 'DENY'}];
       headers['x-xss-protection'] = [{key: 'X-XSS-Protection', value: '1; mode=block'}];
       headers['referrer-policy'] = [{key: 'Referrer-Policy', value: 'same-origin'}];
   
       //Return modified response
       callback(null, response);
   };
   ```

1. Scegli **File**, **Salva** per salvare il codice aggiornato.

1. Seleziona **Implementa**.

Passa alla sezione successiva per aggiungere un CloudFront trigger per eseguire la funzione.

## Fase 4: Aggiungere un CloudFront trigger per eseguire la funzione
<a name="lambda-edge-how-it-works-tutorial-add-trigger"></a>

Ora che hai una funzione Lambda per aggiornare le intestazioni di sicurezza, configura il CloudFront trigger per eseguire la funzione per aggiungere le intestazioni in qualsiasi risposta CloudFront ricevuta dall'origine per la tua distribuzione.<a name="lambda-edge-how-it-works-tutorial-add-trigger-proc"></a>

**Per configurare il CloudFront trigger per la tua funzione**

1. Nella console Lambda, nella pagina **Panoramica della funzione** relativa alla funzione desiderata, scegli **Aggiungi trigger**.

1. Per la **configurazione di Trigger**, scegli **CloudFront**.

1. Scegli **Implementa in Lambda@Edge**.

1. Nel riquadro **Deploy to Lambda** @Edge, **in CloudFront Configura** trigger, inserisci le seguenti informazioni:
   + **Distribuzione**: l'ID di CloudFront distribuzione da associare alla funzione. Nell’elenco a discesa, scegli l’ID della distribuzione.
   + **Comportamento cache**: il comportamento cache da utilizzare con il trigger. Per questo esempio, lascia il valore impostato su **\$1**, che applica a tutte le richieste il comportamento cache predefinito della distribuzione. Per ulteriori informazioni, consulta [Cache Behavior Settings (Impostazioni del comportamento della cache)](DownloadDistValuesCacheBehavior.md) nell'argomento [Riferimento a tutte le impostazioni di distribuzione](distribution-web-values-specify.md).
   + **CloudFront evento**: il trigger che specifica quando viene eseguita la funzione. Vogliamo che la funzione security headers venga eseguita ogni volta che CloudFront restituisce una risposta dall'origine. Nell’elenco a discesa, scegli **Risposta origine**. Per ulteriori informazioni, consulta [Aggiunta di trigger per una funzione Lambda@Edge](lambda-edge-add-triggers.md).

1. Seleziona la casella di controllo **Conferma implementazione in Lambda@Edge**.

1. Scegli **Deploy** per aggiungere il trigger e replicare la funzione in sedi in tutto il mondo. AWS 

1. Attendi che la funzione venga replicata. Questo richiede in genere diversi minuti.

    È possibile controllare se la replica è terminata [accedendo alla console CloudFront](https://console.aws.amazon.com/cloudfront/v4/home) e visualizzando la distribuzione: Attendi che lo stato di distribuzione cambi da **Implementazione in corso** a una data e un’ora, il che significa che la funzione è stata replicata. Quindi segui la procedura nella sezione successiva per verificare che la funzione sia attiva.

## Fase 5: verificare che la funzione venga eseguita
<a name="lambda-edge-how-it-works-tutorial-verify"></a>

Ora che hai creato la funzione Lambda e configurato un trigger per eseguirla per una CloudFront distribuzione, assicurati che la funzione stia ottenendo ciò che ti aspetti. In questo esempio, controlliamo le intestazioni HTTP restituite da CloudFront, per assicurarci che vengano aggiunte le intestazioni di sicurezza.<a name="lambda-edge-how-it-works-tutorial-verify-proc"></a>

**Per verificare che la funzione Lambda@Edge aggiunga le intestazioni di sicurezza**

1. In un browser, digita l'URL di un file del tuo S3 bucket. Ad esempio, puoi usare un URL simile a `https://d111111abcdef8.cloudfront.net/image.jpg`.

   Per ulteriori informazioni sul nome di CloudFront dominio da utilizzare nell'URL del file, consulta. [Personalizza il formato URL per i file in CloudFront](LinkFormat.md)

1. Apri la barra degli strumenti per sviluppatori del tuo browser Web. Ad esempio, nella finestra del browser in Chrome, apri il menu contestuale (pulsante destro del mouse) e scegli **Inspect (Ispeziona)**.

1. Scegliere la scheda **Network (Rete)**.

1. Ricarica la pagina per visualizzare l'immagine e quindi scegli una richiesta HTTP nel riquadro a sinistra. Vedrai le intestazioni HTTP visualizzate in un riquadro separato.

1. Scorri l'elenco delle intestazioni HTTP per verificare che le intestazioni di sicurezza previste vi siano incluse. Ad esempio, potresti vedere intestazioni simili a quelle mostrate nella schermata seguente:  
![\[Elenco di intestazioni HTTP con le intestazioni di sicurezza previste evidenziate.\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/images/lambda-at-edge-security-headers-list.png)

Se le intestazioni di sicurezza sono incluse nel tuo elenco di intestazioni, è perfetto: hai creato la tua prima funzione Lambda@Edge. Se CloudFront restituisce errori o se ci sono altri problemi, continua con il passaggio successivo per risolverli.

## Fase 6: risolvere i problemi
<a name="lambda-edge-how-it-works-tutorial-troubleshoot"></a>

Se CloudFront restituisce errori o non aggiunge le intestazioni di sicurezza come previsto, puoi esaminare l'esecuzione della funzione esaminando Logs. CloudWatch Assicurati di utilizzare i log archiviati nella posizione più vicina alla AWS posizione in cui viene eseguita la funzione.

Ad esempio, se visualizzi il file da Londra, prova a cambiare la regione nella CloudWatch console in Europa (Londra).<a name="lambda-edge-how-it-works-tutorial-cloudwatch-proc"></a>

**Per esaminare CloudWatch i log per la tua funzione Lambda @Edge**

1. Accedi a Console di gestione AWS e apri la CloudWatch console all'indirizzo. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)

1. Cambia **regione** nella posizione visualizzata quando visualizzi il file nel browser. Questo è dove la funzione è in esecuzione.

1. Nel riquadro sinistro, scegli **Logs (Log)** per visualizzare i log per la tua distribuzione. 

Per ulteriori informazioni, consulta [Monitora le CloudFront metriche con Amazon CloudWatch](monitoring-using-cloudwatch.md).

## Fase 7: eliminare le risorse di esempio
<a name="lambda-edge-how-it-works-tutorial-cleanup-resources"></a>

Se hai creato un bucket Amazon S3 e una CloudFront distribuzione solo per questo tutorial, elimina le AWS risorse che hai allocato in modo da non addebitare più costi. Dopo aver eliminato le AWS risorse, i contenuti aggiunti non sono più disponibili.

**Attività**
+ [Elimina il bucket S3](#lambda-edge-how-it-works-tutorial-delete-bucket) 
+ [Eliminazione della funzione Lambda](#lambda-edge-how-it-works-tutorial-delete-function)
+ [Eliminare la distribuzione CloudFront](#lambda-edge-how-it-works-tutorial-delete-distribution)

### Elimina il bucket S3
<a name="lambda-edge-how-it-works-tutorial-delete-bucket"></a>

Prima di eliminare il bucket Amazon S3 in uso, accertarsi che le attività di registrazione siano disattivate per quel bucket. Altrimenti, AWS continua a scrivere i log nel bucket mentre lo elimini.<a name="lambda-edge-how-it-works-tutorial-delete-bucket-proc"></a>

**Per disattivare il log per un bucket**

1. Apri la console Amazon S3 all'indirizzo. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)

1. Seleziona il bucket, quindi **Proprietà**.

1. Da **Properties (Proprietà)**, selezionare **Log**.

1. Deseleziona la casella **Attivato**.

1. Scegliere **Save (Salva)**.

È possibile ora eliminare il bucket. Per ulteriori informazioni, consulta [Eliminazione di un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html) nella *Guida per l'utente della console di Amazon Simple Storage Service*.

### Eliminazione della funzione Lambda
<a name="lambda-edge-how-it-works-tutorial-delete-function"></a>

Per istruzioni su come eliminare l’associazione della funzione Lambda e, facoltativamente, la funzione stessa, consulta [Eliminazione delle funzioni e delle repliche Lambda@Edge](lambda-edge-delete-replicas.md).

### Eliminare la distribuzione CloudFront
<a name="lambda-edge-how-it-works-tutorial-delete-distribution"></a>

Prima di eliminare una CloudFront distribuzione, è necessario disattivarla. Una distribuzione disattivata non è più funzionante e non accumula addebiti. Puoi attivare una distribuzione disattivata in qualsiasi momento. Una volta eliminata una distribuzione disattivata, non è più disponibile.<a name="lambda-edge-how-it-works-tutorial-delete-distribution-proc"></a>

**Per disabilitare ed eliminare una CloudFront distribuzione**

1. Apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Selezionare la distribuzione che si vuole disattivare e scegliere **Disable (Disattiva)**.

1. Quando viene richiesta la conferma, seleziona **Sì, disattiva**.

1. Selezionare la distribuzione disattivata e scegliere **Delete (Elimina)**.

1. Quando viene richiesta la conferma, seleziona **Sì, elimina**.

## Informazioni correlate
<a name="lambda-edge-how-it-works-tutorial-resources"></a>

Ora che hai un'idea di come operano le funzioni Lambda@Edge, puoi approfondire i concetti consultando queste risorse:
+ [Esempi di funzioni Lambda@Edge](lambda-examples.md)
+ [Best practice di progettazione Lambda @Edge](https://aws.amazon.com/blogs/networking-and-content-delivery/lambdaedge-design-best-practices/)
+ [Ridurre la latenza e spostare l'elaborazione verso l'edge con Lambda @Edge](https://aws.amazon.com/blogs/networking-and-content-delivery/reducing-latency-and-shifting-compute-to-the-edge-with-lambdaedge/)

# Configurazione di ruoli e autorizzazioni IAM per Lambda@Edge
<a name="lambda-edge-permissions"></a>

Per configurare Lambda@Edge, devi disporre delle seguenti autorizzazioni e ruoli IAM per AWS Lambda: 
+ [Autorizzazioni IAM](#lambda-edge-permissions-required): queste autorizzazioni ti consentono di creare la tua funzione Lambda e associarla alla tua distribuzione. CloudFront 
+ [Un ruolo di esecuzione della funzione Lambda](#lambda-edge-permissions-function-execution) (ruolo IAM): i principali del servizio Lambda assumono questo ruolo per eseguire la funzione.
+ [Ruoli collegati ai servizi per Lambda @Edge: i ruoli](#using-service-linked-roles-lambda-edge) collegati ai servizi consentono a specifiche funzioni Lambda di Servizi AWS replicare e abilitare l'utilizzo di file di registro. Regioni AWS CloudWatch CloudFront 

## Autorizzazioni IAM necessarie per associare le funzioni Lambda @Edge alle distribuzioni CloudFront
<a name="lambda-edge-permissions-required"></a>

Oltre alle autorizzazioni IAM necessarie per Lambda, sono necessarie le seguenti autorizzazioni per associare le funzioni Lambda alle distribuzioni: CloudFront 
+ `lambda:GetFunction`: concede l’autorizzazione per ottenere informazioni di configurazione relative alla funzione Lambda e un URL pre-firmato per scaricare un file `.zip` contenente la funzione.
+ `lambda:EnableReplication*`: concede l’autorizzazione alla policy delle risorse in modo che il servizio di replica Lambda possa ottenere il codice e la configurazione della funzione.
+ `lambda:DisableReplication*`: concede l’autorizzazione alla policy delle risorse in modo che il servizio di replica Lambda possa eliminare la funzione.
**Importante**  
È necessario aggiungere l’asterisco (`*`) alla fine delle azioni `lambda:EnableReplication*` e `lambda:DisableReplication*`.
+ Per la risorsa, specificate l'ARN della versione della funzione che desiderate eseguire quando si verifica un CloudFront evento, come nell'esempio seguente:

  `arn:aws:lambda:us-east-1:123456789012:function:TestFunction:2`
+ `iam:CreateServiceLinkedRole`— Concede l'autorizzazione a creare un ruolo collegato al servizio che Lambda @Edge utilizza per replicare le funzioni Lambda. CloudFront Dopo aver configurato Lambda@Edge per la prima volta, il ruolo collegato al servizio viene creato automaticamente. Non è necessario aggiungere questa autorizzazione ad altre distribuzioni che utilizzano Lambda@Edge.

  
+ `cloudfront:UpdateDistribution` o `cloudfront:CreateDistribution`: concede l’autorizzazione per aggiornare o creare una distribuzione.

Per ulteriori informazioni, consulta i seguenti argomenti:
+ [Identity and Access Management per Amazon CloudFront](security-iam.md)
+ [Autorizzazioni di accesso alle risorse Lambda](https://docs.aws.amazon.com/lambda/latest/dg/intro-permission-model.html#lambda-intro-execution-role) nella *Guida per gli sviluppatori di AWS Lambda *

## Ruolo di esecuzione della funzione per i principali del servizio
<a name="lambda-edge-permissions-function-execution"></a>

È necessario creare un ruolo IAM che può essere assunto dai principali servizi `lambda.amazonaws.com` e `edgelambda.amazonaws.com` quando eseguono la funzione. 

**Suggerimento**  
Quando crei la tua funzione nella console Lambda, puoi scegliere di creare un nuovo ruolo di esecuzione utilizzando un modello di AWS policy. Questa fase aggiunge *automaticamente* le autorizzazioni Lambda@Edge richieste per eseguire la funzione. Consulta [Fase 5 del tutorial: creazione di una semplice funzione Lambda@Edge](lambda-edge-how-it-works-tutorial.md#lambda-edge-how-it-works-tutorial-create-function).

Per ulteriori informazioni sulla creazione manuale di un ruolo IAM, consulta [Creazione di ruoli e collegamento di policy (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) nella *Guida per l’utente IAM*.

**Example Esempio: policy di attendibilità del ruolo**  
Puoi aggiungere questo ruolo nella scheda **Relazioni di attendibilità** nella console IAM. Non aggiungere questa policy nella scheda **Autorizzazioni**.    
****  

```
{
   "Version":"2012-10-17",		 	 	 
   "Statement": [
      {
         "Effect": "Allow",
         "Principal": {
            "Service": [
               "lambda.amazonaws.com",
               "edgelambda.amazonaws.com"
            ]
         },
         "Action": "sts:AssumeRole"
      }
   ]
}
```

Per ulteriori informazioni sulle autorizzazioni da concedere al ruolo di esecuzione, consulta [Autorizzazioni di accesso alle risorse Lambda](https://docs.aws.amazon.com/lambda/latest/dg/intro-permission-model.html#lambda-intro-execution-role) nella *Guida per gli sviluppatori di AWS Lambda *.

**Note**  
Per impostazione predefinita, ogni volta che un CloudFront evento attiva una funzione Lambda, i dati vengono scritti CloudWatch nei log. Se si desidera utilizzare questi registri, il ruolo di esecuzione richiede l'autorizzazione per scrivere dati nei registri. CloudWatch Puoi utilizzare il ruolo AWSLambdaBasicExecutionRole predefinito per concedere l’autorizzazione al ruolo di esecuzione.  
Per ulteriori informazioni sui CloudWatch registri, vedere. [Registri delle funzioni Edge](edge-functions-logs.md)
Se il codice della funzione Lambda accede ad altre AWS risorse, ad esempio la lettura di un oggetto da un bucket S3, il ruolo di esecuzione necessita dell'autorizzazione per eseguire quell'azione. 

## Ruoli collegati ai servizi per Lambda@Edge
<a name="using-service-linked-roles-lambda-edge"></a>

Lambda@Edge usa un [ruolo collegato al servizio](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) IAM. Un ruolo collegato ai servizi è un tipo univoco di ruolo IAM collegato direttamente a un servizio. I ruoli collegati ai servizi sono definiti automaticamente dal servizio stesso e includono tutte le autorizzazioni richieste dal servizio per eseguire chiamate agli altri servizi AWS per tuo conto.

Lambda@Edge usa i seguenti ruoli collegati al servizio IAM:
+ **AWSServiceRoleForLambdaReplicator**: Lambda@Edge utilizza questo ruolo per consentire a Lambda@Edge di replicare funzioni su Regioni AWS.

  Quando aggiungi per la prima volta un trigger Lambda @Edge CloudFront, AWSServiceRoleForLambdaReplicator viene creato automaticamente un ruolo denominato per consentire a Lambda @Edge di replicare le funzioni. Regioni AWS Tale ruolo è obbligatorio per utilizzare le funzioni Lambda@Edge. L’aspetto dell’ARN per il ruolo AWSServiceRoleForLambdaReplicator è simile a quello dell’esempio seguente:

  `arn:aws:iam::123456789012:role/aws-service-role/replicator.lambda.amazonaws.com/AWSServiceRoleForLambdaReplicator`
+ **AWSServiceRoleForCloudFrontLogger**— CloudFront utilizza questo ruolo per inviare file di registro in. CloudWatch Puoi utilizzare i file di log per eseguire il debug degli errori di convalida di Lambda@Edge.

  Il AWSServiceRoleForCloudFrontLogger ruolo viene creato automaticamente quando si aggiunge l'associazione di funzioni Lambda @Edge per consentire di inviare i file di CloudFront registro degli errori Lambda @Edge a. CloudWatch L'ARN per il ruolo AWSServiceRoleForCloudFrontLogger avrà il seguente aspetto:

  `arn:aws:iam::account_number:role/aws-service-role/logger.cloudfront.amazonaws.com/AWSServiceRoleForCloudFrontLogger`

Un ruolo collegato ai servizi semplifica la configurazione e l'utilizzo di Lambda@Edge perché non dovrai più aggiungere manualmente le autorizzazioni necessarie. Lambda@Edge definisce le autorizzazioni dei relativi ruoli associati ai servizi e solo Lambda@Edge potrà assumere i propri ruoli. Le autorizzazioni definite includono policy di trust e di autorizzazioni. Le policy di autorizzazioni non possono essere attribuite a nessun'altra entità IAM.

È necessario rimuovere tutte le risorse associate CloudFront o Lambda @Edge prima di poter eliminare un ruolo collegato al servizio. Questo aiuta a proteggere le risorse Lambda@Edge in modo da non rimuovere un ruolo collegato al servizio che è ancora necessario per accedere alle risorse attive.

Per ulteriori informazioni sui ruoli collegati al servizio, consulta [Ruoli collegati ai servizi per CloudFront](security_iam_service-with-iam.md#security_iam_service-with-iam-roles-service-linked). 

### Autorizzazioni del ruolo collegato ai servizi per Lambda@Edge
<a name="slr-permissions-lambda-edge"></a>

Lambda@Edge usa due ruoli collegati ai servizi denominati **AWSServiceRoleForLambdaReplicator** e **AWSServiceRoleForCloudFrontLogger**. Nelle sezioni seguenti vengono descritte le autorizzazioni per ognuno di questi ruoli.

**Contents**
+ [Autorizzazioni del ruolo collegato ai servizi per Lambda Replicator](#slr-permissions-lambda-replicator)
+ [Autorizzazioni relative ai ruoli collegati ai servizi per logger CloudFront](#slr-permissions-cloudfront-logger)

#### Autorizzazioni del ruolo collegato ai servizi per Lambda Replicator
<a name="slr-permissions-lambda-replicator"></a>

Questo ruolo collegato al servizio consente a Lambda di replicare le funzioni Lambda@Edge su Regioni AWS.

Ai fini dell'assunzione del ruolo AWSServiceRoleForLambdaReplicator, il ruolo collegato ai servizi `replicator.lambda.amazonaws.com`considera attendibile il servizio.

La policy delle autorizzazioni del ruolo consente a Lambda@Edge di eseguire le seguenti operazioni sulle risorse specificate:
+ `lambda:CreateFunction` - `arn:aws:lambda:*:*:function:*`
+ `lambda:DeleteFunction` - `arn:aws:lambda:*:*:function:*`
+ `lambda:DisableReplication` - `arn:aws:lambda:*:*:function:*`
+ `iam:PassRole` - `all AWS resources`
+  `cloudfront:ListDistributionsByLambdaFunction` - `all AWS resources`

#### Autorizzazioni relative ai ruoli collegati ai servizi per logger CloudFront
<a name="slr-permissions-cloudfront-logger"></a>

Questo ruolo collegato al servizio consente di CloudFront inviare file di registro in CloudWatch modo da poter eseguire il debug degli errori di convalida Lambda @Edge.

Ai fini dell'assunzione del ruolo AWSServiceRoleForCloudFrontLogger, il ruolo collegato ai servizi `logger.cloudfront.amazonaws.com`considera attendibile il servizio.

La policy delle autorizzazioni del ruolo consente a Lambda@Edge di eseguire le seguenti azioni sulla risorsa `arn:aws:logs:*:*:log-group:/aws/cloudfront/*` specificata:
+ `logs:CreateLogGroup` ``
+ `logs:CreateLogStream`
+ `logs:PutLogEvents`

Per consentire a un'entità IAM (ad esempio un utente, un gruppo o un ruolo) di eliminare ruoli Lambda@Edge collegati ai servizi, devi configurare le autorizzazioni. Per ulteriori informazioni, consulta [Autorizzazioni del ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) nella *Guida per l'utente IAM*.

### Creazione di ruoli collegati ai servizi per Lambda@Edge
<a name="create-slr-lambda-edge"></a>

In genere non si creano manualmente i ruoli collegati ai servizi per Lambda@Edge. Il servizio crea i ruoli automaticamente nei seguenti casi:
+ Quando si crea un trigger per la prima volta, il servizio crea il ruolo AWSServiceRoleForLambdaReplicator (se non esiste già). Questo ruolo consente a Lambda di replicare le funzioni Lambda@Edge su Regioni AWS.

  Se lo elimini, il ruolo collegato ai servizi verrà creato nuovamente quando aggiungi un nuovo trigger per Lambda@Edge in una distribuzione.
+ Quando aggiorni o crei una CloudFront distribuzione con un'associazione Lambda @Edge, il servizio crea il AWSServiceRoleForCloudFrontLogger ruolo (se il ruolo non esiste già). Questo ruolo consente di CloudFront inviare i file di registro a CloudWatch.

  Se elimini il ruolo collegato al servizio, il ruolo verrà creato nuovamente quando aggiorni o crei una CloudFront distribuzione con un'associazione Lambda @Edge.

Per creare manualmente questi ruoli collegati ai servizi, puoi eseguire i seguenti comandi (): AWS Command Line Interface AWS CLI

**Per creare il ruolo AWSServiceRoleForLambdaReplicator**
+ Eseguire il seguente comando seguente.

  ```
  aws iam create-service-linked-role --aws-service-name replicator.lambda.amazonaws.com
  ```

**Per creare il ruolo AWSServiceRoleForCloudFrontLogger**
+ Eseguire il seguente comando seguente.

  ```
  aws iam create-service-linked-role --aws-service-name logger.cloudfront.amazonaws.com
  ```

### Modifica dei ruoli Lambda@Edge collegati ai servizi
<a name="edit-slr-lambda-edge"></a>

Lambda@Edge non consente di modificare i ruoli collegati al servizio AWSServiceRoleForLambdaReplicator o AWSServiceRoleForCloudFrontLogger. Dopo che è stato creato un ruolo collegato al servizio, non puoi modificare il nome del ruolo perché varie entità possono farvi riferimento. Puoi tuttavia utilizzare IAM per modificare la descrizione del ruolo. Per ulteriori informazioni, consulta [Modifica di un ruolo collegato al servizio](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) nella *Guida per l’utente di IAM*.

### Supportato Regioni AWS per i ruoli collegati ai servizi Lambda @Edge
<a name="slr-regions-lambda-edge"></a>

CloudFront supporta l'utilizzo di ruoli collegati ai servizi per Lambda @Edge nei seguenti casi: Regioni AWS
+ Stati Uniti orientali (Virginia settentrionale) – `us-east-1`
+ Stati Uniti orientali (Ohio) – `us-east-2`
+ Stati Uniti occidentali (California settentrionale) – `us-west-1`
+ Stati Uniti occidentali (Oregon) – `us-west-2`
+ Asia Pacifico (Mumbai) – `ap-south-1`
+ Asia Pacifico (Seul) - `ap-northeast-2`
+ Asia Pacifico (Singapore) – `ap-southeast-1`
+ Asia Pacifico (Sydney) - `ap-southeast-2`
+ Asia Pacifico (Tokyo) - `ap-northeast-1`
+ Europe (Francoforte) – `eu-central-1`
+ Europa (Irlanda) – `eu-west-1`
+ Europe (Londra) – `eu-west-2`
+ Sud America (San Paolo) – `sa-east-1`

# Scrivere e creare una funzione Lambda@Edge
<a name="lambda-edge-create-function"></a>

Per usare Lambda@Edge, *scrivi* il codice per la funzione AWS Lambda . Per aiutarti a scrivere funzioni Lambda@Edge, consulta le seguenti risorse:
+  [Struttura dell'evento Lambda@Edge](lambda-event-structure.md): comprendere la struttura degli eventi da utilizzare con Lambda@Edge.
+ [Esempi di funzioni Lambda@Edge](lambda-examples.md)— Funzioni di esempio, come il A/B test e la generazione di un reindirizzamento HTTP.

Il modello di programmazione per l’utilizzo di Node.js o Python con Lambda@Edge corrisponde a quello relativo all’utilizzo di Lambda in una Regione AWS. Per ulteriori informazioni, consulta [Creazione di funzioni Lambda con Node.js](https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html) o [Creazione di funzioni Lambda con Python](https://docs.aws.amazon.com/lambda/latest/dg/lambda-python.html) nella *Guida per gli sviluppatori di AWS Lambda *.

Nella funzione Lambda@Edge, includi il parametro `callback` e restituisci l’oggetto applicabile per gli eventi di richiesta o di risposta:
+ **Eventi di richiesta** - È necessario includere l'oggetto `cf.request` nella risposta.

  Se si sta generando una risposta, includere l'oggetto `cf.response` nella risposta. Per ulteriori informazioni, consulta [Generazione di risposte HTTP in trigger di richiesta](lambda-generating-http-responses.md#lambda-generating-http-responses-in-requests). 
+ **Eventi di risposta** - È necessario includere l'oggetto `cf.response` nella risposta.

Dopo aver scritto il codice personalizzato o aver utilizzato uno degli esempi, crea la funzione in Lambda. Per creare una funzione o modificarne una esistente, consulta i seguenti argomenti:

**Topics**
+ [Creazione di una funzione Lambda@Edge](lambda-edge-create-in-lambda-console.md)
+ [Modifica di una funzione Lambda](lambda-edge-edit-function.md)

 *Dopo aver creato la funzione in Lambda, configuri Lambda per eseguire la funzione in base a CloudFront eventi specifici, chiamati trigger.* Per ulteriori informazioni, consulta [Aggiunta di trigger per una funzione Lambda@Edge](lambda-edge-add-triggers.md).

# Creazione di una funzione Lambda@Edge
<a name="lambda-edge-create-in-lambda-console"></a>

 AWS Lambda Per configurare l'esecuzione di funzioni Lambda basate su CloudFront eventi, segui questa procedura.<a name="lambda-edge-create-function-procedure"></a>

**Per creare una funzione Lambda@Edge**

1. Accedi a Console di gestione AWS e apri la AWS Lambda console all'indirizzo [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/).

1. Se si dispone già di una o più funzioni Lambda, selezionare **Create function (Crea funzione)**.

   Se non si dispone di funzioni, selezionare **Get Started Now (Inizia subito)**.

1. Nell'elenco Regione nella parte superiore della pagina, scegliere **Stati Uniti orientali (Virginia settentrionale)**.

1. Creare una funzione utilizzando il proprio codice o creare una funzione iniziando con un piano CloudFront .
   + Per creare una funzione utilizzando il proprio codice, selezionare **Author from scratch (Crea da zero)**. 
   + **Per visualizzare un elenco di progetti per CloudFront, inserisci **cloudfront** nel campo del filtro, quindi scegli Invio.**

     Se si individua un piano che si desidera utilizzare, scegliere il nome del piano.

1. Nella sezione **Basic information** (Informazioni di base), specificare i seguenti valori:

   1. **Nome**: immetti un nome per la funzione.

   1. **Ruolo**: per iniziare rapidamente, scegli **Crea nuovo ruolo dai modelli**. Puoi anche scegliere **Scegli un ruolo esistente** o **Crea un ruolo personalizzato**, quindi segui i prompt per completare le informazioni di questa sezione.

   1. **Nome ruolo**: immetti un nome per il ruolo.

   1. **Modelli di policy**: scegli le **autorizzazioni Lambda Edge di base**.

1. Se nella fase 4 si è scelto **Author from scratch (Crea da zero)**, passare alla fase 7.

   Se hai scelto un blueprint nel passaggio 4, la sezione **cloudfront** ti consente di creare un trigger, che associa questa funzione a una cache in una distribuzione e in un evento. CloudFront CloudFront A questo punto è consigliabile selezionare **Remove (Rimuovi)** in modo che non sia disponibile un trigger per la funzione al momento della creazione. È possibile aggiungere trigger in un secondo momento. 
**Suggerimento**  
Prima di aggiungere trigger, ti consigliamo di eseguire il test e il debugging della funzione. Se aggiungi ora un trigger, la funzione verrà eseguita non appena creerai la funzione e terminerà la replica in diverse AWS località del mondo e verrà distribuita la distribuzione corrispondente.

1. Selezionare **Create function (Crea funzione)**.

   Lambda crea due versioni della funzione: \$1LATEST e Version 1 (Versione 1). È possibile modificare solo la versione \$1LATEST, ma inizialmente nella console viene visualizzata l'opzione Version 1 (Versione 1).

1. Per modificare la funzione, selezionare **Version 1** (Versione 1) vicino alla parte superiore della pagina, sotto l'ARN per la funzione. Quindi, nella scheda **Versions** (Versioni), selezionare **\$1LATEST**. Se si torna alla funzione in un secondo momento, l'etichetta del pulsante è **Qualifiers** (Qualificatori).

1. Nella scheda **Configuration** (Configurazione), selezionare l'opzione di **Code entry type** (Tipo di immissione codice) applicabile. Quindi, seguire le istruzioni per modificare o caricare il codice.

1. Per **Runtime**, scegliere il valore in base al codice della funzione.

1. Nella sezione **Tags** (Tag), aggiungere gli eventuali tag applicabili.

1. Selezionare **Actions** (Operazioni), quindi **Publish new version** (Pubblica nuova versione).

1. Immetti una descrizione per la nuova versione della funzione.

1. Seleziona **Publish** (Pubblica).

1. Eseguire il test e il debugging della funzione. Per ulteriori informazioni sul test nella console Lambda, consulta [Invocare una funzione Lambda utilizzando la console](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#get-started-invoke-manually) nella *Guida per gli sviluppatori di AWS Lambda *.

1. Quando sei pronto per l'esecuzione della funzione per CloudFront gli eventi, pubblica un'altra versione e modifica la funzione per aggiungere trigger. Per ulteriori informazioni, consulta [Aggiunta di trigger per una funzione Lambda@Edge](lambda-edge-add-triggers.md).

# Modifica di una funzione Lambda
<a name="lambda-edge-edit-function"></a>

Dopo aver creato una funzione Lambda@Edge, puoi utilizzare la console Lambda per modificarla.

**Note**  
La versione originale è contrassegnata con l'etichetta \$1LATEST.
È possibile modificare solo la versione \$1LATEST.
Ogni volta che si modifica la versione \$1LATEST, è necessario pubblicare una nuova versione numerata.
Non è possibile creare trigger per \$1LATEST.
Quando si pubblica una nuova versione di una funzione, Lambda non copia automaticamente i trigger dalla versione precedente in quella nuova. È necessario riprodurre i trigger per la nuova versione. 
Quando aggiungi un trigger per un CloudFront evento a una funzione, se esiste già un trigger per la stessa distribuzione, lo stesso comportamento della cache e lo stesso evento per una versione precedente della stessa funzione, Lambda elimina il trigger dalla versione precedente.
Dopo aver apportato aggiornamenti a una CloudFront distribuzione, ad esempio aggiungendo i trigger, è necessario attendere che le modifiche si propaghino nelle posizioni periferiche prima che le funzioni specificate nei trigger funzionino.<a name="lambda-edge-edit-function-procedure"></a>

**Come modificare una funzione Lambda**

1. Accedi Console di gestione AWS e apri la console all'indirizzo. AWS Lambda [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/)

1. Nell'elenco Regione nella parte superiore della pagina, scegliere **Stati Uniti orientali (Virginia settentrionale)**.

1. Nell’elenco di funzioni, scegli il nome della funzione.

   Per default, nella console viene visualizzata la versione \$1LATEST. È possibile visualizzare le versioni precedenti selezionando **Qualifiers** (Qualificatori), ma è possibile modificare solo la versione \$1LATEST.

1. Nella scheda **Code (Codice)**, per **Code entry type (Tipo di immissione codice)**, scegliere di modificare il codice nel browser, caricare un file .zip o un file da Amazon S3.

1. Selezionare **Save (Salva)** o **Save and test (Salva ed esegui test)**.

1. Selezionare **Actions (Operazioni)**, quindi **Publish new version (Pubblica nuova versione)**. 

1. Nella finestra di dialogo **Publish new version from \$1LATEST** (Pubblica nuova versione da \$1LATEST), immettere una descrizione della nuova versione. Questa descrizione viene visualizzata nell'elenco di versioni, insieme a un numero di versione generato automaticamente. 

1. Seleziona **Publish** (Pubblica).

   La nuova versione diventa automaticamente la versione più recente. Il numero di versione viene visualizzato sulla **Versione** nell’angolo in alto a sinistra della pagina.
**Nota**  
Se non hai ancora aggiunto trigger per la funzione, consulta [Aggiunta di trigger per una funzione Lambda@Edge](lambda-edge-add-triggers.md). 

1. Selezionare la scheda **Triggers** (Trigger).

1. Selezionare **Add trigger** (Aggiungi trigger).

1. Nella finestra di dialogo **Add trigger (Aggiungi trigger)**, selezionare la casella punteggiata, quindi **CloudFront**.
**Nota**  
Se hai già creato uno o più trigger per una funzione, CloudFront è il servizio predefinito.

1. Specificare i seguenti valori per indicare quando si desidera che la funzione Lambda venga eseguita.

   1. **ID distribuzione**: scegli l’ID della distribuzione a cui aggiungere il trigger.

   1. **Comportamento cache**: scegli il comportamento cache che specifica gli oggetti sui quali eseguire la funzione.

   1. **CloudFront evento**: scegli l' CloudFront evento che causa l'esecuzione della funzione.

   1. **Attiva trigger e replica**: seleziona questa casella di controllo per fare in modo che Lambda replichi la funzione nelle Regioni AWS a livello globale.

1. Seleziona **Invia**.

1. Per aggiungere più trigger per questa funzione, ripetere le fasi da 10 a 13.

Per ulteriori informazioni sul test e il debug della funzione nella console Lambda, consulta [Invocare una funzione Lambda utilizzando la console](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#get-started-invoke-manually) nella *Guida per gli sviluppatori di AWS Lambda *.

Quando sei pronto per l'esecuzione della funzione per CloudFront gli eventi, pubblica un'altra versione e modifica la funzione per aggiungere trigger. Per ulteriori informazioni, consulta [Aggiunta di trigger per una funzione Lambda@Edge](lambda-edge-add-triggers.md).

# Aggiunta di trigger per una funzione Lambda@Edge
<a name="lambda-edge-add-triggers"></a>

Un trigger Lambda @Edge è una combinazione di CloudFront distribuzione, comportamento della cache ed evento che causa l'esecuzione di una funzione. Ad esempio, puoi creare un trigger che causa l'esecuzione della funzione quando ricevi CloudFront una richiesta da un visualizzatore per uno specifico comportamento della cache impostato per la tua distribuzione. È possibile specificare uno o più CloudFront trigger. 

**Suggerimento**  
Quando si crea una CloudFront distribuzione, si specificano le impostazioni che indicano CloudFront come rispondere quando riceve richieste diverse. Per impostazioni predefinite si intende il *comportamento cache predefinito* per la distribuzione. È possibile impostare comportamenti aggiuntivi della cache che definiscono la modalità di CloudFront risposta in circostanze specifiche, ad esempio quando riceve una richiesta per un tipo di file specifico. Per ulteriori informazioni, consulta [Cache Behavior Settings (Impostazioni del comportamento della cache)](DownloadDistValuesCacheBehavior.md).

Quando crei una funzione Lambda per la prima volta, puoi specificare *un* solo trigger. Puoi aggiungere altri trigger alla stessa funzione in un secondo momento utilizzando la console Lambda o modificando la distribuzione nella CloudFront console.
+ La console Lambda funziona bene se desideri aggiungere più trigger a una funzione per la stessa distribuzione. CloudFront 
+ La CloudFront console può essere migliore se desideri aggiungere trigger per più distribuzioni, perché è più facile trovare la distribuzione che desideri aggiornare. Puoi anche aggiornare altre CloudFront impostazioni contemporaneamente.

**Topics**
+ [CloudFront eventi che possono attivare una funzione Lambda @Edge](lambda-cloudfront-trigger-events.md)
+ [Scelta dell’evento per attivare la funzione](lambda-how-to-choose-event.md)
+ [Aggiunta di trigger a una funzione Lambda@Edge](lambda-edge-add-triggers-console.md)

# CloudFront eventi che possono attivare una funzione Lambda @Edge
<a name="lambda-cloudfront-trigger-events"></a>

Per ogni comportamento della cache in una CloudFront distribuzione Amazon, puoi aggiungere fino a quattro trigger (associazioni) che causano l'esecuzione di una funzione Lambda quando si verificano eventi CloudFront specifici. CloudFront i trigger possono essere basati su uno dei quattro CloudFront eventi, come mostrato nel diagramma seguente.

![\[Grafico concettuale che mostra come si CloudFront integrano gli eventi di attivazione per le funzioni Lambda con. CloudFront\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/images/cloudfront-events-that-trigger-lambda-functions.png)


Gli CloudFront eventi che possono essere utilizzati per attivare le funzioni Lambda @Edge sono i seguenti:

**Richiesta visualizzatore**  
La funzione viene eseguita quando CloudFront riceve una richiesta da un visualizzatore, prima di verificare se l'oggetto richiesto è nella CloudFront cache.  
La funzione non viene eseguita nei seguenti casi:  
+ Quando si recupera una pagina di errore personalizzata.
+ Quando reindirizza CloudFront automaticamente una richiesta HTTP a HTTPS (quando il valore di [Viewer Protocol Policy (Policy protocollo visualizzatore)](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy) è **Reindirizza HTTP** a HTTPS).

**Richiesta origine**  
La funzione viene eseguita *solo* quando CloudFront inoltra una richiesta all'origine. Quando l'oggetto richiesto è nella CloudFront cache, la funzione non viene eseguita.

**Risposta origine**  
La funzione viene eseguita dopo aver CloudFront ricevuto una risposta dall'origine e prima di memorizzare nella cache l'oggetto nella risposta. La funzione verrà eseguita anche se l'origine restituisce un errore.  
La funzione non viene eseguita nei seguenti casi:  
+ Quando il file richiesto è nella CloudFront cache e non è scaduto.
+ Quando la risposta viene generata da una funzione che è stata attivata da un evento di richiesta origine

**Risposta visualizzatore**  
La funzione viene eseguita prima di restituire il file richiesto al visualizzatore. Si noti che la funzione viene eseguita indipendentemente dal fatto che il file sia già presente nella CloudFront cache.  
La funzione non viene eseguita nei seguenti casi:  
+ Quando l'origine restituisce un codice di stato HTTP 400 o superiore
+ Quando viene restituita una pagina di errore personalizzata
+ Quando la risposta viene generata da una funzione che è stata attivata da un evento di richiesta visualizzatore
+ Quando reindirizza CloudFront automaticamente una richiesta HTTP a HTTPS (quando il valore di [Viewer Protocol Policy (Policy protocollo visualizzatore)](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy) è **Reindirizza HTTP** a HTTPS).

Quando aggiungi più trigger allo stesso comportamento cache, puoi utilizzarli per eseguire la stessa funzione o eseguire funzioni differenti per ciascun trigger. Puoi anche associare la stessa funzione a più di una distribuzione.

**Nota**  
Quando un CloudFront evento attiva l'esecuzione di una funzione Lambda, la funzione deve *terminare* CloudFront prima di poter continuare.   
Ad esempio, se una funzione Lambda viene attivata da un evento di richiesta del CloudFront visualizzatore, CloudFront non restituirà una risposta al visualizzatore né inoltrerà la richiesta all'origine fino al termine dell'esecuzione della funzione Lambda.   
Ciò significa che ogni richiesta che attiva una funzione Lambda aumenta la latenza per la richiesta, pertanto è consigliabile che la funzione venga eseguita il più rapidamente possibile.

# Scelta dell’evento per attivare la funzione
<a name="lambda-how-to-choose-event"></a>

Quando decidi quale CloudFront evento utilizzare per attivare una funzione Lambda, considera quanto segue:

**Voglio CloudFront memorizzare nella cache gli oggetti che vengono modificati da una funzione Lambda**  
Per memorizzare nella cache un oggetto che è stato modificato da una funzione Lambda in modo che CloudFront possa servire l'oggetto dall'edge location la prossima volta che viene richiesto, utilizzate l'evento *origin request* o *origin response*.   
In questo modo, si riduce il carico sull'origine, la latenza per le richieste successive e il costo della richiamata di Lambda@Edge sulle richieste successive.  
Ad esempio, se desideri aggiungere, rimuovere o modificare le intestazioni per gli oggetti restituiti dall'origine e desideri CloudFront inserire nella cache il risultato, utilizza l'evento origin response.

**Desidero che la funzione venga eseguita per ogni richiesta**  
Per eseguire la funzione per ogni richiesta CloudFront ricevuta per la distribuzione, utilizzate gli eventi di *richiesta del visualizzatore* o di *risposta del visualizzatore*.   
Gli eventi Origin request e origin response si verificano solo quando un oggetto richiesto non viene memorizzato nella cache in una edge location e CloudFront inoltra una richiesta all'origine.

**Desidero che funzione modifichi la chiave della cache**  
Per modificare un valore utilizzato per il caching, utilizza l’evento di *richiesta visualizzatore*.   
Ad esempio, se una funzione modifica l'URL per includere un abbreviazione di lingua nel percorso (ad esempio, perché l'utente ha scelto il linguaggio da un elenco a discesa), utilizza l'evento di richiesta visualizzatore:  
+ **URL nella richiesta del visualizzatore: index.html** https://example.com/en/
+ **URL se la richiesta proviene da un indirizzo IP in Germania**https://example.com/de/: index.html
Puoi anche utilizzare l'evento di richiesta visualizzatore se stai eseguendo il caching in base a cookie o intestazioni di richiesta.  
Se la funzione modifica i cookie o le intestazioni, configurate in modo CloudFront da inoltrare la parte applicabile della richiesta all'origine. Per ulteriori informazioni, consulta i seguenti argomenti:  
+ [Caching dei contenuti basati su cookie](Cookies.md)
+ [Caching dei contenuti in base alle intestazioni di richiesta](header-caching.md)

**La funzione influisce sulla risposta dall’origine**  
Per modificare la richiesta in un modo che influisca sulla risposta dall’origine, utilizza l’evento di *richiesta origine*.   
In genere, la maggior parte degli eventi di richiesta del visualizzatore non viene inoltrata all'origine. CloudFront risponde a una richiesta con un oggetto già presente nella cache edge. Se la funzione modifica la richiesta in base a un evento di richiesta di origine, CloudFront memorizza nella cache la risposta alla richiesta di origine modificata.

# Aggiunta di trigger a una funzione Lambda@Edge
<a name="lambda-edge-add-triggers-console"></a>

Puoi usare la AWS Lambda console o la CloudFront console Amazon per aggiungere un trigger alla tua funzione Lambda @Edge.

**Importante**  
Puoi creare trigger solo per le versioni numerate della funzione (non per **\$1LATEST**).

------
#### [ Lambda console ]<a name="lambda-edge-add-triggers-procedure"></a>

**Per aggiungere trigger per CloudFront eventi a una funzione Lambda @Edge**

1. Accedi a Console di gestione AWS e apri la AWS Lambda console all'indirizzo. [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/)

1. Nell'elenco Regione nella parte superiore della pagina, scegliere **Stati Uniti orientali (Virginia settentrionale)**.

1. Nella pagina **Functions (Funzioni)**, scegliere il nome della funzione per la quale si desidera aggiungere trigger.

1. Nella pagina **Panoramica della funzione**, scegli la scheda **Versioni**.

1. Selezionare la versione alla quale si desidera aggiungere trigger.

   Una volta selezionata la versione, il nome del pulsante viene modificato in **Version: \$1LATEST (Versione: \$1LATEST)** o **Version: (Versione:)** *version number (numero della versione)*.

1. Selezionare la scheda **Triggers** (Trigger).

1. Selezionare **Add trigger** (Aggiungi trigger).

1. Per la **configurazione di Trigger**, scegli **Seleziona una fonte****cloudfront**, inserisci, quindi scegli **CloudFront**.
**Nota**  
Se hai già creato uno o più trigger, CloudFront è il servizio predefinito.

1. Specificare i seguenti valori per indicare quando si desidera che la funzione Lambda venga eseguita.

   1. **Distribuzione**: scegli la distribuzione a cui aggiungere il trigger.

   1. **Comportamento cache**: scegli il comportamento cache che specifica gli oggetti sui quali eseguire la funzione.
**Nota**  
Se specifichi `*` per il comportamento cache, la funzione Lambda effettua la distribuzione al comportamento cache predefinito.

   1. **CloudFront evento**: scegli l'CloudFront evento che causa l'esecuzione della funzione.

   1. **Includi corpo**: seleziona questa casella di controllo per accedere al corpo della richiesta nella funzione. 

   1. **Conferma implementazione in Lambda@Edge**: seleziona questa casella di controllo per fare in modo che AWS Lambda replichi la funzione nelle Regioni AWS a livello globale.

1. Scegliere **Aggiungi**.

   La funzione inizia a elaborare le richieste per gli CloudFront eventi specificati quando viene distribuita la CloudFront distribuzione aggiornata. Per determinare se una distribuzione viene distribuita, seleziona **Distributions (Distribuzioni)** nel riquadro di navigazione. Quando una distribuzione viene implementata, il valore della colonna **Stato** per la distribuzione cambia da **Implementazione in corso** alla data e ora dell’implementazione.

------
#### [ CloudFront console ]<a name="lambda-create-functions-add-triggers-cloudfront-console-procedure"></a>

**Per aggiungere trigger per CloudFront eventi a una funzione Lambda @Edge**

1. Ottieni l'ARN della funzione Lambda a cui desideri aggiungere dei trigger:

   1. Accedi a Console di gestione AWS e apri la AWS Lambda console all'indirizzo. [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/)

   1. Nell'elenco delle regioni nella parte superiore della pagina, scegli **US East (Virginia settentrionale)**.

   1. Nell'elenco delle funzioni, scegli il nome della funzione a cui intendi aggiungere i trigger.

   1. Nella pagina **Panoramica della funzione**, scegli la scheda **Versioni** e seleziona la versione numerata a cui aggiungere i trigger.

   1. Scegli il pulsante **Copia ARN** per copiare l’ARN negli appunti. L’ARN per la funzione Lambda è simile a:

      `arn:aws:lambda:us-east-1:123456789012:function:TestFunction:2`

      Il numero alla fine (**2** in questo esempio) è il numero di versione della funzione.

1. Apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Nell'elenco delle distribuzioni, scegli l'ID della distribuzione a cui intendi aggiungere i trigger.

1. Scegli la scheda **Behaviors** (Comportamenti).

1. Seleziona il comportamento cache a cui aggiungere i trigger e scegli **Modifica**.

1. Per **Associazioni funzione**, nell’elenco **Tipo di funzione**, scegli **Lambda@Edge** per specificare quando eseguire la funzione: per richieste visualizzatore, risposte visualizzatore, richieste origine o risposte origine. 

   Per ulteriori informazioni, consulta [Scelta dell’evento per attivare la funzione](lambda-how-to-choose-event.md).

1. Nella casella di testo **ARN/Nome funzione**, incolla l’ARN della funzione Lambda che desideri eseguire quando si verifica l’evento selezionato. Questo è il valore copiato dalla console Lambda.

1. Seleziona **Includi corpo** se desideri accedere al corpo della richiesta nella funzione.

   Si noti che non è necessario selezionare questa opzione se si desidera sostituire il corpo della richiesta.

1. Per eseguire la stessa funzione per più tipi di evento, ripeti le fasi 6 e 7.

1. Scegli **Save changes** (Salva modifiche).

1. Per aggiungere trigger a più comportamenti di cache per questa distribuzione, ripeti i passaggi da 5 a 10.

   La funzione inizia a elaborare le richieste per gli CloudFront eventi specificati quando viene distribuita la CloudFront distribuzione aggiornata. Per determinare se una distribuzione viene distribuita, seleziona **Distributions (Distribuzioni)** nel riquadro di navigazione. Quando una distribuzione viene implementata, il valore della colonna **Stato** per la distribuzione cambia da **Implementazione in corso** alla data e ora dell’implementazione.

------

# Test e debug delle funzioni Lambda@Edge
<a name="lambda-edge-testing-debugging"></a>

È importante testare il codice della funzione Lambda @Edge in modo indipendente, per assicurarsi che completi l'attività prevista, ed eseguire test di integrazione, per assicurarsi che la funzione funzioni correttamente. CloudFront 

Durante i test di integrazione o dopo la distribuzione della funzione, potrebbe essere necessario eseguire il debug di CloudFront errori, come gli errori HTTP 5xx. Gli errori possono essere una risposta non valida restituita dalla funzione Lambda, gli errori di esecuzione quando la funzione è attivata, oppure gli errori dovuti al throttling di esecuzione da parte del servizio Lambda. Le sezioni in questo argomento condividono le strategie per determinare quale tipo di errore è il problema, e quindi quale procedura adottare per risolvere il problema.

**Nota**  
Quando esamini i file di CloudWatch registro o le metriche durante la risoluzione degli errori, tieni presente che vengono visualizzati o archiviati nella posizione Regione AWS più vicina alla posizione in cui è stata eseguita la funzione. Quindi, se hai un sito Web o un'applicazione Web con utenti nel Regno Unito e hai una funzione Lambda associata alla tua distribuzione, ad esempio, devi modificare la regione per visualizzare le CloudWatch metriche o i file di registro per Londra. Regione AWS Per ulteriori informazioni, consulta [Determinazione della Regione Lambda@Edge](#lambda-edge-testing-debugging-determine-region).

**Topics**
+ [Test delle funzioni Lambda@Edge](#lambda-edge-testing-debugging-test-function)
+ [Identifica gli errori della funzione Lambda @Edge in CloudFront](#lambda-edge-identifying-function-errors)
+ [Risoluzione dei problemi relativi alle risposte non valide della funzione Lambda@Edge (errori di convalida)](#lambda-edge-testing-debugging-troubleshooting-invalid-responses)
+ [Risoluzione dei problemi relativi agli errori di esecuzione della funzione Lambda@Edge](#lambda-edge-testing-debugging-execution-errors)
+ [Determinazione della Regione Lambda@Edge](#lambda-edge-testing-debugging-determine-region)
+ [Determina se il tuo account invia i log a CloudWatch](#lambda-edge-testing-debugging-cloudwatch-logs-enabled)

## Test delle funzioni Lambda@Edge
<a name="lambda-edge-testing-debugging-test-function"></a>

Sono disponibili due fasi per il test della funzione Lambda: test autonomo e test di integrazione.

**Test di funzionalità autonoma**  
Prima di aggiungere la funzione Lambda CloudFront, assicurati di testarla prima utilizzando le funzionalità di test nella console Lambda o utilizzando altri metodi. Per ulteriori informazioni sul test nella console Lambda, consulta [Invocare una funzione Lambda utilizzando la console](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#get-started-invoke-manually) nella *Guida per gli sviluppatori di AWS Lambda *.

**Verifica il funzionamento della tua funzione in CloudFront**  
È importante completare i test di integrazione, in cui la funzione è associata a una distribuzione ed è eseguita in base a un CloudFront evento. Verifica che la funzione sia attivata per l'evento corretto e restituisca una risposta valida e corretta per CloudFront. Ad esempio, verifica che la struttura dell’evento sia corretta, che siano incluse solo le intestazioni valide e così via.  
Mentre esegui il test di integrazione con la tua funzione nella console Lambda, fai riferimento ai passaggi del tutorial Lambda @Edge mentre modifichi il codice o cambi il trigger che chiama CloudFront la tua funzione. Ad esempio, assicurati che si stia utilizzando una versione numerata della tua funzione, come descritto in questa fase del tutorial: [Fase 4: Aggiungere un CloudFront trigger per eseguire la funzione](lambda-edge-how-it-works-tutorial.md#lambda-edge-how-it-works-tutorial-add-trigger).   
Mentre apporti modifiche e le distribuisci, tieni presente che ci vorranno diversi minuti prima che la funzione e i CloudFront trigger aggiornati si replichino in tutte le regioni. Questa operazione di solito richiede alcuni minuti, in alcuni casi fino a 15.  
Puoi verificare se la replica è terminata accedendo alla CloudFront console e visualizzando la distribuzione.  

**Come verificare se l’implementazione della replica è terminata**

1. Apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Scegli il nome della distribuzione.

1. Controlla che lo stato della distribuzione torni da **In Progress (In corso)** a **Deployed (Implementato)**, il che significa che la funzione è stata replicata. Quindi segui la procedura nella sezione successiva per verificare che la funzione sia attiva.
Tieni presente che il test nella console convalida solo la logica della funzione e non applica quote di servizio (precedentemente note come limiti) specifiche di Lambda@Edge.

## Identifica gli errori della funzione Lambda @Edge in CloudFront
<a name="lambda-edge-identifying-function-errors"></a>

Dopo aver verificato il corretto funzionamento della logica della funzione, potresti continuare a visualizzare errori HTTP 5xx durante l'esecuzione della funzione. CloudFront Gli errori HTTP 5xx possono essere restituiti per diversi motivi, tra cui errori della funzione Lambda o altri problemi in. CloudFront
+ Se utilizzi le funzioni Lambda @Edge, puoi utilizzare i grafici nella CloudFront console per individuare la causa dell'errore e quindi lavorare per correggerlo. Ad esempio, puoi vedere se gli errori HTTP 5xx sono causati da CloudFront o da funzioni Lambda e quindi, per funzioni specifiche, puoi visualizzare i file di registro correlati per esaminare il problema.
+ Per risolvere gli errori HTTP in generale in CloudFront, consulta la procedura di risoluzione dei problemi nel seguente argomento:. [Risoluzione dei problemi relativi ai codici di stato della risposta agli errori in CloudFront](troubleshooting-response-errors.md)

### Cosa causa gli errori della funzione Lambda @Edge in CloudFront
<a name="lambda-edge-testing-debugging-function-errors"></a>

Ci sono vari motivi per cui una funzione Lambda potrebbe causare un errore HTTP 5xx e i passaggi di risoluzione dei problemi da eseguire variano a seconda del tipo di errore. Gli errori possono essere classificati come riportato di seguito:

**Un errore di esecuzione della funzione Lambda**  
Si verifica un errore di esecuzione quando CloudFront non riceve una risposta da Lambda perché ci sono eccezioni non gestite nella funzione o c'è un errore nel codice. Ad esempio, se il codice include callback (Error).

**Viene restituita una risposta alla funzione Lambda non valida a CloudFront**  
Dopo l'esecuzione della funzione, CloudFront riceve una risposta da Lambda. Si verifica un errore nel caso in cui la struttura dell'oggetto della risposta non è conforme a [Struttura dell'evento Lambda@Edge](lambda-event-structure.md), oppure la risposta contiene le intestazioni non valide o altri campi non validi.

**L'esecuzione in CloudFront è limitata a causa delle quote del servizio Lambda (precedentemente note come limiti)**  
Il servizio Lambda limita le esecuzioni in ciascuna regione e restituisce un errore se si supera la quota. Per ulteriori informazioni, consulta [Quote di Lambda@Edge](cloudfront-limits.md#limits-lambda-at-edge).

### Come stabilire il tipo di errore
<a name="lambda-edge-testing-debugging-failure-type"></a>

Per aiutarvi a decidere dove concentrarvi durante il debug e la risoluzione degli errori restituiti da CloudFront, è utile identificare il motivo per cui viene restituito un errore HTTP. CloudFront Per iniziare, puoi utilizzare i grafici forniti nella sezione **Monitoraggio** della CloudFront console su. Console di gestione AWS Per ulteriori informazioni sulla visualizzazione dei grafici nella sezione **Monitoraggio** della CloudFront console, vedere. [Monitora le CloudFront metriche con Amazon CloudWatch](monitoring-using-cloudwatch.md)

I seguenti grafici possono essere particolarmente utili quando desideri stabilire se gli errori vengono restituiti da origini o da una funzione Lambda e limitare il tipo di problema quando si tratta di un errore di una funzione Lambda.

**Grafico delle percentuali di errore**  
Uno dei grafici che puoi visualizzare nella scheda **Overview (Panoramica)** per ciascuna delle distribuzioni è un grafico **Error rates (Percentuali di errore)**. Questo grafico visualizza la percentuale di errori come una percentuale di richieste totali pervenute alla distribuzione. Il grafico mostra la percentuale di errori totale, gli errori 4xx totali, gli errori 5xx totali e gli errori 5xx totali da funzioni Lambda. In base al tipo di errore e al volume, puoi eseguire fasi per individuare e risolvere la causa.  

![\[Grafico dei tassi di errore per una distribuzione CloudFront\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/images/Distribution-error-rate-pct-full.png)

+ Se sono visibili errori Lambda, puoi indagare ulteriormente osservando i tipi di errori specifici restituiti dalla funzione. La scheda **Lambda@Edge errors (Errori Lambda@Edge)** include grafici che classificano errori di funzioni in base al tipo per individuare il problema per una funzione specifica.
+ Se riscontri CloudFront degli errori, puoi risolverli e correggere gli errori di origine o modificare la CloudFront configurazione. Per ulteriori informazioni, consulta [Risoluzione dei problemi relativi ai codici di stato della risposta agli errori in CloudFront](troubleshooting-response-errors.md).

**Errori di esecuzione e grafici delle rispose di funzione non validi**  
La scheda **Lambda@Edge errors (Errori Lambda@Edge)** include grafici che classificano gli errori Lambda@Edge per una distribuzione specifica, in base al tipo. Ad esempio, un grafico mostra tutti gli errori di esecuzione in base alla Regione AWS.  
Per semplificare la risoluzione dei problemi, puoi cercare problemi specifici aprendo ed esaminando i file di log per funzioni specifiche in base alla Regione.   

**Come visualizzare i file di log per una funzione specifica in base alla Regione**

1. Nella scheda **Errori Lambda@Edge**, in **Funzioni Lambda@Edge associate**, scegli il nome della funzione, quindi seleziona **Visualizza metriche**. 

1. Nella pagina con il nome della funzione, nell’angolo in alto a destra, scegli **Visualizza log delle funzioni**, quindi seleziona una Regione. 

   Ad esempio, se visualizzi problemi nel grafico **Errori** per la Regione Stati Uniti occidentali (Oregon), scegli tale Regione dall’elenco a discesa. Verrà aperta la CloudWatch console Amazon.

1. Nella CloudWatch console di quella regione, in **Log stream**, scegli un flusso di log per visualizzare gli eventi relativi alla funzione.
Inoltre, leggi le seguenti sezioni in questo capitolo per ulteriori suggerimenti sulla risoluzione dei problemi e la correzione degli errori.

**Grafico di throttling**  
La scheda **Lambda@Edge errors (Errori Lambda@Edge)** include anche un grafico **Throttles (Throttle)**. Talvolta, il servizio Lambda limita le invocazioni della funzione in base alla regione, se raggiungi la quota (precedentemente nota come limite) di simultaneità regionale. Se viene visualizzato un errore di superamento del limite, la tua funzione ha raggiunto una quota che il servizio Lambda impone sulle esecuzioni in una regione. Per ulteriori informazioni su come richiedere un aumento della quota, consulta [Quote di Lambda@Edge](cloudfront-limits.md#limits-lambda-at-edge).  

![\[Grafico di limitazione (della larghezza di banda della rete) per l’esecuzione della funzione Lambda@Edge.\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/images/Lambda-throttles-page.png)


Per un esempio su come utilizzare queste informazioni nella risoluzione di errori HTTP, consulta [Quattro fasi per il debug della distribuzione di contenuti su AWS](https://aws.amazon.com/blogs/networking-and-content-delivery/four-steps-for-debugging-your-content-delivery-on-aws/).

## Risoluzione dei problemi relativi alle risposte non valide della funzione Lambda@Edge (errori di convalida)
<a name="lambda-edge-testing-debugging-troubleshooting-invalid-responses"></a>

Se identifichi che il problema è un errore di convalida Lambda, significa che la funzione Lambda sta restituendo una risposta non valida a. CloudFront Segui le indicazioni in questa sezione per prendere provvedimenti per rivedere la tua funzione e assicurarti che la risposta sia conforme ai requisiti. CloudFront 

CloudFront convalida la risposta di una funzione Lambda in due modi:
+ **La risposta Lambda deve rispettare la struttura richiesta dell'oggetto.** Tra gli esempi di errata struttura dell'oggetto figurano i seguenti: JSON non analizzabile, campi obbligatori mancanti e un oggetto non valido nella risposta. Per ulteriori informazioni, consulta [Struttura dell'evento Lambda@Edge](lambda-event-structure.md).
+ **La risposta deve includere solo i valori di oggetti validi.** Si verifica un errore se la risposta include un oggetto valido ma con valori non supportati. Alcuni esempi sono i seguenti: l'aggiunta o l'aggiornamento di intestazioni inserite nella blacklist o di sola lettura (consulta [Restrizioni sulle funzioni edge](edge-functions-restrictions.md)) che superano la dimensione del corpo massima (consulta *Restrizioni sulla dimensione della risposta generata* nell’argomento Lambda@Edge [Errori](lambda-generating-http-responses.md#lambda-generating-http-responses-errors)) e caratteri o valori non validi (vedi [Struttura dell'evento Lambda@Edge](lambda-event-structure.md)).

Quando Lambda restituisce una risposta non valida a CloudFront, i messaggi di errore vengono scritti nei file di registro che vengono CloudFront inviati nella regione CloudWatch in cui è stata eseguita la funzione Lambda. È il comportamento predefinito a cui inviare i file di registro in CloudWatch caso di risposta non valida. Tuttavia, se hai associato una funzione Lambda a CloudFront prima del rilascio della funzionalità, potrebbe non essere abilitata per la tua funzione. Per ulteriori informazioni, consulta *Stabilire se l'account invia i log a CloudWatch* più avanti in questo argomento.

CloudFront invia i file di registro nella regione corrispondente a dove è stata eseguita la funzione, nel gruppo di log associato alla distribuzione. I gruppi di log hanno il seguente formato:`/aws/cloudfront/LambdaEdge/DistributionId`, *DistributionId* dov'è l'ID della tua distribuzione. Per determinare la regione in cui trovare i file di CloudWatch registro, consulta *Determinazione della regione Lambda @Edge* più avanti in questo argomento.

Se l'errore è riproducibile, puoi creare una nuova richiesta che genera l'errore e quindi trovare l'ID della richiesta in una CloudFront risposta non riuscita (`X-Amz-Cf-Id`intestazione) per individuare un singolo errore nei file di registro. La voce del file di log contiene informazioni che consentono di identificare perché l'errore viene restituito ed elenca anche l'id della richiesta Lambda corrispondente che permette di analizzare la causa principale nel contesto di una singola richiesta.

Se un errore è intermittente, è possibile utilizzare i log di CloudFront accesso per trovare l'ID della richiesta per una richiesta non riuscita e quindi cercare nei CloudWatch log i messaggi di errore corrispondenti. Per ulteriori informazioni, consulta la sezione precedente, *Determinazione del Tipo di fallimento*.

## Risoluzione dei problemi relativi agli errori di esecuzione della funzione Lambda@Edge
<a name="lambda-edge-testing-debugging-execution-errors"></a>

Se il problema è un errore di esecuzione Lambda, può essere utile creare istruzioni di registrazione per le funzioni Lambda, scrivere messaggi nei file di CloudWatch registro che monitorano l'esecuzione della funzione CloudFront e determinare se funziona come previsto. Quindi puoi cercare queste istruzioni nei file di CloudWatch registro per verificare che la tua funzione funzioni.

**Nota**  
Anche se non hai modificato la funzione Lambda@Edge, gli aggiornamenti per l'ambiente di esecuzione della funzione Lambda potrebbero influenzarla e potrebbero restituire un errore di esecuzione. Per informazioni sui test e la migrazione a una versione successiva, consulta [Prossimi aggiornamenti dell'ambiente di esecuzione AWS Lambda e AWS Lambda @Edge](https://aws.amazon.com/blogs/compute/upcoming-updates-to-the-aws-lambda-execution-environment/).

## Determinazione della Regione Lambda@Edge
<a name="lambda-edge-testing-debugging-determine-region"></a>

Per vedere le regioni in cui la tua funzione Lambda @Edge riceve traffico, visualizza le metriche per la funzione sulla CloudFront console su. Console di gestione AWS Le metriche vengono visualizzate per ogni regione. AWS Nella stessa pagina, puoi scegliere una regione e visualizzare i file di log per tale regione, in modo da analizzare i problemi. È necessario esaminare i file di CloudWatch registro nella AWS regione corretta per visualizzare i file di registro creati durante l' CloudFront esecuzione della funzione Lambda.

Per ulteriori informazioni sulla visualizzazione dei grafici nella sezione **Monitoraggio** della CloudFront console, consulta. [Monitora le CloudFront metriche con Amazon CloudWatch](monitoring-using-cloudwatch.md)

## Determina se il tuo account invia i log a CloudWatch
<a name="lambda-edge-testing-debugging-cloudwatch-logs-enabled"></a>

Per impostazione predefinita, CloudFront abilita la registrazione delle risposte della funzione Lambda non valide e invia i file di registro utilizzando uno dei. CloudWatch [Ruoli collegati ai servizi per Lambda@Edge](lambda-edge-permissions.md#using-service-linked-roles-lambda-edge) Se hai funzioni Lambda @Edge che hai aggiunto CloudFront prima del rilascio della funzionalità di registro delle risposte della funzione Lambda non valida, la registrazione viene abilitata al successivo aggiornamento della configurazione Lambda @Edge, ad esempio aggiungendo un trigger. CloudFront 

Puoi verificare che l'invio dei file di registro a CloudWatch sia abilitato per il tuo account effettuando le seguenti operazioni:
+ **Controlla se i log vengono visualizzati in CloudWatch**: assicurati di cercare nella regione in cui è stata eseguita la funzione Lambda @Edge. Per ulteriori informazioni, consulta [Determinazione della Regione Lambda@Edge](#lambda-edge-testing-debugging-determine-region).
+ **Verifica se il ruolo collegato al servizio correlato esiste nell’account in IAM**: devi disporre del ruolo IAM `AWSServiceRoleForCloudFrontLogger` nell’account. Per ulteriori informazioni su questo ruolo, consulta [Ruoli collegati ai servizi per Lambda@Edge](lambda-edge-permissions.md#using-service-linked-roles-lambda-edge).

# Eliminazione delle funzioni e delle repliche Lambda@Edge
<a name="lambda-edge-delete-replicas"></a>

È possibile eliminare una funzione Lambda@Edge solo quando le repliche della funzione sono state eliminate da CloudFront. Le repliche di una funzione Lambda vengono eliminate automaticamente nei seguenti casi:
+ Dopo aver rimosso l'ultima associazione della funzione da tutte le distribuzioni CloudFront. Se più di una distribuzione utilizza una funzione, le repliche vengono eliminate solo dopo aver rimosso l'associazione della funzione dall'ultima distribuzione.
+ Dopo aver eliminato l'ultima distribuzione a cui era associata una funzione.

In genere, le repliche vengono eliminate entro poche ore. Non è possibile eliminare manualmente le repliche delle funzioni Lambda@Edge. Ciò consente di evitare una situazione in cui viene eliminata una replica che è ancora in uso, il che comporterebbe un errore.

**avvertimento**  
Non creare applicazioni che utilizzano repliche di funzioni Lambda @Edge al di fuori di. CloudFront Queste repliche vengono eliminate quando le associazioni con le distribuzioni vengono rimosse o quando le distribuzioni stesse vengono eliminate. Pertanto, la replica da cui dipende un'applicazione esterna potrebbe essere rimossa senza l'emissione di un avviso, causando il mancato funzionamento dell'applicazione.

**Per eliminare un'associazione di funzioni Lambda @Edge da una distribuzione CloudFront**

1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Scegli l’ID della distribuzione con l’associazione della funzione Lambda@Edge da eliminare.

1. Scegli la scheda **Behaviors** (Comportamenti).

1. Seleziona il comportamento cache che dispone dell’associazione della funzione Lambda@Edge da eliminare e quindi scegli **Modifica**.

1. In **Associazioni di funzioni**, **Tipo di funzione**, scegli **Nessuna associazione** per eliminare l’associazione della funzione Lambda@Edge.

1. Scegli **Save changes** (Salva modifiche).

Dopo aver eliminato un'associazione di funzioni Lambda @Edge da una CloudFront distribuzione, puoi facoltativamente eliminare la funzione Lambda o la versione della funzione da. AWS Lambda Attendi alcune ore dopo aver eliminato l’associazione della funzione in modo che le repliche della funzione Lambda@Edge possano essere pulite. Successivamente, puoi eliminare la funzione utilizzando la console Lambda, l'API AWS CLI Lambda o un SDK. AWS 

Puoi anche eliminare una *versione* specifica di una funzione Lambda se alla versione non è associata alcuna CloudFront distribuzione. Dopo aver rimosso tutte le associazioni per una versione della funzione Lambda, attendi alcune ore. Quindi puoi eliminare la versione della funzione.

# Struttura dell'evento Lambda@Edge
<a name="lambda-event-structure"></a>

I seguenti argomenti descrivono gli oggetti evento di richiesta e risposta che CloudFront passano a una funzione Lambda @Edge quando viene attivata.

**Topics**
+ [Selezione origine dinamica](#lambda-event-content-based-routing)
+ [Richiedi Eventi](#lambda-event-structure-request)
+ [Eventi di risposta](#lambda-event-structure-response)

## Selezione origine dinamica
<a name="lambda-event-content-based-routing"></a>

Puoi utilizzare il [modello di percorso in un comportamento cache](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern) per instradare richieste a un'origine, in base al percorso e al nome dell'oggetto richiesto, ad esempio `images/*.jpg`. Utilizzando Lambda@Edge, puoi anche instradare richieste a un'origine in base ad altre caratteristiche, ad esempio i valori nelle intestazioni di richiesta. 

La selezione dinamica dell'origine può risultare utile in vari modi. Ad esempio, puoi distribuire richieste in più origini di aree geografiche differenti per facilitare il bilanciamento del carico globale. Oppure puoi instradare richieste in modo selettivo a diverse origini, ognuna delle quali svolge una funzione particolare: gestione di bot, ottimizzazione di SEO, autenticazione e così via. Per codici di esempio che illustrano come utilizzare questa funzionalità, consulta [Esempi di selezione dinamica dell'origine in funzione del contenuto](lambda-examples.md#lambda-examples-content-based-routing-examples).

Nell'evento CloudFront origin request, l'`origin`oggetto nella struttura degli eventi contiene informazioni sull'origine a cui verrebbe indirizzata la richiesta, in base al modello di percorso. Puoi aggiornare i valori nell'oggetto `origin` dell'origine per instradare una richiesta un'altra origine. Quando si aggiorna l'oggetto `origin`, non è necessario definire l'origine nella distribuzione. È inoltre possibile sostituire un oggetto di origine Amazon S3 con un oggetto di origine personalizzato e viceversa. Tuttavia, è possibile specificare solo una singola origine per richiesta; un'origine personalizzata o un'origine Amazon S3, ma non entrambe.

## Richiedi Eventi
<a name="lambda-event-structure-request"></a>

I seguenti argomenti mostrano la struttura dell'oggetto che CloudFront passa a una funzione Lambda per gli eventi di [richiesta viewer e origin](lambda-cloudfront-trigger-events.md). Questi esempi mostrano una richiesta `GET` senza corpo. Dopo gli esempi è riportato un elenco di tutti i possibili campi negli eventi di richiesta di visualizzazione e origine.

**Topics**
+ [Richiesta visualizzatore di esempio](#example-viewer-request)
+ [Esempio di richiesta di origine](#example-origin-request)
+ [Richiedi campi evento](#request-event-fields)

### Richiesta visualizzatore di esempio
<a name="example-viewer-request"></a>

L'esempio seguente mostra un oggetto evento richiesta visualizzatore.

```
{
  "Records": [
    {
      "cf": {
        "config": {
          "distributionDomainName": "d111111abcdef8.cloudfront.net",
          "distributionId": "EDFDVBD6EXAMPLE",
          "eventType": "viewer-request",
          "requestId": "4TyzHTaYWb1GX1qTfsHhEqV6HUDd_BzoBZnwfnvQc_1oF26ClkoUSEQ=="
        },
        "request": {
          "clientIp": "203.0.113.178",
          "headers": {
            "host": [
              {
                "key": "Host",
                "value": "d111111abcdef8.cloudfront.net"
              }
            ],
            "user-agent": [
              {
                "key": "User-Agent",
                "value": "curl/7.66.0"
              }
            ],
            "accept": [
              {
                "key": "accept",
                "value": "*/*"
              }
            ]
          },
          "method": "GET",
          "querystring": "",
          "uri": "/"
        }
      }
    }
  ]
}
```

### Esempio di richiesta di origine
<a name="example-origin-request"></a>

L'esempio seguente mostra un oggetto evento richiesta origine.

```
{
  "Records": [
    {
      "cf": {
        "config": {
          "distributionDomainName": "d111111abcdef8.cloudfront.net",
          "distributionId": "EDFDVBD6EXAMPLE",
          "eventType": "origin-request",
          "requestId": "4TyzHTaYWb1GX1qTfsHhEqV6HUDd_BzoBZnwfnvQc_1oF26ClkoUSEQ=="
        },
        "request": {
          "clientIp": "203.0.113.178",
          "headers": {
            "x-forwarded-for": [
              {
                "key": "X-Forwarded-For",
                "value": "203.0.113.178"
              }
            ],
            "user-agent": [
              {
                "key": "User-Agent",
                "value": "Amazon CloudFront"
              }
            ],
            "via": [
              {
                "key": "Via",
                "value": "2.0 2afae0d44e2540f472c0635ab62c232b.cloudfront.net (CloudFront)"
              }
            ],
            "host": [
              {
                "key": "Host",
                "value": "example.org"
              }
            ],
            "cache-control": [
              {
                "key": "Cache-Control",
                "value": "no-cache"
              }
            ]
          },
          "method": "GET",
          "origin": {
            "custom": {
              "customHeaders": {},
              "domainName": "example.org",
              "keepaliveTimeout": 5,
              "path": "",
              "port": 443,
              "protocol": "https",
              "readTimeout": 30,
              "responseCompletionTimeout": 30,
              "sslProtocols": [
                "TLSv1",
                "TLSv1.1",
                "TLSv1.2"
              ]
            }
          },
          "querystring": "",
          "uri": "/"
        }
      }
    }
  ]
}
```

### Richiedi campi evento
<a name="request-event-fields"></a>

I dati dell'oggetto evento di richiesta sono contenuti in due sottooggetti: `config` (`Records.cf.config`) e `request` (`Records.cf.request`). I seguenti elenchi descrivono i campi di ciascun oggetto secondario.

#### Campi nell'oggetto config
<a name="request-event-fields-config"></a>

Nella seguente lista sono descritti i campi dell’oggetto `config` (`Records.cf.config`).

**`distributionDomainName` (solo lettura)**  
Il nome di dominio della distribuzione associata alla richiesta.

**`distributionID` (solo lettura)**  
L'ID della distribuzione associata alla richiesta.

**`eventType` (solo lettura)**  
Il tipo di trigger associato alla richiesta: `viewer-request` o `origin-request`.

**`requestId` (solo lettura)**  
Una stringa crittografata che identifica in modo univoco una richiesta. viewer-to-CloudFront Il valore `requestId` è visualizzato anche nei log di accesso di CloudFront come `x-edge-request-id`. Per ulteriori informazioni, consultare [Registri di accesso (registri standard)](AccessLogs.md) e [Campi di file di log](standard-logs-reference.md#BasicDistributionFileFormat).

#### Campi nell'oggetto richiesta
<a name="request-event-fields-request"></a>

Nella seguente lista sono descritti i campi dell’oggetto `request` (`Records.cf.request`).

**`clientIp` (solo lettura)**  
L'indirizzo IP del visualizzatore che ha effettuato la richiesta. Se il visualizzatore ha utilizzato un proxy HTTP o un sistema di bilanciamento del carico per inviare la richiesta, il valore è l'indirizzo IP del proxy o del sistema di bilanciamento del carico.

**intestazioni (lettura/scrittura)**  
Le intestazioni nella richiesta. Tieni presente quanto segue:  
+ Le chiavi nell'oggetto `headers` sono versioni in minuscolo di nomi di intestazione HTTP standard. L'utilizzo di chiavi in minuscolo fornisce accesso ai valori delle intestazioni senza distinzione tra maiuscole e minuscole.
+ Ogni intestazione (ad esempio, `headers["accept"]` o `headers["host"]`) è una matrice di coppie chiave-valore. Per una determinata intestazione, la matrice contiene una coppia chiave-valore per ogni valore nella risposta generata.
+ `key` contiene il nome con distinzione tra maiuscole e minuscole dell’intestazione come appare nella richiesta HTTP; ad esempio `Host`, `User-Agent`, `X-Forwarded-For`, `Cookie` e così via.
+ `value` contiene il valore dell'intestazione come è apparso nella richiesta HTTP.
+ Quando la funzione Lambda aggiunge o modifica le intestazioni di richiesta e non si include il campo di intestazione `key`, Lambda @Edge inserisce automaticamente un'intestazione `key` utilizzando il nome dell'intestazione fornito. Indipendentemente dalla formattazione del nome dell'intestazione, la chiave dell'intestazione automaticamente inserita sarà formattata con iniziale maiuscola per tutte le parti, separate da trattini (-).

  Ad esempio, è possibile aggiungere un'intestazione come quella seguente, senza una chiave dell'intestazione: `key`

  ```
  "user-agent": [
    {
      "value": "ExampleCustomUserAgent/1.X.0"
    }
  ]
  ```

  In questo esempio, Lambda @Edge inserisce automaticamente `"key": "User-Agent"`.
Per informazioni sulle restrizioni di utilizzo delle intestazioni, consulta [Restrizioni sulle funzioni edge](edge-functions-restrictions.md).

**`method` (solo lettura)**  
Metodo HTTP nella richiesta.

**`querystring` (lettura/scrittura)**  
La stringa di query, se presente, nella richiesta. Se la richiesta non include una stringa di query, l’oggetto evento include comunque `querystring` con un valore vuoto. Per ulteriori informazioni sulle stringhe di query, vedi [Memorizzazione nella cache di contenuti basati su parametri delle stringhe di query](QueryStringParameters.md).

**`uri` (lettura/scrittura)**  
Il percorso relativo dell'oggetto richiesto. Se la funzione Lambda modifica il valore `uri`, annotare quanto segue:  
+ Il nuovo valore `uri` deve iniziare con una barra (/).
+ Se una funzione modifica il valore `uri`, l'oggetto richiesto dal visualizzatore viene modificato.
+ Se una funzione modifica il valore `uri`, il comportamento della cache per la richiesta o l'origine a cui la richiesta viene inoltrata *non* viene modificato.

**`body` (lettura/scrittura)**  
Il corpo della richiesta HTTP. La struttura `body` può contenere i seguenti campi:    
**`inputTruncated` (solo lettura)**  
Un flag booleano che indica se l'organismo è stato troncato da Lambda@Edge. Per ulteriori informazioni, consulta [Restrizioni sul corpo della richiesta con l'opzione Includi corpo](lambda-at-edge-function-restrictions.md#lambda-at-edge-restrictions-request-body).  
**`action` (lettura/scrittura)**  
L'operazione che si desidera richiedere con il corpo. Le opzioni per `action` sono le seguenti:  
+ `read-only:` Questa è l'impostazione predefinita. Quando viene restituita la risposta dalla funzione Lambda, se `action` è di sola lettura, Lambda@Edge ignora tutte le modifiche a `encoding` o `data`.
+ `replace:` specificare questo quando si desidera sostituire il corpo inviato all'origine.  
**`encoding` (lettura/scrittura)**  
La codifica per il corpo. Quando Lambda@Edge espone il corpo alla funzione Lambda, converte per prima cosa il corpo nella codifica base64-encoding. Se scegli `replace` per `action` per sostituire il corpo, è possibile decidere se utilizzare la codifica `base64` (questa è l'impostazione predefinita) o `text`. Se specifichi `encoding` come `base64` ma il corpo non è valido in base64, CloudFront restituisce un errore.  
**`data` (lettura/scrittura)**  
I contenuti del corpo della richiesta. 

**`origin` ( lettura/scrittura) (solo eventi di origine)**  
L'origine a cui inviare la richiesta. La struttura `origin` deve contenere *esattamente un’origine*, che può essere un’origine personalizzata o un’origine Amazon S3.  
A seconda del tipo di origine specificato (origini personalizzate o Amazon S3), è necessario specificare i seguenti campi nella richiesta:    
**`customHeaders` ( lettura/scrittura) (origini personalizzate e Amazon S3)**  
(Facoltativo) Puoi includere intestazioni personalizzate con la richiesta specificando un nome di intestazione e una coppia di valori per ogni intestazione personalizzata. Non è possibile aggiungere intestazioni che non sono consentite e in `Records.cf.request.headers` un'intestazione con lo stesso nome non può essere presente. Le [note sulle intestazioni di richiesta](#request-event-fields-request-headers) si applicano anche alle intestazioni personalizzate. Per ulteriori informazioni, consulta [Intestazioni personalizzate che CloudFront non possono essere aggiunte alle richieste di origine](add-origin-custom-headers.md#add-origin-custom-headers-denylist) e [Restrizioni sulle funzioni edge](edge-functions-restrictions.md).  
**`domainName` ( lettura/scrittura) (origini personalizzate e Amazon S3)**  
Il nome di dominio dell'origine. Il nome di dominio non può essere vuoto.  
+ **Per origini personalizzate** - specificare un nome di dominio DNS, ad esempio `www.example.com`. Il nome di dominio non può includere due punti (:) e non può essere un indirizzo IP. Il nome di dominio può contenere fino a 253 caratteri.
+ **Per origini Amazon S3**: specificare il nome di dominio DNS del bucket Amazon S3, ad esempio `amzn-s3-demo-bucket.s3.eu-west-1.amazonaws.com`. Il nome può contenere fino a 128 caratteri e deve essere tutto in minuscolo.  
**`path` ( lettura/scrittura) (origini personalizzate e Amazon S3)**  
Il percorso di directory sul server di origine in cui la richiesta deve trovare il contenuto. Il percorso può iniziare con una barra (/) ma non può terminare con una barra (ad esempio, non può terminare con `example-path/`). Solo per le origini personalizzate, il percorso deve essere codificato con URL e avere una lunghezza massima di 255 caratteri.  
**`keepaliveTimeout` (lettura/scrittura) (solo origini personalizzate)**  
Per quanto tempo, in secondi, si CloudFront dovrebbe cercare di mantenere la connessione all'origine dopo aver ricevuto l'ultimo pacchetto della risposta. Il valore deve essere un numero compreso tra 1 e 120, inclusi.  
**`port` (lettura/scrittura) (solo origini personalizzate)**  
La porta a cui CloudFront deve connettersi all'origine personalizzata. La porta deve essere 80, 443 oppure un numero nell'intervallo 1024-65535, inclusi.  
**`protocol` (lettura/scrittura) (solo origini personalizzate)**  
Il protocollo di connessione da CloudFront utilizzare per la connessione all'origine. Il valore può essere `http` o `https`.  
**`readTimeout` ( lettura/scrittura) (origini personalizzate e Amazon S3)**  
Quanto tempo, in secondi, CloudFront occorre attendere per ricevere una risposta dopo aver inviato una richiesta all'indirizzo di origine. Questo specifica anche quanto tempo CloudFront deve attendere dopo aver ricevuto un pacchetto di una risposta prima di ricevere il pacchetto successivo. Il valore deve essere un numero compreso tra 1 e 120, inclusi.  
Se hai bisogno di una quota maggiore, consulta [Timeout di risposta per origine](cloudfront-limits.md#limits-web-distributions).  
**`responseCompletionTimeout` ( lettura/scrittura) (origini personalizzate e Amazon S3)**  
Il tempo (in secondi) in cui una richiesta dall' CloudFront origine può rimanere aperta e attendere una risposta. Se la risposta completa non viene ricevuta dall'origine entro quest'ora, CloudFront termina la connessione.  
Il valore per `responseCompletionTimeout` deve essere maggiore o uguale al valore per `readTimeout`. Se imposti questo valore su 0, rimuove qualsiasi valore precedente impostato e torna al valore predefinito. Puoi anche ottenere lo stesso risultato eliminando il campo `responseCompletionTimeout` dalla richiesta evento.   
**`sslProtocols` (lettura/scrittura) (solo origini personalizzate)**  
Il SSL/TLS protocollo minimo che CloudFront è possibile utilizzare per stabilire una connessione HTTPS con l'origine. I valori possono essere uno dei seguenti: `TLSv1.2`, `TLSv1.1`, `TLSv1` o `SSLv3`.  
**`authMethod` ( lettura/scrittura) (solo origini Amazon S3)**  
Se stai usando un’[identità di accesso origine (OAI)](private-content-restricting-access-to-s3.md#private-content-restricting-access-to-s3-oai), imposta questo campo su `origin-access-identity`. Se non stai usando una OAI, impostalo su `none`. Se si imposta `authMethod` su `origin-access-identity`, ci sono diversi requisiti:   
+ È necessario specificare `region` (vedere il seguente campo).
+ È necessario utilizzare lo stesso OAI quando si modifica la richiesta da un'origine Amazon S3 a un'altra.
+ Non è possibile utilizzare una OAI quando si modifica la richiesta da un'origine personalizzata a un'origine Amazon S3.
Questo campo non supporta il [controllo dell'accesso all'origine (OAC)](private-content-restricting-access-to-s3.md).  
**`region` ( lettura/scrittura) (solo origini Amazon S3)**  
La AWS regione del tuo bucket Amazon S3. Questo è necessario solo quando si imposta `authMethod` su `origin-access-identity`.

## Eventi di risposta
<a name="lambda-event-structure-response"></a>

I seguenti argomenti mostrano la struttura dell'oggetto che CloudFront passa a una funzione Lambda per gli eventi di [risposta del visualizzatore e dell'origine](lambda-cloudfront-trigger-events.md). Dopo gli esempi c'è un elenco di tutti i campi possibili in eventi di risposta del visualizzatore e origine.

**Topics**
+ [Esempio di risposta all'origine](#lambda-event-structure-response-origin)
+ [Risposta del visualizzatore di esempio](#lambda-event-structure-response-viewer)
+ [Campi eventi di risposta](#response-event-fields)

### Esempio di risposta all'origine
<a name="lambda-event-structure-response-origin"></a>

L'esempio seguente mostra un oggetto evento risposta origine.

```
{
  "Records": [
    {
      "cf": {
        "config": {
          "distributionDomainName": "d111111abcdef8.cloudfront.net",
          "distributionId": "EDFDVBD6EXAMPLE",
          "eventType": "origin-response",
          "requestId": "4TyzHTaYWb1GX1qTfsHhEqV6HUDd_BzoBZnwfnvQc_1oF26ClkoUSEQ=="
        },
        "request": {
          "clientIp": "203.0.113.178",
          "headers": {
            "x-forwarded-for": [
              {
                "key": "X-Forwarded-For",
                "value": "203.0.113.178"
              }
            ],
            "user-agent": [
              {
                "key": "User-Agent",
                "value": "Amazon CloudFront"
              }
            ],
            "via": [
              {
                "key": "Via",
                "value": "2.0 8f22423015641505b8c857a37450d6c0.cloudfront.net (CloudFront)"
              }
            ],
            "host": [
              {
                "key": "Host",
                "value": "example.org"
              }
            ],
            "cache-control": [
              {
                "key": "Cache-Control",
                "value": "no-cache"
              }
            ]
          },
          "method": "GET",
          "origin": {
            "custom": {
              "customHeaders": {},
              "domainName": "example.org",
              "keepaliveTimeout": 5,
              "path": "",
              "port": 443,
              "protocol": "https",
              "readTimeout": 30,
              "responseCompletionTimeout": 30,
              "sslProtocols": [
                "TLSv1",
                "TLSv1.1",
                "TLSv1.2"
              ]
            }
          },
          "querystring": "",
          "uri": "/"
        },
        "response": {
          "headers": {
            "access-control-allow-credentials": [
              {
                "key": "Access-Control-Allow-Credentials",
                "value": "true"
              }
            ],
            "access-control-allow-origin": [
              {
                "key": "Access-Control-Allow-Origin",
                "value": "*"
              }
            ],
            "date": [
              {
                "key": "Date",
                "value": "Mon, 13 Jan 2020 20:12:38 GMT"
              }
            ],
            "referrer-policy": [
              {
                "key": "Referrer-Policy",
                "value": "no-referrer-when-downgrade"
              }
            ],
            "server": [
              {
                "key": "Server",
                "value": "ExampleCustomOriginServer"
              }
            ],
            "x-content-type-options": [
              {
                "key": "X-Content-Type-Options",
                "value": "nosniff"
              }
            ],
            "x-frame-options": [
              {
                "key": "X-Frame-Options",
                "value": "DENY"
              }
            ],
            "x-xss-protection": [
              {
                "key": "X-XSS-Protection",
                "value": "1; mode=block"
              }
            ],
            "content-type": [
              {
                "key": "Content-Type",
                "value": "text/html; charset=utf-8"
              }
            ],
            "content-length": [
              {
                "key": "Content-Length",
                "value": "9593"
              }
            ]
          },
          "status": "200",
          "statusDescription": "OK"
        }
      }
    }
  ]
}
```

### Risposta del visualizzatore di esempio
<a name="lambda-event-structure-response-viewer"></a>

Nell'esempio seguente viene illustrato un oggetto evento risposta visualizzatore.

```
{
  "Records": [
    {
      "cf": {
        "config": {
          "distributionDomainName": "d111111abcdef8.cloudfront.net",
          "distributionId": "EDFDVBD6EXAMPLE",
          "eventType": "viewer-response",
          "requestId": "4TyzHTaYWb1GX1qTfsHhEqV6HUDd_BzoBZnwfnvQc_1oF26ClkoUSEQ=="
        },
        "request": {
          "clientIp": "203.0.113.178",
          "headers": {
            "host": [
              {
                "key": "Host",
                "value": "d111111abcdef8.cloudfront.net"
              }
            ],
            "user-agent": [
              {
                "key": "User-Agent",
                "value": "curl/7.66.0"
              }
            ],
            "accept": [
              {
                "key": "accept",
                "value": "*/*"
              }
            ]
          },
          "method": "GET",
          "querystring": "",
          "uri": "/"
        },
        "response": {
          "headers": {
            "access-control-allow-credentials": [
              {
                "key": "Access-Control-Allow-Credentials",
                "value": "true"
              }
            ],
            "access-control-allow-origin": [
              {
                "key": "Access-Control-Allow-Origin",
                "value": "*"
              }
            ],
            "date": [
              {
                "key": "Date",
                "value": "Mon, 13 Jan 2020 20:14:56 GMT"
              }
            ],
            "referrer-policy": [
              {
                "key": "Referrer-Policy",
                "value": "no-referrer-when-downgrade"
              }
            ],
            "server": [
              {
                "key": "Server",
                "value": "ExampleCustomOriginServer"
              }
            ],
            "x-content-type-options": [
              {
                "key": "X-Content-Type-Options",
                "value": "nosniff"
              }
            ],
            "x-frame-options": [
              {
                "key": "X-Frame-Options",
                "value": "DENY"
              }
            ],
            "x-xss-protection": [
              {
                "key": "X-XSS-Protection",
                "value": "1; mode=block"
              }
            ],
            "age": [
              {
                "key": "Age",
                "value": "2402"
              }
            ],
            "content-type": [
              {
                "key": "Content-Type",
                "value": "text/html; charset=utf-8"
              }
            ],
            "content-length": [
              {
                "key": "Content-Length",
                "value": "9593"
              }
            ]
          },
          "status": "200",
          "statusDescription": "OK"
        }
      }
    }
  ]
}
```

### Campi eventi di risposta
<a name="response-event-fields"></a>

I dati dell'oggetto evento risposta sono contenuti in tre sottooggetti: `config` 8`Records.cf.config`), `request` (`Records.cf.request`) e `response` (`Records.cf.response`). Per ulteriori informazioni sui campi dell'oggetto richiesta, vedere [Campi nell'oggetto richiesta](#request-event-fields-request). Gli elenchi seguenti descrivono i campi nei sottooggetti `config` e `response`.

#### Campi nell'oggetto config
<a name="response-event-fields-config"></a>

Nella seguente lista sono descritti i campi dell’oggetto `config` (`Records.cf.config`).

**`distributionDomainName` (solo lettura)**  
Il nome di dominio della distribuzione associata alla risposta.

**`distributionID` (solo lettura)**  
L'ID della distribuzione associata alla risposta.

**`eventType` (solo lettura)**  
Il tipo di trigger associato alla risposta: `origin-response` o `viewer-response`.

**`requestId` (solo lettura)**  
Una stringa crittografata che identifica in modo univoco la viewer-to-CloudFront richiesta a cui è associata questa risposta. Il `requestId` valore appare anche nei registri di CloudFront accesso come. `x-edge-request-id` Per ulteriori informazioni, consultare [Registri di accesso (registri standard)](AccessLogs.md) e [Campi di file di log](standard-logs-reference.md#BasicDistributionFileFormat).

#### Campi nell'oggetto risposta
<a name="response-event-fields-response"></a>

Nella seguente lista sono descritti i campi dell’oggetto `response` (`Records.cf.response`). Per informazioni sull'utilizzo di una funzione Lambda @Edge per generare una risposta HTTP, vedere [Generazione di risposte HTTP in trigger di richiesta](lambda-generating-http-responses.md#lambda-generating-http-responses-in-requests).

**`headers` (lettura/scrittura)**  
Le intestazioni nella risposta. Tieni presente quanto segue:  
+ Le chiavi nell'oggetto `headers` sono versioni in minuscolo di nomi di intestazione HTTP standard. L'utilizzo di chiavi in minuscolo fornisce accesso ai valori delle intestazioni senza distinzione tra maiuscole e minuscole.
+ Ogni intestazione (ad esempio, `headers["content-type"]` o `headers["content-length"]`) è una matrice di coppie chiave-valore. Per una determinata intestazione, la matrice contiene una coppia chiave-valore per ogni valore nella risposta generata.
+ `key` contiene il nome con distinzione tra maiuscole e minuscole dell’intestazione come appare nella risposta HTTP; ad esempio `Content-Type`, `Content-Length`, `Cookie` e così via.
+ `value` contiene il valore dell'intestazione come appare nella risposta HTTP.
+ Quando la funzione Lambda aggiunge o modifica le intestazioni di risposta e non si include il campo di intestazione `key`, Lambda @Edge inserisce automaticamente un'intestazione `key` utilizzando il nome dell'intestazione fornito. Indipendentemente dalla formattazione del nome dell'intestazione, la chiave dell'intestazione automaticamente inserita sarà formattata con iniziale maiuscola per tutte le parti, separate da trattini (-).

  Ad esempio, è possibile aggiungere un'intestazione come quella seguente, senza una chiave dell'intestazione: `key`

  ```
  "content-type": [
    {
      "value": "text/html;charset=UTF-8"
    }
  ]
  ```

  In questo esempio, Lambda @Edge inserisce automaticamente `"key": "Content-Type"`.
Per informazioni sulle restrizioni di utilizzo delle intestazioni, consulta [Restrizioni sulle funzioni edge](edge-functions-restrictions.md).

**`status`**  
Il codice di stato HTTP per la risposta.

**`statusDescription`**  
Descrizione dello stato HTTP della risposta.

# Utilizzo di richieste e risposte
<a name="lambda-generating-http-responses"></a>

Per utilizzare le richieste e le risposte di Lambda@Edge, consulta i seguenti argomenti:

**Topics**
+ [Utilizzo delle funzioni Lambda@Edge con failover di origine](#lambda-and-origin-failover)
+ [Generazione di risposte HTTP in trigger di richiesta](#lambda-generating-http-responses-in-requests)
+ [Aggiornamento delle risposte HTTP nei trigger di risposta origine](#lambda-updating-http-responses)
+ [Accesso al corpo della richiesta scegliendo l’opzione includi corpo](#lambda-include-body-access)

## Utilizzo delle funzioni Lambda@Edge con failover di origine
<a name="lambda-and-origin-failover"></a>

Puoi utilizzare le funzioni Lambda @Edge con le CloudFront distribuzioni che hai configurato con i gruppi di origine, ad esempio per il failover di origine che configuri per garantire un'elevata disponibilità. Per usare una funzione Lambda con un gruppo di origine, specifica la funzione in una richiesta all'origine o di risposta di origine trigger per un gruppo di origine quando crei il comportamento cache.

Per ulteriori informazioni, consulta gli argomenti seguenti:
+ **Crea gruppi di origine:** [Creazione di un gruppo di origine](high_availability_origin_failover.md#concept_origin_groups.creating)
+ **Come funziona il failover di origine con Lambda@Edge:** [Utilizzo del failover di origine con le funzioni Lambda@Edge](high_availability_origin_failover.md#concept_origin_groups.lambda)

## Generazione di risposte HTTP in trigger di richiesta
<a name="lambda-generating-http-responses-in-requests"></a>

Quando si CloudFront riceve una richiesta, è possibile utilizzare una funzione Lambda per generare una risposta HTTP che CloudFront ritorna direttamente al visualizzatore senza inoltrare la risposta all'origine. La generazione di risposte HTTP riduce il carico sull'origine e in genere riduce la latenza per il visualizzatore.

Alcuni scenari comuni per la generazione di risposte HTTP sono:
+ Restituzione di una piccola pagina Web al visualizzatore
+ Restituzione di un codice di stato HTTP 301 o 302 per reindirizzare l'utente a un'altra pagina Web
+ Restituzione di un codice di stato HTTP 401 al visualizzatore quando l'utente non ha eseguito la procedura di autenticazione

Una funzione Lambda@Edge può generare una risposta HTTP quando si verificano i seguenti eventi di CloudFront:

**Eventi di richiesta visualizzatore**  
Quando una funzione viene attivata da un evento di richiesta del visualizzatore, CloudFront restituisce la risposta al visualizzatore e non la memorizza nella cache.

**Eventi di richiesta origine**  
Quando una funzione viene attivata da un evento di richiesta di origine, CloudFront verifica nella cache edge la presenza di una risposta precedentemente generata dalla funzione.   
+ Se la risposta è nella cache, la funzione non viene eseguita e CloudFront restituisce la risposta memorizzata nella cache al visualizzatore.
+ Se la risposta non è nella cache, la funzione viene eseguita e CloudFront restituisce la risposta al visualizzatore e la memorizza nella cache.

Per vedere il codice di esempio per la generazione di risposte HTTP, consulta [Esempi di funzioni Lambda@Edge](lambda-examples.md). È inoltre possibile sostituire le risposte HTTP nei trigger di risposta. Per ulteriori informazioni, consulta [Aggiornamento delle risposte HTTP nei trigger di risposta origine](#lambda-updating-http-responses).

### Modello di programmazione
<a name="lambda-generating-http-responses-programming-model"></a>

Questa sezione descrive il modello di programmazione che consente di utilizzare Lambda@Edge per generare risposte HTTP.

**Topics**
+ [Oggetto Response](#lambda-generating-http-responses-object)
+ [Errori](#lambda-generating-http-responses-errors)
+ [Campi obbligatori](#lambda-generating-http-responses-required-fields)

#### Oggetto Response
<a name="lambda-generating-http-responses-object"></a>

La risposta che restituisci come parametro `result` del metodo `callback` deve avere la seguente struttura (nota che solo il campo `status` è obbligatorio).

```
const response = {
    body: 'content',
    bodyEncoding: 'text' | 'base64',
    headers: {
        'header name in lowercase': [{
            key: 'header name in standard case',
            value: 'header value'
         }],
         ...
    },
    status: 'HTTP status code (string)',
    statusDescription: 'status description'
};
```

L'oggetto di risposta può includere i seguenti valori:

**`body`**  
Il corpo, se presente, che si desidera CloudFront restituire nella risposta generata.

**`bodyEncoding`**  
La codifica per il valore che hai specificato in `body`. Le uniche codifiche valide sono `text` e `base64`. Se lo includete `body` nell'`response`oggetto ma lo omettete`bodyEncoding`, CloudFront considera il corpo come testo.  
Se specifichi `bodyEncoding` come `base64`, ma il corpo non è valido in base64, CloudFront restituisce un errore.

**`headers`**  
Intestazioni che desiderate CloudFront restituire nella risposta generata. Tenere presente quanto segue:  
+ Le chiavi nell'oggetto `headers` sono versioni in minuscolo di nomi di intestazione HTTP standard. L'utilizzo di chiavi in minuscolo fornisce accesso ai valori delle intestazioni senza distinzione tra maiuscole e minuscole.
+ Ogni intestazione (ad esempio, `headers["accept"]` o `headers["host"]`) è una matrice di coppie chiave-valore. Per una determinata intestazione, la matrice contiene una coppia chiave-valore per ogni valore nella risposta generata.
+ `key` (facoltativo) è il nome dell'intestazione con distinzione tra maiuscole e minuscole come visualizzato in una richiesta HTTP, ad esempio `accept` o `host`.
+ Specifica `value` come valore dell'intestazione.
+ Se non includi la chiave dell'intestazione parte della coppia chiave-valore, Lambda@Edge inserisce automaticamente una chiave dell'intestazione utilizzando il nome dell'intestazione che fornisci. Indipendentemente dalla formattazione del nome dell'intestazione, la chiave dell'intestazione automaticamente inserita sarà formattata con iniziale maiuscola per tutte le parti, separate da trattini (-).

  Ad esempio, è possibile aggiungere un'intestazione come quella seguente, senza una chiave dell'intestazione: `'content-type': [{ value: 'text/html;charset=UTF-8' }]`

  In questo esempio, Lambda@Edge crea la chiave dell'intestazione seguente: `Content-Type`.
Per informazioni sulle restrizioni di utilizzo delle intestazioni, consulta [Restrizioni sulle funzioni edge](edge-functions-restrictions.md).

**`status`**  
Codice di stato HTTP . Fornisci il codice di stato come stringa. CloudFront utilizza il codice di stato fornito per quanto segue:  
+ Restituzione nella risposta
+ Cache nella cache CloudFront edge, quando la risposta è stata generata da una funzione attivata da un evento di richiesta di origine
+ Effettua il login CloudFront [Registri di accesso (registri standard)](AccessLogs.md)
Se il valore `status` non è compreso tra 200 e 599, CloudFront restituisce un errore al visualizzatore.

**`statusDescription`**  
La descrizione che desideri CloudFront restituire nella risposta, da aggiungere al codice di stato HTTP. Non hai bisogno di utilizzare le descrizioni standard, ad esempio `OK` per un codice di stato HTTP 200.

#### Errori
<a name="lambda-generating-http-responses-errors"></a>

Di seguito sono riportati possibili errori per le risposte HTTP generate.

**La risposta contiene un corpo e specifica un codice di stato 204 (Nessun contenuto)**  
Quando una funzione viene attivata da una richiesta del visualizzatore, CloudFront restituisce un codice di stato HTTP 502 (Bad Gateway) al visualizzatore quando entrambe le seguenti condizioni sono vere:  
+ Il valore di `status` è 204 (Nessun contenuto)
+ La risposta include un valore per `body`
Questo perché Lambda@Edge impone la restrizione facoltativa inclusa in RFC 2616, che indica che una risposta `HTTP 204` non deve contenere un corpo di messaggio.

**Restrizioni relative alla dimensione della risposta generata**  
La dimensione massima di una risposta generata da una funzione Lambda dipende dall'evento che ha attivato la funzione:  
+ **Eventi di richiesta visualizzatore** - 40 KB
+ **Eventi di richiesta origine** - 1 MB
Se la risposta è maggiore della dimensione consentita, CloudFront restituisce un codice di stato HTTP 502 (Bad Gateway) al visualizzatore.

#### Campi obbligatori
<a name="lambda-generating-http-responses-required-fields"></a>

Il campo `status` è obbligatorio. 

Tutti gli altri campi sono facoltativi.

## Aggiornamento delle risposte HTTP nei trigger di risposta origine
<a name="lambda-updating-http-responses"></a>

Quando CloudFront riceve una risposta HTTP dal server di origine, se al comportamento della cache è associato un trigger di risposta all'origine, è possibile modificare la risposta HTTP per sovrascrivere ciò che è stato restituito dall'origine.

Alcuni scenari comuni per l'aggiornamento di risposte HTTP sono:
+ Modifica dello stato per impostare un codice di stato HTTP 200 e creazione di contenuto di corpo statico da restituire al visualizzatore quando un'origine restituisce un codice di stato di errore (4xx e 5xx). Per il codice di esempio, consulta [Esempio: utilizzo di un trigger di risposta origine per aggiornare il codice di stato di errore a 200](lambda-examples.md#lambda-examples-custom-error-static-body).
+ Modifica dello stato per impostare un codice di stato HTTP 301 o 302, al fine di reindirizzare l'utente a un altro sito Web quando un'origine restituisce un codice di stato di errore (4xx e 5xx). Per il codice di esempio, consulta [Esempio: utilizzo di un trigger di risposta origine per aggiornare il codice di stato di errore a 302](lambda-examples.md#lambda-examples-custom-error-new-site).

**Nota**  
La funzione deve restituire un valore di stato compreso tra `200` e `599` (incluso), altrimenti CloudFront restituisce un errore al visualizzatore.

È inoltre possibile sostituire le risposte HTTP negli eventi di richiesta origine e visualizzatore. Per ulteriori informazioni, consulta [Generazione di risposte HTTP in trigger di richiesta](#lambda-generating-http-responses-in-requests).

Quando utilizzi la risposta HTTP, Lambda@Edge non espone il corpo restituito dal server di origine al trigger di risposta origine. Puoi generare un corpo di contenuto statico impostandolo sul valore desiderato oppure rimuovere il corpo nella funzione impostando un valore vuoto. Se non aggiorni il campo del corpo nella funzione, il corpo originale restituito dal server di origine viene restituito al visualizzatore.

## Accesso al corpo della richiesta scegliendo l’opzione includi corpo
<a name="lambda-include-body-access"></a>

Ora puoi fare in modo che Lambda@Edge esponga il corpo in una richiesta per metodi HTTP con possibilità di scrittura (POST, PUT, DELETE e così via), in modo che tu possa accedervi dalla tua funzione Lambda. È possibile scegliere le autorizzazioni di accesso in sola lettura, oppure è possibile specificare che sarà possibile sostituire il corpo.

Per attivare questa opzione, scegli **Include Body (Includi corpo)** al momento della creazione di un trigger CloudFront per la tua funzione, per una richiesta di un visualizzatore o per un evento di richiesta del server di origine. Per ulteriori informazioni, consulta [Aggiunta di trigger per una funzione Lambda@Edge](lambda-edge-add-triggers.md) o per ulteriori informazioni su come usare **Include Body (Includi corpo)** con la tua funzione, vedi [Struttura dell'evento Lambda@Edge](lambda-event-structure.md).

Tra gli scenari in cui è possibile utilizzare questa funzionalità figurano i seguenti:
+ Elaborazione di moduli Web, ad esempio "Contattaci", senza l'invio di dati di input del cliente a server di origine.
+ Raccolta di dati di beacon Web inviati dai browser dei visualizzatori e l'elaborazione al confine.

Per il codice di esempio, consulta [Esempi di funzioni Lambda@Edge](lambda-examples.md).

**Nota**  
Se il corpo della richiesta è di grandi dimensioni, Lambda@Edge lo tronca. Per informazioni dettagliate sulle dimensioni massime e il troncamento, consulta [Restrizioni sul corpo della richiesta con l'opzione Includi corpo](lambda-at-edge-function-restrictions.md#lambda-at-edge-restrictions-request-body).

# Esempi di funzioni Lambda@Edge
<a name="lambda-examples"></a>

Guarda i seguenti esempi per utilizzare le funzioni Lambda con Amazon. CloudFront

**Nota**  
Se scegli Node.js 18 o versioni successive come runtime per la funzione Lambda@Edge, viene creato automaticamente un file `index.mjs`. Per utilizzare i seguenti esempi di codice, rinomina invece il file `index.mjs` in `index.js`.

**Topics**
+ [Esempi generali](#lambda-examples-general-examples)
+ [Generazione di risposte: esempi](#lambda-examples-generated-response-examples)
+ [Stringhe di query: esempi](#lambda-examples-query-string-examples)
+ [Esempi di personalizzazione del contenuto in base alle intestazioni del paese o del tipo di dispositivo](#lambda-examples-redirecting-examples)
+ [Esempi di selezione dinamica dell'origine in funzione del contenuto](#lambda-examples-content-based-routing-examples)
+ [Aggiornamento degli stati di errore: esempi](#lambda-examples-update-error-status-examples)
+ [Accesso al corpo della richiesta: esempi](#lambda-examples-access-request-body-examples)

## Esempi generali
<a name="lambda-examples-general-examples"></a>

Gli esempi seguenti mostrano i modi più comuni di usare Lambda @Edge in. CloudFront

**Topics**
+ [Esempio: test A/B](#lambda-examples-a-b-testing)
+ [Esempio: sostituzione di un’intestazione di risposta](#lambda-examples-overriding-response-header)

### Esempio: test A/B
<a name="lambda-examples-a-b-testing"></a>

È possibile utilizzare l'esempio seguente per testare due diverse versioni di un'immagine senza creare reindirizzamenti o modificare l'URL. Questo esempio legge i cookie nella richiesta del visualizzatore e modifica l'URL della richiesta di conseguenza. Se il visualizzatore non invia un cookie con uno dei valori previsti, l'esempio assegna casualmente il visualizzatore a uno dei. URLs

------
#### [ Node.js ]

```
'use strict';

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;
    const headers = request.headers;

    if (request.uri !== '/experiment-pixel.jpg') {
        // do not process if this is not an A-B test request
        callback(null, request);
        return;
    }

    const cookieExperimentA = 'X-Experiment-Name=A';
    const cookieExperimentB = 'X-Experiment-Name=B';
    const pathExperimentA = '/experiment-group/control-pixel.jpg';
    const pathExperimentB = '/experiment-group/treatment-pixel.jpg';

    /*
     * Lambda at the Edge headers are array objects.
     *
     * Client may send multiple Cookie headers, i.e.:
     * > GET /viewerRes/test HTTP/1.1
     * > User-Agent: curl/7.18.1 (x86_64-unknown-linux-gnu) libcurl/7.18.1 OpenSSL/1.0.1u zlib/1.2.3
     * > Cookie: First=1; Second=2
     * > Cookie: ClientCode=abc
     * > Host: example.com
     *
     * You can access the first Cookie header at headers["cookie"][0].value
     * and the second at headers["cookie"][1].value.
     *
     * Header values are not parsed. In the example above,
     * headers["cookie"][0].value is equal to "First=1; Second=2"
     */
    let experimentUri;
    if (headers.cookie) {
        for (let i = 0; i < headers.cookie.length; i++) {
            if (headers.cookie[i].value.indexOf(cookieExperimentA) >= 0) {
                console.log('Experiment A cookie found');
                experimentUri = pathExperimentA;
                break;
            } else if (headers.cookie[i].value.indexOf(cookieExperimentB) >= 0) {
                console.log('Experiment B cookie found');
                experimentUri = pathExperimentB;
                break;
            }
        }
    }

    if (!experimentUri) {
        console.log('Experiment cookie has not been found. Throwing dice...');
        if (Math.random() < 0.75) {
            experimentUri = pathExperimentA;
        } else {
            experimentUri = pathExperimentB;
        }
    }

    request.uri = experimentUri;
    console.log(`Request uri set to "${request.uri}"`);
    callback(null, request);
};
```

------
#### [ Python ]

```
import json
import random

def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']
    headers = request['headers']

    if request['uri'] != '/experiment-pixel.jpg':
        # Not an A/B Test
        return request

    cookieExperimentA, cookieExperimentB = 'X-Experiment-Name=A', 'X-Experiment-Name=B'
    pathExperimentA, pathExperimentB = '/experiment-group/control-pixel.jpg', '/experiment-group/treatment-pixel.jpg'

    '''
    Lambda at the Edge headers are array objects.

    Client may send multiple cookie headers. For example:
    > GET /viewerRes/test HTTP/1.1
    > User-Agent: curl/7.18.1 (x86_64-unknown-linux-gnu) libcurl/7.18.1 OpenSSL/1.0.1u zlib/1.2.3
    > Cookie: First=1; Second=2
    > Cookie: ClientCode=abc
    > Host: example.com

    You can access the first Cookie header at headers["cookie"][0].value
    and the second at headers["cookie"][1].value.

    Header values are not parsed. In the example above,
    headers["cookie"][0].value is equal to "First=1; Second=2"
    '''

    experimentUri = ""

    for cookie in headers.get('cookie', []):
        if cookieExperimentA in cookie['value']:
            print("Experiment A cookie found")
            experimentUri = pathExperimentA
            break
        elif cookieExperimentB in cookie['value']:
            print("Experiment B cookie found")
            experimentUri = pathExperimentB
            break

    if not experimentUri:
        print("Experiment cookie has not been found. Throwing dice...")
        if random.random() < 0.75:
            experimentUri = pathExperimentA
        else:
            experimentUri = pathExperimentB

    request['uri'] = experimentUri
    print(f"Request uri set to {experimentUri}")
    return request
```

------

### Esempio: sostituzione di un’intestazione di risposta
<a name="lambda-examples-overriding-response-header"></a>

L'esempio seguente mostra come modificare il valore di un'intestazione di risposta in base al valore di un'altra intestazione.

------
#### [ Node.js ]

```
export const handler = async (event) => {
    const response = event.Records[0].cf.response;
    const headers = response.headers;

    const headerNameSrc = 'X-Amz-Meta-Last-Modified';
    const headerNameDst = 'Last-Modified';

    if (headers[headerNameSrc.toLowerCase()]) {
        headers[headerNameDst.toLowerCase()] = [{
            key: headerNameDst,
            value: headers[headerNameSrc.toLowerCase()][0].value,
        }];
        console.log(`Response header "${headerNameDst}" was set to ` +
                    `"${headers[headerNameDst.toLowerCase()][0].value}"`);
    }

    return response;
};
```

------
#### [ Python ]

```
import json 

def lambda_handler(event, context):
    response = event['Records'][0]['cf']['response']
    headers = response['headers']
    
    header_name_src = 'X-Amz-Meta-Last-Modified'
    header_name_dst = 'Last-Modified'
    
    if headers.get(header_name_src.lower()):
        headers[header_name_dst.lower()] = [{
            'key': header_name_dst,
            'value': headers[header_name_src.lower()][0]['value']
        }]
        print(f'Response header "{header_name_dst}" was set to '
              f'"{headers[header_name_dst.lower()][0]["value"]}"')
    
    return response
```

------

## Generazione di risposte: esempi
<a name="lambda-examples-generated-response-examples"></a>

Gli esempi seguenti illustrano come è possibile usare Lambda@Edge per generare risposte.

**Topics**
+ [Esempio: distribuzione di contenuto statico (risposta generata)](#lambda-examples-static-web-server)
+ [Esempio: generazione di un reindirizzamento HTTP (risposta generata)](#lambda-examples-http-redirect)

### Esempio: distribuzione di contenuto statico (risposta generata)
<a name="lambda-examples-static-web-server"></a>

L'esempio seguente mostra come utilizzare una funzione Lambda per distribuire contenuto Web statico e quindi ridurre il carico sul server di origine e la latenza complessiva. 

**Nota**  
È possibile generare risposte HTTP solo per eventi di richiesta origine e visualizzatore. Per ulteriori informazioni, consulta [Generazione di risposte HTTP in trigger di richiesta](lambda-generating-http-responses.md#lambda-generating-http-responses-in-requests).  
È inoltre possibile sostituire o rimuovere il corpo della risposta HTTP negli eventi di richiesta origine. Per ulteriori informazioni, consulta [Aggiornamento delle risposte HTTP nei trigger di risposta origine](lambda-generating-http-responses.md#lambda-updating-http-responses).

------
#### [ Node.js ]

```
'use strict';

const content = `
<\!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Simple Lambda@Edge Static Content Response</title>
  </head>
  <body>
    <p>Hello from Lambda@Edge!</p>
  </body>
</html>
`;

exports.handler = (event, context, callback) => {
    /*
     * Generate HTTP OK response using 200 status code with HTML body.
     */
    const response = {
        status: '200',
        statusDescription: 'OK',
        headers: {
            'cache-control': [{
                key: 'Cache-Control',
                value: 'max-age=100'
            }],
            'content-type': [{
                key: 'Content-Type',
                value: 'text/html'
            }]
        },
        body: content,
    };
    callback(null, response);
};
```

------
#### [ Python ]

```
import json

CONTENT = """
<\!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <title>Simple Lambda@Edge Static Content Response</title>
</head>
<body>
    <p>Hello from Lambda@Edge!</p>
</body>
</html>
"""

def lambda_handler(event, context):
    # Generate HTTP OK response using 200 status code with HTML body.
    response = {
        'status': '200',
        'statusDescription': 'OK',
        'headers': {
            'cache-control': [
                {
                    'key': 'Cache-Control',
                    'value': 'max-age=100'
                }
            ],
            "content-type": [
                {
                    'key': 'Content-Type',
                    'value': 'text/html'
                }
            ]
        },
        'body': CONTENT
    }
    return response
```

------

### Esempio: generazione di un reindirizzamento HTTP (risposta generata)
<a name="lambda-examples-http-redirect"></a>

L'esempio seguente mostra come generare un reindirizzamento HTTP.

**Nota**  
È possibile generare risposte HTTP solo per eventi di richiesta origine e visualizzatore. Per ulteriori informazioni, consulta [Generazione di risposte HTTP in trigger di richiesta](lambda-generating-http-responses.md#lambda-generating-http-responses-in-requests).

------
#### [ Node.js ]

```
'use strict';

exports.handler = (event, context, callback) => {
    /*
     * Generate HTTP redirect response with 302 status code and Location header.
     */
    const response = {
        status: '302',
        statusDescription: 'Found',
        headers: {
            location: [{
                key: 'Location',
                value: 'https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html',
            }],
        },
    };
    callback(null, response);
};
```

------
#### [ Python ]

```
def lambda_handler(event, context):

    # Generate HTTP redirect response with 302 status code and Location header.

    response = {
        'status': '302',
        'statusDescription': 'Found',
        'headers': {
            'location': [{
                'key': 'Location',
                'value': 'https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html'
            }]
        }
    }

    return response
```

------

## Stringhe di query: esempi
<a name="lambda-examples-query-string-examples"></a>

Gli esempi seguenti illustrano i modi in cui è possibile usare Lambda@Edge con le stringhe di query.

**Topics**
+ [Esempio: aggiunta di un’intestazione in base a un parametro di stringa di query](#lambda-examples-header-based-on-query-string)
+ [Esempio: normalizzazione dei parametri di stringa di query per migliorare il numero di riscontri nella cache](#lambda-examples-normalize-query-string-parameters)
+ [Esempio: reindirizzamento di utenti non autenticati a un pagina di accesso](#lambda-examples-redirect-to-signin-page)

### Esempio: aggiunta di un’intestazione in base a un parametro di stringa di query
<a name="lambda-examples-header-based-on-query-string"></a>

L'esempio seguente mostra come ottenere la coppia chiave-valore di un parametro di stringa di query e aggiungere quindi un'intestazione in base a tali valori.

------
#### [ Node.js ]

```
'use strict';

const querystring = require('querystring');
exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;
    
    /* When a request contains a query string key-value pair but the origin server
     * expects the value in a header, you can use this Lambda function to
     * convert the key-value pair to a header. Here's what the function does:
     * 1. Parses the query string and gets the key-value pair.
     * 2. Adds a header to the request using the key-value pair that the function got in step 1.
     */

    /* Parse request querystring to get javascript object */
    const params = querystring.parse(request.querystring);

    /* Move auth param from querystring to headers */
    const headerName = 'Auth-Header';
    request.headers[headerName.toLowerCase()] = [{ key: headerName, value: params.auth }];
    delete params.auth;

    /* Update request querystring */
    request.querystring = querystring.stringify(params);

    callback(null, request);
};
```

------
#### [ Python ]

```
from urllib.parse import parse_qs, urlencode

def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']

    '''
    When a request contains a query string key-value pair but the origin server
    expects the value in a header, you can use this Lambda function to
    convert the key-value pair to a header. Here's what the function does:
        1. Parses the query string and gets the key-value pair.
        2. Adds a header to the request using the key-value pair that the function got in step 1.
    '''

    # Parse request querystring to get dictionary/json
    params = {k : v[0] for k, v in parse_qs(request['querystring']).items()}

    # Move auth param from querystring to headers
    headerName = 'Auth-Header'
    request['headers'][headerName.lower()] = [{'key': headerName, 'value': params['auth']}]
    del params['auth']

    # Update request querystring
    request['querystring'] = urlencode(params)

    return request
```

------

### Esempio: normalizzazione dei parametri di stringa di query per migliorare il numero di riscontri nella cache
<a name="lambda-examples-normalize-query-string-parameters"></a>

L'esempio seguente mostra come migliorare il rapporto di accesso alla cache apportando le seguenti modifiche alle stringhe di query prima di CloudFront inoltrare le richieste all'origine:
+ Ordina alfabeticamente le coppie chiave-valore in base al nome del parametro
+ Cambia le coppie chiave-valore da maiuscolo in minuscolo

Per ulteriori informazioni, consulta [Memorizzazione nella cache di contenuti basati su parametri delle stringhe di query](QueryStringParameters.md).

------
#### [ Node.js ]

```
'use strict';

const querystring = require('querystring');

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;
    /* When you configure a distribution to forward query strings to the origin and
     * to cache based on an allowlist of query string parameters, we recommend
     * the following to improve the cache-hit ratio:
     * - Always list parameters in the same order.
     * - Use the same case for parameter names and values.
     *
     * This function normalizes query strings so that parameter names and values
     * are lowercase and parameter names are in alphabetical order.
     *
     * For more information, see:
     * https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/QueryStringParameters.html
     */

    console.log('Query String: ', request.querystring);

    /* Parse request query string to get javascript object */
    const params = querystring.parse(request.querystring.toLowerCase());
    const sortedParams = {};

    /* Sort param keys */
    Object.keys(params).sort().forEach(key => {
        sortedParams[key] = params[key];
    });

    /* Update request querystring with normalized  */
    request.querystring = querystring.stringify(sortedParams);

    callback(null, request);
};
```

------
#### [ Python ]

```
from urllib.parse import parse_qs, urlencode

def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']
    '''
    When you configure a distribution to forward query strings to the origin and
    to cache based on an allowlist of query string parameters, we recommend
    the following to improve the cache-hit ratio:
    Always list parameters in the same order.
    - Use the same case for parameter names and values.

    This function normalizes query strings so that parameter names and values
    are lowercase and parameter names are in alphabetical order.

    For more information, see:
    https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/QueryStringParameters.html
    '''
    print("Query string: ", request["querystring"])

    # Parse request query string to get js object
    params = {k : v[0] for k, v in parse_qs(request['querystring'].lower()).items()}

    # Sort param keys
    sortedParams = sorted(params.items(), key=lambda x: x[0])

    # Update request querystring with normalized
    request['querystring'] = urlencode(sortedParams)
    
    return request
```

------

### Esempio: reindirizzamento di utenti non autenticati a un pagina di accesso
<a name="lambda-examples-redirect-to-signin-page"></a>

L'esempio seguente mostra come reindirizzare gli utenti a una pagina di accesso se non hanno immesso le loro credenziali.

------
#### [ Node.js ]

```
'use strict';

function parseCookies(headers) {
    const parsedCookie = {};
    if (headers.cookie) {
        headers.cookie[0].value.split(';').forEach((cookie) => {
            if (cookie) {
                const parts = cookie.split('=');
                parsedCookie[parts[0].trim()] = parts[1].trim();
            }
        });
    }
    return parsedCookie;
}

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;
    const headers = request.headers;

    /* Check for session-id in request cookie in viewer-request event,
     * if session-id is absent, redirect the user to sign in page with original
     * request sent as redirect_url in query params.
     */

    /* Check for session-id in cookie, if present then proceed with request */
    const parsedCookies = parseCookies(headers);
    if (parsedCookies && parsedCookies['session-id']) {
        callback(null, request);
        return;
    }

    /* URI encode the original request to be sent as redirect_url in query params */
    const encodedRedirectUrl = encodeURIComponent(`https://${headers.host[0].value}${request.uri}?${request.querystring}`);
    const response = {
        status: '302',
        statusDescription: 'Found',
        headers: {
            location: [{
                key: 'Location',
                value: `https://www.example.com/signin?redirect_url=${encodedRedirectUrl}`,
            }],
        },
    };
    callback(null, response);
};
```

------
#### [ Python ]

```
import urllib

def parseCookies(headers):
    parsedCookie = {}
    if headers.get('cookie'):
        for cookie in headers['cookie'][0]['value'].split(';'):
            if cookie:
                parts = cookie.split('=')
                parsedCookie[parts[0].strip()] = parts[1].strip()
    return parsedCookie

def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']
    headers = request['headers']

    '''
    Check for session-id in request cookie in viewer-request event,
    if session-id is absent, redirect the user to sign in page with original
    request sent as redirect_url in query params.
    '''

    # Check for session-id in cookie, if present, then proceed with request
    parsedCookies = parseCookies(headers)

    if parsedCookies and parsedCookies['session-id']:
        return request

    # URI encode the original request to be sent as redirect_url in query params
    redirectUrl = "https://%s%s?%s" % (headers['host'][0]['value'], request['uri'], request['querystring'])
    encodedRedirectUrl = urllib.parse.quote_plus(redirectUrl.encode('utf-8'))

    response = {
        'status': '302',
        'statusDescription': 'Found',
        'headers': {
            'location': [{
                'key': 'Location',
                'value': 'https://www.example.com/signin?redirect_url=%s' % encodedRedirectUrl
            }]
        }
    }
    return response
```

------

## Esempi di personalizzazione del contenuto in base alle intestazioni del paese o del tipo di dispositivo
<a name="lambda-examples-redirecting-examples"></a>

Gli esempi seguenti illustrano come utilizzare Lambda@Edge per personalizzare il comportamento in base alla posizione o al tipo di dispositivo usato dal visualizzatore.

**Topics**
+ [Esempio: reindirizzamento di richieste visualizzatore a un URL specifico di un paese](#lambda-examples-redirect-based-on-country)
+ [Esempio: distribuzione di versioni differenti di un oggetto in base al dispositivo](#lambda-examples-vary-on-device-type)

### Esempio: reindirizzamento di richieste visualizzatore a un URL specifico di un paese
<a name="lambda-examples-redirect-based-on-country"></a>

L'esempio seguente mostra come generare una risposta di reindirizzamento HTTP con un URL specifico di un paese e restituire la risposta al visualizzatore. Ciò è utile quando intendi fornire risposte relative a un paese. Ad esempio:
+ Se hai sottodomini specifici di un paese, ad esempio us.example.com e tw.example.com, puoi generare una risposta di reindirizzamento quando un visualizzatore richiede example.com.
+ Se stai eseguendo lo streaming di video, ma non disponi dei diritti per lo streaming di contenuto in un determinato paese, puoi reindirizzare gli utenti in quel paese a una pagina che spiega perché non sono in grado di riprodurre il video. 

Tieni presente quanto segue:
+ Devi configurare la tua distribuzione in modo tale che la memorizzazione nella cache venga eseguita in base all'intestazione `CloudFront-Viewer-Country`. Per ulteriori informazioni, consulta [Cache Based on Selected Request Headers (Cache in base a intestazioni di richiesta selezionate)](DownloadDistValuesCacheBehavior.md#DownloadDistValuesForwardHeaders).
+ CloudFront aggiunge l'`CloudFront-Viewer-Country`intestazione dopo l'evento di richiesta del visualizzatore. Per utilizzare questo esempio, devi creare un trigger per l'evento di richiesta origine.

------
#### [ Node.js ]

```
'use strict';

/* This is an origin request function */
exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;
    const headers = request.headers;

    /*
     * Based on the value of the CloudFront-Viewer-Country header, generate an
     * HTTP status code 302 (Redirect) response, and return a country-specific
     * URL in the Location header.
     * NOTE: 1. You must configure your distribution to cache based on the
     *          CloudFront-Viewer-Country header. For more information, see
     *          https://docs.aws.amazon.com/console/cloudfront/cache-on-selected-headers
     *       2. CloudFront adds the CloudFront-Viewer-Country header after the viewer
     *          request event. To use this example, you must create a trigger for the
     *          origin request event.
     */

    let url = 'https://example.com/';
    if (headers['cloudfront-viewer-country']) {
        const countryCode = headers['cloudfront-viewer-country'][0].value;
        if (countryCode === 'TW') {
            url = 'https://tw.example.com/';
        } else if (countryCode === 'US') {
            url = 'https://us.example.com/';
        }
    }

    const response = {
        status: '302',
        statusDescription: 'Found',
        headers: {
            location: [{
                key: 'Location',
                value: url,
            }],
        },
    };
    callback(null, response);
};
```

------
#### [ Python ]

```
# This is an origin request function

def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']
    headers = request['headers']

    '''
    Based on the value of the CloudFront-Viewer-Country header, generate an
    HTTP status code 302 (Redirect) response, and return a country-specific
    URL in the Location header.
    NOTE: 1. You must configure your distribution to cache based on the
            CloudFront-Viewer-Country header. For more information, see
            https://docs.aws.amazon.com/console/cloudfront/cache-on-selected-headers
          2. CloudFront adds the CloudFront-Viewer-Country header after the viewer
            request event. To use this example, you must create a trigger for the
            origin request event.
    '''

    url = 'https://example.com/'
    viewerCountry = headers.get('cloudfront-viewer-country')
    if viewerCountry:
        countryCode = viewerCountry[0]['value']
        if countryCode == 'TW':
            url = 'https://tw.example.com/'
        elif countryCode == 'US':
            url = 'https://us.example.com/'

    response = {
        'status': '302',
        'statusDescription': 'Found',
        'headers': {
            'location': [{
                'key': 'Location',
                'value': url
            }]
        }
    }

    return response
```

------

### Esempio: distribuzione di versioni differenti di un oggetto in base al dispositivo
<a name="lambda-examples-vary-on-device-type"></a>

L'esempio seguente mostra come servire diverse versioni di un oggetto in base al tipo di dispositivo che l'utente sta utilizzando, ad esempio, un dispositivo mobile o un tablet. Tieni presente quanto segue:
+ Devi configurare la tua distribuzione in modo tale che la memorizzazione nella cache venga eseguita in base all'intestazione `CloudFront-Is-*-Viewer`. Per ulteriori informazioni, consulta [Cache Based on Selected Request Headers (Cache in base a intestazioni di richiesta selezionate)](DownloadDistValuesCacheBehavior.md#DownloadDistValuesForwardHeaders).
+ CloudFront aggiunge le `CloudFront-Is-*-Viewer` intestazioni dopo l'evento di richiesta del visualizzatore. Per utilizzare questo esempio, devi creare un trigger per l'evento di richiesta origine.

------
#### [ Node.js ]

```
'use strict';

/* This is an origin request function */
exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;
    const headers = request.headers;

    /*
     * Serve different versions of an object based on the device type.
     * NOTE: 1. You must configure your distribution to cache based on the
     *          CloudFront-Is-*-Viewer headers. For more information, see
     *          the following documentation:
     *          https://docs.aws.amazon.com/console/cloudfront/cache-on-selected-headers
     *          https://docs.aws.amazon.com/console/cloudfront/cache-on-device-type
     *       2. CloudFront adds the CloudFront-Is-*-Viewer headers after the viewer
     *          request event. To use this example, you must create a trigger for the
     *          origin request event.
     */

    const desktopPath = '/desktop';
    const mobilePath = '/mobile';
    const tabletPath = '/tablet';
    const smarttvPath = '/smarttv';

    if (headers['cloudfront-is-desktop-viewer']
        && headers['cloudfront-is-desktop-viewer'][0].value === 'true') {
        request.uri = desktopPath + request.uri;
    } else if (headers['cloudfront-is-mobile-viewer']
               && headers['cloudfront-is-mobile-viewer'][0].value === 'true') {
        request.uri = mobilePath + request.uri;
    } else if (headers['cloudfront-is-tablet-viewer']
               && headers['cloudfront-is-tablet-viewer'][0].value === 'true') {
        request.uri = tabletPath + request.uri;
    } else if (headers['cloudfront-is-smarttv-viewer']
               && headers['cloudfront-is-smarttv-viewer'][0].value === 'true') {
        request.uri = smarttvPath + request.uri;
    }
    console.log(`Request uri set to "${request.uri}"`);

    callback(null, request);
};
```

------
#### [ Python ]

```
# This is an origin request function
def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']
    headers = request['headers']

    '''
    Serve different versions of an object based on the device type.
    NOTE: 1. You must configure your distribution to cache based on the
            CloudFront-Is-*-Viewer headers. For more information, see
            the following documentation:
            https://docs.aws.amazon.com/console/cloudfront/cache-on-selected-headers
            https://docs.aws.amazon.com/console/cloudfront/cache-on-device-type
          2. CloudFront adds the CloudFront-Is-*-Viewer headers after the viewer
            request event. To use this example, you must create a trigger for the
            origin request event.
    '''

    desktopPath = '/desktop';
    mobilePath = '/mobile';
    tabletPath = '/tablet';
    smarttvPath = '/smarttv';

    if 'cloudfront-is-desktop-viewer' in headers and headers['cloudfront-is-desktop-viewer'][0]['value'] == 'true':
        request['uri'] = desktopPath + request['uri']
    elif 'cloudfront-is-mobile-viewer' in headers and headers['cloudfront-is-mobile-viewer'][0]['value'] == 'true':
        request['uri'] = mobilePath + request['uri']
    elif 'cloudfront-is-tablet-viewer' in headers and headers['cloudfront-is-tablet-viewer'][0]['value'] == 'true':
        request['uri'] = tabletPath + request['uri']
    elif 'cloudfront-is-smarttv-viewer' in headers and headers['cloudfront-is-smarttv-viewer'][0]['value'] == 'true':
        request['uri'] = smarttvPath + request['uri']

    print("Request uri set to %s" % request['uri'])

    return request
```

------

## Esempi di selezione dinamica dell'origine in funzione del contenuto
<a name="lambda-examples-content-based-routing-examples"></a>

Gli esempi seguenti mostrano in che modo è possibile usare Lambda@Edge per l’instradamento a diverse origini in base alle informazioni nella richiesta.

**Topics**
+ [Esempio: utilizzo di un trigger di richiesta origine per passare da un’origine personalizzata a un’origine Amazon S3](#lambda-examples-content-based-S3-origin-based-on-query)
+ [Esempio: utilizzo di un trigger di richiesta origine per modificare la Regione dell’origine Amazon S3](#lambda-examples-content-based-S3-origin-request-trigger)
+ [Esempio: utilizzo di un trigger di richiesta origine per passare da un’origine Amazon S3 a un’origine personalizzata](#lambda-examples-content-based-custom-origin-request-trigger)
+ [Esempio: utilizzo di un trigger di richiesta origine per trasferire progressivamente il traffico da un bucket Amazon S3 a un altro](#lambda-examples-content-based-gradual-traffic-transfer)
+ [Esempio: utilizzo di un trigger di richiesta origine per modificare il nome di dominio dell’origine in base all’intestazione del paese](#lambda-examples-content-based-geo-header)

### Esempio: utilizzo di un trigger di richiesta origine per passare da un’origine personalizzata a un’origine Amazon S3
<a name="lambda-examples-content-based-S3-origin-based-on-query"></a>

Questa funzione mostra come utilizzare un trigger di richiesta origine per passare da un'origine personalizzata a un'origine Amazon S3 da cui il contenuto viene recuperato, in base alle proprietà della richiesta.

------
#### [ Node.js ]

```
'use strict';

 const querystring = require('querystring');
 
 exports.handler = (event, context, callback) => {
     const request = event.Records[0].cf.request;
 
     /**
      * Reads query string to check if S3 origin should be used, and
      * if true, sets S3 origin properties.
      */
 
     const params = querystring.parse(request.querystring);
 
     if (params['useS3Origin']) {
         if (params['useS3Origin'] === 'true') {
             const s3DomainName = 'amzn-s3-demo-bucket.s3.amazonaws.com';
 
             /* Set S3 origin fields */
             request.origin = {
                 s3: {
                     domainName: s3DomainName,
                     region: '',
                     authMethod: 'origin-access-identity',
                     path: '',
                     customHeaders: {}
                 }
             };
             request.headers['host'] = [{ key: 'host', value: s3DomainName}];
         }
     }
     
    callback(null, request);
};
```

------
#### [ Python ]

```
from urllib.parse import parse_qs

def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']
    '''
    Reads query string to check if S3 origin should be used, and
    if true, sets S3 origin properties
    '''
    params = {k: v[0] for k, v in parse_qs(request['querystring']).items()}
    if params.get('useS3Origin') == 'true':
        s3DomainName = 'amzn-s3-demo-bucket.s3.amazonaws.com'

        # Set S3 origin fields
        request['origin'] = {
            's3': {
                'domainName': s3DomainName,
                'region': '',
                'authMethod': 'origin-access-identity',
                'path': '',
                'customHeaders': {}
            }
        }
        request['headers']['host'] = [{'key': 'host', 'value': s3DomainName}]
    return request
```

------

### Esempio: utilizzo di un trigger di richiesta origine per modificare la Regione dell’origine Amazon S3
<a name="lambda-examples-content-based-S3-origin-request-trigger"></a>

Questa funzione mostra come utilizzare un trigger di richiesta origine per modificare l'origine Amazon S3 da cui viene recuperato il contenuto, in base alle proprietà della richiesta.

In questo esempio viene utilizzato il valore dell'intestazione `CloudFront-Viewer-Country` per aggiornare il nome di dominio del bucket S3 in un bucket in una regione più vicina al visualizzatore. Questa modifica può essere utile per vari motivi:
+ Riduce le latenze quando la regione specificata è più vicina al paese del visualizzatore.
+ Consente il controllo dei dati verificando che siano serviti da un'origine nello stesso paese in cui è stata effettuata la richiesta.

Per utilizzare questo esempio, è necessario eseguire le operazioni indicate di seguito:
+ Configurare la tua distribuzione in modo tale che la memorizzazione nella cache venga eseguita in base all'intestazione `CloudFront-Viewer-Country`. Per ulteriori informazioni, consulta [Cache Based on Selected Request Headers (Cache in base a intestazioni di richiesta selezionate)](DownloadDistValuesCacheBehavior.md#DownloadDistValuesForwardHeaders). 
+ Crea un trigger per questa funzione nell'evento origin request. CloudFrontaggiunge l'`CloudFront-Viewer-Country`intestazione dopo l'evento viewer request, quindi per usare questo esempio, devi assicurarti che la funzione venga eseguita per una richiesta di origine.

**Nota**  
Il codice di esempio seguente utilizza la stessa identità di accesso origine (OAI) per tutti i bucket S3 utilizzati per l’origine. Per ulteriori informazioni, consulta [Identità di accesso origine](private-content-restricting-access-to-s3.md#private-content-restricting-access-to-s3-oai).

------
#### [ Node.js ]

```
'use strict';

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;

    /**
     * This blueprint demonstrates how an origin-request trigger can be used to
     * change the origin from which the content is fetched, based on request properties.
     * In this example, we use the value of the CloudFront-Viewer-Country header
     * to update the S3 bucket domain name to a bucket in a Region that is closer to
     * the viewer.
     * 
     * This can be useful in several ways:
     *      1) Reduces latencies when the Region specified is nearer to the viewer's
     *         country.
     *      2) Provides data sovereignty by making sure that data is served from an
     *         origin that's in the same country that the request came from.
     * 
     * NOTE: 1. You must configure your distribution to cache based on the
     *          CloudFront-Viewer-Country header. For more information, see
     *          https://docs.aws.amazon.com/console/cloudfront/cache-on-selected-headers
     *       2. CloudFront adds the CloudFront-Viewer-Country header after the viewer
     *          request event. To use this example, you must create a trigger for the
     *          origin request event.
     */

    const countryToRegion = {
        'DE': 'eu-central-1',
        'IE': 'eu-west-1',
        'GB': 'eu-west-2',
        'FR': 'eu-west-3',
        'JP': 'ap-northeast-1',
        'IN': 'ap-south-1'
    };

    if (request.headers['cloudfront-viewer-country']) {
        const countryCode = request.headers['cloudfront-viewer-country'][0].value;
        const region = countryToRegion[countryCode];
        
        /**
         * If the viewer's country is not in the list you specify, the request
         * goes to the default S3 bucket you've configured.
         */  
        if (region) {
            /**
             * If you've set up OAI, the bucket policy in the destination bucket
             * should allow the OAI GetObject operation, as configured by default
             * for an S3 origin with OAI. Another requirement with OAI is to provide
             * the Region so it can be used for the SIGV4 signature. Otherwise, the
             * Region is not required.
             */
            request.origin.s3.region = region;
            const domainName = `amzn-s3-demo-bucket-in-${region}.s3.${region}.amazonaws.com`;
            request.origin.s3.domainName = domainName;
            request.headers['host'] = [{ key: 'host', value: domainName }];
        }
    }

    callback(null, request);
};
```

------
#### [ Python ]

```
def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']

    '''
    This blueprint demonstrates how an origin-request trigger can be used to
    change the origin from which the content is fetched, based on request properties.
    In this example, we use the value of the CloudFront-Viewer-Country header
    to update the S3 bucket domain name to a bucket in a Region that is closer to
    the viewer.
    
    This can be useful in several ways:
        1) Reduces latencies when the Region specified is nearer to the viewer's
            country.
        2) Provides data sovereignty by making sure that data is served from an
            origin that's in the same country that the request came from.
    
    NOTE: 1. You must configure your distribution to cache based on the
            CloudFront-Viewer-Country header. For more information, see
            https://docs.aws.amazon.com/console/cloudfront/cache-on-selected-headers
          2. CloudFront adds the CloudFront-Viewer-Country header after the viewer
            request event. To use this example, you must create a trigger for the
            origin request event.
    '''

    countryToRegion = {
        'DE': 'eu-central-1',
        'IE': 'eu-west-1',
        'GB': 'eu-west-2',
        'FR': 'eu-west-3',
        'JP': 'ap-northeast-1',
        'IN': 'ap-south-1'
    }

    viewerCountry = request['headers'].get('cloudfront-viewer-country')
    if viewerCountry:
        countryCode = viewerCountry[0]['value']
        region = countryToRegion.get(countryCode)

        # If the viewer's country in not in the list you specify, the request
        # goes to the default S3 bucket you've configured
        if region:
            '''
            If you've set up OAI, the bucket policy in the destination bucket
            should allow the OAI GetObject operation, as configured by default
            for an S3 origin with OAI. Another requirement with OAI is to provide
            the Region so it can be used for the SIGV4 signature. Otherwise, the
            Region is not required.
            '''
            request['origin']['s3']['region'] = region
            domainName = 'amzn-s3-demo-bucket-in-{0}.s3.{0}.amazonaws.com'.format(region)
            request['origin']['s3']['domainName'] = domainName
            request['headers']['host'] = [{'key': 'host', 'value': domainName}]

    return request
```

------

### Esempio: utilizzo di un trigger di richiesta origine per passare da un’origine Amazon S3 a un’origine personalizzata
<a name="lambda-examples-content-based-custom-origin-request-trigger"></a>

Questa funzione mostra come utilizzare un trigger di richiesta origine per passare all'origine personalizzata da cui viene recuperato il contenuto in base alle proprietà della richiesta.

------
#### [ Node.js ]

```
'use strict';

const querystring = require('querystring');
 
 exports.handler = (event, context, callback) => {
     const request = event.Records[0].cf.request;
 
     /**
      * Reads query string to check if custom origin should be used, and
      * if true, sets custom origin properties.
      */
 
     const params = querystring.parse(request.querystring);
 
     if (params['useCustomOrigin']) {
         if (params['useCustomOrigin'] === 'true') {
 
             /* Set custom origin fields*/
             request.origin = {
                 custom: {
                     domainName: 'www.example.com',
                     port: 443,
                     protocol: 'https',
                     path: '',
                     sslProtocols: ['TLSv1', 'TLSv1.1'],
                     readTimeout: 5,
                     keepaliveTimeout: 5,
                     customHeaders: {}
                 }
             };
             request.headers['host'] = [{ key: 'host', value: 'www.example.com'}];
         }
     }
    callback(null, request);
};
```

------
#### [ Python ]

```
from urllib.parse import parse_qs

def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']

    # Reads query string to check if custom origin should be used, and
    # if true, sets custom origin properties

    params = {k: v[0] for k, v in parse_qs(request['querystring']).items()}

    if params.get('useCustomOrigin') == 'true':
            # Set custom origin fields
            request['origin'] = {
                'custom': {
                    'domainName': 'www.example.com',
                    'port': 443,
                    'protocol': 'https',
                    'path': '',
                    'sslProtocols': ['TLSv1', 'TLSv1.1'],
                    'readTimeout': 5,
                    'keepaliveTimeout': 5,
                    'customHeaders': {}
                }
            }
            request['headers']['host'] = [{'key': 'host', 'value': 'www.example.com'}]

    return request
```

------

### Esempio: utilizzo di un trigger di richiesta origine per trasferire progressivamente il traffico da un bucket Amazon S3 a un altro
<a name="lambda-examples-content-based-gradual-traffic-transfer"></a>

Questa funzione mostra come è possibile trasferire progressivamente il traffico da un bucket Amazon S3 a un altro in modo controllato.

------
#### [ Node.js ]

```
'use strict';

    function getRandomInt(min, max) {
        /* Random number is inclusive of min and max*/
        return Math.floor(Math.random() * (max - min + 1)) + min;
 }

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;
    const BLUE_TRAFFIC_PERCENTAGE = 80;

    /**
      * This Lambda function demonstrates how to gradually transfer traffic from
      * one S3 bucket to another in a controlled way.
      * We define a variable BLUE_TRAFFIC_PERCENTAGE which can take values from
      * 1 to 100. If the generated randomNumber less than or equal to BLUE_TRAFFIC_PERCENTAGE, traffic
      * is re-directed to blue-bucket. If not, the default bucket that we've configured
      * is used.
      */

    const randomNumber = getRandomInt(1, 100);

if (randomNumber <= BLUE_TRAFFIC_PERCENTAGE) {
         const domainName = 'blue-bucket.s3.amazonaws.com';
         request.origin.s3.domainName = domainName;
         request.headers['host'] = [{ key: 'host', value: domainName}];
     }
    callback(null, request);
};
```

------
#### [ Python ]

```
import math
import random

def getRandomInt(min, max):
    # Random number is inclusive of min and max
    return math.floor(random.random() * (max - min + 1)) + min

def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']
    BLUE_TRAFFIC_PERCENTAGE = 80

    '''
    This Lambda function demonstrates how to gradually transfer traffic from
    one S3 bucket to another in a controlled way.
    We define a variable BLUE_TRAFFIC_PERCENTAGE which can take values from
    1 to 100. If the generated randomNumber less than or equal to BLUE_TRAFFIC_PERCENTAGE, traffic
    is re-directed to blue-bucket. If not, the default bucket that we've configured
    is used.
    '''

    randomNumber = getRandomInt(1, 100)

    if randomNumber <= BLUE_TRAFFIC_PERCENTAGE:
        domainName = 'blue-bucket.s3.amazonaws.com'
        request['origin']['s3']['domainName'] = domainName
        request['headers']['host'] = [{'key': 'host', 'value': domainName}]

    return request
```

------

### Esempio: utilizzo di un trigger di richiesta origine per modificare il nome di dominio dell’origine in base all’intestazione del paese
<a name="lambda-examples-content-based-geo-header"></a>

Questa funzione mostra come è possibile modificare il nome di dominio dell'origine in base all'intestazione `CloudFront-Viewer-Country`, affinché il contenuto venga distribuito da un'origine più vicina al paese del visualizzatore.

L'implementazione di questa funzionalità per la distribuzione può offrire i seguenti vantaggi:
+ Riduzione delle latenze quando la regione specificata è più vicina al paese del visualizzatore.
+ Possibilità di controllare i dati verificando che siano distribuiti da un'origine nello stesso paese in cui è stata effettuata la richiesta.

Per attivare questa funzionalità, è necessario configurare la distribuzione in modo che la memorizzazione nella cache venga eseguita in base all'intestazione `CloudFront-Viewer-Country`. Per ulteriori informazioni, consulta [Cache Based on Selected Request Headers (Cache in base a intestazioni di richiesta selezionate)](DownloadDistValuesCacheBehavior.md#DownloadDistValuesForwardHeaders).

------
#### [ Node.js ]

```
'use strict';

exports.handler = (event, context, callback) => {
     const request = event.Records[0].cf.request;
     
  if (request.headers['cloudfront-viewer-country']) {
         const countryCode = request.headers['cloudfront-viewer-country'][0].value;
         if (countryCode === 'GB' || countryCode === 'DE' || countryCode === 'IE' ) {
             const domainName = 'eu.example.com';
             request.origin.custom.domainName = domainName;
             request.headers['host'] = [{key: 'host', value: domainName}];
         } 
     }
     
    callback(null, request);
};
```

------
#### [ Python ]

```
def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']

    viewerCountry = request['headers'].get('cloudfront-viewer-country')
    if viewerCountry:
        countryCode = viewerCountry[0]['value']
        if countryCode == 'GB' or countryCode == 'DE' or countryCode == 'IE':
            domainName = 'eu.example.com'
            request['origin']['custom']['domainName'] = domainName
            request['headers']['host'] = [{'key': 'host', 'value': domainName}]
    return request
```

------

## Aggiornamento degli stati di errore: esempi
<a name="lambda-examples-update-error-status-examples"></a>

Gli esempi seguenti forniscono indicazioni su come è possibile usare Lambda@Edge per modificare lo stato di errore che viene restituito agli utenti.

**Topics**
+ [Esempio: utilizzo di un trigger di risposta origine per aggiornare il codice di stato di errore a 200](#lambda-examples-custom-error-static-body)
+ [Esempio: utilizzo di un trigger di risposta origine per aggiornare il codice di stato di errore a 302](#lambda-examples-custom-error-new-site)

### Esempio: utilizzo di un trigger di risposta origine per aggiornare il codice di stato di errore a 200
<a name="lambda-examples-custom-error-static-body"></a>

Questa funzione mostra come puoi aggiornare lo stato della risposta a 200 e generare contenuto di corpo statico da restituire al visualizzatore nel seguente scenario:
+ La funzione viene attivata in una risposta di origine
+ Lo stato delle risposta dal server di origine è codice di stato di errore (4xx e 5xx)

------
#### [ Node.js ]

```
'use strict';

exports.handler = (event, context, callback) => {
    const response = event.Records[0].cf.response;

    /**
     * This function updates the response status to 200 and generates static
     * body content to return to the viewer in the following scenario:
     * 1. The function is triggered in an origin response
     * 2. The response status from the origin server is an error status code (4xx or 5xx)
     */

    if (response.status >= 400 && response.status <= 599) {
        response.status = 200;
        response.statusDescription = 'OK';
        response.body = 'Body generation example';
    }

    callback(null, response);
};
```

------
#### [ Python ]

```
def lambda_handler(event, context):
    response = event['Records'][0]['cf']['response']

    '''
    This function updates the response status to 200 and generates static
    body content to return to the viewer in the following scenario:
    1. The function is triggered in an origin response
    2. The response status from the origin server is an error status code (4xx or 5xx)
    '''

    if int(response['status']) >= 400 and int(response['status']) <= 599:
        response['status'] = 200
        response['statusDescription'] = 'OK'
        response['body'] = 'Body generation example'
    return response
```

------

### Esempio: utilizzo di un trigger di risposta origine per aggiornare il codice di stato di errore a 302
<a name="lambda-examples-custom-error-new-site"></a>

Questa funzione mostra come puoi aggiornare il codice di stato HTTP a 302 per eseguire il reindirizzamento a un altro percorso (comportamento cache) che ha un'origine configurata differente. Tieni presente quanto segue:
+ La funzione viene attivata in una risposta di origine
+ Lo stato delle risposta dal server di origine è codice di stato di errore (4xx e 5xx)

------
#### [ Node.js ]

```
'use strict';

exports.handler = (event, context, callback) => {
    const response = event.Records[0].cf.response;
    const request = event.Records[0].cf.request;

    /**
     * This function updates the HTTP status code in the response to 302, to redirect to another
     * path (cache behavior) that has a different origin configured. Note the following:
     * 1. The function is triggered in an origin response
     * 2. The response status from the origin server is an error status code (4xx or 5xx)
     */

    if (response.status >= 400 && response.status <= 599) {
        const redirect_path = `/plan-b/path?${request.querystring}`;

        response.status = 302;
        response.statusDescription = 'Found';

        /* Drop the body, as it is not required for redirects */
        response.body = '';
        response.headers['location'] = [{ key: 'Location', value: redirect_path }];
    }

    callback(null, response);
};
```

------
#### [ Python ]

```
def lambda_handler(event, context):
    response = event['Records'][0]['cf']['response']
    request = event['Records'][0]['cf']['request']

    '''
    This function updates the HTTP status code in the response to 302, to redirect to another
    path (cache behavior) that has a different origin configured. Note the following:
    1. The function is triggered in an origin response
    2. The response status from the origin server is an error status code (4xx or 5xx)
    '''

    if int(response['status']) >= 400 and int(response['status']) <= 599:
        redirect_path = '/plan-b/path?%s' % request['querystring']

        response['status'] = 302
        response['statusDescription'] = 'Found'

        # Drop the body as it is not required for redirects
        response['body'] = ''
        response['headers']['location'] = [{'key': 'Location', 'value': redirect_path}]

    return response
```

------

## Accesso al corpo della richiesta: esempi
<a name="lambda-examples-access-request-body-examples"></a>

Gli esempi seguenti illustrano come utilizzare Lambda@Edge con le richieste POST.

**Nota**  
Per utilizzare questi esempi, è necessario abilitare l'opzione *include body* (Includi corpo) nell'associazione della funzione Lambda della distribuzione. Non è abilitato per impostazione predefinita.  
Per abilitare questa impostazione nella CloudFront console, seleziona la casella di controllo **Includi corpo** nella **Lambda Function** Association.
Per abilitare questa impostazione nell' CloudFront API o con CloudFormation, imposta il `IncludeBody` campo su `true` in`LambdaFunctionAssociation`.

**Topics**
+ [Esempio: utilizzo di un trigger di richiesta per leggere un modulo HTML](#lambda-examples-access-request-body-examples-read)
+ [Esempio: utilizzo di un trigger di richiesta per modificare un modulo HTML](#lambda-examples-access-request-body-examples-replace)

### Esempio: utilizzo di un trigger di richiesta per leggere un modulo HTML
<a name="lambda-examples-access-request-body-examples-read"></a>

Questa funzione dimostra come è possibile elaborare il corpo di una richiesta POST generato da un modulo HTML (modulo Web), ad esempio "Contattaci". Ad esempio, potresti avere un modulo HTML come il seguente:

```
<html>
  <form action="https://example.com" method="post">
    Param 1: <input type="text" name="name1"><br>
    Param 2: <input type="text" name="name2"><br>
    input type="submit" value="Submit">
  </form>
</html>
```

Per la funzione di esempio che segue, la funzione deve essere attivata in una richiesta di un visualizzatore CloudFront o di richiesta origine.

------
#### [ Node.js ]

```
'use strict';

const querystring = require('querystring');

/**
 * This function demonstrates how you can read the body of a POST request 
 * generated by an HTML form (web form). The function is triggered in a
 * CloudFront viewer request or origin request event type.
 */

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;

    if (request.method === 'POST') {
        /* HTTP body is always passed as base64-encoded string. Decode it. */
        const body = Buffer.from(request.body.data, 'base64').toString();
 
        /* HTML forms send the data in query string format. Parse it. */
        const params = querystring.parse(body);
 
        /* For demonstration purposes, we only log the form fields here.
         * You can put your custom logic here. For example, you can store the 
         * fields in a database, such as Amazon DynamoDB, and generate a response
         * right from your Lambda@Edge function.
         */
        for (let param in params) {
            console.log(`For "${param}" user submitted "${params[param]}".\n`);
        }
    }
    return callback(null, request);
};
```

------
#### [ Python ]

```
import base64
from urllib.parse import parse_qs

'''
Say there is a POST request body generated by an HTML such as:

<html>
<form action="https://example.com" method="post">
    Param 1: <input type="text" name="name1"><br>
    Param 2: <input type="text" name="name2"><br>
    input type="submit" value="Submit">
</form>
</html>

'''

'''
This function demonstrates how you can read the body of a POST request 
generated by an HTML form (web form). The function is triggered in a
CloudFront viewer request or origin request event type.
'''

def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']

    if request['method'] == 'POST':
        # HTTP body is always passed as base64-encoded string. Decode it
        body = base64.b64decode(request['body']['data'])

        # HTML forms send the data in query string format. Parse it
        params = {k: v[0] for k, v in parse_qs(body).items()}

        '''
        For demonstration purposes, we only log the form fields here.
        You can put your custom logic here. For example, you can store the
        fields in a database, such as Amazon DynamoDB, and generate a response
        right from your Lambda@Edge function.
        '''
        for key, value in params.items():
            print("For %s use submitted %s" % (key, value))
            
    return request
```

------

### Esempio: utilizzo di un trigger di richiesta per modificare un modulo HTML
<a name="lambda-examples-access-request-body-examples-replace"></a>

Questa funzione dimostra come è possibile modificare il corpo di una richiesta POST generato da un modulo HTML (modulo Web). La funzione viene attivata in una richiesta del CloudFront visualizzatore o in una richiesta di origine.

------
#### [ Node.js ]

```
'use strict';
				
const querystring = require('querystring');

exports.handler = (event, context, callback) => {
    var request = event.Records[0].cf.request;
    if (request.method === 'POST') {
        /* Request body is being replaced. To do this, update the following
        /* three fields:
         *    1) body.action to 'replace'
         *    2) body.encoding to the encoding of the new data.
         *
         *       Set to one of the following values:
         *
         *           text - denotes that the generated body is in text format.
         *               Lambda@Edge will propagate this as is.
         *           base64 - denotes that the generated body is base64 encoded.
         *               Lambda@Edge will base64 decode the data before sending
         *               it to the origin.
         *    3) body.data to the new body.
         */
        request.body.action = 'replace';
        request.body.encoding = 'text';
        request.body.data = getUpdatedBody(request);
    }
    callback(null, request);
};

function getUpdatedBody(request) {
    /* HTTP body is always passed as base64-encoded string. Decode it. */
    const body = Buffer.from(request.body.data, 'base64').toString();

    /* HTML forms send data in query string format. Parse it. */
    const params = querystring.parse(body);

    /* For demonstration purposes, we're adding one more param.
     *
     * You can put your custom logic here. For example, you can truncate long
     * bodies from malicious requests.
     */
    params['new-param-name'] = 'new-param-value';
    return querystring.stringify(params);
}
```

------
#### [ Python ]

```
import base64
from urllib.parse import parse_qs, urlencode

def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']
    if request['method'] == 'POST':
        '''
        Request body is being replaced. To do this, update the following
        three fields:
            1) body.action to 'replace'
            2) body.encoding to the encoding of the new data.
        
            Set to one of the following values:
        
                text - denotes that the generated body is in text format.
                    Lambda@Edge will propagate this as is.
                base64 - denotes that the generated body is base64 encoded.
                    Lambda@Edge will base64 decode the data before sending
                    it to the origin.
            3) body.data to the new body.
        '''
        request['body']['action'] = 'replace'
        request['body']['encoding'] = 'text'
        request['body']['data'] = getUpdatedBody(request)
    return request

def getUpdatedBody(request):
    # HTTP body is always passed as base64-encoded string. Decode it
    body = base64.b64decode(request['body']['data'])

    # HTML forms send data in query string format. Parse it
    params = {k: v[0] for k, v in parse_qs(body).items()}

    # For demonstration purposes, we're adding one more param

    # You can put your custom logic here. For example, you can truncate long
    # bodies from malicious requests
    params['new-param-name'] = 'new-param-value'
    return urlencode(params)
```

------