

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

# Uso di Lambda con Amazon MSK
<a name="with-msk"></a>

[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
<a name="msk-sample-event"></a>

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
<a name="with-msk-cluster-network"></a>

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
<a name="msk-network-requirements"></a>

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
<a name="msk-nat-gateway"></a>

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
<a name="msk-vpc-privatelink"></a>

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
<a name="with-msk-permissions"></a>

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
<a name="msk-required-permissions"></a>

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
<a name="msk-basic-permissions"></a>

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
<a name="msk-cluster-permissions"></a>

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
<a name="msk-vpc-permissions"></a>

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
<a name="msk-optional-permissions"></a>

 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
<a name="with-msk-configure"></a>

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
<a name="msk-esm-overview"></a>

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
<a name="msk-cluster-auth"></a>

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
<a name="msk-unauthenticated"></a>

Se nessun client accede al cluster tramite Internet, è possibile utilizzare l'accesso non autenticato.

## Autenticazione SASL/SCRAM
<a name="msk-sasl-scram"></a>

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
<a name="msk-mtls"></a>

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
<a name="mtls-auth-secret"></a>

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-----  
        <certificate contents>
-----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-----  
         <private key contents>
-----END PRIVATE KEY-----
```

Per una chiave privata crittografata, utilizza la struttura seguente:

```
-----BEGIN ENCRYPTED PRIVATE KEY-----  
          <private key contents>
-----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
<a name="msk-iam-auth"></a>

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
<a name="msk-bootstrap-brokers"></a>

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
<a name="msk-esm-create"></a>

[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
<a name="msk-cross-account"></a>

È 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
<a name="msk-esm-parameters"></a>

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
<a name="services-msk-tutorial"></a>

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
<a name="w2aad101c23c15c35c19"></a>

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
<a name="install_aws_cli"></a>

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
<a name="w2aad101c23c15c35c21"></a>

 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
<a name="w2aad101c23c15c35c23"></a>

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
<a name="w2aad101c23c15c35c25"></a>

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
<a name="w2aad101c23c15c35c27"></a>

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
<a name="w2aad101c23c15c35c29"></a>

 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
{
    
    
    /// <param name="input">The event for the Lambda function handler to process.</param>
    /// <param name="context">The ILambdaContext that provides methods for logging and describing the Lambda environment.</param>
    /// <returns></returns>
    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<KafkaEvent, Void> {

    @Override
    public Void handleRequest(KafkaEvent event, Context context) {
        for (Map.Entry<String, java.util.List<KafkaEventRecord>> 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<void> => {
  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.  

```
<?php
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0

// using bref/bref and bref/logger for simplicity

use Bref\Context\Context;
use Bref\Event\Kafka\KafkaEvent;
use Bref\Event\Handler as StdHandler;
use Bref\Logger\StderrLogger;

require __DIR__ . '/vendor/autoload.php';

class Handler implements StdHandler
{
    private StderrLogger $logger;
    public function __construct(StderrLogger $logger)
    {
        $this->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<KafkaEvent>) -> Result<Value, Error> {

    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
<a name="w2aad101c23c15c35c31"></a>

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)