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à.
# Richiamare Lambda con eventi di altri servizi AWS
*Alcuni Servizi AWS possono richiamare direttamente le funzioni Lambda utilizzando i trigger.* Questi servizi inviano eventi a Lambda e la funzione viene richiamata immediatamente quando si verifica l'evento specificato. I trigger sono adatti per eventi discreti ed elaborazione in tempo reale. Quando [crei un trigger utilizzando la console Lambda, la console](#lambda-invocation-trigger) interagisce con il AWS servizio corrispondente per configurare la notifica degli eventi su quel servizio. Il trigger viene effettivamente archiviato e gestito dal servizio che genera gli eventi, non da Lambda.
Gli eventi sono dati strutturati nel formato JSON. La struttura di JSON varia a seconda del servizio che la genera e del tipo di evento, ma contengono tutte i dati necessari alla funzione per elaborare l'evento.
Una funzione può avere più trigger. Ogni trigger agisce come un client che invoca la funzione in modo indipendente e ogni evento che Lambda invia alla funzione contiene dati solo da un trigger. Lambda converte il documento di evento in un oggetto e lo passa al gestore funzione.
A seconda del servizio, l'invocazione basata sugli eventi può essere [sincrona](invocation-sync.md) o [asincrona](invocation-async.md).
+ Per la chiamata sincrona, il servizio che genera l'evento attende la risposta della funzione. Tale servizio definisce i dati che la funzione deve restituire nella risposta. Il servizio controlla la strategia di errore, ad esempio se riprovare in caso di errori.
+ Per la chiamata asincrona, Lambda inserisce l'evento in una coda prima di passarlo alla funzione. Quando Lambda accoda l'evento, invia immediatamente una risposta riuscita al servizio che ha generato l'evento. Dopo che la funzione elabora l'evento, Lambda non restituisce una risposta al servizio generatore di eventi.
## Creazione di un trigger
Il modo più semplice per creare un trigger consiste nell'utilizzare la console Lambda. Quando crei un trigger utilizzando la console, Lambda aggiunge automaticamente le autorizzazioni richieste alla [policy basata sulle risorse](access-control-resource-based.md) della funzione.
**Per creare un trigger utilizzando la console Lambda**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Seleziona la funzione per cui desideri creare un trigger.
1. Nel riquadro **Panoramica della funzione**, scegli **Aggiungi trigger**.
1. Seleziona il AWS servizio a cui desideri richiamare la tua funzione.
1. Compila le opzioni nel riquadro **Configurazione trigger** e scegli **Aggiungi**. A seconda della Servizio AWS funzione scelta per richiamare la funzione, le opzioni di configurazione del trigger saranno diverse.
## Servizi che possono richiamare le funzioni Lambda
La tabella seguente elenca i servizi che possono richiamare le funzioni Lambda.
****
| Servizio | Metodo di chiamata |
| --- | --- |
| [Amazon Managed Streaming per Apache Kafka](with-msk.md) | [Strumento di mappatura dell'origine degli eventi](invocation-eventsourcemapping.md) |
| [Apache Kafka gestito dal cliente](with-kafka.md) | [Strumento di mappatura dell'origine degli eventi](invocation-eventsourcemapping.md) |
| [Gateway Amazon API](services-apigateway.md) | Chiamata sincrona basata su eventi |
| [AWS CloudFormation](services-cloudformation.md) | Chiamata asincrona basata su eventi |
| [ CloudWatch Registri Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters.html#LambdaFunctionExample) | Chiamata asincrona basata su eventi |
| [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-notify-lambda-cc.html) | Chiamata asincrona basata su eventi |
| [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/actions-invoke-lambda-function.html) | Chiamata asincrona basata su eventi |
| [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-events.html) | Chiamata sincrona basata su eventi |
| [AWS Config](governance-config.md) | Chiamata asincrona basata su eventi |
| [Amazon Connect](https://docs.aws.amazon.com/connect/latest/adminguide/connect-lambda-functions.html) | Chiamata sincrona basata su eventi |
| [Amazon DocumentDB](with-documentdb.md) | [Strumento di mappatura dell'origine degli eventi](invocation-eventsourcemapping.md) |
| [Amazon DynamoDB](with-ddb.md) | [Strumento di mappatura dell'origine degli eventi](invocation-eventsourcemapping.md) |
| [Elastic Load Balancer (Application Load Balancer)](services-alb.md) | Chiamata sincrona basata su eventi |
| [Amazon EventBridge (CloudWatch Eventi)](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) | Basata sugli eventi; invocazione asincrona (router di eventi), invocazione sincrona o asincrona (pipe e pianificazioni) |
| [AWS IoT](services-iot.md) | Chiamata asincrona basata su eventi |
| [Amazon Kinesis](with-kinesis.md) | [Strumento di mappatura dell'origine degli eventi](invocation-eventsourcemapping.md) |
| [Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/data-transformation.html) | Chiamata sincrona basata su eventi |
| [Amazon Lex](https://docs.aws.amazon.com/lexv2/latest/dg/lambda.html) | Chiamata sincrona basata su eventi |
| [Amazon MQ](with-mq.md) | [Strumento di mappatura dell'origine degli eventi](invocation-eventsourcemapping.md) |
| [Amazon Simple Email Service](https://docs.aws.amazon.com/ses/latest/dg/receiving-email-action-lambda.html) | Chiamata asincrona basata su eventi |
| [Amazon Simple Notification Service](with-sns.md) | Chiamata asincrona basata su eventi |
| [Amazon Simple Queue Service](with-sqs.md) | [Strumento di mappatura dell'origine degli eventi](invocation-eventsourcemapping.md) |
| [Amazon Simple Storage Service (Amazon S3)](with-s3.md) | Chiamata asincrona basata su eventi |
| [Batch di Amazon Simple Storage Service](services-s3-batch.md) | Chiamata sincrona basata su eventi |
| [Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_lambda.html) | Rotazione del segreto |
| [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/connect-lambda.html) | Basata sugli eventi; invocazione sincrona o asincrona |
| [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/lambda-functions.html) | Chiamata sincrona basata su eventi |
# Usare Lambda con Apache Kafka
Lambda supporta [Apache Kafka](https://kafka.apache.org/) come [origine eventi](invocation-eventsourcemapping.md). Apache Kafka è una piattaforma di streaming di eventi open source progettata per gestire pipeline di dati e applicazioni di streaming ad alto rendimento e in tempo reale. Esistono due modi principali per utilizzare Lambda con Apache Kafka:
+ [Uso di Lambda con Amazon MSK](with-msk.md)— Amazon Managed Streaming for Apache Kafka (Amazon MSK) è un servizio completamente gestito da. AWS Amazon MSK aiuta ad automatizzare la gestione dell'infrastruttura Kafka, inclusi il provisioning, l'applicazione di patch e la scalabilità.
+ [Utilizzo di Lambda con Apache Kafka gestito dal cliente](with-kafka.md)— In AWS terminologia, un cluster autogestito include cluster Kafka non ospitati.AWS [Ad esempio, puoi ancora utilizzare Lambda con un cluster Kafka ospitato presso un provider non cloud come [Confluent AWS](https://www.confluent.io/confluent-cloud/) Cloud o Redpanda.](https://www.redpanda.com/)
Quando decidi tra Amazon MSK e Apache Kafka autogestito, considera le tue esigenze operative e i requisiti di controllo. Amazon MSK è la scelta migliore se desideri aiutarti AWS a gestire rapidamente una configurazione Kafka scalabile e pronta per la produzione con un sovraccarico operativo minimo. Semplifica la sicurezza, il monitoraggio e l'elevata disponibilità, aiutandoti a concentrarti sullo sviluppo di applicazioni piuttosto che sulla gestione dell'infrastruttura. D'altra parte, Apache Kafka autogestito è più adatto per i casi d'uso eseguiti su ambienti non AWS ospitati, inclusi i cluster locali.
**Topics**
+ [
# Uso di Lambda con Amazon MSK
](with-msk.md)
+ [
# Utilizzo di Lambda con Apache Kafka gestito dal cliente
](with-kafka.md)
+ [
# Modalità di ridimensionamento del poller di eventi di Apache Kafka in Lambda
](kafka-scaling-modes.md)
+ [
# Sondaggi di Apache Kafka e posizioni iniziali dello streaming in Lambda
](kafka-starting-positions.md)
+ [
# ID gruppo di consumer personalizzabile
](kafka-consumer-group-id.md)
+ [
# Filtraggio eventi da origini eventi Amazon MSK e Apache Kafka autogestito
](kafka-filtering.md)
+ [
# Utilizzo dei registri degli schemi con le sorgenti di eventi Kafka in Lambda
](services-consume-kafka-events.md)
+ [
# Elaborazione a bassa latenza per sorgenti di eventi Kafka
](with-kafka-low-latency.md)
+ [
# Configurazione dei controlli di gestione degli errori per le sorgenti di eventi Kafka
](kafka-retry-configurations.md)
+ [
# Acquisizione di batch scartati per un'origine eventi di Amazon MSK e Apache Kafka autogestito
](kafka-on-failure.md)
+ [
# Usare un argomento di Kafka come destinazione in caso di errore
](kafka-on-failure-destination.md)
+ [
# Registrazione della mappatura delle sorgenti degli eventi Kafka
](esm-logging.md)
+ [
# Risoluzione degli errori di mappatura delle sorgenti degli eventi Kafka
](with-kafka-troubleshoot.md)
# Uso di Lambda con Amazon MSK
[Amazon Managed Streaming for Apache Kafka (Amazon MSK) è un servizio completamente gestito che puoi utilizzare per](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html) creare ed eseguire applicazioni che utilizzano Apache Kafka per elaborare dati di streaming. Amazon MSK semplifica la configurazione, la scalabilità e la gestione dei cluster Kafka. Amazon MSK semplifica inoltre la configurazione dell'applicazione per più zone di disponibilità e per la sicurezza con AWS Identity and Access Management (IAM).
Questo capitolo spiega come utilizzare un cluster Amazon MSK come origine di eventi per la funzione Lambda. Il processo generale per l'integrazione di Amazon MSK con Lambda prevede i seguenti passaggi:
1. **[Configurazione del cluster e della rete](with-msk-cluster-network.md)**: per prima cosa, configura il tuo [cluster Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html). Ciò include la configurazione di rete corretta per consentire a Lambda di accedere al cluster.
1. **[Configurazione della mappatura delle sorgenti degli eventi](with-msk-configure.md)**: quindi, crea la risorsa di [mappatura delle sorgenti degli eventi](invocation-eventsourcemapping.md) di cui Lambda ha bisogno per connettere in modo sicuro il tuo cluster Amazon MSK alla tua funzione.
1. **[Configurazione delle funzioni e delle autorizzazioni](with-msk-permissions.md)**[: infine, assicurati che la funzione sia configurata correttamente e disponga delle autorizzazioni necessarie per il suo ruolo di esecuzione.](lambda-intro-execution-role.md)
**Nota**
Ora puoi creare e gestire le mappature delle sorgenti degli eventi Amazon MSK direttamente dalla console Lambda o Amazon MSK. Entrambe le console offrono la possibilità di gestire automaticamente la configurazione delle autorizzazioni necessarie per il ruolo di esecuzione Lambda per un processo di configurazione più semplificato.
Per esempi su come configurare un'integrazione Lambda con un cluster Amazon MSK, consulta [Tutorial: Utilizzo di uno strumento di mappatura dell'origine degli eventi Amazon MSK per richiamare una funzione Lambda](services-msk-tutorial.md) Utilizzo di Amazon MSK [come origine di eventi per AWS Lambda](https://aws.amazon.com/blogs/compute/using-amazon-msk-as-an-event-source-for-aws-lambda/) sul AWS Compute Blog e Integrazione di Amazon MSK [Lambda negli Amazon MSK](https://amazonmsk-labs.workshop.aws/en/msklambda.html) Labs.
**Topics**
+ [
## Esempio di evento
](#msk-sample-event)
+ [
# Configurazione del cluster Amazon MSK e della rete Amazon VPC per Lambda
](with-msk-cluster-network.md)
+ [
# Configurazione delle autorizzazioni Lambda per le mappature delle sorgenti degli eventi Amazon MSK
](with-msk-permissions.md)
+ [
# Configurazione delle origini eventi di Amazon MSK per Lambda
](with-msk-configure.md)
+ [
# Tutorial: Utilizzo di uno strumento di mappatura dell'origine degli eventi Amazon MSK per richiamare una funzione Lambda
](services-msk-tutorial.md)
## Esempio di evento
Lambda invia il batch di messaggi nel parametro evento quando richiama la funzione. Il payload evento contiene un array di messaggi. Ogni elemento dell'array contiene i dettagli dell'argomento e dell'identificatore dello shard Amazon MSK, insieme a una data/ora e a un messaggio con codifica base64.
```
{
"eventSource":"aws:kafka",
"eventSourceArn":"arn:aws:kafka:us-east-1:123456789012:cluster/vpc-2priv-2pub/751d2973-a626-431c-9d4e-d7975eb44dd7-2",
"bootstrapServers":"b-2.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092,b-1.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092",
"records":{
"mytopic-0":[
{
"topic":"mytopic",
"partition":0,
"offset":15,
"timestamp":1545084650987,
"timestampType":"CREATE_TIME",
"key":"abcDEFghiJKLmnoPQRstuVWXyz1234==",
"value":"SGVsbG8sIHRoaXMgaXMgYSB0ZXN0Lg==",
"headers":[
{
"headerKey":[
104,
101,
97,
100,
101,
114,
86,
97,
108,
117,
101
]
}
]
}
]
}
}
```
# Configurazione del cluster Amazon MSK e della rete Amazon VPC per Lambda
Per connettere la tua AWS Lambda funzione al cluster Amazon MSK, devi configurare correttamente il cluster e l'[Amazon Virtual Private Cloud (VPC) in cui risiede](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html). Questa pagina descrive come configurare il cluster e il VPC. Se il cluster e il VPC sono già configurati correttamente, consulta [Configurazione delle origini eventi di Amazon MSK per Lambda](with-msk-configure.md) Configurare la mappatura delle sorgenti degli eventi.
**Topics**
+ [
## Panoramica dei requisiti di configurazione di rete per le integrazioni Lambda e MSK
](#msk-network-requirements)
+ [
## Configurazione di un gateway NAT per un'origine di eventi MSK
](#msk-nat-gateway)
+ [
## Configurazione degli AWS PrivateLink endpoint per un'origine di eventi MSK
](#msk-vpc-privatelink)
## Panoramica dei requisiti di configurazione di rete per le integrazioni Lambda e MSK
La configurazione di rete richiesta per un'integrazione Lambda e MSK dipende dall'architettura di rete dell'applicazione. Ci sono tre risorse principali coinvolte in questa integrazione: il cluster Amazon MSK, la funzione Lambda e la mappatura delle sorgenti degli eventi Lambda. Ognuna di queste risorse risiede in un VPC diverso:
+ Il tuo cluster Amazon MSK risiede in genere in una sottorete privata di un VPC che gestisci.
+ La tua funzione Lambda risiede in un AWS VPC gestito di proprietà di Lambda.
+ La mappatura delle sorgenti degli eventi Lambda risiede in un altro AWS VPC gestito di proprietà di Lambda, separato dal VPC che contiene la funzione.
La [mappatura dell'origine degli eventi](invocation-eventsourcemapping.md) è la risorsa intermedia tra il cluster MSK e la funzione Lambda. La mappatura delle sorgenti degli eventi ha due funzioni principali. Innanzitutto, esegue il polling del cluster MSK per verificare la presenza di nuovi messaggi. Quindi, richiama la funzione Lambda con quei messaggi. Poiché queste tre risorse sono diverse VPCs, sia le operazioni di poll che quelle di invoke richiedono chiamate di rete tra VPC.
I requisiti di configurazione di rete per la mappatura delle sorgenti degli eventi dipendono dal fatto che venga utilizzata la [modalità provisioning o la modalità](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode) on-demand, come illustrato nel diagramma seguente:
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/MSK-esm-network-overview.png)
Il modo in cui la mappatura delle sorgenti degli eventi Lambda analizza il cluster MSK alla ricerca di nuovi messaggi è lo stesso in entrambe le modalità. Per stabilire una connessione tra la mappatura delle sorgenti degli eventi e il cluster MSK, Lambda crea un [ENI iperpiano](configuration-vpc.md#configuration-vpc-enis) (o ne riutilizza uno esistente, se disponibile) nella sottorete privata per stabilire una connessione sicura. Come illustrato nel diagramma, questo iperpiano ENI utilizza la configurazione della sottorete e del gruppo di sicurezza del cluster MSK, non la funzione Lambda.
Dopo aver analizzato il messaggio dal cluster, il modo in cui Lambda richiama la funzione è diverso in ciascuna modalità:
+ In modalità provisioned, Lambda gestisce automaticamente la connessione tra il VPC di mappatura della sorgente degli eventi e la funzione VPC. Pertanto, non è necessario alcun componente di rete aggiuntivo per richiamare correttamente la funzione.
+ In modalità on-demand, la mappatura delle sorgenti degli eventi Lambda richiama la funzione tramite un percorso attraverso il VPC gestito dal cliente. [Per questo motivo, è necessario configurare un [gateway NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) nella sottorete pubblica del VPC o gli [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)endpoint nella sottorete privata del VPC che forniscono l'accesso a Lambda (STS) e, facoltativamente,.AWS Security Token Service[Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) La corretta configurazione di una di queste opzioni consente una connessione tra il VPC e il VPC di runtime gestito da Lambda, necessario per richiamare la funzione.
Un gateway NAT consente alle risorse della sottorete privata di accedere alla rete Internet pubblica. L'utilizzo di questa configurazione significa che il traffico attraversa Internet prima di richiamare la funzione Lambda. AWS PrivateLink gli endpoint consentono alle sottoreti private di connettersi in modo sicuro ai AWS servizi o ad altre risorse VPC private senza attraversare la rete Internet pubblica. Vedi [Configurazione di un gateway NAT per un'origine di eventi MSK](#msk-nat-gateway) o [Configurazione degli AWS PrivateLink endpoint per un'origine di eventi MSK](#msk-vpc-privatelink) per i dettagli su come configurare queste risorse.
Finora, abbiamo dato per scontato che il cluster MSK risieda in una sottorete privata all'interno del VPC, che è il caso più comune. Tuttavia, anche se il cluster MSK si trova in una sottorete pubblica all'interno del VPC, è necessario configurare gli AWS PrivateLink endpoint per abilitare una connessione sicura. La tabella seguente riassume i requisiti di configurazione della rete in base a come si configura il cluster MSK e la mappatura delle sorgenti degli eventi Lambda:
| Ubicazione del cluster MSK (in VPC gestito dal cliente) | Modalità di scalabilità della mappatura delle sorgenti di eventi Lambda | Configurazione di rete richiesta |
| --- | --- | --- |
| Sottorete privata | Modalità on demand | Gateway NAT (nella sottorete pubblica del VPC) o AWS PrivateLink endpoint (nella sottorete privata del VPC) per consentire l'accesso a Lambda e, facoltativamente, a Secrets Manager. AWS STS |
| Sottorete pubblica | Modalità on demand | AWS PrivateLink endpoint (nella sottorete pubblica del tuo VPC) per abilitare l'accesso a Lambda e, facoltativamente AWS STS, a Secrets Manager. |
| Sottorete privata | Modalità provisioning | Nessuno |
| Sottorete pubblica | Modalità provisioning | Nessuno |
Inoltre, i gruppi di sicurezza associati al cluster MSK devono consentire il traffico sulle porte corrette. Assicuratevi di aver configurato le seguenti regole per i gruppi di sicurezza:
+ **Regole in entrata**: consente tutto il traffico sulla porta broker predefinita. La porta utilizzata da MSK dipende dal tipo di autenticazione sul cluster: `9098` per l'autenticazione IAM, per SASL/SCRAM e `9096` per TLS. `9094` In alternativa, è possibile utilizzare una regola del gruppo di sicurezza autoreferenziante per consentire l'accesso da istanze all'interno dello stesso gruppo di sicurezza.
+ **Regole in uscita**: consentono tutto il traffico sulla porta `443` per destinazioni esterne se la funzione deve comunicare con altri servizi. AWS In alternativa, puoi utilizzare una regola del gruppo di sicurezza autoreferenziale per limitare l'accesso al broker se non hai bisogno di comunicare con altri servizi. AWS
+ **Regole di ingresso degli endpoint Amazon VPC**: se utilizzi un endpoint Amazon VPC, il gruppo di sicurezza associato all'endpoint deve consentire il traffico in entrata sulla porta `443` dal gruppo di sicurezza del cluster.
## Configurazione di un gateway NAT per un'origine di eventi MSK
Puoi configurare un gateway NAT per consentire alla mappatura della fonte degli eventi di interrogare i messaggi dal cluster e richiamare la funzione tramite un percorso attraverso il tuo VPC. Questo è necessario solo se la mappatura delle sorgenti degli eventi utilizza la modalità on demand e il cluster risiede all'interno di una sottorete privata del VPC. Se il cluster risiede in una sottorete pubblica del VPC o la mappatura delle sorgenti degli eventi utilizza la modalità provisioning, non è necessario configurare un gateway NAT.
Le risorse in una sottorete privata richiedono un [gateway NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) per accedere alla rete Internet pubblica. Se hai bisogno di connettività privata a Lambda, vedi [Configurazione degli AWS PrivateLink endpoint per un'origine di eventi MSK](#msk-vpc-privatelink) invece.
Dopo aver configurato il gateway NAT, è necessario configurare le tabelle di routing appropriate. Ciò consente al traffico proveniente dalla sottorete privata di indirizzarsi verso la rete Internet pubblica tramite il gateway NAT.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/MSK-NAT-Gateway.png)
I seguenti passaggi guidano l'utente nella configurazione di un gateway NAT utilizzando la console. Ripetere questi passaggi se necessario per ogni zona di disponibilità (AZ).
**Per configurare un gateway NAT e un routing corretto (console)**
1. Segui la procedura descritta in [Creare un gateway NAT](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-working-with.html), tenendo presente quanto segue:
+ I gateway NAT devono sempre risiedere in una sottorete pubblica. [Crea gateway NAT con connettività pubblica.](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)
+ Se il tuo cluster MSK viene replicato su più server AZs, crea un gateway NAT per AZ. Ad esempio, in ogni AZ, il tuo VPC dovrebbe avere una sottorete privata contenente il cluster e una sottorete pubblica contenente il gateway NAT. Per una configurazione con tre AZs, avrai tre sottoreti private, tre sottoreti pubbliche e tre gateway NAT.
1. Dopo aver creato il gateway NAT, apri la console [Amazon VPC](https://console.aws.amazon.com/vpc/) e **scegli Route** tables nel menu a sinistra.
1. Selezionare **Create route table (Crea tabella di instradamento)**.
1. Associate questa tabella di routing al VPC che contiene il vostro cluster MSK. Facoltativamente, inserisci un nome per la tabella dei percorsi.
1. Selezionare **Create route table (Crea tabella di instradamento)**.
1. Scegli la tabella dei percorsi che hai appena creato.
1. Nella scheda **Associazioni di sottoreti, scegli Modifica associazioni** **di sottoreti**.
+ Associate questa tabella di routing alla sottorete privata che contiene il cluster MSK.
1. Selezionare **Modifica route**.
1. Scegli **Aggiungi** percorso:
1. Per **Destinazione** scegliere `0.0.0.0/0`.
1. Per **Target**, scegli **NAT gateway**.
1. Nella casella di ricerca, scegli il gateway NAT che hai creato nel passaggio 1. Questo dovrebbe essere il gateway NAT che si trova nella stessa AZ della sottorete privata che contiene il cluster MSK (la sottorete privata associata a questa tabella di routing nel passaggio 6).
1. Scegli **Save changes** (Salva modifiche).
## Configurazione degli AWS PrivateLink endpoint per un'origine di eventi MSK
Puoi configurare gli AWS PrivateLink endpoint per eseguire il polling dei messaggi dal tuo cluster e richiamare la funzione tramite un percorso attraverso il tuo VPC. Questi endpoint dovrebbero consentire al cluster MSK di accedere a quanto segue:
+ Il servizio Lambda
+ Il [AWS Security Token Service (STS)](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html)
+ Facoltativamente, il [Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)servizio. Questo è necessario se il segreto richiesto per l'autenticazione del cluster è archiviato in Secrets Manager.
La configurazione PrivateLink degli endpoint è necessaria solo se la mappatura delle sorgenti degli eventi utilizza la modalità on-demand. Se la mappatura delle sorgenti degli eventi utilizza la modalità provisioned, Lambda stabilisce automaticamente le connessioni necessarie.
PrivateLink gli endpoint consentono un accesso sicuro e privato ai servizi tramite. AWS AWS PrivateLink In alternativa, per configurare un gateway NAT per consentire al cluster MSK di accedere alla rete Internet pubblica, vedere. [Configurazione di un gateway NAT per un'origine di eventi MSK](#msk-nat-gateway)
Dopo aver configurato gli endpoint VPC, il cluster MSK dovrebbe avere accesso diretto e privato a Lambda, STS e, facoltativamente, a Secrets Manager.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/MSK-PrivateLink-Endpoints.png)
I seguenti passaggi guidano l'utente nella configurazione di un endpoint utilizzando la console. PrivateLink Ripetere questi passaggi se necessario per ogni endpoint (Lambda, STS, Secrets Manager).
**Per configurare gli PrivateLink endpoint VPC (console)**
1. Apri la [console Amazon VPC](https://console.aws.amazon.com/vpc/) e seleziona **Endpoints nel menu** a sinistra.
1. Seleziona **Crea endpoint**.
1. Facoltativamente, inserisci un nome per il tuo endpoint.
1. **Per **Tipo**, scegli AWS servizi.**
1. In **Servizi**, inizia a digitare il nome del servizio. Ad esempio, per creare un endpoint per la connessione a Lambda, `lambda` digita nella casella di ricerca.
1. Nei risultati, dovresti vedere l'endpoint del servizio nella regione corrente. Ad esempio, nella regione Stati Uniti orientali (Virginia settentrionale), dovresti vedere. `com.amazonaws.us-east-2.lambda` Seleziona questo servizio.
1. In **Impostazioni di rete**, selezionare il VPC che contiene il cluster MSK.
1. In **Sottoreti**, seleziona AZs quello in cui si trova il tuo cluster MSK.
+ Per ogni AZ, in **Subnet ID**, scegli la sottorete privata che contiene il cluster MSK.
1. In **Gruppo di sicurezza**, seleziona i gruppi di sicurezza associati al cluster MSK.
1. Seleziona **Crea endpoint**.
Per impostazione predefinita, gli endpoint Amazon VPC dispongono di policy IAM aperte che consentono un ampio accesso alle risorse. La best practice consiste nel limitare queste policy per eseguire le azioni necessarie utilizzando quell'endpoint. Ad esempio, per l'endpoint Secrets Manager, è possibile modificarne la policy in modo che solo il ruolo di esecuzione della funzione possa accedere al segreto.
**Example Politica degli endpoint VPC: endpoint Secrets Manager**
```
{
"Statement": [
{
"Action": "secretsmanager:GetSecretValue",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws::iam::123456789012:role/my-role"
]
},
"Resource": "arn:aws::secretsmanager:us-west-2:123456789012:secret:my-secret"
}
]
}
```
Per gli endpoint AWS STS e Lambda, puoi limitare il principale chiamante al principale del servizio Lambda. Tuttavia, assicurati di utilizzarlo `"Resource": "*"` in queste politiche.
**Example Politica degli endpoint VPC — endpoint AWS STS**
```
{
"Statement": [
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
**Example Politica degli endpoint VPC — Endpoint Lambda**
```
{
"Statement": [
{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
# Configurazione delle autorizzazioni Lambda per le mappature delle sorgenti degli eventi Amazon MSK
Per accedere al cluster Amazon MSK, la mappatura delle funzioni e delle sorgenti degli eventi necessita delle autorizzazioni per eseguire varie azioni dell'API Amazon MSK. [Aggiungi queste autorizzazioni al ruolo di esecuzione della funzione.](lambda-intro-execution-role.md) Se gli utenti devono accedere, aggiungi le autorizzazioni richieste alla politica di identità per l'utente o il ruolo.
La policy gestita dai [AWSLambdaMSKExecutionruoli](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html) contiene le autorizzazioni minime richieste per le mappature delle sorgenti degli eventi Amazon MSK Lambda. Per semplificare il processo di autorizzazione, puoi:
+ Allega la politica di gestione dei [AWSLambdaMSKExecutionruoli](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html) al tuo ruolo di esecuzione.
+ Lascia che la console Lambda generi le autorizzazioni per te. Quando [crei una mappatura dell'origine degli eventi Amazon MSK nella console, Lambda valuta il](msk-esm-create.md#msk-console) tuo ruolo di esecuzione e ti avvisa se mancano delle autorizzazioni. Scegli **Genera autorizzazioni** per aggiornare automaticamente il tuo ruolo di esecuzione. Questo non funziona se hai creato o modificato manualmente i criteri relativi ai ruoli di esecuzione o se i criteri sono associati a più ruoli. Tieni presente che potrebbero essere ancora necessarie autorizzazioni aggiuntive nel ruolo di esecuzione quando utilizzi funzionalità avanzate come [On-Failure Destination](kafka-on-failure.md) o [AWS Glue Schema](services-consume-kafka-events.md) Registry.
**Topics**
+ [
## Autorizzazioni richieste
](#msk-required-permissions)
+ [
## Autorizzazioni facoltative
](#msk-optional-permissions)
## Autorizzazioni richieste
Il ruolo di esecuzione della funzione Lambda deve avere le seguenti autorizzazioni richieste per le mappature delle sorgenti degli eventi Amazon MSK. [Queste autorizzazioni sono incluse nella politica di gestione dei ruoli. AWSLambda MSKExecution](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html)
### CloudWatch Registra le autorizzazioni
Le seguenti autorizzazioni consentono a Lambda di creare e archiviare log in CloudWatch Amazon Logs.
+ [registri: CreateLogGroup](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogGroup.html)
+ [registri: CreateLogStream](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogStream.html)
+ [registri: PutLogEvents](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html)
### autorizzazioni del cluster MSK
Le seguenti autorizzazioni consentono a Lambda di accedere al tuo cluster Amazon MSK per tuo conto:
+ [kafka: DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html)
+ [kafka: V2 DescribeCluster](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters-clusterarn.html)
+ [kafka: GetBootstrapBrokers](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-bootstrap-brokers.html)
[Ti consigliamo di usare [kafka: DescribeCluster V2 invece di kafka:](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters-clusterarn.html). DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html) L'autorizzazione v2 funziona sia con i cluster Amazon MSK con provisioning che senza server. Nella tua policy ti serve solo una di queste autorizzazioni.
### Autorizzazioni VPC
Le seguenti autorizzazioni consentono a Lambda di creare e gestire interfacce di rete durante la connessione al cluster Amazon MSK:
+ [ec2: CreateNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateNetworkInterface.html)
+ [ec2: DescribeNetworkInterfaces](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeNetworkInterfaces.html)
+ [ec2: DescribeVpcs](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpcs.html)
+ [ec2: DeleteNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteNetworkInterface.html)
+ [ec2: DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html)
+ [ec2: DescribeSecurityGroups](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSecurityGroups.html)
## Autorizzazioni facoltative
La funzione Lambda potrebbe richiedere autorizzazioni per:
+ Accedi ai cluster Amazon MSK con più account. Per le mappature delle sorgenti degli eventi tra account, è necessario [kafka](https://docs.aws.amazon.com/msk/1.0/apireference/vpc-connection-arn.html): nel ruolo di esecuzione. DescribeVpcConnection [Un preside IAM che crea una mappatura delle sorgenti degli eventi tra account ha bisogno di kafka:. ListVpcConnections](https://docs.aws.amazon.com/msk/1.0/apireference/vpc-connections.html)
+ [Accedi al tuo segreto SCRAM, se utilizzi l'autenticazione SASL/SCRAM.](msk-cluster-auth.md#msk-sasl-scram) Ciò consente alla funzione di utilizzare un nome utente e una password per connettersi a Kafka.
+ Descrivi il tuo segreto di Secrets Manager, se utilizzi l' SASL/SCRAM [autenticazione MTLS](msk-cluster-auth.md#msk-mtls). Ciò consente alla funzione di recuperare le credenziali o i certificati necessari per connessioni sicure.
+ Accedi alla tua chiave gestita AWS KMS dal cliente, se il tuo Gestione dei segreti AWS segreto è crittografato con una chiave gestita AWS KMS dal cliente.
+ Accedi ai segreti del registro degli schemi, se utilizzi un registro degli schemi con autenticazione:
+ Per il registro AWS Glue degli schemi: le esigenze `glue:GetRegistry` e le `glue:GetSchemaVersion` autorizzazioni della funzione. Questi consentono alla funzione di cercare e utilizzare le regole di formato dei messaggi memorizzate in AWS Glue.
+ Per [Confluent Schema Registry](https://docs.confluent.io/platform/current/schema-registry/security/index.html) con `BASIC_AUTH` o`CLIENT_CERTIFICATE_TLS_AUTH`: La tua funzione richiede l'`secretsmanager:GetSecretValue`autorizzazione per il segreto contenente le credenziali di autenticazione. Ciò consente alla funzione di recuperare i certificati username/password o necessari per accedere al Confluent Schema Registry.
+ Per i certificati CA privati: la tua funzione richiede secretsmanager: GetSecretValue autorizzazione per il segreto contenente il certificato. Ciò consente alla funzione di verificare l'identità dei registri dello schema che utilizzano certificati personalizzati.
+ Accedi ai gruppi di consumatori del cluster Kafka e ai messaggi di sondaggio relativi all'argomento, se utilizzi l'autenticazione IAM per la mappatura delle sorgenti degli eventi.
Queste corrispondono alle seguenti autorizzazioni richieste:
+ [kafka: ListScramSecrets](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-scram-secrets.html) - Consente l'elenco dei segreti SCRAM per l'autenticazione Kafka
+ [secretsmanager: GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html) - Consente il recupero di segreti da Secrets Manager
+ [KMS:Decrypt - Permette la decrittografia](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) dei dati crittografati utilizzando AWS KMS
+ [glue: - Consente l'accesso al registro degli schemi GetRegistry](https://docs.aws.amazon.com/glue/latest/webapi/API_GetRegistry.html) AWS Glue
+ [glue: GetSchemaVersion](https://docs.aws.amazon.com/glue/latest/webapi/API_GetSchemaVersion.html) - Consente il recupero di versioni specifiche dello schema dal AWS Glue registro degli schemi
+ [Kafka-Cluster:Connect - Concede il permesso di connettersi e autenticarsi al cluster](https://docs.aws.amazon.com/service-authorization/latest/reference/list_apachekafkaapisforamazonmskclusters.html)
+ [kafka-cluster: AlterGroup - Concede il permesso di unirsi a gruppi su un cluster](https://docs.aws.amazon.com/service-authorization/latest/reference/list_apachekafkaapisforamazonmskclusters.html), equivalente all'ACL READ GROUP di Apache Kafka
+ [kafka-cluster: DescribeGroup - Concede il permesso di descrivere i gruppi su un cluster](https://docs.aws.amazon.com/service-authorization/latest/reference/list_apachekafkaapisforamazonmskclusters.html), equivalente all'ACL DESCRIBE GROUP di Apache Kafka
+ [kafka-cluster: DescribeTopic - Concede il permesso di descrivere argomenti su un cluster](https://docs.aws.amazon.com/service-authorization/latest/reference/list_apachekafkaapisforamazonmskclusters.html), equivalente all'ACL DESCRIBE TOPIC di Apache Kafka
+ [kafka-cluster: ReadData - Concede il permesso di leggere i dati dagli argomenti su un cluster](https://docs.aws.amazon.com/service-authorization/latest/reference/list_apachekafkaapisforamazonmskclusters.html), equivalente all'ACL READ TOPIC di Apache Kafka
Inoltre, se desideri inviare i record delle chiamate non riuscite a una destinazione in caso di errore, avrai bisogno delle seguenti autorizzazioni a seconda del tipo di destinazione:
+ Per le destinazioni Amazon SQS: [sqs: SendMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) - Consente l'invio di messaggi a una coda Amazon SQS
+ Per le destinazioni Amazon SNS: [SNS:Publish - Consente la pubblicazione](https://docs.aws.amazon.com/sns/latest/api/API_Publish.html) di messaggi su un argomento Amazon SNS
+ Per le destinazioni dei bucket Amazon S3: s3: PutObject e [https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html) - Abilita la scrittura e l'elenco di oggetti in un bucket Amazon S3
Per la risoluzione degli errori di autenticazione e autorizzazione, consulta. [Risoluzione degli errori di mappatura delle sorgenti degli eventi Kafka](with-kafka-troubleshoot.md)
# Configurazione delle origini eventi di Amazon MSK per Lambda
Per utilizzare un cluster Amazon MSK come origine di eventi per la tua funzione Lambda, crei [una mappatura delle sorgenti di eventi](invocation-eventsourcemapping.md) che collega le due risorse. Questa pagina descrive come creare una mappatura delle sorgenti degli eventi per Amazon MSK.
Questa pagina presuppone che tu abbia già configurato correttamente il tuo cluster MSK e l'[Amazon Virtual Private Cloud (VPC) in cui risiede](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html). Se è necessario configurare il cluster o il VPC, vedere. [Configurazione del cluster Amazon MSK e della rete Amazon VPC per Lambda](with-msk-cluster-network.md) Per configurare il comportamento dei tentativi di ripetizione per la gestione degli errori, consulta. [Configurazione dei controlli di gestione degli errori per le sorgenti di eventi Kafka](kafka-retry-configurations.md)
**Topics**
+ [
## Utilizzo di un cluster Amazon MSK come origine eventi
](#msk-esm-overview)
+ [
# Configurazione dei metodi di autenticazione del cluster Amazon MSK in Lambda
](msk-cluster-auth.md)
+ [
# Creazione di una mappatura della sorgente di eventi Lambda per un'origine di eventi Amazon MSK
](msk-esm-create.md)
+ [
# Creazione di mappature delle sorgenti degli eventi tra account in Lambda
](msk-cross-account.md)
+ [
# Tutti i parametri di configurazione dell'origine degli eventi Amazon MSK in Lambda
](msk-esm-parameters.md)
## Utilizzo di un cluster Amazon MSK come origine eventi
Quando aggiungi il cluster Apache Kafka o Amazon MSK come trigger per la funzione Lambda, il cluster viene utilizzato come [origine eventi](invocation-eventsourcemapping.md).
Lambda legge i dati degli eventi dagli argomenti di Kafka specificati `Topics` in una [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)richiesta, in base alla posizione [iniziale](kafka-starting-positions.md) specificata. Dopo che l'elaborazione è avvenuta con successo, l'argomento Kafka viene salvato nel cluster Kafka.
Lambda legge i messaggi in sequenza per ogni partizione dell'argomento Kafka. Un singolo payload Lambda può contenere messaggi provenienti da più partizioni. Quando sono disponibili più record, Lambda continua a elaborare i record in batch, in base al BatchSize valore specificato in una [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)richiesta, finché la funzione non raggiunge l'argomento.
Dopo che Lambda ha elaborato ogni batch, esegue il commit degli offset dei messaggi in quel batch. Se la funzione restituisce un errore per uno qualsiasi dei messaggi di un batch, Lambda ritenta l'intero batch di messaggi fino a quando l'elaborazione non riesce o i messaggi scadono. È possibile inviare i record per i quali tutti i nuovi tentativi falliscono a una destinazione in errore per un'elaborazione successiva.
**Nota**
Anche se le funzioni Lambda generalmente prevedono un timeout massimo di 15 minuti, gli strumenti di mappatura dell'origine degli eventi per Amazon MSK, Apache Kafka autogestito, Amazon DocumentDB e Amazon MQ per ActiveMQ e RabbitMQ supportano solo funzioni con timeout massimi di 14 minuti.
# Configurazione dei metodi di autenticazione del cluster Amazon MSK in Lambda
Lambda necessita dell'autorizzazione per accedere al cluster Amazon MSK, recuperare record ed eseguire altre attività. Amazon MSK supporta diversi metodi per l'autenticazione con il cluster MSK.
**Topics**
+ [
## Accesso non autenticato
](#msk-unauthenticated)
+ [
## Autenticazione SASL/SCRAM
](#msk-sasl-scram)
+ [
## Autenticazione TLS reciproca
](#msk-mtls)
+ [
## Autenticazione IAM
](#msk-iam-auth)
+ [
## Come Lambda sceglie un broker bootstrap
](#msk-bootstrap-brokers)
## Accesso non autenticato
Se nessun client accede al cluster tramite Internet, è possibile utilizzare l'accesso non autenticato.
## Autenticazione SASL/SCRAM
Lambda supporta [l'autenticazione SASL/SCRAM (Simple Authentication and Security Layer/Salted Challenge Response Authentication Mechanism)](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password-tutorial.html), con la funzione hash SHA-512 e la crittografia Transport Layer Security (TLS). Affinché Lambda si connetta al cluster, memorizza le credenziali di autenticazione (nome utente e password) in un segreto di Secrets Manager e fai riferimento a questo segreto durante la configurazione della mappatura dell'origine degli eventi.
Per ulteriori informazioni sull'uso di Secrets Manager, consulta [Autenticazione delle credenziali di accesso con Secrets Manager](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password.html) nella *Amazon Managed Streaming for Apache Kafka Developer Guide*.
**Nota**
Amazon MSK non supporta SASL/PLAIN l'autenticazione.
## Autenticazione TLS reciproca
Mutual TLS (mTLS) fornisce l'autenticazione bidirezionale tra il client e il server. Il client invia un certificato al server affinché il server verifichi il client. Il server invia inoltre un certificato al client per consentire al client di verificare il server.
Per le integrazioni Amazon MSK con Lambda, il cluster MSK funge da server e Lambda funge da client.
+ Affinché Lambda verifichi il tuo cluster MSK, configuri un certificato client come segreto in Secrets Manager e fai riferimento a questo certificato nella configurazione di mappatura delle sorgenti degli eventi. Il certificato client deve essere firmato da un'autorità di certificazione (CA) presente nel trust store del server.
+ Il cluster MSK invia anche un certificato server a Lambda. Il certificato del server deve essere firmato da un'autorità di certificazione (CA) nel AWS trust store.
Amazon MSK non supporta certificati server autofirmati. Tutti i broker di Amazon MSK utilizzano [certificati pubblici firmati](https://docs.aws.amazon.com/msk/latest/developerguide/msk-encryption.html) da [Amazon Trust Services CAs](https://www.amazontrust.com/repository/), che Lambda considera affidabili per impostazione predefinita.
### Configurazione del segreto mTLS
Il segreto CLIENT\$1CERTIFICATE\$1TLS\$1AUTH richiede un campo certificato e un campo chiave privata. Per una chiave privata crittografata, il segreto richiede una password per chiave privata. Il certificato e la chiave privata devono essere in formato PEM.
**Nota**
Lambda supporta gli algoritmi di crittografia a chiave privata [PBES1](https://datatracker.ietf.org/doc/html/rfc2898/#section-6.1)(ma non PBES2).
Il campo certificato deve contenere un elenco di certificati, a partire dal certificato client, seguito da qualsiasi certificato intermedio, per finire con il certificato root. Ogni certificato deve iniziare su una nuova riga con la struttura seguente:
```
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
```
Secrets Manager supporta segreti fino a 65.536 byte, che è uno spazio sufficiente per lunghe catene di certificati.
La chiave privata deve essere in formato [PKCS \$18](https://datatracker.ietf.org/doc/html/rfc5208), con la struttura seguente:
```
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
```
Per una chiave privata crittografata, utilizza la struttura seguente:
```
-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----
```
Nell'esempio seguente viene mostrato il contenuto di un segreto per l'autenticazione mTLS utilizzando una chiave privata crittografata. Per una chiave privata crittografata, includi una password per chiave privata nel segreto.
```
{
"privateKeyPassword": "testpassword",
"certificate": "-----BEGIN CERTIFICATE-----
MIIE5DCCAsygAwIBAgIRAPJdwaFaNRrytHBto0j5BA0wDQYJKoZIhvcNAQELBQAw
...
j0Lh4/+1HfgyE2KlmII36dg4IMzNjAFEBZiCRoPimO40s1cRqtFHXoal0QQbIlxk
cmUuiAii9R0=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFgjCCA2qgAwIBAgIQdjNZd6uFf9hbNC5RdfmHrzANBgkqhkiG9w0BAQsFADBb
...
rQoiowbbk5wXCheYSANQIfTZ6weQTgiCHCCbuuMKNVS95FkXm0vqVD/YpXKwA/no
c8PH3PSoAaRwMMgOSA2ALJvbRz8mpg==
-----END CERTIFICATE-----",
"privateKey": "-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIFKzBVBgkqhkiG9w0BBQ0wSDAnBgkqhkiG9w0BBQwwGgQUiAFcK5hT/X7Kjmgp
...
QrSekqF+kWzmB6nAfSzgO9IaoAaytLvNgGTckWeUkWn/V0Ck+LdGUXzAC4RxZnoQ
zp2mwJn2NYB7AZ7+imp0azDZb+8YG2aUCiyqb6PnnA==
-----END ENCRYPTED PRIVATE KEY-----"
}
```
Per ulteriori informazioni su MTL per Amazon MSK e istruzioni su come generare un certificato client, consulta l'autenticazione client [Mutual TLS per Amazon MSK nella Amazon Managed Streaming for](https://docs.aws.amazon.com/msk/latest/developerguide/msk-authentication.html) *Apache Kafka* Developer Guide.
## Autenticazione IAM
Puoi utilizzare AWS Identity and Access Management (IAM) per autenticare l'identità dei client che si connettono al cluster MSK. Con l'autenticazione IAM, Lambda si basa sulle autorizzazioni nel [ruolo di esecuzione](lambda-intro-execution-role.md) della funzione per connettersi al cluster, recuperare i record ed eseguire altre azioni necessarie. Per un esempio di policy che contiene le autorizzazioni necessarie, consulta [Create authorization policies for the IAM](https://docs.aws.amazon.com/msk/latest/developerguide/create-iam-access-control-policies.html) nella *Amazon Managed Streaming for Apache Kafka Developer Guide*.
Se l'autenticazione IAM è attiva sul tuo cluster MSK e non fornisci un segreto, Lambda utilizza automaticamente l'autenticazione IAM.
Per ulteriori informazioni sull'autenticazione IAM in Amazon MSK, consulta [IAM access control](https://docs.aws.amazon.com/msk/latest/developerguide/iam-access-control.html).
## Come Lambda sceglie un broker bootstrap
Lambda sceglie un [broker bootstrap](https://docs.aws.amazon.com/msk/latest/developerguide/msk-get-bootstrap-brokers.html) in base ai metodi di autenticazione disponibili nel tuo cluster e se fornisci un segreto per l'autenticazione. Se fornisci un segreto per mTLS o SASL/SCRAM, Lambda sceglie automaticamente quel metodo di autenticazione. Se non fornisci un segreto, Lambda seleziona il metodo di autenticazione più forte attivo sul tuo cluster. Di seguito è riportato l'ordine di priorità in cui Lambda seleziona un broker, dall'autenticazione più forte a quella più debole:
+ mTLS (segreto fornito per mTLS)
+ SASL/SCRAM (secret provided for SASL/SCRAM)
+ IAM SASL (nessun segreto fornito e autenticazione IAM attiva)
+ TLS non autenticato (nessun segreto fornito e autenticazione IAM non attiva)
+ Testo semplice (nessun segreto fornito e autenticazione IAM e TLS non autenticato non attivi)
**Nota**
Se Lambda non riesce a connettersi al tipo di broker più sicuro, non proverà a connettersi a un tipo di broker diverso (più debole). Se vuoi che Lambda scelga un tipo di broker più debole, disattiva tutti i metodi di autenticazione più forti sul tuo cluster.
# Creazione di una mappatura della sorgente di eventi Lambda per un'origine di eventi Amazon MSK
[Per creare una mappatura delle sorgenti degli eventi, puoi utilizzare la console Lambda, la [AWS Command Line Interface (CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)) o un SDK.AWS](https://aws.amazon.com/getting-started/tools-sdks/)
**Nota**
Quando crei la mappatura dell'origine degli eventi, Lambda crea [un ENI iperpiano](configuration-vpc.md#configuration-vpc-enis) nella sottorete privata che contiene il cluster MSK, permettendo a Lambda di stabilire una connessione sicura. Questo iperpiano consentito da ENI utilizza la configurazione della sottorete e del gruppo di sicurezza del cluster MSK, non la funzione Lambda.
I seguenti passaggi della console aggiungono un cluster Amazon MSK come trigger per la funzione Lambda. Sotto il cofano, questo crea una risorsa di mappatura delle sorgenti degli eventi.
**Per aggiungere un trigger Amazon MSK alla tua funzione Lambda (console)**
1. Apri la [pagina Funzione](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegli il nome della funzione Lambda per la quale si desidera aggiungere un trigger Amazon MSK.
1. In **Panoramica delle funzioni**, scegliere **Aggiungi trigger**.
1. **In **Configurazione Trigger**, scegli MSK.**
1. Per specificare i dettagli del cluster Kafka, procedi come segue:
1. Per **MSK cluster (Cluster MSK)** seleziona il cluster.
1. Per **Nome argomento**, inserisci il nome dell'argomento Kafka da cui consumare i messaggi.
1. Per **ID del gruppo di consumatori**, inserisci l'ID di un gruppo di consumatori Kafka a cui aderire, se applicabile. Per ulteriori informazioni, consulta [ID gruppo di consumer personalizzabile](kafka-consumer-group-id.md).
1. Per l'**autenticazione del cluster**, effettua le configurazioni necessarie. Per ulteriori informazioni sull’autenticazione cluster, consulta [Configurazione dei metodi di autenticazione del cluster Amazon MSK in Lambda](msk-cluster-auth.md).
+ Attiva **Usa autenticazione** se desideri che Lambda esegua l'autenticazione con il tuo cluster MSK quando stabilisci una connessione. L'autenticazione è consigliata.
+ Se utilizzi l'autenticazione, per **Metodo di autenticazione**, scegli il metodo di autenticazione da utilizzare.
+ Se utilizzi l'autenticazione, per la chiave **Secrets Manager, scegli la chiave** Secrets Manager che contiene le credenziali di autenticazione necessarie per accedere al tuo cluster.
1. In **Event poller configuration**, effettuate le configurazioni necessarie.
+ Scegli **Attiva trigger** per abilitare il trigger subito dopo la creazione.
+ Scegli se desideri **configurare la modalità provisioning** per la mappatura delle sorgenti degli eventi. Per ulteriori informazioni, consulta [Modalità di ridimensionamento del poller di eventi di Apache Kafka in Lambda](kafka-scaling-modes.md).
+ Se configuri la modalità provisioned, inserisci un valore per **Minimum event poller**, un valore per **Maximum event poller** e un valore opzionale per PollerGroupName specificare il raggruppamento di più eventi ESMs all'interno dello stesso VPC di origine eventi.
+ Per **Posizione iniziale**, scegli come vuoi che Lambda inizi a leggere dal tuo stream. Per ulteriori informazioni, consulta [Sondaggi di Apache Kafka e posizioni iniziali dello streaming in Lambda](kafka-starting-positions.md).
1. In **Batching**, effettua le configurazioni necessarie. Per ulteriori informazioni sulla suddivisione in batch, vedere. [Comportamento di batching](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching)
1. Per **Batch Size (Dimensione batch)**, immettere il numero massimo di messaggi da recuperare in un singolo batch.
1. Per **Batch window**, inserisci il numero massimo di secondi che Lambda impiega per raccogliere i record prima di richiamare la funzione.
1. In **Filtraggio**, effettua le configurazioni necessarie. Per ulteriori informazioni sul filtro, consulta [Filtraggio eventi da origini eventi Amazon MSK e Apache Kafka autogestito](kafka-filtering.md).
+ Per **i criteri di filtro**, aggiungete le definizioni dei criteri di filtro per determinare se elaborare o meno un evento.
1. In **Gestione degli errori**, effettuate le configurazioni necessarie. Per ulteriori informazioni sulla gestione degli errori, vedere[Acquisizione di batch scartati per un'origine eventi di Amazon MSK e Apache Kafka autogestito](kafka-on-failure.md).
+ Per **Destinazione in caso di errore**, specificare l'ARN della destinazione in caso di errore.
1. Per **Tag**, inserisci i tag da associare a questa mappatura della fonte degli eventi.
1. Per creare il trigger, scegli **Aggiungi**.
È inoltre possibile creare la mappatura della sorgente dell'evento utilizzando la AWS CLI con [ create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html)il comando. L'esempio seguente crea una mappatura dell'origine degli eventi per mappare la `my-msk-function` funzione Lambda `AWSKafkaTopic` all'argomento, a partire dal `LATEST` messaggio. Questo comando utilizza inoltre l'[SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html)oggetto per indicare a Lambda di [utilizzare l'](msk-cluster-auth.md#msk-sasl-scram)autenticazione SASL/SCRAM durante la connessione al cluster.
```
aws lambda create-event-source-mapping \
--event-source-arn arn:aws:kafka:us-east-1:111122223333:cluster/my-cluster/fc2f5bdf-fd1b-45ad-85dd-15b4a5a6247e-2 \
--topics AWSKafkaTopic \
--starting-position LATEST \
--function-name my-kafka-function
--source-access-configurations '[{"Type": "SASL_SCRAM_512_AUTH","URI": "arn:aws:secretsmanager:us-east-1:111122223333:secret:my-secret"}]'
```
Se il cluster utilizza l'[autenticazione MTLS](msk-cluster-auth.md#msk-mtls), includi un [SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html)oggetto che specifica `CLIENT_CERTIFICATE_TLS_AUTH` e una chiave ARN di Secrets Manager. Questo è mostrato nel seguente comando:
```
aws lambda create-event-source-mapping \
--event-source-arn arn:aws:kafka:us-east-1:111122223333:cluster/my-cluster/fc2f5bdf-fd1b-45ad-85dd-15b4a5a6247e-2 \
--topics AWSKafkaTopic \
--starting-position LATEST \
--function-name my-kafka-function
--source-access-configurations '[{"Type": "CLIENT_CERTIFICATE_TLS_AUTH","URI": "arn:aws:secretsmanager:us-east-1:111122223333:secret:my-secret"}]'
```
Quando il cluster utilizza [l'autenticazione IAM](msk-cluster-auth.md#msk-iam-auth), non è necessario un [ SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html)oggetto. Questo è mostrato nel seguente comando:
```
aws lambda create-event-source-mapping \
--event-source-arn arn:aws:kafka:us-east-1:111122223333:cluster/my-cluster/fc2f5bdf-fd1b-45ad-85dd-15b4a5a6247e-2 \
--topics AWSKafkaTopic \
--starting-position LATEST \
--function-name my-kafka-function
```
# Creazione di mappature delle sorgenti degli eventi tra account in Lambda
È possibile utilizzare la [connettività privata multi-VPC](https://docs.aws.amazon.com/msk/latest/developerguide/aws-access-mult-vpc.html) per connettere una funzione Lambda a un cluster MSK assegnato in un altro Account AWS. Utilizza la connettività multi-VPC AWS PrivateLink, che mantiene tutto il traffico all'interno della AWS rete.
**Nota**
Non è possibile creare strumenti di mappatura dell'origine degli eventi multi-account per i cluster MSK serverless.
Per creare uno strumento di mappatura dell'origine degli eventi multi-account, è necessario innanzitutto [configurare la connettività multi-VPC per il cluster MSK](https://docs.aws.amazon.com/msk/latest/developerguide/aws-access-mult-vpc.html#mvpc-cluster-owner-action-turn-on). Quando crei lo strumento di mappatura dell'origine degli eventi, utilizza l'ARN della connessione VPC gestita anziché l'ARN del cluster, come illustrato negli esempi seguenti. L'[CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)operazione varia anche a seconda del tipo di autenticazione utilizzato dal cluster MSK.
**Example — Creazione di uno strumento di mappatura dell'origine degli eventi multi-account per cluster che utilizzano l'autenticazione IAM**
Quando il cluster utilizza l'[autenticazione basata sui ruoli IAM](msk-cluster-auth.md#msk-iam-auth), non è necessario un oggetto. [SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html) Esempio:
```
aws lambda create-event-source-mapping \
--event-source-arn arn:aws:kafka:us-east-1:111122223333:vpc-connection/444455556666/my-cluster-name/51jn98b4-0a61-46cc-b0a6-61g9a3d797d5-7 \
--topics AWSKafkaTopic \
--starting-position LATEST \
--function-name my-kafka-function
```
**Example — Crea una mappatura delle sorgenti degli eventi tra account per un cluster che utilizza l'autenticazione SASL/SCRAM**
Se il cluster utilizza l'[autenticazione SASL/SCRAM](msk-cluster-auth.md#msk-sasl-scram), è necessario includere un [SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html)oggetto che specifica e un ARN segreto di `SASL_SCRAM_512_AUTH` Secrets Manager.
Esistono due modi per utilizzare i segreti per le mappature delle sorgenti di eventi Amazon MSK tra account diversi con autenticazione: SASL/SCRAM
+ Crea un segreto nell'account della funzione Lambda e sincronizzalo con il segreto del cluster. [Crea una rotazione](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html) per mantenere sincronizzati i due segreti. Questa opzione consente di controllare il segreto dall'account della funzione.
+ Utilizza il segreto associato al cluster MSK. Questo segreto deve consentire l'accesso multi-account all'account della funzione Lambda. Per ulteriori informazioni, consulta la pagina [Permissions to Gestione dei segreti AWS secrets for users in a different account](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples_cross.html).
```
aws lambda create-event-source-mapping \
--event-source-arn arn:aws:kafka:us-east-1:111122223333:vpc-connection/444455556666/my-cluster-name/51jn98b4-0a61-46cc-b0a6-61g9a3d797d5-7 \
--topics AWSKafkaTopic \
--starting-position LATEST \
--function-name my-kafka-function \
--source-access-configurations '[{"Type": "SASL_SCRAM_512_AUTH","URI": "arn:aws:secretsmanager:us-east-1:444455556666:secret:my-secret"}]'
```
**Example — Creazione di uno strumento di mappatura dell'origine degli eventi multi-account per cluster che utilizzano l'autenticazione mTLS**
Se il cluster utilizza l'[autenticazione MTLS](msk-cluster-auth.md#msk-mtls), è necessario includere un [SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html)oggetto che specifica `CLIENT_CERTIFICATE_TLS_AUTH` e un ARN segreto di Secrets Manager. Il segreto può essere archiviato nell'account del cluster o nell'account della funzione Lambda.
```
aws lambda create-event-source-mapping \
--event-source-arn arn:aws:kafka:us-east-1:111122223333:vpc-connection/444455556666/my-cluster-name/51jn98b4-0a61-46cc-b0a6-61g9a3d797d5-7 \
--topics AWSKafkaTopic \
--starting-position LATEST \
--function-name my-kafka-function \
--source-access-configurations '[{"Type": "CLIENT_CERTIFICATE_TLS_AUTH","URI": "arn:aws:secretsmanager:us-east-1:444455556666:secret:my-secret"}]'
```
# Tutti i parametri di configurazione dell'origine degli eventi Amazon MSK in Lambda
Tutti i tipi di sorgenti di eventi Lambda condividono le stesse operazioni [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)e quelle dell'[UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)API. Tuttavia, solo alcuni parametri si applicano ad Amazon MSK, come illustrato nella tabella seguente.
| Parametro | Obbligatorio | Predefinito | Note |
| --- | --- | --- | --- |
| AmazonManagedKafkaEventSourceConfig | N | Contiene il ConsumerGroupId campo, che per impostazione predefinita è un valore univoco. | Può essere impostato solo su Create |
| BatchSize | N | 100 | Massimo: 10.000. |
| DestinationConfig | N | N/D | [Acquisizione di batch scartati per un'origine eventi di Amazon MSK e Apache Kafka autogestito](kafka-on-failure.md) |
| Abilitato | N | True | |
| BisectBatchOnFunctionError | N | False | [Configurazione dei controlli di gestione degli errori per le sorgenti di eventi Kafka](kafka-retry-configurations.md) |
| FunctionResponseTypes | N | N/D | [Configurazione dei controlli di gestione degli errori per le sorgenti di eventi Kafka](kafka-retry-configurations.md) |
| MaximumRecordAgeInSeconds | N | -1 (infinito) | [Configurazione dei controlli di gestione degli errori per le sorgenti di eventi Kafka](kafka-retry-configurations.md) |
| MaximumRetryAttempts | N | -1 (infinito) | [Configurazione dei controlli di gestione degli errori per le sorgenti di eventi Kafka](kafka-retry-configurations.md) |
| EventSourceArn | Y | N/D | Può essere impostato solo su Create |
| FilterCriteria | N | N/D | [Controllare gli eventi che Lambda invia alla funzione](invocation-eventfiltering.md) |
| FunctionName | Y | N/D | |
| KMSKeyBraccio | N | N/D | [Crittografia dei criteri di filtro](invocation-eventfiltering.md#filter-criteria-encryption) |
| MaximumBatchingWindowInSeconds | N | 500 ms | [Comportamento di batching](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching) |
| ProvisionedPollersConfig | N | `MinimumPollers`: se non specificato, il valore predefinito è 1 `MaximumPollers`: se non specificato, il valore predefinito è 200 `PollerGroupName`: N/A | [Modalità provisioning](kafka-scaling-modes.md#kafka-provisioned-mode) |
| SourceAccessConfigurations | N | Nessuna credenziale | Credenziali di autenticazione SASL/SCRAM o CLIENT\$1CERTIFICATE\$1TLS\$1AUTH (MutualTLS) per la tua origine eventi |
| StartingPosition | Y | N/D | AT\$1TIMESTAMP, TRIM\$1HORIZON o LATEST Può essere impostato solo su Create |
| StartingPositionTimestamp | N | N/D | Obbligatorio se StartingPosition è impostato su AT\$1TIMESTAMP |
| Tag | N | N/D | [Utilizzo di tag negli strumenti di mappatura dell'origine degli eventi](tags-esm.md) |
| Argomenti | Y | N/D | Nome argomento Kafka Può essere impostato solo su Create |
**Nota**
Quando si specifica una`PollerGroupName`, più unità ESMs all'interno dello stesso Amazon VPC possono condividere la capacità dell'Event Poller Unit (EPU). Puoi utilizzare questa opzione per ottimizzare i costi della modalità Provisioned per i tuoi. ESMs Requisiti per il raggruppamento ESM:
ESMs deve trovarsi all'interno dello stesso Amazon VPC
Massimo 100 ESMs per gruppo di sondaggi
Il numero massimo aggregato di sondaggi di tutti ESMs i membri di un gruppo non può superare i 2000
È possibile aggiornare il file `PollerGroupName` per spostare un ESM in un gruppo diverso oppure rimuovere un ESM da un gruppo `PollerGroupName` impostandolo su una stringa vuota («»).
# Tutorial: Utilizzo di uno strumento di mappatura dell'origine degli eventi Amazon MSK per richiamare una funzione Lambda
In questo tutorial verranno eseguite le seguenti operazioni:
+ Crea una funzione Lambda nello stesso AWS account di un cluster Amazon MSK esistente.
+ Configura la rete e l'autenticazione per consentire a Lambda di comunicare con Amazon MSK.
+ Configura uno strumento di mappatura dell'origine degli eventi Lambda Amazon MSK, che esegue la funzione Lambda quando gli eventi vengono visualizzati nell'argomento.
Dopo aver completato questi passaggi, quando gli eventi vengono inviati ad Amazon MSK, potrai configurare una funzione Lambda per elaborare tali eventi automaticamente con il tuo codice Lambda personalizzato.
**Cosa puoi fare con questa funzionalità?**
**Soluzione di esempio: utilizza uno strumento di mappatura dell'origine degli eventi MSK per fornire risultati in tempo reale ai tuoi clienti.**
Considera lo scenario seguente: la tua azienda ospita un'applicazione Web in cui i clienti possono visualizzare informazioni sugli eventi dal vivo, come le partite sportive. Gli aggiornamenti delle informazioni dal gioco vengono forniti al tuo team tramite un argomento Kafka su Amazon MSK. Vuoi progettare una soluzione che utilizzi gli aggiornamenti dell'argomento MSK per fornire una visione aggiornata dell'evento dal vivo ai clienti all'interno di un'applicazione da te sviluppata. Hai deciso il seguente approccio di progettazione: le tue applicazioni client comunicheranno con un backend serverless ospitato in AWS. I client si connetteranno tramite sessioni websocket utilizzando l'API Amazon WebSocket API Gateway.
In questa soluzione, è necessario un componente che legga gli eventi MSK, esegua una logica personalizzata per preparare tali eventi per il livello dell'applicazione e quindi inoltri tali informazioni all'API Gateway. Puoi implementare questo componente con AWS Lambda, fornendo la tua logica personalizzata in una funzione Lambda, quindi chiamandolo con una mappatura dell'origine degli eventi AWS Lambda Amazon MSK.
Per ulteriori informazioni sull'implementazione di soluzioni utilizzando l'API Amazon WebSocket API Gateway, consulta [i tutorial sulle WebSocket API nella documentazione](https://docs.aws.amazon.com/apigateway/latest/developerguide/websocket-api-chat-app.html) di API Gateway.
## Prerequisiti
Un AWS account con le seguenti risorse preconfigurate:
**Per soddisfare questi prerequisiti, ti consigliamo di consultare la sezione [Guida introduttiva all'uso di Amazon MSK](https://docs.aws.amazon.com//msk/latest/developerguide/getting-started.html) nella documentazione di Amazon MSK.**
+ UN cluster Amazon MSK. Consulta [Creare un cluster Amazon MSK](https://docs.aws.amazon.com//msk/latest/developerguide/create-cluster.html) in *Guida introduttiva all'uso di Amazon MSK*.
+ La seguente configurazione:
+ Assicurati che l'**autenticazione basata sui ruoli IAM** sia **abilitata** nelle impostazioni di sicurezza del cluster. Ciò aumenta la sicurezza limitando la funzione Lambda al solo accesso alle risorse Amazon MSK necessarie. Questa funzionalità è abilitata per impostazione predefinita per i nuovi cluster Amazon MSK.
+ Assicurati che l'**accesso pubblico** sia disattivato nelle impostazioni di rete del cluster. Limitare l'accesso a Internet del cluster Amazon MSK migliora la sicurezza limitando il numero di intermediari che gestiscono i dati. Questa funzionalità è abilitata per impostazione predefinita per i nuovi cluster Amazon MSK.
+ Un argomento Kafka nel tuo cluster Amazon MSK da utilizzare per questa soluzione. Consulta [Creare un argomento](https://docs.aws.amazon.com//msk/latest/developerguide/create-topic.html) in *Guida introduttiva all'uso di Amazon MSK*.
+ Un host di amministrazione Kafka configurato per recuperare informazioni dal tuo cluster Kafka e inviare eventi Kafka al tuo argomento per i test, ad esempio un'istanza Amazon EC2 con la CLI di amministrazione Kafka e la libreria IAM Amazon MSK installate. Consulta [Creare una macchina client](https://docs.aws.amazon.com//msk/latest/developerguide/create-client-machine.html) in *Guida introduttiva all'uso di Amazon MSK*.
Dopo aver configurato queste risorse, raccogli le seguenti informazioni dal tuo AWS account per confermare che sei pronto a continuare.
+ Il nome del cluster Amazon MSK. È possibile trovare queste informazioni nella console Amazon MSK.
+ L'UUID del cluster, parte dell'ARN per il tuo cluster Amazon MSK, che puoi trovare nella console Amazon MSK. Segui le procedure in [Elencare i cluster](https://docs.aws.amazon.com/msk/latest/developerguide/msk-list-clusters.html) nella documentazione di Amazon MSK per trovare queste informazioni.
+ I gruppi di sicurezza associati al cluster Amazon MSK. È possibile trovare queste informazioni nella console Amazon MSK. Nei passaggi seguenti, definiscile come tue*clusterSecurityGroups*.
+ L'ID Amazon VPC contenente il cluster Amazon MSK. Puoi trovare queste informazioni identificando le sottoreti associate al tuo cluster Amazon MSK nella console Amazon MSK, quindi identificando l'Amazon VPC associato alla sottorete nella console Amazon VPC.
+ Il nome dell'argomento Kafka usato nella tua soluzione. Puoi trovare queste informazioni chiamando il tuo cluster Amazon MSK con l'`topics` CLI di Kafka dal tuo host di amministrazione Kafka. Per ulteriori informazioni sugli argomenti della CLI, consulta [Aggiungere e rimuovere argomenti](https://kafka.apache.org/documentation/#basic_ops_add_topic) nella documentazione di Kafka.
+ Il nome di un gruppo di consumer per l'argomento Kafka, adatto all'uso con la funzione Lambda. Questo gruppo può essere creato automaticamente da Lambda, quindi non devi crearlo con la CLI Kafka. Se devi gestire i tuoi gruppi di consumer, per saperne di più sulla CLI dei gruppi di consumer, consulta [Gestione dei gruppi di consumer](https://kafka.apache.org/documentation/#basic_ops_consumer_group) nella documentazione di Kafka.
Le seguenti autorizzazioni nel tuo AWS account:
+ Autorizzazione per creare e gestire una funzione Lambda.
+ Autorizzazione per creare policy IAM e associarle alla funzione Lambda.
+ Autorizzazione a creare endpoint Amazon VPC e modificare la configurazione di rete nell'Amazon VPC che ospita il cluster Amazon MSK.
### Installa il AWS Command Line Interface
Se non l'hai ancora installato AWS Command Line Interface, segui i passaggi indicati in [Installazione o aggiornamento della versione più recente di AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) per installarlo.
Per eseguire i comandi nel tutorial, sono necessari un terminale a riga di comando o una shell (interprete di comandi). In Linux e macOS, utilizza la shell (interprete di comandi) e il gestore pacchetti preferiti.
**Nota**
Su Windows, alcuni comandi della CLI Bash utilizzati comunemente con Lambda (ad esempio, `zip`) non sono supportati dai terminali integrati del sistema operativo. Per ottenere una versione integrata su Windows di Ubuntu e Bash, [installa il sottosistema Windows per Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10).
## Configurare la connettività di rete per consentire a Lambda di comunicare con Amazon MSK
AWS PrivateLink Usalo per connettere Lambda e Amazon MSK. È possibile farlo creando endpoint Amazon VPC di interfaccia nella console Amazon VPC. Per ulteriori informazioni sui problemi di configurazioni di rete, consulta [Configurazione del cluster Amazon MSK e della rete Amazon VPC per Lambda](with-msk-cluster-network.md).
Quando uno strumento di mappatura dell'origine degli eventi Amazon MSK viene eseguita per conto di una funzione Lambda, assume il ruolo di esecuzione della funzione Lambda. Questo ruolo IAM autorizza la mappatura per accedere a risorse protette da IAM, come il cluster Amazon MSK. Sebbene i componenti condividano un ruolo di esecuzione, la mappatura Amazon MSK e la funzione Lambda hanno requisiti di connettività separati per le rispettive attività, come illustrato nel diagramma seguente.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/msk_tut_network.png)
Lo strumento di mappatura dell'origine degli eventi appartiene al gruppo di sicurezza del cluster Amazon MSK. In questa fase di networking, crea endpoint Amazon VPC dal tuo VPC del cluster Amazon MSK per connettere lo strumento di mappatura dell'origine degli eventi ai servizi Lambda e STS. Proteggi questi endpoint per accettare il traffico proveniente dal tuo gruppo di sicurezza del cluster Amazon MSK. Quindi, modifica i gruppi di sicurezza del cluster Amazon MSK per consentire allo strumento di mappatura dell'origine degli eventi di comunicare con il cluster Amazon MSK.
Puoi configurare la procedura seguente utilizzando la Console di gestione AWS.
**Per configurare gli endpoint Amazon VPC di interfaccia per connettere Lambda e Amazon MSK**
1. Crea un gruppo di sicurezza per gli endpoint Amazon VPC della tua interfaccia*endpointSecurityGroup*, che consenta il traffico TCP in entrata su 443 da. *clusterSecurityGroups* Segui la procedura in [Creare un gruppo di sicurezza](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/working-with-security-groups.html#creating-security-group) nella documentazione di Amazon EC2 per creare un gruppo di sicurezza. Quindi, segui la procedura in [Aggiungere regole a un gruppo di sicurezza](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule) nella documentazione di Amazon EC2 per aggiungere le regole appropriate.
**Crea un gruppo di sicurezza con le seguenti informazioni:**
Quando aggiungi le regole in entrata, crea una regola per ogni gruppo di sicurezza in. *clusterSecurityGroups* Per ogni regola:
+ Per **Tipo**, seleziona **HTTPS**.
+ Per **Origine**, seleziona uno dei. *clusterSecurityGroups*
1. Crea un endpoint che connette il servizio Lambda all'Amazon VPC contenente il cluster Amazon MSK. Segui la procedura riportata in [Creare un endpoint di interfaccia](https://docs.aws.amazon.com//vpc/latest/privatelink/create-interface-endpoint.html).
**Crea un endpoint di interfaccia con le seguenti informazioni:**
+ Per **Nome servizio**, seleziona`com.amazonaws.regionName.lambda`, dove *regionName* ospita la funzione Lambda.
+ Per **VPC**, seleziona l'Amazon VPC contenente il cluster Amazon MSK.
+ Per i **gruppi di sicurezza**, seleziona*endpointSecurityGroup*, che hai creato in precedenza.
+ Per **Sottoreti**, seleziona le sottoreti che ospitano il tuo cluster Amazon MSK.
+ Per **Policy**, fornisci il seguente documento di policy, che protegge l'endpoint per l'utilizzo da parte del responsabile del servizio Lambda per l'azione `lambda:InvokeFunction`.
```
{
"Statement": [
{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
+ Assicurati **Abilita nome DNS** rimanga impostato.
1. Crea un endpoint che collega il AWS STS servizio all'Amazon VPC contenente il tuo cluster Amazon MSK. Segui la procedura riportata in [Creare un endpoint di interfaccia](https://docs.aws.amazon.com//vpc/latest/privatelink/create-interface-endpoint.html).
**Crea un endpoint di interfaccia con le seguenti informazioni:**
+ Per **Nome del servizio**, seleziona. AWS STS
+ Per **VPC**, seleziona l'Amazon VPC contenente il cluster Amazon MSK.
+ Per i **gruppi di sicurezza**, selezionare*endpointSecurityGroup*.
+ Per **Sottoreti**, seleziona le sottoreti che ospitano il tuo cluster Amazon MSK.
+ Per **Policy**, fornisci il seguente documento di policy, che protegge l'endpoint per l'utilizzo da parte del responsabile del servizio Lambda per l'azione `sts:AssumeRole`.
```
{
"Statement": [
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
+ Assicurati **Abilita nome DNS** rimanga impostato.
1. Per ogni gruppo di sicurezza associato al tuo cluster Amazon MSK, ovvero in*clusterSecurityGroups*, consenti quanto segue:
+ Consenti tutto il traffico TCP in entrata e in uscita su 9098 verso tutti, anche all'interno di *clusterSecurityGroups* se stesso.
+ Consenti tutto il traffico TCP in uscita su 443.
Parte di questo traffico è consentito dalle regole predefinite del gruppo di sicurezza, quindi se il cluster è collegato a un singolo gruppo di sicurezza e tale gruppo ha regole predefinite, non sono necessarie regole aggiuntive. Per ottimizzare le regole del gruppo di sicurezza, segui la procedura in [Aggiungere regole a un gruppo di sicurezza](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule) nella documentazione di Amazon EC2.
**Aggiungi le regole ai tuoi gruppi di sicurezza con le seguenti informazioni:**
+ Per ogni regola in entrata o in uscita per la porta 9098, fornisci
+ Per **Type (Tipo)** seleziona **Custom TCP (TCP personalizzato)**.
+ Per **Intervallo di porte**, specifica 9098.
+ Per **Source, fornisci** uno dei. *clusterSecurityGroups*
+ Per ogni regola in entrata per la porta 443, per **Tipo**, seleziona **HTTPS**.
## Crea un ruolo IAM perché Lambda legga dal tuo argomento Amazon MSK
Identifica i requisiti di autenticazione perché Lambda legga dall'argomento di Amazon MSK, quindi definiscili in una policy. Crea un ruolo che autorizzi *lambdaAuthRole* Lambda a utilizzare tali autorizzazioni. Autorizza le azioni sul tuo cluster Amazon MSK utilizzando azioni `kafka-cluster` IAM. Quindi, autorizza Lambda a eseguire le azioni di Amazon `kafka` MSK e Amazon EC2 necessarie per scoprire e connettersi al tuo cluster Amazon MSK, nonché le CloudWatch azioni in modo che Lambda possa registrare ciò che ha fatto.
**Per descrivere i requisiti di autenticazione perché Lambda legga da Amazon MSK**
1. Scrivi un documento di policy IAM (un documento JSON)*clusterAuthPolicy*, che consenta a Lambda di leggere il tuo argomento Kafka nel tuo cluster Amazon MSK utilizzando il tuo gruppo di consumatori Kafka. Lambda richiede che durante la lettura sia impostato un gruppo di consumer Kafka.
Modifica il seguente modello per allinearlo ai tuoi prerequisiti:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:DescribeGroup",
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeTopic",
"kafka-cluster:ReadData",
"kafka-cluster:DescribeClusterDynamicConfiguration"
],
"Resource": [
"arn:aws:kafka:us-east-1:111122223333:cluster/mskClusterName/cluster-uuid",
"arn:aws:kafka:us-east-1:111122223333:topic/mskClusterName/cluster-uuid/mskTopicName",
"arn:aws:kafka:us-east-1:111122223333:group/mskClusterName/cluster-uuid/mskGroupName"
]
}
]
}
```
------
Per ulteriori informazioni, consulta [Configurazione delle autorizzazioni Lambda per le mappature delle sorgenti degli eventi Amazon MSK](with-msk-permissions.md). Quando scrivi la tua policy:
+ Sostituisci *us-east-1* e *111122223333* con Regione AWS e Account AWS del tuo cluster Amazon MSK.
+ Per*mskClusterName*, fornisci il nome del tuo cluster Amazon MSK.
+ Per*cluster-uuid*, fornisci l'UUID nell'ARN per il tuo cluster Amazon MSK.
+ Per*mskTopicName*, fornisci il nome del tuo argomento su Kafka.
+ Per*mskGroupName*, fornisci il nome del tuo gruppo di consumatori Kafka.
1. Identifica Amazon MSK, Amazon EC2 CloudWatch e le autorizzazioni necessarie a Lambda per rilevare e connettere il tuo cluster Amazon MSK e registrare tali eventi.
La policy gestita da `AWSLambdaMSKExecutionRole` definisce in modo permissivo le autorizzazioni richieste. Utilizzalo nelle fasi seguenti.
In un ambiente di produzione, valuta `AWSLambdaMSKExecutionRole` per limitare la policy del ruolo di esecuzione in base al principio del privilegio minimo, quindi scrivi una policy per il tuo ruolo che sostituisca questa policy gestita.
Per i dettagli sul linguaggio della policy IAM, consulta la [documentazione IAM](https://docs.aws.amazon.com//iam/).
Ora che hai scritto il tuo documento di policy, crea una policy IAM in modo da poterla collegare al tuo ruolo. È possibile effettuare tale operazione mediante la console utilizzando la seguente procedura.
**Per creare una policy IAM dal documento della policy**
1. Accedi Console di gestione AWS e apri la console IAM all'indirizzo. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Nel riquadro di navigazione a sinistra, seleziona **Policies (Policy)**.
1. Scegli **Crea policy**.
1. Nella sezione **Editor di policy**, scegli l'opzione **JSON**.
1. Incolla*clusterAuthPolicy*.
1. Una volta terminata l'aggiunta delle autorizzazioni alla policy, scegli **Successivo**.
1. Nella pagina **Verifica e crea**, digita i valori per **Nome policy** e **Descrizione** (facoltativa) per la policy che si sta creando. Rivedi **Autorizzazioni definite in questa policy** per visualizzare le autorizzazioni concesse dalla policy.
1. Seleziona **Crea policy** per salvare la nuova policy.
Per ulteriori informazioni, consulta [Creazione di policy IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_create.html) nella documentazione di IAM.
Ora che disponi delle policy IAM appropriate, crea un ruolo e associale ad esso. È possibile effettuare tale operazione mediante la console utilizzando la seguente procedura.
**Per creare un ruolo di esecuzione nella console IAM**
1. Aprire la pagina [Roles (Ruoli)](https://console.aws.amazon.com/iam/home#/roles) nella console IAM.
1. Scegli **Crea ruolo**.
1. In **Tipo di entità attendibile**, scegli **Servizio AWS **.
1. In **Use case** (Caso d'uso), scegli **Lambda**.
1. Scegli **Next (Successivo)**.
1. Selezionare le seguenti policy:
+ *clusterAuthPolicy*
+ `AWSLambdaMSKExecutionRole`
1. Scegli **Next (Successivo)**.
1. Per **Nome ruolo**, inserisci *lambdaAuthRole* e quindi scegli **Crea ruolo**.
Per ulteriori informazioni, consulta [Definizione delle autorizzazioni della funzione Lambda con un ruolo di esecuzione](lambda-intro-execution-role.md).
## Creare una funzione Lambda per leggere dal tuo argomento Amazon MSK
Crea una funzione Lambda configurata per utilizzare il tuo ruolo IAM. È possibile creare la funzione Lambda utilizzando la console.
**Per creare una funzione Lambda utilizzando la tua configurazione di autenticazione**
1. Apri la console Lambda e seleziona **Crea funzione** dall'intestazione.
1. Scegli **Crea da zero**.
1. Per **Nome della funzione**, fornisci un nome appropriato a tua scelta.
1. Per **Runtime**, scegli l'**ultima versione supportata** di `Node.js` per utilizzare il codice fornito in questo tutorial.
1. Scegli **Cambia ruolo di esecuzione predefinito**.
1. Seleziona **Utilizza un ruolo esistente**.
1. Per **Ruolo esistente**, seleziona*lambdaAuthRole*.
In un ambiente di produzione, in genere è necessario aggiungere ulteriori policy al ruolo di esecuzione per la funzione Lambda per elaborare in modo significativo gli eventi Amazon MSK. Per ulteriori informazioni sull'aggiunta di policy al tuo ruolo, consulta [Aggiungere o rimuovere le autorizzazioni di identità](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console) nella documentazione IAM.
## Creare uno strumento di mappatura dell'origine degli eventi sulla funzione Lambda
Lo strumento di mappatura dell'origine degli eventi Amazon MSK fornisce al servizio Lambda le informazioni necessarie per richiamare Lambda quando si verificano gli eventi Amazon MSK appropriati. Puoi creare una mappatura Amazon MSK utilizzando la console. Crea un trigger Lambda, quindi lo strumento di mappatura dell'origine degli eventi viene impostato automaticamente.
**Per creare un trigger Lambda (e uno strumento di mappatura dell'origine degli eventi)**
1. Vai alla pagina della panoramica della tua funzione Lambda.
1. Nella sezione della panoramica della funzione, scegli **Aggiungi trigger** in basso a sinistra.
1. Nel menu a discesa **Seleziona un'origine**, seleziona **Amazon MSK**.
1. Non impostare l'**autenticazione**.
1. Per **Cluster MSK** seleziona il nome del cluster.
1. Per **Dimensioni del batch**, immetti 1. Questo passaggio semplifica il test di questa funzionalità e non rappresenta un valore ideale nella produzione.
1. Per **Nome argomento**, fornisci il nome del tuo argomento Kafka.
1. Per l'**ID del gruppo di consumer**, fornisci l'ID del tuo gruppo di consumer Kafka.
## Aggiornare la funzione Lambda per leggere i dati di streaming
Lambda fornisce informazioni sugli eventi di Kafka tramite il parametro event method. Per una struttura di esempio di un evento Amazon MSK, consulta [Esempio di evento](with-msk.md#msk-sample-event). Dopo aver capito come interpretare gli eventi Amazon MSK inoltrati da Lambda, puoi modificare il codice della funzione Lambda per utilizzare le informazioni fornite.
Fornisci il seguente codice alla tua funzione Lambda per registrare il contenuto di un evento Lambda Amazon MSK a scopo di test:
------
#### [ .NET ]
**SDK per .NET**
C'è altro da fare GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Utilizzo di un evento Amazon MSK con Lambda tramite .NET.
```
using System.Text;
using Amazon.Lambda.Core;
using Amazon.Lambda.KafkaEvents;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace MSKLambda;
public class Function
{
/// The event for the Lambda function handler to process.
/// The ILambdaContext that provides methods for logging and describing the Lambda environment.
///
public void FunctionHandler(KafkaEvent evnt, ILambdaContext context)
{
foreach (var record in evnt.Records)
{
Console.WriteLine("Key:" + record.Key);
foreach (var eventRecord in record.Value)
{
var valueBytes = eventRecord.Value.ToArray();
var valueText = Encoding.UTF8.GetString(valueBytes);
Console.WriteLine("Message:" + valueText);
}
}
}
}
```
------
#### [ Go ]
**SDK per Go V2**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Utilizzo di un evento Amazon MSK con Lambda tramite Go.
```
package main
import (
"encoding/base64"
"fmt"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func handler(event events.KafkaEvent) {
for key, records := range event.Records {
fmt.Println("Key:", key)
for _, record := range records {
fmt.Println("Record:", record)
decodedValue, _ := base64.StdEncoding.DecodeString(record.Value)
message := string(decodedValue)
fmt.Println("Message:", message)
}
}
}
func main() {
lambda.Start(handler)
}
```
------
#### [ Java ]
**SDK per Java 2.x**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Utilizzo di un evento Amazon MSK con Lambda tramite Java.
```
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.KafkaEvent;
import com.amazonaws.services.lambda.runtime.events.KafkaEvent.KafkaEventRecord;
import java.util.Base64;
import java.util.Map;
public class Example implements RequestHandler {
@Override
public Void handleRequest(KafkaEvent event, Context context) {
for (Map.Entry> entry : event.getRecords().entrySet()) {
String key = entry.getKey();
System.out.println("Key: " + key);
for (KafkaEventRecord record : entry.getValue()) {
System.out.println("Record: " + record);
byte[] value = Base64.getDecoder().decode(record.getValue());
String message = new String(value);
System.out.println("Message: " + message);
}
}
return null;
}
}
```
------
#### [ JavaScript ]
**SDK per JavaScript (v3)**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Consumo di un evento Amazon MSK con JavaScript Lambda utilizzando.
```
exports.handler = async (event) => {
// Iterate through keys
for (let key in event.records) {
console.log('Key: ', key)
// Iterate through records
event.records[key].map((record) => {
console.log('Record: ', record)
// Decode base64
const msg = Buffer.from(record.value, 'base64').toString()
console.log('Message:', msg)
})
}
}
```
Consumo di un evento Amazon MSK con TypeScript Lambda utilizzando.
```
import { MSKEvent, Context } from "aws-lambda";
import { Buffer } from "buffer";
import { Logger } from "@aws-lambda-powertools/logger";
const logger = new Logger({
logLevel: "INFO",
serviceName: "msk-handler-sample",
});
export const handler = async (
event: MSKEvent,
context: Context
): Promise => {
for (const [topic, topicRecords] of Object.entries(event.records)) {
logger.info(`Processing key: ${topic}`);
// Process each record in the partition
for (const record of topicRecords) {
try {
// Decode the message value from base64
const decodedMessage = Buffer.from(record.value, 'base64').toString();
logger.info({
message: decodedMessage
});
}
catch (error) {
logger.error('Error processing event', { error });
throw error;
}
};
}
}
```
------
#### [ PHP ]
**SDK per PHP**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Utilizzo di un evento Amazon MSK con Lambda tramite PHP.
```
logger = $logger;
}
/**
* @throws JsonException
* @throws \Bref\Event\InvalidLambdaEvent
*/
public function handle(mixed $event, Context $context): void
{
$kafkaEvent = new KafkaEvent($event);
$this->logger->info("Processing records");
$records = $kafkaEvent->getRecords();
foreach ($records as $record) {
try {
$key = $record->getKey();
$this->logger->info("Key: $key");
$values = $record->getValue();
$this->logger->info(json_encode($values));
foreach ($values as $value) {
$this->logger->info("Value: $value");
}
} catch (Exception $e) {
$this->logger->error($e->getMessage());
}
}
$totalRecords = count($records);
$this->logger->info("Successfully processed $totalRecords records");
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**SDK per Python (Boto3)**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Utilizzo di un evento Amazon MSK con Lambda tramite Python.
```
import base64
def lambda_handler(event, context):
# Iterate through keys
for key in event['records']:
print('Key:', key)
# Iterate through records
for record in event['records'][key]:
print('Record:', record)
# Decode base64
msg = base64.b64decode(record['value']).decode('utf-8')
print('Message:', msg)
```
------
#### [ Ruby ]
**SDK per Ruby**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Utilizzo di un evento Amazon MSK con Lambda tramite Ruby.
```
require 'base64'
def lambda_handler(event:, context:)
# Iterate through keys
event['records'].each do |key, records|
puts "Key: #{key}"
# Iterate through records
records.each do |record|
puts "Record: #{record}"
# Decode base64
msg = Base64.decode64(record['value'])
puts "Message: #{msg}"
end
end
end
```
------
#### [ Rust ]
**SDK per Rust**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Utilizzo di un evento Amazon MSK con Lambda tramite Rust.
```
use aws_lambda_events::event::kafka::KafkaEvent;
use lambda_runtime::{run, service_fn, tracing, Error, LambdaEvent};
use base64::prelude::*;
use serde_json::{Value};
use tracing::{info};
/// Pre-Requisites:
/// 1. Install Cargo Lambda - see https://www.cargo-lambda.info/guide/getting-started.html
/// 2. Add packages tracing, tracing-subscriber, serde_json, base64
///
/// This is the main body for the function.
/// Write your code inside it.
/// There are some code example in the following URLs:
/// - https://github.com/awslabs/aws-lambda-rust-runtime/tree/main/examples
/// - https://github.com/aws-samples/serverless-rust-demo/
async fn function_handler(event: LambdaEvent) -> Result {
let payload = event.payload.records;
for (_name, records) in payload.iter() {
for record in records {
let record_text = record.value.as_ref().ok_or("Value is None")?;
info!("Record: {}", &record_text);
// perform Base64 decoding
let record_bytes = BASE64_STANDARD.decode(record_text)?;
let message = std::str::from_utf8(&record_bytes)?;
info!("Message: {}", message);
}
}
Ok(().into())
}
#[tokio::main]
async fn main() -> Result<(), Error> {
// required to enable CloudWatch error logging by the runtime
tracing::init_default_subscriber();
info!("Setup CW subscriber!");
run(service_fn(function_handler)).await
}
```
------
È possibile fornire il codice della funzione a Lambda utilizzando la console.
**Aggiornamento del codice della funzione utilizzando l'editor di codice della console**
1. Apri la [pagina Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda e scegli la tua funzione.
1. Scegli la scheda **Codice**.
1. Nel riquadro **Origine del codice**, seleziona il tuo file di codice sorgente e modificalo nell'editor di codice integrato.
1. Nella sezione **DEPLOY**, scegli **Implementa** per aggiornare il codice della tua funzione:
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/getting-started-tutorial/deploy-console.png)
## Testa la tua funzione Lambda per verificare che sia connessa al tuo argomento Amazon MSK
Ora puoi verificare se la tua Lambda viene richiamata o meno dall'origine dell'evento CloudWatch controllando i registri degli eventi.
**Per verificare se la funzione Lambda viene richiamata**
1. Usa il tuo host di amministrazione Kafka per generare eventi Kafka utilizzando la CLI `kafka-console-producer`. Per ulteriori informazioni, consulta [Scrivere alcuni eventi nell'argomento](https://kafka.apache.org/documentation/#quickstart_send) della documentazione di Kafka. Invia un numero sufficiente di eventi per riempire il batch definito dalla dimensione del batch per lo strumento di mappatura dell'origine degli eventi definito nel passaggio precedente, altrimenti Lambda aspetterà che vengano richiamate ulteriori informazioni.
1. Se la funzione viene eseguita, Lambda scrive cosa è successo a. CloudWatch Nella console, passa alla pagina dei dettagli della funzione Lambda.
1. Selezionare la scheda **Configurazione**.
1. Dalla barra laterale, seleziona **Strumenti di monitoraggio e operazioni**.
1. Identifica il **gruppo di CloudWatch log** in **Logging configuration.** Il gruppo di log dovrebbe iniziare con `/aws/lambda`. Scegli il link del gruppo di log.
1. Nella CloudWatch console, controlla gli eventi di **registro per gli eventi** di registro che Lambda ha inviato al flusso di log. Identifica se ci sono eventi del log contenenti il messaggio del tuo evento Kafka, come nell'immagine seguente. In tal caso, hai collegato correttamente una funzione Lambda ad Amazon MSK con uno strumento di mappatura dell'origine degli eventi Lambda.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/msk_tut_log.png)
# Utilizzo di Lambda con Apache Kafka gestito dal cliente
Questo argomento descrive come utilizzare Lambda con un cluster Kafka autogestito. In AWS terminologia, un cluster autogestito include cluster Kafka non AWS ospitati. Ad esempio, è possibile ospitare il proprio cluster Kafka con un provider cloud come [Confluent Cloud](https://www.confluent.io/confluent-cloud/) o [Redpanda](https://www.redpanda.com/).
Questo capitolo spiega come utilizzare un cluster Apache Kafka autogestito come origine di eventi per la funzione Lambda. Il processo generale per l'integrazione di Apache Kafka autogestito con Lambda prevede i seguenti passaggi:
1. **[Configurazione del cluster e della rete](with-kafka-cluster-network.md)**: per prima cosa, configura il cluster Apache Kafka autogestito con la configurazione di rete corretta per consentire a Lambda di accedere al cluster.
1. **[Configurazione della mappatura delle sorgenti degli eventi](with-kafka-configure.md)**: quindi, crea la risorsa di [mappatura delle sorgenti degli eventi](invocation-eventsourcemapping.md) di cui Lambda ha bisogno per connettere in modo sicuro il cluster Apache Kafka alla tua funzione.
1. **[Configurazione delle funzioni e delle autorizzazioni](with-kafka-permissions.md)**[: infine, assicurati che la funzione sia configurata correttamente e disponga delle autorizzazioni necessarie nel suo ruolo di esecuzione.](lambda-intro-execution-role.md)
Apache Kafka come origine eventi funziona in modo simile all'utilizzo di Amazon Simple Queue Service (Amazon SQS) o Amazon Kinesis. Lambda interroga internamente i nuovi messaggi dell'origine eventi, quindi richiama in modo sincrono la funzione Lambda di destinazione. Lambda legge i messaggi in batch e li fornisce alla funzione come payload di evento. La dimensione massima del batch è configurabile (l'impostazione predefinita è 100 messaggi). Per ulteriori informazioni, consulta [Comportamento di batching](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching).
Per ottimizzare il throughput dello strumento di mappatura dell'origine degli eventi di Apache Kafla autogestito, configura la modalità provisioning. In modalità provisioning, puoi definire il numero minimo e massimo di poller di eventi assegnati allo strumento di mappatura dell'origine degli eventi. Ciò può migliorare la capacità dello strumento di mappatura dell'origine degli eventi per gestire picchi di messaggi imprevisti. Per ulteriori informazioni, consulta [Modalità provisioning](kafka-scaling-modes.md#kafka-provisioned-mode).
**avvertimento**
Gli strumenti di mappatura dell'origine degli eventi elaborano ogni evento almeno una volta e può verificarsi un'elaborazione duplicata dei record. Per evitare potenziali problemi legati agli eventi duplicati, ti consigliamo vivamente di rendere idempotente il codice della funzione. Per ulteriori informazioni, consulta [Come posso rendere idempotente la mia funzione Lambda](https://repost.aws/knowledge-center/lambda-function-idempotent) nel Knowledge Center. AWS
Per le origini eventi basate su KAFKA, Lambda supporta i parametri di controllo dell'elaborazione, come le finestre di batch e le dimensioni del batch. Per ulteriori informazioni, consulta [Comportamento di batching](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching).
Per un esempio di come utilizzare Kafka autogestito come fonte di eventi, vedi [Utilizzo di Apache Kafka ospitato autonomamente come fonte di eventi per sul blog di Compute](https://aws.amazon.com/blogs/compute/using-self-hosted-apache-kafka-as-an-event-source-for-aws-lambda/). AWS Lambda AWS
**Topics**
+ [
## Esempio di evento
](#smaa-sample-event)
+ [
# Configurazione del cluster e della rete Apache Kafka autogestiti per Lambda
](with-kafka-cluster-network.md)
+ [
# Configurazione delle autorizzazioni del ruolo di esecuzione Lambda
](with-kafka-permissions.md)
+ [
# Configurazione di origini eventi Apache Kafka autogestito per Lambda
](with-kafka-configure.md)
## Esempio di evento
Lambda invia il batch di messaggi nel parametro evento quando richiama la funzione Lambda. Il payload evento contiene un array di messaggi. Ogni elemento dell'array contiene i dettagli dell'argomento Kafka e dell'identificatore dello shard Kafka, insieme a una data/ora e a un messaggio con codifica base64.
```
{
"eventSource": "SelfManagedKafka",
"bootstrapServers":"b-2.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092,b-1.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092",
"records":{
"mytopic-0":[
{
"topic":"mytopic",
"partition":0,
"offset":15,
"timestamp":1545084650987,
"timestampType":"CREATE_TIME",
"key":"abcDEFghiJKLmnoPQRstuVWXyz1234==",
"value":"SGVsbG8sIHRoaXMgaXMgYSB0ZXN0Lg==",
"headers":[
{
"headerKey":[
104,
101,
97,
100,
101,
114,
86,
97,
108,
117,
101
]
}
]
}
]
}
}
```
# Configurazione del cluster e della rete Apache Kafka autogestiti per Lambda
Per connettere la funzione Lambda al cluster Apache Kafka autogestito, devi configurare correttamente il cluster e la rete in cui si trova. Questa pagina spiega come configurare il cluster e la rete. Se il cluster e la rete sono già configurati correttamente, consulta [Configurazione di origini eventi Apache Kafka autogestito per Lambda](with-kafka-configure.md) Configurare la mappatura delle sorgenti degli eventi.
**Topics**
+ [
## Un cluster Apache Kafka autogestito.
](#kafka-cluster-setup)
+ [
## Configurare la sicurezza della rete
](#services-kafka-vpc-config)
## Un cluster Apache Kafka autogestito.
Puoi ospitare il tuo cluster Apache Kafka autogestito con provider di servizi cloud come [Confluent Cloud](https://www.confluent.io/confluent-cloud/) o [Redpanda](https://www.redpanda.com/) oppure eseguirlo sulla tua infrastruttura. Assicurati che il cluster sia configurato correttamente e accessibile dalla rete a cui si connetterà la mappatura delle sorgenti degli eventi Lambda.
## Configurare la sicurezza della rete
Per concedere a Lambda l'accesso completo ad Apache Kafka autogestito tramite lo strumento di mappatura dell'origine degli eventi, il cluster deve utilizzare un endpoint pubblico (indirizzo IP pubblico) oppure devi fornire l'accesso all'Amazon VPC in cui hai creato il cluster.
Quando usi Apache Kafka autogestito con Lambda, crea [endpoint VPC AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) che forniscono alla funzione l'accesso alle risorse del tuo Amazon VPC.
**Nota**
Gli endpoint VPC AWS PrivateLink sono necessari per le funzioni con lo strumento di mappatura dell'origine degli eventi delle origini degli eventi che utilizzano la modalità predefinita (on demand) per i poller degli eventi. Se lo strumento di mappatura dell'origine degli eventi utilizza la [modalità provisioning](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode), non è necessario configurare gli endpoint VPC AWS PrivateLink.
Crea un endpoint per fornire l'accesso alle seguenti risorse:
+ Lambda: crea un endpoint per il principale del servizio Lambda.
+ AWS STS: crea un endpoint per AWS STS in modo che un principale del servizio possa assumere un ruolo per conto tuo.
+ Secrets Manager: se il tuo cluster utilizza Secrets Manager per archiviare le credenziali, crea un endpoint per Secrets Manager.
In alternativa, configura un gateway NAT su ogni sottorete pubblica in Amazon VPC. Per ulteriori informazioni, consulta [Abilitare l'accesso a Internet per funzioni Lambda connesse a un VPC](configuration-vpc-internet.md).
Quando crei uno strumento di mappatura dell'origine degli eventi per Apache Kafka autogestito, Lambda verifica se le interfacce di rete elastiche (ENI) sono già presenti per le sottoreti e i gruppi di sicurezza configurati per il tuo Amazon VPC. Se Lambda trova ENI esistenti, prova a riutilizzarle. Altrimenti, Lambda crea nuove ENI per connettersi all'origine dell'evento e richiamare la tua funzione.
**Nota**
Le funzioni Lambda vengono sempre eseguite all'interno di VPC di proprietà del servizio Lambda. La configurazione VPC della funzione non influisce sullo strumento di mappatura dell'origine degli eventi. Solo la configurazione di rete dell'origine dell'evento determina il modo in cui Lambda si connette all'origine dell'evento.
Configura i gruppi di sicurezza per l'Amazon VPC contenente il tuo cluster. Per impostazione predefinita, Apache Kafka autogestito utilizza le seguenti porte: `9092`.
+ Regole in ingresso: consenti tutto il traffico sulla porta del broker predefinita per il gruppo di sicurezza associato all'origine eventi. In alternativa, puoi utilizzare una regola del gruppo di sicurezza autoreferenziante per consentire l'accesso da istanze all'interno dello stesso gruppo di sicurezza.
+ Regole in uscita: consenti tutto il traffico sulla porta `443` per destinazioni esterne se la funzione deve comunicare con AWS i servizi. In alternativa, puoi anche utilizzare una regola del gruppo di sicurezza autoreferenziale per limitare l'accesso al broker se non hai bisogno di comunicare con altri servizi. AWS
+ Regole di ingresso degli endpoint Amazon VPC: se utilizzi un endpoint Amazon VPC, il gruppo di sicurezza associato all'endpoint Amazon VPC deve consentire il traffico in entrata sulla porta `443` dal gruppo di sicurezza del cluster.
Se il cluster utilizza l'autenticazione, puoi anche limitare la policy degli endpoint per l'endpoint Secrets Manager. Per chiamare l'API Secrets Manager, Lambda utilizza il ruolo della funzione, non il principale del servizio Lambda.
**Example Policy dell'endpoint VPC: endpoint Secrets Manager**
```
{
"Statement": [
{
"Action": "secretsmanager:GetSecretValue",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws::iam::123456789012:role/my-role"
]
},
"Resource": "arn:aws::secretsmanager:us-west-2:123456789012:secret:my-secret"
}
]
}
```
Quando utilizzi gli endpoint Amazon VPC, AWS indirizza le chiamate API per invocare la funzione utilizzando l'interfaccia di rete elastica (ENI) dell'endpoint. Il principale del servizio Lambda deve chiamare `lambda:InvokeFunction` su tutti i ruoli e le funzioni che utilizzano tali ENI.
Per impostazione predefinita, gli endpoint Amazon VPC dispongono di policy IAM aperte che consentono un ampio accesso alle risorse. La best practice consiste nel limitare queste policy per eseguire le azioni necessarie utilizzando quell'endpoint. Per garantire che lo strumento di mappatura dell'origine degli eventi sia in grado di invocare la funzione Lambda, la policy degli endpoint VPC deve consentire al principale del servizio Lambda di chiamare `sts:AssumeRole` e `lambda:InvokeFunction`. Limitare le policy degli endpoint VPC per consentire solo le chiamate API provenienti dall'organizzazione impedisce il corretto funzionamento dello strumento di mappatura dell'origine degli eventi, pertanto `"Resource": "*"` è richiesto in queste policy.
Il seguente esempio di policy degli endpoint VPC mostra come concedere l'accesso richiesto al principale del servizio Lambda per gli endpoint AWS STS e Lambda.
**Example Policy dell'endpoint VPC: endpoint AWS STS**
```
{
"Statement": [
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
**Example Policy dell'endpoint VPC: endpoint Lambda**
```
{
"Statement": [
{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
# Configurazione delle autorizzazioni del ruolo di esecuzione Lambda
Oltre ad [accedere al cluster Kafka autogestito](kafka-cluster-auth.md), la funzione Lambda necessita delle autorizzazioni per eseguire varie azioni API. Aggiungere queste autorizzazioni al [ruolo di esecuzione](lambda-intro-execution-role.md) della funzione. Se i tuoi utenti devono accedere a qualsiasi azione API, aggiungi le autorizzazioni richieste alla politica di identità per l'utente o il ruolo AWS Identity and Access Management (IAM).
**Topics**
+ [
## Autorizzazioni necessarie per la funzione Lambda
](#smaa-api-actions-required)
+ [
## Autorizzazioni facoltative per la funzione Lambda
](#smaa-api-actions-optional)
+ [
## Aggiunta di autorizzazioni al ruolo di esecuzione
](#smaa-permissions-add-policy)
+ [
## Concessione di accesso agli utenti con una policy IAM
](#smaa-permissions-add-users)
## Autorizzazioni necessarie per la funzione Lambda
Per creare e archiviare i log in un gruppo di log in Amazon CloudWatch Logs, la funzione Lambda deve disporre delle seguenti autorizzazioni nel ruolo di esecuzione:
+ [registri: CreateLogGroup](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogGroup.html)
+ [registri: CreateLogStream](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogStream.html)
+ [registri: PutLogEvents](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html)
## Autorizzazioni facoltative per la funzione Lambda
La funzione Lambda potrebbe richiedere autorizzazioni per:
+ Descrivere il segreto di Secrets Manager.
+ Accedi alla tua chiave AWS Key Management Service (AWS KMS) gestita dal cliente.
+ Accedere ad Amazon VPC.
+ Invia i record delle chiamate non riuscite a una destinazione.
### Secrets Manager e AWS KMS autorizzazioni
A seconda del tipo di controllo degli accessi che stai configurando per i tuoi broker Kafka, la tua funzione Lambda potrebbe richiedere l'autorizzazione per accedere al tuo segreto di Secrets Manager o per decrittografare la tua chiave gestita dal cliente. AWS KMS Per accedere a queste risorse, il ruolo di esecuzione della funzione deve disporre delle seguenti autorizzazioni:
+ [gestore dei segreti: GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html)
+ [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html)
### Autorizzazioni VPC
Se soltanto gli utenti all'interno di un VPC possono accedere al cluster Apache Kafka autogestito, la funzione Lambda deve disporre dell'autorizzazione per accedere alle risorse di Amazon VPC. Queste risorse includono la VPC, le sottoreti, i gruppi di sicurezza e le interfacce di rete. Per accedere a queste risorse, il ruolo di esecuzione della funzione deve disporre delle seguenti autorizzazioni:
+ [ec2: CreateNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateNetworkInterface.html)
+ [ec2: DescribeNetworkInterfaces](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeNetworkInterfaces.html)
+ [ec2: DescribeVpcs](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpcs.html)
+ [ec2: DeleteNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteNetworkInterface.html)
+ [ec2: DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html)
+ [ec2: DescribeSecurityGroups](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSecurityGroups.html)
## Aggiunta di autorizzazioni al ruolo di esecuzione
[Per accedere ad altri AWS servizi utilizzati dal cluster Apache Kafka autogestito, Lambda utilizza le politiche di autorizzazione definite nel ruolo di esecuzione della funzione Lambda.](lambda-intro-execution-role.md)
Per impostazione predefinita, Lambda non è autorizzato a eseguire le operazioni richieste o facoltative per un cluster Apache Kafka autogestito. Dovrai creare e definire queste operazioni in una [policy di attendibilità IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-trust-policy.html) per il ruolo di esecuzione. Questo esempio mostra come creare una policy che consente a Lambda di accedere alle risorse Amazon VPC.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ec2:CreateNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeVpcs",
"ec2:DeleteNetworkInterface",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups"
],
"Resource":"*"
}
]
}
```
------
## Concessione di accesso agli utenti con una policy IAM
Per impostazione predefinita, gli utenti e i ruoli non dispongono dell'autorizzazione per eseguire [operazioni API di origine eventi](invocation-eventsourcemapping.md#event-source-mapping-api). Per concedere l'accesso agli utenti dell'organizzazione o dell'account, è possibile creare o aggiornare una policy basata sull'identità. *Per ulteriori informazioni, consulta [Controlling access to AWS resources using](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html) policies nella IAM User Guide.*
Per la risoluzione degli errori di autenticazione e autorizzazione, consulta[Risoluzione degli errori di mappatura delle sorgenti degli eventi Kafka](with-kafka-troubleshoot.md).
# Configurazione di origini eventi Apache Kafka autogestito per Lambda
Per utilizzare un cluster Apache Kafka autogestito come origine di eventi per la funzione Lambda, è necessario creare una [mappatura delle sorgenti degli eventi](invocation-eventsourcemapping.md) che collega le due risorse. Questa pagina descrive come creare una mappatura delle sorgenti degli eventi per Apache Kafka autogestito.
Questa pagina presuppone che tu abbia già configurato correttamente il tuo cluster Kafka e la rete in cui risiede. Se devi configurare il tuo cluster o la tua rete, vedi. [Configurazione del cluster e della rete Apache Kafka autogestiti per Lambda](with-kafka-cluster-network.md)
**Topics**
+ [
## Utilizzo di un cluster Apache Kafka autogestito come fonte di eventi
](#kafka-esm-overview)
+ [
# Configurazione dei metodi di autenticazione del cluster in Lambda
](kafka-cluster-auth.md)
+ [
# Creazione di una mappatura della sorgente di eventi Lambda per un'origine di eventi Apache Kafka autogestita
](kafka-esm-create.md)
+ [
# Tutti i parametri di configurazione dell'origine degli eventi Apache Kafka autogestiti in Lambda
](kafka-esm-parameters.md)
## Utilizzo di un cluster Apache Kafka autogestito come fonte di eventi
Quando aggiungi il cluster Apache Kafka o Amazon MSK come trigger per la funzione Lambda, il cluster viene utilizzato come [origine eventi](invocation-eventsourcemapping.md).
Lambda legge i dati degli eventi dagli argomenti di Kafka specificati `Topics` in una [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)richiesta, in base alla posizione [iniziale](kafka-starting-positions.md) specificata. Dopo che l'elaborazione è avvenuta con successo, l'argomento Kafka viene salvato nel cluster Kafka.
Lambda legge i messaggi in sequenza per ogni partizione dell'argomento Kafka. Un singolo payload Lambda può contenere messaggi provenienti da più partizioni. Quando sono disponibili più record, Lambda continua a elaborare i record in batch, in base al BatchSize valore specificato in una [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)richiesta, finché la funzione non raggiunge l'argomento.
Dopo che Lambda ha elaborato ogni batch, esegue il commit degli offset dei messaggi in quel batch. Se la funzione restituisce un errore per uno qualsiasi dei messaggi di un batch, Lambda ritenta l'intero batch di messaggi fino a quando l'elaborazione non riesce o i messaggi scadono. È possibile inviare i record per i quali tutti i nuovi tentativi falliscono a una destinazione in errore per un'elaborazione successiva.
**Nota**
Anche se le funzioni Lambda generalmente prevedono un timeout massimo di 15 minuti, gli strumenti di mappatura dell'origine degli eventi per Amazon MSK, Apache Kafka autogestito, Amazon DocumentDB e Amazon MQ per ActiveMQ e RabbitMQ supportano solo funzioni con timeout massimi di 14 minuti.
# Configurazione dei metodi di autenticazione del cluster in Lambda
Lambda supporta diversi metodi per l'autenticazione al cluster Apache Kafka autogestito. Assicurarsi di configurare il cluster Kafka in modo da utilizzare uno dei seguenti metodi di autenticazione supportati. Per ulteriori informazioni sulla sicurezza con Kafka, consultare la sezione [Sicurezza](http://kafka.apache.org/documentation.html#security) della documentazione di Kafka.
## Autenticazione SASL/SCRAM
Lambda supporta l'autenticazione SASL/SCRAM (Simple Authentication and Security Layer/Salted Challenge Response Authentication Mechanism) con crittografia Transport Layer Security (TLS) (). `SASL_SSL` Lambda invia le credenziali crittografate per l'autenticazione con il cluster. Lambda non supporta il testo in SASL/SCRAM chiaro (). `SASL_PLAINTEXT` [Per ulteriori informazioni sull' SASL/SCRAM autenticazione, consulta RFC 5802.](https://tools.ietf.org/html/rfc5802)
Lambda supporta SASL/PLAIN anche l'autenticazione. Poiché questo meccanismo utilizza credenziali in chiaro, la connessione al server deve utilizzare la crittografia TLS per garantire che le credenziali siano protette.
Per l'autenticazione SASL, è necessario archiviare le credenziali di accesso come segreto in Gestione dei segreti AWS. Per ulteriori informazioni sull'utilizzo di Secrets Manager, consulta [Create an Gestione dei segreti AWS secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) nella *Guida Gestione dei segreti AWS per l'utente*.
**Importante**
Per utilizzare Secrets Manager per l'autenticazione, i segreti devono essere archiviati nella stessa AWS area della funzione Lambda.
## Autenticazione TLS reciproca
MTLS (Mutual TLS) fornisce l'autenticazione bidirezionale tra client e server. Il client invia un certificato al server affinché il server verifichi il client e il server invia un certificato al client affinché il client verifichi il server.
In Apache Kafka autogestito Lambda agisce come client. È possibile configurare un certificato client (come segreto in Secrets Manager) per autenticare Lambda con i broker Kafka. Il certificato client deve essere firmato da una CA nell'archivio trust del server.
Il cluster Kafka invia un certificato server a Lambda per autenticare i broker con Lambda. Il certificato del server può essere un certificato CA pubblico o un certificato con CA/self-signed certificate. The public CA certificate must be signed by a certificate authority (CA) that's in the Lambda trust store. For a private CA/self firma privata, è possibile configurare il certificato CA root del server (come segreto in Secrets Manager). Lambda utilizza il certificato root per verificare i broker Kafka.
Per ulteriori informazioni su mTLS, consultare [ Introduzione dell'autenticazione TLS reciproca per Amazon MSK come origine eventi](https://aws.amazon.com/blogs/compute/introducing-mutual-tls-authentication-for-amazon-msk-as-an-event-source).
## Configurazione del segreto del certificato client
Il segreto CLIENT\$1CERTIFICATE\$1TLS\$1AUTH richiede un campo certificato e un campo chiave privata. Per una chiave privata crittografata, il segreto richiede una password per chiave privata. Il certificato e la chiave privata devono essere in formato PEM.
**Nota**
Lambda supporta gli algoritmi di crittografia a chiave privata [PBES1](https://datatracker.ietf.org/doc/html/rfc2898/#section-6.1)(ma non PBES2).
Il campo certificato deve contenere un elenco di certificati, a partire dal certificato client, seguito da qualsiasi certificato intermedio, per finire con il certificato root. Ogni certificato deve iniziare su una nuova riga con la struttura seguente:
```
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
```
Secrets Manager supporta segreti fino a 65.536 byte, che è uno spazio sufficiente per lunghe catene di certificati.
La chiave privata deve essere in formato [PKCS \$18](https://datatracker.ietf.org/doc/html/rfc5208), con la struttura seguente:
```
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
```
Per una chiave privata crittografata, utilizza la struttura seguente:
```
-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----
```
Nell'esempio seguente viene mostrato il contenuto di un segreto per l'autenticazione mTLS utilizzando una chiave privata crittografata. Per una chiave privata crittografata, includere la password per chiave privata nel segreto.
```
{"privateKeyPassword":"testpassword",
"certificate":"-----BEGIN CERTIFICATE-----
MIIE5DCCAsygAwIBAgIRAPJdwaFaNRrytHBto0j5BA0wDQYJKoZIhvcNAQELBQAw
...
j0Lh4/+1HfgyE2KlmII36dg4IMzNjAFEBZiCRoPimO40s1cRqtFHXoal0QQbIlxk
cmUuiAii9R0=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFgjCCA2qgAwIBAgIQdjNZd6uFf9hbNC5RdfmHrzANBgkqhkiG9w0BAQsFADBb
...
rQoiowbbk5wXCheYSANQIfTZ6weQTgiCHCCbuuMKNVS95FkXm0vqVD/YpXKwA/no
c8PH3PSoAaRwMMgOSA2ALJvbRz8mpg==
-----END CERTIFICATE-----",
"privateKey":"-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIFKzBVBgkqhkiG9w0BBQ0wSDAnBgkqhkiG9w0BBQwwGgQUiAFcK5hT/X7Kjmgp
...
QrSekqF+kWzmB6nAfSzgO9IaoAaytLvNgGTckWeUkWn/V0Ck+LdGUXzAC4RxZnoQ
zp2mwJn2NYB7AZ7+imp0azDZb+8YG2aUCiyqb6PnnA==
-----END ENCRYPTED PRIVATE KEY-----"
}
```
## Configurazione del segreto del certificato CA root del server
Questo segreto viene creato se i broker Kafka utilizzano la crittografia TLS con certificati firmati da una CA privata. Puoi utilizzare la crittografia TLS per l'autenticazione VPC SASL/SCRAM, SASL/PLAIN o MTLS.
Il segreto del certificato CA root del server richiede un campo che contiene il certificato CA root del broker Kafka in formato PEM. Il seguente esempio illustra la struttura del segreto.
```
{"certificate":"-----BEGIN CERTIFICATE-----
MIID7zCCAtegAwIBAgIBADANBgkqhkiG9w0BAQsFADCBmDELMAkGA1UEBhMCVVMx
EDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxJTAjBgNVBAoT
HFN0YXJmaWVsZCBUZWNobm9sb2dpZXMsIEluYy4xOzA5BgNVBAMTMlN0YXJmaWVs
ZCBTZXJ2aWNlcyBSb290IENlcnRpZmljYXRlIEF1dG...
-----END CERTIFICATE-----"
}
```
# Creazione di una mappatura della sorgente di eventi Lambda per un'origine di eventi Apache Kafka autogestita
[Per creare una mappatura delle sorgenti degli eventi, puoi utilizzare la console Lambda, la [AWS Command Line Interface (CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)) o un SDK.AWS](https://aws.amazon.com/getting-started/tools-sdks/)
I seguenti passaggi della console aggiungono un cluster Apache Kafka autogestito come trigger per la funzione Lambda. Sotto il cofano, questo crea una risorsa di mappatura delle sorgenti degli eventi.
## Prerequisiti
+ Un cluster Apache Kafka autogestito. Lambda supporta la versione 0.10.1.0 e successive di Apache Kafka.
+ Un [ruolo di esecuzione](lambda-intro-execution-role.md) con autorizzazione ad accedere alle AWS risorse utilizzate dal cluster Kafka autogestito.
## Aggiunta di un cluster Kafka autogestito (console)
Segui questi passaggi per aggiungere il cluster Apache Kafka autogestito e un argomento Kafka come trigger per la funzione Lambda.
**Per aggiungere un trigger Apache Kafka alla funzione Lambda (console)**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegliere il nome della funzione Lambda.
1. In **Panoramica delle funzioni**, scegliere **Aggiungi trigger**.
1. In **Configurazione trigger**, effettua le operazioni seguenti:
1. Scegliere il tipo di trigger **Apache Kafka**.
1. Per **Server di bootstrap**, inserisci l'indirizzo composto dalla coppia host e porta di un broker Kafka nel cluster, quindi scegli **Aggiungi**. Ripeti la procedura per ogni broker Kafka del cluster.
1. Per **Nome argomento**, inserisci il nome dell'argomento Kafka utilizzato per memorizzare i record nel cluster.
1. Se configuri la modalità provisioned, inserisci un valore per **Minimum event poller**, un valore per **Maximum event poller** e un valore opzionale per PollerGroupName specificare il raggruppamento di più eventi ESMs all'interno dello stesso VPC di origine eventi.
1. (Facoltativo) In **Dimensioni batch**, inserisci il numero massimo di record da ricevere in un singolo batch.
1. Per **Finestra batch**, immetti il tempo massimo in secondi per la raccolta dei registri da parte di Lambda prima di richiamare la funzione.
1. (Facoltativo) Per **ID gruppo di consumer**, inserisci l'ID di un gruppo di consumer Kafka a cui aderire.
1. (Facoltativo) Per **Posizione di inizio**, scegli **Più recente** per iniziare a leggere il flusso dal record più recente, **Orizzonte di taglio** per iniziare dal primo record disponibile o **In corrispondenza del timestamp** per specificare un timestamp da cui iniziare la lettura.
1. (Facoltativo) Per **VPC**, scegli Amazon VPC per il cluster Kafka. Quindi, scegli **Sottoreti VPC** e **Gruppi di sicurezza VPC**.
Questa impostazione è necessaria soltanto se gli utenti del VPC accedono ai broker.
1. (Facoltativo) Per **Autenticazione**, scegli **Aggiungi** e quindi esegui le seguenti operazioni:
1. Scegli il protocollo di accesso o di autenticazione dei broker Kafka del cluster.
+ **Se il tuo broker Kafka utilizza l'autenticazione, scegli BASIC\$1AUTH. SASL/PLAIN **
+ Se il tuo broker utilizza SASL/SCRAM l'autenticazione, scegli uno dei protocolli. **SASL\$1SCRAM**
+ Se stai configurando l'autenticazione mTLS, scegli il protocollo **CLIENT\$1CERTIFICATE\$1TLS\$1AUTH**.
1. Per SASL/SCRAM l'autenticazione MTLS, scegli la chiave segreta Secrets Manager che contiene le credenziali per il tuo cluster Kafka.
1. (Facoltativo) Per **Crittografia**, scegli il segreto di Secrets Manager contenente il certificato CA root utilizzato dai broker Kafka per la crittografia TLS, se i broker Kafka utilizzano certificati firmati da una CA privata.
Questa impostazione si applica alla crittografia TLS per SASL/PLAIN e all' SASL/SCRAM autenticazione MTLS.
1. Per creare il trigger in uno stato disabilitato per il test (scelta consigliata), deselezionare **Abilita trigger**. Oppure, per attivare immediatamente il trigger, selezionare**Abilita trigger**.
1. Per creare il trigger, scegli **Aggiungi**.
## Aggiunta di un cluster Kafka autogestito (AWS CLI)
Usa i seguenti AWS CLI comandi di esempio per creare e visualizzare un trigger Apache Kafka autogestito per la tua funzione Lambda.
### Utilizzo di SASL/SCRAM
Se gli utenti Kafka accedono ai tuoi broker Kafka tramite Internet, specifica il segreto Secrets Manager che hai creato per l'autenticazione. SASL/SCRAM L'esempio seguente utilizza il [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html) AWS CLI comando per mappare una funzione Lambda denominata `my-kafka-function` a un argomento di Kafka denominato. `AWSKafkaTopic`
```
aws lambda create-event-source-mapping \
--topics AWSKafkaTopic \
--source-access-configuration Type=SASL_SCRAM_512_AUTH,URI=arn:aws:secretsmanager:us-east-1:111122223333:secret:MyBrokerSecretName \
--function-name arn:aws:lambda:us-east-1:111122223333:function:my-kafka-function \
--self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc3.xyz.com:9092", "abc2.xyz.com:9092"]}}'
```
### Utilizzo di un VPC
Se solo gli utenti Kafka all'interno del proprio VPC accedono ai broker Kafka, dovrai specificare VPC, sottorete e gruppo di sicurezza del VPC. L'esempio seguente utilizza il [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html) AWS CLI comando per mappare una funzione Lambda denominata `my-kafka-function` a un argomento di Kafka denominato. `AWSKafkaTopic`
```
aws lambda create-event-source-mapping \
--topics AWSKafkaTopic \
--source-access-configuration '[{"Type": "VPC_SUBNET", "URI": "subnet:subnet-0011001100"}, {"Type": "VPC_SUBNET", "URI": "subnet:subnet-0022002200"}, {"Type": "VPC_SECURITY_GROUP", "URI": "security_group:sg-0123456789"}]' \
--function-name arn:aws:lambda:us-east-1:111122223333:function:my-kafka-function \
--self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc3.xyz.com:9092", "abc2.xyz.com:9092"]}}'
```
### Visualizzazione dello stato utilizzando il AWS CLI
L'esempio seguente utilizza il [get-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/get-event-source-mapping.html) AWS CLI comando per descrivere lo stato della mappatura dell'origine degli eventi creata.
```
aws lambda get-event-source-mapping
--uuid dh38738e-992b-343a-1077-3478934hjkfd7
```
# Tutti i parametri di configurazione dell'origine degli eventi Apache Kafka autogestiti in Lambda
Tutti i tipi di sorgenti di eventi Lambda condividono le stesse operazioni [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)e quelle dell'[UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)API. Tuttavia, solo alcuni parametri si applicano ad Apache Kafka autogestito, come illustrato nella tabella seguente.
| Parametro | Obbligatorio | Predefinito | Note |
| --- | --- | --- | --- |
| BatchSize | N | 100 | Massimo: 10.000. |
| DestinationConfig | N | N/D | [Acquisizione di batch scartati per un'origine eventi di Amazon MSK e Apache Kafka autogestito](kafka-on-failure.md) |
| Abilitato | N | True | |
| FilterCriteria | N | N/D | [Controllare gli eventi che Lambda invia alla funzione](invocation-eventfiltering.md) |
| FunctionName | Y | N/D | |
| KMSKeyArn | N | N/D | [Crittografia dei criteri di filtro](invocation-eventfiltering.md#filter-criteria-encryption) |
| MaximumBatchingWindowInSeconds | N | 500 ms | [Comportamento di batching](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching) |
| ProvisionedPollersConfig | N | `MinimumPollers`: se non specificato, il valore predefinito è 1 `MaximumPollers`: se non specificato, il valore predefinito è 200 `PollerGroupName`: N/A | [Modalità provisioning](kafka-scaling-modes.md#kafka-provisioned-mode) |
| SelfManagedEventSource | Y | N/D | Elenco dei broker Kafka. Può essere impostato solo su Create |
| SelfManagedKafkaEventSourceConfig | N | Contiene il ConsumerGroupId campo che per impostazione predefinita è un valore univoco. | Può essere impostato solo su Create |
| SourceAccessConfigurations | N | Nessuna credenziale | Informazioni sul VPC o credenziali di autenticazione per il cluster Per SASL\$1PLAIN, imposta su BASIC\$1AUTH |
| StartingPosition | Y | N/D | AT\$1TIMESTAMP, TRIM\$1HORIZON o LATEST Può essere impostato solo su Create |
| StartingPositionTimestamp | N | N/D | Obbligatorio se StartingPosition è impostato su AT\$1TIMESTAMP |
| Tag | N | N/D | [Utilizzo di tag negli strumenti di mappatura dell'origine degli eventi](tags-esm.md) |
| Argomenti | Y | N/D | Nome dell'argomento Può essere impostato solo su Create |
**Nota**
Quando si specifica una`PollerGroupName`, più unità ESMs all'interno dello stesso Amazon VPC possono condividere la capacità dell'Event Poller Unit (EPU). Puoi utilizzare questa opzione per ottimizzare i costi della modalità Provisioned per i tuoi. ESMs Requisiti per il raggruppamento ESM:
ESMs deve trovarsi all'interno dello stesso Amazon VPC
Massimo 100 ESMs per gruppo di sondaggi
Il numero massimo aggregato di sondaggi di tutti ESMs i membri di un gruppo non può superare i 2000
È possibile aggiornare il file `PollerGroupName` per spostare un ESM in un gruppo diverso oppure rimuovere un ESM da un gruppo `PollerGroupName` impostandolo su una stringa vuota («»).
# Modalità di ridimensionamento del poller di eventi di Apache Kafka in Lambda
Puoi scegliere tra due modalità di ridimensionamento dei poller degli eventi per Amazon MSK e mappature delle sorgenti di eventi Apache Kafka autogestite:
+ [Modalità on-demand (impostazione predefinita)](#kafka-default-mode)
+ [Modalità provisioning](#kafka-provisioned-mode)
## Modalità on-demand (impostazione predefinita)
Quando crei inizialmente l'origine degli eventi Kafka, Lambda assegna un numero predefinito di poller di eventi per elaborare tutte le partizioni nell'argomento Kafka. Lambda aumenta o riduce automaticamente il numero di [sondaggi di eventi in base al caricamento dei messaggi](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode).
In un intervallo di un minuto, Lambda valuta il ritardo dell'offset di tutte le partizioni dell'argomento. Se il ritardo dell'offset è troppo alto, lo shard sta ricevendo messaggi più velocemente di quanto Lambda possa elaborarli. Se necessario, Lambda aggiunge o rimuove i poller di eventi dall'argomento. Questo processo di dimensionamento automatico di aggiunta o rimozione dei poller degli eventi avviene entro tre minuti dalla valutazione.
Se la funzione Lambda di destinazione è limitata, Lambda riduce il numero di poller di eventi. Questa operazione riduce il carico di lavoro sulla funzione riducendo il numero di messaggi che i poller di eventi possono recuperare e inviare alla funzione.
## Modalità provisioning
Per i carichi di lavoro in cui è necessario ottimizzare il throughput dello strumento di mappatura dell'origine degli eventi, è possibile utilizzare la modalità provisioning. In modalità provisioning, vengono definiti i limiti minimi e massimi per la quantità di poller di eventi assegnati. Questi poller di eventi con provisioning sono dedicati allo strumento di mappatura dell'origine degli eventi e possono gestire picchi di messaggi imprevisti tramite un dimensionamento automatico reattivo. Ti consigliamo di utilizzare la modalità provisioning per i carichi di lavoro Kafka che hanno requisiti di prestazioni rigorosi.
In Lambda, un event poller è un'unità di calcolo con funzionalità di throughput che variano in base al tipo di origine dell'evento. Per Amazon MSK e Apache Kafka autogestito, ogni event poller può gestire fino al 5% MB/sec del throughput o fino a 5 chiamate simultanee. Ad esempio, se la fonte dell'evento produce un payload medio di 1 MB e la durata media della funzione è di 1 secondo, un singolo event poller di eventi Kafka può supportare 5 MB/sec velocità effettiva e 5 chiamate Lambda simultanee (presupponendo che non vi sia alcuna trasformazione del payload). Per Amazon SQS, ogni event poller può gestire fino all'1% MB/sec del throughput o fino a 10 chiamate simultanee. L'utilizzo della modalità provisioned comporta costi aggiuntivi in base all'utilizzo dell'event poller. Per i dettagli sui prezzi, vedere [Prezzi di AWS Lambda](https://aws.amazon.com/lambda/pricing/).
**Nota**
Quando si utilizza la modalità provisioned, non è necessario creare endpoint AWS PrivateLink VPC o concedere le autorizzazioni associate come parte della configurazione di rete.
In modalità provisioning, l'intervallo di valori accettati per il numero minimo di poller di event (`MinimumPollers`) è compreso tra 1 e 200, inclusi. L'intervallo di valori accettati per il numero massimo di poller di eventi (`MaximumPollers`) è compreso tra 1 e 2.000, inclusi. `MaximumPollers` deve essere maggiore o uguale a `MinimumPollers`. Inoltre, per mantenere l'elaborazione ordinata all'interno delle partizioni, Lambda limita a `MaximumPollers` il numero di partizioni indicato nell'argomento.
Per ulteriori informazioni sulla scelta dei valori minimi e massimi appropriati di poller di eventi, consulta [Best practice](#kafka-provisioned-mode-bp).
Puoi configurare la modalità di provisioning per la mappatura delle sorgenti degli eventi Kafka utilizzando la console o l'API Lambda.
**Per configurare la modalità provisioning per una mappatura delle sorgenti di eventi esistente (console)**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegliete la funzione con la mappatura delle sorgenti degli eventi per cui desiderate configurare la modalità di provisioning.
1. Scegli la scheda **Configurazione**, quindi scegli **Trigger**.
1. **Scegli la mappatura delle sorgenti degli eventi per cui desideri configurare la modalità di provisioning, quindi scegli Modifica.**
1. **In **modalità Provisioned**, seleziona Configura.**
+ Per **Numero minimo di poller di eventi**, inserisci un valore compreso tra 1 e 200. Se non si specifica un valore, Lambda assegna il valore predefinito 1.
+ Per **Numero massimo di poller di eventi**, inserisci un valore compreso tra 1 e 2.000. Questo valore deve essere maggiore o uguale al valore specificato in **Numero minimo di poller di eventi**. Se non si specifica un valore, Lambda assegna il valore predefinito 200.
1. Scegli **Save** (Salva).
È possibile configurare la modalità di provisioning a livello di codice utilizzando l'[ProvisionedPollerConfig](https://docs.aws.amazon.com/lambda/latest/api/API_ProvisionedPollerConfig.html)oggetto presente in. [ EventSourceMappingConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_EventSourceMappingConfiguration.html) Ad esempio, il seguente comando [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)CLI configura un `MinimumPollers` valore di 5 e un `MaximumPollers` valore di 100.
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--provisioned-poller-config '{"MinimumPollers": 5, "MaximumPollers": 100}'
```
Dopo aver configurato la modalità provisioning, puoi osservare l'utilizzo dei poller di eventi per il tuo carico di lavoro monitorando il parametro `ProvisionedPollers`. Per ulteriori informazioni, consulta [Parametri dello strumento di mappatura dell'origine degli eventi](monitoring-metrics-types.md#event-source-mapping-metrics).
Per disabilitare la modalità provisioning e tornare alla modalità predefinita (su richiesta), puoi utilizzare il seguente comando CLI [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html):
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--provisioned-poller-config '{}'
```
## Funzionalità avanzate di gestione degli errori e prestazioni
Per le mappature delle sorgenti di eventi Kafka con la modalità provisioning abilitata, puoi configurare funzionalità aggiuntive per migliorare la gestione e le prestazioni degli errori:
+ [Configurazioni di](kafka-retry-configurations.md) nuovi tentativi: controlla il modo in cui Lambda gestisce i record non riusciti con il numero massimo di tentativi di ripetizione, limiti di età dei record, suddivisione in batch e risposte batch parziali.
+ [Destinazioni Kafka in caso di errore: invia i](kafka-on-failure-destination.md) record non riusciti a un argomento di Kafka per elaborarli o analizzarli in un secondo momento.
## Best practice e considerazioni sull'utilizzo della modalità provisioning
La configurazione ottimale dei poller di eventi minimi e massimi per lo strumento di mappatura dell'origine degli eventi dipende dai requisiti delle prestazioni dell'applicazione. Ti consigliamo di iniziare con i poller di eventi minimi di default per definire il profilo delle prestazioni. Modifica la configurazione in base ai modelli di elaborazione dei messaggi osservati e al profilo delle prestazioni desiderato.
Per carichi di lavoro con picchi di traffico e requisiti delle prestazioni rigorosi, aumenta il numero minimo di poller di eventi per gestire picchi improvvisi di messaggi. Per determinare i poller di eventi minimi richiesti, considerate i messaggi al secondo del carico di lavoro e la dimensione media del payload e utilizzate la capacità di throughput di un singolo event poller (fino a 5) come riferimento. MBps
Per mantenere l'elaborazione ordinata all'interno di uno shard, Lambda limita il numero massimo di poller di eventi al numero di shard nell'argomento. Inoltre, il numero massimo di poller di eventi a cui lo strumento di mappatura dell'origine degli eventi può scalare dipende dalle impostazioni di simultaneità della funzione.
Quando attivi la modalità provisioned, aggiorna le impostazioni di rete per rimuovere gli endpoint AWS PrivateLink VPC e le autorizzazioni associate.
## Ottimizzazione dei costi per la modalità Provisioned
### Prezzi in modalità provisioned
La modalità Provisioned viene addebitata in base ai poller di eventi minimi forniti e ai poller di eventi utilizzati durante la scalabilità automatica. Gli addebiti vengono calcolati utilizzando un'unità di fatturazione denominata Event Poller Unit (EPU). Si paga in base al numero e alla durata dell' EPUs utilizzo, misurati in. Event-Poller-Unit-hours È possibile utilizzare la modalità Provisioned con un singolo ESM per applicazioni sensibili alle prestazioni oppure è possibile raggrupparne più di uno all'interno dello stesso VPC per condividere ESMs la capacità e i costi dell'EPU. Approfondiremo due funzionalità che ti aiutano a ottimizzare i costi della modalità Provisioned. Per i dettagli sui prezzi, consulta i prezzi di [AWS Lambda](https://aws.amazon.com/lambda/pricing/).
### Utilizzo migliorato dell'EPU
Ogni EPU supporta fino a 20 capacità di MB/s throughput per il polling degli eventi e supporta un valore predefinito di 10 poller di eventi. Quando si crea una modalità Provisioned per Kafka ESM impostando un numero minimo e massimo di poller, viene utilizzato il numero minimo di poller per il provisioning EPUs in base all'impostazione predefinita di 10 poller di eventi per EPU. Tuttavia, ogni event poller può scalare in modo indipendente fino a supportare fino al 5% MB/s della capacità di throughput, il che potrebbe richiedere una minore densità di event poller su una specifica EPU e innescare la scalabilità di. EPUs Il numero di event poller allocati su un'EPU dipende dalla capacità di calcolo consumata da ciascun event poller. Questo approccio di utilizzo migliorato dell'EPU consente ai poller di eventi con requisiti di throughput diversi di utilizzare la capacità dell'EPU in modo efficace, riducendo i costi per tutti. ESMs
### Raggruppamento ESM
Per ottimizzare ulteriormente i costi della modalità Provisioned, è possibile raggruppare più sistemi Kafka ESMs per condividere la capacità EPU. Con il raggruppamento ESM e l'utilizzo avanzato dell'EPU, è possibile ridurre i costi della modalità Provisioned fino al 90% per carichi di lavoro a basso throughput rispetto all'esecuzione in modalità ESM singola. Tutto ciò ESMs che richiede meno di 1 capacità EPU trarrà vantaggio dal raggruppamento ESM. Ciò richiede ESMs in genere un numero minimo di event poller per supportare le proprie esigenze di throughput. Questa funzionalità ti consentirà di adottare la modalità Provisioned per tutti i tuoi carichi di lavoro Kafka e di beneficiare di funzionalità come la convalida dello schema, il filtraggio Avro/Protobuf degli eventi, le chiamate a bassa latenza e la gestione avanzata degli errori disponibili solo in modalità Provisioned.
Quando configuri il `PollerGroupName` parametro con lo stesso valore per più utenti ESMs all'interno dello stesso Amazon VPC, questi ESMs condividono le risorse EPU anziché richiedere una capacità EPU dedicata. Puoi raggruppare fino a 100 ESMs per gruppo di poller e il numero massimo di poller aggregato per tutti ESMs i membri di un gruppo non può superare i 2000.
#### Per configurare il raggruppamento ESM (console)
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegliere la funzione.
1. Scegli **Configurazione**, quindi scegli **Trigger**.
1. ****Quando crei una nuova mappatura della sorgente degli eventi Kafka o ne modifichi una esistente, seleziona Configura in modalità Provisioned.****
1. Per **Numero minimo di poller di eventi**, inserisci un valore compreso tra 1 e 200.
1. Per **Numero massimo di poller di eventi**, inserisci un valore compreso tra 1 e 2.000.
1. Per il **nome del gruppo Poller**, inserisci un identificatore per il gruppo. Usa lo stesso nome per gli altri ESMs che vuoi raggruppare.
1. Scegli **Save** (Salva).
#### Per configurare il raggruppamento ESM (CLI AWS )
L'esempio seguente crea un ESM con un gruppo di poller denominato: `production-app-group`
```
aws lambda create-event-source-mapping \
--function-name myFunction1 \
--event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster/abcd1234 \
--topics topic1 \
--starting-position LATEST \
--provisioned-poller-config '{
"MinimumPollers": 1,
"MaximumPollers": 10,
"PollerGroupName": "production-app-group"
}'
```
Per aggiungere un altro ESM allo stesso gruppo (condividendo la capacità EPU), usa lo stesso: PollerGroupName
```
aws lambda create-event-source-mapping \
--function-name myFunction2 \
--event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster/abcd1234 \
--topics topic2 \
--starting-position LATEST \
--provisioned-poller-config '{
"MinimumPollers": 1,
"MaximumPollers": 10,
"PollerGroupName": "production-app-group"
}'
```
**Nota**
È possibile aggiornare il file `PollerGroupName` per spostare un ESM in un gruppo diverso o rimuovere un ESM da un gruppo passando una stringa vuota («») per: `PollerGroupName`
```
# Move ESM to a different group
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--provisioned-poller-config '{
"MinimumPollers": 1,
"MaximumPollers": 10,
"PollerGroupName": "new-group-name"
}'
# Remove ESM from group (use dedicated resources)
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--provisioned-poller-config '{
"MinimumPollers": 1,
"MaximumPollers": 10,
"PollerGroupName": ""
}'
```
#### Considerazioni sulla strategia di raggruppamento
+ **Limite dell'applicazione**: gruppo ESMs che appartiene alle stesse applicazioni o servizi per una migliore allocazione e gestione dei costi. Prendi in considerazione l'utilizzo di convenzioni di denominazione come `app-name-environment` (ad esempio,). `order-processor-prod`
+ **Schema del traffico**: evita i raggruppamenti ESMs con un throughput elevato e un andamento di traffico con picchi di traffico, poiché ciò potrebbe portare a un conflitto di risorse.
+ **Blast radius**: considera l'impatto se l'infrastruttura condivisa presenta problemi. Tutti i ESMs membri dello stesso gruppo sono interessati dalle limitazioni delle risorse condivise. Per i carichi di lavoro mission critical, potresti voler utilizzare gruppi separati o dedicati. ESMs
#### Esempio di ottimizzazione dei costi
Considerate uno scenario in cui ne avete 10 ESMs, ciascuno configurato con 1 event poller e un throughput inferiore a 2 MB/s:
**Senza raggruppamento:**
+ Ogni ESM richiede la propria EPU
+ Totale EPUs necessario: 10
+ Costo per EPU: 0,185 USD/ora negli Stati Uniti orientali (Virginia settentrionale)
+ Costo EPU mensile (720 ore): 10 × 720 × 0,185 USD = 1.332 USD
**Con raggruppamento:**
+ Tutti e 10 ESMs condividono la capacità dell'EPU
+ 10 sondaggi per eventi rientrano in 1 EPU (con nuovi 10 sondaggi per ogni supporto EPU)
+ Totale necessario: 1 EPUs
+ Costo mensile dell'EPU (720 ore): 1 × 720 × 0,185 USD = 133,20 USD
+ **Risparmio sui costi: 90% (1.198,80\$1 di risparmio al mese**)
# Sondaggi di Apache Kafka e posizioni iniziali dello streaming in Lambda
Il [parametro startingPosition](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-StartingPosition) indica a Lambda quando iniziare a leggere i messaggi dal tuo stream Amazon MSK o Apache Kafka autogestito. Ci sono tre opzioni tra cui scegliere:
+ Più **recente**: Lambda inizia a leggere subito dopo il record più recente nell'argomento Kafka.
+ **Orizzonte di taglio**: inizia a leggere l'argomento con l'ultimo record non tagliato nella partizione. Questo è il record meno recente nella partizione.
+ **Al timestamp:** Lambda avvia la lettura da una posizione definita da un timestamp, in secondi di tempo Unix. Utilizzate il parametro [startingPositionTimestamp per specificare il timestamp](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-StartingPositionTimestamp).
Tieni presente che il polling dei flussi durante la creazione e gli aggiornamenti dello strumento di mappatura dell'origine degli eventi alla fine è coerente.
+ Durante la creazione dello strumento di mappatura dell'origine degli eventi, potrebbero essere necessari alcuni minuti per l'avvio degli eventi di polling dal flusso.
+ Durante gli aggiornamenti dello strumento di mappatura dell'origine degli eventi, potrebbero essere necessari alcuni minuti per l'avvio degli eventi di polling dal flusso.
Questo comportamento implica che se specifichi `LATEST` come posizione iniziale del flusso, lo strumento di mappatura dell'origine degli eventi potrebbe perdere eventi durante la creazione o gli aggiornamenti. Per garantire che nessun evento venga perso, specificate o. `TRIM_HORIZON` `AT_TIMESTAMP`
# ID gruppo di consumer personalizzabile
Quando configuri Amazon MSK o Apache Kafka autogestita come origine, puoi specificare un ID [gruppo di consumer](https://developer.confluent.io/learn-more/kafka-on-the-go/consumer-groups/). Questo ID gruppo di consumer è un identificatore esistente per il gruppo di consumer Kafka a cui desideri che la tua funzione Lambda aderisca. Puoi utilizzare questa funzione per migrare senza problemi qualsiasi configurazione di elaborazione dei record Kafka in corso da altri utenti a Lambda.
Kafka distribuisce messaggi a tutti i consumer di un gruppo di consumer. Se si specifica un ID di gruppo di consumatori con altri consumatori attivi, Lambda riceve solo una parte dei messaggi dall'argomento Kafka. Se desideri che Lambda gestisca tutti i messaggi dell'argomento, disattiva tutti gli altri sondaggi in quel gruppo di consumer.
Inoltre, se specifichi un ID gruppo di consumer e Kafka trova un gruppo di consumer esistente valido con lo stesso ID, Lambda ignora il parametro per la mappatura dell'origine eventi. Inizia invece ad elaborare i record in base alla compensazione impegnata del gruppo di consumer. Se specifichi un ID gruppo di consumer e Kafka non riesce a trovare un gruppo di consumer esistente, Lambda configura l'origine eventi con la specificata `StartingPosition`.
L'ID gruppo di consumer deve essere univoco tra tutte le origini eventi Kafka. Dopo aver creato una mappatura dell'origine eventi Kafka con l'ID gruppo di consumer specificato, non sarà più possibile aggiornare questo valore.
# Filtraggio eventi da origini eventi Amazon MSK e Apache Kafka autogestito
Puoi utilizzare il filtraggio degli eventi per controllare quali record di un flusso o di una coda Lambda invia alla funzione. Per informazioni generali sul funzionamento del filtraggio eventi, consulta [Controllare gli eventi che Lambda invia alla funzione](invocation-eventfiltering.md).
**Nota**
Amazon MSK e le mappature origine eventi Apache Kafka autogestito. `value`
**Topics**
+ [
## Nozioni di base del filtro evento
](#filtering-kafka)
## Nozioni di base del filtro evento
Supponiamo che un produttore stia scrivendo messaggi su un argomento nel tuo cluster Amazon MSK, in formato JSON valido o come stringhe semplici. Un record di esempio sarebbe simile al seguente, con il messaggio convertito in una stringa codificata Base64 nel campo `value`.
```
{
"mytopic-0":[
{
"topic":"mytopic",
"partition":0,
"offset":15,
"timestamp":1545084650987,
"timestampType":"CREATE_TIME",
"value":"SGVsbG8sIHRoaXMgaXMgYSB0ZXN0Lg==",
"headers":[]
}
]
}
```
Supponiamo che il produttore Apache Kafka stia scrivendo messaggi sul tuo argomento nel seguente formato JSON.
```
{
"device_ID": "AB1234",
"session":{
"start_time": "yyyy-mm-ddThh:mm:ss",
"duration": 162
}
}
```
Puoi utilizzare la chiave `value` per filtrare i record. Supponiamo di voler filtrare solo i record in cui `device_ID` inizia con le lettere AB. L'oggetto `FilterCriteria` dovrebbe avere la struttura seguente.
```
{
"Filters": [
{
"Pattern": "{ \"value\" : { \"device_ID\" : [ { \"prefix\": \"AB\" } ] } }"
}
]
}
```
Per una maggiore chiarezza, ecco il valore del `Pattern` del filtro espanso in JSON semplice.
```
{
"value": {
"device_ID": [ { "prefix": "AB" } ]
}
}
```
Puoi aggiungere il filtro utilizzando la console, la AWS CLI o un modello AWS SAM.
------
#### [ Console ]
Per aggiungere questo filtro utilizzando la console, segui le istruzioni riportate in [Collegamento dei criteri di filtro a una mappatura dell'origine evento (console)](invocation-eventfiltering.md#filtering-console) e inserisci la seguente stringa per i **criteri di filtraggio**.
```
{ "value" : { "device_ID" : [ { "prefix": "AB" } ] } }
```
------
#### [ AWS CLI ]
Per creare una nuova mappatura dell'origine degli eventi con questi criteri di filtraggio utilizzando l'AWS Command Line Interface (AWS CLI), esegui il comando seguente.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:kafka:us-east-2:123456789012:cluster/my-cluster/b-8ac7cc01-5898-482d-be2f-a6b596050ea8 \
--filter-criteria '{"Filters": [{"Pattern": "{ \"value\" : { \"device_ID\" : [ { \"prefix\": \"AB\" } ] } }"}]}'
```
Per aggiungere questi criteri di filtraggio a una mappatura dell'origine degli eventi esistente, esegui il comando seguente.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"value\" : { \"device_ID\" : [ { \"prefix\": \"AB\" } ] } }"}]}'
```
------
#### [ AWS SAM ]
Per aggiungere questo filtro utilizzando AWS SAM, aggiungi il seguente frammento al modello YAML dell'origine degli eventi.
```
FilterCriteria:
Filters:
- Pattern: '{ "value" : { "device_ID" : [ { "prefix": "AB" } ] } }'
```
------
Con Amazon MSK, puoi anche filtrare i record in cui il messaggio è una stringa semplice. Supponiamo di voler ignorare i messaggi la cui stringa è "errore". L'oggetto `FilterCriteria` dovrebbe avere la struttura seguente.
```
{
"Filters": [
{
"Pattern": "{ \"value\" : [ { \"anything-but\": [ \"error\" ] } ] }"
}
]
}
```
Per una maggiore chiarezza, ecco il valore del `Pattern` del filtro espanso in JSON semplice.
```
{
"value": [
{
"anything-but": [ "error" ]
}
]
}
```
Puoi aggiungere il filtro utilizzando la console, la AWS CLI o un modello AWS SAM.
------
#### [ Console ]
Per aggiungere questo filtro utilizzando la console, segui le istruzioni riportate in [Collegamento dei criteri di filtro a una mappatura dell'origine evento (console)](invocation-eventfiltering.md#filtering-console) e inserisci la seguente stringa per i **criteri di filtraggio**.
```
{ "value" : [ { "anything-but": [ "error" ] } ] }
```
------
#### [ AWS CLI ]
Per creare una nuova mappatura dell'origine degli eventi con questi criteri di filtraggio utilizzando l'AWS Command Line Interface (AWS CLI), esegui il comando seguente.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:kafka:us-east-2:123456789012:cluster/my-cluster/b-8ac7cc01-5898-482d-be2f-a6b596050ea8 \
--filter-criteria '{"Filters": [{"Pattern": "{ \"value\" : [ { \"anything-but\": [ \"error\" ] } ] }"}]}'
```
Per aggiungere questi criteri di filtraggio a una mappatura dell'origine degli eventi esistente, esegui il comando seguente.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"value\" : [ { \"anything-but\": [ \"error\" ] } ] }"}]}'
```
------
#### [ AWS SAM ]
Per aggiungere questo filtro utilizzando AWS SAM, aggiungi il seguente frammento al modello YAML dell'origine degli eventi.
```
FilterCriteria:
Filters:
- Pattern: '{ "value" : [ { "anything-but": [ "error" ] } ] }'
```
------
I messaggi Kafka e Amazon MQ devono essere stringhe codificate in UTF-8, stringhe semplici o in formato JSON. Questo perché Lambda decodifica gli array di byte Kafka in UTF-8 prima di applicare i criteri di filtro. Se i messaggi utilizzano un'altra codifica, ad esempio UTF-16 o ASCII o se il formato del messaggio non corrisponde al formato `FilterCriteria`, Lambda elabora solo i filtri di metadati. La tabella seguente riepiloga il comportamento specifico:
| Formato messaggio in arrivo | Formato del modello di filtro per le proprietà di messaggi | Operazione risultante |
| --- | --- | --- |
| Stringa normale | Stringa normale | Filtri Lambda in base ai criteri di filtro. |
| Stringa normale | Nessun modello di filtro per le proprietà dei dati | Filtri Lambda (solo sulle altre proprietà dei metadati) in base ai criteri di filtro. |
| Stringa normale | JSON valido | Filtri Lambda (solo sulle altre proprietà dei metadati) in base ai criteri di filtro. |
| JSON valido | Stringa normale | Filtri Lambda (solo sulle altre proprietà dei metadati) in base ai criteri di filtro. |
| JSON valido | Nessun modello di filtro per le proprietà dei dati | Filtri Lambda (solo sulle altre proprietà dei metadati) in base ai criteri di filtro. |
| JSON valido | JSON valido | Filtri Lambda in base ai criteri di filtro. |
| Stringa codificata non UTF-8 | JSON, stringa semplice o nessun modello | Filtri Lambda (solo sulle altre proprietà dei metadati) in base ai criteri di filtro. |
# Utilizzo dei registri degli schemi con le sorgenti di eventi Kafka in Lambda
I registri degli schemi ti aiutano a definire e gestire gli schemi dei flussi di dati. Uno schema definisce la struttura e il formato di un registro di dati. Nel contesto delle mappature delle sorgenti degli eventi Kafka, puoi configurare un registro degli schemi per convalidare la struttura e il formato dei messaggi Kafka rispetto a schemi predefiniti prima che raggiungano la tua funzione Lambda. Ciò aggiunge un livello di governance dei dati all'applicazione e consente di gestire in modo efficiente i formati di dati, garantire la conformità allo schema e ottimizzare i costi tramite il filtraggio degli eventi.
Questa funzionalità è compatibile con tutti i linguaggi di programmazione, ma considera questi punti importanti:
+ Powertools for Lambda fornisce supporto specifico per Java, Python e mantiene la coerenza con i modelli di sviluppo Kafka esistenti TypeScript e consente l'accesso diretto agli oggetti aziendali senza codice di deserializzazione personalizzato
+ Questa funzionalità è disponibile solo per le mappature delle sorgenti degli eventi che utilizzano la modalità provisioned. Il registro degli schemi non supporta i mapping delle sorgenti degli eventi in modalità su richiesta. Se si utilizza la modalità provisioning e si dispone di un registro degli schemi configurato, non è possibile passare alla modalità su richiesta a meno che non si rimuova prima la configurazione del registro dello schema. Per ulteriori informazioni, consulta [Modalità provisioning](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode)
+ È possibile configurare un solo registro degli schemi per Event Source Mapping (ESM). L'utilizzo di un registro degli schemi con l'origine degli eventi Kafka può aumentare l'utilizzo della Lambda Event Poller Unit (EPU), che è una dimensione tariffaria per la modalità Provisioned.
**Topics**
+ [
## Opzioni del registro dello schema
](#services-consume-kafka-events-options)
+ [
## In che modo Lambda esegue la convalida dello schema per i messaggi Kafka
](#services-consume-kafka-events-how)
+ [
## Configurazione di un registro degli schemi Kafka
](#services-consume-kafka-events-config)
+ [
## Filtraggio per Avro e Protobuf
](#services-consume-kafka-events-filtering)
+ [
## Formati di payload e comportamento di deserializzazione
](#services-consume-kafka-events-payload)
+ [
## Utilizzo di dati deserializzati nelle funzioni Lambda
](#services-consume-kafka-events-payload-examples)
+ [
## Metodi di autenticazione per il registro degli schemi
](#services-consume-kafka-events-auth)
+ [
## Gestione degli errori e risoluzione dei problemi relativi al registro dello schema
](#services-consume-kafka-events-troubleshooting)
## Opzioni del registro dello schema
Lambda supporta le seguenti opzioni di registro dello schema:
+ [AWS Glue Registro degli schemi](https://docs.aws.amazon.com/glue/latest/dg/schema-registry.html)
+ [Registro degli schemi Confluent Cloud](https://docs.confluent.io/platform/current/schema-registry/index.html)
+ [Registro degli schemi Confluent autogestito](https://docs.confluent.io/platform/current/schema-registry/index.html)
Il registro degli schemi supporta la convalida dei messaggi nei seguenti formati di dati:
+ Apache Avro
+ Buffer di protocollo (Protobuf)
+ Schema JSON (JSON-SE)
Per utilizzare un registro degli schemi, assicurati innanzitutto che la mappatura delle sorgenti degli eventi sia in modalità provisioning. Quando si utilizza un registro dello schema, Lambda aggiunge i metadati relativi allo schema al payload. Per ulteriori informazioni, consulta [Formati di payload](#services-consume-kafka-events-payload) e comportamento di deserializzazione.
## In che modo Lambda esegue la convalida dello schema per i messaggi Kafka
Quando configuri un registro degli schemi, Lambda esegue i seguenti passaggi per ogni messaggio Kafka:
1. Lambda analizza il record di Kafka dal tuo cluster.
1. Lambda convalida gli attributi dei messaggi selezionati nel record rispetto a uno schema specifico nel registro degli schemi.
+ Se lo schema associato al messaggio non viene trovato nel registro, Lambda invia il messaggio a un DLQ con codice motivo. `SCHEMA_NOT_FOUND`
1. Lambda deserializza il messaggio in base alla configurazione del registro dello schema per convalidarlo. Se il filtraggio degli eventi è configurato, Lambda esegue quindi il filtraggio in base ai criteri di filtro configurati.
+ Se la deserializzazione fallisce, Lambda invia il messaggio a un DLQ con il codice motivo. `DESERIALIZATION_ERROR` Se non è configurato alcun DLQ, Lambda rilascia il messaggio.
1. Se il messaggio è convalidato dal registro dello schema e non viene filtrato in base ai criteri di filtro, Lambda richiama la funzione con il messaggio.
Questa funzionalità ha lo scopo di convalidare i messaggi già prodotti utilizzando client Kafka integrati con un registro degli schemi. Ti consigliamo di configurare i tuoi produttori Kafka in modo che utilizzino il registro degli schemi per creare messaggi formattati correttamente.
## Configurazione di un registro degli schemi Kafka
I seguenti passaggi della console aggiungono una configurazione del registro dello schema Kafka alla mappatura delle sorgenti degli eventi.
**Per aggiungere una configurazione del registro dello schema Kafka alla mappatura delle sorgenti degli eventi (console)**
1. Apri la [pagina Funzione](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegliere **Configuration (Configurazione)**.
1. **Scegli Triggers.**
1. **Seleziona la mappatura della sorgente degli eventi Kafka per cui desideri configurare un registro dello schema e scegli Modifica.**
1. **In **Event poller configuration**, scegli Configura il registro dello schema.** La mappatura delle sorgenti degli eventi deve essere in modalità provisioning per visualizzare questa opzione.
1. Per l'**URI del registro degli schemi**, inserisci l'ARN del registro degli AWS Glue schemi o l'URL HTTPS del registro degli schemi di Confluent Cloud o del registro degli schemi Confluent Self-Managed.
1. I seguenti passaggi di configurazione indicano a Lambda come accedere al registro degli schemi. Per ulteriori informazioni, consulta [Metodi di autenticazione per il registro degli schemi](#services-consume-kafka-events-auth).
+ Per il **tipo di configurazione Access**, scegli il tipo di autenticazione che Lambda utilizza per accedere al registro dello schema.
+ Per **l'URI di configurazione di Access**, inserisci l'ARN del segreto Secrets Manager per l'autenticazione con il registro dello schema, se applicabile. Assicurati che il [ruolo di esecuzione](with-msk-permissions.md) della funzione contenga le autorizzazioni corrette.
1. Il campo **Encryption** si applica solo se il registro dello schema è firmato da un'Autorità di certificazione (CA) privata o da un'autorità di certificazione (CA) che non si trova nel Lambda Trust Store. Se applicabile, fornisci la chiave segreta contenente il certificato CA privato utilizzato dal registro dello schema per la crittografia TLS.
1. Per il **formato di registrazione degli eventi**, scegli come desideri che Lambda fornisca i record della tua funzione dopo la convalida dello schema. Per ulteriori informazioni, consulta gli [esempi di formati di payload](#services-consume-kafka-events-payload).
+ Se scegli **JSON**, Lambda fornisce gli attributi selezionati nell'attributo di convalida dello schema riportato di seguito in formato JSON standard. Per gli attributi che non selezioni, Lambda li fornisce così come sono.
+ Se scegli **SOURCE**, Lambda fornisce gli attributi selezionati nell'attributo di convalida dello schema riportato di seguito nel formato di origine originale.
1. Per l'**attributo di convalida dello schema**, seleziona gli attributi del messaggio che desideri che Lambda convalidi e deserializzi utilizzando il registro dello schema. ****È necessario selezionare almeno uno dei valori KEY o VALUE.**** Se hai scelto JSON per il formato di registrazione degli eventi, Lambda deserializza anche gli attributi del messaggio selezionati prima di inviarli alla tua funzione. Per ulteriori informazioni, consulta Formati di [payload](#services-consume-kafka-events-payload) e comportamento di deserializzazione.
1. Scegli **Save** (Salva).
Puoi anche utilizzare l'API Lambda per creare o aggiornare la mappatura delle sorgenti degli eventi con una configurazione del registro dello schema. *Gli esempi seguenti mostrano come configurare un registro di schemi AWS Glue o Confluent utilizzando AWS CLI, che corrisponde alle operazioni [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)e [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)API nell'API Reference:AWS Lambda *
**Importante**
Se si sta aggiornando un campo di configurazione del registro dello schema utilizzando AWS CLI o l'`update-event-source-mapping`API, è necessario aggiornare tutti i campi della configurazione del registro dello schema.
------
#### [ Create Event Source Mapping ]
```
aws lambda create-event-source-mapping \
--function-name my-schema-validator-function \
--event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/my-cluster/a1b2c3d4-5678-90ab-cdef-11111EXAMPLE \
--topics my-kafka-topic \
--provisioned-poller-config MinimumPollers=1,MaximumPollers=1 \
--amazon-managed-kafka-event-source-mapping '{
"SchemaRegistryConfig" : {
"SchemaRegistryURI": "https://abcd-ef123.us-west-2.aws.confluent.cloud",
"AccessConfigs": [{
"Type": "BASIC_AUTH",
"URI": "arn:aws:secretsmanager:us-east-1:123456789012:secret:secretName"
}],
"EventRecordFormat": "JSON",
"SchemaValidationConfigs": [
{
"Attribute": "KEY"
},
{
"Attribute": "VALUE"
}]
}
}'
```
------
#### [ Update AWS Glue Schema Registry ]
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--amazon-managed-kafka-event-source-mapping '{
"SchemaRegistryConfig" : {
"SchemaRegistryURI": "arn:aws:glue:us-east-1:123456789012:registry/registryName",
"EventRecordFormat": "JSON",
"SchemaValidationConfigs": [
{
"Attribute": "KEY"
},
{
"Attribute": "VALUE"
}]
}
}'
```
------
#### [ Update Confluent Schema Registry with Authentication ]
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--amazon-managed-kafka-event-source-mapping '{
"SchemaRegistryConfig" : {
"SchemaRegistryURI": "https://abcd-ef123.us-west-2.aws.confluent.cloud",
"AccessConfigs": [{
"Type": "BASIC_AUTH",
"URI": "arn:aws:secretsmanager:us-east-1:123456789012:secret:secretName"
}],
"EventRecordFormat": "JSON",
"SchemaValidationConfigs": [
{
"Attribute": "KEY"
},
{
"Attribute": "VALUE"
}]
}
}'
```
------
#### [ Update Confluent Schema Registry without Authentication ]
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--amazon-managed-kafka-event-source-mapping '{
"SchemaRegistryConfig" : {
"SchemaRegistryURI": "https://abcd-ef123.us-west-2.aws.confluent.cloud",
"EventRecordFormat": "JSON",
"SchemaValidationConfigs": [
{
"Attribute": "KEY"
},
{
"Attribute": "VALUE"
}]
}
}'
```
------
#### [ Remove Schema Registry Configuration ]
Per rimuovere una configurazione del registro dello schema dalla mappatura dell'origine degli eventi, puoi utilizzare il [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)comando *AWS Lambda CLI* nell'API Reference.
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--amazon-managed-kafka-event-source-mapping '{
"SchemaRegistryConfig" : {}
}'
```
------
## Filtraggio per Avro e Protobuf
Quando si utilizzano i formati Avro o Protobuf con un registro degli schemi, è possibile applicare il filtro degli eventi alla funzione Lambda. I modelli di filtro vengono applicati alla rappresentazione JSON classica deserializzata dei dati dopo la convalida dello schema. Ad esempio, con uno schema Avro che definisce i dettagli del prodotto, incluso il prezzo, puoi filtrare i messaggi in base al valore del prezzo:
**Nota**
Quando viene deserializzato, Avro viene convertito in JSON standard, il che significa che non può essere riconvertito direttamente in un oggetto Avro. Se devi eseguire la conversione in un oggetto Avro, usa invece il formato SOURCE.
Per la deserializzazione di Protobuf, i nomi dei campi nel JSON risultante corrispondono a quelli definiti nello schema, anziché essere convertiti in camel case come fa normalmente Protobuf. Tienilo a mente quando crei modelli di filtraggio.
```
aws lambda create-event-source-mapping \
--function-name myAvroFunction \
--topics myAvroTopic \
--starting-position TRIM_HORIZON \
--kafka-bootstrap-servers '["broker1:9092", "broker2:9092"]' \
--schema-registry-config '{
"SchemaRegistryURI": "arn:aws:glue:us-east-1:123456789012:registry/myAvroRegistry",
"EventRecordFormat": "JSON",
"SchemaValidationConfigs": [
{
"Attribute": "VALUE"
}
]
}' \
--filter-criteria '{
"Filters": [
{
"Pattern": "{ \"value\" : { \"field_1\" : [\"value1\"], \"field_2\" : [\"value2\"] } }"
}
]
}'
```
In questo esempio, lo schema di filtro analizza l'`value`oggetto, associando i messaggi `field_1` con `"value1"` e `field_2` con. `"value2"` I criteri di filtro vengono valutati rispetto ai dati deserializzati, dopo che Lambda ha convertito il messaggio dal formato Avro a JSON.
Per informazioni più dettagliate sul filtraggio degli eventi, consulta Filtraggio degli eventi [Lambda](invocation-eventfiltering.md).
## Formati di payload e comportamento di deserializzazione
Quando si utilizza un registro degli schemi, Lambda fornisce il payload finale alla funzione in un formato simile al [normale payload degli eventi](with-msk.md#msk-sample-event), con alcuni campi aggiuntivi. I campi aggiuntivi dipendono dal parametro. `SchemaValidationConfigs` Per ogni attributo selezionato per la convalida (chiave o valore), Lambda aggiunge i metadati dello schema corrispondenti al payload.
**Nota**
Devi aggiornare il tuo [aws-lambda-java-events](https://github.com/aws/aws-lambda-java-libs/tree/main/aws-lambda-java-events)alla versione 3.16.0 o successiva per utilizzare i campi dei metadati dello schema.
Ad esempio, se convalidi il `value` campo, Lambda aggiunge un campo `valueSchemaMetadata` chiamato al tuo payload. Allo stesso modo, per il `key` campo, Lambda aggiunge un campo chiamato. `keySchemaMetadata` Questi metadati contengono informazioni sul formato dei dati e sull'ID dello schema utilizzati per la convalida:
```
"valueSchemaMetadata": {
"dataFormat": "AVRO",
"schemaId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
```
Il `EventRecordFormat` parametro può essere impostato su `JSON` o`SOURCE`, il che determina in che modo Lambda gestisce i dati convalidati dallo schema prima di consegnarli alla tua funzione. Ogni opzione offre diverse funzionalità di elaborazione:
+ `JSON`- Lambda deserializza gli attributi convalidati in formato JSON standard, rendendo i dati pronti per l'uso diretto nelle lingue con supporto JSON nativo. Questo formato è ideale quando non è necessario conservare il formato binario originale o lavorare con classi generate.
+ `SOURCE`- Lambda conserva il formato binario originale dei dati come stringa con codifica Base64, che consente la conversione diretta in oggetti Avro o Protobuf. Questo formato è essenziale quando si lavora con linguaggi fortemente tipizzati o quando è necessario mantenere tutte le funzionalità degli schemi Avro o Protobuf.
In base a queste caratteristiche di formato e alle considerazioni specifiche della lingua, consigliamo i seguenti formati:
**Formati consigliati basati sul linguaggio di programmazione**
| Lingua | Avro | Protobuf | JSON |
| --- | --- | --- | --- |
| Java | SOURCE | SOURCE | SOURCE |
| Python | JSON | JSON | JSON |
| NodeJS | JSON | JSON | JSON |
| .NET | SOURCE | SOURCE | SOURCE |
| Altri | JSON | JSON | JSON |
Le sezioni seguenti descrivono questi formati in dettaglio e forniscono esempi di payload per ogni formato.
### Formato JSON
Se scegli `JSON` come`EventRecordFormat`, Lambda convalida e deserializza gli attributi del messaggio che hai selezionato nel campo (gli attributi). `SchemaValidationConfigs` `key` and/or `value` Lambda fornisce questi attributi selezionati come stringhe con codifica base64 della loro rappresentazione JSON standard nella funzione.
**Nota**
Quando viene deserializzato, Avro viene convertito in JSON standard, il che significa che non può essere riconvertito direttamente in un oggetto Avro. Se devi eseguire la conversione in un oggetto Avro, usa invece il formato SOURCE.
Per la deserializzazione di Protobuf, i nomi dei campi nel JSON risultante corrispondono a quelli definiti nello schema, anziché essere convertiti in camel case come fa normalmente Protobuf. Tienilo a mente quando crei modelli di filtraggio.
Di seguito viene mostrato un esempio di payload, supponendo che tu scelga `JSON` come `EventRecordFormat` ed entrambi gli attributi `key` e `value` come `SchemaValidationConfigs`:
```
{
"eventSource":"aws:kafka",
"eventSourceArn":"arn:aws:kafka:us-east-1:123456789012:cluster/vpc-2priv-2pub/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111-1",
"bootstrapServers":"b-2.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092,b-1.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092",
"records":{
"mytopic-0":[
{
"topic":"mytopic",
"partition":0,
"offset":15,
"timestamp":1545084650987,
"timestampType":"CREATE_TIME",
"key":"abcDEFghiJKLmnoPQRstuVWXyz1234==", //Base64 encoded string of JSON
"keySchemaMetadata": {
"dataFormat": "AVRO",
"schemaId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"value":"abcDEFghiJKLmnoPQRstuVWXyz1234", //Base64 encoded string of JSON
"valueSchemaMetadata": {
"dataFormat": "AVRO",
"schemaId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"headers":[
{
"headerKey":[
104,
101,
97,
100,
101,
114,
86,
97,
108,
117,
101
]
}
]
}
]
}
}
```
In questo esempio:
+ Entrambe `key` e `value` sono stringhe codificate in base64 della loro rappresentazione JSON dopo la deserializzazione.
+ Lambda include i metadati dello schema per entrambi gli attributi in e. `keySchemaMetadata` `valueSchemaMetadata`
+ La tua funzione può decodificare le stringhe `key` e `value` per accedere ai dati JSON deserializzati.
Il formato JSON è consigliato per i linguaggi che non sono fortemente tipizzati, come Python o Node.js. Questi linguaggi dispongono del supporto nativo per la conversione di JSON in oggetti.
### Formato sorgente
Se scegli `SOURCE` come`EventRecordFormat`, Lambda convalida comunque il record rispetto al registro dello schema, ma fornisce i dati binari originali alla tua funzione senza deserializzazione. Questi dati binari vengono forniti come stringa codificata in Base64 dei dati in byte originali, con i metadati aggiunti dal produttore rimossi. Di conseguenza, è possibile convertire direttamente i dati binari non elaborati in oggetti Avro e Protobuf all'interno del codice della funzione. Ti consigliamo di utilizzare Powertools for AWS Lambda, che deserializzerà i dati binari grezzi e ti fornirà direttamente gli oggetti Avro e Protobuf.
Ad esempio, se configuri Lambda per convalidare entrambi gli attributi `key` e `value` ma utilizzi il formato `SOURCE`, la tua funzione riceve un payload come questo:
```
{
"eventSource": "aws:kafka",
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/vpc-2priv-2pub/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111-1",
"bootstrapServers": "b-2.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092,b-1.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092",
"records": {
"mytopic-0": [
{
"topic": "mytopic",
"partition": 0,
"offset": 15,
"timestamp": 1545084650987,
"timestampType": "CREATE_TIME",
"key": "abcDEFghiJKLmnoPQRstuVWXyz1234==", // Base64 encoded string of Original byte data, producer-appended metadata removed
"keySchemaMetadata": {
"dataFormat": "AVRO",
"schemaId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"value": "abcDEFghiJKLmnoPQRstuVWXyz1234==", // Base64 encoded string of Original byte data, producer-appended metadata removed
"valueSchemaMetadata": {
"dataFormat": "AVRO",
"schemaId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"headers": [
{
"headerKey": [
104,
101,
97,
100,
101,
114,
86,
97,
108,
117,
101
]
}
]
}
]
}
}
```
In questo esempio:
+ Sia `key` che `value` contengono i dati binari originali come stringhe codificate in Base64.
+ La tua funzione deve gestire la deserializzazione utilizzando le librerie appropriate.
La scelta di `SOURCE` for `EventRecordFormat` è consigliata se utilizzate oggetti generati da AVRO o da ProtoBuf, specialmente con le funzioni Java. Questo perché Java è fortemente tipizzato e richiede deserializzatori specifici per i formati Avro e Protobuf. Nel codice della funzione, puoi usare la tua libreria Avro o Protobuf preferita per deserializzare i dati.
## Utilizzo di dati deserializzati nelle funzioni Lambda
Powertools for AWS Lambda consente di deserializzare i record Kafka nel codice della funzione in base al formato utilizzato. Questa utilità semplifica l'utilizzo dei record di Kafka gestendo la conversione dei dati e fornendo oggetti. ready-to-use
Per utilizzare Powertools for AWS Lambda nella tua funzione, devi aggiungere Powertools come livello o includerlo come dipendenza quando crei la tua funzione Lambda. AWS Lambda Per istruzioni di configurazione e ulteriori informazioni, consultate Powertools per la AWS Lambda documentazione relativa alla vostra lingua preferita:
+ [Powertools per AWS Lambda (Java)](https://docs.powertools.aws.dev/lambda/java/latest/utilities/kafka/)
+ [Utensili elettrici per AWS Lambda (Python)](https://docs.powertools.aws.dev/lambda/python/latest/utilities/kafka/)
+ [Utensili elettrici per () AWS Lambda TypeScript](https://docs.powertools.aws.dev/lambda/typescript/latest/features/kafka/)
+ [Utensili elettrici per AWS Lambda (.NET)](https://docs.powertools.aws.dev/lambda/dotnet/utilities/kafka/)
**Nota**
Quando si lavora con l'integrazione del registro dello schema, è possibile scegliere `SOURCE` o `JSON` formattare. Ogni opzione supporta diversi formati di serializzazione, come illustrato di seguito:
| Formato | Supporta |
| --- | --- |
| SOURCE | Avro e Protobuf (utilizzando l'integrazione del Lambda Schema Registry) |
| JSON | Dati JSON |
Quando si utilizza il `JSON` formato `SOURCE` o, è possibile utilizzare Powertools per aiutare AWS a deserializzare i dati nel codice della funzione. Ecco alcuni esempi di come gestire diversi formati di dati:
------
#### [ AVRO ]
Esempio di Java:
```
package org.demo.kafka;
import org.apache.kafka.clients.consumer.ConsumerRecord;
import org.apache.kafka.clients.consumer.ConsumerRecords;
import org.demo.kafka.avro.AvroProduct;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import software.amazon.lambda.powertools.kafka.Deserialization;
import software.amazon.lambda.powertools.kafka.DeserializationType;
import software.amazon.lambda.powertools.logging.Logging;
public class AvroDeserializationFunction implements RequestHandler, String> {
private static final Logger LOGGER = LoggerFactory.getLogger(AvroDeserializationFunction.class);
@Override
@Logging
@Deserialization(type = DeserializationType.KAFKA_AVRO)
public String handleRequest(ConsumerRecords records, Context context) {
for (ConsumerRecord consumerRecord : records) {
LOGGER.info("ConsumerRecord: {}", consumerRecord);
AvroProduct product = consumerRecord.value();
LOGGER.info("AvroProduct: {}", product);
String key = consumerRecord.key();
LOGGER.info("Key: {}", key);
}
return "OK";
}
}
```
Esempio di Python:
```
from aws_lambda_powertools.utilities.kafka_consumer.kafka_consumer import kafka_consumer
from aws_lambda_powertools.utilities.kafka_consumer.schema_config import SchemaConfig
from aws_lambda_powertools.utilities.kafka_consumer.consumer_records import ConsumerRecords
from aws_lambda_powertools.utilities.typing import LambdaContext
from aws_lambda_powertools import Logger
logger = Logger(service="kafkaConsumerPowertools")
value_schema_str = open("customer_profile.avsc", "r").read()
schema_config = SchemaConfig(
value_schema_type="AVRO",
value_schema=value_schema_str)
@kafka_consumer(schema_config=schema_config)
def lambda_handler(event: ConsumerRecords, context:LambdaContext):
for record in event.records:
value = record.value
logger.info(f"Received value: {value}")
```
TypeScript esempio:
```
import { kafkaConsumer } from '@aws-lambda-powertools/kafka';
import type { ConsumerRecords } from '@aws-lambda-powertools/kafka/types';
import { Logger } from '@aws-lambda-powertools/logger';
import type { Context } from 'aws-lambda';
const logger = new Logger();
type Value = {
id: number;
name: string;
price: number;
};
const schema = '{
"type": "record",
"name": "Product",
"fields": [
{ "name": "id", "type": "int" },
{ "name": "name", "type": "string" },
{ "name": "price", "type": "double" }
]
}';
export const handler = kafkaConsumer(
(event: ConsumerRecords, _context: Context) => {
for (const record of event.records) {
logger.info(Processing record with key: ${record.key});
logger.info(Record value: ${JSON.stringify(record.value)});
// You can add more processing logic here
}
},
{
value: {
type: 'avro',
schema: schema,
},
}
);
```
Esempio.NET:
```
using Amazon.Lambda.Core;
using AWS.Lambda.Powertools.Kafka;
using AWS.Lambda.Powertools.Kafka.Avro;
using AWS.Lambda.Powertools.Logging;
using Com.Example;
// Assembly attribute to enable the Lambda function's Kafka event to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(PowertoolsKafkaAvroSerializer))]
namespace ProtoBufClassLibrary;
public class Function
{
public string FunctionHandler(ConsumerRecords records, ILambdaContext context)
{
foreach (var record in records)
{
Logger.LogInformation("Processing messagem from topic: {topic}", record.Topic);
Logger.LogInformation("Partition: {partition}, Offset: {offset}", record.Partition, record.Offset);
Logger.LogInformation("Produced at: {timestamp}", record.Timestamp);
foreach (var header in record.Headers.DecodedValues())
{
Logger.LogInformation($"{header.Key}: {header.Value}");
}
Logger.LogInformation("Processing order for: {fullName}", record.Value.FullName);
}
return "Processed " + records.Count() + " records";
}
}
```
------
#### [ PROTOBUF ]
Esempio di Java:
```
package org.demo.kafka;
import org.apache.kafka.clients.consumer.ConsumerRecord;
import org.apache.kafka.clients.consumer.ConsumerRecords;
import org.demo.kafka.protobuf.ProtobufProduct;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import software.amazon.lambda.powertools.kafka.Deserialization;
import software.amazon.lambda.powertools.kafka.DeserializationType;
import software.amazon.lambda.powertools.logging.Logging;
public class ProtobufDeserializationFunction
implements RequestHandler, String> {
private static final Logger LOGGER = LoggerFactory.getLogger(ProtobufDeserializationFunction.class);
@Override
@Logging
@Deserialization(type = DeserializationType.KAFKA_PROTOBUF)
public String handleRequest(ConsumerRecords records, Context context) {
for (ConsumerRecord consumerRecord : records) {
LOGGER.info("ConsumerRecord: {}", consumerRecord);
ProtobufProduct product = consumerRecord.value();
LOGGER.info("ProtobufProduct: {}", product);
String key = consumerRecord.key();
LOGGER.info("Key: {}", key);
}
return "OK";
}
}
```
Esempio di Python:
```
from aws_lambda_powertools.utilities.kafka_consumer.kafka_consumer import kafka_consumer
from aws_lambda_powertools.utilities.kafka_consumer.schema_config import SchemaConfig
from aws_lambda_powertools.utilities.kafka_consumer.consumer_records import ConsumerRecords
from aws_lambda_powertools.utilities.typing import LambdaContext
from aws_lambda_powertools import Logger
from user_pb2 import User # protobuf generated class
logger = Logger(service="kafkaConsumerPowertools")
schema_config = SchemaConfig(
value_schema_type="PROTOBUF",
value_schema=User)
@kafka_consumer(schema_config=schema_config)
def lambda_handler(event: ConsumerRecords, context:LambdaContext):
for record in event.records:
value = record.value
logger.info(f"Received value: {value}")
```
TypeScript esempio:
```
import { kafkaConsumer } from '@aws-lambda-powertools/kafka';
import type { ConsumerRecords } from '@aws-lambda-powertools/kafka/types';
import { Logger } from '@aws-lambda-powertools/logger';
import type { Context } from 'aws-lambda';
import { Product } from './product.generated.js';
const logger = new Logger();
type Value = {
id: number;
name: string;
price: number;
};
export const handler = kafkaConsumer(
(event: ConsumerRecords, _context: Context) => {
for (const record of event.records) {
logger.info(Processing record with key: ${record.key});
logger.info(Record value: ${JSON.stringify(record.value)});
}
},
{
value: {
type: 'protobuf',
schema: Product,
},
}
);
```
Esempio.NET:
```
using Amazon.Lambda.Core;
using AWS.Lambda.Powertools.Kafka;
using AWS.Lambda.Powertools.Kafka.Protobuf;
using AWS.Lambda.Powertools.Logging;
using Com.Example;
// Assembly attribute to enable the Lambda function's Kafka event to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(PowertoolsKafkaProtobufSerializer))]
namespace ProtoBufClassLibrary;
public class Function
{
public string FunctionHandler(ConsumerRecords records, ILambdaContext context)
{
foreach (var record in records)
{
Logger.LogInformation("Processing messagem from topic: {topic}", record.Topic);
Logger.LogInformation("Partition: {partition}, Offset: {offset}", record.Partition, record.Offset);
Logger.LogInformation("Produced at: {timestamp}", record.Timestamp);
foreach (var header in record.Headers.DecodedValues())
{
Logger.LogInformation($"{header.Key}: {header.Value}");
}
Logger.LogInformation("Processing order for: {fullName}", record.Value.FullName);
}
return "Processed " + records.Count() + " records";
}
}
```
------
#### [ JSON ]
Esempio di Java:
```
package org.demo.kafka;
import org.apache.kafka.clients.consumer.ConsumerRecord;
import org.apache.kafka.clients.consumer.ConsumerRecords;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import software.amazon.lambda.powertools.kafka.Deserialization;
import software.amazon.lambda.powertools.kafka.DeserializationType;
import software.amazon.lambda.powertools.logging.Logging;
public class JsonDeserializationFunction implements RequestHandler, String> {
private static final Logger LOGGER = LoggerFactory.getLogger(JsonDeserializationFunction.class);
@Override
@Logging
@Deserialization(type = DeserializationType.KAFKA_JSON)
public String handleRequest(ConsumerRecords consumerRecords, Context context) {
for (ConsumerRecord consumerRecord : consumerRecords) {
LOGGER.info("ConsumerRecord: {}", consumerRecord);
Product product = consumerRecord.value();
LOGGER.info("Product: {}", product);
String key = consumerRecord.key();
LOGGER.info("Key: {}", key);
}
return "OK";
}
}
```
Esempio di Python:
```
from aws_lambda_powertools.utilities.kafka_consumer.kafka_consumer import kafka_consumer
from aws_lambda_powertools.utilities.kafka_consumer.schema_config import SchemaConfig
from aws_lambda_powertools.utilities.kafka_consumer.consumer_records import ConsumerRecords
from aws_lambda_powertools.utilities.typing import LambdaContext
from aws_lambda_powertools import Logger
logger = Logger(service="kafkaConsumerPowertools")
schema_config = SchemaConfig(value_schema_type="JSON")
@kafka_consumer(schema_config=schema_config)
def lambda_handler(event: ConsumerRecords, context:LambdaContext):
for record in event.records:
value = record.value
logger.info(f"Received value: {value}")
```
TypeScript esempio:
```
import { kafkaConsumer } from '@aws-lambda-powertools/kafka';
import type { ConsumerRecords } from '@aws-lambda-powertools/kafka/types';
import { Logger } from '@aws-lambda-powertools/logger';
import type { Context } from 'aws-lambda';
const logger = new Logger();
type Value = {
id: number;
name: string;
price: number;
};
export const handler = kafkaConsumer(
(event: ConsumerRecords, _context: Context) => {
for (const record of event.records) {
logger.info(Processing record with key: ${record.key});
logger.info(Record value: ${JSON.stringify(record.value)});
// You can add more processing logic here
}
},
{
value: {
type: 'json',
},
}
);
```
Esempio.NET:
```
using Amazon.Lambda.Core;
using AWS.Lambda.Powertools.Kafka;
using AWS.Lambda.Powertools.Kafka.Json;
using AWS.Lambda.Powertools.Logging;
using Com.Example;
// Assembly attribute to enable the Lambda function's Kafka event to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(PowertoolsKafkaJsonSerializer))]
namespace JsonClassLibrary;
public class Function
{
public string FunctionHandler(ConsumerRecords records, ILambdaContext context)
{
foreach (var record in records)
{
Logger.LogInformation("Processing messagem from topic: {topic}", record.Topic);
Logger.LogInformation("Partition: {partition}, Offset: {offset}", record.Partition, record.Offset);
Logger.LogInformation("Produced at: {timestamp}", record.Timestamp);
foreach (var header in record.Headers.DecodedValues())
{
Logger.LogInformation($"{header.Key}: {header.Value}");
}
Logger.LogInformation("Processing order for: {fullName}", record.Value.FullName);
}
return "Processed " + records.Count() + " records";
}
}
```
------
## Metodi di autenticazione per il registro degli schemi
Per utilizzare un registro degli schemi, Lambda deve essere in grado di accedervi in modo sicuro. Se lavori con un registro di AWS Glue schemi, Lambda si affida all'autenticazione IAM. Ciò significa che il [ruolo di esecuzione](lambda-intro-execution-role.md) della funzione deve disporre delle seguenti autorizzazioni per accedere al registro: AWS Glue
+ [GetRegistry](https://docs.aws.amazon.com/glue/latest/webapi/API_GetRegistry.html)nel *AWS Glue Web API Reference*
+ [GetSchemaVersion](https://docs.aws.amazon.com/glue/latest/webapi/API_GetSchemaVersion.html)nel *AWS Glue Web API Reference*
Esempio della policy IAM richiesta:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetRegistry",
"glue:GetSchemaVersion"
],
"Resource": [
"*"
]
}
]
}
```
------
**Nota**
Per i registri AWS Glue dello schema, se fornisci `AccessConfigs` un AWS Glue registro, Lambda restituirà un'eccezione di convalida.
Se lavori con un registro di schemi Confluent, puoi scegliere uno dei tre metodi di autenticazione supportati per il parametro del tuo oggetto: `Type` [KafkaSchemaRegistryAccessConfig](https://docs.aws.amazon.com/lambda/latest/api/API_KafkaSchemaRegistryAccessConfig)
+ **BASIC\$1AUTH** — Lambda utilizza nome utente e password o chiave API e autenticazione segreta API per accedere al registro. Se scegli questa opzione, fornisci l'ARN di Secrets Manager contenente le tue credenziali nel campo URI.
+ **CLIENT\$1CERTIFICATE\$1TLS\$1AUTH — Lambda** utilizza l'autenticazione TLS reciproca con i certificati client. Per utilizzare questa opzione, Lambda deve accedere sia al certificato che alla chiave privata. Fornisci l'ARN di Secrets Manager contenente queste credenziali nel campo URI.
+ **NO\$1AUTH**: il certificato emesso da una CA pubblica deve essere firmato da un'autorità di certificazione (CA) presente nel trust store di Lambda. Per un certificato CA privato/autofirmato, si configura il certificato CA principale del server. Per utilizzare questa opzione, omettete il parametro. `AccessConfigs`
Inoltre, se Lambda necessita dell'accesso a un certificato CA privato per verificare il certificato TLS del registro dello schema, scegli `SERVER_ROOT_CA_CERT` `Type` e fornisci l'ARN di Secrets Manager al certificato nel campo URI.
**Nota**
Per configurare l'`SERVER_ROOT_CA_CERT`opzione nella console, fornisci l'ARN segreto contenente il certificato nel campo **Crittografia**.
La configurazione di autenticazione per il registro degli schemi è separata da qualsiasi autenticazione configurata per il cluster Kafka. È necessario configurarli entrambi separatamente, anche se utilizzano metodi di autenticazione simili.
## Gestione degli errori e risoluzione dei problemi relativi al registro dello schema
Quando si utilizza un registro degli schemi con l'origine degli eventi Amazon MSK, è possibile che si verifichino diversi errori. Questa sezione fornisce indicazioni sui problemi più comuni e su come risolverli.
### Errori di configurazione
Questi errori si verificano durante l'impostazione della configurazione del registro dello schema.
È richiesta la modalità di provisioning
**Messaggio di errore**: `SchemaRegistryConfig is only available for Provisioned Mode. To configure Schema Registry, please enable Provisioned Mode by specifying MinimumPollers in ProvisionedPollerConfig.`
**Risoluzione:** abilita la modalità provisioning per la mappatura delle sorgenti degli eventi configurando il parametro in. `MinimumPollers` `ProvisionedPollerConfig`
URL del registro dello schema non valido
**Messaggio di errore**: `Malformed SchemaRegistryURI provided. Please provide a valid URI or ARN. For example, https://schema-registry.example.com:8081 or arn:aws:glue:us-east-1:123456789012:registry/ExampleRegistry.`
**Risoluzione:** fornire un URL HTTPS valido per Confluent Schema Registry o un ARN valido per Schema Registry. AWS Glue
Formato di registrazione degli eventi non valido o mancante
**Messaggio di errore**: `EventRecordFormat is a required field for SchemaRegistryConfig. Please provide one of supported format types: SOURCE, JSON.`
**Risoluzione:** specifica SOURCE o JSON come file EventRecordFormat nella configurazione del registro dello schema.
Attributi di convalida duplicati
**Messaggio di errore**: `Duplicate KEY/VALUE Attribute in SchemaValidationConfigs. SchemaValidationConfigs must contain at most one KEY/VALUE Attribute.`
**Risoluzione:** rimuovi gli attributi KEY o VALUE duplicati dal tuo. SchemaValidationConfigs Ogni tipo di attributo può apparire solo una volta.
Configurazione di convalida mancante
**Messaggio di errore**: `SchemaValidationConfigs is a required field for SchemaRegistryConfig.`
**Risoluzione:** aggiungi SchemaValidationConfigs alla tua configurazione, specificando almeno un attributo di convalida (KEY o VALUE).
### Errori di accesso e autorizzazione
Questi errori si verificano quando Lambda non può accedere al registro dello schema a causa di problemi di autorizzazione o autenticazione.
AWS Glue Accesso al registro degli schemi negato
**Messaggio di errore**: `Cannot access Glue Schema with provided role. Please ensure the provided role can perform the GetRegistry and GetSchemaVersion Actions on your schema.`
**Risoluzione:** aggiungi le autorizzazioni necessarie (`glue:GetRegistry` e `glue:GetSchemaVersion`) per il ruolo di esecuzione di una funzione.
Accesso al Confluent Schema Registry negato
**Messaggio di errore**: `Cannot access Confluent Schema with the provided access configuration.`
**Risoluzione:** verifica che le credenziali di autenticazione (archiviate in Secrets Manager) siano corrette e dispongano delle autorizzazioni necessarie per accedere al registro dello schema.
Registro degli schemi tra account AWS Glue
**Messaggio di errore**: `Cross-account Glue Schema Registry ARN not supported.`
**Risoluzione:** utilizza un registro AWS Glue degli schemi che si trova nello stesso AWS account della funzione Lambda.
Registro degli schemi tra regioni AWS Glue
**Messaggio di errore**: `Cross-region Glue Schema Registry ARN not supported.`
**Risoluzione:** utilizza un registro AWS Glue degli schemi che si trova nella stessa area della funzione Lambda.
Problemi di accesso segreto
**Messaggio di errore**: `Lambda received InvalidRequestException from Secrets Manager.`
**Risoluzione:** verifica che il ruolo di esecuzione della funzione disponga dell'autorizzazione ad accedere al segreto e che il segreto non sia crittografato con una AWS KMS chiave predefinita se accedi da un account diverso.
### Errori di connessione
Questi errori si verificano quando Lambda non riesce a stabilire una connessione al registro dello schema.
Problemi di connettività VPC
**Messaggio di errore**: `Cannot connect to your Schema Registry. Your Kafka cluster's VPC must be able to connect to the schema registry. You can provide access by configuring AWS PrivateLink or a NAT Gateway or VPC Peering between Kafka Cluster VPC and the schema registry VPC.`
**Risoluzione:** configura la rete VPC per consentire le connessioni al registro dello schema utilizzando AWS PrivateLink un gateway NAT o un peering VPC.
Errore di handshake TLS
**Messaggio di errore**: `Unable to establish TLS handshake with the schema registry. Please provide correct CA-certificate or client certificate using Secrets Manager to access your schema registry.`
**Risoluzione:** verifica che i certificati CA e i certificati client (per MTL) siano corretti e configurati correttamente in Secrets Manager.
Throttling
**Messaggio di errore**: `Receiving throttling errors when accessing the schema registry. Please increase API TPS limits for your schema registry.`
**Risoluzione:** aumenta i limiti di velocità delle API per il registro degli schemi o riduci la frequenza delle richieste provenienti dall'applicazione.
Errori del registro dello schema autogestiti
**Messaggio di errore**: `Lambda received an internal server an unexpected error from the provided self-managed schema registry.`
**Risoluzione:** verifica lo stato e la configurazione del server del registro degli schemi autogestito.
# Elaborazione a bassa latenza per sorgenti di eventi Kafka
AWS Lambda supporta nativamente l'elaborazione di eventi a bassa latenza per applicazioni che richiedono latenze costanti inferiori a 100 millisecondi. end-to-end Questa pagina fornisce dettagli di configurazione e consigli per abilitare flussi di lavoro a bassa latenza.
## Abilita l'elaborazione a bassa latenza
Per abilitare l'elaborazione a bassa latenza su una mappatura della sorgente di eventi Kafka, è richiesta la seguente configurazione di base:
+ Abilita la modalità provisioning. Per ulteriori informazioni, consulta [Modalità provisioning](kafka-scaling-modes.md#kafka-provisioned-mode).
+ Imposta il `MaximumBatchingWindowInSeconds` parametro della mappatura della sorgente degli eventi su 0. Per ulteriori informazioni, consulta [Comportamento di batching](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching).
## Ottimizzazione del tuo Kafka ESM a bassa latenza
Considerate i seguenti consigli per ottimizzare la mappatura delle sorgenti di eventi Kafka per una bassa latenza:
### Configurazione della modalità provisioned
**Nella modalità provisioning per la mappatura delle sorgenti degli eventi Kafka, Lambda consente di ottimizzare la velocità effettiva della mappatura delle sorgenti degli eventi configurando un numero minimo e massimo di risorse chiamate event poller.** Un event poller (o **poller) rappresenta una** risorsa di calcolo che è alla base di una mappatura delle sorgenti di eventi nella modalità provisioning e alloca fino a 5 velocità effettiva. MB/s Ogni event poller supporta fino a 5 chiamate Lambda simultanee.
Per determinare la configurazione ottimale del poller per la vostra applicazione, tenete conto della velocità di ingestione massima e dei requisiti di elaborazione. Diamo un'occhiata a un esempio semplificato:
Con un batch di 20 record e una durata media della funzione target di 50 ms, ogni poller può gestire 2.000 record al secondo entro un limite di 5. MB/s Viene calcolato come: (20 record × 1000 ms/50 ms) × 5 chiamate Lambda simultanee. Pertanto, se la velocità di ingestione massima desiderata è di 20.000 record al secondo, sono necessari almeno 10 event poller.
**Nota**
Si consiglia di fornire sondaggi di eventi aggiuntivi come buffer per evitare di operare costantemente alla massima capacità.
La modalità Provisioned ridimensiona automaticamente i poller degli eventi in base ai modelli di traffico all'interno di poller di **eventi** minimi e massimi configurati, che possono attivare il ribilanciamento e quindi introdurre una latenza aggiuntiva. **È possibile disabilitare l'auto-scaling configurando lo stesso valore per il poller di eventi minimo e massimo.**
### Ulteriori considerazioni
Alcune delle considerazioni aggiuntive includono:
+ L'avvio a freddo dall'invocazione della funzione target Lambda può potenzialmente aumentare la latenza. end-to-end Per ridurre questo rischio, prendi in considerazione la possibilità di abilitare la [concorrenza fornita o [SnapStart](snapstart.md)la](provisioned-concurrency.md) funzione di destinazione della mappatura dell'origine degli eventi. Inoltre, ottimizza l'allocazione della memoria della funzione per garantire esecuzioni coerenti e ottimali.
+ Quando `MaximumBatchingWindowInSeconds` è impostato su 0, Lambda elaborerà immediatamente tutti i record disponibili senza attendere di riempire la dimensione completa del batch. Ad esempio, se la dimensione del batch è impostata su 1.000 record ma sono disponibili solo 100 record, Lambda elaborerà tali 100 record immediatamente anziché attendere che si accumulino tutti i 1.000 record.
**Importante**
La configurazione ottimale per l'elaborazione a bassa latenza varia in modo significativo in base al carico di lavoro specifico. Ti consigliamo vivamente di testare diverse configurazioni con il tuo carico di lavoro effettivo per determinare le impostazioni migliori per il tuo caso d'uso.
# Configurazione dei controlli di gestione degli errori per le sorgenti di eventi Kafka
Puoi configurare il modo in cui Lambda gestisce gli errori e i nuovi tentativi per le mappature delle sorgenti degli eventi Kafka. Queste configurazioni consentono di controllare il modo in cui Lambda elabora i record non riusciti e gestisce il comportamento dei tentativi.
## Configurazioni di nuovi tentativi disponibili
Le seguenti configurazioni di riprova sono disponibili sia per Amazon MSK che per le sorgenti di eventi Kafka autogestite:
+ Numero **massimo di tentativi**: il numero massimo di tentativi Lambda quando la funzione restituisce un errore. Questo non conta il tentativo di invocazione iniziale. L'impostazione predefinita è -1 (infinito). Quando configuri sia tentativi infiniti che una [destinazione in caso di errore](kafka-on-failure-destination.md), Lambda applica automaticamente un massimo di 10 tentativi.
+ **Età massima di registrazione**: l'età massima di un record che Lambda invia alla tua funzione. L'impostazione predefinita è -1 (infinito).
+ **Suddividi il batch in caso di errore**: quando la funzione restituisce un errore, dividi il batch in due batch più piccoli e riprova ciascuno separatamente. Questo aiuta a isolare i record problematici.
+ **Risposta batch parziale**: consenti alla funzione di restituire informazioni sui record di un batch che non è riuscita a elaborare, in modo che Lambda possa riprovare solo i record non riusciti.
## Configurazione dei controlli di gestione degli errori (console)
Puoi configurare il comportamento dei tentativi durante la creazione o l'aggiornamento di una mappatura della sorgente degli eventi Kafka nella console Lambda.
**Per configurare il comportamento di ripetizione dei tentativi per una sorgente di eventi Kafka (console)**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegliete il nome della funzione.
1. Esegui una delle seguenti operazioni:
+ Per aggiungere un nuovo trigger Kafka, in **Panoramica delle funzioni**, scegli **Aggiungi** trigger.
+ **Per modificare un trigger Kafka esistente, scegli il trigger, quindi scegli Modifica.**
1. In **Event poller configuration**, seleziona la modalità provisioned per configurare i controlli di gestione degli errori:
1. Per **Riprovare, inserisci il numero massimo di tentativi** (0-10000 o -1 per un numero infinito).
1. Per Durata **massima di registrazione, inserisci l'età** massima in secondi (60-604800 o -1 per infinito).
1. **Per abilitare la suddivisione in batch quando si verificano errori, seleziona Dividi batch in caso di errore.**
1. Per abilitare la risposta parziale in batch, selezionare **ReportBatchItemFailures**.
1. Scegli **Aggiungi** o **Salva**.
## Configurazione del comportamento dei tentativi ()AWS CLI
Utilizzate i seguenti AWS CLI comandi per configurare il comportamento dei tentativi di ripetizione per le mappature delle sorgenti degli eventi Kafka.
### Creazione di una mappatura delle sorgenti degli eventi con configurazioni di nuovo tentativo
L'esempio seguente crea una mappatura delle sorgenti degli eventi Kafka autogestita con controlli di gestione degli errori:
```
aws lambda create-event-source-mapping \
--function-name my-kafka-function \
--topics my-kafka-topic \
--source-access-configuration Type=SASL_SCRAM_512_AUTH,URI=arn:aws:secretsmanager:us-east-1:111122223333:secret:MyBrokerSecretName \
--self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc.xyz.com:9092"]}}' \
--starting-position LATEST \
--provisioned-poller-config MinimumPollers=1,MaximumPollers=1 \
--maximum-retry-attempts 3 \
--maximum-record-age-in-seconds 3600 \
--bisect-batch-on-function-error \
--function-response-types "ReportBatchItemFailures"
```
Per le fonti di eventi Amazon MSK:
```
aws lambda create-event-source-mapping \
--event-source-arn arn:aws:kafka:us-east-1:111122223333:cluster/my-cluster/fc2f5bdf-fd1b-45ad-85dd-15b4a5a6247e-2 \
--topics AWSMSKKafkaTopic \
--starting-position LATEST \
--function-name my-kafka-function \
--source-access-configurations '[{"Type": "SASL_SCRAM_512_AUTH","URI": "arn:aws:secretsmanager:us-east-1:111122223333:secret:my-secret"}]' \
--provisioned-poller-config MinimumPollers=1,MaximumPollers=1 \
--maximum-retry-attempts 3 \
--maximum-record-age-in-seconds 3600 \
--bisect-batch-on-function-error \
--function-response-types "ReportBatchItemFailures"
```
### Aggiornamento delle configurazioni dei tentativi
Usa il `update-event-source-mapping` comando per modificare le configurazioni dei tentativi per una mappatura dell'origine degli eventi esistente:
```
aws lambda update-event-source-mapping \
--uuid 12345678-1234-1234-1234-123456789012 \
--maximum-retry-attempts 5 \
--maximum-record-age-in-seconds 7200 \
--bisect-batch-on-function-error \
--function-response-types "ReportBatchItemFailures"
```
## PartialBatchResponse
La risposta parziale in batch, nota anche come ReportBatchItemFailures, è una funzionalità chiave per la gestione degli errori nell'integrazione di Lambda con i sorgenti Kafka. Senza questa funzionalità, quando si verifica un errore in uno degli elementi di un batch, comporta la rielaborazione di tutti i messaggi in quel batch. Con la risposta batch parziale abilitata e implementata, il gestore restituisce gli identificatori solo per i messaggi non riusciti, permettendo a Lambda di riprovare solo quegli elementi specifici. Ciò fornisce un maggiore controllo sul modo in cui vengono elaborati i batch contenenti messaggi non riusciti.
Per segnalare gli errori dei batch, utilizzerai questo schema JSON:
```
{
"batchItemFailures": [
{
"itemIdentifier": {
"partition": "topic-partition_number",
"offset": 100
}
},
...
]
}
```
**Importante**
Se restituisci un codice JSON o null valido vuoto, la mappatura dell'origine dell'evento considererà un batch come elaborato correttamente. Qualsiasi topic-partition\$1number o offset non valido restituito che non era presente nell'evento richiamato verrà considerato un errore e l'intero batch verrà riprovato.
I seguenti esempi di codice mostrano come implementare una risposta batch parziale per le funzioni Lambda che ricevono eventi da sorgenti Kafka. La funzione riporta gli errori degli elementi batch nella risposta, segnalando a Lambda di riprovare tali messaggi in un secondo momento.
Ecco un'implementazione del gestore Python Lambda che mostra questo approccio:
```
import base64
from typing import Any, Dict, List
def lambda_handler(event: Dict[str, Any], context: Any) -> Dict[str, List[Dict[str, Dict[str, Any]]]]:
failures: List[Dict[str, Dict[str, Any]]] = []
records_dict = event.get("records", {})
for topic_partition, records_list in records_dict.items():
for record in records_list:
topic = record.get("topic")
partition = record.get("partition")
offset = record.get("offset")
value_b64 = record.get("value")
try:
data = base64.b64decode(value_b64).decode("utf-8")
process_message(data)
except Exception as exc:
print(f"Failed to process record topic={topic} partition={partition} offset={offset}: {exc}")
item_identifier: Dict[str, Any] = {
"partition": f"{topic}-{partition}",
"offset": int(offset) if offset is not None else None,
}
failures.append({"itemIdentifier": item_identifier})
return {"batchItemFailures": failures}
def process_message(data: str) -> None:
# Your business logic for a single message
pass
```
Ecco una versione di Node.js:
```
const { Buffer } = require("buffer");
const handler = async (event) => {
const failures = [];
for (let topicPartition in event.records) {
const records = event.records[topicPartition];
for (const record of records) {
const topic = record.topic;
const partition = record.partition;
const offset = record.offset;
const valueBase64 = record.value;
const data = Buffer.from(valueBase64, "base64").toString("utf8");
try {
await processMessage(data);
} catch (error) {
console.error("Failed to process record", { topic, partition, offset, error });
const itemIdentifier = {
"partition": `${topic}-${partition}`,
"offset": Number(offset),
};
failures.push({ itemIdentifier });
}
}
}
return { batchItemFailures: failures };
};
async function processMessage(payload) {
// Your business logic for a single message
}
module.exports = { handler };
```
# Acquisizione di batch scartati per un'origine eventi di Amazon MSK e Apache Kafka autogestito
Per mantenere i record delle chiamate non riuscite allo strumento di mappatura dell'origine degli eventi, aggiungi una destinazione allo strumento di mappatura dell'origine degli eventi della funzione. Ogni record inviato alla destinazione è un documento JSON contenente i metadati relativi alla chiamata non riuscita. Per le destinazioni Amazon S3, Lambda invia insieme ai metadati anche l'intero record di invocazione. Puoi configurare qualsiasi argomento Amazon SNS, coda Amazon SQS, bucket Amazon S3 o Kafka come destinazione.
Con le destinazioni Amazon S3, puoi utilizzare la funzionalità [Notifiche eventi Amazon S3](https://docs.aws.amazon.com/) per ricevere notifiche quando gli oggetti vengono caricati nel bucket S3 di destinazione. Puoi anche configurare Notifiche eventi S3 per richiamare un'altra funzione Lambda per eseguire l'elaborazione automatica su batch non riusciti.
Il tuo ruolo di esecuzione deve avere le autorizzazioni per la destinazione:
+ **[Per una destinazione SQS: sqs: SendMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)**
+ **[Per una destinazione SNS: sns:publish](https://docs.aws.amazon.com/sns/latest/api/API_Publish.html)**
+ **[Per una destinazione S3: s3: e [s3](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html): PutObject ListBucket](https://docs.aws.amazon.com/AmazonS3/latest/API/ListObjectsV2.html)**
+ **[Per una destinazione Kafka: kafka-cluster: WriteData](https://docs.aws.amazon.com/msk/latest/developerguide/kafka-actions.html)**
È possibile configurare un argomento di Kafka come destinazione in caso di errore per le mappature delle sorgenti degli eventi Kafka. Quando Lambda non è in grado di elaborare i record dopo estenuanti tentativi o quando i record superano l'età massima, Lambda invia i record non riusciti all'argomento Kafka specificato per un'elaborazione successiva. Fai riferimento a [Usare un argomento di Kafka come destinazione in caso di errore](kafka-on-failure-destination.md).
È necessario implementare un endpoint VPC per il servizio di destinazione in caso di errore all'interno del VPC del cluster Kafka.
Inoltre, se hai configurato una chiave KMS sulla destinazione, Lambda necessita delle seguenti autorizzazioni, a seconda del tipo di destinazione:
+ [Se hai abilitato la crittografia con la tua chiave KMS per una destinazione S3, è richiesto kms:. GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) Se la chiave KMS e la destinazione del bucket S3 si trovano in un account diverso dalla funzione Lambda e dal ruolo di esecuzione, configura la chiave KMS in modo che consideri attendibile il ruolo di esecuzione da consentire. kms: GenerateDataKey
+ [https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) [https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html)
+ [https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) [https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html)
## Configurazione delle destinazioni in caso di errore per una mappatura della sorgente degli eventi Kafka
Per configurare una destinazione in caso di errore tramite la console, completa i seguenti passaggi:
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegliere una funzione.
1. In **Function overview (Panoramica delle funzioni)**, scegliere **Add destination (Aggiungi destinazione)**.
1. Per **Origine**, scegli **Chiamata allo strumento di mappatura dell'origine degli eventi**.
1. Per **Strumento di mappatura dell'origine degli eventi**, scegli un'origine dell'evento configurata per questa funzione.
1. Per **Condizione**, seleziona **In caso di errore**. Per le chiamate allo strumento di mappatura dell'origine degli eventi, questa è l'unica condizione accettata.
1. Per **Tipo di destinazione**, scegli il tipo di destinazione a cui Lambda deve inviare i record di chiamata.
1. Per **Destination (Destinazione)**, scegliere una risorsa.
1. Scegli **Save** (Salva).
È inoltre possibile configurare una destinazione in errore utilizzando la AWS CLI. Ad esempio, il [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html)comando seguente aggiunge una mappatura dell'origine degli eventi con una destinazione SQS in caso di errore a: `MyFunction`
```
aws lambda create-event-source-mapping \
--function-name "MyFunction" \
--event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/vpc-2priv-2pub/751d2973-a626-431c-9d4e-d7975eb44dd7-2 \
--destination-config '{"OnFailure": {"Destination": "arn:aws:sqs:us-east-1:123456789012:dest-queue"}}'
```
Il [update-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-event-source-mapping.html)comando seguente aggiunge una destinazione S3 in caso di errore all'origine dell'evento associata all'input: `uuid`
```
aws lambda update-event-source-mapping \
--uuid f89f8514-cdd9-4602-9e1f-01a5b77d449b \
--destination-config '{"OnFailure": {"Destination": "arn:aws:s3:::dest-bucket"}}'
```
Per rimuovere una destinazione, fornisci una stringa vuota come argomento del parametro `destination-config`:
```
aws lambda update-event-source-mapping \
--uuid f89f8514-cdd9-4602-9e1f-01a5b77d449b \
--destination-config '{"OnFailure": {"Destination": ""}}'
```
### Best practice di sicurezza per destinazioni Amazon S3
L'eliminazione di un bucket S3 configurato come destinazione senza rimuovere la destinazione dalla configurazione della funzione può creare un rischio per la sicurezza. Se un altro utente conosce il nome del bucket di destinazione, può ricreare il bucket nel proprio Account AWS. I record delle invocazioni non riuscite verranno inviati al relativo bucket, esponendo potenzialmente i dati della tua funzione.
**avvertimento**
Per garantire che i record di invocazione della tua funzione non possano essere inviati a un bucket S3 in un altro Account AWS, aggiungi una condizione al ruolo di esecuzione della funzione che limiti le `s3:PutObject` autorizzazioni ai bucket del tuo account.
Di seguito viene illustrato un esempio di policy IAM che limita le autorizzazioni `s3:PutObject` della funzione ai bucket presenti nell'account. Questa policy fornisce inoltre a Lambda l'autorizzazione `s3:ListBucket` necessaria per utilizzare un bucket S3 come destinazione.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "S3BucketResourceAccountWrite",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::*/*",
"arn:aws:s3:::*"
],
"Condition": {
"StringEquals": {
"s3:ResourceAccount": "111122223333"
}
}
}
]
}
```
Per aggiungere una politica di autorizzazioni al ruolo di esecuzione della tua funzione utilizzando Console di gestione AWS o AWS CLI, consulta le istruzioni nelle seguenti procedure:
------
#### [ Console ]
**Per aggiungere una policy di autorizzazioni al ruolo di esecuzione di una funzione (console)**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Seleziona la funzione Lambda di cui si desidera modificare il ruolo di esecuzione.
1. Nella scheda **Configurazione** scegli **Autorizzazioni**.
1. Nella scheda **Ruolo di esecuzione**, seleziona il **nome del ruolo** della funzione per aprire la pagina della console IAM del ruolo.
1. Aggiungi una policy di autorizzazioni di base al ruolo completando le seguenti operazioni:
1. Nel riquadro **Policy di autorizzazioni**, scegli **Aggiungi autorizzazioni**, poi **Crea policy in linea**.
1. Nell'**editor delle policy**, seleziona **JSON**.
1. Incolla la policy che desideri aggiungere nell'editor (sostituendo il codice JSON esistente), quindi scegli **Avanti**.
1. In **Dettagli della policy**, specifica un **nome per la policy**.
1. Scegli **Crea policy**.
------
#### [ AWS CLI ]
**Per aggiungere una policy di autorizzazioni al ruolo di esecuzione di una funzione (CLI)**
1. Crea un documento di policy JSON con le autorizzazioni richieste e salvalo in una directory locale.
1. Utilizza il comando della CLI `put-role-policy` di IAM per aggiungere le autorizzazioni per il ruolo di esecuzione di una funzione. Esegui il comando seguente dalla directory in cui hai salvato il documento di policy JSON e sostituisci il nome del ruolo, il nome della policy e il documento di policy con i tuoi valori.
```
aws iam put-role-policy \
--role-name my_lambda_role \
--policy-name LambdaS3DestinationPolicy \
--policy-document file://my_policy.json
```
------
### Record di invocazione SNS e SQS di esempio
L'esempio seguente mostra il contenuto che Lambda invia a un argomento SNS o una coda SQS di destinazione per una chiamata non riuscita all'origine dell'evento Kafka. Ciascuna delle chiavi in `recordsInfo` contiene sia l'argomento sia lo shard di Kafka, separati da un trattino. Ad esempio, per la chiave `"Topic-0"`, `Topic` è l'argomento di Kafka e `0` è lo shard. Per ogni argomento e partizione, è possibile utilizzare i dati di offset e timestamp per individuare i record di chiamata originali.
```
{
"requestContext": {
"requestId": "316aa6d0-8154-xmpl-9af7-85d5f4a6bc81",
"functionArn": "arn:aws:lambda:us-east-1:123456789012:function:myfunction",
"condition": "RetryAttemptsExhausted" | "MaximumPayloadSizeExceeded",
"approximateInvokeCount": 1
},
"responseContext": { // null if record is MaximumPayloadSizeExceeded
"statusCode": 200,
"executedVersion": "$LATEST",
"functionError": "Unhandled"
},
"version": "1.0",
"timestamp": "2019-11-14T00:38:06.021Z",
"KafkaBatchInfo": {
"batchSize": 500,
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/vpc-2priv-2pub/751d2973-a626-431c-9d4e-d7975eb44dd7-2",
"bootstrapServers": "...",
"payloadSize": 2039086, // In bytes
"recordsInfo": {
"Topic-0": {
"firstRecordOffset": "49601189658422359378836298521827638475320189012309704722",
"lastRecordOffset": "49601189658422359378836298522902373528957594348623495186",
"firstRecordTimestamp": "2019-11-14T00:38:04.835Z",
"lastRecordTimestamp": "2019-11-14T00:38:05.580Z",
},
"Topic-1": {
"firstRecordOffset": "49601189658422359378836298521827638475320189012309704722",
"lastRecordOffset": "49601189658422359378836298522902373528957594348623495186",
"firstRecordTimestamp": "2019-11-14T00:38:04.835Z",
"lastRecordTimestamp": "2019-11-14T00:38:05.580Z",
}
}
}
}
```
### Record di invocazione di esempio di destinazione S3
Se le destinazioni sono S3, Lambda invia alla destinazione l'intero record di chiamata insieme ai metadati. L'esempio seguente mostra ciò che Lambda invia a un bucket S3 di destinazione per una chiamata non riuscita all'origine dell'evento Kafka. Oltre a tutti i campi dell'esempio precedente per le destinazioni SQS e SNS, il campo `payload` contiene il record di chiamata originale come stringa JSON con escape.
```
{
"requestContext": {
"requestId": "316aa6d0-8154-xmpl-9af7-85d5f4a6bc81",
"functionArn": "arn:aws:lambda:us-east-1:123456789012:function:myfunction",
"condition": "RetryAttemptsExhausted" | "MaximumPayloadSizeExceeded",
"approximateInvokeCount": 1
},
"responseContext": { // null if record is MaximumPayloadSizeExceeded
"statusCode": 200,
"executedVersion": "$LATEST",
"functionError": "Unhandled"
},
"version": "1.0",
"timestamp": "2019-11-14T00:38:06.021Z",
"KafkaBatchInfo": {
"batchSize": 500,
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/vpc-2priv-2pub/751d2973-a626-431c-9d4e-d7975eb44dd7-2",
"bootstrapServers": "...",
"payloadSize": 2039086, // In bytes
"recordsInfo": {
"Topic-0": {
"firstRecordOffset": "49601189658422359378836298521827638475320189012309704722",
"lastRecordOffset": "49601189658422359378836298522902373528957594348623495186",
"firstRecordTimestamp": "2019-11-14T00:38:04.835Z",
"lastRecordTimestamp": "2019-11-14T00:38:05.580Z",
},
"Topic-1": {
"firstRecordOffset": "49601189658422359378836298521827638475320189012309704722",
"lastRecordOffset": "49601189658422359378836298522902373528957594348623495186",
"firstRecordTimestamp": "2019-11-14T00:38:04.835Z",
"lastRecordTimestamp": "2019-11-14T00:38:05.580Z",
}
}
},
"payload": "" // Only available in S3
}
```
**Suggerimento**
Ti consigliamo di abilitare il controllo delle versioni S3 sul bucket di destinazione.
# Usare un argomento di Kafka come destinazione in caso di errore
È possibile configurare un argomento di Kafka come destinazione in caso di errore per le mappature delle sorgenti degli eventi Kafka. Quando Lambda non è in grado di elaborare i record dopo estenuanti tentativi o quando i record superano l'età massima, Lambda invia i record non riusciti all'argomento Kafka specificato per un'elaborazione successiva. Quando configuri sia [tentativi infiniti](kafka-retry-configurations.md) che una destinazione in caso di errore, Lambda applica automaticamente un massimo di 10 tentativi.
## Come funziona una destinazione Kafka in caso di errore
Quando si configura un argomento di Kafka come destinazione in caso di errore, Lambda funge da produttore Kafka e scrive i record non riusciti nell'argomento di destinazione. Questo crea un pattern DLT (Dead Letter Topic) all'interno dell'infrastruttura Kafka.
+ **Stesso requisito del cluster**: l'argomento di destinazione deve esistere nello stesso cluster Kafka degli argomenti di origine.
+ **Contenuto effettivo dei record**: le destinazioni Kafka ricevono i record effettivamente non riusciti insieme ai metadati di errore.
+ **Prevenzione della ricorsione**: Lambda previene i loop infiniti bloccando le configurazioni in cui gli argomenti di origine e destinazione coincidono.
## Configurazione di una destinazione Kafka in caso di errore
È possibile configurare un argomento di Kafka come destinazione in caso di errore durante la creazione o l'aggiornamento di una mappatura dell'origine degli eventi Kafka.
### Configurazione di una destinazione Kafka (console)
**Configurare un argomento di Kafka come destinazione in caso di errore (console)**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegliete il nome della funzione.
1. Esegui una delle seguenti operazioni:
+ Per aggiungere un nuovo trigger Kafka, in **Panoramica delle funzioni**, scegli **Aggiungi** trigger.
+ **Per modificare un trigger Kafka esistente, scegli il trigger, quindi scegli Modifica.**
1. **In **Impostazioni aggiuntive**, per **Destinazione in caso di errore**, scegli l'argomento Kafka.**
1. Per **Nome argomento**, inserisci il nome dell'argomento Kafka a cui desideri inviare i record non riusciti.
1. **Scegli **Aggiungi o Salva**.**
### Configurazione di una destinazione Kafka ()AWS CLI
Utilizzate il `kafka://` prefisso per specificare un argomento di Kafka come destinazione in caso di errore.
#### Creazione di una mappatura della sorgente degli eventi con la destinazione Kafka
L'esempio seguente crea una mappatura dell'origine degli eventi Amazon MSK con un argomento Kafka come destinazione in caso di errore:
```
aws lambda create-event-source-mapping \
--function-name my-kafka-function \
--topics AWSKafkaTopic \
--event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/my-cluster/abc123 \
--starting-position LATEST \
--provisioned-poller-config MinimumPollers=1,MaximumPollers=3 \
--destination-config '{"OnFailure":{"Destination":"kafka://failed-records-topic"}}'
```
Per Kafka autogestito, usa la stessa sintassi:
```
aws lambda create-event-source-mapping \
--function-name my-kafka-function \
--topics AWSKafkaTopic \
--self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc.xyz.com:9092"]}}' \
--starting-position LATEST \
--provisioned-poller-config MinimumPollers=1,MaximumPollers=3 \
--destination-config '{"OnFailure":{"Destination":"kafka://failed-records-topic"}}'
```
#### Aggiornamento di una destinazione Kafka
Usa il `update-event-source-mapping` comando per aggiungere o modificare una destinazione Kafka:
```
aws lambda update-event-source-mapping \
--uuid 12345678-1234-1234-1234-123456789012 \
--destination-config '{"OnFailure":{"Destination":"kafka://failed-records-topic"}}'
```
## Formato di registrazione per una destinazione Kafka
Quando Lambda invia record non riusciti a un argomento di Kafka, ogni messaggio contiene sia metadati sull'errore che il contenuto effettivo del record.
### Metadati di errore
I metadati includono informazioni sul motivo per cui il record ha avuto esito negativo e dettagli sul batch originale:
```
{
"requestContext": {
"requestId": "e4b46cbf-b738-xmpl-8880-a18cdf61200e",
"functionArn": "arn:aws:lambda:us-east-1:123456789012:function:my-function:$LATEST",
"condition": "RetriesExhausted",
"approximateInvokeCount": 3
},
"responseContext": {
"statusCode": 200,
"executedVersion": "$LATEST",
"functionError": "Unhandled"
},
"version": "1.0",
"timestamp": "2019-11-14T18:16:05.568Z",
"KafkaBatchInfo": {
"batchSize": 1,
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/my-cluster/abc123",
"bootstrapServers": "b-1.mycluster.abc123.kafka.us-east-1.amazonaws.com:9098",
"payloadSize": 1162,
"recordInfo": {
"offset": "49601189658422359378836298521827638475320189012309704722",
"timestamp": "2019-11-14T18:16:04.835Z"
}
},
"payload": {
"bootstrapServers": "b-1.mycluster.abc123.kafka.us-east-1.amazonaws.com:9098",
"eventSource": "aws:kafka",
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/my-cluster/abc123",
"records": {
"my-topic-0": [
{
"headers": [],
"key": "dGVzdC1rZXk=",
"offset": 100,
"partition": 0,
"timestamp": 1749116692330,
"timestampType": "CREATE_TIME",
"topic": "my-topic",
"value": "dGVzdC12YWx1ZQ=="
}
]
}
}
}
```
### Comportamento delle chiavi di partizione
Lambda utilizza la stessa chiave di partizione del record originale per la produzione sull'argomento di destinazione. Se il record originale non aveva alcuna chiave, Lambda utilizza il partizionamento round-robin predefinito di Kafka su tutte le partizioni disponibili nell'argomento di destinazione.
## Requisiti e limitazioni
+ È **richiesta la modalità di provisioning**: una destinazione Kafka in caso di errore è disponibile solo per le mappature delle sorgenti degli eventi con la modalità provisioning abilitata.
+ **Solo stesso cluster**: l'argomento di destinazione deve esistere nello stesso cluster Kafka degli argomenti di origine.
+ **Autorizzazioni per gli argomenti**: la mappatura dei sorgenti degli eventi deve disporre delle autorizzazioni di scrittura sull'argomento di destinazione. Esempio:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ClusterPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:DescribeCluster",
"kafka-cluster:DescribeTopic",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:*:*:cluster/*"
]
},
{
"Sid": "TopicPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:DescribeTopic",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:*:*:topic/*/*"
]
},
{
"Effect": "Allow",
"Action": [
"kafka:DescribeCluster",
"kafka:GetBootstrapBrokers",
"kafka:Produce"
],
"Resource": "arn:aws:kafka:*:*:cluster/*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DeleteNetworkInterface",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups"
],
"Resource": "*"
}
]
}
```
+ **Nessuna ricorsione**: il nome dell'argomento di destinazione non può essere lo stesso dei nomi degli argomenti di origine.
# Registrazione della mappatura delle sorgenti degli eventi Kafka
Puoi configurare la registrazione a livello di sistema per le mappature delle sorgenti degli eventi Kafka per abilitare e filtrare i log di sistema a cui vengono inviati i poller di eventi Lambda. CloudWatch
[Questa funzionalità è disponibile solo per le mappature delle sorgenti degli eventi Kafka e con la modalità Provisioned.](https://docs.aws.amazon.com/lambda/latest/dg/kafka-scaling-modes.html#kafka-provisioned-mode)
****Per la mappatura delle sorgenti degli eventi con logging config, puoi anche controllare i log di sistema dalle query di registro predefinite nella scheda **Monitor** dalla pagina Console **Lambda** > Risorse aggiuntive > mappature delle sorgenti degli eventi ora.****
## Come funziona la registrazione
Quando imposti la configurazione di registrazione con il livello di log nella mappatura dell'origine degli eventi, il poller di eventi Lambda invia i log corrispondenti (log del sistema di mappatura dell'origine degli eventi).
La mappatura delle sorgenti degli eventi riutilizza la stessa [destinazione di log](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-logs.html#configuring-log-destinations) con la funzione Lambda. Assicurati che il ruolo di esecuzione della tua funzione Lambda disponga delle autorizzazioni di registrazione necessarie.
La mappatura delle sorgenti degli eventi avrà un proprio flusso di log, con data e origine degli eventi che mappano l'UUID come nome del flusso di registro, ad esempio. `2020/01/01/12345678-1234-1234-1234-12345678901`
Per i registri di sistema di mappatura delle sorgenti degli eventi, puoi scegliere tra i seguenti livelli di registro.
| Livello di log | Utilizzo |
| --- | --- |
| DEBUG (dettaglio massimo) | Informazioni dettagliate sull'avanzamento dell'elaborazione delle fonti degli eventi |
| INFO | Messaggi sul normale funzionamento della mappatura delle sorgenti degli eventi |
| WARN (dettaglio minimo) | Messaggi relativi a potenziali avvisi ed errori che possono portare a comportamenti imprevisti |
Quando si seleziona un livello di registro, Lambda event poller invia i log a quel livello e a un livello inferiore. Ad esempio, se imposti il livello di registro del sistema di mappatura delle sorgenti degli eventi su INFO, event poller non invia output di log a livello DEBUG.
## Configurazione della registrazione
È possibile impostare la configurazione di registrazione durante la creazione o l'aggiornamento di una mappatura della sorgente degli eventi Kafka.
### Configurazione della registrazione (console)
**Per configurare la registrazione (console)**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegli il nome della tua funzione.
1. Esegui una delle seguenti operazioni:
+ Per aggiungere un nuovo trigger Kafka, in **Panoramica delle funzioni**, scegli **Aggiungi** trigger.
+ **Per modificare un trigger Kafka esistente, scegli il trigger, quindi scegli Modifica.**
1. **In **Event poller configuration**, per la **modalità Provisioned**, abilita la casella di controllo Configure.** E verrà visualizzata l'impostazione **del livello di registro**.
1. Fai clic sull'elenco **a discesa del livello di registro** e seleziona un livello per la mappatura della fonte dell'evento.
1. Scegli **Aggiungi** o **Salva** in basso per creare o aggiornare la mappatura della fonte dell'evento.
### Configurazione della registrazione ()AWS CLI
#### Creazione di una mappatura della sorgente degli eventi con registrazione
L'esempio seguente crea una mappatura dell'origine degli eventi Amazon MSK con configurazione di registrazione:
```
aws lambda create-event-source-mapping \
--function-name my-kafka-function \
--topics AWSKafkaTopic \
--event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/my-cluster/abc123 \
--starting-position LATEST \
--provisioned-poller-config MinimumPollers=1,MaximumPollers=3 \
--logging-config '{"SystemLogLevel":"DEBUG"}'
```
Per Kafka autogestito, usa la stessa sintassi:
```
aws lambda create-event-source-mapping \
--function-name my-kafka-function \
--topics AWSKafkaTopic \
--self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc.xyz.com:9092"]}}' \
--starting-position LATEST \
--provisioned-poller-config MinimumPollers=1,MaximumPollers=3 \
--logging-config '{"SystemLogLevel":"DEBUG"}'
```
#### Aggiornamento della configurazione di registrazione
Usa il `update-event-source-mapping` comando per aggiungere o modificare la configurazione di registrazione:
```
aws lambda update-event-source-mapping \
--uuid 12345678-1234-1234-1234-123456789012 \
--logging-config '{"SystemLogLevel":"WARN"}'
```
## Formato di registrazione per un registro del sistema di mappatura delle sorgenti di eventi Kafka
Quando Lambda event poller invia il registro, ogni voce di registro contiene metadati generali di mappatura dell'origine degli eventi e anche contenuti specifici dell'evento.
### Record di registro WARN
Il record WARN contiene errori o avvisi provenienti dal poller degli eventi e viene emesso quando si è verificato l'evento. Esempio:
```
{
"eventType": "ESM_PROCESSING_EVENT",
"timestamp": 1546347650000,
"resourceArn": "arn:aws:lambda:us-east-1:123456789012:event-source-mapping:12345678-1234-1234-1234-123456789012",
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/tests-cluster/87654321-4321-4321-4321-876543221-s1",
"eventProcessorId": "12345678-1234-1234-1234-123456789012/0",
"logLevel": "WARN",
"error": {
"errorMessage": "Timeout expired while fetching topic metadata",
"errorCode": "org.apache.kafka.common.errors.TimeoutException"
}
}
```
### Record di registro INFO
Il record INFO contiene le configurazioni del client consumer Kafka in ogni sondaggio di eventi e viene emesso nel caso in cui un consumatore venga creato o modificato. Esempio:
```
{
"eventType": "POLLER_STATUS_EVENT",
"timestamp": 1546347660000,
"resourceArn": "arn:aws:lambda:us-east-1:123456789012:event-source-mapping:12345678-1234-1234-1234-123456789012",
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/tests-cluster/87654321-4321-4321-4321-876543221-s1",
"eventProcessorId": "12345678-1234-1234-1234-123456789012/0",
"logLevel": "INFO",
"kafkaEventSourceConnection": {
"brokerEndpoints": "boot-abcd1234.c2.kafka-serverless.us-east-1.amazonaws.com:9098",
"consumerId": "12345678-1234-1234-1234-123456789012-0",
"topics": [
"test"
],
"consumerGroupId": "12345678-1234-1234-1234-123456789012",
"securityProtocol": "SASL_SSL",
"saslMechanism": "AWS_MSK_IAM",
"totalPartitionCount": 2,
"assignedPartitionCount": 2,
"partitionsAssignmentGeneration": 5,
"assignedPartitions": [
"test-0",
"test-1"
],
"networkConfig": {
"ipAddresses": [
"10.100.141.1"
],
"subnetCidrBlock": "10.100.128.0/20",
"securityGroups": [
"sg-abcdefabcdefabcdef"
]
}
}
}
```
### Record di registro DEBUG
Il registro DEBUG contiene le informazioni relative agli offset di Kafka nell'elaborazione della mappatura della sorgente degli eventi e le informazioni sull'offset vengono emesse al minuto. Esempio:
```
{
"eventType": "KAFKA_STATUS_EVENT",
"timestamp": 1546347670000,
"resourceArn": "arn:aws:lambda:us-east-1:123456789012:event-source-mapping:12345678-1234-1234-1234-123456789012",
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/tests-cluster/87654321-4321-4321-4321-876543221-s1",
"eventProcessorId": "12345678-1234-1234-1234-123456789012/0",
"logLevel": "DEBUG",
"kafkaPartitionOffsets": {
"partition": "test-1",
"endOffset": 5004,
"consumedOffset": 5003,
"processedOffset": 5003,
"committedOffset": 5004
}
}
```
# Risoluzione degli errori di mappatura delle sorgenti degli eventi Kafka
Negli argomenti seguenti vengono forniti suggerimenti per la risoluzione dei problemi relativi a errori e problemi che potrebbero verificarsi durante l'utilizzo di Amazon MSK o Apache Kafka autogestito con Lambda.
Per ulteriori informazioni sulla risoluzione dei problemi, visita il [Knowledge Center AWS](https://repost.aws/knowledge-center#AWS_Lambda).
## Errori di autenticazione e autorizzazione
Se manca una delle autorizzazioni necessarie per consumare i dati dal cluster Kafka, Lambda visualizza uno dei seguenti messaggi di errore nella mappatura delle sorgenti degli eventi sotto. **LastProcessingResult**
**Topics**
+ [
### Il cluster non è riuscito ad autorizzare Lambda
](#kafka-authorize-errors)
+ [
### Autenticazione SASL non riuscita
](#kafka-sasl-errors)
+ [
### Il server non è riuscito ad autenticare Lambda
](#kafka-mtls-errors-server)
+ [
### Lambda non è riuscita ad autenticare il server
](#kafka-mtls-errors-lambda)
+ [
### Il certificato o la chiave privata forniti non sono validi
](#kafka-key-errors)
### Il cluster non è riuscito ad autorizzare Lambda
Per i SASL/SCRAM nostri MTL, questo errore indica che l'utente fornito non dispone di tutte le seguenti autorizzazioni necessarie per la lista di controllo degli accessi Kafka (ACL):
+ DescribeConfigs Cluster
+ Descrivi il gruppo
+ Leggi il gruppo
+ Descrivi l'argomento
+ Leggi l'argomento
Quando crei Kafka ACLs con le `kafka-cluster` autorizzazioni richieste, specifica l'argomento e il gruppo come risorse. Il nome dell'argomento deve corrispondere all'argomento nella mappatura dell'origine eventi. Il nome del gruppo deve corrispondere all'UUID della mappatura dell'origine eventi.
Dopo avere aggiunto le autorizzazioni richieste al ruolo di esecuzione, potrebbero essere necessari alcuni minuti affinché le modifiche entrino in vigore.
Di seguito è riportato un esempio di registro ESM a livello di sistema dopo aver abilitato Logging [Config](esm-logging.md) per questo problema:
```
{
"eventType": "ESM_PROCESSING_EVENT",
"timestamp": 1734567890123,
"resourceArn": "arn:aws:lambda:us-east-1:123456789012:event-source-mapping:a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/my-kafka-cluster/12345678-abcd-1234-efgh-EXAMPLE11111-1",
"eventProcessorId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111/0",
"logLevel": "WARN",
"error": {
"errorMessage": "Not authorized to access topics: [my-topic]",
"errorCode": "org.apache.kafka.common.errors.TopicAuthorizationException"
}
}
```
### Autenticazione SASL non riuscita
Per SASL/SCRAM o SASL/PLAIN, questo errore indica che le credenziali di accesso fornite non sono valide.
Per il controllo degli accessi IAM, al ruolo di esecuzione manca l'`kafka-cluster:Connect`autorizzazione per il cluster. Aggiungi questa autorizzazione al ruolo e specifica l'Amazon Resource Name (ARN) del cluster come risorsa.
Potresti visualizzare questo errore in modo intermittente. Il cluster rifiuta le connessioni dopo che il numero di connessioni TCP supera la quota di servizio. Lambda cessa e ritenta finché una connessione non ha esito positivo. Dopo che Lambda si connette al cluster e ha eseguito il polling dei registri, l'ultimo risultato di elaborazione cambia in `OK`.
Di seguito è riportato un esempio di log ESM a livello di sistema dopo aver abilitato Logging [Config](esm-logging.md) per questo problema quando si utilizza l'autenticazione IAM:
```
{
"eventType": "ESM_PROCESSING_EVENT",
"timestamp": 1734567890456,
"resourceArn": "arn:aws:lambda:us-east-1:123456789012:event-source-mapping:a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/my-kafka-cluster/12345678-abcd-1234-efgh-EXAMPLE22222-1",
"eventProcessorId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222/0",
"logLevel": "WARN",
"error": {
"errorMessage": "[a1b2c3d4-5678-90ab-cdef-EXAMPLE22222]: Access denied",
"errorCode": "org.apache.kafka.common.errors.SaslAuthenticationException"
}
}
```
### Il server non è riuscito ad autenticare Lambda
Questo errore indica che il broker Kafka non è riuscito ad autenticare Lambda. Questo errore può verificarsi per uno dei seguenti motivi:
+ Non è stato fornito un certificato client per l'autenticazione mTLS.
+ È stato fornito un certificato client, ma i broker Kafka non sono configurati per l'utilizzo dell'autenticazione mTLS.
+ Un certificato client non è attendibile per i broker Kafka.
### Lambda non è riuscita ad autenticare il server
Questo errore indica che Lambda non è riuscita ad autenticare il broker Kafka. Questo errore può verificarsi per uno dei seguenti motivi:
+ Per Apache Kafka autogestito: i broker Kafka utilizzano certificati autofirmati o una CA privata, ma non hanno fornito il certificato CA root del server.
+ Per Apache Kafka autogestito: il certificato CA principale del server non corrisponde alla CA principale che ha firmato il certificato del broker.
+ La convalida del nome host non è riuscita perché il certificato del broker non contiene il nome DNS o l'indirizzo IP del broker come nome alternativo dell'oggetto.
### Il certificato o la chiave privata forniti non sono validi
Questo errore indica che il consumatore Kafka non ha potuto utilizzare il certificato o la chiave privata fornita. Assicurati che il certificato e la chiave utilizzino il formato PEM e che la crittografia a chiave privata utilizzi un algoritmo. PBES1
Di seguito è riportato un esempio di registro ESM a livello di sistema dopo aver abilitato Logging [Config](esm-logging.md) per questo problema:
```
{
"eventType": "ESM_PROCESSING_EVENT",
"timestamp": 1734567891234,
"resourceArn": "arn:aws:lambda:us-east-1:123456789012:event-source-mapping:a1b2c3d4-5678-90ab-cdef-EXAMPLE44444",
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/my-kafka-cluster/12345678-abcd-1234-efgh-EXAMPLE44444-1",
"eventProcessorId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE44444/0",
"logLevel": "WARN",
"error": {
"errorMessage": "Invalid PEM keystore configs",
"errorCode": "org.apache.kafka.common.errors.InvalidConfigurationException"
}
}
```
## Errori di rete e connettività
I problemi di configurazione della rete possono impedire a Lambda di connettersi al cluster Kafka. I seguenti argomenti descrivono gli errori più comuni relativi alla rete.
**Topics**
+ [
### Timeout di connessione dovuto alla configurazione del gruppo di sicurezza
](#kafka-security-group-errors)
+ [
### Gli endpoint del broker Kafka non possono essere risolti
](#kafka-cluster-deleted-errors)
### Timeout di connessione dovuto alla configurazione del gruppo di sicurezza
Se il gruppo di sicurezza associato al tuo cluster Kafka non consente il traffico in entrata da solo, Lambda non può connettersi al cluster. Assicurati che le regole in entrata del gruppo di sicurezza consentano il traffico proveniente dal gruppo di sicurezza stesso sulle porte del broker Kafka.
Di seguito è riportato un esempio di registro ESM a livello di sistema dopo aver abilitato Logging [Config](esm-logging.md) per questo problema:
```
{
"eventType": "ESM_PROCESSING_EVENT",
"timestamp": 1734567892345,
"resourceArn": "arn:aws:lambda:us-east-1:123456789012:event-source-mapping:a1b2c3d4-5678-90ab-cdef-EXAMPLE55555",
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/my-kafka-cluster/12345678-abcd-1234-efgh-EXAMPLE55555-1",
"eventProcessorId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE55555/0",
"logLevel": "WARN",
"error": {
"errorMessage": "Timeout expired while fetching topic metadata",
"errorCode": "org.apache.kafka.common.errors.TimeoutException"
}
}
```
È inoltre possibile controllare il registro Kafka Consumer INFO per verificare la connessione e la configurazione di rete. Il `brokerEndpoints` campo mostra gli indirizzi del broker Kafka `securityProtocol` e `saslMechanism` (se applicabile) mostra il metodo di autenticazione e il `networkConfig` campo mostra gli indirizzi IP, il blocco CIDR di sottorete e i gruppi di sicurezza utilizzati dalla mappatura delle sorgenti degli eventi. Verifica che i gruppi di sicurezza elencati consentano il traffico in entrata richiesto:
```
{
"eventType": "POLLER_STATUS_EVENT",
"timestamp": 1734567892456,
"resourceArn": "arn:aws:lambda:us-east-1:123456789012:event-source-mapping:a1b2c3d4-5678-90ab-cdef-11111EXAMPLE",
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/my-kafka-cluster/a1b2c3d4-5678-90ab-cdef-11111EXAMPLE-1",
"eventProcessorId": "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE/0",
"logLevel": "INFO",
"kafkaEventSourceConnection": {
"brokerEndpoints": "boot-abcd1234.c2.kafka-serverless.us-east-1.amazonaws.com:9098",
"consumerId": "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE-0",
"topics": [
"my-topic"
],
"consumerGroupId": "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE",
"securityProtocol": "SASL_SSL",
"saslMechanism": "AWS_MSK_IAM",
"totalPartitionCount": 2,
"assignedPartitionCount": 2,
"partitionsAssignmentGeneration": 1,
"assignedPartitions": [
"my-topic-0",
"my-topic-1"
],
"networkConfig": {
"ipAddresses": [
"10.0.0.37"
],
"subnetCidrBlock": "10.0.0.32/28",
"securityGroups": [
"sg-0123456789abcdef0"
]
}
}
}
```
### Gli endpoint del broker Kafka non possono essere risolti
Questo errore indica che il cluster Kafka non esiste o è stato eliminato. Verifica che il cluster specificato nella mappatura dell'origine degli eventi esista e sia in uno stato attivo.
Di seguito è riportato un esempio di registro ESM a livello di sistema dopo aver abilitato Logging [Config](esm-logging.md) per questo problema:
```
{
"eventType": "ESM_PROCESSING_EVENT",
"timestamp": 1734567893456,
"resourceArn": "arn:aws:lambda:us-east-1:123456789012:event-source-mapping:a1b2c3d4-5678-90ab-cdef-EXAMPLE66666",
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/my-kafka-cluster/12345678-abcd-1234-efgh-EXAMPLE66666-1",
"eventProcessorId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE66666/0",
"logLevel": "WARN",
"error": {
"errorMessage": "No resolvable bootstrap urls given in bootstrap.servers",
"errorCode": "org.apache.kafka.common.config.ConfigException"
}
}
```
## Errori della mappatura dell'origine eventi
Quando aggiungi il cluster Apache Kafka come [origine eventi](invocation-eventsourcemapping.md) per la funzione Lambda, se la funzione rileva un errore, il consumer Kafka arresta l'elaborazione dei record. I consumatori di uno shard dell'argomento sono quelli che sottoscrivono, leggono ed elaborano i record. Gli altri consumatori Kafka possono continuare a elaborare i record, a condizione che non riscontrino lo stesso errore.
Per determinare la causa di un consumatore interrotto, controlla il campo `StateTransitionReason` nella risposta di `EventSourceMapping`. Nell'elenco seguente vengono descritti gli errori dell'origine eventi che è possibile ricevere:
**`ESM_CONFIG_NOT_VALID`**
La configurazione della mappatura della fonte evento non è valida.
**`EVENT_SOURCE_AUTHN_ERROR`**
Lambda non ha potuto autenticare la fonte evento.
**`EVENT_SOURCE_AUTHZ_ERROR`**
Lambda non dispone delle autorizzazioni necessarie per accedere alla fonte evento.
**`FUNCTION_CONFIG_NOT_VALID`**
La configurazione della funzione non è valida.
**Nota**
Se i record degli eventi Lambda superano il limite di dimensione consentito di 6 MB, potrebbero non venire elaborati.
# Richiamo di funzione Lambda utilizzando un endpoint Gateway Amazon API
È possibile creare un'API web con un endpoint HTTP per la funzione Lambda utilizzando Amazon API Gateway. API Gateway fornisce strumenti per creare e documentare siti Web APIs che instradano le richieste HTTP verso le funzioni Lambda. È possibile proteggere l'accesso all'API con controlli di autenticazione e autorizzazione. APIs Puoi servire il traffico su Internet o essere accessibile solo all'interno del tuo VPC.
**Suggerimento**
Lambda offre due modi per richiamare una funzione tramite un endpoint HTTP: API Gateway e funzione Lambda. URLs In caso di dubbi su quale sia il metodo migliore per il tuo caso d'uso, consulta [Selezionare un metodo per richiamare la funzione Lambda tramite una richiesta HTTP](apig-http-invoke-decision.md).
Le risorse nell'API definiscono uno o più metodi, ad esempio GET o POST. I metodi hanno un'integrazione che instrada le richieste a una funzione Lambda o a un altro tipo di integrazione. È possibile definire ogni risorsa e metodo singolarmente oppure utilizzare tipi di risorse e metodi speciali per soddisfare tutte le richieste che si adattano a un modello. Una [risorsa proxy](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html) cattura tutti i percorsi sottostanti una risorsa. Il metodo `ANY` cattura tutti i metodi HTTP.
**Topics**
+ [
## Scelta di un tipo di API
](#services-apigateway-apitypes)
+ [
## Aggiunta di un endpoint alla funzione Lambda
](#apigateway-add)
+ [
## Integrazione proxy
](#apigateway-proxy)
+ [
## Formato dell'evento
](#apigateway-example-event)
+ [
## Formato della risposta
](#apigateway-types-transforms)
+ [
## Permissions
](#apigateway-permissions)
+ [
## Applicazione di esempio
](#services-apigateway-samples)
+ [
## Il gestore di eventi di Powertools for Lambda AWS
](#services-apigateway-powertools)
+ [
# Tutorial: uso di Lambda con Amazon API Gateway
](services-apigateway-tutorial.md)
+ [
# Gestione degli errori con un'API di API Gateway
](services-apigateway-errors.md)
+ [
# Selezionare un metodo per richiamare la funzione Lambda tramite una richiesta HTTP
](apig-http-invoke-decision.md)
## Scelta di un tipo di API
API Gateway supporta tre tipi di funzioni APIs che richiamano funzioni Lambda:
+ [API HTTP: un'API](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html) leggera e a bassa RESTful latenza.
+ [API REST: un'API](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html) personalizzabile e ricca di funzionalità RESTful .
+ [WebSocket API](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api.html): un'API Web che mantiene connessioni persistenti con i client per comunicazioni full-duplex.
HTTP APIs e REST APIs elaborano entrambe RESTful APIs le richieste HTTP e restituiscono risposte. APIs Gli HTTP sono più recenti e sono creati con l'API API Gateway versione 2. Le seguenti funzionalità sono nuove per HTTP: APIs
**Funzionalità API HTTP**
+ **Distribuzioni automatiche**: quando si modificano routing o integrazioni, le modifiche vengono distribuite automaticamente alle fasi in cui è abilitata la distribuzione automatica.
+ **Fase predefinita**: è possibile creare una fase predefinita (`$default`) che invii le richieste nel percorso root dell'URL dell'API. Per le fasi denominate, è necessario includere il nome dello stage all'inizio del percorso.
+ **Configurazione CORS:** è possibile configurare l'API in modo da aggiungere intestazioni CORS alle risposte in uscita, invece di aggiungerle manualmente nel codice della funzione.
APIs I REST sono i classici RESTful APIs che API Gateway ha supportato sin dal lancio. APIs Attualmente REST offre più funzionalità di personalizzazione, integrazione e gestione.
**Funzionalità REST API**
+ **Tipi di integrazione**: REST APIs supporta integrazioni Lambda personalizzate. Con un'integrazione personalizzata, è possibile inviare solo il corpo della richiesta alla funzione, o applicare un modello di trasformazione al corpo della richiesta prima di inviarlo alla funzione.
+ **Controllo degli accessi**: REST APIs supporta più opzioni per l'autenticazione e l'autorizzazione.
+ **Monitoraggio e tracciamento**: REST APIs supporta il AWS X-Ray tracciamento e opzioni di registrazione aggiuntive.
Per un confronto dettagliato, consulta [Choose between HTTP APIs and REST APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-vs-rest.html) nella *API Gateway Developer Guide*.
WebSocket APIs utilizza anche l'API API Gateway versione 2 e supporta un set di funzionalità simile. Utilizza un' WebSocket API per le applicazioni che traggono vantaggio da una connessione persistente tra il client e l'API. WebSocket APIs forniscono una comunicazione full-duplex, il che significa che sia il client che l'API possono inviare messaggi in modo continuo senza attendere una risposta.
HTTP APIs supporta un formato di eventi semplificato (versione 2.0). Per un esempio di evento da un'API HTTP, consulta [Creare integrazioni AWS Lambda proxy per HTTP APIs in API Gateway](https://docs.aws.amazon.com//apigateway/latest/developerguide/http-api-develop-integrations-lambda.html).
Per ulteriori informazioni, consulta [Creare integrazioni AWS Lambda proxy per HTTP APIs in API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-lambda.html).
## Aggiunta di un endpoint alla funzione Lambda
**Per aggiungere un endpoint pubblico alla funzione Lambda**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegliere una funzione.
1. In **Function overview (Panoramica delle funzioni)**, scegliere **Add trigger (Aggiungi trigger)**.
1. Selezionare **API Gateway**.
1. Scegliere **Create an API** (Crea una nuova API) o **Use an existing API** (Usa un'API esistente).
1. **Nuova API:** per **API type** (Tipo di API), scegliere **HTTP API** (API HTTP). Per ulteriori informazioni, consulta [Scelta di un tipo di API](#services-apigateway-apitypes).
1. **API esistente:** seleziona l'API dal menu a discesa o inserisci l'ID API (ad esempio, r3pmxmplak).
1. Per **Security (Sicurezza)**, scegliere **Open (Apri)**.
1. Scegliere **Add (Aggiungi)**.
## Integrazione proxy
Gli API Gateway APIs sono composti da fasi, risorse, metodi e integrazioni. La fase e la risorsa determinano il percorso dell'endpoint:
**Formato del percorso API**
+ `/prod/`: la fase e la risorsa radice di `prod`.
+ `/prod/user`: la fase di `prod` e la risorsa di `user`.
+ `/dev/{proxy+}` – Qualunque routing della fase `dev`.
+ `/`— (HTTP APIs) La fase e la risorsa principale predefinite.
Un'integrazione Lambda mappa una combinazione di percorso e metodo HTTP a una funzione Lambda. È possibile configurare API Gateway in modo da passare il corpo della richiesta HTTP così com'è (integrazione personalizzata), o da incapsulare il corpo della richiesta in un documento che include tutte le informazioni sulla richiesta, incluse intestazioni, risorsa, percorso e metodo.
Per ulteriori informazioni, consulta [Integrazioni del proxy Lambda di API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html).
## Formato dell'evento
Amazon API Gateway richiama la funzione [in modo sincrono](invocation-sync.md) con un evento che contiene una rappresentazione JSON della richiesta HTTP. Per un'integrazione personalizzata, l'evento è il corpo della richiesta. Per un'integrazione proxy, l'evento ha una struttura definita. Per un esempio di evento proxy proveniente da una REST API di API Gateway, consulta [Formato di input di una funzione Lambda per l'integrazione del proxy](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format) nella *Guida per gli sviluppatori di API Gateway*.
## Formato della risposta
API Gateway attende una risposta dalla funzione e inoltra il risultato al chiamante. Per un'integrazione personalizzata, è possibile definire una risposta di integrazione e una risposta al metodo per convertire l'output dalla funzione a una risposta HTTP. Per un'integrazione proxy, la funzione deve rispondere con una rappresentazione della risposta in un formato specifico.
L'esempio seguente mostra un oggetto risposta da una funzione Node.js. L'oggetto risposta rappresenta una risposta HTTP riuscita che contiene un documento JSON.
**Example index.mjs: oggetto risposta di integrazione proxy (Node.js)**
```
var response = {
"statusCode": 200,
"headers": {
"Content-Type": "application/json"
},
"isBase64Encoded": false,
"multiValueHeaders": {
"X-Custom-Header": ["My value", "My other value"],
},
"body": "{\n \"TotalCodeSize\": 104330022,\n \"FunctionCount\": 26\n}"
}
```
Il runtime Lambda serializza l'oggetto di risposta in JSON e lo invia all'API. L'API analizza la risposta e la utilizza per creare una risposta HTTP, che quindi la invia al client che ha effettuato la richiesta originale.
**Example Risposta HTTP**
```
< HTTP/1.1 200 OK
< Content-Type: application/json
< Content-Length: 55
< Connection: keep-alive
< x-amzn-RequestId: 32998fea-xmpl-4268-8c72-16138d629356
< X-Custom-Header: My value
< X-Custom-Header: My other value
< X-Amzn-Trace-Id: Root=1-5e6aa925-ccecxmplbae116148e52f036
<
{
"TotalCodeSize": 104330022,
"FunctionCount": 26
}
```
## Permissions
Amazon API Gateway ottiene l'autorizzazione a richiamare la funzione dalla [policy basata su risorse](access-control-resource-based.md) della funzione. È possibile concedere l'autorizzazione a un'intera API o concedere un accesso limitato a una fase, una risorsa o un metodo.
Quando aggiungi un'API alla funzione utilizzando la console Lambda, la console API Gateway o in un modello AWS SAM , la policy basata su risorse della funzione viene aggiornata automaticamente. Di seguito è riportata una policy di funzioni di esempio.
**Example Policy di funzione**
****
```
{
"Version":"2012-10-17",
"Id": "default",
"Statement": [
{
"Sid": "nodejs-apig-functiongetEndpointPermissionProd-BWDBXMPLXE2F",
"Effect": "Allow",
"Principal": {
"Service": "apigateway.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-2:111122223333:function:nodejs-apig-function-1G3MXMPLXVXYI",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:execute-api:us-east-2:111122223333:ktyvxmpls1/*/GET/"
}
}
}
]
}
```
È possibile gestire manualmente le autorizzazioni delle policy di funzione con le seguenti operazioni API:
+ [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html)
+ [RemovePermission](https://docs.aws.amazon.com/lambda/latest/api/API_RemovePermission.html)
+ [GetPolicy](https://docs.aws.amazon.com/lambda/latest/api/API_GetPolicy.html)
Per concedere l'autorizzazione di chiamata a un'API esistente, utilizzare il comando `add-permission`. Esempio:
```
aws lambda add-permission \
--function-name my-function \
--statement-id apigateway-get --action lambda:InvokeFunction \
--principal apigateway.amazonaws.com \
--source-arn "arn:aws:execute-api:us-east-2:123456789012:mnh1xmpli7/default/GET/"
```
Verrà visualizzato l’output seguente:
```
{
"Statement": "{\"Sid\":\"apigateway-test-2\",\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"apigateway.amazonaws.com\"},\"Action\":\"lambda:InvokeFunction\",\"Resource\":\"arn:aws:lambda:us-east-2:123456789012:function:my-function\",\"Condition\":{\"ArnLike\":{\"AWS:SourceArn\":\"arn:aws:execute-api:us-east-2:123456789012:mnh1xmpli7/default/GET\"}}}"
}
```
**Nota**
Se la funzione e l'API sono diverse Regioni AWS, l'identificatore di regione nell'ARN di origine deve corrispondere alla regione della funzione, non alla regione dell'API. Quando API Gateway richiama una funzione, utilizza un ARN di risorsa basato sull'ARN dell'API, ma modificato per corrispondere alla regione della funzione.
L'ARN di origine in questo esempio concede l'autorizzazione a un'integrazione nel metodo GET della risorsa root nella fase predefinita di un'API, con ID `mnh1xmpli7`. È possibile utilizzare un asterisco nell'ARN di origine per concedere autorizzazioni a più fasi, metodi o risorse.
**Modelli di risorse**
+ `mnh1xmpli7/*/GET/*`: metodo GET su tutte le risorse in tutte le fasi.
+ `mnh1xmpli7/prod/ANY/user`: metodo ANY sulla risorsa `user` nella fase `prod`.
+ `mnh1xmpli7/*/*/*`: qualsiasi metodo su tutte le risorse in tutte le fasi.
Per informazioni dettagliate sulla visualizzazione delle policy e sulla rimozione delle istruzioni, vedere [Visualizzazione delle policy IAM basate sulle risorse in Lambda](access-control-resource-based.md).
## Applicazione di esempio
L'app di esempio [API Gateway with Node.js](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/nodejs-apig) include una funzione con un AWS SAM modello che crea un'API REST con AWS X-Ray tracciamento abilitato. Include anche script per l'implementazione, il richiamo della funzione, il test dell'API e la pulizia.
## Il gestore di eventi di Powertools for Lambda AWS
Il gestore di eventi del toolkit Powertools for AWS Lambda fornisce routing, middleware, configurazione CORS, generazione di specifiche OpenAPI, convalida delle richieste, gestione degli errori e altre funzioni utili durante la scrittura di funzioni Lambda richiamate da un endpoint API Gateway (HTTP o REST). L'utilità Event Handler è disponibile per Python TypeScript e/. JavaScript Per ulteriori informazioni, vedete l'[API REST di Event Handler](https://docs.powertools.aws.dev/lambda/python/latest/core/event_handler/api_gateway/) nella documentazione di *Powertools for AWS Lambda (Python)* [e l'API HTTP Event Handler](https://docs.aws.amazon.com/powertools/typescript/latest/features/event-handler/http/) nella documentazione di *Powertools* for Lambda (). AWS TypeScript
### Python
```
from aws_lambda_powertools import Logger
from aws_lambda_powertools.event_handler import APIGatewayRestResolver
from aws_lambda_powertools.logging import correlation_paths
from aws_lambda_powertools.utilities.typing.lambda_context import LambdaContext
app = APIGatewayRestResolver()
logger = Logger()
@app.get("/healthz")
def ping():
return {"message": "health status ok"}
@logger.inject_lambda_context(correlation_id_path=correlation_paths.API_GATEWAY_REST)
def lambda_handler(event: dict, context: LambdaContext) -> dict:
return app.resolve(event, context)
```
### Typescript
```
import { Router } from '@aws-lambda-powertools/event-handler/experimental-rest';
import { Logger } from '@aws-lambda-powertools/logger';
import {
correlationPaths,
search,
} from '@aws-lambda-powertools/logger/correlationId';
import type { Context } from 'aws-lambda/handler';
const logger = new Logger({
correlationIdSearchFn: search,
});
const app = new Router({ logger });
app.get("/healthz", async () => {
return { message: "health status ok" };
});
export const handler = async (event: unknown, context: Context) => {
// You can continue using other utilities just as before
logger.addContext(context);
logger.setCorrelationId(event, correlationPaths.API_GATEWAY_REST);
return app.resolve(event, context);
};
```
# Tutorial: uso di Lambda con Amazon API Gateway
In questo tutorial, viene creata una REST API tramite la quale viene richiamata una funzione Lambda utilizzando una richiesta HTTP. La funzione Lambda eseguirà operazioni di creazione, aggiornamento ed eliminazione (CRUD) su una tabella DynamoDB. Questa funzione viene fornita qui a scopo dimostrativo, ma imparerai a configurare una REST API di Gateway API in grado di richiamare qualsiasi funzione Lambda.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/APIG_tut_resources.png)
L'utilizzo di Gateway API fornisce agli utenti un endpoint HTTP sicuro per richiamare la funzione Lambda e può aiutare a gestire grandi volumi di chiamate alla funzione limitando il traffico e convalidando e autorizzando automaticamente le chiamate API. API Gateway fornisce anche controlli di sicurezza flessibili utilizzando AWS Identity and Access Management (IAM) e Amazon Cognito. Ciò è utile nei casi d'uso in cui è richiesta un'autorizzazione preventiva per le chiamate all'applicazione.
**Suggerimento**
Lambda offre due modi per richiamare una funzione tramite un endpoint HTTP: API Gateway e funzione Lambda. URLs In caso di dubbi su quale sia il metodo migliore per il tuo caso d'uso, consulta [Selezionare un metodo per richiamare la funzione Lambda tramite una richiesta HTTP](apig-http-invoke-decision.md).
Per completare questo tutorial, saranno completate le seguenti fasi:
1. Crea e configura una funzione Lambda in Python o Node.js per eseguire operazioni su una tabella DynamoDB.
1. Crea una REST API in Gateway API per connetterti alla funzione Lambda.
1. Crea una tabella DynamoDB e testala con la funzione Lambda nella console.
1. Implementa la tua API e testa la configurazione completa usando curl in un terminale.
Completando queste fasi, imparerai come utilizzare Gateway API per creare un endpoint HTTP in grado di richiamare in modo sicuro una funzione Lambda su qualsiasi scala. Imparerai anche come distribuire la tua API e come testarla nella console e inviando una richiesta HTTP tramite un terminale.
## Creazione di una policy di autorizzazione
Prima di poter creare un [ruolo di esecuzione](lambda-intro-execution-role.md) per la tua funzione Lambda, devi prima creare una politica di autorizzazioni per concedere alla funzione il permesso di accedere alle risorse richieste. AWS Per questo tutorial, la policy consente a Lambda di eseguire operazioni CRUD su una tabella DynamoDB e scrivere su Amazon Logs. CloudWatch
**Come creare la policy**
1. Apri la pagina [Policies (Policy)](https://console.aws.amazon.com/iam/home#/policies) nella console IAM.
1. Scegli **Crea policy**.
1. Scegliere la scheda **JSON** e quindi incollare la seguente policy personalizzata nell'editor JSON.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Stmt1428341300017",
"Action": [
"dynamodb:DeleteItem",
"dynamodb:GetItem",
"dynamodb:PutItem",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:UpdateItem"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Sid": "",
"Resource": "*",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Effect": "Allow"
}
]
}
```
------
1. Scegliere **Next: Tags (Successivo: Tag)**.
1. Scegliere **Next:Review (Successivo: Rivedi)**.
1. In **Rivedi policy**, per **Nome** della policy inserisci **lambda-apigateway-policy**.
1. Scegli **Crea policy**.
## Creazione di un ruolo di esecuzione
Un [ruolo di esecuzione](lambda-intro-execution-role.md) è un ruolo AWS Identity and Access Management (IAM) che concede a una funzione Lambda l'autorizzazione all' Servizi AWS accesso e alle risorse. Per consentire alla funzione di eseguire operazioni su una tabella DynamoDB, collega la policy di autorizzazione che hai creato nella fase precedente.
**Creazione di un ruolo di esecuzione e collegamento di una policy di autorizzazione personalizzata**
1. Aprire la [pagina Roles (Ruoli)](https://console.aws.amazon.com/iam/home#/roles) della console IAM.
1. Scegli **Crea ruolo**.
1. Per il tipo di entità attendibile, scegli **Servizio AWS **, quindi per il caso d'uso seleziona **Lambda**.
1. Scegli **Next (Successivo)**.
1. Nella casella di ricerca delle policy, immettere **lambda-apigateway-policy**.
1. Nei risultati della ricerca, seleziona la policy creata (`lambda-apigateway-policy`), quindi scegli **Next** (Successivo).
1. In **Role details** (Dettagli del ruolo), per **Role name** (Nome del ruolo), specifica **lambda-apigateway-role**, quindi scegli **Create role** (Crea ruolo).
## Creazione della funzione Lambda
1. Apri la [pagina Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda e scegli **Crea funzione**.
1. Scegli **Crea da zero**.
1. Nel campo **Function name (Nome funzione)**, immettere `LambdaFunctionOverHttps`.
1. Per **Runtime**, scegli l'ultimo runtime di Node.js o di Python.
1. In **Autorizzazioni** espandere **Modifica ruolo di esecuzione predefinito**.
1. Scegli **Utilizza un ruolo esistente**, quindi seleziona il ruolo **lambda-apigateway-role** creato in precedenza.
1. Scegli **Crea funzione**.
1. Nel riquadro **Fonte codice**, sostituisci il codice predefinito con il seguente codice Node.js o Python.
------
#### [ Node.js ]
L'`region`impostazione deve corrispondere al Regione AWS luogo in cui si distribuisce la funzione e si [crea la tabella DynamoDB](#services-apigateway-tutorial-table).
**Example index.mjs**
```
import { DynamoDBDocumentClient, PutCommand, GetCommand,
UpdateCommand, DeleteCommand} from "@aws-sdk/lib-dynamodb";
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
const ddbClient = new DynamoDBClient({ region: "us-east-2" });
const ddbDocClient = DynamoDBDocumentClient.from(ddbClient);
// Define the name of the DDB table to perform the CRUD operations on
const tablename = "lambda-apigateway";
/**
* Provide an event that contains the following keys:
*
* - operation: one of 'create,' 'read,' 'update,' 'delete,' or 'echo'
* - payload: a JSON object containing the parameters for the table item
* to perform the operation on
*/
export const handler = async (event, context) => {
const operation = event.operation;
if (operation == 'echo'){
return(event.payload);
}
else {
event.payload.TableName = tablename;
let response;
switch (operation) {
case 'create':
response = await ddbDocClient.send(new PutCommand(event.payload));
break;
case 'read':
response = await ddbDocClient.send(new GetCommand(event.payload));
break;
case 'update':
response = ddbDocClient.send(new UpdateCommand(event.payload));
break;
case 'delete':
response = ddbDocClient.send(new DeleteCommand(event.payload));
break;
default:
response = 'Unknown operation: ${operation}';
}
console.log(response);
return response;
}
};
```
------
#### [ Python ]
**Example lambda\$1function.py**
```
import boto3
# Define the DynamoDB table that Lambda will connect to
table_name = "lambda-apigateway"
# Create the DynamoDB resource
dynamo = boto3.resource('dynamodb').Table(table_name)
# Define some functions to perform the CRUD operations
def create(payload):
return dynamo.put_item(Item=payload['Item'])
def read(payload):
return dynamo.get_item(Key=payload['Key'])
def update(payload):
return dynamo.update_item(**{k: payload[k] for k in ['Key', 'UpdateExpression',
'ExpressionAttributeNames', 'ExpressionAttributeValues'] if k in payload})
def delete(payload):
return dynamo.delete_item(Key=payload['Key'])
def echo(payload):
return payload
operations = {
'create': create,
'read': read,
'update': update,
'delete': delete,
'echo': echo,
}
def lambda_handler(event, context):
'''Provide an event that contains the following keys:
- operation: one of the operations in the operations dict below
- payload: a JSON object containing parameters to pass to the
operation being performed
'''
operation = event['operation']
payload = event['payload']
if operation in operations:
return operations[operation](payload)
else:
raise ValueError(f'Unrecognized operation "{operation}"')
```
------
**Nota**
In questo esempio, il nome della tabella DynamoDB è definito come variabile nel codice della funzione. In un'applicazione reale, la best practice consiste nell'inviare questo parametro come variabile d'ambiente ed evitare di codificare il nome della tabella. Per ulteriori informazioni, consulta [Uso AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html) delle variabili di ambiente.
1. Nella sezione **DEPLOY**, scegli **Implementa** per aggiornare il codice della tua funzione:
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/getting-started-tutorial/deploy-console.png)
## Test della funzione
Prima di integrare la tua funzione con Gateway API, verifica di aver implementato correttamente la funzione. Utilizza la console Lambda per inviare un evento di test alla tua funzione.
1. Nella pagina della console Lambda della funzione, scegli la scheda **Test**.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/test-tab.png)
1. Scorri alla sezione **JSON dell'evento** e sostituisci l’evento predefinito con il seguente. Questo evento corrisponde alla struttura prevista dalla funzione Lambda.
```
{
"operation": "echo",
"payload": {
"somekey1": "somevalue1",
"somekey2": "somevalue2"
}
}
```
1. Scegli **Test (Esegui test)**.
1. In **Esecuzione funzione: riuscita**, espandi **Dettagli**. Dovrebbe essere visualizzata la seguente risposta:
```
{
"somekey1": "somevalue1",
"somekey2": "somevalue2"
}
```
## Creazione di una REST API utilizzando API Gateway
In questa fase, viene creata la REST API di Gateway API che sarà utilizzata per richiamare la funzione Lambda.
**Per creare l'API**
1. Apri la [console API Gateway](https://console.aws.amazon.com/apigateway).
1. Seleziona **Create API** (Crea API).
1. Nella casella **REST API**, scegliere **Build**.
1. In **Dettagli API**, lasciare selezionata **Nuova API** e per **Nome API**, inserire **DynamoDBOperations**.
1. Seleziona **Create API** (Crea API).
## Creazione di una risorsa sulla REST API
Per aggiungere un metodo HTTP all'API, è necessario prima creare una risorsa su cui quel metodo possa operare. Qui viene creata la risorsa per gestire la tabella DynamoDB.
**Per creare la risorsa**
1. Nella [console API Gateway](https://console.aws.amazon.com/apigateway), nella pagina **Risorse** dell'API, scegliere **Crea risorsa**.
1. In **Dettagli risorsa**, per **Nome risorsa**, inserire **DynamoDBManager**.
1. Scegliere **Create Resource (Crea risorsa)**.
## Creazione di un metodo HTTP POST
In questa fase, viene creato un metodo (`POST`) per la risorsa `DynamoDBManager`. Il metodo `POST` viene collegato alla funzione Lambda in modo che quando il metodo riceve una richiesta HTTP, Gateway API richiama la funzione Lambda.
**Nota**
Ai fini di questo tutorial, viene utilizzato un metodo HTTP (`POST`) per richiamare una singola funzione Lambda che esegue tutte le operazioni sulla tabella DynamoDB. In un'applicazione reale, la best practice consiste nell'utilizzare una funzione Lambda e un metodo HTTP diversi per ogni operazione. Per ulteriori informazioni, consulta [Il monolite Lambda](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/monolith) in Serverless Land.
**Creazione del metodo POST**
1. Nella pagina **Risorse** dell'API, assicurarsi che la risorsa `/DynamoDBManager` sia evidenziata. Quindi, nel riquadro **Metodi**, scegliere **Crea metodo**.
1. Per **Metodo HTTP** scegliere **POST**.
1. Per **Tipo di integrazione** lasciare selezionato **Funzione Lambda**.
1. Per la **funzione Lambda**, scegliere nome della risorsa Amazon (ARN) per la funzione (`LambdaFunctionOverHttps`).
1. Scegli **Crea metodo**.
## Creazione di una tabella DynamoDB
Crea una tabella DynamoDB vuota su cui la funzione Lambda eseguirà le operazioni CRUD.
**Creare la tabella DynamoDB**
1. Aprire la pagina [Tables (Tabelle)](https://console.aws.amazon.com/dynamodbv2#tables) della console DynamoDB.
1. Scegliere **Create table (Crea tabella)**.
1. In **Table details (Dettagli tabella)**, effettuare le seguenti operazioni:
1. Nel campo **Table name (Nome tabella)** immetti **lambda-apigateway**.
1. Per **Partition key (Chiave di partizione)**, immettere **id** e mantenere il tipo di dati impostato come **String (Stringa)**.
1. In **Table settings** (Impostazioni tabella), mantieni le **impostazioni predefinite**.
1. Scegliere **Create table (Crea tabella)**.
## Test dell'integrazione di Gateway API, Lambda e DynamoDB
A questo punto sei pronto per testare l'integrazione del metodo API di Gateway API con la funzione Lambda e la tabella DynamoDB. Utilizzando la console di Gateway API, invii le richieste direttamente al metodo `POST` utilizzando la funzione di test della console. In questo passaggio, viene utilizzata prima un'operazione `create` per aggiungere un nuovo elemento alla tabella DynamoDB, quindi viene utilizzata un'operazione `update` per modificare l'elemento.
**Test 1: creazione di un nuovo elemento nella tabella DynamoDB**
1. Nella [console di Gateway API](https://console.aws.amazon.com/apigateway), scegli l'API (`DynamoDBOperations`).
1. Scegli il metodo **POST** sotto la risorsa `DynamoDBManager`.
1. Seleziona la scheda **Test**. Potrebbe essere necessario scegliere il pulsante freccia destra per visualizzare la scheda.
1. In **Metodo di prova**, lasciare vuote le **stringhe di query** e le **intestazioni**. Per **Corpo della richiesta**, incollare il file JSON seguente:
```
{
"operation": "create",
"payload": {
"Item": {
"id": "1234ABCD",
"number": 5
}
}
}
```
1. Scegli **Test (Esegui test)**.
I risultati visualizzati al termine del test devono mostrare lo stato `200`. Questo codice di stato indica che l'operazione `create` è riuscita.
Come verifica, controlla che la tabella DynamoDB contenga il nuovo elemento.
1. Apri la pagina [Tables](https://console.aws.amazon.com/dynamodbv2#tables) (Tabelle) della console DynamoDB e scegli la tabella `lambda-apigateway`.
1. Scegli **Explore table items** (Esplora elementi della tabella). Nel riquadro **Items returned** (Elementi restituiti), dovresti vedere un elemento con l'**id** `1234ABCD` e il **numero** `5`. Esempio:
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/items-returned.png)
**Test 2: aggiornamento dell'elemento nella tabella DynamoDB**
1. Nella [Console API Gateway](https://console.aws.amazon.com/apigateway), tornare alla scheda **Test** del metodo POST.
1. In **Metodo di prova**, lasciare vuote le **stringhe di query** e le **intestazioni**. Per **Corpo della richiesta**, incollare il file JSON seguente:
```
{
"operation": "update",
"payload": {
"Key": {
"id": "1234ABCD"
},
"UpdateExpression": "SET #num = :newNum",
"ExpressionAttributeNames": {
"#num": "number"
},
"ExpressionAttributeValues": {
":newNum": 10
}
}
}
```
1. Scegli **Test (Esegui test)**.
I risultati visualizzati al termine del test devono mostrare lo stato `200`. Questo codice di stato indica che l'operazione `update` è riuscita.
Per confermare, controlla che l'elemento nella tua tabella DynamoDB sia stato modificato.
1. Apri la pagina [Tables](https://console.aws.amazon.com/dynamodbv2#tables) (Tabelle) della console DynamoDB e scegli la tabella `lambda-apigateway`.
1. Scegli **Explore table items** (Esplora elementi della tabella). Nel riquadro **Items returned** (Elementi restituiti), dovresti vedere un elemento con l'**id** `1234ABCD` e il **numero** `10`.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/items-returned-2.png)
## Distribuzione dell'API
Per consentire al client di chiamare l'API, è necessario creare una implementazione e una fase associata. Una fase rappresenta un'istantanea dell'API, inclusi i suoi metodi e le sue integrazioni.
**Per distribuire l'API**
1. Apri la **APIs**pagina della [console API Gateway](https://console.aws.amazon.com/apigateway) e scegli l'`DynamoDBOperations`API.
1. Nella pagina **Risorse** per la tua API, scegliere **Distribuzione dell'API**.
1. Per **Fase**, scegliere **\$1Nuova fase\$1** quindi per **Nome fase** specificare **test**.
1. Seleziona **Implementa**.
1. Nel riquadro **Editor fase** (Editor fasi) del test, copia l'**URL di richiamo**. Questo verrà utilizzato nella fase successiva per richiamare la tua funzione utilizzando una richiesta HTTP.
## Uso di curl per richiamare la funzione tramite le richieste HTTP
A questo punto è possibile richiamare la funzione Lambda inviando una richiesta HTTP all'API. In questo passaggio, verrà creato un nuovo elemento nella tabella DynamoDB e quindi verranno eseguite le operazioni di lettura, aggiornamento ed eliminazione su tale elemento.
**Per creare un elemento nella tabella DynamoDB utilizzando curl**
1. Apri un terminale o un prompt dei comandi sul computer locale ed esegui il comando `curl` seguente utilizzando l'URL di invocazione che hai copiato nel passaggio precedente. Questo comando utilizza le seguenti opzioni:
+ `-H`: aggiunge un'intestazione personalizzata alla richiesta. Qui specifica il tipo di contenuto come JSON.
+ `-d`: invia i dati nel corpo della richiesta. Per impostazione predefinita, questa opzione utilizza un metodo HTTP POST.
------
#### [ Linux/macOS ]
```
curl https://l8togsqxd8.execute-api.us-east-2.amazonaws.com/test/DynamoDBManager \
-H "Content-Type: application/json" \
-d '{"operation": "create", "payload": {"Item": {"id": "5678EFGH", "number": 15}}}'
```
------
#### [ PowerShell ]
```
curl.exe 'https://l8togsqxd8.execute-api.us-east-2.amazonaws.com/test/DynamoDBManager' -H 'Content-Type: application/json' -d '{\"operation\": \"create\", \"payload\": {\"Item\": {\"id\": \"5678EFGH\", \"number\": 15}}}'
```
------
Se l'operazione ha avuto esito positivo, dovrebbe essere restituita una risposta con un codice di stato HTTP di 200.
1. È inoltre possibile utilizzare la console DynamoDB per verificare che il nuovo elemento sia nella tabella effettuando le operazioni seguenti:
1. Apri la pagina [Tables](https://console.aws.amazon.com/dynamodbv2#tables) (Tabelle) della console DynamoDB e scegli la tabella `lambda-apigateway`.
1. Scegli **Explore table items** (Esplora elementi della tabella). Nel riquadro **Items returned** (Elementi restituiti), dovresti vedere un elemento con l'**id** `5678EFGH` e il **numero** `15`.
**Per leggere l'elemento nella tabella DynamoDB utilizzando curl**
+ Nel terminale o nel prompt dei comandi, esegui il comando `curl` seguente per leggere il valore dell'elemento appena creato. Utilizzo dei propri URL di richiamo
------
#### [ Linux/macOS ]
```
curl https://l8togsqxd8.execute-api.us-east-2.amazonaws.com/test/DynamoDBManager \
-H "Content-Type: application/json" \
-d '{"operation": "read", "payload": {"Key": {"id": "5678EFGH"}}}'
```
------
#### [ PowerShell ]
```
curl.exe 'https://l8togsqxd8.execute-api.us-east-2.amazonaws.com/test/DynamoDBManager' -H 'Content-Type: application/json' -d '{\"operation\": \"read\", \"payload\": {\"Key\": {\"id\": \"5678EFGH\"}}}'
```
------
Dovresti vedere un output simile a uno dei seguenti a seconda che tu abbia scelto il codice della funzione Node.js o Python:
------
#### [ Node.js ]
```
{"$metadata":{"httpStatusCode":200,"requestId":"7BP3G5Q0C0O1E50FBQI9NS099JVV4KQNSO5AEMVJF66Q9ASUAAJG",
"attempts":1,"totalRetryDelay":0},"Item":{"id":"5678EFGH","number":15}}
```
------
#### [ Python ]
```
{"Item":{"id":"5678EFGH","number":15},"ResponseMetadata":{"RequestId":"QNDJICE52E86B82VETR6RKBE5BVV4KQNSO5AEMVJF66Q9ASUAAJG",
"HTTPStatusCode":200,"HTTPHeaders":{"server":"Server","date":"Wed, 31 Jul 2024 00:37:01 GMT","content-type":"application/x-amz-json-1.0",
"content-length":"52","connection":"keep-alive","x-amzn-requestid":"QNDJICE52E86B82VETR6RKBE5BVV4KQNSO5AEMVJF66Q9ASUAAJG","x-amz-crc32":"2589610852"},
"RetryAttempts":0}}
```
------
**Per aggiornare l'elemento nella tabella DynamoDB utilizzando curl**
1. Nel terminale o nel prompt dei comanti, esegui il comando `curl` seguente per aggiornare l'elemento appena creato modificando il valore `number`. Utilizzo dei propri URL di richiamo
------
#### [ Linux/macOS ]
```
curl https://l8togsqxd8.execute-api.us-east-2.amazonaws.com/test/DynamoDBManager \
-H "Content-Type: application/json" \
-d '{"operation": "update", "payload": {"Key": {"id": "5678EFGH"}, "UpdateExpression": "SET #num = :new_value", "ExpressionAttributeNames": {"#num": "number"}, "ExpressionAttributeValues": {":new_value": 42}}}'
```
------
#### [ PowerShell ]
```
curl.exe 'https://l8togsqxd8.execute-api.us-east-2.amazonaws.com/test/DynamoDBManager' -H 'Content-Type: application/json' -d '{\"operation\": \"update\", \"payload\": {\"Key\": {\"id\": \"5678EFGH\"}, \"UpdateExpression\": \"SET #num = :new_value\", \"ExpressionAttributeNames\": {\"#num\": \"number\"}, \"ExpressionAttributeValues\": {\":new_value\": 42}}}'
```
------
1. Per verificare che il valore di `number` per l'elemento sia stato aggiornato, esegui un altro comando di lettura:
------
#### [ Linux/macOS ]
```
curl https://l8togsqxd8.execute-api.us-east-2.amazonaws.com/test/DynamoDBManager \
-H "Content-Type: application/json" \
-d '{"operation": "read", "payload": {"Key": {"id": "5678EFGH"}}}'
```
------
#### [ PowerShell ]
```
curl.exe 'https://l8togsqxd8.execute-api.us-east-2.amazonaws.com/test/DynamoDBManager' -H 'Content-Type: application/json' -d '{\"operation\": \"read\", \"payload\": {\"Key\": {\"id\": \"5678EFGH\"}}}'
```
------
**Per eliminare l'elemento nella tabella DynamoDB utilizzando curl**
1. Nel terminale o nel prompt dei comandi, esegui il comando `curl` seguente per eliminare l'elemento appena creato. Utilizzo dei propri URL di richiamo
------
#### [ Linux/macOS ]
```
curl https://l8togsqxd8.execute-api.us-east-2.amazonaws.com/test/DynamoDBManager \
-H "Content-Type: application/json" \
-d '{"operation": "delete", "payload": {"Key": {"id": "5678EFGH"}}}'
```
------
#### [ PowerShell ]
```
curl.exe 'https://l8togsqxd8.execute-api.us-east-2.amazonaws.com/test/DynamoDBManager' -H 'Content-Type: application/json' -d '{\"operation\": \"delete\", \"payload\": {\"Key\": {\"id\": \"5678EFGH\"}}}'
```
------
1. Verifica che l'operazione di eliminazione è andata a buon fine. Nel riquadro **Elementi restituiti** della pagina **Esplora elementi** della console DynamoDB, verifica che l'elemento con **id** `5678EFGH` non sia più presente nella tabella.
## Pulizia delle risorse (facoltativo)
Ora è possibile eliminare le risorse create per questo tutorial, a meno che non si voglia conservarle. Eliminando AWS le risorse che non utilizzi più, eviti addebiti inutili a tuo Account AWS carico.
**Per eliminare la funzione Lambda**
1. Aprire la pagina [Functions (Funzioni)](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Selezionare la funzione creata.
1. Scegliere **Operazioni**, **Elimina**.
1. Inserisci **confirm** nel campo di immissione del testo, quindi scegli **Elimina**.
**Come eliminare il ruolo di esecuzione**
1. Aprire la pagina [Ruoli](https://console.aws.amazon.com/iam/home#/roles) della console IAM.
1. Selezionare il ruolo di esecuzione creato.
1. Scegliere **Elimina**.
1. Inserisci il nome del ruolo nel campo di immissione testo e seleziona **Delete** (Elimina).
**Per eliminare l'API**
1. Apri la [APIs pagina](https://console.aws.amazon.com/apigateway/main/apis) della console API Gateway.
1. Selezionare l'API creata.
1. Scegliere **Actions (Operazioni)**, **Delete (Elimina)**.
1. Scegliere **Delete (Elimina)**.
**Per eliminare la tabella DynamoDB**
1. Aprire la pagina [Tables (Tabelle)](https://console.aws.amazon.com//dynamodb/home#tables:) della console DynamoDB.
1. Selezionare la tabella creata.
1. Scegliere **Delete (Elimina)**.
1. Immettere **delete** nella casella di testo.
1. Seleziona **Delete Table (Elimina tabella)**.
# Gestione degli errori con un'API di API Gateway
API Gateway considera tutti gli errori di invocazione e di funzione come errori interni. Se l'API Lambda rifiuta la richiesta di invocazione, API Gateway restituisce un codice di errore 500. Se la funzione viene eseguita ma restituisce un errore o una risposta nel formato errato, API Gateway restituisce il codice 502. In entrambi i casi, il corpo della risposta da API Gateway è `{"message": "Internal server error"}`.
**Nota**
API Gateway non riprova le invocazioni Lambda. Se Lambda restituisce un errore, API Gateway restituisce una risposta di errore al client.
Nell'esempio seguente viene illustrata una mappa di tracciamento X-Ray per una richiesta che ha generato un errore di funzione e un codice 502 da API Gateway. Il client riceve il messaggio di errore generico.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/tracemap-apig-502.png)
Per personalizzare la risposta di errore, è necessario rilevare gli errori nel codice e formattare una risposta nel formato richiesto.
**Example [index.mjs](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/nodejs-apig/function/index.mjs): errore di formattazione**
```
var formatError = function(error){
var response = {
"statusCode": error.statusCode,
"headers": {
"Content-Type": "text/plain",
"x-amzn-ErrorType": error.code
},
"isBase64Encoded": false,
"body": error.code + ": " + error.message
}
return response
}
```
API Gateway converte questa risposta in un errore HTTP con un codice di stato personalizzato e un corpo. Nella mappa di tracciamento, il nodo della funzione è verde perché ha gestito l'errore.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/tracemap-apig-404.png)
# Selezionare un metodo per richiamare la funzione Lambda tramite una richiesta HTTP
Numerosi casi d'uso comuni per Lambda implicano l'invocazione della funzione tramite una richiesta HTTP. Ad esempio, potrebbe essere preferibile che un'applicazione Web invochi la funzione tramite una richiesta del browser. Le funzioni Lambda possono essere utilizzate anche per creare REST completo APIs, gestire le interazioni degli utenti da app mobili, elaborare dati da servizi esterni tramite chiamate HTTP o creare webhook personalizzati.
Le sezioni seguenti spiegano quali sono le tue scelte per richiamare Lambda tramite HTTP e forniscono informazioni per aiutarti a prendere la decisione giusta per il tuo caso d'uso particolare.
## Quali sono le tue scelte quando selezioni un metodo di invocazione HTTP?
[[Lambda offre due metodi principali per richiamare una funzione utilizzando una richiesta HTTP: funzione e API URLs Gateway.](services-apigateway.md)](urls-configuration.md) Le differenze tra queste due opzioni sono le seguenti:
+ **La funzione Lambda URLs** fornisce un endpoint HTTP semplice e diretto per una funzione Lambda. Sono ottimizzati per semplicità ed economicità e forniscono il percorso più veloce per esporre una funzione Lambda tramite HTTP.
+ **API Gateway** è un servizio più avanzato per la creazione di funzionalità complete APIs. API Gateway è ottimizzato per la creazione e la gestione di produzioni APIs su larga scala e fornisce strumenti completi per la sicurezza, il monitoraggio e la gestione del traffico.
## Suggerimenti se conosci già le tue esigenze
Se hai già le idee chiare sulle tue esigenze, ecco i nostri suggerimenti di base:
Consigliamo **[la funzionalità URLs](urls-configuration.md)** per applicazioni semplici o per la prototipazione in cui sono necessari solo metodi di autenticazione e request/response gestione di base e dove si desidera ridurre al minimo costi e complessità.
**[API Gateway](services-apigateway.md)** è la scelta migliore per le applicazioni di produzione su larga scala o per i casi in cui sono necessarie funzionalità più avanzate come il supporto [OpenAPI Description](https://www.openapis.org/), una scelta di opzioni di autenticazione, nomi di dominio personalizzati o una request/response gestione avanzata che include throttling, caching e trasformazione. request/response
## Cosa considerare quando si seleziona un metodo per richiamare la funzione Lambda
Nella scelta tra funzione URLs e API Gateway, è necessario considerare i seguenti fattori:
+ Le tue esigenze di autenticazione, ad esempio se richiedi OAuth o Amazon Cognito per autenticare gli utenti
+ I tuoi requisiti di scalabilità e la complessità dell'API che desideri implementare
+ Se hai bisogno di funzionalità avanzate come la convalida e la formattazione delle richieste request/response
+ I tuoi requisiti di monitoraggio
+ I tuoi obiettivi di costo
Comprendendo questi fattori, è possibile selezionare l'opzione che meglio bilancia i requisiti di sicurezza, complessità e costi.
Le informazioni seguente riepilogano le differenze principali tra le due opzioni.
### Autenticazione
+ **La funzione URLs** fornisce opzioni di autenticazione di base tramite AWS Identity and Access Management (IAM). Puoi configurare gli endpoint in modo che siano pubblici (senza autenticazione) o che richiedano l'autenticazione IAM. Con l'autenticazione IAM, puoi utilizzare AWS credenziali standard o ruoli IAM per controllare l'accesso. Sebbene sia semplice da configurare, questo approccio offre opzioni limitate rispetto ad altri metodi di autenticazione.
+ **API Gateway** fornisce l'accesso a una gamma più completa di opzioni di autenticazione. Oltre all'autenticazione IAM, puoi utilizzare gli [autorizzatori Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html) (logica di autenticazione personalizzata), i pool di utenti di [Amazon Cognito e i flussi](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html) .0. OAuth2 Questa flessibilità consente di implementare schemi di autenticazione complessi, inclusi provider di autenticazione di terze parti, autenticazione basata su token e autenticazione a più fattori.
### Gestione di richieste/risposte
+ **La funzione URLs fornisce la** gestione di base delle richieste e delle risposte HTTP. Supportano i metodi HTTP standard e includono il supporto integrato per CORS (cross-origin resource sharing). Sebbene siano in grado di gestire i payload JSON e i parametri di query in modo naturale, non offrono funzionalità di trasformazione o convalida delle richieste. La gestione delle risposte è altrettanto semplice: il client riceve la risposta dalla funzione Lambda esattamente come la restituisce Lambda.
+ **API Gateway** offre sofisticate funzionalità di gestione delle richieste e delle risposte. È possibile definire validatori di richiesta, trasformare richieste e risposte utilizzando modelli di mappatura, impostare request/response intestazioni e implementare la memorizzazione nella cache delle risposte. API Gateway supporta anche payload binari e nomi di dominio personalizzati e può modificare le risposte prima che raggiungano il client. È possibile configurare modelli per la request/response convalida e la trasformazione utilizzando JSON Schema.
### Dimensionamento
+ Le **funzioni** si URLs adattano direttamente ai limiti di concorrenza della funzione Lambda e gestisci i picchi di traffico scalando la funzione fino al limite di concorrenza massimo configurato. Una volta raggiunto tale limite, Lambda risponde alle richieste aggiuntive con risposte HTTP 429. Non esiste un meccanismo di accodamento integrato, pertanto la gestione della scalabilità dipende interamente dalla configurazione della funzione Lambda. Per impostazione predefinita, le funzioni Lambda hanno un limite di 1.000 esecuzioni simultanee per. Regione AWS
+ **API Gateway** offre funzionalità di scalabilità aggiuntive oltre alla scalabilità propria di Lambda. Include controlli integrati per l'accodamento e la limitazione delle richieste che consentono di gestire i picchi di traffico con maggiore efficienza. Per impostazione predefinita, API Gateway è in grado di gestire fino a 10.000 richieste al secondo per regione, con una capacità di espansione di 5.000 richieste al secondo. Fornisce inoltre strumenti per limitare le richieste a diversi livelli (API, fase o metodo) per proteggere il backend.
### Monitoraggio
+ **La funzione URLs** offre un monitoraggio di base tramite i CloudWatch parametri di Amazon, tra cui il conteggio delle richieste, la latenza e i tassi di errore. Puoi accedere a parametri e log Lambda standard, che mostrano le richieste non elaborate che arrivano alla tua funzione. Sebbene ciò fornisca una visibilità operativa essenziale, i parametri si concentrano principalmente sull'esecuzione delle funzioni.
+ **API Gateway** offre funzionalità di monitoraggio complete, tra cui parametri dettagliati, opzioni di registrazione e tracciamento. Puoi monitorare le chiamate API, la latenza, i tassi di errore e i tassi di cache hit/miss tramite. CloudWatch API Gateway si integra anche con AWS X-Ray il tracciamento distribuito e fornisce formati di registrazione personalizzabili.
### Costo
+ Le **funzioni URLs** seguono il modello di prezzo standard Lambda: paghi solo per le chiamate di funzione e il tempo di calcolo. Non sono previsti costi aggiuntivi per l'endpoint URL stesso. Ciò lo rende una scelta conveniente per applicazioni semplici APIs o a basso traffico se non sono necessarie le funzionalità aggiuntive di API Gateway.
+ **API Gateway** offre un [piano gratuito](https://aws.amazon.com/api-gateway/pricing/#Free_Tier) che include un milione di chiamate API ricevute per REST APIs e un milione di chiamate API ricevute per HTTP APIs. Successivamente, API Gateway addebita i costi per le chiamate API, il trasferimento dei dati e la memorizzazione nella cache (se abilitata). Consulta la [pagina dei prezzi](https://aws.amazon.com/api-gateway/pricing/) di API Gateway per conoscere i costi relativi al tuo caso d'uso.
### Altre funzionalità
+ URLsLe **funzioni** sono progettate per la semplicità e l'integrazione diretta con Lambda. Supportano endpoint HTTP e HTTPS, offrono supporto CORS integrato e forniscono endpoint dual-stack (e). IPv4 IPv6 Sebbene non dispongano di funzionalità avanzate, eccellono negli scenari in cui è necessario un modo rapido e diretto per esporre le funzioni Lambda tramite HTTP.
+ **API Gateway** include numerose funzionalità aggiuntive come il controllo delle versioni delle API, la gestione delle fasi, le chiavi API per i piani di utilizzo, la documentazione delle API tramite Swagger/OpenAPI, l'accesso WebSocket APIs privato all'interno di APIs un VPC e l'integrazione WAF per una maggiore sicurezza. Supporta anche implementazioni Canary, integrazioni fittizie per i test e l'integrazione con altri sistemi oltre a Lambda. Servizi AWS
## Selezionare un metodo per richiamare la funzione Lambda
Ora che hai letto i criteri per la selezione tra la funzione Lambda URLs e l'API Gateway e le principali differenze tra di essi, puoi selezionare l'opzione più adatta alle tue esigenze e utilizzare le seguenti risorse per iniziare a utilizzarla.
------
#### [ Function URLs ]
**Inizia a usare la funzione URLs con le seguenti risorse**
+ Segui il tutorial [Creazione di una funzione Lambda con la funzione URL](urls-webhook-tutorial.md)
+ Scopri di più sulla funzione URLs nel [Creazione e gestione della funzione Lambda URLs](urls-configuration.md) capitolo di questa guida
+ Prova il tutorial guidato dalla console **Creare una semplice app Web** effettuando le seguenti operazioni:
1. Apri la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Apri il pannello di aiuto scegliendo l'icona nell'angolo in alto a destra della schermata.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/console_help_screenshot.png)
1. Seleziona **Tutorial**.
1. In **Crea una semplice app Web**, scegli **Avvia tutorial**.
------
#### [ API Gateway ]
**Iniziare a usare Lambda e API Gateway con le seguenti risorse**
+ Segui il tutorial [Utilizzo di Lambda con API Gateway](services-apigateway-tutorial.md) per creare una REST API integrata con una funzione Lambda di backend.
+ Scopri di più sui diversi tipi di API offerti da API Gateway nelle seguenti sezioni della *Guida per gli sviluppatori di Gateway Amazon API*:
+ [API Gateway REST APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html)
+ [Gateway API HTTP APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html)
+ [API Gateway WebSocket APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api.html)
+ Prova uno o più esempi nella sezione [Tutorial e workshop](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-tutorials.html) della *Guida per gli sviluppatori di Gateway Amazon API*.
------
# Utilizzo AWS Lambda con AWS Infrastructure Composer
AWS Infrastructure Composer è un generatore visivo per la progettazione di applicazioni moderne su. AWS Progetta l'architettura della tua applicazione trascinandola, raggruppandola e connettendola in un'area di disegno visiva. Servizi AWS Infrastructure Composer crea modelli di infrastructure as code (IaC) a partire dal tuo progetto che puoi implementare utilizzando [AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html) oppure [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html).
## Esportazione di una funzione Lambda in Infrastructure Composer
Per iniziare a utilizzare Infrastructure Composer, crea un nuovo progetto basato sulla configurazione di una funzione Lambda esistente utilizzando la console Lambda. Per esportare la configurazione e il codice della funzione in Infrastructure Composer per creare un nuovo progetto, procedi come segue:
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Seleziona la funzione che desideri utilizzare come base per il tuo progetto Infrastructure Composer.
1. Nel riquadro **Panoramica della funzione**, scegli **Esporta in Infrastructure Composer**.
Per esportare la configurazione e il codice della funzione in Infrastructure Composer, Lambda crea un bucket Amazon S3 nel tuo account in cui archiviare temporaneamente questi dati.
1. Nella finestra di dialogo, scegli **Conferma e crea progetto** per accettare il nome predefinito per questo bucket ed esportare la configurazione e il codice della funzione in Infrastructure Composer.
1. (Facoltativo) Per scegliere un altro nome per il bucket Amazon S3 creato da Lambda, immetti un nuovo nome e scegli **Conferma e crea progetto**. I nomi dei bucket Amazon S3 devono essere univoci a livello globale e seguire le [regole di denominazione dei bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html).
1. Per salvare i file di progetto e funzione in Infrastructure Composer, attiva la [modalità di sincronizzazione locale](https://docs.aws.amazon.com/application-composer/latest/dg/reference-features-local-sync.html).
**Nota**
Se hai già utilizzato la funzionalità **Esporta in Strumento per la creazione di applicazioni** e hai creato un bucket Amazon S3 utilizzando il nome predefinito, Lambda può riutilizzare questo bucket, se esiste ancora. Accetta il nome predefinito del bucket nella finestra di dialogo per riutilizzare il bucket esistente.
### Configurazione del bucket di trasferimento Amazon S3
Il bucket Amazon S3 creato da Lambda per trasferire la configurazione della funzione crittografa automaticamente gli oggetti utilizzando lo standard di crittografia AES 256. Lambda configura inoltre il bucket in modo che utilizzi la [condizione di proprietario del bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-owner-condition.html) per garantire che solo il tuo Account AWS sia in grado di aggiungere oggetti al bucket.
Lambda configura il bucket per eliminare automaticamente gli oggetti 10 giorni dopo il caricamento. Tuttavia, Lambda non elimina automaticamente il bucket stesso. [Per eliminare il bucket dal tuo Account AWS, segui le istruzioni in Eliminare un bucket.](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html) Il nome predefinito del bucket utilizza il prefisso`lambdasam`, una stringa alfanumerica di 10 cifre, e la funzione in cui hai creato la funzione in: Regione AWS
```
lambdasam-06f22da95b-us-east-1
```
Per evitare costi aggiuntivi Account AWS, ti consigliamo di eliminare il bucket Amazon S3 non appena hai finito di esportare la funzione in Infrastructure Composer.
Si applicano i [prezzi standard di Amazon S3](https://aws.amazon.com/s3/pricing/).
### Autorizzazioni richieste
Per utilizzare l'integrazione Lambda con la funzionalità Infrastructure Composer, sono necessarie determinate autorizzazioni per scaricare un AWS SAM modello e scrivere la configurazione della funzione su Amazon S3.
Per scaricare un AWS SAM modello, devi disporre dell'autorizzazione per utilizzare le seguenti azioni API:
+ [GetPolicy](https://docs.aws.amazon.com/lambda/latest/api/API_GetPolicy.html)
+ [sono: GetPolicyVersion](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetPolicyVersion.html)
+ [sono: GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)
+ [sono: GetRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRolePolicy.html)
+ [sono: ListAttachedRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAttachedRolePolicies.html)
+ [sono: ListRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRolePolicies.html)
+ [sono: ListRoles](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRoles.html)
Puoi concedere l'autorizzazione a utilizzare tutte queste azioni aggiungendo la policy [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html) AWS gestita al tuo ruolo utente IAM.
Affinché Lambda scriva la configurazione della tua funzione su Amazon S3, devi disporre dell'autorizzazione a utilizzare le seguenti operazioni dell'API:
+ [S3: PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html)
+ [S3: CreateBucket](https://docs.aws.amazon.com/AmazonS3/latest/API/API_CreateBucket.html)
+ [S3: PutBucketEncryption](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketEncryption.html)
+ [S3: PutBucketLifecycleConfiguration](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketLifecycleConfiguration.html)
Se non riesci a esportare la configurazione della tua funzione in Infrastructure Composer, verifica che il tuo account disponga delle autorizzazioni necessarie per queste operazioni. Se disponi delle autorizzazioni richieste ma non riesci comunque a esportare la configurazione della funzione, verifica se ne sono presenti [policy basate sulle risorse](access-control-resource-based.md) che potrebbero limitare l'accesso ad Amazon S3.
## Altre risorse
Per un tutorial più dettagliato su come progettare un'applicazione serverless in Infrastructure Composer basata su una funzione Lambda esistente, consulta [Utilizzo di Lambda con l'infrastructure as code (IaC)](foundation-iac.md).
[Per utilizzare Infrastructure Composer e AWS SAM progettare e distribuire un'applicazione serverless completa utilizzando Lambda, puoi anche seguire il [AWS Infrastructure Composer tutorial](https://catalog.workshops.aws/serverless-patterns/en-US/dive-deeper/module1a) nel Serverless Patterns Workshop.AWS](https://catalog.workshops.aws/serverless-patterns/en-US)
# Utilizzo AWS Lambda con CloudFormation
In un AWS CloudFormation modello, puoi specificare una funzione Lambda come destinazione di una risorsa personalizzata. Utilizza risorse personalizzate per elaborare parametri, recuperare valori di configurazione o chiamare altre persone Servizi AWS durante gli eventi del ciclo di vita dello stack.
L'esempio seguente invoca una funzione definita in un altro punto del modello.
**Example – Definizione di risorse personalizzate**
```
Resources:
primerinvoke:
Type: [AWS::CloudFormation::CustomResource](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cfn-customresource.html)
Version: "1.0"
Properties:
ServiceToken: !GetAtt primer.Arn
FunctionName: !Ref randomerror
```
Il token di servizio è l'Amazon Resource Name (ARN) della funzione che CloudFormation richiama quando crei, aggiorni o elimini lo stack. Puoi anche includere proprietà aggiuntive come`FunctionName`, che vengono CloudFormation passate alla funzione così com'è.
CloudFormation richiama la funzione Lambda in modo [asincrono](invocation-async.md) con un evento che include un URL di callback.
**Example — CloudFormation evento del messaggio**
```
{
"RequestType": "Create",
"ServiceToken": "arn:aws:lambda:us-east-1:123456789012:function:lambda-error-processor-primer-14ROR2T3JKU66",
"ResponseURL": "https://cloudformation-custom-resource-response-useast1.s3-us-east-1.amazonaws.com/arn%3Aaws%3Acloudformation%3Aus-east-1%3A123456789012%3Astack/lambda-error-processor/1134083a-2608-1e91-9897-022501a2c456%7Cprimerinvoke%7C5d478078-13e9-baf0-464a-7ef285ecc786?AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE&Expires=1555451971&Signature=28UijZePE5I4dvukKQqM%2F9Rf1o4%3D",
"StackId": "arn:aws:cloudformation:us-east-1:123456789012:stack/lambda-error-processor/1134083a-2608-1e91-9897-022501a2c456",
"RequestId": "5d478078-13e9-baf0-464a-7ef285ecc786",
"LogicalResourceId": "primerinvoke",
"ResourceType": "AWS::CloudFormation::CustomResource",
"ResourceProperties": {
"ServiceToken": "arn:aws:lambda:us-east-1:123456789012:function:lambda-error-processor-primer-14ROR2T3JKU66",
"FunctionName": "lambda-error-processor-randomerror-ZWUC391MQAJK"
}
}
```
Da questa funzione dipende la risposta all'URL di callback che indica un esito positivo o negativo. Per la sintassi di risposta completa, consulta [Oggetti di risposta delle risorse personalizzate](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/crpg-ref-responses.html).
**Example — risposta CloudFormation personalizzata delle risorse**
```
{
"Status": "SUCCESS",
"PhysicalResourceId": "2019/04/18/[$LATEST]b3d1bfc65f19ec610654e4d9b9de47a0",
"StackId": "arn:aws:cloudformation:us-east-1:123456789012:stack/lambda-error-processor/1134083a-2608-1e91-9897-022501a2c456",
"RequestId": "5d478078-13e9-baf0-464a-7ef285ecc786",
"LogicalResourceId": "primerinvoke"
}
```
CloudFormation fornisce una libreria chiamata `cfn-response` che gestisce l'invio della risposta. Se definisci la tua funzione all'interno di un modello, puoi richiedere la libreria per nome. CloudFormation quindi aggiunge la libreria al pacchetto di distribuzione creato per la funzione.
Se alla funzione utilizzata da una risorsa personalizzata è collegata un'[interfaccia di rete elastica](configuration-vpc.md#configuration-vpc-enis), aggiungi le seguenti risorse alla policy VPC, dove **region** è la regione in cui si trova la funzione senza i trattini. Ad esempio, `us-east-1` è `useast1`. Ciò consentirà alla risorsa personalizzata di rispondere all'URL di callback che invia un segnale allo CloudFormation stack.
```
arn:aws:s3:::cloudformation-custom-resource-response-region",
"arn:aws:s3:::cloudformation-custom-resource-response-region/*",
```
La seguente funzione di esempio invoca una seconda funzione. Se la chiamata ha esito positivo, la funzione invia una risposta positiva a CloudFormation e l'aggiornamento dello stack continua. Il modello utilizza il tipo di [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)risorsa fornito da. AWS Serverless Application Model
**Example : funzione relativa alle risorse personalizzate**
```
Transform: 'AWS::Serverless-2016-10-31'
Resources:
primer:
Type: [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)
Properties:
Handler: index.handler
Runtime: nodejs16.x
InlineCode: |
var aws = require('aws-sdk');
var response = require('cfn-response');
exports.handler = function(event, context) {
// For Delete requests, immediately send a SUCCESS response.
if (event.RequestType == "Delete") {
response.send(event, context, "SUCCESS");
return;
}
var responseStatus = "FAILED";
var responseData = {};
var functionName = event.ResourceProperties.FunctionName
var lambda = new aws.Lambda();
lambda.invoke({ FunctionName: functionName }, function(err, invokeResult) {
if (err) {
responseData = {Error: "Invoke call failed"};
console.log(responseData.Error + ":\n", err);
}
else responseStatus = "SUCCESS";
response.send(event, context, responseStatus, responseData);
});
};
Description: Invoke a function to create a log stream.
MemorySize: 128
Timeout: 8
Role: !GetAtt role.Arn
Tracing: Active
```
Se la funzione richiamata dalla risorsa personalizzata non è definita in un modello, puoi ottenere il codice sorgente `cfn-response` dal [modulo cfn-response](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-lambda-function-code-cfnresponsemodule.html) nella Guida per l'utente. AWS CloudFormation
Per ulteriori informazioni sulle risorse personalizzate, consulta [Risorse personalizzate](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html) nella *Guida per l'utente di AWS CloudFormation *.
# Elaborare gli eventi Amazon DocumentDB con Lambda
Per elaborare gli eventi in un [flusso di modifica di Amazon DocumentDB (compatibile con MongoDB)](https://docs.aws.amazon.com/documentdb/latest/developerguide/change_streams.html), puoi utilizzare una funzione Lambda configurando un cluster Amazon DocumentDB come origine degli eventi. Successivamente puoi automatizzare i carichi di lavoro basati sugli eventi invocando la funzione Lambda con il cluster Amazon DocumentDB ogni volta che i dati cambiano.
**Nota**
Lambda supporta solo le versioni 4.0 e 5.0 di Amazon DocumentDB. Lambda non supporta la versione 3.6.
Inoltre, per gli strumenti di mappatura dell'origine degli eventi, Lambda supporta solo cluster basati su istanze e cluster regionali. Lambda non supporta [cluster elastici](https://docs.aws.amazon.com/documentdb/latest/developerguide/docdb-using-elastic-clusters.html) o [cluster globali](https://docs.aws.amazon.com/documentdb/latest/developerguide/global-clusters.html). Questa limitazione non si applica quando si utilizza Lambda come client per connettersi ad Amazon DocumentDB. Lambda può connettersi a tutti i tipi di cluster per eseguire operazioni CRUD.
Lambda elabora gli eventi di Amazon DocumentDB nei flussi di modifica in sequenza secondo l'ordine in cui arrivano. Per questo motivo, la tua funzione può gestire solo una invocazione simultanea da Amazon DocumentDB alla volta. Per monitorare la tua funzione, puoi tenere traccia dei relativi [parametri di simultaneità](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-concurrency.html).
**avvertimento**
Gli strumenti di mappatura dell'origine degli eventi elaborano ogni evento almeno una volta e può verificarsi un'elaborazione duplicata dei record. Per evitare potenziali problemi legati agli eventi duplicati, ti consigliamo vivamente di rendere idempotente il codice della funzione. Per ulteriori informazioni, consulta [Come posso rendere idempotente la mia funzione Lambda](https://repost.aws/knowledge-center/lambda-function-idempotent) nel Knowledge Center. AWS
**Topics**
+ [
## Esempio di evento Amazon DocumentDB
](#docdb-sample-event)
+ [
## Prerequisiti e autorizzazioni
](#docdb-prereqs)
+ [
## Configurare la sicurezza della rete
](#docdb-network)
+ [
## Creazione di una mappatura dell'origine degli eventi Amazon DocumentDB (console)
](#docdb-configuration)
+ [
## Creazione di una mappatura dell'origine degli eventi Amazon DocumentDB (SDK o CLI)
](#docdb-api)
+ [
## Posizioni di partenza di polling e flussi
](#docdb-stream-polling)
+ [
## Monitoraggio dell'origine degli eventi di Amazon DocumentDB
](#docdb-monitoring)
+ [
# Tutorial: Utilizzo AWS Lambda con Amazon DocumentDB Streams
](with-documentdb-tutorial.md)
## Esempio di evento Amazon DocumentDB
```
{
"eventSourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:canaryclusterb2a659a2-qo5tcmqkcl03",
"events": [
{
"event": {
"_id": {
"_data": "0163eeb6e7000000090100000009000041e1"
},
"clusterTime": {
"$timestamp": {
"t": 1676588775,
"i": 9
}
},
"documentKey": {
"_id": {
"$oid": "63eeb6e7d418cd98afb1c1d7"
}
},
"fullDocument": {
"_id": {
"$oid": "63eeb6e7d418cd98afb1c1d7"
},
"anyField": "sampleValue"
},
"ns": {
"db": "test_database",
"coll": "test_collection"
},
"operationType": "insert"
}
}
],
"eventSource": "aws:docdb"
}
```
Per ulteriori informazioni sugli eventi in questo esempio e sulle loro forme, consulta la sezione [Eventi di modifica](https://www.mongodb.com/docs/manual/reference/change-events/) sul sito Web della documentazione di MongoDB.
## Prerequisiti e autorizzazioni
Prima di utilizzare Amazon DocumentDB come origine degli eventi della funzione Lambda, è necessario tenere a mente i seguenti prerequisiti. Devi:
+ **Disponi di un cluster Amazon DocumentDB esistente nella stessa Account AWS Regione AWS funzione.** Se non hai un cluster esistente, puoi crearlo seguendo i passaggi riportati nella sezione [Nozioni di base su Amazon DocumentDB](https://docs.aws.amazon.com/documentdb/latest/developerguide/get-started-guide.html) nella *Guida per gli sviluppatori di Amazon DocumentDB*. In alternativa, la prima serie di passaggi riportati in [Tutorial: Utilizzo AWS Lambda con Amazon DocumentDB Streams](with-documentdb-tutorial.md) ti guideranno nella creazione di un cluster Amazon DocumentDB con tutti i prerequisiti necessari.
+ **Concedere a Lambda l'accesso alle risorse di Amazon Virtual Private Cloud (Amazon VPC) associate al cluster Amazon DocumentDB.** Per ulteriori informazioni, consulta [Configurare la sicurezza della rete](#docdb-network).
+ **Abilitare TLS sul cluster Amazon DocumentDB.** Questa è l'impostazione predefinita. Se TLS è disabilitato, Lambda non è in grado di comunicare con il cluster.
+ **È necessario attivare i flussi di modifica sul cluster Amazon DocumentDB.** Per ulteriori informazioni, consulta la sezione [Utilizzo dei flussi di modifica di Amazon DocumentDB](https://docs.aws.amazon.com/documentdb/latest/developerguide/change_streams.html) nella *Guida per gli sviluppatori di Amazon DocumentDB*.
+ **Fornire a Lambda le credenziali per accedere al cluster Amazon DocumentDB.** Quando configuri l'origine degli eventi, fornisci la chiave [Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) che contiene i dettagli di autenticazione (nome utente e password) necessari per accedere al cluster. Per fornire questa chiave durante la configurazione, esegui una delle seguenti operazioni:
+ Se per la configurazione stai utilizzando la console Lambda, fornisci la chiave nel campo **Chiave di Secrets manager**.
+ Se utilizzi AWS Command Line Interface (AWS CLI) per la configurazione, fornisci questa chiave nell'`source-access-configurations`opzione. È possibile includere questa opzione sia con il comando [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html) sia con il comando [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-event-source-mapping.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-event-source-mapping.html). Esempio:
```
aws lambda create-event-source-mapping \
...
--source-access-configurations '[{"Type":"BASIC_AUTH","URI":"arn:aws:secretsmanager:us-west-2:123456789012:secret:DocDBSecret-AbC4E6"}]' \
...
```
+ **Concedere a Lambda le autorizzazioni per gestire le risorse correlate al flusso di Amazon DocumentDB.** Aggiungi le seguenti autorizzazioni al [ruolo di esecuzione](lambda-intro-execution-role.md) della tua funzione:
+ [RDS: Descrivi DBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html)
+ [RDS: descrivere i parametri DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusterParameters.html)
+ [RDS: Descrivi DBSubnet i gruppi](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBSubnetGroups.html)
+ [ec2: CreateNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateNetworkInterface.html)
+ [ec2: DescribeNetworkInterfaces](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeNetworkInterfaces.html)
+ [ec2: DescribeVpcs](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpcs.html)
+ [ec2: DeleteNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteNetworkInterface.html)
+ [ec2: DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html)
+ [ec2: DescribeSecurityGroups](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSecurityGroups.html)
+ [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html)
+ [gestore dei segreti: GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html)
+ **È necessario mantenere la dimensione degli eventi del flusso di modifica di Amazon DocumentDB che invii a Lambda inferiore a 6 MB.** Lambda supporta payload di dimensioni massime di 6 MB. Se il flusso di modifica tenta di inviare a Lambda un evento di dimensioni superiori a 6 MB, Lambda tralascia il messaggio ed emette il parametro `OversizedRecordCount`. Lambda emette tutte i parametri sulla base del miglior tentativo.
**Nota**
Sebbene le funzioni Lambda abbiano di solito un timeout massimo di 15 minuti, le mappature dell'origine degli eventi per Amazon MSK, Apache Kafka autogestito, Amazon DocumentDB e Amazon MQ per ActiveMQ e RabbitMQ supportano soltanto funzioni con timeout massimi di 14 minuti. Questa limitazione garantisce che lo strumento di mappatura dell'origine degli eventi possa gestire correttamente errori di funzioni e nuovi tentativi.
## Configurare la sicurezza della rete
Per concedere a Lambda l'accesso completo ad Amazon DocumentDB tramite lo strumento di mappatura dell'origine degli eventi, il cluster deve utilizzare un endpoint pubblico (indirizzo IP pubblico) oppure devi fornire l'accesso all'Amazon VPC in cui hai creato il cluster.
Quando usi Amazon DocumentDB con Lambda, crea [endpoint VPC AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) che forniscono alla funzione l'accesso alle risorse del tuo Amazon VPC.
**Nota**
AWS PrivateLink Gli endpoint VPC sono necessari per le funzioni con mappature delle sorgenti degli eventi che utilizzano la modalità predefinita (su richiesta) per i poller degli eventi. Se la mappatura delle sorgenti degli eventi utilizza la [modalità provisioning](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode), non è necessario configurare gli endpoint VPC AWS PrivateLink .
Crea un endpoint per fornire l'accesso alle seguenti risorse:
+ Lambda: crea un endpoint per il principale del servizio Lambda.
+ AWS STS — Crea un endpoint per consentire AWS STS a un responsabile del servizio di assumere un ruolo per tuo conto.
+ Secrets Manager: se il tuo cluster utilizza Secrets Manager per archiviare le credenziali, crea un endpoint per Secrets Manager.
In alternativa, configura un gateway NAT su ogni sottorete pubblica in Amazon VPC. Per ulteriori informazioni, consulta [Abilitare l'accesso a Internet per funzioni Lambda connesse a un VPC](configuration-vpc-internet.md).
Quando crei una mappatura delle sorgenti di eventi per Amazon DocumentDB, Lambda verifica se Elastic Network Interfaces ENIs () sono già presenti per le sottoreti e i gruppi di sicurezza configurati per il tuo Amazon VPC. Se Lambda rileva che esistono ENIs, tenta di riutilizzarli. Altrimenti, Lambda ne crea di nuovi ENIs per connettersi all'origine dell'evento e richiamare la funzione.
**Nota**
Le funzioni Lambda vengono sempre eseguite all'interno del servizio Lambda di VPCs proprietà. La configurazione VPC della funzione non influisce sullo strumento di mappatura dell'origine degli eventi. Solo la configurazione di rete dell'origine dell'evento determina il modo in cui Lambda si connette all'origine dell'evento.
Configura i gruppi di sicurezza per l'Amazon VPC contenente il tuo cluster. Per impostazione predefinita, Amazon DocumentDB utilizza le seguenti porte: `27017`.
+ Regole in ingresso: consenti tutto il traffico sulla porta del broker predefinita per il gruppo di sicurezza associato all'origine eventi. In alternativa, puoi utilizzare una regola del gruppo di sicurezza autoreferenziante per consentire l'accesso da istanze all'interno dello stesso gruppo di sicurezza.
+ Regole in uscita: consentono tutto il traffico sulla porta `443` per destinazioni esterne se la funzione deve comunicare con i servizi. AWS In alternativa, puoi anche utilizzare una regola del gruppo di sicurezza autoreferenziale per limitare l'accesso al broker se non hai bisogno di comunicare con altri servizi. AWS
+ Regole di ingresso degli endpoint Amazon VPC: se utilizzi un endpoint Amazon VPC, il gruppo di sicurezza associato all'endpoint Amazon VPC deve consentire il traffico in entrata sulla porta `443` dal gruppo di sicurezza del cluster.
Se il cluster utilizza l'autenticazione, puoi anche limitare la policy degli endpoint per l'endpoint Secrets Manager. Per chiamare l'API Secrets Manager, Lambda utilizza il ruolo della funzione, non il principale del servizio Lambda.
**Example Policy dell'endpoint VPC: endpoint Secrets Manager**
```
{
"Statement": [
{
"Action": "secretsmanager:GetSecretValue",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws::iam::123456789012:role/my-role"
]
},
"Resource": "arn:aws::secretsmanager:us-west-2:123456789012:secret:my-secret"
}
]
}
```
Quando utilizzi gli endpoint Amazon VPC, AWS indirizza le chiamate API per richiamare la tua funzione utilizzando l'Elastic Network Interface (ENI) dell'endpoint. Il responsabile del servizio Lambda deve `lambda:InvokeFunction` richiamare tutti i ruoli e le funzioni che li utilizzano. ENIs
Per impostazione predefinita, gli endpoint Amazon VPC dispongono di policy IAM aperte che consentono un ampio accesso alle risorse. La best practice consiste nel limitare queste policy per eseguire le azioni necessarie utilizzando quell'endpoint. Per garantire che lo strumento di mappatura dell'origine degli eventi sia in grado di invocare la funzione Lambda, la policy degli endpoint VPC deve consentire al principale del servizio Lambda di chiamare `sts:AssumeRole` e `lambda:InvokeFunction`. Limitare le policy degli endpoint VPC per consentire solo le chiamate API provenienti dall'organizzazione impedisce il corretto funzionamento dello strumento di mappatura dell'origine degli eventi, pertanto `"Resource": "*"` è richiesto in queste policy.
Il seguente esempio di policy degli endpoint VPC mostra come concedere l'accesso richiesto al principale del servizio Lambda per gli endpoint AWS STS e Lambda.
**Example Policy VPC Endpoint — endpoint AWS STS**
```
{
"Statement": [
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
**Example Policy dell'endpoint VPC: endpoint Lambda**
```
{
"Statement": [
{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
## Creazione di una mappatura dell'origine degli eventi Amazon DocumentDB (console)
Per configurare una funzione Lambda per la lettura dal flusso di modifica di un cluster Amazon DocumentDB, crea una [mappatura dell'origine degli eventi](invocation-eventsourcemapping.md). In questa sezione viene descritto come eseguire questa operazione dalla console Lambda. Per AWS SDK e AWS CLI istruzioni, consulta. [Creazione di una mappatura dell'origine degli eventi Amazon DocumentDB (SDK o CLI)](#docdb-api)
**Creazione di una mappatura dell'origine degli eventi per Amazon DocumentDB (console)**
1. Aprire la pagina [Functions](https://console.aws.amazon.com/lambda/home#/functions) (Funzioni) della console Lambda.
1. Scegliere il nome della funzione.
1. In **Function overview** (Panoramica delle funzioni), scegliere **Add trigger** (Aggiungi trigger).
1. In **Configurazione del trigger**, nell'elenco a discesa, scegli **DocumentDB**.
1. Configurare le opzioni richieste, quindi scegliere **Add (Aggiungi)**.
Lambda supporta le seguenti opzioni per le origini degli eventi Amazon DocumentDB:
+ **Cluster DocumentDB**: seleziona un cluster Amazon DocumentDB.
+ **Attiva il trigger**: seleziona l'opzione se vuoi attivare il trigger immediatamente. Se selezioni questa casella, la funzione inizia immediatamente a ricevere traffico dal flusso di modifica specificato di Amazon DocumentDB al momento della creazione della mappatura dell'origine degli eventi. Ai fini del test, è preferibile deselezionare la casella in modo da creare una mappatura dell'origine degli eventi non attiva. Dopo la creazione, puoi attivare lo strumento di mappatura dell'origine degli eventi in qualsiasi momento.
+ **Nome database:** immetti il nome di un database da utilizzare nel cluster.
+ (Facoltativo) **Nome della raccolta**: immetti il nome di una raccolta da utilizzare nel database. Se non specifichi una raccolta, Lambda ascolta tutti gli eventi di ciascuna raccolta del database.
+ **Dimensioni batch: ** imposta, fino a 10.000, il numero massimo di messaggi da recuperare in un singolo batch. La dimensione predefinita del batch è pari a 100.
+ **Posizione iniziale:** scegli la posizione del flusso da cui iniziare a leggere i record.
+ **Ultimi**: elabora solo i nuovi record aggiunti al flusso. La funzione inizia a elaborare i record solo dopo che Lambda ha terminato la creazione dell'origine degli eventi. Ciò significa che alcuni record potrebbero essere tralasciati fino a quando l'origine degli eventi non viene creata correttamente.
+ **Trim Horizon (Orizzonte di taglio):** elabora tutti i record contenuti nel flusso. Lambda utilizza la durata di conservazione dei log del tuo cluster per stabilire da dove iniziare a leggere gli eventi. In particolare Lambda inizia a leggere da `current_time - log_retention_duration`. Il flusso di modifica deve essere già attivo prima di questo timestamp affinché Lambda legga tutti gli eventi correttamente.
+ **At timestamp (Al timestamp)**: elaborare record a partire da una determinata ora. Il flusso di modifica deve essere già attivo prima del timestamp specificato affinché Lambda legga tutti gli eventi correttamente.
+ .**Autenticazione:** scegli il metodo di autenticazione per l'accesso dei broker al cluster.
+ **BASIC\$1AUTH:** con l'autenticazione di base è necessario fornire la chiave Secrets Manager che contiene le credenziali per accedere al cluster.
+ **Chiave Secrets Manager**: scegli la chiave Secrets Manager che contiene i dettagli di autenticazione (nome utente e password) necessari per accedere al cluster Amazon DocumentDB.
+ (Facoltativo) **Finestra batch**: specifica il tempo massimo, espresso in secondi fino a un massimo di 300, per la raccolta dei record prima che la funzione venga richiamata.
+ (Facoltativo) **Configurazione completa del documento**: per le operazioni di aggiornamento del documento, scegli che cosa inviare al flusso. Il valore predefinito è `Default`, il che significa che Amazon DocumentDB invia solo un delta che descrive le modifiche apportate per ogni evento del flusso di modifica. Per ulteriori informazioni su questo campo, consulta la documentazione dell'[FullDocument](https://mongodb.github.io/mongo-java-driver/3.9/javadoc/com/mongodb/client/model/changestream/FullDocument.html#DEFAULT)API Javadoc di MongoDB.
+ **Impostazione predefinita:** Lambda invia solo un documento parziale che descrive le modifiche apportate.
+ **UpdateLookup**— Lambda invia un delta che descrive le modifiche, insieme a una copia dell'intero documento.
## Creazione di una mappatura dell'origine degli eventi Amazon DocumentDB (SDK o CLI)
Per creare o gestire una mappatura dell'origine degli eventi Amazon DocumentDB tramite un [SDK AWS](https://aws.amazon.com/developer/tools/), puoi utilizzare le seguenti operazioni dell'API:
+ [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)
+ [ListEventSourceMappings](https://docs.aws.amazon.com/lambda/latest/api/API_ListEventSourceMappings.html)
+ [GetEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_GetEventSourceMapping.html)
+ [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)
+ [DeleteEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteEventSourceMapping.html)
Per creare la mappatura della sorgente degli eventi con AWS CLI, usa il comando. [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html) L'esempio seguente utilizza questo comando per mappare una funzione denominata `my-function` a un flusso di modifica Amazon DocumentDB. L'origine degli eventi è indicata da un nome della risorsa Amazon (ARN), con una dimensione batch di 500, a partire dal timestamp in formato Unix. Il comando specifica anche la chiave Secrets Manager che Lambda utilizza per connettersi ad Amazon DocumentDB. Inoltre, include `document-db-event-source-config` parametri che specificano il database e la raccolta da cui leggere.
```
aws lambda create-event-source-mapping --function-name my-function \
--event-source-arn arn:aws:rds:us-west-2:123456789012:cluster:privatecluster7de2-epzcyvu4pjoy
--batch-size 500 \
--starting-position AT_TIMESTAMP \
--starting-position-timestamp 1541139109 \
--source-access-configurations '[{"Type":"BASIC_AUTH","URI":"arn:aws:secretsmanager:us-east-1:123456789012:secret:DocDBSecret-BAtjxi"}]' \
--document-db-event-source-config '{"DatabaseName":"test_database", "CollectionName": "test_collection"}' \
```
L'output visualizzato dovrebbe essere di questo tipo:
```
{
"UUID": "2b733gdc-8ac3-cdf5-af3a-1827b3b11284",
"BatchSize": 500,
"DocumentDBEventSourceConfig": {
"CollectionName": "test_collection",
"DatabaseName": "test_database",
"FullDocument": "Default"
},
"MaximumBatchingWindowInSeconds": 0,
"EventSourceArn": "arn:aws:rds:us-west-2:123456789012:cluster:privatecluster7de2-epzcyvu4pjoy",
"FunctionArn": "arn:aws:lambda:us-west-2:123456789012:function:my-function",
"LastModified": 1541348195.412,
"LastProcessingResult": "No records processed",
"State": "Creating",
"StateTransitionReason": "User action"
}
```
Dopo la creazione, puoi utilizzare il comando [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-event-source-mapping.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-event-source-mapping.html) per modificare le impostazioni di aggiornamento relative all'origine degli eventi di Amazon DocumentDB. Nell'esempio seguente, la dimensione del batch viene aggiornata a 1.000 e la finestra batch a 10 secondi. Per questo comando è necessario l'UUID della mappatura dell'origine degli eventi, recuperabile utilizzando il comando `list-event-source-mapping` o dalla console Lambda.
```
aws lambda update-event-source-mapping --function-name my-function \
--uuid f89f8514-cdd9-4602-9e1f-01a5b77d449b \
--batch-size 1000 \
--batch-window 10
```
L'output visualizzato dovrebbe essere di questo tipo:
```
{
"UUID": "2b733gdc-8ac3-cdf5-af3a-1827b3b11284",
"BatchSize": 500,
"DocumentDBEventSourceConfig": {
"CollectionName": "test_collection",
"DatabaseName": "test_database",
"FullDocument": "Default"
},
"MaximumBatchingWindowInSeconds": 0,
"EventSourceArn": "arn:aws:rds:us-west-2:123456789012:cluster:privatecluster7de2-epzcyvu4pjoy",
"FunctionArn": "arn:aws:lambda:us-west-2:123456789012:function:my-function",
"LastModified": 1541359182.919,
"LastProcessingResult": "OK",
"State": "Updating",
"StateTransitionReason": "User action"
}
```
Lambda aggiorna le impostazioni in modo asincrono, pertanto potresti non essere in grado di visualizzare queste modifiche nell'output fino al completamento del processo. Per visualizzare le impostazioni correnti della mappatura dell'origine degli eventi, utilizza il comando [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/get-event-source-mapping.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/get-event-source-mapping.html).
```
aws lambda get-event-source-mapping --uuid f89f8514-cdd9-4602-9e1f-01a5b77d449b
```
L'output visualizzato dovrebbe essere di questo tipo:
```
{
"UUID": "2b733gdc-8ac3-cdf5-af3a-1827b3b11284",
"DocumentDBEventSourceConfig": {
"CollectionName": "test_collection",
"DatabaseName": "test_database",
"FullDocument": "Default"
},
"BatchSize": 1000,
"MaximumBatchingWindowInSeconds": 10,
"EventSourceArn": "arn:aws:rds:us-west-2:123456789012:cluster:privatecluster7de2-epzcyvu4pjoy",
"FunctionArn": "arn:aws:lambda:us-west-2:123456789012:function:my-function",
"LastModified": 1541359182.919,
"LastProcessingResult": "OK",
"State": "Enabled",
"StateTransitionReason": "User action"
}
```
Per eliminare la mappatura dell'origine degli eventi di Amazon DocumentDB, utilizza il comando [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/delete-event-source-mapping.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/delete-event-source-mapping.html):
```
aws lambda delete-event-source-mapping \
--uuid 2b733gdc-8ac3-cdf5-af3a-1827b3b11284
```
## Posizioni di partenza di polling e flussi
Tieni presente che il polling dei flussi durante la creazione e gli aggiornamenti dello strumento di mappatura dell’origine degli eventi alla fine è coerente.
+ Durante la creazione dello strumento di mappatura dell'origine degli eventi, potrebbero essere necessari alcuni minuti per l'avvio degli eventi di polling dal flusso.
+ Durante gli aggiornamenti dello strumento di mappatura dell'origine degli eventi, potrebbero essere necessari alcuni minuti per l'avvio degli eventi di polling dal flusso.
Questo comportamento implica che se specifichi `LATEST` come posizione iniziale del flusso, lo strumento di mappatura dell'origine degli eventi potrebbe perdere eventi durante la creazione o gli aggiornamenti. Per non perdere alcun evento, specifica la posizione iniziale del flusso come `TRIM_HORIZON` o `AT_TIMESTAMP`.
## Monitoraggio dell'origine degli eventi di Amazon DocumentDB
Per aiutarti a monitorare l'origine degli eventi Amazon DocumentDB, Lambda emette il parametro `IteratorAge` quando la funzione termina l'elaborazione di un batch di record. L'*età dell'iteratore* è la differenza tra il timestamp dell'evento più recente e il timestamp corrente. Sostanzialmente, il parametro `IteratorAge` indica l'età dell'ultimo record elaborato nel batch. Se la funzione continua a elaborare nuovi eventi, puoi utilizzare la cronologia di iterazione per stimare la latenza tra il momento in cui un record viene aggiunto e il momento in cui viene elaborato dalla tua funzione. Una tendenza in aumento in `IteratorAge` può indicare problemi con la funzione. Per ulteriori informazioni, consulta [Utilizzo dei parametri di CloudWatch Logs con Lambda](monitoring-metrics.md).
I flussi di modifiche di Amazon DocumentDB non sono ottimizzati per gestire ampi intervalli di tempo tra gli eventi. Se l'origine eventi Amazon DocumentDB non riceve alcun evento per un periodo di tempo prolungato, Lambda può disabilitare lo strumento di mappatura dell'origine degli eventi. La durata di questo periodo di tempo può variare da alcune settimane a qualche mese a seconda delle dimensioni del cluster e di altri carichi di lavoro.
Lambda supporta payload di dimensioni massime di 6 MB. Tuttavia, gli eventi del flusso di modifica di Amazon DocumentDB possono avere dimensioni fino a 16 MB. Se il flusso di modifica tenta di inviare a Lambda un evento di flusso di modifica di dimensioni superiori a 6 MB, Lambda tralascia il messaggio ed emette il parametro `OversizedRecordCount`. Lambda emette tutti i parametri sulla base del miglior tentativo.
# Tutorial: Utilizzo AWS Lambda con Amazon DocumentDB Streams
In questo tutorial creerai una funzione Lambda di base che utilizza gli eventi provenienti da un flusso di modifica Amazon DocumentDB (compatibile con MongoDB). Per completare questo tutorial, saranno completate le seguenti fasi:
+ Configura il tuo cluster Amazon DocumentDB, connettiti a esso e attiva i flussi di modifica su di esso.
+ Crea la funzione Lambda e configura il cluster Amazon DocumentDB come origine degli eventi Amazon DocumentDB come origine degli eventi per la funzione.
+ Verifica la configurazione inserendo elementi nel tuo database Amazon DocumentDB.
## Creare il cluster Amazon DocumentDB
1. Apri la [console Amazon DocumentDB](https://console.aws.amazon.com/docdb/home#). In **Cluster**, scegli **Crea**.
1. Crea un cluster con la seguente configurazione:
+ Per **Tipo di cluster**, scegli **Cluster basato su istanze**. Questa è l'opzione predefinita.
+ In **Configurazione del cluster**, assicurati che sia selezionata la **versione 5.0.0 del motore**. Questa è l'opzione predefinita.
+ In **Configurazione dell'istanza**:
+ Per la **classe di istanza DB**, seleziona **Classi ottimizzate per la memoria**. Questa è l'opzione predefinita.
+ Per **Numero di istanze di replica regolari**, scegli 1.
+ Per la **classe Instance**, usa la selezione predefinita.
+ In **Autenticazione**, inserisci un nome utente per l'utente principale, quindi scegli **Autogestito**. Inserisci una password, quindi confermala.
+ Mantieni tutte le altre impostazioni predefinite.
1. Scegli **Crea cluster**.
## Creazione del segreto di Gestione dei segreti
Mentre Amazon DocumentDB crea il tuo cluster, crea un Gestione dei segreti AWS segreto per archiviare le credenziali del database. Fornirai questo segreto quando creerai la mappatura delle sorgenti degli eventi Lambda in un passaggio successivo.
**Creazione del segreto in Gestione dei segreti**
1. Apri la console [Gestione dei segreti](https://console.aws.amazon.com/secretsmanager/home#) e scegli **Archivia un nuovo segreto**.
1. In **Scegli il tipo di segreto**, scegli una delle seguenti opzioni:
+ In **Dettagli di base**:
+ **Tipo di segreto**: credenziali per il database Amazon DocumentDB
+ In **Credenziali**, inserisci lo stesso nome utente e la stessa password che hai usato per creare il tuo cluster Amazon DocumentDB.
+ **Database**: scegli il tuo cluster Amazon DocumentDB.
+ Scegli **Next (Successivo)**.
1. Per **Configura segreto**, scegli tra le seguenti opzioni:
+ **Nome segreto**: `DocumentDBSecret`
+ Scegli **Next (Successivo)**.
1. Scegli **Next (Successivo)**.
1. Scegli **Store**.
1. Aggiorna la console per verificare di aver archiviato correttamente il segreto `DocumentDBSecret`.
Nota l'**ARN segreto**. Lo utilizzerai in un passaggio successivo.
## Connessione al cluster
**Connettiti al tuo cluster Amazon DocumentDB tramite AWS CloudShell**
1. Nella console di gestione di Amazon DocumentDB, in **Clusters**, individua il cluster che hai creato. Scegli il tuo cluster facendo clic sulla casella di controllo accanto ad esso.
1. Scegli **Connect to cluster**. Viene visualizzata la schermata **di comando CloudShell Esegui**.
1. Nel campo **Nuovo nome dell'ambiente**, inserisci un nome univoco, ad esempio «test» e scegli **Crea ed esegui**.
1. Specifica la password, quando richiesto. Quando viene richiesto`rs0 [direct: primary] >`, la connessione al cluster Amazon DocumentDB è avvenuta correttamente.
## Attivazione dei flussi di modifica
Per questo tutorial, monitorerai le modifiche alla raccolta di `products` del database `docdbdemo` nel cluster Amazon DocumentDB. Puoi farlo attivando i [flussi di modifica](https://docs.aws.amazon.com/documentdb/latest/developerguide/change_streams.html).
**Creazione di un nuovo database all'interno del cluster**
1. Esegui il seguente comando per creare un nuovo database chiamato: `docdbdemo`
```
use docdbdemo
```
1. Nella finestra del terminale, utilizzate il seguente comando per inserire un record in`docdbdemo`:
```
db.products.insertOne({"hello":"world"})
```
Dovresti vedere un output come questo:
```
{
acknowledged: true,
insertedId: ObjectId('67f85066ca526410fd531d59')
}
```
1. Quindi, attiva i flussi di modifica sulla raccolta `products` del database `docdbdemo` utilizzando il comando seguente:
```
db.adminCommand({modifyChangeStreams: 1,
database: "docdbdemo",
collection: "products",
enable: true});
```
L'output visualizzato dovrebbe essere di questo tipo:
```
{ "ok" : 1, "operationTime" : Timestamp(1680126165, 1) }
```
## Creazione di endpoint VPC dell'interfaccia
Successivamente, crea gli [endpoint VPC di interfaccia](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws) per garantire che Lambda e Gestione dei segreti (utilizzati in seguito per archiviare le credenziali di accesso al cluster) possano connettersi al tuo VPC predefinito.
**Creazione di endpoint VPC dell'interfaccia**
1. Apri la [console VPC](https://console.aws.amazon.com/vpc/home#). Nel menu a sinistra, in **Cloud privato virtuale**, scegli **Endpoint**.
1. Seleziona **Crea endpoint**. Crea un endpoint con la seguente configurazione:
+ Per **Nome tag**, inserisci `lambda-default-vpc`.
+ Per la **categoria di servizi**, scegli AWS servizi.
+ Per **Servizi**, digita `lambda` nella casella di ricerca. Scegli il servizio con il formato `com.amazonaws..lambda`.
+ Per **VPC, scegli il VPC** in cui si trova il tuo cluster Amazon DocumentDB. Si tratta in genere del [VPC predefinito](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html).
+ Per **Sottoreti**, seleziona le caselle accanto a ciascuna zona di disponibilità. Scegli l'ID della sottorete corretta per ogni zona di disponibilità.
+ Per il **tipo di indirizzo IP**, selezionare IPv4.
+ Per i **gruppi di sicurezza**, scegli il gruppo di sicurezza utilizzato dal tuo cluster Amazon DocumentDB. Questo è in genere il gruppo `default` di sicurezza.
+ Mantieni tutte le altre impostazioni predefinite.
+ Seleziona **Crea endpoint**.
1. Seleziona di nuovo **Crea endpoint**. Crea un endpoint con la seguente configurazione:
+ Per **Nome tag**, inserisci `secretsmanager-default-vpc`.
+ Per la **categoria di servizi**, scegli AWS servizi.
+ Per **Servizi**, digita `secretsmanager` nella casella di ricerca. Scegli il servizio con il formato `com.amazonaws..secretsmanager`.
+ Per **VPC, scegli il VPC** in cui si trova il tuo cluster Amazon DocumentDB. Si tratta in genere del [VPC predefinito](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html).
+ Per **Sottoreti**, seleziona le caselle accanto a ciascuna zona di disponibilità. Scegli l'ID della sottorete corretta per ogni zona di disponibilità.
+ Per il **tipo di indirizzo IP**, selezionare IPv4.
+ Per i **gruppi di sicurezza**, scegli il gruppo di sicurezza utilizzato dal tuo cluster Amazon DocumentDB. Questo è in genere il gruppo `default` di sicurezza.
+ Mantieni tutte le altre impostazioni predefinite.
+ Seleziona **Crea endpoint**.
Questo completa la sezione del tutorial dedicata alla configurazione del cluster.
## Creazione del ruolo di esecuzione
Nella serie di passaggi successiva, creerai la funzione Lambda. Innanzitutto, devi creare il ruolo di esecuzione che fornisce alla funzione l'autorizzazione per accedere al cluster. Per farlo, creerai prima una policy IAM, dopodiché la collegherai a un ruolo IAM.
**Creazione di una policy IAM**
1. Nella console IAM, apri la pagina [Policy](https://console.aws.amazon.com/iam/home#/policies), quindi scegli **Crea policy**.
1. Scegli la scheda **JSON**. Nella policy seguente, sostituisci l'ARN della risorsa Gestione dei segreti nell'ultima riga dell'istruzione con l'ARN del segreto utilizzato in precedenza e copia la policy nell'editor.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "LambdaESMNetworkingAccess",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeVpcs",
"ec2:DeleteNetworkInterface",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups",
"kms:Decrypt"
],
"Resource": "*"
},
{
"Sid": "LambdaDocDBESMAccess",
"Effect": "Allow",
"Action": [
"rds:DescribeDBClusters",
"rds:DescribeDBClusterParameters",
"rds:DescribeDBSubnetGroups"
],
"Resource": "*"
},
{
"Sid": "LambdaDocDBESMGetSecretValueAccess",
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:DocumentDBSecret"
}
]
}
```
------
1. Scegli **Successivo: Tag**, quindi **Successivo: Verifica**.
1. In **Nome**, inserisci `AWSDocumentDBLambdaPolicy`.
1. Scegli **Create Policy (Crea policy)**.
**Per creare il ruolo IAM**
1. Nella console IAM, apri la pagina [Ruoli](https://console.aws.amazon.com/iam/home#/roles), quindi scegli **Crea ruolo**.
1. Per **Seleziona un'entità attendibile**, scegli le seguenti opzioni:
+ **Tipo di entità affidabile**: AWS servizio
+ **Servizio o caso d'uso**: Lambda
+ Scegli **Next (Successivo)**.
1. Per **Aggiungi autorizzazioni**, scegli la `AWSDocumentDBLambdaPolicy` policy che hai appena creato e `AWSLambdaBasicExecutionRole` autorizza la funzione a scrivere su Amazon CloudWatch Logs.
1. Scegli **Next (Successivo)**.
1. Per **Nome ruolo**, inserisci `AWSDocumentDBLambdaExecutionRole`.
1. Scegli **Crea ruolo**.
## Creazione della funzione Lambda
Questo tutorial utilizza il runtime di Python 3.14, ma abbiamo anche fornito file di codice di esempio per altri runtime. Per visualizzare il codice per il runtime che ti interessa, seleziona la scheda corrispondente nella casella seguente.
Il codice riceve l'input di un evento Amazon DocumentDB ed elabora il messaggio in esso contenuto.
**Creazione della funzione Lambda**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegli **Crea funzione**.
1. Scegli **Crea da zero**.
1. In **Basic information (Informazioni di base)** eseguire queste operazioni:
1. Nel campo **Nome funzione**, inserisci `ProcessDocumentDBRecords`.
1. Per **Runtime**, scegli **Python 3.14**.
1. In **Architecture** (Architettura), scegli **x86\$164**.
1. Nella scheda **Modifica ruolo di esecuzione predefinito**, effettua le seguenti operazioni:
1. Espandi la scheda, quindi scegli **Utilizza un ruolo esistente**.
1. Seleziona il `AWSDocumentDBLambdaExecutionRole` che hai creato in precedenza.
1. Scegli **Crea funzione**.
**Implementazione del codice della funzione**
1. Scegli la scheda **Python** nella casella seguente e copia il codice.
------
#### [ .NET ]
**SDK per .NET**
C'è di più su. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-docdb-to-lambda).
Utilizzo di un evento Amazon DocumentDB con Lambda tramite .NET.
```
using Amazon.Lambda.Core;
using System.Text.Json;
using System;
using System.Collections.Generic;
using System.Text.Json.Serialization;
//Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace LambdaDocDb;
public class Function
{
///
/// Lambda function entry point to process Amazon DocumentDB events.
///
/// The Amazon DocumentDB event.
/// The Lambda context object.
/// A string to indicate successful processing.
public string FunctionHandler(Event evnt, ILambdaContext context)
{
foreach (var record in evnt.Events)
{
ProcessDocumentDBEvent(record, context);
}
return "OK";
}
private void ProcessDocumentDBEvent(DocumentDBEventRecord record, ILambdaContext context)
{
var eventData = record.Event;
var operationType = eventData.OperationType;
var databaseName = eventData.Ns.Db;
var collectionName = eventData.Ns.Coll;
var fullDocument = JsonSerializer.Serialize(eventData.FullDocument, new JsonSerializerOptions { WriteIndented = true });
context.Logger.LogLine($"Operation type: {operationType}");
context.Logger.LogLine($"Database: {databaseName}");
context.Logger.LogLine($"Collection: {collectionName}");
context.Logger.LogLine($"Full document:\n{fullDocument}");
}
public class Event
{
[JsonPropertyName("eventSourceArn")]
public string EventSourceArn { get; set; }
[JsonPropertyName("events")]
public List Events { get; set; }
[JsonPropertyName("eventSource")]
public string EventSource { get; set; }
}
public class DocumentDBEventRecord
{
[JsonPropertyName("event")]
public EventData Event { get; set; }
}
public class EventData
{
[JsonPropertyName("_id")]
public IdData Id { get; set; }
[JsonPropertyName("clusterTime")]
public ClusterTime ClusterTime { get; set; }
[JsonPropertyName("documentKey")]
public DocumentKey DocumentKey { get; set; }
[JsonPropertyName("fullDocument")]
public Dictionary FullDocument { get; set; }
[JsonPropertyName("ns")]
public Namespace Ns { get; set; }
[JsonPropertyName("operationType")]
public string OperationType { get; set; }
}
public class IdData
{
[JsonPropertyName("_data")]
public string Data { get; set; }
}
public class ClusterTime
{
[JsonPropertyName("$timestamp")]
public Timestamp Timestamp { get; set; }
}
public class Timestamp
{
[JsonPropertyName("t")]
public long T { get; set; }
[JsonPropertyName("i")]
public int I { get; set; }
}
public class DocumentKey
{
[JsonPropertyName("_id")]
public Id Id { get; set; }
}
public class Id
{
[JsonPropertyName("$oid")]
public string Oid { get; set; }
}
public class Namespace
{
[JsonPropertyName("db")]
public string Db { get; set; }
[JsonPropertyName("coll")]
public string Coll { get; set; }
}
}
```
------
#### [ Go ]
**SDK per Go V2**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-docdb-to-lambda).
Utilizzo di un evento Amazon DocumentDB con Lambda tramite Go.
```
package main
import (
"context"
"encoding/json"
"fmt"
"github.com/aws/aws-lambda-go/lambda"
)
type Event struct {
Events []Record `json:"events"`
}
type Record struct {
Event struct {
OperationType string `json:"operationType"`
NS struct {
DB string `json:"db"`
Coll string `json:"coll"`
} `json:"ns"`
FullDocument interface{} `json:"fullDocument"`
} `json:"event"`
}
func main() {
lambda.Start(handler)
}
func handler(ctx context.Context, event Event) (string, error) {
fmt.Println("Loading function")
for _, record := range event.Events {
logDocumentDBEvent(record)
}
return "OK", nil
}
func logDocumentDBEvent(record Record) {
fmt.Printf("Operation type: %s\n", record.Event.OperationType)
fmt.Printf("db: %s\n", record.Event.NS.DB)
fmt.Printf("collection: %s\n", record.Event.NS.Coll)
docBytes, _ := json.MarshalIndent(record.Event.FullDocument, "", " ")
fmt.Printf("Full document: %s\n", string(docBytes))
}
```
------
#### [ Java ]
**SDK per Java 2.x**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-docdb-to-lambda).
Utilizzo di un evento Amazon DocumentDB con Lambda tramite Java.
```
import java.util.List;
import java.util.Map;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
public class Example implements RequestHandler, String> {
@SuppressWarnings("unchecked")
@Override
public String handleRequest(Map event, Context context) {
List> events = (List>) event.get("events");
for (Map record : events) {
Map eventData = (Map) record.get("event");
processEventData(eventData);
}
return "OK";
}
@SuppressWarnings("unchecked")
private void processEventData(Map eventData) {
String operationType = (String) eventData.get("operationType");
System.out.println("operationType: %s".formatted(operationType));
Map ns = (Map) eventData.get("ns");
String db = (String) ns.get("db");
System.out.println("db: %s".formatted(db));
String coll = (String) ns.get("coll");
System.out.println("coll: %s".formatted(coll));
Map fullDocument = (Map) eventData.get("fullDocument");
System.out.println("fullDocument: %s".formatted(fullDocument));
}
}
```
------
#### [ JavaScript ]
**SDK per JavaScript (v3)**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-docdb-to-lambda).
Consumo di un evento Amazon DocumentDB con Lambda utilizzando. JavaScript
```
console.log('Loading function');
exports.handler = async (event, context) => {
event.events.forEach(record => {
logDocumentDBEvent(record);
});
return 'OK';
};
const logDocumentDBEvent = (record) => {
console.log('Operation type: ' + record.event.operationType);
console.log('db: ' + record.event.ns.db);
console.log('collection: ' + record.event.ns.coll);
console.log('Full document:', JSON.stringify(record.event.fullDocument, null, 2));
};
```
Consumo di un evento Amazon DocumentDB con Lambda utilizzando TypeScript
```
import { DocumentDBEventRecord, DocumentDBEventSubscriptionContext } from 'aws-lambda';
console.log('Loading function');
export const handler = async (
event: DocumentDBEventSubscriptionContext,
context: any
): Promise => {
event.events.forEach((record: DocumentDBEventRecord) => {
logDocumentDBEvent(record);
});
return 'OK';
};
const logDocumentDBEvent = (record: DocumentDBEventRecord): void => {
console.log('Operation type: ' + record.event.operationType);
console.log('db: ' + record.event.ns.db);
console.log('collection: ' + record.event.ns.coll);
console.log('Full document:', JSON.stringify(record.event.fullDocument, null, 2));
};
```
------
#### [ PHP ]
**SDK per PHP**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-docdb-to-lambda).
Utilizzo di un evento Amazon DocumentDB con Lambda tramite PHP.
```
logDocumentDBEvent($record['event']);
}
return 'OK';
}
private function logDocumentDBEvent($event): void
{
// Extract information from the event record
$operationType = $event['operationType'] ?? 'Unknown';
$db = $event['ns']['db'] ?? 'Unknown';
$collection = $event['ns']['coll'] ?? 'Unknown';
$fullDocument = $event['fullDocument'] ?? [];
// Log the event details
echo "Operation type: $operationType\n";
echo "Database: $db\n";
echo "Collection: $collection\n";
echo "Full document: " . json_encode($fullDocument, JSON_PRETTY_PRINT) . "\n";
}
}
return new DocumentDBEventHandler();
```
------
#### [ Python ]
**SDK per Python (Boto3)**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-docdb-to-lambda).
Utilizzo di un evento Amazon DocumentDB con Lambda tramite Python.
```
import json
def lambda_handler(event, context):
for record in event.get('events', []):
log_document_db_event(record)
return 'OK'
def log_document_db_event(record):
event_data = record.get('event', {})
operation_type = event_data.get('operationType', 'Unknown')
db = event_data.get('ns', {}).get('db', 'Unknown')
collection = event_data.get('ns', {}).get('coll', 'Unknown')
full_document = event_data.get('fullDocument', {})
print(f"Operation type: {operation_type}")
print(f"db: {db}")
print(f"collection: {collection}")
print("Full document:", json.dumps(full_document, indent=2))
```
------
#### [ Ruby ]
**SDK per Ruby**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-docdb-to-lambda).
Utilizzo di un evento Amazon DocumentDB con Lambda tramite Ruby.
```
require 'json'
def lambda_handler(event:, context:)
event['events'].each do |record|
log_document_db_event(record)
end
'OK'
end
def log_document_db_event(record)
event_data = record['event'] || {}
operation_type = event_data['operationType'] || 'Unknown'
db = event_data.dig('ns', 'db') || 'Unknown'
collection = event_data.dig('ns', 'coll') || 'Unknown'
full_document = event_data['fullDocument'] || {}
puts "Operation type: #{operation_type}"
puts "db: #{db}"
puts "collection: #{collection}"
puts "Full document: #{JSON.pretty_generate(full_document)}"
end
```
------
#### [ Rust ]
**SDK per Rust**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-docdb-to-lambda).
Utilizzo di un evento Amazon DocumentDB con Lambda tramite Ruby.
```
use lambda_runtime::{service_fn, tracing, Error, LambdaEvent};
use aws_lambda_events::{
event::documentdb::{DocumentDbEvent, DocumentDbInnerEvent},
};
// Built with the following dependencies:
//lambda_runtime = "0.11.1"
//serde_json = "1.0"
//tokio = { version = "1", features = ["macros"] }
//tracing = { version = "0.1", features = ["log"] }
//tracing-subscriber = { version = "0.3", default-features = false, features = ["fmt"] }
//aws_lambda_events = "0.15.0"
async fn function_handler(event: LambdaEvent) ->Result<(), Error> {
tracing::info!("Event Source ARN: {:?}", event.payload.event_source_arn);
tracing::info!("Event Source: {:?}", event.payload.event_source);
let records = &event.payload.events;
if records.is_empty() {
tracing::info!("No records found. Exiting.");
return Ok(());
}
for record in records{
log_document_db_event(record);
}
tracing::info!("Document db records processed");
// Prepare the response
Ok(())
}
fn log_document_db_event(record: &DocumentDbInnerEvent)-> Result<(), Error>{
tracing::info!("Change Event: {:?}", record.event);
Ok(())
}
#[tokio::main]
async fn main() -> Result<(), Error> {
tracing_subscriber::fmt()
.with_max_level(tracing::Level::INFO)
.with_target(false)
.without_time()
.init();
let func = service_fn(function_handler);
lambda_runtime::run(func).await?;
Ok(())
}
```
------
1. Nel riquadro **Codice sorgente** della console Lambda, incolla il codice nell'editor di codice, sostituendo il codice creato da Lambda.
1. Nella sezione **DEPLOY**, scegli **Implementa** per aggiornare il codice della tua funzione:
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/getting-started-tutorial/deploy-console.png)
## Creazione della mappatura dell'origine degli eventi Lambda
Crea lo strumento di mappatura dell'origine degli eventi che associa il flusso di modifica di Amazon DocumentDB alla funzione Lambda. Dopo aver creato questa mappatura delle sorgenti degli eventi, inizia AWS Lambda immediatamente il polling dello stream.
**Creazione di una mappatura dell'origine degli eventi**
1. Apri la [pagina Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegli la funzione `ProcessDocumentDBRecords` creata in precedenza.
1. Scegli la scheda **Configurazione**, quindi scegli **Triggers nel menu** a sinistra.
1. Selezionare **Add trigger** (Aggiungi trigger).
1. In **Configurazione del trigger**, per l'origine seleziona **Amazon DocumentDB**.
1. Crea la mappatura dell'origine degli eventi con la seguente configurazione:
+ **Cluster Amazon DocumentDB**: scegli il cluster creato in precedenza.
+ **Nome del database: docdbdemo**
+ **Nome della collezione: prodotti**
+ **Dimensione del batch**: 1
+ **Posizione di partenza**: più recente
+ **Autenticazione**: BASIC\$1AUTH
+ **Chiave Secrets Manager**: scegli il segreto per il tuo cluster Amazon DocumentDB. Si chiamerà qualcosa del genere`rds!cluster-12345678-a6f0-52c0-b290-db4aga89274f`.
+ **Finestra Batch**: 1
+ **Configurazione completa del documento**: UpdateLookup
1. Scegliere **Aggiungi**. La creazione della mappatura dell'origine degli eventi può richiedere alcuni minuti.
## Test della funzione
Attendi che la mappatura della fonte dell'evento raggiunga lo stato **Abilitato**. Questo processo può richiedere diversi minuti. Quindi, verifica la end-to-end configurazione inserendo, aggiornando ed eliminando i record del database. Prima di iniziare:
1. [Riconnettiti al cluster Amazon DocumentDB nel CloudShell tuo](#docdb-connect-to-cluster) ambiente.
1. Esegui il comando seguente per assicurarti di utilizzare il `docdbdemo` database:
```
use docdbdemo
```
### Inserisci un record
Inserisci un record nella raccolta `products` del database `docdbdemo`:
```
db.products.insertOne({"name":"Pencil", "price": 1.00})
```
Verifica che la tua funzione abbia elaborato correttamente questo evento [controllando CloudWatch Logs.](monitoring-cloudwatchlogs-view.md#monitoring-cloudwatchlogs-console) Dovresti vedere una voce di registro come questa:
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/documentdb-insert-log.png)
### Aggiornare un record
Aggiorna il record che hai appena inserito con il seguente comando:
```
db.products.updateOne(
{ "name": "Pencil" },
{ $set: { "price": 0.50 }}
)
```
Verifica che la tua funzione abbia elaborato correttamente questo evento [controllando CloudWatch Logs.](monitoring-cloudwatchlogs-view.md#monitoring-cloudwatchlogs-console) Dovresti vedere una voce di registro come questa:
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/documentdb-update-log.png)
### Eliminazione di un registro
Eliminare il record appena aggiornato con il seguente comando:
```
db.products.deleteOne( { "name": "Pencil" } )
```
Verifica che la tua funzione abbia elaborato correttamente questo evento [controllando CloudWatch Logs.](monitoring-cloudwatchlogs-view.md#monitoring-cloudwatchlogs-console) Dovresti vedere una voce di registro come questa:
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/documentdb-delete-log.png)
## Risoluzione dei problemi
Se non vedi alcun evento del database nei CloudWatch log della tua funzione, controlla quanto segue:
+ **Assicurati che la mappatura dell'origine degli eventi Lambda (nota anche come trigger) sia nello stato Abilitato.** La creazione delle mappature delle sorgenti degli eventi può richiedere diversi minuti.
+ Se la mappatura delle sorgenti degli eventi è **abilitata** ma non riesci ancora a visualizzare gli eventi del database in: CloudWatch
+ Assicurati che il **nome del database** nella mappatura delle sorgenti degli eventi sia impostato su. `docdbdemo`
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/documentdb-trigger.png)
+ Controlla la mappatura della sorgente dell'evento nel campo **Ultimo risultato di elaborazione** il seguente messaggio «PROBLEMA: errore di connessione. Il tuo VPC deve essere in grado di connettersi a Lambda e STS, oltre a Secrets Manager se è richiesta l'autenticazione.» Se vedi questo errore, assicurati di aver [creato gli endpoint dell'interfaccia VPC Lambda and Secrets Manager e che gli endpoint utilizzino lo stesso VPC](#docdb-create-interface-vpc-endpoints) e le stesse sottoreti utilizzate dal cluster Amazon DocumentDB.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/documentdb-lastprocessingresult.png)
## Pulizia delle risorse
Ora è possibile eliminare le risorse create per questo tutorial, a meno che non si voglia conservarle. Eliminando le risorse AWS che non si utilizzano più, è possibile evitare addebiti superflui sul proprio account Account AWS.
**Per eliminare la funzione Lambda**
1. Aprire la pagina [Functions (Funzioni)](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Selezionare la funzione creata.
1. Scegliere **Operazioni**, **Elimina**.
1. Inserisci **confirm** nel campo di immissione del testo, quindi scegli **Elimina**.
**Come eliminare il ruolo di esecuzione**
1. Aprire la pagina [Ruoli](https://console.aws.amazon.com/iam/home#/roles) della console IAM.
1. Selezionare il ruolo di esecuzione creato.
1. Scegliere **Elimina**.
1. Inserisci il nome del ruolo nel campo di immissione testo e seleziona **Elimina**.
**Eliminazione degli endpoint VPC**
1. Apri la [console VPC](https://console.aws.amazon.com/vpc/home#). Nel menu a sinistra, in **Cloud privato virtuale**, scegli **Endpoint**.
1. Seleziona gli endpoint creati.
1. Seleziona **Actions** (Operazioni), **Delete VPC endpoints** (Eliminazione di endpoint VPC).
1. Inserisci **delete** nel campo di immissione del testo.
1. Scegli **Elimina**.
**Eliminazione del cluster Amazon DocumentDB**
1. Apri la [console Amazon DocumentDB](https://console.aws.amazon.com/docdb/home#).
1. Scegli il cluster Amazon DocumentDB che hai creato per questo tutorial e disabilita la protezione dall'eliminazione.
1. Nella pagina principale **Cluster**, scegli nuovamente il tuo cluster Amazon DocumentDB.
1. Scegli **Operazioni** > **Elimina**.
1. Per **Crea snapshot finale del cluster**, seleziona **No**.
1. Inserisci **delete** nel campo di immissione del testo.
1. Scegli **Elimina**.
**Eliminazione del segreto in Gestione dei segreti**
1. Apri la [console Secrets Manager](https://console.aws.amazon.com/secretsmanager/home#).
1. Scegli il segreto creato per questo tutorial.
1. Scegli **Operazioni**, **Elimina segreto**.
1. Scegliere **Schedule deletion (Pianifica eliminazione)**.
# Utilizzo AWS Lambda con Amazon DynamoDB
**Nota**
[Se desideri inviare dati a una destinazione diversa da una funzione Lambda o arricchire i dati prima di inviarli, consulta Amazon Pipes. EventBridge ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-pipes.html)
Puoi utilizzare una AWS Lambda funzione per elaborare i record in un flusso [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html). Con DynamoDB Streams, è possibile attivare una funzione Lambda per eseguire lavoro aggiuntivo ogni volta che una tabella DynamoDB viene aggiornata.
Durante l'elaborazione di flussi DynamoDB, è necessario implementare una logica di risposta batch parziale per evitare che i record elaborati correttamente vengano ritentati quando alcuni record di un batch falliscono. [L'utilità Batch Processor](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/) di Powertools for AWS Lambda è disponibile in Python TypeScript, .NET e Java e semplifica questa implementazione gestendo automaticamente la logica di risposta batch parziale, riducendo i tempi di sviluppo e migliorando l'affidabilità.
**Topics**
+ [
## Flussi di polling e batching
](#dynamodb-polling-and-batching)
+ [
## Posizioni di partenza di polling e flussi
](#dyanmo-db-stream-poll)
+ [
## Lettori simultanei di uno shard in DynamoDB Streams
](#events-dynamodb-simultaneous-readers)
+ [
## Esempio di evento
](#events-sample-dynamodb)
+ [
# Elaborare i record DynamoDB con Lambda
](services-dynamodb-eventsourcemapping.md)
+ [
# Configurazione della risposta batch parziale con DynamoDB e Lambda
](services-ddb-batchfailurereporting.md)
+ [
# Conservare i record scartati per un'origine eventi DynamoDB in Lambda
](services-dynamodb-errors.md)
+ [
# Implementazione dell'elaborazione del flusso DynamoDB stateful in Lambda
](services-ddb-windows.md)
+ [
# Parametri Lambda per gli strumenti di mappatura dell'origine degli eventi di Amazon DynamoDB
](services-ddb-params.md)
+ [
# Utilizzo del filtro eventi con un'origine eventi DynamoDB
](with-ddb-filtering.md)
+ [
# Tutorial: Utilizzo AWS Lambda con flussi Amazon DynamoDB
](with-ddb-example.md)
## Flussi di polling e batching
Lambda esegue il polling delle partizioni presenti nel proprio flusso DynamoDB ricercando i record a una velocità di base di 4 volte al secondo. Quando sono disponibili dei record, Lambda invoca la funzione e attende il risultato. Se l'elaborazione ha esito positivo, Lambda riprende il polling fino a quando non riceve più record.
Per impostazione predefinita, Lambda richiama la funzione non appena i record sono disponibili. Se il batch che Lambda legge dall'origine eventi contiene un solo record, Lambda invia solo un record alla funzione. Per evitare di richiamare la funzione con pochi record è possibile, configurando un *periodo di batch*, chiedere all'origine eventi di memorizzare nel buffer i registri per un massimo di 5 minuti. Prima di richiamare la funzione, Lambda continua a leggere i registri dall'origine eventi fino a quando non ha raccolto un batch completo, fino alla scadenza del periodo di batch o fino a quando il batch non ha raggiunto il limite del payload di 6 MB. Per ulteriori informazioni, consulta [Comportamento di batching](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching).
**avvertimento**
Gli strumenti di mappatura dell'origine degli eventi elaborano ogni evento almeno una volta e può verificarsi un'elaborazione duplicata dei record. Per evitare potenziali problemi legati agli eventi duplicati, ti consigliamo vivamente di rendere idempotente il codice della funzione. Per ulteriori informazioni, consulta [Come posso rendere idempotente la mia funzione Lambda](https://repost.aws/knowledge-center/lambda-function-idempotent) nel Knowledge Center. AWS
Lambda non attende il completamento di alcuna [estensione](lambda-extensions.md) prima di inviare il batch successivo per l'elaborazione. In altre parole, le estensioni possono continuare a funzionare mentre Lambda elabora il successivo batch di record. Ciò può causare problemi di limitazione in caso di violazione delle impostazioni o dei limiti di [simultaneità](lambda-concurrency.md). Per rilevare se si tratta di un potenziale problema, monitora le tue funzioni e verifica se i [parametri di simultaneità](monitoring-concurrency.md#general-concurrency-metrics) per lo strumento di mappatura dell'origine degli eventi sono superiori al previsto. A causa degli intervalli ridotti tra le invocazioni, Lambda potrebbe segnalare brevemente un utilizzo della simultaneità maggiore rispetto al numero di partizioni. Ciò può essere vero anche per le funzioni Lambda senza estensioni.
Configura l'[ ParallelizationFactor](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-ParallelizationFactor)impostazione per elaborare uno shard di un flusso DynamoDB con più di una chiamata Lambda contemporaneamente. È possibile specificare il numero di batch simultanei di cui Lambda esegue il polling da uno shard da un fattore di parallelizzazione compreso tra da 1 (predefinito) e 10. Ad esempio, impostando `ParallelizationFactor` su 2, puoi disporre al massimo di 200 invocazioni Lambda simultanee per elaborare 100 shard di flusso DynamoDB (anche se nella pratica potresti vedere valori differenti per il parametro `ConcurrentExecutions`). Ciò permette di dimensionare verso l'alto il throughput di elaborazione quando il volume dei dati è volatile e l'[IteratorAge](monitoring-metrics-types.md#performance-metrics) è alta. Se si aumenta il numero di batch simultanei per shard, Lambda garantisce comunque l'ordine di elaborazione a livello di elemento (partizione e chiave di ordinamento).
## Posizioni di partenza di polling e flussi
Tieni presente che il polling dei flussi durante la creazione e gli aggiornamenti dello strumento di mappatura dell’origine degli eventi alla fine è coerente.
+ Durante la creazione dello strumento di mappatura dell'origine degli eventi, potrebbero essere necessari alcuni minuti per l'avvio degli eventi di polling dal flusso.
+ Durante gli aggiornamenti dello strumento di mappatura dell'origine degli eventi, potrebbero essere necessari alcuni minuti per l'avvio degli eventi di polling dal flusso.
Questo comportamento implica che se specifichi `LATEST` come posizione iniziale del flusso, lo strumento di mappatura dell’origine degli eventi potrebbe perdere eventi durante la creazione o gli aggiornamenti. Per garantire che nessun evento venga perso, specifica la posizione di inizio del flusso come `TRIM_HORIZON`.
## Lettori simultanei di uno shard in DynamoDB Streams
Per le tabelle di una regione singola che non sono tabelle globali, è possibile progettare contemporaneamente fino a due funzioni Lambda per leggere dallo stesso shard di DynamoDB Streams nello stesso momento. Il superamento di questo limite comporta una limitazione delle richieste. Per le tabelle globali consigliamo di limitare il numero di lettori simultanei a uno per evitare richieste di limitazione della larghezza di banda della rete.
## Esempio di evento
**Example**
```
{
"Records": [
{
"eventID": "1",
"eventVersion": "1.0",
"dynamodb": {
"Keys": {
"Id": {
"N": "101"
}
},
"NewImage": {
"Message": {
"S": "New item!"
},
"Id": {
"N": "101"
}
},
"StreamViewType": "NEW_AND_OLD_IMAGES",
"SequenceNumber": "111",
"SizeBytes": 26
},
"awsRegion": "us-west-2",
"eventName": "INSERT",
"eventSourceARN": "arn:aws:dynamodb:us-east-2:123456789012:table/my-table/stream/2024-06-10T19:26:16.525",
"eventSource": "aws:dynamodb"
},
{
"eventID": "2",
"eventVersion": "1.0",
"dynamodb": {
"OldImage": {
"Message": {
"S": "New item!"
},
"Id": {
"N": "101"
}
},
"SequenceNumber": "222",
"Keys": {
"Id": {
"N": "101"
}
},
"SizeBytes": 59,
"NewImage": {
"Message": {
"S": "This item has changed"
},
"Id": {
"N": "101"
}
},
"StreamViewType": "NEW_AND_OLD_IMAGES"
},
"awsRegion": "us-west-2",
"eventName": "MODIFY",
"eventSourceARN": "arn:aws:dynamodb:us-east-2:123456789012:table/my-table/stream/2024-06-10T19:26:16.525",
"eventSource": "aws:dynamodb"
}
]}
```
# Elaborare i record DynamoDB con Lambda
Crea una mappatura dell'origine eventi per indicare a Lambda di inviare i record dal proprio flusso a una funzione Lambda. È possibile creare più mappature dell'origine eventi per elaborare gli stessi dati con più funzioni Lambda o per elaborare elementi da più flussi con una singola funzione.
È possibile configurare gli strumenti di mappatura dell'origine degli eventi per elaborare i record da un flusso in un altro Account AWS. Per ulteriori informazioni, consulta [Creazione di uno strumento di mappatura dell'origine degli eventi multi-account](#services-dynamodb-eventsourcemapping-cross-account).
**Per configurare la tua funzione per la lettura da DynamoDB Streams, collega la policy gestita di [DBExecutionDynamo Role AWSLambda al](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaDynamoDBExecutionRole.html) tuo AWS ruolo di esecuzione e quindi crea un trigger DynamoDB.**
**Per aggiungere le autorizzazioni e creare un trigger**
1. Aprire la pagina [Functions](https://console.aws.amazon.com/lambda/home#/functions) (Funzioni) della console Lambda.
1. Scegliere il nome della funzione.
1. Quindi, seleziona la scheda **Configuration** (Configurazione) e poi **Permissions** (Autorizzazioni).
1. In **Nome del ruolo**, scegli il link al tuo ruolo di esecuzione. Questo ruolo si apre nella console IAM.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/execution-role.png)
1. Seleziona **Aggiungi autorizzazioni**, quindi seleziona **Collega policy**.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/attach-policies.png)
1. Inserisci `AWSLambdaDynamoDBExecutionRole` nel campo di ricerca. Aggiungi questa policy al tuo ruolo di esecuzione. Si tratta di una policy AWS gestita che contiene le autorizzazioni che la funzione deve leggere dal flusso DynamoDB. *Per ulteriori informazioni su questa politica, consulta [AWSLambdaDynamo DBExecution Role](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaDynamoDBExecutionRole.html) nel Managed Policy Reference.AWS *
1. Torna alla funzione nella console Lambda. In **Panoramica delle funzioni**, scegliere **Aggiungi trigger**.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/add-trigger.png)
1. Scegliere un tipo di trigger.
1. Configurare le opzioni richieste, quindi scegliere **Add (Aggiungi)**.
Lambda supporta le seguenti opzioni per le origini eventi DynamoDB:
**Opzioni di origine eventi**
+ **DynamoDB table (Tabella DynamoDB):** la tabella DynamoDB da cui leggere i record.
+ **Batch size (Dimensione batch):** il numero di record da inviare alla funzione in ogni batch, fino a 10.000. Lambda passa tutti i record del batch alla funzione in una singola chiamata, purché la dimensione totale degli eventi non superi il [limite di payload](gettingstarted-limits.md) per l'invocazione sincrona (6 MB).
+ **Batch window (Periodo di batch):** specifica il tempo massimo in secondi per la raccolta dei record prima di richiamare la funzione.
+ **Starting position (Posizione iniziale):** elabora solo i nuovi record o tutti i record esistenti.
+ **Latest (Ultimi)**: consente di elaborare i nuovi record aggiunti al flusso.
+ **Trim Horizon (Orizzonte di taglio):** elabora tutti i record contenuti nel flusso.
Dopo l'elaborazione di qualsiasi record esistente, la funzione è aggiornata e continua a elaborare nuovi record.
+ **Destinazione in caso di errore**: una coda SQS standard o un argomento SNS standard per i record che non è possibile elaborare. Quando Lambda scarta un batch di record perché è troppo datato o ha esaurito tutti i tentativi, invia i dettagli sul batch alla coda o all'argomento.
+ **Retry attempts (Nuovi tentativi):** il numero massimo di tentativi che Lambda effettua quando la funzione restituisce un errore. Non si applica agli errori di servizio o alle limitazioni in cui il batch non ha raggiunto la funzione.
+ **Maximum age of record (Età massima del record):** l'età massima di un record inviato da Lambda alla funzione.
+ **Split batch on error (Dividi batch in caso di errore):** quando la funzione restituisce un errore, divide il batch in due prima di un nuovo tentativo. L'impostazione originale delle dimensioni del batch rimane invariata.
+ **Batch simultanei per shard**: elabora più batch dallo stesso shard simultaneamente.
+ **Enabled (Abilitato):** impostare su true per abilitare la mappatura dell'origine eventi. Impostare su false per interrompere l'elaborazione dei record. Lambda registra l'ultimo record elaborato e riprende l'elaborazione da quel punto quando la mappatura viene riabilitata.
**Nota**
Non ti vengono addebitati costi per le chiamate GetRecords API richiamate da Lambda come parte dei trigger di DynamoDB.
Per gestire la configurazione dell'origine eventi in un momento successivo, scegliere il trigger nel designer.
## Creazione di uno strumento di mappatura dell'origine degli eventi multi-account
[Amazon DynamoDB ora supporta policy basate sulle risorse.](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/access-control-resource-based.html) Con questa funzionalità, puoi elaborare i dati da un flusso DynamoDB in uno Account AWS con una funzione Lambda in un altro account.
Per creare una mappatura delle sorgenti degli eventi per la tua funzione Lambda utilizzando un flusso DynamoDB in un Account AWS altro, devi configurare il flusso utilizzando una policy basata sulle risorse per concedere alla funzione Lambda il permesso di leggere i record. *Per informazioni su come configurare lo stream per l'accesso tra account diversi, consulta [Condividi l'accesso con le funzioni Lambda tra](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-cross-account-access.html#rbac-analyze-cross-account-lambda-access) account nella Amazon DynamoDB Developer Guide.*
Dopo aver configurato lo stream con una policy basata sulle risorse che fornisce alla funzione Lambda le autorizzazioni richieste, crea la mappatura delle sorgenti degli eventi con il tuo ARN del flusso tra account. Puoi trovare l'ARN dello stream nella scheda **Esportazioni e flussi** della tabella nella console DynamoDB per più account.
Quando usi la console Lambda, incolla l'ARN dello stream direttamente nel campo di input della tabella DynamoDB nella pagina di creazione della mappatura delle sorgenti degli eventi.
**Nota: i trigger interregionali** non sono supportati.
# Configurazione della risposta batch parziale con DynamoDB e Lambda
Quando si consumano ed elaborano i dati di streaming da un'origine eventi, per impostazione predefinita i Lambda imposta i checkpoint al numero di sequenza più alto di un batch solo quando il batch è riuscito completamente. Lambda tratta tutti gli altri risultati come un fallimento completo e riprova a elaborare il batch fino al limite di tentativi. Per consentire i successi parziali durante l'elaborazione di batch da un flusso, attivare `ReportBatchItemFailures`. Consentire successi parziali può contribuire a ridurre il numero di tentativi su un record, anche se non impedisce del tutto la possibilità di tentativi in un record riuscito.
Per attivare `ReportBatchItemFailures`, includere il valore enum**ReportBatchItemFailures** nell'[FunctionResponseTypes](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-FunctionResponseTypes)elenco. Questo elenco indica quali tipi di risposta sono abilitati per la funzione. È possibile configurare questo elenco quando si [crea](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) o si [aggiorna](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html) uno strumento di mappatura dell'origine degli eventi.
**Nota**
Anche quando il codice della funzione restituisce risposte parziali di errore in batch, queste risposte non verranno elaborate da Lambda a meno che la `ReportBatchItemFailures` funzionalità non sia esplicitamente attivata per la mappatura delle sorgenti degli eventi.
## Sintassi di report
Quando si configura la creazione di report sugli errori degli elementi batch, la `StreamsEventResponse` classe viene restituita con un elenco di errori degli articoli batch. È possibile utilizzare un `StreamsEventResponse` oggetto per restituire il numero di sequenza del primo record non riuscito nel batch. È inoltre possibile creare la propria classe personalizzata utilizzando la sintassi di risposta corretta. La seguente struttura JSON mostra la sintassi di risposta richiesta:
```
{
"batchItemFailures": [
{
"itemIdentifier": ""
}
]
}
```
**Nota**
Se l'array `batchItemFailures` contiene più elementi, Lambda utilizza il record con il numero di sequenza più basso come checkpoint. Lambda quindi riprova tutti i record a partire da quel checkpoint.
## Condizioni di successo e di errore
Lambda considera un batch come un successo completo se si restituisce uno degli elementi seguenti:
+ Una `batchItemFailure` lista vuota
+ Un `batchItemFailure` elenco nullo
+ Un vuoto `EventResponse`
+ Un valore nullo `EventResponse`
Lambda considera un batch come un fallimento completo se si restituisce uno degli elementi seguenti:
+ Una stringa vuota `itemIdentifier`
+ Un valore nullo `itemIdentifier`
+ Un `itemIdentifier` con un nome chiave errato
Lambda esegue nuovi tentativi in seguito ai fallimenti secondo la strategia di tentativi impostata.
## Bisezione un batch
Se il richiamo fallisce ed `BisectBatchOnFunctionError` è attivato, il batch viene bisecato a prescindere dalle `ReportBatchItemFailures` impostazioni.
Quando si riceve una risposta di successo parziale del batch ed entrambi `BisectBatchOnFunctionError` e `ReportBatchItemFailures` sono attivati, il batch viene bisecato in corrispondenza del numero di sequenza restituito e Lambda ritenta solo i record rimanenti.
Per semplificare l'implementazione della logica di risposta batch parziale, prendi in considerazione l'utilizzo dell'[utilità Batch Processor](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/) di Powertools for AWS Lambda, che gestisce automaticamente queste complessità per te.
Ecco alcuni esempi di codice di funzione che restituiscono l'elenco dei messaggi non riusciti IDs nel batch:
------
#### [ .NET ]
**SDK per .NET**
C'è altro su GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda-with-batch-item-handling).
Segnalazione di errori di elementi batch di DynamoDB con Lambda tramite .NET.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using System.Text.Json;
using System.Text;
using Amazon.Lambda.Core;
using Amazon.Lambda.DynamoDBEvents;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace AWSLambda_DDB;
public class Function
{
public StreamsEventResponse FunctionHandler(DynamoDBEvent dynamoEvent, ILambdaContext context)
{
context.Logger.LogInformation($"Beginning to process {dynamoEvent.Records.Count} records...");
List batchItemFailures = new List();
StreamsEventResponse streamsEventResponse = new StreamsEventResponse();
foreach (var record in dynamoEvent.Records)
{
try
{
var sequenceNumber = record.Dynamodb.SequenceNumber;
context.Logger.LogInformation(sequenceNumber);
}
catch (Exception ex)
{
context.Logger.LogError(ex.Message);
batchItemFailures.Add(new StreamsEventResponse.BatchItemFailure() { ItemIdentifier = record.Dynamodb.SequenceNumber });
}
}
if (batchItemFailures.Count > 0)
{
streamsEventResponse.BatchItemFailures = batchItemFailures;
}
context.Logger.LogInformation("Stream processing complete.");
return streamsEventResponse;
}
}
```
------
#### [ Go ]
**SDK per Go V2**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda-with-batch-item-handling).
Segnalazione di errori di elementi batch di DynamoDB con Lambda tramite Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package main
import (
"context"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
type BatchItemFailure struct {
ItemIdentifier string `json:"ItemIdentifier"`
}
type BatchResult struct {
BatchItemFailures []BatchItemFailure `json:"BatchItemFailures"`
}
func HandleRequest(ctx context.Context, event events.DynamoDBEvent) (*BatchResult, error) {
var batchItemFailures []BatchItemFailure
curRecordSequenceNumber := ""
for _, record := range event.Records {
// Process your record
curRecordSequenceNumber = record.Change.SequenceNumber
}
if curRecordSequenceNumber != "" {
batchItemFailures = append(batchItemFailures, BatchItemFailure{ItemIdentifier: curRecordSequenceNumber})
}
batchResult := BatchResult{
BatchItemFailures: batchItemFailures,
}
return &batchResult, nil
}
func main() {
lambda.Start(HandleRequest)
}
```
------
#### [ Java ]
**SDK per Java 2.x**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda-with-batch-item-handling).
Segnalazione di errori di elementi batch di DynamoDB con Lambda tramite Java.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.DynamodbEvent;
import com.amazonaws.services.lambda.runtime.events.StreamsEventResponse;
import com.amazonaws.services.lambda.runtime.events.models.dynamodb.StreamRecord;
import java.util.ArrayList;
import java.util.List;
public class ProcessDynamodbRecords implements RequestHandler {
@Override
public StreamsEventResponse handleRequest(DynamodbEvent input, Context context) {
List batchItemFailures = new ArrayList<>();
String curRecordSequenceNumber = "";
for (DynamodbEvent.DynamodbStreamRecord dynamodbStreamRecord : input.getRecords()) {
try {
//Process your record
StreamRecord dynamodbRecord = dynamodbStreamRecord.getDynamodb();
curRecordSequenceNumber = dynamodbRecord.getSequenceNumber();
} catch (Exception e) {
/* Since we are working with streams, we can return the failed item immediately.
Lambda will immediately begin to retry processing from this failed item onwards. */
batchItemFailures.add(new StreamsEventResponse.BatchItemFailure(curRecordSequenceNumber));
return new StreamsEventResponse(batchItemFailures);
}
}
return new StreamsEventResponse();
}
}
```
------
#### [ JavaScript ]
**SDK per JavaScript (v3)**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda-with-batch-item-handling).
Segnalazione degli errori degli elementi batch di DynamoDB utilizzando Lambda. JavaScript
```
export const handler = async (event) => {
const records = event.Records;
let curRecordSequenceNumber = "";
for (const record of records) {
try {
// Process your record
curRecordSequenceNumber = record.dynamodb.SequenceNumber;
} catch (e) {
// Return failed record's sequence number
return { batchItemFailures: [{ itemIdentifier: curRecordSequenceNumber }] };
}
}
return { batchItemFailures: [] };
};
```
Segnalazione degli errori degli elementi batch di DynamoDB utilizzando Lambda. TypeScript
```
import {
DynamoDBBatchResponse,
DynamoDBBatchItemFailure,
DynamoDBStreamEvent,
} from "aws-lambda";
export const handler = async (
event: DynamoDBStreamEvent
): Promise => {
const batchItemFailures: DynamoDBBatchItemFailure[] = [];
let curRecordSequenceNumber;
for (const record of event.Records) {
curRecordSequenceNumber = record.dynamodb?.SequenceNumber;
if (curRecordSequenceNumber) {
batchItemFailures.push({
itemIdentifier: curRecordSequenceNumber,
});
}
}
return { batchItemFailures: batchItemFailures };
};
```
------
#### [ PHP ]
**SDK per PHP**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda-with-batch-item-handling).
Segnalazione di errori di elementi batch di DynamoDB con Lambda tramite PHP.
```
logger = $logger;
}
/**
* @throws JsonException
* @throws \Bref\Event\InvalidLambdaEvent
*/
public function handle(mixed $event, Context $context): array
{
$dynamoDbEvent = new DynamoDbEvent($event);
$this->logger->info("Processing records");
$records = $dynamoDbEvent->getRecords();
$failedRecords = [];
foreach ($records as $record) {
try {
$data = $record->getData();
$this->logger->info(json_encode($data));
// TODO: Do interesting work based on the new data
} catch (Exception $e) {
$this->logger->error($e->getMessage());
// failed processing the record
$failedRecords[] = $record->getSequenceNumber();
}
}
$totalRecords = count($records);
$this->logger->info("Successfully processed $totalRecords records");
// change format for the response
$failures = array_map(
fn(string $sequenceNumber) => ['itemIdentifier' => $sequenceNumber],
$failedRecords
);
return [
'batchItemFailures' => $failures
];
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**SDK per Python (Boto3)**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda-with-batch-item-handling).
Segnalazione di errori di elementi batch di DynamoDB con Lambda tramite Python.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def handler(event, context):
records = event.get("Records")
curRecordSequenceNumber = ""
for record in records:
try:
# Process your record
curRecordSequenceNumber = record["dynamodb"]["SequenceNumber"]
except Exception as e:
# Return failed record's sequence number
return {"batchItemFailures":[{"itemIdentifier": curRecordSequenceNumber}]}
return {"batchItemFailures":[]}
```
------
#### [ Ruby ]
**SDK per Ruby**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda-with-batch-item-handling).
Segnalazione di errori di elementi batch di DynamoDB con Lambda tramite Ruby.
```
def lambda_handler(event:, context:)
records = event["Records"]
cur_record_sequence_number = ""
records.each do |record|
begin
# Process your record
cur_record_sequence_number = record["dynamodb"]["SequenceNumber"]
rescue StandardError => e
# Return failed record's sequence number
return {"batchItemFailures" => [{"itemIdentifier" => cur_record_sequence_number}]}
end
end
{"batchItemFailures" => []}
end
```
------
#### [ Rust ]
**SDK per Rust**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda-with-batch-item-handling).
Segnalazione di errori di elementi batch di DynamoDB con Lambda tramite Rust.
```
use aws_lambda_events::{
event::dynamodb::{Event, EventRecord, StreamRecord},
streams::{DynamoDbBatchItemFailure, DynamoDbEventResponse},
};
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
/// Process the stream record
fn process_record(record: &EventRecord) -> Result<(), Error> {
let stream_record: &StreamRecord = &record.change;
// process your stream record here...
tracing::info!("Data: {:?}", stream_record);
Ok(())
}
/// Main Lambda handler here...
async fn function_handler(event: LambdaEvent) -> Result {
let mut response = DynamoDbEventResponse {
batch_item_failures: vec![],
};
let records = &event.payload.records;
if records.is_empty() {
tracing::info!("No records found. Exiting.");
return Ok(response);
}
for record in records {
tracing::info!("EventId: {}", record.event_id);
// Couldn't find a sequence number
if record.change.sequence_number.is_none() {
response.batch_item_failures.push(DynamoDbBatchItemFailure {
item_identifier: Some("".to_string()),
});
return Ok(response);
}
// Process your record here...
if process_record(record).is_err() {
response.batch_item_failures.push(DynamoDbBatchItemFailure {
item_identifier: record.change.sequence_number.clone(),
});
/* Since we are working with streams, we can return the failed item immediately.
Lambda will immediately begin to retry processing from this failed item onwards. */
return Ok(response);
}
}
tracing::info!("Successfully processed {} record(s)", records.len());
Ok(response)
}
#[tokio::main]
async fn main() -> Result<(), Error> {
tracing_subscriber::fmt()
.with_max_level(tracing::Level::INFO)
// disable printing the name of the module in every log line.
.with_target(false)
// disabling time is handy because CloudWatch will add the ingestion time.
.without_time()
.init();
run(service_fn(function_handler)).await
}
```
------
## Utilizzo di Powertools per il processore AWS Lambda batch
L'utilità per il processore batch di Powertools gestisce AWS Lambda automaticamente la logica di risposta parziale in batch, riducendo la complessità dell'implementazione della segnalazione degli errori dei batch. Ecco alcuni esempi di utilizzo del processore batch:
**Python**
Per esempi completi e istruzioni di configurazione, consultate la [documentazione del processore batch](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/).
Elaborazione dei record AWS Lambda di flusso DynamoDB con processore batch.
```
import json
from aws_lambda_powertools import Logger
from aws_lambda_powertools.utilities.batch import BatchProcessor, EventType, process_partial_response
from aws_lambda_powertools.utilities.data_classes import DynamoDBStreamEvent
from aws_lambda_powertools.utilities.typing import LambdaContext
processor = BatchProcessor(event_type=EventType.DynamoDBStreams)
logger = Logger()
def record_handler(record):
logger.info(record)
# Your business logic here
# Raise an exception to mark this record as failed
def lambda_handler(event, context: LambdaContext):
return process_partial_response(
event=event,
record_handler=record_handler,
processor=processor,
context=context
)
```
**TypeScript**
Per esempi completi e istruzioni di configurazione, consultate la documentazione del [processore batch](https://docs.aws.amazon.com/powertools/typescript/latest/features/batch/).
Elaborazione dei record AWS Lambda di flusso DynamoDB con processore batch.
```
import { BatchProcessor, EventType, processPartialResponse } from '@aws-lambda-powertools/batch';
import { Logger } from '@aws-lambda-powertools/logger';
import type { DynamoDBStreamEvent, Context } from 'aws-lambda';
const processor = new BatchProcessor(EventType.DynamoDBStreams);
const logger = new Logger();
const recordHandler = async (record: any): Promise => {
logger.info('Processing record', { record });
// Your business logic here
// Throw an error to mark this record as failed
};
export const handler = async (event: DynamoDBStreamEvent, context: Context) => {
return processPartialResponse(event, recordHandler, processor, {
context,
});
};
```
**Java**
Per esempi completi e istruzioni di configurazione, consultate la documentazione del [processore batch](https://docs.powertools.aws.dev/lambda/java/latest/utilities/batch/).
Elaborazione dei record AWS Lambda di flusso DynamoDB con processore batch.
```
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.DynamodbEvent;
import com.amazonaws.services.lambda.runtime.events.StreamsEventResponse;
import software.amazon.lambda.powertools.batch.BatchMessageHandlerBuilder;
import software.amazon.lambda.powertools.batch.handler.BatchMessageHandler;
public class DynamoDBStreamBatchHandler implements RequestHandler {
private final BatchMessageHandler handler;
public DynamoDBStreamBatchHandler() {
handler = new BatchMessageHandlerBuilder()
.withDynamoDbBatchHandler()
.buildWithRawMessageHandler(this::processMessage);
}
@Override
public StreamsEventResponse handleRequest(DynamodbEvent ddbEvent, Context context) {
return handler.processBatch(ddbEvent, context);
}
private void processMessage(DynamodbEvent.DynamodbStreamRecord dynamodbStreamRecord, Context context) {
// Process the change record
}
}
```
**.NET**
Per esempi completi e istruzioni di configurazione, consultate la documentazione del [processore batch](https://docs.aws.amazon.com/powertools/dotnet/utilities/batch-processing/).
Elaborazione dei record AWS Lambda di flusso DynamoDB con processore batch.
```
using System;
using System.Threading;
using System.Threading.Tasks;
using Amazon.Lambda.Core;
using Amazon.Lambda.DynamoDBEvents;
using Amazon.Lambda.Serialization.SystemTextJson;
using AWS.Lambda.Powertools.BatchProcessing;
[assembly: LambdaSerializer(typeof(DefaultLambdaJsonSerializer))]
namespace HelloWorld;
public class Customer
{
public string? CustomerId { get; set; }
public string? Name { get; set; }
public string? Email { get; set; }
public DateTime CreatedAt { get; set; }
}
internal class TypedDynamoDbRecordHandler : ITypedRecordHandler
{
public async Task HandleAsync(Customer customer, CancellationToken cancellationToken)
{
if (string.IsNullOrEmpty(customer.Email))
{
throw new ArgumentException("Customer email is required");
}
return await Task.FromResult(RecordHandlerResult.None);
}
}
public class Function
{
[BatchProcessor(TypedRecordHandler = typeof(TypedDynamoDbRecordHandler))]
public BatchItemFailuresResponse HandlerUsingTypedAttribute(DynamoDBEvent _)
{
return TypedDynamoDbStreamBatchProcessor.Result.BatchItemFailuresResponse;
}
}
```
# Conservare i record scartati per un'origine eventi DynamoDB in Lambda
La gestione degli errori per gli strumenti di mappatura dell'origine degli eventi DynamoDB dipende dal fatto che l'errore si verifichi prima che la funzione venga richiamata o durante la chiamata della funzione:
+ **Prima della chiamata:** se una mappatura dell'origine degli eventi Lambda non è in grado di richiamare la funzione a causa di limitazioni o altri problemi, riprova finché i record non scadono o superano l'età massima configurata nella mappatura dell'origine dell'evento (). [MaximumRecordAgeInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumRecordAgeInSeconds)
+ **Durante la chiamata:** se la funzione viene richiamata ma restituisce un errore, Lambda riprova fino alla scadenza dei record, al superamento dell'età massima () o al raggiungimento della quota di tentativi configurata ([MaximumRecordAgeInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumRecordAgeInSeconds)). [MaximumRetryAttempts](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumRetryAttempts) Per gli errori di funzione, puoi anche configurare, che divide un batch non riuscito in due batch più piccoli [BisectBatchOnFunctionError](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-response-BisectBatchOnFunctionError), isolando i record non validi ed evitando i timeout. La divisione dei batch non consuma la quota di tentativi.
Se le misure di gestione degli errori non riescono, Lambda elimina i record e continua l'elaborazione dei batch dal flusso. Con le impostazioni predefinite, ciò significa che un record errato può bloccare l'elaborazione sullo shard interessata per un massimo di un giorno. Per evitare questa situazione, configura la mappatura dell'origine eventi della funzione con un numero ragionevole di tentativi e un'età massima dei record che sia adatta al caso d'uso.
## Configurazione delle destinazioni per le chiamate non riuscite
Per mantenere i record delle chiamate non riuscite allo strumento di mappatura dell'origine degli eventi, aggiungi una destinazione allo strumento di mappatura dell'origine degli eventi della funzione. Ogni record inviato alla destinazione è un documento JSON contenente i metadati relativi alla chiamata non riuscita. Per le destinazioni Amazon S3, Lambda invia insieme ai metadati anche l'intero record di invocazione. Puoi configurare qualsiasi argomento Amazon SNS, coda Amazon SQS, bucket Amazon S3 o Kafka come destinazione.
Con le destinazioni Amazon S3, puoi utilizzare la funzionalità [Notifiche eventi Amazon S3](https://docs.aws.amazon.com/) per ricevere notifiche quando gli oggetti vengono caricati nel bucket S3 di destinazione. Puoi anche configurare Notifiche eventi S3 per richiamare un'altra funzione Lambda per eseguire l'elaborazione automatica su batch non riusciti.
Il tuo ruolo di esecuzione deve avere le autorizzazioni per la destinazione:
+ **[Per una destinazione SQS: sqs: SendMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)**
+ **[Per una destinazione SNS: sns:publish](https://docs.aws.amazon.com/sns/latest/api/API_Publish.html)**
+ **[Per una destinazione S3: s3: e [s3](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html): PutObject ListBucket](https://docs.aws.amazon.com/AmazonS3/latest/API/ListObjectsV2.html)**
+ **[Per una destinazione Kafka: kafka-cluster: WriteData](https://docs.aws.amazon.com/msk/latest/developerguide/kafka-actions.html)**
È possibile configurare un argomento di Kafka come destinazione in caso di errore per le mappature delle sorgenti degli eventi Kafka. Quando Lambda non è in grado di elaborare i record dopo estenuanti tentativi o quando i record superano l'età massima, Lambda invia i record non riusciti all'argomento Kafka specificato per un'elaborazione successiva. Fai riferimento a [Usare un argomento di Kafka come destinazione in caso di errore](kafka-on-failure-destination.md).
[Se hai abilitato la crittografia con la tua chiave KMS per una destinazione S3, anche il ruolo di esecuzione della funzione deve avere l'autorizzazione a chiamare kms:. GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) Se la chiave KMS e la destinazione del bucket S3 si trovano in un account diverso dalla funzione Lambda e dal ruolo di esecuzione, configura la chiave KMS in modo che consideri attendibile il ruolo di esecuzione da consentire. kms: GenerateDataKey
Per configurare una destinazione in caso di errore tramite la console, completa i seguenti passaggi:
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegliere una funzione.
1. In **Function overview (Panoramica delle funzioni)**, scegliere **Add destination (Aggiungi destinazione)**.
1. Per **Origine**, scegli **Chiamata allo strumento di mappatura dell'origine degli eventi**.
1. Per **Strumento di mappatura dell'origine degli eventi**, scegli un'origine dell'evento configurata per questa funzione.
1. Per **Condizione**, seleziona **In caso di errore**. Per le chiamate allo strumento di mappatura dell'origine degli eventi, questa è l'unica condizione accettata.
1. Per **Tipo di destinazione**, scegli il tipo di destinazione a cui Lambda deve inviare i record di chiamata.
1. Per **Destination (Destinazione)**, scegliere una risorsa.
1. Scegli **Save** (Salva).
Puoi anche configurare una destinazione in caso di errore utilizzando (). AWS Command Line Interface AWS CLI Ad esempio, il [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html)comando seguente aggiunge una mappatura dell'origine degli eventi con una destinazione SQS in caso di errore a: `MyFunction`
```
aws lambda create-event-source-mapping \
--function-name "MyFunction" \
--event-source-arn arn:aws:dynamodb:us-east-2:123456789012:table/my-table/stream/2024-06-10T19:26:16.525 \
--destination-config '{"OnFailure": {"Destination": "arn:aws:sqs:us-east-1:123456789012:dest-queue"}}'
```
Il [update-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-event-source-mapping.html)comando seguente aggiorna una mappatura dell'origine degli eventi per inviare i record di chiamata non riuscita a una destinazione SNS dopo due tentativi o se i record risalgono a più di un'ora.
```
aws lambda update-event-source-mapping \
--uuid f89f8514-cdd9-4602-9e1f-01a5b77d449b \
--maximum-retry-attempts 2 \
--maximum-record-age-in-seconds 3600 \
--destination-config '{"OnFailure": {"Destination": "arn:aws:sns:us-east-1:123456789012:dest-topic"}}'
```
Le impostazioni aggiornate sono applicate in modo asincrono e non sono riflesse nell'output fino al completamento del processo. Utilizza il comando [get-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/get-event-source-mapping.html) per visualizzare lo stato corrente.
Per rimuovere una destinazione, fornisci una stringa vuota come argomento del parametro `destination-config`:
```
aws lambda update-event-source-mapping \
--uuid f89f8514-cdd9-4602-9e1f-01a5b77d449b \
--destination-config '{"OnFailure": {"Destination": ""}}'
```
### Best practice di sicurezza per destinazioni Amazon S3
L'eliminazione di un bucket S3 configurato come destinazione senza rimuovere la destinazione dalla configurazione della funzione può creare un rischio per la sicurezza. Se un altro utente conosce il nome del bucket di destinazione, può ricreare il bucket nel proprio Account AWS. I record delle invocazioni non riuscite verranno inviati al relativo bucket, esponendo potenzialmente i dati della tua funzione.
**avvertimento**
Per garantire che i record di invocazione della tua funzione non possano essere inviati a un bucket S3 in un altro Account AWS, aggiungi una condizione al ruolo di esecuzione della funzione che limiti le autorizzazioni ai bucket del tuo account. `s3:PutObject`
Di seguito viene illustrato un esempio di policy IAM che limita le autorizzazioni `s3:PutObject` della funzione ai bucket presenti nell'account. Questa policy fornisce inoltre a Lambda l'autorizzazione `s3:ListBucket` necessaria per utilizzare un bucket S3 come destinazione.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "S3BucketResourceAccountWrite",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::*/*",
"arn:aws:s3:::*"
],
"Condition": {
"StringEquals": {
"s3:ResourceAccount": "111122223333"
}
}
}
]
}
```
Per aggiungere una politica di autorizzazioni al ruolo di esecuzione della tua funzione utilizzando Console di gestione AWS o AWS CLI, consulta le istruzioni nelle seguenti procedure:
------
#### [ Console ]
**Per aggiungere una policy di autorizzazioni al ruolo di esecuzione di una funzione (console)**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Seleziona la funzione Lambda di cui si desidera modificare il ruolo di esecuzione.
1. Nella scheda **Configurazione** scegli **Autorizzazioni**.
1. Nella scheda **Ruolo di esecuzione**, seleziona il **nome del ruolo** della funzione per aprire la pagina della console IAM del ruolo.
1. Aggiungi una policy di autorizzazioni di base al ruolo completando le seguenti operazioni:
1. Nel riquadro **Policy di autorizzazioni**, scegli **Aggiungi autorizzazioni**, poi **Crea policy in linea**.
1. Nell'**editor delle policy**, seleziona **JSON**.
1. Incolla la policy che desideri aggiungere nell'editor (sostituendo il codice JSON esistente), quindi scegli **Avanti**.
1. In **Dettagli della policy**, specifica un **nome per la policy**.
1. Scegli **Crea policy**.
------
#### [ AWS CLI ]
**Per aggiungere una policy di autorizzazioni al ruolo di esecuzione di una funzione (CLI)**
1. Crea un documento di policy JSON con le autorizzazioni richieste e salvalo in una directory locale.
1. Utilizza il comando della CLI `put-role-policy` di IAM per aggiungere le autorizzazioni per il ruolo di esecuzione di una funzione. Esegui il comando seguente dalla directory in cui hai salvato il documento di policy JSON e sostituisci il nome del ruolo, il nome della policy e il documento di policy con i tuoi valori.
```
aws iam put-role-policy \
--role-name my_lambda_role \
--policy-name LambdaS3DestinationPolicy \
--policy-document file://my_policy.json
```
------
### Record di invocazione Amazon SNS e Amazon SQS di esempio
L'esempio seguente mostra un record di chiamata che Lambda invia a una destinazione SQS o SNS per un flusso DynamoDB.
```
{
"requestContext": {
"requestId": "316aa6d0-8154-xmpl-9af7-85d5f4a6bc81",
"functionArn": "arn:aws:lambda:us-east-2:123456789012:function:myfunction",
"condition": "RetryAttemptsExhausted",
"approximateInvokeCount": 1
},
"responseContext": {
"statusCode": 200,
"executedVersion": "$LATEST",
"functionError": "Unhandled"
},
"version": "1.0",
"timestamp": "2019-11-14T00:13:49.717Z",
"DDBStreamBatchInfo": {
"shardId": "shardId-00000001573689847184-864758bb",
"startSequenceNumber": "800000000003126276362",
"endSequenceNumber": "800000000003126276362",
"approximateArrivalOfFirstRecord": "2019-11-14T00:13:19Z",
"approximateArrivalOfLastRecord": "2019-11-14T00:13:19Z",
"batchSize": 1,
"streamArn": "arn:aws:dynamodb:us-east-2:123456789012:table/mytable/stream/2019-11-14T00:04:06.388"
}
}
```
È possibile utilizzare queste informazioni per recuperare i record interessati dal flusso per la risoluzione dei problemi. I record effettivi non sono inclusi, pertanto è necessario elaborare questo record e recuperarli dal flusso prima che scadano e vadano persi.
### Record di invocazione Amazon S3 di esempio
L'esempio seguente mostra un record di invocazione che Lambda invia a un bucket S3 per un flusso DynamoDB. Oltre a tutti i campi dell'esempio precedente per le destinazioni SQS e SNS, il campo `payload` contiene il record di chiamata originale come stringa JSON con escape.
```
{
"requestContext": {
"requestId": "316aa6d0-8154-xmpl-9af7-85d5f4a6bc81",
"functionArn": "arn:aws:lambda:us-east-2:123456789012:function:myfunction",
"condition": "RetryAttemptsExhausted",
"approximateInvokeCount": 1
},
"responseContext": {
"statusCode": 200,
"executedVersion": "$LATEST",
"functionError": "Unhandled"
},
"version": "1.0",
"timestamp": "2019-11-14T00:13:49.717Z",
"DDBStreamBatchInfo": {
"shardId": "shardId-00000001573689847184-864758bb",
"startSequenceNumber": "800000000003126276362",
"endSequenceNumber": "800000000003126276362",
"approximateArrivalOfFirstRecord": "2019-11-14T00:13:19Z",
"approximateArrivalOfLastRecord": "2019-11-14T00:13:19Z",
"batchSize": 1,
"streamArn": "arn:aws:dynamodb:us-east-2:123456789012:table/mytable/stream/2019-11-14T00:04:06.388"
},
"payload": "" // Only available in S3
}
```
L'oggetto S3 contenente il record di invocazione utilizza la seguente convenzione di denominazione:
```
aws/lambda///YYYY/MM/DD/YYYY-MM-DDTHH.MM.SS-
```
# Implementazione dell'elaborazione del flusso DynamoDB stateful in Lambda
Le funzioni Lambda possono eseguire applicazioni di elaborazione di flussi continui. Un flusso rappresenta dati illimitati che scorrono continuamente attraverso l'applicazione. Per analizzare le informazioni da questo input di aggiornamento continuo, è possibile associare i record inclusi utilizzando una finestra definita in termini di tempo.
Le finestre a cascata sono finestre temporali distinte che si aprono e si chiudono a intervalli regolari. Per impostazione predefinita, le invocazioni Lambda sono senza stato: non è possibile utilizzarle per l'elaborazione dei dati tra più invocazioni continue senza un database esterno. Tuttavia, con la finestra a cascata, è possibile mantenere il proprio stato tra le invocazioni. Questo stato contiene il risultato aggregato dei messaggi precedentemente elaborati per la finestra corrente. Lo stato può essere un massimo di 1 MB per shard. Se supera quella dimensione, Lambda termina la finestra in anticipo.
Ogni record in un flusso appartiene a una finestra specifica. Lambda elaborerà ogni record almeno una volta, ma non garantisce che ogni record venga elaborato una sola volta. In rari casi, come nel caso della gestione degli errori, alcuni record potrebbero essere elaborati più di una volta. La prima volta i record vengono sempre elaborati in ordine. Se i record vengono elaborati più di una volta, possono essere elaborati fuori ordine.
## Aggregazione ed elaborazione
La funzione gestita dall'utente viene richiamata sia per l'aggregazione che per l'elaborazione dei risultati finali di tale aggregazione. Lambda aggrega tutti i record ricevuti nella finestra. È possibile ricevere questi record in più batch, ciascuno come richiamo separato. Ogni richiamo riceve uno stato. Pertanto, quando si utilizzano finestre a cascata, la risposta della funzione Lambda deve contenere una proprietà di `state`. Se la risposta non contiene una proprietà di `state`, Lambda la considera un'invocazione non riuscita. Per soddisfare questa condizione, la funzione può restituire un oggetto `TimeWindowEventResponse`, che presenta la seguente forma JSON:
**Example `TimeWindowEventResponse` valori**
```
{
"state": {
"1": 282,
"2": 715
},
"batchItemFailures": []
}
```
**Nota**
Per le funzioni Java, si consiglia di utilizzare una `Map` per rappresentare lo stato.
Alla fine della finestra, il flag `isFinalInvokeForWindow` è impostato `true` per indicare che questo è lo stato finale e che è pronto per l'elaborazione. Dopo l'elaborazione, la finestra viene completata e il richiamo finale viene completato e quindi lo stato viene eliminato.
Al termine della finestra, Lambda utilizza l'elaborazione finale per le operazioni sui risultati dell'aggregazione. L'elaborazione finale viene richiamata in modo sincrono. Dopo il richiamo riuscito, la funzione controlla il numero di sequenza e l'elaborazione del flusso continua. Se il richiamo non ha esito positivo, la funzione Lambda sospende l'ulteriore elaborazione fino a quando non viene eseguito correttamente il richiamo.
**Example DynamodbTimeWindowEvent**
```
{
"Records":[
{
"eventID":"1",
"eventName":"INSERT",
"eventVersion":"1.0",
"eventSource":"aws:dynamodb",
"awsRegion":"us-east-1",
"dynamodb":{
"Keys":{
"Id":{
"N":"101"
}
},
"NewImage":{
"Message":{
"S":"New item!"
},
"Id":{
"N":"101"
}
},
"SequenceNumber":"111",
"SizeBytes":26,
"StreamViewType":"NEW_AND_OLD_IMAGES"
},
"eventSourceARN":"stream-ARN"
},
{
"eventID":"2",
"eventName":"MODIFY",
"eventVersion":"1.0",
"eventSource":"aws:dynamodb",
"awsRegion":"us-east-1",
"dynamodb":{
"Keys":{
"Id":{
"N":"101"
}
},
"NewImage":{
"Message":{
"S":"This item has changed"
},
"Id":{
"N":"101"
}
},
"OldImage":{
"Message":{
"S":"New item!"
},
"Id":{
"N":"101"
}
},
"SequenceNumber":"222",
"SizeBytes":59,
"StreamViewType":"NEW_AND_OLD_IMAGES"
},
"eventSourceARN":"stream-ARN"
},
{
"eventID":"3",
"eventName":"REMOVE",
"eventVersion":"1.0",
"eventSource":"aws:dynamodb",
"awsRegion":"us-east-1",
"dynamodb":{
"Keys":{
"Id":{
"N":"101"
}
},
"OldImage":{
"Message":{
"S":"This item has changed"
},
"Id":{
"N":"101"
}
},
"SequenceNumber":"333",
"SizeBytes":38,
"StreamViewType":"NEW_AND_OLD_IMAGES"
},
"eventSourceARN":"stream-ARN"
}
],
"window": {
"start": "2020-07-30T17:00:00Z",
"end": "2020-07-30T17:05:00Z"
},
"state": {
"1": "state1"
},
"shardId": "shard123456789",
"eventSourceARN": "stream-ARN",
"isFinalInvokeForWindow": false,
"isWindowTerminatedEarly": false
}
```
## Configurazione
È possibile configurare le finestre a cascata quando si crea o si aggiorna un mapping di origini di eventi. Per configurare una finestra rotante, specificate la finestra in secondi (). [TumblingWindowInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-TumblingWindowInSeconds) Il seguente comando di esempio AWS Command Line Interface (AWS CLI) crea una mappatura della sorgente degli eventi in streaming con una finestra di rotazione di 120 secondi. La funzione Lambda definita per l'aggregazione e l'elaborazione è denominata `tumbling-window-example-function`.
```
aws lambda create-event-source-mapping \
--event-source-arn arn:aws:dynamodb:us-east-2:123456789012:table/my-table/stream/2024-06-10T19:26:16.525 \
--function-name tumbling-window-example-function \
--starting-position TRIM_HORIZON \
--tumbling-window-in-seconds 120
```
Lambda determina i limiti delle finestre a cascata in base al momento in cui i record sono stati inseriti nel flusso. Tutti i record dispongono di un timestamp approssimativo che Lambda utilizza nelle determinazioni dei limiti.
Le aggregazioni delle finestre a cascata non supportano il risharding. Quando lo shard termina, Lambda considera la finestra chiusa e gli shard secondari iniziano la propria finestra in uno stato nuovo.
Le finestre a cascata supportano completamente le policy di ripetizione dei tentativi esistenti `maxRetryAttempts` e `maxRecordAge`.
**Example Handler.py: aggregazione ed elaborazione**
La seguente funzione Python mostra come aggregare e quindi elaborare lo stato finale:
```
def lambda_handler(event, context):
print('Incoming event: ', event)
print('Incoming state: ', event['state'])
#Check if this is the end of the window to either aggregate or process.
if event['isFinalInvokeForWindow']:
# logic to handle final state of the window
print('Destination invoke')
else:
print('Aggregate invoke')
#Check for early terminations
if event['isWindowTerminatedEarly']:
print('Window terminated early')
#Aggregation logic
state = event['state']
for record in event['Records']:
state[record['dynamodb']['NewImage']['Id']] = state.get(record['dynamodb']['NewImage']['Id'], 0) + 1
print('Returning state: ', state)
return {'state': state}
```
# Parametri Lambda per gli strumenti di mappatura dell'origine degli eventi di Amazon DynamoDB
Tutti i tipi di sorgenti di eventi Lambda condividono le stesse operazioni [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)e quelle dell'[UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)API. Tuttavia, solo alcuni dei parametri si applicano a DynamoDB Streams.
| Parametro | Obbligatorio | Predefinito | Note |
| --- | --- | --- | --- |
| BatchSize | N | 100 | Massimo: 10.000. |
| BisectBatchOnFunctionError | N | false | nessuno |
| DestinationConfig | N | N/D | Una destinazione della coda standard di Amazon SQS o di un argomento standard di Amazon SNS per i record scartati. |
| Abilitato | N | true | nessuno |
| EventSourceArn | Y | N/D | L'ARN del flusso dei dati o di un consumer di flusso. |
| FilterCriteria | N | N/D | [Controllare gli eventi che Lambda invia alla funzione](invocation-eventfiltering.md) |
| FunctionName | Y | N/D | nessuno |
| FunctionResponseTypes | N | N/D | Per consentire alla funzione di segnalare errori specifici in un batch, includi il valore `ReportBatchItemFailures` in `FunctionResponseTypes`. Per ulteriori informazioni, consulta [Configurazione della risposta batch parziale con DynamoDB e Lambda](services-ddb-batchfailurereporting.md). |
| MaximumBatchingWindowInSeconds | N | 0 | nessuno |
| MaximumRecordAgeInSeconds | N | -1 | -1 sta per infinito: i record non riusciti vengono ripetuti fino alla scadenza del record. Il [limite di conservazione dei dati per i flussi DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html#Streams.DataRetention) è di 24 ore. Minimo: -1 Massimo: 604.800 |
| MaximumRetryAttempts | N | -1 | -1 sta per infinito: i record non riusciti vengono ripetuti fino alla scadenza del record Minimo: 0 Massimo: 10.000. |
| ParallelizationFactor | N | 1 | Maximum: 10 |
| StartingPosition | Y | N/D | TRIM\$1HORIZON o LATEST |
| TumblingWindowInSeconds | N | N/D | Minimo: 0 Massimo: 900 |
# Utilizzo del filtro eventi con un'origine eventi DynamoDB
Puoi utilizzare il filtraggio degli eventi per controllare quali record di un flusso o di una coda Lambda invia alla funzione. Per informazioni generali sul funzionamento del filtraggio eventi, consulta [Controllare gli eventi che Lambda invia alla funzione](invocation-eventfiltering.md).
In questa sezione viene descritto il filtraggio degli eventi per le origini eventi DynamoDB.
**Nota**
Le mappature delle sorgenti degli eventi DynamoDB supportano solo il filtraggio sulla chiave. `dynamodb`
**Topics**
+ [
## Evento DynamoDB
](#filtering-ddb)
+ [
## Filtraggio con attributi di tabella
](#filtering-ddb-attributes)
+ [
## Filtraggio con espressioni booleane
](#filtering-ddb-boolean)
+ [
## Utilizzo dell'operatore Exists
](#filtering-ddb-exists)
+ [
## Formato JSON per il filtro DynamoDB
](#filtering-ddb-JSON-format)
## Evento DynamoDB
Supponiamo di avere una tabella DynamoDB con la chiave primaria `CustomerName` e gli attributi `AccountManager` e `PaymentTerms`. Di seguito è riportato un esempio di record dal flusso della tabella DynamoDB.
```
{
"eventID": "1",
"eventVersion": "1.0",
"dynamodb": {
"ApproximateCreationDateTime": "1678831218.0",
"Keys": {
"CustomerName": {
"S": "AnyCompany Industries"
}
},
"NewImage": {
"AccountManager": {
"S": "Pat Candella"
},
"PaymentTerms": {
"S": "60 days"
},
"CustomerName": {
"S": "AnyCompany Industries"
}
},
"SequenceNumber": "111",
"SizeBytes": 26,
"StreamViewType": "NEW_IMAGE"
}
}
```
Per filtrare in base ai valori della chiave e degli attributi nella tabella DynamoDB, utilizza la chiave `dynamodb` nel record. Le seguenti sezioni forniscono esempi per diversi tipi di filtri.
### Filtraggio con chiavi di tabella
Supponiamo che tu voglia che la tua funzione elabori solo i record in cui la chiave primaria `CustomerName` è "AnyCompany Industries". L'oggetto `FilterCriteria` dovrebbe avere la struttura seguente.
```
{
"Filters": [
{
"Pattern": "{ \"dynamodb\" : { \"Keys\" : { \"CustomerName\" : { \"S\" : [ \"AnyCompany Industries\" ] } } } }"
}
]
}
```
Per una maggiore chiarezza, ecco il valore del `Pattern` del filtro espanso in JSON semplice.
```
{
"dynamodb": {
"Keys": {
"CustomerName": {
"S": [ "AnyCompany Industries" ]
}
}
}
}
```
Puoi aggiungere il filtro utilizzando la console, la AWS CLI o un modello AWS SAM.
------
#### [ Console ]
Per aggiungere questo filtro utilizzando la console, segui le istruzioni riportate in [Collegamento dei criteri di filtro a una mappatura dell'origine evento (console)](invocation-eventfiltering.md#filtering-console) e inserisci la seguente stringa per i **criteri di filtraggio**.
```
{ "dynamodb" : { "Keys" : { "CustomerName" : { "S" : [ "AnyCompany Industries" ] } } } }
```
------
#### [ AWS CLI ]
Per creare una nuova mappatura dell'origine degli eventi con questi criteri di filtraggio utilizzando l'AWS Command Line Interface (AWS CLI), esegui il comando seguente.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:dynamodb:us-east-2:123456789012:table/my-table \
--filter-criteria '{"Filters": [{"Pattern": "{ \"dynamodb\" : { \"Keys\" : { \"CustomerName\" : { \"S\" : [ \"AnyCompany Industries\" ] } } } }"}]}'
```
Per aggiungere questi criteri di filtraggio a una mappatura dell'origine degli eventi esistente, esegui il comando seguente.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"dynamodb\" : { \"Keys\" : { \"CustomerName\" : { \"S\" : [ \"AnyCompany Industries\" ] } } } }"}]}'
```
------
#### [ AWS SAM ]
Per aggiungere questo filtro utilizzando AWS SAM, aggiungi il seguente frammento al modello YAML dell'origine degli eventi.
```
FilterCriteria:
Filters:
- Pattern: '{ "dynamodb" : { "Keys" : { "CustomerName" : { "S" : [ "AnyCompany Industries" ] } } } }'
```
------
## Filtraggio con attributi di tabella
Con DynamoDB, puoi anche utilizzare le chiavi `NewImage` e `OldImage` per filtrare i valori degli attributi. Supponiamo di voler filtrare i record in cui l'attributo `AccountManager` nell'ultima immagine della tabella è "Pat Candella" o "Shirley Rodriguez". L'oggetto `FilterCriteria` dovrebbe avere la struttura seguente.
```
{
"Filters": [
{
"Pattern": "{ \"dynamodb\" : { \"NewImage\" : { \"AccountManager\" : { \"S\" : [ \"Pat Candella\", \"Shirley Rodriguez\" ] } } } }"
}
]
}
```
Per una maggiore chiarezza, ecco il valore del `Pattern` del filtro espanso in JSON semplice.
```
{
"dynamodb": {
"NewImage": {
"AccountManager": {
"S": [ "Pat Candella", "Shirley Rodriguez" ]
}
}
}
}
```
Puoi aggiungere il filtro utilizzando la console, la AWS CLI o un modello AWS SAM.
------
#### [ Console ]
Per aggiungere questo filtro utilizzando la console, segui le istruzioni riportate in [Collegamento dei criteri di filtro a una mappatura dell'origine evento (console)](invocation-eventfiltering.md#filtering-console) e inserisci la seguente stringa per i **criteri di filtraggio**.
```
{ "dynamodb" : { "NewImage" : { "AccountManager" : { "S" : [ "Pat Candella", "Shirley Rodriguez" ] } } } }
```
------
#### [ AWS CLI ]
Per creare una nuova mappatura dell'origine degli eventi con questi criteri di filtraggio utilizzando l'AWS Command Line Interface (AWS CLI), esegui il comando seguente.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:dynamodb:us-east-2:123456789012:table/my-table \
--filter-criteria '{"Filters": [{"Pattern": "{ \"dynamodb\" : { \"NewImage\" : { \"AccountManager\" : { \"S\" : [ \"Pat Candella\", \"Shirley Rodriguez\" ] } } } }"}]}'
```
Per aggiungere questi criteri di filtraggio a una mappatura dell'origine degli eventi esistente, esegui il comando seguente.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"dynamodb\" : { \"NewImage\" : { \"AccountManager\" : { \"S\" : [ \"Pat Candella\", \"Shirley Rodriguez\" ] } } } }"}]}'
```
------
#### [ AWS SAM ]
Per aggiungere questo filtro utilizzando AWS SAM, aggiungi il seguente frammento al modello YAML dell'origine degli eventi.
```
FilterCriteria:
Filters:
- Pattern: '{ "dynamodb" : { "NewImage" : { "AccountManager" : { "S" : [ "Pat Candella", "Shirley Rodriguez" ] } } } }'
```
------
## Filtraggio con espressioni booleane
È inoltre possibile creare filtri utilizzando espressioni booleane AND. Queste espressioni possono includere sia i parametri chiave sia quelli degli attributi della tabella. Supponiamo che tu voglia filtrare i record in cui il valore di `NewImage` di `AccountManager` è "Pat Candella" e il valore di `OldImage` è "Terry Whitlock". L'oggetto `FilterCriteria` dovrebbe avere la struttura seguente.
```
{
"Filters": [
{
"Pattern": "{ \"dynamodb\" : { \"NewImage\" : { \"AccountManager\" : { \"S\" : [ \"Pat Candella\" ] } } } , \"dynamodb\" : { \"OldImage\" : { \"AccountManager\" : { \"S\" : [ \"Terry Whitlock\" ] } } } }"
}
]
}
```
Per una maggiore chiarezza, ecco il valore del `Pattern` del filtro espanso in JSON semplice.
```
{
"dynamodb" : {
"NewImage" : {
"AccountManager" : {
"S" : [
"Pat Candella"
]
}
}
},
"dynamodb": {
"OldImage": {
"AccountManager": {
"S": [
"Terry Whitlock"
]
}
}
}
}
```
Puoi aggiungere il filtro utilizzando la console, la AWS CLI o un modello AWS SAM.
------
#### [ Console ]
Per aggiungere questo filtro utilizzando la console, segui le istruzioni riportate in [Collegamento dei criteri di filtro a una mappatura dell'origine evento (console)](invocation-eventfiltering.md#filtering-console) e inserisci la seguente stringa per i **criteri di filtraggio**.
```
{ "dynamodb" : { "NewImage" : { "AccountManager" : { "S" : [ "Pat Candella" ] } } } , "dynamodb" : { "OldImage" : { "AccountManager" : { "S" : [ "Terry Whitlock" ] } } } }
```
------
#### [ AWS CLI ]
Per creare una nuova mappatura dell'origine degli eventi con questi criteri di filtraggio utilizzando l'AWS Command Line Interface (AWS CLI), esegui il comando seguente.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:dynamodb:us-east-2:123456789012:table/my-table \
--filter-criteria '{"Filters": [{"Pattern": "{ \"dynamodb\" : { \"NewImage\" : { \"AccountManager\" : { \"S\" : [ \"Pat Candella\" ] } } } , \"dynamodb\" : { \"OldImage\" : { \"AccountManager\" : { \"S\" : [ \"Terry Whitlock\" ] } } } } "}]}'
```
Per aggiungere questi criteri di filtraggio a una mappatura dell'origine degli eventi esistente, esegui il comando seguente.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"dynamodb\" : { \"NewImage\" : { \"AccountManager\" : { \"S\" : [ \"Pat Candella\" ] } } } , \"dynamodb\" : { \"OldImage\" : { \"AccountManager\" : { \"S\" : [ \"Terry Whitlock\" ] } } } } "}]}'
```
------
#### [ AWS SAM ]
Per aggiungere questo filtro utilizzando AWS SAM, aggiungi il seguente frammento al modello YAML dell'origine degli eventi.
```
FilterCriteria:
Filters:
- Pattern: '{ "dynamodb" : { "NewImage" : { "AccountManager" : { "S" : [ "Pat Candella" ] } } } , "dynamodb" : { "OldImage" : { "AccountManager" : { "S" : [ "Terry Whitlock" ] } } } }'
```
------
**Nota**
Il filtraggio degli eventi DynamoDB non supporta l'uso di operatori numerici (uguali numerici e intervallo numerico). Anche se gli elementi della tabella sono memorizzati come numeri, questi parametri vengono convertiti in stringhe nell'oggetto record JSON.
## Utilizzo dell'operatore Exists
A causa del modo in cui sono strutturati gli oggetti evento JSON di DynamoDB, l'utilizzo dell'operatore Exists richiede particolare attenzione. L'operatore Exists funziona solo sui nodi foglia nel JSON dell'evento, quindi se il modello di filtro utilizza Exists per testare un nodo intermedio, non funzionerà. Considera il seguente elemento della tabella DynamoDB:
```
{
"UserID": {"S": "12345"},
"Name": {"S": "John Doe"},
"Organizations": {"L": [
{"S":"Sales"},
{"S":"Marketing"},
{"S":"Support"}
]
}
}
```
Potresti voler creare uno schema di filtro come il seguente per verificare la presenza di eventi contenenti `"Organizations"`:
```
{ "dynamodb" : { "NewImage" : { "Organizations" : [ { "exists": true } ] } } }
```
Tuttavia, questo modello di filtro non restituirebbe mai una corrispondenza perché `"Organizations"` non è un nodo foglia. L'esempio seguente mostra come utilizzare correttamente l'operatore Exists per creare lo schema di filtro desiderato:
```
{ "dynamodb" : { "NewImage" : {"Organizations": {"L": {"S": [ {"exists": true } ] } } } } }
```
## Formato JSON per il filtro DynamoDB
Per filtrare correttamente gli eventi da origini DynamoDB, sia il campo dati sia i criteri di filtraggio per il campo dati (`dynamodb`) devono essere in un formato JSON valido. Se uno dei due campi non è in un formato JSON valido, Lambda rilascia il messaggio o genera un'eccezione. La tabella seguente riepiloga il comportamento specifico:
| Formato dei dati in entrata | Formato del modello di filtro per le proprietà di dati | Operazione risultante |
| --- | --- | --- |
| JSON valido | JSON valido | Filtri Lambda in base ai criteri di filtro. |
| JSON valido | Nessun modello di filtro per le proprietà dei dati | Filtri Lambda (solo sulle altre proprietà dei metadati) in base ai criteri di filtro. |
| JSON valido | Non-JSON | Lambda genera un'eccezione al momento della creazione o dell'aggiornamento della mappatura dell'origine evento. Il modello di filtro per le proprietà dei dati deve essere in un formato JSON valido. |
| Non-JSON | JSON valido | Lambda rilascia il registro. |
| Non-JSON | Nessun modello di filtro per le proprietà dei dati | Filtri Lambda (solo sulle altre proprietà dei metadati) in base ai criteri di filtro. |
| Non-JSON | Non-JSON | Lambda genera un'eccezione al momento della creazione o dell'aggiornamento della mappatura dell'origine evento. Il modello di filtro per le proprietà dei dati deve essere in un formato JSON valido. |
# Tutorial: Utilizzo AWS Lambda con flussi Amazon DynamoDB
In questo tutorial creerai una funzione Lambda per consumare eventi da un flusso Amazon DynamoDB.
## Prerequisiti
### Installa il AWS Command Line Interface
Se non l'hai ancora installato AWS Command Line Interface, segui i passaggi indicati in [Installazione o aggiornamento della versione più recente di AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) per installarlo.
Per eseguire i comandi nel tutorial, sono necessari un terminale a riga di comando o una shell (interprete di comandi). In Linux e macOS, utilizza la shell (interprete di comandi) e il gestore pacchetti preferiti.
**Nota**
Su Windows, alcuni comandi della CLI Bash utilizzati comunemente con Lambda (ad esempio, `zip`) non sono supportati dai terminali integrati del sistema operativo. Per ottenere una versione integrata su Windows di Ubuntu e Bash, [installa il sottosistema Windows per Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10).
## Creazione del ruolo di esecuzione
Crea il [ruolo di esecuzione](lambda-intro-execution-role.md) che autorizza la funzione ad accedere alle AWS risorse.
**Per creare un ruolo di esecuzione**
1. Apri la pagina [Ruoli](https://console.aws.amazon.com/iam/home#/roles) nella console IAM.
1. Scegliere **Crea ruolo**.
1. Creare un ruolo con le seguenti proprietà.
+ **Entità attendibile** – Lambda.
+ **Autorizzazioni** — **AWSLambdaDBExecutionDynamo** Role.
+ **Nome ruolo** – **lambda-dynamodb-role**.
Il **DBExecutionruolo AWSLambda Dynamo** dispone delle autorizzazioni necessarie alla funzione per leggere gli elementi da DynamoDB e scrivere i log nei log. CloudWatch
## Creazione della funzione
Crea una funzione Lambda che elabora gli eventi DynamoDB. Il codice della funzione scrive alcuni dei dati degli eventi in entrata in Logs. CloudWatch
------
#### [ .NET ]
**SDK per .NET**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda).
Utilizzo di un evento DynamoDB con Lambda tramite .NET.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using System.Text.Json;
using System.Text;
using Amazon.Lambda.Core;
using Amazon.Lambda.DynamoDBEvents;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace AWSLambda_DDB;
public class Function
{
public void FunctionHandler(DynamoDBEvent dynamoEvent, ILambdaContext context)
{
context.Logger.LogInformation($"Beginning to process {dynamoEvent.Records.Count} records...");
foreach (var record in dynamoEvent.Records)
{
context.Logger.LogInformation($"Event ID: {record.EventID}");
context.Logger.LogInformation($"Event Name: {record.EventName}");
context.Logger.LogInformation(JsonSerializer.Serialize(record));
}
context.Logger.LogInformation("Stream processing complete.");
}
}
```
------
#### [ Go ]
**SDK per Go V2**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda).
Utilizzo di un evento DynamoDB con Lambda tramite Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package main
import (
"context"
"github.com/aws/aws-lambda-go/lambda"
"github.com/aws/aws-lambda-go/events"
"fmt"
)
func HandleRequest(ctx context.Context, event events.DynamoDBEvent) (*string, error) {
if len(event.Records) == 0 {
return nil, fmt.Errorf("received empty event")
}
for _, record := range event.Records {
LogDynamoDBRecord(record)
}
message := fmt.Sprintf("Records processed: %d", len(event.Records))
return &message, nil
}
func main() {
lambda.Start(HandleRequest)
}
func LogDynamoDBRecord(record events.DynamoDBEventRecord){
fmt.Println(record.EventID)
fmt.Println(record.EventName)
fmt.Printf("%+v\n", record.Change)
}
```
------
#### [ Java ]
**SDK per Java 2.x**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda).
Utilizzo di un evento DynamoDB con Lambda tramite Java.
```
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.DynamodbEvent;
import com.amazonaws.services.lambda.runtime.events.DynamodbEvent.DynamodbStreamRecord;
import com.google.gson.Gson;
import com.google.gson.GsonBuilder;
public class example implements RequestHandler {
private static final Gson GSON = new GsonBuilder().setPrettyPrinting().create();
@Override
public Void handleRequest(DynamodbEvent event, Context context) {
System.out.println(GSON.toJson(event));
event.getRecords().forEach(this::logDynamoDBRecord);
return null;
}
private void logDynamoDBRecord(DynamodbStreamRecord record) {
System.out.println(record.getEventID());
System.out.println(record.getEventName());
System.out.println("DynamoDB Record: " + GSON.toJson(record.getDynamodb()));
}
}
```
------
#### [ JavaScript ]
**SDK per JavaScript (v3)**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda).
Consumo di un evento DynamoDB con Lambda utilizzando. JavaScript
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
exports.handler = async (event, context) => {
console.log(JSON.stringify(event, null, 2));
event.Records.forEach(record => {
logDynamoDBRecord(record);
});
};
const logDynamoDBRecord = (record) => {
console.log(record.eventID);
console.log(record.eventName);
console.log(`DynamoDB Record: ${JSON.stringify(record.dynamodb)}`);
};
```
Consumo di un evento DynamoDB con Lambda utilizzando. TypeScript
```
export const handler = async (event, context) => {
console.log(JSON.stringify(event, null, 2));
event.Records.forEach(record => {
logDynamoDBRecord(record);
});
}
const logDynamoDBRecord = (record) => {
console.log(record.eventID);
console.log(record.eventName);
console.log(`DynamoDB Record: ${JSON.stringify(record.dynamodb)}`);
};
```
------
#### [ PHP ]
**SDK per PHP**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda).
Utilizzo di un evento DynamoDB con Lambda tramite PHP.
```
logger = $logger;
}
/**
* @throws JsonException
* @throws \Bref\Event\InvalidLambdaEvent
*/
public function handleDynamoDb(DynamoDbEvent $event, Context $context): void
{
$this->logger->info("Processing DynamoDb table items");
$records = $event->getRecords();
foreach ($records as $record) {
$eventName = $record->getEventName();
$keys = $record->getKeys();
$old = $record->getOldImage();
$new = $record->getNewImage();
$this->logger->info("Event Name:".$eventName."\n");
$this->logger->info("Keys:". json_encode($keys)."\n");
$this->logger->info("Old Image:". json_encode($old)."\n");
$this->logger->info("New Image:". json_encode($new));
// TODO: Do interesting work based on the new data
// Any exception thrown will be logged and the invocation will be marked as failed
}
$totalRecords = count($records);
$this->logger->info("Successfully processed $totalRecords items");
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**SDK per Python (Boto3)**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda).
Utilizzo di un evento DynamoDB con Lambda tramite Python.
```
import json
def lambda_handler(event, context):
print(json.dumps(event, indent=2))
for record in event['Records']:
log_dynamodb_record(record)
def log_dynamodb_record(record):
print(record['eventID'])
print(record['eventName'])
print(f"DynamoDB Record: {json.dumps(record['dynamodb'])}")
```
------
#### [ Ruby ]
**SDK per Ruby**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda).
Utilizzo di un evento DynamoDB con Lambda tramite Ruby.
```
def lambda_handler(event:, context:)
return 'received empty event' if event['Records'].empty?
event['Records'].each do |record|
log_dynamodb_record(record)
end
"Records processed: #{event['Records'].length}"
end
def log_dynamodb_record(record)
puts record['eventID']
puts record['eventName']
puts "DynamoDB Record: #{JSON.generate(record['dynamodb'])}"
end
```
------
#### [ Rust ]
**SDK per Rust**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda).
Utilizzo di un evento DynamoDB con Lambda tramite Rust.
```
use lambda_runtime::{service_fn, tracing, Error, LambdaEvent};
use aws_lambda_events::{
event::dynamodb::{Event, EventRecord},
};
// Built with the following dependencies:
//lambda_runtime = "0.11.1"
//serde_json = "1.0"
//tokio = { version = "1", features = ["macros"] }
//tracing = { version = "0.1", features = ["log"] }
//tracing-subscriber = { version = "0.3", default-features = false, features = ["fmt"] }
//aws_lambda_events = "0.15.0"
async fn function_handler(event: LambdaEvent) ->Result<(), Error> {
let records = &event.payload.records;
tracing::info!("event payload: {:?}",records);
if records.is_empty() {
tracing::info!("No records found. Exiting.");
return Ok(());
}
for record in records{
log_dynamo_dbrecord(record);
}
tracing::info!("Dynamo db records processed");
// Prepare the response
Ok(())
}
fn log_dynamo_dbrecord(record: &EventRecord)-> Result<(), Error>{
tracing::info!("EventId: {}", record.event_id);
tracing::info!("EventName: {}", record.event_name);
tracing::info!("DynamoDB Record: {:?}", record.change );
Ok(())
}
#[tokio::main]
async fn main() -> Result<(), Error> {
tracing_subscriber::fmt()
.with_max_level(tracing::Level::INFO)
.with_target(false)
.without_time()
.init();
let func = service_fn(function_handler);
lambda_runtime::run(func).await?;
Ok(())
}
```
------
**Per creare la funzione**
1. Copiare il codice di esempio in un file denominato `example.js`.
1. Crea un pacchetto di implementazione.
```
zip function.zip example.js
```
1. Creare una funzione Lambda con il comando `create-function`.
```
aws lambda create-function --function-name ProcessDynamoDBRecords \
--zip-file fileb://function.zip --handler example.handler --runtime nodejs24.x \
--role arn:aws:iam::111122223333:role/lambda-dynamodb-role
```
## Test della funzione Lambda
In questo passaggio, si richiama manualmente la funzione Lambda utilizzando il comando `invoke` AWS Lambda CLI e il seguente evento DynamoDB di esempio. Copia quanto riportato di seguito in un file denominato `input.txt`.
**Example input.txt**
```
{
"Records":[
{
"eventID":"1",
"eventName":"INSERT",
"eventVersion":"1.0",
"eventSource":"aws:dynamodb",
"awsRegion":"us-east-1",
"dynamodb":{
"Keys":{
"Id":{
"N":"101"
}
},
"NewImage":{
"Message":{
"S":"New item!"
},
"Id":{
"N":"101"
}
},
"SequenceNumber":"111",
"SizeBytes":26,
"StreamViewType":"NEW_AND_OLD_IMAGES"
},
"eventSourceARN":"stream-ARN"
},
{
"eventID":"2",
"eventName":"MODIFY",
"eventVersion":"1.0",
"eventSource":"aws:dynamodb",
"awsRegion":"us-east-1",
"dynamodb":{
"Keys":{
"Id":{
"N":"101"
}
},
"NewImage":{
"Message":{
"S":"This item has changed"
},
"Id":{
"N":"101"
}
},
"OldImage":{
"Message":{
"S":"New item!"
},
"Id":{
"N":"101"
}
},
"SequenceNumber":"222",
"SizeBytes":59,
"StreamViewType":"NEW_AND_OLD_IMAGES"
},
"eventSourceARN":"stream-ARN"
},
{
"eventID":"3",
"eventName":"REMOVE",
"eventVersion":"1.0",
"eventSource":"aws:dynamodb",
"awsRegion":"us-east-1",
"dynamodb":{
"Keys":{
"Id":{
"N":"101"
}
},
"OldImage":{
"Message":{
"S":"This item has changed"
},
"Id":{
"N":"101"
}
},
"SequenceNumber":"333",
"SizeBytes":38,
"StreamViewType":"NEW_AND_OLD_IMAGES"
},
"eventSourceARN":"stream-ARN"
}
]
}
```
Eseguire il seguente comando `invoke`.
```
aws lambda invoke --function-name ProcessDynamoDBRecords \
--cli-binary-format raw-in-base64-out \
--payload file://input.txt outputfile.txt
```
L'**cli-binary-format**opzione è obbligatoria se si utilizza la versione 2. AWS CLI Per rendere questa impostazione come predefinita, esegui `aws configure set cli-binary-format raw-in-base64-out`. Per ulteriori informazioni, consulta la pagina [AWS CLI supported global command line options](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) nella *Guida per l'utente di AWS Command Line Interface versione 2*.
La funzione restituisce la stringa `message` nel corpo della risposta.
Verificare l'output nel file `outputfile.txt`.
## Creazione di una tabella DynamoDB con un flusso abilitato
Crea una tabella Amazon DynamoDB con un flusso abilitato.
**Per creare una tabella DynamoDB**
1. Aprire la [console DynamoDB](https://console.aws.amazon.com/dynamodb).
1. Scegliere **Create table (Crea tabella)**.
1. Creare una tabella con le impostazioni seguenti.
+ **Table name (Nome tabella)** – **lambda-dynamodb-stream**
+ **Primary key (Chiave primaria)** – **id** (string)
1. Scegliere **Create (Crea)**.
**Per abilitare i flussi**
1. Aprire la [console DynamoDB](https://console.aws.amazon.com/dynamodb).
1. Scegliere **Tables (Tabelle)**.
1. Seleziona la tabella **lambda-dynamodb-stream**.
1. In **Exports and streams (Esportazioni e flussi)**, scegliere **DynamDB stream details (Dettagli del flusso di Dynamo DB)**.
1. Scegliere **Turn On (Attiva)**.
1. Per **Tipo di visualizzazione**, scegli **Solo attributi chiave**.
1. Scegli **Attiva il flusso**.
Prendi nota dell'ARN del flusso. Questa operazione è necessaria nella fase successiva quando si associa il flusso alla funzione Lambda. Per ulteriori informazioni sull'attivazione dei flussi, consultare [Acquisizione dell'attività sulla tabella tramite DynamoDB Streams](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html).
## Aggiungi una fonte di eventi in AWS Lambda
Creare una mappatura dell'origine eventi in AWS Lambda. Questa mappatura dell'origine eventi associa il flusso DynamoDB alla funzione Lambda. Dopo aver creato questa mappatura delle sorgenti degli eventi, AWS Lambda inizia il polling dello stream.
Eseguire il seguente comando AWS CLI `create-event-source-mapping`. Dopo l'esecuzione del comando, annotare l'UUID. Questo UUID è necessario per fare riferimento alla mappatura delle origini eventi nei comandi, ad esempio quando si elimina tale mappatura.
```
aws lambda create-event-source-mapping --function-name ProcessDynamoDBRecords \
--batch-size 100 --starting-position LATEST --event-source DynamoDB-stream-arn
```
Questa procedura crea una mappatura tra il flusso DynamoDB specificato e la funzione Lambda. È possibile associare un flusso DynamoDB a più funzioni Lambda e associare la stessa funzione Lambda a più flussi. Tuttavia, le funzioni Lambda condivideranno il throughput di lettura per il flusso che condividono.
Mediante l'esecuzione del comando riportato di seguito è possibile ottenere l'elenco di mappature delle origini eventi.
```
aws lambda list-event-source-mappings
```
L'elenco restituisce tutte le mappature delle origini eventi create e per ciascuna mappatura mostra, tra l'altro, il valore `LastProcessingResult`. Questo campo è utilizzato per fornire un messaggio informativo nel caso in cui vengano riscontrati problemi. Valori come `No records processed` (indica che non AWS Lambda è stato avviato il polling o che non ci sono record nello stream) e `OK` (indica che i record dallo stream sono AWS Lambda stati letti correttamente e che è stata richiamata la funzione Lambda) indicano che non ci sono problemi. Se vengono riscontrati problemi, si riceve un messaggio di errore.
Se disponi di una grande quantità di mappature delle origini eventi, utilizza il parametro funzione-nome per restringere i risultati.
```
aws lambda list-event-source-mappings --function-name ProcessDynamoDBRecords
```
## Eseguire il test della configurazione
Metti alla prova l'esperienza. end-to-end Quando vengono eseguiti gli aggiornamenti delle tabelle, DynamoDB scrive record di eventi nel flusso. Quando AWS Lambda esegue il polling del flusso, rileva nuovi record nel flusso e richiama la funzione Lambda per proprio conto passando eventi alla funzione.
1. Nella console di DynamoDB, aggiungi, aggiorna ed elimina elementi dalla tabella. DynamoDB scrive record di queste operazioni nel flusso.
1. AWS Lambda esegue il polling dello stream e quando rileva aggiornamenti allo stream richiama la funzione Lambda passando i dati degli eventi che trova nello stream.
1. La tua funzione viene eseguita e crea registri in Amazon CloudWatch. Puoi verificare i log riportati nella CloudWatch console Amazon.
## Fasi successive
Questo tutorial ti ha mostrato le basi dell'elaborazione degli eventi di flusso DynamoDB con Lambda. Per i carichi di lavoro di produzione, prendi in considerazione l'implementazione della logica di risposta parziale in batch per gestire gli errori dei singoli record in modo più efficiente. [L'utilità di elaborazione batch](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/) di Powertools for AWS Lambda è disponibile in Python TypeScript, .NET e Java e fornisce una soluzione robusta per questo, gestendo automaticamente la complessità delle risposte parziali in batch e riducendo il numero di tentativi per i record elaborati correttamente.
## Pulizia delle risorse
Ora è possibile eliminare le risorse create per questo tutorial, a meno che non si voglia conservarle. Eliminando AWS le risorse che non utilizzi più, eviti addebiti inutili ai tuoi. Account AWS
**Per eliminare la funzione Lambda**
1. Aprire la pagina [Functions (Funzioni)](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Selezionare la funzione creata.
1. Scegliere **Operazioni**, **Elimina**.
1. Inserisci **confirm** nel campo di immissione del testo, quindi scegli **Elimina**.
**Come eliminare il ruolo di esecuzione**
1. Aprire la pagina [Ruoli](https://console.aws.amazon.com/iam/home#/roles) della console IAM.
1. Selezionare il ruolo di esecuzione creato.
1. Scegliere **Elimina**.
1. Inserisci il nome del ruolo nel campo di immissione testo e seleziona **Delete** (Elimina).
**Per eliminare la tabella DynamoDB**
1. Aprire la pagina [Tables (Tabelle)](https://console.aws.amazon.com//dynamodb/home#tables:) della console DynamoDB.
1. Selezionare la tabella creata.
1. Scegliere **Delete (Elimina)**.
1. Immettere **delete** nella casella di testo.
1. Seleziona **Delete Table (Elimina tabella)**.
# Elaborare gli eventi del ciclo di vita di Amazon EC2 con una funzione Lambda
Puoi utilizzare AWS Lambda per elaborare gli eventi del ciclo di vita da Amazon Elastic Compute Cloud e gestire le risorse Amazon EC2. Amazon EC2 invia gli eventi ad [Amazon EventBridge (Eventi CloudWatch)](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) per [eventi del ciclo di vita](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-lifecycle.html), ad esempio quando un'istanza cambia stato, quando viene completata una snapshot del volume di Amazon Elastic Block Store o quando un'istanza spot è pianificata per essere terminata. È possibile configurare EventBridge (CloudWatch Events) per inoltrare tali eventi a una funzione Lambda per l'elaborazione.
EventBridge (CloudWatch Events) richiama la funzione Lambda in modo asincrono con il documento di evento da Amazon EC2.
**Example Evento del ciclo di vita dell'istanza**
```
{
"version": "0",
"id": "b6ba298a-7732-2226-xmpl-976312c1a050",
"detail-type": "EC2 Instance State-change Notification",
"source": "aws.ec2",
"account": "111122223333",
"time": "2019-10-02T17:59:30Z",
"region": "us-east-1",
"resources": [
"arn:aws:ec2:us-east-1:111122223333:instance/i-0c314xmplcd5b8173"
],
"detail": {
"instance-id": "i-0c314xmplcd5b8173",
"state": "running"
}
}
```
Per informazioni dettagliate sulla configurazione degli eventi, consulta [Richiamo di una funzione Lambda su una pianificazione](with-eventbridge-scheduler.md). Per una funzione di esempio che elabora le notifiche di snapshot Amazon EBS, consulta [Pianificatore EventBridge per Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-cloud-watch-events.html).
È inoltre possibile utilizzare l'SDK AWS per gestire istanze e altre risorse con l'API Amazon EC2.
## Concessione di autorizzazioni a EventBridge (Eventi CloudWatch)
Per elaborare gli eventi del ciclo di vita da Amazon EC2, EventBridge (CloudWatch Events) deve disporre dell'autorizzazione per richiamare la funzione. Questa autorizzazione proviene dalla [policy basata sulle risorse](access-control-resource-based.md) della funzione. Se si utilizza la console EventBridge (CloudWatch Events) per configurare un trigger di evento, la console aggiorna la policy basata sulle risorse per tuo conto. In caso contrario, aggiungere un'istruzione come la seguente:
**Example Dichiarazione della policy basata sulle risorse per le notifiche del ciclo di vita di Amazon EC2**
```
{
"Sid": "ec2-events",
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-1:12456789012:function:my-function",
"Condition": {
"ArnLike": {
"AWS:SourceArn": "arn:aws:events:us-east-1:12456789012:rule/*"
}
}
}
```
Per aggiungere un'istruzione, utilizzare il comando `add-permission` della AWS CLI.
```
aws lambda add-permission --action lambda:InvokeFunction --statement-id ec2-events \
--principal events.amazonaws.com --function-name my-function --source-arn 'arn:aws:events:us-east-1:12456789012:rule/*'
```
Se la funzione utilizza l'SDK AWS per gestire le risorse Amazon EC2, aggiungere le autorizzazioni Amazon EC2 al [ruolo di esecuzione](lambda-intro-execution-role.md) della funzione.
# Elaborare le richieste di Application Load Balancer con Lambda
È possibile utilizzare una funzione Lambda per elaborare le richieste di un Application Load Balancer. Elastic Load Balancing supporta le funzioni Lambda come target per un Application Load Balancer. Utilizza le regole per il sistema di bilanciamento del carico per indirizzare le richieste HTTP a una funzione in base ai valori del percorso o dell'intestazione. Elabora la richiesta e restituisce una risposta HTTP dalla funzione Lambda.
Elastic Load Balancing richiama la funzione Lambda in modo sincrono con un evento contenente il corpo della richiesta e i metadati.
**Example Evento di richiesta Application Load Balancer**
```
{
"requestContext": {
"elb": {
"targetGroupArn": "arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/lambda-279XGJDqGZ5rsrHC2Fjr/49e9d65c45c6791a"
}
},
"httpMethod": "GET",
"path": "/lambda",
"queryStringParameters": {
"query": "1234ABCD"
},
"headers": {
"accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8",
"accept-encoding": "gzip",
"accept-language": "en-US,en;q=0.9",
"connection": "keep-alive",
"host": "lambda-alb-123578498.us-east-1.elb.amazonaws.com",
"upgrade-insecure-requests": "1",
"user-agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36",
"x-amzn-trace-id": "Root=1-5c536348-3d683b8b04734faae651f476",
"x-forwarded-for": "72.12.164.125",
"x-forwarded-port": "80",
"x-forwarded-proto": "http",
"x-imforwards": "20"
},
"body": "",
"isBase64Encoded": False
}
```
La funzione elabora l'evento e restituisce un documento di risposta al sistema di bilanciamento del carico in JSON. Elastic Load Balancing converte il documento in una risposta HTTP di esito positivo o negativo e la restituisce all'utente.
**Example Formato del documento di risposta**
```
{
"statusCode": 200,
"statusDescription": "200 OK",
"isBase64Encoded": False,
"headers": {
"Content-Type": "text/html"
},
"body": "Hello from Lambda!
"
}
```
Per configurare un Application Load Balancer come trigger di funzione, concedi l'autorizzazione Elastic Load Balancing per eseguire la funzione, crea un gruppo di destinazioni che instradi le richieste alla funzione e aggiungi una regola al sistema di bilanciamento del carico che invia le richieste al gruppo di destinazioni.
Utilizza il comando `add-permission` per aggiungere un'istruzione di autorizzazione alla policy basata sulle risorse della funzione.
```
aws lambda add-permission --function-name alb-function \
--statement-id load-balancer --action "lambda:InvokeFunction" \
--principal elasticloadbalancing.amazonaws.com
```
Verrà visualizzato l’output seguente:
```
{
"Statement": "{\"Sid\":\"load-balancer\",\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"elasticloadbalancing.amazonaws.com\"},\"Action\":\"lambda:InvokeFunction\",\"Resource\":\"arn:aws:lambda:us-west-2:123456789012:function:alb-function\"}"
}
```
Per istruzioni su come configurare il gruppo di destinazione e il listener di Application Load Balancer, consulta [funzioni Lambda come target](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html) nella *Guida per l'utente dei sistemi Application Load Balancer*.
## Gestore di eventi di Powertools per Lambda AWS
Il gestore di eventi del toolkit Powertools for AWS Lambda fornisce routing, middleware, configurazione CORS, generazione di specifiche OpenAPI, convalida delle richieste, gestione degli errori e altre funzioni utili per la scrittura di funzioni Lambda richiamate da un Application Load Balancer. L'utilità Event Handler è disponibile per Python. Per ulteriori informazioni, consulta [l'API REST di Event Handler](https://docs.powertools.aws.dev/lambda/python/latest/core/event_handler/api_gateway/) nella documentazione di *Powertools for AWS Lambda (Python)*.
### Python
```
import requests
from requests import Response
from aws_lambda_powertools import Logger, Tracer
from aws_lambda_powertools.event_handler import ALBResolver
from aws_lambda_powertools.logging import correlation_paths
from aws_lambda_powertools.utilities.typing import LambdaContext
tracer = Tracer()
logger = Logger()
app = ALBResolver()
@app.get("/todos")
@tracer.capture_method
def get_todos():
todos: Response = requests.get("https://jsonplaceholder.typicode.com/todos")
todos.raise_for_status()
# for brevity, we'll limit to the first 10 only
return {"todos": todos.json()[:10]}
# You can continue to use other utilities just as before
@logger.inject_lambda_context(correlation_id_path=correlation_paths.APPLICATION_LOAD_BALANCER)
@tracer.capture_lambda_handler
def lambda_handler(event: dict, context: LambdaContext) -> dict:
return app.resolve(event, context)
```
# Richiamo di una funzione Lambda su una pianificazione
[Pianificatore Amazon EventBridge](https://docs.aws.amazon.com/scheduler/latest/UserGuide/what-is-scheduler.html) è un pianificatore serverless che consente di creare, eseguire e gestire attività da un unico servizio gestito centralizzato. Con il Pianificatore EventBridge puoi creare pianificazioni utilizzando le espressioni cron e rate per schemi ricorrenti o configurare invocazioni una tantum. Puoi configurare finestre temporali flessibili per la consegna, definire limiti per nuovi tentativi e impostare il tempo massimo di conservazione per eventi non elaborati.
Quando configuri il pianificatore EventBridge con Lambda, questo richiama la funzione Lambda in modo asincrono. Questa pagina descrive l'utilizzo del Pianificatore EventBridge per richiamare una funzione Lambda su una pianificazione.
## Configurare il ruolo di esecuzione
Quando crei una nuova pianificazione, il PIanificatore EventBridge deve disporre dell'autorizzazione per richiamare automaticamente l'operazione dell'API di destinazione. Concedi queste autorizzazioni al Pianificatore EventBridge utilizzando un *ruolo di esecuzione*. La policy di autorizzazione collegata al ruolo di esecuzione della pianificazione definisce le autorizzazioni necessarie. Tali autorizzazioni dipendono dall'API di destinazione che deve essere richiamata dal Pianificatore EventBridge.
Quando utilizzi la console del Pianificatore EventBridge per creare una pianificazione, come nella procedura seguente, il Pianificatore EventBridge configura automaticamente un ruolo di esecuzione in base alla destinazione selezionata. Per creare una pianificazione utilizzando uno degli SDK del Pianificatore EventBridge, AWS CLI o CloudFormation, devi disporre di un ruolo di esecuzione esistente che conceda le autorizzazioni richieste dal Pianificatore EventBridge per richiamare una destinazione. Per ulteriori informazioni sull'impostazione manuale di un ruolo di esecuzione per la pianificazione, consulta [Configurazione di un ruolo di esecuzione](https://docs.aws.amazon.com/scheduler/latest/UserGuide/setting-up.html#setting-up-execution-role) nella *Guida per l'utente di Pianificatore EventBridge*.
## Creare una pianificazione.
**Per creare una pianificazione utilizzando la console**
1. Apri la console del Pianificatore Amazon EventBridge all'indirizzo [https://console.aws.amazon.com/scheduler/home](https://console.aws.amazon.com/scheduler/home/).
1. Nella pagina **Pianificazioni**, scegli **Crea pianificazione**.
1. Nella pagina **Specifica i dettagli della pianificazione**, nella sezione **Nome e descrizione della pianificazione**, effettua le seguenti operazioni:
1. Per **Nome pianificazione**, inserisci un nome per la pianificazione. Ad esempio, **MyTestSchedule**.
1. (Facoltativo) Per **Descrizione**, inserisci una descrizione per la pianificazione. Ad esempio, **My first schedule**.
1. Per **Gruppo di pianificazioni**, scegli un gruppo di pianificazioni dall'elenco a discesa. Se non hai un gruppo, scegli **predefinito**. Per creare un gruppo di pianificazioni, scegli **crea la tua pianificazione**.
I gruppi di pianificazione vengono utilizzati per aggiungere tag a gruppi di pianificazioni.
1.
1. Scegli le opzioni di pianificazione.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/with-eventbridge-scheduler.html)
1. (Facoltativo) Se hai scelto **Pianificazione ricorrente** nel passaggio precedente, nella sezione **Intervallo di tempo** effettua le seguenti operazioni:
1. Per **Fuso orario**, scegli un fuso orario.
1. Per **Data e ora di inizio**, inserisci una data valida in formato `YYYY/MM/DD`, quindi specifica un timestamp in formato `hh:mm` 24 ore.
1. Per **Data e ora di fine**, inserisci una data valida in formato `YYYY/MM/DD`, quindi specifica un timestamp in formato `hh:mm` 24 ore.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Seleziona destinazione**, scegli l'operazione dell'API AWS richiamata dal Pianificatore EventBridge:
1. Scegli **Richiama AWS Lambda**.
1. Nella sezione **Richiama**, seleziona una funzione o scegli **Crea una nuova funzione Lambda**.
1. (Facoltativo) Inserisci un payload JSON. Se non inserisci un payload, il Pianificatore EventBridge utilizza un evento vuoto per richiamare la funzione.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Settings (Impostazioni)**, eseguire le operazioni descritte di seguito.
1. Per attivare la pianificazione, in **Stato della pianificazione**, attiva **Abilita pianificazione**.
1. Per configurare una policy di ripetizione per la tua pianificazione, in **Policy di ripetizione e coda DLQ (Dead-Letter Queue)** effettua le seguenti operazioni:
+ Attiva/disattiva **Riprova**.
+ Per **Età massima dell'evento**, inserisci il numero massimo di **ore** e **minuti** per cui il Pianificatore EventBridge deve conservare un evento non elaborato.
+ La durata massima è 24 ore.
+ Per **Numero massimo di tentativi**, inserisci il numero massimo di volte che il Pianificatore EventBridge ritenta la pianificazione se la destinazione restituisce un errore.
Il valore massimo è 185 tentativi.
Con le policy per nuovi tentativi, se una pianificazione non riesce a richiamare la sua destinazione, il Pianificatore EventBridge esegue nuovamente la pianificazione. Se configurato, è necessario impostare il tempo di conservazione massimo e i nuovi tentativi per la pianificazione.
1. Scegli la posizione in cui il Pianificatore EventBridge deve archiviare gli eventi non consegnati.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/with-eventbridge-scheduler.html)
1. Per utilizzare una chiave gestita dal cliente per crittografare l'input di destinazione, in **Crittografia** scegli **Personalizza le impostazioni di crittografia (avanzate)**.
Se scegli questa opzione, inserisci l'ARN di una chiave KMS esistente scegli **Crea una AWS KMS key** per accedere alla console AWS KMS. Per ulteriori informazioni sulla modalità con cui il Pianificatore EventBridge esegue la crittografia dei dati inattivi, consulta [Crittografia a riposo](https://docs.aws.amazon.com/scheduler/latest/UserGuide/encryption-rest.html) nella *Guida per l'utente di Pianificatore Amazon EventBridge*.
1. Affinché il Pianificatore EventBridge crei automaticamente un nuovo ruolo di esecuzione, scegli **Crea nuovo ruolo per questa pianificazione**. Inserisci, quindi, un nome per **Nome ruolo**. Se scegli questa opzione, il Pianificatore EventBridge collega al ruolo le autorizzazioni necessarie per la destinazione basata sul modello.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Rivedi e crea pianificazione**, rivedi i dettagli della pianificazione. In ogni sezione, scegli **Modifica** per tornare a tale passaggio e modificarne i dettagli.
1. Scegli **Crea pianificazione**.
Puoi visualizzare un elenco delle pianificazioni nuove ed esistenti nella pagina **Pianificazioni**. Nella colonna **Stato**, accertati che la nuova pianificazione sia **Abilitata**.
Per accertarti che il Pianificatore EventBridge abbia richiamato la funzione, [controlla i Amazon CloudWatch Logs della funzione](monitoring-cloudwatchlogs-view.md#monitoring-cloudwatchlogs-console).
## Risorse correlate
Per ulteriori informazioni sul Pianificatore EventBridge, consulta:
+ [Guida per l'utente di Pianificatore EventBridge](https://docs.aws.amazon.com/scheduler/latest/UserGuide/what-is-scheduler.html)
+ [Riferimento all'API del Pianificatore EventBridge](https://docs.aws.amazon.com/scheduler/latest/APIReference/Welcome.html)
+ [Prezzi del Pianificatore EventBridge](https://aws.amazon.com/eventbridge/pricing/#Scheduler)
# Uso di AWS Lambda con AWS IoT
AWS IoT fornisce una comunicazione sicura tra i dispositivi connessi a Internet (come i sensori) e AWS Cloud. Questo consente raccogliere, archiviare e analizzare i dati di telemetria da più dispositivi.
È possibile creare regole AWS IoT affinché i dispositivi interagiscano con i Servizi AWS. AWS IoT [Rules Engine](https://docs.aws.amazon.com/iot/latest/developerguide/iot-rules.html) fornisce un linguaggio basato su SQL, per selezionare i dati dai payload dei messaggi e inviare i dati ad altri servizi, ad esempio Amazon S3, Amazon DynamoDB e AWS Lambda. Si definisce una regola per richiamare una funzione Lambda quando si desidera richiamare un altro servizio AWS o un servizio di terze parti.
Quando un messaggio IoT in ingresso attiva la regola, AWS IoTrichiama la funzione Lambda in modo [asincrono](invocation-async.md) e passa i dati dal messaggio IoT alla funzione.
L'esempio seguente mostra una lettura dell'umidità da un sensore serra. I valori di **riga** e **pos** identificano la posizione del sensore. Questo evento di esempio si basa sul tipo serra in [Tutorial sulle regole AWS IoT](https://docs.aws.amazon.com/iot/latest/developerguide/iot-rules-tutorial.html).
**Example AWS IoTEvento messaggio di**
```
{
"row" : "10",
"pos" : "23",
"moisture" : "75"
}
```
Per le chiamate asincrone, Lambda inserisce in una coda i messaggi e i [tentativi](invocation-retries.md) se la funzione restituisce un errore. Configura la tua funzione con una [destination](invocation-async-retain-records.md#invocation-async-destinations) per mantenere gli eventi che la tua funzione non è in grado di elaborare.
È necessario concedere l'autorizzazione al servizio AWS IoT per richiamare la funzione Lambda. Utilizza il comando `add-permission` per aggiungere un'istruzione di autorizzazione alla policy basata sulle risorse della funzione.
```
aws lambda add-permission --function-name my-function \
--statement-id iot-events --action "lambda:InvokeFunction" --principal iot.amazonaws.com
```
Verrà visualizzato l'output seguente:
```
{
"Statement": "{\"Sid\":\"iot-events\",\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"iot.amazonaws.com\"},\"Action\":\"lambda:InvokeFunction\",\"Resource\":\"arn:aws:lambda:us-east-1:123456789012:function:my-function\"}"
}
```
Per ulteriori informazioni su come utilizzare Lambda con AWS IoT, consulta [Creazione di una regola AWS Lambda](https://docs.aws.amazon.com/iot/latest/developerguide/iot-lambda-rule.html).
# Scopri come Lambda elabora i record di Flusso di dati Amazon Kinesis.
È possibile usare una funzione Lambda per elaborare i record in un [flusso di dati Amazon Kinesis](https://docs.aws.amazon.com/streams/latest/dev/introduction.html). È possibile mappare una funzione Lambda a un consumer a throughput condiviso (iteratore standard) del flusso di dati Kinesis o a un consumer di throughput dedicato con [fan-out avanzato](https://docs.aws.amazon.com/kinesis/latest/dev/enhanced-consumers.html). Per gli iteratori standard, Lambda interroga ogni shard nel flusso Kinesis alla ricerca di record utilizzando il protocollo HTTP. La mappatura dell'origine eventi condivide il throughput di lettura con altri utenti dello shard.
Per informazioni dettagliate sui flussi di dati Kinesis, consulta [Lettura dei dati da Flusso di dati Amazon Kinesis](https://docs.aws.amazon.com/kinesis/latest/dev/building-consumers.html).
**Nota**
Kinesis addebita dei costi per ogni shard, per il fan-out avanzato e per i dati letti dal flusso. Per i dettagli sui prezzi, consulta [Prezzi di Amazon Kinesis](https://aws.amazon.com/kinesis/data-streams/pricing).
## Flussi di polling e batching
Lambda legge i record dal flusso di dati e richiama la funzione [in modo sincrono](invocation-sync.md) con un evento che contiene record di flusso. Lambda legge i record in batch e richiama la funzione per elaborare i record dal batch. Ogni batch contiene registri da una singolo shard/flusso dei dati.
La funzione Lambda è un'applicazione consumer per il flusso di dati. Elabora un batch di record alla volta da ciascuno shard. È possibile mappare una funzione Lambda a un consumer a throughput condiviso (iteratore standard) o a un consumer di throughput dedicato con fan-out avanzato.
+ **Iteratori standard:** Lambda esegue il polling per ogni shard nel flusso Kinesis per i record a una velocità di base di una volta al secondo. Quando sono disponibili più record, Lambda continua l'elaborazione dei batch fino a quando la funzione raggiunge il flusso. La mappatura dell'origine eventi condivide il throughput di lettura con altri utenti dello shard.
+ **Fan-out avanzato:** per ridurre al minimo la latenza e massimizzare il throughput di lettura, è necessario creare un consumer del flusso di dati con [fan-out avanzato](https://docs.aws.amazon.com/streams/latest/dev/enhanced-consumers.html). I consumatori del fan-out avanzato ottengono una connessione dedicata a ciascuno shard che non ha conseguenze su altre applicazioni che leggono dal flusso. I consumatori del flusso utilizzano HTTP/2 per ridurre la latenza spingendo record da Lambda a long-lived su una connessione di lunga durata e comprimendo le intestazioni della richiesta. È possibile creare un consumatore di flusso con l'API [RegisterStreamConsumer](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_RegisterStreamConsumer.html) Kinesis.
```
aws kinesis register-stream-consumer \
--consumer-name con1 \
--stream-arn arn:aws:kinesis:us-east-2:123456789012:stream/lambda-stream
```
Verrà visualizzato l'output seguente:
```
{
"Consumer": {
"ConsumerName": "con1",
"ConsumerARN": "arn:aws:kinesis:us-east-2:123456789012:stream/lambda-stream/consumer/con1:1540591608",
"ConsumerStatus": "CREATING",
"ConsumerCreationTimestamp": 1540591608.0
}
}
```
Per aumentare la velocità con cui la funzione elabora i record, [aggiungere gli shard al flusso di dati](https://repost.aws/knowledge-center/kinesis-data-streams-open-shards). Lambda elabora i record in ogni shard in ordine. Interrompe l'elaborazione di record aggiuntivi in uno shard se la funzione restituisce un errore. Con più partizioni, vengono elaborati più batch contemporaneamente e l'impatto di errori in simultanea viene ridotto.
Se la funzione non è in grado di aumentare le dimensioni fino a gestire il numero totale di batch simultanei, [richiedere un aumento della quota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) o [riservare la simultaneità](configuration-concurrency.md) per la funzione.
Per impostazione predefinita, Lambda richiama la funzione non appena i record sono disponibili. Se il batch che Lambda legge dall'origine eventi contiene un solo record, Lambda invia solo un record alla funzione. Per evitare di richiamare la funzione con pochi record è possibile, configurando un *periodo di batch*, chiedere all'origine eventi di memorizzare nel buffer i registri per un massimo di 5 minuti. Prima di richiamare la funzione, Lambda continua a leggere i registri dall'origine eventi fino a quando non ha raccolto un batch completo, fino alla scadenza del periodo di batch o fino a quando il batch non ha raggiunto il limite del payload di 6 MB. Per ulteriori informazioni, consulta [Comportamento di batching](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching).
**avvertimento**
Gli strumenti di mappatura dell'origine degli eventi elaborano ogni evento almeno una volta e può verificarsi un'elaborazione duplicata dei record. Per evitare potenziali problemi legati agli eventi duplicati, ti consigliamo vivamente di rendere idempotente il codice della funzione. Per ulteriori informazioni, consulta [Come posso rendere idempotente la mia funzione Lambda](https://repost.aws/knowledge-center/lambda-function-idempotent) nel Knowledge Center AWS.
Lambda non attende il completamento di alcuna [estensione](lambda-extensions.md) prima di inviare il batch successivo per l'elaborazione. In altre parole, le estensioni possono continuare a funzionare mentre Lambda elabora il successivo batch di record. Ciò può causare problemi di limitazione in caso di violazione delle impostazioni o dei limiti di [simultaneità](lambda-concurrency.md). Per rilevare se si tratta di un potenziale problema, monitora le tue funzioni e verifica se i [parametri di simultaneità](monitoring-concurrency.md#general-concurrency-metrics) per lo strumento di mappatura dell'origine degli eventi sono superiori al previsto. A causa degli intervalli ridotti tra le invocazioni, Lambda potrebbe segnalare brevemente un utilizzo della simultaneità maggiore rispetto al numero di partizioni. Ciò può essere vero anche per le funzioni Lambda senza estensioni.
Configura l'impostazione [ParallelizationFactor](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-ParallelizationFactor) per elaborare uno shard di un flusso di dati Kinesis con più invocazioni Lambda contemporaneamente. È possibile specificare il numero di batch simultanei di cui Lambda esegue il polling da uno shard da un fattore di parallelizzazione compreso tra da 1 (predefinito) e 10. Ad esempio, impostando `ParallelizationFactor` su 2, puoi disporre al massimo di 200 invocazioni Lambda simultanee per elaborare 100 partizioni di dati Kinesis (anche se nella pratica potresti vedere valori differenti per il parametro `ConcurrentExecutions`). Ciò permette di dimensionare verso l'alto il throughput di elaborazione quando il volume dei dati è volatile e l'`IteratorAge` è alta. Se si aumenta il numero di batch simultanei per shard, Lambda garantisce comunque l'ordine di elaborazione a livello di partizione-chiave.
Puoi anche utilizzare `ParallelizationFactor` con l'aggregazione Kinesis. Il comportamento dello strumento di mappatura dell'origine degli eventi dipende dall'utilizzo o meno di un [fan-out avanzato](https://docs.aws.amazon.com/streams/latest/dev/enhanced-consumers.html):
+ **Senza fan-out avanzato**: tutti gli eventi all'interno di un evento aggregato devono avere la stessa chiave di partizione. La chiave di partizione deve inoltre corrispondere a quella dell'evento aggregato. Se gli eventi all'interno dell'evento aggregato hanno chiavi di partizione diverse, Lambda non può garantire l'elaborazione ordinata degli eventi per chiave di partizione.
+ **Con fan-out migliorato**: innanzitutto, Lambda decodifica l'evento aggregato nei suoi singoli eventi. L'evento aggregato può avere una chiave di partizione diversa dagli eventi che contiene. Tuttavia, gli eventi che non corrispondono alla chiave di partizione vengono [eliminati e persi](https://github.com/awslabs/kinesis-aggregation/blob/master/potential_data_loss.md). Lambda non elabora questi eventi e non li invia a una destinazione di errore configurata.
## Esempio di evento
**Example**
```
{
"Records": [
{
"kinesis": {
"kinesisSchemaVersion": "1.0",
"partitionKey": "1",
"sequenceNumber": "49590338271490256608559692538361571095921575989136588898",
"data": "SGVsbG8sIHRoaXMgaXMgYSB0ZXN0Lg==",
"approximateArrivalTimestamp": 1545084650.987
},
"eventSource": "aws:kinesis",
"eventVersion": "1.0",
"eventID": "shardId-000000000006:49590338271490256608559692538361571095921575989136588898",
"eventName": "aws:kinesis:record",
"invokeIdentityArn": "arn:aws:iam::123456789012:role/lambda-role",
"awsRegion": "us-east-2",
"eventSourceARN": "arn:aws:kinesis:us-east-2:123456789012:stream/lambda-stream"
},
{
"kinesis": {
"kinesisSchemaVersion": "1.0",
"partitionKey": "1",
"sequenceNumber": "49590338271490256608559692540925702759324208523137515618",
"data": "VGhpcyBpcyBvbmx5IGEgdGVzdC4=",
"approximateArrivalTimestamp": 1545084711.166
},
"eventSource": "aws:kinesis",
"eventVersion": "1.0",
"eventID": "shardId-000000000006:49590338271490256608559692540925702759324208523137515618",
"eventName": "aws:kinesis:record",
"invokeIdentityArn": "arn:aws:iam::123456789012:role/lambda-role",
"awsRegion": "us-east-2",
"eventSourceARN": "arn:aws:kinesis:us-east-2:123456789012:stream/lambda-stream"
}
]
}
```
# Elaborare i record del flusso di dati Amazon Kinesis con Lambda
Per elaborare i record di Amazon Kinesis Data Streams con Lambda, crea una mappatura delle sorgenti degli eventi Lambda. È possibile mappare una funzione Lambda a un iteratore standard o a un consumatore fan-out avanzato. Per ulteriori informazioni, consulta [Flussi di polling e batching](with-kinesis.md#kinesis-polling-and-batching).
## Creare una mappatura delle sorgenti degli eventi Kinesis
Per richiamare la funzione Lambda con i record dal flusso di dati, crea uno [strumento di mappatura dell'origine degli eventi](invocation-eventsourcemapping.md). È possibile creare più mappature delle origini eventi per elaborare gli stessi dati con più funzioni Lambda o per elaborare elementi da più flussi di dati con una singola funzione. Quando si elaborano elementi da più flussi, ogni batch conterrà i record di un solo shard o di un solo flusso.
È possibile configurare gli strumenti di mappatura dell'origine degli eventi per elaborare i record da un flusso in un altro Account AWS. Per ulteriori informazioni, consulta [Creazione di uno strumento di mappatura dell'origine degli eventi multi-account](#services-kinesis-eventsourcemapping-cross-account).
Prima di creare uno strumento di mappatura dell'origine degli eventi, devi autorizzare la funzione Lambda a leggere da un flusso di dati Kinesis. Lambda richiede le seguenti autorizzazioni per gestire le risorse correlate al flusso di dati Kinesis:
+ [kinesis: DescribeStream](https://docs.aws.amazon.com/lambda/latest/api/API_DescribeStream.html)
+ [cinesi: DescribeStreamSummary](https://docs.aws.amazon.com/lambda/latest/api/API_DescribeStreamSummary.html)
+ [cinesi: GetRecords](https://docs.aws.amazon.com/lambda/latest/api/API_GetRecords.html)
+ [cinesi: GetShardIterator](https://docs.aws.amazon.com/lambda/latest/api/API_GetShardIterator.html)
+ [cinesi: ListShards](https://docs.aws.amazon.com/lambda/latest/api/API_ListShards.html)
+ [cinesi: SubscribeToShard](https://docs.aws.amazon.com/lambda/latest/api/API_SubscribeToShard.html)
La politica AWS gestita [AWSLambdaKinesisExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaKinesisExecutionRole.html)include queste autorizzazioni. Aggiungi questa policy gestita alla funzione come descritto nella seguente procedura.
**Nota**
Non è necessaria l'`kinesis:ListStreams`autorizzazione per creare e gestire le mappature delle sorgenti degli eventi per Kinesis. Tuttavia, se crei una mappatura dell'origine degli eventi nella console e non disponi di questa autorizzazione, non sarai in grado di selezionare uno stream Kinesis da un elenco a discesa e la console visualizzerà un errore. Per creare la mappatura delle sorgenti degli eventi, devi inserire manualmente l'Amazon Resource Name (ARN) del tuo stream.
Lambda effettua `kinesis:GetRecords` chiamate `kinesis:GetShardIterator` API ogni volta che tenta di ripetere le chiamate non riuscite.
------
#### [ Console di gestione AWS ]
**Per aggiungere le autorizzazioni Kinesis alla tua funzione**
1. Apri la [pagina Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda e scegli la tua funzione.
1. Nella scheda **Configurazione** scegli **Autorizzazioni**.
1. Nel riquadro **Ruolo di esecuzione**, ub **Nome del ruolo**, scegli il link al ruolo di esecuzione della tua funzione. Questo link apre la pagina del ruolo nella console IAM.
1. Nel riquadro **Policy di autorizzazioni**, seleziona **Aggiungi autorizzazioni**, quindi **Collega policy**.
1. Inserisci **AWSLambdaKinesisExecutionRole** nel campo di ricerca.
1. Seleziona la casella di controllo accanto al nome della policy, quindi scegli **Aggiungi autorizzazione**.
------
#### [ AWS CLI ]
**Per aggiungere le autorizzazioni Kinesis alla tua funzione**
+ Per aggiungere la policy `AWSLambdaKinesisExecutionRole` al ruolo di esecuzione della funzione, eseguire il comando della CLI sotto riportato:
```
aws iam attach-role-policy \
--role-name MyFunctionRole \
--policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaKinesisExecutionRole
```
------
#### [ AWS SAM ]
**Per aggiungere le autorizzazioni Kinesis alla tua funzione**
+ Nella definizione della funzione, aggiungi la proprietà `Policies` come mostrato nell'esempio seguente:
```
Resources:
MyFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: ./my-function/
Handler: index.handler
Runtime: nodejs24.x
Policies:
- AWSLambdaKinesisExecutionRole
```
------
Dopo aver configurato le autorizzazioni richieste, crea lo strumento di mappatura dell'origine degli eventi.
------
#### [ Console di gestione AWS ]
**Per creare uno strumento di mappatura dell'origine degli eventi Kinesis**
1. Apri la [pagina Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda e scegli la tua funzione.
1. Nel riquadro **Panoramica della funzione**, scegli **Aggiungi trigger**.
1. In **Configurazione del trigger**, per l'origine seleziona **Kinesis**.
1. Seleziona il flusso Kinesis per il quale desideri creare lo strumento di mappatura dell'origine degli eventi e, facoltativamente, un consumer del tuo flusso.
1. (Facoltativo) Modifica la **dimensione del batch**, la **posizione iniziale** e la **finestra batch** per lo strumento di mappatura dell'origine degli eventi.
1. Scegliere **Aggiungi**.
[Quando crei la mappatura delle sorgenti degli eventi dalla console, il tuo ruolo IAM deve disporre delle autorizzazioni kinesis: e [kinesis](https://docs.aws.amazon.com/lambda/latest/api/API_ListStreams.html):. ListStreams ListStreamConsumers](https://docs.aws.amazon.com/lambda/latest/api/API_ListStreamConsumers.html)
------
#### [ AWS CLI ]
**Per creare uno strumento di mappatura dell'origine degli eventi Kinesis**
+ Per creare uno strumento di mappatura dell'origine degli eventi Kinesis, eseguire il comando della CLI sotto riportato. Scegli la dimensione del batch e la posizione iniziale in base al tuo caso d'uso.
```
aws lambda create-event-source-mapping \
--function-name MyFunction \
--event-source-arn arn:aws:kinesis:us-east-2:123456789012:stream/lambda-stream \
--starting-position LATEST \
--batch-size 100
```
Per specificare una finestra di batch, aggiungi l'opzione `--maximum-batching-window-in-seconds`. *Per ulteriori informazioni sull'utilizzo di questo e di altri parametri, consulta [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html)la sezione Command Reference.AWS CLI *
------
#### [ AWS SAM ]
**Per creare uno strumento di mappatura dell'origine degli eventi Kinesis**
+ Nella definizione della funzione, aggiungi la proprietà `KinesisEvent` come mostrato nell'esempio seguente:
```
Resources:
MyFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: ./my-function/
Handler: index.handler
Runtime: nodejs24.x
Policies:
- AWSLambdaKinesisExecutionRole
Events:
KinesisEvent:
Type: Kinesis
Properties:
Stream: !GetAtt MyKinesisStream.Arn
StartingPosition: LATEST
BatchSize: 100
MyKinesisStream:
Type: AWS::Kinesis::Stream
Properties:
ShardCount: 1
```
*Per ulteriori informazioni sulla creazione di una mappatura delle sorgenti di eventi per Kinesis Data Streams in AWS SAM, consulta [Kinesis nella Developer Guide](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-property-function-kinesis.html).AWS Serverless Application Model *
------
## Posizioni di partenza di polling e flussi
Tieni presente che il polling dei flussi durante la creazione e gli aggiornamenti dello strumento di mappatura dell'origine degli eventi alla fine è coerente.
+ Durante la creazione dello strumento di mappatura dell'origine degli eventi, potrebbero essere necessari alcuni minuti per l'avvio degli eventi di polling dal flusso.
+ Durante gli aggiornamenti dello strumento di mappatura dell'origine degli eventi, potrebbero essere necessari alcuni minuti per l'avvio degli eventi di polling dal flusso.
Questo comportamento implica che se specifichi `LATEST` come posizione iniziale del flusso, lo strumento di mappatura dell'origine degli eventi potrebbe perdere eventi durante la creazione o gli aggiornamenti. Per non perdere alcun evento, specifica la posizione iniziale del flusso come `TRIM_HORIZON` o `AT_TIMESTAMP`.
## Creazione di uno strumento di mappatura dell'origine degli eventi multi-account
Flusso di dati Amazon Kinesis supporta le [policy basate sulle risorse](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html). Per questo motivo, puoi elaborare i dati inseriti in un flusso in uno Account AWS con una funzione Lambda in un altro account.
Per creare una mappatura dell'origine degli eventi per la tua funzione Lambda utilizzando un flusso Kinesis in un Account AWS altro, devi configurare il flusso utilizzando una policy basata sulle risorse per autorizzare la funzione Lambda a leggere gli elementi. Per informazioni su come configurare lo stream per consentire l'accesso su più account, consulta [Condivisione dell'accesso con AWS Lambda funzioni su più account nella guida](https://docs.aws.amazon.com/streams/latest/dev/resource-based-policy-examples.html#Resource-based-policy-examples-lambda) per sviluppatori di *Amazon Kinesis Streams*.
Dopo aver configurato il flusso con una policy basata sulle risorse che fornisce alla funzione Lambda le autorizzazioni richieste, crea lo strumento di mappatura dell'origine degli eventi utilizzando uno dei metodi descritti nella sezione precedente.
Se scegli di creare lo strumento di mappatura dell'origine degli eventi utilizzando la console Lambda, incolla l'ARN del tuo flusso direttamente nel campo di input. Se desideri specificare un consumer per il tuo flusso, incollando l'ARN del consumer viene compilato automaticamente il campo del flusso.
# Configurazione della risposta batch parziale con il flusso di dati Kinesis e Lambda
Quando si consumano ed elaborano i dati di streaming da un'origine eventi, per impostazione predefinita i Lambda imposta i checkpoint al numero di sequenza più alto di un batch solo quando il batch è riuscito completamente. Lambda tratta tutti gli altri risultati come un fallimento completo e riprova a elaborare il batch fino al limite di tentativi. Per consentire i successi parziali durante l'elaborazione di batch da un flusso, attivare `ReportBatchItemFailures`. Consentire successi parziali può contribuire a ridurre il numero di tentativi su un record, anche se non impedisce del tutto la possibilità di tentativi in un record riuscito.
Per attivare `ReportBatchItemFailures`, includere il valore enum**ReportBatchItemFailures** nell'[FunctionResponseTypes](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-FunctionResponseTypes)elenco. Questo elenco indica quali tipi di risposta sono abilitati per la funzione. È possibile configurare questo elenco quando si [crea](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) o si [aggiorna](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html) uno strumento di mappatura dell'origine degli eventi.
**Nota**
Anche quando il codice della funzione restituisce risposte parziali di errore in batch, queste risposte non verranno elaborate da Lambda a meno che la `ReportBatchItemFailures` funzionalità non sia esplicitamente attivata per la mappatura dell'origine degli eventi.
## Sintassi di report
Quando si configura la creazione di report sugli errori degli elementi batch, la `StreamsEventResponse` classe viene restituita con un elenco di errori degli articoli batch. È possibile utilizzare un `StreamsEventResponse` oggetto per restituire il numero di sequenza del primo record non riuscito nel batch. È inoltre possibile creare la propria classe personalizzata utilizzando la sintassi di risposta corretta. La seguente struttura JSON mostra la sintassi di risposta richiesta:
```
{
"batchItemFailures": [
{
"itemIdentifier": ""
}
]
}
```
**Nota**
Se l'array `batchItemFailures` contiene più elementi, Lambda utilizza il record con il numero di sequenza più basso come checkpoint. Lambda quindi riprova tutti i record a partire da quel checkpoint.
## Condizioni di successo e di errore
Lambda considera un batch come un successo completo se si restituisce uno degli elementi seguenti:
+ Una `batchItemFailure` lista vuota
+ Un `batchItemFailure` elenco nullo
+ Un vuoto `EventResponse`
+ Un valore nullo `EventResponse`
Lambda considera un batch come un fallimento completo se si restituisce uno degli elementi seguenti:
+ Una stringa vuota `itemIdentifier`
+ Un valore nullo `itemIdentifier`
+ Un `itemIdentifier` con un nome chiave errato
Lambda esegue nuovi tentativi in seguito ai fallimenti secondo la strategia di tentativi impostata.
## Bisezione un batch
Se il richiamo fallisce ed `BisectBatchOnFunctionError` è attivato, il batch viene bisecato a prescindere dalle `ReportBatchItemFailures` impostazioni.
Quando si riceve una risposta di successo parziale del batch ed entrambi `BisectBatchOnFunctionError` e `ReportBatchItemFailures` sono attivati, il batch viene bisecato in corrispondenza del numero di sequenza restituito e Lambda ritenta solo i record rimanenti.
Per semplificare l'implementazione della logica di risposta batch parziale, prendi in considerazione l'utilizzo dell'[utilità Batch Processor](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/) di Powertools for AWS Lambda, che gestisce automaticamente queste complessità per te.
Ecco alcuni esempi di codice di funzione che restituiscono l'elenco dei messaggi non riusciti IDs nel batch:
------
#### [ .NET ]
**SDK per .NET**
C'è altro su GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda-with-batch-item-handling).
Segnalazione di errori di elementi batch di Kinesis con Lambda tramite .NET.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using System.Text;
using System.Text.Json.Serialization;
using Amazon.Lambda.Core;
using Amazon.Lambda.KinesisEvents;
using AWS.Lambda.Powertools.Logging;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace KinesisIntegration;
public class Function
{
// Powertools Logger requires an environment variables against your function
// POWERTOOLS_SERVICE_NAME
[Logging(LogEvent = true)]
public async Task FunctionHandler(KinesisEvent evnt, ILambdaContext context)
{
if (evnt.Records.Count == 0)
{
Logger.LogInformation("Empty Kinesis Event received");
return new StreamsEventResponse();
}
foreach (var record in evnt.Records)
{
try
{
Logger.LogInformation($"Processed Event with EventId: {record.EventId}");
string data = await GetRecordDataAsync(record.Kinesis, context);
Logger.LogInformation($"Data: {data}");
// TODO: Do interesting work based on the new data
}
catch (Exception ex)
{
Logger.LogError($"An error occurred {ex.Message}");
/* Since we are working with streams, we can return the failed item immediately.
Lambda will immediately begin to retry processing from this failed item onwards. */
return new StreamsEventResponse
{
BatchItemFailures = new List
{
new StreamsEventResponse.BatchItemFailure { ItemIdentifier = record.Kinesis.SequenceNumber }
}
};
}
}
Logger.LogInformation($"Successfully processed {evnt.Records.Count} records.");
return new StreamsEventResponse();
}
private async Task GetRecordDataAsync(KinesisEvent.Record record, ILambdaContext context)
{
byte[] bytes = record.Data.ToArray();
string data = Encoding.UTF8.GetString(bytes);
await Task.CompletedTask; //Placeholder for actual async work
return data;
}
}
public class StreamsEventResponse
{
[JsonPropertyName("batchItemFailures")]
public IList BatchItemFailures { get; set; }
public class BatchItemFailure
{
[JsonPropertyName("itemIdentifier")]
public string ItemIdentifier { get; set; }
}
}
```
------
#### [ Go ]
**SDK per Go V2**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda-with-batch-item-handling).
Segnalazione di errori di elementi batch di Kinesis con Lambda tramite Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package main
import (
"context"
"fmt"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func handler(ctx context.Context, kinesisEvent events.KinesisEvent) (map[string]interface{}, error) {
batchItemFailures := []map[string]interface{}{}
for _, record := range kinesisEvent.Records {
curRecordSequenceNumber := ""
// Process your record
if /* Your record processing condition here */ {
curRecordSequenceNumber = record.Kinesis.SequenceNumber
}
// Add a condition to check if the record processing failed
if curRecordSequenceNumber != "" {
batchItemFailures = append(batchItemFailures, map[string]interface{}{"itemIdentifier": curRecordSequenceNumber})
}
}
kinesisBatchResponse := map[string]interface{}{
"batchItemFailures": batchItemFailures,
}
return kinesisBatchResponse, nil
}
func main() {
lambda.Start(handler)
}
```
------
#### [ Java ]
**SDK per Java 2.x**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda-with-batch-item-handling).
Segnalazione di errori di elementi batch di Kinesis con Lambda tramite Java.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.KinesisEvent;
import com.amazonaws.services.lambda.runtime.events.StreamsEventResponse;
import java.io.Serializable;
import java.util.ArrayList;
import java.util.List;
public class ProcessKinesisRecords implements RequestHandler {
@Override
public StreamsEventResponse handleRequest(KinesisEvent input, Context context) {
List batchItemFailures = new ArrayList<>();
String curRecordSequenceNumber = "";
for (KinesisEvent.KinesisEventRecord kinesisEventRecord : input.getRecords()) {
try {
//Process your record
KinesisEvent.Record kinesisRecord = kinesisEventRecord.getKinesis();
curRecordSequenceNumber = kinesisRecord.getSequenceNumber();
} catch (Exception e) {
/* Since we are working with streams, we can return the failed item immediately.
Lambda will immediately begin to retry processing from this failed item onwards. */
batchItemFailures.add(new StreamsEventResponse.BatchItemFailure(curRecordSequenceNumber));
return new StreamsEventResponse(batchItemFailures);
}
}
return new StreamsEventResponse(batchItemFailures);
}
}
```
------
#### [ JavaScript ]
**SDK per JavaScript (v3)**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/blob/main/integration-kinesis-to-lambda-with-batch-item-handling).
Segnalazione di errori di elementi batch di Kinesis con Lambda tramite Javascript.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
exports.handler = async (event, context) => {
for (const record of event.Records) {
try {
console.log(`Processed Kinesis Event - EventID: ${record.eventID}`);
const recordData = await getRecordDataAsync(record.kinesis);
console.log(`Record Data: ${recordData}`);
// TODO: Do interesting work based on the new data
} catch (err) {
console.error(`An error occurred ${err}`);
/* Since we are working with streams, we can return the failed item immediately.
Lambda will immediately begin to retry processing from this failed item onwards. */
return {
batchItemFailures: [{ itemIdentifier: record.kinesis.sequenceNumber }],
};
}
}
console.log(`Successfully processed ${event.Records.length} records.`);
return { batchItemFailures: [] };
};
async function getRecordDataAsync(payload) {
var data = Buffer.from(payload.data, "base64").toString("utf-8");
await Promise.resolve(1); //Placeholder for actual async work
return data;
}
```
Segnalazione degli errori degli elementi batch di Kinesis utilizzando Lambda. TypeScript
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import {
KinesisStreamEvent,
Context,
KinesisStreamHandler,
KinesisStreamRecordPayload,
KinesisStreamBatchResponse,
} from "aws-lambda";
import { Buffer } from "buffer";
import { Logger } from "@aws-lambda-powertools/logger";
const logger = new Logger({
logLevel: "INFO",
serviceName: "kinesis-stream-handler-sample",
});
export const functionHandler: KinesisStreamHandler = async (
event: KinesisStreamEvent,
context: Context
): Promise => {
for (const record of event.Records) {
try {
logger.info(`Processed Kinesis Event - EventID: ${record.eventID}`);
const recordData = await getRecordDataAsync(record.kinesis);
logger.info(`Record Data: ${recordData}`);
// TODO: Do interesting work based on the new data
} catch (err) {
logger.error(`An error occurred ${err}`);
/* Since we are working with streams, we can return the failed item immediately.
Lambda will immediately begin to retry processing from this failed item onwards. */
return {
batchItemFailures: [{ itemIdentifier: record.kinesis.sequenceNumber }],
};
}
}
logger.info(`Successfully processed ${event.Records.length} records.`);
return { batchItemFailures: [] };
};
async function getRecordDataAsync(
payload: KinesisStreamRecordPayload
): Promise {
var data = Buffer.from(payload.data, "base64").toString("utf-8");
await Promise.resolve(1); //Placeholder for actual async work
return data;
}
```
------
#### [ PHP ]
**SDK per PHP**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda-with-batch-item-handling).
Segnalazione di errori di elementi batch di Kinesis con Lambda tramite PHP.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
logger = $logger;
}
/**
* @throws JsonException
* @throws \Bref\Event\InvalidLambdaEvent
*/
public function handle(mixed $event, Context $context): array
{
$kinesisEvent = new KinesisEvent($event);
$this->logger->info("Processing records");
$records = $kinesisEvent->getRecords();
$failedRecords = [];
foreach ($records as $record) {
try {
$data = $record->getData();
$this->logger->info(json_encode($data));
// TODO: Do interesting work based on the new data
} catch (Exception $e) {
$this->logger->error($e->getMessage());
// failed processing the record
$failedRecords[] = $record->getSequenceNumber();
}
}
$totalRecords = count($records);
$this->logger->info("Successfully processed $totalRecords records");
// change format for the response
$failures = array_map(
fn(string $sequenceNumber) => ['itemIdentifier' => $sequenceNumber],
$failedRecords
);
return [
'batchItemFailures' => $failures
];
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**SDK per Python (Boto3)**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda-with-batch-item-handling).
Segnalazione di errori di elementi batch di Kinesis con Lambda tramite Python.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def handler(event, context):
records = event.get("Records")
curRecordSequenceNumber = ""
for record in records:
try:
# Process your record
curRecordSequenceNumber = record["kinesis"]["sequenceNumber"]
except Exception as e:
# Return failed record's sequence number
return {"batchItemFailures":[{"itemIdentifier": curRecordSequenceNumber}]}
return {"batchItemFailures":[]}
```
------
#### [ Ruby ]
**SDK per Ruby**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda-with-batch-item-handling).
Segnalazione di errori di elementi batch di Kinesis con Lambda tramite Ruby.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
require 'aws-sdk'
def lambda_handler(event:, context:)
batch_item_failures = []
event['Records'].each do |record|
begin
puts "Processed Kinesis Event - EventID: #{record['eventID']}"
record_data = get_record_data_async(record['kinesis'])
puts "Record Data: #{record_data}"
# TODO: Do interesting work based on the new data
rescue StandardError => err
puts "An error occurred #{err}"
# Since we are working with streams, we can return the failed item immediately.
# Lambda will immediately begin to retry processing from this failed item onwards.
return { batchItemFailures: [{ itemIdentifier: record['kinesis']['sequenceNumber'] }] }
end
end
puts "Successfully processed #{event['Records'].length} records."
{ batchItemFailures: batch_item_failures }
end
def get_record_data_async(payload)
data = Base64.decode64(payload['data']).force_encoding('utf-8')
# Placeholder for actual async work
sleep(1)
data
end
```
------
#### [ Rust ]
**SDK per Rust**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda-with-batch-item-handling).
Segnalazione di errori di elementi batch di Kinesis con Lambda tramite Rust.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
use aws_lambda_events::{
event::kinesis::KinesisEvent,
kinesis::KinesisEventRecord,
streams::{KinesisBatchItemFailure, KinesisEventResponse},
};
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
async fn function_handler(event: LambdaEvent) -> Result {
let mut response = KinesisEventResponse {
batch_item_failures: vec![],
};
if event.payload.records.is_empty() {
tracing::info!("No records found. Exiting.");
return Ok(response);
}
for record in &event.payload.records {
tracing::info!(
"EventId: {}",
record.event_id.as_deref().unwrap_or_default()
);
let record_processing_result = process_record(record);
if record_processing_result.is_err() {
response.batch_item_failures.push(KinesisBatchItemFailure {
item_identifier: record.kinesis.sequence_number.clone(),
});
/* Since we are working with streams, we can return the failed item immediately.
Lambda will immediately begin to retry processing from this failed item onwards. */
return Ok(response);
}
}
tracing::info!(
"Successfully processed {} records",
event.payload.records.len()
);
Ok(response)
}
fn process_record(record: &KinesisEventRecord) -> Result<(), Error> {
let record_data = std::str::from_utf8(record.kinesis.data.as_slice());
if let Some(err) = record_data.err() {
tracing::error!("Error: {}", err);
return Err(Error::from(err));
}
let record_data = record_data.unwrap_or_default();
// do something interesting with the data
tracing::info!("Data: {}", record_data);
Ok(())
}
#[tokio::main]
async fn main() -> Result<(), Error> {
tracing_subscriber::fmt()
.with_max_level(tracing::Level::INFO)
// disable printing the name of the module in every log line.
.with_target(false)
// disabling time is handy because CloudWatch will add the ingestion time.
.without_time()
.init();
run(service_fn(function_handler)).await
}
```
------
## Utilizzo di Powertools per il processore AWS Lambda batch
L'utilità per il processore batch di Powertools gestisce AWS Lambda automaticamente la logica di risposta parziale in batch, riducendo la complessità dell'implementazione della segnalazione degli errori dei batch. Ecco alcuni esempi di utilizzo del processore batch:
**Python**
Per esempi completi e istruzioni di configurazione, consultate la [documentazione del processore batch](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/).
Elaborazione dei AWS Lambda record di flusso Kinesis Data Streams con processore batch.
```
import json
from aws_lambda_powertools import Logger
from aws_lambda_powertools.utilities.batch import BatchProcessor, EventType, process_partial_response
from aws_lambda_powertools.utilities.data_classes import KinesisEvent
from aws_lambda_powertools.utilities.typing import LambdaContext
processor = BatchProcessor(event_type=EventType.KinesisDataStreams)
logger = Logger()
def record_handler(record):
logger.info(record)
# Your business logic here
# Raise an exception to mark this record as failed
def lambda_handler(event, context: LambdaContext):
return process_partial_response(
event=event,
record_handler=record_handler,
processor=processor,
context=context
)
```
**TypeScript**
Per esempi completi e istruzioni di configurazione, consulta la documentazione del [processore batch](https://docs.aws.amazon.com/powertools/typescript/latest/features/batch/).
Elaborazione dei AWS Lambda record di flusso Kinesis Data Streams con processore batch.
```
import { BatchProcessor, EventType, processPartialResponse } from '@aws-lambda-powertools/batch';
import { Logger } from '@aws-lambda-powertools/logger';
import type { KinesisEvent, Context } from 'aws-lambda';
const processor = new BatchProcessor(EventType.KinesisDataStreams);
const logger = new Logger();
const recordHandler = async (record: any): Promise => {
logger.info('Processing record', { record });
// Your business logic here
// Throw an error to mark this record as failed
};
export const handler = async (event: KinesisEvent, context: Context) => {
return processPartialResponse(event, recordHandler, processor, {
context,
});
};
```
**Java**
Per esempi completi e istruzioni di configurazione, consulta la documentazione del [processore batch](https://docs.powertools.aws.dev/lambda/java/latest/utilities/batch/).
Elaborazione dei AWS Lambda record di flusso Kinesis Data Streams con processore batch.
```
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.KinesisEvent;
import com.amazonaws.services.lambda.runtime.events.StreamsEventResponse;
import software.amazon.lambda.powertools.batch.BatchMessageHandlerBuilder;
import software.amazon.lambda.powertools.batch.handler.BatchMessageHandler;
public class KinesisStreamBatchHandler implements RequestHandler {
private final BatchMessageHandler handler;
public KinesisStreamBatchHandler() {
handler = new BatchMessageHandlerBuilder()
.withKinesisBatchHandler()
.buildWithRawMessageHandler(this::processMessage);
}
@Override
public StreamsEventResponse handleRequest(KinesisEvent kinesisEvent, Context context) {
return handler.processBatch(kinesisEvent, context);
}
private void processMessage(KinesisEvent.KinesisEventRecord kinesisEventRecord, Context context) {
// Process the stream record
}
}
```
**.NET**
Per esempi completi e istruzioni di configurazione, consulta la documentazione del [processore batch](https://docs.aws.amazon.com/powertools/dotnet/utilities/batch-processing/).
Elaborazione dei AWS Lambda record di flusso Kinesis Data Streams con processore batch.
```
using System;
using System.Threading;
using System.Threading.Tasks;
using Amazon.Lambda.Core;
using Amazon.Lambda.KinesisEvents;
using Amazon.Lambda.Serialization.SystemTextJson;
using AWS.Lambda.Powertools.BatchProcessing;
[assembly: LambdaSerializer(typeof(DefaultLambdaJsonSerializer))]
namespace HelloWorld;
public class OrderEvent
{
public string? OrderId { get; set; }
public string? CustomerId { get; set; }
public decimal Amount { get; set; }
public DateTime OrderDate { get; set; }
}
internal class TypedKinesisRecordHandler : ITypedRecordHandler
{
public async Task HandleAsync(OrderEvent orderEvent, CancellationToken cancellationToken)
{
if (string.IsNullOrEmpty(orderEvent.OrderId))
{
throw new ArgumentException("Order ID is required");
}
return await Task.FromResult(RecordHandlerResult.None);
}
}
public class Function
{
[BatchProcessor(TypedRecordHandler = typeof(TypedKinesisRecordHandler))]
public BatchItemFailuresResponse HandlerUsingTypedAttribute(KinesisEvent _)
{
return TypedKinesisStreamBatchProcessor.Result.BatchItemFailuresResponse;
}
}
```
# Conservare i record batch scartati per un'origine di eventi del flusso di dati Kinesis in Lambda
La gestione degli errori per gli strumenti di mappatura dell'origine degli eventi Kinesis dipende dal fatto che l'errore si verifichi prima che la funzione venga richiamata o durante la chiamata della funzione:
+ **Prima della chiamata:** se una mappatura dell'origine degli eventi Lambda non è in grado di richiamare la funzione a causa di limitazioni o altri problemi, riprova finché i record non scadono o superano l'età massima configurata nella mappatura dell'origine dell'evento (). [MaximumRecordAgeInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumRecordAgeInSeconds)
+ **Durante la chiamata:** se la funzione viene richiamata ma restituisce un errore, Lambda riprova fino alla scadenza dei record, al superamento dell'età massima () o al raggiungimento della quota di tentativi configurata ([MaximumRecordAgeInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumRecordAgeInSeconds)). [MaximumRetryAttempts](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumRetryAttempts) Per gli errori di funzione, puoi anche configurare, che divide un batch non riuscito in due batch più piccoli [BisectBatchOnFunctionError](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-response-BisectBatchOnFunctionError), isolando i record non validi ed evitando i timeout. La divisione dei batch non consuma la quota di tentativi.
Se le misure di gestione degli errori non riescono, Lambda elimina i record e continua l'elaborazione dei batch dal flusso. Con le impostazioni predefinite, ciò significa che un record errato può bloccare l'elaborazione sullo shard interessata per un massimo di una settimana. Per evitare questa situazione, configura la mappatura dell'origine eventi della funzione con un numero ragionevole di tentativi e un'età massima dei record che sia adatta al caso d'uso.
## Configurazione delle destinazioni per le chiamate non riuscite
Per mantenere i record delle chiamate non riuscite allo strumento di mappatura dell'origine degli eventi, aggiungi una destinazione allo strumento di mappatura dell'origine degli eventi della funzione. Ogni record inviato alla destinazione è un documento JSON contenente i metadati relativi alla chiamata non riuscita. Per le destinazioni Amazon S3, Lambda invia insieme ai metadati anche l'intero record di invocazione. Puoi configurare qualsiasi argomento Amazon SNS, coda Amazon SQS, bucket Amazon S3 o Kafka come destinazione.
Con le destinazioni Amazon S3, puoi utilizzare la funzionalità [Notifiche eventi Amazon S3](https://docs.aws.amazon.com/) per ricevere notifiche quando gli oggetti vengono caricati nel bucket S3 di destinazione. Puoi anche configurare Notifiche eventi S3 per richiamare un'altra funzione Lambda per eseguire l'elaborazione automatica su batch non riusciti.
Il tuo ruolo di esecuzione deve avere le autorizzazioni per la destinazione:
+ **[Per una destinazione SQS: sqs: SendMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)**
+ **[Per una destinazione SNS: sns:publish](https://docs.aws.amazon.com/sns/latest/api/API_Publish.html)**
+ **[Per una destinazione S3: s3: e [s3](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html): PutObject ListBucket](https://docs.aws.amazon.com/AmazonS3/latest/API/ListObjectsV2.html)**
+ **[Per una destinazione Kafka: kafka-cluster: WriteData](https://docs.aws.amazon.com/msk/latest/developerguide/kafka-actions.html)**
È possibile configurare un argomento di Kafka come destinazione in caso di errore per le mappature delle sorgenti degli eventi Kafka. Quando Lambda non è in grado di elaborare i record dopo estenuanti tentativi o quando i record superano l'età massima, Lambda invia i record non riusciti all'argomento Kafka specificato per un'elaborazione successiva. Fai riferimento a [Usare un argomento di Kafka come destinazione in caso di errore](kafka-on-failure-destination.md).
[Se hai abilitato la crittografia con la tua chiave KMS per una destinazione S3, anche il ruolo di esecuzione della funzione deve avere l'autorizzazione a chiamare kms:. GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) Se la chiave KMS e la destinazione del bucket S3 si trovano in un account diverso dalla funzione Lambda e dal ruolo di esecuzione, configura la chiave KMS in modo che consideri attendibile il ruolo di esecuzione da consentire. kms: GenerateDataKey
Per configurare una destinazione in caso di errore tramite la console, completa i seguenti passaggi:
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegliere una funzione.
1. In **Function overview (Panoramica delle funzioni)**, scegliere **Add destination (Aggiungi destinazione)**.
1. Per **Origine**, scegli **Chiamata allo strumento di mappatura dell'origine degli eventi**.
1. Per **Strumento di mappatura dell'origine degli eventi**, scegli un'origine dell'evento configurata per questa funzione.
1. Per **Condizione**, seleziona **In caso di errore**. Per le chiamate allo strumento di mappatura dell'origine degli eventi, questa è l'unica condizione accettata.
1. Per **Tipo di destinazione**, scegli il tipo di destinazione a cui Lambda deve inviare i record di chiamata.
1. Per **Destination (Destinazione)**, scegliere una risorsa.
1. Scegli **Save** (Salva).
Puoi anche configurare una destinazione in caso di errore utilizzando (). AWS Command Line Interface AWS CLI Ad esempio, il [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html)comando seguente aggiunge una mappatura dell'origine degli eventi con una destinazione SQS in caso di errore a: `MyFunction`
```
aws lambda create-event-source-mapping \
--function-name "MyFunction" \
--event-source-arn arn:aws:kinesis:us-east-2:123456789012:stream/lambda-stream \
--destination-config '{"OnFailure": {"Destination": "arn:aws:sqs:us-east-1:123456789012:dest-queue"}}'
```
Il [update-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-event-source-mapping.html)comando seguente aggiorna una mappatura dell'origine degli eventi per inviare i record di chiamata non riuscita a una destinazione SNS dopo due tentativi o se i record risalgono a più di un'ora.
```
aws lambda update-event-source-mapping \
--uuid f89f8514-cdd9-4602-9e1f-01a5b77d449b \
--maximum-retry-attempts 2 \
--maximum-record-age-in-seconds 3600 \
--destination-config '{"OnFailure": {"Destination": "arn:aws:sns:us-east-1:123456789012:dest-topic"}}'
```
Le impostazioni aggiornate sono applicate in modo asincrono e non sono riflesse nell'output fino al completamento del processo. Utilizza il comando [get-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/get-event-source-mapping.html) per visualizzare lo stato corrente.
Per rimuovere una destinazione, fornisci una stringa vuota come argomento del parametro `destination-config`:
```
aws lambda update-event-source-mapping \
--uuid f89f8514-cdd9-4602-9e1f-01a5b77d449b \
--destination-config '{"OnFailure": {"Destination": ""}}'
```
### Best practice di sicurezza per destinazioni Amazon S3
L'eliminazione di un bucket S3 configurato come destinazione senza rimuovere la destinazione dalla configurazione della funzione può creare un rischio per la sicurezza. Se un altro utente conosce il nome del bucket di destinazione, può ricreare il bucket nel proprio Account AWS. I record delle invocazioni non riuscite verranno inviati al relativo bucket, esponendo potenzialmente i dati della tua funzione.
**avvertimento**
Per garantire che i record di invocazione della tua funzione non possano essere inviati a un bucket S3 in un altro Account AWS, aggiungi una condizione al ruolo di esecuzione della funzione che limiti le autorizzazioni ai bucket del tuo account. `s3:PutObject`
Di seguito viene illustrato un esempio di policy IAM che limita le autorizzazioni `s3:PutObject` della funzione ai bucket presenti nell'account. Questa policy fornisce inoltre a Lambda l'autorizzazione `s3:ListBucket` necessaria per utilizzare un bucket S3 come destinazione.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "S3BucketResourceAccountWrite",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::*/*",
"arn:aws:s3:::*"
],
"Condition": {
"StringEquals": {
"s3:ResourceAccount": "111122223333"
}
}
}
]
}
```
Per aggiungere una politica di autorizzazioni al ruolo di esecuzione della tua funzione utilizzando Console di gestione AWS o AWS CLI, consulta le istruzioni nelle seguenti procedure:
------
#### [ Console ]
**Per aggiungere una policy di autorizzazioni al ruolo di esecuzione di una funzione (console)**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Seleziona la funzione Lambda di cui si desidera modificare il ruolo di esecuzione.
1. Nella scheda **Configurazione** scegli **Autorizzazioni**.
1. Nella scheda **Ruolo di esecuzione**, seleziona il **nome del ruolo** della funzione per aprire la pagina della console IAM del ruolo.
1. Aggiungi una policy di autorizzazioni di base al ruolo completando le seguenti operazioni:
1. Nel riquadro **Policy di autorizzazioni**, scegli **Aggiungi autorizzazioni**, poi **Crea policy in linea**.
1. Nell'**editor delle policy**, seleziona **JSON**.
1. Incolla la policy che desideri aggiungere nell'editor (sostituendo il codice JSON esistente), quindi scegli **Avanti**.
1. In **Dettagli della policy**, specifica un **nome per la policy**.
1. Scegli **Crea policy**.
------
#### [ AWS CLI ]
**Per aggiungere una policy di autorizzazioni al ruolo di esecuzione di una funzione (CLI)**
1. Crea un documento di policy JSON con le autorizzazioni richieste e salvalo in una directory locale.
1. Utilizza il comando della CLI `put-role-policy` di IAM per aggiungere le autorizzazioni per il ruolo di esecuzione di una funzione. Esegui il comando seguente dalla directory in cui hai salvato il documento di policy JSON e sostituisci il nome del ruolo, il nome della policy e il documento di policy con i tuoi valori.
```
aws iam put-role-policy \
--role-name my_lambda_role \
--policy-name LambdaS3DestinationPolicy \
--policy-document file://my_policy.json
```
------
### Record di invocazione Amazon SNS e Amazon SQS di esempio
L'esempio seguente mostra ciò che Lambda invia a un argomento SNS o una coda SQS di destinazione per una chiamata non riuscita all'origine dell'evento Kinesis. Poiché Lambda invia solo i metadati per questi tipi di destinazione, utilizza i campi `streamArn`, `shardId`, `startSequenceNumber` e `endSequenceNumber` per ottenere il record originale completo. Tutti i campi mostrati nella proprietà `KinesisBatchInfo` saranno sempre presenti.
```
{
"requestContext": {
"requestId": "c9b8fa9f-5a7f-xmpl-af9c-0c604cde93a5",
"functionArn": "arn:aws:lambda:us-east-2:123456789012:function:myfunction",
"condition": "RetryAttemptsExhausted",
"approximateInvokeCount": 1
},
"responseContext": {
"statusCode": 200,
"executedVersion": "$LATEST",
"functionError": "Unhandled"
},
"version": "1.0",
"timestamp": "2019-11-14T00:38:06.021Z",
"KinesisBatchInfo": {
"shardId": "shardId-000000000001",
"startSequenceNumber": "49601189658422359378836298521827638475320189012309704722",
"endSequenceNumber": "49601189658422359378836298522902373528957594348623495186",
"approximateArrivalOfFirstRecord": "2019-11-14T00:38:04.835Z",
"approximateArrivalOfLastRecord": "2019-11-14T00:38:05.580Z",
"batchSize": 500,
"streamArn": "arn:aws:kinesis:us-east-2:123456789012:stream/mystream"
}
}
```
È possibile utilizzare queste informazioni per recuperare i record interessati dal flusso per la risoluzione dei problemi. I record effettivi non sono inclusi, pertanto è necessario elaborare questo record e recuperarli dal flusso prima che scadano e vadano persi.
### Record di invocazione Amazon S3 di esempio
L'esempio seguente mostra ciò che Lambda invia a un bucket Amazon S3 per una chiamata non riuscita all'origine eventi Kinesis. Oltre a tutti i campi dell'esempio precedente per le destinazioni SQS e SNS, il campo `payload` contiene il record di chiamata originale come stringa JSON con escape.
```
{
"requestContext": {
"requestId": "c9b8fa9f-5a7f-xmpl-af9c-0c604cde93a5",
"functionArn": "arn:aws:lambda:us-east-2:123456789012:function:myfunction",
"condition": "RetryAttemptsExhausted",
"approximateInvokeCount": 1
},
"responseContext": {
"statusCode": 200,
"executedVersion": "$LATEST",
"functionError": "Unhandled"
},
"version": "1.0",
"timestamp": "2019-11-14T00:38:06.021Z",
"KinesisBatchInfo": {
"shardId": "shardId-000000000001",
"startSequenceNumber": "49601189658422359378836298521827638475320189012309704722",
"endSequenceNumber": "49601189658422359378836298522902373528957594348623495186",
"approximateArrivalOfFirstRecord": "2019-11-14T00:38:04.835Z",
"approximateArrivalOfLastRecord": "2019-11-14T00:38:05.580Z",
"batchSize": 500,
"streamArn": "arn:aws:kinesis:us-east-2:123456789012:stream/mystream"
},
"payload": "" // Only available in S3
}
```
L'oggetto S3 contenente il record di invocazione utilizza la seguente convenzione di denominazione:
```
aws/lambda///YYYY/MM/DD/YYYY-MM-DDTHH.MM.SS-
```
# Implementazione dell'elaborazione di Flusso di dati Kinesis stateful in Lambda
Le funzioni Lambda possono eseguire applicazioni di elaborazione di flussi continui. Un flusso rappresenta dati illimitati che scorrono continuamente attraverso l'applicazione. Per analizzare le informazioni da questo input di aggiornamento continuo, è possibile associare i record inclusi utilizzando una finestra definita in termini di tempo.
Le finestre a cascata sono finestre temporali distinte che si aprono e si chiudono a intervalli regolari. Per impostazione predefinita, le invocazioni Lambda sono senza stato: non è possibile utilizzarle per l'elaborazione dei dati tra più invocazioni continue senza un database esterno. Tuttavia, con la finestra a cascata, è possibile mantenere il proprio stato tra le invocazioni. Questo stato contiene il risultato aggregato dei messaggi precedentemente elaborati per la finestra corrente. Lo stato può essere un massimo di 1 MB per shard. Se supera quella dimensione, Lambda termina la finestra in anticipo.
Ogni record in un flusso appartiene a una finestra specifica. Lambda elaborerà ogni record almeno una volta, ma non garantisce che ogni record venga elaborato una sola volta. In rari casi, come nel caso della gestione degli errori, alcuni record potrebbero essere elaborati più di una volta. La prima volta i record vengono sempre elaborati in ordine. Se i record vengono elaborati più di una volta, possono essere elaborati fuori ordine.
## Aggregazione ed elaborazione
La funzione gestita dall'utente viene richiamata sia per l'aggregazione che per l'elaborazione dei risultati finali di tale aggregazione. Lambda aggrega tutti i record ricevuti nella finestra. È possibile ricevere questi record in più batch, ciascuno come richiamo separato. Ogni richiamo riceve uno stato. Pertanto, quando si utilizzano finestre a cascata, la risposta della funzione Lambda deve contenere una proprietà di `state`. Se la risposta non contiene una proprietà di `state`, Lambda la considera un'invocazione non riuscita. Per soddisfare questa condizione, la funzione può restituire un oggetto `TimeWindowEventResponse`, che presenta la seguente forma JSON:
**Example `TimeWindowEventResponse` valori**
```
{
"state": {
"1": 282,
"2": 715
},
"batchItemFailures": []
}
```
**Nota**
Per le funzioni Java, si consiglia di utilizzare una `Map` per rappresentare lo stato.
Alla fine della finestra, il flag `isFinalInvokeForWindow` è impostato `true` per indicare che questo è lo stato finale e che è pronto per l'elaborazione. Dopo l'elaborazione, la finestra viene completata e il richiamo finale viene completato e quindi lo stato viene eliminato.
Al termine della finestra, Lambda utilizza l'elaborazione finale per le operazioni sui risultati dell'aggregazione. L'elaborazione finale viene richiamata in modo sincrono. Dopo il richiamo riuscito, la funzione controlla il numero di sequenza e l'elaborazione del flusso continua. Se il richiamo non ha esito positivo, la funzione Lambda sospende l'ulteriore elaborazione fino a quando non viene eseguito correttamente il richiamo.
**Example KinesisTimeWindowEvent**
```
{
"Records": [
{
"kinesis": {
"kinesisSchemaVersion": "1.0",
"partitionKey": "1",
"sequenceNumber": "49590338271490256608559692538361571095921575989136588898",
"data": "SGVsbG8sIHRoaXMgaXMgYSB0ZXN0Lg==",
"approximateArrivalTimestamp": 1607497475.000
},
"eventSource": "aws:kinesis",
"eventVersion": "1.0",
"eventID": "shardId-000000000006:49590338271490256608559692538361571095921575989136588898",
"eventName": "aws:kinesis:record",
"invokeIdentityArn": "arn:aws:iam::123456789012:role/lambda-kinesis-role",
"awsRegion": "us-east-1",
"eventSourceARN": "arn:aws:kinesis:us-east-1:123456789012:stream/lambda-stream"
}
],
"window": {
"start": "2020-12-09T07:04:00Z",
"end": "2020-12-09T07:06:00Z"
},
"state": {
"1": 282,
"2": 715
},
"shardId": "shardId-000000000006",
"eventSourceARN": "arn:aws:kinesis:us-east-1:123456789012:stream/lambda-stream",
"isFinalInvokeForWindow": false,
"isWindowTerminatedEarly": false
}
```
## Configurazione
È possibile configurare le finestre a cascata quando si crea o si aggiorna un mapping di origini di eventi. Per configurare una finestra rotante, specificate la finestra in secondi ([TumblingWindowInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-TumblingWindowInSeconds)). Il seguente comando di esempio AWS Command Line Interface (AWS CLI) crea una mappatura della sorgente degli eventi in streaming con una finestra di tumbling di 120 secondi. La funzione Lambda definita per l'aggregazione e l'elaborazione è denominata `tumbling-window-example-function`.
```
aws lambda create-event-source-mapping \
--event-source-arn arn:aws:kinesis:us-east-1:123456789012:stream/lambda-stream \
--function-name tumbling-window-example-function \
--starting-position TRIM_HORIZON \
--tumbling-window-in-seconds 120
```
Lambda determina i limiti delle finestre a cascata in base al momento in cui i record sono stati inseriti nel flusso. Tutti i record dispongono di un timestamp approssimativo che Lambda utilizza nelle determinazioni dei limiti.
Le aggregazioni delle finestre a cascata non supportano il risharding. Quando lo shard viene terminato, Lambda considera la finestra chiusa e gli shard secondari iniziano la propria finestra in uno stato nuovo. Quando non vengono aggiunti nuovi record alla finestra corrente, Lambda attende fino a due minuti prima di presumere che la finestra sia terminata. Ciò aiuta a garantire che la funzione legga tutti i record nella finestra corrente, anche se i record vengono aggiunti a intermittenza.
Le finestre a cascata supportano completamente le policy di ripetizione dei tentativi esistenti `maxRetryAttempts` e `maxRecordAge`.
**Example Handler.py: aggregazione ed elaborazione**
La seguente funzione Python mostra come aggregare e quindi elaborare lo stato finale:
```
def lambda_handler(event, context):
print('Incoming event: ', event)
print('Incoming state: ', event['state'])
#Check if this is the end of the window to either aggregate or process.
if event['isFinalInvokeForWindow']:
# logic to handle final state of the window
print('Destination invoke')
else:
print('Aggregate invoke')
#Check for early terminations
if event['isWindowTerminatedEarly']:
print('Window terminated early')
#Aggregation logic
state = event['state']
for record in event['Records']:
state[record['kinesis']['partitionKey']] = state.get(record['kinesis']['partitionKey'], 0) + 1
print('Returning state: ', state)
return {'state': state}
```
# Parametri Lambda per gli strumenti di mappatura dell'origine degli eventi di un flusso di dati Amazon Kinesis
Tutti gli strumenti di mappatura dell'origine degli eventi Lambda condividono le stesse operazioni API [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) e [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html). Tuttavia, solo alcuni dei parametri si applicano a Kinesis.
| Parametro | Obbligatorio | Predefinito | Note |
| --- | --- | --- | --- |
| [BatchSize](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-BatchSize) | N | 100 | Massimo: 10.000. |
| [BisectBatchOnFunctionError](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-BisectBatchOnFunctionError) | N | false | nessuno |
| [DestinationConfig](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-DestinationConfig) | N | N/D | Una destinazione coda Amazon SQS o argomento Amazon SNS per i record scartati. Per ulteriori informazioni, consulta [Configurazione delle destinazioni per le chiamate non riuscite](kinesis-on-failure-destination.md#kinesis-on-failure-destination-console). |
| [Abilitazione di](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-Enabled) | N | true | nessuno |
| [EventSourceArn](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-EventSourceArn) | Y | N/D | L'ARN del flusso dei dati o di un consumer di flusso. |
| [FunctionName](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-FunctionName) | Y | N/D | nessuno |
| [FunctionResponseTypes](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-FunctionResponseTypes) | N | N/D | Per consentire alla funzione di segnalare errori specifici in un batch, includi il valore `ReportBatchItemFailures` in `FunctionResponseTypes`. Per ulteriori informazioni, consulta [Configurazione della risposta batch parziale con il flusso di dati Kinesis e Lambda](services-kinesis-batchfailurereporting.md). |
| [MaximumBatchingWindowInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumBatchingWindowInSeconds) | N | 0 | nessuno |
| [MaximumRecordAgeInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumRecordAgeInSeconds) | N | -1 | -1 sta per infinito: Lambda non scarta i record (le [impostazioni di conservazione dei dati del flusso di dati Kinesis](https://docs.aws.amazon.com/streams/latest/dev/kinesis-extended-retention.html) sono ancora valide) Minimo: -1 Massimo: 604.800 |
| [MaximumRetryAttempts](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumRetryAttempts) | N | -1 | -1 sta per infinito: i record non riusciti vengono ripetuti fino alla scadenza del record Minimo: -1 Massimo: 10.000. |
| [ParallelizationFactor](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-ParallelizationFactor) | N | 1 | Maximum: 10 |
| [StartingPosition](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-StartingPosition) | Y | N/D | AT\$1TIMESTAMP, TRIM\$1HORIZON o LATEST |
| [StartingPositionTimestamp](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-StartingPositionTimestamp) | N | N/D | Valido solo se StartingPosition è impostato su AT\$1TIMESTAMP. Il tempo da cui avviare la lettura, in secondi di tempo Unix. |
| [TumblingWindowInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-TumblingWindowInSeconds) | N | N/D | Minimo: 0 Massimo: 900 |
# Utilizzo del filtro eventi con un'origine eventi Kinesis
Puoi utilizzare il filtraggio degli eventi per controllare quali record di un flusso o di una coda Lambda invia alla funzione. Per informazioni generali sul funzionamento del filtraggio eventi, consulta [Controllare gli eventi che Lambda invia alla funzione](invocation-eventfiltering.md).
In questa sezione viene descritto il filtraggio degli eventi per le origini eventi Kinesis.
**Nota**
Le mappature delle sorgenti degli eventi Kinesis supportano solo il filtraggio sulla chiave. `data`
**Topics**
+ [
## Nozioni di base sul filtro di eventi Kinesis
](#filtering-kinesis)
+ [
## Filtraggio dei record aggregati Kinesis
](#filtering-kinesis-efo)
## Nozioni di base sul filtro di eventi Kinesis
Supponiamo che un produttore stia inserendo dati in formato JSON nel flusso di dati Kinesis. Un record di esempio sarebbe simile al seguente, con i dati JSON convertiti in una stringa codificata Base64 nel campo `data`.
```
{
"kinesis": {
"kinesisSchemaVersion": "1.0",
"partitionKey": "1",
"sequenceNumber": "49590338271490256608559692538361571095921575989136588898",
"data": "eyJSZWNvcmROdW1iZXIiOiAiMDAwMSIsICJUaW1lU3RhbXAiOiAieXl5eS1tbS1kZFRoaDptbTpzcyIsICJSZXF1ZXN0Q29kZSI6ICJBQUFBIn0=",
"approximateArrivalTimestamp": 1545084650.987
},
"eventSource": "aws:kinesis",
"eventVersion": "1.0",
"eventID": "shardId-000000000006:49590338271490256608559692538361571095921575989136588898",
"eventName": "aws:kinesis:record",
"invokeIdentityArn": "arn:aws:iam::123456789012:role/lambda-role",
"awsRegion": "us-east-2",
"eventSourceARN": "arn:aws:kinesis:us-east-2:123456789012:stream/lambda-stream"
}
```
Fintantoché i dati che il produttore inserisce nel flusso sono JSON validi, puoi utilizzare il filtraggio degli eventi per filtrare i record utilizzando la chiave `data`. Supponiamo che un produttore stia inserendo dati in formato JSON nel flusso di dati Kinesis.
```
{
"record": 12345,
"order": {
"type": "buy",
"stock": "ANYCO",
"quantity": 1000
}
}
```
Per filtrare solo i record in cui il tipo di ordine è "acquista", l'oggetto `FilterCriteria` dovrebbe avere la struttura seguente.
```
{
"Filters": [
{
"Pattern": "{ \"data\" : { \"order\" : { \"type\" : [ \"buy\" ] } } }"
}
]
}
```
Per una maggiore chiarezza, ecco il valore del `Pattern` del filtro espanso in JSON semplice.
```
{
"data": {
"order": {
"type": [ "buy" ]
}
}
}
```
Puoi aggiungere il filtro utilizzando la console, la AWS CLI o un modello AWS SAM.
------
#### [ Console ]
Per aggiungere questo filtro utilizzando la console, segui le istruzioni riportate in [Collegamento dei criteri di filtro a una mappatura dell'origine evento (console)](invocation-eventfiltering.md#filtering-console) e inserisci la seguente stringa per i **criteri di filtraggio**.
```
{ "data" : { "order" : { "type" : [ "buy" ] } } }
```
------
#### [ AWS CLI ]
Per creare una nuova mappatura dell'origine degli eventi con questi criteri di filtraggio utilizzando l'AWS Command Line Interface (AWS CLI), esegui il comando seguente.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:kinesis:us-east-2:123456789012:stream/my-stream \
--filter-criteria '{"Filters": [{"Pattern": "{ \"data\" : { \"order\" : { \"type\" : [ \"buy\" ] } } }"}]}'
```
Per aggiungere questi criteri di filtraggio a una mappatura dell'origine degli eventi esistente, esegui il comando seguente.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"data\" : { \"order\" : { \"type\" : [ \"buy\" ] } } }"}]}'
```
------
#### [ AWS SAM ]
Per aggiungere questo filtro utilizzando AWS SAM, aggiungi il seguente frammento al modello YAML dell'origine degli eventi.
```
FilterCriteria:
Filters:
- Pattern: '{ "data" : { "order" : { "type" : [ "buy" ] } } }'
```
------
Per filtrare correttamente gli eventi da origini Kinesis, sia il campo dati sia i criteri di filtraggio per il campo dati devono essere in un formato JSON valido. Se uno dei due campi non è in un formato JSON valido, Lambda rilascia il messaggio o genera un'eccezione. La tabella seguente riepiloga il comportamento specifico:
| Formato dei dati in entrata | Formato del modello di filtro per le proprietà di dati | Operazione risultante |
| --- | --- | --- |
| JSON valido | JSON valido | Filtri Lambda in base ai criteri di filtro. |
| JSON valido | Nessun modello di filtro per le proprietà dei dati | Filtri Lambda (solo sulle altre proprietà dei metadati) in base ai criteri di filtro. |
| JSON valido | Non-JSON | Lambda genera un'eccezione al momento della creazione o dell'aggiornamento della mappatura dell'origine evento. Il modello di filtro per le proprietà dei dati deve essere in un formato JSON valido. |
| Non-JSON | JSON valido | Lambda rilascia il registro. |
| Non-JSON | Nessun modello di filtro per le proprietà dei dati | Filtri Lambda (solo sulle altre proprietà dei metadati) in base ai criteri di filtro. |
| Non-JSON | Non-JSON | Lambda genera un'eccezione al momento della creazione o dell'aggiornamento della mappatura dell'origine evento. Il modello di filtro per le proprietà dei dati deve essere in un formato JSON valido. |
## Filtraggio dei record aggregati Kinesis
Con Kinesis, puoi aggregare più record in un unico record flusso di dati Kinesis per aumentare il throughput dei dati. Lambda può applicare criteri di filtraggio ai record aggregati solo quando si utilizza il [fan-out avanzato](https://docs.aws.amazon.com/streams/latest/dev/enhanced-consumers.html) di Kinesis. Il filtraggio dei record aggregati con Kinesis standard non è supportato. Quando utilizzi il fan-out avanzato, configuri un consumatore Kinesis a throughput dedicato che funga da trigger per la funzione Lambda. Lambda filtra quindi i record aggregati e passa solo i record che soddisfano i criteri di filtraggio.
Per ulteriori informazioni sull'aggregazione dei record Kinesis, consulta la sezione [Aggregazione](https://docs.aws.amazon.com/streams/latest/dev/kinesis-kpl-concepts.html#kinesis-kpl-concepts-aggretation) nella pagina Concetti chiave di Kinesis Producer Library (KPL). Per ulteriori informazioni sull'utilizzo di Lambda con il fan-out avanzato di Kinesis, consulta la pagina [Aumento delle prestazioni di elaborazione dei flussi in tempo reale con il fan-out avanzato dei Flussi di dati Amazon Kinesis e AWS Lambda](https://aws.amazon.com/blogs/compute/increasing-real-time-stream-processing-performance-with-amazon-kinesis-data-streams-enhanced-fan-out-and-aws-lambda/) nel blog di calcolo AWS.
# Tutorial: Utilizzo di Lambda con Flusso di dati Kinesis
In questo tutorial, viene creata una funzione Lambda per utilizzare gli eventi da un flusso di dati Amazon Kinesis.
1. L'app personalizzata scrive record nel flusso.
1. AWS Lambda interroga lo stream e, quando rileva nuovi record nello stream, richiama la funzione Lambda.
1. AWS Lambda esegue la funzione Lambda assumendo il ruolo di esecuzione specificato al momento della creazione della funzione Lambda.
## Prerequisiti
### Installa AWS Command Line Interface
Se non l'hai ancora installato AWS Command Line Interface, segui i passaggi indicati in [Installazione o aggiornamento della versione più recente di AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) per installarlo.
Per eseguire i comandi nel tutorial, sono necessari un terminale a riga di comando o una shell (interprete di comandi). In Linux e macOS, utilizza la shell (interprete di comandi) e il gestore pacchetti preferiti.
**Nota**
Su Windows, alcuni comandi della CLI Bash utilizzati comunemente con Lambda (ad esempio, `zip`) non sono supportati dai terminali integrati del sistema operativo. Per ottenere una versione integrata su Windows di Ubuntu e Bash, [installa il sottosistema Windows per Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10).
## Creazione del ruolo di esecuzione
Crea il [ruolo di esecuzione](lambda-intro-execution-role.md) che autorizza la funzione ad accedere alle AWS risorse.
**Per creare un ruolo di esecuzione**
1. Apri la pagina [Ruoli](https://console.aws.amazon.com/iam/home#/roles) nella console IAM.
1. Scegliere **Crea ruolo**.
1. Creare un ruolo con le seguenti proprietà.
+ **Trusted entity **(Entità attendibile) – **AWS Lambda**.
+ **Autorizzazioni** — **AWSLambdaKinesisExecutionRole**.
+ **Nome ruolo** – **lambda-kinesis-role**.
La **AWSLambdaKinesisExecutionRole**policy dispone delle autorizzazioni necessarie alla funzione per leggere gli elementi da Kinesis e scrivere i log in CloudWatch Logs.
## Creazione della funzione
Crea una funzione Lambda che elabora i messaggi Kinesis. Il codice funzione registra l'ID dell'evento e i dati dell'evento del record CloudWatch Kinesis in Logs.
Questo tutorial utilizza il runtime Node.js 24, ma abbiamo anche fornito codice di esempio in altri linguaggi di runtime. Per visualizzare il codice per il runtime che ti interessa, seleziona la scheda corrispondente nella casella seguente. Il JavaScript codice che utilizzerai in questo passaggio si trova nel primo esempio mostrato nella **JavaScript**scheda.
------
#### [ .NET ]
**SDK per .NET**
C'è altro su GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda).
Utilizzo di un evento Kinesis con Lambda tramite .NET.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using System.Text;
using Amazon.Lambda.Core;
using Amazon.Lambda.KinesisEvents;
using AWS.Lambda.Powertools.Logging;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace KinesisIntegrationSampleCode;
public class Function
{
// Powertools Logger requires an environment variables against your function
// POWERTOOLS_SERVICE_NAME
[Logging(LogEvent = true)]
public async Task FunctionHandler(KinesisEvent evnt, ILambdaContext context)
{
if (evnt.Records.Count == 0)
{
Logger.LogInformation("Empty Kinesis Event received");
return;
}
foreach (var record in evnt.Records)
{
try
{
Logger.LogInformation($"Processed Event with EventId: {record.EventId}");
string data = await GetRecordDataAsync(record.Kinesis, context);
Logger.LogInformation($"Data: {data}");
// TODO: Do interesting work based on the new data
}
catch (Exception ex)
{
Logger.LogError($"An error occurred {ex.Message}");
throw;
}
}
Logger.LogInformation($"Successfully processed {evnt.Records.Count} records.");
}
private async Task GetRecordDataAsync(KinesisEvent.Record record, ILambdaContext context)
{
byte[] bytes = record.Data.ToArray();
string data = Encoding.UTF8.GetString(bytes);
await Task.CompletedTask; //Placeholder for actual async work
return data;
}
}
```
------
#### [ Go ]
**SDK per Go V2**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda).
Utilizzo di un evento Kinesis con Lambda tramite Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package main
import (
"context"
"log"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func handler(ctx context.Context, kinesisEvent events.KinesisEvent) error {
if len(kinesisEvent.Records) == 0 {
log.Printf("empty Kinesis event received")
return nil
}
for _, record := range kinesisEvent.Records {
log.Printf("processed Kinesis event with EventId: %v", record.EventID)
recordDataBytes := record.Kinesis.Data
recordDataText := string(recordDataBytes)
log.Printf("record data: %v", recordDataText)
// TODO: Do interesting work based on the new data
}
log.Printf("successfully processed %v records", len(kinesisEvent.Records))
return nil
}
func main() {
lambda.Start(handler)
}
```
------
#### [ Java ]
**SDK per Java 2.x**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda).
Utilizzo di un evento Kinesis con Lambda tramite Java.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package example;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.LambdaLogger;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.KinesisEvent;
public class Handler implements RequestHandler {
@Override
public Void handleRequest(final KinesisEvent event, final Context context) {
LambdaLogger logger = context.getLogger();
if (event.getRecords().isEmpty()) {
logger.log("Empty Kinesis Event received");
return null;
}
for (KinesisEvent.KinesisEventRecord record : event.getRecords()) {
try {
logger.log("Processed Event with EventId: "+record.getEventID());
String data = new String(record.getKinesis().getData().array());
logger.log("Data:"+ data);
// TODO: Do interesting work based on the new data
}
catch (Exception ex) {
logger.log("An error occurred:"+ex.getMessage());
throw ex;
}
}
logger.log("Successfully processed:"+event.getRecords().size()+" records");
return null;
}
}
```
------
#### [ JavaScript ]
**SDK per JavaScript (v3)**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/blob/main/integration-kinesis-to-lambda).
Consumo di un evento Kinesis con Lambda utilizzando. JavaScript
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
exports.handler = async (event, context) => {
for (const record of event.Records) {
try {
console.log(`Processed Kinesis Event - EventID: ${record.eventID}`);
const recordData = await getRecordDataAsync(record.kinesis);
console.log(`Record Data: ${recordData}`);
// TODO: Do interesting work based on the new data
} catch (err) {
console.error(`An error occurred ${err}`);
throw err;
}
}
console.log(`Successfully processed ${event.Records.length} records.`);
};
async function getRecordDataAsync(payload) {
var data = Buffer.from(payload.data, "base64").toString("utf-8");
await Promise.resolve(1); //Placeholder for actual async work
return data;
}
```
Consumo di un evento Kinesis con Lambda utilizzando. TypeScript
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import {
KinesisStreamEvent,
Context,
KinesisStreamHandler,
KinesisStreamRecordPayload,
} from "aws-lambda";
import { Buffer } from "buffer";
import { Logger } from "@aws-lambda-powertools/logger";
const logger = new Logger({
logLevel: "INFO",
serviceName: "kinesis-stream-handler-sample",
});
export const functionHandler: KinesisStreamHandler = async (
event: KinesisStreamEvent,
context: Context
): Promise => {
for (const record of event.Records) {
try {
logger.info(`Processed Kinesis Event - EventID: ${record.eventID}`);
const recordData = await getRecordDataAsync(record.kinesis);
logger.info(`Record Data: ${recordData}`);
// TODO: Do interesting work based on the new data
} catch (err) {
logger.error(`An error occurred ${err}`);
throw err;
}
logger.info(`Successfully processed ${event.Records.length} records.`);
}
};
async function getRecordDataAsync(
payload: KinesisStreamRecordPayload
): Promise {
var data = Buffer.from(payload.data, "base64").toString("utf-8");
await Promise.resolve(1); //Placeholder for actual async work
return data;
}
```
------
#### [ PHP ]
**SDK per PHP**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda).
Utilizzo di un evento Kinesis con Lambda tramite PHP.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
logger = $logger;
}
/**
* @throws JsonException
* @throws \Bref\Event\InvalidLambdaEvent
*/
public function handleKinesis(KinesisEvent $event, Context $context): void
{
$this->logger->info("Processing records");
$records = $event->getRecords();
foreach ($records as $record) {
$data = $record->getData();
$this->logger->info(json_encode($data));
// TODO: Do interesting work based on the new data
// Any exception thrown will be logged and the invocation will be marked as failed
}
$totalRecords = count($records);
$this->logger->info("Successfully processed $totalRecords records");
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**SDK per Python (Boto3)**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda).
Utilizzo di un evento Kinesis con Lambda tramite Python.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
import base64
def lambda_handler(event, context):
for record in event['Records']:
try:
print(f"Processed Kinesis Event - EventID: {record['eventID']}")
record_data = base64.b64decode(record['kinesis']['data']).decode('utf-8')
print(f"Record Data: {record_data}")
# TODO: Do interesting work based on the new data
except Exception as e:
print(f"An error occurred {e}")
raise e
print(f"Successfully processed {len(event['Records'])} records.")
```
------
#### [ Ruby ]
**SDK per Ruby**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda).
Utilizzo di un evento Kinesis con Lambda tramite Ruby.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
require 'aws-sdk'
def lambda_handler(event:, context:)
event['Records'].each do |record|
begin
puts "Processed Kinesis Event - EventID: #{record['eventID']}"
record_data = get_record_data_async(record['kinesis'])
puts "Record Data: #{record_data}"
# TODO: Do interesting work based on the new data
rescue => err
$stderr.puts "An error occurred #{err}"
raise err
end
end
puts "Successfully processed #{event['Records'].length} records."
end
def get_record_data_async(payload)
data = Base64.decode64(payload['data']).force_encoding('UTF-8')
# Placeholder for actual async work
# You can use Ruby's asynchronous programming tools like async/await or fibers here.
return data
end
```
------
#### [ Rust ]
**SDK per Rust**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda).
Utilizzo di un evento Kinesis con Lambda tramite Rust.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
use aws_lambda_events::event::kinesis::KinesisEvent;
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
async fn function_handler(event: LambdaEvent) -> Result<(), Error> {
if event.payload.records.is_empty() {
tracing::info!("No records found. Exiting.");
return Ok(());
}
event.payload.records.iter().for_each(|record| {
tracing::info!("EventId: {}",record.event_id.as_deref().unwrap_or_default());
let record_data = std::str::from_utf8(&record.kinesis.data);
match record_data {
Ok(data) => {
// log the record data
tracing::info!("Data: {}", data);
}
Err(e) => {
tracing::error!("Error: {}", e);
}
}
});
tracing::info!(
"Successfully processed {} records",
event.payload.records.len()
);
Ok(())
}
#[tokio::main]
async fn main() -> Result<(), Error> {
tracing_subscriber::fmt()
.with_max_level(tracing::Level::INFO)
// disable printing the name of the module in every log line.
.with_target(false)
// disabling time is handy because CloudWatch will add the ingestion time.
.without_time()
.init();
run(service_fn(function_handler)).await
}
```
------
**Creazione della funzione**
1. Crea una directory per il progetto, quindi passa a quella directory.
```
mkdir kinesis-tutorial
cd kinesis-tutorial
```
1. Copia il JavaScript codice di esempio in un nuovo file denominato`index.js`.
1. Crea un pacchetto di implementazione.
```
zip function.zip index.js
```
1. Creare una funzione Lambda con il comando `create-function`.
```
aws lambda create-function --function-name ProcessKinesisRecords \
--zip-file fileb://function.zip --handler index.handler --runtime nodejs24.x \
--role arn:aws:iam::111122223333:role/lambda-kinesis-role
```
## Test della funzione Lambda
Richiama la funzione Lambda manualmente utilizzando il comando `invoke` AWS Lambda CLI e un evento Kinesis di esempio.
**Verifica della funzione Lambda**
1. Copiare il codice JSON seguente in un file e salvarlo con nome `input.txt`.
```
{
"Records": [
{
"kinesis": {
"kinesisSchemaVersion": "1.0",
"partitionKey": "1",
"sequenceNumber": "49590338271490256608559692538361571095921575989136588898",
"data": "SGVsbG8sIHRoaXMgaXMgYSB0ZXN0Lg==",
"approximateArrivalTimestamp": 1545084650.987
},
"eventSource": "aws:kinesis",
"eventVersion": "1.0",
"eventID": "shardId-000000000006:49590338271490256608559692538361571095921575989136588898",
"eventName": "aws:kinesis:record",
"invokeIdentityArn": "arn:aws:iam::111122223333:role/lambda-kinesis-role",
"awsRegion": "us-east-2",
"eventSourceARN": "arn:aws:kinesis:us-east-2:111122223333:stream/lambda-stream"
}
]
}
```
1. Utilizzare il comando `invoke` per inviare l'evento alla funzione.
```
aws lambda invoke --function-name ProcessKinesisRecords \
--cli-binary-format raw-in-base64-out \
--payload file://input.txt outputfile.txt
```
L'**cli-binary-format**opzione è obbligatoria se utilizzi la versione 2. AWS CLI Per rendere questa impostazione come predefinita, esegui `aws configure set cli-binary-format raw-in-base64-out`. Per ulteriori informazioni, consulta la pagina [AWS CLI supported global command line options](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) nella *Guida per l'utente di AWS Command Line Interface versione 2*.
La risposta viene salvata in `out.txt`.
## Creare un flusso Kinesis
Utilizzare il comando `create-stream ` per creare un flusso.
```
aws kinesis create-stream --stream-name lambda-stream --shard-count 1
```
Eseguire il seguente comando `describe-stream` per ottenere il flusso ARN.
```
aws kinesis describe-stream --stream-name lambda-stream
```
Verrà visualizzato l’output seguente:
```
{
"StreamDescription": {
"Shards": [
{
"ShardId": "shardId-000000000000",
"HashKeyRange": {
"StartingHashKey": "0",
"EndingHashKey": "340282366920746074317682119384634633455"
},
"SequenceNumberRange": {
"StartingSequenceNumber": "49591073947768692513481539594623130411957558361251844610"
}
}
],
"StreamARN": "arn:aws:kinesis:us-east-1:111122223333:stream/lambda-stream",
"StreamName": "lambda-stream",
"StreamStatus": "ACTIVE",
"RetentionPeriodHours": 24,
"EnhancedMonitoring": [
{
"ShardLevelMetrics": []
}
],
"EncryptionType": "NONE",
"KeyId": null,
"StreamCreationTimestamp": 1544828156.0
}
}
```
Nella fase successiva utilizzare l'ARN del flusso per associare il flusso alla funzione Lambda.
## Aggiungi una fonte di eventi in AWS Lambda
Eseguire il seguente comando AWS CLI `add-event-source`.
```
aws lambda create-event-source-mapping --function-name ProcessKinesisRecords \
--event-source arn:aws:kinesis:us-east-1:111122223333:stream/lambda-stream \
--batch-size 100 --starting-position LATEST
```
Annotare l'ID della mappatura per utilizzarlo in futuro. Mediante l'esecuzione del comando `list-event-source-mappings` è possibile ottenere un elenco di mappature delle origini eventi.
```
aws lambda list-event-source-mappings --function-name ProcessKinesisRecords \
--event-source arn:aws:kinesis:us-east-1:111122223333:stream/lambda-stream
```
Nella risposta è possibile verificare che il valore dello stato sia `enabled` (attivato). Le mappature dell'origine eventi possono essere disabilitate per sospendere il polling temporaneamente senza perdere alcuni record.
## Eseguire il test della configurazione
Per testare la mappatura dell'origine eventi, aggiungere i record dell'evento al flusso Kinesis. Il valore `--data` è una stringa che il CLI codifica in base64 prima di inviarla a Kinesis. È possibile eseguire lo stesso comando più volte per aggiungere più record al flusso.
```
aws kinesis put-record --stream-name lambda-stream --partition-key 1 \
--data "Hello, this is a test."
```
Lambda usa il ruolo di esecuzione per leggere i record dal flusso. Quindi richiama la funzione Lambda, passando ai batch dei record. La funzione decodifica i dati di ogni record e li registra, inviando l'output a CloudWatch Logs. Visualizza i log nella [console CloudWatch ](https://console.aws.amazon.com/cloudwatch).
## Pulizia delle risorse
Ora è possibile eliminare le risorse create per questo tutorial, a meno che non si voglia conservarle. Eliminando AWS le risorse che non utilizzi più, eviti addebiti inutili a tuo carico. Account AWS
**Come eliminare il ruolo di esecuzione**
1. Aprire la pagina [Ruoli](https://console.aws.amazon.com/iam/home#/roles) della console IAM.
1. Selezionare il ruolo di esecuzione creato.
1. Scegliere **Elimina**.
1. Inserisci il nome del ruolo nel campo di immissione testo e seleziona **Delete** (Elimina).
**Per eliminare la funzione Lambda**
1. Aprire la pagina [Functions (Funzioni)](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Selezionare la funzione creata.
1. Scegliere **Operazioni**, **Elimina**.
1. Digita **confirm** nel campo di immissione testo e scegli **Delete** (Elimina).
**Per eliminare il flusso Kinesis**
1. [Accedi Console di gestione AWS e apri la console Kinesis all'indirizzo https://console.aws.amazon.com /kinesis.](https://console.aws.amazon.com/kinesis)
1. Selezionare il flusso creato.
1. Scegli **Operazioni** > **Elimina**.
1. Inserisci **delete** nel campo di immissione del testo.
1. Scegli **Delete** (Elimina).
# Utilizzo di Lambda con Kubernetes
Puoi implementare e gestire funzioni Lambda con l'API Kubernetes utilizzando i [controller AWS per Kubernetes (ACK)](https://aws-controllers-k8s.github.io/community/docs/community/overview/) o [Crossplane](https://docs.crossplane.io/latest/packages/providers/).
## Controller AWS per Kubernetes (ACK)
Puoi utilizzare ACK per implementare e gestire risorse AWS dall'API Kubernetes. Tramite ACK, AWS fornisce controller personalizzati open source per servizi AWS, ad esempio Lambda, Amazon Elastic Container Registry (Amazon ECR), Amazon Simple Storage Service (Amazon S3) e Amazon SageMaker AI. Ogni servizio AWS supportato ha un proprio controller personalizzato. Nel cluster Kubernetes installa un controller per ogni servizio AWS da utilizzare. Crea, quindi, una [definizione risorsa personalizzata (CRD)](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) per definire le risorse AWS.
È preferibile utilizzare [Helm 3.8 o versioni successive](https://helm.sh/docs/intro/install/) per installare i controller ACK. Ogni controller ACK è dotato di un proprio grafico Helm, che installa il controller, le CRD e le regole RBAC di Kubernetes. Per ulteriori informazioni, consulta [Installare un ACK Controller](https://aws-controllers-k8s.github.io/community/docs/user-docs/install/) nella documentazione di ACK.
Dopo aver creato la risorsa personalizzata ACK, puoi utilizzarla come qualunque altro oggetto Kubernetes integrato. Ad esempio, puoi implementare e gestire funzioni Lambda con le tue toolchain Kubernetes preferite, inclusa [kubectl](https://kubernetes.io/docs/reference/kubectl/).
Di seguito sono riportati alcuni esempi di casi d'uso per il provisioning di funzioni Lambda tramite ACK:
+ La tua organizzazione utilizza il [controllo degli accessi basato sui ruoli (RBAC)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) e [ruoli IAM per gli account di servizio](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) per creare limiti delle autorizzazioni. Con ACK puoi riutilizzare questo modello di sicurezza per Lambda senza bisogno di creare nuovi utenti e policy.
+ La tua organizzazione utilizza un processo DevOps per implementare le risorse in un cluster Amazon Elastic Kubernetes Service (Amazon EKS) utilizzando manifesti Kubernetes. Con ACK puoi utilizzare un manifesto per eseguire il provisioning delle funzioni Lambda senza creare un'infrastruttura separata come modelli di codice.
Per ulteriori informazioni sull'utilizzo di ACK, consulta il [tutorial Lambda nella documentazione di ACK](https://aws-controllers-k8s.github.io/community/docs/tutorials/lambda-oci-example/).
## Crossplane
[Crossplane](https://docs.crossplane.io/latest/packages/providers/) è un progetto CNCF (Cloud Native Computing Foundation) che utilizza Kubernetes per gestire risorse dell'infrastruttura cloud. Con Crossplane gli sviluppatori possono richiedere l'infrastruttura senza doverne comprendere le complessità. I team della piattaforma mantengono il controllo sulle modalità di provisioning e gestione dell'infrastruttura.
Utilizzando Crossplane puoi implementare e gestire funzioni Lambda con le tue toolchain Kubernetes preferite, ad esempio [kubectl](https://kubernetes.io/docs/reference/kubectl/), e qualunque pipeline CI/CD in grado di implementare manifesti su Kubernetes. Di seguito sono riportati alcuni esempi di casi d'uso per il provisioning di funzioni Lambda tramite Crossplane:
+ La tua organizzazione desidera attenersi alla conformità accertandosi che le funzioni Lambda abbiano [tag](configuration-tags.md) corretti. I team della piattaforma possono utilizzare [composizioni Crossplane](https://docs.crossplane.io/latest/get-started/get-started-with-composition/) per definire questa policy tramite astrazioni API. Gli sviluppatori, quindi, possono utilizzare tali astrazioni per implementare funzioni Lambda con tag.
+ Il tuo progetto utilizza GitOps con Kubernetes. In questo modello, Kubernetes riconcilia continuamente il repository git (stato desiderato) con le risorse in esecuzione all'interno del cluster (stato corrente). Se esistono differenze, il processo GitOps apporta automaticamente modifiche al cluster. Puoi utilizzare GitOps con Kubernetes per implementare e gestire funzioni Lambda tramite Crossplane, adoperando strumenti e concetti familiari di Kubernetes, ad esempio [CRD](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) e [controller](https://kubernetes.io/docs/concepts/architecture/controller/).
Per ulteriori informazioni sull'utilizzo di Crossplane con Lambda, consulta:
+ [Schemi AWS per Crossplane](https://github.com/awslabs/crossplane-on-eks/blob/main/examples/upbound-aws-provider/README.md#deploy-the-examples): questo repository include esempi di utilizzo di Crossplane per l'implementazione di risorse AWS, incluse le funzioni Lambda.
**Nota**
Gli schemi AWS per Crossplane sono in fase di sviluppo attivo e non devono essere utilizzati in produzione.
+ [Implementazione di Lambda con Amazon EKS e Crossplane](https://www.youtube.com/watch?v=m-9KLq29K4k): questo video mostra un esempio avanzato di implementazione di un'architettura serverless AWS con Crossplane, esplorando la progettazione dal punto di vista dello sviluppatore e della piattaforma.
# Utilizzo di Lambda con Amazon MQ
**Nota**
[Se desideri inviare dati a una destinazione diversa da una funzione Lambda o arricchire i dati prima di inviarli, consulta Amazon Pipes. EventBridge ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-pipes.html)
Amazon MQ è un servizio gestito di broker dei messaggi per [Apache ActiveMQ](https://activemq.apache.org/) e [RabbitMQ](https://www.rabbitmq.com). Un *broker di messaggi* consente alle applicazioni e ai componenti software di comunicare utilizzando vari linguaggi di programmazione, sistemi operativi e protocolli di messaggistica formali tramite destinazioni eventi di tipo argomento o coda.
Amazon MQ può anche gestire automaticamente istanze di Amazon Elastic Compute Cloud (Amazon EC2) con l'installazione di ActiveMQ o RabbitMQ e la fornitura di diverse topologie di rete e altri requisiti infrastrutturali.
Puoi utilizzare una funzione Lambda per elaborare i record da un broker di messaggi di Amazon MQ. Lambda richiama la funzione tramite uno [strumento di mappatura dell'origine degli eventi](invocation-eventsourcemapping.md), una risorsa Lambda che legge i messaggi dal broker e richiama la funzione [in maniera sincrona](invocation-sync.md).
**avvertimento**
Gli strumenti di mappatura dell'origine degli eventi elaborano ogni evento almeno una volta e può verificarsi un'elaborazione duplicata dei record. Per evitare potenziali problemi legati agli eventi duplicati, ti consigliamo vivamente di rendere idempotente il codice della funzione. Per ulteriori informazioni, consulta [Come posso rendere idempotente la mia funzione Lambda](https://repost.aws/knowledge-center/lambda-function-idempotent) nel Knowledge Center. AWS
Lo strumento di mappatura dell'origine degli eventi di Amazon MQ presenta le seguenti restrizioni di configurazione:
+ Simultaneità: le funzioni Lambda che utilizzano uno strumento di mappatura dell'origine degli eventi Amazon MQ hanno un'impostazione di [simultaneità](lambda-concurrency.md) massima predefinita. Per ActiveMQ, il servizio Lambda limita il numero di ambienti di esecuzione simultanei a cinque per lo strumento di mappatura dell'origine degli eventi di Amazon MQ. Per RabbitMQ, il numero di ambienti di esecuzione simultanei è limitato a 1 per lo strumento di mappatura dell'origine degli eventi di Amazon MQ. Anche se modifichi le impostazioni di simultaneità sottoposta a provisioning o riservata, il servizio Lambda non renderà disponibili altri ambienti di esecuzione. Per richiedere un aumento della concorrenza massima predefinita per una singola mappatura della sorgente di eventi Amazon MQ, contatta Supporto l'UUID di mappatura della sorgente dell'evento e la regione. Poiché gli aumenti vengono applicati al livello dello strumento di mappatura dell'origine degli eventi specifico, non a livello di account o regione, è necessario richiedere manualmente un aumento di scalabilità per ogni strumento di mappatura dell'origine degli eventi.
+ Più account: Lambda non supporta l'elaborazione tra più account. Non puoi utilizzare Lambda per elaborare i record da un broker di messaggi di Amazon MQ incluso in un Account AWS diverso.
+ Autenticazione: per ActiveMQ, è supportato solo [SimpleAuthenticationPlugin](https://activemq.apache.org/security#simple-authentication-plugin)ActiveMQ. Per RabbitMQ è supportato solo il meccanismo di autenticazione [PLAIN](https://www.rabbitmq.com/access-control.html#mechanisms). Gli utenti devono utilizzare per gestire le proprie Gestione dei segreti AWS credenziali. Per ulteriori informazioni sull'autenticazione di ActiveMQ, consulta [Integrazione di broker ActiveMQ con LDAP](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/security-authentication-authorization.html) nella *Guida per gli sviluppatori di Amazon MQ*.
+ Quota di connessione: i broker hanno un numero massimo di connessioni consentite per protocollo a livello di collegamento. Questa quota si basa sul tipo di istanza del broker. Per ulteriori informazioni, consulta la sezione [Broker](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/amazon-mq-limits.html#broker-limits) di **Quote in Amazon MQ** nella *Guida per gli sviluppatori di Amazon MQ*.
+ Connettività: puoi creare broker in un VPC (Virtual Private Cloud) pubblico o privato. Per uso privato VPCs, la funzione Lambda deve accedere al VPC per ricevere messaggi. Per ulteriori informazioni, consulta [Configurare la sicurezza della rete](process-mq-messages-with-lambda.md#process-mq-messages-with-lambda-networkconfiguration) di seguito in questa sezione.
+ Destinazioni eventi: sono supportate solo le destinazioni coda. Tuttavia, puoi utilizzare un argomento virtuale che si comporta internamente come un argomento mentre interagisce con Lambda come una coda. Per ulteriori informazioni, consulta [Destinazioni virtuali](https://activemq.apache.org/virtual-destinations) sul sito web di Apache ActiveMQ e [Host virtuali](https://www.rabbitmq.com/vhosts.html) sul sito Web di RabbitMQ.
+ Topologia di rete: per ActiveMQ è supportato un solo broker a istanza singola o in standby per ogni strumento di mappatura dell'origine degli eventi. Per RabbitMQ è supportata una sola implementazione di broker o cluster a istanza singola per ogni strumento di mappatura dell'origine degli eventi. I broker a istanza singola richiedono un endpoint di failover. Per ulteriori informazioni su queste modalità di implementazione del broker, consulta [Architettura del broker MQ attiva](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/amazon-mq-broker-architecture.html) e [Architettura del broker MQ di Rabbit](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/rabbitmq-broker-architecture.html) nella *Guida per gli sviluppatori di Amazon MQ*.
+ Protocolli: i protocolli supportati dipendono dal tipo di integrazione di Amazon MQ.
+ Per le integrazioni ActiveMQ, Lambda utilizza i messaggi utilizzando OpenWire/Java il protocollo Message Service (JMS). Non sono supportati altri protocolli per l'utilizzo dei messaggi. All'interno del protocollo JMS, sono supportati solo [https://activemq.apache.org/components/cms/api_docs/activemqcpp-3.6.0/html/classactivemq_1_1commands_1_1_active_m_q_text_message.html](https://activemq.apache.org/components/cms/api_docs/activemqcpp-3.6.0/html/classactivemq_1_1commands_1_1_active_m_q_text_message.html) e [https://activemq.apache.org/components/cms/api_docs/activemqcpp-3.9.0/html/classactivemq_1_1commands_1_1_active_m_q_bytes_message.html](https://activemq.apache.org/components/cms/api_docs/activemqcpp-3.9.0/html/classactivemq_1_1commands_1_1_active_m_q_bytes_message.html). Lambda supporta anche le proprietà JMS personalizzate. Per ulteriori informazioni sul OpenWire protocollo, vedere [OpenWire](https://activemq.apache.org/openwire.html)il sito Web di Apache ActiveMQ.
+ Per le integrazioni RabbitMQ, Lambda utilizza i messaggi tramite il protocollo AMQP 0-9-1. Non sono supportati altri protocolli per l'utilizzo dei messaggi. Per ulteriori informazioni sull'implementazione del protocollo AMQP 0-9-1 in RabbitMQ, consulta la [Guida di riferimento completa di AMQP 0-9-1](https://www.rabbitmq.com/amqp-0-9-1-reference.html) sul sito web di RabbitMQ.
Lambda supporta automaticamente le versioni più recenti di ActiveMQ e RabbitMQ supportate da Amazon MQ. Per le ultime versioni supportate, consulta le [Note di rilascio di Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/amazon-mq-release-notes.html) nella *Guida per gli sviluppatori di Amazon MQ*.
**Nota**
Per impostazione predefinita, Amazon MQ prevede un periodo di manutenzione settimanale per i broker. Durante quella finestra temporale, i broker non sono disponibili. Per i broker senza standby, Lambda non può elaborare alcun messaggio durante tale finestra.
**Topics**
+ [
## Informazioni sul gruppo di consumatori Lambda per Amazon MQ
](#services-mq-configure)
+ [
# Configurazione dell'origine eventi Amazon MQ per Lambda
](process-mq-messages-with-lambda.md)
+ [
# Parametri dello strumento di mappatura dell'origine degli eventi
](services-mq-params.md)
+ [
# Filtrare gli eventi da una origine eventi Amazon MQ
](with-mq-filtering.md)
+ [
# Risolvere i problemi relativi gli errori di mappatura dell'origine eventi di Amazon MQ
](services-mq-errors.md)
## Informazioni sul gruppo di consumatori Lambda per Amazon MQ
Per interagire con Amazon MQ, Lambda crea un gruppo di utenti che può leggere dai broker di Amazon MQ. Il gruppo di utenti viene creato con lo stesso ID dell'UUID dello strumento di mappatura dell'origine degli eventi.
Per le origini eventi di Amazon MQ, Lambda crea un batch dei record e li invia alla tua funzione in un singolo payload. Per controllare il comportamento, puoi configurare la finestra batch e le dimensioni del batch. Lambda estrae i messaggi finché elabora la dimensione del payload massima di 6 MB, la finestra di batch scade o il numero di record raggiunge la dimensione completa del batch. Per ulteriori informazioni, consulta [Comportamento di batching](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching).
Il gruppo di utenti recupera i messaggi come BLOB di byte, li codifica in base64 in un singolo payload JSON e richiama la tua funzione. Se la funzione restituisce un errore per uno qualunque dei messaggi in un batch, Lambda ritenta l'intero batch di messaggi fino a quando l'elaborazione riesce o i messaggi scadono.
**Nota**
Anche se le funzioni Lambda generalmente prevedono un timeout massimo di 15 minuti, gli strumenti di mappatura dell'origine degli eventi per Amazon MSK, Apache Kafka autogestito, Amazon DocumentDB e Amazon MQ per ActiveMQ e RabbitMQ supportano solo funzioni con timeout massimi di 14 minuti. Questa limitazione garantisce che lo strumento di mappatura dell'origine degli eventi possa gestire correttamente errori di funzioni e nuovi tentativi.
Puoi monitorare l'utilizzo simultaneo di una determinata funzione utilizzando la `ConcurrentExecutions` metrica in Amazon. CloudWatch Per ulteriori informazioni sulla simultaneità, consulta [Configurazione della simultaneità riservata per una funzione](configuration-concurrency.md).
**Example Eventi record di Amazon MQ**
```
{
"eventSource": "aws:mq",
"eventSourceArn": "arn:aws:mq:us-east-2:111122223333:broker:test:b-9bcfa592-423a-4942-879d-eb284b418fc8",
"messages": [
{
"messageID": "ID:b-9bcfa592-423a-4942-879d-eb284b418fc8-1---mq---us-east-2.amazonaws.com.rproxy.goskope.com-37557-1234520418293-4:1:1:1:1",
"messageType": "jms/text-message",
"deliveryMode": 1,
"replyTo": null,
"type": null,
"expiration": "60000",
"priority": 1,
"correlationId": "myJMSCoID",
"redelivered": false,
"destination": {
"physicalName": "testQueue"
},
"data":"QUJDOkFBQUE=",
"timestamp": 1598827811958,
"brokerInTime": 1598827811958,
"brokerOutTime": 1598827811959,
"properties": {
"index": "1",
"doAlarm": "false",
"myCustomProperty": "value"
}
},
{
"messageID": "ID:b-9bcfa592-423a-4942-879d-eb284b418fc8-1---mq---us-east-2.amazonaws.com.rproxy.goskope.com-37557-1234520418293-4:1:1:1:1",
"messageType": "jms/bytes-message",
"deliveryMode": 1,
"replyTo": null,
"type": null,
"expiration": "60000",
"priority": 2,
"correlationId": "myJMSCoID1",
"redelivered": false,
"destination": {
"physicalName": "testQueue"
},
"data":"LQaGQ82S48k=",
"timestamp": 1598827811958,
"brokerInTime": 1598827811958,
"brokerOutTime": 1598827811959,
"properties": {
"index": "1",
"doAlarm": "false",
"myCustomProperty": "value"
}
}
]
}
```
```
{
"eventSource": "aws:rmq",
"eventSourceArn": "arn:aws:mq:us-east-2:111122223333:broker:pizzaBroker:b-9bcfa592-423a-4942-879d-eb284b418fc8",
"rmqMessagesByQueue": {
"pizzaQueue::/": [
{
"basicProperties": {
"contentType": "text/plain",
"contentEncoding": null,
"headers": {
"header1": {
"bytes": [
118,
97,
108,
117,
101,
49
]
},
"header2": {
"bytes": [
118,
97,
108,
117,
101,
50
]
},
"numberInHeader": 10
},
"deliveryMode": 1,
"priority": 34,
"correlationId": null,
"replyTo": null,
"expiration": "60000",
"messageId": null,
"timestamp": "Jan 1, 1970, 12:33:41 AM",
"type": null,
"userId": "AIDACKCEVSQ6C2EXAMPLE",
"appId": null,
"clusterId": null,
"bodySize": 80
},
"redelivered": false,
"data": "eyJ0aW1lb3V0IjowLCJkYXRhIjoiQ1pybWYwR3c4T3Y0YnFMUXhENEUifQ=="
}
]
}
}
```
Nell'esempio di RabbitMQ, `pizzaQueue` è il nome della coda RabbitMQ e `/` è il nome dell'host virtuale. Quando si ricevono messaggi, l'origine eventi elenca i messaggi in `pizzaQueue::/`.
# Configurazione dell'origine eventi Amazon MQ per Lambda
**Topics**
+ [
## Configurare la sicurezza della rete
](#process-mq-messages-with-lambda-networkconfiguration)
+ [
## Creare lo strumento di mappatura dell'origine degli eventi
](#services-mq-eventsourcemapping)
## Configurare la sicurezza della rete
Per concedere a Lambda l'accesso completo ad Amazon MQ tramite lo strumento di mappatura dell'origine degli eventi, il broker deve utilizzare un endpoint pubblico (indirizzo IP pubblico) oppure deve fornire l'accesso all'Amazon VPC in cui hai creato il broker.
Quando usi Amazon MQ con Lambda, crea [endpoint VPC AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) che forniscono alla funzione l'accesso alle risorse del tuo Amazon VPC.
**Nota**
AWS PrivateLink Gli endpoint VPC sono necessari per le funzioni con mappature delle sorgenti degli eventi che utilizzano la modalità predefinita (su richiesta) per i poller degli eventi. Se la mappatura delle sorgenti degli eventi utilizza la [modalità provisioning](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode), non è necessario configurare gli endpoint VPC AWS PrivateLink .
Crea un endpoint per fornire l'accesso alle seguenti risorse:
+ Lambda: crea un endpoint per il principale del servizio Lambda.
+ AWS STS — Crea un endpoint per consentire AWS STS a un responsabile del servizio di assumere un ruolo per tuo conto.
+ Secrets Manager: se il tuo broker utilizza Secrets Manager per archiviare le credenziali, crea un endpoint per Secrets Manager.
In alternativa, configura un gateway NAT su ogni sottorete pubblica in Amazon VPC. Per ulteriori informazioni, consulta [Abilitare l'accesso a Internet per funzioni Lambda connesse a un VPC](configuration-vpc-internet.md).
Quando crei una mappatura dell'origine degli eventi per Amazon MQ, Lambda verifica se Elastic Network Interfaces ENIs () sono già presenti per le sottoreti e i gruppi di sicurezza configurati per il tuo Amazon VPC. Se Lambda rileva che esistono ENIs, tenta di riutilizzarli. Altrimenti, Lambda ne crea di nuovi ENIs per connettersi all'origine dell'evento e richiamare la funzione.
**Nota**
Le funzioni Lambda vengono sempre eseguite all'interno del servizio Lambda di VPCs proprietà. La configurazione VPC della funzione non influisce sullo strumento di mappatura dell'origine degli eventi. Solo la configurazione di rete dell'origine dell'evento determina il modo in cui Lambda si connette all'origine dell'evento.
Configura i gruppi di sicurezza per l'Amazon VPC contenente il tuo broker. Per impostazione predefinita, Amazon MQ utilizza le seguenti porte: `61617` (Amazon MQ per ActiveMQ) e `5671` (Amazon MQ per RabbitMQ).
+ Regole in ingresso: consenti tutto il traffico sulla porta del broker predefinita per il gruppo di sicurezza associato all'origine eventi. In alternativa, puoi utilizzare una regola del gruppo di sicurezza autoreferenziante per consentire l'accesso da istanze all'interno dello stesso gruppo di sicurezza.
+ Regole in uscita: consentono tutto il traffico sulla porta `443` per destinazioni esterne se la funzione deve comunicare con i servizi. AWS In alternativa, puoi anche utilizzare una regola del gruppo di sicurezza autoreferenziale per limitare l'accesso al broker se non hai bisogno di comunicare con altri servizi. AWS
+ Regole di ingresso degli endpoint Amazon VPC: se utilizzi un endpoint Amazon VPC, il gruppo di sicurezza associato all'endpoint Amazon VPC deve consentire il traffico in entrata sulla porta `443` dal gruppo di sicurezza del broker.
Se il broker utilizza l'autenticazione, puoi anche limitare la policy degli endpoint per l'endpoint Secrets Manager. Per chiamare l'API Secrets Manager, Lambda utilizza il ruolo della funzione, non il principale del servizio Lambda.
**Example Policy dell'endpoint VPC: endpoint Secrets Manager**
```
{
"Statement": [
{
"Action": "secretsmanager:GetSecretValue",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws::iam::123456789012:role/my-role"
]
},
"Resource": "arn:aws::secretsmanager:us-west-2:123456789012:secret:my-secret"
}
]
}
```
Quando utilizzi gli endpoint Amazon VPC, AWS indirizza le chiamate API per richiamare la tua funzione utilizzando l'Elastic Network Interface (ENI) dell'endpoint. Il responsabile del servizio Lambda deve `lambda:InvokeFunction` richiamare tutti i ruoli e le funzioni che li utilizzano. ENIs
Per impostazione predefinita, gli endpoint Amazon VPC dispongono di policy IAM aperte che consentono un ampio accesso alle risorse. La best practice consiste nel limitare queste policy per eseguire le azioni necessarie utilizzando quell'endpoint. Per garantire che lo strumento di mappatura dell'origine degli eventi sia in grado di invocare la funzione Lambda, la policy degli endpoint VPC deve consentire al principale del servizio Lambda di chiamare `sts:AssumeRole` e `lambda:InvokeFunction`. Limitare le policy degli endpoint VPC per consentire solo le chiamate API provenienti dall'organizzazione impedisce il corretto funzionamento dello strumento di mappatura dell'origine degli eventi, pertanto `"Resource": "*"` è richiesto in queste policy.
Il seguente esempio di policy degli endpoint VPC mostra come concedere l'accesso richiesto al principale del servizio Lambda per gli endpoint AWS STS e Lambda.
**Example Policy VPC Endpoint — endpoint AWS STS**
```
{
"Statement": [
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
**Example Policy dell'endpoint VPC: endpoint Lambda**
```
{
"Statement": [
{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
## Creare lo strumento di mappatura dell'origine degli eventi
Creare una [mappatura dell'origine eventi](invocation-eventsourcemapping.md) per indicare a Lambda di inviare i record da un broker Amazon MQ a una funzione Lambda. È possibile creare più mappature delle origini di eventi per elaborare gli stessi dati con più funzioni o per elaborare elementi da più fonti con una singola funzione.
Per configurare la funzione per la lettura da Amazon MQ, aggiungi le autorizzazioni richieste e crea un trigger **MQ** nella console Lambda.
Per leggere i record da un broker Amazon MQ, la funzione Lambda richiede le seguenti autorizzazioni. Concedi a Lambda l'autorizzazione a interagire con il tuo broker Amazon MQ e le relative risorse sottostanti aggiungendo istruzioni di autorizzazione al tuo [ruolo di esecuzione](lambda-intro-execution-role.md) della funzione:
+ [mq: DescribeBroker](https://docs.aws.amazon.com/amazon-mq/latest/api-reference/brokers-broker-id.html#brokers-broker-id-http-methods)
+ [gestore dei segreti: GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html)
+ [ec2: CreateNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateNetworkInterface.html)
+ [ec2: DeleteNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteNetworkInterface.html)
+ [ec2: DescribeNetworkInterfaces](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeNetworkInterfaces.html)
+ [ec2: DescribeSecurityGroups](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSecurityGroups.html)
+ [ec2: DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html)
+ [ec2: DescribeVpcs](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpcs.html)
+ [registri: CreateLogGroup](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogGroup.html)
+ [registri: CreateLogStream](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogStream.html)
+ [registri: PutLogEvents](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html)
**Nota**
Quando utilizzi una chiave gestita dal cliente crittografata, aggiungi anche l'autorizzazione `[kms:Decrypt](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-bootstrap-brokers.html#clusters-clusterarn-bootstrap-brokersget)`.
**Per aggiungere le autorizzazioni e creare un trigger**
1. Aprire la pagina [Functions](https://console.aws.amazon.com/lambda/home#/functions) (Funzioni) della console Lambda.
1. Scegliere il nome della funzione.
1. Quindi, seleziona la scheda **Configuration** (Configurazione) e poi **Permissions** (Autorizzazioni).
1. In **Nome del ruolo**, scegli il link al tuo ruolo di esecuzione. Questo ruolo si apre nella console IAM.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/execution-role.png)
1. Scegli **Aggiungi autorizzazioni**, quindi seleziona **Crea policy in linea**.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/inline-policy.png)
1. Nella sezione **Editor di policy**, scegli **JSON**. Immetti la seguente policy. La tua funzione necessita di queste autorizzazioni per leggere da un broker Amazon MQ.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"mq:DescribeBroker",
"secretsmanager:GetSecretValue",
"ec2:CreateNetworkInterface",
"ec2:DeleteNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
```
------
**Nota**
Quando utilizzi una chiave gestita dal cliente crittografata, è necessario aggiungere anche l'autorizzazione `kms:Decrypt`.
1. Scegli **Next (Successivo)**. Inserire un nome per la policy, quindi seleziona **Crea policy**.
1. Torna alla funzione nella console Lambda. In **Panoramica delle funzioni**, scegliere **Aggiungi trigger**.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/add-trigger.png)
1. Seleziona il tipo di trigger **MQ**.
1. Configurare le opzioni richieste, quindi scegliere **Add (Aggiungi)**.
Lambda supporta le seguenti opzioni per le origini eventi Amazon MQ:
+ **Broker MQ** – Selezionare un broker Amazon MQ.
+ **Batch size (Dimensioni batch**) – Impostare il numero massimo di messaggi da recuperare in un singolo batch.
+ **Queue name (Nome della coda)** - Immettere la coda Amazon MQ da utilizzare.
+ **Source access configuration (Configurazione dell'accesso di origine)** – Immettere le informazioni sull'host virtuale e il segreto di Secrets Manager in cui sono memorizzate le credenziali del broker.
+ **Abilita trigger** – Disabilitare il trigger per interrompere l'elaborazione dei record.
Per attivare o disattivare il trigger (o eliminarlo), scegliere il trigger **MQ** nella finestra di progettazione. Per riconfigurare il trigger, utilizzare le operazioni API della mappatura dell'origine eventi.
# Parametri dello strumento di mappatura dell'origine degli eventi
Tutti i tipi di origine eventi Lambda condividono le stesse operazioni API [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) e [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html). Tuttavia, solo alcuni dei parametri si applicano ad Amazon MQ e RabbitMQ.
| Parametro | Obbligatorio | Predefinito | Note |
| --- | --- | --- | --- |
| BatchSize | N | 100 | Massimo: 10.000 |
| Abilitato | N | true | nessuno |
| FunctionName | Y | N/D | nessuno |
| FilterCriteria | N | N/D | [Controllare gli eventi che Lambda invia alla funzione](invocation-eventfiltering.md) |
| MaximumBatchingWindowInSeconds | N | 500 ms | [Comportamento di batching](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching) |
| Queues | N | N/D | Il nome della coda di destinazione del broker Amazon MQ da utilizzare. |
| SourceAccessConfigurations | N | N/D | Per ActiveMQ, le credenziali BASIC\$1AUTH. Per RabbitMQ, può contenere sia le credenziali BASIC\$1AUTH che le informazioni VIRTUAL\$1HOST. |
# Filtrare gli eventi da una origine eventi Amazon MQ
Puoi utilizzare il filtraggio degli eventi per controllare quali record di un flusso o di una coda Lambda invia alla funzione. Per informazioni generali sul funzionamento del filtraggio eventi, consulta [Controllare gli eventi che Lambda invia alla funzione](invocation-eventfiltering.md).
In questa sezione viene descritto il filtraggio degli eventi per le origini di eventi Amazon MQ.
**Nota**
Le mappature delle sorgenti degli eventi di Amazon MQ supportano solo il filtraggio sulla chiave. `data`
**Topics**
+ [
## Nozioni di base sul filtraggio degli eventi Amazon MQ
](#filtering-AMQ)
## Nozioni di base sul filtraggio degli eventi Amazon MQ
Supponiamo che la coda di messaggi di Amazon MQ contenga messaggi in formato JSON valido o come stringhe semplici. Un record di esempio sarebbe simile al seguente, con i dati convertiti in una stringa codificata Base64 nel campo `data`.
------
#### [ ActiveMQ ]
```
{
"messageID": "ID:b-9bcfa592-423a-4942-879d-eb284b418fc8-1---mq---us-east-2.amazonaws.com.rproxy.goskope.com-37557-1234520418293-4:1:1:1:1",
"messageType": "jms/text-message",
"deliveryMode": 1,
"replyTo": null,
"type": null,
"expiration": "60000",
"priority": 1,
"correlationId": "myJMSCoID",
"redelivered": false,
"destination": {
"physicalName": "testQueue"
},
"data":"QUJDOkFBQUE=",
"timestamp": 1598827811958,
"brokerInTime": 1598827811958,
"brokerOutTime": 1598827811959,
"properties": {
"index": "1",
"doAlarm": "false",
"myCustomProperty": "value"
}
}
```
------
#### [ RabbitMQ ]
```
{
"basicProperties": {
"contentType": "text/plain",
"contentEncoding": null,
"headers": {
"header1": {
"bytes": [
118,
97,
108,
117,
101,
49
]
},
"header2": {
"bytes": [
118,
97,
108,
117,
101,
50
]
},
"numberInHeader": 10
},
"deliveryMode": 1,
"priority": 34,
"correlationId": null,
"replyTo": null,
"expiration": "60000",
"messageId": null,
"timestamp": "Jan 1, 1970, 12:33:41 AM",
"type": null,
"userId": "AIDACKCEVSQ6C2EXAMPLE",
"appId": null,
"clusterId": null,
"bodySize": 80
},
"redelivered": false,
"data": "eyJ0aW1lb3V0IjowLCJkYXRhIjoiQ1pybWYwR3c4T3Y0YnFMUXhENEUifQ=="
}
```
------
Per i broker sia Active MQ sia Rabbit MQ, puoi utilizzare il filtraggio degli eventi per filtrare i record utilizzando la chiave `data`. Supponiamo che la coda Amazon MQ contenga messaggi nel formato JSON seguente.
```
{
"timeout": 0,
"IPAddress": "203.0.113.254"
}
```
Per filtrare solo i record in cui il campo `timeout` è maggiore di 0, l'oggetto `FilterCriteria` sarebbe il seguente.
```
{
"Filters": [
{
"Pattern": "{ \"data\" : { \"timeout\" : [ { \"numeric\": [ \">\", 0] } } ] } }"
}
]
}
```
Per una maggiore chiarezza, ecco il valore del `Pattern` del filtro espanso in JSON semplice.
```
{
"data": {
"timeout": [ { "numeric": [ ">", 0 ] } ]
}
}
```
Puoi aggiungere il filtro utilizzando la console, la AWS CLI o un modello AWS SAM.
------
#### [ Console ]
Per aggiungere questo filtro utilizzando la console, segui le istruzioni riportate in [Collegamento dei criteri di filtro a una mappatura dell'origine evento (console)](invocation-eventfiltering.md#filtering-console) e inserisci la seguente stringa per i **criteri di filtraggio**.
```
{ "data" : { "timeout" : [ { "numeric": [ ">", 0 ] } ] } }
```
------
#### [ AWS CLI ]
Per creare una nuova mappatura dell'origine degli eventi con questi criteri di filtraggio utilizzando l'AWS Command Line Interface (AWS CLI), esegui il comando seguente.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:mq:us-east-2:123456789012:broker:my-broker:b-8ac7cc01-5898-482d-be2f-a6b596050ea8 \
--filter-criteria '{"Filters": [{"Pattern": "{ \"data\" : { \"timeout\" : [ { \"numeric\": [ \">\", 0 ] } ] } }"}]}'
```
Per aggiungere questi criteri di filtraggio a una mappatura dell'origine degli eventi esistente, esegui il comando seguente.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"data\" : { \"timeout\" : [ { \"numeric\": [ \">\", 0 ] } ] } }"}]}'
```
Per aggiungere questi criteri di filtraggio a una mappatura dell'origine degli eventi esistente, esegui il comando seguente.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"data\" : { \"timeout\" : [ { \"numeric\": [ \">\", 0 ] } ] } }"}]}'
```
------
#### [ AWS SAM ]
Per aggiungere questo filtro utilizzando AWS SAM, aggiungi il seguente frammento al modello YAML dell'origine degli eventi.
```
FilterCriteria:
Filters:
- Pattern: '{ "data" : { "timeout" : [ { "numeric": [ ">", 0 ] } ] } }'
```
------
Con Amazon MQ, puoi anche filtrare i record in cui il messaggio è una stringa semplice. Supponiamo di voler elaborare solo i record in cui il messaggio inizia con "Risultato: ". L'oggetto `FilterCriteria` dovrebbe avere la struttura seguente.
```
{
"Filters": [
{
"Pattern": "{ \"data\" : [ { \"prefix\": \"Result: \" } ] }"
}
]
}
```
Per una maggiore chiarezza, ecco il valore del `Pattern` del filtro espanso in JSON semplice.
```
{
"data": [
{
"prefix": "Result: "
}
]
}
```
Puoi aggiungere il filtro utilizzando la console, la AWS CLI o un modello AWS SAM.
------
#### [ Console ]
Per aggiungere questo filtro utilizzando la console, segui le istruzioni riportate in [Collegamento dei criteri di filtro a una mappatura dell'origine evento (console)](invocation-eventfiltering.md#filtering-console) e inserisci la seguente stringa per i **criteri di filtraggio**.
```
{ "data" : [ { "prefix": "Result: " } ] }
```
------
#### [ AWS CLI ]
Per creare una nuova mappatura dell'origine degli eventi con questi criteri di filtraggio utilizzando l'AWS Command Line Interface (AWS CLI), esegui il comando seguente.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:mq:us-east-2:123456789012:broker:my-broker:b-8ac7cc01-5898-482d-be2f-a6b596050ea8 \
--filter-criteria '{"Filters": [{"Pattern": "{ \"data\" : [ { \"prefix\": \"Result: \" } ] }"}]}'
```
Per aggiungere questi criteri di filtraggio a una mappatura dell'origine degli eventi esistente, esegui il comando seguente.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"data\" : [ { \"prefix\": \"Result: \" } ] }"}]}'
```
------
#### [ AWS SAM ]
Per aggiungere questo filtro utilizzando AWS SAM, aggiungi il seguente frammento al modello YAML dell'origine degli eventi.
```
FilterCriteria:
Filters:
- Pattern: '{ "data" : [ { "prefix": "Result " } ] }'
```
------
I messaggi Amazon MQ devono essere stringhe codificate in UTF-8, semplici o in formato JSON. Questo perché Lambda decodifica gli array di byte Amazon MQ in UTF-8 prima di applicare i criteri di filtraggio. Se i messaggi utilizzano un'altra codifica, ad esempio UTF-16 o ASCII o se il formato del messaggio non corrisponde al formato `FilterCriteria`, Lambda elabora solo i filtri di metadati. La tabella seguente riepiloga il comportamento specifico:
| Formato messaggio in arrivo | Formato del modello di filtro per le proprietà di messaggi | Operazione risultante |
| --- | --- | --- |
| Stringa normale | Stringa normale | Filtri Lambda in base ai criteri di filtro. |
| Stringa normale | Nessun modello di filtro per le proprietà dei dati | Filtri Lambda (solo sulle altre proprietà dei metadati) in base ai criteri di filtro. |
| Stringa normale | JSON valido | Filtri Lambda (solo sulle altre proprietà dei metadati) in base ai criteri di filtro. |
| JSON valido | Stringa normale | Filtri Lambda (solo sulle altre proprietà dei metadati) in base ai criteri di filtro. |
| JSON valido | Nessun modello di filtro per le proprietà dei dati | Filtri Lambda (solo sulle altre proprietà dei metadati) in base ai criteri di filtro. |
| JSON valido | JSON valido | Filtri Lambda in base ai criteri di filtro. |
| Stringa codificata non UTF-8 | JSON, stringa semplice o nessun modello | Filtri Lambda (solo sulle altre proprietà dei metadati) in base ai criteri di filtro. |
# Risolvere i problemi relativi gli errori di mappatura dell'origine eventi di Amazon MQ
Quando una funzione Lambda rileva un errore irreversibile, il consumatore Amazon MQ arresta l'elaborazione dei record. Tutti gli altri consumatori possono continuare a elaborare, a condizione che non riscontrino lo stesso errore. Per determinare la causa potenziale di un consumatore fermato, controllare il campo `StateTransitionReason` nei dettagli di reso del `EventSourceMapping` per uno dei seguenti codici:
**`ESM_CONFIG_NOT_VALID`**
La configurazione della mappa dell'origine eventi non è valida.
**`EVENT_SOURCE_AUTHN_ERROR`**
Lambda non è riuscito ad autenticare l'origine eventi.
**`EVENT_SOURCE_AUTHZ_ERROR`**
Lambda non dispone delle autorizzazioni necessarie per accedere all'origine eventi.
**`FUNCTION_CONFIG_NOT_VALID`**
La configurazione della funzione non è valida.
I record non verranno elaborati anche se Lambda li scarta a causa delle loro dimensioni. Il limite di dimensioni per i record Lambda è di 6 MB. Per riconsegnare i messaggi in caso di errore di funzione, è possibile utilizzare una coda di messaggi non instradabili (coda DLQ). Per ulteriori informazioni, consultare [Message Redelivery and DLQ Handling](https://activemq.apache.org/message-redelivery-and-dlq-handling) sul sito Web Apache ActiveMQ e [Guida all'affidabilità](https://www.rabbitmq.com/reliability.html) sul sito Web RabbitMQ.
**Nota**
Lambda non supporta policy di riconsegna personalizzate. Lambda utilizza invece una policy con i valori predefiniti dalla pagina [Policy di riconsegna](https://activemq.apache.org/redelivery-policy) sul sito Web Apache ActiveMQ, con `maximumRedeliveries` impostato su 6.
# Utilizzo AWS Lambda con Amazon RDS
Puoi collegare una funzione Lambda a un database Amazon Relational Database Service (Amazon RDS) direttamente e attraverso un Server proxy per Amazon RDS. Le connessioni dirette sono utili in scenari semplici, mentre i server proxy sono consigliati per la produzione. Un proxy del database gestisce un pool di connessioni a database condivisi che consente alla funzione di raggiungere elevati livelli di simultaneità senza esaurire le connessioni al database.
Consigliamo di utilizzare il Server proxy per Amazon RDS per le funzioni Lambda che effettuano connessioni brevi e frequenti al database o aprono e chiudono numerose connessioni al database. Per ulteriori informazioni, consulta [Connessione automatica di una funzione Lambda e un'istanza DB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/lambda-rds-connect.html) nella Guida per gli sviluppatori di Amazon Relational Database Service.
**Suggerimento**
Per connettere rapidamente una funzione Lambda a un database Amazon RDS, puoi utilizzare la procedura guidata integrata nella console. Per aprire la procedura guidata, esegui queste operazioni:
Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
Seleziona la funzione a cui desideri connettere un database.
Nella scheda **Configurazione**, seleziona **Database RDS**.
Scegli **Connessione al database RDS**.
Dopo aver collegato la funzione a un database, scegli **Aggiungi proxy** se desideri creare un proxy.
## Configurazione della funzione per l'utilizzo con le risorse RDS
Nella console Lambda, puoi eseguire il provisioning, e configurare, delle istanze di database Amazon RDS e risorse proxy. Puoi farlo accedendo ai **database RDS** nella scheda **Configurazione**. In alternativa, puoi anche creare e configurare connessioni alle funzioni Lambda nella console Amazon RDS. Quando configuri un'istanza di database RDS da utilizzare con Lambda, tieni presente i seguenti criteri:
+ Per effettuare la connessione a un database, la funzione si deve trovare nello stesso Amazon VPC in cui viene eseguito il database.
+ Puoi utilizzare i database Amazon RDS con motori MySQL, MariaDB, PostgreSQL o Microsoft SQL Server.
+ Puoi anche utilizzare cluster Aurora DB con motori MySQL o PostgreSQL.
+ Devi fornire un segreto di Secrets Manager per l'autenticazione del database.
+ Un ruolo IAM deve fornire l'autorizzazione all'uso del segreto, mentre una policy di attendibilità deve consentire ad Amazon RDS di assumere il ruolo.
+ Il principale IAM che utilizza la console per configurare la risorsa Amazon RDS e connetterla alla tua funzione deve disporre delle seguenti autorizzazioni:
### Policy di autorizzazione di esempio
**Nota**
Le autorizzazioni del server proxy per Amazon RDS sono necessarie solo se configuri un server proxy per Amazon RDS per gestire un pool di connessioni al database.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateSecurityGroup",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:RevokeSecurityGroupEgress",
"ec2:CreateNetworkInterface",
"ec2:DeleteNetworkInterface",
"ec2:DescribeNetworkInterfaces"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"rds-db:connect",
"rds:CreateDBProxy",
"rds:CreateDBInstance",
"rds:CreateDBSubnetGroup",
"rds:DescribeDBClusters",
"rds:DescribeDBInstances",
"rds:DescribeDBSubnetGroups",
"rds:DescribeDBProxies",
"rds:DescribeDBProxyTargets",
"rds:DescribeDBProxyTargetGroups",
"rds:RegisterDBProxyTargets",
"rds:ModifyDBInstance",
"rds:ModifyDBProxy"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"lambda:CreateFunction",
"lambda:ListFunctions",
"lambda:UpdateFunctionConfiguration"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:CreateRole",
"iam:CreatePolicy"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetResourcePolicy",
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret",
"secretsmanager:ListSecretVersionIds",
"secretsmanager:CreateSecret"
],
"Resource": "*"
}
]
}
```
------
Amazon RDS addebita una tariffa oraria per i proxy in base alla dimensione dell'istanza di database, consulta [Prezzi di Server proxy per RDS](https://aws.amazon.com/rds/proxy/pricing/) per conoscere i dettagli. Per ulteriori informazioni sulle connessioni proxy in generale, consulta [Utilizzo di Server proxy per Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) nella Guida per l'utente di Amazon RDS.
### Requisiti SSL/TLS per le connessioni Amazon RDS
Per stabilire SSL/TLS connessioni sicure a un'istanza di database Amazon RDS, la funzione Lambda deve verificare l'identità del server di database utilizzando un certificato affidabile. Lambda gestisce questi certificati in modo diverso a seconda del tipo di pacchetto di implementazione:
+ [Archivi di file .zip](configuration-function-zip.md): la gestione dei certificati varia in base al runtime:
+ **Node.js 18 e versioni precedenti**: Lambda include automaticamente certificati CA e certificati RDS.
+ **Node.js 20 e versioni successive**: Lambda non carica più certificati CA aggiuntivi per impostazione predefinita. Impostare la variabile di ambiente `NODE_EXTRA_CA_CERTS` su `/var/runtime/ca-cert.pem`.
Potrebbero essere necessarie fino a 4 settimane prima che i nuovi Regioni AWS certificati Amazon RDS vengano aggiunti ai runtime gestiti Lambda.
+ Immagini dei [container: le immagini](images-create.md) AWS di base includono solo certificati CA. Se la tua funzione si connette a un'istanza del database Amazon RDS, devi includere i certificati appropriati nell'immagine container. Nel tuo Dockerfile, scarica il [pacchetto di certificati corrispondente al Regione AWS luogo in cui ospiti il](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html#UsingWithRDS.SSL.CertificatesDownload) database. Esempio:
```
RUN curl https://truststore.pki.rds.amazonaws.com/us-east-1/us-east-1-bundle.pem -o /us-east-1-bundle.pem
```
Questo comando scarica il bundle di certificati Amazon RDS e lo salva nel percorso assoluto `/us-east-1-bundle.pem` nella directory principale del container. Quando configuri la connessione del database nel codice della funzione, devi fare riferimento a questo percorso esatto. Esempio:
------
#### [ Node.js ]
La funzione `readFileSync` è necessaria perché i client del database Node.js necessitano del contenuto effettivo del certificato in memoria, non solo del percorso al file del certificato. Senza `readFileSync`, il client interpreta la stringa del percorso come contenuto del certificato, generando un errore di «certificato autofirmato nella catena di certificati».
**Example Configurazione della connessione Node.js per la funzione OCI**
```
import { readFileSync } from 'fs';
// ...
let connectionConfig = {
host: process.env.ProxyHostName,
user: process.env.DBUserName,
password: token,
database: process.env.DBName,
ssl: {
ca: readFileSync('/us-east-1-bundle.pem') // Load RDS certificate content from file into memory
}
};
```
------
#### [ Python ]
**Example Configurazione della connessione Python per la funzione OCI**
```
connection = pymysql.connect(
host=proxy_host_name,
user=db_username,
password=token,
db=db_name,
port=port,
ssl={'ca': '/us-east-1-bundle.pem'} #Path to the certificate in container
)
```
------
#### [ Java ]
Per le funzioni Java che utilizzano connessioni JDBC, la stringa di connessione deve includere:
+ `useSSL=true`
+ `requireSSL=true`
+ Un parametro `sslCA` che indica la posizione del certificato Amazon RDS nell'immagine container
**Example Stringa di connessione Java per la funzione OCI**
```
// Define connection string
String connectionString = String.format("jdbc:mysql://%s:%s/%s?useSSL=true&requireSSL=true&sslCA=/us-east-1-bundle.pem", // Path to the certificate in container
System.getenv("ProxyHostName"),
System.getenv("Port"),
System.getenv("DBName"));
```
------
#### [ .NET ]
**Example Stringa di connessione.NET per la connessione MySQL nella funzione OCI**
```
/// Build the Connection String with the Token
string connectionString = $"Server={Environment.GetEnvironmentVariable("RDS_ENDPOINT")};" +
$"Port={Environment.GetEnvironmentVariable("RDS_PORT")};" +
$"Uid={Environment.GetEnvironmentVariable("RDS_USERNAME")};" +
$"Pwd={authToken};" +
"SslMode=Required;" +
"SslCa=/us-east-1-bundle.pem"; // Path to the certificate in container
```
------
#### [ Go ]
Per le funzioni Go che utilizzano connessioni MySQL, carica il certificato Amazon RDS in un pool di certificati e registralo con il driver MySQL. La stringa di connessione deve quindi fare riferimento a questa configurazione utilizzando il parametro `tls`.
**Example Codice Go per la connessione MySQL nella funzione OCI**
```
import (
"crypto/tls"
"crypto/x509"
"os"
"github.com/go-sql-driver/mysql"
)
...
// Create certificate pool and register TLS config
rootCertPool := x509.NewCertPool()
pem, err := os.ReadFile("/us-east-1-bundle.pem") // Path to the certificate in container
if err != nil {
panic("failed to read certificate file: " + err.Error())
}
if ok := rootCertPool.AppendCertsFromPEM(pem); !ok {
panic("failed to append PEM")
}
mysql.RegisterTLSConfig("custom", &tls.Config{
RootCAs: rootCertPool,
})
dsn := fmt.Sprintf("%s:%s@tcp(%s)/%s?allowCleartextPasswords=true&tls=custom",
dbUser, authenticationToken, dbEndpoint, dbName,
)
```
------
#### [ Ruby ]
**Example Configurazione della connessione Ruby per la funzione OCI**
```
conn = Mysql2::Client.new(
host: endpoint,
username: user,
password: token,
port: port,
database: db_name,
sslca: '/us-east-1-bundle.pem', # Path to the certificate in container
sslverify: true
)
```
------
## Connessione a un database Amazon RDS in una funzione Lambda
Gli esempi di codice seguenti mostrano come implementare una funzione Lambda che si connette a un database Amazon RDS. La funzione effettua una semplice richiesta al database e restituisce il risultato.
**Nota**
Questi esempi di codice sono validi solo per i [pacchetti di implementazione .zip](configuration-function-zip.md). Se stai implementando la funzione utilizzando un'[immagine container,](images-create.md) devi specificare il file del certificato Amazon RDS nel codice della funzione, come spiegato nella [sezione precedente](#oci-certificate).
------
#### [ .NET ]
**SDK per .NET**
C'è di più su. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-connect-rds-iam).
Connessione a un database Amazon RDS in una funzione Lambda con .NET.
```
using System.Data;
using System.Text.Json;
using Amazon.Lambda.APIGatewayEvents;
using Amazon.Lambda.Core;
using MySql.Data.MySqlClient;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace aws_rds;
public class InputModel
{
public string key1 { get; set; }
public string key2 { get; set; }
}
public class Function
{
///
// Handles the Lambda function execution for connecting to RDS using IAM authentication.
///
/// The input event data passed to the Lambda function
/// The Lambda execution context that provides runtime information
/// A response object containing the execution result
public async Task FunctionHandler(APIGatewayProxyRequest request, ILambdaContext context)
{
// Sample Input: {"body": "{\"key1\":\"20\", \"key2\":\"25\"}"}
var input = JsonSerializer.Deserialize(request.Body);
/// Obtain authentication token
var authToken = RDSAuthTokenGenerator.GenerateAuthToken(
Environment.GetEnvironmentVariable("RDS_ENDPOINT"),
Convert.ToInt32(Environment.GetEnvironmentVariable("RDS_PORT")),
Environment.GetEnvironmentVariable("RDS_USERNAME")
);
/// Build the Connection String with the Token
string connectionString = $"Server={Environment.GetEnvironmentVariable("RDS_ENDPOINT")};" +
$"Port={Environment.GetEnvironmentVariable("RDS_PORT")};" +
$"Uid={Environment.GetEnvironmentVariable("RDS_USERNAME")};" +
$"Pwd={authToken};";
try
{
await using var connection = new MySqlConnection(connectionString);
await connection.OpenAsync();
const string sql = "SELECT @param1 + @param2 AS Sum";
await using var command = new MySqlCommand(sql, connection);
command.Parameters.AddWithValue("@param1", int.Parse(input.key1 ?? "0"));
command.Parameters.AddWithValue("@param2", int.Parse(input.key2 ?? "0"));
await using var reader = await command.ExecuteReaderAsync();
if (await reader.ReadAsync())
{
int result = reader.GetInt32("Sum");
//Sample Response: {"statusCode":200,"body":"{\"message\":\"The sum is: 45\"}","isBase64Encoded":false}
return new APIGatewayProxyResponse
{
StatusCode = 200,
Body = JsonSerializer.Serialize(new { message = $"The sum is: {result}" })
};
}
}
catch (Exception ex)
{
Console.WriteLine($"Error: {ex.Message}");
}
return new APIGatewayProxyResponse
{
StatusCode = 500,
Body = JsonSerializer.Serialize(new { error = "Internal server error" })
};
}
}
```
------
#### [ Go ]
**SDK per Go V2**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-connect-rds-iam).
Connessione a un database Amazon RDS in una funzione Lambda tramite Go.
```
/*
Golang v2 code here.
*/
package main
import (
"context"
"database/sql"
"encoding/json"
"fmt"
"os"
"github.com/aws/aws-lambda-go/lambda"
"github.com/aws/aws-sdk-go-v2/config"
"github.com/aws/aws-sdk-go-v2/feature/rds/auth"
_ "github.com/go-sql-driver/mysql"
)
type MyEvent struct {
Name string `json:"name"`
}
func HandleRequest(event *MyEvent) (map[string]interface{}, error) {
var dbName string = os.Getenv("DatabaseName")
var dbUser string = os.Getenv("DatabaseUser")
var dbHost string = os.Getenv("DBHost") // Add hostname without https
var dbPort int = os.Getenv("Port") // Add port number
var dbEndpoint string = fmt.Sprintf("%s:%d", dbHost, dbPort)
var region string = os.Getenv("AWS_REGION")
cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
panic("configuration error: " + err.Error())
}
authenticationToken, err := auth.BuildAuthToken(
context.TODO(), dbEndpoint, region, dbUser, cfg.Credentials)
if err != nil {
panic("failed to create authentication token: " + err.Error())
}
dsn := fmt.Sprintf("%s:%s@tcp(%s)/%s?tls=true&allowCleartextPasswords=true",
dbUser, authenticationToken, dbEndpoint, dbName,
)
db, err := sql.Open("mysql", dsn)
if err != nil {
panic(err)
}
defer db.Close()
var sum int
err = db.QueryRow("SELECT ?+? AS sum", 3, 2).Scan(&sum)
if err != nil {
panic(err)
}
s := fmt.Sprint(sum)
message := fmt.Sprintf("The selected sum is: %s", s)
messageBytes, err := json.Marshal(message)
if err != nil {
return nil, err
}
messageString := string(messageBytes)
return map[string]interface{}{
"statusCode": 200,
"headers": map[string]string{"Content-Type": "application/json"},
"body": messageString,
}, nil
}
func main() {
lambda.Start(HandleRequest)
}
```
------
#### [ Java ]
**SDK per Java 2.x**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-connect-rds-iam).
Connessione a un database Amazon RDS in una funzione Lambda tramite Java.
```
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyRequestEvent;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyResponseEvent;
import software.amazon.awssdk.auth.credentials.DefaultCredentialsProvider;
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.rdsdata.RdsDataClient;
import software.amazon.awssdk.services.rdsdata.model.ExecuteStatementRequest;
import software.amazon.awssdk.services.rdsdata.model.ExecuteStatementResponse;
import software.amazon.awssdk.services.rdsdata.model.Field;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
public class RdsLambdaHandler implements RequestHandler {
@Override
public APIGatewayProxyResponseEvent handleRequest(APIGatewayProxyRequestEvent event, Context context) {
APIGatewayProxyResponseEvent response = new APIGatewayProxyResponseEvent();
try {
// Obtain auth token
String token = createAuthToken();
// Define connection configuration
String connectionString = String.format("jdbc:mysql://%s:%s/%s?useSSL=true&requireSSL=true",
System.getenv("ProxyHostName"),
System.getenv("Port"),
System.getenv("DBName"));
// Establish a connection to the database
try (Connection connection = DriverManager.getConnection(connectionString, System.getenv("DBUserName"), token);
PreparedStatement statement = connection.prepareStatement("SELECT ? + ? AS sum")) {
statement.setInt(1, 3);
statement.setInt(2, 2);
try (ResultSet resultSet = statement.executeQuery()) {
if (resultSet.next()) {
int sum = resultSet.getInt("sum");
response.setStatusCode(200);
response.setBody("The selected sum is: " + sum);
}
}
}
} catch (Exception e) {
response.setStatusCode(500);
response.setBody("Error: " + e.getMessage());
}
return response;
}
private String createAuthToken() {
// Create RDS Data Service client
RdsDataClient rdsDataClient = RdsDataClient.builder()
.region(Region.of(System.getenv("AWS_REGION")))
.credentialsProvider(DefaultCredentialsProvider.create())
.build();
// Define authentication request
ExecuteStatementRequest request = ExecuteStatementRequest.builder()
.resourceArn(System.getenv("ProxyHostName"))
.secretArn(System.getenv("DBUserName"))
.database(System.getenv("DBName"))
.sql("SELECT 'RDS IAM Authentication'")
.build();
// Execute request and obtain authentication token
ExecuteStatementResponse response = rdsDataClient.executeStatement(request);
Field tokenField = response.records().get(0).get(0);
return tokenField.stringValue();
}
}
```
------
#### [ JavaScript ]
**SDK per JavaScript (v3)**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-connect-rds-iam).
Connessione a un database Amazon RDS in una funzione Lambda utilizzando. JavaScript
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
/*
Node.js code here.
*/
// ES6+ example
import { Signer } from "@aws-sdk/rds-signer";
import mysql from 'mysql2/promise';
async function createAuthToken() {
// Define connection authentication parameters
const dbinfo = {
hostname: process.env.ProxyHostName,
port: process.env.Port,
username: process.env.DBUserName,
region: process.env.AWS_REGION,
}
// Create RDS Signer object
const signer = new Signer(dbinfo);
// Request authorization token from RDS, specifying the username
const token = await signer.getAuthToken();
return token;
}
async function dbOps() {
// Obtain auth token
const token = await createAuthToken();
// Define connection configuration
let connectionConfig = {
host: process.env.ProxyHostName,
user: process.env.DBUserName,
password: token,
database: process.env.DBName,
ssl: 'Amazon RDS'
}
// Create the connection to the DB
const conn = await mysql.createConnection(connectionConfig);
// Obtain the result of the query
const [res,] = await conn.execute('select ?+? as sum', [3, 2]);
return res;
}
export const handler = async (event) => {
// Execute database flow
const result = await dbOps();
// Return result
return {
statusCode: 200,
body: JSON.stringify("The selected sum is: " + result[0].sum)
}
};
```
Connessione a un database Amazon RDS in una funzione Lambda utilizzando. TypeScript
```
import { Signer } from "@aws-sdk/rds-signer";
import mysql from 'mysql2/promise';
// RDS settings
// Using '!' (non-null assertion operator) to tell the TypeScript compiler that the DB settings are not null or undefined,
const proxy_host_name = process.env.PROXY_HOST_NAME!
const port = parseInt(process.env.PORT!)
const db_name = process.env.DB_NAME!
const db_user_name = process.env.DB_USER_NAME!
const aws_region = process.env.AWS_REGION!
async function createAuthToken(): Promise {
// Create RDS Signer object
const signer = new Signer({
hostname: proxy_host_name,
port: port,
region: aws_region,
username: db_user_name
});
// Request authorization token from RDS, specifying the username
const token = await signer.getAuthToken();
return token;
}
async function dbOps(): Promise {
try {
// Obtain auth token
const token = await createAuthToken();
const conn = await mysql.createConnection({
host: proxy_host_name,
user: db_user_name,
password: token,
database: db_name,
ssl: 'Amazon RDS' // Ensure you have the CA bundle for SSL connection
});
const [rows, fields] = await conn.execute('SELECT ? + ? AS sum', [3, 2]);
console.log('result:', rows);
return rows;
}
catch (err) {
console.log(err);
}
}
export const lambdaHandler = async (event: any): Promise<{ statusCode: number; body: string }> => {
// Execute database flow
const result = await dbOps();
// Return error is result is undefined
if (result == undefined)
return {
statusCode: 500,
body: JSON.stringify(`Error with connection to DB host`)
}
// Return result
return {
statusCode: 200,
body: JSON.stringify(`The selected sum is: ${result[0].sum}`)
};
};
```
------
#### [ PHP ]
**SDK per PHP**
C'è di più su. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-connect-rds-iam).
Connessione a un database Amazon RDS in una funzione Lambda tramite PHP.
```
logger = $logger;
}
private function getAuthToken(): string {
// Define connection authentication parameters
$dbConnection = [
'hostname' => getenv('DB_HOSTNAME'),
'port' => getenv('DB_PORT'),
'username' => getenv('DB_USERNAME'),
'region' => getenv('AWS_REGION'),
];
// Create RDS AuthTokenGenerator object
$generator = new AuthTokenGenerator(CredentialProvider::defaultProvider());
// Request authorization token from RDS, specifying the username
return $generator->createToken(
$dbConnection['hostname'] . ':' . $dbConnection['port'],
$dbConnection['region'],
$dbConnection['username']
);
}
private function getQueryResults() {
// Obtain auth token
$token = $this->getAuthToken();
// Define connection configuration
$connectionConfig = [
'host' => getenv('DB_HOSTNAME'),
'user' => getenv('DB_USERNAME'),
'password' => $token,
'database' => getenv('DB_NAME'),
];
// Create the connection to the DB
$conn = new PDO(
"mysql:host={$connectionConfig['host']};dbname={$connectionConfig['database']}",
$connectionConfig['user'],
$connectionConfig['password'],
[
PDO::MYSQL_ATTR_SSL_CA => '/path/to/rds-ca-2019-root.pem',
PDO::MYSQL_ATTR_SSL_VERIFY_SERVER_CERT => true,
]
);
// Obtain the result of the query
$stmt = $conn->prepare('SELECT ?+? AS sum');
$stmt->execute([3, 2]);
return $stmt->fetch(PDO::FETCH_ASSOC);
}
/**
* @param mixed $event
* @param Context $context
* @return array
*/
public function handle(mixed $event, Context $context): array
{
$this->logger->info("Processing query");
// Execute database flow
$result = $this->getQueryResults();
return [
'sum' => $result['sum']
];
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**SDK per Python (Boto3)**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-connect-rds-iam).
Connessione a un database Amazon RDS in una funzione Lambda tramite Python.
```
import json
import os
import boto3
import pymysql
# RDS settings
proxy_host_name = os.environ['PROXY_HOST_NAME']
port = int(os.environ['PORT'])
db_name = os.environ['DB_NAME']
db_user_name = os.environ['DB_USER_NAME']
aws_region = os.environ['AWS_REGION']
# Fetch RDS Auth Token
def get_auth_token():
client = boto3.client('rds')
token = client.generate_db_auth_token(
DBHostname=proxy_host_name,
Port=port
DBUsername=db_user_name
Region=aws_region
)
return token
def lambda_handler(event, context):
token = get_auth_token()
try:
connection = pymysql.connect(
host=proxy_host_name,
user=db_user_name,
password=token,
db=db_name,
port=port,
ssl={'ca': 'Amazon RDS'} # Ensure you have the CA bundle for SSL connection
)
with connection.cursor() as cursor:
cursor.execute('SELECT %s + %s AS sum', (3, 2))
result = cursor.fetchone()
return result
except Exception as e:
return (f"Error: {str(e)}") # Return an error message if an exception occurs
```
------
#### [ Ruby ]
**SDK per Ruby**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-connect-rds-iam).
Connessione a un database Amazon RDS in una funzione Lambda tramite Ruby.
```
# Ruby code here.
require 'aws-sdk-rds'
require 'json'
require 'mysql2'
def lambda_handler(event:, context:)
endpoint = ENV['DBEndpoint'] # Add the endpoint without https"
port = ENV['Port'] # 3306
user = ENV['DBUser']
region = ENV['DBRegion'] # 'us-east-1'
db_name = ENV['DBName']
credentials = Aws::Credentials.new(
ENV['AWS_ACCESS_KEY_ID'],
ENV['AWS_SECRET_ACCESS_KEY'],
ENV['AWS_SESSION_TOKEN']
)
rds_client = Aws::RDS::AuthTokenGenerator.new(
region: region,
credentials: credentials
)
token = rds_client.auth_token(
endpoint: endpoint+ ':' + port,
user_name: user,
region: region
)
begin
conn = Mysql2::Client.new(
host: endpoint,
username: user,
password: token,
port: port,
database: db_name,
sslca: '/var/task/global-bundle.pem',
sslverify: true,
enable_cleartext_plugin: true
)
a = 3
b = 2
result = conn.query("SELECT #{a} + #{b} AS sum").first['sum']
puts result
conn.close
{
statusCode: 200,
body: result.to_json
}
rescue => e
puts "Database connection failed due to #{e}"
end
end
```
------
#### [ Rust ]
**SDK per Rust**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-connect-rds-iam).
Connessione a un database Amazon RDS in una funzione Lambda tramite Rust.
```
use aws_config::BehaviorVersion;
use aws_credential_types::provider::ProvideCredentials;
use aws_sigv4::{
http_request::{sign, SignableBody, SignableRequest, SigningSettings},
sign::v4,
};
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
use serde_json::{json, Value};
use sqlx::postgres::PgConnectOptions;
use std::env;
use std::time::{Duration, SystemTime};
const RDS_CERTS: &[u8] = include_bytes!("global-bundle.pem");
async fn generate_rds_iam_token(
db_hostname: &str,
port: u16,
db_username: &str,
) -> Result {
let config = aws_config::load_defaults(BehaviorVersion::v2024_03_28()).await;
let credentials = config
.credentials_provider()
.expect("no credentials provider found")
.provide_credentials()
.await
.expect("unable to load credentials");
let identity = credentials.into();
let region = config.region().unwrap().to_string();
let mut signing_settings = SigningSettings::default();
signing_settings.expires_in = Some(Duration::from_secs(900));
signing_settings.signature_location = aws_sigv4::http_request::SignatureLocation::QueryParams;
let signing_params = v4::SigningParams::builder()
.identity(&identity)
.region(®ion)
.name("rds-db")
.time(SystemTime::now())
.settings(signing_settings)
.build()?;
let url = format!(
"https://{db_hostname}:{port}/?Action=connect&DBUser={db_user}",
db_hostname = db_hostname,
port = port,
db_user = db_username
);
let signable_request =
SignableRequest::new("GET", &url, std::iter::empty(), SignableBody::Bytes(&[]))
.expect("signable request");
let (signing_instructions, _signature) =
sign(signable_request, &signing_params.into())?.into_parts();
let mut url = url::Url::parse(&url).unwrap();
for (name, value) in signing_instructions.params() {
url.query_pairs_mut().append_pair(name, &value);
}
let response = url.to_string().split_off("https://".len());
Ok(response)
}
#[tokio::main]
async fn main() -> Result<(), Error> {
run(service_fn(handler)).await
}
async fn handler(_event: LambdaEvent) -> Result {
let db_host = env::var("DB_HOSTNAME").expect("DB_HOSTNAME must be set");
let db_port = env::var("DB_PORT")
.expect("DB_PORT must be set")
.parse::()
.expect("PORT must be a valid number");
let db_name = env::var("DB_NAME").expect("DB_NAME must be set");
let db_user_name = env::var("DB_USERNAME").expect("DB_USERNAME must be set");
let token = generate_rds_iam_token(&db_host, db_port, &db_user_name).await?;
let opts = PgConnectOptions::new()
.host(&db_host)
.port(db_port)
.username(&db_user_name)
.password(&token)
.database(&db_name)
.ssl_root_cert_from_pem(RDS_CERTS.to_vec())
.ssl_mode(sqlx::postgres::PgSslMode::Require);
let pool = sqlx::postgres::PgPoolOptions::new()
.connect_with(opts)
.await?;
let result: i32 = sqlx::query_scalar("SELECT $1 + $2")
.bind(3)
.bind(2)
.fetch_one(&pool)
.await?;
println!("Result: {:?}", result);
Ok(json!({
"statusCode": 200,
"content-type": "text/plain",
"body": format!("The selected sum is: {result}")
}))
}
```
------
## Elaborazione di notifiche di eventi da Amazon RDS
Puoi utilizzare Lambda per elaborare le notifiche degli eventi da un database Amazon RDS. Amazon RDS invia le notifiche a un argomento Amazon Simple Notification Service (Amazon SNS), che puoi configurare per richiamare una funzione Lambda. Amazon SNS avvolge il messaggio proveniente da Amazon RDS nel proprio documento evento e lo invia alla tua funzione.
Per ulteriori informazioni sulla configurazione di un database Amazon RDS per l'invio di notifiche, consulta [Utilizzo delle notifiche di eventi di Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html).
**Example Messaggio Amazon RDS in un evento Amazon SNS**
```
{
"Records": [
{
"EventVersion": "1.0",
"EventSubscriptionArn": "arn:aws:sns:us-east-2:123456789012:rds-lambda:21be56ed-a058-49f5-8c98-aedd2564c486",
"EventSource": "aws:sns",
"Sns": {
"SignatureVersion": "1",
"Timestamp": "2023-01-02T12:45:07.000Z",
"Signature": "tcc6faL2yUC6dgZdmrwh1Y4cGa/ebXEkAi6RibDsvpi+tE/1+82j...65r==",
"SigningCertUrl": "https://sns.us-east-2.amazonaws.com/SimpleNotificationService-ac565b8b1a6c5d002d285f9598aa1d9b.pem",
"MessageId": "95df01b4-ee98-5cb9-9903-4c221d41eb5e",
"Message": "{\"Event Source\":\"db-instance\",\"Event Time\":\"2023-01-02 12:45:06.000\",\"Identifier Link\":\"https://console.aws.amazon.com/rds/home?region=eu-west-1#dbinstance:id=dbinstanceid\",\"Source ID\":\"dbinstanceid\",\"Event ID\":\"http://docs.amazonwebservices.com/AmazonRDS/latest/UserGuide/USER_Events.html#RDS-EVENT-0002\",\"Event Message\":\"Finished DB Instance backup\"}",
"MessageAttributes": {},
"Type": "Notification",
"UnsubscribeUrl": "https://sns.us-east-2.amazonaws.com/?Action=Unsubscribe&SubscriptionArn=arn:aws:sns:us-east-2:123456789012:test-lambda:21be56ed-a058-49f5-8c98-aedd2564c486",
"TopicArn":"arn:aws:sns:us-east-2:123456789012:sns-lambda",
"Subject": "RDS Notification Message"
}
}
]
}
```
## Completare il tutorial su Lambda e Amazon RDS
+ [Uso di una funzione Lambda per accedere a un database Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-lambda-tutorial.html): seguendo la Guida per l'utente di Amazon RDS, impara come utilizzare una funzione Lambda per scrivere dati su un database Amazon RDS attraverso un Server proxy per Amazon RDS. La funzione Lambda leggerà i record da una coda di Amazon SQS e scriverà nuove voci in una tabella del database ogni volta che verrà aggiunto un messaggio.
# Seleziona un servizio di database per le tue applicazioni basate su Lambda
Molte applicazioni serverless devono archiviare e recuperare dati. AWS offre diverse opzioni di database che funzionano con le funzioni Lambda. Due delle scelte più popolari sono Amazon DynamoDB, un servizio di database NoSQL, e Amazon RDS, una soluzione di database relazionale tradizionale. Le sezioni seguenti spiegano le principali differenze tra questi servizi quando vengono utilizzati con Lambda e ti aiutano a selezionare il servizio di database giusto per la tua applicazione serverless.
Per saperne di più sugli altri servizi di database offerti da AWS e per comprenderne i casi d'uso e i compromessi in generale, consulta [Scelta di un AWS](https://docs.aws.amazon.com/decision-guides/latest/databases-on-aws-how-to-choose/databases-on-aws-how-to-choose.html) servizio di database. Tutti i servizi di database AWS sono compatibili con Lambda, ma non tutti possono essere adatti al tuo caso d'uso specifico.
## Quali sono le tue scelte quando selezioni un servizio di database con Lambda?
AWS offre diversi servizi di database. Per le applicazioni serverless, due delle scelte più popolari sono DynamoDB e Amazon RDS.
+ **DynamoDB** è un servizio di database NoSQL completamente gestito ottimizzato per le applicazioni serverless. Fornisce una scalabilità ottimale e prestazioni costanti in millisecondi su qualsiasi scala.
+ **Amazon RDS** è un servizio di database relazionale gestito che supporta più motori di database tra cui MySQL e PostgreSQL. Fornisce funzionalità SQL familiari con un'infrastruttura gestita.
## Suggerimenti se conosci già le tue esigenze
Se hai già le idee chiare sulle tue esigenze, ecco i nostri suggerimenti di base:
Consigliamo [DynamoDB](with-ddb.md) per applicazioni serverless che richiedono prestazioni costanti a bassa latenza, scalabilità automatica e non richiedono join o transazioni complesse. È particolarmente adatto per applicazioni basate su Lambda grazie alla sua natura serverless.
[Amazon RDS](services-rds.md) è la scelta migliore quando hai bisogno di query SQL complesse, join o se hai applicazioni esistenti che utilizzano database relazionali. Tuttavia, tieni presente che la connessione delle funzioni Lambda ad Amazon RDS richiede una configurazione aggiuntiva e può influire sui tempi di avvio a freddo.
## Aspetti da tenere in considerazione selezioni un servizio di database
Quando scegli tra DynamoDB e Amazon RDS per le tue applicazioni Lambda, considera questi fattori:
+ Gestione delle connessioni e avvii a freddo
+ Modelli di accesso ai dati
+ Complessità delle query
+ Requisiti di coerenza dei dati
+ Caratteristiche di scalabilità
+ Modello di costi
Se conosci questi fattori, puoi selezionare l'opzione che soddisfa al meglio le esigenze del caso d'uso specifico.
### Gestione delle connessioni e avvii a freddo
+ DynamoDB utilizza un'API HTTP per tutte le operazioni. Le funzioni Lambda possono effettuare richieste immediate senza mantenere le connessioni, con conseguente miglioramento delle prestazioni di avvio a freddo. Ogni richiesta viene autenticata utilizzando AWS credenziali senza sovraccarico di connessione.
+ Amazon RDS richiede la gestione dei pool di connessioni poiché utilizza connessioni di database tradizionali. Ciò può influire sugli avvii a freddo poiché le nuove istanze Lambda devono stabilire connessioni. Dovrai implementare strategie di pool di connessioni e potenzialmente utilizzare il [Server proxy per Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) per gestire le connessioni in modo efficace. Tieni presente che l'utilizzo del Server proxy per Amazon RDS comporta costi aggiuntivi.
### Modelli di accesso ai dati
+ DynamoDB funziona al meglio con modelli di accesso noti e design a tabella singola. È ideale per applicazioni Lambda che richiedono un accesso coerente a bassa latenza ai dati basato su chiavi primarie o indici secondari.
+ Amazon RDS offre flessibilità per query complesse e modelli di accesso in evoluzione. È più adatto quando le funzioni Lambda devono eseguire query uniche e personalizzate o join complessi su più tabelle.
### Complessità delle query
+ DynamoDB eccelle nelle operazioni semplici basate su chiavi e nei modelli di accesso predefiniti. Le query complesse devono essere progettate sulla base di strutture indicizzate e i join devono essere gestiti nel codice dell'applicazione.
+ Amazon RDS supporta query SQL complesse con join, sottoquery e aggregazioni. Questo può semplificare il codice della funzione Lambda quando sono necessarie operazioni complesse sui dati.
### Requisiti di coerenza dei dati
+ DynamoDB offre opzioni di coerenza sia finali che avanzate, con una forte coerenza disponibile per le letture di singoli elementi. Le transazioni sono supportate ma con alcune limitazioni.
+ Amazon RDS garantisce la conformità completa di atomicità, coerenza, isolamento e durabilità (ACID) e supporto per transazioni complesse. Se le tue funzioni Lambda richiedono transazioni complesse o una forte coerenza tra più record, Amazon RDS potrebbe essere più adatto.
### Caratteristiche di scalabilità
+ DynamoDB si adatta automaticamente al carico di lavoro. È in grado di gestire picchi improvvisi di traffico provenienti da funzioni Lambda senza pre-provisioning. Puoi utilizzare la modalità di capacità su richiesta per pagare solo per ciò che usi, in linea con il modello di scalabilità di Lambda.
+ Amazon RDS ha una capacità fissa in base alla dimensione dell'istanza scelta. Se più funzioni Lambda tentano di connettersi contemporaneamente, potresti superare la quota di connessione. È necessario gestire con attenzione i pool di connessioni e potenzialmente implementare la logica dei tentativi.
### Modello di costi
+ I prezzi di DynamoDB si allineano bene con le applicazioni serverless. Con la capacità su richiesta, paghi solo per le letture e le scritture effettive eseguite dalle tue funzioni Lambda. Non sono previsti addebiti per i tempi di inattività.
+ Amazon RDS addebita i costi per l'istanza in esecuzione indipendentemente dall'utilizzo. Questo può essere meno conveniente per i carichi di lavoro sporadici che possono essere tipici delle applicazioni serverless. Tuttavia, potrebbe essere più economico per carichi di lavoro ad alto throughput con un utilizzo costante.
## Nozioni di base sulle istanze del database da te scelte
Ora che hai letto i criteri per scegliere tra DynamoDB and Amazon RDS e le principali differenze tra questi, puoi selezionare l'opzione più adatta alle tue esigenze e utilizzare le seguenti risorse per iniziare a utilizzarla.
------
#### [ DynamoDB ]
**Iniziare a usare DynamoDB con le seguenti risorse**
+ Per un'introduzione al servizio DynamoDB, leggi [Cos'è DynamoDB?](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) nella *Guida per gli sviluppatori di Amazon DynamoDB*.
+ Segui il tutorial [Uso di Lambda con API Gateway](services-apigateway-tutorial.md) per vedere un esempio di utilizzo di una funzione Lambda per eseguire operazioni CRUD su una tabella DynamoDB in risposta a una richiesta API.
+ Leggi [Programming with DynamoDB e AWS SDKs](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Programming.html) la Amazon *DynamoDB Developer Guide per ulteriori informazioni su come accedere a DynamoDB* dall'interno della tua funzione Lambda utilizzando una delle. AWS SDKs
------
#### [ Amazon RDS ]
**Iniziare a usare Amazon RDS con le seguenti risorse**
+ Per un'introduzione al servizio Amazon RDS, leggi [Cos'è Amazon Relational Database Service (Amazon RDS)?](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) nella *Guida per l’utente di Amazon Relational Database Service*.
+ Segui il tutorial [Uso di una funzione Lambda per accedere a un database Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-lambda-tutorial.html) nella *Guida per l’utente di Amazon Relational Database Service*.
+ Per ulteriori informazioni sull'uso di Lambda con Amazon RDS, consulta [Utilizzo AWS Lambda con Amazon RDS](services-rds.md).
------
# Elaborare le notifiche di eventi Amazon S3 con Lambda
È possibile utilizzare Lambda per elaborare le [notifiche degli eventi](https://docs.aws.amazon.com/AmazonS3/latest/userguide/NotificationHowTo.html) da Amazon Simple Storage Service. Amazon S3 può inviare un evento a una funzione Lambda quando un oggetto viene creato o eliminato. È possibile configurare le impostazioni di notifica su un bucket e concedere ad Amazon S3 l'autorizzazione a invocare una funzione sulla policy di autorizzazione basata sulle risorse della funzione.
**avvertimento**
Se la funzione Lambda utilizza lo stesso bucket che la attiva, potrebbe causare l'esecuzione della funzione in loop. Ad esempio, se il bucket attiva una funzione ogni volta che un oggetto viene caricato e la funzione carica un oggetto nel bucket, allora la funzione indirettamente lo attiva. Per evitare questo, utilizzare due bucket, oppure configurare il trigger in modo che venga applicato solo a un prefisso utilizzato per gli oggetti in entrata.
Amazon S3 richiama la funzione [in modo asincrono](invocation-async.md) con un evento che contiene dettagli sull'oggetto. L'esempio seguente mostra un evento che Amazon S3 ha inviato quando un pacchetto di distribuzione è stato caricato su Amazon S3.
**Example Evento di notifica Amazon S3**
```
{
"Records": [
{
"eventVersion": "2.1",
"eventSource": "aws:s3",
"awsRegion": "us-east-2",
"eventTime": "2019-09-03T19:37:27.192Z",
"eventName": "ObjectCreated:Put",
"userIdentity": {
"principalId": "AWS:AIDAINPONIXQXHT3IKHL2"
},
"requestParameters": {
"sourceIPAddress": "205.255.255.255"
},
"responseElements": {
"x-amz-request-id": "D82B88E5F771F645",
"x-amz-id-2": "vlR7PnpV2Ce81l0PRw6jlUpck7Jo5ZsQjryTjKlc5aLWGVHPZLj5NeC6qMa0emYBDXOo6QBU0Wo="
},
"s3": {
"s3SchemaVersion": "1.0",
"configurationId": "828aa6fc-f7b5-4305-8584-487c791949c1",
"bucket": {
"name": "amzn-s3-demo-bucket",
"ownerIdentity": {
"principalId": "A3I5XTEXAMAI3E"
},
"arn": "arn:aws:s3:::lambda-artifacts-deafc19498e3f2df"
},
"object": {
"key": "b21b84d653bb07b05b1e6b33684dc11b",
"size": 1305107,
"eTag": "b21b84d653bb07b05b1e6b33684dc11b",
"sequencer": "0C0F6F405D6ED209E1"
}
}
}
]
}
```
Per richiamare la funzione, Amazon S3 necessita dell'autorizzazione dalla [policy basata su risorse](access-control-resource-based.md) della funzione. Quando si configura un trigger Amazon S3 nella console Lambda, la console modifica la policy basata su risorse per consentire ad Amazon S3 di richiamare la funzione se il nome del bucket e l'ID account corrispondono. Se si configura la notifica in Amazon S3, si utilizza l'API Lambda per aggiornare la policy. È inoltre possibile utilizzare l'API Lambda per concedere l'autorizzazione a un altro account o limitare l'autorizzazione a un alias designato.
[Se la tua funzione utilizza l' AWS SDK per gestire le risorse Amazon S3, necessita anche delle autorizzazioni Amazon S3 nel suo ruolo di esecuzione.](lambda-intro-execution-role.md)
**Topics**
+ [
# Tutorial: uso di un trigger Amazon S3 per richiamare una funzione Lambda
](with-s3-example.md)
+ [
# Tutorial: uso di un trigger Amazon S3 per creare immagini in miniatura
](with-s3-tutorial.md)
# Tutorial: uso di un trigger Amazon S3 per richiamare una funzione Lambda
In questo tutorial si utilizzerà la console per creare una funzione Lambda e configurare un trigger per un bucket Amazon Simple Storage Service (Amazon S3). Ogni volta che aggiungi un oggetto al tuo bucket Amazon S3, la funzione viene eseguita e invia il tipo di oggetto in Amazon Logs. CloudWatch
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-s3-example/s3_tut_config.png)
Questo tutorial dimostra come:
1. Crea un bucket Amazon S3.
1. Crea una funzione Lambda che restituisce il tipo di oggetto in un bucket Amazon S3.
1. Configura un trigger Lambda che richiami la tua funzione quando gli oggetti vengono caricati nel bucket.
1. Prova la tua funzione, prima con un evento fittizio e poi usando il trigger.
Completando questi passaggi, imparerai come configurare una funzione Lambda da eseguire ogni volta che vengono aggiunti o eliminati oggetti da un bucket Amazon S3. Puoi completare questo tutorial soltanto dalla Console di gestione AWS.
## Crea un bucket Amazon S3
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-s3-example/s3trigger_tut_steps1.png)
**Come creare un bucket Amazon S3.**
1. Apri la [console Amazon S3](https://console.aws.amazon.com/s3) e seleziona la pagina **Bucket per uso generico**.
1. Seleziona quello più Regione AWS vicino alla tua posizione geografica. Puoi modificare la regione utilizzando l'elenco a discesa nella parte superiore dello schermo. Più avanti nel tutorial, è necessario creare la funzione Lambda nella stessa regione.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/console_region_select.png)
1. Scegliere **Create bucket (Crea bucket)**.
1. In **General configuration (Configurazione generale)**, eseguire le operazioni seguenti:
1. Per **Tipo di secchio**, assicurati che sia selezionata l'**opzione Uso generale**.
1. Per **Nome del bucket**, inserisci un nome univoco globale che soddisfi le [regole di denominazione dei bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html) di Amazon S3. I nomi dei bucket possono contenere solo lettere minuscole, numeri, punti (.) e trattini (-).
1. Lascia tutte le altre opzioni impostate sui valori predefiniti e scegli **Crea bucket**.
## Caricamento di un oggetto di test in un bucket
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-s3-example/s3trigger_tut_steps2.png)
**Caricamento di un oggetto di test**
1. Apri la pagina [Bucket](https://console.aws.amazon.com/s3/buckets) della console Amazon S3 e scegli il bucket che hai creato durante il passaggio precedente.
1. Scegli **Carica**.
1. Scegli **Aggiungi file** e seleziona l'oggetto da caricare. È possibile selezionare qualsiasi file (ad esempio, `HappyFace.jpg`).
1. Seleziona **Apri**, quindi **Carica**.
Più avanti nel tutorial, testerai la funzione Lambda utilizzando questo oggetto.
## Creazione di una policy di autorizzazione
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-s3-example/s3trigger_tut_steps3.png)
Crea una politica di autorizzazioni che consenta a Lambda di ottenere oggetti da un bucket Amazon S3 e di scriverli su Amazon Logs. CloudWatch
**Come creare la policy**
1. Apri la pagina [Policies (Policy)](https://console.aws.amazon.com/iam/home#/policies) nella console IAM.
1. Scegli **Crea policy**.
1. Scegliere la scheda **JSON** e quindi incollare la seguente policy personalizzata nell'editor JSON.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:PutLogEvents",
"logs:CreateLogGroup",
"logs:CreateLogStream"
],
"Resource": "arn:aws:logs:*:*:*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": "arn:aws:s3:::*/*"
}
]
}
```
------
1. Scegliere **Next: Tags (Successivo: Tag)**.
1. Scegliere **Next:Review (Successivo: Rivedi)**.
1. In **Rivedi policy**, per **Nome** della policy inserisci **s3-trigger-tutorial**.
1. Scegli **Crea policy**.
## Creazione di un ruolo di esecuzione
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-s3-example/s3trigger_tut_steps4.png)
Un [ruolo di esecuzione](lambda-intro-execution-role.md) è un ruolo AWS Identity and Access Management (IAM) che concede a una funzione Lambda l'autorizzazione all' Servizi AWS accesso e alle risorse. In questa fase, creare un ruolo di esecuzione utilizzando la policy di autorizzazioni creata nel passaggio precedente.
**Creazione di un ruolo di esecuzione e collegamento di una policy di autorizzazione personalizzata**
1. Aprire la [pagina Roles (Ruoli)](https://console.aws.amazon.com/iam/home#/roles) della console IAM.
1. Scegli **Crea ruolo**.
1. Per il tipo di entità attendibile, scegli **Servizio AWS **, quindi per il caso d'uso seleziona **Lambda**.
1. Scegli **Next (Successivo)**.
1. Nella casella di ricerca delle policy, immettere **s3-trigger-tutorial**.
1. Nei risultati della ricerca, seleziona la policy creata (`s3-trigger-tutorial`), quindi scegli **Next** (Successivo).
1. In **Role details** (Dettagli del ruolo), per **Role name** (Nome del ruolo), specifica **lambda-s3-trigger-role**, quindi scegli **Create role** (Crea ruolo).
## Creazione della funzione Lambda
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-s3-example/s3trigger_tut_steps5.png)
Crea una funzione Lambda nella console usando il runtime Python 3.14.
**Creazione della funzione Lambda**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Assicurati di lavorare nello stesso bucket in Regione AWS cui hai creato il tuo bucket Amazon S3. Puoi modificare la regione utilizzando l'elenco a discesa nella parte superiore dello schermo.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/console_region_select.png)
1. Scegli **Crea funzione**.
1. Scegli **Crea da zero**.
1. In **Basic information (Informazioni di base)** eseguire queste operazioni:
1. Nel campo **Nome funzione**, inserisci `s3-trigger-tutorial`.
1. Per **Runtime**, scegli **Python 3.14**.
1. In **Architecture** (Architettura), scegli **x86\$164**.
1. Nella scheda **Modifica ruolo di esecuzione predefinito**, effettua le seguenti operazioni:
1. Espandi la scheda, quindi scegli **Utilizza un ruolo esistente**.
1. Seleziona il `lambda-s3-trigger-role` che hai creato in precedenza.
1. Scegli **Crea funzione**.
## Implementazione del codice della funzione
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-s3-example/s3trigger_tut_steps6.png)
Questo tutorial utilizza il runtime di Python 3.14, ma abbiamo anche fornito file di codice di esempio per altri runtime. Per visualizzare il codice per il runtime che ti interessa, seleziona la scheda corrispondente nella casella seguente.
La funzione Lambda recupera il nome della chiave dell'oggetto caricato e il nome del bucket dal parametro `event` che riceve da Amazon S3. La funzione utilizza quindi il metodo [get\$1object](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/s3/client/get_object.html) di AWS SDK per Python (Boto3) per recuperare i metadati dell'oggetto, incluso il tipo di contenuto (tipo MIME) dell'oggetto caricato.
**Implementazione del codice della funzione**
1. Scegli la scheda **Python** nella casella seguente e copia il codice.
------
#### [ .NET ]
**SDK per .NET**
C'è altro su. GitHub Trova l'esempio completo e scopri come eseguire la configurazione e l'esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-s3-to-lambda).
Utilizzo di un evento S3 con Lambda tramite .NET.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using System.Threading.Tasks;
using Amazon.Lambda.Core;
using Amazon.S3;
using System;
using Amazon.Lambda.S3Events;
using System.Web;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace S3Integration
{
public class Function
{
private static AmazonS3Client _s3Client;
public Function() : this(null)
{
}
internal Function(AmazonS3Client s3Client)
{
_s3Client = s3Client ?? new AmazonS3Client();
}
public async Task Handler(S3Event evt, ILambdaContext context)
{
try
{
if (evt.Records.Count <= 0)
{
context.Logger.LogLine("Empty S3 Event received");
return string.Empty;
}
var bucket = evt.Records[0].S3.Bucket.Name;
var key = HttpUtility.UrlDecode(evt.Records[0].S3.Object.Key);
context.Logger.LogLine($"Request is for {bucket} and {key}");
var objectResult = await _s3Client.GetObjectAsync(bucket, key);
context.Logger.LogLine($"Returning {objectResult.Key}");
return objectResult.Key;
}
catch (Exception e)
{
context.Logger.LogLine($"Error processing request - {e.Message}");
return string.Empty;
}
}
}
}
```
------
#### [ Go ]
**SDK per Go V2**
C'è dell'altro GitHub. Trova l'esempio completo e scopri come eseguire la configurazione e l'esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-s3-to-lambda).
Utilizzo di un evento S3 con Lambda tramite Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package main
import (
"context"
"log"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
"github.com/aws/aws-sdk-go-v2/config"
"github.com/aws/aws-sdk-go-v2/service/s3"
)
func handler(ctx context.Context, s3Event events.S3Event) error {
sdkConfig, err := config.LoadDefaultConfig(ctx)
if err != nil {
log.Printf("failed to load default config: %s", err)
return err
}
s3Client := s3.NewFromConfig(sdkConfig)
for _, record := range s3Event.Records {
bucket := record.S3.Bucket.Name
key := record.S3.Object.URLDecodedKey
headOutput, err := s3Client.HeadObject(ctx, &s3.HeadObjectInput{
Bucket: &bucket,
Key: &key,
})
if err != nil {
log.Printf("error getting head of object %s/%s: %s", bucket, key, err)
return err
}
log.Printf("successfully retrieved %s/%s of type %s", bucket, key, *headOutput.ContentType)
}
return nil
}
func main() {
lambda.Start(handler)
}
```
------
#### [ Java ]
**SDK per Java 2.x**
C'è dell'altro GitHub. Trova l'esempio completo e scopri come eseguire la configurazione e l'esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-s3-to-lambda).
Utilizzo di un evento S3 con Lambda tramite Java.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package example;
import software.amazon.awssdk.services.s3.model.HeadObjectRequest;
import software.amazon.awssdk.services.s3.model.HeadObjectResponse;
import software.amazon.awssdk.services.s3.S3Client;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.S3Event;
import com.amazonaws.services.lambda.runtime.events.models.s3.S3EventNotification.S3EventNotificationRecord;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class Handler implements RequestHandler {
private static final Logger logger = LoggerFactory.getLogger(Handler.class);
@Override
public String handleRequest(S3Event s3event, Context context) {
try {
S3EventNotificationRecord record = s3event.getRecords().get(0);
String srcBucket = record.getS3().getBucket().getName();
String srcKey = record.getS3().getObject().getUrlDecodedKey();
S3Client s3Client = S3Client.builder().build();
HeadObjectResponse headObject = getHeadObject(s3Client, srcBucket, srcKey);
logger.info("Successfully retrieved " + srcBucket + "/" + srcKey + " of type " + headObject.contentType());
return "Ok";
} catch (Exception e) {
throw new RuntimeException(e);
}
}
private HeadObjectResponse getHeadObject(S3Client s3Client, String bucket, String key) {
HeadObjectRequest headObjectRequest = HeadObjectRequest.builder()
.bucket(bucket)
.key(key)
.build();
return s3Client.headObject(headObjectRequest);
}
}
```
------
#### [ JavaScript ]
**SDK per JavaScript (v3)**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-s3-to-lambda).
Consumo di un evento S3 con JavaScript Lambda utilizzando.
```
import { S3Client, HeadObjectCommand } from "@aws-sdk/client-s3";
const client = new S3Client();
export const handler = async (event, context) => {
// Get the object from the event and show its content type
const bucket = event.Records[0].s3.bucket.name;
const key = decodeURIComponent(event.Records[0].s3.object.key.replace(/\+/g, ' '));
try {
const { ContentType } = await client.send(new HeadObjectCommand({
Bucket: bucket,
Key: key,
}));
console.log('CONTENT TYPE:', ContentType);
return ContentType;
} catch (err) {
console.log(err);
const message = `Error getting object ${key} from bucket ${bucket}. Make sure they exist and your bucket is in the same region as this function.`;
console.log(message);
throw new Error(message);
}
};
```
Consumo di un evento S3 con TypeScript Lambda utilizzando.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import { S3Event } from 'aws-lambda';
import { S3Client, HeadObjectCommand } from '@aws-sdk/client-s3';
const s3 = new S3Client({ region: process.env.AWS_REGION });
export const handler = async (event: S3Event): Promise => {
// Get the object from the event and show its content type
const bucket = event.Records[0].s3.bucket.name;
const key = decodeURIComponent(event.Records[0].s3.object.key.replace(/\+/g, ' '));
const params = {
Bucket: bucket,
Key: key,
};
try {
const { ContentType } = await s3.send(new HeadObjectCommand(params));
console.log('CONTENT TYPE:', ContentType);
return ContentType;
} catch (err) {
console.log(err);
const message = `Error getting object ${key} from bucket ${bucket}. Make sure they exist and your bucket is in the same region as this function.`;
console.log(message);
throw new Error(message);
}
};
```
------
#### [ PHP ]
**SDK per PHP**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-s3-to-lambda).
Utilizzo di un evento S3 con Lambda tramite PHP.
```
logger = $logger;
}
public function handleS3(S3Event $event, Context $context) : void
{
$this->logger->info("Processing S3 records");
// Get the object from the event and show its content type
$records = $event->getRecords();
foreach ($records as $record)
{
$bucket = $record->getBucket()->getName();
$key = urldecode($record->getObject()->getKey());
try {
$fileSize = urldecode($record->getObject()->getSize());
echo "File Size: " . $fileSize . "\n";
// TODO: Implement your custom processing logic here
} catch (Exception $e) {
echo $e->getMessage() . "\n";
echo 'Error getting object ' . $key . ' from bucket ' . $bucket . '. Make sure they exist and your bucket is in the same region as this function.' . "\n";
throw $e;
}
}
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**SDK per Python (Boto3)**
C'è dell'altro GitHub. Trova l'esempio completo e scopri come eseguire la configurazione e l'esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-s3-to-lambda).
Utilizzo di un evento S3 con Lambda tramite Python.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
import json
import urllib.parse
import boto3
print('Loading function')
s3 = boto3.client('s3')
def lambda_handler(event, context):
#print("Received event: " + json.dumps(event, indent=2))
# Get the object from the event and show its content type
bucket = event['Records'][0]['s3']['bucket']['name']
key = urllib.parse.unquote_plus(event['Records'][0]['s3']['object']['key'], encoding='utf-8')
try:
response = s3.get_object(Bucket=bucket, Key=key)
print("CONTENT TYPE: " + response['ContentType'])
return response['ContentType']
except Exception as e:
print(e)
print('Error getting object {} from bucket {}. Make sure they exist and your bucket is in the same region as this function.'.format(key, bucket))
raise e
```
------
#### [ Ruby ]
**SDK per Ruby**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-s3-to-lambda).
Utilizzo di un evento S3 con Lambda tramite Ruby.
```
require 'json'
require 'uri'
require 'aws-sdk'
puts 'Loading function'
def lambda_handler(event:, context:)
s3 = Aws::S3::Client.new(region: 'region') # Your AWS region
# puts "Received event: #{JSON.dump(event)}"
# Get the object from the event and show its content type
bucket = event['Records'][0]['s3']['bucket']['name']
key = URI.decode_www_form_component(event['Records'][0]['s3']['object']['key'], Encoding::UTF_8)
begin
response = s3.get_object(bucket: bucket, key: key)
puts "CONTENT TYPE: #{response.content_type}"
return response.content_type
rescue StandardError => e
puts e.message
puts "Error getting object #{key} from bucket #{bucket}. Make sure they exist and your bucket is in the same region as this function."
raise e
end
end
```
------
#### [ Rust ]
**SDK per Rust**
C'è altro da fare. GitHub Trova l'esempio completo e scopri come eseguire la configurazione e l'esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-s3-to-lambda).
Utilizzo di un evento S3 con Lambda tramite Rust.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
use aws_lambda_events::event::s3::S3Event;
use aws_sdk_s3::{Client};
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
/// Main function
#[tokio::main]
async fn main() -> Result<(), Error> {
tracing_subscriber::fmt()
.with_max_level(tracing::Level::INFO)
.with_target(false)
.without_time()
.init();
// Initialize the AWS SDK for Rust
let config = aws_config::load_from_env().await;
let s3_client = Client::new(&config);
let res = run(service_fn(|request: LambdaEvent| {
function_handler(&s3_client, request)
})).await;
res
}
async fn function_handler(
s3_client: &Client,
evt: LambdaEvent
) -> Result<(), Error> {
tracing::info!(records = ?evt.payload.records.len(), "Received request from SQS");
if evt.payload.records.len() == 0 {
tracing::info!("Empty S3 event received");
}
let bucket = evt.payload.records[0].s3.bucket.name.as_ref().expect("Bucket name to exist");
let key = evt.payload.records[0].s3.object.key.as_ref().expect("Object key to exist");
tracing::info!("Request is for {} and object {}", bucket, key);
let s3_get_object_result = s3_client
.get_object()
.bucket(bucket)
.key(key)
.send()
.await;
match s3_get_object_result {
Ok(_) => tracing::info!("S3 Get Object success, the s3GetObjectResult contains a 'body' property of type ByteStream"),
Err(_) => tracing::info!("Failure with S3 Get Object request")
}
Ok(())
}
```
------
1. Nel riquadro **Codice sorgente** della console Lambda, incolla il codice nell'editor di codice, sostituendo il codice creato da Lambda.
1. Nella sezione **DEPLOY**, scegli **Implementa** per aggiornare il codice della tua funzione:
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/getting-started-tutorial/deploy-console.png)
## Creazione del trigger Amazon S3
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-s3-example/s3trigger_tut_steps7.png)
**Creazione del trigger Amazon S3**
1. Nel riquadro **Panoramica della funzione**, scegli **Aggiungi trigger**.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/overview-trigger.png)
1. Seleziona **S3**.
1. In **Bucket**, seleziona il bucket che hai creato in precedenza nel tutorial.
1. In **Tipi di eventi**, verifica che sia selezionata l'opzione **Tutti gli eventi di creazione di oggetti**.
1. In **Invocazione ricorsiva**, seleziona la casella di controllo per confermare che non è consigliabile utilizzare lo stesso bucket Amazon S3 per input e output.
1. Scegliere **Aggiungi**.
**Nota**
Quando crei un trigger Amazon S3 per una funzione Lambda utilizzando la console Lambda, Amazon S3 configura una [notifica degli eventi](https://docs.aws.amazon.com/AmazonS3/latest/userguide/EventNotifications.html) sul bucket specificato. Prima di configurare questa notifica di evento, Amazon S3 esegue una serie di controlli per confermare che la destinazione dell'evento esista e disponga delle policy IAM richieste. Amazon S3 esegue questi test anche su qualsiasi altra notifica di eventi configurata per quel bucket.
A causa di questo controllo, se il bucket ha precedentemente configurato destinazioni di eventi per risorse che non esistono più o per risorse che non dispongono delle policy di autorizzazione richieste, Amazon S3 non sarà in grado di creare la nuova notifica di evento. Verrà visualizzato il seguente messaggio di errore che indica che non è stato possibile creare il trigger:
```
An error occurred when creating the trigger: Unable to validate the following destination configurations.
```
Puoi visualizzare questo errore se in precedenza hai configurato un trigger per un'altra funzione Lambda utilizzando lo stesso bucket e da allora hai eliminato la funzione o modificato le sue policy di autorizzazioni.
## Test di una funzione Lambda con un evento fittizio
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-s3-example/s3trigger_tut_steps8.png)
**Test della funzione Lambda con un evento fittizio**
1. Nella pagina della console Lambda della funzione, seleziona la scheda **Test**.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/test-tab.png)
1. Per **Event name (Nome evento)** immettere `MyTestEvent`.
1. Nella sezione **JSON dell'evento**, incolla il seguente evento di test. Assicurati di sostituire i seguenti valori:
+ Sostituisci `us-east-1` con la regione in cui è stato creato il bucket Amazon S3.
+ Sostituisci entrambe le istanze di `amzn-s3-demo-bucket` con il nome del bucket Amazon S3.
+ Sostituisci `test%2FKey` con il nome dell'oggetto di test che hai caricato in precedenza nel tuo bucket (ad esempio, `HappyFace.jpg`).
```
{
"Records": [
{
"eventVersion": "2.0",
"eventSource": "aws:s3",
"awsRegion": "us-east-1",
"eventTime": "1970-01-01T00:00:00.000Z",
"eventName": "ObjectCreated:Put",
"userIdentity": {
"principalId": "EXAMPLE"
},
"requestParameters": {
"sourceIPAddress": "127.0.0.1"
},
"responseElements": {
"x-amz-request-id": "EXAMPLE123456789",
"x-amz-id-2": "EXAMPLE123/5678abcdefghijklambdaisawesome/mnopqrstuvwxyzABCDEFGH"
},
"s3": {
"s3SchemaVersion": "1.0",
"configurationId": "testConfigRule",
"bucket": {
"name": "amzn-s3-demo-bucket",
"ownerIdentity": {
"principalId": "EXAMPLE"
},
"arn": "arn:aws:s3:::amzn-s3-demo-bucket"
},
"object": {
"key": "test%2Fkey",
"size": 1024,
"eTag": "0123456789abcdef0123456789abcdef",
"sequencer": "0A1B2C3D4E5F678901"
}
}
}
]
}
```
1. Scegli **Save** (Salva).
1. Scegli **Test (Esegui test)**.
1. Se la tua funzione viene eseguita correttamente, vedrai un output simile al seguente nella scheda **Risultati dell'esecuzione**.
```
Response
"image/jpeg"
Function Logs
START RequestId: 12b3cae7-5f4e-415e-93e6-416b8f8b66e6 Version: $LATEST
2021-02-18T21:40:59.280Z 12b3cae7-5f4e-415e-93e6-416b8f8b66e6 INFO INPUT BUCKET AND KEY: { Bucket: 'amzn-s3-demo-bucket', Key: 'HappyFace.jpg' }
2021-02-18T21:41:00.215Z 12b3cae7-5f4e-415e-93e6-416b8f8b66e6 INFO CONTENT TYPE: image/jpeg
END RequestId: 12b3cae7-5f4e-415e-93e6-416b8f8b66e6
REPORT RequestId: 12b3cae7-5f4e-415e-93e6-416b8f8b66e6 Duration: 976.25 ms Billed Duration: 977 ms Memory Size: 128 MB Max Memory Used: 90 MB Init Duration: 430.47 ms
Request ID
12b3cae7-5f4e-415e-93e6-416b8f8b66e6
```
### Test della funzione Lambda mediante il trigger Amazon S3
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-s3-example/s3trigger_tut_steps9.png)
Per verificare la funzione con il trigger configurato, carica un oggetto sul bucket Amazon S3 utilizzando la console. Per verificare che la funzione Lambda sia stata eseguita come previsto, usa CloudWatch Logs per visualizzare l'output della funzione.
**Caricamento di un oggetto nel bucket Amazon S3**
1. Apri la pagina [Bucket](https://console.aws.amazon.com/s3/buckets) della console Amazon S3 e scegli il bucket che hai creato in precedenza.
1. Scegli **Carica**.
1. Scegli **Aggiungi file** e usa il selettore di file per scegliere un oggetto da caricare. Tale oggetto può essere qualsiasi file desideri.
1. Seleziona **Apri**, quindi **Carica**.
**Per verificare l'invocazione della funzione utilizzando Logs CloudWatch**
1. Aprire la console [CloudWatch](https://console.aws.amazon.com/cloudwatch/home).
1. Assicurati di lavorare nella stessa modalità in Regione AWS cui hai creato la funzione Lambda. Puoi modificare la regione utilizzando l'elenco a discesa nella parte superiore dello schermo.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/console_region_select.png)
1. Scegli **Log** e quindi **Gruppi di log**.
1. Scegli il nome del gruppo di log per la funzione (`/aws/lambda/s3-trigger-tutorial`).
1. In **Flussi di log**, scegli il flusso di log più recente.
1. Se la tua funzione è stata richiamata correttamente in risposta al trigger Amazon S3, vedrai un output simile al seguente. Il `CONTENT TYPE` visualizzato dipende dal tipo di file che hai caricato nel bucket.
```
2022-05-09T23:17:28.702Z 0cae7f5a-b0af-4c73-8563-a3430333cc10 INFO CONTENT TYPE: image/jpeg
```
## Pulizia delle risorse
Ora è possibile eliminare le risorse create per questo tutorial, a meno che non si voglia conservarle. Eliminando AWS le risorse che non utilizzi più, eviti addebiti inutili a tuo carico. Account AWS
**Per eliminare la funzione Lambda**
1. Aprire la pagina [Functions (Funzioni)](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Selezionare la funzione creata.
1. Scegliere **Operazioni**, **Elimina**.
1. Inserisci **confirm** nel campo di immissione del testo, quindi scegli **Elimina**.
**Come eliminare il ruolo di esecuzione**
1. Aprire la pagina [Ruoli](https://console.aws.amazon.com/iam/home#/roles) della console IAM.
1. Selezionare il ruolo di esecuzione creato.
1. Scegliere **Elimina**.
1. Inserisci il nome del ruolo nel campo di immissione testo e seleziona **Delete** (Elimina).
**Per eliminare il bucket S3**
1. Aprire la [console Amazon S3](https://console.aws.amazon.com//s3/home#).
1. Selezionare il bucket creato in precedenza.
1. Scegli **Elimina**.
1. Inserisci il nome del bucket nel campo di immissione testo.
1. Scegli **Delete Bucket** (Elimina bucket).
## Fasi successive
In [Tutorial: uso di un trigger Amazon S3 per creare immagini in miniatura](with-s3-tutorial.md), il trigger Amazon S3 richiama una funzione per creare un'immagine in miniatura per ogni file immagine caricato nel bucket. Questo tutorial richiede un livello moderato di conoscenza del AWS dominio Lambda. Dimostra come creare risorse utilizzando AWS Command Line Interface (AWS CLI) e come creare un pacchetto di distribuzione di archivi di file.zip per la funzione e le sue dipendenze.
# Tutorial: uso di un trigger Amazon S3 per creare immagini in miniatura
In questo tutorial, creerai e configurerai una funzione Lambda che ridimensiona le immagini aggiunte a un bucket Amazon Simple Storage Service (Amazon S3). Quando aggiungi un file di immagine al bucket, Amazon S3 richiama la tua funzione Lambda. La funzione crea quindi una versione in miniatura dell'immagine e la invia a un altro bucket Amazon S3.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-s3-tutorial/s3thumb_tut_resources.png)
Per completare questo tutorial, completa le seguenti attività:
1. Crea i bucket Amazon S3 di origine e destinazione e carica un'immagine di esempio.
1. Crea una funzione Lambda che ridimensiona un'immagine e restituisce una miniatura in un bucket Amazon S3.
1. Configura un trigger Lambda che richiama la tua funzione quando gli oggetti vengono caricati nel bucket di origine.
1. Testa la tua funzione, prima con un evento fittizio e poi caricando un'immagine nel tuo bucket di origine.
Completando questi passaggi, imparerai come utilizzare Lambda per eseguire un'attività di elaborazione di file su oggetti aggiunti a un bucket Amazon S3. Puoi completare questo tutorial usando il AWS Command Line Interface (AWS CLI) o il Console di gestione AWS.
Se stai cercando un esempio più semplice per imparare a configurare un trigger Amazon S3 per Lambda, puoi provare [Tutorial: utilizzo di un trigger Amazon S3 per richiamare una funzione Lambda](https://docs.aws.amazon.com/lambda/latest/dg/with-s3-example.html).
**Topics**
+ [
## Prerequisiti
](#with-s3-example-prereqs)
+ [
## Creazione di due bucket Amazon S3
](#with-s3-tutorial-prepare-create-buckets)
+ [
## Caricamento di un'immagine di test nel bucket di origine
](#with-s3-tutorial-test-image)
+ [
## Creazione di una policy di autorizzazione
](#with-s3-tutorial-create-policy)
+ [
## Creazione di un ruolo di esecuzione
](#with-s3-tutorial-create-execution-role)
+ [
## Creazione del pacchetto di implementazione della funzione
](#with-s3-tutorial-create-function-package)
+ [
## Creazione della funzione Lambda
](#with-s3-tutorial-create-function-createfunction)
+ [
## Configurazione di Amazon S3 per richiamare la funzione
](#with-s3-tutorial-configure-s3-trigger)
+ [
## Test di una funzione Lambda con un evento fittizio
](#with-s3-tutorial-dummy-test)
+ [
## Test della funzione tramite il trigger Amazon S3
](#with-s3-tutorial-test-s3)
+ [
## Pulizia delle risorse
](#s3-tutorial-cleanup)
## Prerequisiti
Se vuoi usare il per AWS CLI completare il tutorial, installa la [versione più recente di AWS Command Line Interface]().
Per il codice della funzione Lambda, puoi utilizzare Python o Node.js. Installa gli strumenti di supporto linguistico e un gestore di pacchetti per il linguaggio che desideri utilizzare.
### Installa il AWS Command Line Interface
Se non l'hai ancora installato AWS Command Line Interface, segui i passaggi indicati in [Installazione o aggiornamento della versione più recente di AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) per installarlo.
Per eseguire i comandi nel tutorial, sono necessari un terminale a riga di comando o una shell (interprete di comandi). In Linux e macOS, utilizza la shell (interprete di comandi) e il gestore pacchetti preferiti.
**Nota**
Su Windows, alcuni comandi della CLI Bash utilizzati comunemente con Lambda (ad esempio, `zip`) non sono supportati dai terminali integrati del sistema operativo. Per ottenere una versione integrata su Windows di Ubuntu e Bash, [installa il sottosistema Windows per Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10).
## Creazione di due bucket Amazon S3
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-s3-tutorial/s3thumb_tut_steps1.png)
Per prima cosa, crea due bucket Amazon S3. Il primo bucket è il bucket di origine in cui caricherai le tue immagini. Il secondo bucket viene utilizzato da Lambda per salvare la miniatura ridimensionata quando richiami la tua funzione.
------
#### [ Console di gestione AWS ]
**Creazione di bucket Amazon S3 (console)**
1. Apri la [console Amazon S3](https://console.aws.amazon.com/s3) e seleziona la pagina **General Purpose bucket**.
1. Seleziona quello più Regione AWS vicino alla tua posizione geografica. Puoi modificare la regione utilizzando l'elenco a discesa nella parte superiore dello schermo. Più avanti nel tutorial, è necessario creare la funzione Lambda nella stessa regione.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/console_region_select.png)
1. Scegliere **Create bucket (Crea bucket)**.
1. In **General configuration (Configurazione generale)**, eseguire le operazioni seguenti:
1. Per **Tipo di secchio**, assicurati che sia selezionata l'**opzione Uso generale**.
1. Per **Nome del bucket**, inserisci un nome univoco globale che soddisfi le [regole di denominazione dei bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html) di Amazon S3. I nomi dei bucket possono contenere solo lettere minuscole, numeri, punti (.) e trattini (-).
1. Lascia tutte le altre opzioni impostate sui valori predefiniti e scegli **Crea bucket**.
1. Ripeti i passaggi da 1 a 5 per creare il bucket di destinazione. Per **Nome del bucket**, inserisci `amzn-s3-demo-source-bucket-resized`, dove `amzn-s3-demo-source-bucket` è il nome del bucket di origine che hai appena creato.
------
#### [ AWS CLI ]
**Creazione dei bucket Amazon S3 (AWS CLI)**
1. Esegui il comando della CLI sotto riportato per creare il bucket di origine. Il nome che scegli per il bucket deve essere univoco a livello globale e seguire le [regole di denominazione dei bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html) di Amazon S3. I nomi possono contenere solo lettere minuscole, numeri, punti (.) e trattini (-). Per `region` e `LocationConstraint`, scegli la [Regione AWS](https://docs.aws.amazon.com/general/latest/gr/lambda-service.html) più vicina alla tua posizione geografica.
```
aws s3api create-bucket --bucket amzn-s3-demo-source-bucket --region us-east-1 \
--create-bucket-configuration LocationConstraint=us-east-1
```
Più avanti nel tutorial, devi creare la tua funzione Lambda nello Regione AWS stesso bucket sorgente, quindi prendi nota della regione che hai scelto.
1. Esegui il comando sotto riportato per creare il bucket di destinazione. Per il nome del bucket, devi usare `amzn-s3-demo-source-bucket-resized`, dove `amzn-s3-demo-source-bucket` è il nome del bucket di origine che hai creato nel passaggio 1. Per `region` e`LocationConstraint`, scegli lo stesso Regione AWS che hai usato per creare il bucket sorgente.
```
aws s3api create-bucket --bucket amzn-s3-demo-source-bucket-resized --region us-east-1 \
--create-bucket-configuration LocationConstraint=us-east-1
```
------
## Caricamento di un'immagine di test nel bucket di origine
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-s3-tutorial/s3thumb_tut_steps2.png)
Più avanti nel tutorial, testerai la tua funzione Lambda invocandola utilizzando la console o AWS CLI la console Lambda. Per confermare che la funzione funzioni correttamente, il bucket di origine deve contenere un'immagine di test. Questa immagine può essere qualsiasi file JPG o PNG che scegli.
------
#### [ Console di gestione AWS ]
**Caricamento di un'immagine di test nel bucket di origine (console)**
1. Nella console Amazon S3, apri la pagina [Bucket](https://console.aws.amazon.com/s3/buckets).
1. Seleziona il bucket di origine che hai creato nella fase precedente.
1. Scegli **Carica**.
1. Scegli **Aggiungi file** e usa il selettore di file per scegliere l'oggetto da caricare.
1. Seleziona **Apri**, quindi **Carica**.
------
#### [ AWS CLI ]
**Caricamento di un'immagine di test nel bucket di origine (AWS CLI)**
+ Dalla directory contenente l'immagine che desideri caricare, esegui il comando della CLI sotto riportato. Sostituisci il parametro `--bucket` con il nome del bucket di origine. Per i parametri `--key` e `--body`, usa il nome del file dell'immagine di test.
```
aws s3api put-object --bucket amzn-s3-demo-source-bucket --key HappyFace.jpg --body ./HappyFace.jpg
```
------
## Creazione di una policy di autorizzazione
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-s3-tutorial/s3thumb_tut_steps3.png)
Il primo passo per creare una funzione Lambda consiste nel creare una policy di autorizzazione. Questa politica fornisce alla funzione le autorizzazioni necessarie per accedere ad altre risorse. AWS Per questo tutorial, la policy fornisce le autorizzazioni di lettura e scrittura Lambda per i bucket Amazon S3 e consente di scrivere su Amazon Logs. CloudWatch
------
#### [ Console di gestione AWS ]
**Creazione della policy (console)**
1. Apri la pagina [Policies](https://console.aws.amazon.com/iamv2/home#policies) della console (IAM). AWS Identity and Access Management
1. Scegli **Crea policy**.
1. Scegliere la scheda **JSON** e quindi incollare la seguente policy personalizzata nell'editor JSON.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:PutLogEvents",
"logs:CreateLogGroup",
"logs:CreateLogStream"
],
"Resource": "arn:aws:logs:*:*:*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": "arn:aws:s3:::*/*"
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::*/*"
}
]
}
```
1. Scegli **Next (Successivo)**.
1. In **Dettagli sulla policy**, per **Nome policy**, inserisci `LambdaS3Policy`.
1. Scegli **Crea policy**.
------
#### [ AWS CLI ]
**Creazione della policy (AWS CLI)**
1. Salva il seguente JSON in un file denominato `policy.json`.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:PutLogEvents",
"logs:CreateLogGroup",
"logs:CreateLogStream"
],
"Resource": "arn:aws:logs:*:*:*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": "arn:aws:s3:::*/*"
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::*/*"
}
]
}
```
1. Nella directory in cui hai salvato il documento della policy JSON, esegui il comando della CLI sotto riportato.
```
aws iam create-policy --policy-name LambdaS3Policy --policy-document file://policy.json
```
------
## Creazione di un ruolo di esecuzione
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-s3-tutorial/s3thumb_tut_steps4.png)
Un ruolo di esecuzione è un ruolo IAM che concede a una funzione Lambda l'autorizzazione all' Servizi AWS accesso e alle risorse. Per concedere alla funzione l'accesso in lettura e scrittura a un bucket Amazon S3, è necessario collegare la policy di autorizzazione che hai creato nel passaggio precedente.
------
#### [ Console di gestione AWS ]
**Creazione di un ruolo di esecuzione e collegamento di una policy di autorizzazione (console)**
1. Apri la pagina [Ruoli](https://console.aws.amazon.com/iamv2/home#roles) della console (IAM).
1. Scegli **Crea ruolo**.
1. Per **Tipo di entità attendibile**, seleziona **Servizio AWS**, mentre per **Caso d'uso**, seleziona **Lambda**.
1. Scegli **Next (Successivo)**.
1. Aggiungi la policy di autorizzazione che hai creato nel passaggio precedente effettuando le seguenti operazioni:
1. Nella casella di ricerca delle policy, immettere `LambdaS3Policy`.
1. Nei risultati di ricerca, seleziona la casella di controllo per `LambdaS3Policy`.
1. Scegli **Next (Successivo)**.
1. In **Dettagli ruolo**, per **Nome ruolo**, inserisci `LambdaS3Role`.
1. Scegli **Crea ruolo**.
------
#### [ AWS CLI ]
**Creazione di un ruolo di esecuzione e collegamento di una policy di autorizzazione (AWS CLI)**
1. Salva il seguente JSON in un file denominato `trust-policy.json`. Questa politica di fiducia consente a Lambda di utilizzare le autorizzazioni del ruolo concedendo al servizio principale l'`lambda.amazonaws.com`autorizzazione a chiamare l'azione AWS Security Token Service ()AWS STS. `AssumeRole`
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Nella directory in cui hai salvato il documento della policy di attendibilità JSON, esegui il comando della CLI sotto riportato per creare il ruolo di esecuzione.
```
aws iam create-role --role-name LambdaS3Role --assume-role-policy-document file://trust-policy.json
```
1. Per collegare la policy di autorizzazione creata nel passaggio precedente, esegui il comando della CLI sotto riportato. Sostituisci il Account AWS numero nell'ARN della polizza con il tuo numero di conto.
```
aws iam attach-role-policy --role-name LambdaS3Role --policy-arn arn:aws:iam::123456789012:policy/LambdaS3Policy
```
------
## Creazione del pacchetto di implementazione della funzione
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-s3-tutorial/s3thumb_tut_steps5.png)
Per creare la funzione, occorre creare un *pacchetto di implementazione* contenente la funzione e le rispettive dipendenze. Per questa funzione `CreateThumbnail`, il codice della funzione utilizza una libreria separata per il ridimensionamento dell'immagine. Segui le istruzioni per il linguaggio scelto per creare un pacchetto di implementazione contenente la libreria richiesta.
------
#### [ Node.js ]
**Creazione del pacchetto di implementazione (Node.js)**
1. Crea una directory denominata `lambda-s3` per il codice della funzione e le dipendenze e naviga al suo interno.
```
mkdir lambda-s3
cd lambda-s3
```
1. Crea un nuovo progetto Node.js con `npm`. Per accettare le opzioni predefinite fornite nell'esperienza interattiva, premi `Enter`.
```
npm init
```
1. Salvare il codice della funzione seguente in un file denominato `index.mjs`. Assicurati di sostituire `us-east-1` con la Regione AWS in cui hai creato i tuoi bucket di origine e destinazione.
```
// dependencies
import { S3Client, GetObjectCommand, PutObjectCommand } from '@aws-sdk/client-s3';
import { Readable } from 'stream';
import sharp from 'sharp';
import util from 'util';
// create S3 client
const s3 = new S3Client({region: 'us-east-1'});
// define the handler function
export const handler = async (event, context) => {
// Read options from the event parameter and get the source bucket
console.log("Reading options from event:\n", util.inspect(event, {depth: 5}));
const srcBucket = event.Records[0].s3.bucket.name;
// Object key may have spaces or unicode non-ASCII characters
const srcKey = decodeURIComponent(event.Records[0].s3.object.key.replace(/\+/g, " "));
const dstBucket = srcBucket + "-resized";
const dstKey = "resized-" + srcKey;
// Infer the image type from the file suffix
const typeMatch = srcKey.match(/\.([^.]*)$/);
if (!typeMatch) {
console.log("Could not determine the image type.");
return;
}
// Check that the image type is supported
const imageType = typeMatch[1].toLowerCase();
if (imageType != "jpg" && imageType != "png") {
console.log(`Unsupported image type: ${imageType}`);
return;
}
// Get the image from the source bucket. GetObjectCommand returns a stream.
try {
const params = {
Bucket: srcBucket,
Key: srcKey
};
var response = await s3.send(new GetObjectCommand(params));
var stream = response.Body;
// Convert stream to buffer to pass to sharp resize function.
if (stream instanceof Readable) {
var content_buffer = Buffer.concat(await stream.toArray());
} else {
throw new Error('Unknown object stream type');
}
} catch (error) {
console.log(error);
return;
}
// set thumbnail width. Resize will set the height automatically to maintain aspect ratio.
const width = 200;
// Use the sharp module to resize the image and save in a buffer.
try {
var output_buffer = await sharp(content_buffer).resize(width).toBuffer();
} catch (error) {
console.log(error);
return;
}
// Upload the thumbnail image to the destination bucket
try {
const destparams = {
Bucket: dstBucket,
Key: dstKey,
Body: output_buffer,
ContentType: "image"
};
const putResult = await s3.send(new PutObjectCommand(destparams));
} catch (error) {
console.log(error);
return;
}
console.log('Successfully resized ' + srcBucket + '/' + srcKey +
' and uploaded to ' + dstBucket + '/' + dstKey);
};
```
1. Nella directory `lambda-s3`, installa la libreria sharp utilizzando npm. Tieni presente che l'ultima versione di sharp (0.33) non è compatibile con Lambda. Per completare questo tutorial, installa la versione 0.32.6.
```
npm install sharp@0.32.6
```
Il comando `install` di npm crea una directory `node_modules` per i tuoi moduli. Dopo questo passaggio, la struttura di directory dovrebbe avere un aspetto simile al seguente.
```
lambda-s3
|- index.mjs
|- node_modules
| |- base64js
| |- bl
| |- buffer
...
|- package-lock.json
|- package.json
```
1. Crea un pacchetto di implementazione .zip contenente il codice della funzione e le rispettive dipendenze. Su MacOS o Linux, esegui il comando sotto riportato.
```
zip -r function.zip .
```
Su Windows, utilizza il tuo strumento di compressione preferito per creare il file .zip. Assicurati che i tuoi file `index.mjs`, `package.json` e `package-lock.json` e la tua directory `node_modules` si trovino tutti nella directory principale del tuo file .zip.
------
#### [ Python ]
**Creazione del pacchetto di implementazione (Python)**
1. Salva il codice di esempio come un file denominato `lambda_function.py`.
```
import boto3
import os
import sys
import uuid
from urllib.parse import unquote_plus
from PIL import Image
import PIL.Image
s3_client = boto3.client('s3')
def resize_image(image_path, resized_path):
with Image.open(image_path) as image:
image.thumbnail(tuple(x / 2 for x in image.size))
image.save(resized_path)
def lambda_handler(event, context):
for record in event['Records']:
bucket = record['s3']['bucket']['name']
key = unquote_plus(record['s3']['object']['key'])
tmpkey = key.replace('/', '')
download_path = '/tmp/{}{}'.format(uuid.uuid4(), tmpkey)
upload_path = '/tmp/resized-{}'.format(tmpkey)
s3_client.download_file(bucket, key, download_path)
resize_image(download_path, upload_path)
s3_client.upload_file(upload_path, '{}-resized'.format(bucket), 'resized-{}'.format(key))
```
1. Nella stessa directory in cui hai creato il file `lambda_function.py`, crea una nuova directory denominata `package` e installa la libreria [Pillow (PIL)](https://pypi.org/project/Pillow/) e AWS SDK per Python (Boto3). Sebbene il runtime Lambda di Python includa una versione dell'SDK Boto3, ti consigliamo di aggiungere tutte le dipendenze della funzione al pacchetto di implementazione, anche se sono incluse nel runtime. Per ulteriori informazioni, consulta [Dipendenze del runtime in Python](https://docs.aws.amazon.com/lambda/latest/dg/python-package.html#python-package-dependencies).
```
mkdir package
pip install \
--platform manylinux2014_x86_64 \
--target=package \
--implementation cp \
--python-version 3.12 \
--only-binary=:all: --upgrade \
pillow boto3
```
La libreria Pillow contiene codice C/C\$1\$1. Utilizzando le opzioni `--platform manylinux_2014_x86_64` e `--only-binary=:all:`, pip scaricherà e installerà una versione di Pillow che contiene file binari precompilati compatibili con il sistema operativo Amazon Linux 2. Ciò garantisce che il pacchetto di implementazione funzioni nell'ambiente di esecuzione Lambda, indipendentemente dal sistema operativo e dall'architettura del computer di compilazione locale.
1. Crea un file .zip contenente il codice dell'applicazione e le librerie Pillow e Boto3. Su Linux o MacOS, esegui i comandi riportati di seguito dall'interfaccia della linea di comando.
```
cd package
zip -r ../lambda_function.zip .
cd ..
zip lambda_function.zip lambda_function.py
```
Su Windows, usa il tuo strumento di compressione preferito per creare il file `lambda_function.zip`. Assicurati che il tuo file `lambda_function.py` e le cartelle contenenti le tue dipendenze si trovino tutti nella directory principale del file .zip.
Puoi creare il tuo pacchetto di implementazione anche utilizzando un ambiente virtuale Python. Per informazioni, consultare [Utilizzo di archivi di file .zip per le funzioni Lambda in Python](python-package.md).
------
## Creazione della funzione Lambda
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-s3-tutorial/s3thumb_tut_steps6.png)
Puoi creare la tua funzione Lambda utilizzando la console AWS CLI o la console Lambda. Segui le istruzioni per il linguaggio scelto per creare la funzione.
------
#### [ Console di gestione AWS ]
**Creazione della funzione (console)**
Per creare la tua funzione Lambda utilizzando la console, devi prima creare una funzione di base contenente del codice "Hello world". Quindi, sostituisci questo codice con il codice della tua funzione caricando il file .zip o JAR creato nel passaggio precedente.
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Assicurati di lavorare nello stesso bucket in Regione AWS cui hai creato il tuo bucket Amazon S3. Puoi modificare la regione utilizzando l'elenco a discesa nella parte superiore dello schermo.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/console_region_select.png)
1. Selezionare **Create function (Crea funzione)**.
1. Scegli **Author from scratch** (Crea da zero).
1. In **Basic information (Informazioni di base)** eseguire queste operazioni:
1. Nel campo **Function name (Nome funzione)**, immettere `CreateThumbnail`.
1. Per **Runtime**, scegli **Node.js 22.x** o **Python 3.12**, a seconda del linguaggio che hai scelto per la funzione.
1. In **Architecture** (Architettura), scegli **x86\$164**.
1. Nella scheda **Modifica ruolo di esecuzione predefinito**, effettua le seguenti operazioni:
1. Espandi la scheda, quindi scegli **Utilizza un ruolo esistente**.
1. Seleziona il `LambdaS3Role` che hai creato in precedenza.
1. Scegli **Crea funzione**.
**Caricamento del codice della funzione (console)**
1. Nel riquadro **Origine del codice**, scegli **Carica da**.
1. Scegli **File .zip**.
1. Scegli **Carica**.
1. Nel selettore di file, seleziona il tuo file .zip e scegli **Apri**.
1. Scegli **Save** (Salva).
------
#### [ AWS CLI ]
**Creazione della funzione (AWS CLI)**
+ Esegui il comando della CLI per il linguaggio che hai scelto. Per il `role` parametro, assicurati di sostituirlo `123456789012` con il tuo ID. Account AWS Per il parametro `region`, sostituisci `us-east-1` con la regione in cui hai creato i bucket Amazon S3.
+ Per **Node.js**, esegui il comando sotto riportato dalla directory contenente il file `function.zip`.
```
aws lambda create-function --function-name CreateThumbnail \
--zip-file fileb://function.zip --handler index.handler --runtime nodejs24.x \
--timeout 10 --memory-size 1024 \
--role arn:aws:iam::123456789012:role/LambdaS3Role --region us-east-1
```
+ Per **Python**, esegui il comando sotto riportato dalla directory contenente il file `lambda_function.zip`.
```
aws lambda create-function --function-name CreateThumbnail \
--zip-file fileb://lambda_function.zip --handler lambda_function.lambda_handler \
--runtime python3.14 --timeout 10 --memory-size 1024 \
--role arn:aws:iam::123456789012:role/LambdaS3Role --region us-east-1
```
------
## Configurazione di Amazon S3 per richiamare la funzione
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-s3-tutorial/s3thumb_tut_steps7.png)
Affinché la funzione Lambda venga eseguita quando carichi un'immagine nel bucket di origine, devi configurare un trigger per la funzione. È possibile configurare il trigger Amazon S3 utilizzando la console Lambda o la AWS CLI.
**Importante**
Questa procedura configura il bucket Amazon S3 per richiamare la funzione ogni volta che un oggetto viene creato nel bucket. Assicurati di configurare questa opzione solo sul bucket di origine. Se la tua funzione Lambda crea oggetti nello stesso bucket che la richiama, la tua funzione può essere [richiamata continuamente in un ciclo ricorsivo (loop)](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/recursive-runaway). Ciò può comportare la fatturazione di addebiti imprevisti al tuo Account AWS.
------
#### [ Console di gestione AWS ]
**Configurazione del trigger Amazon S3 (console)**
1. Apri la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda e scegli la tua funzione (`CreateThumbnail`).
1. Selezionare **Add trigger** (Aggiungi trigger).
1. Seleziona **S3**.
1. In **Bucket**, seleziona il tuo bucket di origine.
1. In **Tipi di eventi**, seleziona **Tutti gli eventi di creazione di oggetti**.
1. In **Invocazione ricorsiva**, seleziona la casella di controllo per confermare che non è consigliabile utilizzare lo stesso bucket Amazon S3 per input e output. Per maggiori informazioni sui modelli di invocazione ricorsivi in Lambda, consulta [Schemi ricorsivi che causano loop indeterminati delle funzioni Lambda](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/recursive-runaway) in Serverless Land.
1. Scegliere **Aggiungi**.
Quando crei un trigger utilizzando la console Lambda, Lambda crea automaticamente una [policy basata sulle risorse](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html) per concedere al servizio selezionato l'autorizzazione a richiamare la funzione.
------
#### [ AWS CLI ]
**Configurazione del trigger Amazon S3 (AWS CLI)**
1. Affinché il bucket di origine Amazon S3 richiami la funzione quando aggiungi un file di immagine, devi prima configurare le autorizzazioni per la funzione utilizzando una [policy basata sulle risorse](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html). Una dichiarazione politica basata sulle risorse fornisce altre Servizi AWS autorizzazioni per richiamare la funzione. Per autorizzare Amazon S3 a richiamare la tua funzione, esegui il comando della CLI comando sotto riportato. Assicurati di sostituire il `source-account` parametro con il tuo Account AWS ID e di utilizzare il tuo nome del bucket di origine.
```
aws lambda add-permission --function-name CreateThumbnail \
--principal s3.amazonaws.com --statement-id s3invoke --action "lambda:InvokeFunction" \
--source-arn arn:aws:s3:::amzn-s3-demo-source-bucket \
--source-account 123456789012
```
La policy che definisci con questo comando consente ad Amazon S3 di richiamare la tua funzione solo quando viene eseguita un'operazione sul tuo bucket di origine.
**Nota**
Sebbene i nomi dei bucket Amazon S3 siano univoci a livello globale, quando utilizzi policy basate sulle risorse è consigliabile specificare che il bucket deve appartenere al tuo account. Questo perché se elimini un bucket, è possibile che un altro lo Account AWS crei con lo stesso Amazon Resource Name (ARN).
1. Salva il seguente JSON in un file denominato `notification.json`. Quando viene applicato al tuo bucket di origine, questo JSON configura il bucket in modo che invii una notifica alla funzione Lambda ogni volta che viene aggiunto un nuovo oggetto. Sostituisci il Account AWS numero e Regione AWS nella funzione Lambda ARN con il tuo numero di account e la tua regione.
```
{
"LambdaFunctionConfigurations": [
{
"Id": "CreateThumbnailEventConfiguration",
"LambdaFunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:CreateThumbnail",
"Events": [ "s3:ObjectCreated:Put" ]
}
]
}
```
1. Esegui il comando della CLI comando sotto riportato per applicare le impostazioni di notifica nel file JSON che hai creato al tuo bucket di origine. Sostituisci `amzn-s3-demo-source-bucket` con il nome del tuo bucket di origine.
```
aws s3api put-bucket-notification-configuration --bucket amzn-s3-demo-source-bucket \
--notification-configuration file://notification.json
```
Per ulteriori informazioni sul `put-bucket-notification-configuration` comando e sull'`notification-configuration`opzione, consulta [put-bucket-notification-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/put-bucket-notification-configuration.html)la *AWS CLI Command* Reference.
------
## Test di una funzione Lambda con un evento fittizio
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-s3-tutorial/s3thumb_tut_steps8.png)
Prima di testare l'intera configurazione aggiungendo un file di immagine al tuo bucket di origine Amazon S3, verifica che la tua funzione Lambda funzioni correttamente richiamandola con un evento fittizio. Un evento in Lambda è un documento in formato JSON che contiene i dati che una funzione deve elaborare. Quando la funzione viene richiamata da Amazon S3, l'evento inviato alla funzione contiene informazioni come il nome del bucket, l'ARN del bucket e la chiave dell'oggetto.
------
#### [ Console di gestione AWS ]
**Test di una funzione Lambda con un evento fittizio (console)**
1. Apri la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda e scegli la tua funzione (`CreateThumbnail`).
1. Seleziona la scheda **Test**.
1. Per creare il tuo evento di test, nel riquadro **Evento di test**, procedi come segue:
1. In **Operazione evento di test**, seleziona **Crea nuovo evento**.
1. Per **Event name (Nome evento)** immettere **myTestEvent**.
1. Per **Modello**, seleziona **S3 Put**.
1. Sostituisci i valori dei seguenti parametri con i tuoi valori.
+ Infatti`awsRegion`, `us-east-1` sostituiscilo con quello in Regione AWS cui hai creato i bucket Amazon S3.
+ Per `name`, sostituisci `amzn-s3-demo-bucket` con il nome del bucket di origine Amazon S3.
+ Per `key`, sostituisci `test%2Fkey` con il nome del file dell'oggetto di test che hai caricato nel bucket di origine durante il passaggio [Caricamento di un'immagine di test nel bucket di origine](#with-s3-tutorial-test-image).
```
{
"Records": [
{
"eventVersion": "2.0",
"eventSource": "aws:s3",
"awsRegion": "us-east-1",
"eventTime": "1970-01-01T00:00:00.000Z",
"eventName": "ObjectCreated:Put",
"userIdentity": {
"principalId": "EXAMPLE"
},
"requestParameters": {
"sourceIPAddress": "127.0.0.1"
},
"responseElements": {
"x-amz-request-id": "EXAMPLE123456789",
"x-amz-id-2": "EXAMPLE123/5678abcdefghijklambdaisawesome/mnopqrstuvwxyzABCDEFGH"
},
"s3": {
"s3SchemaVersion": "1.0",
"configurationId": "testConfigRule",
"bucket": {
"name": "amzn-s3-demo-bucket",
"ownerIdentity": {
"principalId": "EXAMPLE"
},
"arn": "arn:aws:s3:::amzn-s3-demo-bucket"
},
"object": {
"key": "test%2Fkey",
"size": 1024,
"eTag": "0123456789abcdef0123456789abcdef",
"sequencer": "0A1B2C3D4E5F678901"
}
}
}
]
}
```
1. Scegli **Save** (Salva).
1. Nel riquadro **Evento di test**, scegli **Test**.
1. Per verificare che la funzione abbia creato una versione ridimensionata dell'immagine e l'abbia archiviata nel bucket Amazon S3 di destinazione, procedi come segue:
1. Nella console Amazon S3, apri la pagina [Bucket](https://console.aws.amazon.com/s3/buckets).
1. Scegli il bucket di destinazione e conferma che il file ridimensionato sia elencato nel riquadro **Oggetti**.
------
#### [ AWS CLI ]
**Test di una funzione Lambda con un evento fittizio (AWS CLI)**
1. Salva il seguente JSON in un file denominato `dummyS3Event.json`. Sostituisci i valori dei seguenti parametri con i tuoi valori:
+ Infatti`awsRegion`, `us-east-1` sostituiscilo con quello in Regione AWS cui hai creato i bucket Amazon S3.
+ Per `name`, sostituisci `amzn-s3-demo-bucket` con il nome del bucket di origine Amazon S3.
+ Per `key`, sostituisci `test%2Fkey` con il nome del file dell'oggetto di test che hai caricato nel bucket di origine durante il passaggio [Caricamento di un'immagine di test nel bucket di origine](#with-s3-tutorial-test-image).
```
{
"Records": [
{
"eventVersion": "2.0",
"eventSource": "aws:s3",
"awsRegion": "us-east-1",
"eventTime": "1970-01-01T00:00:00.000Z",
"eventName": "ObjectCreated:Put",
"userIdentity": {
"principalId": "EXAMPLE"
},
"requestParameters": {
"sourceIPAddress": "127.0.0.1"
},
"responseElements": {
"x-amz-request-id": "EXAMPLE123456789",
"x-amz-id-2": "EXAMPLE123/5678abcdefghijklambdaisawesome/mnopqrstuvwxyzABCDEFGH"
},
"s3": {
"s3SchemaVersion": "1.0",
"configurationId": "testConfigRule",
"bucket": {
"name": "amzn-s3-demo-bucket",
"ownerIdentity": {
"principalId": "EXAMPLE"
},
"arn": "arn:aws:s3:::amzn-s3-demo-bucket"
},
"object": {
"key": "test%2Fkey",
"size": 1024,
"eTag": "0123456789abcdef0123456789abcdef",
"sequencer": "0A1B2C3D4E5F678901"
}
}
}
]
}
```
1. Nella directory in cui hai salvato il file `dummyS3Event.json`, richiama la funzione eseguendo il seguente comando della CLI. Questo comando richiama la funzione Lambda in modo sincrono specificando `RequestResponse` come valore del parametro invocation-type. Per ulteriori informazioni sulla chiamata sincrona e asincrona, consulta la pagina [Invocazione delle funzioni Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-invocation.html).
```
aws lambda invoke --function-name CreateThumbnail \
--invocation-type RequestResponse --cli-binary-format raw-in-base64-out \
--payload file://dummyS3Event.json outputfile.txt
```
L' cli-binary-formatopzione è obbligatoria se si utilizza la versione 2 di. AWS CLI Per rendere questa impostazione come predefinita, esegui `aws configure set cli-binary-format raw-in-base64-out`. Per ulteriori informazioni, consulta [Opzioni della riga di comando globali supportate da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list).
1. Verifica che la funzione abbia creato una versione in miniatura dell'immagine e l'abbia salvata nel bucket Amazon S3 di destinazione. Esegui il comando della CLI sotto riportato sostituendo `amzn-s3-demo-source-bucket-resized` con il nome del tuo bucket di destinazione.
```
aws s3api list-objects-v2 --bucket amzn-s3-demo-source-bucket-resized
```
Verrà visualizzato un output simile al seguente. Il parametro `Key` mostra il nome del file di immagine ridimensionato.
```
{
"Contents": [
{
"Key": "resized-HappyFace.jpg",
"LastModified": "2023-06-06T21:40:07+00:00",
"ETag": "\"d8ca652ffe83ba6b721ffc20d9d7174a\"",
"Size": 2633,
"StorageClass": "STANDARD"
}
]
}
```
------
## Test della funzione tramite il trigger Amazon S3
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-s3-tutorial/s3thumb_tut_steps9.png)
Ora che hai verificato che la funzione Lambda funziona correttamente, puoi testare la configurazione completa aggiungendo un file di immagine al tuo bucket di origine Amazon S3. Quando aggiungi l'immagine al bucket di origine, la tua funzione Lambda dovrebbe essere richiamata automaticamente. La tua funzione crea una versione ridimensionata del file e la archivia nel bucket di destinazione.
------
#### [ Console di gestione AWS ]
**Test della funzione Lambda tramite il trigger Amazon S3 (console)**
1. Per caricare un'immagine nel bucket Amazon S3, procedi come segue:
1. Apri la pagina [Bucket](https://console.aws.amazon.com/s3/buckets) della console Amazon S3 e scegli il bucket di origine.
1. Scegli **Carica**.
1. Scegli **Aggiungi file** e utilizza il selettore di file per scegliere il file di immagine da caricare. L'oggetto dell'immagine può essere qualsiasi file .jpg o .png.
1. Seleziona **Apri**, quindi **Carica**.
1. Verifica che Lambda abbia salvato una versione ridimensionata del tuo file di immagine nel bucket di destinazione effettuando le seguenti operazioni:
1. Torna alla pagina [Bucket](https://console.aws.amazon.com/s3/buckets) della console Amazon S3 e scegli il bucket di destinazione.
1. Nel riquadro **Oggetti**, ora dovresti vedere due file di immagine ridimensionati, uno per ogni test della tua funzione Lambda. Per scaricare l'immagine ridimensionata, seleziona il file, quindi scegli **Scarica**.
------
#### [ AWS CLI ]
**Test della funzione Lambda tramite il trigger Amazon S3 (AWS CLI)**
1. Dalla directory contenente l'immagine che desideri caricare, esegui il comando della CLI sotto riportato. Sostituisci il parametro `--bucket` con il nome del bucket di origine. Per i parametri `--key` e `--body`, usa il nome del file dell'immagine di test. L'immagine di test può essere qualsiasi file .jpg o .png.
```
aws s3api put-object --bucket amzn-s3-demo-source-bucket --key SmileyFace.jpg --body ./SmileyFace.jpg
```
1. Verifica che la funzione abbia creato una versione in miniatura dell'immagine e l'abbia salvata nel bucket Amazon S3 di destinazione. Esegui il comando della CLI sotto riportato sostituendo `amzn-s3-demo-source-bucket-resized` con il nome del tuo bucket di destinazione.
```
aws s3api list-objects-v2 --bucket amzn-s3-demo-source-bucket-resized
```
Se la tua funzione viene eseguita correttamente, vedrai un output simile al seguente. Il bucket di destinazione dovrebbe ora contenere due file ridimensionati.
```
{
"Contents": [
{
"Key": "resized-HappyFace.jpg",
"LastModified": "2023-06-07T00:15:50+00:00",
"ETag": "\"7781a43e765a8301713f533d70968a1e\"",
"Size": 2763,
"StorageClass": "STANDARD"
},
{
"Key": "resized-SmileyFace.jpg",
"LastModified": "2023-06-07T00:13:18+00:00",
"ETag": "\"ca536e5a1b9e32b22cd549e18792cdbc\"",
"Size": 1245,
"StorageClass": "STANDARD"
}
]
}
```
------
## Pulizia delle risorse
Ora è possibile eliminare le risorse create per questo tutorial, a meno che non si voglia conservarle. Eliminando AWS le risorse che non utilizzi più, eviti addebiti inutili a tuo Account AWS carico.
**Per eliminare la funzione Lambda**
1. Aprire la pagina [Functions (Funzioni)](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Selezionare la funzione creata.
1. Scegliere **Operazioni**, **Elimina**.
1. Digita **confirm** nel campo di immissione testo e scegli **Delete** (Elimina).
**Per eliminare la policy creata**
1. Aprire la pagina [Policies (Policy)](https://console.aws.amazon.com/iam/home#/policies) nella console IAM.
1. Seleziona la politica che hai creato (**AWSLambdaS3Policy**).
1. Scegliere **Policy actions (Operazioni policy)**, **Delete (Elimina)**.
1. Scegliere **Delete (Elimina)**.
**Per eliminare il ruolo di esecuzione**
1. Aprire la pagina [Ruoli](https://console.aws.amazon.com/iam/home#/roles) della console IAM.
1. Selezionare il ruolo di esecuzione creato.
1. Scegliere **Elimina**.
1. Inserisci il nome del ruolo nel campo di immissione testo e seleziona **Delete** (Elimina).
**Per eliminare il bucket S3**
1. Aprire la [console Amazon S3](https://console.aws.amazon.com//s3/home#).
1. Selezionare il bucket creato in precedenza.
1. Scegli **Elimina**.
1. Inserisci il nome del bucket nel campo di immissione testo.
1. Scegli **Delete Bucket** (Elimina bucket).
# Uso dei segreti in Secrets Manager nelle funzioni Lambda
Gestione dei segreti AWS ti aiuta a gestire credenziali, chiavi API e altri segreti necessari alle tue funzioni Lambda. Esistono due approcci principali per il recupero dei segreti nelle funzioni Lambda, entrambi offrono prestazioni migliori e costi inferiori rispetto al recupero diretto dei segreti tramite l'SDK: AWS
+ **AWS parametri e segreti Estensione Lambda**: una soluzione indipendente dal runtime che fornisce una semplice interfaccia HTTP per il recupero dei segreti
+ **Powertools for AWS Lambda parameters utility**: una soluzione integrata nel codice che supporta più provider (Secrets Manager, Parameter Store AppConfig) con trasformazioni integrate
Entrambi gli approcci mantengono cache locali di segreti, eliminando la necessità per la funzione di chiamare Secrets Manager per ogni invocazione. Quando la funzione richiede un segreto, la cache viene controllata per prima. Se il segreto è disponibile e non è scaduto, viene restituito immediatamente. Altrimenti, viene recuperato da Secrets Manager, memorizzato nella cache e restituito. Questo meccanismo di memorizzazione nella cache consente tempi di risposta più rapidi e costi ridotti riducendo al minimo le chiamate API.
## Scelta di un approccio
Considerate questi fattori quando scegliete tra l'estensione e: PowerTools
Usa l'estensione Lambda AWS Parametri e segreti quando:
+ Vuoi una soluzione indipendente dal runtime che funzioni con qualsiasi runtime Lambda
+ Preferisci non aggiungere dipendenze di codice alla tua funzione
+ Devi solo recuperare i segreti da Secrets Manager o Parameter Store
Utilizzate Powertools per l'utilità AWS Lambda dei parametri quando:
+ Vuoi un'esperienza di sviluppo integrata con il codice dell'applicazione
+ È necessario il supporto per più provider (Secrets Manager, Parameter Store, AppConfig)
+ Desideri trasformazioni di dati integrate (analisi JSON, decodifica base64)
+ Stai usando i runtime Python TypeScript, Java o.NET
## Quando usare Secrets Manager con Lambda
Gli scenari più comuni per l'utilizzo di Secrets Manager con Lambda includono:
+ Memorizzazione delle credenziali del database utilizzate dalla funzione per connettersi ad Amazon RDS o ad altri database
+ Gestione delle chiavi API per i servizi esterni chiamati dalle tue funzioni
+ Memorizzazione delle chiavi di crittografia o di altri dati di configurazione sensibili
+ Rotazione automatica delle credenziali senza dover aggiornare il codice della funzione
## Utilizzo dei AWS parametri e dei segreti (estensione Lambda)
L'estensione Lambda AWS Parameters and Secrets utilizza una semplice interfaccia HTTP compatibile con qualsiasi runtime Lambda. Per impostazione predefinita, memorizza nella cache i segreti per 300 secondi (5 minuti) e può contenere fino a 1.000 segreti. Puoi [personalizzare queste impostazioni con variabili di ambiente](#lambda-secrets-manager-env-vars).
### Usa Secrets Manager in una funzione Lambda
Questa sezione presuppone che tu abbia già un segreto Secrets Manager. Per creare un segreto, consulta [Creare un Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) segreto.
#### Creazione del pacchetto di implementazione
Scegli il tuo runtime preferito e segui i passaggi per creare una funzione che recuperi segreti da Secrets Manager. La funzione di esempio recupera un segreto da Secrets Manager e può essere utilizzata per accedere alle credenziali del database, alle chiavi API o ad altri dati di configurazione sensibili nelle applicazioni.
------
#### [ Python ]
**Per creare una funzione Python**
1. Crea e vai in una nuova directory di progetto. Esempio:
```
mkdir my_function
cd my_function
```
1. Crea un file denominato `lambda_function.py` con il codice seguente. Per `secret_name`, utilizza il nome o il nome della risorsa Amazon (ARN) del segreto.
```
import json
import os
import requests
def lambda_handler(event, context):
try:
# Replace with the name or ARN of your secret
secret_name = "arn:aws:secretsmanager:us-east-1:111122223333:secret:SECRET_NAME"
secrets_extension_endpoint = f"http://localhost:2773/secretsmanager/get?secretId={secret_name}"
headers = {"X-Aws-Parameters-Secrets-Token": os.environ.get('AWS_SESSION_TOKEN')}
response = requests.get(secrets_extension_endpoint, headers=headers)
print(f"Response status code: {response.status_code}")
secret = json.loads(response.text)["SecretString"]
print(f"Retrieved secret: {secret}")
return {
'statusCode': response.status_code,
'body': json.dumps({
'message': 'Successfully retrieved secret',
'secretRetrieved': True
})
}
except Exception as e:
print(f"Error: {str(e)}")
return {
'statusCode': 500,
'body': json.dumps({
'message': 'Error retrieving secret',
'error': str(e)
})
}
```
1. Creare un file denominato `requirements.txt` con il seguente contenuto:
```
requests
```
1. Installare le dipendenze:
```
pip install -r requirements.txt -t .
```
1. Crea un file .zip contenente tutti i file:
```
zip -r function.zip .
```
------
#### [ Node.js ]
**Per creare una funzione Node.js.**
1. Crea e vai in una nuova directory di progetto. Esempio:
```
mkdir my_function
cd my_function
```
1. Crea un file denominato `index.mjs` con il codice seguente. Per `secret_name`, utilizza il nome o il nome della risorsa Amazon (ARN) del segreto.
```
import http from 'http';
export const handler = async (event) => {
try {
// Replace with the name or ARN of your secret
const secretName = "arn:aws:secretsmanager:us-east-1:111122223333:secret:SECRET_NAME";
const options = {
hostname: 'localhost',
port: 2773,
path: `/secretsmanager/get?secretId=${secretName}`,
headers: {
'X-Aws-Parameters-Secrets-Token': process.env.AWS_SESSION_TOKEN
}
};
const response = await new Promise((resolve, reject) => {
http.get(options, (res) => {
let data = '';
res.on('data', (chunk) => { data += chunk; });
res.on('end', () => {
resolve({
statusCode: res.statusCode,
body: data
});
});
}).on('error', reject);
});
const secret = JSON.parse(response.body).SecretString;
console.log('Retrieved secret:', secret);
return {
statusCode: response.statusCode,
body: JSON.stringify({
message: 'Successfully retrieved secret',
secretRetrieved: true
})
};
} catch (error) {
console.error('Error:', error);
return {
statusCode: 500,
body: JSON.stringify({
message: 'Error retrieving secret',
error: error.message
})
};
}
};
```
1. Crea un file .zip contenente il file `index.mjs`:
```
zip -r function.zip index.mjs
```
------
#### [ Java ]
**Per creare una funzione Java**
1. Crea un progetto Maven:
```
mvn archetype:generate \
-DgroupId=example \
-DartifactId=lambda-secrets-demo \
-DarchetypeArtifactId=maven-archetype-quickstart \
-DarchetypeVersion=1.4 \
-DinteractiveMode=false
```
1. Vai alla directory del progetto:
```
cd lambda-secrets-demo
```
1. Apri `pom.xml` e sostituisci il contenuto con quanto riportato di seguito.
```
4.0.0
example
lambda-secrets-demo
1.0-SNAPSHOT
11
11
com.amazonaws
aws-lambda-java-core
1.2.1
org.apache.maven.plugins
maven-shade-plugin
3.2.4
package
shade
false
function
```
1. Rinomina `/lambda-secrets-demo/src/main/java/example/App.java` in `Hello.java` in modo che corrisponda al nome del gestore Java predefinito di Lambda (`example.Hello::handleRequest`):
```
mv src/main/java/example/App.java src/main/java/example/Hello.java
```
1. Apri il file `Hello.java` e sostituisci il contenuto con quanto riportato di seguito. Per `secretName`, utilizza il nome o il nome della risorsa Amazon (ARN) del segreto.
```
package example;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
public class Hello implements RequestHandler {
private final HttpClient client = HttpClient.newHttpClient();
@Override
public String handleRequest(Object input, Context context) {
try {
// Replace with the name or ARN of your secret
String secretName = "arn:aws:secretsmanager:us-east-1:111122223333:secret:SECRET_NAME";
String endpoint = "http://localhost:2773/secretsmanager/get?secretId=" + secretName;
HttpRequest request = HttpRequest.newBuilder()
.uri(URI.create(endpoint))
.header("X-Aws-Parameters-Secrets-Token", System.getenv("AWS_SESSION_TOKEN"))
.GET()
.build();
HttpResponse response = client.send(request,
HttpResponse.BodyHandlers.ofString());
String secret = response.body();
secret = secret.substring(secret.indexOf("SecretString") + 15);
secret = secret.substring(0, secret.indexOf("\""));
System.out.println("Retrieved secret: " + secret);
return String.format(
"{\"statusCode\": %d, \"body\": \"%s\"}",
response.statusCode(), "Successfully retrieved secret"
);
} catch (Exception e) {
e.printStackTrace();
return String.format(
"{\"body\": \"Error retrieving secret: %s\"}",
e.getMessage()
);
}
}
}
```
1. Rimuovi la directory di test. Maven la crea per impostazione predefinita, ma non ne abbiamo bisogno per questo esempio.
```
rm -rf src/test
```
1. Compila il progetto:
```
mvn package
```
1. Scarica il file JAR (`target/function.jar`) per un uso successivo.
------
#### Creazione della funzione
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegli **Crea funzione**.
1. Scegli **Crea da zero**.
1. Nel campo **Function name (Nome funzione)**, immettere **secret-retrieval-demo**.
1. Scegli il **runtime** preferito.
1. Scegli **Crea funzione**.
**Per caricare il pacchetto di implementazione**
1. Nella scheda **Codice** della funzione, scegli **Carica da** e seleziona il **file.zip** (per Python e Node.js) **o.jar (per** Java).
1. Carica il pacchetto di implementazione creato in precedenza.
1. Scegli **Save** (Salva).
#### Aggiunta dell'estensione
**Per aggiungere l'estensione Lambda AWS Parameters and Secrets come livello**
1. Nella scheda **Codice** della funzione, scorri verso il basso fino a **Livelli**.
1. Scegliere **Add a layer (Aggiungi un livello)**.
1. Seleziona **AWS livelli**.
1. Scegli **AWS-Parameters-and-Secrets-Lambda-Extension**.
1. Scegli la versione più recente.
1. Scegliere **Aggiungi**.
#### Aggiunta di autorizzazioni
**Per aggiungere i permessi di Secrets Manager al ruolo di esecuzione**
1. Quindi, seleziona la scheda **Configuration** (Configurazione) e poi **Permissions** (Autorizzazioni).
1. In **Nome del ruolo**, scegli il link al tuo ruolo di esecuzione. Questo ruolo si apre nella console IAM.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/execution-role-console.png)
1. Scegli **Aggiungi autorizzazioni**, quindi seleziona **Crea policy in linea**.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/create-inline-policy.png)
1. Scegli la scheda **JSON** e aggiungi la policy seguente. Per `Resource`, inserisci l'ARN del tuo segreto.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:us-east-1:111122223333:secret:SECRET_NAME"
}
]
}
```
------
1. Scegli **Next (Successivo)**.
1. Inserisci un nome per la policy.
1. Scegli **Crea policy**.
#### Test della funzione
**Per testare la funzione**
1. Torna alla console Lambda.
1. Seleziona la scheda **Test**.
1. Scegli **Test (Esegui test)**. Dovrebbe essere visualizzata la seguente risposta:
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/execution-results-secret.png)
### Variabili di ambiente
L'estensione Lambda AWS Parameters and Secrets utilizza le seguenti impostazioni predefinite. Puoi sovrascrivere queste impostazioni creando le variabili [ambiente corrispondenti.](configuration-envvars.md#create-environment-variables) Per visualizzare le impostazioni correnti di una funzione, imposta `PARAMETERS_SECRETS_EXTENSION_LOG_LEVEL` su `DEBUG`. L'estensione registrerà le informazioni di configurazione in CloudWatch Logs all'inizio di ogni chiamata di funzione.
| Impostazione | Valore predefinito | Valori validi | Variabile di ambiente | Informazioni |
| --- | --- | --- | --- | --- |
| Porta HTTP | 2773 | 1 - 65535 | PARAMETERS\$1SECRETS\$1EXTENSION\$1HTTP\$1PORT | Porta per il server HTTP locale |
| Cache abilitata | TRUE | TRUE \$1 FALSE | PARAMETERS\$1SECRETS\$1EXTENSION\$1CACHE\$1ENABLED | Abilita o disabilita la cache |
| Dimensioni della cache | 1000 | 0 - 1.000 | PARAMETERS\$1SECRETS\$1EXTENSION\$1CACHE\$1SIZE | Imposta su 0 per disabilitare la memorizzazione nella cache |
| TTL di Secrets Manager. | 300 secondi | 0 - 300 secondi | SECRETS\$1MANAGER\$1TTL | Time-to-live per segreti memorizzati nella cache. Imposta su 0 per disabilitare la memorizzazione nella cache. Questa variabile viene ignorata se il valore per PARAMETERS\$1SECRETS\$1EXTENSION\$1CACHE\$1SIZE è 0. |
| TTL Parameter Store | 300 secondi | 0 - 300 secondi | SSM\$1PARAMETER\$1STORE\$1TTL | Time-to-live per i parametri memorizzati nella cache. Imposta su 0 per disabilitare la memorizzazione nella cache. Questa variabile viene ignorata se il valore per PARAMETERS\$1SECRETS\$1EXTENSION\$1CACHE\$1SIZE è 0. |
| Livello di log | INFO | DEBUG \$1 INFO \$1 WARN \$1 ERROR \$1 NONE | PARAMETERS\$1SECRETS\$1EXTENSION\$1LOG\$1LEVEL | Il livello di dettaglio riportato nei log per l'estensione |
| Connessioni max | 3 | Uguale o maggiore di 1 | PARAMETERS\$1SECRETS\$1EXTENSION\$1MAX\$1CONNECTIONS | Numero massimo di connessioni HTTP per richieste a Parameter Store o Secrets Manager |
| Timeout di Secrets Manager | 0 (nessun timeout) | Tutti i numeri interi | SECRETS\$1MANAGER\$1TIMEOUT\$1MILLIS | Timeout per le richieste a Secrets Manager (in millisecondi) |
| Timeout Parameter Store | 0 (nessun timeout) | Tutti i numeri interi | SSM\$1PARAMETER\$1STORE\$1TIMEOUT\$1MILLIS | Timeout per le richieste a Parameter Store (in millisecondi). |
### Operazioni con rotazione di un segreto
Se ruoti spesso i segreti, la durata predefinita di 300 secondi della cache potrebbe far sì che la funzione utilizzi segreti obsoleti. Sono disponibili due opzioni per garantire che la funzione utilizzi il valore segreto più recente:
+ Ridurre il TTL della cache impostando la variabile di ambiente `SECRETS_MANAGER_TTL` su un valore inferiore (in secondi). Ad esempio, impostandolo su `60` garantire che la funzione non utilizzi mai un segreto vecchio più di un minuto.
+ Usare le etichette temporanee `AWSCURRENT` o `AWSPREVIOUS` nella tua richiesta di segreto per assicurarti di ottenere la versione specifica che desideri:
```
secretsmanager/get?secretId=YOUR_SECRET_NAME&versionStage=AWSCURRENT
```
Scegli l'approccio che meglio bilancia le tue esigenze di prestazioni e aggiornamento. Un TTL inferiore significa chiamate più frequenti a Secrets Manager, ma garantisce l'utilizzo dei valori segreti più recenti.
## Utilizzo dell'utilità di parametrizzazione di Powertools per AWS Lambda
L'utilità dei parametri di Powertools for AWS Lambda fornisce un'interfaccia unificata per il recupero di segreti da più provider, tra cui Secrets Manager, Parameter Store e. AppConfig Gestisce la memorizzazione nella cache, le trasformazioni e offre un'esperienza di sviluppo più integrata rispetto all'approccio di estensione.
### Vantaggi dell'utilità parametri
+ **Provider multipli**: recupera i parametri da Secrets Manager, Parameter Store e AppConfig utilizza la stessa interfaccia
+ **Trasformazioni integrate**: analisi JSON automatica, decodifica base64 e altre trasformazioni dei dati
+ **Memorizzazione nella cache integrata**: memorizzazione nella cache configurabile con supporto TTL per ridurre le chiamate API
+ **Sicurezza dei tipi**: forte supporto alla digitazione in altri TypeScript runtime supportati
+ **Gestione degli errori**: logica di ripetizione dei tentativi e gestione degli errori integrate
### Esempi di codice
Negli esempi seguenti viene illustrato come recuperare i segreti utilizzando l'utilità Parametri in runtime diversi:
**Python**
Per esempi completi e istruzioni di configurazione, consulta la [documentazione dell'utilità Parametri](https://docs.powertools.aws.dev/lambda/python/latest/utilities/parameters/).
Recupero di segreti da Secrets Manager con l'utilità Powertools for AWS Lambda Parameters.
```
from aws_lambda_powertools import Logger
from aws_lambda_powertools.utilities import parameters
logger = Logger()
def lambda_handler(event, context):
try:
# Get secret with caching (default TTL: 5 seconds)
secret_value = parameters.get_secret("my-secret-name")
# Get secret with custom TTL
secret_with_ttl = parameters.get_secret("my-secret-name", max_age=300)
# Get secret and transform JSON
secret_json = parameters.get_secret("my-json-secret", transform="json")
logger.info("Successfully retrieved secrets")
return {
'statusCode': 200,
'body': 'Successfully retrieved secrets'
}
except Exception as e:
logger.error(f"Error retrieving secret: {str(e)}")
return {
'statusCode': 500,
'body': f'Error: {str(e)}'
}
```
**TypeScript**
Per esempi completi e istruzioni di configurazione, consulta la [documentazione dell'utilità Parametri](https://docs.aws.amazon.com/powertools/typescript/2.1.1/utilities/parameters/).
Recupero di segreti da Secrets Manager con l'utilità Powertools for AWS Lambda Parameters.
```
import { Logger } from '@aws-lambda-powertools/logger';
import { getSecret } from '@aws-lambda-powertools/parameters/secrets';
import type { Context } from 'aws-lambda';
const logger = new Logger();
export const handler = async (event: any, context: Context) => {
try {
// Get secret with caching (default TTL: 5 seconds)
const secretValue = await getSecret('my-secret-name');
// Get secret with custom TTL
const secretWithTtl = await getSecret('my-secret-name', { maxAge: 300 });
// Get secret and transform JSON
const secretJson = await getSecret('my-json-secret', { transform: 'json' });
logger.info('Successfully retrieved secrets');
return {
statusCode: 200,
body: 'Successfully retrieved secrets'
};
} catch (error) {
logger.error('Error retrieving secret', { error });
return {
statusCode: 500,
body: `Error: ${error}`
};
}
};
```
**Java**
Per esempi completi e istruzioni di configurazione, consulta la [documentazione dell'utilità Parametri](https://docs.powertools.aws.dev/lambda/java/latest/utilities/parameters/).
Recupero di segreti da Secrets Manager con l'utilità Powertools for AWS Lambda Parameters.
```
import software.amazon.lambda.powertools.logging.Logging;
import software.amazon.lambda.powertools.parameters.SecretsProvider;
import software.amazon.lambda.powertools.parameters.ParamManager;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
public class SecretHandler implements RequestHandler {
private final SecretsProvider secretsProvider = ParamManager.getSecretsProvider();
@Logging
@Override
public String handleRequest(Object input, Context context) {
try {
// Get secret with caching (default TTL: 5 seconds)
String secretValue = secretsProvider.get("my-secret-name");
// Get secret with custom TTL (300 seconds)
String secretWithTtl = secretsProvider.withMaxAge(300).get("my-secret-name");
// Get secret and transform JSON
MySecret secretJson = secretsProvider.get("my-json-secret", MySecret.class);
return "Successfully retrieved secrets";
} catch (Exception e) {
return "Error retrieving secret: " + e.getMessage();
}
}
public static class MySecret {
// Define your secret structure here
}
}
```
**.NET**
Per esempi completi e istruzioni di configurazione, consulta la [documentazione dell'utilità Parametri](https://docs.aws.amazon.com/powertools/typescript/latest/features/parameters/).
Recupero di segreti da Secrets Manager con l'utilità Powertools for AWS Lambda Parameters.
```
using AWS.Lambda.Powertools.Logging;
using AWS.Lambda.Powertools.Parameters;
using Amazon.Lambda.Core;
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
public class Function
{
private readonly ISecretsProvider _secretsProvider;
public Function()
{
_secretsProvider = ParametersManager.SecretsProvider;
}
[Logging]
public async Task FunctionHandler(object input, ILambdaContext context)
{
try
{
// Get secret with caching (default TTL: 5 seconds)
var secretValue = await _secretsProvider.GetAsync("my-secret-name");
// Get secret with custom TTL
var secretWithTtl = await _secretsProvider.WithMaxAge(TimeSpan.FromMinutes(5))
.GetAsync("my-secret-name");
// Get secret and transform JSON
var secretJson = await _secretsProvider.GetAsync("my-json-secret");
return "Successfully retrieved secrets";
}
catch (Exception e)
{
return $"Error retrieving secret: {e.Message}";
}
}
public class MySecret
{
// Define your secret structure here
}
}
```
### Configurazione e autorizzazioni
Per utilizzare l'utilità Parametri, devi:
1. Installa Powertools per AWS Lambda il tuo runtime. Per informazioni dettagliate, vedi [Utensili elettrici per AWS Lambda](powertools-for-lambda.md).
1. Aggiungere le autorizzazioni IAM necessarie al ruolo di esecuzione della tua funzione. Fare riferimento a [Gestione delle autorizzazioni in AWS Lambda](lambda-permissions.md) per ulteriori dettagli.
1. Configura eventuali impostazioni opzionali tramite [variabili di ambiente](configuration-envvars.md).
Le autorizzazioni IAM richieste sono le stesse dell'approccio di estensione. L'utilità gestirà automaticamente la memorizzazione nella cache e le chiamate API a Secrets Manager in base alla configurazione dell'utente.
# Utilizzo di Lambda con Amazon SQS
**Nota**
[Se desideri inviare dati a una destinazione diversa da una funzione Lambda o arricchire i dati prima di inviarli, consulta Amazon Pipes. EventBridge ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-pipes.html)
È possibile utilizzare una funzione Lambda per elaborare i messaggi in una coda Amazon Simple Queue Service (Amazon SQS). Lambda supporta sia [code standard](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/standard-queues.html) che [code first-in, first-out (FIFO)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues.html) per gli [strumenti di mappatura dell'origine degli eventi](invocation-eventsourcemapping.md). Puoi anche utilizzare la modalità provisioned per allocare risorse di polling dedicate per le mappature delle sorgenti degli eventi Amazon SQS. [La funzione Lambda e la coda Amazon SQS devono trovarsi nella Regione AWS stessa posizione, anche se possono trovarsi in posizioni diverse. Account AWS](with-sqs-cross-account-example.md)
Durante l'elaborazione di messaggi Amazon SQS, è necessario implementare una logica di risposta batch parziale per evitare che i messaggi elaborati correttamente vengano ritentati quando alcuni messaggi di un batch falliscono. L'[utilità Batch Processor](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/) di Powertools AWS Lambda semplifica questa implementazione gestendo automaticamente la logica di risposta batch parziale, riducendo i tempi di sviluppo e migliorando l'affidabilità.
**Topics**
+ [
## Informazioni sul comportamento di polling e batch per gli strumenti di mappatura dell'origine degli eventi di Amazon SQS
](#sqs-polling-behavior)
+ [
## Utilizzo della modalità provisioning con le mappature delle sorgenti degli eventi di Amazon SQS
](#sqs-provisioned-mode)
+ [
## Configurazione della modalità di provisioning per la mappatura delle sorgenti degli eventi Amazon SQS
](#sqs-configuring-provisioned-mode)
+ [
## Esempio di evento con messaggio di coda standard
](#example-standard-queue-message-event)
+ [
## Esempio di evento di messaggio di coda FIFO
](#sample-fifo-queues-message-event)
+ [
# Creazione e configurazione di uno strumento di mappatura dell'origine degli eventi Amazon SQS
](services-sqs-configure.md)
+ [
# Configurazione del comportamento di dimensionamento per gli strumenti di mappatura dell'origine degli eventi
](services-sqs-scaling.md)
+ [
# Gestione degli errori per un'origine eventi SQS in Lambda
](services-sqs-errorhandling.md)
+ [
# Parametri Lambda per gli strumenti di mappatura dell'origine degli eventi di Amazon SQS
](services-sqs-parameters.md)
+ [
# Utilizzo del filtro eventi con un'origine eventi Amazon SQS
](with-sqs-filtering.md)
+ [
# Tutorial: Utilizzo di Lambda con Amazon SQS
](with-sqs-example.md)
+ [
# Tutorial: utilizzo di una coda Amazon SQS tra più account come origine eventi
](with-sqs-cross-account-example.md)
## Informazioni sul comportamento di polling e batch per gli strumenti di mappatura dell'origine degli eventi di Amazon SQS
Con gli strumenti di mappatura dell'origine degli eventi di Amazon SQS, Lambda esegue il polling della coda e richiama la funzione [in modo sincrono](invocation-sync.md) con un evento. Ogni evento può contenere un batch di più messaggi dalla coda. Lambda riceve questi eventi un batch alla volta e richiama la funzione una volta per ogni batch. Quando la funzione elabora correttamente un batch, Lambda elimina i relativi messaggi dalla coda.
Quando Lambda legge un batch, i messaggi rimangono nella coda ma vengono nascosti per la durata del [timeout visibilità](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html) della coda. Se la funzione elabora correttamente tutti i messaggi nel batch, Lambda elimina i messaggi dalla coda. Per impostazione predefinita, se la funzione rileva un errore durante l'elaborazione di un batch, una volta scaduto il timeout di visibilità tutti i messaggi in quel batch diventeranno nuovamente visibili nella coda. Per questo motivo, il codice della funzione deve riuscire a elaborare lo stesso messaggio più volte, senza intoppi indesiderati.
**avvertimento**
Gli strumenti di mappatura dell'origine degli eventi elaborano ogni evento almeno una volta e può verificarsi un'elaborazione duplicata dei record. Per evitare potenziali problemi legati agli eventi duplicati, ti consigliamo vivamente di rendere idempotente il codice della funzione. Per ulteriori informazioni, consulta [Come posso rendere idempotente la mia funzione Lambda](https://repost.aws/knowledge-center/lambda-function-idempotent) nel Knowledge Center. AWS
Per impedire a Lambda di elaborare un messaggio più volte, puoi configurare la mappatura dell'origine degli eventi per includere gli [errori degli elementi in batch](services-sqs-errorhandling.md#services-sqs-batchfailurereporting) nella risposta della funzione oppure puoi utilizzare l'[DeleteMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteMessage.html)API per rimuovere i messaggi dalla coda man mano che la funzione Lambda li elabora correttamente.
Per ulteriori informazioni sui parametri di configurazione supportati da Lambda per gli strumenti di mappatura dell'origine degli eventi di SQS, consulta [Creazione di uno strumento di mappatura dell'origine degli eventi SQS](services-sqs-configure.md#events-sqs-eventsource).
## Utilizzo della modalità provisioning con le mappature delle sorgenti degli eventi di Amazon SQS
Per i carichi di lavoro in cui è necessario ottimizzare il throughput dello strumento di mappatura dell'origine degli eventi, è possibile utilizzare la modalità provisioning. In modalità provisioning, vengono definiti i limiti minimi e massimi per la quantità di poller di eventi assegnati. Questi poller di eventi con provisioning sono dedicati allo strumento di mappatura dell'origine degli eventi e possono gestire picchi di messaggi imprevisti tramite un dimensionamento automatico reattivo. La mappatura delle sorgenti di eventi di Amazon SQS configurata con la modalità Provisioned è 3 volte più veloce (fino a 1.000 richiami simultanei al minuto) e supporta una contemporaneità 16 volte superiore (fino a 20.000 richiami simultanei) rispetto alla funzionalità di mappatura delle sorgenti di eventi di Amazon SQS predefinita. Ti consigliamo di utilizzare la modalità provisioned per i carichi di lavoro basati su eventi di Amazon SQS che hanno requisiti prestazionali rigorosi, come le società di servizi finanziari che elaborano i feed di dati di mercato, le piattaforme di e-commerce che forniscono consigli personalizzati in tempo reale e le società di gioco che gestiscono le interazioni tra giocatori dal vivo. L'utilizzo della modalità provisioning comporta costi aggiuntivi. [Per i prezzi dettagliati, consulta la pagina dei prezzi.AWS Lambda](https://aws.amazon.com/lambda/pricing/)
Ogni event poller in modalità provisioned può gestire fino all'1% MB/s del throughput, fino a 10 chiamate simultanee o fino a 10 chiamate API di polling di Amazon SQS al secondo. L'intervallo di valori accettati per il numero minimo di event poller (MinimumPollers) è compreso tra 2 e 200, con il valore predefinito di 2. L'intervallo di valori accettati per il numero massimo di event poller (MaximumPollers) è compreso tra 2 e 2.000, con il valore predefinito di 200. MaximumPollers deve essere maggiore o uguale a. MinimumPollers
### Determinazione dei sondaggi di eventi richiesti
Per stimare il numero di event poller necessari per garantire prestazioni ottimali di elaborazione dei messaggi quando si utilizza la modalità provisioned per SQS ESM, raccogli le seguenti metriche per la tua applicazione: eventi SQS di picco al secondo che richiedono un'elaborazione a bassa latenza, dimensione media del payload degli eventi SQS, durata media della funzione Lambda e dimensione del batch configurato.
Innanzitutto puoi stimare il numero di eventi SQS al secondo (EPS) supportati da un event poller per il tuo carico di lavoro utilizzando la seguente formula:
```
EPS per event poller =
minimum(
ceiling(1024 / average event size in KB),
ceiling(10 / average function duration in seconds) * batch size,
min(100, 10 * batch size)
)
```
Quindi, puoi calcolare il numero minimo di poller richiesti utilizzando la formula seguente. Questo calcolo garantisce la disponibilità di una capacità sufficiente per gestire i requisiti di traffico di picco.
```
Required event pollers = (Peak number of events per second in Queue) / EPS per event poller
```
Prendiamo in considerazione un carico di lavoro con una dimensione del batch predefinita di 10, una dimensione media degli eventi di 3 KB, una durata media della funzione di 100 ms e un requisito per gestire 1.000 eventi al secondo. In questo scenario, ogni event poller supporterà circa 100 eventi al secondo (EPS). Pertanto, è necessario impostare un numero minimo di poller su 10 per gestire adeguatamente i requisiti di traffico di picco. Se il carico di lavoro ha le stesse caratteristiche ma la durata media della funzione è di 1 secondo, ogni poller supporterà solo 10 EPS, il che richiede la configurazione di almeno 100 poller per supportare 1.000 eventi al secondo a bassa latenza.
Ti consigliamo di utilizzare una dimensione batch predefinita pari o superiore a 10 per massimizzare l'efficienza dei poller di eventi in modalità provisioned. Le dimensioni dei batch più elevate consentono a ciascun poller di elaborare più eventi per chiamata, migliorando la produttività e l'efficienza in termini di costi. Quando pianificate la capacità dei poller del vostro evento, tenete conto dei potenziali picchi di traffico e valutate la possibilità di impostare il valore MinimumPollers leggermente più alto del minimo calcolato per fornire un buffer. Inoltre, monitora le caratteristiche del carico di lavoro nel tempo, poiché le modifiche alla dimensione dei messaggi, alla durata delle funzioni o ai modelli di traffico potrebbero richiedere modifiche alla configurazione del poller degli eventi per mantenere prestazioni ed efficienza dei costi ottimali. Per una pianificazione precisa della capacità, consigliamo di testare il carico di lavoro specifico per determinare l'EPS effettivo che ogni event poller può generare.
## Configurazione della modalità di provisioning per la mappatura delle sorgenti degli eventi Amazon SQS
Puoi configurare la modalità di provisioning per la mappatura delle sorgenti degli eventi Amazon SQS utilizzando la console o l'API Lambda.
**Per configurare la modalità di provisioning per una mappatura delle sorgenti di eventi Amazon SQS esistente (console)**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegli la funzione con la mappatura delle sorgenti degli eventi di Amazon SQS per cui desideri configurare la modalità di provisioning.
1. Scegli la scheda **Configurazione**, quindi scegli **Trigger**.
1. **Scegli la mappatura delle sorgenti degli eventi Amazon SQS per cui desideri configurare la modalità di provisioning, quindi scegli Modifica.**
1. In **Configurazione dello strumento di mappatura dell'origine degli eventi**, scegli **Configura la modalità provisioning**.
+ Per **Minimum event poller**, inserisci un valore compreso tra 2 e 200. Se non si specifica un valore, Lambda sceglie un valore predefinito pari a 2.
+ Per **Maximum event poller**, inserisci un valore compreso tra 2 e 2.000. Questo valore deve essere maggiore o uguale al valore specificato in **Numero minimo di poller di eventi**. Se non si specifica un valore, Lambda assegna il valore predefinito 200.
1. Scegli **Save** (Salva).
È possibile configurare la modalità di provisioning a livello di codice utilizzando l'`ProvisionedPollerConfig`oggetto in. `EventSourceMappingConfiguration` Ad esempio, il seguente comando `UpdateEventSourceMapping` CLI configura un `MinimumPollers` valore di 5 e un `MaximumPollers` valore di 100.
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--provisioned-poller-config '{"MinimumPollers": 5, "MaximumPollers": 100}'
```
Dopo aver configurato la modalità provisioning, puoi osservare l'utilizzo dei poller di eventi per il tuo carico di lavoro monitorando il parametro `ProvisionedPollers`. Per ulteriori informazioni, consulta Metriche di mappatura della fonte degli eventi.
Per disabilitare la modalità provisioning e tornare alla modalità predefinita (su richiesta), puoi utilizzare il seguente comando CLI`UpdateEventSourceMapping`:
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--provisioned-poller-config '{}'
```
**Nota**
La modalità provisioned non può essere utilizzata insieme all'impostazione della massima concorrenza. Quando si utilizza la modalità provisioned, è possibile controllare la massima concorrenza mediante il numero massimo di sondaggi di eventi.
Per ulteriori informazioni sulla configurazione della modalità provisioned, vedere. [Creazione e configurazione di uno strumento di mappatura dell'origine degli eventi Amazon SQS](services-sqs-configure.md)
## Esempio di evento con messaggio di coda standard
**Example Evento messaggio Amazon SQS (coda standard)**
```
{
"Records": [
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "Test message.",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {
"myAttribute": {
"stringValue": "myValue",
"stringListValues": [],
"binaryListValues": [],
"dataType": "String"
}
},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue",
"awsRegion": "us-east-2"
},
{
"messageId": "2e1424d4-f796-459a-8184-9c92662be6da",
"receiptHandle": "AQEBzWwaftRI0KuVm4tP+/7q1rGgNqicHq...",
"body": "Test message.",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082650636",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082650649"
},
"messageAttributes": {},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue",
"awsRegion": "us-east-2"
}
]
}
```
Per impostazione predefinita, Lambda eseguirà il polling di un massimo di 10 messaggi contemporaneamente nella coda e invierà il batch alla funzione. Per evitare di richiamare la funzione con un piccolo numero di record, è possibile configurare l'origine eventi per memorizzare nel buffer i record per un massimo di 5 minuti definendo un periodo di batch. Prima di richiamare la funzione, Lambda continua a eseguire il polling dei messaggi dalla coda standard fino alla scadenza del periodo di batch, al raggiungimento della [quota della dimensione del payload di richiesta](gettingstarted-limits.md) o al raggiungimento della dimensione massima per la configurazione di un batch.
Se stai utilizzando un periodo di batch e la tua coda SQS contiene un traffico molto basso, Lambda potrebbe attendere fino a 20 secondi prima di richiamare la tua funzione. Lo stesso vale anche se imposti un periodo di batch inferiore a 20 secondi.
**Nota**
In Java, potresti riscontrare errori di puntatore null durante la deserializzazione di JSON. Ciò potrebbe essere dovuto al modo in cui "Records" e "eventSourceARN" vengono convertiti dal mappatore di oggetti JSON.
## Esempio di evento di messaggio di coda FIFO
Per le code FIFO, i record contengono attributi aggiuntivi correlati alla deduplicazione e al sequenziamento.
**Example Evento messaggio Amazon SQS (coda FIFO)**
```
{
"Records": [
{
"messageId": "11d6ee51-4cc7-4302-9e22-7cd8afdaadf5",
"receiptHandle": "AQEBBX8nesZEXmkhsmZeyIE8iQAMig7qw...",
"body": "Test message.",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1573251510774",
"SequenceNumber": "18849496460467696128",
"MessageGroupId": "1",
"SenderId": "AIDAIO23YVJENQZJOL4VO",
"MessageDeduplicationId": "1",
"ApproximateFirstReceiveTimestamp": "1573251510774"
},
"messageAttributes": {},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:fifo.fifo",
"awsRegion": "us-east-2"
}
]
}
```
# Creazione e configurazione di uno strumento di mappatura dell'origine degli eventi Amazon SQS
Per elaborare i messaggi Amazon SQS con Lambda, configura la coda con le impostazioni appropriate, quindi crea uno strumento di mappatura dell'origine degli eventi Lambda.
**Topics**
+ [
## Configurazione di una coda da utilizzare con Lambda
](#events-sqs-queueconfig)
+ [
## Impostazione delle autorizzazioni del ruolo di esecuzione Lambda
](#events-sqs-permissions)
+ [
## Creazione di uno strumento di mappatura dell'origine degli eventi SQS
](#events-sqs-eventsource)
## Configurazione di una coda da utilizzare con Lambda
Se non disponi già di una coda Amazon SQS esistente, [creane una](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-create-queue.html) da utilizzare come origine eventi per la funzione Lambda. [La funzione Lambda e la coda Amazon SQS devono trovarsi nella Regione AWS stessa posizione, anche se possono trovarsi in posizioni diverse. Account AWS](with-sqs-cross-account-example.md)
Per concedere alla funzione il tempo necessario per elaborare ogni batch di record, imposta il [timeout di visibilità](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html) della coda di origine su un valore pari ad almeno sei volte il [timeout di configurazione](configuration-timeout.md) per la funzione. Il tempo aggiuntivo consente a Lambda di riprovare se l'esecuzione della funzione viene limitata durante l'elaborazione di un batch precedente.
**Nota**
Il timeout della funzione deve essere inferiore o uguale al timeout di visibilità della coda. Lambda convalida questo requisito quando si crea o si aggiorna una mappatura dell'origine degli eventi e restituisce un errore se il timeout della funzione supera il timeout di visibilità della coda.
Per impostazione predefinita, se Lambda rileva un errore in qualsiasi momento durante l'elaborazione di un batch, tutti i messaggi in quel batch ritorneranno nella coda. Dopo il [timeout di visibilità](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html), i messaggi diventano nuovamente visibili a Lambda. È possibile configurare lo strumento di mappatura dell'origine degli eventi in modo da utilizzare [risposte batch parziali](services-sqs-errorhandling.md#services-sqs-batchfailurereporting) per restituire alla coda solo i messaggi non riusciti. Se la funzione dovesse non riuscire più volte a elaborare un messaggio, Amazon SQS può inviarlo a una [coda DLQ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html). Ti consigliamo di impostare `maxReceiveCount` sulla [policy redrive](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html#policies-for-dead-letter-queues) della coda di origine su un valore pari almeno a 5. Ciò offre a Lambda alcune possibilità di riprovare prima di inviare i messaggi non riusciti direttamente alla coda DLQ.
## Impostazione delle autorizzazioni del ruolo di esecuzione Lambda
La policy [ AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html) AWS gestita include le autorizzazioni di cui Lambda ha bisogno per leggere dalla coda Amazon SQS. Puoi aggiungere questa policy gestita al [ruolo di esecuzione](lambda-intro-execution-role.md) della tua funzione.
Facoltativamente, se utilizzi una coda crittografata, devi anche aggiungere la seguente autorizzazione al tuo ruolo di esecuzione:
+ [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html)
## Creazione di uno strumento di mappatura dell'origine degli eventi SQS
Creare una mappatura dell'origine eventi per indicare a Lambda di inviare le voci dalla coda a una funzione Lambda. È possibile creare più mappature delle origini eventi per elaborare elementi da più code con una singola funzione. Quando Lambda richiama la funzione di destinazione, l'evento può contenere più voci, fino a una *dimensione batch* massima configurabile.
Per configurare la tua funzione per la lettura da Amazon SQS, collega la policy [ AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html) AWS gestita al tuo ruolo di esecuzione. Quindi, crea uno strumento di mappatura dell'origine degli eventi **SQS** dalla console utilizzando i seguenti passaggi.
**Per aggiungere le autorizzazioni e creare un trigger**
1. Aprire la pagina [Functions](https://console.aws.amazon.com/lambda/home#/functions) (Funzioni) della console Lambda.
1. Scegliere il nome della funzione.
1. Quindi, seleziona la scheda **Configuration** (Configurazione) e poi **Permissions** (Autorizzazioni).
1. In **Nome del ruolo**, scegli il link al tuo ruolo di esecuzione. Questo ruolo si apre nella console IAM.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/execution-role.png)
1. Seleziona **Aggiungi autorizzazioni**, quindi seleziona **Collega policy**.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/attach-policies.png)
1. Inserisci `AWSLambdaSQSQueueExecutionRole` nel campo di ricerca. Aggiungi questa policy al tuo ruolo di esecuzione. Si tratta di una policy AWS gestita che contiene le autorizzazioni di cui la funzione ha bisogno per leggere da una coda Amazon SQS. Per ulteriori informazioni su questa politica, consulta il *AWS Managed* Policy [ AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html)Reference.
1. Torna alla funzione nella console Lambda. In **Panoramica delle funzioni**, scegliere **Aggiungi trigger**.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/add-trigger.png)
1. Scegliere un tipo di trigger.
1. Configurare le opzioni richieste, quindi scegliere **Add (Aggiungi)**.
Lambda supporta le seguenti opzioni di configurazione per le origini eventi di Amazon SQS:
**Coda SQS**
La coda Amazon SQS da cui leggere i record. [La funzione Lambda e la coda Amazon SQS devono trovarsi nella Regione AWS stessa posizione, anche se possono trovarsi in posizioni diverse. Account AWS](with-sqs-cross-account-example.md)
**Abilita trigger**
Lo stato dello strumento di mappatura dell'origine degli eventi. L'opzione **Enable trigger** (Abilita trigger) è selezionata per impostazione predefinita.
**Dimensione batch**
Il numero massimo di record da inviare alla funzione in ogni batch. Per una coda standard il numero di registri può arrivare fino a 10.000. Per una coda FIFO il massimo è 10. Per un batch di dimensioni superiori a 10, è inoltre necessario la finestra batch (`MaximumBatchingWindowInSeconds`) su almeno 1 secondo.
Configura il [timeout della funzione](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/configurations#timeouts) per consentire il tempo necessario all'elaborazione di un intero batch di elementi. Se gli elementi richiedono tempi di elaborazione più lunghi, scegli un batch di dimensioni più piccole. Un batch di grandi dimensioni può migliorare l'efficienza per i carichi di lavoro molto veloci o con costi di gestione molto elevati. Se si configura la [concorrenza riservata](configuration-concurrency.md) sulla funzione, impostare un minimo di cinque esecuzioni simultanee per ridurre le probabilità di errori di limitazione (della larghezza di banda della rete) quando Lambda richiama la funzione.
Lambda passa tutti i registri del batch alla funzione in una singola chiamata, purché la dimensione totale degli eventi non superi la [quota della dimensione del payload di invocazione](gettingstarted-limits.md) per una invocazione sincrona (6 MB). Per ogni registro, vengono generati metadati sia da Lambda che da Amazon SQS. Questi metadati aggiuntivi vengono conteggiati per la dimensione totale del payload e possono far sì che il numero totale di registri inviati in un batch sia inferiore alla dimensione del batch configurato. I campi di metadati inviati da Amazon SQS possono essere di lunghezza variabile. Per ulteriori informazioni sui campi di metadati di Amazon SQS, consulta la documentazione sul funzionamento delle [ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)API nell'*Amazon Simple Queue* Service API Reference.
**Finestra batch**
Il tempo massimo in secondi per la raccolta dei record prima di richiamare la funzione. Questo parametro si applica solo alle code standard.
Se si utilizza un periodo batch superiore a 0 secondi, è necessario tenere conto dell'aumento del tempo di elaborazione nel [timeout di visibilità](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html) della coda. Si consiglia di impostare il timeout di visibilità della coda ad un tempo sei volte maggiore rispetto al [timeout della funzione](configuration-timeout.md), più il valore di `MaximumBatchingWindowInSeconds`. Ciò consente alla funzione Lambda di elaborare ogni batch di eventi e riprovare in caso di errore di throttling.
Quando i messaggi diventano disponibili, Lambda avvia l'elaborazione dei messaggi in batch. Lambda inizia a elaborare cinque batch alla volta con cinque chiamate simultanee della funzione. Se i messaggi sono ancora disponibili, Lambda aggiunge fino a 300 richiami simultanei della funzione al minuto, fino a un massimo di 1.250 richiami simultanei. Quando si utilizza la modalità provisioned, ogni event poller può gestire fino all'1% MB/s del throughput, fino a 10 richiami simultanei o fino a 10 chiamate API di polling di Amazon SQS al secondo. Lambda ridimensiona il numero di event poller tra il minimo e il massimo configurati, aggiungendo rapidamente fino a 1.000 richiami simultanei al minuto per fornire un'elaborazione a bassa latenza degli eventi Amazon SQS. Puoi controllare la scalabilità e la concorrenza tramite queste impostazioni minime e massime del poller degli eventi. Per ulteriori informazioni sul ridimensionamento e sulla concorrenza delle funzioni, consulta. [Informazioni sulla scalabilità della funzione Lambda](lambda-concurrency.md)
Per elaborare più messaggi, puoi ottimizzare la funzione Lambda per un maggiore throughput. Per ulteriori informazioni, consulta [Comprendere la AWS Lambda scalabilità con le code standard di Amazon SQS.](https://aws.amazon.com/blogs/compute/understanding-how-aws-lambda-scales-when-subscribed-to-amazon-sqs-queues/#:~:text=If there are more messages,messages from the SQS queue.)
**Criteri di filtro**
Aggiungi i criteri di filtro per controllare gli eventi che Lambda invia alla funzione per l'elaborazione. Per ulteriori informazioni, consulta [Controllare gli eventi che Lambda invia alla funzione](invocation-eventfiltering.md).
**Simultaneità massima**
Il numero massimo di funzioni simultanee che l'origine eventi può richiamare. Non può essere utilizzato con la modalità Provisioned Mode abilitata. Per ulteriori informazioni, consulta [Configurazione della simultaneità massima per le origini eventi di Amazon SQS](services-sqs-scaling.md#events-sqs-max-concurrency).
**Modalità assegnata**
Se abilitata, alloca risorse di polling dedicate per la mappatura delle sorgenti degli eventi. È possibile configurare il numero minimo (2-200) e massimo (2-2000) di sondaggi di eventi. Ogni event poller può gestire fino all'1% MB/sec del throughput, fino a 10 chiamate simultanee o fino a 10 chiamate API di polling di Amazon SQS al secondo.
Nota: non è possibile utilizzare contemporaneamente Provisioned Mode e Maximum Concurrency. Quando la modalità Provisioned Mode è abilitata, utilizza l'impostazione del numero massimo di poller per controllare la concorrenza.
# Configurazione del comportamento di dimensionamento per gli strumenti di mappatura dell'origine degli eventi
Puoi controllare il comportamento di scalabilità delle mappature delle sorgenti degli eventi di Amazon SQS tramite impostazioni di massima concorrenza o abilitando la modalità provisioning. Si tratta di opzioni che si escludono a vicenda.
Per impostazione predefinita, Lambda ridimensiona automaticamente i poller di eventi in base al volume dei messaggi. Quando abiliti la modalità provisioned, allochi un numero minimo e massimo di risorse di polling dedicate che rimangono pronte a gestire i modelli di traffico previsti. Ciò consente di ottimizzare le prestazioni della mappatura delle sorgenti degli eventi in due modi:
+ Modalità standard (impostazione predefinita): Lambda gestisce automaticamente la scalabilità, a partire da un numero limitato di poller e aumentando o diminuendo in base al carico di lavoro.
+ Modalità provisioned: è possibile configurare risorse di polling dedicate con limiti minimi e massimi, che consentono una scalabilità 3 volte più veloce e una capacità di elaborazione fino a 16 volte superiore.
Per le code standard, Lambda utilizza il [long polling](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-short-and-long-polling.html#sqs-long-polling) per eseguire il polling di una coda fino a quando questa non diventa attiva. Quando sono disponibili dei messaggi, Lambda inizia a elaborare cinque batch alla volta con cinque chiamate simultanee della funzione. Se i messaggi sono ancora disponibili, Lambda aumenta il numero di processi che leggono i batch fino a 300 chiamate simultanee in più al minuto. Il numero massimo di richiami che una mappatura dell'origine degli eventi può elaborare contemporaneamente è 1.250. Quando il traffico è basso, Lambda ridimensiona l'elaborazione a cinque chiamate simultanee e può ottimizzarla fino a un minimo di 2 richiami simultanei per ridurre le chiamate Amazon SQS e i costi corrispondenti. Tuttavia, questa ottimizzazione non è disponibile quando si abilita l'impostazione della massima concorrenza.
Per le code FIFO, Lambda invia messaggi alla funzione nell'ordine in cui li riceve. Quando invii un messaggio a una coda FIFO, è necessario specificare un [ID gruppo di messaggi](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/using-messagegroupid-property.html). Amazon SQS garantisce che i messaggi dello stesso gruppo vengano consegnati a Lambda in ordine. Quando Lambda legge i messaggi in batch, ogni batch può contenere messaggi provenienti da più di un gruppo di messaggi, ma l'ordine dei messaggi viene mantenuto. Se la funzione restituisce un errore, questa esegue nuovamente tutti i tentativi necessari sui messaggi interessati, prima che Lambda riceva ulteriori messaggi dallo stesso gruppo.
Quando si utilizza la modalità provisioned, ogni event poller può gestire fino all'1% MB/sec del throughput, fino a 10 richiami simultanei o fino a 10 chiamate API di polling di Amazon SQS al secondo. Lambda ridimensiona il numero di event poller tra il minimo e il massimo configurati, aggiungendo rapidamente fino a 1.000 simultanee al minuto per fornire un'elaborazione coerente e a bassa latenza degli eventi Amazon SQS. L'utilizzo della modalità provisioning comporta costi aggiuntivi. [Per i prezzi dettagliati, consulta la pagina dei prezzi.AWS Lambda](https://aws.amazon.com/lambda/pricing/) Ogni event poller utilizza [lunghi sondaggi](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-short-and-long-polling.html) sulla coda SQS con un massimo di 10 sondaggi al secondo, il che comporta il costo delle richieste API SQS. Per ulteriori informazioni, consulta [i prezzi di Amazon SQS](https://aws.amazon.com/sqs/pricing/ ). Puoi controllare la scalabilità e la concorrenza tramite queste impostazioni minime e massime del poller di eventi, anziché utilizzare l'impostazione di concorrenza massima, poiché queste opzioni non possono essere utilizzate insieme.
**Nota**
Non è possibile utilizzare contemporaneamente l'impostazione di massima concorrenza e la modalità di provisioning. Quando la modalità provisioned è abilitata, puoi controllare la scalabilità e la concorrenza della mappatura delle sorgenti di eventi di Amazon SQS attraverso il numero minimo e massimo di event poller.
## Configurazione della simultaneità massima per le origini eventi di Amazon SQS
È possibile utilizzare l'impostazione di simultaneità massima per controllare il comportamento di dimensionamento delle origini eventi SQS. Tieni presente che non è possibile utilizzare la massima concorrenza con la modalità provisioning abilitata. L'impostazione della simultaneità massima limita il numero di istanze simultanee della funzione che l'origine dell'evento Amazon SQS può richiamare. La simultaneità massima è un'impostazione a livello di origine dell'evento. Se disponi di più origini degli eventi Amazon SQS mappate a una funzione, ogni origine di evento può avere un'impostazione di simultaneità massima separata. È possibile utilizzare la simultaneità massima per evitare che una coda utilizzi tutta la [simultaneità riservata](configuration-concurrency.md) della funzione o il resto della [quota di simultaneità dell'account](gettingstarted-limits.md). Non è previsto alcun addebito per la configurazione della simultaneità massima su un'origine di eventi Amazon SQS.
È importante sottolineare che la simultaneità massima e la simultaneità riservata sono due impostazioni indipendenti. Non è possibile impostare la simultaneità massima su un valore maggiore della simultaneità riservata della funzione. Dopo aver configurato la simultaneità massima, assicurati di non ridurre la simultaneità riservata della funzione a un valore inferiore alla simultaneità massima totale per tutte le origini di eventi Amazon SQS sulla funzione. Altrimenti, Lambda potrebbe limitare i messaggi.
Quando la quota di simultaneità del tuo account è impostata sul valore predefinito di 1.000, uno strumento di mappatura dell'origine degli eventi Amazon SQS può scalare per richiamare istanze di funzioni fino a questo valore, a meno che non si specifichi una simultaneità massima.
Se ricevi un aumento della quota di simultaneità predefinita del tuo account, Lambda potrebbe non essere in grado di richiamare istanze di funzioni simultanee fino alla tua nuova quota. Per impostazione predefinita, Lambda può scalare per richiamare fino a 1.250 istanze di funzioni simultanee per uno strumento di mappatura dell'origine degli eventi Amazon SQS. Se questo non è sufficiente per il tuo caso d'uso, contatta l' AWS assistenza per discutere di un aumento della contemporaneità di mappatura dei sorgenti degli eventi Amazon SQS del tuo account.
**Nota**
Per le code FIFO, le chiamate simultanee sono limitate dal numero di [gruppi di messaggi IDs](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/using-messagegroupid-property.html) () `messageGroupId` o dall'impostazione di concorrenza massima, a seconda di quale sia inferiore. Ad esempio, se avete sei gruppi di messaggi IDs e la concorrenza massima è impostata su 10, la funzione può avere un massimo di sei chiamate simultanee.
Puoi configurare la simultaneità massima sugli strumenti di mappatura dell'origine degli eventi Amazon SQS nuovi ed esistenti.
**Configurazione della simultaneità massima tramite la console Lambda**
1. Aprire la pagina [Functions](https://console.aws.amazon.com/lambda/home#/functions) (Funzioni) della console Lambda.
1. Scegliere il nome della funzione.
1. In **Function overview** (Panoramica delle funzioni), scegli **SQS**. Viene aperta la scheda **Configuration** (Configurazione).
1. Seleziona il trigger Amazon SQS e scegli **Edit** (Modifica).
1. In **Maximum concurrency** (Simultaneità massima), inserisci un numero compreso tra 2 e 1.000. Per disattivare la simultaneità massima, lascia la casella vuota.
1. Scegli **Save** (Salva).
**Configura la massima concorrenza utilizzando () AWS Command Line Interface AWS CLI**
Utilizza il comando [update-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-event-source-mapping.html) con l’opzione `--scaling-config`. Esempio:
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--scaling-config '{"MaximumConcurrency":5}'
```
Per disattivare la simultaneità massima, inserisci un valore vuoto per `--scaling-config`:
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--scaling-config "{}"
```
**Configurazione della simultaneità massima tramite l'API Lambda**
Usa l'[UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)azione [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)o con un [ScalingConfig](https://docs.aws.amazon.com/lambda/latest/api/API_ScalingConfig.html)oggetto.
# Gestione degli errori per un'origine eventi SQS in Lambda
Per gestire gli errori relativi a un'origine eventi SQS, Lambda utilizza automaticamente una strategia di riprova con una strategia di backoff. Puoi anche personalizzare il comportamento di gestione degli errori configurando lo strumento di mappatura dell'origine degli eventi SQS per restituire [risposte parziali in batch](#services-sqs-batchfailurereporting).
## Strategia di backoff per le chiamate non riuscite
Quando una chiamata non riesce, Lambda riprovare la chiamata mentre implementa una strategia di backoff. La strategia di backoff varia leggermente a seconda che Lambda abbia riscontrato l'errore a causa di un errore nel codice della funzione o a causa di una limitazione.
+ Se il **codice della funzione** ha causato l'errore, Lambda interromperà l'elaborazione e riproverà l'invocazione. Allo stesso tempo, Lambda si interrompe gradualmente, riducendo la quantità di simultaneità allocata allo strumento di mappatura dell'origine degli eventi di Amazon SQS. Una volta scaduto il timeout di visibilità della coda, il messaggio riapparirà nuovamente nella coda.
+ Se la chiamata non riesce a causa della **limitazione**, Lambda interrompe gradualmente i nuovi tentativi riducendo la quantità di simultaneità allocata allo strumento di mappatura dell'origine degli eventi di Amazon SQS. Lambda continua a riprovare il messaggio fino a quando il timestamp del messaggio non supera il timeout di visibilità della coda e a quel punto Lambda elimina il messaggio.
## Implementazione di risposte batch parziali
Per impostazione predefinita, se la funzione rileva un errore durante l'elaborazione di un batch, tutti i messaggi in quel batch diventano nuovamente visibili nella coda, inclusi i messaggi che Lambda ha elaborato correttamente. Di conseguenza, la tua funzione potrebbe elaborare lo stesso messaggio più volte.
Per evitare di rielaborare tutti i messaggi correttamente elaborati in un batch con errori, puoi configurare lo strumento di mappatura dell'origine degli eventi in modo da rendere nuovamente visibili solo i messaggi con errori. Questa operazione è nota come risposta batch parziale. Per attivare le risposte parziali in batch, specifica l'[FunctionResponseTypes](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html#lambda-UpdateEventSourceMapping-request-FunctionResponseTypes)azione durante `ReportBatchItemFailures` la configurazione della mappatura della fonte dell'evento. Ciò consente alla funzione di restituire un completamento parziale, riducendo così il numero di tentativi non necessari sui registri.
**Nota**
L'[utilità Batch Processor](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/) di Powertools AWS Lambda gestisce automaticamente tutta la logica di risposta batch parziale. Questa utilità semplifica l'implementazione dei modelli di elaborazione in batch e riduce il codice personalizzato necessario per gestire correttamente gli errori degli articoli in batch. È disponibile per Python, Java, Typescript e.NET.
Se `ReportBatchItemFailures` è attivata, Lambda non [riduce il polling dei messaggi](#services-sqs-backoff-strategy) quando le invocazioni delle funzioni hanno esito negativo. Se prevedi che alcuni messaggi falliscano e non desideri che tali errori influiscano sulla velocità di elaborazione dei messaggi, utilizza `ReportBatchItemFailures`.
**Nota**
Quando utilizzi le risposte batch, tieni presente quanto segue:
Se la funzione restituisce un'eccezione, l'intero batch viene considerato completamente non riuscito.
Se si utilizza questa caratteristica con una coda FIFO, la funzione dovrebbe interrompere l'elaborazione dei messaggi dopo il primo errore e restituire tutti i messaggi di errore e non elaborati in `batchItemFailures`. Ciò aiuta a preservare l'ordine dei messaggi nella coda.
**Attivazione di report batch parziali**
1. Rivedi le [best practice per l'implementazione di risposte batch parziali](https://docs.aws.amazon.com/prescriptive-guidance/latest/lambda-event-filtering-partial-batch-responses-for-sqs/best-practices-partial-batch-responses.html).
1. Per attivare `ReportBatchItemFailures` per la tua funzione, esegui il comando riportato di seguito. Per recuperare l'UUID della mappatura della sorgente degli eventi, esegui il comando. [list-event-source-mappings](https://docs.aws.amazon.com/cli/latest/reference/lambda/list-event-source-mappings.html) AWS CLI
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--function-response-types "ReportBatchItemFailures"
```
1. Aggiorna il codice della funzione per rilevare tutte le eccezioni e restituire i messaggi con errori in una risposta `batchItemFailures` in JSON. La `batchItemFailures` risposta deve includere un elenco di messaggi IDs, sotto forma di valori JSON. `itemIdentifier`
Ad esempio, supponiamo di avere un batch di cinque messaggi, IDs `id1`, `id2` `id3``id4`, e. `id5` La tua funzione elabora correttamente `id1`, `id3`, e `id5`. Per rendere i messaggi `id2` e `id4` di nuovo visibili nella coda, la funzione dovrebbe restituire la seguente risposta:
```
{
"batchItemFailures": [
{
"itemIdentifier": "id2"
},
{
"itemIdentifier": "id4"
}
]
}
```
Di seguito sono riportati alcuni esempi di codice di funzione che restituiscono l'elenco dei messaggi non riusciti IDs nel batch:
------
#### [ .NET ]
**SDK per .NET**
C'è altro su GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Segnalazione di errori di elementi batch di SQS con Lambda tramite .NET.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using Amazon.Lambda.Core;
using Amazon.Lambda.SQSEvents;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace sqsSample;
public class Function
{
public async Task FunctionHandler(SQSEvent evnt, ILambdaContext context)
{
List batchItemFailures = new List();
foreach(var message in evnt.Records)
{
try
{
//process your message
await ProcessMessageAsync(message, context);
}
catch (System.Exception)
{
//Add failed message identifier to the batchItemFailures list
batchItemFailures.Add(new SQSBatchResponse.BatchItemFailure{ItemIdentifier=message.MessageId});
}
}
return new SQSBatchResponse(batchItemFailures);
}
private async Task ProcessMessageAsync(SQSEvent.SQSMessage message, ILambdaContext context)
{
if (String.IsNullOrEmpty(message.Body))
{
throw new Exception("No Body in SQS Message.");
}
context.Logger.LogInformation($"Processed message {message.Body}");
// TODO: Do interesting work based on the new message
await Task.CompletedTask;
}
}
```
------
#### [ Go ]
**SDK per Go V2**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Segnalazione di errori di elementi batch di SQS con Lambda tramite Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package main
import (
"context"
"fmt"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func handler(ctx context.Context, sqsEvent events.SQSEvent) (map[string]interface{}, error) {
batchItemFailures := []map[string]interface{}{}
for _, message := range sqsEvent.Records {
if len(message.Body) > 0 {
// Your message processing condition here
fmt.Printf("Successfully processed message: %s\n", message.Body)
} else {
// Message processing failed
fmt.Printf("Failed to process message %s\n", message.MessageId)
batchItemFailures = append(batchItemFailures, map[string]interface{}{"itemIdentifier": message.MessageId})
}
}
sqsBatchResponse := map[string]interface{}{
"batchItemFailures": batchItemFailures,
}
return sqsBatchResponse, nil
}
func main() {
lambda.Start(handler)
}
```
------
#### [ Java ]
**SDK per Java 2.x**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Segnalazione di errori di elementi batch di SQS con Lambda tramite Java.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.SQSEvent;
import com.amazonaws.services.lambda.runtime.events.SQSBatchResponse;
import java.util.ArrayList;
import java.util.List;
public class ProcessSQSMessageBatch implements RequestHandler {
@Override
public SQSBatchResponse handleRequest(SQSEvent sqsEvent, Context context) {
List batchItemFailures = new ArrayList();
for (SQSEvent.SQSMessage message : sqsEvent.getRecords()) {
try {
//process your message
} catch (Exception e) {
//Add failed message identifier to the batchItemFailures list
batchItemFailures.add(new SQSBatchResponse.BatchItemFailure(message.getMessageId()));
}
}
return new SQSBatchResponse(batchItemFailures);
}
}
```
------
#### [ JavaScript ]
**SDK per JavaScript (v3)**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Segnalazione degli errori degli elementi batch SQS utilizzando Lambda. JavaScript
```
// Node.js 20.x Lambda runtime, AWS SDK for Javascript V3
export const handler = async (event, context) => {
const batchItemFailures = [];
for (const record of event.Records) {
try {
await processMessageAsync(record, context);
} catch (error) {
batchItemFailures.push({ itemIdentifier: record.messageId });
}
}
return { batchItemFailures };
};
async function processMessageAsync(record, context) {
if (record.body && record.body.includes("error")) {
throw new Error("There is an error in the SQS Message.");
}
console.log(`Processed message: ${record.body}`);
}
```
Segnalazione degli errori degli elementi batch SQS utilizzando Lambda. TypeScript
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import { SQSEvent, SQSBatchResponse, Context, SQSBatchItemFailure, SQSRecord } from 'aws-lambda';
export const handler = async (event: SQSEvent, context: Context): Promise => {
const batchItemFailures: SQSBatchItemFailure[] = [];
for (const record of event.Records) {
try {
await processMessageAsync(record);
} catch (error) {
batchItemFailures.push({ itemIdentifier: record.messageId });
}
}
return {batchItemFailures: batchItemFailures};
};
async function processMessageAsync(record: SQSRecord): Promise {
if (record.body && record.body.includes("error")) {
throw new Error('There is an error in the SQS Message.');
}
console.log(`Processed message ${record.body}`);
}
```
------
#### [ PHP ]
**SDK per PHP**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Segnalazione di errori di elementi batch di SQS con Lambda tramite PHP.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
logger = $logger;
}
/**
* @throws JsonException
* @throws \Bref\Event\InvalidLambdaEvent
*/
public function handleSqs(SqsEvent $event, Context $context): void
{
$this->logger->info("Processing SQS records");
$records = $event->getRecords();
foreach ($records as $record) {
try {
// Assuming the SQS message is in JSON format
$message = json_decode($record->getBody(), true);
$this->logger->info(json_encode($message));
// TODO: Implement your custom processing logic here
} catch (Exception $e) {
$this->logger->error($e->getMessage());
// failed processing the record
$this->markAsFailed($record);
}
}
$totalRecords = count($records);
$this->logger->info("Successfully processed $totalRecords SQS records");
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**SDK per Python (Boto3)**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Segnalazione di errori di elementi batch di SQS con Lambda tramite Python.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def lambda_handler(event, context):
if event:
batch_item_failures = []
sqs_batch_response = {}
for record in event["Records"]:
try:
print(f"Processed message: {record['body']}")
except Exception as e:
batch_item_failures.append({"itemIdentifier": record['messageId']})
sqs_batch_response["batchItemFailures"] = batch_item_failures
return sqs_batch_response
```
------
#### [ Ruby ]
**SDK per Ruby**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda-with-batch-item-handling).
Segnalazione di errori di elementi batch di SQS con Lambda tramite Ruby.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
require 'json'
def lambda_handler(event:, context:)
if event
batch_item_failures = []
sqs_batch_response = {}
event["Records"].each do |record|
begin
# process message
rescue StandardError => e
batch_item_failures << {"itemIdentifier" => record['messageId']}
end
end
sqs_batch_response["batchItemFailures"] = batch_item_failures
return sqs_batch_response
end
end
```
------
#### [ Rust ]
**SDK per Rust**
C'è altro da fare. GitHub Trova l'esempio completo e scopri come eseguire la configurazione e l'esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Segnalazione di errori di elementi batch di SQS con Lambda tramite Rust.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
use aws_lambda_events::{
event::sqs::{SqsBatchResponse, SqsEvent},
sqs::{BatchItemFailure, SqsMessage},
};
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
async fn process_record(_: &SqsMessage) -> Result<(), Error> {
Err(Error::from("Error processing message"))
}
async fn function_handler(event: LambdaEvent) -> Result {
let mut batch_item_failures = Vec::new();
for record in event.payload.records {
match process_record(&record).await {
Ok(_) => (),
Err(_) => batch_item_failures.push(BatchItemFailure {
item_identifier: record.message_id.unwrap(),
}),
}
}
Ok(SqsBatchResponse {
batch_item_failures,
})
}
#[tokio::main]
async fn main() -> Result<(), Error> {
run(service_fn(function_handler)).await
}
```
------
Se gli eventi non riusciti non tornano in coda, vedi [Come posso risolvere i problemi della funzione Lambda](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-sqs-report-batch-item-failures/) SQS? ReportBatchItemFailures nel Knowledge Center. AWS
### Condizioni di successo e di errore
Lambda considera un batch completamente riuscito se la funzione restituisce uno dei seguenti elementi:
+ Una `batchItemFailures` lista vuota
+ Un `batchItemFailures` elenco nullo
+ Un vuoto `EventResponse`
+ Un valore nullo `EventResponse`
Lambda considera un batch completamente non riuscito se la funzione restituisce uno dei seguenti elementi:
+ Risposta JSON non valida
+ Una stringa vuota `itemIdentifier`
+ Un valore nullo `itemIdentifier`
+ Un `itemIdentifier` con un nome chiave errato
+ Un `itemIdentifier` valore di con un ID messaggio inesistente
### CloudWatch metriche
Per determinare se la tua funzione riporta correttamente gli errori degli articoli in batch, puoi monitorare i parametri `NumberOfMessagesDeleted` e `ApproximateAgeOfOldestMessage` Amazon SQS in Amazon. CloudWatch
+ `NumberOfMessagesDeleted` tiene traccia del numero di messaggi rimossi dalla coda. Se questo scende a 0, significa che la risposta alla funzione non sta restituendo correttamente i messaggi non riusciti.
+ `ApproximateAgeOfOldestMessage` tiene traccia del tempo di permanenza del messaggio meno recente all'interno della coda. Un incremento considerevole di questo parametro può indicare che la funzione non sta restituendo correttamente i messaggi non riusciti.
### Utilizzo di Powertools per il processore batch AWS Lambda
L'utilità per il processore batch di Powertools gestisce AWS Lambda automaticamente la logica di risposta parziale in batch, riducendo la complessità dell'implementazione della segnalazione degli errori dei batch. Ecco alcuni esempi di utilizzo del processore batch:
**Python**
Per esempi completi e istruzioni di configurazione, consultate la [documentazione del processore batch](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/).
Elaborazione di messaggi Amazon SQS con processore AWS Lambda batch.
```
import json
from aws_lambda_powertools import Logger
from aws_lambda_powertools.utilities.batch import BatchProcessor, EventType, process_partial_response
from aws_lambda_powertools.utilities.data_classes import SQSEvent
from aws_lambda_powertools.utilities.typing import LambdaContext
processor = BatchProcessor(event_type=EventType.SQS)
logger = Logger()
def record_handler(record):
logger.info(record)
# Your business logic here
# Raise an exception to mark this record as failed
def lambda_handler(event, context: LambdaContext):
return process_partial_response(
event=event,
record_handler=record_handler,
processor=processor,
context=context
)
```
**TypeScript**
Per esempi completi e istruzioni di configurazione, consulta la [documentazione del processore batch](https://docs.aws.amazon.com/powertools/typescript/latest/features/batch/).
Elaborazione di messaggi Amazon SQS con processore AWS Lambda batch.
```
import { BatchProcessor, EventType, processPartialResponse } from '@aws-lambda-powertools/batch';
import { Logger } from '@aws-lambda-powertools/logger';
import type { SQSEvent, Context } from 'aws-lambda';
const processor = new BatchProcessor(EventType.SQS);
const logger = new Logger();
const recordHandler = async (record: any): Promise => {
logger.info('Processing record', { record });
// Your business logic here
// Throw an error to mark this record as failed
};
export const handler = async (event: SQSEvent, context: Context) => {
return processPartialResponse(event, recordHandler, processor, {
context,
});
};
```
# Parametri Lambda per gli strumenti di mappatura dell'origine degli eventi di Amazon SQS
Tutti i tipi di sorgenti di eventi Lambda condividono le stesse operazioni [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)e quelle dell'[UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)API. Tuttavia, solo alcuni dei parametri si applicano ad Amazon SQS.
| Parametro | Obbligatorio | Predefinito | Note |
| --- | --- | --- | --- |
| BatchSize | N | 10 | Per le code standard il massimo è 10.000. Per le code FIFO il massimo è 10. |
| Abilitato | N | true | nessuno |
| EventSourceArn | Y | N/D | L'ARN del flusso dei dati o di un consumatore di flusso |
| FunctionName | Y | N/D | nessuno |
| FilterCriteria | N | N/D | [Controllare gli eventi che Lambda invia alla funzione](invocation-eventfiltering.md) |
| FunctionResponseTypes | N | N/D | Per consentire alla funzione di segnalare errori specifici in un batch, includi il valore `ReportBatchItemFailures` in `FunctionResponseTypes`. Per ulteriori informazioni, consulta [Implementazione di risposte batch parziali](services-sqs-errorhandling.md#services-sqs-batchfailurereporting). |
| MaximumBatchingWindowInSeconds | N | 0 | La creazione di finestre di batch non è supportata per le code FIFO |
| ProvisionedPollerConfig | N | N/D | Configura il numero minimo (2-200) e massimo (2-2000) di poller di eventi dedicati per la mappatura delle sorgenti degli eventi SQS. Ogni poller può gestire fino all'1% del throughput e 10 richiami simultanei MB/sec . |
| ScalingConfig | N | N/D | [Configurazione della simultaneità massima per le origini eventi di Amazon SQS](services-sqs-scaling.md#events-sqs-max-concurrency) |
# Utilizzo del filtro eventi con un'origine eventi Amazon SQS
Puoi utilizzare il filtraggio degli eventi per controllare quali record di un flusso o di una coda Lambda invia alla funzione. Per informazioni generali sul funzionamento del filtraggio eventi, consulta [Controllare gli eventi che Lambda invia alla funzione](invocation-eventfiltering.md).
In questa sezione viene descritto il filtraggio degli eventi per le origini di eventi Amazon MQ.
**Nota**
Le mappature delle sorgenti degli eventi di Amazon SQS supportano solo il filtraggio sulla chiave. `body`
**Topics**
+ [
## Nozioni di base sul filtraggio degli eventi di Amazon SQS
](#filtering-SQS)
## Nozioni di base sul filtraggio degli eventi di Amazon SQS
Supponiamo che la coda Amazon SQS contenga messaggi nel formato JSON seguente.
```
{
"RecordNumber": 1234,
"TimeStamp": "yyyy-mm-ddThh:mm:ss",
"RequestCode": "AAAA"
}
```
Un record di esempio per questa coda sarebbe il seguente.
```
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "{\n "RecordNumber": 1234,\n "TimeStamp": "yyyy-mm-ddThh:mm:ss",\n "RequestCode": "AAAA"\n}",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-west-2:123456789012:my-queue",
"awsRegion": "us-west-2"
}
```
Per filtrare in base al contenuto dei messaggi Amazon SQS, utilizza la chiave `body` nel record dei messaggi Amazon SQS. Supponiamo di voler elaborare solo i record nei quali il `RequestCode` del messaggio Amazon SQS è "BBBB". L'oggetto `FilterCriteria` dovrebbe avere la struttura seguente.
```
{
"Filters": [
{
"Pattern": "{ \"body\" : { \"RequestCode\" : [ \"BBBB\" ] } }"
}
]
}
```
Per una maggiore chiarezza, ecco il valore del `Pattern` del filtro espanso in JSON semplice.
```
{
"body": {
"RequestCode": [ "BBBB" ]
}
}
```
Puoi aggiungere il filtro utilizzando la console, la AWS CLI o un modello AWS SAM.
------
#### [ Console ]
Per aggiungere questo filtro utilizzando la console, segui le istruzioni riportate in [Collegamento dei criteri di filtro a una mappatura dell'origine evento (console)](invocation-eventfiltering.md#filtering-console) e inserisci la seguente stringa per i **criteri di filtraggio**.
```
{ "body" : { "RequestCode" : [ "BBBB" ] } }
```
------
#### [ AWS CLI ]
Per creare una nuova mappatura dell'origine degli eventi con questi criteri di filtraggio utilizzando l'AWS Command Line Interface (AWS CLI), esegui il comando seguente.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:sqs:us-east-2:123456789012:my-queue \
--filter-criteria '{"Filters": [{"Pattern": "{ \"body\" : { \"RequestCode\" : [ \"BBBB\" ] } }"}]}'
```
Per aggiungere questi criteri di filtraggio a una mappatura dell'origine degli eventi esistente, esegui il comando seguente.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"body\" : { \"RequestCode\" : [ \"BBBB\" ] } }"}]}'
```
------
#### [ AWS SAM ]
Per aggiungere questo filtro utilizzando AWS SAM, aggiungi il seguente frammento al modello YAML dell'origine degli eventi.
```
FilterCriteria:
Filters:
- Pattern: '{ "body" : { "RequestCode" : [ "BBBB" ] } }'
```
------
Supponiamo che tu voglia che la tua funzione elabori solo i record in cui `RecordNumber` è maggiore di 9999. L'oggetto `FilterCriteria` dovrebbe avere la struttura seguente.
```
{
"Filters": [
{
"Pattern": "{ \"body\" : { \"RecordNumber\" : [ { \"numeric\": [ \">\", 9999 ] } ] } }"
}
]
}
```
Per una maggiore chiarezza, ecco il valore del `Pattern` del filtro espanso in JSON semplice.
```
{
"body": {
"RecordNumber": [
{
"numeric": [ ">", 9999 ]
}
]
}
}
```
Puoi aggiungere il filtro utilizzando la console, la AWS CLI o un modello AWS SAM.
------
#### [ Console ]
Per aggiungere questo filtro utilizzando la console, segui le istruzioni riportate in [Collegamento dei criteri di filtro a una mappatura dell'origine evento (console)](invocation-eventfiltering.md#filtering-console) e inserisci la seguente stringa per i **criteri di filtraggio**.
```
{ "body" : { "RecordNumber" : [ { "numeric": [ ">", 9999 ] } ] } }
```
------
#### [ AWS CLI ]
Per creare una nuova mappatura dell'origine degli eventi con questi criteri di filtraggio utilizzando l'AWS Command Line Interface (AWS CLI), esegui il comando seguente.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:sqs:us-east-2:123456789012:my-queue \
--filter-criteria '{"Filters": [{"Pattern": "{ \"body\" : { \"RecordNumber\" : [ { \"numeric\": [ \">\", 9999 ] } ] } }"}]}'
```
Per aggiungere questi criteri di filtraggio a una mappatura dell'origine degli eventi esistente, esegui il comando seguente.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"body\" : { \"RecordNumber\" : [ { \"numeric\": [ \">\", 9999 ] } ] } }"}]}'
```
------
#### [ AWS SAM ]
Per aggiungere questo filtro utilizzando AWS SAM, aggiungi il seguente frammento al modello YAML dell'origine degli eventi.
```
FilterCriteria:
Filters:
- Pattern: '{ "body" : { "RecordNumber" : [ { "numeric": [ ">", 9999 ] } ] } }'
```
------
Per Amazon SQS, il corpo del messaggio può essere qualsiasi stringa. Tuttavia, questo può essere problematico se il `FilterCriteria` si aspetta che `body` sia in un formato JSON valido. Anche lo scenario inverso è vero: se il corpo del messaggio in arrivo è in formato JSON ma i criteri di filtraggio si aspettano che `body` sia una stringa semplice, allora si potrebbe riscontrare un comportamento indesiderato.
Per evitare questo problema, assicurati che il formato del corpo nei `FilterCriteria` corrisponda al formato previsto per il `body` nei messaggi ricevuti dalla coda. Prima di filtrare i messaggi, Lambda valuta automaticamente il formato del corpo del messaggio in arrivo e il modello di filtraggio per `body`. In caso di mancata corrispondenza, Lambda rilascia il messaggio. La tabella seguente riepiloga questa valutazione:
| Formato `body` messaggio in arrivo | Formato `body` modello di filtro | Operazione risultante |
| --- | --- | --- |
| Stringa normale | Stringa normale | Filtri Lambda in base ai criteri di filtro. |
| Stringa normale | Nessun modello di filtro per le proprietà dei dati | Filtri Lambda (solo sulle altre proprietà dei metadati) in base ai criteri di filtro. |
| Stringa normale | JSON valido | Lambda rilascia il messaggio. |
| JSON valido | Stringa normale | Lambda rilascia il messaggio. |
| JSON valido | Nessun modello di filtro per le proprietà dei dati | Filtri Lambda (solo sulle altre proprietà dei metadati) in base ai criteri di filtro. |
| JSON valido | JSON valido | Filtri Lambda in base ai criteri di filtro. |
# Tutorial: Utilizzo di Lambda con Amazon SQS
In questo tutorial creerai una funzione Lambda che utilizza messaggi da una coda di [Amazon Simple Queue Service (Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html). La funzione Lambda viene eseguita ogni volta che viene aggiunto un nuovo messaggio alla coda. La funzione scrive i messaggi in un flusso Amazon CloudWatch Logs. Il seguente diagramma illustra le risorse AWS utilizzate per completare il tutorial.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/sqs_tut_resources.png)
Per completare questo tutorial, completa le seguenti attività:
1. Crea una funzione Lambda che scrive messaggi nei registri. CloudWatch
1. Creare una coda Amazon SQS.
1. Crea una mappatura dell'origine degli eventi Lambda. La mappatura dell'origine degli eventi legge la coda di Amazon SQS e richiama la funzione Lambda quando viene aggiunto un nuovo messaggio.
1. Verifica la configurazione aggiungendo messaggi alla coda e monitorando i risultati in Logs. CloudWatch
## Prerequisiti
### Installa il AWS Command Line Interface
Se non l'hai ancora installato AWS Command Line Interface, segui i passaggi indicati in [Installazione o aggiornamento della versione più recente di AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) per installarlo.
Per eseguire i comandi nel tutorial, sono necessari un terminale a riga di comando o una shell (interprete di comandi). In Linux e macOS, utilizza la shell (interprete di comandi) e il gestore pacchetti preferiti.
**Nota**
Su Windows, alcuni comandi della CLI Bash utilizzati comunemente con Lambda (ad esempio, `zip`) non sono supportati dai terminali integrati del sistema operativo. Per ottenere una versione integrata su Windows di Ubuntu e Bash, [installa il sottosistema Windows per Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10).
## Creazione del ruolo di esecuzione
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/sqs_tut_steps1.png)
Un [ruolo di esecuzione](lambda-intro-execution-role.md) è un ruolo AWS Identity and Access Management (IAM) che concede a una funzione Lambda l'autorizzazione all' Servizi AWS accesso e alle risorse. Per consentire alla tua funzione di leggere articoli da Amazon SQS, allega la politica di **AWSLambdaSQSQueueExecutionRole**autorizzazione.
**Creazione di un ruolo di esecuzione e collegamento di una policy di autorizzazione Amazon SQS personalizzata**
1. Aprire la [pagina Roles (Ruoli)](https://console.aws.amazon.com/iam/home#/roles) della console IAM.
1. Scegli **Crea ruolo**.
1. Per **Tipo di entità attendibile**, scegli **Servizio AWS **.
1. In **Caso d'uso**, scegli **Lambda**.
1. Scegli **Next (Successivo)**.
1. Nella casella di ricerca **Policy di autorizzazione**, inserisci **AWSLambdaSQSQueueExecutionRole**.
1. **Seleziona la **AWSLambdaSQSQueueExecutionRole**politica, quindi scegli Avanti.**
1. In **Dettagli del ruolo**, per **Nome del ruolo** inserisci **lambda-sqs-role**, quindi scegli **Crea ruolo**.
Dopo la creazione del ruolo, prendi nota del valore del nome della risorsa Amazon (ARN) del ruolo di esecuzione. Ne avrai bisogno nelle fasi successive.
## Creazione della funzione
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/sqs_tut_steps2.png)
Crea una funzione Lambda che elabora i messaggi Amazon SQS. Il codice della funzione registra il corpo del messaggio CloudWatch Amazon SQS in Logs.
Questo tutorial utilizza il runtime Node.js 24, ma abbiamo anche fornito codice di esempio in altri linguaggi di runtime. Per visualizzare il codice per il runtime che ti interessa, seleziona la scheda corrispondente nella casella seguente. Il JavaScript codice che utilizzerai in questo passaggio si trova nel primo esempio mostrato nella **JavaScript**scheda.
------
#### [ .NET ]
**SDK per .NET**
C'è altro su GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Utilizzo di un evento SQS con Lambda tramite .NET.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using Amazon.Lambda.Core;
using Amazon.Lambda.SQSEvents;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace SqsIntegrationSampleCode
{
public async Task FunctionHandler(SQSEvent evnt, ILambdaContext context)
{
foreach (var message in evnt.Records)
{
await ProcessMessageAsync(message, context);
}
context.Logger.LogInformation("done");
}
private async Task ProcessMessageAsync(SQSEvent.SQSMessage message, ILambdaContext context)
{
try
{
context.Logger.LogInformation($"Processed message {message.Body}");
// TODO: Do interesting work based on the new message
await Task.CompletedTask;
}
catch (Exception e)
{
//You can use Dead Letter Queue to handle failures. By configuring a Lambda DLQ.
context.Logger.LogError($"An error occurred");
throw;
}
}
}
```
------
#### [ Go ]
**SDK per Go V2**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Utilizzo di un evento SQS con Lambda tramite Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package integration_sqs_to_lambda
import (
"fmt"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func handler(event events.SQSEvent) error {
for _, record := range event.Records {
err := processMessage(record)
if err != nil {
return err
}
}
fmt.Println("done")
return nil
}
func processMessage(record events.SQSMessage) error {
fmt.Printf("Processed message %s\n", record.Body)
// TODO: Do interesting work based on the new message
return nil
}
func main() {
lambda.Start(handler)
}
```
------
#### [ Java ]
**SDK per Java 2.x**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Utilizzo di un evento SQS con Lambda tramite Java.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.SQSEvent;
import com.amazonaws.services.lambda.runtime.events.SQSEvent.SQSMessage;
public class Function implements RequestHandler {
@Override
public Void handleRequest(SQSEvent sqsEvent, Context context) {
for (SQSMessage msg : sqsEvent.getRecords()) {
processMessage(msg, context);
}
context.getLogger().log("done");
return null;
}
private void processMessage(SQSMessage msg, Context context) {
try {
context.getLogger().log("Processed message " + msg.getBody());
// TODO: Do interesting work based on the new message
} catch (Exception e) {
context.getLogger().log("An error occurred");
throw e;
}
}
}
```
------
#### [ JavaScript ]
**SDK per JavaScript (v3)**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/blob/main/integration-sqs-to-lambda).
Consumo di un evento SQS con JavaScript Lambda utilizzando.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
exports.handler = async (event, context) => {
for (const message of event.Records) {
await processMessageAsync(message);
}
console.info("done");
};
async function processMessageAsync(message) {
try {
console.log(`Processed message ${message.body}`);
// TODO: Do interesting work based on the new message
await Promise.resolve(1); //Placeholder for actual async work
} catch (err) {
console.error("An error occurred");
throw err;
}
}
```
Consumo di un evento SQS con TypeScript Lambda utilizzando.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import { SQSEvent, Context, SQSHandler, SQSRecord } from "aws-lambda";
export const functionHandler: SQSHandler = async (
event: SQSEvent,
context: Context
): Promise => {
for (const message of event.Records) {
await processMessageAsync(message);
}
console.info("done");
};
async function processMessageAsync(message: SQSRecord): Promise {
try {
console.log(`Processed message ${message.body}`);
// TODO: Do interesting work based on the new message
await Promise.resolve(1); //Placeholder for actual async work
} catch (err) {
console.error("An error occurred");
throw err;
}
}
```
------
#### [ PHP ]
**SDK per PHP**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Utilizzo di un evento SQS con Lambda tramite PHP.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
logger = $logger;
}
/**
* @throws InvalidLambdaEvent
*/
public function handleSqs(SqsEvent $event, Context $context): void
{
foreach ($event->getRecords() as $record) {
$body = $record->getBody();
// TODO: Do interesting work based on the new message
}
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**SDK per Python (Boto3)**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Utilizzo di un evento SQS con Lambda tramite Python.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def lambda_handler(event, context):
for message in event['Records']:
process_message(message)
print("done")
def process_message(message):
try:
print(f"Processed message {message['body']}")
# TODO: Do interesting work based on the new message
except Exception as err:
print("An error occurred")
raise err
```
------
#### [ Ruby ]
**SDK per Ruby**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Utilizzo di un evento SQS con Lambda tramite Ruby.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def lambda_handler(event:, context:)
event['Records'].each do |message|
process_message(message)
end
puts "done"
end
def process_message(message)
begin
puts "Processed message #{message['body']}"
# TODO: Do interesting work based on the new message
rescue StandardError => err
puts "An error occurred"
raise err
end
end
```
------
#### [ Rust ]
**SDK per Rust**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Utilizzo di un evento SQS con Lambda tramite Rust.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
use aws_lambda_events::event::sqs::SqsEvent;
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
async fn function_handler(event: LambdaEvent) -> Result<(), Error> {
event.payload.records.iter().for_each(|record| {
// process the record
tracing::info!("Message body: {}", record.body.as_deref().unwrap_or_default())
});
Ok(())
}
#[tokio::main]
async fn main() -> Result<(), Error> {
tracing_subscriber::fmt()
.with_max_level(tracing::Level::INFO)
// disable printing the name of the module in every log line.
.with_target(false)
// disabling time is handy because CloudWatch will add the ingestion time.
.without_time()
.init();
run(service_fn(function_handler)).await
}
```
------
**Creazione di una funzione Lambda in Node.js**
1. Crea una directory per il progetto, quindi passa a quella directory.
```
mkdir sqs-tutorial
cd sqs-tutorial
```
1. Copia il JavaScript codice di esempio in un nuovo file denominato`index.js`.
1. Crea un pacchetto di implementazione utilizzando il seguente comando `zip`.
```
zip function.zip index.js
```
1. Crea una funzione Lambda utilizzando il comando [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html) della AWS CLI . Per il `role` parametro, immettere l'ARN del ruolo di esecuzione creato in precedenza.
**Nota**
La funzione Lambda e la coda Amazon SQS devono trovarsi nella stessa Regione AWS.
```
aws lambda create-function --function-name ProcessSQSRecord \
--zip-file fileb://function.zip --handler index.handler --runtime nodejs24.x \
--role arn:aws:iam::111122223333:role/lambda-sqs-role
```
## Test della funzione
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/sqs_tut_steps3.png)
Richiama la funzione Lambda manualmente utilizzando `invoke` AWS CLI il comando e un evento Amazon SQS di esempio.
**Invocazione della funzione Lambda con un evento di esempio**
1. Salva il seguente JSON come un file denominato `input.json`. Questo JSON simula un evento che Amazon SQS potrebbe inviare alla tua funzione Lambda, dove `"body"` contiene il messaggio effettivo dalla coda. In questo esempio, il messaggio è `"test"`.
**Example Evento Amazon SQS**
Questo è un evento di test: non è necessario modificare il messaggio o il numero di account.
```
{
"Records": [
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "test",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {},
"md5OfBody": "098f6bcd4621d373cade4e832627b4f6",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-1:111122223333:my-queue",
"awsRegion": "us-east-1"
}
]
}
```
1. [Esegui il seguente comando invoke.](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/invoke.html) AWS CLI Questo comando restituisce CloudWatch i log nella risposta. Per ulteriori informazioni sul recupero di oggetti, consulta [Accedi ai log con AWS CLI](monitoring-cloudwatchlogs-view.md#monitoring-cloudwatchlogs-cli).
```
aws lambda invoke --function-name ProcessSQSRecord --payload file://input.json out --log-type Tail \
--query 'LogResult' --output text --cli-binary-format raw-in-base64-out | base64 --decode
```
L'**cli-binary-format**opzione è obbligatoria se si utilizza la AWS CLI versione 2. Per rendere questa impostazione come predefinita, esegui `aws configure set cli-binary-format raw-in-base64-out`. Per ulteriori informazioni, consulta la pagina [AWS CLI supported global command line options](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) nella *Guida per l'utente di AWS Command Line Interface versione 2*.
1. Individua il log `INFO` nella risposta. È qui che la funzione Lambda registra il corpo del messaggio. I log visualizzati dovrebbero essere di questo tipo:
```
2023-09-11T22:45:04.271Z 348529ce-2211-4222-9099-59d07d837b60 INFO Processed message test
2023-09-11T22:45:04.288Z 348529ce-2211-4222-9099-59d07d837b60 INFO done
```
## Creazione di una coda Amazon SQS
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/sqs_tut_steps4.png)
Creare una coda Amazon SQS che la funzione Lambda può utilizzare come origine eventi. La funzione Lambda e la coda Amazon SQS devono trovarsi nella stessa Regione AWS.
**Come creare una coda**
1. Apri la [console Amazon SQS](https://console.aws.amazon.com/sqs).
1. Scegliere **Crea coda**.
1. Inserisci un nome per la coda. Lascia tutte le altre proprietà sui valori predefiniti.
1. Scegliere **Crea coda**.
Dopo aver creato la coda, prendi nota del suo ARN. Questa operazione è necessaria nella fase successiva quando si associa la coda alla funzione Lambda.
## Configurazione dell'origine eventi
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/sqs_tut_steps5.png)
Collega la coda Amazon SQS alla tua funzione Lambda creando una [mappatura dell'origine degli eventi](invocation-eventsourcemapping.md). La mappatura dell'origine degli eventi legge la coda di Amazon SQS e richiama la funzione Lambda quando viene aggiunto un nuovo messaggio.
Per creare una mappatura tra la coda Amazon SQS e la funzione Lambda, usa il comando. [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html) AWS CLI Esempio:
```
aws lambda create-event-source-mapping --function-name ProcessSQSRecord --batch-size 10 \
--event-source-arn arn:aws:sqs:us-east-1:111122223333:my-queue
```
Per ottenere un elenco delle mappature delle sorgenti degli eventi, usa il comando. [list-event-source-mappings](https://awscli.amazonaws.com/v2/documentation/api/2.1.29/reference/lambda/list-event-source-mappings.html) Esempio:
```
aws lambda list-event-source-mappings --function-name ProcessSQSRecord
```
## Invio di un messaggio di test
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/sqs_tut_steps6.png)
**Invio di un messaggio Amazon SQS alla funzione Lambda**
1. Apri la [console Amazon SQS](https://console.aws.amazon.com/sqs).
1. Scegli la coda creata in precedenza.
1. Scegli **Invia e ricevi messaggi**.
1. Nella sezione **Corpo del messaggio**, inserisci un messaggio di test, ad esempio "questo è un messaggio di prova".
1. Scegliere **Invia messaggio**.
Lambda esegue il polling della coda per gli aggiornamenti. Quando c'è un nuovo messaggio, Lambda richiama la tua funzione con questi nuovi dati di evento dalla coda. Se il gestore della funzione conclude senza eccezioni, Lambda considera il messaggio elaborato correttamente e inizia a leggere nuovi messaggi nella coda. Dopo aver elaborato correttamente un messaggio, Lambda lo elimina automaticamente dalla coda. Se il gestore genera un'eccezione, Lambda considera il batch dei messaggi come non correttamente elaborato e Lambda richiama la funzione con lo stesso batch di messaggi.
## Controlla i log CloudWatch
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/sqs_tut_steps7.png)
**Verifica della corretta elaborazione del messaggio da parte della funzione**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegli la SQSRecord funzione **Process**.
1. Scegli **Monitor (Monitoraggio)**.
1. Scegli **Visualizza CloudWatch registri.**
1. Nella CloudWatch console, scegli il **flusso di log** per la funzione.
1. Individua il log `INFO`. È qui che la funzione Lambda registra il corpo del messaggio. Dovresti vedere il messaggio che hai inviato dalla coda Amazon SQS. Esempio:
```
2023-09-11T22:49:12.730Z b0c41e9c-0556-5a8b-af83-43e59efeec71 INFO Processed message this is a test message.
```
## Pulizia delle risorse
Ora è possibile eliminare le risorse create per questo tutorial, a meno che non si voglia conservarle. Eliminando AWS le risorse che non utilizzi più, eviti addebiti inutili a tuo Account AWS carico.
**Come eliminare il ruolo di esecuzione**
1. Aprire la pagina [Ruoli](https://console.aws.amazon.com/iam/home#/roles) della console IAM.
1. Selezionare il ruolo di esecuzione creato.
1. Scegliere **Elimina**.
1. Inserisci il nome del ruolo nel campo di immissione testo e seleziona **Delete** (Elimina).
**Per eliminare la funzione Lambda**
1. Aprire la pagina [Functions (Funzioni)](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Selezionare la funzione creata.
1. Scegliere **Operazioni**, **Elimina**.
1. Digita **confirm** nel campo di immissione testo e scegli **Delete** (Elimina).
**Per eliminare la coda Amazon SQS**
1. Accedi Console di gestione AWS e apri la console Amazon SQS all'indirizzo. [https://console.aws.amazon.com/sqs/](https://console.aws.amazon.com/sqs/)
1. Selezionare la coda creata.
1. Scegli **Elimina**.
1. Inserisci **confirm** nel campo di immissione del testo.
1. Scegli **Delete** (Elimina).
# Tutorial: utilizzo di una coda Amazon SQS tra più account come origine eventi
In questo tutorial, crei una funzione Lambda che consuma i messaggi da una coda Amazon Simple Queue Service (Amazon SQS) in un account diverso. AWS Questo tutorial include due AWS account: l'**account A** si riferisce all'account che contiene la funzione Lambda e l'**account B** si riferisce all'account che contiene la coda Amazon SQS.
## Prerequisiti
### Installa il AWS Command Line Interface
Se non l'hai ancora installato AWS Command Line Interface, segui i passaggi indicati in [Installazione o aggiornamento della versione più recente di AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) per installarlo.
Per eseguire i comandi nel tutorial, sono necessari un terminale a riga di comando o una shell (interprete di comandi). In Linux e macOS, utilizza la shell (interprete di comandi) e il gestore pacchetti preferiti.
**Nota**
Su Windows, alcuni comandi della CLI Bash utilizzati comunemente con Lambda (ad esempio, `zip`) non sono supportati dai terminali integrati del sistema operativo. Per ottenere una versione integrata su Windows di Ubuntu e Bash, [installa il sottosistema Windows per Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10).
## Creazione del ruolo di esecuzione (account A)
Nell'**Account A**, crea un [ruolo di esecuzione](lambda-intro-execution-role.md) che autorizzi la funzione ad accedere alle AWS risorse richieste.
**Creazione di un ruolo di esecuzione**
1. Apri la [pagina Ruoli](https://console.aws.amazon.com/iam/home#/roles) nella console AWS Identity and Access Management (IAM).
1. Scegliere **Create role** (Crea ruolo).
1. Creare un ruolo con le seguenti proprietà.
+ **Entità attendibile** – **AWS Lambda**
+ **Autorizzazioni**: **AWSLambdaSQSQueueExecutionRole**
+ **Nome ruolo** – **cross-account-lambda-sqs-role**
La **AWSLambdaSQSQueueExecutionRole**policy dispone delle autorizzazioni necessarie alla funzione per leggere elementi da Amazon SQS e scrivere log su Amazon Logs. CloudWatch
## Creazione della funzione (account A)
In **Account A**, crea una funzione Lambda che elabora i messaggi Amazon SQS. La funzione Lambda e la coda Amazon SQS devono trovarsi nella stessa Regione AWS.
Il seguente esempio di codice Node.js scrive ogni messaggio in un log in Logs. CloudWatch
**Example index.mjs**
```
export const handler = async function(event, context) {
event.Records.forEach(record => {
const { body } = record;
console.log(body);
});
return {};
}
```
**Creazione della funzione**
**Nota**
Seguendo questi passaggi viene creata una funzione Node.js. Per le altre lingue i passaggi sono simili, ma alcuni dettagli sono diversi.
1. Salva l'esempio di codice come un file denominato `index.mjs`.
1. Crea un pacchetto di implementazione.
```
zip function.zip index.mjs
```
1. Create la funzione utilizzando il comando `create-function` AWS Command Line Interface (AWS CLI). Sostituisci `arn:aws:iam::111122223333:role/cross-account-lambda-sqs-role` con l'ARN del ruolo di esecuzione creato in precedenza.
```
aws lambda create-function --function-name CrossAccountSQSExample \
--zip-file fileb://function.zip --handler index.handler --runtime nodejs24.x \
--role arn:aws:iam::111122223333:role/cross-account-lambda-sqs-role
```
## Testa la funzione (Account A)
Nell'**Account A**, verifica manualmente la tua funzione Lambda utilizzando il `invoke` AWS CLI comando e un evento Amazon SQS di esempio.
Se il gestore termina normalmente senza eccezioni, Lambda considera il messaggio come elaborato correttamente e inizia a leggere nuovi messaggi nella coda. Dopo aver elaborato correttamente un messaggio, Lambda lo elimina automaticamente dalla coda. Se il gestore genera un'eccezione, Lambda considera il batch dei messaggi come non correttamente elaborato e Lambda richiama la funzione con lo stesso batch di messaggi.
1. Salva il seguente JSON come un file denominato `input.txt`.
```
{
"Records": [
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "test",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {},
"md5OfBody": "098f6bcd4621d373cade4e832627b4f6",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-1:111122223333:example-queue",
"awsRegion": "us-east-1"
}
]
}
```
Il precedente JSON simula un evento che Amazon SQS potrebbe inviare alla tua funzione Lambda, dove `"body"` contiene il messaggio effettivo dalla coda.
1. Eseguire il seguente comando `invoke` AWS CLI .
```
aws lambda invoke --function-name CrossAccountSQSExample \
--cli-binary-format raw-in-base64-out \
--payload file://input.txt outputfile.txt
```
L'**cli-binary-format**opzione è obbligatoria se utilizzi la AWS CLI versione 2. Per rendere questa impostazione come predefinita, esegui `aws configure set cli-binary-format raw-in-base64-out`. Per ulteriori informazioni, consulta la pagina [AWS CLI supported global command line options](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) nella *Guida per l'utente di AWS Command Line Interface versione 2*.
1. Verificare l'output nel file `outputfile.txt`.
## Creazione di una coda Amazon SQS (account B)
In **Account B**, crea una coda Amazon SQS che la funzione Lambda in **Account A** può utilizzare come origine eventi. La funzione Lambda e la coda Amazon SQS devono trovarsi nella stessa Regione AWS.
**Come creare una coda**
1. Apri la [console Amazon SQS](https://console.aws.amazon.com/sqs).
1. Scegliere **Crea coda**.
1. Crea una coda con le seguenti proprietà.
+ **Type (Tipo)**: **Standard**
+ **Nome**: **LambdaCrossAccountQueue**
+ **Configuration (Configurazione)**: mantieni le impostazioni predefinite.
+ **Access policy (Policy di accesso)**: scegli **Advanced (Avanzata)**. Incolla la seguente politica JSON. Sostituisci i valori seguenti:
+ `111122223333`: Account AWS ID per l'**account** A
+ `444455556666`: Account AWS ID per l'**account B**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [
{
"Sid": "Queue1_AllActions",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/cross-account-lambda-sqs-role"
]
},
"Action": "sqs:*",
"Resource": "arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue"
}
]
}
```
------
Questa policy concede al ruolo di esecuzione Lambda nell'**Account A** le autorizzazioni per utilizzare i messaggi provenienti da questa coda Amazon SQS.
1. Dopo aver creato la coda, registra il suo Amazon Resource Name (ARN). Questa operazione è necessaria nella fase successiva quando si associa la coda alla funzione Lambda.
## Configurazione dell'origine eventi (account A)
Nell'**Account A, crea una** mappatura dell'origine degli eventi tra la coda Amazon SQS **nell'Account** B e la tua funzione Lambda eseguendo il comando seguente. `create-event-source-mapping` AWS CLI Sostituisci `arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue` con l'ARN della coda Amazon SQS creata nel passaggio precedente.
```
aws lambda create-event-source-mapping --function-name CrossAccountSQSExample --batch-size 10 \
--event-source-arn arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue
```
È possibile ottenere un elenco delle mappature delle fonti eventi eseguendo il comando riportato di seguito.
```
aws lambda list-event-source-mappings --function-name CrossAccountSQSExample \
--event-source-arn arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue
```
## Eseguire il test della configurazione
A questo punto è possibile eseguire il test della configurazione come indicato di seguito:
1. Nell'**Account B**, apri [Console Amazon SQS](https://console.aws.amazon.com/sqs).
1. Scegli **LambdaCrossAccountQueue**, che hai creato in precedenza.
1. Scegli **Invia e ricevi messaggi**.
1. In **Corpo del messaggio**, inserisci un messaggio di prova.
1. Scegliere **Send Message** (Invia messaggio).
La funzione Lambda nell'**Account A** dovrebbe ricevere il messaggio. Lambda continuerà a eseguire il polling della coda per gli aggiornamenti. Quando c'è un nuovo messaggio, Lambda richiama la tua funzione con questi nuovi dati di evento dalla coda. La tua funzione viene eseguita e crea registri in Amazon CloudWatch. Puoi visualizzare i log nella [console CloudWatch ](https://console.aws.amazon.com/cloudwatch).
## Pulizia delle risorse
Ora è possibile eliminare le risorse create per questo tutorial, a meno che non si voglia conservarle. Eliminando AWS le risorse che non utilizzi più, eviti addebiti inutili a tuo carico. Account AWS
Nell'**Account A** elimina il ruolo di esecuzione e la funzione Lambda.
**Come eliminare il ruolo di esecuzione**
1. Aprire la pagina [Ruoli](https://console.aws.amazon.com/iam/home#/roles) della console IAM.
1. Selezionare il ruolo di esecuzione creato.
1. Scegliere **Elimina**.
1. Inserisci il nome del ruolo nel campo di immissione testo e seleziona **Delete** (Elimina).
**Per eliminare la funzione Lambda**
1. Aprire la pagina [Functions (Funzioni)](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Selezionare la funzione creata.
1. Scegliere **Operazioni**, **Elimina**.
1. Digita **confirm** nel campo di immissione testo e scegli **Delete** (Elimina).
Nell'**Account B** elimina la coda Amazon SQS.
**Per eliminare la coda Amazon SQS**
1. Accedi Console di gestione AWS e apri la console Amazon SQS all'indirizzo. [https://console.aws.amazon.com/sqs/](https://console.aws.amazon.com/sqs/)
1. Selezionare la coda creata.
1. Scegli **Elimina**.
1. Inserisci **confirm** nel campo di immissione del testo.
1. Scegli **Delete** (Elimina).
# Orchestrazione delle funzioni Lambda con Step Functions
AWS Step Functions fornisce l'orchestrazione visiva del flusso di lavoro per coordinare le funzioni Lambda con altri servizi. AWS Con integrazioni native per oltre 220 AWS servizi e un'infrastruttura completamente gestita e senza manutenzione, Step Functions è ideale quando è necessario progettare flussi di lavoro visivi e integrazioni di servizi completamente gestite.
[Per l'orchestrazione utilizzando linguaggi di programmazione standard all'interno di Lambda, in cui la logica del flusso di lavoro convive con la logica aziendale, prendi in considerazione le funzioni durevoli Lambda.](durable-functions.md) Per informazioni sulla scelta tra queste opzioni, consulta [Durable functions o Step Functions](durable-step-functions.md).
Ad esempio, l'elaborazione di un ordine potrebbe richiedere la convalida dei dettagli dell'ordine, il controllo dei livelli di inventario, l'elaborazione del pagamento e la generazione di una fattura. Scrivi funzioni Lambda separate per ogni attività e usa Step Functions per gestire il flusso di lavoro. Step Functions coordina il flusso di dati tra le funzioni e gestisce gli errori in ogni fase. Questa separazione semplifica la visualizzazione, la modifica e la gestione dei flussi di lavoro man mano che diventano più complessi.
## Quando usare Step Functions con Lambda
Gli scenari seguenti sono buoni esempi di quando Step Functions è particolarmente adatto per l'orchestrazione di applicazioni basate su Lambda.
+ [Elaborazione sequenziale](#sequential-processing)
+ [Gestione complessa degli errori](#complex-error-handling)
+ [Flussi di lavoro condizionali e approvazioni umane](#conditional-workflows-human-approvals)
+ [Elaborazione parallela](#parallel-processing)
### Elaborazione sequenziale
L'elaborazione sequenziale si verifica quando un'attività deve essere completata prima che possa iniziare l'attività successiva. Ad esempio, in un sistema di elaborazione degli ordini, l'elaborazione dei pagamenti non può iniziare fino al completamento della convalida dell'ordine e la generazione della fattura deve attendere la conferma del pagamento. Scrivi funzioni Lambda separate per ogni attività e usa Step Functions per gestire la sequenza e gestire il flusso di dati tra le funzioni.
#### Esempio anti-pattern
Una singola funzione Lambda gestisce l'intero flusso di lavoro di elaborazione degli ordini tramite:
+ Richiamo di altre funzioni Lambda in sequenza
+ Analisi e convalida delle risposte di ogni funzione
+ Implementazione della gestione degli errori e della logica di ripristino
+ Gestione del flusso di dati tra le funzioni
#### Approccio consigliato
Utilizza due funzioni Lambda: una per convalidare l'ordine e una per elaborare il pagamento. Step Functions coordina queste funzioni tramite:
+ Esecuzione delle attività nella sequenza corretta
+ Passaggio di dati tra funzioni
+ Implementazione della gestione degli errori in ogni fase
+ L'utilizzo di [Choice](https://docs.aws.amazon.com/step-functions/latest/dg/state-choice.html) indica che solo gli ordini validi procedono al pagamento
**Example grafico del flusso di lavoro**
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/sequential_workflow.png)
**Nota**
**Alternativa basata sul codice: per l'elaborazione sequenziale con checkpoint e ripetizione** [basati sul codice, consulta le fasi delle funzioni durevoli di Lambda.](durable-basic-concepts.md)
### Gestione complessa degli errori
Mentre Lambda offre [funzionalità di ripetizione dei tentativi per chiamate asincrone e mappature delle sorgenti degli eventi, Step](invocation-retries.md) Functions offre una gestione degli errori più sofisticata per flussi di lavoro complessi. È possibile [configurare nuovi tentativi automatici con backoff esponenziale e impostare politiche di nuovo tentativo](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html#error-handling-retrying-after-an-error) diverse per diversi tipi di errori. [Quando i tentativi sono esauriti, utilizza per indirizzare gli errori `Catch` verso uno stato di fallback.](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html#error-handling-fallback-states) Ciò è particolarmente utile quando è necessaria una gestione degli errori a livello di flusso di lavoro che coordini più funzioni e servizi.
Per ulteriori informazioni sulla gestione degli errori della funzione Lambda in una macchina a stati, vedere [Gestione degli errori](https://catalog.workshops.aws/stepfunctions/handling-errors) in *The AWS Step Functions * Workshop.
#### Esempio anti-pattern
Una singola funzione Lambda gestisce tutto quanto segue:
+ Tentativi di chiamare un servizio di elaborazione dei pagamenti
+ Se il servizio di pagamento non è disponibile, la funzione attende e riprova più tardi.
+ Implementa un backoff esponenziale personalizzato per il tempo di attesa
+ Dopo che tutti i tentativi sono falliti, catch l'errore e scegli un altro flusso
#### Approccio consigliato
Utilizza una singola funzione Lambda incentrata esclusivamente sull'elaborazione dei pagamenti. Step Functions gestisce la gestione degli errori tramite:
+ [Riprovare automaticamente le attività non riuscite con periodi di backoff configurabili](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html#error-handling-retrying-after-an-error)
+ Applicazione di politiche di riprova diverse in base ai tipi di errore
+ Instradamento di diversi tipi di errori verso stati di fallback appropriati
+ Mantenimento dello stato e della cronologia della gestione degli errori
**Example grafico del flusso di lavoro**
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/error_handling_workflow.png)
**Nota**
**Alternativa Code-first:** le funzioni durevoli forniscono la gestione degli errori try-catch con strategie di riprova configurabili. [Vedi Gestione degli errori nelle funzioni durevoli.](durable-execution-sdk-retries.md)
### Flussi di lavoro condizionali e approvazioni umane
Utilizza lo [stato Step Functions Choice](https://docs.aws.amazon.com/step-functions/latest/dg/state-choice.html) per indirizzare i flussi di lavoro in base all'output della funzione e il [suffisso waitForTask Token](https://docs.aws.amazon.com/step-functions/latest/dg/connect-to-resource.html#connect-wait-token) per sospendere i flussi di lavoro per decisioni umane. Ad esempio, per elaborare una richiesta di aumento del limite di credito, utilizza una funzione Lambda per valutare i fattori di rischio. Quindi, utilizza Step Functions per indirizzare le richieste ad alto rischio all'approvazione manuale e le richieste a basso rischio all'approvazione automatica.
*Per implementare un flusso di lavoro di esempio che utilizza un modello di integrazione dei token di attività di callback, consulta [Callback with Task](https://catalog.workshops.aws/stepfunctions/integrating-services/3-callback-token) Token in The Workshop. AWS Step Functions *
#### Esempio anti-pattern
Una singola funzione Lambda gestisce un flusso di lavoro di approvazione complesso mediante:
+ Implementazione della logica condizionale annidata per valutare le richieste di credito
+ Richiamo di diverse funzioni di approvazione in base agli importi delle richieste
+ Gestione di più percorsi di approvazione e punti decisionali
+ Monitoraggio dello stato delle approvazioni in sospeso
+ Implementazione del timeout e della logica di notifica per le approvazioni
#### Approccio consigliato
Utilizza tre funzioni Lambda: una per valutare il rischio di ogni richiesta, una per approvare le richieste a basso rischio e una per indirizzare le richieste ad alto rischio a un manager per la revisione. Step Functions gestisce il flusso di lavoro tramite:
+ Utilizzo degli stati [Choice](https://docs.aws.amazon.com/step-functions/latest/dg/state-choice.html) per indirizzare le richieste in base all'importo e al livello di rischio
+ Sospensione dell'esecuzione in attesa dell'approvazione umana
+ Gestione dei timeout per le approvazioni in sospeso
+ Fornire visibilità sullo stato attuale di ogni richiesta
**Example grafico del flusso di lavoro**
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/conditional_workflow.png)
**Nota**
**Alternativa Code-first:** le funzioni durevoli supportano i callback per i flussi di lavoro. human-in-the-loop Vedi [Callback](durable-execution-sdk.md) nelle funzioni durevoli.
### Elaborazione parallela
Step Functions offre tre modi per gestire l'elaborazione parallela:
+ [Lo stato Parallel](https://docs.aws.amazon.com/step-functions/latest/dg/state-parallel.html) esegue più rami del flusso di lavoro contemporaneamente. Usalo quando devi eseguire diverse funzioni in parallelo, come la generazione di miniature durante l'estrazione dei metadati delle immagini.
+ Lo [stato Inline Map](https://docs.aws.amazon.com/step-functions/latest/dg/state-map-inline.html) elabora matrici di dati con un massimo di 40 iterazioni simultanee. Utilizzatelo per set di dati di piccole e medie dimensioni in cui è necessario eseguire la stessa operazione su ciascun elemento.
+ [Lo stato Distributed Map](https://docs.aws.amazon.com/step-functions/latest/dg/state-map-distributed.html) gestisce l'elaborazione parallela su larga scala con un massimo di 10.000 esecuzioni simultanee, supportando sia gli array JSON che le origini dati Amazon Simple Storage Service (Amazon S3) Simple Storage Service (Amazon S3). Usalo quando elabori set di dati di grandi dimensioni o quando hai bisogno di una maggiore concorrenza.
#### Esempio anti-pattern
Una singola funzione Lambda tenta di gestire l'elaborazione parallela mediante:
+ Richiamo simultaneo di più funzioni di elaborazione delle immagini
+ Implementazione di una logica di esecuzione parallela personalizzata
+ Gestione dei timeout e degli errori per ogni attività parallela
+ Raccolta e aggregazione dei risultati di tutte le funzioni
#### Approccio consigliato
Usa tre funzioni Lambda: una per creare un'immagine in miniatura, una per aggiungere una filigrana e una per estrarre i metadati. Step Functions gestisce queste funzioni tramite:
+ Esecuzione simultanea di tutte le funzioni utilizzando lo stato [Parallel](https://docs.aws.amazon.com/step-functions/latest/dg/state-parallel.html)
+ Raccolta dei risultati da ciascuna funzione in un array ordinato
+ Gestione dei timeout e degli errori in tutte le esecuzioni parallele
+ Procedere solo quando tutti i rami paralleli sono completi
**Example grafico del flusso di lavoro**
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/parallel_workflow.png)
**Nota**
**Alternativa incentrata sul codice**: funzionalità e operazioni durevoli. `parallel()` `map()` Vedere Esecuzione [parallela](durable-execution-sdk.md).
## Quando non usare Step Functions con Lambda
Non tutte le applicazioni basate su Lambda traggono vantaggio dall'utilizzo di Step Functions. Considerate questi scenari quando scegliete l'architettura dell'applicazione.
+ [Applicazioni semplici](#simple-applications)
+ [Elaborazione di dati complessi](#complex-data-processing)
+ [Carichi di lavoro che richiedono un uso intensivo della CPU](#cpu-intensive)
### Applicazioni semplici
**Nota**
Per i flussi di lavoro che non richiedono progettazione visiva o integrazioni estese di servizi, le [funzioni durevoli Lambda](durable-functions.md) possono essere un'alternativa più semplice che mantiene la logica del flusso di lavoro nel codice all'interno di Lambda.
Per le applicazioni che non richiedono un'orchestrazione complessa, l'utilizzo di Step Functions potrebbe aggiungere complessità non necessarie. Ad esempio, se stai semplicemente elaborando messaggi da una coda Amazon SQS o rispondendo a eventi EventBridge Amazon, puoi configurare questi servizi per richiamare direttamente le tue funzioni Lambda. Allo stesso modo, se l'applicazione è composta solo da una o due funzioni Lambda con una gestione semplice degli errori, l'invocazione diretta Lambda o le architetture basate sugli eventi potrebbero essere più semplici da implementare e gestire.
### Elaborazione di dati complessi
Puoi utilizzare lo stato Step Functions [Distributed Map](https://docs.aws.amazon.com/step-functions/latest/dg/state-map-distributed.html) per elaborare contemporaneamente set di dati Amazon S3 di grandi dimensioni con funzioni Lambda. Ciò è efficace per molti carichi di lavoro paralleli su larga scala, inclusa l'elaborazione di dati semistrutturati come file JSON o CSV. Tuttavia, per trasformazioni di dati più complesse o analisi avanzate, prendi in considerazione queste alternative:
+ **Pipeline di trasformazione dei dati**: utilizzate AWS Glue per lavori ETL che elaborano dati strutturati o semistrutturati provenienti da più fonti. AWS Glue è particolarmente utile quando sono necessarie funzionalità integrate di gestione del catalogo di dati e dello schema.
+ **Analisi dei dati: usa Amazon EMR per analisi dei dati** [su scala petabyte, soprattutto quando hai bisogno di strumenti Apache Hadoop ecosistemici o per carichi di lavoro di machine learning che superano i limiti di memoria di Lambda.](configuration-memory.md)
### Carichi di lavoro che richiedono un uso intensivo della CPU
Sebbene Step Functions sia in grado di orchestrare attività che richiedono un uso intensivo della CPU, le funzioni Lambda potrebbero non essere adatte a questi carichi di lavoro a causa delle risorse limitate della CPU. Per le operazioni ad alta intensità di calcolo all'interno dei flussi di lavoro, prendi in considerazione queste alternative:
+ **Orchestrazione dei container:** usa Step Functions per gestire le attività di Amazon Elastic Container Service (Amazon ECS) per risorse di elaborazione più coerenti e scalabili.
+ **Elaborazione in batch:** integrazione AWS Batch con Step Functions per la gestione di processi batch ad alta intensità di calcolo che richiedono un utilizzo prolungato della CPU.
# Richiamo di una funzione Lambda con eventi batch Amazon S3
È possibile utilizzare le operazioni batch di Amazon S3 per richiamare una funzione Lambda su un set di oggetti Amazon S3 di grandi dimensioni. Amazon S3 tiene traccia dello stato di avanzamento delle operazioni batch, invia notifiche e memorizza un report di completamento che mostra lo stato di ogni operazione.
Per eseguire un'operazione batch, è possibile creare un [lavoro di operazioni batch](https://docs.aws.amazon.com/AmazonS3/latest/dev/batch-ops-operations.html) Amazon S3. Quando si crea il lavoro, si fornisce un file manifest (l'elenco degli oggetti) e si configura l'operazione da eseguire su tali oggetti.
All'avvio del lavoro batch, Amazon S3 richiama la funzione Lambda in modo [sincrono](invocation-sync.md) per ogni oggetto nel manifest. Il parametro evento include i nomi del bucket e dell'oggetto.
Nell'esempio seguente viene illustrato l'evento che Amazon S3 invia alla funzione Lambda per un oggetto denominato **customerImage1.jpg** nel bucket **amzn-s3-demo-bucket**.
**Example Evento di richiesta batch Amazon S3**
```
{
"invocationSchemaVersion": "1.0",
"invocationId": "YXNkbGZqYWRmaiBhc2RmdW9hZHNmZGpmaGFzbGtkaGZza2RmaAo",
"job": {
"id": "f3cc4f60-61f6-4a2b-8a21-d07600c373ce"
},
"tasks": [
{
"taskId": "dGFza2lkZ29lc2hlcmUK",
"s3Key": "customerImage1.jpg",
"s3VersionId": "1",
"s3BucketArn": "arn:aws:s3:::amzn-s3-demo-bucket"
}
]
}
```
La funzione Lambda deve restituire un oggetto JSON con i campi come mostrato nell'esempio seguente. È possibile copiare `invocationId` e `taskId` dal parametro evento. È possibile restituire una stringa in `resultString`. Amazon S3 salva i valori `resultString` nel report di completamento.
**Example Risposta alla richiesta batch Amazon S3**
```
{
"invocationSchemaVersion": "1.0",
"treatMissingKeysAs" : "PermanentFailure",
"invocationId" : "YXNkbGZqYWRmaiBhc2RmdW9hZHNmZGpmaGFzbGtkaGZza2RmaAo",
"results": [
{
"taskId": "dGFza2lkZ29lc2hlcmUK",
"resultCode": "Succeeded",
"resultString": "[\"Alice\", \"Bob\"]"
}
]
}
```
## Chiamata di funzioni Lambda dalle operazioni in batch Amazon S3
È possibile richiamare la funzione Lambda con una funzione ARN non qualificata o qualificata. Se si desidera utilizzare la stessa versione di funzione per l'intero lavoro batch, configurare una versione di funzione specifica nel parametro `FunctionARN` quando si crea il lavoro. Se si configura un alias o il qualificatore \$1LATEST, il lavoro batch inizia immediatamente a chiamare la nuova versione della funzione se l'alias o \$1LATEST viene aggiornato durante l'esecuzione del lavoro.
Si noti che non è possibile riutilizzare una funzione basata su eventi Amazon S3 esistente per le operazioni batch. Questo perché l'operazione batch Amazon S3 passa un parametro di evento diverso alla funzione Lambda e si aspetta un messaggio di ritorno con una struttura JSON specifica.
Nella [policy basata sulle risorse](access-control-resource-based.md) creata per il lavoro batch Amazon S3, assicurarsi di impostare l'autorizzazione per il lavoro per richiamare la funzione Lambda.
Nel [ruolo di esecuzione](https://docs.aws.amazon.com/AmazonS3/latest/userguide/batch-ops-iam-role-policies.html) per la funzione, impostare una policy di attendibilità Amazon S3 per assumere il ruolo quando viene eseguita la funzione.
Se la tua funzione utilizza l' AWS SDK per gestire le risorse Amazon S3, devi aggiungere le autorizzazioni Amazon S3 nel ruolo di esecuzione.
Quando il lavoro viene eseguito, Amazon S3 avvia più istanze di funzione per elaborare gli oggetti Amazon S3 in parallelo, fino al [limite di simultaneità](lambda-concurrency.md) della funzione. Amazon S3 limita l'aumento iniziale delle istanze per evitare costi eccessivi per i lavori più piccoli.
Se la funzione Lambda restituisce un codice di risposta `TemporaryFailure`, Amazon S3 riattiva l'operazione.
Per ulteriori informazioni sulla gestione delle operazioni in batch Amazon S3, consulta [Gestione dei processi di operazioni in batch](https://docs.aws.amazon.com/AmazonS3/latest/dev/batch-ops.html) nella *Guida per gli sviluppatori di Amazon S3*.
Per un esempio di come utilizzare una funzione Lambda nelle operazioni batch di Amazon S3, consulta [Invocare una funzione Lambda da operazioni batch di Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/batch-ops-invoke-lambda.html) nella *Guida per gli sviluppatori di Amazon S3*.
# Richiamo di funzioni Lambda mediante notifiche Amazon SNS
Si può utilizzare una funzione Lambda per elaborare le notifiche Amazon Simple Notification Service (Amazon SNS). Amazon SNS supporta le funzioni Lambda come destinazione per i messaggi inviati a un argomento. Puoi sottoscrivere la funzione ad argomenti nello stesso account o in altri account AWS. Per la procedura guidata dettagliata, consulta [Tutorial: Utilizzo AWS Lambda con Amazon Simple Notification Service](with-sns-example.md).
Lambda supporta i trigger SNS solo per argomenti SNS standard. Gli argomenti FIFO non sono supportati.
Lambda elabora i messaggi SNS in modo asincrono mettendoli in coda e gestendo i nuovi tentativi. Se Amazon SNS non è in grado di raggiungere Lambda o il messaggio viene rifiutato, Amazon SNS riprova a intervalli crescenti per diverse ore. Per ulteriori informazioni, consulta [Affidabilità](https://aws.amazon.com/sns/faqs/#Reliability) nelle domande frequenti su Amazon SNS.
**avvertimento**
Gli strumenti di mappatura dell'origine degli eventi elaborano ogni evento almeno una volta e può verificarsi un'elaborazione duplicata dei record. Per evitare potenziali problemi legati agli eventi duplicati, ti consigliamo vivamente di rendere idempotente il codice della funzione. Per ulteriori informazioni, consulta [Come posso rendere idempotente la mia funzione Lambda](https://repost.aws/knowledge-center/lambda-function-idempotent) nel Knowledge Center AWS.
## Utilità di idempotenza di Powertools per Lambda AWS
L'utilità di idempotenza di Powertools for AWS Lambda rende le funzioni Lambda idempotenti. È disponibile per Python, TypeScript, Java e.NET. [https://docs.powertools.aws.dev/lambda/dotnet/utilities/idempotency/](https://docs.powertools.aws.dev/lambda/dotnet/utilities/idempotency/)
**Topics**
+ [
## Utilità di idempotenza di Powertools per Lambda AWS
](#services-sns-powertools-idempotency)
+ [
## Aggiunta di un trigger di argomento Amazon SNS per una funzione Lambda utilizzando la console
](#sns-trigger-console)
+ [
## Aggiunta manuale di un trigger di argomento Amazon SNS per una funzione Lambda
](#sns-trigger-manual)
+ [
## Esempio di forma evento SNS
](#sns-sample-event)
+ [
# Tutorial: Utilizzo AWS Lambda con Amazon Simple Notification Service
](with-sns-example.md)
## Aggiunta di un trigger di argomento Amazon SNS per una funzione Lambda utilizzando la console
Per aggiungere un argomento SNS come trigger per una funzione Lambda, il modo più semplice è utilizzare la console Lambda. Quando aggiungi il trigger tramite la console, Lambda configura automaticamente le autorizzazioni e gli abbonamenti necessari per iniziare a ricevere eventi dall'argomento SNS.
**Per aggiungere un argomento SNS come trigger per una funzione Lambda (console)**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegli il nome della funzione per la quale si desidera aggiungere il trigger.
1. Scegli **Configurazione**, quindi scegli **Trigger**.
1. Selezionare **Add trigger** (Aggiungi trigger).
1. In **Configurazione del trigger**, nell'elenco a discesa, scegli **SNS**.
1. Per **Argomento SNS**, scegli l'argomento SNS da sottoscrivere.
## Aggiunta manuale di un trigger di argomento Amazon SNS per una funzione Lambda
Per configurare manualmente un trigger SNS per una funzione Lambda, è necessario completare i seguenti passaggi:
+ Definisci una policy basata sulle risorse per la tua funzione per consentire a SNS di richiamarla.
+ Sottoscrivere la funzione Lambda all'argomento Amazon SNS.
**Nota**
Se l'argomento SNS e la funzione Lambda si trovano in account AWS diversi, è inoltre necessario concedere autorizzazioni aggiuntive per consentire le sottoscrizioni tra account all'argomento SNS. Per maggiori informazioni, consulta [Concedere l'autorizzazioni tra account per la sottoscrizione di Amazon SNS](with-sns-example.md#with-sns-subscription-grant-permission).
Puoi usare la AWS Command Line Interface (AWS CLI) per completare entrambi questi passaggi. Innanzitutto, per definire una policy basata sulle risorse per una funzione Lambda che consenta le chiamate SNS, usa il comando AWS CLI seguente. Assicurati di sostituire il valore di `--function-name` con il nome della funzione Lambda e il valore di `--source-arn` con l'ARN dell'argomento SNS.
```
aws lambda add-permission --function-name example-function \
--source-arn arn:aws:sns:us-east-1:123456789012:sns-topic-for-lambda \
--statement-id function-with-sns --action "lambda:InvokeFunction" \
--principal sns.amazonaws.com
```
Per sottoscrivere la tua funzione all'argomento SNS, usa il comando AWS CLI seguente. Assicurati di sostituire il valore di `--topic-arn` con l'ARN dell'argomento SNS e il valore di `--notification-endpoint` con l'ARN della funzione Lambda.
```
aws sns subscribe --protocol lambda \
--region us-east-1 \
--topic-arn arn:aws:sns:us-east-1:123456789012:sns-topic-for-lambda \
--notification-endpoint arn:aws:lambda:us-east-1:123456789012:function:example-function
```
## Esempio di forma evento SNS
Amazon SNS richiama la funzione in modo [asincrono](invocation-async.md) con un evento che contiene un messaggio e dei metadati.
**Example Evento messaggio di Amazon SNS**
```
{
"Records": [
{
"EventVersion": "1.0",
"EventSubscriptionArn": "arn:aws:sns:us-east-1:123456789012:sns-lambda:21be56ed-a058-49f5-8c98-aedd2564c486",
"EventSource": "aws:sns",
"Sns": {
"SignatureVersion": "1",
"Timestamp": "2019-01-02T12:45:07.000Z",
"Signature": "tcc6faL2yUC6dgZdmrwh1Y4cGa/ebXEkAi6RibDsvpi+tE/1+82j...65r==",
"SigningCertURL": "https://sns.us-east-1.amazonaws.com/SimpleNotificationService-ac565b8b1a6c5d002d285f9598aa1d9b.pem",
"MessageId": "95df01b4-ee98-5cb9-9903-4c221d41eb5e",
"Message": "Hello from SNS!",
"MessageAttributes": {
"Test": {
"Type": "String",
"Value": "TestString"
},
"TestBinary": {
"Type": "Binary",
"Value": "TestBinary"
}
},
"Type": "Notification",
"UnsubscribeUrl": "https://sns.us-east-1.amazonaws.com/?Action=Unsubscribe&SubscriptionArn=arn:aws:sns:us-east-1:123456789012:test-lambda:21be56ed-a058-49f5-8c98-aedd2564c486",
"TopicArn":"arn:aws:sns:us-east-1:123456789012:sns-lambda",
"Subject": "TestInvoke"
}
}
]
}
```
# Tutorial: Utilizzo AWS Lambda con Amazon Simple Notification Service
In questo tutorial, utilizzi una funzione Lambda in un'unica funzione Account AWS per iscriverti a un argomento di Amazon Simple Notification Service (Amazon SNS) in un altro argomento. Account AWS Quando pubblichi messaggi sul tuo argomento Amazon SNS, la funzione Lambda legge il contenuto del messaggio e lo invia ad Amazon Logs. CloudWatch Per completare questo tutorial, usa il (). AWS Command Line Interface AWS CLI
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-sns-tutorial/sns_tut_resources.png)
Per completare questo tutorial, esegui i passaggi riportati:
+ Nell'**account A**, crea un argomento Amazon SNS.
+ Nell'**account B**, crea una funzione Lambda che leggerà i messaggi dall'argomento.
+ Nell'**account B**, crea una sottoscrizione all'argomento.
+ Pubblica messaggi sull'argomento Amazon SNS nell'**account A** e conferma che la funzione Lambda nell'**account B** li invii nei log. CloudWatch
Completando questi passaggi, imparerai come configurare un argomento Amazon SNS per richiamare una funzione Lambda. Imparerai anche come creare una policy AWS Identity and Access Management (IAM) che autorizzi una risorsa in un'altra Account AWS a richiamare Lambda.
Nel tutorial, vengono utilizzati due Account AWS separati. I AWS CLI comandi illustrano ciò utilizzando due profili denominati chiamati `accountA` e`accountB`, ciascuno configurato per l'uso con un altro. Account AWS Per informazioni su come configurare l'utilizzo AWS CLI di profili diversi, consulta [Impostazioni dei file di configurazione e credenziali](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) nella *Guida per l'AWS Command Line Interface utente della versione 2*. Assicurati di configurare lo stesso valore predefinito Regione AWS per entrambi i profili.
Se i AWS CLI profili creati per i due Account AWS utilizzano nomi diversi o se utilizzi il profilo predefinito e un profilo denominato, modifica i AWS CLI comandi nei passaggi seguenti in base alle esigenze.
## Prerequisiti
### Installa il AWS Command Line Interface
Se non l'hai ancora installato AWS Command Line Interface, segui i passaggi indicati in [Installazione o aggiornamento della versione più recente di AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) per installarlo.
Per eseguire i comandi nel tutorial, sono necessari un terminale a riga di comando o una shell (interprete di comandi). In Linux e macOS, utilizza la shell (interprete di comandi) e il gestore pacchetti preferiti.
**Nota**
Su Windows, alcuni comandi della CLI Bash utilizzati comunemente con Lambda (ad esempio, `zip`) non sono supportati dai terminali integrati del sistema operativo. Per ottenere una versione integrata su Windows di Ubuntu e Bash, [installa il sottosistema Windows per Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10).
## Creare un argomento Amazon SNS (account A)
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-sns-tutorial/sns_tut_steps_1.png)
**Per creare l'argomento**
+ Nell'**account A**, crea un argomento standard di Amazon SNS utilizzando il seguente AWS CLI comando.
```
aws sns create-topic --name sns-topic-for-lambda --profile accountA
```
Verrà visualizzato un output simile al seguente.
```
{
"TopicArn": "arn:aws:sns:us-west-2:123456789012:sns-topic-for-lambda"
}
```
Prendi nota del nome della risorsa Amazon (ARN) dell'argomento. Sarà necessario in seguito nel tutorial, quando aggiungerai autorizzazioni alla funzione Lambda per effettuare la sottoscrizione all'argomento.
## Creazione di un ruolo di esecuzione della funzione (account B)
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-sns-tutorial/sns_tut_steps_2.png)
Un ruolo di esecuzione è un ruolo IAM che concede a una funzione Lambda l'autorizzazione all' Servizi AWS accesso e alle risorse. Prima di creare la funzione nell'**account B**, crei un ruolo che fornisce alla funzione le autorizzazioni di base per scrivere i log nei registri. CloudWatch Aggiungeremo le autorizzazioni per la lettura dal tuo argomento Amazon SNS in un passaggio successivo.
**Creazione di un ruolo di esecuzione**
1. Nell'**account B** apri la [pagina dei ruoli](https://console.aws.amazon.com/iam/home#/roles) nella console IAM.
1. Scegli **Crea ruolo**.
1. Per **Tipo di entità attendibile**, scegli **Servizio AWS **.
1. In **Caso d'uso**, scegli **Lambda**.
1. Scegli **Next (Successivo)**.
1. Aggiungi una policy di autorizzazioni di base al ruolo completando le seguenti operazioni:
1. Nella casella di ricerca **Policy di autorizzazione**, inserisci **AWSLambdaBasicExecutionRole**.
1. Scegli **Next (Successivo)**.
1. Completa la creazione del ruolo effettuando le seguenti operazioni:
1. In **Dettagli ruolo**, immetti **lambda-sns-role** per **Nome ruolo**.
1. Scegli **Crea ruolo**.
## Creare una funzione Lambda (account B)
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-sns-tutorial/sns_tut_steps_3.png)
Crea una funzione Lambda che elabora i messaggi Amazon SNS. Il codice funzione registra il contenuto dei messaggi di ogni record in Amazon CloudWatch Logs.
Questo tutorial utilizza il runtime Node.js 24, ma abbiamo anche fornito codice di esempio in altri linguaggi di runtime. Per visualizzare il codice per il runtime che ti interessa, seleziona la scheda corrispondente nella casella seguente. Il JavaScript codice che utilizzerai in questo passaggio si trova nel primo esempio mostrato nella **JavaScript**scheda.
------
#### [ .NET ]
**SDK per .NET**
C'è altro su GitHub. Trova l'esempio completo e scopri come eseguire la configurazione e l'esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sns-to-lambda).
Utilizzo di un evento SNS con Lambda tramite .NET.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using Amazon.Lambda.Core;
using Amazon.Lambda.SNSEvents;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace SnsIntegration;
public class Function
{
public async Task FunctionHandler(SNSEvent evnt, ILambdaContext context)
{
foreach (var record in evnt.Records)
{
await ProcessRecordAsync(record, context);
}
context.Logger.LogInformation("done");
}
private async Task ProcessRecordAsync(SNSEvent.SNSRecord record, ILambdaContext context)
{
try
{
context.Logger.LogInformation($"Processed record {record.Sns.Message}");
// TODO: Do interesting work based on the new message
await Task.CompletedTask;
}
catch (Exception e)
{
//You can use Dead Letter Queue to handle failures. By configuring a Lambda DLQ.
context.Logger.LogError($"An error occurred");
throw;
}
}
}
```
------
#### [ Go ]
**SDK per Go V2**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sns-to-lambda).
Utilizzo di un evento SNS con Lambda tramite Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package main
import (
"context"
"fmt"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func handler(ctx context.Context, snsEvent events.SNSEvent) {
for _, record := range snsEvent.Records {
processMessage(record)
}
fmt.Println("done")
}
func processMessage(record events.SNSEventRecord) {
message := record.SNS.Message
fmt.Printf("Processed message: %s\n", message)
// TODO: Process your record here
}
func main() {
lambda.Start(handler)
}
```
------
#### [ Java ]
**SDK per Java 2.x**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sns-to-lambda).
Utilizzo di un evento SNS con Lambda tramite Java.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package example;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.LambdaLogger;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.SNSEvent;
import com.amazonaws.services.lambda.runtime.events.SNSEvent.SNSRecord;
import java.util.Iterator;
import java.util.List;
public class SNSEventHandler implements RequestHandler {
LambdaLogger logger;
@Override
public Boolean handleRequest(SNSEvent event, Context context) {
logger = context.getLogger();
List records = event.getRecords();
if (!records.isEmpty()) {
Iterator recordsIter = records.iterator();
while (recordsIter.hasNext()) {
processRecord(recordsIter.next());
}
}
return Boolean.TRUE;
}
public void processRecord(SNSRecord record) {
try {
String message = record.getSNS().getMessage();
logger.log("message: " + message);
} catch (Exception e) {
throw new RuntimeException(e);
}
}
}
```
------
#### [ JavaScript ]
**SDK per JavaScript (v3)**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/blob/main/integration-sns-to-lambda).
Consumo di un evento SNS con JavaScript Lambda utilizzando.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
exports.handler = async (event, context) => {
for (const record of event.Records) {
await processMessageAsync(record);
}
console.info("done");
};
async function processMessageAsync(record) {
try {
const message = JSON.stringify(record.Sns.Message);
console.log(`Processed message ${message}`);
await Promise.resolve(1); //Placeholder for actual async work
} catch (err) {
console.error("An error occurred");
throw err;
}
}
```
Consumo di un evento SNS con TypeScript Lambda utilizzando.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import { SNSEvent, Context, SNSHandler, SNSEventRecord } from "aws-lambda";
export const functionHandler: SNSHandler = async (
event: SNSEvent,
context: Context
): Promise => {
for (const record of event.Records) {
await processMessageAsync(record);
}
console.info("done");
};
async function processMessageAsync(record: SNSEventRecord): Promise {
try {
const message: string = JSON.stringify(record.Sns.Message);
console.log(`Processed message ${message}`);
await Promise.resolve(1); //Placeholder for actual async work
} catch (err) {
console.error("An error occurred");
throw err;
}
}
```
------
#### [ PHP ]
**SDK per PHP**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sns-to-lambda).
Utilizzo di un evento SNS con Lambda tramite PHP.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
getRecords() as $record) {
$message = $record->getMessage();
// TODO: Implement your custom processing logic here
// Any exception thrown will be logged and the invocation will be marked as failed
echo "Processed Message: $message" . PHP_EOL;
}
}
}
return new Handler();
```
------
#### [ Python ]
**SDK per Python (Boto3)**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sns-to-lambda).
Utilizzo di un evento SNS con Lambda tramite Python.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def lambda_handler(event, context):
for record in event['Records']:
process_message(record)
print("done")
def process_message(record):
try:
message = record['Sns']['Message']
print(f"Processed message {message}")
# TODO; Process your record here
except Exception as e:
print("An error occurred")
raise e
```
------
#### [ Ruby ]
**SDK per Ruby**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sns-to-lambda).
Utilizzo di un evento SNS con Lambda tramite Ruby.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def lambda_handler(event:, context:)
event['Records'].map { |record| process_message(record) }
end
def process_message(record)
message = record['Sns']['Message']
puts("Processing message: #{message}")
rescue StandardError => e
puts("Error processing message: #{e}")
raise
end
```
------
#### [ Rust ]
**SDK per Rust**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sns-to-lambda).
Utilizzo di un evento SNS con Lambda tramite Rust.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
use aws_lambda_events::event::sns::SnsEvent;
use aws_lambda_events::sns::SnsRecord;
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
use tracing::info;
// Built with the following dependencies:
// aws_lambda_events = { version = "0.10.0", default-features = false, features = ["sns"] }
// lambda_runtime = "0.8.1"
// tokio = { version = "1", features = ["macros"] }
// tracing = { version = "0.1", features = ["log"] }
// tracing-subscriber = { version = "0.3", default-features = false, features = ["fmt"] }
async fn function_handler(event: LambdaEvent) -> Result<(), Error> {
for event in event.payload.records {
process_record(&event)?;
}
Ok(())
}
fn process_record(record: &SnsRecord) -> Result<(), Error> {
info!("Processing SNS Message: {}", record.sns.message);
// Implement your record handling code here.
Ok(())
}
#[tokio::main]
async fn main() -> Result<(), Error> {
tracing_subscriber::fmt()
.with_max_level(tracing::Level::INFO)
.with_target(false)
.without_time()
.init();
run(service_fn(function_handler)).await
}
```
------
**Creazione della funzione**
1. Crea una directory per il progetto, quindi passa a quella directory.
```
mkdir sns-tutorial
cd sns-tutorial
```
1. Copia il JavaScript codice di esempio in un nuovo file denominato`index.js`.
1. Crea un pacchetto di implementazione utilizzando il seguente comando `zip`.
```
zip function.zip index.js
```
1. Esegui il AWS CLI comando seguente per creare la tua funzione Lambda nell'**account B.**
```
aws lambda create-function --function-name Function-With-SNS \
--zip-file fileb://function.zip --handler index.handler --runtime nodejs24.x \
--role arn:aws:iam:::role/lambda-sns-role \
--timeout 60 --profile accountB
```
Verrà visualizzato un output simile al seguente.
```
{
"FunctionName": "Function-With-SNS",
"FunctionArn": "arn:aws:lambda:us-west-2:123456789012:function:Function-With-SNS",
"Runtime": "nodejs24.x",
"Role": "arn:aws:iam::123456789012:role/lambda_basic_role",
"Handler": "index.handler",
...
"RuntimeVersionConfig": {
"RuntimeVersionArn": "arn:aws:lambda:us-west-2::runtime:7d5f06b69c951da8a48b926ce280a9daf2e8bb1a74fc4a2672580c787d608206"
}
}
```
1. Registra il nome della risorsa Amazon (ARN) della funzione. Sarà necessario in seguito nel tutorial, quando aggiungerai autorizzazioni per consentire ad Amazon SNS di richiamare la funzione.
## Aggiunta di autorizzazioni alla funzione (account B)
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-sns-tutorial/sns_tut_steps_4.png)
Perché Amazon SNS richiami la tua funzione, è necessario concedergli l'autorizzazione in una istruzione su una [policy basata sulle risorse](access-control-resource-based.md). Si aggiunge questa dichiarazione utilizzando il AWS CLI `add-permission` comando.
**Concessione dell'autorizzazione di Amazon SNS per richiamare la tua funzione**
+ Nell'**account B**, esegui il AWS CLI comando seguente utilizzando l'ARN per l'argomento Amazon SNS che hai registrato in precedenza.
```
aws lambda add-permission --function-name Function-With-SNS \
--source-arn arn:aws:sns:us-east-1::sns-topic-for-lambda \
--statement-id function-with-sns --action "lambda:InvokeFunction" \
--principal sns.amazonaws.com --profile accountB
```
Verrà visualizzato un output simile al seguente.
```
{
"Statement": "{\"Condition\":{\"ArnLike\":{\"AWS:SourceArn\":
\"arn:aws:sns:us-east-1::sns-topic-for-lambda\"}},
\"Action\":[\"lambda:InvokeFunction\"],
\"Resource\":\"arn:aws:lambda:us-east-1::function:Function-With-SNS\",
\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"sns.amazonaws.com\"},
\"Sid\":\"function-with-sns\"}"
}
```
**Nota**
Se l'account con l'argomento Amazon SNS è ospitato in un [opt-in Regione AWS](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html), devi specificare la regione nell'area principale. Ad esempio, se stai lavorando con un argomento Amazon SNS nella regione Asia Pacifico (Hong Kong), per il principale devi specificare `sns.ap-east-1.amazonaws.com` invece di `sns.amazonaws.com`.
## Concessione dell'autorizzazione tra più account per la sottoscrizione ad Amazon SNS (account A)
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-sns-tutorial/sns_tut_steps_5.png)
Perché la funzione Lambda nell'**account B** sottoscriva l'argomento Amazon SNS che hai creato nell'**account A**, è necessario concedere l'autorizzazione per l'**account B** in modo da sottoscrivere il tuo argomento. Concedi questa autorizzazione utilizzando il AWS CLI `add-permission` comando.
**Concessione dell'autorizzazione per consentire all'account B la sottoscrizione all'argomento**
+ Nell'**account A**, esegui il seguente AWS CLI comando. Usa l'ARN per l'argomento Amazon SNS registrato in precedenza.
```
aws sns add-permission --label lambda-access --aws-account-id \
--topic-arn arn:aws:sns:us-east-1::sns-topic-for-lambda \
--action-name Subscribe ListSubscriptionsByTopic --profile accountA
```
## Creare una sottoscrizione (account B)
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-sns-tutorial/sns_tut_steps_6.png)
Nell'**account B**, ora sottoscrivi la tua funzione Lambda all'argomento Amazon SNS che hai creato all'inizio del tutorial nell'**account A**. Quando viene inviato un messaggio a questo argomento (`sns-topic-for-lambda`), Amazon SNS richiama la funzione Lambda `Function-With-SNS` nell'**account B**.
**Creazione di una sottoscrizione**
+ Nell'**account B**, esegui il AWS CLI comando seguente. Usa l'area predefinita in cui hai creato l'argomento e la funzione ARNs for your topic e Lambda.
```
aws sns subscribe --protocol lambda \
--region us-east-1 \
--topic-arn arn:aws:sns:us-east-1::sns-topic-for-lambda \
--notification-endpoint arn:aws:lambda:us-east-1::function:Function-With-SNS \
--profile accountB
```
Verrà visualizzato un output simile al seguente.
```
{
"SubscriptionArn": "arn:aws:sns:us-east-1::sns-topic-for-lambda:5d906xxxx-7c8x-45dx-a9dx-0484e31c98xx"
}
```
## Pubblicazione di messaggi sull'argomento (account A e account B)
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/services-sns-tutorial/sns_tut_steps_7.png)
Ora che la tua funzione Lambda nell'**account B** ha sottoscritto l'argomento Amazon SNS nell'**account A**, è il momento di testare la configurazione pubblicando messaggi sull'argomento. Per confermare che Amazon SNS ha richiamato la funzione Lambda, utilizza CloudWatch Logs per visualizzare l'output della funzione.
**Pubblicazione di un messaggio sull' argomento e visualizzazione dell'output della tua funzione**
1. Digita `Hello World` in un file di testo e salvalo come `message.txt`.
1. **Dalla stessa directory in cui hai salvato il file di testo, esegui il seguente AWS CLI comando nell'account A.** Usa l'ARN per il tuo argomento.
```
aws sns publish --message file://message.txt --subject Test \
--topic-arn arn:aws:sns:us-east-1::sns-topic-for-lambda \
--profile accountA
```
In questo modo verrà restituito un ID messaggio con un identificatore univoco, indicando che il messaggio è stato accettato da Amazon SNS. Amazon SNS prova quindi a consegnare il messaggio a tutti i sottoscrittori dell'argomento. Per confermare che Amazon SNS ha richiamato la funzione Lambda, usa CloudWatch Logs per visualizzare l'output della funzione:
1. Nell'**account B**, apri la pagina dei [gruppi di log](https://console.aws.amazon.com/cloudwatch/home#logsV2:log-groups) della CloudWatch console Amazon.
1. Scegli il nome del gruppo di log per la funzione (`/aws/lambda/Function-With-SNS`).
1. Scegli il flusso di log più recente.
1. Se la funzione è stata richiamata correttamente, vedrai un output simile al seguente che mostra il contenuto del messaggio pubblicato sull'argomento.
```
2023-07-31T21:42:51.250Z c1cba6b8-ade9-4380-aa32-d1a225da0e48 INFO Processed message Hello World
2023-07-31T21:42:51.250Z c1cba6b8-ade9-4380-aa32-d1a225da0e48 INFO done
```
## Pulizia delle risorse
Ora è possibile eliminare le risorse create per questo tutorial, a meno che non si voglia conservarle. Eliminando AWS le risorse che non utilizzi più, eviti addebiti inutili ai tuoi Account AWS.
Nell'**Account A**, elimina l'argomento Amazon SNS.
**Per eliminare l'argomento Amazon SNS**
1. Aprire la [pagina Topics (Argomenti)](https://console.aws.amazon.com//sns/home#topics:) nella console Amazon SNS.
1. Selezionare l'argomento creato.
1. Scegli **Elimina**.
1. Inserisci **delete me** nel campo di immissione del testo.
1. Scegli **Elimina**.
Nell'**Account B**, elimina il ruolo di esecuzione, la funzione Lambda e la sottoscrizione Amazon SNS.
**Come eliminare il ruolo di esecuzione**
1. Aprire la pagina [Ruoli](https://console.aws.amazon.com/iam/home#/roles) della console IAM.
1. Selezionare il ruolo di esecuzione creato.
1. Scegliere **Elimina**.
1. Inserisci il nome del ruolo nel campo di immissione testo e seleziona **Delete** (Elimina).
**Per eliminare la funzione Lambda**
1. Aprire la pagina [Functions (Funzioni)](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Selezionare la funzione creata.
1. Scegliere **Operazioni**, **Elimina**.
1. Digita **confirm** nel campo di immissione testo e scegli **Delete** (Elimina).
**Per eliminare la sottoscrizione Amazon SNS**
1. Aprire la [pagina Subscriptions (Sottoscrizioni)](https://console.aws.amazon.com//sns/home#subscriptions:) nella console Amazon SNS.
1. Selezionare la sottoscrizione creata.
1. Scegli **Delete** (Elimina), poi **Delete** (Elimina).