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à.
# In che modo Lambda elabora i record provenienti da origini eventi basate su flussi e code
Uno *strumento di mappatura dell'origine degli eventi* è una risorsa Lambda che legge gli elementi da servizi basati su flussi o code e richiama una funzione con batch di record. All'interno di uno strumento di mappatura dell'origine degli eventi, risorse chiamate *poller di eventi* cercano attivamente nuovi messaggi e richiamano funzioni. Per impostazione predefinita, Lambda scala automaticamente i poller di eventi, ma per determinati tipi di origini eventi, puoi utilizzare la [modalità provisioning](#invocation-eventsourcemapping-provisioned-mode) per controllare il numero minimo e massimo di poller di eventi dedicati allo strumento di mappatura dell'origine degli eventi.
I seguenti servizi utilizzano gli strumenti di mappatura dell'origine degli eventi per richiamare le funzioni Lambda:
+ [Amazon DocumentDB (compatibile con MongoDB) (Amazon DocumentDB)](with-documentdb.md)
+ [Amazon DynamoDB](with-ddb.md)
+ [Amazon Kinesis](with-kinesis.md)
+ [Amazon MQ](with-mq.md)
+ [Amazon Managed Streaming for Apache Kafka (Amazon MSK)](with-msk.md)
+ [Apache Kafka gestito dal cliente](with-kafka.md)
+ [Amazon Simple Queue Service (Amazon SQS)](with-sqs.md)
**avvertimento**
Gli strumenti di mappatura dell'origine degli eventi elaborano ogni evento almeno una volta e può verificarsi un'elaborazione duplicata dei record. Per evitare potenziali problemi legati agli eventi duplicati, ti consigliamo vivamente di rendere idempotente il codice della funzione. Per ulteriori informazioni, consulta [Come posso rendere idempotente la mia funzione Lambda](https://repost.aws/knowledge-center/lambda-function-idempotent) nel Knowledge Center. AWS
## In che modo gli strumenti di mappatura dell'origine degli eventi differiscono dai trigger diretti
*Alcuni Servizi AWS possono richiamare direttamente le funzioni Lambda utilizzando i trigger.* Questi servizi inviano eventi a Lambda e la funzione viene richiamata immediatamente quando si verifica l'evento specificato. I trigger sono adatti per eventi discreti ed elaborazione in tempo reale. Quando [crei un trigger utilizzando la console Lambda, la console](lambda-services.md#lambda-invocation-trigger) interagisce con il AWS servizio corrispondente per configurare la notifica degli eventi su quel servizio. Il trigger viene effettivamente archiviato e gestito dal servizio che genera gli eventi, non da Lambda. Ecco alcuni esempi di servizi che utilizzano i trigger per richiamare le funzioni Lambda:
+ **Amazon Simple Storage Service (Amazon S3):** richiama una funzione quando un oggetto viene creato, eliminato o modificato in un bucket. Per ulteriori informazioni, consulta [Tutorial: uso di un trigger Amazon S3 per richiamare una funzione Lambda](with-s3-example.md).
+ **Amazon Simple Notification Service (Amazon SNS)**: richiama una funzione quando un messaggio è pubblicato in un argomento SNS. Per ulteriori informazioni, consulta [Tutorial: Utilizzo AWS Lambda con Amazon Simple Notification Service](with-sns-example.md).
+ **Gateway Amazon API:** richiama una funzione quando viene effettuata una richiesta API a un endpoint specifico. Per ulteriori informazioni, consulta [Richiamo di funzione Lambda utilizzando un endpoint Gateway Amazon API](services-apigateway.md).
Gli strumenti di mappatura dell'origine degli eventi sono risorse Lambda create e gestite all'interno del servizio Lambda. Gli strumenti di mappatura dell'origine degli eventi sono progettate per l'elaborazione di dati o messaggi in streaming ad alto volume dalle code. L'elaborazione dei record da un flusso o da una coda in batch è più efficiente rispetto all'elaborazione dei record singolarmente.
## Comportamento di batching
Per impostazione predefinita, una mappatura delle origini eventi raggruppa i registri in un unico payload che Lambda invia alla funzione. Per ottimizzare il comportamento del batch, è possibile configurare una finestra di batch ([MaximumBatchingWindowInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumBatchingWindowInSeconds)) e una dimensione del batch ([BatchSize](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-response-BatchSize)). Una finestra di batch è il tempo massimo per la raccolta dei registri in un singolo payload. La dimensione del batch è il numero massimo di registri in un singolo batch. Lambda richiama la funzione in presenza dei tre criteri seguenti:
+ **La finestra di dosaggio raggiunge il valore massimo.** Il comportamento predefinito della finestra di batch varia in base alla specifica origine eventi.
+ **Per le origini eventi Kinesis, DynamoDB e Amazon SQS:** la finestra di batch di default è 0 secondi. Ciò significa che Lambda richiama la funzione non appena i record sono disponibili. Per impostare una finestra di batch, configura `MaximumBatchingWindowInSeconds`. È possibile impostare questo parametro su qualsiasi valore da compreso tra 0 e 300 secondi con incrementi di 1 secondo. Se si configura una la finestra di batch, la finestra successiva inizia non appena viene completato il precedente richiamo della funzione.
+ **Per le origini degli eventi di Amazon MSK, Apache Kafka autogestito, Amazon MQ e Amazon DocumentDB** la finestra di batch predefinita è 500 ms. È possibile configurare `MaximumBatchingWindowInSeconds` su qualsiasi valore da 0 secondi a 300 secondi con incrementi di secondi. Nella modalità preimpostata per le mappature delle sorgenti degli eventi Kafka, quando si configura una finestra di batch, la finestra successiva inizia non appena viene completato il batch precedente. Nelle mappature delle sorgenti di eventi Kafka senza provisioning, quando si configura una finestra di batch, la finestra successiva inizia non appena viene completata la precedente invocazione della funzione. Per ridurre al minimo la latenza quando si utilizzano le mappature delle sorgenti degli eventi Kafka in modalità provisioning, impostate su 0. `MaximumBatchingWindowInSeconds` Questa impostazione assicura che Lambda inizi l'elaborazione del batch successivo immediatamente dopo aver completato la chiamata della funzione corrente. Per ulteriori informazioni sull'elaborazione a bassa latenza, consulta. [Apache Kafka a bassa latenza](with-kafka-low-latency.md)
+ **Per le sorgenti di eventi Amazon MQ e Amazon DocumentDB:** la finestra di batch predefinita è di 500 ms. È possibile configurare `MaximumBatchingWindowInSeconds` su qualsiasi valore da 0 secondi a 300 secondi con incrementi di secondi. Una finestra di batch inizia non appena arriva il primo registro.
**Nota**
Perché è possibile modificare `MaximumBatchingWindowInSeconds` solo in incrementi di secondi, non puoi tornare alla finestra di batch predefinita di 500 ms dopo averla modificata. Per ripristinare la finestra di batch predefinita, è necessario creare una nuova mappatura dell'origine eventi.
+ **Le dimensioni del batch sono soddisfatte.** La dimensione minima del batch è 1. La dimensione predefinita e massima del batch dipendono dall'origine eventi. Per ulteriori informazioni su questi valori, consulta le specifiche di [BatchSize](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-BatchSize) per l'operazione API `CreateEventSourceMapping`.
+ **La dimensione del payload raggiunge [6 MB](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html).** Tale limite non è modificabile.
Il diagramma seguente illustra queste tre configurazioni. Supponiamo che una finestra di batch inizi a `t = 7` secondi. Nel primo scenario, la finestra di batch raggiunge il suo massimo di 40 secondi a `t = 47` secondi dopo aver accumulato 5 registri. Nel secondo scenario, la dimensione del batch raggiunge 10 prima della scadenza della finestra di batch, quindi la finestra di batch termina in anticipo. Nel secondo scenario, il valore massimo del payload viene raggiunta prima della scadenza della finestra di batch, quindi la finestra di batch termina in anticipo.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/batching-window.png)
Consigliamo di eseguire il test con dimensioni di batch e record diverse in modo che la frequenza di polling di ogni origine eventi sia regolata in base alla velocità con cui la funzione è in grado di completare l'attività. Il [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)`BatchSize`parametro controlla il numero massimo di record che possono essere inviati alla funzione con ogni chiamata. Una dimensione di batch maggiore può spesso assorbire in modo più efficiente il costo associato all'invocazione in un set di record più grande, aumentando in tal modo il throughput.
Lambda non attende il completamento di alcuna [estensione](lambda-extensions.md) prima di inviare il batch successivo per l'elaborazione. In altre parole, le estensioni possono continuare a funzionare mentre Lambda elabora il successivo batch di record. Ciò può causare problemi di limitazione in caso di violazione delle impostazioni o dei limiti di [simultaneità](lambda-concurrency.md). Per rilevare se si tratta di un potenziale problema, monitora le tue funzioni e verifica se i [parametri di simultaneità](monitoring-concurrency.md#general-concurrency-metrics) per lo strumento di mappatura dell'origine degli eventi sono superiori al previsto. A causa degli intervalli ridotti tra le invocazioni, Lambda potrebbe segnalare brevemente un utilizzo della simultaneità maggiore rispetto al numero di partizioni. Ciò può essere vero anche per le funzioni Lambda senza estensioni.
Per impostazione predefinita, se la funzione restituisce un errore, l'intera mappatura del batch viene rielaborato fino a quando la funzione non restituisce esito positivo o gli elementi nel batch scadono. Per garantire l'ordine di elaborazione, l'elaborazione della mappatura delle fonti eventi per gli shard interessati viene messa in pausa finché l'errore non viene risolto. Per le origini di flusso (DynamoDB e Kinesis), è possibile configurare il numero massimo di tentativi che Lambda effettua quando la funzione restituisce un errore. Gli errori di servizio o le limitazioni per cui il batch non raggiunge la funzione non vengono conteggiati ai fini dei tentativi ripetuti. È inoltre possibile configurare lo strumento di mappatura dell'origine degli eventi per inviare un record di invocazione a una [destinazione](invocation-async-retain-records.md#invocation-async-destinations) quando elimina un batch di eventi.
## Modalità provisioning
Gli strumenti di mappatura dell'origine degli eventi Lambda utilizzano i poller di eventi per interrogare l'origine eventi alla ricerca di nuovi messaggi. Per impostazione predefinita, Lambda gestisce la scalabilità automatica di questi poller in base al volume dei messaggi. Quando il traffico di messaggi aumenta, Lambda aumenta automaticamente il numero di poller di eventi per gestire il carico e li riduce quando il traffico diminuisce.
In modalità provisioned, puoi ottimizzare la velocità effettiva della mappatura delle sorgenti degli eventi definendo limiti minimi e massimi per le risorse di polling dedicate che rimangono pronte a gestire i modelli di traffico previsti. Queste risorse si scalano automaticamente 3 volte più velocemente per gestire picchi improvvisi nel traffico degli eventi e forniscono una capacità 16 volte superiore per elaborare milioni di eventi. Questo ti aiuta a creare carichi di lavoro basati sugli eventi altamente reattivi con requisiti prestazionali rigorosi.
In Lambda, un event poller è un'unità di calcolo con funzionalità di throughput che variano in base al tipo di origine dell'evento. Per Amazon MSK e Apache Kafka autogestito, ogni event poller può gestire fino al 5% MB/sec del throughput o fino a 5 chiamate simultanee. Ad esempio, se la fonte dell'evento produce un payload medio di 1 MB e la durata media della funzione è di 1 secondo, un singolo event poller di eventi Kafka può supportare 5 MB/sec velocità effettiva e 5 chiamate Lambda simultanee (presupponendo che non vi sia alcuna trasformazione del payload). Per Amazon SQS, ogni event poller può gestire fino all'1% MB/sec del throughput o fino a 10 chiamate simultanee. L'utilizzo della modalità provisioned comporta costi aggiuntivi in base all'utilizzo dell'event poller. Per i dettagli sui prezzi, vedere [Prezzi di AWS Lambda](https://aws.amazon.com/lambda/pricing/).
La modalità provisioned è disponibile per Amazon MSK, Apache Kafka autogestite e sorgenti di eventi Amazon SQS. Mentre le impostazioni di simultaneità consentono di controllare la scalabilità della funzione, la modalità provisioning consente di controllare il throughput dello strumento di mappatura dell'origine degli eventi. Per garantire le massime prestazioni, potrebbe essere necessario regolare entrambe le impostazioni in modo indipendente.
La modalità Provisioned è ideale per applicazioni in tempo reale che richiedono una latenza di elaborazione degli eventi costante, come le società di servizi finanziari che elaborano i feed di dati di mercato, le piattaforme di e-commerce che forniscono consigli personalizzati in tempo reale e le società di gioco che gestiscono le interazioni tra giocatori dal vivo.
Ogni event poller supporta una capacità di throughput diversa:
+ Per Amazon MSK e Apache Kafka autogestito: fino al 5% MB/sec della velocità effettiva o fino a 5 richiami simultanei
+ Per Amazon SQS: fino all'1% MB/sec del throughput o fino a 10 richiami simultanei o fino a 10 chiamate API di polling SQS al secondo.
Per le mappature delle sorgenti di eventi Amazon SQS, puoi impostare il numero minimo di poller tra 2 e 200 con un valore predefinito di 2 e il numero massimo tra 2 e 2.000 con un valore predefinito di 200. Lambda ridimensiona il numero di sondaggi di eventi tra il minimo e il massimo configurati, aggiungendo rapidamente fino a 1.000 simultanee al minuto per fornire un'elaborazione coerente e a bassa latenza degli eventi.
Per le mappature delle sorgenti degli eventi Kafka, puoi impostare il numero minimo di poller tra 1 e 200 con un valore predefinito di 1 e il numero massimo tra 1 e 2.000 con un valore predefinito di 200. Lambda ridimensiona il numero di sondaggi degli eventi tra il minimo e il massimo configurati in base al backlog degli eventi nell'argomento per fornire un'elaborazione a bassa latenza degli eventi.
Tieni presente che per le sorgenti di eventi Amazon SQS, l'impostazione di concorrenza massima non può essere utilizzata con la modalità provisioned. Quando si utilizza la modalità provisioned, è possibile controllare la concorrenza tramite l'impostazione del numero massimo di poller di eventi.
Per informazioni dettagliate sulla configurazione della modalità provisioning, consulta le sezioni seguenti:
+ [Configurazione della modalità provisioning per gli strumenti di mappatura dell'origine degli eventi Amazon MSK](kafka-scaling-modes.md)
+ [Configurazione della modalità provisioning per lo strumento di mappatura dell'origine degli eventi di Apache Kafka autogestito](kafka-scaling-modes.md#kafka-provisioned-mode)
+ [Utilizzo della modalità provisioning con le mappature delle sorgenti degli eventi di Amazon SQS](with-sqs.md#sqs-provisioned-mode)
Per ridurre al minimo la latenza in modalità provisioned, impostate su 0. `MaximumBatchingWindowInSeconds` Questa impostazione assicura che Lambda inizi l'elaborazione del batch successivo immediatamente dopo aver completato la chiamata della funzione corrente. Per ulteriori informazioni sull'elaborazione a bassa latenza, consulta. [Apache Kafka a bassa latenza](with-kafka-low-latency.md)
Dopo aver configurato la modalità provisioning, puoi osservare l'utilizzo dei poller di eventi per il tuo carico di lavoro monitorando il parametro `ProvisionedPollers`. Per ulteriori informazioni, consulta [Parametri dello strumento di mappatura dell'origine degli eventi](monitoring-metrics-types.md#event-source-mapping-metrics).
## API della mappatura dell'origine eventi
Per gestire un'origine eventi con la [AWS Command Line Interface (AWS 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/), è possibile utilizzare le seguenti operazioni API:
+ [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)
+ [ListEventSourceMappings](https://docs.aws.amazon.com/lambda/latest/api/API_ListEventSourceMappings.html)
+ [GetEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_GetEventSourceMapping.html)
+ [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)
+ [DeleteEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteEventSourceMapping.html)
# Utilizzo di tag negli strumenti di mappatura dell'origine degli eventi
Puoi taggare gli strumenti di mappatura dell'origine degli eventi per organizzare e gestire le risorse. I tag sono coppie chiave-valore a forma libera associate alle risorse supportate su Servizi AWS. Per ulteriori informazioni sui casi d'uso dei tag, consulta [Strategie di tagging comuni nella Guida AWS](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#tag-strategies) *alle risorse di etichettatura e all'editor di tag*.
Gli strumenti di mappatura dell'origine degli eventi sono associati a funzioni che possono avere i propri tag. Gli strumenti di mappatura dell'origine degli eventi non ereditano automaticamente i tag dalle funzioni. Puoi utilizzare l' AWS Lambda API per visualizzare e aggiornare i tag. Puoi anche visualizzare e aggiornare i tag mentre gestisci una mappatura specifica dell'origine degli eventi nella console Lambda, compresi quelli che utilizzano la modalità Provisioned per Amazon SQS.
## Autorizzazioni necessarie per lavorare con i tag
Per consentire a un'identità AWS Identity and Access Management (IAM) (utente, gruppo o ruolo) di leggere o impostare tag su una risorsa, concedile le autorizzazioni corrispondenti:
+ **lambda: ListTags** —Quando una risorsa contiene dei tag, concedi questa autorizzazione a chiunque debba richiamarla. `ListTags` Per le funzioni con tag, questa autorizzazione è necessaria anche per `GetFunction`.
+ **lambda: TagResource** —Concedi questa autorizzazione a chiunque abbia bisogno di chiamare `TagResource` o eseguire un tag durante la creazione.
Facoltativamente, valuta la possibilità di concedere anche l'UntagResourceautorizzazione **lambda:** per consentire `UntagResource` le chiamate alla risorsa.
Per ulteriori informazioni, consulta [Policy IAM basate sull'identità per Lambda](access-control-identity-based.md).
## Utilizzo di tag con la console Lambda
Puoi utilizzare la console Lambda per creare mappature delle sorgenti di eventi con tag, aggiungere tag alle mappature delle sorgenti di eventi esistenti e filtrare le mappature delle sorgenti degli eventi per tag, comprese quelle configurate in modalità Provisioned per Amazon SQS.
Quando aggiungi un trigger per i servizi basati su flussi e code supportati tramite la console Lambda, Lambda crea automaticamente uno strumento di mappatura dell'origine degli eventi. Per ulteriori informazioni su queste origini eventi, consulta [In che modo Lambda elabora i record provenienti da origini eventi basate su flussi e code](invocation-eventsourcemapping.md). Per creare uno strumento di mappatura dell'origine degli eventi nella console, sono necessari i prerequisiti seguenti:
+ Una funzione .
+ Un'origine eventi proveniente da un servizio interessato.
È possibile aggiungere i tag come parte della stessa interfaccia utente utilizzata per creare o aggiornare i trigger.
**Per aggiungere un tag durante la creazione di uno strumento di mappatura dell'origine degli eventi**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegli il nome della funzione .
1. In **Panoramica delle funzioni**, scegliere **Aggiungi trigger**.
1. In **Configurazione trigger**, nell'elenco a discesa, scegli il nome del servizio da cui proviene l'origine eventi.
1. Fornisci la configurazione di base per la tua origine eventi. Per ulteriori informazioni sulla configurazione dell'origine eventi, consulta la sezione per il servizio correlato in [Richiamare Lambda con eventi di altri servizi AWS](lambda-services.md).
1. In **Configurazione dello strumento di mappatura dell'origine degli eventi**, scegli **Impostazioni aggiuntive**.
1. In **Tag**, seleziona **Aggiungi nuovo tag**.
1. Nel campo **Chiave**, inserisci la chiave del tag. *Per informazioni sulle restrizioni relative ai tag, consulta [Limiti e requisiti di denominazione dei tag nella Guida alle risorse di etichettatura e all'editor di](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) tag. AWS *
1. Scegliere **Aggiungi**.
**Per aggiungere tag a uno strumento di mappatura dell'origine degli eventi esistente**
1. Apri [Strumenti di mappatura dell'origine degli eventi](https://console.aws.amazon.com/lambda/home#/event-source-mappings) nella console Lambda.
1. Dall'elenco delle risorse, scegli l'**UUID** per lo strumento di mappatura dell'origine degli eventi corrispondente alla **funzione** e all'**ARN dell'origine eventi**.
1. Dall'elenco delle schede sotto il **riquadro di configurazione generale**, scegli **Tag**.
1. Scegliere **Gestisci tag**.
1. Scegliere **Aggiungi nuovo tag**.
1. Nel campo **Chiave**, inserisci la chiave del tag. Per informazioni sulle restrizioni relative ai tag, consulta [Limiti e requisiti di denominazione dei tag nella Guida alle risorse di etichettatura e](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) all'editor di *tag AWS *.
1. Scegli **Save** (Salva).
**Per filtrare gli strumenti di mappatura dell'origine degli eventi per tag**
1. Apri [Strumenti di mappatura dell'origine degli eventi](https://console.aws.amazon.com/lambda/home#/event-source-mappings) nella console Lambda.
1. Scegli la barra di ricerca.
1. Dall'elenco a discesa, seleziona la chiave di tag sotto **Tag**.
1. Seleziona **Usa: "nome-tag"** per vedere tutti gli strumenti di mappatura dell'origine degli eventi etichettati con questa chiave, oppure scegli un **operatore** per filtrare ulteriormente in base al valore.
1. Seleziona il valore del tag da filtrare in base a una combinazione di chiave e valore del tag.
La barra di ricerca supporta anche la ricerca di chiavi di tag. Immetti il nome di una chiave per trovarla nell'elenco.
## Usare i tag con il AWS CLI
Puoi aggiungere e rimuovere tag sulle risorse Lambda esistenti, inclusi gli strumenti di mappatura dell'origine degli eventi, con l'API Lambda. Puoi aggiungere i tag anche quando crei uno strumento di mappatura dell'origine degli eventi, che ti consente di mantenere etichettata una risorsa per tutto il suo ciclo di vita.
### Aggiornamento dei tag con il tag Lambda APIs
Puoi aggiungere e rimuovere tag per le risorse Lambda supportate tramite le operazioni [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html)e [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html)API.
Puoi chiamare queste operazioni tramite la AWS CLI. Per aggiungere i tag a una risorsa esistente, utilizza il comando `tag-resource`. Questo esempio aggiunge due tag, uno con la chiave *Department* e uno con la chiave*CostCenter*.
```
aws lambda tag-resource \
--resource arn:aws:lambda:us-east-2:123456789012:resource-type:my-resource \
--tags Department=Marketing,CostCenter=1234ABCD
```
Pr rimuovere i tag, utilizza il comando `untag-resource`. Questo esempio rimuove il tag con la chiave*Department*.
```
aws lambda untag-resource --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier \
--tag-keys Department
```
### Aggiunta di tag durante la creazione di uno strumento di mappatura dell'origine degli eventi
Per creare una nuova mappatura delle sorgenti di eventi Lambda con tag, utilizza l'[CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)operazione API. Specifica il parametro `Tags`. È possibile richiamare questa operazione con il `create-event-source-mapping` AWS CLI comando e l'`--tags`opzione. *Per ulteriori informazioni sul comando CLI, vedere [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html)nel Command Reference AWS CLI .*
Prima di utilizzare il parametro `Tags` con `CreateEventSourceMapping`, assicurati che il tuo ruolo disponga dell'autorizzazione per etichettare le risorse oltre alle normali autorizzazioni necessarie per questa operazione. Per ulteriori informazioni sulle autorizzazioni per il tagging, consulta [Autorizzazioni necessarie per lavorare con i tag](#esm-tags-required-permissions).
### Visualizzazione dei tag con il tag Lambda APIs
Per visualizzare i tag applicati a una risorsa Lambda specifica, utilizza l'operazione API `ListTags`. Per ulteriori informazioni, consulta [ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html).
Puoi richiamare questa operazione con il `list-tags` AWS CLI comando fornendo un ARN (Amazon Resource Name).
```
aws lambda list-tags --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier
```
### Filtro delle risorse per tag
Puoi utilizzare l'operazione AWS Resource Groups Tagging API [GetResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_GetResources.html)API per filtrare le tue risorse in base ai tag. L'operazione `GetResources` riceve fino a 10 filtri, ognuno dei quali contenente una chiave di tag e un massimo di 10 valori di tag. Fornisci `GetResources` con un `ResourceType` per filtrare in base a tipi di risorse specifiche.
È possibile richiamare questa operazione utilizzando il `get-resources` AWS CLI comando. Per esempi di utilizzo di `get-resources`, consulta [get-resources](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/resourcegroupstaggingapi/get-resources.html#examples) nella *Riferimento ai comandi CLI di AWS *.