Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Invoquer Lambda avec des événements provenant d'autres services AWS
*Certains Services AWS peuvent appeler directement des fonctions Lambda à l'aide de déclencheurs.* Ces services envoient des événements à Lambda, et la fonction est invoquée aussitôt que l’événement spécifié se produit. Les déclencheurs sont adaptés aux événements discrets et au traitement en temps réel. Lorsque vous [créez un déclencheur à l'aide de la console Lambda](#lambda-invocation-trigger), celle-ci interagit avec le AWS service correspondant pour configurer la notification d'événement sur ce service. Le déclencheur est en fait stocké et géré par le service qui génère les événements, et non par Lambda.
Les événements sont des données structurées au format JSON. La structure JSON varie en fonction du service qui la génère et du type d’événement, mais elles contiennent toutes les données nécessaires à la fonction pour traiter l’événement.
Une fonction peut avoir plusieurs déclencheurs. Chaque déclencheur agit comme un client qui invoque votre fonction indépendamment, et chaque événement que Lambda transmet à votre fonction contient des données provenant d'un seul déclencheur. Lambda convertit le document d’événement en objet et le transmet à votre gestionnaire de fonctions.
Selon le service, l’invocation pilotée par l’événement peut être [synchrone](invocation-sync.md) ou [asynchrone](invocation-async.md).
+ Pour une invocation synchrone, l’autre service qui génère l’événement attend la réponse de votre fonction. Ce service définit les données que la fonction doit renvoyer dans la réponse. Le service contrôle la stratégie d’erreur, par exemple s’il faut réessayer les erreurs.
+ Pour l’invocation asynchrone, Lambda place l’événement dans une file d’attente avant de le transmettre à votre fonction. Lorsque Lambda met l’événement en file d’attent, il envoie immédiatement une réponse de réussite au service qui a généré l’événement. Après que la fonction ait traité l’événement, Lambda ne renvoie pas de réponse au service qui a généré l’événement.
## Création d’un déclencheur
La manière la plus simple de créer un déclencheur consiste à utiliser la console Lambda. Lorsque vous créez un déclencheur à l’aide de la console, Lambda dernier ajoute automatiquement les autorisations requises à la [politique basée sur les ressources](access-control-resource-based.md) de la fonction.
**Pour créer un déclencheur à l’aide de la console Lambda**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Sélectionnez la fonction pour laquelle vous souhaitez créer un déclencheur.
1. Dans le volet de **Présentation de la fonction**, choisissez **Ajouter un déclencheur**.
1. Sélectionnez le AWS service pour lequel vous souhaitez appeler votre fonction.
1. Renseignez les options dans le volet de **configuration du déclencheur** et choisissez **Ajouter**. En fonction de la fonction Service AWS que vous choisissez d'invoquer, les options de configuration du déclencheur seront différentes.
## Services pouvant appeler des fonctions Lambda
Le tableau suivant répertorie les services qui peuvent invoquer des fonctions Lambda.
****
| Service | Méthode d’invocation |
| --- | --- |
| [Streaming géré par Amazon pour Apache Kafka](with-msk.md) | [Mappage des sources d’événements](invocation-eventsourcemapping.md) |
| [Self-managed Apache Kafka](with-kafka.md) | [Mappage des sources d’événements](invocation-eventsourcemapping.md) |
| [Amazon API Gateway](services-apigateway.md) | Pilotée par les événements ; invocation synchrone |
| [AWS CloudFormation](services-cloudformation.md) | Pilotée par les événements ; invocation asynchrone |
| [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters.html#LambdaFunctionExample) | Pilotée par les événements ; invocation asynchrone |
| [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-notify-lambda-cc.html) | Pilotée par les événements ; invocation asynchrone |
| [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/actions-invoke-lambda-function.html) | Pilotée par les événements ; invocation asynchrone |
| [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-events.html) | Pilotée par les événements ; invocation synchrone |
| [AWS Config](governance-config.md) | Pilotée par les événements ; invocation asynchrone |
| [Amazon Connect](https://docs.aws.amazon.com/connect/latest/adminguide/connect-lambda-functions.html) | Pilotée par les événements ; invocation synchrone |
| [Amazon DocumentDB](with-documentdb.md) | [Mappage des sources d’événements](invocation-eventsourcemapping.md) |
| [Amazon DynamoDB](with-ddb.md) | [Mappage des sources d’événements](invocation-eventsourcemapping.md) |
| [Elastic Load Balancing (Application Load Balancer)](services-alb.md) | Pilotée par les événements ; invocation synchrone |
| [Amazon EventBridge (CloudWatch Événements)](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) | Pilotée par les événements ; invocation asynchrone (bus d’événements), invocation synchrone ou asynchrone (canaux et plannings) |
| [AWS IoT](services-iot.md) | Pilotée par les événements ; invocation asynchrone |
| [Amazon Kinesis](with-kinesis.md) | [Mappage des sources d’événements](invocation-eventsourcemapping.md) |
| [Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/data-transformation.html) | Pilotée par les événements ; invocation synchrone |
| [Amazon Lex](https://docs.aws.amazon.com/lexv2/latest/dg/lambda.html) | Pilotée par les événements ; invocation synchrone |
| [Amazon MQ](with-mq.md) | [Mappage des sources d’événements](invocation-eventsourcemapping.md) |
| [Amazon Simple Email Service](https://docs.aws.amazon.com/ses/latest/dg/receiving-email-action-lambda.html) | Pilotée par les événements ; invocation asynchrone |
| [Amazon Simple Notification Service](with-sns.md) | Pilotée par les événements ; invocation asynchrone |
| [Amazon Simple Queue Service](with-sqs.md) | [Mappage des sources d’événements](invocation-eventsourcemapping.md) |
| [Amazon Simple Storage Service (Amazon S3)](with-s3.md) | Pilotée par les événements ; invocation asynchrone |
| [Amazon Simple Storage Service Batch](services-s3-batch.md) | Pilotée par les événements ; invocation synchrone |
| [Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_lambda.html) | Rotation des secrets |
| [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/connect-lambda.html) | Pilotée par les événements ; invocation synchrone ou asynchrone |
| [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/lambda-functions.html) | Pilotée par les événements ; invocation synchrone |
# Utilisation de Lambda avec Apache Kafka
Lambda prend en charge [Apache Kafka](https://kafka.apache.org/) en tant que [source d’événement](invocation-eventsourcemapping.md). Apache Kafka est une plateforme open source de diffusion en continu d’événements conçue pour gérer des pipelines de données en temps réel à haut débit et des applications de diffusion en continu. Il existe deux méthodes principales pour utiliser Lambda avec Apache Kafka :
+ [Utilisation de Lambda avec Amazon MSK](with-msk.md)— Amazon Managed Streaming pour Apache Kafka (Amazon MSK) est un service entièrement géré par. AWS Amazon MSK permet d’automatiser la gestion de votre infrastructure Kafka, notamment le provisionnement, l’application de correctifs et la mise à l’échelle.
+ [Utilisation de Lambda avec Apache Kafka autogéré](with-kafka.md)— En AWS termes terminologiques, un cluster autogéré inclut les clusters Kafka non AWS hébergés. [Par exemple, vous pouvez toujours utiliser Lambda avec un cluster Kafka hébergé par un fournisseur non cloud tel que [Confluent AWS](https://www.confluent.io/confluent-cloud/) Cloud ou Redpanda.](https://www.redpanda.com/)
Lorsque vous choisissez entre Amazon MSK et Apache Kafka autogéré, tenez compte de vos besoins opérationnels et de vos exigences en matière de contrôle. Amazon MSK est un meilleur choix si vous souhaitez vous aider AWS à gérer rapidement une configuration Kafka évolutive et prête pour la production avec un minimum de frais opérationnels. Cette solution simplifie la sécurité, la surveillance et la haute disponibilité, vous permettant ainsi de vous concentrer sur le développement d’applications plutôt que sur la gestion de l’infrastructure. D'autre part, Apache Kafka autogéré est mieux adapté aux cas d'utilisation exécutés sur des environnements non AWS hébergés, y compris les clusters sur site.
**Topics**
+ [Utilisation de Lambda avec Amazon MSK](with-msk.md)
+ [Utilisation de Lambda avec Apache Kafka autogéré](with-kafka.md)
+ [Modes de mise à l’échelle des sondeurs d’événements Apache Kafka dans Lambda](kafka-scaling-modes.md)
+ [Positions de départ des interrogations et flux Apache Kafka dans Lambda](kafka-starting-positions.md)
+ [ID de groupe de consommateurs personnalisable dans Lambda](kafka-consumer-group-id.md)
+ [Filtrage des événements provenant d’Amazon MSK et sources d’événements Apache Kafka autogéré](kafka-filtering.md)
+ [Utilisation de registres de schémas avec les sources d’événements Kafka dans Lambda](services-consume-kafka-events.md)
+ [Traitement à faible latence pour les sources d’événements Kafka](with-kafka-low-latency.md)
+ [Configuration des contrôles de gestion des erreurs pour les sources d'événements Kafka](kafka-retry-configurations.md)
+ [Capture de lots supprimés pour des sources d’événement Amazon MSK et Apache Kafka autogéré](kafka-on-failure.md)
+ [Utiliser un sujet Kafka comme destination en cas d'échec](kafka-on-failure-destination.md)
+ [Journalisation du mappage des sources d'événements Kafka](esm-logging.md)
+ [Résolution des erreurs de mappage des sources d’événements Kafka](with-kafka-troubleshoot.md)
# Utilisation de Lambda avec Amazon MSK
[Amazon Managed Streaming for Apache Kafka (Amazon MSK)](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html) est un service entièrement géré qui vous permet de créer et d’exécuter des applications qui utilisent Apache Kafka pour traiter des données en streaming. Amazon MSK simplifie la configuration, la mise à l’échelle et la gestion des clusters Kafka. Amazon MSK facilite également la configuration de votre application pour plusieurs zones de disponibilité et pour des raisons de sécurité avec Gestion des identités et des accès AWS (IAM).
Ce chapitre explique comment utiliser un cluster Amazon MSK en tant que source d’événements pour votre fonction Lambda. Le processus général d’intégration d’Amazon MSK à Lambda comprend les étapes suivantes :
1. **[Configuration du cluster et du réseau](with-msk-cluster-network.md)** : configurez d’abord votre [cluster Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html). Cela inclut la configuration réseau correcte pour permettre à Lambda d’accéder à votre cluster.
1. **[Configuration du mappage des sources d’événements](with-msk-configure.md)** : créez ensuite la ressource de [mappage des sources d’événements](invocation-eventsourcemapping.md) dont Lambda a besoin pour connecter de façon sécurisée votre cluster Amazon MSK à votre fonction.
1. **[Configuration de la fonction et des autorisations](with-msk-permissions.md)** : enfin, assurez-vous que votre fonction est correctement configurée et qu’elle dispose des autorisations nécessaires dans son [rôle d’exécution](lambda-intro-execution-role.md).
**Note**
Vous pouvez désormais créer et gérer vos mappages de sources d'événements Amazon MSK directement depuis la console Lambda ou Amazon MSK. Les deux consoles offrent la possibilité de gérer automatiquement la configuration des autorisations de rôle d'exécution Lambda nécessaires pour un processus de configuration plus rationalisé.
Pour des exemples expliquant comment configurer une intégration Lambda avec un cluster Amazon MSK, consultez les sections [Tutoriel : Utilisation d’un mappage des sources d’événements Amazon MSK pour invoquer une fonction Lambda](services-msk-tutorial.md) Utilisation d'[Amazon MSK comme source d'événements AWS Lambda sur le blog AWS Compute et Intégration d'](https://aws.amazon.com/blogs/compute/using-amazon-msk-as-an-event-source-for-aws-lambda/)[Amazon MSK Lambda dans les Amazon MSK](https://amazonmsk-labs.workshop.aws/en/msklambda.html) Labs.
**Topics**
+ [Exemple d’évènement](#msk-sample-event)
+ [Configuration de votre cluster Amazon MSK et de votre réseau Amazon VPC pour Lambda](with-msk-cluster-network.md)
+ [Configuration des autorisations Lambda pour les mappages de sources d'événements Amazon MSK](with-msk-permissions.md)
+ [Configuration de source d’événements Amazon MSK pour Lambda](with-msk-configure.md)
+ [Tutoriel : Utilisation d’un mappage des sources d’événements Amazon MSK pour invoquer une fonction Lambda](services-msk-tutorial.md)
## Exemple d’évènement
Lambda envoie le lot de messages dans le paramètre d’événement quand il invoque votre fonction. La charge utile d’un événement contient un tableau de messages. Chaque élément de tableau contient des détails de la rubrique Amazon MSK et un identifiant de partition, ainsi qu’un horodatage et un message codé en base 64.
```
{
"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
]
}
]
}
]
}
}
```
# Configuration de votre cluster Amazon MSK et de votre réseau Amazon VPC pour Lambda
Pour connecter votre AWS Lambda fonction à votre cluster Amazon MSK, vous devez configurer correctement votre cluster et l'[Amazon Virtual Private Cloud (VPC) dans lequel il](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) réside. Cette page décrit comment configurer votre cluster et votre VPC. Si votre cluster et votre VPC sont déjà correctement configurés, consultez [Configuration de source d’événements Amazon MSK pour Lambda](with-msk-configure.md) pour configurer le mappage des sources d’événements.
**Topics**
+ [Présentation des exigences de configuration réseau pour les intégrations Lambda et MSK](#msk-network-requirements)
+ [Configuration d’une passerelle NAT pour une source d’événements MSK](#msk-nat-gateway)
+ [Configuration des AWS PrivateLink points de terminaison pour une source d'événements MSK](#msk-vpc-privatelink)
## Présentation des exigences de configuration réseau pour les intégrations Lambda et MSK
La configuration réseau requise pour une intégration Lambda et MSK dépend de l’architecture réseau de votre application. Trois ressources principales sont impliquées dans cette intégration : le cluster Amazon MSK, la fonction Lambda et le mappage des sources d’événements Lambda. Chacune de ces ressources réside dans un VPC différent :
+ Votre cluster Amazon MSK réside généralement dans un sous-réseau privé d’un VPC que vous gérez.
+ Votre fonction Lambda réside dans un VPC AWS géré appartenant à Lambda.
+ Le mappage de votre source d'événements Lambda réside dans un autre VPC AWS géré appartenant à Lambda, distinct du VPC qui contient votre fonction.
Le [mappage des sources d’événements](invocation-eventsourcemapping.md) est la ressource intermédiaire entre le cluster MSK et la fonction Lambda. Le mappage des sources d’événements effectue deux tâches principales. Tout d’abord, il interroge votre cluster MSK à la recherche de nouveaux messages. Ensuite, il invoque votre fonction Lambda avec ces messages. Ces trois ressources étant différentes VPCs, les opérations d'interrogation et d'appel nécessitent des appels réseau inter-VPC.
Les exigences de configuration réseau pour votre mappage des sources d’événements varient selon qu’il utilise le [mode provisionné](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode) ou le mode à la demande, comme le montre le schéma suivant :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/MSK-esm-network-overview.png)
La façon dont le mappage des sources d’événements Lambda interroge votre cluster MSK à la recherche de nouveaux messages est la même dans les deux modes. Pour établir une connexion entre votre mappage des sources d’événements et votre cluster MSK, Lambda crée une [ENI Hyperplane](configuration-vpc.md#configuration-vpc-enis) (ou réutilise une ENI existante, si disponible) dans votre sous-réseau privé afin d’établir une connexion sécurisée. Comme illustré dans le schéma, cette ENI Hyperplane utilise la configuration du sous-réseau et du groupe de sécurité de votre cluster MSK, et non votre fonction Lambda.
Après avoir interrogé le message du cluster, la façon dont Lambda invoque votre fonction est différente dans chaque mode :
+ En mode provisionné, Lambda gère automatiquement la connexion entre le VPC du mappage des sources d’événements et le VPC de la fonction. Vous n’avez donc pas besoin de composants de mise en réseau supplémentaires pour invoquer votre fonction avec succès.
+ En mode à la demande, votre mappage des sources d’événements Lambda invoque votre fonction via un chemin passant par votre VPC géré par le client. Pour cette raison, vous devez configurer soit une [passerelle NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) dans le sous-réseau public de votre VPC, soit des points de terminaison [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) dans le sous-réseau privé du VPC qui fournissent un accès à Lambda, [AWS Security Token Service (STS)](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) et éventuellement [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html). La configuration correcte de l’une ou l’autre de ces options permet d’établir une connexion entre votre VPC et le VPC d’environnement d’exécution géré par Lambda, ce qui est nécessaire pour invoquer votre fonction.
Une passerelle NAT permet aux ressources de votre sous-réseau privé d’accéder à l’Internet public. L'utilisation de cette configuration signifie que votre trafic traverse Internet avant d'appeler la fonction Lambda. AWS PrivateLink les points de terminaison permettent aux sous-réseaux privés de se connecter en toute sécurité à AWS des services ou à d'autres ressources VPC privées sans passer par l'Internet public. Consultez [Configuration d’une passerelle NAT pour une source d’événements MSK](#msk-nat-gateway) ou [Configuration des AWS PrivateLink points de terminaison pour une source d'événements MSK](#msk-vpc-privatelink) pour en savoir plus sur la façon de configurer ces ressources.
Jusqu’à présent, nous avons supposé que votre cluster MSK résidait dans un sous-réseau privé au sein de votre VPC, ce qui est le cas le plus courant. Toutefois, même si votre cluster MSK se trouve dans un sous-réseau public au sein de votre VPC, vous devez configurer des points de terminaison AWS PrivateLink pour permettre une connexion sécurisée. Le tableau suivant résume les exigences de configuration réseau en fonction de la façon dont vous configurez votre cluster MSK et du mappage des sources d’événements Lambda :
| Emplacement du cluster MSK (dans un VPC géré par le client) | Mode de mise à l’échelle du mappage des sources d’événements Lambda | Configuration réseau requise |
| --- | --- | --- |
| Sous-réseau privé | Mode de capacité à la demande | Passerelle NAT (dans le sous-réseau public de votre VPC) ou AWS PrivateLink points de terminaison (dans le sous-réseau privé de votre VPC) pour permettre l'accès à Lambda, et AWS STSéventuellement à Secrets Manager. |
| Public subnet | Mode de capacité à la demande | AWS PrivateLink points de terminaison (dans le sous-réseau public de votre VPC) pour permettre l'accès à Lambda et, éventuellement AWS STS, à Secrets Manager. |
| Sous-réseau privé | Mode alloué | Aucune |
| Public subnet | Mode alloué | Aucune |
En outre, les groupes de sécurité associés à votre cluster MSK doivent autoriser le trafic sur les bons ports. Vérifiez que les règles de groupe de sécurité suivantes sont configurées :
+ **Règles entrantes** : autorisez tout le trafic sur le port d’agent par défaut. Le port utilisé par MSK dépend du type d’authentification sur le cluster : `9098` pour l’authentification IAM, `9096` pour SASL/SCRAM et `9094` pour TLS. Vous pouvez également utiliser une règle de groupe de sécurité avec référence circulaire pour autoriser l’accès à partir d’instances appartenant au même groupe de sécurité.
+ **Règles de sortie** : autorisez tout le trafic sur le port `443` pour les destinations externes si votre fonction doit communiquer avec d'autres AWS services. Vous pouvez également utiliser une règle de groupe de sécurité à référencement automatique pour limiter l'accès au courtier si vous n'avez pas besoin de communiquer avec d'autres AWS services.
+ **Règles entrantes de point de terminaison Amazon VPC** :si vous utilisez un point de terminaison Amazon VPC, le groupe de sécurité associé à votre point de terminaison doit autoriser le trafic entrant sur le port `443` en provenance du groupe de sécurité du cluster.
## Configuration d’une passerelle NAT pour une source d’événements MSK
Vous pouvez configurer une passerelle NAT pour permettre à votre mappage des sources d’événements d’interroger les messages de votre cluster et d’invoquer la fonction via un chemin à travers votre VPC. Cela n’est nécessaire que si votre mappage des sources d’événements utilise le mode à la demande et que votre cluster réside dans un sous-réseau privé de votre VPC. Si votre cluster réside dans un sous-réseau public de votre VPC, ou si le mappage des sources d’événements utilise le mode provisionné, vous n’avez pas besoin de configurer de passerelle NAT.
Une [passerelle NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) permet aux ressources d’un sous-réseau privé d’accéder à l’Internet public. Si vous avez besoin d’une connectivité privée à Lambda, consultez plutôt [Configuration des AWS PrivateLink points de terminaison pour une source d'événements MSK](#msk-vpc-privatelink).
Après avoir configuré votre passerelle NAT, vous devez configurer les tables de routage appropriées. Cela permet au trafic provenant de votre sous-réseau privé d’être acheminé vers l’Internet public via la passerelle NAT.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/MSK-NAT-Gateway.png)
Les étapes suivantes vous guident dans la mise en réseau d’une passerelle NAT à l’aide de la console. Si nécessaire, répétez ces étapes pour chaque zone de disponibilité (AZ).
**Configurer une passerelle NAT et un routage approprié (console)**
1. Suivez les étapes de [Créer une passerelle NAT](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-working-with.html), en notant ce qui suit :
+ Les passerelles NAT doivent toujours résider dans un sous-réseau public. Créez des passerelles NAT avec une [connectivité publique](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html).
+ Si votre cluster MSK est répliqué sur plusieurs AZs, créez une passerelle NAT par AZ. Par exemple, dans chaque AZ, votre VPC doit avoir un sous-réseau privé contenant votre cluster et un sous-réseau public contenant votre passerelle NAT. Pour une configuration avec trois AZs, vous aurez trois sous-réseaux privés, trois sous-réseaux publics et trois passerelles NAT.
1. Après avoir créé votre passerelle NAT, ouvrez la [console Amazon VPC](https://console.aws.amazon.com/vpc/) et choisissez **Tables de routage** dans le menu de gauche.
1. Choisissez **Créer une table de routage**.
1. Associez cette table de routage au VPC contenant votre cluster MSK. Vous pouvez éventuellement saisir un nom pour votre table de routage.
1. Choisissez **Créer une table de routage**.
1. Choisissez la table de routage que vous venez de créer.
1. Sur l’onglet **Associations de sous-réseau**, choisissez **Modifier les associations de sous-réseau**.
+ Associez cette table de routage au sous-réseau privé contenant votre cluster MSK.
1. Choisissez **Edit routes (Modifier des routes)**.
1. Choisissez **Ajouter une route** :
1. Pour **Destination**, choisissez `0.0.0.0/0`.
1. Pour **Cible**, choisissez **Passerelle NAT**.
1. Dans la zone de recherche, choisissez la passerelle NAT que vous avez créée à l’étape 1. Il doit s’agir de la passerelle NAT située dans la même AZ que le sous-réseau privé contenant votre cluster MSK (le sous-réseau privé que vous avez associé à cette table de routage à l’étape 6).
1. Sélectionnez **Enregistrer les modifications**.
## Configuration des AWS PrivateLink points de terminaison pour une source d'événements MSK
Vous pouvez configurer des AWS PrivateLink points de terminaison pour interroger les messages de votre cluster et appeler la fonction via un chemin via votre VPC. Ces points de terminaison devraient permettre à votre cluster MSK d’accéder à ce qui suit :
+ Le service Lambda
+ [AWS Security Token Service (STS)](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html)
+ Éventuellement le service [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html). Il est nécessaire si le secret requis pour l’authentification du cluster est stocké dans Secrets Manager.
La configuration des PrivateLink points de terminaison n'est requise que si le mappage des sources d'événements utilise le mode à la demande. Si votre mappage des sources d’événements utilise le mode provisionné, Lambda établit les connexions requises pour vous.
PrivateLink les points de terminaison permettent un accès sécurisé et privé aux AWS services. AWS PrivateLink Vous pouvez également configurer une passerelle NAT afin de permettre à votre cluster MSK d’accéder à l’Internet public (voir [Configuration d’une passerelle NAT pour une source d’événements MSK](#msk-nat-gateway)).
Une fois que vous avez configuré vos points de terminaison de VPC, votre cluster MSK devrait disposer d’un accès direct et privé à Lambda, STS et éventuellement Secrets Manager.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/MSK-PrivateLink-Endpoints.png)
Les étapes suivantes vous guident dans la configuration d'un PrivateLink point de terminaison à l'aide de la console. Si nécessaire, répétez ces étapes pour chaque point de terminaison (Lambda, STS, Secrets Manager).
**Pour configurer les PrivateLink points de terminaison VPC (console)**
1. Ouvrez la [console Amazon VPC](https://console.aws.amazon.com/vpc/) et choisissez **Points de terminaison** dans le menu de gauche.
1. Choisissez **Créer un point de terminaison**.
1. Vous pouvez éventuellement saisir un nom pour votre point de terminaison.
1. Dans **Type**, sélectionnez **Services AWS **.
1. Sous **Services**, commencez à saisir le nom du service. Par exemple, pour créer un point de terminaison pour la connexion à Lambda, saisissez `lambda` dans le champ de recherche.
1. Dans les résultats, vous devriez voir le point de terminaison de service dans la région actuelle. Par exemple, dans la région USA Est (Virginie du Nord), vous devriez voir `com.amazonaws.us-east-2.lambda`. Sélectionnez ce service.
1. Sous **Paramètres réseau**, sélectionnez le VPC qui contient votre cluster MSK.
1. Sous **Sous-réseaux**, sélectionnez le cluster dans lequel AZs se trouve votre cluster MSK.
+ Pour chaque AZ, sous **ID de sous-réseau**, choisissez le sous-réseau privé contenant votre cluster MSK.
1. Sous **Groupes de sécurité**, sélectionnez les groupes de sécurité associés à votre cluster MSK.
1. Choisissez **Créer un point de terminaison**.
Par défaut, les points de terminaison Amazon VPC disposent de politiques IAM ouvertes qui permettent un accès étendu aux ressources. La meilleure pratique consiste à restreindre ces politiques pour effectuer les actions nécessaires à l’aide de ce point de terminaison. Par exemple, pour votre point de terminaison Secrets Manager, vous pouvez modifier sa politique de sorte qu’il autorise uniquement le rôle d’exécution de votre fonction à accéder au secret.
**Example Politique de point de terminaison de VPC – Point de terminaison 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"
}
]
}
```
Pour les points de terminaison Lambda AWS STS et Lambda, vous pouvez limiter le principal appelant au principal de service Lambda. Cependant, assurez-vous d’utiliser `"Resource": "*"` dans ces politiques.
**Example Politique de point de terminaison VPC — point de terminaison AWS STS**
```
{
"Statement": [
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
**Example Politique de point de terminaison de VPC – Point de terminaison Lambda**
```
{
"Statement": [
{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
# Configuration des autorisations Lambda pour les mappages de sources d'événements Amazon MSK
Pour accéder au cluster Amazon MSK, votre fonction et votre mappage des sources d’événements ont besoin d’autorisations pour effectuer diverses actions de l’API Amazon MSK. Ajoutez ces autorisations au [rôle d’exécution](lambda-intro-execution-role.md) de votre fonction. Si vos utilisateurs ont besoin de l’accès, ajoutez les autorisations requises à la stratégie d’identité de l’utilisateur ou du rôle correspondant.
La politique de gestion des [AWSLambdaMSKExecutionrôles](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html) contient les autorisations minimales requises pour les mappages de sources d'événements Amazon MSK Lambda. Pour simplifier le processus d'autorisation, vous pouvez :
+ Associez la politique de gestion des [AWSLambdaMSKExecutionrôles](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html) à votre rôle d'exécution.
+ Laissez la console Lambda générer les autorisations pour vous. Lorsque vous [créez un mappage de source d'événement Amazon MSK dans la console](msk-esm-create.md#msk-console), Lambda évalue votre rôle d'exécution et vous avertit si des autorisations sont manquantes. Choisissez **Générer des autorisations** pour mettre à jour automatiquement votre rôle d'exécution. Cela ne fonctionne pas si vous avez créé ou modifié manuellement vos politiques de rôle d'exécution, ou si les politiques sont associées à plusieurs rôles. Notez que des autorisations supplémentaires peuvent toujours être requises dans votre rôle d'exécution lorsque vous utilisez des fonctionnalités avancées telles que la [destination en cas d'échec](kafka-on-failure.md) ou le [registre des AWS Glue schémas](services-consume-kafka-events.md).
**Topics**
+ [Autorisations requises](#msk-required-permissions)
+ [Autorisations facultatives](#msk-optional-permissions)
## Autorisations requises
Votre rôle d'exécution de fonction Lambda doit disposer des autorisations requises suivantes pour les mappages de sources d'événements Amazon MSK. Ces autorisations sont incluses dans la politique de gestion des [AWSLambdaMSKExecutionrôles](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html).
### CloudWatch Autorisations de journalisation
Les autorisations suivantes permettent à Lambda de créer et de stocker des journaux dans Amazon CloudWatch Logs.
+ [journaux : CreateLogGroup](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogGroup.html)
+ [journaux : CreateLogStream](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogStream.html)
+ [journaux : PutLogEvents](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html)
### Autorisations du cluster MSK
Les autorisations suivantes permettent à Lambda d'accéder à votre cluster Amazon MSK en votre nom :
+ [Kafka : DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html)
+ [Source : 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)
Nous recommandons d'utiliser [kafka : DescribeCluster V2](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters-clusterarn.html) au lieu de [kafka](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html) :. DescribeCluster L'autorisation v2 fonctionne à la fois avec les clusters Amazon MSK provisionnés et sans serveur. Vous n'avez besoin que d'une de ces autorisations dans votre politique.
### Autorisations VPC
Les autorisations suivantes permettent à Lambda de créer et de gérer des interfaces réseau lors de la connexion à votre 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)
## Autorisations facultatives
Votre fonction Lambda peut également nécessiter ces autorisations pour :
+ Accédez à des clusters Amazon MSK multicomptes. Pour les mappages de sources d'événements entre comptes, vous avez besoin de [kafka : DescribeVpcConnection](https://docs.aws.amazon.com/msk/1.0/apireference/vpc-connection-arn.html) dans le rôle d'exécution. Un directeur IAM qui crée un mappage de sources d'événements entre comptes a besoin de [Kafka](https://docs.aws.amazon.com/msk/1.0/apireference/vpc-connections.html) :. ListVpcConnections
+ Accédez à votre secret SCRAM si vous utilisez l’[authentification SASL/SCRAM](msk-cluster-auth.md#msk-sasl-scram). Cela permet à votre fonction d’utiliser un nom d’utilisateur et un mot de passe pour se connecter à Kafka.
+ Décrivez le secret de votre Secrets Manager, si vous utilisez l' SASL/SCRAM [authentification mTLS](msk-cluster-auth.md#msk-mtls). Cela permet à votre fonction de récupérer les informations d’identification ou les certificats nécessaires pour des connexions sécurisées.
+ Accédez à votre clé gérée par le AWS KMS client, si votre AWS Secrets Manager secret est chiffré à l'aide d'une clé gérée par le AWS KMS client.
+ Accédez aux secrets de votre registre de schémas, si vous utilisez un registre de schémas avec authentification :
+ Pour le registre des AWS Glue schémas : les besoins `glue:GetRegistry` et `glue:GetSchemaVersion` les autorisations de votre fonction. Elles permettent à votre fonction de rechercher et d’utiliser les règles de format de message stockées dans AWS Glue.
+ Pour le [registre de schémas Confluent](https://docs.confluent.io/platform/current/schema-registry/security/index.html) avec `BASIC_AUTH` ou `CLIENT_CERTIFICATE_TLS_AUTH` : votre fonction a besoin de l’autorisation `secretsmanager:GetSecretValue` pour accéder au secret contenant les informations d’authentification. Cela permet à votre fonction de récupérer les username/password certificats nécessaires pour accéder au registre des schémas Confluent.
+ Pour les certificats CA privés : votre fonction a besoin de l'GetSecretValue autorisation secretsmanager : pour le secret contenant le certificat. Cela permet à votre fonction de vérifier l’identité des registres de schémas qui utilisent des certificats personnalisés.
+ Accédez aux groupes de consommateurs du cluster Kafka et interrogez les messages depuis le sujet, si vous utilisez l'authentification IAM pour le mappage des sources d'événements.
Cela correspond aux autorisations requises suivantes :
+ [kafka : ListScramSecrets](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-scram-secrets.html) - Permet de répertorier les secrets SCRAM pour l'authentification Kafka
+ [secretsmanager : GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html) - Permet de récupérer des secrets depuis Secrets Manager
+ [KMS:Decrypt - Permet le déchiffrement](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) de données cryptées en utilisant AWS KMS
+ [glue : GetRegistry](https://docs.aws.amazon.com/glue/latest/webapi/API_GetRegistry.html) - Autorise l'accès au registre des AWS Glue schémas
+ [glue : GetSchemaVersion](https://docs.aws.amazon.com/glue/latest/webapi/API_GetSchemaVersion.html) - Permet de récupérer des versions de schéma spécifiques à partir du registre des AWS Glue schémas
+ [Kafka-Cluster:connect - Accorde l'autorisation de se connecter](https://docs.aws.amazon.com/service-authorization/latest/reference/list_apachekafkaapisforamazonmskclusters.html) et de s'authentifier auprès du cluster
+ [kafka-cluster : AlterGroup](https://docs.aws.amazon.com/service-authorization/latest/reference/list_apachekafkaapisforamazonmskclusters.html) - Accorde l'autorisation de rejoindre des groupes sur un cluster, équivalent à l'ACL READ GROUP d'Apache Kafka
+ [kafka-cluster : DescribeGroup](https://docs.aws.amazon.com/service-authorization/latest/reference/list_apachekafkaapisforamazonmskclusters.html) - Accorde l'autorisation de décrire les groupes d'un cluster, équivalent à l'ACL DESCRIBE GROUP d'Apache Kafka
+ [kafka-cluster : DescribeTopic](https://docs.aws.amazon.com/service-authorization/latest/reference/list_apachekafkaapisforamazonmskclusters.html) - Accorde l'autorisation de décrire les sujets d'un cluster, équivalent à l'ACL DESCRIBE TOPIC d'Apache Kafka
+ [kafka-cluster : ReadData](https://docs.aws.amazon.com/service-authorization/latest/reference/list_apachekafkaapisforamazonmskclusters.html) - Accorde l'autorisation de lire les données des rubriques d'un cluster, équivalent à l'ACL READ TOPIC d'Apache Kafka
En outre, si vous souhaitez envoyer des enregistrements d’invocations ayant échoué vers une destination en cas d’échec, vous devez disposer des autorisations suivantes en fonction du type de destination :
+ Pour les destinations Amazon SQS : [sqs : SendMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) - Permet d'envoyer des messages à une file d'attente Amazon SQS
+ Pour les destinations Amazon SNS : [sns:Publish](https://docs.aws.amazon.com/sns/latest/api/API_Publish.html) : permet de publier des messages sur une rubrique Amazon SNS
+ Pour les destinations du compartiment Amazon S3 : [s3 : PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html) et [s3 : ListBucket](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListBucket.html) - Permet d'écrire et de répertorier des objets dans un compartiment Amazon S3
Pour résoudre les erreurs d’authentification et d’autorisation, consultez [Résolution des erreurs de mappage des sources d’événements Kafka](with-kafka-troubleshoot.md).
# Configuration de source d’événements Amazon MSK pour Lambda
Pour utiliser un cluster Amazon MSK comme source d’événements pour votre fonction Lambda, vous devez créer un [mappage des sources d’événements](invocation-eventsourcemapping.md) qui connecte les deux ressources. Cette page explique comment créer un mappage des sources d’événements pour Amazon MSK.
Cette page suppose que vous avez déjà correctement configuré votre cluster MSK et l’instance [Amazon Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) dans lequel il réside. Si vous devez configurer votre cluster ou VPC, consultez [Configuration de votre cluster Amazon MSK et de votre réseau Amazon VPC pour Lambda](with-msk-cluster-network.md). Pour configurer le comportement des nouvelles tentatives afin de gérer les erreurs, consultez[Configuration des contrôles de gestion des erreurs pour les sources d'événements Kafka](kafka-retry-configurations.md).
**Topics**
+ [Utilisation d’un cluster Amazon MSK en tant que source d’événement](#msk-esm-overview)
+ [Configuration des méthodes d'authentification du cluster Amazon MSK dans Lambda](msk-cluster-auth.md)
+ [Création d’un mappage des sources d’événements Lambda pour une source d’événements Amazon MSK](msk-esm-create.md)
+ [Création de mappages de sources d’événements entre comptes dans Lambda](msk-cross-account.md)
+ [Tous les paramètres de configuration des sources d’événements Amazon MSK dans Lambda](msk-esm-parameters.md)
## Utilisation d’un cluster Amazon MSK en tant que source d’événement
Lorsque vous ajoutez votre cluster Apache Kafka ou Amazon MSK comme déclencheur pour votre fonction Lambda, le cluster est utilisé comme [source d’événement](invocation-eventsourcemapping.md).
Lambda lit les données d'événements des rubriques Kafka que vous spécifiez `Topics` dans une [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)demande, en fonction de la [position de départ](kafka-starting-positions.md) que vous spécifiez. Lorsque le traitement a réussi, votre rubrique Kafka est validée dans votre cluster Kafka.
Lambda lit les messages séquentiellement pour chaque partition de rubrique Kafka. Une seule charge utile Lambda peut contenir des messages provenant de plusieurs partitions. Lorsque d'autres enregistrements sont disponibles, Lambda continue de traiter les enregistrements par lots, en fonction de la BatchSize valeur que vous spécifiez dans une [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)demande, jusqu'à ce que votre fonction aborde le sujet.
Après avoir traité chaque lot, Lambda valide les décalages des messages dans celui-ci. Si votre fonction renvoie une erreur pour l’un des messages d’un lot, Lambda réessaie le lot de messages complet jusqu’à ce que le traitement réussisse ou que les messages expirent. Vous pouvez envoyer les enregistrements qui échouent à toutes les tentatives vers une destination en cas de panne pour un traitement ultérieur.
**Note**
Alors que les fonctions Lambda ont généralement un délai d’expiration maximal de 15 minutes, les mappages des sources d’événement pour Amazon MSK, Apache Kafka autogéré, Amazon DocumentDB et Amazon MQ pour ActiveMQ et RabbitMQ ne prennent en charge que les fonctions dont le délai d’expiration maximal est de 14 minutes.
# Configuration des méthodes d'authentification du cluster Amazon MSK dans Lambda
Lambda doit être autorisé à accéder à votre cluster Amazon MSK, à récupérer des enregistrements et à effectuer d’autres tâches. Amazon MSK prend en charge plusieurs méthodes d’authentification auprès de votre cluster MSK.
**Topics**
+ [Accès non authentifié](#msk-unauthenticated)
+ [Authentification SASL/SCRAM](#msk-sasl-scram)
+ [Authentification TLS mutuelle](#msk-mtls)
+ [Authentification IAM](#msk-iam-auth)
+ [Comment Lambda choisit un courtier bootstrap](#msk-bootstrap-brokers)
## Accès non authentifié
Si aucun client n’accède au cluster via Internet, vous pouvez utiliser un accès non authentifié.
## Authentification SASL/SCRAM
Lambda prend en charge [l'authentification simple et l'authentification SASL/SCRAM (Security Layer/Salted Challenge Response Authentication Mechanism)](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password-tutorial.html), avec la fonction de hachage SHA-512 et le chiffrement TLS (Transport Layer Security). Pour que Lambda se connecte au cluster, stockez les informations d’identification d’authentification (nom d’utilisateur et mot de passe) dans un secret Secrets Manager, et référencez ce secret lors de la configuration de votre mappage des sources d’événements.
Pour plus d’informations sur l’utilisation de Secrets Manager, consultez [Authentification par informations d’identification avec Secrets Manager](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password.html) dans le *Guide du développeur Amazon Managed Streaming for Apache Kafka*.
**Note**
Amazon MSK ne prend pas en charge SASL/PLAIN l'authentification.
## Authentification TLS mutuelle
Mutual TLS (mTLS) fournit une authentification bidirectionnelle entre le client et le serveur. Le client envoie un certificat au serveur pour que ce dernier vérifie le client. Le serveur envoie également un certificat au client pour que ce dernier vérifie le serveur.
Pour les intégrations Amazon MSK avec Lambda, votre cluster MSK agit en tant que serveur et Lambda en tant que client.
+ Pour que Lambda puisse vérifier votre cluster MSK, vous devez configurer un certificat client en tant que secret dans Secrets Manager et référencer ce certificat dans votre configuration de mappage des sources d’événements. Le certificat client doit être signé par une autorité de certification (CA) située dans le magasin d’approbations du serveur.
+ Le cluster MSK envoie également un certificat de serveur à Lambda. Le certificat du serveur doit être signé par une autorité de certification (CA) dans le AWS trust store.
Amazon MSK ne prend pas en charge les certificats de serveur autosignés. Tous les courtiers d'Amazon MSK utilisent des [certificats publics](https://docs.aws.amazon.com/msk/latest/developerguide/msk-encryption.html) signés par [Amazon Trust Services CAs](https://www.amazontrust.com/repository/), auxquels Lambda fait confiance par défaut.
### Configuration du secret mTLS
Le secret CLIENT\$1CERTIFICATE\$1TLS\$1AUTH nécessite un champ de certificat et un champ de clé privée. Pour une clé privée chiffrée, le secret nécessite un mot de passe de clé privée. Le certificat et la clé privée doivent être au format PEM.
**Note**
Lambda prend en charge les algorithmes de chiffrement par clé privée [PBES1](https://datatracker.ietf.org/doc/html/rfc2898/#section-6.1)(mais pas PBES2).
Le champ de certificat doit contenir une liste de certificats, commençant par le certificat client, suivi de tous les certificats intermédiaires et se terminant par le certificat racine. Chaque certificat doit commencer sur une nouvelle ligne avec la structure suivante :
```
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
```
Secrets Manager prend en charge les secrets jusqu’à 65 536 octets, ce qui offre suffisamment d’espace pour de longues chaînes de certificats.
La clé privée doit être au format [PKCS \$18](https://datatracker.ietf.org/doc/html/rfc5208), avec la structure suivante :
```
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
```
Pour une clé privée chiffrée, utilisez la structure suivante :
```
-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----
```
L’exemple suivant affiche le contenu d’un secret pour l’authentification mTLS à l’aide d’une clé privée chiffrée. Pour une clé privée chiffrée, vous devez inclure le mot de passe de clé privée dans le secret.
```
{
"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-----"
}
```
Pour plus d’informations sur le protocole mTLS pour Amazon MSK et des instructions sur la génération d’un certificat client, consultez [Authentification de client TLS mutuel pour Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/msk-authentication.html) dans le *Guide du développeur Amazon Managed Streaming for Apache Kafka*.
## Authentification IAM
Vous pouvez utiliser Gestion des identités et des accès AWS (IAM) pour authentifier l'identité des clients qui se connectent au cluster MSK. Avec l’authentification IAM, Lambda s’appuie sur les autorisations du rôle d’exécution de votre fonction pour se connecter au cluster, récupérer des enregistrements et effectuer d’autres actions requises.[Définition des autorisations de fonction Lambda avec un rôle d’exécution](lambda-intro-execution-role.md) Pour un exemple de politique contenant les autorisations nécessaires, consultez [Créer des politiques d’autorisation pour le rôle IAM](https://docs.aws.amazon.com/msk/latest/developerguide/create-iam-access-control-policies.html) dans le *Guide du développeur Amazon Managed Streaming pour Apache Kafka*.
Si l’authentification IAM est active sur votre cluster MSK et que vous ne fournissez pas de secret, Lambda utilise automatiquement l’authentification IAM par défaut.
Pour de plus amples informations sur l’authentification IAM dans Amazon MSK, veuillez consulter [Contrôle d’accès IAM](https://docs.aws.amazon.com/msk/latest/developerguide/iam-access-control.html).
## Comment Lambda choisit un courtier bootstrap
Lambda choisit un [courtier d’amorçage](https://docs.aws.amazon.com/msk/latest/developerguide/msk-get-bootstrap-brokers.html) en fonction des méthodes d’authentification disponibles sur votre cluster, et si vous fournissez un secret pour l’authentification. Si vous fournissez un secret pour les mTLS ou SASL/SCRAM, Lambda choisit automatiquement cette méthode d’authentification. Si vous ne e faites pas, Lambda sélectionne la méthode d’authentification la plus puissante active sur votre cluster. Voici l’ordre de priorité dans lequel Lambda sélectionne un courtier, de l’autorisation la plus forte à la plus faible :
+ MTLs (secret fourni pour les mTLS)
+ SASL/SCRAM (secret provided for SASL/SCRAM)
+ SASL IAM (aucun secret fourni et authentification IAM active)
+ TLS non authentifié (aucun secret fourni et authentification IAM non active)
+ Texte brut (aucun secret n’est fourni, et l’authentification IAM et le TLS non authentifié ne sont pas actifs)
**Note**
Si Lambda ne parvient pas à se connecter au type de courtier le plus sécurisé, Lambda n’essaie pas de se connecter à un type de courtier différent (plus faible). Si vous souhaitez que Lambda choisisse un type de courtier plus faible, désactivez toutes les méthodes d’authentification plus puissantes sur votre cluster.
# Création d’un mappage des sources d’événements Lambda pour une source d’événements Amazon MSK
Pour créer un mappage des sources d’événements, vous pouvez utiliser la console Lambda, [AWS Command Line Interface (CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) ou un [SDK AWS](https://aws.amazon.com/getting-started/tools-sdks/).
**Note**
Lorsque vous créez le mappage des sources d’événements, Lambda crée une [ENI Hyperplane](configuration-vpc.md#configuration-vpc-enis) dans le sous-réseau privé qui contient votre cluster MSK, ce qui permet à Lambda d’établir une connexion sécurisée. Cette ENI Hyperplane utilise la configuration du sous-réseau et du groupe de sécurité de votre cluster MSK, et non votre fonction Lambda.
Les étapes de console suivantes ajoutent un cluster Amazon MSK comme déclencheur pour votre fonction Lambda. En arrière-plan, cela crée une ressource de mappage des sources d’événements.
**Pour ajouter un déclencheur Amazon MSK à votre fonction Lambda (console)**
1. Ouvrez la [page Fonction](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda.
1. Choisissez le nom de la fonction Lambda pour laquelle vous souhaitez ajouter un déclencheur Amazon MSK.
1. Sous **Function overview (Vue d’ensemble de la fonction)**, choisissez **Add trigger (Ajouter un déclencheur)**.
1. Sous **Trigger configuration** (Configuration du déclencheur), choisissez **MSK**.
1. Pour spécifier les détails de votre cluster Kafka, procédez comme suit :
1. Pour **MSK cluster (Cluster MSK)**, sélectionnez votre cluster.
1. Dans **Nom de la rubrique**, donnez un nom à la rubrique Kafka dont vous souhaitez consommer les messages.
1. Pour **l’identifiant de groupe de consommateurs**, entrez l’identifiant d’un groupe de consommateurs Kafka à rejoindre, le cas échéant. Pour de plus amples informations, veuillez consulter [ID de groupe de consommateurs personnalisable dans Lambda](kafka-consumer-group-id.md).
1. Pour **Authentification du cluster**, effectuez les configurations nécessaires. Pour plus d'informations sur l'authentification du cluster, consultez [Configuration des méthodes d'authentification du cluster Amazon MSK dans Lambda](msk-cluster-auth.md).
+ Activez **Utiliser l’authentification** si vous souhaitez que Lambda effectue l’authentification auprès de votre cluster MSK lors de l’établissement d’une connexion. L’authentification est recommandée.
+ Si vous utilisez l’authentification, dans **Méthode d’authentification**, choisissez la méthode d’authentification à utiliser.
+ Si vous utilisez l’authentification, pour **Clé Secrets Manager**, choisissez la clé Secrets Manager qui contient les informations d’identification d’authentification nécessaires pour accéder à votre cluster.
1. Sous **Configuration des sondeurs d’événements**, effectuez les configurations nécessaires.
+ Choisissez **Activer le déclencheur** pour activer le déclencheur immédiatement après sa création.
+ Choisissez si vous souhaitez **Configurer le mode provisionné** pour votre mappage des sources d’événements. Pour de plus amples informations, veuillez consulter [Modes de mise à l’échelle des sondeurs d’événements Apache Kafka dans Lambda](kafka-scaling-modes.md).
+ Si vous configurez le mode provisionné, entrez une valeur pour **Minimum Event Sollers**, une valeur pour **Maximum Event Sollers** et une valeur facultative pour PollerGroupName spécifier le regroupement de plusieurs ESMs au sein d'un même VPC source d'événements.
+ Dans **Position de départ**, choisissez la façon dont vous souhaitez que Lambda commence à lire à partir de votre flux. Pour de plus amples informations, veuillez consulter [Positions de départ des interrogations et flux Apache Kafka dans Lambda](kafka-starting-positions.md).
1. Sous **Traitement par lots**, effectuez les configurations nécessaires. Pour plus d’informations sur la mise en lots, consultez [Comportement de traitement par lots](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching).
1. Pour **Batch size (Taille de lot)**, entrez le nombre maximum d’enregistrements à recevoir dans un même lot.
1. Pour **Batch window**, veuillez saisir le nombre maximal de secondes nécessaires à Lambda pour collecter des enregistrements avant d’invoquer la fonction.
1. Sous **Filtrage**, effectuez les configurations nécessaires. Pour plus d’informations sur le filtrage, veuillez consulter la rubrique [Filtrage des événements provenant d’Amazon MSK et sources d’événements Apache Kafka autogéré](kafka-filtering.md).
+ Pour **Critères de filtre**, ajoutez des définitions de critères de filtre pour déterminer s’il faut ou non traiter un événement.
1. Sous **Gestion des échecs**, effectuez les configurations nécessaires. Pour plus d’informations sur la gestion des échecs, consultez [Capture de lots supprimés pour des sources d’événement Amazon MSK et Apache Kafka autogéré](kafka-on-failure.md).
+ Pour **Destination en cas d’échec**, spécifiez l’ARN de votre destination en cas d’échec.
1. Pour **Balises**, saisissez les balises à associer à ce mappage des sources d’événements.
1. Pour créer le déclencheur, choisissez **Add** (Ajouter).
Vous pouvez également créer le mappage des sources d'événements à l'aide de la AWS CLI avec la [ create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html)commande. L’exemple suivant crée un mappage des sources d’événements pour associer la fonction Lambda `my-msk-function` à la rubrique `AWSKafkaTopic`, en commençant par le message `LATEST`. Cette commande utilise également l'[SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html)objet pour demander à Lambda d'[utiliser](msk-cluster-auth.md#msk-sasl-scram) l'authentification SASL/SCRAM lors de la connexion au 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"}]'
```
Si le cluster utilise l'[authentification mTLS](msk-cluster-auth.md#msk-mtls), incluez un [SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html)objet qui le spécifie `CLIENT_CERTIFICATE_TLS_AUTH` et un ARN de clé Secrets Manager. En voici un exemple dans la commande suivante :
```
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"}]'
```
Lorsque le cluster utilise l'[authentification IAM](msk-cluster-auth.md#msk-iam-auth), vous n'avez pas besoin d'[ SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html)objet. En voici un exemple dans la commande suivante :
```
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
```
# Création de mappages de sources d’événements entre comptes dans Lambda
Vous pouvez utiliser la [connectivité privée multi-VPC](https://docs.aws.amazon.com/msk/latest/developerguide/aws-access-mult-vpc.html) pour connecter une fonction Lambda à un cluster MSK provisionné dans un autre Compte AWS. La connectivité multi-VPC utilise AWS PrivateLink, ce qui permet de maintenir tout le trafic sur le AWS réseau.
**Note**
Vous ne pouvez pas créer de mappages de sources d’événements entre comptes pour les clusters MSK sans serveur.
Pour créer un mappage des sources d’événements entre comptes, vous devez d’abord [configurer la connectivité multi-VPC pour le cluster MSK](https://docs.aws.amazon.com/msk/latest/developerguide/aws-access-mult-vpc.html#mvpc-cluster-owner-action-turn-on). Lorsque vous créez le mappage des sources d’événements, utilisez l’ARN de connexion VPC géré au lieu de l’ARN du cluster, comme indiqué dans les exemples suivants. Le [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)fonctionnement varie également en fonction du type d'authentification utilisé par le cluster MSK.
**Example — Crée un mappage des sources d’événements entre comptes pour le cluster qui utilise l’authentification IAM**
Lorsque le cluster utilise l'[authentification basée sur les rôles IAM](msk-cluster-auth.md#msk-iam-auth), vous n'avez pas besoin d'objet. [SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html) Exemple :
```
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 — Créez un mappage des sources d'événements entre comptes pour le cluster qui utilise l'authentification SASL/SCRAM**
Si le cluster utilise l'[authentification SASL/SCRAM](msk-cluster-auth.md#msk-sasl-scram), vous devez inclure un [SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html)objet qui spécifie `SASL_SCRAM_512_AUTH` et un ARN secret du Secrets Manager.
Il existe deux manières d'utiliser les secrets pour les mappages de sources d'événements Amazon MSK entre comptes avec authentification : SASL/SCRAM
+ Créez un secret dans le compte de fonction Lambda et synchronisez-le avec le secret du cluster. [Créez une rotation](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html) pour synchroniser les deux secrets. Cette option vous permet de contrôler le secret depuis le compte de fonction.
+ Utilisez le secret associé au cluster MSK. Ce secret doit autoriser l’accès intercompte au compte de la fonction Lambda. Pour plus d’informations, voir [Autorisations d’accéder aux secrets AWS Secrets Manager pour les utilisateurs d’un autre compte](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 — Crée un mappage des sources d’événements entre comptes pour le cluster qui utilise l’authentification mTLS**
Si le cluster utilise l'[authentification mTLS](msk-cluster-auth.md#msk-mtls), vous devez inclure un [SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html)objet qui spécifie `CLIENT_CERTIFICATE_TLS_AUTH` et un ARN secret de Secrets Manager. Le secret peut être stocké dans le compte du cluster ou dans le compte de la fonction 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"}]'
```
# Tous les paramètres de configuration des sources d’événements Amazon MSK dans Lambda
Tous les types de sources d'événements Lambda partagent les mêmes opérations [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)et les mêmes opérations d'[UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)API. Cependant, seuls certains paramètres s’appliquent à Amazon MSK, comme indiqué dans le tableau suivant.
| Paramètre | Obligatoire | Par défaut | Remarques |
| --- | --- | --- | --- |
| AmazonManagedKafkaEventSourceConfig | N | Contient le ConsumerGroupId champ, dont la valeur par défaut est unique. | Peut définir uniquement sur Create (Créer) |
| BatchSize | N | 100 | Maximum : 10 000. |
| DestinationConfig | N | N/A | [Capture de lots supprimés pour des sources d’événement Amazon MSK et Apache Kafka autogéré](kafka-on-failure.md) |
| Activé | N | True | |
| BisectBatchOnFunctionError | N | False | [Configuration des contrôles de gestion des erreurs pour les sources d'événements Kafka](kafka-retry-configurations.md) |
| FunctionResponseTypes | N | N/A | [Configuration des contrôles de gestion des erreurs pour les sources d'événements Kafka](kafka-retry-configurations.md) |
| MaximumRecordAgeInSeconds | N | -1 (infini) | [Configuration des contrôles de gestion des erreurs pour les sources d'événements Kafka](kafka-retry-configurations.md) |
| MaximumRetryAttempts | N | -1 (infini) | [Configuration des contrôles de gestion des erreurs pour les sources d'événements Kafka](kafka-retry-configurations.md) |
| EventSourceArn | Y | N/A | Peut définir uniquement sur Create (Créer) |
| FilterCriteria | N | N/A | [Contrôle des événements envoyés par Lambda à votre fonction](invocation-eventfiltering.md) |
| FunctionName | Y | N/A | |
| KMSKeyArn | N | N/A | [Chiffrement des critères de filtre](invocation-eventfiltering.md#filter-criteria-encryption) |
| MaximumBatchingWindowInSeconds | N | 500 ms | [Comportement de traitement par lots](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching) |
| ProvisionedPollersConfig | N | `MinimumPollers` : la valeur par défaut, si elle n’est pas spécifiée, est de 1 `MaximumPollers` : la valeur par défaut, si elle n’est pas spécifiée, est de 200 `PollerGroupName`: N/A | [Mode alloué](kafka-scaling-modes.md#kafka-provisioned-mode) |
| SourceAccessConfigurations | N | Pas d’informations d’identification | Informations d’identification d’authentification SASL/SCRAM ou CLIENT\$1CERTIFICATE\$1TLS\$1AUTH (TLS mutuel) pour votre source d’événement |
| StartingPosition | Y | N/A | AT\$1TIMESTAMP, TRIM\$1HORIZON ou DERNIER Peut définir uniquement sur Create (Créer) |
| StartingPositionTimestamp | N | N/A | Obligatoire s'il StartingPosition est défini sur AT\$1TIMESTAMP |
| Étiquettes | N | N/A | [Utilisation des balises dans les mappages des sources d’événements](tags-esm.md) |
| Rubriques | Y | N/A | Nom de rubrique Kafka Peut définir uniquement sur Create (Créer) |
**Note**
Lorsque vous spécifiez un`PollerGroupName`, plusieurs ESMs au sein d'un même Amazon VPC peuvent partager la capacité de l'Event Poller Unit (EPU). Vous pouvez utiliser cette option pour optimiser les coûts du mode provisionné pour votre ESMs. Exigences relatives au regroupement ESM :
ESMs doit se trouver dans le même Amazon VPC
Maximum de 100 ESMs par groupe de sondeurs
Le nombre maximum de sondeurs agrégés pour l'ensemble ESMs d'un groupe ne peut pas dépasser 2 000
Vous pouvez le mettre `PollerGroupName` à jour pour déplacer un ESM vers un autre groupe, ou supprimer un ESM d'un groupe en le définissant `PollerGroupName` sur une chaîne vide (« »).
# Tutoriel : Utilisation d’un mappage des sources d’événements Amazon MSK pour invoquer une fonction Lambda
Dans ce tutoriel, vous exécuterez les étapes suivantes :
+ Créez une fonction Lambda dans le même AWS compte qu'un cluster Amazon MSK existant.
+ Configurer le réseau et l’authentification pour que Lambda communique avec Amazon MSK.
+ Configurer un mappage des sources d’événements Amazon MSK Lambda, qui exécute votre fonction Lambda lorsque des événements apparaissent dans la rubrique.
Une fois ces étapes terminées, vous pouvez configurer une fonction Lambda pour traiter automatiquement les événements envoyés à Amazon MSK avec votre code Lambda personnalisé.
**Que pouvez-vous faire avec cette fonctionnalité ?**
**Exemple de solution : Utiliser un mappage des sources d’événements MSK pour fournir des résultats en direct à vos clients.**
Imaginons le scénario suivant : votre entreprise héberge une application Web dans laquelle vos clients peuvent consulter des informations sur des événements en direct, tels que des matchs de sport. Les informations actualisées du jeu sont fournies à votre équipe via une rubrique Kafka sur Amazon MSK. Vous souhaitez concevoir une solution qui utilise les mises à jour issues de la rubrique MSK afin de fournir une vue actualisée de l’événement en direct aux clients au sein d’une application que vous développez. Vous avez opté pour l’approche de conception suivante : vos applications clientes communiqueront avec un dorsal sans serveur hébergé dans AWS. Les clients se connecteront via des sessions websocket à l'aide de l'API Amazon WebSocket API Gateway.
Dans cette solution, vous avez besoin d’un composant qui lit les événements MSK, exécute une logique personnalisée pour préparer ces événements pour la couche application, puis transmet ces informations à l’API API Gateway. Vous pouvez implémenter ce composant en fournissant votre logique personnalisée dans une fonction Lambda, puis en l'appelant à l'aide d'un mappage de source d'événements AWS Lambda Amazon MSK. AWS Lambda
Pour plus d'informations sur la mise en œuvre de solutions à l'aide de l'API Amazon WebSocket API Gateway, consultez les [WebSocket didacticiels](https://docs.aws.amazon.com/apigateway/latest/developerguide/websocket-api-chat-app.html) sur les API dans la documentation d'API Gateway.
## Conditions préalables
Un AWS compte avec les ressources préconfigurées suivantes :
**Pour remplir ces prérequis, nous vous recommandons de suivre [Get started using Amazon MSK](https://docs.aws.amazon.com//msk/latest/developerguide/getting-started.html) dans la documentation Amazon MSK.**
+ Un cluster Amazon MSK. Consultez [Create an Amazon MSK cluster](https://docs.aws.amazon.com//msk/latest/developerguide/create-cluster.html) dans *Getting started using Amazon MSK*.
+ La configuration suivante :
+ Assurez-vous que l’**authentification basée sur les rôles IAM** est **Activée** dans les paramètres de sécurité de votre cluster. Cela améliore votre sécurité en limitant votre fonction Lambda à l’accès aux ressources Amazon MSK nécessaires uniquement. L’authentification basée sur les rôles IAM est activée par défaut sur les nouveaux clusters Amazon MSK.
+ Assurez-vous que l’**Accès public** est désactivé dans les paramètres réseau de votre cluster. Restreindre l’accès à Internet de votre cluster Amazon MSK améliore votre sécurité en limitant le nombre d’intermédiaires qui traitent vos données. L’accès public est activé par défaut sur les nouveaux clusters Amazon MSK.
+ Une rubrique Kafka dans votre cluster Amazon MSK à utiliser pour cette solution. Consultez [Create a topic](https://docs.aws.amazon.com//msk/latest/developerguide/create-topic.html) dans *Getting started using Amazon MSK*.
+ Un hôte administrateur Kafka configuré pour extraire les informations de votre cluster Kafka et envoyer des événements Kafka à votre rubrique à des fins de test, par exemple une instance Amazon EC2 sur laquelle la CLI d’administration Kafka et la bibliothèque IAM Amazon MSK sont installées. Consultez [Create a client machine](https://docs.aws.amazon.com//msk/latest/developerguide/create-client-machine.html) dans *Getting started using Amazon MSK*.
Une fois que vous avez configuré ces ressources, collectez les informations suivantes à partir de votre AWS compte pour confirmer que vous êtes prêt à continuer.
+ Le nom de votre cluster Amazon MSK. Vous pouvez trouver cette information dans la console Amazon MSK.
+ L’UUID du cluster, qui fait partie de l’ARN de votre cluster Amazon MSK, que vous pouvez trouver dans la console Amazon MSK. Suivez les procédures décrites dans la rubrique [Listing clusters](https://docs.aws.amazon.com/msk/latest/developerguide/msk-list-clusters.html) de la documentation Amazon MSK pour trouver cette information.
+ Les groupes de sécurité associés à votre cluster Amazon MSK. Vous pouvez trouver cette information dans la console Amazon MSK. Dans les étapes suivantes, appelez-les vos*clusterSecurityGroups*.
+ L’ID du VPC Amazon contenant votre cluster Amazon MSK. Vous pouvez trouver cette information en identifiant les sous-réseaux associés à votre cluster Amazon MSK dans la console Amazon MSK, puis en identifiant le VPC Amazon associé au sous-réseau dans la console Amazon VPC.
+ Le nom de la rubrique Kafka utilisée dans votre solution. Vous pouvez trouver cette information en appelant votre cluster Amazon MSK à l’aide de la CLI `topics` Kafka depuis votre hôte administrateur Kafka. Pour plus d’informations sur la CLI de rubriques, consultez la section [Adding and removing topics](https://kafka.apache.org/documentation/#basic_ops_add_topic) dans la documentation Kafka.
+ Le nom d’un groupe de consommateurs pour votre rubrique Kafka, adapté à une utilisation par votre fonction Lambda. Ce groupe peut être créé automatiquement par Lambda. Vous n’avez donc pas besoin de le créer avec la CLI Kafka. Si vous devez gérer vos groupes de consommateurs, pour en savoir plus sur la CLI de groupes de consommateurs, consultez la rubrique [Managing Consumer Groups](https://kafka.apache.org/documentation/#basic_ops_consumer_group) dans la documentation Kafka.
Les autorisations suivantes dans votre AWS compte :
+ L’autorisation de créer et de gérer une fonction Lambda.
+ L’autorisation de créer des politiques IAM et de les associer à votre fonction Lambda.
+ L’autorisation de créer des points de terminaison de VPC Amazon et de modifier la configuration réseau dans le VPC Amazon hébergeant votre cluster Amazon MSK.
### Installez le AWS Command Line Interface
Si vous ne l'avez pas encore installé AWS Command Line Interface, suivez les étapes décrites dans la [section Installation ou mise à jour de la dernière version du AWS CLI pour l'](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)installer.
Ce tutoriel nécessite un terminal de ligne de commande ou un shell pour exécuter les commandes. Sous Linux et macOS, utilisez votre gestionnaire de shell et de package préféré.
**Note**
Sous Windows, certaines commandes CLI Bash que vous utilisez couramment avec Lambda (par exemple `zip`) ne sont pas prises en charge par les terminaux intégrés du système d’exploitation. [Installez le sous-système Windows pour Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10) afin d’obtenir une version intégrée à Windows d’Ubuntu et Bash.
## Configurer la connectivité réseau pour que Lambda communique avec Amazon MSK
AWS PrivateLink À utiliser pour connecter Lambda et Amazon MSK. Pour ce faire, vous créez des points de terminaison de VPC Amazon d’interface dans la console Amazon VPC. Pour plus d’informations sur la configuration réseau, consultez [Configuration de votre cluster Amazon MSK et de votre réseau Amazon VPC pour Lambda](with-msk-cluster-network.md).
Lorsqu’un mappage des sources d’événements Amazon MSK s’exécute pour le compte d’une fonction Lambda, il endosse le rôle d’exécution de la fonction Lambda. Ce rôle IAM autorise le mappage pour accéder aux ressources sécurisées par IAM, telles que votre cluster Amazon MSK. Bien que les composants partagent un rôle d’exécution, le mappage Amazon MSK et votre fonction Lambda ont des exigences de connectivité distinctes pour leurs tâches respectives, comme le montre le schéma suivant.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/msk_tut_network.png)
Votre mappage des sources d’événements appartient au groupe de sécurité de votre cluster Amazon MSK. Au cours de cette étape de mise en réseau, créez des points de terminaison de VPC Amazon à partir de votre VPC de cluster Amazon MSK pour connecter le mappage des sources d’événements aux services Lambda et STS. Sécurisez ces points de terminaison pour accepter le trafic provenant du groupe de sécurité de votre cluster Amazon MSK. Ajustez ensuite les groupes de sécurité du cluster Amazon MSK pour permettre au mappage des sources d’événements de communiquer avec le cluster Amazon MSK.
Vous pouvez configurer les étapes suivantes à l’aide de l’ AWS Management Console.
**Pour configurer les points de terminaison de VPC Amazon d’interface afin de connecter Lambda et Amazon MSK**
1. Créez un groupe de sécurité pour les points de terminaison Amazon VPC de votre interface*endpointSecurityGroup*, qui autorise le trafic TCP entrant sur 443 depuis. *clusterSecurityGroups* Suivez la procédure décrite dans la rubrique [Create a security group](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/working-with-security-groups.html#creating-security-group) de la documentation Amazon EC2 pour créer un groupe de sécurité. Suivez ensuite la procédure décrite dans la rubrique [Add rules to a security group](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule) de la documentation Amazon EC2 pour ajouter les règles appropriées.
**Créez un groupe de sécurité avec les informations suivantes :**
Lorsque vous ajoutez vos règles de trafic entrant, créez une règle pour chaque groupe de sécurité dans*clusterSecurityGroups*. Pour chaque règle :
+ Dans le champ **Type**, sélectionnez **HTTPS**.
+ Pour **Source**, sélectionnez l'un des*clusterSecurityGroups*.
1. Créez un point de terminaison connectant le service Lambda au VPC Amazon qui contient votre cluster Amazon MSK. Suivez la procédure décrite dans [Create an interface endpoint](https://docs.aws.amazon.com//vpc/latest/privatelink/create-interface-endpoint.html).
**Créez un point de terminaison d’interface avec les informations suivantes :**
+ Dans **Nom du service**`com.amazonaws.regionName.lambda`, sélectionnez où *regionName* héberge votre fonction Lambda.
+ Pour **VPC**, sélectionnez le VPC Amazon contenant votre cluster Amazon MSK.
+ Pour les **groupes de sécurité***endpointSecurityGroup*, sélectionnez ceux que vous avez créés précédemment.
+ Pour **Sous-réseaux**, sélectionnez les sous-réseaux qui hébergent votre cluster Amazon MSK.
+ Pour **Politique**, fournissez le document de politique suivant, qui sécurise le point de terminaison afin qu’il soit utilisé par le principal de service Lambda pour l’action `lambda:InvokeFunction`.
```
{
"Statement": [
{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
+ Assurez-vous que **Activer le nom DNS** reste défini.
1. Créez un point de terminaison connectant le AWS STS service au Amazon VPC contenant votre cluster Amazon MSK. Suivez la procédure décrite dans [Create an interface endpoint](https://docs.aws.amazon.com//vpc/latest/privatelink/create-interface-endpoint.html).
**Créez un point de terminaison d’interface avec les informations suivantes :**
+ Pour **Nom du service**, sélectionnez AWS STS.
+ Pour **VPC**, sélectionnez le VPC Amazon contenant votre cluster Amazon MSK.
+ Pour les **groupes de sécurité**, sélectionnez*endpointSecurityGroup*.
+ Pour **Sous-réseaux**, sélectionnez les sous-réseaux qui hébergent votre cluster Amazon MSK.
+ Pour **Politique**, fournissez le document de politique suivant, qui sécurise le point de terminaison afin qu’il soit utilisé par le principal de service Lambda pour l’action `sts:AssumeRole`.
```
{
"Statement": [
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
+ Assurez-vous que **Activer le nom DNS** reste défini.
1. Pour chaque groupe de sécurité associé à votre cluster Amazon MSK, c'est-à-dire dans*clusterSecurityGroups*, autorisez ce qui suit :
+ Autorisez tout le trafic TCP entrant et sortant sur le 9098 à tous*clusterSecurityGroups*, y compris à l'intérieur de celui-ci.
+ Autorisez tout le trafic TCP sortant sur le port 443.
Une partie de ce trafic est autorisée par les règles des groupes de sécurité par défaut. Par conséquent, si votre cluster est attaché à un seul groupe de sécurité et que ce groupe possède des règles par défaut, il n’est pas nécessaire d’ajouter des règles. Pour ajuster les règles de groupe de sécurité, suivez les procédures décrites dans la rubrique [Add rules to a security group](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule) de la documentation Amazon EC2.
**Ajoutez des règles à vos groupes de sécurité avec les informations suivantes :**
+ Pour chaque règle entrante ou sortante pour le port 9098, indiquez
+ Pour **Type**, sélectionnez **Custom TCP (TCP personnalisé)**.
+ Pour **Plage de ports**, indiquez 9098.
+ Pour **Source**, indiquez l'un des*clusterSecurityGroups*.
+ Pour chaque règle entrante pour le port 443, pour **Type**, sélectionnez **HTTPS**.
## Créer un rôle IAM pour que Lambda puisse lire un extrait de votre rubrique Amazon MSK
Identifiez les exigences d’authentification que Lambda doit lire dans votre rubrique Amazon MSK, puis définissez-les dans une politique. Créez un rôle qui autorise Lambda à utiliser ces autorisations. *lambdaAuthRole* Autorisez les actions sur votre cluster Amazon MSK à l’aide d’actions IAM `kafka-cluster`. Autorisez ensuite Lambda à effectuer les actions Amazon MSK et Amazon `kafka` EC2 nécessaires pour découvrir et vous connecter à votre cluster Amazon MSK, ainsi que les actions permettant à Lambda de consigner CloudWatch ce qu'il a fait.
**Pour décrire les exigences d’authentification pour que Lambda puisse lire depuis Amazon MSK**
1. Rédigez un document de politique IAM (un document JSON) qui permet à Lambda de lire un extrait de votre sujet Kafka dans votre cluster Amazon MSK en utilisant votre groupe de consommateurs Kafka. *clusterAuthPolicy* Lambda nécessite qu’un groupe de consommateurs Kafka soit défini lors de la lecture.
Modifiez le modèle suivant pour l’aligner sur vos prérequis :
------
#### [ 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"
]
}
]
}
```
------
Pour plus d’informations, consultez [Configuration des autorisations Lambda pour les mappages de sources d'événements Amazon MSK](with-msk-permissions.md). Lorsque vous rédigez votre politique :
+ Remplacez *us-east-1* et *111122223333* par le Région AWS et Compte AWS de votre cluster Amazon MSK.
+ Pour*mskClusterName*, indiquez le nom de votre cluster Amazon MSK.
+ Pour*cluster-uuid*, fournissez l'UUID dans l'ARN de votre cluster Amazon MSK.
+ Pour*mskTopicName*, indiquez le nom de votre sujet Kafka.
+ Pour*mskGroupName*, indiquez le nom de votre groupe de consommateurs Kafka.
1. Identifiez Amazon MSK, Amazon EC2 CloudWatch et les autorisations requises pour que Lambda découvre et connecte votre cluster Amazon MSK, puis enregistrez ces événements.
La politique gérée `AWSLambdaMSKExecutionRole` définit de manière permissive les autorisations requises. Utilisez-la dans les étapes suivantes.
Dans un environnement de production, évaluez `AWSLambdaMSKExecutionRole` pour restreindre votre politique de rôle d’exécution sur la base du principe du moindre privilège, puis rédigez une politique pour votre rôle qui remplace cette politique gérée.
Pour plus d’informations sur le langage de politique IAM, consultez la [documentation IAM](https://docs.aws.amazon.com//iam/).
Maintenant que vous avez rédigé votre document de politique, créez une politique IAM afin de pouvoir l’attacher à votre rôle. Pour ce faire, vous pouvez utiliser la console en suivant la procédure ci-dessous.
**Pour créer une politique IAM à partir de votre document de politique**
1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.
1. Dans le panneau de navigation de gauche, choisissez **Politiques**.
1. Choisissez **Create Policy** (Créer une politique).
1. Dans la section **Éditeur de politiques**, choisissez l’option **JSON**.
1. Coller*clusterAuthPolicy*.
1. Lorsque vous avez fini d’ajouter des autorisations à la politique, choisissez **Suivant**.
1. Sur la page **Vérifier et créer**, tapez un **Nom de politique** et une **Description** (facultative) pour la politique que vous créez. Vérifiez les **Autorisations définies dans cette politique** pour voir les autorisations accordées par votre politique.
1. Choisissez **Create policy** (Créer une politique) pour enregistrer votre nouvelle politique.
Pour plus d’informations, consultez [Création de politiques IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_create.html) dans la documentation IAM.
Maintenant que vous disposez des politiques IAM appropriées, créez un rôle et attachez-les à celui-ci. Pour ce faire, vous pouvez utiliser la console en suivant la procédure ci-dessous.
**Pour créer un rôle d’exécution dans la console IAM**
1. Ouvrez la page [Roles (Rôles)](https://console.aws.amazon.com/iam/home#/roles) dans la console IAM.
1. Choisissez **Créer un rôle**.
1. Sous **Trusted entity type** (Type d’entité approuvée), choisissez **service AWS **.
1. Sous **Cas d’utilisation**, choisissez **Lambda**.
1. Choisissez **Suivant**.
1. Sélectionnez les stratégies suivantes :
+ *clusterAuthPolicy*
+ `AWSLambdaMSKExecutionRole`
1. Choisissez **Suivant**.
1. Dans **Nom du rôle**, entrez *lambdaAuthRole* puis choisissez **Créer un rôle**.
Pour de plus amples informations, veuillez consulter [Définition des autorisations de fonction Lambda avec un rôle d’exécution](lambda-intro-execution-role.md).
## Créer une fonction Lambda pour lire à partir de votre rubrique Amazon MSK
Créez une fonction Lambda configurée pour utiliser votre rôle IAM. Vous pouvez enregistrer votre fonction Lambda à l’aide de la console.
**Pour créer une fonction Lambda à l’aide de votre configuration d’authentification**
1. Ouvrez la console Lambda et choisissez **Créer une fonction** dans l’en-tête.
1. Sélectionnez **Créer à partir de zéro**.
1. Pour **Nom de la fonction**, saisissez un nom approprié de votre choix.
1. Pour **Environnement d’exécution**, choisissez la dernière version prise en charge (**Dernier pris en charge**) de `Node.js` pour utiliser le code fourni dans ce tutoriel.
1. Choisissez **Modifier le rôle d’exécution par défaut**.
1. Sélectionnez **Utiliser un rôle existant**.
1. Pour **Rôle existant**, sélectionnez*lambdaAuthRole*.
Dans un environnement de production, vous devez généralement ajouter des politiques supplémentaires au rôle d’exécution de votre fonction Lambda afin de traiter intelligemment vos événements Amazon MSK. Pour plus d’informations sur l’ajout de politiques à votre rôle, consultez la section [Ajouter ou supprimer des autorisations d’identité](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console) dans la documentation IAM.
## Création d’un mappage des sources d’événements pour votre fonction Lambda
Votre mappage des sources d’événements Amazon MSK fournit au service Lambda les informations nécessaires pour invoquer votre fonction Lambda lorsque des événements Amazon MSK appropriés se produisent. Vous pouvez créer un mappage Amazon MSK à l’aide de la console. Créez un déclencheur Lambda, puis le mappage des sources d’événements est automatiquement configuré.
**Pour créer un déclenceur Lambda (et un mappage des sources d’événements)**
1. Accédez à la page de présentation de votre fonction Lambda.
1. Dans la section de présentation de la fonction, choisissez **Ajouter un déclencheur** en bas à gauche.
1. Dans le menu déroulant **Sélectionner une source**, sélectionnez **Amazon MSK**.
1. Ne configurez pas l’**authentification**.
1. Pour **Cluster MSK**, sélectionnez le nom de votre cluster.
1. Pour **Taille de lot**, saisissez 1. Cette étape facilite le test de cette fonctionnalité. Elle ne constitue pas une valeur idéale en production.
1. Pour **Nom de la rubrique**, indiquez le nom de votre rubrique Kafka.
1. Pour **ID du groupe de consommateurs**, indiquez l’ID de votre groupe de consommateurs Kafka.
## Mise à jour de votre fonction Lambda pour lire vos données de streaming
Lambda fournit des informations sur les événements Kafka via le paramètre de méthode d’événement. Pour obtenir un exemple de structure d’un événement Amazon MSK, consultez [Exemple d’évènement](with-msk.md#msk-sample-event). Après avoir compris comment interpréter les événements Amazon MSK transférés par Lambda, vous pouvez modifier le code de votre fonction Lambda pour utiliser les informations qu’ils fournissent.
Fournissez le code suivant à votre fonction Lambda pour journaliser le contenu d’un événement Lambda Amazon MSK à des fins de test :
------
#### [ .NET ]
**SDK pour .NET**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Consommation d’un événement Amazon MSK avec Lambda en utilisant .NET.
```
using System.Text;
using Amazon.Lambda.Core;
using Amazon.Lambda.KafkaEvents;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace MSKLambda;
public class Function
{
/// The event for the Lambda function handler to process.
/// The ILambdaContext that provides methods for logging and describing the Lambda environment.
///
public void FunctionHandler(KafkaEvent evnt, ILambdaContext context)
{
foreach (var record in evnt.Records)
{
Console.WriteLine("Key:" + record.Key);
foreach (var eventRecord in record.Value)
{
var valueBytes = eventRecord.Value.ToArray();
var valueText = Encoding.UTF8.GetString(valueBytes);
Console.WriteLine("Message:" + valueText);
}
}
}
}
```
------
#### [ Go ]
**Kit SDK pour Go V2**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Consommation d’un événement Amazon MSK avec Lambda en utilisant 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 pour Java 2.x**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Consommation d’un événement Amazon MSK avec Lambda en utilisant Java.
```
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.KafkaEvent;
import com.amazonaws.services.lambda.runtime.events.KafkaEvent.KafkaEventRecord;
import java.util.Base64;
import java.util.Map;
public class Example implements RequestHandler {
@Override
public Void handleRequest(KafkaEvent event, Context context) {
for (Map.Entry> entry : event.getRecords().entrySet()) {
String key = entry.getKey();
System.out.println("Key: " + key);
for (KafkaEventRecord record : entry.getValue()) {
System.out.println("Record: " + record);
byte[] value = Base64.getDecoder().decode(record.getValue());
String message = new String(value);
System.out.println("Message: " + message);
}
}
return null;
}
}
```
------
#### [ JavaScript ]
**SDK pour JavaScript (v3)**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Utilisation d'un événement Amazon MSK avec JavaScript Lambda à l'aide de.
```
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)
})
}
}
```
Utilisation d'un événement Amazon MSK avec TypeScript Lambda à l'aide de.
```
import { MSKEvent, Context } from "aws-lambda";
import { Buffer } from "buffer";
import { Logger } from "@aws-lambda-powertools/logger";
const logger = new Logger({
logLevel: "INFO",
serviceName: "msk-handler-sample",
});
export const handler = async (
event: MSKEvent,
context: Context
): Promise => {
for (const [topic, topicRecords] of Object.entries(event.records)) {
logger.info(`Processing key: ${topic}`);
// Process each record in the partition
for (const record of topicRecords) {
try {
// Decode the message value from base64
const decodedMessage = Buffer.from(record.value, 'base64').toString();
logger.info({
message: decodedMessage
});
}
catch (error) {
logger.error('Error processing event', { error });
throw error;
}
};
}
}
```
------
#### [ PHP ]
**Kit SDK pour PHP**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Consommation d’un événement Amazon MSK avec Lambda en utilisant PHP.
```
logger = $logger;
}
/**
* @throws JsonException
* @throws \Bref\Event\InvalidLambdaEvent
*/
public function handle(mixed $event, Context $context): void
{
$kafkaEvent = new KafkaEvent($event);
$this->logger->info("Processing records");
$records = $kafkaEvent->getRecords();
foreach ($records as $record) {
try {
$key = $record->getKey();
$this->logger->info("Key: $key");
$values = $record->getValue();
$this->logger->info(json_encode($values));
foreach ($values as $value) {
$this->logger->info("Value: $value");
}
} catch (Exception $e) {
$this->logger->error($e->getMessage());
}
}
$totalRecords = count($records);
$this->logger->info("Successfully processed $totalRecords records");
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**Kit SDK for Python (Boto3)**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Consommation d’un événement Amazon MSK avec Lambda en utilisant 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 ]
**Kit SDK pour Ruby**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Consommation d’un événement Amazon MSK avec Lambda en utilisant 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 pour Rust**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Consommation d’un événement Amazon MSK avec Lambda en utilisant Rust.
```
use aws_lambda_events::event::kafka::KafkaEvent;
use lambda_runtime::{run, service_fn, tracing, Error, LambdaEvent};
use base64::prelude::*;
use serde_json::{Value};
use tracing::{info};
/// Pre-Requisites:
/// 1. Install Cargo Lambda - see https://www.cargo-lambda.info/guide/getting-started.html
/// 2. Add packages tracing, tracing-subscriber, serde_json, base64
///
/// This is the main body for the function.
/// Write your code inside it.
/// There are some code example in the following URLs:
/// - https://github.com/awslabs/aws-lambda-rust-runtime/tree/main/examples
/// - https://github.com/aws-samples/serverless-rust-demo/
async fn function_handler(event: LambdaEvent) -> Result {
let payload = event.payload.records;
for (_name, records) in payload.iter() {
for record in records {
let record_text = record.value.as_ref().ok_or("Value is None")?;
info!("Record: {}", &record_text);
// perform Base64 decoding
let record_bytes = BASE64_STANDARD.decode(record_text)?;
let message = std::str::from_utf8(&record_bytes)?;
info!("Message: {}", message);
}
}
Ok(().into())
}
#[tokio::main]
async fn main() -> Result<(), Error> {
// required to enable CloudWatch error logging by the runtime
tracing::init_default_subscriber();
info!("Setup CW subscriber!");
run(service_fn(function_handler)).await
}
```
------
Vous pouvez fournir le code de fonction à votre fonction Lambda à l’aide de la console.
**Pour mettre à jour le code de fonction à l’aide de l’éditeur de code de la console**
1. Ouvrez la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda et choisissez votre fonction.
1. Sélectionnez l’onglet **Code**.
1. Dans le volet **Source du code**, sélectionnez votre fichier de code source et modifiez-le dans l’éditeur de code intégré.
1. Dans la section **DÉPLOYER**, choisissez **Déployer** pour mettre à jour le code de votre fonction :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/getting-started-tutorial/deploy-console.png)
## Test de votre fonction Lambda pour vérifier qu’elle est connectée à votre rubrique Amazon MSK
Vous pouvez désormais vérifier si votre Lambda est invoqué par la source d'événements en consultant les journaux d'événements. CloudWatch
**Pour vérifier si votre fonction Lambda est invoquée**
1. Utilisez votre hôte administrateur Kafka pour générer des événements Kafka à l’aide de la CLI `kafka-console-producer`. Pour plus d’informations, consultez [Write some events into the topic](https://kafka.apache.org/documentation/#quickstart_send) dans la documentation Kafka. Envoyez suffisamment d’événements pour remplir le lot défini en fonction de la taille du lot pour votre mappage des sources d’événements défini à l’étape précédente, sinon Lambda attendra d’autres informations pour procéder à l’invocation.
1. Si votre fonction s'exécute, Lambda écrit ce qui s'est passé à. CloudWatch Dans la console, accédez à la page des détails de votre fonction Lambda.
1. Sélectionnez l’onglet **Configuration**.
1. Dans la barre latérale, sélectionnez **Outils de surveillance et d’exploitation**.
1. Identifiez le **groupe de CloudWatch journaux** sous **Configuration de la journalisation**. Le groupe de journaux doit commencer par `/aws/lambda`. Choisissez le lien vers le groupe de journaux.
1. Dans la CloudWatch console, examinez les **événements du journal pour les événements** du journal que Lambda a envoyés au flux de journal. Identifiez s’il existe des événements de journaux contenant le message de votre événement Kafka, comme dans l’image suivante. Si tel est le cas, vous avez connecté avec succès une fonction Lambda à Amazon MSK à l’aide d’un mappage des sources d’événements Lambda.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/msk_tut_log.png)
# Utilisation de Lambda avec Apache Kafka autogéré
Cette rubrique décrit comment utiliser Lambda avec un cluster Kafka autogéré. En AWS termes terminologiques, un cluster autogéré inclut les clusters Kafka non AWS hébergés. Par exemple, vous pouvez héberger votre cluster Kafka avec un fournisseur de cloud tel que [Confluent Cloud](https://www.confluent.io/confluent-cloud/) ou [Redpanda](https://www.redpanda.com/).
Ce chapitre explique comment utiliser un cluster Apache Kafka autogéré en tant que source d’événement pour votre fonction Lambda. Le processus général d’intégration d’Apache Kafka autogéré à Lambda comprend les étapes suivantes :
1. **[Configuration du cluster et du réseau](with-kafka-cluster-network.md)** : configurez d’abord votre cluster Apache Kafka autogéré avec la configuration réseau appropriée pour permettre à Lambda d’accéder à votre cluster.
1. **[Configuration du mappage des sources d’événements](with-kafka-configure.md)** : créez ensuite la ressource de [mappage des sources d’événements](invocation-eventsourcemapping.md) dont Lambda a besoin pour connecter de façon sécurisée votre cluster Apache Kafka à votre fonction.
1. **[Configuration de la fonction et des autorisations](with-kafka-permissions.md)** : enfin, assurez-vous que votre fonction est correctement configurée et qu’elle dispose des autorisations nécessaires dans son [rôle d’exécution](lambda-intro-execution-role.md).
Apache Kafka en tant que source d’événement fonctionne de la même manière qu’Amazon Simple Queue Service (Amazon SQS) ou Amazon Kinesis. Lambda interroge en interne les nouveaux messages de la source d’événement, puis invoque de manière synchrone la fonction Lambda cible. Lambda lit les messages par lot et les fournit à votre fonction en tant que charge utile d’événement. La taille maximale du lot est configurable (la valeur par défaut est de 100 messages). Pour de plus amples informations, veuillez consulter [Comportement de traitement par lots](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching).
Pour optimiser le débit de votre mappage des sources d’événements Apache Kafka autogéré, configurez le mode alloué. En mode alloué, vous pouvez définir le nombre minimal et maximal de sondeurs d’événements alloués à votre mappage des sources d’événements. Cela peut améliorer la capacité de votre mappage des sources d’événements à gérer les pics de messages inattendus. Pour de plus amples informations, veuillez consulter [Mode alloué](kafka-scaling-modes.md#kafka-provisioned-mode).
**Avertissement**
Les mappages des sources d’événements Lambda traitent chaque événement au moins une fois, et le traitement des enregistrements peut être dupliqué. Pour éviter les problèmes potentiels liés à des événements dupliqués, nous vous recommandons vivement de rendre votre code de fonction idempotent. Pour en savoir plus, consultez [Comment rendre ma fonction Lambda idempotente](https://repost.aws/knowledge-center/lambda-function-idempotent) dans le Knowledge Center. AWS
Pour les sources d’événements basées sur Kafka, Lambda prend en charge les paramètres de contrôle du traitement par lots, tels que les fenêtres de traitement par lots et la taille des lots. Pour de plus amples informations, veuillez consulter [Comportement de traitement par lots](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching).
Pour un exemple d'utilisation de Kafka autogéré comme source d'événements, consultez la section [Utilisation d'Apache Kafka auto-hébergée comme source d'événements AWS Lambda sur le blog Compute](https://aws.amazon.com/blogs/compute/using-self-hosted-apache-kafka-as-an-event-source-for-aws-lambda/). AWS
**Topics**
+ [Exemple d’évènement](#smaa-sample-event)
+ [Configuration de votre cluster Apache Kafka autogéré, de votre VPC et de votre réseau Lambda](with-kafka-cluster-network.md)
+ [Configuration des autorisations de rôle d’exécution Lambda](with-kafka-permissions.md)
+ [Configuration de sources d’événements Apache Kafka autogérées pour Lambda](with-kafka-configure.md)
## Exemple d’évènement
Lambda envoie le lot de messages dans le paramètre d’événement quand il invoque votre fonction Lambda. La charge utile d’un événement contient un tableau de messages. Chaque élément de tableau contient des détails de la rubrique Kafka et l’identifiant de partition Kafka, ainsi qu’un horodatage et un message codé en base 64.
```
{
"eventSource": "SelfManagedKafka",
"bootstrapServers":"b-2.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092,b-1.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092",
"records":{
"mytopic-0":[
{
"topic":"mytopic",
"partition":0,
"offset":15,
"timestamp":1545084650987,
"timestampType":"CREATE_TIME",
"key":"abcDEFghiJKLmnoPQRstuVWXyz1234==",
"value":"SGVsbG8sIHRoaXMgaXMgYSB0ZXN0Lg==",
"headers":[
{
"headerKey":[
104,
101,
97,
100,
101,
114,
86,
97,
108,
117,
101
]
}
]
}
]
}
}
```
# Configuration de votre cluster Apache Kafka autogéré, de votre VPC et de votre réseau Lambda
Pour connecter votre fonction Lambda à votre cluster Apache Kafka autogéré, vous devez configurer correctement votre cluster et le réseau dans lequel il réside. Cette page décrit comment configurer votre cluster et votre réseau. Si votre cluster et votre réseau sont déjà correctement configurés, consultez [Configuration de sources d’événements Apache Kafka autogérées pour Lambda](with-kafka-configure.md) pour configurer le mappage des sources d’événements.
**Topics**
+ [Configuration de cluster Apache Kafka autogéré](#kafka-cluster-setup)
+ [Configurer la sécurité réseau](#services-kafka-vpc-config)
## Configuration de cluster Apache Kafka autogéré
Vous pouvez héberger votre cluster Apache Kafka autogéré auprès de fournisseurs de cloud comme [Confluent Cloud](https://www.confluent.io/confluent-cloud/) ou [Redpanda](https://www.redpanda.com/), ou l’exécuter sur votre propre infrastructure. Assurez-vous que votre cluster est correctement configuré et accessible depuis le réseau auquel votre mappage des sources d’événements Lambda sera connecté.
## Configurer la sécurité réseau
Pour donner à Lambda un accès complet à Apache Kafka autogéré via votre mappage des sources d’événements, soit votre cluster doit utiliser un point de terminaison public (adresse IP publique), soit vous devez fournir un accès au VPC Amazon dans lequel vous avez créé le cluster.
Lorsque vous utilisez Apache Kafka autogéré avec Lambda, créez des [points de terminaison de VPC AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) qui permettent à votre fonction d’accéder aux ressources de votre Amazon VPC.
**Note**
Les points de terminaison de VPC AWS PrivateLink sont requis pour les fonctions avec des mappages de sources d’événements qui utilisent le mode par défaut (à la demande) pour les interrogateurs d’événements. Si le mappage de votre source d’événements utilise le [mode provisionné](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode), vous n’avez pas besoin de configurer les points de terminaison de VPC AWS PrivateLink.
Créez un point de terminaison pour accéder aux ressources suivantes :
+ Lambda — Créez un point de terminaison pour le principal de service Lambda.
+ AWS STS — Créez un point de terminaison pour l’AWS STS afin qu’un principal de service assume un rôle en votre nom.
+ Secrets Manager : si votre cluster utilise Secrets Manager pour stocker les informations d’identification, créez un point de terminaison pour Secrets Manager.
Vous pouvez également configurer une passerelle NAT sur chaque sous-réseau public d’Amazon VPC. Pour de plus amples informations, consultez [Activation de l’accès Internet pour les fonctions Lambda connectées à un VPC](configuration-vpc-internet.md).
Lorsque vous créez un mappage des sources d’événements pour Apache Kafka autogéré, Lambda vérifie si des interfaces réseau Elastic (ENI) sont déjà présentes pour les sous-réseaux et les groupes de sécurité configurés pour votre VPC Amazon. Si Lambda trouve des ENI existantes, il tente de les réutiliser. Sinon, Lambda crée de nouvelles ENI pour se connecter à la source d’événement et invoquer votre fonction.
**Note**
Les fonctions Lambda sont toujours exécutées dans des VPC appartenant au service Lambda. La configuration VPC de votre fonction n’affecte pas le mappage des sources d’événements. Seule la configuration réseau des sources d’événements détermine la manière dont Lambda se connecte à votre source d’événements.
Configurez les groupes de sécurité pour le VPC Amazon contenant votre cluster. Par défaut, Apache Kafka autogéré utilise les ports suivants : `9092`.
+ Règles entrantes – Autorisent tout le trafic sur le port de l’agent par défaut pour le groupe de sécurité associé à votre source d’événement. Vous pouvez également utiliser une règle de groupe de sécurité avec référence circulaire pour autoriser l’accès à partir d’instances appartenant au même groupe de sécurité.
+ Règles sortantes : autorisent tout le trafic sur le port `443` pour des destinations externes si votre fonction doit communiquer avec des services AWS. Vous pouvez également utiliser une règle de groupe de sécurité avec référence circulaire pour limiter l’accès à l’agent si vous n’avez pas besoin de communiquer avec d’autres services AWS.
+ Règles entrantes relatives au point de terminaison Amazon VPC – Si vous utilisez un point de terminaison Amazon VPC, le groupe de sécurité associé à votre point de terminaison Amazon VPC doit autoriser le trafic entrant sur le port `443` en provenance du groupe de sécurité du cluster.
Si votre cluster utilise l’authentification, vous pouvez également restreindre la politique de point de terminaison pour le point de terminaison Secrets Manager. Pour appeler l’API Secrets Manager, Lambda utilise votre rôle de fonction, et non le principal de service Lambda.
**Example Politique de point de terminaison de VPC — Point de terminaison 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"
}
]
}
```
Lorsque vous utilisez des points de terminaison Amazon VPC, AWS achemine vos appels d’API pour invoquer votre fonction à l’aide de l’interface réseau Elastic (ENI) du point de terminaison. Le principal de service Lambda doit appeler `lambda:InvokeFunction` pour tous les rôles et fonctions utilisant ces ENI.
Par défaut, les points de terminaison Amazon VPC disposent de politiques IAM ouvertes qui permettent un accès étendu aux ressources. La meilleure pratique consiste à restreindre ces politiques pour effectuer les actions nécessaires à l’aide de ce point de terminaison. Pour garantir que votre mappage des sources d’événements est en mesure d’invoquer votre fonction Lambda, la politique de point de terminaison de VPC doit autoriser le principal de service Lambda à appeler `sts:AssumeRole` et `lambda:InvokeFunction`. Le fait de restreindre vos politiques de point de terminaison de VPC pour autoriser uniquement les appels d’API provenant de votre organisation empêche le mappage des sources d’événements de fonctionner correctement. C’est pourquoi `"Resource": "*"` est requis dans ces politiques.
Les exemples de politiques de point de terminaison de VPC suivants montrent comment accorder l’accès requis au principal de service Lambda pour les points de terminaison AWS STS et Lambda.
**Example Politique de point de terminaison de VPC — Point de terminaison AWS STS**
```
{
"Statement": [
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
**Example Politique de point de terminaison de VPC — Point de terminaison Lambda**
```
{
"Statement": [
{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
# Configuration des autorisations de rôle d’exécution Lambda
En plus d’[accéder au cluster Amazon Kafka autogéré](kafka-cluster-auth.md), votre fonction Lambda a besoin d’autorisations pour effectuer diverses actions d’API. Ajoutez ces autorisations au [rôle d’exécution](lambda-intro-execution-role.md) de votre fonction. Si vos utilisateurs ont besoin d'accéder à des actions d'API, ajoutez les autorisations requises à la politique d'identité de l'utilisateur ou du rôle Gestion des identités et des accès AWS (IAM).
**Topics**
+ [Autorisations de fonction Lambda requises](#smaa-api-actions-required)
+ [Autorisations de fonction Lambda facultatives](#smaa-api-actions-optional)
+ [Ajout d’autorisations à votre rôle d’exécution](#smaa-permissions-add-policy)
+ [Octroi d’accès à des utilisateurs avec une politique IAM](#smaa-permissions-add-users)
## Autorisations de fonction Lambda requises
Pour créer et stocker des journaux dans un groupe de CloudWatch journaux dans Amazon Logs, votre fonction Lambda doit disposer des autorisations suivantes dans son rôle d'exécution :
+ [journaux : CreateLogGroup](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogGroup.html)
+ [journaux : CreateLogStream](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogStream.html)
+ [journaux : PutLogEvents](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html)
## Autorisations de fonction Lambda facultatives
Votre fonction Lambda peut également nécessiter ces autorisations pour :
+ Décrivez votre secret Secrets Manager.
+ Accédez à votre AWS Key Management Service (AWS KMS) clé gérée par le client.
+ Accédez à votre Amazon VPC.
+ Envoyez les enregistrements des invocations ayant échoué vers une destination.
### Secrets Manager et AWS KMS autorisations
Selon le type de contrôle d'accès que vous configurez pour vos courtiers Kafka, votre fonction Lambda peut avoir besoin d'une autorisation pour accéder à votre secret Secrets Manager ou pour déchiffrer AWS KMS votre clé gérée par le client. Afin d’accéder à ces ressources, le rôle d’exécution de votre fonction doit disposer des autorisations suivantes :
+ [responsable des secrets : GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html)
+ [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html)
### Autorisations VPC
Si seuls des utilisateurs au sein d’un VPC peuvent accéder à votre cluster Apache Kafka autogéré, votre fonction Lambda doit être autorisée à accéder à vos ressources Amazon VPC. Ces ressources incluent les sous-réseaux, groupes de sécurité et interfaces réseau de votre VPC. Afin d’accéder à ces ressources, le rôle d’exécution de votre fonction doit disposer des autorisations suivantes :
+ [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)
## Ajout d’autorisations à votre rôle d’exécution
[Pour accéder aux autres AWS services utilisés par votre cluster Apache Kafka autogéré, Lambda utilise les politiques d'autorisation que vous définissez dans le rôle d'exécution de votre fonction Lambda.](lambda-intro-execution-role.md)
Par défaut, Lambda n’est pas autorisé à exécuter les actions obligatoires ou facultatives pour un cluster Apache Kafka autogéré. Vous devez créer et définir ces actions dans une [stratégie d’approbation IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-trust-policy.html) pour votre rôle d’exécution. Cet exemple montre comment créer une stratégie autorisant Lambda à accéder à vos ressources Amazon VPC.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ec2:CreateNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeVpcs",
"ec2:DeleteNetworkInterface",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups"
],
"Resource":"*"
}
]
}
```
------
## Octroi d’accès à des utilisateurs avec une politique IAM
Par défaut, les utilisateurs et les rôles n’ont pas l’autorisation d’effectuer des [opérations d’API de source d’événement](invocation-eventsourcemapping.md#event-source-mapping-api). Pour accorder l’accès aux utilisateurs de votre organisation ou de votre compte, vous pouvez ajouter ou mettre à jour une stratégie basée sur l’identité. Pour plus d'informations, consultez la section [Contrôle de l'accès aux AWS ressources à l'aide de politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html) dans le *Guide de l'utilisateur IAM*.
Pour résoudre les erreurs d’authentification et d’autorisation, consultez [Résolution des erreurs de mappage des sources d’événements Kafka](with-kafka-troubleshoot.md).
# Configuration de sources d’événements Apache Kafka autogérées pour Lambda
Pour utiliser un cluster Apache Kafka autogéré en tant que source d’événements pour votre fonction Lambda, vous devez créer un [mappage des sources d’événements](invocation-eventsourcemapping.md) qui connecte les deux ressources. Cette page explique comment créer un mappage des sources d’événements pour Apache Kafka autogéré.
Cette page suppose que vous avez déjà correctement configuré votre cluster Kafka et le réseau dans lequel il réside. Si vous devez configurer votre cluster ou votre réseau, consultez [Configuration de votre cluster Apache Kafka autogéré, de votre VPC et de votre réseau Lambda](with-kafka-cluster-network.md).
**Topics**
+ [Utilisation d’un cluster Apache Kafka autogéré comme source d’événement](#kafka-esm-overview)
+ [Configuration des méthodes d’authentification de cluster dans Lambda](kafka-cluster-auth.md)
+ [Création d’un mappage des sources d’événements Lambda pour une source d’événements Apache Kafka autogéré](kafka-esm-create.md)
+ [Tous les paramètres de configuration des sources d’événements Apache Kafka autogéré dans Lambda](kafka-esm-parameters.md)
## Utilisation d’un cluster Apache Kafka autogéré comme source d’événement
Lorsque vous ajoutez votre cluster Apache Kafka ou Amazon MSK comme déclencheur pour votre fonction Lambda, le cluster est utilisé comme [source d’événement](invocation-eventsourcemapping.md).
Lambda lit les données d'événements des rubriques Kafka que vous spécifiez `Topics` dans une [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)demande, en fonction de la [position de départ](kafka-starting-positions.md) que vous spécifiez. Lorsque le traitement a réussi, votre rubrique Kafka est validée dans votre cluster Kafka.
Lambda lit les messages séquentiellement pour chaque partition de rubrique Kafka. Une seule charge utile Lambda peut contenir des messages provenant de plusieurs partitions. Lorsque d'autres enregistrements sont disponibles, Lambda continue de traiter les enregistrements par lots, en fonction de la BatchSize valeur que vous spécifiez dans une [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)demande, jusqu'à ce que votre fonction aborde le sujet.
Après avoir traité chaque lot, Lambda valide les décalages des messages dans celui-ci. Si votre fonction renvoie une erreur pour l’un des messages d’un lot, Lambda réessaie le lot de messages complet jusqu’à ce que le traitement réussisse ou que les messages expirent. Vous pouvez envoyer les enregistrements qui échouent à toutes les tentatives vers une destination en cas de panne pour un traitement ultérieur.
**Note**
Alors que les fonctions Lambda ont généralement un délai d’expiration maximal de 15 minutes, les mappages des sources d’événement pour Amazon MSK, Apache Kafka autogéré, Amazon DocumentDB et Amazon MQ pour ActiveMQ et RabbitMQ ne prennent en charge que les fonctions dont le délai d’expiration maximal est de 14 minutes.
# Configuration des méthodes d’authentification de cluster dans Lambda
Lambda prend en charge plusieurs méthodes d’authentification auprès de votre cluster Apache Kafka autogéré. Veillez à configurer le cluster Kafka pour utiliser l’une des méthodes d’authentification prises en charge suivantes : Pour de plus amples informations sur la sécurité, veuillez consulter la section [Sécurité](http://kafka.apache.org/documentation.html#security) de la documentation Kafka.
## Authentification SASL/SCRAM
Lambda prend en charge l'authentification simple et le mécanisme d'authentification par réponse aux Layer/Salted défis de sécurité (SASL/SCRAM) avec le chiffrement TLS (Transport Layer Security) (). `SASL_SSL` Lambda envoie les informations d’identification chiffrées pour s’authentifier auprès du cluster. Lambda n'est pas compatible SASL/SCRAM avec plaintext (). `SASL_PLAINTEXT` Pour plus d'informations sur SASL/SCRAM l'authentification, consultez la [RFC 5802](https://tools.ietf.org/html/rfc5802).
Lambda prend également en charge SASL/PLAIN l'authentification. Comme ce mécanisme utilise des informations d’identification en texte clair, la connexion au serveur doit utiliser le chiffrement TLS pour garantir la protection des informations d’identification.
Pour l’authentification SASL, vous devez stocker les informations d’identification en tant que secret dans AWS Secrets Manager. Pour plus d'informations sur l'utilisation de Secrets Manager, consultez la section [Créer un AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) dans le *Guide de AWS Secrets Manager l'utilisateur*.
**Important**
Pour utiliser Secrets Manager pour l'authentification, les secrets doivent être stockés dans la même AWS région que votre fonction Lambda.
## Authentification TLS mutuelle
Mutual TLS (mTLS) fournit une authentification bidirectionnelle entre le client et le serveur. Le client envoie un certificat au serveur pour que le serveur vérifie le client, et le serveur envoie un certificat au client pour que le client vérifie le serveur.
Dans Apache Kafka autogéré, Lambda agit en tant que client. Vous configurez un certificat client (en tant que secret dans Secrets Manager) pour authentifier Lambda auprès des courtiers Kafka. Le certificat client doit être signé par une autorité de certification dans le magasin d’approbations du serveur.
Le cluster Kafka envoie un certificat de serveur à Lambda pour authentifier les courtiers auprès de Lambda. Le certificat de serveur peut être un certificat d'autorité de certification public ou privéCA/self-signed certificate. The public CA certificate must be signed by a certificate authority (CA) that's in the Lambda trust store. For a private CA/self, vous configurez le certificat d'autorité de certification racine du serveur (en tant que secret dans Secrets Manager). Lambda utilise le certificat racine pour vérifier les courtiers Kafka.
Pour de plus amples informations sur mTLS, veuillez consulter [Introduction d’une authentification TLS mutuelle pour Amazon MSK en tant que source d’événement](https://aws.amazon.com/blogs/compute/introducing-mutual-tls-authentication-for-amazon-msk-as-an-event-source).
## Configuration du secret du certificat client
Le secret CLIENT\$1CERTIFICATE\$1TLS\$1AUTH nécessite un champ de certificat et un champ de clé privée. Pour une clé privée chiffrée, le secret nécessite un mot de passe de clé privée. Le certificat et la clé privée doivent être au format PEM.
**Note**
Lambda prend en charge les algorithmes de chiffrement par clé privée [PBES1](https://datatracker.ietf.org/doc/html/rfc2898/#section-6.1)(mais pas PBES2).
Le champ de certificat doit contenir une liste de certificats, commençant par le certificat client, suivi de tous les certificats intermédiaires et se terminant par le certificat racine. Chaque certificat doit commencer sur une nouvelle ligne avec la structure suivante :
```
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
```
Secrets Manager prend en charge les secrets jusqu’à 65 536 octets, ce qui offre suffisamment d’espace pour de longues chaînes de certificats.
La clé privée doit être au format [PKCS \$18](https://datatracker.ietf.org/doc/html/rfc5208), avec la structure suivante :
```
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
```
Pour une clé privée chiffrée, utilisez la structure suivante :
```
-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----
```
L’exemple suivant affiche le contenu d’un secret pour l’authentification mTLS à l’aide d’une clé privée chiffrée. Pour une clé privée chiffrée, incluez le mot de passe de clé privée dans le secret.
```
{"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-----"
}
```
## Configuration du secret du certificat d’autorité de certification racine du serveur
Vous créez ce secret si vos courtiers Kafka utilisent le chiffrement TLS avec des certificats signés par une autorité de certification privée. Vous pouvez utiliser le chiffrement TLS pour l'authentification VPC ou SASL/SCRAM, SASL/PLAIN mTLS.
Le secret du certificat d’autorité de certification racine du serveur nécessite un champ contenant le certificat d’autorité de certification racine du courtier Kafka au format PEM. La structure du secret est présentée dans l’exemple suivant.
```
{"certificate":"-----BEGIN CERTIFICATE-----
MIID7zCCAtegAwIBAgIBADANBgkqhkiG9w0BAQsFADCBmDELMAkGA1UEBhMCVVMx
EDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxJTAjBgNVBAoT
HFN0YXJmaWVsZCBUZWNobm9sb2dpZXMsIEluYy4xOzA5BgNVBAMTMlN0YXJmaWVs
ZCBTZXJ2aWNlcyBSb290IENlcnRpZmljYXRlIEF1dG...
-----END CERTIFICATE-----"
}
```
# Création d’un mappage des sources d’événements Lambda pour une source d’événements Apache Kafka autogéré
Pour créer un mappage des sources d’événements, vous pouvez utiliser la console Lambda, [AWS Command Line Interface (CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) ou un [SDK AWS](https://aws.amazon.com/getting-started/tools-sdks/).
Les étapes de console suivantes ajoutent un cluster Apache Kafka autogéré en tant que déclencheur pour votre fonction Lambda. En arrière-plan, cela crée une ressource de mappage des sources d’événements.
## Conditions préalables
+ Cluster Apache Kafka autogéré. Lambda prend en charge Apache Kafka versions 0.10.1.0 et ultérieures.
+ [Rôle d'exécution](lambda-intro-execution-role.md) autorisé à accéder aux AWS ressources utilisées par votre cluster Kafka autogéré.
## Ajout d’un cluster Kafka autogéré (console)
Pour ajouter votre cluster Apache Kafka autogéré et une rubrique Kafka en tant que déclencheur pour votre fonction Lambda, procédez comme suit.
**Pour ajouter un déclencheur Apache Kafka à votre fonction Lambda (console)**
1. Ouvrez la [page Functions (Fonctions)](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda.
1. Choisissez le nom de votre fonction Lambda.
1. Sous **Function overview** (Vue d’ensemble de la fonction), choisissez **Add trigger** (Ajouter un déclencheur).
1. Sous **Trigger configuration (Configuration du déclencheur)**, procédez comme suit :
1. Choisissez le type de déclencheur **Apache Kafka**.
1. Pour **Bootstrap servers (Serveurs d’amorçage)**, entrez l’adresse de paire hôte et port d’un agent Kafka dans votre cluster, puis choisissez **Add (Ajouter)**. Répétez l’opération pour chaque agent Kafka dans le cluster.
1. Pour **Topic name (Nom de rubrique)**, entrez le nom de la rubrique Kafka utilisée pour stocker les registres dans le cluster.
1. Si vous configurez le mode provisionné, entrez une valeur pour **Minimum Event Sollers**, une valeur pour **Maximum Event Sollers** et une valeur facultative pour PollerGroupName spécifier le regroupement de plusieurs ESMs au sein d'un même VPC source d'événements.
1. (Facultatif) Pour **Batch size (Taille de lot)**, entrez le nombre maximal de registres à recevoir dans un même lot.
1. Pour **Batch window**, veuillez saisir l’intervalle de temps maximal en secondes nécessaire à Lambda pour collecter des enregistrements avant d’invoquer la fonction.
1. (Facultatif) Pour **l’identifiant de groupe de consommateurs**, entrez l’identifiant d’un groupe de consommateurs Kafka à rejoindre.
1. (Facultatif) Pour **Position de départ**, choisissez **Dernier** pour commencer à lire le flux à partir du dernier enregistrement, **Supprimer l’horizon** pour commencer au premier enregistrement disponible ou **À l’horodatage** pour spécifier un horodatage à partir duquel commencer la lecture.
1. (Facultatif) Pour **VPC**, choisissez l’Amazon VPC pour votre cluster Kafka. Ensuite, choisissez le **VPC subnets (Sous-réseaux VPC)** et les **VPC security groups (Groupes de sécurité VPC)**.
Ce paramètre est requis si seuls des utilisateurs au sein de votre VPC accèdent à vos courtiers.
1. (Facultatif) Pour **Authentication (Authentification)**, choisissez **Add (Ajouter)**, puis procédez comme suit :
1. Choisissez le protocole d’accès ou d’authentification des courtiers Kafka dans votre cluster.
+ Si votre broker Kafka utilise l' SASL/PLAIN authentification, choisissez **BASIC\$1AUTH**.
+ Si votre courtier utilise SASL/SCRAM l'authentification, choisissez l'un des **SASL\$1SCRAM**protocoles.
+ Si vous configurez l’authentification mTLS, choisissez le protocole **CLIENT\$1CERTIFICATE\$1TLS\$1AUTH**.
1. Pour l' SASL/SCRAM authentification mTLS, choisissez la clé secrète de Secrets Manager qui contient les informations d'identification de votre cluster Kafka.
1. (Facultatif) Pour **Encryption (Chiffrement)**, choisissez le secret Secrets Manager contenant le certificat d’autorité de certification racine que vos courtiers Kafka utilisent pour le chiffrement TLS, si vos courtiers Kafka utilisent des certificats signés par une autorité de certification privée.
Ce paramètre s'applique au chiffrement TLS pour SASL/SCRAM ou SASL/PLAIN, ainsi qu'à l'authentification MTLS.
1. Pour créer le déclencheur dans un état désactivé pour le test (recommandé), désactivez **Enable trigger** (Activer le déclencheur). Ou, pour activer le déclencheur immédiatement, sélectionnez**Activer un déclencheur**.
1. Pour créer le déclencheur, choisissez **Add** (Ajouter).
## Ajout d’un cluster Kafka autogéré (AWS CLI)
Utilisez les exemples de AWS CLI commandes suivants pour créer et afficher un déclencheur Apache Kafka autogéré pour votre fonction Lambda.
### Utilisation de SASL/SCRAM
Si les utilisateurs de Kafka accèdent à vos courtiers Kafka via Internet, spécifiez le secret du Gestionnaire de Secrets que vous avez créé pour SASL/SCRAM l'authentification. L'exemple suivant utilise la [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html) AWS CLI commande pour mapper une fonction Lambda nommée `my-kafka-function` à une rubrique Kafka nommée. `AWSKafkaTopic`
```
aws lambda create-event-source-mapping \
--topics AWSKafkaTopic \
--source-access-configuration Type=SASL_SCRAM_512_AUTH,URI=arn:aws:secretsmanager:us-east-1:111122223333:secret:MyBrokerSecretName \
--function-name arn:aws:lambda:us-east-1:111122223333:function:my-kafka-function \
--self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc3.xyz.com:9092", "abc2.xyz.com:9092"]}}'
```
### Utilisation d’un VPC
Si seuls des utilisateurs de Kafka au sein de votre VPC accèdent à vos agents Kafka, vous devez spécifier votre VPC, vos sous-réseaux et votre groupe de sécurité de VPC. L'exemple suivant utilise la [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html) AWS CLI commande pour mapper une fonction Lambda nommée `my-kafka-function` à une rubrique Kafka nommée. `AWSKafkaTopic`
```
aws lambda create-event-source-mapping \
--topics AWSKafkaTopic \
--source-access-configuration '[{"Type": "VPC_SUBNET", "URI": "subnet:subnet-0011001100"}, {"Type": "VPC_SUBNET", "URI": "subnet:subnet-0022002200"}, {"Type": "VPC_SECURITY_GROUP", "URI": "security_group:sg-0123456789"}]' \
--function-name arn:aws:lambda:us-east-1:111122223333:function:my-kafka-function \
--self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc3.xyz.com:9092", "abc2.xyz.com:9092"]}}'
```
### Affichage de l'état à l'aide du AWS CLI
L'exemple suivant utilise la [get-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/get-event-source-mapping.html) AWS CLI commande pour décrire l'état du mappage des sources d'événements que vous avez créé.
```
aws lambda get-event-source-mapping
--uuid dh38738e-992b-343a-1077-3478934hjkfd7
```
# Tous les paramètres de configuration des sources d’événements Apache Kafka autogéré dans Lambda
Tous les types de sources d'événements Lambda partagent les mêmes opérations [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)et les mêmes opérations d'[UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)API. Cependant, seuls certains paramètres s’appliquent à Apache Kafka autogéré, comme indiqué dans le tableau suivant.
| Paramètre | Obligatoire | Par défaut | Remarques |
| --- | --- | --- | --- |
| BatchSize | N | 100 | Maximum : 10 000. |
| DestinationConfig | N | N/A | [Capture de lots supprimés pour des sources d’événement Amazon MSK et Apache Kafka autogéré](kafka-on-failure.md) |
| Activé | N | True | |
| FilterCriteria | N | N/A | [Contrôle des événements envoyés par Lambda à votre fonction](invocation-eventfiltering.md) |
| FunctionName | Y | N/A | |
| KMSKeyArn | N | N/A | [Chiffrement des critères de filtre](invocation-eventfiltering.md#filter-criteria-encryption) |
| MaximumBatchingWindowInSeconds | N | 500 ms | [Comportement de traitement par lots](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching) |
| ProvisionedPollersConfig | N | `MinimumPollers` : la valeur par défaut, si elle n’est pas spécifiée, est de 1 `MaximumPollers` : la valeur par défaut, si elle n’est pas spécifiée, est de 200 `PollerGroupName`: N/A | [Mode alloué](kafka-scaling-modes.md#kafka-provisioned-mode) |
| SelfManagedEventSource | Y | N/A | Liste des agents Kafka. Peut définir uniquement sur Create (Créer) |
| SelfManagedKafkaEventSourceConfig | N | Contient le ConsumerGroupId champ qui prend par défaut une valeur unique. | Peut définir uniquement sur Create (Créer) |
| SourceAccessConfigurations | N | Pas d’informations d’identification | Informations sur le VPC ou informations d’authentification pour le cluster Pour SASL\$1PLAIN, défini sur BASIC\$1AUTH |
| StartingPosition | Y | N/A | AT\$1TIMESTAMP, TRIM\$1HORIZON ou DERNIER Peut définir uniquement sur Create (Créer) |
| StartingPositionTimestamp | N | N/A | Obligatoire s'il StartingPosition est défini sur AT\$1TIMESTAMP |
| Étiquettes | N | N/A | [Utilisation des balises dans les mappages des sources d’événements](tags-esm.md) |
| Rubriques | Y | N/A | Nom du sujet Peut définir uniquement sur Create (Créer) |
**Note**
Lorsque vous spécifiez un`PollerGroupName`, plusieurs ESMs au sein d'un même Amazon VPC peuvent partager la capacité de l'Event Poller Unit (EPU). Vous pouvez utiliser cette option pour optimiser les coûts du mode provisionné pour votre ESMs. Exigences relatives au regroupement ESM :
ESMs doit se trouver dans le même Amazon VPC
Maximum de 100 ESMs par groupe de sondeurs
Le nombre maximum de sondeurs agrégés pour l'ensemble ESMs d'un groupe ne peut pas dépasser 2 000
Vous pouvez le mettre `PollerGroupName` à jour pour déplacer un ESM vers un autre groupe, ou supprimer un ESM d'un groupe en le définissant `PollerGroupName` sur une chaîne vide (« »).
# Modes de mise à l’échelle des sondeurs d’événements Apache Kafka dans Lambda
Vous pouvez choisir entre deux modes de mise à l’échelle des sondeurs d’événements pour Amazon MSK et les mappages des sources d’événements Apache Kafka autogéré :
+ [Mode à la demande (par défaut)](#kafka-default-mode)
+ [Mode alloué](#kafka-provisioned-mode)
## Mode à la demande (par défaut)
Lorsque vous créez initialement une source d’événement Kafka, Lambda alloue un nombre de sondeurs d’événements par défaut pour traiter toutes les partitions de la rubrique Kafka. Lambda augmente ou diminue automatiquement le nombre de [sondeurs d’événements](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode), en fonction de la charge de messages.
Toutes les minutes, Lambda évalue le décalage entre toutes les partitions dans la rubrique. Si le décalage est trop élevé, la partition reçoit des messages plus rapidement que Lambda ne peut les traiter. Si nécessaire, Lambda ajoute ou supprime des sondeurs d’événements dans la rubrique. Cette mise à l’échelle automatique consistant à ajouter ou à supprimer des sondeurs d’événements a lieu dans les trois minutes suivant l’évaluation.
Si votre fonction Lambda cible est limitée, Lambda réduit le nombre de sondeurs d’événements. Cette action réduit la charge de travail de la fonction en diminuant le nombre de messages que les sondeurs d’événements peuvent échanger avec la fonction.
## Mode alloué
Pour les charges de travail où vous devez optimiser le débit de votre mappage des sources d’événements, vous pouvez utiliser le mode provisionné. En mode provisionné, vous définissez des limites minimales et maximales pour le nombre de sondeurs d’événements alloués. Ces sondeurs d’événements alloués sont dédiés à votre mappage des sources d’événements et peuvent gérer les pics de messages inattendus grâce à une mise à l’échelle automatique réactive. Nous vous recommandons d’utiliser le mode provisionné pour les charges de travail Kafka soumises à des exigences de performance strictes.
Dans Lambda, un sondeur d'événements est une unité de calcul dont les capacités de débit varient selon le type de source d'événements. Pour Amazon MSK et Apache Kafka autogéré, chaque sondeur d'événements peut gérer jusqu'à 5 % MB/sec du débit ou jusqu'à 5 appels simultanés. Par exemple, si la source de votre événement produit une charge utile moyenne de 1 Mo et que la durée moyenne de votre fonction est de 1 seconde, un seul sondeur d'événements Kafka peut prendre en charge 5 MB/sec débits et 5 appels Lambda simultanés (en supposant qu'il n'y ait aucune transformation de charge utile). Pour Amazon SQS, chaque sondeur d'événements peut gérer jusqu'à 1 % MB/sec du débit ou jusqu'à 10 appels simultanés. L'utilisation du mode provisionné entraîne des coûts supplémentaires en fonction de l'utilisation de votre sondeur d'événements. Pour plus d’informations sur la tarification, consultez [Tarification AWS Lambda](https://aws.amazon.com/lambda/pricing/).
**Note**
Lorsque vous utilisez le mode provisionné, il n'est pas nécessaire de créer des points de terminaison AWS PrivateLink VPC ni d'accorder les autorisations associées dans le cadre de la configuration de votre réseau.
En mode provisionné, la plage de valeurs acceptées pour le nombre minimal de sondeurs d’événements (`MinimumPollers`) est comprise entre 1 et 200 inclus. La plage de valeurs acceptées pour le nombre maximal de sondeurs d’événements (`MaximumPollers`) est comprise entre 1 et 2 000 inclus. `MaximumPollers` doit être supérieur ou égal à `MinimumPollers`. En outre, pour maintenir un traitement ordonné au sein des partitions, Lambda limite le nombre de `MaximumPollers` au nombre de partitions dans la rubrique.
Pour plus de détails sur le choix des valeurs appropriées pour le nombre minimal et maximal de sondeurs d’événements, consultez [Bonnes pratiques](#kafka-provisioned-mode-bp).
Vous pouvez configurer le mode provisionné pour le mappage des sources d’événements Kafka à l’aide de la console ou de l’API Lambda.
**Pour configurer le mode provisionné pour un mappage des sources d’événements existant (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez la fonction avec le mappage des sources d’événements pour laquelle vous souhaitez configurer le mode provisionné.
1. Choisissez **Configuration**, puis **Déclencheurs**.
1. Choisissez le mappage des sources d’événements pour lequel vous souhaitez configurer le mode alloué, puis choisissez **Modifier**.
1. Sous **Mode provisionné**, sélectionnez **Configurer**.
+ Pour le **Nombre minimal de sondeurs d’événements**, saisissez une valeur comprise entre 1 et 200. Si vous ne spécifiez aucune valeur, Lambda choisit la valeur par défaut 1.
+ Pour le **Nombre maximal de sondeurs d’événements**, saisissez une valeur comprise entre 1 et 2 000. Cette valeur doit être supérieure ou égale à la valeur du **Nombre minimal de sondeurs d’événements**. Si vous ne spécifiez aucune valeur, Lambda choisit la valeur par défaut 200.
1. Choisissez **Enregistrer**.
Vous pouvez configurer le mode provisionné par programmation à l'aide de l'[ProvisionedPollerConfig](https://docs.aws.amazon.com/lambda/latest/api/API_ProvisionedPollerConfig.html)objet de votre. [ EventSourceMappingConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_EventSourceMappingConfiguration.html) Par exemple, la commande [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)CLI suivante configure une `MinimumPollers` valeur de 5 et une `MaximumPollers` valeur de 100.
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--provisioned-poller-config '{"MinimumPollers": 5, "MaximumPollers": 100}'
```
Après avoir configuré le mode alloué, vous pouvez observer l’utilisation des sondeurs d’événements pour votre charge de travail en surveillant la métrique `ProvisionedPollers`. Pour de plus amples informations, veuillez consulter [Métriques de mappage des sources d’événements](monitoring-metrics-types.md#event-source-mapping-metrics).
Pour désactiver le mode provisionné et revenir au mode par défaut (à la demande), vous pouvez utiliser la commande [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)CLI suivante :
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--provisioned-poller-config '{}'
```
## Fonctionnalités avancées de gestion des erreurs et de performance
Pour les mappages de sources d'événements Kafka avec le mode provisionné activé, vous pouvez configurer des fonctionnalités supplémentaires pour améliorer la gestion des erreurs et les performances :
+ [Configurations de nouvelles tentatives](kafka-retry-configurations.md) : contrôlez la façon dont Lambda gère les enregistrements ayant échoué avec un maximum de tentatives, des limites d'âge des enregistrements, un fractionnement par lots et des réponses partielles par lots.
+ [Destinations Kafka en cas de défaillance](kafka-on-failure-destination.md) : envoyez les enregistrements ayant échoué vers une rubrique Kafka pour un traitement ou une analyse ultérieurs.
## Bonnes pratiques et considérations lors de l’utilisation du mode provisionné
La configuration optimale du nombre minimal et maximal de sondeurs d’événements pour votre mappage des sources d’événements dépend des exigences de performances de votre application. Nous vous recommandons de commencer avec le nombre minimal de sondeurs d’événéments par défaut afin de définir le profil de performances. Ajustez votre configuration en fonction des modèles de traitement des messages observés et du profil de performances souhaité.
Pour les charges de travail associées à des pics de trafic et à des exigences de performances strictes, augmentez le nombre minimal de sondeurs d’événements de manière à gérer les pics soudains de messages. Pour déterminer le nombre minimal de sondeurs d'événements requis, prenez en compte le nombre de messages par seconde de votre charge de travail et la taille moyenne de la charge utile, et utilisez la capacité de débit d'un seul sondeur d'événements (jusqu'à 5 MBps) comme référence.
Pour maintenir un traitement ordonné au sein d’une partition, Lambda limite le nombre maximal de sondeurs d’événements au nombre de partitions dans la rubrique. En outre, le nombre maximal de sondeurs d’événements auxquels votre mappage des sources d’événements peut être mis à l’échelle dépend des paramètres de simultanéité de la fonction.
Lorsque vous activez le mode provisionné, mettez à jour vos paramètres réseau pour supprimer les points de terminaison AWS PrivateLink VPC et les autorisations associées.
## Optimisation des coûts pour le mode provisionné
### Tarification du mode provisionné
Le mode provisionné est facturé en fonction du nombre minimum de sondeurs d'événements provisionnés et des sondeurs d'événements consommés lors du dimensionnement automatique. Les frais sont calculés à l'aide d'une unité de facturation appelée Event Poller Unit (EPU). Vous payez en fonction du nombre et de la durée d' EPUs utilisation, exprimés en Event-Poller-Unit-hours. Vous pouvez utiliser le mode provisionné avec un seul ESM pour les applications sensibles aux performances ou vous pouvez en regrouper plusieurs au sein d'un même VPC pour partager ESMs la capacité et les coûts de l'EPU. Nous aborderons en détail deux fonctionnalités qui vous aident à optimiser les coûts de votre mode provisionné. Pour plus de détails sur les tarifs, consultez la section Tarification [AWS Lambda](https://aws.amazon.com/lambda/pricing/).
### Utilisation améliorée de l'EPU
Chaque EPU prend en charge une capacité de MB/s débit allant jusqu'à 20 pour l'interrogation d'événements et prend en charge 10 sondeurs d'événements par défaut. Lorsque vous créez un mode provisionné pour Kafka ESM en définissant un minimum et un maximum de sondeurs, il utilise un nombre minimum d'interrogateurs pour le provisionnement sur la EPUs base de 10 sondeurs d'événements par EPU par défaut. Cependant, chaque sondeur d'événements peut évoluer indépendamment pour prendre en charge jusqu'à 5 % de la capacité MB/s de débit, ce qui peut nécessiter une plus faible densité de sondeurs d'événements sur un EPU spécifique et peut déclencher une mise à l'échelle de. EPUs Le nombre de sondeurs d'événements alloués sur un EPU dépend de la capacité de calcul consommée par chaque sondeur d'événements. Cette approche d'utilisation améliorée de l'EPU permet aux enquêteurs ayant des exigences de débit variables d'utiliser efficacement la capacité de l'EPU, réduisant ainsi les coûts pour tous. ESMs
### Regroupement ESM
Pour optimiser davantage les coûts de votre mode provisionné, vous pouvez regrouper plusieurs Kafka ESMs afin de partager la capacité de l'EPU. Grâce au regroupement ESM et à l'utilisation améliorée de l'EPU, vous pouvez réduire les coûts du mode provisionné jusqu'à 90 % pour les charges de travail à faible débit par rapport à l'exécution en mode ESM unique. Tous ceux ESMs qui nécessitent moins d'une capacité EPU bénéficieront du regroupement ESM. Cela nécessite ESMs généralement un nombre minimal de sondeurs d'événements pour répondre à leurs besoins en matière de débit. Cette fonctionnalité vous permettra d'adopter le mode provisionné pour toutes vos charges de travail Kafka et de bénéficier de fonctionnalités telles que la validation du schéma, le filtrage des Avro/Protobuf événements, les appels à faible latence et la gestion améliorée des erreurs, uniquement disponibles en mode provisionné.
Lorsque vous configurez le `PollerGroupName` paramètre avec la même valeur pour plusieurs éléments d' ESMs un même Amazon VPC, ceux-ci ESMs partagent des ressources EPU au lieu de nécessiter chacun une capacité EPU dédiée. Vous pouvez regrouper jusqu'à 100 ESMs par groupe de sondeurs et le nombre maximum de sondeurs par groupe ne peut pas dépasser 2 000. ESMs
#### Pour configurer le regroupement ESM (console)
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez votre fonction.
1. Choisissez **Configuration**, puis **Déclencheurs**.
1. Lorsque vous créez un nouveau mappage de source d'événements Kafka ou que vous modifiez un mappage existant, sélectionnez **Configurer** en mode **provisionné**.
1. Pour le **Nombre minimal de sondeurs d’événements**, saisissez une valeur comprise entre 1 et 200.
1. Pour le **Nombre maximal de sondeurs d’événements**, saisissez une valeur comprise entre 1 et 2 000.
1. Pour le **nom du groupe Poller**, entrez un identifiant pour le groupe. Utilisez le même nom pour les autres ESMs personnes que vous souhaitez regrouper.
1. Choisissez **Enregistrer**.
#### Pour configurer le regroupement ESM (AWS CLI)
L'exemple suivant crée un ESM avec un groupe de sondeurs nommé : `production-app-group`
```
aws lambda create-event-source-mapping \
--function-name myFunction1 \
--event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster/abcd1234 \
--topics topic1 \
--starting-position LATEST \
--provisioned-poller-config '{
"MinimumPollers": 1,
"MaximumPollers": 10,
"PollerGroupName": "production-app-group"
}'
```
Pour ajouter un autre ESM au même groupe (partageant la capacité de l'EPU), utilisez le même : PollerGroupName
```
aws lambda create-event-source-mapping \
--function-name myFunction2 \
--event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster/abcd1234 \
--topics topic2 \
--starting-position LATEST \
--provisioned-poller-config '{
"MinimumPollers": 1,
"MaximumPollers": 10,
"PollerGroupName": "production-app-group"
}'
```
**Note**
Vous pouvez mettre `PollerGroupName` à jour le pour déplacer un ESM vers un autre groupe, ou supprimer un ESM d'un groupe en transmettant une chaîne vide (« ») pour : `PollerGroupName`
```
# Move ESM to a different group
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--provisioned-poller-config '{
"MinimumPollers": 1,
"MaximumPollers": 10,
"PollerGroupName": "new-group-name"
}'
# Remove ESM from group (use dedicated resources)
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--provisioned-poller-config '{
"MinimumPollers": 1,
"MaximumPollers": 10,
"PollerGroupName": ""
}'
```
#### Considérations relatives aux stratégies de regroupement
+ **Limite des applications** : groupe ESMs appartenant aux mêmes applications ou services pour une meilleure allocation et une meilleure gestion des coûts. Envisagez d'utiliser des conventions de dénomination telles que `app-name-environment` (par exemple,`order-processor-prod`).
+ **Schéma de trafic** : évitez les regroupements ESMs présentant un débit élevé et des pics de trafic, car cela pourrait entraîner une contention des ressources.
+ **Rayon d'explosion** — Tenez compte de l'impact si l'infrastructure partagée rencontre des problèmes. Tous ESMs les membres d'un même groupe sont concernés par les limites des ressources partagées. Pour les charges de travail critiques, vous pouvez utiliser des groupes distincts ou dédiés. ESMs
#### Exemple d'optimisation des coûts
Imaginons un scénario dans lequel vous en avez 10 ESMs, chacun étant configuré avec un sondeur d'événements et un débit inférieur à 2 Mo/s :
**Sans regroupement :**
+ Chaque ESM a besoin de son propre EPU
+ Total EPUs nécessaire : 10
+ Coût par EPU : 0,185 \$1/heure dans l'est des États-Unis (Virginie du Nord)
+ Coût mensuel de l'EPU (720 heures) : 10 × 720 × 0,185\$1 = 1 332\$1
**Avec regroupement :**
+ Tous les 10 ESMs partagent la capacité de l'EPU
+ 10 sondeurs événementiels peuvent être utilisés dans 1 EPU (avec 10 nouveaux sondeurs par support EPU)
+ Total EPUs nécessaire : 1
+ Coût mensuel de l'EPU (720 heures) : 1 × 720 × 0,185\$1 = 133,20\$1
+ **Économies de coûts : 90 %** (1 198,80\$1 d'économies par mois)
# Positions de départ des interrogations et flux Apache Kafka dans Lambda
Le [paramètre StartingPosition](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-StartingPosition) indique à Lambda quand commencer à lire les messages depuis votre flux Amazon MSK ou Apache Kafka autogéré. Vous avez le choix entre trois options :
+ **Dernier** : Lambda commence à lire juste après l’enregistrement le plus récent de la rubrique Kafka.
+ **Supprimer l’horizon** : Lambda commence par le dernier enregistrement non découpé de la rubrique Kafka. Il s’agit également de l’enregistrement le plus ancien de la rubrique.
+ **À l’horodatage** : Lambda commence à lire à partir d’une position définie par un horodatage, en secondes Unix. Utilisez le [paramètre StartingPositionTimestamp](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-StartingPositionTimestamp) pour spécifier l’horodatage.
L’interrogation des flux lors des mises à jour et de la création du mappage des sources d’événements est finalement cohérente :
+ Lors de la création du mappage des sources d’événements, le démarrage de l’interrogation des événements depuis le flux peut prendre plusieurs minutes.
+ Lors des mises à jour du mappage des sources d’événements, l’arrêt et le redémarrage de l’interrogation des événements depuis le flux peuvent prendre jusqu’à 90 secondes.
Ce comportement signifie que si vous spécifiez `LATEST` comme position de départ du flux, le mappage des sources d’événements peut manquer des événements lors d’une création ou d’une mise à jour. Pour vous assurer qu’aucun événement n’est manqué, spécifiez `TRIM_HORIZON` ou `AT_TIMESTAMP`.
# ID de groupe de consommateurs personnalisable dans Lambda
Lorsque vous configurez Amazon MSK ou Apache Kafka autogéré comme source d’événements, vous pouvez spécifier un ID de [groupe de consommateurs](https://developer.confluent.io/learn-more/kafka-on-the-go/consumer-groups/). Cet identifiant de groupe de consommateurs est un identifiant existant pour le groupe de clients Kafka auquel vous souhaitez rattacher votre fonction Lambda. Vous pouvez utiliser cette fonction pour migrer facilement toutes les configurations de traitement d’enregistrements Kafka en cours depuis d’autres clients vers Lambda.
Kafka distribue les messages à tous les consommateurs d’un groupe de consommateurs. Si vous spécifiez un ID de groupe de consommateurs qui compte d’autres consommateurs actifs, Lambda ne reçoit qu’une partie des messages de la rubrique Kafka. Si vous souhaitez que Lambda gère tous les messages de la rubrique, désactivez tous les autres consommateurs de ce groupe de consommateurs.
De plus, si vous spécifiez un ID de groupe de consommateurs et que Kafka trouve un groupe de consommateurs existant valide avec le même ID, Lambda ignore le paramètre [StartingPosition](kafka-starting-positions.md) pour le mappage des sources d’événements. Lambda commence plutôt à traiter les enregistrements en fonction de la compensation engagée par le groupe de consommateurs. Si vous spécifiez un identifiant de groupe de consommateurs et que Kafka ne trouve aucun groupe de consommateurs existant, Lambda configure votre source d’événement avec le spécifié `StartingPosition`.
L’identifiant du groupe de consommateurs que vous spécifiez doit être unique parmi toutes vos sources d’événements Kafka. Après avoir créé un mappage des sources d’événements Kafka avec l’identifiant de groupe de consommateurs spécifié, vous ne pouvez plus mettre à jour cette valeur.
# Filtrage des événements provenant d’Amazon MSK et sources d’événements Apache Kafka autogéré
Vous pouvez utiliser le filtrage d’événements pour contrôler les enregistrements d’un flux ou d’une file d’attente que Lambda envoie à votre fonction. Pour obtenir des informations générales sur le fonctionnement du filtrage des événements, consultez [Contrôle des événements envoyés par Lambda à votre fonction](invocation-eventfiltering.md).
**Note**
Les mappages Amazon MSK et Apache Kafka autogéré ne prennent en charge que le filtrage sur la clé `value`.
**Topics**
+ [Notions de base du filtrage d’événements Lambda](#filtering-kafka)
## Notions de base du filtrage d’événements Lambda
Supposons qu’un producteur écrive des messages à une rubrique de votre cluster Kafka, au format JSON valide ou sous forme de chaînes simples. Un exemple d’enregistrement ressemblerait à ce qui suit, avec le message converti en chaîne encodée en Base64 dans le champ `value`.
```
{
"mytopic-0":[
{
"topic":"mytopic",
"partition":0,
"offset":15,
"timestamp":1545084650987,
"timestampType":"CREATE_TIME",
"value":"SGVsbG8sIHRoaXMgaXMgYSB0ZXN0Lg==",
"headers":[]
}
]
}
```
Supposons que votre producteur Apache Kafka écrive des messages dans votre rubrique au format JSON suivant.
```
{
"device_ID": "AB1234",
"session":{
"start_time": "yyyy-mm-ddThh:mm:ss",
"duration": 162
}
}
```
Vous pouvez utiliser la clé `value` pour filtrer les enregistrements. Supposons que vous vouliez filtrer uniquement les enregistrements où `device_ID` commence par les lettres AB. L’objet `FilterCriteria` serait le suivant.
```
{
"Filters": [
{
"Pattern": "{ \"value\" : { \"device_ID\" : [ { \"prefix\": \"AB\" } ] } }"
}
]
}
```
Pour plus de clarté, voici la valeur du `Pattern` de filtre étendu en JSON simple :
```
{
"value": {
"device_ID": [ { "prefix": "AB" } ]
}
}
```
Vous pouvez ajouter votre filtre à l’aide de la console, d’AWS CLI ou d’un modèle AWS SAM.
------
#### [ Console ]
Pour ajouter ce filtre à l’aide de la console, suivez les instructions de [Attacher des critères de filtre à un mappage de sources d’événements (console)](invocation-eventfiltering.md#filtering-console) et saisissez la chaîne suivante comme **critère de filtre**.
```
{ "value" : { "device_ID" : [ { "prefix": "AB" } ] } }
```
------
#### [ AWS CLI ]
Pour créer un nouveau mappage des sources d’événements avec ces critères de filtrage à l’aide de l’outil AWS Command Line Interface (AWS CLI), exécutez la commande suivante.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:kafka:us-east-2:123456789012:cluster/my-cluster/b-8ac7cc01-5898-482d-be2f-a6b596050ea8 \
--filter-criteria '{"Filters": [{"Pattern": "{ \"value\" : { \"device_ID\" : [ { \"prefix\": \"AB\" } ] } }"}]}'
```
Pour ajouter ces critères de filtre à un mappage des sources d’événements existant, exécutez la commande suivante.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"value\" : { \"device_ID\" : [ { \"prefix\": \"AB\" } ] } }"}]}'
```
------
#### [ AWS SAM ]
Pour ajouter ce filtre à l’aide d’AWS SAM, ajoutez l’extrait suivant au modèle YAML de votre source d’événement.
```
FilterCriteria:
Filters:
- Pattern: '{ "value" : { "device_ID" : [ { "prefix": "AB" } ] } }'
```
------
Avec Kafka, vous pouvez également filtrer les enregistrements dont le message est une chaîne simple. Supposons que vous vouliez ignorer les messages dont la chaîne est « error ». L’objet `FilterCriteria` se présente comme suit.
```
{
"Filters": [
{
"Pattern": "{ \"value\" : [ { \"anything-but\": [ \"error\" ] } ] }"
}
]
}
```
Pour plus de clarté, voici la valeur du `Pattern` de filtre étendu en JSON simple :
```
{
"value": [
{
"anything-but": [ "error" ]
}
]
}
```
Vous pouvez ajouter votre filtre à l’aide de la console, d’AWS CLI ou d’un modèle AWS SAM.
------
#### [ Console ]
Pour ajouter ce filtre à l’aide de la console, suivez les instructions de [Attacher des critères de filtre à un mappage de sources d’événements (console)](invocation-eventfiltering.md#filtering-console) et saisissez la chaîne suivante comme **critère de filtre**.
```
{ "value" : [ { "anything-but": [ "error" ] } ] }
```
------
#### [ AWS CLI ]
Pour créer un nouveau mappage des sources d’événements avec ces critères de filtrage à l’aide de l’outil AWS Command Line Interface (AWS CLI), exécutez la commande suivante.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:kafka:us-east-2:123456789012:cluster/my-cluster/b-8ac7cc01-5898-482d-be2f-a6b596050ea8 \
--filter-criteria '{"Filters": [{"Pattern": "{ \"value\" : [ { \"anything-but\": [ \"error\" ] } ] }"}]}'
```
Pour ajouter ces critères de filtre à un mappage des sources d’événements existant, exécutez la commande suivante.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"value\" : [ { \"anything-but\": [ \"error\" ] } ] }"}]}'
```
------
#### [ AWS SAM ]
Pour ajouter ce filtre à l’aide d’AWS SAM, ajoutez l’extrait suivant au modèle YAML de votre source d’événement.
```
FilterCriteria:
Filters:
- Pattern: '{ "value" : [ { "anything-but": [ "error" ] } ] }'
```
------
Les messages Kafka doivent être des chaînes codées en UTF-8, soit des chaînes en texte brut, soit au format JSON. En effet, Lambda décode les tableaux d’octets Kafka en UTF-8 avant d’appliquer des critères de filtre. Si vos messages utilisent un autre encodage, tel que UTF-16 ou ASCII, ou si le format du message ne correspond pas au format `FilterCriteria`, Lambda traite uniquement les filtres de métadonnées. Le tableau suivant résume le comportement spécifique :
| Format du du message entrant | Modèle de filtre de format pour les propriétés des messages | Action obtenue. |
| --- | --- | --- |
| Chaîne de texte brut | Chaîne de texte brut | Lambda filtre en fonction de vos critères de filtre. |
| Chaîne de texte brut | Pas de modèle de filtre pour les propriétés des données | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
| Chaîne de texte brut | JSON valide | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
| JSON valide | Chaîne de texte brut | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
| JSON valide | Pas de modèle de filtre pour les propriétés des données | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
| JSON valide | JSON valide | Lambda filtre en fonction de vos critères de filtre. |
| Chaîne non codée UTF-8 | JSON, chaîne de texte brut ou aucun modèle | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
# Utilisation de registres de schémas avec les sources d’événements Kafka dans Lambda
Les registres de schémas vous aident à définir et gérer des schémas de flux de données. Un schéma définit la structure et le format d'un enregistrement de données. Dans le contexte des mappages des sources d’événements Kafka, vous pouvez configurer un registre de schémas pour valider la structure et le format des messages Kafka par rapport à des schémas prédéfinis avant qu’ils atteignent votre fonction Lambda. Cela ajoute une couche de gouvernance des données à votre application et vous permet de gérer efficacement les formats de données, de garantir la conformité des schémas et d’optimiser les coûts grâce au filtrage des événements.
Cette fonctionnalité est compatible avec tous les langages de programmation, mais tenez compte des points importants suivants :
+ Powertools for Lambda fournit un support spécifique pour Java, Python TypeScript et assure la cohérence avec les modèles de développement Kafka existants et permet un accès direct aux objets métier sans code de désérialisation personnalisé.
+ Cette fonctionnalité n’est disponible que pour les mappages des sources d’événements utilisant le mode provisionné. Le registre des schémas ne prend pas en charge les mappages des sources d’événements en mode à la demande. Si vous utilisez le mode provisionné et qu’un registre de schéma est configuré, vous ne pouvez pas passer en mode à la demande, sauf si vous supprimez d’abord la configuration de votre registre de schémas. Pour de plus amples informations, consultez [Mode alloué](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode).
+ Vous ne pouvez configurer qu’un seul registre de schémas par mappage des sources d’événements (ESM). L’utilisation d’un registre de schémas avec votre source d’événements Kafka peut augmenter votre utilisation d’unités de sondeur d’événements (EPU) Lambda, une dimension tarifaire pour le mode provisionné.
**Topics**
+ [Options du registre de schémas](#services-consume-kafka-events-options)
+ [Comment Lambda effectue la validation du schéma pour les messages Kafka](#services-consume-kafka-events-how)
+ [Configuration d’un registre de schémas Kafka](#services-consume-kafka-events-config)
+ [Filtrage pour Avro et Protobuf](#services-consume-kafka-events-filtering)
+ [Formats de données utiles et comportement de désérialisation](#services-consume-kafka-events-payload)
+ [Utilisation de données désérialisées dans des fonctions Lambda](#services-consume-kafka-events-payload-examples)
+ [Méthodes d’authentification pour votre registre de schémas](#services-consume-kafka-events-auth)
+ [Gestion des erreurs et résolution des problèmes liés au registre de schémas](#services-consume-kafka-events-troubleshooting)
## Options du registre de schémas
Lambda prend en charge les options de registre de schémas suivantes :
+ [AWS Glue Registre de schémas](https://docs.aws.amazon.com/glue/latest/dg/schema-registry.html)
+ [Registre de schémas Confluent Cloud](https://docs.confluent.io/platform/current/schema-registry/index.html)
+ [Registre de schémas Confluent autogéré](https://docs.confluent.io/platform/current/schema-registry/index.html)
Votre registre de schémas prend en charge la validation des messages dans les formats de données suivants :
+ Apache Avro
+ Protocol Buffers (Protobuf)
+ Schéma JSON (JSON-SE)
Pour utiliser un registre de schémas, assurez-vous d’abord que votre mappage des sources d’événements est en mode provisionné. Lorsque vous utilisez un registre de schémas, Lambda ajoute des métadonnées relatives au schéma aux données utiles. Pour plus d’informations, consultez [Formats de données utiles et comportement de désérialisation](#services-consume-kafka-events-payload).
## Comment Lambda effectue la validation du schéma pour les messages Kafka
Lorsque vous configurez un registre de schémas, Lambda exécute les étapes suivantes pour chaque message Kafka :
1. Lambda interroge l’enregistrement Kafka de votre cluster.
1. Lambda valide les attributs de message sélectionnés dans l’enregistrement par rapport à un schéma spécifique de votre registre de schémas.
+ Si le schéma associé au message n’est pas trouvé dans le registre, Lambda envoie le message à une DLQ avec le code de motif `SCHEMA_NOT_FOUND`.
1. Lambda désérialise le message conformément à la configuration du registre de schémas pour valider le message. Si le filtrage des événements est configuré, Lambda effectue ensuite le filtrage en fonction des critères de filtre configurés.
+ Si la désérialisation échoue, Lambda envoie le message à une DLQ avec le code de motif `DESERIALIZATION_ERROR`. Si aucune DLQ n’est configurée, Lambda abandonne le message.
1. Si le message est validé par le registre de schémas et qu’il n’est pas filtré selon vos critères de filtre, Lambda invoque votre fonction avec le message.
Cette fonctionnalité est destinée à valider les messages déjà produits à l’aide de clients Kafka intégrés à un registre de schémas. Nous vous recommandons de configurer vos producteurs Kafka pour qu’ils fonctionnent avec votre registre de schémas afin de créer des messages correctement formatés.
## Configuration d’un registre de schémas Kafka
Les étapes de console suivantes ajoutent une configuration de registre de schémas Kafka à votre mappage des sources d’événements.
**Ajouter une configuration de registre de schémas Kafka à votre mappage des sources d’événements (console)**
1. Ouvrez la [page Fonction](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda.
1. Choisissez **Configuration**.
1. Choisissez **Déclencheurs**.
1. Sélectionnez le mappage des sources d’événements Kafka pour lequel vous souhaitez configurer un registre de schémas, puis choisissez **Modifier**.
1. Sous **Configuration du sondeur d’événements**, choisissez **Configurer le registre de schémas**. Votre mappage des sources d’événements doit être en mode provisionné pour voir cette option.
1. Pour l'**URI du registre de schéma**, entrez l'ARN de votre registre de AWS Glue schémas ou l'URL HTTPS de votre registre de schémas Confluent Cloud ou de votre registre de schémas Confluent autogéré.
1. Les étapes de configuration suivantes indiquent à Lambda comment accéder à votre registre de schémas. Pour de plus amples informations, veuillez consulter [Méthodes d’authentification pour votre registre de schémas](#services-consume-kafka-events-auth).
+ Pour **Type de configuration d’accès**, choisissez le type d’authentification utilisé par Lambda pour accéder à votre registre de schémas.
+ Pour **URI de configuration d’accès**, entrez l’ARN du secret Secrets Manager pour vous authentifier auprès de votre registre de schémas, le cas échéant. Assurez-vous que le [rôle d’exécution](with-msk-permissions.md) de votre fonction contient les autorisations appropriées.
1. Le champ **Chiffrement** s’applique uniquement si votre registre de schémas est signé par une autorité de certification (CA) privée ou une autorité de certification (CA) qui ne figure pas dans le magasin d’approbations Lambda. Le cas échéant, fournissez la clé secrète contenant le certificat CA privé utilisé par votre registre de schémas pour le chiffrement TLS.
1. Pour **Format d’enregistrement de l’événement**, choisissez la manière dont vous souhaitez que Lambda transmette les enregistrements à votre fonction après la validation du schéma. Pour plus d’informations consultez [Exemples de formats de données utiles](#services-consume-kafka-events-payload).
+ Si vous choisissez **JSON**, Lambda fournit les attributs que vous sélectionnez dans Attribut de validation du schéma ci-dessous au format JSON standard. Pour les attributs que vous ne sélectionnez pas, Lambda les fournit en l’état.
+ Si vous choisissez **SOURCE**, Lambda fournit les attributs que vous avez sélectionnés dans Attribut de validation du schéma ci-dessous dans leur format source d’origine.
1. Pour **Attribut de validation du schéma**, sélectionnez les attributs de message que Lambda doit valider et désérialiser à l’aide de votre registre de schémas. Vous devez sélectionner au moins une option entre **KEY** et **VALUE**. Si vous avez choisi JSON pour le format d’enregistrement d’événement, Lambda désérialise également les attributs de message sélectionnés avant de les envoyer à votre fonction. Pour plus d’informations, consultez [Formats de données utiles et comportement de désérialisation](#services-consume-kafka-events-payload).
1. Choisissez **Enregistrer**.
Vous pouvez également utiliser l’API Lambda pour créer ou mettre à jour votre mappage des sources d’événements avec une configuration de registre de schémas. Les exemples suivants montrent comment configurer un registre de schéma AWS Glue ou un registre de schéma Confluent à l'aide du AWS CLI, qui correspond aux opérations d'[CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)API [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)et de la *référence AWS Lambda d'API :*
**Important**
Si vous mettez à jour un champ de configuration du registre de schéma à l'aide de l'`update-event-source-mapping`API AWS CLI ou de l'API, vous devez mettre à jour tous les champs de configuration du registre de schéma.
------
#### [ Create Event Source Mapping ]
```
aws lambda create-event-source-mapping \
--function-name my-schema-validator-function \
--event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/my-cluster/a1b2c3d4-5678-90ab-cdef-11111EXAMPLE \
--topics my-kafka-topic \
--provisioned-poller-config MinimumPollers=1,MaximumPollers=1 \
--amazon-managed-kafka-event-source-mapping '{
"SchemaRegistryConfig" : {
"SchemaRegistryURI": "https://abcd-ef123.us-west-2.aws.confluent.cloud",
"AccessConfigs": [{
"Type": "BASIC_AUTH",
"URI": "arn:aws:secretsmanager:us-east-1:123456789012:secret:secretName"
}],
"EventRecordFormat": "JSON",
"SchemaValidationConfigs": [
{
"Attribute": "KEY"
},
{
"Attribute": "VALUE"
}]
}
}'
```
------
#### [ Update AWS Glue Schema Registry ]
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--amazon-managed-kafka-event-source-mapping '{
"SchemaRegistryConfig" : {
"SchemaRegistryURI": "arn:aws:glue:us-east-1:123456789012:registry/registryName",
"EventRecordFormat": "JSON",
"SchemaValidationConfigs": [
{
"Attribute": "KEY"
},
{
"Attribute": "VALUE"
}]
}
}'
```
------
#### [ Update Confluent Schema Registry with Authentication ]
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--amazon-managed-kafka-event-source-mapping '{
"SchemaRegistryConfig" : {
"SchemaRegistryURI": "https://abcd-ef123.us-west-2.aws.confluent.cloud",
"AccessConfigs": [{
"Type": "BASIC_AUTH",
"URI": "arn:aws:secretsmanager:us-east-1:123456789012:secret:secretName"
}],
"EventRecordFormat": "JSON",
"SchemaValidationConfigs": [
{
"Attribute": "KEY"
},
{
"Attribute": "VALUE"
}]
}
}'
```
------
#### [ Update Confluent Schema Registry without Authentication ]
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--amazon-managed-kafka-event-source-mapping '{
"SchemaRegistryConfig" : {
"SchemaRegistryURI": "https://abcd-ef123.us-west-2.aws.confluent.cloud",
"EventRecordFormat": "JSON",
"SchemaValidationConfigs": [
{
"Attribute": "KEY"
},
{
"Attribute": "VALUE"
}]
}
}'
```
------
#### [ Remove Schema Registry Configuration ]
Pour supprimer une configuration de registre de schéma de votre mappage de source d'événements, vous pouvez utiliser la commande CLI [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)dans la *référence AWS Lambda d'API*.
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--amazon-managed-kafka-event-source-mapping '{
"SchemaRegistryConfig" : {}
}'
```
------
## Filtrage pour Avro et Protobuf
Lorsque vous utilisez les formats Avro ou Protobuf avec un registre de schémas, vous pouvez appliquer le filtrage des événements à votre fonction Lambda. Les modèles de filtre sont appliqués à la représentation JSON classique désérialisée de vos données après validation du schéma. Par exemple, avec un schéma Avro définissant les détails du produit, y compris le prix, vous pouvez filtrer les messages en fonction de la valeur du prix :
**Note**
Lors de la désérialisation, l’objet Avro est converti en JSON standard, ce qui signifie qu’il ne peut pas être reconverti directement en objet Avro. Si vous devez effectuer une conversion en objet Avro, utilisez plutôt le format SOURCE.
Pour la désérialisation de Protobuf, les noms de champs dans le JSON obtenu correspondent à ceux définis dans votre schéma, plutôt que d’être convertis en casse mixte comme le fait généralement Protobuf. Gardez cela à l’esprit lorsque vous créez des schémas de filtrage.
```
aws lambda create-event-source-mapping \
--function-name myAvroFunction \
--topics myAvroTopic \
--starting-position TRIM_HORIZON \
--kafka-bootstrap-servers '["broker1:9092", "broker2:9092"]' \
--schema-registry-config '{
"SchemaRegistryURI": "arn:aws:glue:us-east-1:123456789012:registry/myAvroRegistry",
"EventRecordFormat": "JSON",
"SchemaValidationConfigs": [
{
"Attribute": "VALUE"
}
]
}' \
--filter-criteria '{
"Filters": [
{
"Pattern": "{ \"value\" : { \"field_1\" : [\"value1\"], \"field_2\" : [\"value2\"] } }"
}
]
}'
```
Dans cet exemple, le modèle de filtre analyse l’objet `value` en faisant correspondre les messages dans `field_1` avec `"value1"`, et `field_2` avec `"value2"`. Les critères de filtre sont évalués par rapport aux données désérialisées, une fois que Lambda a converti le message du format Avro en JSON.
Pour plus d’informations sur le filtrage des événements, consultez la section [Filtrage des événements Lambda](invocation-eventfiltering.md).
## Formats de données utiles et comportement de désérialisation
Lorsque vous utilisez un registre de schémas, Lambda fournit les données utiles finales à votre fonction dans un format similaire aux [données utiles d’événement ordinaires](with-msk.md#msk-sample-event), avec quelques champs supplémentaires. Les champs supplémentaires dépendent du paramètre `SchemaValidationConfigs`. Pour chaque attribut que vous sélectionnez pour validation (clé ou valeur), Lambda ajoute les métadonnées de schéma correspondantes aux données utiles.
**Note**
Vous devez passer [aws-lambda-java-events](https://github.com/aws/aws-lambda-java-libs/tree/main/aws-lambda-java-events)à la version 3.16.0 ou supérieure pour utiliser les champs de métadonnées du schéma.
Par exemple, si vous validez le champ `value`, Lambda ajoute un champ appelé `valueSchemaMetadata` à vos données utiles. De même, pour le champ `key`, Lambda ajoute un champ appelé `keySchemaMetadata`. Ces métadonnées contiennent des informations sur le format des données et l’ID de schéma utilisés pour la validation :
```
"valueSchemaMetadata": {
"dataFormat": "AVRO",
"schemaId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
```
Le paramètre `EventRecordFormat` peut être défini sur `JSON` ou `SOURCE`, ce qui détermine la manière dont Lambda gère les données validées par le schéma avant de les transmettre à votre fonction. Chaque option offre des capacités de traitement différentes :
+ `JSON` : Lambda désérialise les attributs validés au format JSON standard, ce qui rend les données prêtes à être utilisées directement dans les langages prenant en charge le format JSON natif. Ce format est idéal lorsque vous n’avez pas besoin de conserver le format binaire d’origine ou de travailler avec les classes générées.
+ `SOURCE` : Lambda préserve le format binaire original des données sous forme de chaîne codée en Base64, ce qui permet une conversion directe en objets Avro ou Protobuf. Ce format est essentiel lorsque vous travaillez avec des langages fortement typés ou lorsque vous devez conserver toutes les fonctionnalités des schémas Avro ou Protobuf.
Sur la base de ces caractéristiques de format et des considérations spécifiques au langage, nous recommandons les formats suivants :
**Formats recommandés selon le langage de programmation**
| Language | Avro | Protobuf | JSON |
| --- | --- | --- | --- |
| Java | SOURCE | SOURCE | SOURCE |
| Python | JSON | JSON | JSON |
| NodeJS | JSON | JSON | JSON |
| .NET | SOURCE | SOURCE | SOURCE |
| Autres | JSON | JSON | JSON |
Les sections suivantes décrivent ces formats en détail et fournissent des exemples de données utiles pour chaque format.
### Format JSON
Si vous choisissez `JSON` comme tel`EventRecordFormat`, Lambda valide et désérialise les attributs de message que vous avez sélectionnés dans le `SchemaValidationConfigs` champ (les attributs). `key` and/or `value` Lambda fournit ces attributs sélectionnés sous forme de chaînes codées en Base64 de leur représentation JSON standard dans votre fonction.
**Note**
Lors de la désérialisation, l’objet Avro est converti en JSON standard, ce qui signifie qu’il ne peut pas être reconverti directement en objet Avro. Si vous devez effectuer une conversion en objet Avro, utilisez plutôt le format SOURCE.
Pour la désérialisation de Protobuf, les noms de champs dans le JSON obtenu correspondent à ceux définis dans votre schéma, plutôt que d’être convertis en casse mixte comme le fait généralement Protobuf. Gardez cela à l’esprit lorsque vous créez des schémas de filtrage.
Voici un exemple de données utiles, en supposant que vous choisissez `JSON` comme `EventRecordFormat` et les attributs `key` et `value` comme `SchemaValidationConfigs` :
```
{
"eventSource":"aws:kafka",
"eventSourceArn":"arn:aws:kafka:us-east-1:123456789012:cluster/vpc-2priv-2pub/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111-1",
"bootstrapServers":"b-2.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092,b-1.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092",
"records":{
"mytopic-0":[
{
"topic":"mytopic",
"partition":0,
"offset":15,
"timestamp":1545084650987,
"timestampType":"CREATE_TIME",
"key":"abcDEFghiJKLmnoPQRstuVWXyz1234==", //Base64 encoded string of JSON
"keySchemaMetadata": {
"dataFormat": "AVRO",
"schemaId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"value":"abcDEFghiJKLmnoPQRstuVWXyz1234", //Base64 encoded string of JSON
"valueSchemaMetadata": {
"dataFormat": "AVRO",
"schemaId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"headers":[
{
"headerKey":[
104,
101,
97,
100,
101,
114,
86,
97,
108,
117,
101
]
}
]
}
]
}
}
```
Dans cet exemple :
+ `key` et `value` sont des chaînes codées en Base64 de leur représentation JSON après désérialisation.
+ Lambda inclut des métadonnées de schéma pour les deux attributs dans `keySchemaMetadata` et `valueSchemaMetadata`.
+ Votre fonction peut décoder les chaînes `key` et `value` pour accéder aux données JSON désérialisées.
Le format JSON est recommandé pour les langages qui ne sont pas fortement typés, comme Python ou Node.js. Ces langages offrent la prise en charge native de la conversion de JSON en objets.
### Format source
Si vous choisissez `SOURCE` comme `EventRecordFormat`, Lambda valide toujours l’enregistrement par rapport au registre de schémas, mais fournit les données binaires d’origine à votre fonction sans désérialisation. Ces données binaires sont fournies sous la forme d’une chaîne codée en Base64 des données d’octets d’origine, les métadonnées ajoutées par le producteur étant supprimées. Par conséquent, vous pouvez directement convertir les données binaires brutes en objets Avro et Protobuf dans le code de votre fonction. Nous vous recommandons d'utiliser Powertools for AWS Lambda, qui désérialisera les données binaires brutes et vous fournira directement les objets Avro et Protobuf.
Par exemple, si vous configurez Lambda pour valider à la fois les attributs `key` et `value`, mais que vous utilisez le format `SOURCE`, votre fonction reçoit des données utiles semblables à celles-ci :
```
{
"eventSource": "aws:kafka",
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/vpc-2priv-2pub/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111-1",
"bootstrapServers": "b-2.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092,b-1.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092",
"records": {
"mytopic-0": [
{
"topic": "mytopic",
"partition": 0,
"offset": 15,
"timestamp": 1545084650987,
"timestampType": "CREATE_TIME",
"key": "abcDEFghiJKLmnoPQRstuVWXyz1234==", // Base64 encoded string of Original byte data, producer-appended metadata removed
"keySchemaMetadata": {
"dataFormat": "AVRO",
"schemaId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"value": "abcDEFghiJKLmnoPQRstuVWXyz1234==", // Base64 encoded string of Original byte data, producer-appended metadata removed
"valueSchemaMetadata": {
"dataFormat": "AVRO",
"schemaId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"headers": [
{
"headerKey": [
104,
101,
97,
100,
101,
114,
86,
97,
108,
117,
101
]
}
]
}
]
}
}
```
Dans cet exemple :
+ `key` et `value` contiennent tous deux les données binaires d’origine sous forme de chaînes codées en Base64.
+ Votre fonction doit gérer la désérialisation à l’aide des bibliothèques appropriées.
Il est recommandé de choisir `SOURCE` pour `EventRecordFormat` si vous utilisez des objets générés par Avro ou Protobuf, en particulier avec des fonctions Java. Cela est dû au fait que Java est fortement typé et nécessite des désérialiseurs spécifiques pour les formats Avro et Protobuf. Dans le code de votre fonction, vous pouvez utiliser votre bibliothèque Avro ou Protobuf préférée pour désérialiser les données.
## Utilisation de données désérialisées dans des fonctions Lambda
Powertools for vous AWS Lambda aide à désérialiser les enregistrements Kafka dans votre code de fonction en fonction du format que vous utilisez. Cet utilitaire simplifie l'utilisation des enregistrements Kafka en gérant la conversion des données et en fournissant des ready-to-use objets.
Pour utiliser Powertools AWS Lambda dans votre fonction, vous devez ajouter Powertools en tant que couche AWS Lambda ou en tant que dépendance lors de la création de votre fonction Lambda. Pour obtenir des instructions de configuration et plus d'informations, consultez les Powertools pour obtenir AWS Lambda la documentation correspondant à votre langue préférée :
+ [Powertools pour AWS Lambda (Java)](https://docs.powertools.aws.dev/lambda/java/latest/utilities/kafka/)
+ [Powertools pour AWS Lambda (Python)](https://docs.powertools.aws.dev/lambda/python/latest/utilities/kafka/)
+ [Outils électriques pour AWS Lambda () TypeScript](https://docs.powertools.aws.dev/lambda/typescript/latest/features/kafka/)
+ [Powertools pour AWS Lambda (.NET)](https://docs.powertools.aws.dev/lambda/dotnet/utilities/kafka/)
**Note**
Lorsque vous travaillez avec l’intégration du registre de schémas, vous pouvez choisir le format `SOURCE` ou `JSON`. Chaque option prend en charge différents formats de sérialisation, comme indiqué ci-dessous :
| Format | Prend en charge |
| --- | --- |
| SOURCE | Avro et Protobuf (en utilisant l’intégration du registre de schémas Lambda) |
| JSON | Données JSON |
Lorsque vous utilisez le `JSON` format `SOURCE` or, vous pouvez utiliser Powertools pour vous aider AWS à désérialiser les données de votre code de fonction. Voici des exemples de gestion de différents formats de données :
------
#### [ AVRO ]
Exemple Java :
```
package org.demo.kafka;
import org.apache.kafka.clients.consumer.ConsumerRecord;
import org.apache.kafka.clients.consumer.ConsumerRecords;
import org.demo.kafka.avro.AvroProduct;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import software.amazon.lambda.powertools.kafka.Deserialization;
import software.amazon.lambda.powertools.kafka.DeserializationType;
import software.amazon.lambda.powertools.logging.Logging;
public class AvroDeserializationFunction implements RequestHandler, String> {
private static final Logger LOGGER = LoggerFactory.getLogger(AvroDeserializationFunction.class);
@Override
@Logging
@Deserialization(type = DeserializationType.KAFKA_AVRO)
public String handleRequest(ConsumerRecords records, Context context) {
for (ConsumerRecord consumerRecord : records) {
LOGGER.info("ConsumerRecord: {}", consumerRecord);
AvroProduct product = consumerRecord.value();
LOGGER.info("AvroProduct: {}", product);
String key = consumerRecord.key();
LOGGER.info("Key: {}", key);
}
return "OK";
}
}
```
Exemple Python :
```
from aws_lambda_powertools.utilities.kafka_consumer.kafka_consumer import kafka_consumer
from aws_lambda_powertools.utilities.kafka_consumer.schema_config import SchemaConfig
from aws_lambda_powertools.utilities.kafka_consumer.consumer_records import ConsumerRecords
from aws_lambda_powertools.utilities.typing import LambdaContext
from aws_lambda_powertools import Logger
logger = Logger(service="kafkaConsumerPowertools")
value_schema_str = open("customer_profile.avsc", "r").read()
schema_config = SchemaConfig(
value_schema_type="AVRO",
value_schema=value_schema_str)
@kafka_consumer(schema_config=schema_config)
def lambda_handler(event: ConsumerRecords, context:LambdaContext):
for record in event.records:
value = record.value
logger.info(f"Received value: {value}")
```
TypeScript exemple :
```
import { kafkaConsumer } from '@aws-lambda-powertools/kafka';
import type { ConsumerRecords } from '@aws-lambda-powertools/kafka/types';
import { Logger } from '@aws-lambda-powertools/logger';
import type { Context } from 'aws-lambda';
const logger = new Logger();
type Value = {
id: number;
name: string;
price: number;
};
const schema = '{
"type": "record",
"name": "Product",
"fields": [
{ "name": "id", "type": "int" },
{ "name": "name", "type": "string" },
{ "name": "price", "type": "double" }
]
}';
export const handler = kafkaConsumer(
(event: ConsumerRecords, _context: Context) => {
for (const record of event.records) {
logger.info(Processing record with key: ${record.key});
logger.info(Record value: ${JSON.stringify(record.value)});
// You can add more processing logic here
}
},
{
value: {
type: 'avro',
schema: schema,
},
}
);
```
Exemple .NET :
```
using Amazon.Lambda.Core;
using AWS.Lambda.Powertools.Kafka;
using AWS.Lambda.Powertools.Kafka.Avro;
using AWS.Lambda.Powertools.Logging;
using Com.Example;
// Assembly attribute to enable the Lambda function's Kafka event to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(PowertoolsKafkaAvroSerializer))]
namespace ProtoBufClassLibrary;
public class Function
{
public string FunctionHandler(ConsumerRecords records, ILambdaContext context)
{
foreach (var record in records)
{
Logger.LogInformation("Processing messagem from topic: {topic}", record.Topic);
Logger.LogInformation("Partition: {partition}, Offset: {offset}", record.Partition, record.Offset);
Logger.LogInformation("Produced at: {timestamp}", record.Timestamp);
foreach (var header in record.Headers.DecodedValues())
{
Logger.LogInformation($"{header.Key}: {header.Value}");
}
Logger.LogInformation("Processing order for: {fullName}", record.Value.FullName);
}
return "Processed " + records.Count() + " records";
}
}
```
------
#### [ PROTOBUF ]
Exemple Java :
```
package org.demo.kafka;
import org.apache.kafka.clients.consumer.ConsumerRecord;
import org.apache.kafka.clients.consumer.ConsumerRecords;
import org.demo.kafka.protobuf.ProtobufProduct;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import software.amazon.lambda.powertools.kafka.Deserialization;
import software.amazon.lambda.powertools.kafka.DeserializationType;
import software.amazon.lambda.powertools.logging.Logging;
public class ProtobufDeserializationFunction
implements RequestHandler, String> {
private static final Logger LOGGER = LoggerFactory.getLogger(ProtobufDeserializationFunction.class);
@Override
@Logging
@Deserialization(type = DeserializationType.KAFKA_PROTOBUF)
public String handleRequest(ConsumerRecords records, Context context) {
for (ConsumerRecord consumerRecord : records) {
LOGGER.info("ConsumerRecord: {}", consumerRecord);
ProtobufProduct product = consumerRecord.value();
LOGGER.info("ProtobufProduct: {}", product);
String key = consumerRecord.key();
LOGGER.info("Key: {}", key);
}
return "OK";
}
}
```
Exemple Python :
```
from aws_lambda_powertools.utilities.kafka_consumer.kafka_consumer import kafka_consumer
from aws_lambda_powertools.utilities.kafka_consumer.schema_config import SchemaConfig
from aws_lambda_powertools.utilities.kafka_consumer.consumer_records import ConsumerRecords
from aws_lambda_powertools.utilities.typing import LambdaContext
from aws_lambda_powertools import Logger
from user_pb2 import User # protobuf generated class
logger = Logger(service="kafkaConsumerPowertools")
schema_config = SchemaConfig(
value_schema_type="PROTOBUF",
value_schema=User)
@kafka_consumer(schema_config=schema_config)
def lambda_handler(event: ConsumerRecords, context:LambdaContext):
for record in event.records:
value = record.value
logger.info(f"Received value: {value}")
```
TypeScript exemple :
```
import { kafkaConsumer } from '@aws-lambda-powertools/kafka';
import type { ConsumerRecords } from '@aws-lambda-powertools/kafka/types';
import { Logger } from '@aws-lambda-powertools/logger';
import type { Context } from 'aws-lambda';
import { Product } from './product.generated.js';
const logger = new Logger();
type Value = {
id: number;
name: string;
price: number;
};
export const handler = kafkaConsumer(
(event: ConsumerRecords, _context: Context) => {
for (const record of event.records) {
logger.info(Processing record with key: ${record.key});
logger.info(Record value: ${JSON.stringify(record.value)});
}
},
{
value: {
type: 'protobuf',
schema: Product,
},
}
);
```
Exemple .NET :
```
using Amazon.Lambda.Core;
using AWS.Lambda.Powertools.Kafka;
using AWS.Lambda.Powertools.Kafka.Protobuf;
using AWS.Lambda.Powertools.Logging;
using Com.Example;
// Assembly attribute to enable the Lambda function's Kafka event to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(PowertoolsKafkaProtobufSerializer))]
namespace ProtoBufClassLibrary;
public class Function
{
public string FunctionHandler(ConsumerRecords records, ILambdaContext context)
{
foreach (var record in records)
{
Logger.LogInformation("Processing messagem from topic: {topic}", record.Topic);
Logger.LogInformation("Partition: {partition}, Offset: {offset}", record.Partition, record.Offset);
Logger.LogInformation("Produced at: {timestamp}", record.Timestamp);
foreach (var header in record.Headers.DecodedValues())
{
Logger.LogInformation($"{header.Key}: {header.Value}");
}
Logger.LogInformation("Processing order for: {fullName}", record.Value.FullName);
}
return "Processed " + records.Count() + " records";
}
}
```
------
#### [ JSON ]
Exemple Java :
```
package org.demo.kafka;
import org.apache.kafka.clients.consumer.ConsumerRecord;
import org.apache.kafka.clients.consumer.ConsumerRecords;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import software.amazon.lambda.powertools.kafka.Deserialization;
import software.amazon.lambda.powertools.kafka.DeserializationType;
import software.amazon.lambda.powertools.logging.Logging;
public class JsonDeserializationFunction implements RequestHandler, String> {
private static final Logger LOGGER = LoggerFactory.getLogger(JsonDeserializationFunction.class);
@Override
@Logging
@Deserialization(type = DeserializationType.KAFKA_JSON)
public String handleRequest(ConsumerRecords consumerRecords, Context context) {
for (ConsumerRecord consumerRecord : consumerRecords) {
LOGGER.info("ConsumerRecord: {}", consumerRecord);
Product product = consumerRecord.value();
LOGGER.info("Product: {}", product);
String key = consumerRecord.key();
LOGGER.info("Key: {}", key);
}
return "OK";
}
}
```
Exemple Python :
```
from aws_lambda_powertools.utilities.kafka_consumer.kafka_consumer import kafka_consumer
from aws_lambda_powertools.utilities.kafka_consumer.schema_config import SchemaConfig
from aws_lambda_powertools.utilities.kafka_consumer.consumer_records import ConsumerRecords
from aws_lambda_powertools.utilities.typing import LambdaContext
from aws_lambda_powertools import Logger
logger = Logger(service="kafkaConsumerPowertools")
schema_config = SchemaConfig(value_schema_type="JSON")
@kafka_consumer(schema_config=schema_config)
def lambda_handler(event: ConsumerRecords, context:LambdaContext):
for record in event.records:
value = record.value
logger.info(f"Received value: {value}")
```
TypeScript exemple :
```
import { kafkaConsumer } from '@aws-lambda-powertools/kafka';
import type { ConsumerRecords } from '@aws-lambda-powertools/kafka/types';
import { Logger } from '@aws-lambda-powertools/logger';
import type { Context } from 'aws-lambda';
const logger = new Logger();
type Value = {
id: number;
name: string;
price: number;
};
export const handler = kafkaConsumer(
(event: ConsumerRecords, _context: Context) => {
for (const record of event.records) {
logger.info(Processing record with key: ${record.key});
logger.info(Record value: ${JSON.stringify(record.value)});
// You can add more processing logic here
}
},
{
value: {
type: 'json',
},
}
);
```
Exemple .NET :
```
using Amazon.Lambda.Core;
using AWS.Lambda.Powertools.Kafka;
using AWS.Lambda.Powertools.Kafka.Json;
using AWS.Lambda.Powertools.Logging;
using Com.Example;
// Assembly attribute to enable the Lambda function's Kafka event to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(PowertoolsKafkaJsonSerializer))]
namespace JsonClassLibrary;
public class Function
{
public string FunctionHandler(ConsumerRecords records, ILambdaContext context)
{
foreach (var record in records)
{
Logger.LogInformation("Processing messagem from topic: {topic}", record.Topic);
Logger.LogInformation("Partition: {partition}, Offset: {offset}", record.Partition, record.Offset);
Logger.LogInformation("Produced at: {timestamp}", record.Timestamp);
foreach (var header in record.Headers.DecodedValues())
{
Logger.LogInformation($"{header.Key}: {header.Value}");
}
Logger.LogInformation("Processing order for: {fullName}", record.Value.FullName);
}
return "Processed " + records.Count() + " records";
}
}
```
------
## Méthodes d’authentification pour votre registre de schémas
Pour utiliser un registre de schémas, Lambda doit pouvoir y accéder de façon sécurisée. Si vous travaillez avec un registre de AWS Glue schémas, Lambda s'appuie sur l'authentification IAM. Cela signifie que le [rôle d'exécution](lambda-intro-execution-role.md) de votre fonction doit disposer des autorisations suivantes pour accéder au AWS Glue registre :
+ [GetRegistry](https://docs.aws.amazon.com/glue/latest/webapi/API_GetRegistry.html)dans la *référence de l'API AWS Glue Web*
+ [GetSchemaVersion](https://docs.aws.amazon.com/glue/latest/webapi/API_GetSchemaVersion.html)dans la *référence de l'API AWS Glue Web*
Exemple de politique IAM requise :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetRegistry",
"glue:GetSchemaVersion"
],
"Resource": [
"*"
]
}
]
}
```
------
**Note**
Pour les registres de AWS Glue schémas, si vous fournissez `AccessConfigs` un AWS Glue registre, Lambda renverra une exception de validation.
Si vous travaillez avec un registre de schémas Confluent, vous pouvez choisir l'une des trois méthodes d'authentification prises en charge pour le `Type` paramètre de votre [KafkaSchemaRegistryAccessConfig](https://docs.aws.amazon.com/lambda/latest/api/API_KafkaSchemaRegistryAccessConfig)objet :
+ **BASIC\$1AUTH** : Lambda utilise le nom d’utilisateur et le mot de passe ou l’authentification par clé d’API et secret d’API pour accéder à votre registre. Si vous choisissez cette option, indiquez l’ARN Secrets Manager contenant vos informations d’identification dans le champ URI.
+ **CLIENT\$1CERTIFICATE\$1TLS\$1AUTH** : Lambda utilise l’authentification TLS mutuelle avec les certificats clients. Pour utiliser cette option, Lambda doit avoir accès à la fois au certificat et à la clé privée. Indiquez l’ARN Secrets Manager contenant ces informations d’identification dans le champ URI.
+ **NO\$1AUTH** : le certificat CA public doit être signé par une autorité de certification située dans le magasin d’approbations Lambda. Pour un certificat CA/autosigné privé, vous configurez le certificat CA racine du serveur. Pour utiliser cette option, omettez le paramètre `AccessConfigs`.
En outre, si Lambda a besoin d’accéder à un certificat CA privé pour vérifier le certificat TLS de votre registre de schémas, choisissez `SERVER_ROOT_CA_CERT` comme `Type` et fournissez l’ARN Secrets Manager au certificat dans le champ URI.
**Note**
Pour configurer l’option `SERVER_ROOT_CA_CERT` dans la console, fournissez l’ARN secret contenant le certificat dans le champ **Chiffrement**.
La configuration d’authentification de votre registre de schémas est distincte de toute authentification que vous avez configurée pour votre cluster Kafka. Vous devez configurer les deux séparément, même s’ils utilisent des méthodes d’authentification similaires.
## Gestion des erreurs et résolution des problèmes liés au registre de schémas
Lorsque vous utilisez un registre de schémas avec votre source d’événements Amazon MSK, vous pouvez rencontrer diverses erreurs. Cette section fournit des conseils sur les problèmes courants et leur résolution.
### Erreurs de configuration
Ces erreurs se produisent lors de la configuration de votre registre de schémas.
Mode provisionné requis
**Message d’erreur** : `SchemaRegistryConfig is only available for Provisioned Mode. To configure Schema Registry, please enable Provisioned Mode by specifying MinimumPollers in ProvisionedPollerConfig.`
**Résolution :** activez le mode provisionné pour votre mappage des sources d'événements en configurant le paramètre `MinimumPollers` dans `ProvisionedPollerConfig`.
URL de registre de schémas non valide
**Message d’erreur** : `Malformed SchemaRegistryURI provided. Please provide a valid URI or ARN. For example, https://schema-registry.example.com:8081 or arn:aws:glue:us-east-1:123456789012:registry/ExampleRegistry.`
**Solution :** Fournissez une URL HTTPS valide pour le registre des schémas Confluent ou un ARN valide pour le registre des AWS Glue schémas.
Format d’enregistrement d’événement non valide ou manquant
**Message d’erreur** : `EventRecordFormat is a required field for SchemaRegistryConfig. Please provide one of supported format types: SOURCE, JSON.`
**Résolution :** Spécifiez SOURCE ou JSON EventRecordFormat dans la configuration de votre registre de schéma.
Attributs de validation en double
**Message d’erreur** : `Duplicate KEY/VALUE Attribute in SchemaValidationConfigs. SchemaValidationConfigs must contain at most one KEY/VALUE Attribute.`
**Résolution :** Supprimez les attributs KEY ou VALUE dupliqués de votre SchemaValidationConfigs. Chaque type d’attribut ne peut apparaître qu’une seule fois.
Configuration de validation manquante
**Message d’erreur** : `SchemaValidationConfigs is a required field for SchemaRegistryConfig.`
**Solution :** Ajoutez SchemaValidationConfigs à votre configuration en spécifiant au moins un attribut de validation (KEY ou VALUE).
### Erreurs d’accès et d’autorisation
Ces erreurs se produisent lorsque Lambda ne peut pas accéder au registre de schémas en raison de problèmes d’autorisation ou d’authentification.
AWS Glue Accès au registre du schéma refusé
**Message d’erreur** : `Cannot access Glue Schema with provided role. Please ensure the provided role can perform the GetRegistry and GetSchemaVersion Actions on your schema.`
**Résolution :** ajoutez les autorisations requises (`glue:GetRegistry` et `glue:GetSchemaVersion`) au rôle d’exécution de votre fonction.
Accès au registre de schémas Confluent refusé
**Message d’erreur** : `Cannot access Confluent Schema with the provided access configuration.`
**Solution :** vérifiez que vos informations d’authentification (stockées dans Secrets Manager) sont correctes et que vous disposez des autorisations nécessaires pour accéder au registre de schémas.
Registre des AWS Glue schémas entre comptes
**Message d’erreur** : `Cross-account Glue Schema Registry ARN not supported.`
**Solution :** utilisez un registre de AWS Glue schémas enregistré dans le même AWS compte que votre fonction Lambda.
Registre de AWS Glue schémas interrégional
**Message d’erreur** : `Cross-region Glue Schema Registry ARN not supported.`
**Solution :** utilisez un registre de AWS Glue schémas situé dans la même région que votre fonction Lambda.
Problèmes d’accès au secret
**Message d’erreur** : `Lambda received InvalidRequestException from Secrets Manager.`
**Solution :** Vérifiez que le rôle d'exécution de votre fonction est autorisé à accéder au secret et que celui-ci n'est pas chiffré avec une AWS KMS clé par défaut si vous y accédez depuis un autre compte.
### Erreurs de connexion
Ces erreurs se produisent lorsque Lambda ne parvient pas à établir une connexion au registre de schémas.
Problèmes de connectivité VPC
**Message d’erreur** : `Cannot connect to your Schema Registry. Your Kafka cluster's VPC must be able to connect to the schema registry. You can provide access by configuring AWS PrivateLink or a NAT Gateway or VPC Peering between Kafka Cluster VPC and the schema registry VPC.`
**Solution :** configurez votre réseau VPC pour autoriser les connexions au registre de schéma à l'aide AWS PrivateLink d'une passerelle NAT ou d'un peering VPC.
Échec d’établissement d’une liaison TLS
**Message d’erreur** : `Unable to establish TLS handshake with the schema registry. Please provide correct CA-certificate or client certificate using Secrets Manager to access your schema registry.`
**Solution :** vérifiez que vos certificats CA et vos certificats clients (pour mTLS) sont corrects et bien configurés dans Secrets Manager.
étranglement
**Message d’erreur** : `Receiving throttling errors when accessing the schema registry. Please increase API TPS limits for your schema registry.`
**Résolution :** augmentez les limites de débit d’API pour votre registre de schémas ou réduisez le taux de demandes provenant de votre application.
Erreurs de registre de schémas autogéré
**Message d’erreur** : `Lambda received an internal server an unexpected error from the provided self-managed schema registry.`
**Solution :** vérifiez l’état et la configuration de votre serveur de registre de schémas autogéré.
# Traitement à faible latence pour les sources d’événements Kafka
AWS Lambda prend en charge de manière native le traitement des événements à faible latence pour les applications qui nécessitent des end-to-end latences constantes inférieures à 100 millisecondes. Cette page fournit des informations de configuration et des recommandations pour permettre des flux de travail à faible latence.
## Activer le traitement à faible latence
Pour activer le traitement à faible latence sur un mappage des sources d’événements Kafka, la configuration de base suivante est requise :
+ Activez le mode provisionné. Pour de plus amples informations, veuillez consulter [Mode alloué](kafka-scaling-modes.md#kafka-provisioned-mode).
+ Définissez le paramètre du mappage des sources d’événements `MaximumBatchingWindowInSeconds` sur 0. Pour de plus amples informations, veuillez consulter [Comportement de traitement par lots](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching).
## Peaufinage de votre ESM Kafka à faible latence
Tenez compte des recommandations suivantes pour optimiser votre mappage des sources d’événements Kafka pour une faible latence :
### Configuration du mode provisionné
**En mode provisionné pour le mappage des sources d’événements Kafka, Lambda vous permet d’optimiser le débit de votre mappage des sources d’événements en configurant des nombres minimal et maximal de ressources appelées sondeurs d’événements.** Un sondeur d'événements (ou **un interrogateur**) représente une ressource de calcul qui sous-tend le mappage d'une source d'événements en mode provisionné et alloue jusqu'à 5 % de débit. MB/s Chaque sondeur d’événements prend en charge jusqu’à 5 invocations Lambda simultanées.
Pour déterminer la configuration optimale de sondeurs pour votre application, tenez compte de votre taux d’ingestion maximal et de vos exigences de traitement. Étudions un exemple simplifié :
Avec une taille de lot de 20 enregistrements et une durée de fonction cible moyenne de 50 ms, chaque sondeur peut traiter 2 000 enregistrements par seconde, dans la limite de 5 MB/s . Le calcul est le suivant : (20 enregistrements × 1 000 ms/50 ms) × 5 appels Lambda simultanés. Par conséquent, si le taux d’ingestion maximal souhaité est de 20 000 enregistrements par seconde, vous aurez besoin d’au moins 10 sondeurs d’événements.
**Note**
Nous vous recommandons de prévoir des sondeurs d’événements supplémentaires en tant que tampon de sûreté afin d’éviter de fonctionner constamment à pleine capacité.
Le mode provisionné met à l’échelle vos sondeurs d’événements automatiquement en fonction des modèles de trafic dans les limites minimales et maximales de **sondeurs d’événements** configurées, ce qui peut déclencher un rééquilibrage, et par conséquent introduire une latence supplémentaire. Vous pouvez désactiver l’autoscaling en configurant la même valeur pour le nombre minimal et maximal de **sondeurs d’événements**.
### Considérations supplémentaires
Voici quelques considérations supplémentaires :
+ Les démarrages à froid provoqués par l'invocation de votre fonction cible Lambda peuvent potentiellement end-to-end augmenter le temps de latence. Pour réduire ce risque, pensez à activer la [simultanéité provisionnée](provisioned-concurrency.md) ou à activer [SnapStart](snapstart.md)la fonction cible du mappage des sources d'événements. En outre, optimisez l’allocation de mémoire de votre fonction pour garantir des exécutions cohérentes et optimales.
+ Lorsque vous définissez `MaximumBatchingWindowInSeconds` sur 0, Lambda traite immédiatement tous les enregistrements disponibles sans attendre de remplir la taille complète du lot. Par exemple, si la taille de votre lot est définie sur 1 000 enregistrements, mais que seuls 100 enregistrements sont disponibles, Lambda traitera ces 100 enregistrements immédiatement plutôt que d’attendre que les 1 000 enregistrements complets soient accumulés.
**Important**
La configuration optimale pour un traitement à faible latence varie considérablement selon votre charge de travail spécifique. Nous vous recommandons vivement de tester différentes configurations avec votre charge de travail réelle afin de déterminer les meilleurs paramètres pour votre cas d’utilisation.
# Configuration des contrôles de gestion des erreurs pour les sources d'événements Kafka
Vous pouvez configurer la façon dont Lambda gère les erreurs et les nouvelles tentatives pour vos mappages de sources d'événements Kafka. Ces configurations vous aident à contrôler la manière dont Lambda traite les enregistrements ayant échoué et gère le comportement des nouvelles tentatives.
## Configurations de nouvelle tentative disponibles
Les configurations de nouvelle tentative suivantes sont disponibles pour Amazon MSK et les sources d'événements Kafka autogérées :
+ **Nombre maximal de tentatives** : nombre maximal de tentatives de Lambda lorsque votre fonction renvoie une erreur. Cela ne prend pas en compte la tentative d'invocation initiale. La valeur par défaut est -1 (infini). Lorsque vous configurez à la fois un nombre infini de tentatives et une [destination en cas d'échec](kafka-on-failure-destination.md), Lambda applique automatiquement un maximum de 10 tentatives de tentative.
+ **Age maximum d'enregistrement** : âge maximum d'un enregistrement que Lambda envoie à votre fonction. La valeur par défaut est -1 (infini).
+ **Fractionner le lot en cas d'erreur** : lorsque votre fonction renvoie une erreur, divisez le lot en deux lots plus petits et réessayez chacun séparément. Cela permet d'isoler les enregistrements problématiques.
+ **Réponse partielle par lot** : autorisez votre fonction à renvoyer des informations sur les enregistrements d'un lot dont le traitement a échoué, afin que Lambda puisse réessayer uniquement les enregistrements ayant échoué.
## Configuration des contrôles de gestion des erreurs (console)
Vous pouvez configurer le comportement des nouvelles tentatives lors de la création ou de la mise à jour d'un mappage de source d'événements Kafka dans la console Lambda.
**Pour configurer le comportement des nouvelles tentatives pour une source d'événements Kafka (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez le nom de votre fonction.
1. Effectuez l’une des actions suivantes :
+ Pour ajouter un nouveau déclencheur Kafka, sous **Vue d'ensemble des fonctions**, choisissez **Ajouter un déclencheur**.
+ Pour modifier un déclencheur Kafka existant, choisissez-le, puis choisissez **Modifier**.
1. Sous **Configuration du sondeur d'événements**, sélectionnez le mode provisionné pour configurer les contrôles de gestion des erreurs :
1. Pour **Réessayer, entrez le nombre maximum de tentatives** (0 à 10 000, ou -1 pour un nombre infini).
1. Pour **Age maximum d'enregistrement**, entrez l'âge maximum en secondes (60-604800, ou -1 pour un nombre infini).
1. Pour activer le fractionnement par lots en cas d'erreur, sélectionnez **Fractionner le lot en cas d'erreur**.
1. Pour activer la réponse partielle par lots, sélectionnez **ReportBatchItemFailures**.
1. Choisissez **Ajouter** ou **Enregistrer**.
## Configuration du comportement des nouvelles tentatives ()AWS CLI
Utilisez les AWS CLI commandes suivantes pour configurer le comportement des nouvelles tentatives pour vos mappages de sources d'événements Kafka.
### Création d'un mappage de sources d'événements avec des configurations de nouvelle tentative
L'exemple suivant crée un mappage de source d'événements Kafka autogéré avec des contrôles de gestion des erreurs :
```
aws lambda create-event-source-mapping \
--function-name my-kafka-function \
--topics my-kafka-topic \
--source-access-configuration Type=SASL_SCRAM_512_AUTH,URI=arn:aws:secretsmanager:us-east-1:111122223333:secret:MyBrokerSecretName \
--self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc.xyz.com:9092"]}}' \
--starting-position LATEST \
--provisioned-poller-config MinimumPollers=1,MaximumPollers=1 \
--maximum-retry-attempts 3 \
--maximum-record-age-in-seconds 3600 \
--bisect-batch-on-function-error \
--function-response-types "ReportBatchItemFailures"
```
Pour les sources d'événements Amazon MSK :
```
aws lambda create-event-source-mapping \
--event-source-arn arn:aws:kafka:us-east-1:111122223333:cluster/my-cluster/fc2f5bdf-fd1b-45ad-85dd-15b4a5a6247e-2 \
--topics AWSMSKKafkaTopic \
--starting-position LATEST \
--function-name my-kafka-function \
--source-access-configurations '[{"Type": "SASL_SCRAM_512_AUTH","URI": "arn:aws:secretsmanager:us-east-1:111122223333:secret:my-secret"}]' \
--provisioned-poller-config MinimumPollers=1,MaximumPollers=1 \
--maximum-retry-attempts 3 \
--maximum-record-age-in-seconds 3600 \
--bisect-batch-on-function-error \
--function-response-types "ReportBatchItemFailures"
```
### Mise à jour des configurations de nouvelle tentative
Utilisez la `update-event-source-mapping` commande pour modifier les configurations de nouvelle tentative pour un mappage de source d'événement existant :
```
aws lambda update-event-source-mapping \
--uuid 12345678-1234-1234-1234-123456789012 \
--maximum-retry-attempts 5 \
--maximum-record-age-in-seconds 7200 \
--bisect-batch-on-function-error \
--function-response-types "ReportBatchItemFailures"
```
## PartialBatchResponse
La réponse partielle par lots, également connue sous le nom de ReportBatchItemFailures, est une fonctionnalité clé pour la gestion des erreurs dans l'intégration de Lambda aux sources Kafka. Sans cette fonctionnalité, lorsqu'une erreur survient dans l'un des éléments d'un lot, cela entraîne le retraitement de tous les messages de ce lot. Lorsque la réponse par lots partielle est activée et implémentée, le gestionnaire renvoie des identifiants uniquement pour les messages ayant échoué, ce qui permet à Lambda de réessayer uniquement ces éléments spécifiques. Cela permet de mieux contrôler le traitement des lots contenant des messages d'échec.
Pour signaler des erreurs par lots, vous allez utiliser le schéma JSON suivant :
```
{
"batchItemFailures": [
{
"itemIdentifier": {
"partition": "topic-partition_number",
"offset": 100
}
},
...
]
}
```
**Important**
Si vous renvoyez un fichier JSON valide vide ou nul, le mappage de la source d'événements considérera qu'un lot a été traité avec succès. Tout topic-partition\$1number ou offset non valide renvoyé qui n'était pas présent dans l'événement invoqué sera considéré comme un échec et le lot entier sera réessayé.
Les exemples de code suivants montrent comment implémenter une réponse par lots partielle pour les fonctions Lambda qui reçoivent des événements provenant de sources Kafka. La fonction signale les défaillances échecs d’articles par lots dans la réponse, en indiquant à Lambda de réessayer ces messages ultérieurement.
Voici une implémentation du gestionnaire Lambda en Python qui illustre cette approche :
```
import base64
from typing import Any, Dict, List
def lambda_handler(event: Dict[str, Any], context: Any) -> Dict[str, List[Dict[str, Dict[str, Any]]]]:
failures: List[Dict[str, Dict[str, Any]]] = []
records_dict = event.get("records", {})
for topic_partition, records_list in records_dict.items():
for record in records_list:
topic = record.get("topic")
partition = record.get("partition")
offset = record.get("offset")
value_b64 = record.get("value")
try:
data = base64.b64decode(value_b64).decode("utf-8")
process_message(data)
except Exception as exc:
print(f"Failed to process record topic={topic} partition={partition} offset={offset}: {exc}")
item_identifier: Dict[str, Any] = {
"partition": f"{topic}-{partition}",
"offset": int(offset) if offset is not None else None,
}
failures.append({"itemIdentifier": item_identifier})
return {"batchItemFailures": failures}
def process_message(data: str) -> None:
# Your business logic for a single message
pass
```
Voici une version de Node.js :
```
const { Buffer } = require("buffer");
const handler = async (event) => {
const failures = [];
for (let topicPartition in event.records) {
const records = event.records[topicPartition];
for (const record of records) {
const topic = record.topic;
const partition = record.partition;
const offset = record.offset;
const valueBase64 = record.value;
const data = Buffer.from(valueBase64, "base64").toString("utf8");
try {
await processMessage(data);
} catch (error) {
console.error("Failed to process record", { topic, partition, offset, error });
const itemIdentifier = {
"partition": `${topic}-${partition}`,
"offset": Number(offset),
};
failures.push({ itemIdentifier });
}
}
}
return { batchItemFailures: failures };
};
async function processMessage(payload) {
// Your business logic for a single message
}
module.exports = { handler };
```
# Capture de lots supprimés pour des sources d’événement Amazon MSK et Apache Kafka autogéré
Pour retenir les enregistrements des invocations de mappage de sources d’événements qui ont échoué, ajoutez une destination au mappage des sources d’événements de votre fonction. Chaque enregistrement envoyé à la destination est un document JSON contenant les métadonnées sur l’invocation ayant échoué. Pour les destinations Amazon S3, Lambda envoie également l’intégralité de l’enregistrement d’invocation avec les métadonnées. Vous pouvez configurer n'importe quelle rubrique Amazon SNS, n'importe quelle file d'attente Amazon SQS, n'importe quel compartiment Amazon S3 ou Kafka comme destination.
Avec les destinations Amazon S3, vous pouvez utiliser la fonctionnalité [Notifications d’événements Amazon S3](https://docs.aws.amazon.com/) pour recevoir des notifications lorsque des objets sont chargés dans votre compartiment S3 de destination. Vous pouvez également configurer les notifications d’événements S3 pour invoquer une autre fonction Lambda afin d’effectuer un traitement automatique des lots ayant échoué.
Votre rôle d’exécution doit disposer d’autorisations pour la destination :
+ **Pour une destination SQS : [sqs](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) :** SendMessage
+ **[Pour une destination SNS : SNS:Publish](https://docs.aws.amazon.com/sns/latest/api/API_Publish.html)**
+ **Pour une destination S3 :** [s3 : PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html) et [s3 : ListBucket](https://docs.aws.amazon.com/AmazonS3/latest/API/ListObjectsV2.html)
+ **Pour une destination Kafka : [kafka-cluster](https://docs.aws.amazon.com/msk/latest/developerguide/kafka-actions.html) :** WriteData
Vous pouvez configurer un sujet Kafka comme destination en cas d'échec pour vos mappages de sources d'événements Kafka. Lorsque Lambda ne parvient pas à traiter les enregistrements après avoir épuisé toutes les tentatives ou lorsque les enregistrements dépassent l'âge maximum, Lambda envoie les enregistrements ayant échoué à la rubrique Kafka spécifiée pour un traitement ultérieur. Reportez-vous à [Utiliser un sujet Kafka comme destination en cas d'échec](kafka-on-failure-destination.md).
Vous devez déployer un point de terminaison de VPC pour votre service de destination en cas de panne au sein de votre VPC de cluster Kafka.
En outre, si vous avez configuré une clé KMS sur votre destination, Lambda a besoin des autorisations suivantes en fonction du type de destination :
+ Si vous avez activé le chiffrement avec votre propre clé KMS pour une destination S3, [kms : GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) est obligatoire. Si la clé KMS et la destination du compartiment S3 se trouvent dans un compte différent de celui de votre fonction Lambda et de votre rôle d'exécution, configurez la clé KMS pour qu'elle approuve le rôle d'exécution à autoriser. kms: GenerateDataKey
+ [Si vous avez activé le chiffrement avec votre propre clé KMS pour la destination SQS, [KMS:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) et kms : sont obligatoires. GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) [Si la clé KMS et la destination de la file d'attente SQS se trouvent dans un compte différent de celui de votre fonction Lambda et de votre rôle d'exécution, configurez la clé KMS pour qu'elle approuve le rôle d'exécution afin d' kms:autoriser Decrypt kms: GenerateDataKey[, kms DescribeKey : et kms](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) :. ReEncrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_ReEncrypt.html)
+ [Si vous avez activé le chiffrement avec votre propre clé KMS pour la destination SNS, [KMS:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) et kms : sont requis. GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) [Si la clé KMS et la destination de la rubrique SNS se trouvent dans un compte différent de celui de votre fonction Lambda et de votre rôle d'exécution, configurez la clé KMS pour qu'elle approuve le rôle d'exécution afin d' kms:autoriser Decrypt kms: GenerateDataKey[, kms DescribeKey : et kms](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) :. ReEncrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_ReEncrypt.html)
## Configuration des destinations en cas d’échec pour un mappage des sources d’événements Kafka
Pour configurer une destination en cas de panne à l’aide de la console, procédez comme suit :
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez une fonction.
1. Sous **Function overview (Vue d’ensemble de la fonction)**, choisissez **Add destination (Ajouter une destination)**.
1. Pour **Source**, choisissez **Invocation du mappage des sources d’événements**.
1. Pour le **mappage des sources d’événements**, choisissez une source d’événements configurée pour cette fonction.
1. Pour **Condition**, sélectionnez **En cas d’échec**. Pour les invocations de mappage des sources d’événements, il s’agit de la seule condition acceptée.
1. Pour **Type de destination**, choisissez le type de destination auquel Lambda envoie les enregistrements d’invocation.
1. Pour **Destination**, choisissez une ressource.
1. Choisissez **Enregistrer**.
Vous pouvez également configurer une destination en cas de panne à l’aide de l’ AWS CLI. Par exemple, la [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html)commande suivante ajoute un mappage de source d'événement avec une destination SQS en cas de défaillance pour : `MyFunction`
```
aws lambda create-event-source-mapping \
--function-name "MyFunction" \
--event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/vpc-2priv-2pub/751d2973-a626-431c-9d4e-d7975eb44dd7-2 \
--destination-config '{"OnFailure": {"Destination": "arn:aws:sqs:us-east-1:123456789012:dest-queue"}}'
```
La [update-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-event-source-mapping.html)commande suivante ajoute une destination S3 en cas de défaillance à la source d'événements associée à l'entrée `uuid` :
```
aws lambda update-event-source-mapping \
--uuid f89f8514-cdd9-4602-9e1f-01a5b77d449b \
--destination-config '{"OnFailure": {"Destination": "arn:aws:s3:::dest-bucket"}}'
```
Pour supprimer une destination, entrez une chaîne vide comme argument du paramètre `destination-config` :
```
aws lambda update-event-source-mapping \
--uuid f89f8514-cdd9-4602-9e1f-01a5b77d449b \
--destination-config '{"OnFailure": {"Destination": ""}}'
```
### Pratiques exemplaires en matière de sécurité pour les destinations Amazon S3
La suppression d’un compartiment S3 configuré comme destination sans supprimer la destination de la configuration de votre fonction peut engendrer un risque de sécurité. Si un autre utilisateur connaît le nom de votre compartiment de destination, il peut recréer le compartiment dans son Compte AWS. Les enregistrements des invocations ayant échoué seront envoyés dans son compartiment, exposant potentiellement les données de votre fonction.
**Avertissement**
Pour vous assurer que les enregistrements d'invocation de votre fonction ne peuvent pas être envoyés vers un compartiment S3 d'un autre Compte AWS, ajoutez une condition au rôle d'exécution de votre fonction qui limite `s3:PutObject` les autorisations aux compartiments de votre compte.
L’exemple suivant présente une politique IAM qui limite les autorisations `s3:PutObject` de votre fonction aux seuls compartiments de votre compte. Cette politique donne également à Lambda l’autorisation `s3:ListBucket` dont il a besoin pour utiliser un compartiment S3 comme destination.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "S3BucketResourceAccountWrite",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::*/*",
"arn:aws:s3:::*"
],
"Condition": {
"StringEquals": {
"s3:ResourceAccount": "111122223333"
}
}
}
]
}
```
Pour ajouter une politique d'autorisations au rôle d'exécution de votre fonction à l'aide du AWS Management Console ou AWS CLI, reportez-vous aux instructions des procédures suivantes :
------
#### [ Console ]
**Pour ajouter une politique d’autorisations au rôle d’exécution d’une fonction (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Sélectionnez la fonction Lambda dont vous voulez modifier le rôle d’exécution.
1. Sous l’onglet **Configuration**, sélectionnez **Autorisations**.
1. Sous l’onglet **Rôle d’exécution**, sélectionnez le **Nom du rôle** de votre fonction pour ouvrir la page de console IAM du rôle.
1. Ajoutez une politique d’autorisations de au rôle en procédant comme suit :
1. Dans le volet **Politiques d’autorisations**, choisissez **Ajouter des autorisations**, puis **Créer une politique en ligne**.
1. Dans l’**Éditeur de politique**, sélectionnez **JSON**.
1. Collez la politique que vous souhaitez ajouter dans l’éditeur (en remplacement du JSON existant), puis choisissez **Suivant**.
1. Sous **Détails de la politique**, saisissez un **Nom de la politique**.
1. Choisissez **Create Policy** (Créer une politique).
------
#### [ AWS CLI ]
**Pour ajouter une politique d’autorisations au rôle d’exécution d’une fonction (CLI)**
1. Créez un document de politique JSON avec les autorisations requises et enregistrez-le dans un répertoire local.
1. Utilisez la commande `put-role-policy` de la CLI IAM pour ajouter des autorisations au rôle d’exécution de votre fonction. Exécutez la commande suivante depuis le répertoire dans lequel vous avez enregistré votre document de politique JSON et remplacez le nom du rôle, le nom de la politique et le document de politique par vos propres valeurs.
```
aws iam put-role-policy \
--role-name my_lambda_role \
--policy-name LambdaS3DestinationPolicy \
--policy-document file://my_policy.json
```
------
### Exemple d’enregistrement d’invocation SNS et SQS
L’exemple suivant montre ce que Lambda envoie à une rubrique SNS ou à une destination de file d’attente SQS pour une invocation de source d’événement Kafka qui a échoué. Chacune des clés sous `recordsInfo` contient à la fois le sujet et la partition Kafka, séparés par un trait d’union. Par exemple, pour la clé`"Topic-0"`, `Topic` est la rubrique Kafka, et `0` est la partition. Pour chaque sujet et chaque partition, vous pouvez utiliser les décalages et les données d’horodatage pour trouver les enregistrements d’invocation d’origine.
```
{
"requestContext": {
"requestId": "316aa6d0-8154-xmpl-9af7-85d5f4a6bc81",
"functionArn": "arn:aws:lambda:us-east-1:123456789012:function:myfunction",
"condition": "RetryAttemptsExhausted" | "MaximumPayloadSizeExceeded",
"approximateInvokeCount": 1
},
"responseContext": { // null if record is MaximumPayloadSizeExceeded
"statusCode": 200,
"executedVersion": "$LATEST",
"functionError": "Unhandled"
},
"version": "1.0",
"timestamp": "2019-11-14T00:38:06.021Z",
"KafkaBatchInfo": {
"batchSize": 500,
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/vpc-2priv-2pub/751d2973-a626-431c-9d4e-d7975eb44dd7-2",
"bootstrapServers": "...",
"payloadSize": 2039086, // In bytes
"recordsInfo": {
"Topic-0": {
"firstRecordOffset": "49601189658422359378836298521827638475320189012309704722",
"lastRecordOffset": "49601189658422359378836298522902373528957594348623495186",
"firstRecordTimestamp": "2019-11-14T00:38:04.835Z",
"lastRecordTimestamp": "2019-11-14T00:38:05.580Z",
},
"Topic-1": {
"firstRecordOffset": "49601189658422359378836298521827638475320189012309704722",
"lastRecordOffset": "49601189658422359378836298522902373528957594348623495186",
"firstRecordTimestamp": "2019-11-14T00:38:04.835Z",
"lastRecordTimestamp": "2019-11-14T00:38:05.580Z",
}
}
}
}
```
### Exemple d’enregistrement d’invocation de destination S3
Pour les destinations S3, Lambda envoie l’intégralité de l’enregistrement d’invocation ainsi que les métadonnées à la destination. L’exemple suivant montre que Lambda envoie vers une destination de compartiment S3 en cas d’échec d’une invocation de source d’événement Kafka. Outre tous les champs de l’exemple précédent pour les destinations SQS et SNS, le champ `payload` contient l’enregistrement d’invocation d’origine sous forme de chaîne JSON échappée.
```
{
"requestContext": {
"requestId": "316aa6d0-8154-xmpl-9af7-85d5f4a6bc81",
"functionArn": "arn:aws:lambda:us-east-1:123456789012:function:myfunction",
"condition": "RetryAttemptsExhausted" | "MaximumPayloadSizeExceeded",
"approximateInvokeCount": 1
},
"responseContext": { // null if record is MaximumPayloadSizeExceeded
"statusCode": 200,
"executedVersion": "$LATEST",
"functionError": "Unhandled"
},
"version": "1.0",
"timestamp": "2019-11-14T00:38:06.021Z",
"KafkaBatchInfo": {
"batchSize": 500,
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/vpc-2priv-2pub/751d2973-a626-431c-9d4e-d7975eb44dd7-2",
"bootstrapServers": "...",
"payloadSize": 2039086, // In bytes
"recordsInfo": {
"Topic-0": {
"firstRecordOffset": "49601189658422359378836298521827638475320189012309704722",
"lastRecordOffset": "49601189658422359378836298522902373528957594348623495186",
"firstRecordTimestamp": "2019-11-14T00:38:04.835Z",
"lastRecordTimestamp": "2019-11-14T00:38:05.580Z",
},
"Topic-1": {
"firstRecordOffset": "49601189658422359378836298521827638475320189012309704722",
"lastRecordOffset": "49601189658422359378836298522902373528957594348623495186",
"firstRecordTimestamp": "2019-11-14T00:38:04.835Z",
"lastRecordTimestamp": "2019-11-14T00:38:05.580Z",
}
}
},
"payload": "" // Only available in S3
}
```
**Astuce**
Nous vous recommandons d’activer la gestion des versions S3 sur votre compartiment de destination.
# Utiliser un sujet Kafka comme destination en cas d'échec
Vous pouvez configurer un sujet Kafka comme destination en cas d'échec pour vos mappages de sources d'événements Kafka. Lorsque Lambda ne parvient pas à traiter les enregistrements après avoir épuisé toutes les tentatives ou lorsque les enregistrements dépassent l'âge maximum, Lambda envoie les enregistrements ayant échoué à la rubrique Kafka spécifiée pour un traitement ultérieur. Lorsque vous configurez à la fois un [nombre infini de tentatives](kafka-retry-configurations.md) et une destination en cas d'échec, Lambda applique automatiquement un maximum de 10 tentatives.
## Comment fonctionne une destination Kafka en cas de défaillance
Lorsque vous configurez un sujet Kafka comme destination en cas d'échec, Lambda agit en tant que producteur Kafka et écrit les enregistrements ayant échoué dans le sujet de destination. Cela crée un modèle de sujet mort (DLT) au sein de votre infrastructure Kafka.
+ **Même exigence de cluster** — Le sujet de destination doit exister dans le même cluster Kafka que vos sujets source.
+ **Contenu réel des enregistrements** : les destinations Kafka reçoivent les enregistrements défaillants réels ainsi que les métadonnées relatives aux échecs.
+ **Prévention de la récursivité** : Lambda empêche les boucles infinies en bloquant les configurations dans lesquelles les sujets source et destination sont identiques.
## Configuration d'une destination Kafka en cas de panne
Vous pouvez configurer un sujet Kafka comme destination en cas d'échec lors de la création ou de la mise à jour d'un mappage de source d'événements Kafka.
### Configuration d'une destination Kafka (console)
**Pour configurer un sujet Kafka comme destination en cas d'échec (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez le nom de votre fonction.
1. Effectuez l’une des actions suivantes :
+ Pour ajouter un nouveau déclencheur Kafka, sous **Vue d'ensemble des fonctions**, choisissez **Ajouter un déclencheur**.
+ Pour modifier un déclencheur Kafka existant, choisissez-le, puis choisissez **Modifier**.
1. Sous **Paramètres supplémentaires**, pour **Destination en cas d'échec**, choisissez le sujet **Kafka**.
1. Dans le **champ Nom du sujet**, entrez le nom du sujet Kafka auquel vous souhaitez envoyer les enregistrements ayant échoué.
1. Choisissez **Ajouter** ou **Enregistrer**.
### Configuration d'une destination Kafka ()AWS CLI
Utilisez le `kafka://` préfixe pour spécifier un sujet Kafka comme destination en cas d'échec.
#### Création d'un mappage des sources d'événements avec la destination Kafka
L'exemple suivant crée un mappage de source d'événement Amazon MSK avec un sujet Kafka comme destination en cas d'échec :
```
aws lambda create-event-source-mapping \
--function-name my-kafka-function \
--topics AWSKafkaTopic \
--event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/my-cluster/abc123 \
--starting-position LATEST \
--provisioned-poller-config MinimumPollers=1,MaximumPollers=3 \
--destination-config '{"OnFailure":{"Destination":"kafka://failed-records-topic"}}'
```
Pour Kafka autogéré, utilisez la même syntaxe :
```
aws lambda create-event-source-mapping \
--function-name my-kafka-function \
--topics AWSKafkaTopic \
--self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc.xyz.com:9092"]}}' \
--starting-position LATEST \
--provisioned-poller-config MinimumPollers=1,MaximumPollers=3 \
--destination-config '{"OnFailure":{"Destination":"kafka://failed-records-topic"}}'
```
#### Mettre à jour une destination Kafka
Utilisez la `update-event-source-mapping` commande pour ajouter ou modifier une destination Kafka :
```
aws lambda update-event-source-mapping \
--uuid 12345678-1234-1234-1234-123456789012 \
--destination-config '{"OnFailure":{"Destination":"kafka://failed-records-topic"}}'
```
## Format d'enregistrement pour une destination Kafka
Lorsque Lambda envoie des enregistrements ayant échoué à un sujet Kafka, chaque message contient à la fois des métadonnées relatives à l'échec et le contenu réel de l'enregistrement.
### Métadonnées relatives aux défaillances
Les métadonnées incluent des informations sur les raisons de l'échec de l'enregistrement et des détails sur le lot d'origine :
```
{
"requestContext": {
"requestId": "e4b46cbf-b738-xmpl-8880-a18cdf61200e",
"functionArn": "arn:aws:lambda:us-east-1:123456789012:function:my-function:$LATEST",
"condition": "RetriesExhausted",
"approximateInvokeCount": 3
},
"responseContext": {
"statusCode": 200,
"executedVersion": "$LATEST",
"functionError": "Unhandled"
},
"version": "1.0",
"timestamp": "2019-11-14T18:16:05.568Z",
"KafkaBatchInfo": {
"batchSize": 1,
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/my-cluster/abc123",
"bootstrapServers": "b-1.mycluster.abc123.kafka.us-east-1.amazonaws.com:9098",
"payloadSize": 1162,
"recordInfo": {
"offset": "49601189658422359378836298521827638475320189012309704722",
"timestamp": "2019-11-14T18:16:04.835Z"
}
},
"payload": {
"bootstrapServers": "b-1.mycluster.abc123.kafka.us-east-1.amazonaws.com:9098",
"eventSource": "aws:kafka",
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/my-cluster/abc123",
"records": {
"my-topic-0": [
{
"headers": [],
"key": "dGVzdC1rZXk=",
"offset": 100,
"partition": 0,
"timestamp": 1749116692330,
"timestampType": "CREATE_TIME",
"topic": "my-topic",
"value": "dGVzdC12YWx1ZQ=="
}
]
}
}
}
```
### Comportement des clés de partition
Lambda utilise la même clé de partition que celle de l'enregistrement d'origine lors de la production vers le sujet de destination. Si l'enregistrement d'origine ne contenait aucune clé, Lambda utilise le partitionnement circulaire par défaut de Kafka entre toutes les partitions disponibles dans le sujet de destination.
## Exigences et limitations
+ **Mode provisionné requis** — Une destination Kafka en cas de défaillance n'est disponible que pour les mappages de sources d'événements avec le mode provisionné activé.
+ **Même cluster uniquement** — Le sujet de destination doit exister dans le même cluster Kafka que vos sujets source.
+ **Autorisations de sujet** : le mappage de la source de votre événement doit disposer d'autorisations d'écriture sur le sujet de destination. Exemple :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ClusterPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:DescribeCluster",
"kafka-cluster:DescribeTopic",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:*:*:cluster/*"
]
},
{
"Sid": "TopicPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:DescribeTopic",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:*:*:topic/*/*"
]
},
{
"Effect": "Allow",
"Action": [
"kafka:DescribeCluster",
"kafka:GetBootstrapBrokers",
"kafka:Produce"
],
"Resource": "arn:aws:kafka:*:*:cluster/*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DeleteNetworkInterface",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups"
],
"Resource": "*"
}
]
}
```
+ **Aucune récursivité** : le nom du sujet de destination ne peut pas être le même que celui de votre sujet source.
# Journalisation du mappage des sources d'événements Kafka
Vous pouvez configurer la journalisation au niveau du système pour vos mappages de sources d'événements Kafka afin d'activer et de filtrer les journaux système auxquels les sondeurs d'événements Lambda envoient des informations. CloudWatch
Cette fonctionnalité n'est disponible que pour les mappages de sources d'événements Kafka et en mode [provisionné](https://docs.aws.amazon.com/lambda/latest/dg/kafka-scaling-modes.html#kafka-provisioned-mode).
Pour le mappage des sources d'événements avec la configuration de journalisation, vous pouvez également consulter les journaux du système à partir de requêtes de journal prédéfinies dans l'onglet **Monitor** de la page Console **Lambda** **> Ressources supplémentaires >** mappages de **sources d'événements actuels**.
## Comment fonctionne la journalisation
Lorsque vous définissez la configuration de journalisation avec le niveau de journalisation dans le mappage de votre source d'événements, le sondeur d'événements Lambda envoie les journaux correspondants (journaux du système de mappage des sources d'événements).
Le mappage de la source d'événements réutilise la même [destination de journal](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-logs.html#configuring-log-destinations) avec votre fonction Lambda. Assurez-vous que le rôle d'exécution de votre fonction Lambda dispose des autorisations de journalisation nécessaires.
Le mappage de la source d'événements aura son propre flux de journal, avec l'UUID du mappage de la date et de la source de l'événement comme nom du flux de journal, par exemple. `2020/01/01/12345678-1234-1234-1234-12345678901`
Pour les journaux du système de mappage des sources d'événements, vous pouvez choisir entre les niveaux de journal suivants.
| Niveau de journalisation | Usage |
| --- | --- |
| DEBUG (le plus détaillé) | Informations détaillées sur la progression du traitement des sources d'événements |
| INFO | Messages concernant le fonctionnement normal du mappage de la source de votre événement |
| WARN (moindre détail) | Messages concernant les avertissements et les erreurs potentiels susceptibles d'entraîner un comportement inattendu |
Lorsque vous sélectionnez un niveau de journal, Lambda Event Poller envoie des journaux à ce niveau ou à un niveau inférieur. Par exemple, si vous définissez le niveau de journal du système de mappage de la source d'événements sur INFO, Event Poller n'envoie pas de sorties de journal au niveau DEBUG.
## Configuration de la journalisation
Vous pouvez définir la configuration de journalisation lors de la création ou de la mise à jour d'un mappage de source d'événements Kafka.
### Configuration de la journalisation (console)
**Pour configurer la journalisation (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez le nom de votre fonction.
1. Effectuez l’une des actions suivantes :
+ Pour ajouter un nouveau déclencheur Kafka, sous **Vue d'ensemble des fonctions**, choisissez **Ajouter un déclencheur**.
+ Pour modifier un déclencheur Kafka existant, choisissez-le, puis choisissez **Modifier**.
1. Sous **Configuration du sondeur d'événements**, pour le **mode provisionné, cochez** la case **Configurer**. Et le paramètre du **niveau de journalisation** apparaîtrait.
1. Cliquez sur la liste déroulante des **niveaux de journalisation** et sélectionnez un niveau pour le mappage des sources d'événements.
1. Choisissez **Ajouter** ou **Enregistrer** en bas pour créer ou mettre à jour le mappage des sources d'événements.
### Configuration de la journalisation (AWS CLI)
#### Création d'un mappage des sources d'événements avec journalisation
L'exemple suivant crée un mappage de source d'événement Amazon MSK avec une configuration de journalisation :
```
aws lambda create-event-source-mapping \
--function-name my-kafka-function \
--topics AWSKafkaTopic \
--event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/my-cluster/abc123 \
--starting-position LATEST \
--provisioned-poller-config MinimumPollers=1,MaximumPollers=3 \
--logging-config '{"SystemLogLevel":"DEBUG"}'
```
Pour Kafka autogéré, utilisez la même syntaxe :
```
aws lambda create-event-source-mapping \
--function-name my-kafka-function \
--topics AWSKafkaTopic \
--self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc.xyz.com:9092"]}}' \
--starting-position LATEST \
--provisioned-poller-config MinimumPollers=1,MaximumPollers=3 \
--logging-config '{"SystemLogLevel":"DEBUG"}'
```
#### Mettre à jour la configuration d'enregistrement
Utilisez la `update-event-source-mapping` commande pour ajouter ou modifier la configuration de journalisation :
```
aws lambda update-event-source-mapping \
--uuid 12345678-1234-1234-1234-123456789012 \
--logging-config '{"SystemLogLevel":"WARN"}'
```
## Format d'enregistrement pour un journal du système de mappage des sources d'événements Kafka
Lorsque Lambda Event Poller envoie le journal, chaque entrée de journal contient des métadonnées générales de mappage des sources d'événements ainsi que du contenu spécifique à l'événement.
### Enregistrement du journal WARN
L'enregistrement WARN contient des erreurs ou des avertissements provenant de l'analyseur d'événements, et il est émis lorsque l'événement s'est produit. Par exemple :
```
{
"eventType": "ESM_PROCESSING_EVENT",
"timestamp": 1546347650000,
"resourceArn": "arn:aws:lambda:us-east-1:123456789012:event-source-mapping:12345678-1234-1234-1234-123456789012",
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/tests-cluster/87654321-4321-4321-4321-876543221-s1",
"eventProcessorId": "12345678-1234-1234-1234-123456789012/0",
"logLevel": "WARN",
"error": {
"errorMessage": "Timeout expired while fetching topic metadata",
"errorCode": "org.apache.kafka.common.errors.TimeoutException"
}
}
```
### Enregistrement du journal INFO
L'enregistrement INFO contient les configurations des clients clients Kafka dans chaque sondeur d'événements, et il est émis lors de la création ou de la modification d'un consommateur. Par exemple :
```
{
"eventType": "POLLER_STATUS_EVENT",
"timestamp": 1546347660000,
"resourceArn": "arn:aws:lambda:us-east-1:123456789012:event-source-mapping:12345678-1234-1234-1234-123456789012",
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/tests-cluster/87654321-4321-4321-4321-876543221-s1",
"eventProcessorId": "12345678-1234-1234-1234-123456789012/0",
"logLevel": "INFO",
"kafkaEventSourceConnection": {
"brokerEndpoints": "boot-abcd1234.c2.kafka-serverless.us-east-1.amazonaws.com:9098",
"consumerId": "12345678-1234-1234-1234-123456789012-0",
"topics": [
"test"
],
"consumerGroupId": "12345678-1234-1234-1234-123456789012",
"securityProtocol": "SASL_SSL",
"saslMechanism": "AWS_MSK_IAM",
"totalPartitionCount": 2,
"assignedPartitionCount": 2,
"partitionsAssignmentGeneration": 5,
"assignedPartitions": [
"test-0",
"test-1"
],
"networkConfig": {
"ipAddresses": [
"10.100.141.1"
],
"subnetCidrBlock": "10.100.128.0/20",
"securityGroups": [
"sg-abcdefabcdefabcdef"
]
}
}
}
```
### Enregistrement du journal DEBUG
Le journal DEBUG contient les informations relatives aux décalages de Kafka lors du traitement du mappage des sources d'événements, et les informations de décalage sont émises par minute. Par exemple :
```
{
"eventType": "KAFKA_STATUS_EVENT",
"timestamp": 1546347670000,
"resourceArn": "arn:aws:lambda:us-east-1:123456789012:event-source-mapping:12345678-1234-1234-1234-123456789012",
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/tests-cluster/87654321-4321-4321-4321-876543221-s1",
"eventProcessorId": "12345678-1234-1234-1234-123456789012/0",
"logLevel": "DEBUG",
"kafkaPartitionOffsets": {
"partition": "test-1",
"endOffset": 5004,
"consumedOffset": 5003,
"processedOffset": 5003,
"committedOffset": 5004
}
}
```
# Résolution des erreurs de mappage des sources d’événements Kafka
Les rubriques suivantes fournissent des conseils de dépannage pour les erreurs et les problèmes que vous pouvez rencontrer en utilisant Amazon MSK ou Apache Kafka autogéré avec Lambda.
Pour obtenir de l’aide supplémentaire en matière de résolution des problèmes, consultez le [Centre de connaissances AWS](https://repost.aws/knowledge-center#AWS_Lambda).
## Authentification et erreurs d’autorisation
Si l'une des autorisations requises pour consommer les données du cluster Kafka est manquante, Lambda affiche l'un des messages d'erreur suivants dans le mappage des sources d'événements ci-dessous. **LastProcessingResult**
**Topics**
+ [Le cluster n’a pas pu autoriser Lambda](#kafka-authorize-errors)
+ [Échec de l’authentification SASL](#kafka-sasl-errors)
+ [Le serveur n’a pas réussi à authentifier Lambda](#kafka-mtls-errors-server)
+ [Lambda n’a pas réussi à authentifier le serveur](#kafka-mtls-errors-lambda)
+ [Le certificat ou la clé privée fournis n’est pas valide](#kafka-key-errors)
### Le cluster n’a pas pu autoriser Lambda
Pour SASL/SCRAM ou mTLS, cette erreur indique que l'utilisateur fourni ne possède pas toutes les autorisations requises de la liste de contrôle d'accès (ACL) Kafka suivantes :
+ DescribeConfigs Cluster
+ Décrire un groupe
+ Lire le groupe
+ Décrire la rubrique
+ Lire la rubrique
Lorsque vous créez Kafka ACLs avec les `kafka-cluster` autorisations requises, spécifiez le sujet et le groupe en tant que ressources. Le nom de la rubrique doit correspondre à la rubrique dans le mappage des sources d’événements. Le nom du groupe doit correspondre à l’UUID du mappage des sources d’événements.
Une fois que vous avez ajouté les autorisations requises au rôle d’exécution, il peut y avoir un délai de plusieurs minutes avant que les modifications ne prennent effet.
Voici un exemple de journal au niveau du système ESM après avoir activé Logging [Config](esm-logging.md) pour ce problème :
```
{
"eventType": "ESM_PROCESSING_EVENT",
"timestamp": 1734567890123,
"resourceArn": "arn:aws:lambda:us-east-1:123456789012:event-source-mapping:a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/my-kafka-cluster/12345678-abcd-1234-efgh-EXAMPLE11111-1",
"eventProcessorId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111/0",
"logLevel": "WARN",
"error": {
"errorMessage": "Not authorized to access topics: [my-topic]",
"errorCode": "org.apache.kafka.common.errors.TopicAuthorizationException"
}
}
```
### Échec de l’authentification SASL
Pour SASL/SCRAM ou SASL/PLAIN, cette erreur indique que les informations de connexion fournies ne sont pas valides.
Pour le contrôle d’accès IAM, le rôle d’exécution ne dispose pas des autorisations `kafka-cluster:Connect` pour le cluster. Ajoutez cette autorisation au rôle et spécifiez l’Amazon Resource Name (ARN) du cluster en tant que ressource.
Cette erreur peut se produire de façon intermittente. Le cluster rejette les connexions une fois que le nombre de connexions TCP dépasse le Quota de service. Lambda fait marche arrière et tente de nouveau jusqu’à ce qu’une connexion soit réussie. Une fois que Lambda se connecte au cluster et interroge les enregistrements, le dernier résultat de traitement passe à `OK`.
Voici un exemple de journal ESM au niveau du système après avoir activé Logging [Config](esm-logging.md) pour ce problème lors de l'utilisation de l'authentification IAM :
```
{
"eventType": "ESM_PROCESSING_EVENT",
"timestamp": 1734567890456,
"resourceArn": "arn:aws:lambda:us-east-1:123456789012:event-source-mapping:a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/my-kafka-cluster/12345678-abcd-1234-efgh-EXAMPLE22222-1",
"eventProcessorId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222/0",
"logLevel": "WARN",
"error": {
"errorMessage": "[a1b2c3d4-5678-90ab-cdef-EXAMPLE22222]: Access denied",
"errorCode": "org.apache.kafka.common.errors.SaslAuthenticationException"
}
}
```
### Le serveur n’a pas réussi à authentifier Lambda
Cette erreur indique que l’agent Kafka n’a pas réussi à authentifier Lambda. Cette erreur se produit dans les conditions suivantes :
+ Vous n’avez pas fourni de certificat client pour l’authentification mTLS.
+ Vous avez fourni un certificat client, mais les courtiers ne sont pas configurés pour utiliser l’authentification mTLS.
+ Les courtiers Kafka ne font pas confiance à un certificat client.
### Lambda n’a pas réussi à authentifier le serveur
Cette erreur indique que Lambda n’a pas réussi à authentifier l’agent Kafka. Cette erreur se produit dans les conditions suivantes :
+ Pour Apache Kafka autogéré : les agents Kafka utilisent des certificats autosignés ou une autorité de certification privée, mais n’ont pas fourni le certificat CA racine du serveur.
+ Pour Apache Kafka autogéré : le certificat CA racine du serveur ne correspond pas à l’autorité de certification racine qui a signé le certificat de l’agent.
+ La validation du nom d’hôte a échoué, car le certificat du courtier ne contient pas le nom DNS ou l’adresse IP du courtier comme autre nom de sujet.
### Le certificat ou la clé privée fournis n’est pas valide
Cette erreur indique que le consommateur Kafka n’a pas pu utiliser le certificat ou la clé privée fournis. Assurez-vous que le certificat et la clé utilisent le format PEM et que le chiffrement par clé privée utilise un PBES1 algorithme.
Voici un exemple de journal au niveau du système ESM après avoir activé Logging [Config](esm-logging.md) pour ce problème :
```
{
"eventType": "ESM_PROCESSING_EVENT",
"timestamp": 1734567891234,
"resourceArn": "arn:aws:lambda:us-east-1:123456789012:event-source-mapping:a1b2c3d4-5678-90ab-cdef-EXAMPLE44444",
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/my-kafka-cluster/12345678-abcd-1234-efgh-EXAMPLE44444-1",
"eventProcessorId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE44444/0",
"logLevel": "WARN",
"error": {
"errorMessage": "Invalid PEM keystore configs",
"errorCode": "org.apache.kafka.common.errors.InvalidConfigurationException"
}
}
```
## Erreurs de réseau et de connectivité
Des problèmes de configuration réseau peuvent empêcher Lambda de se connecter à votre cluster Kafka. Les rubriques suivantes décrivent les erreurs réseau courantes.
**Topics**
+ [Délai de connexion dû à la configuration du groupe de sécurité](#kafka-security-group-errors)
+ [Les points de terminaison du courtier Kafka ne peuvent pas être résolus](#kafka-cluster-deleted-errors)
### Délai de connexion dû à la configuration du groupe de sécurité
Si le groupe de sécurité associé à votre cluster Kafka n'autorise pas le trafic entrant en provenance de lui-même, Lambda ne peut pas se connecter au cluster. Assurez-vous que les règles entrantes du groupe de sécurité autorisent le trafic provenant du groupe de sécurité lui-même sur les ports du courtier Kafka.
Voici un exemple de journal au niveau du système ESM après avoir activé Logging [Config](esm-logging.md) pour ce problème :
```
{
"eventType": "ESM_PROCESSING_EVENT",
"timestamp": 1734567892345,
"resourceArn": "arn:aws:lambda:us-east-1:123456789012:event-source-mapping:a1b2c3d4-5678-90ab-cdef-EXAMPLE55555",
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/my-kafka-cluster/12345678-abcd-1234-efgh-EXAMPLE55555-1",
"eventProcessorId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE55555/0",
"logLevel": "WARN",
"error": {
"errorMessage": "Timeout expired while fetching topic metadata",
"errorCode": "org.apache.kafka.common.errors.TimeoutException"
}
}
```
Vous pouvez également consulter le journal Kafka Consumer INFO pour vérifier la connexion et la configuration du réseau. Le `brokerEndpoints` champ indique les adresses du courtier Kafka `securityProtocol` et `saslMechanism` (le cas échéant) indique la méthode d'authentification, et le `networkConfig` champ indique les adresses IP, le bloc CIDR du sous-réseau et les groupes de sécurité utilisés par le mappage des sources d'événements. Vérifiez que les groupes de sécurité répertoriés autorisent le trafic entrant requis :
```
{
"eventType": "POLLER_STATUS_EVENT",
"timestamp": 1734567892456,
"resourceArn": "arn:aws:lambda:us-east-1:123456789012:event-source-mapping:a1b2c3d4-5678-90ab-cdef-11111EXAMPLE",
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/my-kafka-cluster/a1b2c3d4-5678-90ab-cdef-11111EXAMPLE-1",
"eventProcessorId": "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE/0",
"logLevel": "INFO",
"kafkaEventSourceConnection": {
"brokerEndpoints": "boot-abcd1234.c2.kafka-serverless.us-east-1.amazonaws.com:9098",
"consumerId": "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE-0",
"topics": [
"my-topic"
],
"consumerGroupId": "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE",
"securityProtocol": "SASL_SSL",
"saslMechanism": "AWS_MSK_IAM",
"totalPartitionCount": 2,
"assignedPartitionCount": 2,
"partitionsAssignmentGeneration": 1,
"assignedPartitions": [
"my-topic-0",
"my-topic-1"
],
"networkConfig": {
"ipAddresses": [
"10.0.0.37"
],
"subnetCidrBlock": "10.0.0.32/28",
"securityGroups": [
"sg-0123456789abcdef0"
]
}
}
}
```
### Les points de terminaison du courtier Kafka ne peuvent pas être résolus
Cette erreur indique que le cluster Kafka n'existe pas ou a été supprimé. Vérifiez que le cluster spécifié dans le mappage des sources d'événements existe et est dans un état actif.
Voici un exemple de journal au niveau du système ESM après avoir activé Logging [Config](esm-logging.md) pour ce problème :
```
{
"eventType": "ESM_PROCESSING_EVENT",
"timestamp": 1734567893456,
"resourceArn": "arn:aws:lambda:us-east-1:123456789012:event-source-mapping:a1b2c3d4-5678-90ab-cdef-EXAMPLE66666",
"eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/my-kafka-cluster/12345678-abcd-1234-efgh-EXAMPLE66666-1",
"eventProcessorId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE66666/0",
"logLevel": "WARN",
"error": {
"errorMessage": "No resolvable bootstrap urls given in bootstrap.servers",
"errorCode": "org.apache.kafka.common.config.ConfigException"
}
}
```
## API de mappage des sources d’événements
Lorsque vous ajoutez votre cluster Apache Kafka en tant que [source d’événement](invocation-eventsourcemapping.md) pour votre fonction Lambda, si votre fonction rencontre une erreur, votre consommateur Kafka cesse de traiter les registres. Les consommateurs d’une partition de rubrique sont ceux qui s’abonnent à vos registres et qui les lisent et traitent. Vos autres consommateurs Kafka peuvent continuer à traiter les registres, à condition qu’ils ne rencontrent pas la même erreur.
Afin d’identifier les raisons pour lesquelles un consommateur cesse son traitement, vérifiez le champ `StateTransitionReason` dans la réponse de `EventSourceMapping`. La liste suivante décrit les erreurs de source d’événement que vous pouvez recevoir :
**`ESM_CONFIG_NOT_VALID`**
La configuration de mappage de source d’événement n’est pas valide.
**`EVENT_SOURCE_AUTHN_ERROR`**
Lambda n’a pas pu authentifier la source d’événement.
**`EVENT_SOURCE_AUTHZ_ERROR`**
Lambda ne dispose pas des autorisations requises pour accéder à la source d’événement.
**`FUNCTION_CONFIG_NOT_VALID`**
La configuration de la fonction n’est pas valide.
**Note**
Si vos registres d’événement Lambda dépassent la limite de taille autorisée de 6 Mo, il se peut qu’ils ne soient pas traités.
# Invocation d’une fonction Lambda à l’aide d’un point de terminaison Amazon API Gateway
Vous pouvez créer une API web avec un point de terminaison HTTP pour votre fonction Lambda à l’aide d’Amazon API Gateway. API Gateway fournit des outils pour créer et documenter des sites Web APIs qui acheminent les requêtes HTTP vers les fonctions Lambda. Vous pouvez sécuriser l’accès à votre API avec des contrôles d’authentification et d’autorisation. APIs Vous pouvez gérer le trafic sur Internet ou n'être accessible qu'au sein de votre VPC.
**Astuce**
Lambda propose deux méthodes pour appeler votre fonction via un point de terminaison HTTP : API Gateway et fonction Lambda. URLs Si vous ne savez pas quelle est la meilleure méthode pour votre cas d’utilisation, consultez [Sélection d’une méthode pour invoquer votre fonction Lambda à l’aide d’une requête HTTP](apig-http-invoke-decision.md).
Les ressources de votre API définissent une ou plusieurs méthodes, telles que GET ou POST. Les méthodes ont une intégration qui achemine les requêtes vers une fonction Lambda ou un autre type d’intégration. Vous pouvez définir chaque ressource et méthode individuellement, ou utiliser des types de ressource et de méthode spéciaux pour correspondre à toutes les demandes adaptées à un modèle. Une [ressource proxy](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html) attrape tous les chemins sous une ressource. La méthode `ANY` attrape toutes les méthodes HTTP.
**Topics**
+ [Choix d’un type d’API](#services-apigateway-apitypes)
+ [Ajout d’un point de terminaison public à votre fonction Lambda](#apigateway-add)
+ [Intégration de proxy](#apigateway-proxy)
+ [Format des événements](#apigateway-example-event)
+ [Format de la réponse](#apigateway-types-transforms)
+ [Permissions](#apigateway-permissions)
+ [Exemple d’application](#services-apigateway-samples)
+ [Le gestionnaire d'événements de Powertools pour Lambda AWS](#services-apigateway-powertools)
+ [Didacticiel : Utiliser Lambda avec Amazon API Gateway](services-apigateway-tutorial.md)
+ [Gestion des erreurs Lambda avec une API Gateway](services-apigateway-errors.md)
+ [Sélection d’une méthode pour invoquer votre fonction Lambda à l’aide d’une requête HTTP](apig-http-invoke-decision.md)
## Choix d’un type d’API
API Gateway prend en charge trois types de fonctions APIs qui invoquent des fonctions Lambda :
+ [API HTTP : API](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html) légère à faible latence RESTful .
+ [API REST : API](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html) personnalisable et riche en fonctionnalités RESTful .
+ [WebSocket API : API](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api.html) Web qui maintient des connexions persistantes avec les clients pour une communication en duplex intégral.
HTTP APIs et REST APIs traitent RESTful APIs les requêtes HTTP et renvoient des réponses. APIs Les protocoles HTTP sont plus récents et sont créés avec l'API API Gateway version 2. Les fonctionnalités suivantes sont nouvelles pour le protocole HTTP APIs :
**Fonctionnalités de l’API HTTP**
+ **Déploiements automatiques** – Lorsque vous modifiez des routages ou des intégrations, les modifications se déploient automatiquement sur des étapes pour lesquelles le déploiement automatique est activé.
+ **Étape par défaut** – Vous pouvez créer une étape par défaut (`$default`) pour servir les demandes au chemin d’accès racine de l’URL de votre API. Pour les étapes nommées, vous devez inclure le nom de l’étape au début du chemin d’accès.
+ **Configuration CORS** – Vous pouvez configurer votre API pour ajouter des en-têtes CORS aux réponses sortantes, au lieu de les ajouter manuellement dans votre code de fonction.
APIs Les REST sont RESTful APIs les classiques pris en charge par API Gateway depuis son lancement. REST propose APIs actuellement davantage de fonctionnalités de personnalisation, d'intégration et de gestion.
**Fonctionnalités de l’API REST**
+ **Types d'intégration** : REST APIs prend en charge les intégrations Lambda personnalisées. Avec une intégration personnalisée, vous pouvez envoyer uniquement le corps de la requête à la fonction, ou appliquer un modèle de transformation au corps de requête avant de l’envoyer à la fonction.
+ **Contrôle d'accès** : REST APIs prend en charge davantage d'options d'authentification et d'autorisation.
+ **Surveillance et suivi** : REST APIs prend en charge le AWS X-Ray suivi et des options de journalisation supplémentaires.
Pour une comparaison détaillée, consultez [Choisir entre HTTP APIs et REST APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-vs-rest.html) dans le *guide du développeur d'API Gateway*.
WebSocket APIs utilise également l'API API Gateway version 2 et prend en charge un ensemble de fonctionnalités similaires. Utilisez une WebSocket API pour les applications qui bénéficient d'une connexion permanente entre le client et l'API. WebSocket APIs fournissent une communication en duplex intégral, ce qui signifie que le client et l'API peuvent envoyer des messages en continu sans attendre de réponse.
Le protocole HTTP APIs prend en charge un format d'événement simplifié (version 2.0). Pour un exemple d'événement provenant d'une API HTTP, voir [Créer des intégrations de AWS Lambda proxy pour HTTP APIs dans API Gateway](https://docs.aws.amazon.com//apigateway/latest/developerguide/http-api-develop-integrations-lambda.html).
Pour plus d'informations, consultez la section [Création d'intégrations de AWS Lambda proxy pour HTTP APIs dans API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-lambda.html).
## Ajout d’un point de terminaison public à votre fonction Lambda
**Ajouter un point de terminaison public à votre fonction Lambda**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez une fonction.
1. Sous **Function overview (Vue d’ensemble de la fonction)**, choisissez **Add trigger (Ajouter un déclencheur)**.
1. Sélectionnez **API Gateway**.
1. Choisissez **Créer une API** ou **Utiliser une API existante**.
1. **Nouvelle API :** pour **Type d’API**, choisissez **API HTTP**. Pour de plus amples informations, veuillez consulter [Choix d’un type d’API](#services-apigateway-apitypes).
1. **API existante :** Sélectionnez l’API dans la liste déroulante ou entrez l’ID de l’API (par exemple, r3pmxmplak).
1. Pour **Sécurité**, choisissez **Ouvrir**.
1. Choisissez **Ajouter**.
## Intégration de proxy
API Gateway comprend APIs des étapes, des ressources, des méthodes et des intégrations. L’étape et la ressource déterminent le chemin du point de terminaison :
**Format du chemin d’accès de l’API**
+ `/prod/` – Etape `prod` et ressource racine.
+ `/prod/user` – Etape `prod` et ressource `user`.
+ `/dev/{proxy+}` – Routage quelconque à l’étape `dev`.
+ `/`— (HTTP APIs) Le stage par défaut et la ressource racine.
Une intégration Lambda mappe une combinaison de chemin d’accès et de méthode HTTP à une fonction Lambda. Vous pouvez configurer API Gateway pour transmettre le corps de la demande HTTP tel quel (intégration personnalisée) ou pour encapsuler le corps de requête dans un document qui inclut toutes les informations de la demande, y compris les en-têtes, la ressource, le chemin et la méthode.
Pour plus d’informations, consultez [Lambda proxy integrations in API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html).
## Format des événements
Amazon API Gateway appelle votre fonction [de manière synchrone](invocation-sync.md) avec un événement contenant une représentation JSON de la requête HTTP. Pour une intégration personnalisée, l’événement est le corps de la requête. Pour une intégration par proxy, l’événement a une structure définie. Pour obtenir un exemple d’événement de proxy à partir d’une API REST API Gateway, consultez la rubrique [Input format of a Lambda function for proxy integration](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format) du *guide du développeur API Gateway*.
## Format de la réponse
API Gateway attend une réponse de votre fonction et relaie le résultat à l’appelant. Pour une intégration personnalisée, vous définissez une réponse d’intégration et une réponse de méthode pour convertir la sortie de la fonction en réponse HTTP. Pour une intégration par proxy, la fonction doit répondre avec une représentation de la réponse dans un format spécifique.
L’exemple suivant montre un objet de réponse d’une fonction Node.js. L’objet de réponse représente une réponse HTTP réussie qui contient un document JSON.
**Example index.js : objet de réponse d’intégration de proxy (Node.js)**
```
var response = {
"statusCode": 200,
"headers": {
"Content-Type": "application/json"
},
"isBase64Encoded": false,
"multiValueHeaders": {
"X-Custom-Header": ["My value", "My other value"],
},
"body": "{\n \"TotalCodeSize\": 104330022,\n \"FunctionCount\": 26\n}"
}
```
L’environnement d’exécution Lambda sérialise l’objet réponse dans JSON et l’envoie à l’API. L’API analyse la réponse et l’utilise pour créer une réponse HTTP, qu’elle envoie ensuite au client qui a fait la demande d’origine.
**Example Réponse HTTP**
```
< HTTP/1.1 200 OK
< Content-Type: application/json
< Content-Length: 55
< Connection: keep-alive
< x-amzn-RequestId: 32998fea-xmpl-4268-8c72-16138d629356
< X-Custom-Header: My value
< X-Custom-Header: My other value
< X-Amzn-Trace-Id: Root=1-5e6aa925-ccecxmplbae116148e52f036
<
{
"TotalCodeSize": 104330022,
"FunctionCount": 26
}
```
## Permissions
Amazon API Gateway obtient l’autorisation d’appeler votre fonction à partir de la [politique basée sur une ressource](access-control-resource-based.md) de la fonction. Vous pouvez accorder l’autorisation d’appel à toute une API ou accorder un accès limité à une étape, à une ressource ou à une méthode.
Lorsque vous ajoutez une API à votre fonction à l’aide de la console Lambda, de la console API Gateway ou d’un modèle AWS SAM , la politique basée sur une ressource de la fonction est mise à jour automatiquement. Voici un exemple de politique de fonction.
**Example stratégie de fonction**
****
```
{
"Version":"2012-10-17",
"Id": "default",
"Statement": [
{
"Sid": "nodejs-apig-functiongetEndpointPermissionProd-BWDBXMPLXE2F",
"Effect": "Allow",
"Principal": {
"Service": "apigateway.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-2:111122223333:function:nodejs-apig-function-1G3MXMPLXVXYI",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:execute-api:us-east-2:111122223333:ktyvxmpls1/*/GET/"
}
}
}
]
}
```
Vous pouvez gérer manuellement les autorisations de politique de fonction à l’aide des opérations d’API suivantes :
+ [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html)
+ [RemovePermission](https://docs.aws.amazon.com/lambda/latest/api/API_RemovePermission.html)
+ [GetPolicy](https://docs.aws.amazon.com/lambda/latest/api/API_GetPolicy.html)
Pour accorder l’autorisation d’invocation à une API existante, utilisez la commande `add-permission`. Exemple :
```
aws lambda add-permission \
--function-name my-function \
--statement-id apigateway-get --action lambda:InvokeFunction \
--principal apigateway.amazonaws.com \
--source-arn "arn:aws:execute-api:us-east-2:123456789012:mnh1xmpli7/default/GET/"
```
Vous devriez voir la sortie suivante :
```
{
"Statement": "{\"Sid\":\"apigateway-test-2\",\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"apigateway.amazonaws.com\"},\"Action\":\"lambda:InvokeFunction\",\"Resource\":\"arn:aws:lambda:us-east-2:123456789012:function:my-function\",\"Condition\":{\"ArnLike\":{\"AWS:SourceArn\":\"arn:aws:execute-api:us-east-2:123456789012:mnh1xmpli7/default/GET\"}}}"
}
```
**Note**
Si votre fonction et votre API sont différentes Régions AWS, l'identifiant de région dans l'ARN source doit correspondre à la région de la fonction, et non à la région de l'API. Quand API Gateway appelle une fonction, elle utilise un ARN de ressource basé sur l’ARN de l’API, mais modifié pour correspondre à la Région de la fonction.
L’ARN source dans cet exemple accorde l’autorisation à une intégration sur la méthode GET de la ressource racine au cours de l’étape par défaut d’une API, avec l’ID `mnh1xmpli7`. Vous pouvez utiliser un astérisque dans l’ARN source pour accorder des autorisations à plusieurs étapes, méthodes ou ressources.
**Modèles de ressources**
+ `mnh1xmpli7/*/GET/*` – Méthode GET sur toutes les ressources à toutes les étapes.
+ `mnh1xmpli7/prod/ANY/user` – Méthode ANY sur la ressource `user` à l’étape `prod`.
+ `mnh1xmpli7/*/*/*` – Toute méthode sur toutes les ressources à toutes les étapes.
Pour de plus amples informations sur l’affichage de la politique et la suppression des instructions, veuillez consulter [Voir les politiques IAM basées sur les ressources dans Lambda](access-control-resource-based.md).
## Exemple d’application
L'exemple d'application [API Gateway with Node.js](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/nodejs-apig) inclut une fonction avec un AWS SAM modèle qui crée une API REST dont le AWS X-Ray suivi est activé. Il inclut également des scripts pour le déploiement, l’invocation de la fonction, le test de l’API et le nettoyage.
## Le gestionnaire d'événements de Powertools pour Lambda AWS
Le gestionnaire d'événements du kit d'outils Powertools for AWS Lambda fournit le routage, le middleware, la configuration CORS, la génération de spécifications OpenAPI, la validation des demandes, la gestion des erreurs et d'autres fonctionnalités utiles lors de l'écriture de fonctions Lambda invoquées par un point de terminaison API Gateway (HTTP ou REST). L'utilitaire de gestion d'événements est disponible pour Python et TypeScript/JavaScript. Pour plus d'informations, consultez l'[API REST du gestionnaire d'événements](https://docs.powertools.aws.dev/lambda/python/latest/core/event_handler/api_gateway/) dans la documentation de *Powertools pour AWS Lambda (Python)* [et l'API HTTP du gestionnaire d'événements](https://docs.aws.amazon.com/powertools/typescript/latest/features/event-handler/http/) dans la documentation de *Powertools pour AWS * Lambda (). TypeScript
### Python
```
from aws_lambda_powertools import Logger
from aws_lambda_powertools.event_handler import APIGatewayRestResolver
from aws_lambda_powertools.logging import correlation_paths
from aws_lambda_powertools.utilities.typing.lambda_context import LambdaContext
app = APIGatewayRestResolver()
logger = Logger()
@app.get("/healthz")
def ping():
return {"message": "health status ok"}
@logger.inject_lambda_context(correlation_id_path=correlation_paths.API_GATEWAY_REST)
def lambda_handler(event: dict, context: LambdaContext) -> dict:
return app.resolve(event, context)
```
### TypeScript
```
import { Router } from '@aws-lambda-powertools/event-handler/experimental-rest';
import { Logger } from '@aws-lambda-powertools/logger';
import {
correlationPaths,
search,
} from '@aws-lambda-powertools/logger/correlationId';
import type { Context } from 'aws-lambda/handler';
const logger = new Logger({
correlationIdSearchFn: search,
});
const app = new Router({ logger });
app.get("/healthz", async () => {
return { message: "health status ok" };
});
export const handler = async (event: unknown, context: Context) => {
// You can continue using other utilities just as before
logger.addContext(context);
logger.setCorrelationId(event, correlationPaths.API_GATEWAY_REST);
return app.resolve(event, context);
};
```
# Didacticiel : Utiliser Lambda avec Amazon API Gateway
Dans ce tutoriel, vous créez une API REST par laquelle vous invoquez une fonction Lambda à l’aide d’une demande HTTP. Votre fonction Lambda effectuera des opérations de création, lecture, mise à jour et suppression (CRUD) sur une table DynamoDB. Cette fonction est fournie ici à titre de démonstration, mais vous apprendrez à configurer une API REST API Gateway qui peut invoquer n’importe quelle fonction Lambda.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/APIG_tut_resources.png)
L’utilisation d’API Gateway fournit aux utilisateurs un point de terminaison HTTP sécurisé pour invoquer votre fonction Lambda et peut aider à gérer de gros volumes d’appels à votre fonction en limitant le trafic et en validant et autorisant automatiquement les appels d’API. API Gateway fournit également des contrôles de sécurité flexibles à l'aide de Gestion des identités et des accès AWS (IAM) et d'Amazon Cognito. Ceci est utile pour les cas d’utilisation où une autorisation préalable est requise pour les appels à votre application.
**Astuce**
Lambda propose deux méthodes pour appeler votre fonction via un point de terminaison HTTP : API Gateway et fonction Lambda. URLs Si vous ne savez pas quelle est la meilleure méthode pour votre cas d’utilisation, consultez [Sélection d’une méthode pour invoquer votre fonction Lambda à l’aide d’une requête HTTP](apig-http-invoke-decision.md).
Pour réaliser ce tutoriel, vous passerez par les étapes suivantes :
1. Créer et configurer une fonction Lambda en Python ou Node.js pour effectuer des opérations sur une table DynamoDB.
1. Créer une API REST dans API Gateway pour se connecter à votre fonction Lambda.
1. Créer une table DynamoDB et la tester avec votre fonction Lambda dans la console.
1. Déployer votre API et tester la configuration complète en utilisant curl dans un terminal.
En suivant ces étapes, vous apprendrez à utiliser API Gateway pour créer un point de terminaison HTTP capable d’invoquer en toute sécurité une fonction Lambda à n’importe quelle échelle. Vous apprendrez également à déployer votre API, et à la tester dans la console et en envoyant une demande HTTP à l’aide d’un terminal.
## Création d’une stratégie d’autorisations
Avant de créer un [rôle d'exécution](lambda-intro-execution-role.md) pour votre fonction Lambda, vous devez d'abord créer une politique d'autorisation pour autoriser votre fonction à accéder aux ressources requises AWS . Pour ce didacticiel, la politique permet à Lambda d'effectuer des opérations CRUD sur une table DynamoDB et d'écrire sur Amazon Logs. CloudWatch
**Pour créer la politique**
1. Ouvrez la [page stratégies](https://console.aws.amazon.com/iam/home#/policies) de la console IAM.
1. Choisissez **Créer une stratégie**.
1. Choisissez l’onglet **JSON**, puis collez la stratégie personnalisée suivante dans l’éditeur JSON.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Stmt1428341300017",
"Action": [
"dynamodb:DeleteItem",
"dynamodb:GetItem",
"dynamodb:PutItem",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:UpdateItem"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Sid": "",
"Resource": "*",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Effect": "Allow"
}
]
}
```
------
1. Choisissez **Suivant : Balises**.
1. Choisissez **Suivant : Vérification**.
1. Sous **Examiner une stratégie**, pour le **Nom** de la stratégie, saisissez **lambda-apigateway-policy**.
1. Choisissez **Créer une stratégie**.
## Créer un rôle d’exécution
Un [rôle d'exécution](lambda-intro-execution-role.md) est un rôle Gestion des identités et des accès AWS (IAM) qui accorde à une fonction Lambda l'autorisation d' Services AWS accès et de ressources. Pour permettre à votre fonction d’effectuer des opérations sur une table DynamoDB, vous attachez la politique d’autorisation que vous avez créée à l’étape précédente.
**Pour créer un rôle d’exécution et attacher votre politique d’autorisations personnalisée**
1. Ouvrez la [page Rôles](https://console.aws.amazon.com/iam/home#/roles) de la console IAM.
1. Sélectionnez **Créer un rôle**.
1. Pour le type d’entité de confiance, choisissez **Service AWS **, puis pour le cas d’utilisation, choisissez **Lambda**.
1. Choisissez **Suivant**.
1. Dans la zone de recherche de stratégie, entrez **lambda-apigateway-policy**.
1. Dans les résultats de la recherche, sélectionnez la stratégie que vous avez créée (`lambda-apigateway-policy`), puis choisissez **Suivant**.
1. Sous **Role details** (Détails du rôle), pour **Role name** (Nom du rôle), saisissez **lambda-apigateway-role**, puis sélectionnez **Create role** (Créer un rôle).
## Créer la fonction Lambda
1. Ouvrez la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda et choisissez **Créer une fonction**.
1. Choisissez **Créer à partir de zéro**.
1. Sous **Nom de la fonction**, saisissez `LambdaFunctionOverHttps`.
1. Pour **Exécution**, choisissez le dernier environnement d’exécution Node.js ou Python.
1. Sous **Permissions** (Autorisations), développez **Change default execution role** (Modifier le rôle d’exécution par défaut).
1. Sélectionnez **Utiliser un rôle existant**, sélectionnez le rôle **lambda-apigateway-role** que vous avez créé précédemment.
1. Choisissez **Créer une fonction**.
1. Dans le volet **Source du code**, remplacez le code par défaut par le code Node.js ou Python suivant.
------
#### [ Node.js ]
Le `region` paramètre doit correspondre à l' Région AWS endroit où vous déployez la fonction et [créez la table DynamoDB](#services-apigateway-tutorial-table).
**Example index.mjs**
```
import { DynamoDBDocumentClient, PutCommand, GetCommand,
UpdateCommand, DeleteCommand} from "@aws-sdk/lib-dynamodb";
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
const ddbClient = new DynamoDBClient({ region: "us-east-2" });
const ddbDocClient = DynamoDBDocumentClient.from(ddbClient);
// Define the name of the DDB table to perform the CRUD operations on
const tablename = "lambda-apigateway";
/**
* Provide an event that contains the following keys:
*
* - operation: one of 'create,' 'read,' 'update,' 'delete,' or 'echo'
* - payload: a JSON object containing the parameters for the table item
* to perform the operation on
*/
export const handler = async (event, context) => {
const operation = event.operation;
if (operation == 'echo'){
return(event.payload);
}
else {
event.payload.TableName = tablename;
let response;
switch (operation) {
case 'create':
response = await ddbDocClient.send(new PutCommand(event.payload));
break;
case 'read':
response = await ddbDocClient.send(new GetCommand(event.payload));
break;
case 'update':
response = ddbDocClient.send(new UpdateCommand(event.payload));
break;
case 'delete':
response = ddbDocClient.send(new DeleteCommand(event.payload));
break;
default:
response = 'Unknown operation: ${operation}';
}
console.log(response);
return response;
}
};
```
------
#### [ Python ]
**Example lambda\$1function.py**
```
import boto3
# Define the DynamoDB table that Lambda will connect to
table_name = "lambda-apigateway"
# Create the DynamoDB resource
dynamo = boto3.resource('dynamodb').Table(table_name)
# Define some functions to perform the CRUD operations
def create(payload):
return dynamo.put_item(Item=payload['Item'])
def read(payload):
return dynamo.get_item(Key=payload['Key'])
def update(payload):
return dynamo.update_item(**{k: payload[k] for k in ['Key', 'UpdateExpression',
'ExpressionAttributeNames', 'ExpressionAttributeValues'] if k in payload})
def delete(payload):
return dynamo.delete_item(Key=payload['Key'])
def echo(payload):
return payload
operations = {
'create': create,
'read': read,
'update': update,
'delete': delete,
'echo': echo,
}
def lambda_handler(event, context):
'''Provide an event that contains the following keys:
- operation: one of the operations in the operations dict below
- payload: a JSON object containing parameters to pass to the
operation being performed
'''
operation = event['operation']
payload = event['payload']
if operation in operations:
return operations[operation](payload)
else:
raise ValueError(f'Unrecognized operation "{operation}"')
```
------
**Note**
Dans cet exemple, le nom de la table DynamoDB est défini comme une variable dans le code de votre fonction. Dans une application réelle, passer ce paramètre comme une variable d’environnement et éviter de coder en dur le nom de la table constitue une bonne pratique. Pour plus d'informations, voir [Utilisation de variables d' AWS Lambda environnement](https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html).
1. Dans la section **DÉPLOYER**, choisissez **Déployer** pour mettre à jour le code de votre fonction :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/getting-started-tutorial/deploy-console.png)
## Tester la fonction
Avant d’intégrer votre fonction à API Gateway, confirmez que vous avez déployé la fonction avec succès. Utilisez la console Lambda pour envoyer un événement de test à votre fonction.
1. Dans la page de votre fonction de la console Lambda, choisissez l’onglet **Tester**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/test-tab.png)
1. Défilez jusqu’à la section **JSON d’événement** et remplacez l’événement par défaut par ce qui suit. Cet événement correspond à la structure attendue par la fonction Lambda.
```
{
"operation": "echo",
"payload": {
"somekey1": "somevalue1",
"somekey2": "somevalue2"
}
}
```
1. Sélectionnez **Tester)**.
1. Sous **Exécution de la fonction : succès**, développez **Détails**. Vous devriez voir la réponse suivante :
```
{
"somekey1": "somevalue1",
"somekey2": "somevalue2"
}
```
## Créer une API REST avec API Gateway
Dans cette étape, vous créez l’API REST API Gateway que vous utiliserez pour invoquer votre fonction Lambda.
**Pour créer l’API**
1. Ouvrez la [console API Gateway](https://console.aws.amazon.com/apigateway).
1. Sélectionnez **Create API** (Créer une API).
1. Dans la boîte de dialogue **API REST**, choisissez **Créer**.
1. Sous **Détails de l’API**, laissez **Nouvelle API** sélectionnée et pour **Nom de l’API**, saisissez **DynamoDBOperations**.
1. Sélectionnez **Create API** (Créer une API).
## Créez une ressource sur votre API REST
Pour ajouter une méthode HTTP à votre API, vous devez d’abord créer une ressource pour que cette méthode puisse fonctionner. Ici, vous créez la ressource pour gérer votre table DynamoDB.
**Pour créer la ressource**
1. Dans la [console API Gateway](https://console.aws.amazon.com/apigateway), sur la page **Ressources** de votre API, choisissez **Créer une ressource**.
1. Dans **Détails de la ressource**, pour **Nom de la ressource** saisissez **DynamoDBManager**.
1. Choisissez **Create Resource**.
## Création d’une méthode HTTP POST
Dans cette étape, vous créez une méthode (`POST`) pour votre ressource `DynamoDBManager`. Vous liez cette méthode `POST` à votre fonction Lambda de sorte que lorsque la méthode reçoit une demande HTTP, API Gateway invoque votre fonction Lambda.
**Note**
Dans le cadre de ce tutoriel, une méthode HTTP (`POST`) est utilisée pour invoquer une seule fonction Lambda qui exécute toutes les opérations sur votre table DynamoDB. Dans une application réelle, l’utilisation d’une fonction Lambda et d’une méthode HTTP différentes pour chaque opération constitue une bonne pratique. Pour plus d’informations, consultez [Le monolithe Lambda](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/monolith) dans Serverless Land.
**Pour créer la méthode POST**
1. Sur la page **Ressources** de votre API, assurez-vous que la ressource `/DynamoDBManager` est surlignée. Ensuite, dans le volet **Méthodes**, choisissez **Créer une méthode**.
1. Pour **Type de méthode**, sélectionnez **POST**.
1. Pour **Type d’intégration**, laissez la **Fonction Lambda** sélectionnée.
1. Pour la **Fonction Lambda**, choisissez l’Amazon Resource Name (ARN) pour votre fonction (`LambdaFunctionOverHttps`).
1. Choisissez **Créer une méthode**.
## Créez une table DynamoDB
Créez une table DynamoDB vide sur laquelle votre fonction Lambda effectuera des opérations CRUD.
**Créer le tableau DynamoDB**
1. Ouvrez la [page Tables (Tables)](https://console.aws.amazon.com/dynamodbv2#tables) de la console DynamoDB.
1. Choisissez **Créer un tableau**.
1. Sous **Détails du tableau**, procédez comme suit :
1. Sous **Nom du tableau**, saisissez **lambda-apigateway**.
1. Pour **Clé de partition**, saisissez **id**, et conservez le type de données défini comme **Chaîne**.
1. Sous **Table settings** (Paramètres de la table), conservez les **Default settings** (Paramètres par défaut).
1. Choisissez **Créer un tableau**.
## Test de l’intégration d’API Gateway, Lambda et DynamoDB
Vous êtes maintenant prêt à tester l’intégration de votre méthode API Gateway avec votre fonction Lambda et votre table DynamoDB. À l’aide de la console API Gateway, vous envoyez des demandes directement à votre méthode `POST` en utilisant la fonction de test de la console. Dans cette étape, vous utilisez d’abord une opération `create` pour ajouter un nouvel élément à votre table DynamoDB, puis vous utilisez une opération `update` pour modifier l’élément.
**Test 1 : Pour créer un nouvel élément dans votre table DynamoDB**
1. Dans la [console API Gateway](https://console.aws.amazon.com/apigateway), choisissez votre API (`DynamoDBOperations`).
1. Choisissez la méthode **POST** sous la ressource `DynamoDBManager`.
1. Choisissez l’onglet **Test**. Vous devrez peut-être choisir la flèche droite pour afficher l’onglet.
1. Sous **Méthode de test**, laissez les **Chaînes de requête** et les **En-têtes** vides. Pour **Corps de requête**, collez l’élément JSON suivant :
```
{
"operation": "create",
"payload": {
"Item": {
"id": "1234ABCD",
"number": 5
}
}
}
```
1. Sélectionnez **Tester)**.
Les résultats qui s’affichent à la fin du test doivent indiquer le statut `200`. Ce code d’état indique que l’opération `create` a réussi.
Pour confirmer, vérifiez que votre table DynamoDB contient maintenant le nouvel élément.
1. Ouvrez la [page Tables](https://console.aws.amazon.com/dynamodbv2#tables) de la console DynamoDB et choisissez la table `lambda-apigateway`.
1. Choisissez **Explore table items** (Explorer les éléments de la table). Dans le volet **Items returned** (Éléments retournés), vous devriez voir un élément avec l’**id** `1234ABCD` et le **numéro** `5`. Exemple :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/items-returned.png)
**Test 2 : Pour mettre à jour l’élément dans votre table DynamoDB**
1. Dans la [Console API Gateway](https://console.aws.amazon.com/apigateway), revenez à l’onglet **Test** votre méthode POST.
1. Sous **Méthode de test**, laissez les **Chaînes de requête** et les **En-têtes** vides. Pour **Corps de requête**, collez l’élément JSON suivant :
```
{
"operation": "update",
"payload": {
"Key": {
"id": "1234ABCD"
},
"UpdateExpression": "SET #num = :newNum",
"ExpressionAttributeNames": {
"#num": "number"
},
"ExpressionAttributeValues": {
":newNum": 10
}
}
}
```
1. Sélectionnez **Tester)**.
Les résultats qui s’affichent à la fin du test devraient montrer l’état `200`. Ce code d’état indique que l’opération `update` a réussi.
Pour confirmer, vérifiez que l’élément dans votre table DynamoDB a été modifié.
1. Ouvrez la [page Tables](https://console.aws.amazon.com/dynamodbv2#tables) de la console DynamoDB et choisissez la table `lambda-apigateway`.
1. Choisissez **Explore table items** (Explorer les éléments de la table). Dans le volet **Items returned** (Éléments retournés), vous devriez voir un élément avec l’**id** `1234ABCD` et le **numéro** `10`.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/items-returned-2.png)
## Déploiement de l’API
Pour qu’un client puisse appeler l’API, vous devez créer un déploiement et une étape associée. Une étape représente un instantané de votre API, y compris ses méthodes et intégrations.
**Pour déployer l’API**
1. Ouvrez la **APIs**page de la [console API Gateway](https://console.aws.amazon.com/apigateway) et choisissez l'`DynamoDBOperations`API.
1. Sur la page **Ressources** de votre API, choisissez **Deploy API** (Déployer l’API).
1. Pour **Stage** (Étape), choisissez **\$1New stage\$1** (Nouvelle étape), puis pour **Stage name** (Nom de l’étape), saisissez **test**.
1. Choisissez **Déployer**.
1. Dans le volet **Stage details** (Détails de l’étape), copiez **Invoke URL** (URL d’invocation). Vous l’utiliserez à l’étape suivante pour invoquer votre fonction à l’aide d’une demande HTTP.
## Utilisez curl pour invoquer votre fonction à l’aide de demandes HTTP
Vous pouvez maintenant invoquer votre fonction Lambda en émettant une demande HTTP vers votre API. Dans cette étape, vous allez créer un nouvel élément dans votre table DynamoDB, puis effectuer des oéprations de lecture, de mise à jour et de suppression sur cet élément.
**Pour créer un élément dans votre table DynamoDB à l’aide de curl**
1. Ouvrez un terminal ou une invite de commande sur votre machine locale et exécutez la commande `curl` suivante en utilisant l’URL d’invocation que vous avez copiée à l’étape précédente. Cette commande utilise les options suivantes :
+ `-H` : ajoute un en-tête personnalisé à la demande. Ici, le paramètre spécifie le type de contenu comme étant du JSON.
+ `-d` : envoie des données dans le corps de la demande. Cette option utilise une méthode HTTP POST par défaut.
------
#### [ Linux/macOS ]
```
curl https://l8togsqxd8.execute-api.us-east-2.amazonaws.com/test/DynamoDBManager \
-H "Content-Type: application/json" \
-d '{"operation": "create", "payload": {"Item": {"id": "5678EFGH", "number": 15}}}'
```
------
#### [ PowerShell ]
```
curl.exe 'https://l8togsqxd8.execute-api.us-east-2.amazonaws.com/test/DynamoDBManager' -H 'Content-Type: application/json' -d '{\"operation\": \"create\", \"payload\": {\"Item\": {\"id\": \"5678EFGH\", \"number\": 15}}}'
```
------
Si l’opération a réussi, vous devriez voir une réponse renvoyée avec un code d’état HTTP de 200.
1. Vous pouvez également utiliser la console DynamoDB pour vérifier que le nouvel élément figure dans votre table en procédant comme suit :
1. Ouvrez la [page Tables](https://console.aws.amazon.com/dynamodbv2#tables) de la console DynamoDB et choisissez la table `lambda-apigateway`.
1. Sélectionnez **Explore table items** (Explorer les éléments de la table). Dans le volet **Items returned** (Éléments retournés), vous devriez voir un élément avec l’**id** `5678EFGH` et le **numéro** `15`.
**Pour lire l’élément dans votre table DynamoDB à l’aide de curl**
+ Dans votre terminal ou invite de commande, exécutez la commande `curl` suivante pour lire la valeur l’élément que vous venez de créer. Utilisez votre propre URL invoquée.
------
#### [ Linux/macOS ]
```
curl https://l8togsqxd8.execute-api.us-east-2.amazonaws.com/test/DynamoDBManager \
-H "Content-Type: application/json" \
-d '{"operation": "read", "payload": {"Key": {"id": "5678EFGH"}}}'
```
------
#### [ PowerShell ]
```
curl.exe 'https://l8togsqxd8.execute-api.us-east-2.amazonaws.com/test/DynamoDBManager' -H 'Content-Type: application/json' -d '{\"operation\": \"read\", \"payload\": {\"Key\": {\"id\": \"5678EFGH\"}}}'
```
------
Vous devriez obtenir un résultat semblable à l’un des suivants selon que vous avez choisi le code de fonction Node.js ou Python :
------
#### [ Node.js ]
```
{"$metadata":{"httpStatusCode":200,"requestId":"7BP3G5Q0C0O1E50FBQI9NS099JVV4KQNSO5AEMVJF66Q9ASUAAJG",
"attempts":1,"totalRetryDelay":0},"Item":{"id":"5678EFGH","number":15}}
```
------
#### [ Python ]
```
{"Item":{"id":"5678EFGH","number":15},"ResponseMetadata":{"RequestId":"QNDJICE52E86B82VETR6RKBE5BVV4KQNSO5AEMVJF66Q9ASUAAJG",
"HTTPStatusCode":200,"HTTPHeaders":{"server":"Server","date":"Wed, 31 Jul 2024 00:37:01 GMT","content-type":"application/x-amz-json-1.0",
"content-length":"52","connection":"keep-alive","x-amzn-requestid":"QNDJICE52E86B82VETR6RKBE5BVV4KQNSO5AEMVJF66Q9ASUAAJG","x-amz-crc32":"2589610852"},
"RetryAttempts":0}}
```
------
**Pour mettre à jour l’élément dans votre table DynamoDB à l’aide de curl**
1. Dans votre terminal ou invite de commande, exécutez la commande `curl` suivante pour mettre à jour l’élément que vous venez de créer en modifiant la valeur `number`. Utilisez votre propre URL invoquée.
------
#### [ Linux/macOS ]
```
curl https://l8togsqxd8.execute-api.us-east-2.amazonaws.com/test/DynamoDBManager \
-H "Content-Type: application/json" \
-d '{"operation": "update", "payload": {"Key": {"id": "5678EFGH"}, "UpdateExpression": "SET #num = :new_value", "ExpressionAttributeNames": {"#num": "number"}, "ExpressionAttributeValues": {":new_value": 42}}}'
```
------
#### [ PowerShell ]
```
curl.exe 'https://l8togsqxd8.execute-api.us-east-2.amazonaws.com/test/DynamoDBManager' -H 'Content-Type: application/json' -d '{\"operation\": \"update\", \"payload\": {\"Key\": {\"id\": \"5678EFGH\"}, \"UpdateExpression\": \"SET #num = :new_value\", \"ExpressionAttributeNames\": {\"#num\": \"number\"}, \"ExpressionAttributeValues\": {\":new_value\": 42}}}'
```
------
1. Pour confirmer que la valeur de `number` de l’élément a été mise à jour, exécutez une autre commande de lecture :
------
#### [ Linux/macOS ]
```
curl https://l8togsqxd8.execute-api.us-east-2.amazonaws.com/test/DynamoDBManager \
-H "Content-Type: application/json" \
-d '{"operation": "read", "payload": {"Key": {"id": "5678EFGH"}}}'
```
------
#### [ PowerShell ]
```
curl.exe 'https://l8togsqxd8.execute-api.us-east-2.amazonaws.com/test/DynamoDBManager' -H 'Content-Type: application/json' -d '{\"operation\": \"read\", \"payload\": {\"Key\": {\"id\": \"5678EFGH\"}}}'
```
------
**Pour supprimer l’élément dans votre table DynamoDB à l’aide de curl**
1. Dans votre terminal ou invite de commande, exécutez la commande `curl` suivante pour supprimer l’élément que vous venez de créer. Utilisez votre propre URL invoquée.
------
#### [ Linux/macOS ]
```
curl https://l8togsqxd8.execute-api.us-east-2.amazonaws.com/test/DynamoDBManager \
-H "Content-Type: application/json" \
-d '{"operation": "delete", "payload": {"Key": {"id": "5678EFGH"}}}'
```
------
#### [ PowerShell ]
```
curl.exe 'https://l8togsqxd8.execute-api.us-east-2.amazonaws.com/test/DynamoDBManager' -H 'Content-Type: application/json' -d '{\"operation\": \"delete\", \"payload\": {\"Key\": {\"id\": \"5678EFGH\"}}}'
```
------
1. Confirmez que l’opération de suppression a réussi. Dans le volet **Items returned** (Éléments retournés) de la page **Explore items** (Explorer les éléments) de la console DynamoDB, vérifiez que l’élément avec l’**id** `5678EFGH` n’est plus dans la table.
## Nettoyer vos ressources (facultatif)
Vous pouvez maintenant supprimer les ressources que vous avez créées pour ce didacticiel, sauf si vous souhaitez les conserver. En supprimant AWS les ressources que vous n'utilisez plus, vous évitez des frais inutiles pour votre Compte AWS.
**Pour supprimer la fonction Lambda**
1. Ouvrez la [page Functions (Fonctions)](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda.
1. Sélectionnez la fonction que vous avez créée.
1. Sélectionnez **Actions**, **Supprimer**.
1. Saisissez **confirm** dans la zone de saisie de texte et choisissez **Delete** (Supprimer).
**Pour supprimer le rôle d’exécution**
1. Ouvrez la [page Roles (Rôles)](https://console.aws.amazon.com/iam/home#/roles) de la console IAM.
1. Sélectionnez le rôle d’exécution que vous avez créé.
1. Sélectionnez **Delete (Supprimer)**.
1. Saisissez le nom du rôle dans le champ de saisie de texte et choisissez **Delete** (Supprimer).
**Pour supprimer l’API**
1. Ouvrez la [APIs page](https://console.aws.amazon.com/apigateway/main/apis) de la console API Gateway.
1. Sélectionnez l’API que vous avez créée.
1. Sélectionnez **Actions**, **Supprimer**.
1. Sélectionnez **Supprimer**.
**Pour supprimer la table DynamoDB**
1. Ouvrez la [page Tables (Tables)](https://console.aws.amazon.com//dynamodb/home#tables:) de la console DynamoDB.
1. Sélectionnez la table que vous avez créée.
1. Choisissez **Supprimer**.
1. Saisissez **delete** dans la zone de texte.
1. Choisissez **Supprimer la table**.
# Gestion des erreurs Lambda avec une API Gateway
API Gateway traite toutes les erreurs d’invocation et de fonction comme des erreurs internes. Si l’API Lambda rejette la demande d’invocation, API Gateway renvoie un code d’erreur 500. Si la fonction s’exécute mais renvoie une erreur ou une réponse dans un format inadéquat, API Gateway renvoie un code d’erreur 502. Dans les deux cas, le corps de la réponse d’API Gateway est `{"message": "Internal server error"}`.
**Note**
API Gateway ne fait aucune nouvelle tentative d’appel Lambda. Si Lambda renvoie une erreur, API Gateway renvoie une réponse d’erreur au client.
L’exemple suivant montre une cartographie de suivi X-Ray pour une demande qui a entraîné une erreur de fonction et un message d’erreur 502 d’API Gateway. Le client reçoit le message d’erreur générique.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/tracemap-apig-502.png)
Pour personnaliser la réponse d’erreur, vous devez attraper les erreurs dans votre code et formater une réponse dans le format requis.
**Example [index.js](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/nodejs-apig/function/index.mjs) : formatage des erreurs**
```
var formatError = function(error){
var response = {
"statusCode": error.statusCode,
"headers": {
"Content-Type": "text/plain",
"x-amzn-ErrorType": error.code
},
"isBase64Encoded": false,
"body": error.code + ": " + error.message
}
return response
}
```
API Gateway convertit cette réponse en une erreur HTTP avec un code d’état et un corps personnalisés. Dans la carte de trace, le nœud de fonction est vert car il a géré l’erreur.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/tracemap-apig-404.png)
# Sélection d’une méthode pour invoquer votre fonction Lambda à l’aide d’une requête HTTP
De nombreux cas d’utilisation courants de Lambda impliquent d’invoquer votre fonction à l’aide d’une requête HTTP. Vous pourriez souhaiter qu’une application Web invoque votre fonction par le biais d’une demande de navigateur. Les fonctions Lambda peuvent également être utilisées pour créer un REST complet APIs, gérer les interactions des utilisateurs à partir d'applications mobiles, traiter des données provenant de services externes via des appels HTTP ou créer des webhooks personnalisés.
Les sections suivantes expliquent quels sont vos choix pour invoquer Lambda via HTTP et fournissent des informations qui vous aideront à prendre la bonne décision pour votre cas d’utilisation particulier.
## Options proposées lors de la sélection d’une méthode d’appel HTTP
Lambda propose deux méthodes principales pour appeler une fonction à l'aide d'une requête HTTP : [function URLs](urls-configuration.md) et [API](services-apigateway.md) Gateway. Les principales différences entre ces deux options sont les suivantes :
+ **La fonction Lambda URLs** fournit un point de terminaison HTTP simple et direct pour une fonction Lambda. Elles sont optimisées pour la simplicité et la rentabilité et constituent le moyen le plus rapide d’exposer une fonction Lambda via HTTP.
+ **API Gateway** est un service plus avancé permettant de créer des fonctionnalités complètes APIs. API Gateway est optimisé pour créer et gérer des productions APIs à grande échelle et fournit des outils complets pour la sécurité, la surveillance et la gestion du trafic.
## Recommandations si vous connaissez déjà vos besoins
Si vous connaissez déjà bien vos besoins, voici nos recommandations de base :
Nous recommandons cette **[fonction URLs](urls-configuration.md)** pour les applications simples ou le prototypage où vous n'avez besoin que de méthodes d'authentification et de request/response manipulation de base et où vous souhaitez réduire les coûts et la complexité au minimum.
**[API Gateway](services-apigateway.md)** est un meilleur choix pour les applications de production à grande échelle ou pour les cas où vous avez besoin de fonctionnalités plus avancées telles que la prise en charge d'[OpenAPI Description](https://www.openapis.org/), un choix d'options d'authentification, des noms de domaine personnalisés ou une request/response gestion riche, notamment la régulation, la mise en cache et la transformation. request/response
## Éléments à prendre en compte lors de la sélection d’une méthode pour invoquer votre fonction Lambda
Lorsque vous choisissez entre function URLs et API Gateway, vous devez prendre en compte les facteurs suivants :
+ Vos besoins en matière d'authentification, par exemple si vous avez besoin OAuth d'Amazon Cognito pour authentifier les utilisateurs
+ Vos exigences en matière de mise à l’échelle et la complexité de l’API que vous souhaitez implémenter
+ Si vous avez besoin de fonctionnalités avancées telles que la validation et le request/response formatage des demandes
+ Vos besoins en matière de surveillance
+ Vos objectifs en matière de coûts
La compréhension de ces facteurs vous permettra de choisir l’option qui répond le mieux à vos exigences en matière de sécurité, de complexité et de coût.
Le tableau suivant résume les différences entre les deux options.
### Authentification
+ **La fonction URLs** fournit des options d'authentification de base via Gestion des identités et des accès AWS (IAM). Vous pouvez configurer vos points de terminaison pour qu’ils soient publics (aucune authentification) ou pour qu’ils nécessitent une authentification IAM. Avec l'authentification IAM, vous pouvez utiliser des AWS informations d'identification standard ou des rôles IAM pour contrôler l'accès. Bien que simple à configurer, cette approche offre des options limitées par rapport aux autres méthodes d’authentification.
+ **API Gateway** donne accès à une gamme plus complète d’options d’authentification. Outre l'authentification IAM, vous pouvez utiliser des autorisateurs [Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html) (logique d'authentification personnalisée), des groupes d'utilisateurs Amazon [Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html) et des flux .0. OAuth2 Cette flexibilité vous permet de mettre en œuvre des schémas d’authentification complexes, notamment des fournisseurs d’authentification tiers, une authentification basée sur des jetons et une authentification multifactorielle.
### Traitement des requêtes et réponses
+ **La fonction URLs** fournit une gestion de base des requêtes et des réponses HTTP. Elles prennent en charge les méthodes HTTP standard et créent une prise en charge intégrée du partage des ressources entre origines (CORS, cross-origin resource sharing). Bien qu’elles puissent gérer naturellement les charges utiles JSON et les paramètres de requête, elles n’offrent pas de fonctionnalités de transformation ou de validation des requêtes. La gestion des réponses est tout aussi simple : le client reçoit la réponse de votre fonction Lambda exactement telle que Lambda la renvoie.
+ **API Gateway** fournit des fonctionnalités sophistiquées de gestion des requêtes et des réponses. Vous pouvez définir des validateurs de demandes, transformer les demandes et les réponses à l'aide de modèles de mappage, configurer request/response des en-têtes et implémenter la mise en cache des réponses. API Gateway prend également en charge les charges utiles binaires et les noms de domaine personnalisés et peut modifier les réponses avant qu’elles n’atteignent le client. Vous pouvez configurer des modèles pour la request/response validation et la transformation à l'aide du schéma JSON.
### Mise à l’échelle
+ Les **fonctions** s' URLsadaptent directement aux limites de simultanéité de votre fonction Lambda et gérez les pics de trafic en augmentant la taille de votre fonction jusqu'à sa limite de simultanéité maximale configurée. Une fois cette limite atteinte, Lambda répond aux requêtes supplémentaires avec des réponses HTTP 429. Il n’existe aucun mécanisme de mise en file d’attente intégré. La gestion de la mise à l’échelle dépend donc entièrement de la configuration de votre fonction Lambda. Par défaut, les fonctions Lambda sont limitées à 1 000 exécutions simultanées par fonction. Région AWS
+ **API Gateway** fournit des fonctionnalités de dimensionnement supplémentaires en plus de la propre mise à l’échelle de Lambda. Il inclut des commandes intégrées de mise en file d’attente et de limitation des requêtes, ce qui vous permet de gérer les pics de trafic de manière plus élégante. API Gateway peut traiter jusqu’à 10 000 requêtes par seconde et par région par défaut, avec une capacité de débordement de 5 000 requêtes par seconde. Il fournit également des outils pour limiter les requêtes à différents niveaux (API, étape ou méthode) afin de protéger votre dorsal.
### Contrôle
+ Les **fonctions URLs** offrent une surveillance de base via CloudWatch les métriques Amazon, notamment le nombre de demandes, la latence et les taux d'erreur. Vous avez accès aux métriques et aux journaux Lambda standard, qui indiquent les requêtes brutes entrant dans votre fonction. Bien que cela fournisse une visibilité opérationnelle essentielle, les métriques se concentrent principalement sur l’exécution des fonctions.
+ **API Gateway** fournit des fonctionnalités de surveillance complètes, notamment des métriques détaillées, des options de journalisation et de suivi. Vous pouvez surveiller les appels d'API, la latence, les taux d'erreur et hit/miss les taux de cache via CloudWatch. API Gateway s'intègre également au AWS X-Ray traçage distribué et fournit des formats de journalisation personnalisables.
### Cost
+ Les **fonctions URLs** suivent le modèle de tarification Lambda standard : vous ne payez que pour les appels de fonctions et le temps de calcul. Il n’y a pas de frais supplémentaires pour le point de terminaison de l’URL lui-même. Cela en fait un choix rentable pour les applications simples APIs ou à faible trafic si vous n'avez pas besoin des fonctionnalités supplémentaires d'API Gateway.
+ **API Gateway** propose un [niveau gratuit](https://aws.amazon.com/api-gateway/pricing/#Free_Tier) qui inclut un million d'appels d'API reçus pour REST APIs et un million d'appels d'API reçus pour HTTP APIs. Ensuite, API Gateway facture les appels d’API, le transfert de données et la mise en cache (si activée). Reportez-vous à la [page de tarification](https://aws.amazon.com/api-gateway/pricing/) d’API Gateway pour connaître les coûts associés à votre propre cas d’utilisation.
### Autres fonctions
+ URLsLes **fonctions** sont conçues pour la simplicité et l'intégration directe de Lambda. Ils prennent en charge les points de terminaison HTTP et HTTPS, offrent un support CORS intégré et fournissent des points de terminaison à double pile (IPv4 et IPv6). Bien qu’elles ne disposent d’aucune fonctionnalité avancée, elles excellent dans les scénarios où vous avez besoin d’un moyen rapide et simple d’exposer les fonctions Lambda via HTTP.
+ **API Gateway** inclut de nombreuses fonctionnalités supplémentaires telles que la gestion des versions des API, la gestion des étapes, les clés d'API pour les plans d'utilisation, la documentation des API via Swagger/OpenAPI, le mode WebSocket APIs privé au sein d' APIs un VPC et l'intégration WAF pour une sécurité accrue. Il prend également en charge les déploiements Canary, les intégrations fictives à des fins de test et l'intégration avec d'autres solutions que Services AWS Lambda.
## Sélection d’une méthode pour invoquer votre fonction Lambda
Maintenant que vous avez pris connaissance des critères de sélection entre la fonction Lambda URLs et API Gateway et des principales différences entre les deux, vous pouvez sélectionner l'option qui répond le mieux à vos besoins et utiliser les ressources suivantes pour vous aider à commencer à l'utiliser.
------
#### [ Function URLs ]
**Commencez à utiliser Function URLs grâce aux ressources suivantes**
+ Suivre le tutoriel [Création d’une fonction Lambda avec une URL de fonction](urls-webhook-tutorial.md)
+ Pour en savoir plus sur URLs les fonctions, consultez le [Création et gestion de la fonction Lambda URLs](urls-configuration.md) chapitre de ce guide
+ Essayez le tutoriel guidé intégré à la console **Créer une application Web simple** en procédant comme suit :
1. Ouvrez la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda.
1. Ouvrez le panneau d’aide en cliquant sur l’icône dans le coin supérieur droit de l’écran.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/console_help_screenshot.png)
1. Sélectionnez **Tutoriels**.
1. Dans **Créer une application Web simple**, choisissez **Démarrer le tutoriel**.
------
#### [ API Gateway ]
**Mise en route avec Lambda et API Gateway grâce aux ressources suivantes**
+ Suivez le tutoriel [Utilisation de Lambda avec API Gateway](services-apigateway-tutorial.md) pour créer une API REST intégrée à une fonction Lambda principale.
+ Pour en savoir plus sur les différents types d’API proposés par API Gateway, consultez les sections suivantes du *Guide du développeur Amazon API Gateway* :
+ [API Gateway REST APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html)
+ [API Gateway HTTP APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html)
+ [API Gateway WebSocket APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api.html)
+ Essayez un ou plusieurs des exemples de la section [Tutoriels et ateliers](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-tutorials.html) du manuel *Guide du développeur Amazon API Gateway*.
------
# Utilisation AWS Lambda avec AWS Infrastructure Composer
AWS Infrastructure Composer est un constructeur visuel permettant de concevoir des applications modernes sur AWS. Vous concevez l'architecture de votre application en faisant glisser, en regroupant et Services AWS en connectant dans un canevas visuel. Infrastructure Composer crée des modèles d’infrastructure en tant que code (IaC) à partir de votre conception que vous pouvez déployer en utilisant [AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html) ou [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html).
## Exportation d’une fonction Lambda vers Infrastructure Composer
Vous pouvez commencer à utiliser Infrastructure Composer en créant un nouveau projet basé sur la configuration d’une fonction Lambda existante à l’aide de la console Lambda. Pour exporter la configuration et le code de votre fonction vers Infrastructure Composer afin de créer un nouveau projet, procédez comme suit :
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Sélectionnez la fonction que doit utiliser comme base pour votre projet Infrastructure Composer.
1. Dans le volet **Présentation de la fonction**, choisissez **Exporter vers Infrastructure Composer**.
Pour exporter la configuration et le code de votre fonction vers Infrastructure Composer, Lambda crée un compartiment Amazon S3 dans votre compte pour stocker temporairement ces données.
1. Dans la boîte de dialogue, choisissez **Confirmer et créer un projet** pour accepter le nom par défaut de ce compartiment et exporter la configuration et le code de votre fonction vers Infrastructure Composer.
1. (Facultatif) Pour choisir un autre nom pour le compartiment Amazon S3 créé par Lambda, entrez un nouveau nom et choisissez **Confirmer et créer un projet**. Les noms de compartiment Amazon S3 doivent être uniques et respecter les [règles de dénomination de compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html).
1. Pour enregistrer vos fichiers de projet et de fonction dans Infrastructure Composer, activez le [mode de synchronisation locale](https://docs.aws.amazon.com/application-composer/latest/dg/reference-features-local-sync.html).
**Note**
Si vous avez déjà utilisé la fonctionnalité **Exporter vers Application Composer** et créé un compartiment Amazon S3 en utilisant le nom par défaut, Lambda peut réutiliser ce compartiment s’il existe toujours. Acceptez le nom du compartiment par défaut dans la boîte de dialogue pour réutiliser le compartiment existant.
### Configuration des compartiments de transfert Amazon S3 Transfer AccelAccelAccel
Le compartiment Amazon S3 créé par Lambda pour transférer la configuration de votre fonction chiffre automatiquement les objets à l’aide de la norme de chiffrement AES 256. Lambda configure également le bucket pour utiliser la [condition de propriétaire du bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-owner-condition.html) afin de garantir que vous Compte AWS êtes le seul à pouvoir ajouter des objets au bucket.
Lambda configure le compartiment pour qu’il supprime automatiquement les objets 10 jours après leur téléchargement. Toutefois, Lambda ne supprime pas automatiquement le compartiment lui-même. Pour supprimer le bucket de votre Compte AWS, suivez les instructions de la section [Supprimer un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html). Le nom du compartiment par défaut utilise le préfixe`lambdasam`, une chaîne alphanumérique à 10 chiffres, et Région AWS vous avez créé votre fonction dans :
```
lambdasam-06f22da95b-us-east-1
```
Pour éviter que des frais supplémentaires ne soient ajoutés à votre compte Compte AWS, nous vous recommandons de supprimer le compartiment Amazon S3 dès que vous avez terminé d'exporter votre fonction vers Infrastructure Composer.
La [tarification standard d’Amazon S3](https://aws.amazon.com/s3/pricing/) s’applique.
### Autorisations requises
Pour utiliser la fonctionnalité d'intégration de Lambda à Infrastructure Composer, vous devez disposer de certaines autorisations pour télécharger un AWS SAM modèle et écrire la configuration de votre fonction sur Amazon S3.
Pour télécharger un AWS SAM modèle, vous devez être autorisé à utiliser les actions d'API suivantes :
+ [GetPolicy](https://docs.aws.amazon.com/lambda/latest/api/API_GetPolicy.html)
+ [iam : GetPolicyVersion](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetPolicyVersion.html)
+ [iam : GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)
+ [iam : GetRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRolePolicy.html)
+ [iam : ListAttachedRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAttachedRolePolicies.html)
+ [iam : ListRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRolePolicies.html)
+ [iam : ListRoles](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRoles.html)
Vous pouvez autoriser l'utilisation de toutes ces actions en ajoutant la politique [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html) AWS gérée à votre rôle d'utilisateur IAM.
Pour que Lambda puisse écrire la configuration de votre fonction sur Amazon S3, vous devez être autorisé à utiliser les actions d’API suivantes :
+ [S3 : PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html)
+ [S3 : CreateBucket](https://docs.aws.amazon.com/AmazonS3/latest/API/API_CreateBucket.html)
+ [S3 : PutBucketEncryption](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketEncryption.html)
+ [S3 : PutBucketLifecycleConfiguration](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketLifecycleConfiguration.html)
Si vous ne pouvez pas exporter la configuration de votre fonction vers Infrastructure Composer, vérifiez que votre compte dispose des autorisations requises pour ces opérations. Si vous avez les autorisations requises mais que vous ne pouvez toujours pas exporter la configuration de votre fonction, vérifiez les [politiques basées sur les ressources](access-control-resource-based.md) qui pourraient limiter l’accès Amazon S3.
## Autres ressources
Pour obtenir un didacticiel plus détaillé sur la conception d’une application sans serveur dans Infrastructure Composer sur la base d’une fonction Lambda existante, consultez [Utilisation de Lambda avec infrastructure en tant que code (IaC)](foundation-iac.md).
Pour utiliser Infrastructure Composer et concevoir et déployer une application sans serveur complète AWS SAM à l'aide de Lambda, vous pouvez également suivre [AWS Infrastructure Composer le didacticiel du](https://catalog.workshops.aws/serverless-patterns/en-US/dive-deeper/module1a) [Serverless Patterns AWS Workshop](https://catalog.workshops.aws/serverless-patterns/en-US).
# Utilisation AWS Lambda avec CloudFormation
Dans un AWS CloudFormation modèle, vous pouvez spécifier une fonction Lambda comme cible d'une ressource personnalisée. Utilisez des ressources personnalisées pour traiter les paramètres, récupérer les valeurs de configuration ou appeler d'autres personnes Services AWS lors des événements du cycle de vie de la pile.
L’exemple suivant appelle une fonction qui est définie ailleurs dans le modèle.
**Example – Définition de ressource personnalisée**
```
Resources:
primerinvoke:
Type: [AWS::CloudFormation::CustomResource](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cfn-customresource.html)
Version: "1.0"
Properties:
ServiceToken: !GetAtt primer.Arn
FunctionName: !Ref randomerror
```
Le jeton de service est l'Amazon Resource Name (ARN) de la fonction CloudFormation invoquée lorsque vous créez, mettez à jour ou supprimez la pile. Vous pouvez également inclure des propriétés supplémentaires telles que`FunctionName`, qui CloudFormation sont transmises telles quelles à votre fonction.
CloudFormation invoque votre [fonction](invocation-async.md) Lambda de manière asynchrone avec un événement qui inclut une URL de rappel.
**Example — événement de CloudFormation message**
```
{
"RequestType": "Create",
"ServiceToken": "arn:aws:lambda:us-east-1:123456789012:function:lambda-error-processor-primer-14ROR2T3JKU66",
"ResponseURL": "https://cloudformation-custom-resource-response-useast1.s3-us-east-1.amazonaws.com/arn%3Aaws%3Acloudformation%3Aus-east-1%3A123456789012%3Astack/lambda-error-processor/1134083a-2608-1e91-9897-022501a2c456%7Cprimerinvoke%7C5d478078-13e9-baf0-464a-7ef285ecc786?AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE&Expires=1555451971&Signature=28UijZePE5I4dvukKQqM%2F9Rf1o4%3D",
"StackId": "arn:aws:cloudformation:us-east-1:123456789012:stack/lambda-error-processor/1134083a-2608-1e91-9897-022501a2c456",
"RequestId": "5d478078-13e9-baf0-464a-7ef285ecc786",
"LogicalResourceId": "primerinvoke",
"ResourceType": "AWS::CloudFormation::CustomResource",
"ResourceProperties": {
"ServiceToken": "arn:aws:lambda:us-east-1:123456789012:function:lambda-error-processor-primer-14ROR2T3JKU66",
"FunctionName": "lambda-error-processor-randomerror-ZWUC391MQAJK"
}
}
```
La fonction se charge de renvoyer à l’URL de rappel une réponse indiquant le succès ou l’échec. Pour obtenir la syntaxe de réponse complète, consultez [Objets de réponse des ressources personnalisées](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/crpg-ref-responses.html).
**Example — réponse CloudFormation personnalisée aux ressources**
```
{
"Status": "SUCCESS",
"PhysicalResourceId": "2019/04/18/[$LATEST]b3d1bfc65f19ec610654e4d9b9de47a0",
"StackId": "arn:aws:cloudformation:us-east-1:123456789012:stack/lambda-error-processor/1134083a-2608-1e91-9897-022501a2c456",
"RequestId": "5d478078-13e9-baf0-464a-7ef285ecc786",
"LogicalResourceId": "primerinvoke"
}
```
CloudFormation fournit une bibliothèque appelée `cfn-response` qui gère l'envoi de la réponse. Si vous définissez votre fonction dans un modèle, vous pouvez demander le nom de la bibliothèque. CloudFormation ajoute ensuite la bibliothèque au package de déploiement qu'elle crée pour la fonction.
Si votre fonction qu’une ressource personnalisée utilise possède une [interface réseau Elastic](configuration-vpc.md#configuration-vpc-enis) qui lui est associée, ajoutez les ressources suivantes à la politique VPC où **region** est la région dans laquelle se trouve la fonction sans les tirets. Par exemple, `us-east-1` est `useast1`. Cela permettra à la ressource personnalisée de répondre à l'URL de rappel qui renvoie un signal à la CloudFormation pile.
```
arn:aws:s3:::cloudformation-custom-resource-response-region",
"arn:aws:s3:::cloudformation-custom-resource-response-region/*",
```
L’exemple de fonction suivant appelle une deuxième fonction. Si l'appel aboutit, la fonction envoie une réponse de confirmation à CloudFormation, et la mise à jour de la pile se poursuit. Le modèle utilise le type de [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)ressource fourni par AWS Serverless Application Model.
**Example – Fonction de ressource personnalisée**
```
Transform: 'AWS::Serverless-2016-10-31'
Resources:
primer:
Type: [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)
Properties:
Handler: index.handler
Runtime: nodejs16.x
InlineCode: |
var aws = require('aws-sdk');
var response = require('cfn-response');
exports.handler = function(event, context) {
// For Delete requests, immediately send a SUCCESS response.
if (event.RequestType == "Delete") {
response.send(event, context, "SUCCESS");
return;
}
var responseStatus = "FAILED";
var responseData = {};
var functionName = event.ResourceProperties.FunctionName
var lambda = new aws.Lambda();
lambda.invoke({ FunctionName: functionName }, function(err, invokeResult) {
if (err) {
responseData = {Error: "Invoke call failed"};
console.log(responseData.Error + ":\n", err);
}
else responseStatus = "SUCCESS";
response.send(event, context, responseStatus, responseData);
});
};
Description: Invoke a function to create a log stream.
MemorySize: 128
Timeout: 8
Role: !GetAtt role.Arn
Tracing: Active
```
Si la fonction invoquée par la ressource personnalisée n'est pas définie dans un modèle, vous pouvez obtenir le code source à `cfn-response` partir du [module cfn-response](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-lambda-function-code-cfnresponsemodule.html) dans le guide de l' AWS CloudFormation utilisateur.
Pour plus d’informations sur les ressources personnalisées, consultez [Ressources personnalisées](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html) dans le *Guide de l’utilisateur AWS CloudFormation *.
# Traiter les événements Amazon DocumentDB avec Lambda
Vous pouvez utiliser une fonction Lambda pour traiter les événements dans un [flux de modifications Amazon DocumentDB (compatible avec MongoDB)](https://docs.aws.amazon.com/documentdb/latest/developerguide/change_streams.html) en configurant un cluster Amazon DocumentDB comme source d’événements. Ensuite, vous pouvez automatiser les charges de travail orientées événements en invoquant votre fonction Lambda chaque fois que les données changent avec votre cluster Amazon DocumentDB.
**Note**
Lambda prend en charge uniquement les versions 4.0 et 5.0 d’Amazon DocumentDB. Lambda ne prend pas en charge la version 3.6.
De plus, pour les mappages des sources d’événements, Lambda ne prend en charge que les clusters basés sur des instances et les clusters régionaux. Lambda ne prend pas en charge les [clusters élastiques](https://docs.aws.amazon.com/documentdb/latest/developerguide/docdb-using-elastic-clusters.html) ni les [clusters globaux](https://docs.aws.amazon.com/documentdb/latest/developerguide/global-clusters.html). Cette limitation ne s’applique pas lorsque vous utilisez Lambda en tant que client pour vous connecter à Amazon DocumentDB. Lambda peut se connecter à tous les types de clusters pour effectuer des opérations CRUD.
Lambda traite les événements des flux de modifications Amazon DocumentDB de manière séquentielle dans l’ordre de leur arrivée. Pour cette raison, votre fonction ne peut gérer qu’une seule invocation simultanée d’Amazon DocumentDB à la fois. Pour surveiller votre fonction, vous pouvez suivre ses [métriques de simultanéité](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-concurrency.html).
**Avertissement**
Les mappages des sources d’événements Lambda traitent chaque événement au moins une fois, et le traitement des enregistrements peut être dupliqué. Pour éviter les problèmes potentiels liés à des événements dupliqués, nous vous recommandons vivement de rendre votre code de fonction idempotent. Pour en savoir plus, consultez [Comment rendre ma fonction Lambda idempotente](https://repost.aws/knowledge-center/lambda-function-idempotent) dans le Knowledge Center. AWS
**Topics**
+ [Exemple d’événement Amazon DocumentDB](#docdb-sample-event)
+ [Conditions préalables et autorisations](#docdb-prereqs)
+ [Configurer la sécurité réseau](#docdb-network)
+ [Création d’un mappage des sources d’événements Amazon DocumentDB (console)](#docdb-configuration)
+ [Création d’un mappage des sources d’événements Amazon DocumentDB (kit SDK ou CLI)](#docdb-api)
+ [Positions de départ des interrogations et des flux](#docdb-stream-polling)
+ [Surveillance de votre source d’événements Amazon DocumentDB](#docdb-monitoring)
+ [Tutoriel : Utilisation AWS Lambda avec Amazon DocumentDB Streams](with-documentdb-tutorial.md)
## Exemple d’événement Amazon DocumentDB
```
{
"eventSourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:canaryclusterb2a659a2-qo5tcmqkcl03",
"events": [
{
"event": {
"_id": {
"_data": "0163eeb6e7000000090100000009000041e1"
},
"clusterTime": {
"$timestamp": {
"t": 1676588775,
"i": 9
}
},
"documentKey": {
"_id": {
"$oid": "63eeb6e7d418cd98afb1c1d7"
}
},
"fullDocument": {
"_id": {
"$oid": "63eeb6e7d418cd98afb1c1d7"
},
"anyField": "sampleValue"
},
"ns": {
"db": "test_database",
"coll": "test_collection"
},
"operationType": "insert"
}
}
],
"eventSource": "aws:docdb"
}
```
Pour plus d’informations sur les événements de cet exemple et leurs formes, consultez la page [Événements de modification](https://www.mongodb.com/docs/manual/reference/change-events/) sur le site Web de la documentation MongoDB.
## Conditions préalables et autorisations
Avant de pouvoir utiliser Amazon DocumentDB comme source d’événements pour votre fonction Lambda, veuillez prendre note des conditions préalables suivantes. Vous devez :
+ **Disposez d'un cluster Amazon DocumentDB existant au même endroit Région AWS que votre fonction Compte AWS et en tant que tel.** Si vous n’avez pas de cluster existant, vous pouvez en créer un en suivant les étapes de la section [Prise en main d’Amazon DocumentDB](https://docs.aws.amazon.com/documentdb/latest/developerguide/get-started-guide.html) dans le *Guide du développeur Amazon DocumentDB*. Sinon, la première série d’étapes de [Tutoriel : Utilisation AWS Lambda avec Amazon DocumentDB Streams](with-documentdb-tutorial.md) vous guide dans la création d’un cluster Amazon DocumentDB avec tous les prérequis nécessaires.
+ **Autorisez Lambda à accéder aux ressources Amazon Virtual Private Cloud (Amazon VPC) associées à votre cluster Amazon DocumentDB.** Pour de plus amples informations, veuillez consulter [Configurer la sécurité réseau](#docdb-network).
+ **Activez le protocole TLS sur votre cluster Amazon DocumentDB.** Il s’agit du paramètre par défaut. Si vous désactivez le protocole TLS, Lambda ne peut pas communiquer avec votre cluster.
+ **Activez les flux de modifications sur votre cluster Amazon DocumentDB.** Pour plus d’informations, veuillez consulter la rubrique [Utilisation des flux de modifications avec Amazon DocumentDB](https://docs.aws.amazon.com/documentdb/latest/developerguide/change_streams.html) dans le *Guide du développeur Amazon DocumentDB*.
+ **Fournissez à Lambda les informations d’identification pour accéder à votre cluster Amazon DocumentDB.** Lors de la configuration de la source d’événement, fournissez la clé [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) qui contient les informations d’authentification (nom d’utilisateur et mot de passe) requises pour accéder à votre cluster. Pour fournir cette clé lors de la configuration, procédez de l’une des manières suivantes :
+ Si vous utilisez la console Lambda pour la configuration, saisissez cette clé dans le champ **Clé du gestionnaire de secrets**.
+ Si vous utilisez le AWS Command Line Interface (AWS CLI) pour la configuration, fournissez cette clé dans l'`source-access-configurations`option. Vous pouvez inclure cette option avec la commande [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html) ou la commande [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-event-source-mapping.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-event-source-mapping.html). Par exemple :
```
aws lambda create-event-source-mapping \
...
--source-access-configurations '[{"Type":"BASIC_AUTH","URI":"arn:aws:secretsmanager:us-west-2:123456789012:secret:DocDBSecret-AbC4E6"}]' \
...
```
+ **Accordez des autorisations à Lambda pour gérer les ressources liées à votre flux Amazon DocumentDB.** Ajoutez manuellement les autorisations suivantes au [rôle d’exécution](lambda-intro-execution-role.md) de votre fonction :
+ [RDS : Décrivez DBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html)
+ [RDS DBCluster : Décrire les paramètres](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusterParameters.html)
+ [RDS DBSubnet : Décrire les groupes](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBSubnetGroups.html)
+ [EC2 : CreateNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateNetworkInterface.html)
+ [EC2 : DescribeNetworkInterfaces](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeNetworkInterfaces.html)
+ [EC2 : DescribeVpcs](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpcs.html)
+ [EC2 : DeleteNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteNetworkInterface.html)
+ [EC2 : DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html)
+ [EC2 : DescribeSecurityGroups](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSecurityGroups.html)
+ [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html)
+ [responsable des secrets : GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html)
+ **La taille des événements de flux de modifications Amazon DocumentDB que vous envoyez à Lambda doit être inférieure à 6 Mo.** Lambda prend en charge des charges utiles d’une taille maximale de 6 Mo. Si votre flux de modifications essaie d’envoyer à Lambda un événement supérieur à 6 Mo, Lambda supprime le message et émet la métrique `OversizedRecordCount`. Lambda émet toutes les métriques dans la mesure du possible.
**Note**
Alors que les fonctions Lambda ont généralement un délai d’expiration maximal de 15 minutes, les mappages des sources d’événement pour Amazon MSK, Apache Kafka autogéré, Amazon DocumentDB et Amazon MQ pour ActiveMQ et RabbitMQ ne prennent en charge que les fonctions dont le délai d’expiration maximal est de 14 minutes. Cette contrainte garantit que le mappage des sources d’événements peut gérer correctement les erreurs de fonction et effectuer de nouvelles tentatives.
## Configurer la sécurité réseau
Pour donner à Lambda un accès complet à Amazon DocumentDB via votre mappage des sources d’événements, soit votre cluster doit utiliser un point de terminaison public (adresse IP publique), soit vous devez fournir un accès au VPC Amazon dans lequel vous avez créé le cluster.
Lorsque vous utilisez Amazon DocumentDB avec Lambda, créez des [points de terminaison de VPC AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) qui permettent à votre fonction d’accéder aux ressources de votre Amazon VPC.
**Note**
AWS PrivateLink Les points de terminaison VPC sont requis pour les fonctions avec des mappages de sources d'événements qui utilisent le mode par défaut (à la demande) pour les sondeurs d'événements. Si le mappage de votre source d'événements utilise le [mode provisionné](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode), vous n'avez pas besoin de configurer les points de terminaison AWS PrivateLink VPC.
Créez un point de terminaison pour accéder aux ressources suivantes :
+ Lambda — Créez un point de terminaison pour le principal de service Lambda.
+ AWS STS — Créez un point de terminaison pour le AWS STS afin qu'un directeur de service assume un rôle en votre nom.
+ Secrets Manager : si votre cluster utilise Secrets Manager pour stocker les informations d’identification, créez un point de terminaison pour Secrets Manager.
Vous pouvez également configurer une passerelle NAT sur chaque sous-réseau public d’Amazon VPC. Pour de plus amples informations, veuillez consulter [Activation de l’accès Internet pour les fonctions Lambda connectées à un VPC](configuration-vpc-internet.md).
Lorsque vous créez un mappage de source d'événements pour Amazon DocumentDB, Lambda vérifie si des interfaces réseau élastiques (ENIs) sont déjà présentes pour les sous-réseaux et les groupes de sécurité configurés pour votre Amazon VPC. Si Lambda trouve des objets existants ENIs, il essaie de les réutiliser. Sinon, Lambda en crée un nouveau ENIs pour se connecter à la source de l'événement et appeler votre fonction.
**Note**
Les fonctions Lambda s'exécutent toujours au sein VPCs du service Lambda. La configuration VPC de votre fonction n’affecte pas le mappage des sources d’événements. Seule la configuration réseau des sources d’événements détermine la manière dont Lambda se connecte à votre source d’événements.
Configurez les groupes de sécurité pour le VPC Amazon contenant votre cluster. Par défaut, Amazon DocumentDB utilise les ports suivants : `27017`.
+ Règles entrantes – Autorisent tout le trafic sur le port de l’agent par défaut pour le groupe de sécurité associé à votre source d’événement. Vous pouvez également utiliser une règle de groupe de sécurité avec référence circulaire pour autoriser l’accès à partir d’instances appartenant au même groupe de sécurité.
+ Règles de sortie : autorisez tout le trafic sur le port `443` pour les destinations externes si votre fonction doit communiquer avec les AWS services. Vous pouvez également utiliser une règle de groupe de sécurité à référencement automatique pour limiter l'accès au courtier si vous n'avez pas besoin de communiquer avec d'autres AWS services.
+ Règles entrantes relatives au point de terminaison Amazon VPC – Si vous utilisez un point de terminaison Amazon VPC, le groupe de sécurité associé à votre point de terminaison Amazon VPC doit autoriser le trafic entrant sur le port `443` en provenance du groupe de sécurité du cluster.
Si votre cluster utilise l’authentification, vous pouvez également restreindre la politique de point de terminaison pour le point de terminaison Secrets Manager. Pour appeler l’API Secrets Manager, Lambda utilise votre rôle de fonction, et non le principal de service Lambda.
**Example Politique de point de terminaison de VPC — Point de terminaison 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"
}
]
}
```
Lorsque vous utilisez des points de terminaison Amazon VPC, AWS achemine vos appels d'API pour appeler votre fonction à l'aide de l'Elastic Network Interface (ENI) du point de terminaison. Le directeur du service Lambda doit faire appel à tous `lambda:InvokeFunction` les rôles et fonctions qui les utilisent. ENIs
Par défaut, les points de terminaison Amazon VPC disposent de politiques IAM ouvertes qui permettent un accès étendu aux ressources. La meilleure pratique consiste à restreindre ces politiques pour effectuer les actions nécessaires à l’aide de ce point de terminaison. Pour garantir que votre mappage des sources d’événements est en mesure d’invoquer votre fonction Lambda, la politique de point de terminaison de VPC doit autoriser le principal de service Lambda à appeler `sts:AssumeRole` et `lambda:InvokeFunction`. Le fait de restreindre vos politiques de point de terminaison de VPC pour autoriser uniquement les appels d’API provenant de votre organisation empêche le mappage des sources d’événements de fonctionner correctement. C’est pourquoi `"Resource": "*"` est requis dans ces politiques.
Les exemples de politiques de point de terminaison de VPC suivants montrent comment accorder l’accès requis au principal de service Lambda pour les points de terminaison AWS STS et Lambda.
**Example Politique de point de terminaison VPC — point de terminaison AWS STS**
```
{
"Statement": [
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
**Example Politique de point de terminaison de VPC — Point de terminaison Lambda**
```
{
"Statement": [
{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
## Création d’un mappage des sources d’événements Amazon DocumentDB (console)
Pour qu’une fonction Lambda puisse lire le flux de modifications d’un cluster Amazon DocumentDB, créez un [mappage des sources d’événements](invocation-eventsourcemapping.md). Cette section explique comment procéder à partir de la console Lambda. Pour le AWS SDK et les AWS CLI instructions, voir[Création d’un mappage des sources d’événements Amazon DocumentDB (kit SDK ou CLI)](#docdb-api).
**Pour créer un mappage des sources d’événements Amazon DocumentDB (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez le nom d’une fonction.
1. Sous **Function overview (Présentation de la fonction)**, choisissez **Add trigger (Ajouter un déclencheur)**.
1. Sous **Configuration du déclencheur**, dans la liste déroulante, choisissez **DocumentDB**.
1. Configurez les options requises, puis choisissez **Add (Ajouter)**.
Lambda prend en charge les options suivantes pour les sources d’événement Amazon DocumentDB :
+ **Cluster DocumentDB** : sélectionnez un cluster Amazon DocumentDB.
+ **Activer le déclencheur** : choisissez si vous voulez activer le déclencheur maintenant. Si vous cochez cette case, votre fonction commence immédiatement à recevoir du trafic provenant du flux de modifications Amazon DocumentDB spécifié lors de la création du mappage des sources d’événements. Nous vous recommandons de décocher la case pour créer le mappage des sources d’événements dans un état désactivé à des fins de test. Après la création, vous pouvez activer le mappage des sources d’événements à tout moment.
+ **Nom de la base de données –** Saisissez le nom de la base de données du cluster à utiliser.
+ (Facultatif) **Nom de la collection** : saisissez le nom d’une collection de la base de données à utiliser. Si vous n’indiquez pas de collection, Lambda écoute tous les événements de chaque collection de la base de données.
+ **Taille de lot –** Définissez le nombre maximum de messages à extraire dans un lot, jusqu’à 10 000. La taille du lot par défaut est de 100.
+ **Position de départ –** Choisissez la position dans le flux à partir de laquelle commencer la lecture des enregistrements.
+ **Derniers –** Traiter uniquement les nouveaux enregistrements qui sont ajoutés au flux. Votre fonction ne commence à traiter les enregistrements que lorsque Lambda a fini de créer votre source d’événements. Cela signifie que certains enregistrements peuvent être supprimés jusqu’à ce que la source de votre événement soit correctement créée.
+ **Trim horizon (Supprimer l’horizon)** – Traiter tous les enregistrements figurant dans le flux. Lambda utilise la durée de conservation des journaux de votre cluster pour déterminer par où commencer la lecture des événements. Plus précisément, Lambda commence à lire à partir de `current_time - log_retention_duration`. Votre flux de modifications doit déjà être actif avant cet horodatage pour que Lambda puisse lire correctement tous les événements.
+ **At timestamp (À l’horodatage)** – Traitez les enregistrements à partir d’une heure spécifique. Votre flux de modifications doit déjà être actif avant l’horodatage spécifié pour que Lambda puisse lire correctement tous les événements.
+ **Authentication –** Choisissez la méthode d’authentification pour accéder aux agents de votre cluster.
+ **BASIC\$1AUTH –** Avec l’authentification de base, vous devez fournir la clé Secrets Manager qui contient les informations d’identification pour accéder à votre cluster.
+ **Clé Secrets Manager** : choisissez la clé Secrets Manager qui contient les informations d’authentification (nom d’utilisateur et mot de passe) requises pour accéder à votre cluster Amazon DocumentDB.
+ (Facultatif) **Fenêtre de traitement par lot** : définissez l’intervalle de temps maximum (en secondes) pour collecter des enregistrements avant d’invoquer votre fonction, jusqu’à 300.
+ (Facultatif) **Configuration complète du document** : pour les opérations de mise à jour des documents, choisissez ce que vous voulez envoyer au flux. La valeur par défaut est `Default`, ce qui signifie que pour chaque événement de flux de modifications, Amazon DocumentDB envoie uniquement un delta décrivant les modifications apportées. Pour plus d'informations sur ce champ, consultez la documentation [FullDocument](https://mongodb.github.io/mongo-java-driver/3.9/javadoc/com/mongodb/client/model/changestream/FullDocument.html#DEFAULT)de l'API MongoDB Javadoc.
+ **Par défaut –** Lambda n’envoie qu’un document partiel décrivant les modifications apportées.
+ **UpdateLookup**— Lambda envoie un delta décrivant les modifications, ainsi qu'une copie de l'intégralité du document.
## Création d’un mappage des sources d’événements Amazon DocumentDB (kit SDK ou CLI)
Pour créer ou gérer votre mappage des sources d’événements Amazon DocumentDB avec un [kit SDK AWS](https://aws.amazon.com/developer/tools/), vous pouvez utiliser les opérations d’API suivantes :
+ [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)
Pour créer le mappage des sources d'événements avec le AWS CLI, utilisez la [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html)commande. L’exemple suivant utilise cette commande pour mapper une fonction nommée `my-function` à un flux de modifications Amazon DocumentDB. La source d’événement est spécifiée par un Amazon Resource Name (ARN), avec une taille de lot de 500, à partir de l’horodatage en heure Unix. La commande spécifie également la clé Secrets Manager que Lambda utilise pour se connecter à Amazon DocumentDB. De plus, elle inclut des paramètres `document-db-event-source-config` qui spécifient la base de données et la collection à partir de laquelle lire.
```
aws lambda create-event-source-mapping --function-name my-function \
--event-source-arn arn:aws:rds:us-west-2:123456789012:cluster:privatecluster7de2-epzcyvu4pjoy
--batch-size 500 \
--starting-position AT_TIMESTAMP \
--starting-position-timestamp 1541139109 \
--source-access-configurations '[{"Type":"BASIC_AUTH","URI":"arn:aws:secretsmanager:us-east-1:123456789012:secret:DocDBSecret-BAtjxi"}]' \
--document-db-event-source-config '{"DatabaseName":"test_database", "CollectionName": "test_collection"}' \
```
Vous devriez obtenir un résultat du type suivant :
```
{
"UUID": "2b733gdc-8ac3-cdf5-af3a-1827b3b11284",
"BatchSize": 500,
"DocumentDBEventSourceConfig": {
"CollectionName": "test_collection",
"DatabaseName": "test_database",
"FullDocument": "Default"
},
"MaximumBatchingWindowInSeconds": 0,
"EventSourceArn": "arn:aws:rds:us-west-2:123456789012:cluster:privatecluster7de2-epzcyvu4pjoy",
"FunctionArn": "arn:aws:lambda:us-west-2:123456789012:function:my-function",
"LastModified": 1541348195.412,
"LastProcessingResult": "No records processed",
"State": "Creating",
"StateTransitionReason": "User action"
}
```
Après la création, vous pouvez utiliser la commande [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-event-source-mapping.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-event-source-mapping.html) pour mettre à jour les paramètres de votre source d’événements Amazon DocumentDB. L’exemple suivant met à jour la taille du lot à 1 000 et la fenêtre de traitement par lots à 10 secondes. Pour cette commande, vous avez besoin de l’UUID de votre mappage des sources d’événements, que vous pouvez récupérer à l’aide de la commande `list-event-source-mapping` ou de la console Lambda.
```
aws lambda update-event-source-mapping --function-name my-function \
--uuid f89f8514-cdd9-4602-9e1f-01a5b77d449b \
--batch-size 1000 \
--batch-window 10
```
Vous devriez obtenir un résultat du type suivant :
```
{
"UUID": "2b733gdc-8ac3-cdf5-af3a-1827b3b11284",
"BatchSize": 500,
"DocumentDBEventSourceConfig": {
"CollectionName": "test_collection",
"DatabaseName": "test_database",
"FullDocument": "Default"
},
"MaximumBatchingWindowInSeconds": 0,
"EventSourceArn": "arn:aws:rds:us-west-2:123456789012:cluster:privatecluster7de2-epzcyvu4pjoy",
"FunctionArn": "arn:aws:lambda:us-west-2:123456789012:function:my-function",
"LastModified": 1541359182.919,
"LastProcessingResult": "OK",
"State": "Updating",
"StateTransitionReason": "User action"
}
```
Lambda met à jour les paramètres de façon asynchrone, il se peut donc que vous ne voyiez pas ces modifications dans la sortie tant que le processus n’est pas terminé. Pour afficher les paramètres actuels de votre mappage des sources d’événements, utilisez la commande [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/get-event-source-mapping.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/get-event-source-mapping.html).
```
aws lambda get-event-source-mapping --uuid f89f8514-cdd9-4602-9e1f-01a5b77d449b
```
Vous devriez obtenir un résultat du type suivant :
```
{
"UUID": "2b733gdc-8ac3-cdf5-af3a-1827b3b11284",
"DocumentDBEventSourceConfig": {
"CollectionName": "test_collection",
"DatabaseName": "test_database",
"FullDocument": "Default"
},
"BatchSize": 1000,
"MaximumBatchingWindowInSeconds": 10,
"EventSourceArn": "arn:aws:rds:us-west-2:123456789012:cluster:privatecluster7de2-epzcyvu4pjoy",
"FunctionArn": "arn:aws:lambda:us-west-2:123456789012:function:my-function",
"LastModified": 1541359182.919,
"LastProcessingResult": "OK",
"State": "Enabled",
"StateTransitionReason": "User action"
}
```
Pour supprimer le mappage des sources d’événements Amazon DocumentDB, utilisez la commande [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/delete-event-source-mapping.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/delete-event-source-mapping.html).
```
aws lambda delete-event-source-mapping \
--uuid 2b733gdc-8ac3-cdf5-af3a-1827b3b11284
```
## Positions de départ des interrogations et des flux
Sachez que l’interrogation des flux lors des mises à jour et de la création du mappage des sources d’événements est finalement cohérente.
+ Lors de la création du mappage des sources d’événements, le démarrage de l’interrogation des événements depuis le flux peut prendre plusieurs minutes.
+ Lors des mises à jour du mappage des sources d’événements, l’arrêt et le redémarrage de l’interrogation des événements depuis le flux peuvent prendre plusieurs minutes.
Ce comportement signifie que si vous spécifiez `LATEST` comme position de départ du flux, le mappage des sources d’événements peut manquer des événements lors de la création ou des mises à jour. Pour vous assurer de ne manquer aucun événement, spécifiez la position de départ du flux comme `TRIM_HORIZON` ou `AT_TIMESTAMP`.
## Surveillance de votre source d’événements Amazon DocumentDB
Pour vous aider à surveiller votre source d’événements Amazon DocumentDB, Lambda émet la métrique `IteratorAge` lorsque votre fonction termine le traitement d’un lot d’enregistrements. *L’âge de l’itérateur* est la différence entre l’horodatage de l’événement le plus récent et l’horodatage actuel. La métrique `IteratorAge` indique essentiellement l’ancienneté du dernier enregistrement traité dans le lot. Si votre fonction traite actuellement de nouveaux événements, vous pouvez utiliser l’âge de l’itérateur pour estimer la latence entre le moment où un enregistrement est ajouté et celui où votre fonction le traite. Une tendance à la hausse de `IteratorAge` peut indiquer des problèmes liés à votre fonction. Pour de plus amples informations, veuillez consulter [Utilisation des métriques CloudWatch avec Lambda](monitoring-metrics.md).
Les flux de modifications Amazon DocumentDB ne sont pas optimisés pour gérer les intervalles de temps importants entre les événements. Si votre source d’événements Amazon DocumentDB ne reçoit aucun événement pendant une longue période, Lambda peut désactiver le mappage des sources d’événements. Cette période peut varier de quelques semaines à quelques mois en fonction de la taille du cluster et des autres charges de travail.
Lambda prend en charge des charges utiles allant jusqu’à 6 Mo. Cependant, les événements du flux de modification d’Amazon DocumentDB peuvent avoir une taille allant jusqu’à 16 Mo. Si votre flux de modifications tente d’envoyer à Lambda un événement d’une taille supérieure à 6 Mo, Lambda supprime le message et émet la métrique `OversizedRecordCount`. Lambda émet toutes les métriques dans la mesure du possible.
# Tutoriel : Utilisation AWS Lambda avec Amazon DocumentDB Streams
Dans ce tutoriel, vous créez une fonction Lambda de base qui consomme des événements à partir d’un flux de modifications Amazon DocumentDB (compatible avec MongoDB). Pour réaliser ce tutoriel, vous passerez par les étapes suivantes :
+ Configurez votre cluster Amazon DocumentDB, connectez-vous-y, et activez les flux de modifications sur ce cluster.
+ Créez votre fonction Lambda, et configurez votre cluster Amazon DocumentDB en tant que source d’événements pour votre fonction.
+ Testez la configuration en insérant des éléments dans votre base de données Amazon DocumentDB.
## Créer le cluster Amazon DocumentDB
1. Ouvrez la [console Amazon DocumentDB](https://console.aws.amazon.com/docdb/home#). Sous **Clusters**, sélectionnez **Créer**.
1. Créez un cluster avec la configuration suivante :
+ Pour **Type de cluster**, choisissez **Cluster basé sur l’instance**. Il s’agit de l’option par défaut.
+ Sous **Configuration du cluster**, assurez-vous que la **Version du moteur** 5.0.0 est sélectionnée. Il s’agit de l’option par défaut.
+ Sous **Configuration de l’instance** :
+ Pour **Classe d’instance de base de données**, sélectionnez **Classes à mémoire optimisée**. Il s’agit de l’option par défaut.
+ Pour **Nombre d’instances de réplica ordinaire**, choisissez 1.
+ Pour **Classe de l’instance**, utilisez la sélection par défaut.
+ Sous **Authentification**, saisissez un nom d’utilisateur pour l’utilisateur principal, puis choisissez **Autogéré**. Saisissez un mot de passe, puis confirmez-le.
+ Conservez tous les autres paramètres par défaut.
1. Choisissez **Créer un cluster**.
## Création d’un secret dans Secrets Manager
Pendant qu'Amazon DocumentDB crée votre cluster, créez un AWS Secrets Manager secret pour stocker les informations d'identification de votre base de données. Vous fournirez ce secret lors de la création du mappage des sources d’événements Lambda lors d’une étape ultérieure.
**Pour créer le secret dans Secrets Manager**
1. Ouvrez la console [Secrets Manager](https://console.aws.amazon.com/secretsmanager/home#) et choisissez **Stocker un nouveau secret**.
1. Pour **Choisir le type de secret**, sélectionnez les options suivantes :
+ Sous **Informations de base** :
+ **Type de secret** : informations d’identification pour votre base de données Amazon DocumentDB
+ Sous **Informations d’identification**, saisissez les mêmes nom d’utilisateur et mot de passe que vous avez utilisés pour créer votre cluster Amazon DocumentDB.
+ **Base de données** : choisissez votre cluster Amazon DocumentDB.
+ Choisissez **Suivant**.
1. Pour **Configurer le secret**, choisissez les options suivantes :
+ **Nom secret** : `DocumentDBSecret`
+ Choisissez **Suivant**.
1. Choisissez **Suivant**.
1. Choisissez **Stocker**.
1. Actualisez la console pour vérifier que vous avez correctement enregistré le secret `DocumentDBSecret`.
Notez l’**ARN du secret**. Vous en aurez besoin dans une étape ultérieure.
## Connexion au cluster
**Connectez-vous à votre cluster Amazon DocumentDB à l'aide de AWS CloudShell**
1. Dans la console de gestion Amazon DocumentDB, sous **Clusters**, recherchez le cluster que vous avez créé. Sélectionnez votre cluster en cochant la case en regard de celui-ci.
1. Choisissez **Se connecter au cluster**. L'écran CloudShell **Exécuter la commande** apparaît.
1. Dans le champ **Nom du nouvel environnement**, saisissez un nom unique, comme « test », puis choisissez **Créer et exécuter**.
1. Lorsque vous y êtes invité, saisissez votre mot de passe. Lorsque l’invite affiche `rs0 [direct: primary] >`, vous êtes connecté avec succès à votre cluster Amazon DocumentDB.
## Activation des flux de modifications
Pour ce tutoriel, vous allez suivre les modifications apportées à la collection `products` de la base de données `docdbdemo` dans votre cluster Amazon DocumentDB. Pour ce faire, vous activez les [flux de modifications](https://docs.aws.amazon.com/documentdb/latest/developerguide/change_streams.html).
**Pour créer une nouvelle base de données dans votre cluster**
1. Exécutez la commande suivante pour créer une nouvelle base de données appelée `docdbdemo` :
```
use docdbdemo
```
1. Dans la fenêtre de terminal, utilisez la commande suivante pour insérer un enregistrement dans `docdbdemo` :
```
db.products.insertOne({"hello":"world"})
```
Elle doit générer une sortie comme suit :
```
{
acknowledged: true,
insertedId: ObjectId('67f85066ca526410fd531d59')
}
```
1. Activez ensuite les flux de modifications sur la collection `products` de la base de données `docdbdemo` à l’aide de la commande suivante :
```
db.adminCommand({modifyChangeStreams: 1,
database: "docdbdemo",
collection: "products",
enable: true});
```
Vous devriez obtenir un résultat du type suivant :
```
{ "ok" : 1, "operationTime" : Timestamp(1680126165, 1) }
```
## Création de points de terminaison d’un VPC d’interface
Créez ensuite des [points de terminaison d’un VPC d’interface](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws) pour vous assurer que Lambda et Secrets Manager (utilisé plus tard pour stocker nos informations d’identification d’accès au cluster) peuvent se connecter à votre VPC par défaut.
**Pour créer des points de terminaison d’un VPC d’interface**
1. Ouvrez la [console VPC](https://console.aws.amazon.com/vpc/home#). Dans le menu de gauche, sous **Cloud privé virtuel**, choisissez **Points de terminaison**.
1. Choisissez **Créer un point de terminaison**. Créez un point de terminaison avec la configuration suivante :
+ Pour **Balise de nom**, saisissez `lambda-default-vpc`.
+ Pour la **catégorie de service**, sélectionnez AWS services.
+ Pour **Services**, saisissez `lambda` dans la zone de recherche. Choisissez le service au format `com.amazonaws..lambda`.
+ Pour **VPC**, choisissez le VPC dans lequel se trouve votre cluster Amazon DocumentDB. Il s’agit généralement du [VPC par défaut](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html).
+ Pour **Sous-réseaux**, cochez les cases à côté de chaque zone de disponibilité. Choisissez l’ID de sous-réseau correct pour chaque zone de disponibilité.
+ Pour le **type d'adresse IP**, sélectionnez IPv4.
+ Pour **Groupes de sécurité**, choisissez le groupe de sécurité utilisé par votre cluster Amazon DocumentDB. Il s’agit généralement du groupe de sécurité `default`.
+ Conservez tous les autres paramètres par défaut.
+ Choisissez **Créer un point de terminaison**.
1. Choisissez à nouveau **Créer un point de terminaison**. Créez un point de terminaison avec la configuration suivante :
+ Pour **Balise de nom**, saisissez `secretsmanager-default-vpc`.
+ Pour la **catégorie de service**, sélectionnez AWS services.
+ Pour **Services**, saisissez `secretsmanager` dans la zone de recherche. Choisissez le service au format `com.amazonaws..secretsmanager`.
+ Pour **VPC**, choisissez le VPC dans lequel se trouve votre cluster Amazon DocumentDB. Il s’agit généralement du [VPC par défaut](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html).
+ Pour **Sous-réseaux**, cochez les cases à côté de chaque zone de disponibilité. Choisissez l’ID de sous-réseau correct pour chaque zone de disponibilité.
+ Pour le **type d'adresse IP**, sélectionnez IPv4.
+ Pour **Groupes de sécurité**, choisissez le groupe de sécurité utilisé par votre cluster Amazon DocumentDB. Il s’agit généralement du groupe de sécurité `default`.
+ Conservez tous les autres paramètres par défaut.
+ Choisissez **Créer un point de terminaison**.
Ceci termine la partie de ce tutoriel concernant la configuration du cluster.
## Créer le rôle d’exécution
Dans les étapes suivantes, vous allez créer votre fonction Lambda. Tout d’abord, vous devez créer le rôle d’exécution qui donne à votre fonction l’autorisation d’accéder à votre cluster. Vous faites cela en créant d’abord une politique IAM, puis en associant cette politique à un rôle IAM.
**Pour créer une politique IAM**
1. Ouvrez la [page Politiques](https://console.aws.amazon.com/iam/home#/policies) dans la console IAM et choisissez **Créer une politique**.
1. Choisissez l’onglet **JSON**. Dans la politique suivante, remplacez l'ARN de la ressource Secrets Manager dans la dernière ligne de l'instruction par votre ARN secret précédent et copiez la politique dans l'éditeur.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "LambdaESMNetworkingAccess",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeVpcs",
"ec2:DeleteNetworkInterface",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups",
"kms:Decrypt"
],
"Resource": "*"
},
{
"Sid": "LambdaDocDBESMAccess",
"Effect": "Allow",
"Action": [
"rds:DescribeDBClusters",
"rds:DescribeDBClusterParameters",
"rds:DescribeDBSubnetGroups"
],
"Resource": "*"
},
{
"Sid": "LambdaDocDBESMGetSecretValueAccess",
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:DocumentDBSecret"
}
]
}
```
------
1. Choisissez **Suivant : Balises**, puis **Suivant : Vérification**.
1. Pour **Nom**, saisissez `AWSDocumentDBLambdaPolicy`.
1. Sélectionnez **Create policy** (Créer une politique).
**Pour créer le rôle IAM**
1. Ouvrez la [page Rôles](https://console.aws.amazon.com/iam/home#/roles) dans la console IAM et choisissez **Créer un rôle**.
1. Pour **Sélectionner une entité de confiance**, choisissez les options suivantes :
+ **Type d'entité de confiance** : AWS service
+ **Service ou cas d’utilisation** : Lambda
+ Choisissez **Suivant**.
1. Pour **Ajouter des autorisations**, choisissez la `AWSDocumentDBLambdaPolicy` politique que vous venez de créer, ainsi que celle permettant `AWSLambdaBasicExecutionRole` à votre fonction d'écrire sur Amazon CloudWatch Logs.
1. Choisissez **Suivant**.
1. Pour le **Nom du rôle**, saisissez `AWSDocumentDBLambdaExecutionRole`.
1. Choisissez **Créer un rôle**.
## Créer la fonction Lambda
Ce didacticiel utilise le moteur d'exécution Python 3.14, mais nous avons également fourni des exemples de fichiers de code pour d'autres environnements d'exécution. Vous pouvez sélectionner l’onglet dans la zone suivante pour voir le code d’exécution qui vous intéresse.
Le code reçoit une entrée d’événement Amazon DocumentDB et traite le message qu’elle contient.
**Pour créer la fonction Lambda**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez **Créer une fonction**.
1. Choisissez **Créer à partir de zéro**.
1. Sous **Basic information** (Informations de base), procédez comme suit :
1. Sous **Nom de la fonction**, saisissez `ProcessDocumentDBRecords`.
1. Pour **Runtime**, choisissez **Python 3.14**.
1. Pour **Architecture**, choisissez **x86\$164**.
1. Dans l’onglet **Modifier le rôle d’exécution par défaut**, procédez comme suit :
1. Ouvrez l’onglet, puis choisissez **Utiliser un rôle existant**.
1. Sélectionnez le `AWSDocumentDBLambdaExecutionRole` que vous avez créé précédemment.
1. Choisissez **Créer une fonction**.
**Pour déployer le code de la fonction**
1. Choisissez l’onglet **Python** dans la zone suivante et copiez le code.
------
#### [ .NET ]
**SDK pour .NET**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-docdb-to-lambda).
Consommation d’un événement Amazon DocumentDB avec Lambda en utilisant .NET.
```
using Amazon.Lambda.Core;
using System.Text.Json;
using System;
using System.Collections.Generic;
using System.Text.Json.Serialization;
//Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace LambdaDocDb;
public class Function
{
///
/// Lambda function entry point to process Amazon DocumentDB events.
///
/// The Amazon DocumentDB event.
/// The Lambda context object.
/// A string to indicate successful processing.
public string FunctionHandler(Event evnt, ILambdaContext context)
{
foreach (var record in evnt.Events)
{
ProcessDocumentDBEvent(record, context);
}
return "OK";
}
private void ProcessDocumentDBEvent(DocumentDBEventRecord record, ILambdaContext context)
{
var eventData = record.Event;
var operationType = eventData.OperationType;
var databaseName = eventData.Ns.Db;
var collectionName = eventData.Ns.Coll;
var fullDocument = JsonSerializer.Serialize(eventData.FullDocument, new JsonSerializerOptions { WriteIndented = true });
context.Logger.LogLine($"Operation type: {operationType}");
context.Logger.LogLine($"Database: {databaseName}");
context.Logger.LogLine($"Collection: {collectionName}");
context.Logger.LogLine($"Full document:\n{fullDocument}");
}
public class Event
{
[JsonPropertyName("eventSourceArn")]
public string EventSourceArn { get; set; }
[JsonPropertyName("events")]
public List Events { get; set; }
[JsonPropertyName("eventSource")]
public string EventSource { get; set; }
}
public class DocumentDBEventRecord
{
[JsonPropertyName("event")]
public EventData Event { get; set; }
}
public class EventData
{
[JsonPropertyName("_id")]
public IdData Id { get; set; }
[JsonPropertyName("clusterTime")]
public ClusterTime ClusterTime { get; set; }
[JsonPropertyName("documentKey")]
public DocumentKey DocumentKey { get; set; }
[JsonPropertyName("fullDocument")]
public Dictionary FullDocument { get; set; }
[JsonPropertyName("ns")]
public Namespace Ns { get; set; }
[JsonPropertyName("operationType")]
public string OperationType { get; set; }
}
public class IdData
{
[JsonPropertyName("_data")]
public string Data { get; set; }
}
public class ClusterTime
{
[JsonPropertyName("$timestamp")]
public Timestamp Timestamp { get; set; }
}
public class Timestamp
{
[JsonPropertyName("t")]
public long T { get; set; }
[JsonPropertyName("i")]
public int I { get; set; }
}
public class DocumentKey
{
[JsonPropertyName("_id")]
public Id Id { get; set; }
}
public class Id
{
[JsonPropertyName("$oid")]
public string Oid { get; set; }
}
public class Namespace
{
[JsonPropertyName("db")]
public string Db { get; set; }
[JsonPropertyName("coll")]
public string Coll { get; set; }
}
}
```
------
#### [ Go ]
**Kit SDK pour Go V2**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-docdb-to-lambda).
Consommation d’un événement Amazon DocumentDB avec Lambda en utilisant Go.
```
package main
import (
"context"
"encoding/json"
"fmt"
"github.com/aws/aws-lambda-go/lambda"
)
type Event struct {
Events []Record `json:"events"`
}
type Record struct {
Event struct {
OperationType string `json:"operationType"`
NS struct {
DB string `json:"db"`
Coll string `json:"coll"`
} `json:"ns"`
FullDocument interface{} `json:"fullDocument"`
} `json:"event"`
}
func main() {
lambda.Start(handler)
}
func handler(ctx context.Context, event Event) (string, error) {
fmt.Println("Loading function")
for _, record := range event.Events {
logDocumentDBEvent(record)
}
return "OK", nil
}
func logDocumentDBEvent(record Record) {
fmt.Printf("Operation type: %s\n", record.Event.OperationType)
fmt.Printf("db: %s\n", record.Event.NS.DB)
fmt.Printf("collection: %s\n", record.Event.NS.Coll)
docBytes, _ := json.MarshalIndent(record.Event.FullDocument, "", " ")
fmt.Printf("Full document: %s\n", string(docBytes))
}
```
------
#### [ Java ]
**SDK pour Java 2.x**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-docdb-to-lambda).
Consommation d’un événement Amazon DocumentDB avec Lambda en utilisant Java.
```
import java.util.List;
import java.util.Map;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
public class Example implements RequestHandler, String> {
@SuppressWarnings("unchecked")
@Override
public String handleRequest(Map event, Context context) {
List> events = (List>) event.get("events");
for (Map record : events) {
Map eventData = (Map) record.get("event");
processEventData(eventData);
}
return "OK";
}
@SuppressWarnings("unchecked")
private void processEventData(Map eventData) {
String operationType = (String) eventData.get("operationType");
System.out.println("operationType: %s".formatted(operationType));
Map ns = (Map) eventData.get("ns");
String db = (String) ns.get("db");
System.out.println("db: %s".formatted(db));
String coll = (String) ns.get("coll");
System.out.println("coll: %s".formatted(coll));
Map fullDocument = (Map) eventData.get("fullDocument");
System.out.println("fullDocument: %s".formatted(fullDocument));
}
}
```
------
#### [ JavaScript ]
**SDK pour JavaScript (v3)**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-docdb-to-lambda).
Consommation d'un événement Amazon DocumentDB avec Lambda à l'aide de. JavaScript
```
console.log('Loading function');
exports.handler = async (event, context) => {
event.events.forEach(record => {
logDocumentDBEvent(record);
});
return 'OK';
};
const logDocumentDBEvent = (record) => {
console.log('Operation type: ' + record.event.operationType);
console.log('db: ' + record.event.ns.db);
console.log('collection: ' + record.event.ns.coll);
console.log('Full document:', JSON.stringify(record.event.fullDocument, null, 2));
};
```
Utilisation d'un événement Amazon DocumentDB avec Lambda à l'aide de TypeScript
```
import { DocumentDBEventRecord, DocumentDBEventSubscriptionContext } from 'aws-lambda';
console.log('Loading function');
export const handler = async (
event: DocumentDBEventSubscriptionContext,
context: any
): Promise => {
event.events.forEach((record: DocumentDBEventRecord) => {
logDocumentDBEvent(record);
});
return 'OK';
};
const logDocumentDBEvent = (record: DocumentDBEventRecord): void => {
console.log('Operation type: ' + record.event.operationType);
console.log('db: ' + record.event.ns.db);
console.log('collection: ' + record.event.ns.coll);
console.log('Full document:', JSON.stringify(record.event.fullDocument, null, 2));
};
```
------
#### [ PHP ]
**Kit SDK pour PHP**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-docdb-to-lambda).
Consommation d’un événement Amazon DocumentDB avec Lambda en utilisant PHP.
```
logDocumentDBEvent($record['event']);
}
return 'OK';
}
private function logDocumentDBEvent($event): void
{
// Extract information from the event record
$operationType = $event['operationType'] ?? 'Unknown';
$db = $event['ns']['db'] ?? 'Unknown';
$collection = $event['ns']['coll'] ?? 'Unknown';
$fullDocument = $event['fullDocument'] ?? [];
// Log the event details
echo "Operation type: $operationType\n";
echo "Database: $db\n";
echo "Collection: $collection\n";
echo "Full document: " . json_encode($fullDocument, JSON_PRETTY_PRINT) . "\n";
}
}
return new DocumentDBEventHandler();
```
------
#### [ Python ]
**Kit SDK for Python (Boto3)**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-docdb-to-lambda).
Consommation d’un événement Amazon DocumentDB avec Lambda en utilisant Python.
```
import json
def lambda_handler(event, context):
for record in event.get('events', []):
log_document_db_event(record)
return 'OK'
def log_document_db_event(record):
event_data = record.get('event', {})
operation_type = event_data.get('operationType', 'Unknown')
db = event_data.get('ns', {}).get('db', 'Unknown')
collection = event_data.get('ns', {}).get('coll', 'Unknown')
full_document = event_data.get('fullDocument', {})
print(f"Operation type: {operation_type}")
print(f"db: {db}")
print(f"collection: {collection}")
print("Full document:", json.dumps(full_document, indent=2))
```
------
#### [ Ruby ]
**Kit SDK pour Ruby**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-docdb-to-lambda).
Consommation d’un événement Amazon DocumentDB avec Lambda en utilisant Ruby.
```
require 'json'
def lambda_handler(event:, context:)
event['events'].each do |record|
log_document_db_event(record)
end
'OK'
end
def log_document_db_event(record)
event_data = record['event'] || {}
operation_type = event_data['operationType'] || 'Unknown'
db = event_data.dig('ns', 'db') || 'Unknown'
collection = event_data.dig('ns', 'coll') || 'Unknown'
full_document = event_data['fullDocument'] || {}
puts "Operation type: #{operation_type}"
puts "db: #{db}"
puts "collection: #{collection}"
puts "Full document: #{JSON.pretty_generate(full_document)}"
end
```
------
#### [ Rust ]
**SDK pour Rust**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-docdb-to-lambda).
Consommation d’un événement Amazon DocumentDB avec Lambda en utilisant Rust.
```
use lambda_runtime::{service_fn, tracing, Error, LambdaEvent};
use aws_lambda_events::{
event::documentdb::{DocumentDbEvent, DocumentDbInnerEvent},
};
// Built with the following dependencies:
//lambda_runtime = "0.11.1"
//serde_json = "1.0"
//tokio = { version = "1", features = ["macros"] }
//tracing = { version = "0.1", features = ["log"] }
//tracing-subscriber = { version = "0.3", default-features = false, features = ["fmt"] }
//aws_lambda_events = "0.15.0"
async fn function_handler(event: LambdaEvent) ->Result<(), Error> {
tracing::info!("Event Source ARN: {:?}", event.payload.event_source_arn);
tracing::info!("Event Source: {:?}", event.payload.event_source);
let records = &event.payload.events;
if records.is_empty() {
tracing::info!("No records found. Exiting.");
return Ok(());
}
for record in records{
log_document_db_event(record);
}
tracing::info!("Document db records processed");
// Prepare the response
Ok(())
}
fn log_document_db_event(record: &DocumentDbInnerEvent)-> Result<(), Error>{
tracing::info!("Change Event: {:?}", record.event);
Ok(())
}
#[tokio::main]
async fn main() -> Result<(), Error> {
tracing_subscriber::fmt()
.with_max_level(tracing::Level::INFO)
.with_target(false)
.without_time()
.init();
let func = service_fn(function_handler);
lambda_runtime::run(func).await?;
Ok(())
}
```
------
1. Dans le volet **Code source** de la console Lambda, collez le code dans l’éditeur de code, en remplaçant le code créé par Lambda.
1. Dans la section **DÉPLOYER**, choisissez **Déployer** pour mettre à jour le code de votre fonction :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/getting-started-tutorial/deploy-console.png)
## Création du mappage des sources d’événements Lambda
Créez le mappage des sources d’événements qui associe votre flux de modifications Amazon DocumentDB à votre fonction Lambda. Après avoir créé ce mappage des sources d'événements, commence AWS Lambda immédiatement à interroger le flux.
**Pour créer le mappage des sources d’événements**
1. Ouvrez la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda.
1. Choisissez la fonction `ProcessDocumentDBRecords` que vous avez créée précédemment.
1. Choisissez l’onglet **Configuration**, puis **Déclencheurs** dans le menu de gauche.
1. Choisissez **Add trigger (Ajouter déclencheur)**.
1. Sous **Configuration du déclencheur**, pour la source, sélectionnez **Amazon DocumentDB**.
1. Créez le mappage des sources d’événements avec la configuration suivante :
+ **Cluster Amazon DocumentDB** : choisissez le cluster que vous avez créé précédemment.
+ **Nom de la base de données** : docdbdemo
+ **Nom de la collection** : products
+ **Taille du lot** : 1
+ **Position de départ** : dernière
+ **Authentification** : BASIC\$1AUTH
+ **Clé Secrets Manager** : choisissez le secret de votre cluster Amazon DocumentDB. Son nom ressemblera à `rds!cluster-12345678-a6f0-52c0-b290-db4aga89274f`.
+ **Fenêtre de traitement par lots** : 1
+ **Configuration complète du document** : UpdateLookup
1. Choisissez **Ajouter**. La création de votre mappage des sources d’événements peut prendre quelques minutes.
## Test de votre fonction
Attendez que le mappage des sources d’événements atteigne l’état **Activé**. Cela peut prendre plusieurs minutes. Testez ensuite la end-to-end configuration en insérant, en mettant à jour et en supprimant des enregistrements de base de données. Avant de commencer :
1. [Reconnectez-vous à votre cluster Amazon DocumentDB](#docdb-connect-to-cluster) dans CloudShell votre environnement.
1. Exécutez la commande suivante pour vous assurer que vous utilisez la base de données `docdbdemo` :
```
use docdbdemo
```
### Insérer un enregistrement
Insérez un enregistrement dans la collection `products` de la base de donnée `docdbdemo` :
```
db.products.insertOne({"name":"Pencil", "price": 1.00})
```
Vérifiez que votre fonction a correctement traité cet événement en [vérifiant CloudWatch les journaux](monitoring-cloudwatchlogs-view.md#monitoring-cloudwatchlogs-console). Vous devriez voir une entrée de journal comme celle-ci :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/documentdb-insert-log.png)
### Mettre à jour un enregistrement
Mettez à jour l’enregistrement que vous venez d’insérer à l’aide de la commande suivante :
```
db.products.updateOne(
{ "name": "Pencil" },
{ $set: { "price": 0.50 }}
)
```
Vérifiez que votre fonction a correctement traité cet événement en [vérifiant CloudWatch les journaux](monitoring-cloudwatchlogs-view.md#monitoring-cloudwatchlogs-console). Vous devriez voir une entrée de journal comme celle-ci :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/documentdb-update-log.png)
### Supprimer un enregistrement
Supprimez l’enregistrement que vous venez de mettre à jour à l’aide de la commande suivante :
```
db.products.deleteOne( { "name": "Pencil" } )
```
Vérifiez que votre fonction a correctement traité cet événement en [vérifiant CloudWatch les journaux](monitoring-cloudwatchlogs-view.md#monitoring-cloudwatchlogs-console). Vous devriez voir une entrée de journal comme celle-ci :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/documentdb-delete-log.png)
## Résolution des problèmes
Si aucun événement de base de données n'apparaît dans les CloudWatch journaux de votre fonction, vérifiez les points suivants :
+ Assurez-vous que le mappage des sources d’événements Lambda (également appelé déclencheur) est à l’état **Activé**. La création de mappages des sources d’événements peut prendre plusieurs minutes.
+ Si le mappage des sources d'événements est **activé** mais que les événements de base de données ne s'affichent toujours pas dans CloudWatch :
+ Assurez-vous que le **Nom de la base de données** dans le mappage des sources d’événements est défini sur `docdbdemo`.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/documentdb-trigger.png)
+ Vérifiez si le champ **Résultat du dernier traitement** du mappage des sources d'événements contient le message « PROBLEM: Connection error. Your VPC must be able to connect to Lambda and STS, as well as Secrets Manager if authentication is required. » Si cette erreur s’affiche, assurez-vous que vous avez [créé les points de terminaison de l’interface VPC de Lambda et Secrets Manager](#docdb-create-interface-vpc-endpoints), et que les points de terminaison utilisent le même VPC et les mêmes sous-réseaux que ceux utilisés par votre cluster Amazon DocumentDB.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/documentdb-lastprocessingresult.png)
## Nettoyage de vos ressources
Vous pouvez maintenant supprimer les ressources que vous avez créées pour ce didacticiel, sauf si vous souhaitez les conserver. En supprimant des ressources AWS que vous n’utilisez plus, vous évitez les frais superflus pour votre Compte AWS.
**Pour supprimer la fonction Lambda**
1. Ouvrez la [page Functions (Fonctions)](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda.
1. Sélectionnez la fonction que vous avez créée.
1. Sélectionnez **Actions**, **Supprimer**.
1. Saisissez **confirm** dans la zone de saisie de texte et choisissez **Delete** (Supprimer).
**Pour supprimer le rôle d’exécution**
1. Ouvrez la [page Roles (Rôles)](https://console.aws.amazon.com/iam/home#/roles) de la console IAM.
1. Sélectionnez le rôle d’exécution que vous avez créé.
1. Sélectionnez **Delete (Supprimer)**.
1. Saisissez le nom du rôle dans le champ de saisie de texte et choisissez **Delete** (Supprimer).
**Pour supprimer les points de terminaison d’un VPC**
1. Ouvrez la [console VPC](https://console.aws.amazon.com/vpc/home#). Dans le menu de gauche, sous **Cloud privé virtuel**, choisissez **Points de terminaison**.
1. Sélectionnez les points de terminaison que vous avez créés.
1. Choisissez **Actions**, **Delete VPC endpoints** (Supprimer le point de terminaison d’un VPC).
1. Saisissez **delete** dans le champ de saisie de texte.
1. Sélectionnez **Delete (Supprimer)**.
**Pour supprimer le cluster Amazon DocumentDB**
1. Ouvrez la [console Amazon DocumentDB](https://console.aws.amazon.com/docdb/home#).
1. Sélectionnez le cluster Amazon DocumentDB que vous avez créé pour ce tutoriel et désactivez la protection contre la suppression.
1. Dans la page principale **Clusters**, choisissez à nouveau votre cluster Amazon DocumentDB.
1. Sélectionnez **Actions**, **Supprimer**.
1. Pour **Créer un instantané final du cluster**, sélectionnez **Non**.
1. Saisissez **delete** dans le champ de saisie de texte.
1. Sélectionnez **Delete (Supprimer)**.
**Pour supprimer le secret dans Secrets Manager**
1. Ouvrez la [console Secrets Manager](https://console.aws.amazon.com/secretsmanager/home#).
1. Sélectionnez le secret que vous avez créé pour ce tutoriel.
1. Choisissez **Actions**, **Supprimer le secret**.
1. Choisissez **Schedule deletion (Planifier la suppression)**.
# Utilisation AWS Lambda avec Amazon DynamoDB
**Note**
Si vous souhaitez envoyer des données à une cible autre qu'une fonction Lambda ou enrichir les données avant de les envoyer, consultez [Amazon EventBridge ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-pipes.html) Pipes.
Vous pouvez utiliser une AWS Lambda fonction pour traiter les enregistrements d'un flux [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html). DynamoDB Streams vous permet de déclencher une fonction Lambda pour effectuer un travail supplémentaire chaque fois qu’une table DynamoDB est mise à jour.
Lorsque vous traitez des flux DynamoDB, vous devez implémenter une logique de réponse partielle de lot afin d’éviter le retraitement d’enregistrements traités avec succès si d’autres enregistrements du lot échouent. L'[utilitaire Batch Processor](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/) de Powertools for AWS Lambda est disponible en Python TypeScript, .NET et Java et simplifie cette implémentation en gérant automatiquement la logique de réponse partielle par lots, en réduisant le temps de développement et en améliorant la fiabilité.
**Topics**
+ [Flux d’interrogation et de mise en lots](#dynamodb-polling-and-batching)
+ [Positions de départ des interrogations et des flux](#dyanmo-db-stream-poll)
+ [Lecteurs simultanés d’une partition dans DynamoDB Streams](#events-dynamodb-simultaneous-readers)
+ [Exemple d’évènement](#events-sample-dynamodb)
+ [Traiter les enregistrements DynamoDB avec Lambda](services-dynamodb-eventsourcemapping.md)
+ [Configuration d’une réponse par lots partielle avec DynamoDB et Lambda](services-ddb-batchfailurereporting.md)
+ [Retenir les enregistrements ignorés pour une source d’événement DynamoDB dans Lambda](services-dynamodb-errors.md)
+ [Implémentation du traitement des flux DynamoDB avec état dans Lambda](services-ddb-windows.md)
+ [Paramètres Lambda pour les mappages des sources d’événement Amazon DynamoDB](services-ddb-params.md)
+ [Utilisation du filtrage des événements avec une source d’événement DynamoDB](with-ddb-filtering.md)
+ [Tutoriel : Utilisation AWS Lambda avec les flux Amazon DynamoDB](with-ddb-example.md)
## Flux d’interrogation et de mise en lots
Lambda interroge les partitions de votre flux DynamoDB en quête d’enregistrements à une fréquence de base de quatre fois par seconde. Lorsque des enregistrements sont disponibles, Lambda invoque votre fonction et attend le résultat. Si le traitement réussit, Lambda reprend l’interrogation jusqu’à recevoir plus d’enregistrements.
Par défaut, Lambda invoque votre fonction dès que des enregistrements sont disponibles. Si le lot que Lambda lit à partir de la source d’événements ne comprend qu’un seul enregistrement, Lambda envoie un seul registre à la fonction. Pour éviter d’invoquer la fonction avec un petit nombre de registres, vous pouvez indiquer à la source d’événement de les mettre en mémoire tampon pendant 5 minutes en configurant une *fenêtre de traitement par lots*. Avant d’invoquer la fonction, Lambda continue de lire les registres de la source d’événements jusqu’à ce qu’il ait rassemblé un lot complet, que la fenêtre de traitement par lot expire ou que le lot atteigne la limite de charge utile de 6 Mo. Pour de plus amples informations, veuillez consulter [Comportement de traitement par lots](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching).
**Avertissement**
Les mappages des sources d’événements Lambda traitent chaque événement au moins une fois, et le traitement des enregistrements peut être dupliqué. Pour éviter les problèmes potentiels liés à des événements dupliqués, nous vous recommandons vivement de rendre votre code de fonction idempotent. Pour en savoir plus, consultez [Comment rendre ma fonction Lambda idempotente](https://repost.aws/knowledge-center/lambda-function-idempotent) dans le Knowledge Center. AWS
Lambda envoi le prochain lot pour traitement sans attendre que les [extensions](lambda-extensions.md) configurées soient terminées. En d’autres termes, vos extensions peuvent continuer à s’exécuter pendant que Lambda traite le prochain lot d’enregistrements. Cela peut causer des problèmes de limitation si vous enfreignez l’un des paramètres ou l’une des limites de [simultanéité](lambda-concurrency.md) de votre compte. Pour détecter s’il s’agit d’un problème éventuel, surveillez vos fonctions et vérifiez si vous observez des [métriques de simultanéité](monitoring-concurrency.md#general-concurrency-metrics) plus élevées que prévu pour votre mappage des sources d’événements. En raison de la brièveté des intervalles entre les invocations, Lambda peut brièvement signaler une utilisation simultanée supérieure au nombre de partitions. Cela peut être vrai même pour les fonctions Lambda sans extensions.
Configurez le [ ParallelizationFactor](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-ParallelizationFactor)paramètre pour traiter une partition d'un flux DynamoDB avec plusieurs invocations Lambda simultanément. Vous pouvez spécifier le nombre de lots simultanés que Lambda interroge à partir d’une partition via un facteur de parallélisation de 1 (par défaut) à 10. Par exemple, quand vous définissez `ParallelizationFactor` sur 2, vous pouvez avoir jusqu’à 200 invocations Lambda simultanés pour traiter 100 partitions de données DynamoDB (bien que, dans la réalité, la métrique `ConcurrentExecutions` puisse indiquer une valeur différente). Cela permet d’augmenter le débit de traitement quand le volume de données est volatil et que la valeur du paramètre [IteratorAge](monitoring-metrics-types.md#performance-metrics) est élevée. Lorsque vous augmentez le nombre de lots simultanés par partition, Lambda assure toujours un traitement dans l’ordre au niveau de l’élément (partition et clé de tri).
## Positions de départ des interrogations et des flux
Sachez que l’interrogation des flux lors des mises à jour et de la création du mappage des sources d’événements est finalement cohérente.
+ Lors de la création du mappage des sources d’événements, le démarrage de l’interrogation des événements depuis le flux peut prendre plusieurs minutes.
+ Lors des mises à jour du mappage des sources d’événements, l’arrêt et le redémarrage de l’interrogation des événements depuis le flux peuvent prendre plusieurs minutes.
Ce comportement signifie que si vous spécifiez `LATEST` comme position de départ du flux, le mappage des sources d’événements peut manquer des événements lors de la création ou des mises à jour. Pour vous assurer de ne manquer aucun événement, spécifiez la position de départ du flux comme `TRIM_HORIZON`.
## Lecteurs simultanés d’une partition dans DynamoDB Streams
Pour les tables à région unique qui ne sont pas des tables globales, vous pouvez concevoir jusqu’à deux fonctions Lambda pour lire la même partition DynamoDB Streams simultanément. Le dépassement de cette limite peut se traduire par une limitation de la demande. Pour les tables globales, nous vous recommandons de limiter le nombre de fonctions simultanées à une seule pour éviter la limitation des demandes.
## Exemple d’évènement
**Example**
```
{
"Records": [
{
"eventID": "1",
"eventVersion": "1.0",
"dynamodb": {
"Keys": {
"Id": {
"N": "101"
}
},
"NewImage": {
"Message": {
"S": "New item!"
},
"Id": {
"N": "101"
}
},
"StreamViewType": "NEW_AND_OLD_IMAGES",
"SequenceNumber": "111",
"SizeBytes": 26
},
"awsRegion": "us-west-2",
"eventName": "INSERT",
"eventSourceARN": "arn:aws:dynamodb:us-east-2:123456789012:table/my-table/stream/2024-06-10T19:26:16.525",
"eventSource": "aws:dynamodb"
},
{
"eventID": "2",
"eventVersion": "1.0",
"dynamodb": {
"OldImage": {
"Message": {
"S": "New item!"
},
"Id": {
"N": "101"
}
},
"SequenceNumber": "222",
"Keys": {
"Id": {
"N": "101"
}
},
"SizeBytes": 59,
"NewImage": {
"Message": {
"S": "This item has changed"
},
"Id": {
"N": "101"
}
},
"StreamViewType": "NEW_AND_OLD_IMAGES"
},
"awsRegion": "us-west-2",
"eventName": "MODIFY",
"eventSourceARN": "arn:aws:dynamodb:us-east-2:123456789012:table/my-table/stream/2024-06-10T19:26:16.525",
"eventSource": "aws:dynamodb"
}
]}
```
# Traiter les enregistrements DynamoDB avec Lambda
Créez un mappage de source d’événement pour indiquer à Lambda d’envoyer des enregistrements de votre flux à une fonction Lambda. Vous pouvez créer plusieurs mappages de source d’événement pour traiter les mêmes données avec plusieurs fonctions Lambda, ou traiter des éléments de plusieurs flux avec une seule fonction.
Vous pouvez configurer des mappages de sources d’événements pour traiter les enregistrements d’un flux dans un autre Compte AWS. Pour en savoir plus, veuillez consulter la section [Création d’un mappage des sources d’événements entre comptes](#services-dynamodb-eventsourcemapping-cross-account).
**Pour configurer votre fonction de manière à lire depuis DynamoDB Streams, associez la politique AWS gérée [AWSLambdaDynamo Role à votre DBExecution rôle](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaDynamoDBExecutionRole.html) d'exécution, puis créez un déclencheur DynamoDB.**
**Pour ajouter des autorisations et créer un déclencheur**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez le nom d’une fonction.
1. Choisissez l’onglet **Configuration**, puis **Permissions** (Autorisations).
1. Sous **Nom du rôle**, cliquez sur le lien vers votre rôle d’exécution. Ce lien ouvre le rôle dans la console IAM.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/execution-role.png)
1. Choisissez **Ajouter des autorisations**, puis **Attacher des politiques**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/attach-policies.png)
1. Dans le champ de recherche, entrez `AWSLambdaDynamoDBExecutionRole`. Ajoutez cette politique à votre rôle d’exécution. Il s'agit d'une politique AWS gérée qui contient les autorisations dont votre fonction a besoin pour lire le flux DynamoDB. Pour plus d'informations sur cette politique, consultez [AWSLambdaDynamo DBExecution Role](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaDynamoDBExecutionRole.html) dans le manuel *AWS Managed Policy Reference*.
1. Revenez à votre fonction dans la console Lambda. Sous **Function overview (Vue d’ensemble de la fonction)**, choisissez **Add trigger (Ajouter un déclencheur)**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/add-trigger.png)
1. Choisissez un type de déclencheur.
1. Configurez les options requises, puis choisissez **Add (Ajouter)**.
Lambda prend en charge les options suivantes pour les sources d’événement DynamoDB :
**Options de source d’événement**
+ **DynamoDB table (Table DynamoDB)** – Table DynamoDB à partir de laquelle lire les enregistrements.
+ **Batch size (Taille de lot)** – Nombre d’enregistrements par lot à envoyer à la fonction, jusqu’à 10 000. Lambda transmet tous les enregistrements du lot à la fonction en une seule invocation, tant que la taille totale des événements ne dépasse pas la [limite de charge utile](gettingstarted-limits.md) pour une invocation synchrone (6 Mo).
+ **Batch window (Fenêtre de traitement par lots)** – Intervalle de temps maximum (en secondes) pour collecter des enregistrements avant d’invoquer la fonction.
+ **Starting position (Position de départ)** – Traiter uniquement les nouveaux enregistrements, ou tous enregistrement existants.
+ **Latest (Derniers)** – Traiter les nouveaux enregistrements ajoutés au flux.
+ **Trim horizon (Supprimer l’horizon)** – Traiter tous les enregistrements figurant dans le flux.
Après le traitement de tous les enregistrements existants, la fonction est à jour et continue à traiter les nouveaux enregistrements.
+ **Destination en cas d’échec** : une file d’attente SQS standard ou rubrique SNS standard pour les enregistrements qui ne peuvent pas être traités. Quand Lambda écarte un lot d’enregistrements qui est trop ancien ou qui a épuisé toutes les tentatives, il envoie les détails du lot à la file d’attente ou à la rubrique.
+ **Retry attempts (Nouvelles tentatives)** – Nombre maximum de nouvelles tentatives que Lambda effectue quand la fonction renvoie une erreur. Cela ne s’applique pas aux erreurs ou limitations de service où le lot n’a pas atteint la fonction.
+ **Maximum age of record (Âge maximum d’enregistrement)** – Âge maximum d’un enregistrement que Lambda envoie à votre fonction.
+ **Split batch on error (Fractionner le lot en cas d’erreur)** – Quand la fonction renvoie une erreur, diviser le lot en deux avant d’effectuer une nouvelle tentative. Le paramètre de taille de lot d’origine reste inchangé.
+ **Concurrent batches per shard (Lots simultanés par partition)** – Traite simultanément plusieurs lots de la même partition.
+ **Enabled (Activé)** – Valeur définie sur VRAI pour activer le mappage de source d’événement. Définissez la valeur sur « false » pour arrêter le traitement des enregistrements. Lambda garde une trace du dernier enregistrement traité et reprend le traitement à ce point lorsque le mappage est réactivé.
**Note**
Les appels d' GetRecords API invoqués par Lambda dans le cadre des déclencheurs DynamoDB ne vous sont pas facturés.
Pour gérer ultérieurement la configuration de la source d’événement, choisissez le déclencheur dans le concepteur.
## Création d’un mappage des sources d’événements entre comptes
[Amazon DynamoDB prend désormais en charge les politiques basées sur les ressources.](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/access-control-resource-based.html) Grâce à cette fonctionnalité, vous pouvez traiter les données d'un flux DynamoDB dans un compte Compte AWS avec une fonction Lambda dans un autre compte.
Pour créer un mappage de source d'événements pour votre fonction Lambda à l'aide d'un flux DynamoDB dans un autre Compte AWS, vous devez configurer le flux à l'aide d'une politique basée sur les ressources afin d'autoriser votre fonction Lambda à lire des enregistrements. *Pour savoir comment configurer votre flux pour un accès entre comptes, consultez [Partager l'accès avec les fonctions Lambda entre](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-cross-account-access.html#rbac-analyze-cross-account-lambda-access) comptes dans le guide du développeur Amazon DynamoDB.*
Une fois que vous avez configuré votre flux avec une politique basée sur les ressources qui donne à votre fonction Lambda les autorisations requises, créez le mappage des sources d'événements avec l'ARN de votre flux entre comptes. Vous pouvez trouver l'ARN du flux sous l'onglet **Exportations et flux** du tableau dans la console DynamoDB multicomptes.
Lorsque vous utilisez la console Lambda, collez l'ARN du flux directement dans le champ de saisie de la table DynamoDB sur la page de création du mappage des sources d'événements.
**Remarque :** Les déclencheurs interrégionaux ne sont pas pris en charge.
# Configuration d’une réponse par lots partielle avec DynamoDB et Lambda
Lors de l’utilisation et du traitement de données de streaming à partir d’une source d’événement, par défaut, Lambda n’effectue un point de contrôle sur le numéro de séquence le plus élevé d’un lot que lorsque celui-ci est un succès complet. Lambda traite tous les autres résultats comme un échec complet et recommence à traiter le lot jusqu’à atteindre la limite de nouvelles tentatives. Pour autoriser des succès partiels lors du traitement des lots à partir d’un flux, activez `ReportBatchItemFailures`. Autoriser des succès partiels peut permettre de réduire le nombre de nouvelles tentatives sur un enregistrement, mais cela n’empêche pas entièrement la possibilité de nouvelles tentatives dans un enregistrement réussi.
Pour activer `ReportBatchItemFailures`, incluez la valeur enum **ReportBatchItemFailures** dans la liste[FunctionResponseTypes](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-FunctionResponseTypes). Cette liste indique quels types de réponse sont activés pour votre fonction. Vous pouvez configurer cette liste lorsque vous [créez](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) ou [mettez à jour](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html) un mappage des sources d’événements.
**Note**
Même lorsque le code de votre fonction renvoie des réponses d’échec partiel de lot, ces réponses ne seront pas traitées par Lambda à moins que la fonctionnalité `ReportBatchItemFailures` soit explicitement activée pour votre mappage des sources d'événements.
## Syntaxe du rapport
Lors de la configuration des rapports d’échec d’articles de lot, la classe `StreamsEventResponse` est renvoyée avec une liste d’échecs d’articles de lot. Vous pouvez utiliser un objet `StreamsEventResponse` pour renvoyer le numéro de séquence du premier enregistrement ayant échoué dans le lot. Vous pouvez également créer votre classe personnalisée en utilisant la syntaxe de réponse correcte. La structure JSON suivante montre la syntaxe de réponse requise :
```
{
"batchItemFailures": [
{
"itemIdentifier": ""
}
]
}
```
**Note**
Si le tableau `batchItemFailures` contient plusieurs éléments, Lambda utilise l’enregistrement portant le numéro de séquence le plus bas comme point de contrôle. Lambda réessaie ensuite tous les enregistrements à partir de ce point de contrôle.
## Conditions de réussite et d’échec
Lambda traite un lot comme un succès complet si vous renvoyez l’un des éléments suivants :
+ Une liste `batchItemFailure` vide
+ Une liste `batchItemFailure` nulle
+ Une `EventResponse` vide
+ Un nu `EventResponse`
Lambda traite un lot comme un échec complet si vous renvoyez l’un des éléments suivants :
+ Une chaîne vid `itemIdentifier`
+ Un `itemIdentifier` nul
+ Un `itemIdentifier` avec un nom de clé incorrect
Lambda effectue des nouvelles tentatives en cas d’échec en fonction de votre stratégie de nouvelle tentative.
## Diviser un lot
Si votre invocation échoue et que `BisectBatchOnFunctionError` est activé, le lot est divisé en deux quel que soit votre paramètre `ReportBatchItemFailures`.
Quand une réponse de succès partiel de lot est reçue et que les paramètres `BisectBatchOnFunctionError` et `ReportBatchItemFailures` sont activés, le lot est divisé au numéro de séquence renvoyé, et Lambda n’effectue de nouvelle tentative que sur les enregistrements restants.
Pour simplifier la mise en œuvre de la logique de réponse partielle par lots, pensez à utiliser l'[utilitaire Batch Processor](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/) de Powertools for AWS Lambda, qui gère automatiquement ces complexités pour vous.
Voici quelques exemples de code de fonction qui renvoie la liste des messages ayant échoué IDs dans le lot :
------
#### [ .NET ]
**SDK pour .NET**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda-with-batch-item-handling).
Signalement des échecs d’articles par lots DynamoDB avec Lambda à l’aide de .NET.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using System.Text.Json;
using System.Text;
using Amazon.Lambda.Core;
using Amazon.Lambda.DynamoDBEvents;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace AWSLambda_DDB;
public class Function
{
public StreamsEventResponse FunctionHandler(DynamoDBEvent dynamoEvent, ILambdaContext context)
{
context.Logger.LogInformation($"Beginning to process {dynamoEvent.Records.Count} records...");
List batchItemFailures = new List();
StreamsEventResponse streamsEventResponse = new StreamsEventResponse();
foreach (var record in dynamoEvent.Records)
{
try
{
var sequenceNumber = record.Dynamodb.SequenceNumber;
context.Logger.LogInformation(sequenceNumber);
}
catch (Exception ex)
{
context.Logger.LogError(ex.Message);
batchItemFailures.Add(new StreamsEventResponse.BatchItemFailure() { ItemIdentifier = record.Dynamodb.SequenceNumber });
}
}
if (batchItemFailures.Count > 0)
{
streamsEventResponse.BatchItemFailures = batchItemFailures;
}
context.Logger.LogInformation("Stream processing complete.");
return streamsEventResponse;
}
}
```
------
#### [ Go ]
**Kit SDK pour Go V2**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda-with-batch-item-handling).
Signalement des échecs d’articles par lots DynamoDB avec Lambda à l’aide de Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package main
import (
"context"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
type BatchItemFailure struct {
ItemIdentifier string `json:"ItemIdentifier"`
}
type BatchResult struct {
BatchItemFailures []BatchItemFailure `json:"BatchItemFailures"`
}
func HandleRequest(ctx context.Context, event events.DynamoDBEvent) (*BatchResult, error) {
var batchItemFailures []BatchItemFailure
curRecordSequenceNumber := ""
for _, record := range event.Records {
// Process your record
curRecordSequenceNumber = record.Change.SequenceNumber
}
if curRecordSequenceNumber != "" {
batchItemFailures = append(batchItemFailures, BatchItemFailure{ItemIdentifier: curRecordSequenceNumber})
}
batchResult := BatchResult{
BatchItemFailures: batchItemFailures,
}
return &batchResult, nil
}
func main() {
lambda.Start(HandleRequest)
}
```
------
#### [ Java ]
**SDK pour Java 2.x**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda-with-batch-item-handling).
Signalement des échecs d’articles par lots DynamoDB avec Lambda à l’aide de Java.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.DynamodbEvent;
import com.amazonaws.services.lambda.runtime.events.StreamsEventResponse;
import com.amazonaws.services.lambda.runtime.events.models.dynamodb.StreamRecord;
import java.util.ArrayList;
import java.util.List;
public class ProcessDynamodbRecords implements RequestHandler {
@Override
public StreamsEventResponse handleRequest(DynamodbEvent input, Context context) {
List batchItemFailures = new ArrayList<>();
String curRecordSequenceNumber = "";
for (DynamodbEvent.DynamodbStreamRecord dynamodbStreamRecord : input.getRecords()) {
try {
//Process your record
StreamRecord dynamodbRecord = dynamodbStreamRecord.getDynamodb();
curRecordSequenceNumber = dynamodbRecord.getSequenceNumber();
} catch (Exception e) {
/* Since we are working with streams, we can return the failed item immediately.
Lambda will immediately begin to retry processing from this failed item onwards. */
batchItemFailures.add(new StreamsEventResponse.BatchItemFailure(curRecordSequenceNumber));
return new StreamsEventResponse(batchItemFailures);
}
}
return new StreamsEventResponse();
}
}
```
------
#### [ JavaScript ]
**SDK pour JavaScript (v3)**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda-with-batch-item-handling).
Signaler les défaillances d'éléments de lot DynamoDB avec Lambda à l'aide de. JavaScript
```
export const handler = async (event) => {
const records = event.Records;
let curRecordSequenceNumber = "";
for (const record of records) {
try {
// Process your record
curRecordSequenceNumber = record.dynamodb.SequenceNumber;
} catch (e) {
// Return failed record's sequence number
return { batchItemFailures: [{ itemIdentifier: curRecordSequenceNumber }] };
}
}
return { batchItemFailures: [] };
};
```
Signaler les défaillances d'éléments de lot DynamoDB avec Lambda à l'aide de. TypeScript
```
import {
DynamoDBBatchResponse,
DynamoDBBatchItemFailure,
DynamoDBStreamEvent,
} from "aws-lambda";
export const handler = async (
event: DynamoDBStreamEvent
): Promise => {
const batchItemFailures: DynamoDBBatchItemFailure[] = [];
let curRecordSequenceNumber;
for (const record of event.Records) {
curRecordSequenceNumber = record.dynamodb?.SequenceNumber;
if (curRecordSequenceNumber) {
batchItemFailures.push({
itemIdentifier: curRecordSequenceNumber,
});
}
}
return { batchItemFailures: batchItemFailures };
};
```
------
#### [ PHP ]
**Kit SDK pour PHP**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda-with-batch-item-handling).
Signalement des échecs d’articles par lots DynamoDB avec Lambda à l’aide de PHP.
```
logger = $logger;
}
/**
* @throws JsonException
* @throws \Bref\Event\InvalidLambdaEvent
*/
public function handle(mixed $event, Context $context): array
{
$dynamoDbEvent = new DynamoDbEvent($event);
$this->logger->info("Processing records");
$records = $dynamoDbEvent->getRecords();
$failedRecords = [];
foreach ($records as $record) {
try {
$data = $record->getData();
$this->logger->info(json_encode($data));
// TODO: Do interesting work based on the new data
} catch (Exception $e) {
$this->logger->error($e->getMessage());
// failed processing the record
$failedRecords[] = $record->getSequenceNumber();
}
}
$totalRecords = count($records);
$this->logger->info("Successfully processed $totalRecords records");
// change format for the response
$failures = array_map(
fn(string $sequenceNumber) => ['itemIdentifier' => $sequenceNumber],
$failedRecords
);
return [
'batchItemFailures' => $failures
];
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**Kit SDK for Python (Boto3)**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda-with-batch-item-handling).
Signalement des échecs d’articles par lots DynamoDB avec Lambda à l’aide de Python.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def handler(event, context):
records = event.get("Records")
curRecordSequenceNumber = ""
for record in records:
try:
# Process your record
curRecordSequenceNumber = record["dynamodb"]["SequenceNumber"]
except Exception as e:
# Return failed record's sequence number
return {"batchItemFailures":[{"itemIdentifier": curRecordSequenceNumber}]}
return {"batchItemFailures":[]}
```
------
#### [ Ruby ]
**Kit SDK pour Ruby**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda-with-batch-item-handling).
Signalement des échecs d’articles par lots DynamoDB avec Lambda à l’aide de Ruby.
```
def lambda_handler(event:, context:)
records = event["Records"]
cur_record_sequence_number = ""
records.each do |record|
begin
# Process your record
cur_record_sequence_number = record["dynamodb"]["SequenceNumber"]
rescue StandardError => e
# Return failed record's sequence number
return {"batchItemFailures" => [{"itemIdentifier" => cur_record_sequence_number}]}
end
end
{"batchItemFailures" => []}
end
```
------
#### [ Rust ]
**SDK pour Rust**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda-with-batch-item-handling).
Signalement des échecs d’articles par lots DynamoDB avec Lambda à l’aide de Rust.
```
use aws_lambda_events::{
event::dynamodb::{Event, EventRecord, StreamRecord},
streams::{DynamoDbBatchItemFailure, DynamoDbEventResponse},
};
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
/// Process the stream record
fn process_record(record: &EventRecord) -> Result<(), Error> {
let stream_record: &StreamRecord = &record.change;
// process your stream record here...
tracing::info!("Data: {:?}", stream_record);
Ok(())
}
/// Main Lambda handler here...
async fn function_handler(event: LambdaEvent) -> Result {
let mut response = DynamoDbEventResponse {
batch_item_failures: vec![],
};
let records = &event.payload.records;
if records.is_empty() {
tracing::info!("No records found. Exiting.");
return Ok(response);
}
for record in records {
tracing::info!("EventId: {}", record.event_id);
// Couldn't find a sequence number
if record.change.sequence_number.is_none() {
response.batch_item_failures.push(DynamoDbBatchItemFailure {
item_identifier: Some("".to_string()),
});
return Ok(response);
}
// Process your record here...
if process_record(record).is_err() {
response.batch_item_failures.push(DynamoDbBatchItemFailure {
item_identifier: record.change.sequence_number.clone(),
});
/* Since we are working with streams, we can return the failed item immediately.
Lambda will immediately begin to retry processing from this failed item onwards. */
return Ok(response);
}
}
tracing::info!("Successfully processed {} record(s)", records.len());
Ok(response)
}
#[tokio::main]
async fn main() -> Result<(), Error> {
tracing_subscriber::fmt()
.with_max_level(tracing::Level::INFO)
// disable printing the name of the module in every log line.
.with_target(false)
// disabling time is handy because CloudWatch will add the ingestion time.
.without_time()
.init();
run(service_fn(function_handler)).await
}
```
------
## Utilisation de Powertools pour le AWS Lambda traitement par lots
L'utilitaire de traitement par lots de Powertools for gère AWS Lambda automatiquement la logique de réponse partielle par lots, réduisant ainsi la complexité de la mise en œuvre du signalement des défaillances par lots. Voici des exemples d’utilisation de l’utilitaire de traitement par lots :
**Python**
Pour des exemples complets et des instructions de configuration, consultez la [documentation de l’utilitaire de traitement par lots](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/).
Traitement des enregistrements AWS Lambda de flux DynamoDB à l'aide d'un processeur par lots.
```
import json
from aws_lambda_powertools import Logger
from aws_lambda_powertools.utilities.batch import BatchProcessor, EventType, process_partial_response
from aws_lambda_powertools.utilities.data_classes import DynamoDBStreamEvent
from aws_lambda_powertools.utilities.typing import LambdaContext
processor = BatchProcessor(event_type=EventType.DynamoDBStreams)
logger = Logger()
def record_handler(record):
logger.info(record)
# Your business logic here
# Raise an exception to mark this record as failed
def lambda_handler(event, context: LambdaContext):
return process_partial_response(
event=event,
record_handler=record_handler,
processor=processor,
context=context
)
```
**TypeScript**
Pour des exemples complets et des instructions de configuration, consultez la [documentation de l’utilitaire de traitement par lots](https://docs.aws.amazon.com/powertools/typescript/latest/features/batch/).
Traitement des enregistrements AWS Lambda de flux DynamoDB à l'aide d'un processeur par lots.
```
import { BatchProcessor, EventType, processPartialResponse } from '@aws-lambda-powertools/batch';
import { Logger } from '@aws-lambda-powertools/logger';
import type { DynamoDBStreamEvent, Context } from 'aws-lambda';
const processor = new BatchProcessor(EventType.DynamoDBStreams);
const logger = new Logger();
const recordHandler = async (record: any): Promise => {
logger.info('Processing record', { record });
// Your business logic here
// Throw an error to mark this record as failed
};
export const handler = async (event: DynamoDBStreamEvent, context: Context) => {
return processPartialResponse(event, recordHandler, processor, {
context,
});
};
```
**Java**
Pour des exemples complets et des instructions de configuration, consultez la [documentation de l’utilitaire de traitement par lots](https://docs.powertools.aws.dev/lambda/java/latest/utilities/batch/).
Traitement des enregistrements AWS Lambda de flux DynamoDB à l'aide d'un processeur par lots.
```
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.DynamodbEvent;
import com.amazonaws.services.lambda.runtime.events.StreamsEventResponse;
import software.amazon.lambda.powertools.batch.BatchMessageHandlerBuilder;
import software.amazon.lambda.powertools.batch.handler.BatchMessageHandler;
public class DynamoDBStreamBatchHandler implements RequestHandler {
private final BatchMessageHandler handler;
public DynamoDBStreamBatchHandler() {
handler = new BatchMessageHandlerBuilder()
.withDynamoDbBatchHandler()
.buildWithRawMessageHandler(this::processMessage);
}
@Override
public StreamsEventResponse handleRequest(DynamodbEvent ddbEvent, Context context) {
return handler.processBatch(ddbEvent, context);
}
private void processMessage(DynamodbEvent.DynamodbStreamRecord dynamodbStreamRecord, Context context) {
// Process the change record
}
}
```
**.NET**
Pour des exemples complets et des instructions de configuration, consultez la [documentation de l’utilitaire de traitement par lots](https://docs.aws.amazon.com/powertools/dotnet/utilities/batch-processing/).
Traitement des enregistrements AWS Lambda de flux DynamoDB à l'aide d'un processeur par lots.
```
using System;
using System.Threading;
using System.Threading.Tasks;
using Amazon.Lambda.Core;
using Amazon.Lambda.DynamoDBEvents;
using Amazon.Lambda.Serialization.SystemTextJson;
using AWS.Lambda.Powertools.BatchProcessing;
[assembly: LambdaSerializer(typeof(DefaultLambdaJsonSerializer))]
namespace HelloWorld;
public class Customer
{
public string? CustomerId { get; set; }
public string? Name { get; set; }
public string? Email { get; set; }
public DateTime CreatedAt { get; set; }
}
internal class TypedDynamoDbRecordHandler : ITypedRecordHandler
{
public async Task HandleAsync(Customer customer, CancellationToken cancellationToken)
{
if (string.IsNullOrEmpty(customer.Email))
{
throw new ArgumentException("Customer email is required");
}
return await Task.FromResult(RecordHandlerResult.None);
}
}
public class Function
{
[BatchProcessor(TypedRecordHandler = typeof(TypedDynamoDbRecordHandler))]
public BatchItemFailuresResponse HandlerUsingTypedAttribute(DynamoDBEvent _)
{
return TypedDynamoDbStreamBatchProcessor.Result.BatchItemFailuresResponse;
}
}
```
# Retenir les enregistrements ignorés pour une source d’événement DynamoDB dans Lambda
La gestion des erreurs pour les mappages des sources d’événements DynamoDB n’est pas la même selon si l’erreur se produit avant que la fonction ne soit invoquée ou pendant l’invocation de la fonction :
+ **Avant l'appel :** si un mappage de source d'événement Lambda ne parvient pas à appeler la fonction en raison d'un ralentissement ou d'autres problèmes, il réessaie jusqu'à ce que les enregistrements expirent ou dépassent l'âge maximum configuré sur le mappage de source d'événement (). [MaximumRecordAgeInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumRecordAgeInSeconds)
+ **Pendant l'appel :** si la fonction est invoquée mais renvoie une erreur, Lambda réessaie jusqu'à ce que les enregistrements expirent, dépassent l'âge maximum [MaximumRecordAgeInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumRecordAgeInSeconds)() ou atteignent le quota de nouvelles tentatives configuré (). [MaximumRetryAttempts](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumRetryAttempts) Pour les erreurs de fonctionnement, vous pouvez également configurer [BisectBatchOnFunctionError](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-response-BisectBatchOnFunctionError), ce qui divise un lot défaillant en deux lots plus petits, isolant ainsi les mauvais enregistrements et évitant les délais d'attente. Le fractionnement des lots ne consomme pas le quota de nouvelles tentatives.
Si les mesures de gestion des erreurs échouent, Lambda ignore les enregistrements et poursuit le traitement des lots du flux. Avec les paramètres par défaut, cela signifie qu’un enregistrement défectueux peut bloquer le traitement sur la partition affectée pendant jusqu’à une journée. Pour éviter cela, configurez le mappage de source d’événement de votre fonction avec un nombre raisonnable de nouvelles tentatives et un âge maximum d’enregistrement correspondant à votre cas d’utilisation.
## Configuration des destinations pour les invocations ayant échoué
Pour retenir les enregistrements des invocations de mappage de sources d’événements qui ont échoué, ajoutez une destination au mappage des sources d’événements de votre fonction. Chaque enregistrement envoyé à la destination est un document JSON contenant les métadonnées sur l’invocation ayant échoué. Pour les destinations Amazon S3, Lambda envoie également l’intégralité de l’enregistrement d’invocation avec les métadonnées. Vous pouvez configurer n'importe quelle rubrique Amazon SNS, n'importe quelle file d'attente Amazon SQS, n'importe quel compartiment Amazon S3 ou Kafka comme destination.
Avec les destinations Amazon S3, vous pouvez utiliser la fonctionnalité [Notifications d’événements Amazon S3](https://docs.aws.amazon.com/) pour recevoir des notifications lorsque des objets sont chargés dans votre compartiment S3 de destination. Vous pouvez également configurer les notifications d’événements S3 pour invoquer une autre fonction Lambda afin d’effectuer un traitement automatique des lots ayant échoué.
Votre rôle d’exécution doit disposer d’autorisations pour la destination :
+ **Pour une destination SQS : [sqs](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) :** SendMessage
+ **[Pour une destination SNS : SNS:Publish](https://docs.aws.amazon.com/sns/latest/api/API_Publish.html)**
+ **Pour une destination S3 :** [s3 : PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html) et [s3 : ListBucket](https://docs.aws.amazon.com/AmazonS3/latest/API/ListObjectsV2.html)
+ **Pour une destination Kafka : [kafka-cluster](https://docs.aws.amazon.com/msk/latest/developerguide/kafka-actions.html) :** WriteData
Vous pouvez configurer un sujet Kafka comme destination en cas d'échec pour vos mappages de sources d'événements Kafka. Lorsque Lambda ne parvient pas à traiter les enregistrements après avoir épuisé toutes les tentatives ou lorsque les enregistrements dépassent l'âge maximum, Lambda envoie les enregistrements ayant échoué à la rubrique Kafka spécifiée pour un traitement ultérieur. Reportez-vous à [Utiliser un sujet Kafka comme destination en cas d'échec](kafka-on-failure-destination.md).
Si vous avez activé le chiffrement avec votre propre clé KMS pour une destination S3, le rôle d'exécution de votre fonction doit également être autorisé à appeler [kms : GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html). Si la clé KMS et la destination du compartiment S3 se trouvent dans un compte différent de celui de votre fonction Lambda et de votre rôle d'exécution, configurez la clé KMS pour qu'elle approuve le rôle d'exécution à autoriser. kms: GenerateDataKey
Pour configurer une destination en cas de panne à l’aide de la console, procédez comme suit :
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez une fonction.
1. Sous **Function overview (Vue d’ensemble de la fonction)**, choisissez **Add destination (Ajouter une destination)**.
1. Pour **Source**, choisissez **Invocation du mappage des sources d’événements**.
1. Pour le **mappage des sources d’événements**, choisissez une source d’événements configurée pour cette fonction.
1. Pour **Condition**, sélectionnez **En cas d’échec**. Pour les invocations de mappage des sources d’événements, il s’agit de la seule condition acceptée.
1. Pour **Type de destination**, choisissez le type de destination auquel Lambda envoie les enregistrements d’invocation.
1. Pour **Destination**, choisissez une ressource.
1. Choisissez **Enregistrer**.
Vous pouvez également configurer une destination en cas de panne à l'aide de AWS Command Line Interface (AWS CLI). Par exemple, la [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html)commande suivante ajoute un mappage de source d'événement avec une destination SQS en cas de défaillance pour : `MyFunction`
```
aws lambda create-event-source-mapping \
--function-name "MyFunction" \
--event-source-arn arn:aws:dynamodb:us-east-2:123456789012:table/my-table/stream/2024-06-10T19:26:16.525 \
--destination-config '{"OnFailure": {"Destination": "arn:aws:sqs:us-east-1:123456789012:dest-queue"}}'
```
La [update-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-event-source-mapping.html)commande suivante met à jour le mappage d'une source d'événements afin d'envoyer les enregistrements d'invocation ayant échoué vers une destination SNS après deux tentatives, ou si les enregistrements datent de plus d'une heure.
```
aws lambda update-event-source-mapping \
--uuid f89f8514-cdd9-4602-9e1f-01a5b77d449b \
--maximum-retry-attempts 2 \
--maximum-record-age-in-seconds 3600 \
--destination-config '{"OnFailure": {"Destination": "arn:aws:sns:us-east-1:123456789012:dest-topic"}}'
```
Les paramètres mis à jour sont appliqués de façon asynchrone et ne sont pas reflétés dans la sortie tant que le processus n’est pas terminé. Utilisez la commande [get-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/get-event-source-mapping.html) pour afficher l’état actuel.
Pour supprimer une destination, entrez une chaîne vide comme argument du paramètre `destination-config` :
```
aws lambda update-event-source-mapping \
--uuid f89f8514-cdd9-4602-9e1f-01a5b77d449b \
--destination-config '{"OnFailure": {"Destination": ""}}'
```
### Pratiques exemplaires en matière de sécurité pour les destinations Amazon S3
La suppression d’un compartiment S3 configuré comme destination sans supprimer la destination de la configuration de votre fonction peut engendrer un risque de sécurité. Si un autre utilisateur connaît le nom de votre compartiment de destination, il peut recréer le compartiment dans son Compte AWS. Les enregistrements des invocations ayant échoué seront envoyés dans son compartiment, exposant potentiellement les données de votre fonction.
**Avertissement**
Pour vous assurer que les enregistrements d'invocation de votre fonction ne peuvent pas être envoyés vers un compartiment S3 d'un autre Compte AWS, ajoutez une condition au rôle d'exécution de votre fonction qui limite `s3:PutObject` les autorisations aux compartiments de votre compte.
L’exemple suivant présente une politique IAM qui limite les autorisations `s3:PutObject` de votre fonction aux seuls compartiments de votre compte. Cette politique donne également à Lambda l’autorisation `s3:ListBucket` dont il a besoin pour utiliser un compartiment S3 comme destination.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "S3BucketResourceAccountWrite",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::*/*",
"arn:aws:s3:::*"
],
"Condition": {
"StringEquals": {
"s3:ResourceAccount": "111122223333"
}
}
}
]
}
```
Pour ajouter une politique d'autorisations au rôle d'exécution de votre fonction à l'aide du AWS Management Console ou AWS CLI, reportez-vous aux instructions des procédures suivantes :
------
#### [ Console ]
**Pour ajouter une politique d’autorisations au rôle d’exécution d’une fonction (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Sélectionnez la fonction Lambda dont vous voulez modifier le rôle d’exécution.
1. Sous l’onglet **Configuration**, sélectionnez **Autorisations**.
1. Sous l’onglet **Rôle d’exécution**, sélectionnez le **Nom du rôle** de votre fonction pour ouvrir la page de console IAM du rôle.
1. Ajoutez une politique d’autorisations de au rôle en procédant comme suit :
1. Dans le volet **Politiques d’autorisations**, choisissez **Ajouter des autorisations**, puis **Créer une politique en ligne**.
1. Dans l’**Éditeur de politique**, sélectionnez **JSON**.
1. Collez la politique que vous souhaitez ajouter dans l’éditeur (en remplacement du JSON existant), puis choisissez **Suivant**.
1. Sous **Détails de la politique**, saisissez un **Nom de la politique**.
1. Choisissez **Create Policy** (Créer une politique).
------
#### [ AWS CLI ]
**Pour ajouter une politique d’autorisations au rôle d’exécution d’une fonction (CLI)**
1. Créez un document de politique JSON avec les autorisations requises et enregistrez-le dans un répertoire local.
1. Utilisez la commande `put-role-policy` de la CLI IAM pour ajouter des autorisations au rôle d’exécution de votre fonction. Exécutez la commande suivante depuis le répertoire dans lequel vous avez enregistré votre document de politique JSON et remplacez le nom du rôle, le nom de la politique et le document de politique par vos propres valeurs.
```
aws iam put-role-policy \
--role-name my_lambda_role \
--policy-name LambdaS3DestinationPolicy \
--policy-document file://my_policy.json
```
------
### Exemple d’enregistrement d’invocation Amazon SNS et Amazon SQS
L’exemple suivant illustre un enregistrement d’invocation que Lambda envoie à une destination SQS ou SNS pour un flux DynamoDB.
```
{
"requestContext": {
"requestId": "316aa6d0-8154-xmpl-9af7-85d5f4a6bc81",
"functionArn": "arn:aws:lambda:us-east-2:123456789012:function:myfunction",
"condition": "RetryAttemptsExhausted",
"approximateInvokeCount": 1
},
"responseContext": {
"statusCode": 200,
"executedVersion": "$LATEST",
"functionError": "Unhandled"
},
"version": "1.0",
"timestamp": "2019-11-14T00:13:49.717Z",
"DDBStreamBatchInfo": {
"shardId": "shardId-00000001573689847184-864758bb",
"startSequenceNumber": "800000000003126276362",
"endSequenceNumber": "800000000003126276362",
"approximateArrivalOfFirstRecord": "2019-11-14T00:13:19Z",
"approximateArrivalOfLastRecord": "2019-11-14T00:13:19Z",
"batchSize": 1,
"streamArn": "arn:aws:dynamodb:us-east-2:123456789012:table/mytable/stream/2019-11-14T00:04:06.388"
}
}
```
Vous pouvez utiliser ces informations pour récupérer les enregistrements concernés à partir du flux à des fins de résolution de problèmes. Les enregistrements réels n’étant pas inclus, vous devez les récupérer du flux avant qu’ils expirent et soient perdus.
### Exemple d’enregistrement d’invocation Amazon S3
L’exemple suivant illustre un enregistrement d’invocation que Lambda envoie à un compartiment S3 pour un flux DynamoDB. Outre tous les champs de l’exemple précédent pour les destinations SQS et SNS, le champ `payload` contient l’enregistrement d’invocation d’origine sous forme de chaîne JSON échappée.
```
{
"requestContext": {
"requestId": "316aa6d0-8154-xmpl-9af7-85d5f4a6bc81",
"functionArn": "arn:aws:lambda:us-east-2:123456789012:function:myfunction",
"condition": "RetryAttemptsExhausted",
"approximateInvokeCount": 1
},
"responseContext": {
"statusCode": 200,
"executedVersion": "$LATEST",
"functionError": "Unhandled"
},
"version": "1.0",
"timestamp": "2019-11-14T00:13:49.717Z",
"DDBStreamBatchInfo": {
"shardId": "shardId-00000001573689847184-864758bb",
"startSequenceNumber": "800000000003126276362",
"endSequenceNumber": "800000000003126276362",
"approximateArrivalOfFirstRecord": "2019-11-14T00:13:19Z",
"approximateArrivalOfLastRecord": "2019-11-14T00:13:19Z",
"batchSize": 1,
"streamArn": "arn:aws:dynamodb:us-east-2:123456789012:table/mytable/stream/2019-11-14T00:04:06.388"
},
"payload": "" // Only available in S3
}
```
L’objet S3 contenant l’enregistrement d’invocation utilise la convention de dénomination suivante :
```
aws/lambda///YYYY/MM/DD/YYYY-MM-DDTHH.MM.SS-
```
# Implémentation du traitement des flux DynamoDB avec état dans Lambda
Les fonctions Lambda peuvent exécuter des applications de traitement de flux continu. Un flux représente des données illimitées qui circulent en continu dans votre application. Pour analyser les informations provenant de cette entrée de mise à jour continue, vous pouvez lier les enregistrements inclus à l’aide d’une fenêtre de temps définie.
Les fenêtres bascules sont des fenêtres temporelles distinctes qui s’ouvrent et se ferment à intervalles réguliers. Par défaut, les invocations Lambda sont sans état : vous ne pouvez pas les utiliser pour traiter des données sur plusieurs invocations continues sans base de données externe. Cependant, avec les fenêtres bascules, vous pouvez maintenir votre état au long des invocations. Cet état contient le résultat global des messages précédemment traités pour la fenêtre actuelle. Votre état peut être d’un maximum de 1 Mo par partition. S’il dépasse cette taille, Lambda met fin précocement à la fenêtre de traitement.
Chaque enregistrement d’un flux appartient à une fenêtre spécifique. La fonction Lambda traitera chaque enregistrement au moins une fois. Toutefois, elle ne garantit pas un seul traitement pour chaque enregistrement. Dans de rares cas, tels que pour la gestion des erreurs, certains enregistrements peuvent être sujet à de multiples traitements. Les dossiers sont toujours traités dans l’ordre dès la première fois. Si les enregistrements sont traités plusieurs fois, ils peuvent être traités dans le désordre.
## Regroupement et traitement
Votre fonction gérée par l’utilisateur est invoquée tant pour l’agrégation que pour le traitement des résultats finaux de celle-ci. Lambda regroupe tous les enregistrements reçus dans la fenêtre. Vous pouvez recevoir ces enregistrements en plusieurs lots, chacun sous forme d’invocation séparée. Chaque invocation reçoit un état. Ainsi, lorsque vous utilisez des fenêtres bascules, votre réponse de fonction Lambda doit contenir une propriété `state`. Si la réponse ne contient pas de propriété `state`, Lambda considère qu’il s’agit d’une invocation ayant échoué. Pour satisfaire à cette condition, votre fonction peut renvoyer un objet `TimeWindowEventResponse` ayant la forme JSON suivante :
**Example `TimeWindowEventResponse` values**
```
{
"state": {
"1": 282,
"2": 715
},
"batchItemFailures": []
}
```
**Note**
Pour les fonctions Java, nous vous recommandons d’utiliser `Map` pour représenter l’état.
À la fin de la fenêtre, l’indicateur `isFinalInvokeForWindow` est défini sur `true` pour indiquer qu’il s’agit de l’état final et qu’il est prêt pour le traitement. Après le traitement, la fenêtre et votre invocation final se terminent, puis l’état est supprimé.
À la fin de votre fenêtre, Lambda applique un traitement final pour les actions sur les résultats de l’agrégation. Votre traitement final est invoqué de manière synchrone. Une fois l’invocation réussie, votre fonction contrôle le numéro de séquence et le traitement du flux continue. Si l’invocation échoue, votre fonction Lambda suspend le traitement ultérieur jusqu’à ce que l’invocation soit réussie.
**Example DynamodbTimeWindowEvent**
```
{
"Records":[
{
"eventID":"1",
"eventName":"INSERT",
"eventVersion":"1.0",
"eventSource":"aws:dynamodb",
"awsRegion":"us-east-1",
"dynamodb":{
"Keys":{
"Id":{
"N":"101"
}
},
"NewImage":{
"Message":{
"S":"New item!"
},
"Id":{
"N":"101"
}
},
"SequenceNumber":"111",
"SizeBytes":26,
"StreamViewType":"NEW_AND_OLD_IMAGES"
},
"eventSourceARN":"stream-ARN"
},
{
"eventID":"2",
"eventName":"MODIFY",
"eventVersion":"1.0",
"eventSource":"aws:dynamodb",
"awsRegion":"us-east-1",
"dynamodb":{
"Keys":{
"Id":{
"N":"101"
}
},
"NewImage":{
"Message":{
"S":"This item has changed"
},
"Id":{
"N":"101"
}
},
"OldImage":{
"Message":{
"S":"New item!"
},
"Id":{
"N":"101"
}
},
"SequenceNumber":"222",
"SizeBytes":59,
"StreamViewType":"NEW_AND_OLD_IMAGES"
},
"eventSourceARN":"stream-ARN"
},
{
"eventID":"3",
"eventName":"REMOVE",
"eventVersion":"1.0",
"eventSource":"aws:dynamodb",
"awsRegion":"us-east-1",
"dynamodb":{
"Keys":{
"Id":{
"N":"101"
}
},
"OldImage":{
"Message":{
"S":"This item has changed"
},
"Id":{
"N":"101"
}
},
"SequenceNumber":"333",
"SizeBytes":38,
"StreamViewType":"NEW_AND_OLD_IMAGES"
},
"eventSourceARN":"stream-ARN"
}
],
"window": {
"start": "2020-07-30T17:00:00Z",
"end": "2020-07-30T17:05:00Z"
},
"state": {
"1": "state1"
},
"shardId": "shard123456789",
"eventSourceARN": "stream-ARN",
"isFinalInvokeForWindow": false,
"isWindowTerminatedEarly": false
}
```
## Configuration
Vous pouvez configurer des fenêtres bascule lorsque vous créez ou mettez à jour un mappage de source d’événement. Pour configurer une fenêtre variable, spécifiez la fenêtre en secondes ([TumblingWindowInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-TumblingWindowInSeconds)). L'exemple de commande suivant AWS Command Line Interface (AWS CLI) crée un mappage des sources d'événements de streaming dont la fenêtre de basculement est de 120 secondes. La fonction Lambda définie pour l’agrégation et le traitement est nommée `tumbling-window-example-function`.
```
aws lambda create-event-source-mapping \
--event-source-arn arn:aws:dynamodb:us-east-2:123456789012:table/my-table/stream/2024-06-10T19:26:16.525 \
--function-name tumbling-window-example-function \
--starting-position TRIM_HORIZON \
--tumbling-window-in-seconds 120
```
Lambda détermine les limites des fenêtres bascule en fonction de l’heure à laquelle les enregistrements ont été insérés dans le flux. Tous les enregistrements ont un horodatage approximatif disponible que Lambda utilise pour déterminer des limites.
Les agrégations de fenêtres bascule ne prennent pas en charge le repartitionnement. Quand la partition prend fin, Lambda considère que la fenêtre de traitement est fermée, et les partitions enfants entament leur propre fenêtre de traitement dans un nouvel état.
Les fenêtres bascule prennent complètement en charge les stratégies de nouvelle tentative existantes `maxRetryAttempts` et `maxRecordAge`.
**Example Handler.py – Agrégation et traitement**
La fonction Python suivante montre comment regrouper et traiter votre état final :
```
def lambda_handler(event, context):
print('Incoming event: ', event)
print('Incoming state: ', event['state'])
#Check if this is the end of the window to either aggregate or process.
if event['isFinalInvokeForWindow']:
# logic to handle final state of the window
print('Destination invoke')
else:
print('Aggregate invoke')
#Check for early terminations
if event['isWindowTerminatedEarly']:
print('Window terminated early')
#Aggregation logic
state = event['state']
for record in event['Records']:
state[record['dynamodb']['NewImage']['Id']] = state.get(record['dynamodb']['NewImage']['Id'], 0) + 1
print('Returning state: ', state)
return {'state': state}
```
# Paramètres Lambda pour les mappages des sources d’événement Amazon DynamoDB
Tous les types de sources d'événements Lambda partagent les mêmes opérations [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)et les mêmes opérations d'[UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)API. Cependant, seuls certains paramètres s’appliquent à DynamoDB Streams.
| Paramètre | Obligatoire | Par défaut | Remarques |
| --- | --- | --- | --- |
| BatchSize | N | 100 | Maximum : 10 000. |
| BisectBatchOnFunctionError | N | FAUX | Aucune |
| DestinationConfig | N | N/A | File d’attente Amazon SQS standard ou destination de rubrique Amazon SNS standard pour les enregistrements ignorés |
| Activé | N | VRAI | Aucune |
| EventSourceArn | Y | N/A | ARN du flux de données ou d’un consommateur de flux |
| FilterCriteria | N | N/A | [Contrôle des événements envoyés par Lambda à votre fonction](invocation-eventfiltering.md) |
| FunctionName | Y | N/A | Aucune |
| FunctionResponseTypes | N | N/A | Pour permettre à votre fonction de signaler des échecs spécifiques dans un lot, incluez la valeur `ReportBatchItemFailures` dans `FunctionResponseTypes`. Pour de plus amples informations, veuillez consulter [Configuration d’une réponse par lots partielle avec DynamoDB et Lambda](services-ddb-batchfailurereporting.md). |
| MaximumBatchingWindowInSeconds | N | 0 | Aucune |
| MaximumRecordAgeInSeconds | N | -1 | -1 signifie infini : les enregistrements qui ont échoué sont réessayés jusqu’à ce que l’enregistrement expire. La [limite de conservation des données pour les flux DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html#Streams.DataRetention) est de 24 heures. Minimum : -1 Maximum : 604 800 |
| MaximumRetryAttempts | N | -1 | -1 signifie infini : les registres qui ont échoué sont réessayés jusqu’à ce que le registre expire. Minimum : 0 Maximum : 10 000. |
| ParallelizationFactor | N | 1 | Maximum : 10 |
| StartingPosition | Y | N/A | TRIM\$1HORIZON ou LATEST |
| TumblingWindowInSeconds | N | N/A | Minimum : 0 Maximum : 900 |
# Utilisation du filtrage des événements avec une source d’événement DynamoDB
Vous pouvez utiliser le filtrage d’événements pour contrôler les enregistrements d’un flux ou d’une file d’attente que Lambda envoie à votre fonction. Pour obtenir des informations générales sur le fonctionnement du filtrage des événements, consultez [Contrôle des événements envoyés par Lambda à votre fonction](invocation-eventfiltering.md).
Cette section porte sur le filtrage des événements pour les sources d’événement DynamoDB.
**Note**
Les mappages des sources d’événements DynamoDB prennent uniquement en charge le filtrage sur la clé `dynamodb`.
**Topics**
+ [Événement DynamoDB](#filtering-ddb)
+ [Filtrage à l’aide des attributs de table](#filtering-ddb-attributes)
+ [Filtrage à l’aide d’expressions booléennes](#filtering-ddb-boolean)
+ [Utilisation de l’opérateur Exists](#filtering-ddb-exists)
+ [Format JSON pour le filtrage DynamoDB](#filtering-ddb-JSON-format)
## Événement DynamoDB
Supposons que vous ayez une table DynamoDB avec la clé primaire `CustomerName` et les attributs `AccountManager` et `PaymentTerms`. La figure suivante montre un exemple d’enregistrement provenant du flux de votre table DynamoDB.
```
{
"eventID": "1",
"eventVersion": "1.0",
"dynamodb": {
"ApproximateCreationDateTime": "1678831218.0",
"Keys": {
"CustomerName": {
"S": "AnyCompany Industries"
}
},
"NewImage": {
"AccountManager": {
"S": "Pat Candella"
},
"PaymentTerms": {
"S": "60 days"
},
"CustomerName": {
"S": "AnyCompany Industries"
}
},
"SequenceNumber": "111",
"SizeBytes": 26,
"StreamViewType": "NEW_IMAGE"
}
}
```
Pour filtrer sur la base des valeurs de clé et d’attribut de votre table DynamoDB, utilisez la clé `dynamodb` dans l’enregistrement. Les sections suivantes fournissent des exemples de différents types de filtres.
### Filtrage à l’aide des clés de table
Supposons que vous vouliez que votre fonction ne traite que les enregistrements dont la clé primaire `CustomerName` est « AnyCompany Industries. » L’objet `FilterCriteria` serait le suivant.
```
{
"Filters": [
{
"Pattern": "{ \"dynamodb\" : { \"Keys\" : { \"CustomerName\" : { \"S\" : [ \"AnyCompany Industries\" ] } } } }"
}
]
}
```
Pour plus de clarté, voici la valeur du `Pattern` de filtre étendu en JSON simple :
```
{
"dynamodb": {
"Keys": {
"CustomerName": {
"S": [ "AnyCompany Industries" ]
}
}
}
}
```
Vous pouvez ajouter votre filtre à l’aide de la console, d’AWS CLI ou d’un modèle AWS SAM.
------
#### [ Console ]
Pour ajouter ce filtre à l’aide de la console, suivez les instructions de [Attacher des critères de filtre à un mappage de sources d’événements (console)](invocation-eventfiltering.md#filtering-console) et saisissez la chaîne suivante comme **critère de filtre**.
```
{ "dynamodb" : { "Keys" : { "CustomerName" : { "S" : [ "AnyCompany Industries" ] } } } }
```
------
#### [ AWS CLI ]
Pour créer un nouveau mappage des sources d’événements avec ces critères de filtrage à l’aide de l’outil AWS Command Line Interface (AWS CLI), exécutez la commande suivante.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:dynamodb:us-east-2:123456789012:table/my-table \
--filter-criteria '{"Filters": [{"Pattern": "{ \"dynamodb\" : { \"Keys\" : { \"CustomerName\" : { \"S\" : [ \"AnyCompany Industries\" ] } } } }"}]}'
```
Pour ajouter ces critères de filtre à un mappage des sources d’événements existant, exécutez la commande suivante.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"dynamodb\" : { \"Keys\" : { \"CustomerName\" : { \"S\" : [ \"AnyCompany Industries\" ] } } } }"}]}'
```
------
#### [ AWS SAM ]
Pour ajouter ce filtre à l’aide d’AWS SAM, ajoutez l’extrait suivant au modèle YAML de votre source d’événement.
```
FilterCriteria:
Filters:
- Pattern: '{ "dynamodb" : { "Keys" : { "CustomerName" : { "S" : [ "AnyCompany Industries" ] } } } }'
```
------
## Filtrage à l’aide des attributs de table
Avec DynamoDB, vous pouvez également utiliser les clés `NewImage` et `OldImage` pour filtrer les valeurs d’attributs. Supposons que vous vouliez filtrer les enregistrements où l’attribut `AccountManager` de la dernière image de la table est « Pat Candella » ou « Shirley Rodriguez ». L’objet `FilterCriteria` serait le suivant.
```
{
"Filters": [
{
"Pattern": "{ \"dynamodb\" : { \"NewImage\" : { \"AccountManager\" : { \"S\" : [ \"Pat Candella\", \"Shirley Rodriguez\" ] } } } }"
}
]
}
```
Pour plus de clarté, voici la valeur du `Pattern` de filtre étendu en JSON simple :
```
{
"dynamodb": {
"NewImage": {
"AccountManager": {
"S": [ "Pat Candella", "Shirley Rodriguez" ]
}
}
}
}
```
Vous pouvez ajouter votre filtre à l’aide de la console, d’AWS CLI ou d’un modèle AWS SAM.
------
#### [ Console ]
Pour ajouter ce filtre à l’aide de la console, suivez les instructions de [Attacher des critères de filtre à un mappage de sources d’événements (console)](invocation-eventfiltering.md#filtering-console) et saisissez la chaîne suivante comme **critère de filtre**.
```
{ "dynamodb" : { "NewImage" : { "AccountManager" : { "S" : [ "Pat Candella", "Shirley Rodriguez" ] } } } }
```
------
#### [ AWS CLI ]
Pour créer un nouveau mappage des sources d’événements avec ces critères de filtrage à l’aide de l’outil AWS Command Line Interface (AWS CLI), exécutez la commande suivante.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:dynamodb:us-east-2:123456789012:table/my-table \
--filter-criteria '{"Filters": [{"Pattern": "{ \"dynamodb\" : { \"NewImage\" : { \"AccountManager\" : { \"S\" : [ \"Pat Candella\", \"Shirley Rodriguez\" ] } } } }"}]}'
```
Pour ajouter ces critères de filtre à un mappage des sources d’événements existant, exécutez la commande suivante.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"dynamodb\" : { \"NewImage\" : { \"AccountManager\" : { \"S\" : [ \"Pat Candella\", \"Shirley Rodriguez\" ] } } } }"}]}'
```
------
#### [ AWS SAM ]
Pour ajouter ce filtre à l’aide d’AWS SAM, ajoutez l’extrait suivant au modèle YAML de votre source d’événement.
```
FilterCriteria:
Filters:
- Pattern: '{ "dynamodb" : { "NewImage" : { "AccountManager" : { "S" : [ "Pat Candella", "Shirley Rodriguez" ] } } } }'
```
------
## Filtrage à l’aide d’expressions booléennes
Vous pouvez également créer des filtres à l’aide des expressions booléennes AND. Ces expressions peuvent inclure les paramètres de clé et d’attribut de votre table. Supposons que vous souhaitiez filtrer les enregistrements dont la valeur `NewImage` d’`AccountManager` est « Pat Candella » et la valeur `OldImage` est « Terry Whitlock ». L’objet `FilterCriteria` serait le suivant.
```
{
"Filters": [
{
"Pattern": "{ \"dynamodb\" : { \"NewImage\" : { \"AccountManager\" : { \"S\" : [ \"Pat Candella\" ] } } } , \"dynamodb\" : { \"OldImage\" : { \"AccountManager\" : { \"S\" : [ \"Terry Whitlock\" ] } } } }"
}
]
}
```
Pour plus de clarté, voici la valeur du `Pattern` de filtre étendu en JSON simple :
```
{
"dynamodb" : {
"NewImage" : {
"AccountManager" : {
"S" : [
"Pat Candella"
]
}
}
},
"dynamodb": {
"OldImage": {
"AccountManager": {
"S": [
"Terry Whitlock"
]
}
}
}
}
```
Vous pouvez ajouter votre filtre à l’aide de la console, d’AWS CLI ou d’un modèle AWS SAM.
------
#### [ Console ]
Pour ajouter ce filtre à l’aide de la console, suivez les instructions de [Attacher des critères de filtre à un mappage de sources d’événements (console)](invocation-eventfiltering.md#filtering-console) et saisissez la chaîne suivante comme **critère de filtre**.
```
{ "dynamodb" : { "NewImage" : { "AccountManager" : { "S" : [ "Pat Candella" ] } } } , "dynamodb" : { "OldImage" : { "AccountManager" : { "S" : [ "Terry Whitlock" ] } } } }
```
------
#### [ AWS CLI ]
Pour créer un nouveau mappage des sources d’événements avec ces critères de filtrage à l’aide de l’outil AWS Command Line Interface (AWS CLI), exécutez la commande suivante.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:dynamodb:us-east-2:123456789012:table/my-table \
--filter-criteria '{"Filters": [{"Pattern": "{ \"dynamodb\" : { \"NewImage\" : { \"AccountManager\" : { \"S\" : [ \"Pat Candella\" ] } } } , \"dynamodb\" : { \"OldImage\" : { \"AccountManager\" : { \"S\" : [ \"Terry Whitlock\" ] } } } } "}]}'
```
Pour ajouter ces critères de filtre à un mappage des sources d’événements existant, exécutez la commande suivante.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"dynamodb\" : { \"NewImage\" : { \"AccountManager\" : { \"S\" : [ \"Pat Candella\" ] } } } , \"dynamodb\" : { \"OldImage\" : { \"AccountManager\" : { \"S\" : [ \"Terry Whitlock\" ] } } } } "}]}'
```
------
#### [ AWS SAM ]
Pour ajouter ce filtre à l’aide d’AWS SAM, ajoutez l’extrait suivant au modèle YAML de votre source d’événement.
```
FilterCriteria:
Filters:
- Pattern: '{ "dynamodb" : { "NewImage" : { "AccountManager" : { "S" : [ "Pat Candella" ] } } } , "dynamodb" : { "OldImage" : { "AccountManager" : { "S" : [ "Terry Whitlock" ] } } } }'
```
------
**Note**
Le filtrage d’événements DynamoDB ne prend pas en charge l’utilisation d’opérateurs numériques (égalité numérique et plage numérique). Même si les éléments de votre table sont stockés sous forme de nombres, ces paramètres sont convertis en chaînes dans l’objet d’enregistrement JSON.
## Utilisation de l’opérateur Exists
En raison de la structure des objets d’événements JSON de DynamoDB, l’utilisation de l’opérateur Exists nécessite une attention particulière. L’opérateur Exists ne fonctionne que sur les nœuds terminaux dans l’événement JSON. Par conséquent, si votre modèle de filtre utilise Exists pour tester un nœud intermédiaire, il ne fonctionnera pas. Observez l’élément de table DynamoDB suivant :
```
{
"UserID": {"S": "12345"},
"Name": {"S": "John Doe"},
"Organizations": {"L": [
{"S":"Sales"},
{"S":"Marketing"},
{"S":"Support"}
]
}
}
```
Vous pourriez avoir besoin de créer un modèle de filtre comme le suivant pour tester les événements contenant `"Organizations"` :
```
{ "dynamodb" : { "NewImage" : { "Organizations" : [ { "exists": true } ] } } }
```
Cependant, ce modèle de filtre ne renverra jamais de correspondance, car `"Organizations"` n’est pas un nœud terminal. L’exemple suivant montre comment utiliser correctement l’opérateur Exists pour construire le modèle de filtre souhaité :
```
{ "dynamodb" : { "NewImage" : {"Organizations": {"L": {"S": [ {"exists": true } ] } } } } }
```
## Format JSON pour le filtrage DynamoDB
Pour filtrer correctement les événements provenant de sources DynamoDB, le champ de données et vos critères de filtre pour le champ de données (`dynamodb`) doivent être au format JSON valide. Si l’un ou l’autre des champs n’est pas dans un format JSON valide, Lambda rejette le message ou lance une exception. Le tableau suivant résume le comportement spécifique :
| Format des données entrantes | Pas de modèle de filtre pour les propriétés des données | Action obtenue. |
| --- | --- | --- |
| JSON valide | JSON valide | Lambda filtre en fonction de vos critères de filtre. |
| JSON valide | Pas de modèle de filtre pour les propriétés des données | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
| JSON valide | Non JSON | Lambda lance une exception au moment de la création ou de la mise à jour du mappage de sources d’événements. Le modèle de filtre des propriétés de données doit être au format JSON valide. |
| Non JSON | JSON valide | Lambda rejette l’enregistrement. |
| Non JSON | Pas de modèle de filtre pour les propriétés des données | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
| Non JSON | Non JSON | Lambda lance une exception au moment de la création ou de la mise à jour du mappage de sources d’événements. Le modèle de filtre des propriétés de données doit être au format JSON valide. |
# Tutoriel : Utilisation AWS Lambda avec les flux Amazon DynamoDB
Dans ce didacticiel, vous allez créer une fonction Lambda afin d’utiliser des événements d’un flux Amazon DynamoDB.
## Conditions préalables
### Installez le AWS Command Line Interface
Si vous ne l'avez pas encore installé AWS Command Line Interface, suivez les étapes décrites dans la [section Installation ou mise à jour de la dernière version du AWS CLI pour l'](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)installer.
Ce tutoriel nécessite un terminal de ligne de commande ou un shell pour exécuter les commandes. Sous Linux et macOS, utilisez votre gestionnaire de shell et de package préféré.
**Note**
Sous Windows, certaines commandes CLI Bash que vous utilisez couramment avec Lambda (par exemple `zip`) ne sont pas prises en charge par les terminaux intégrés du système d’exploitation. [Installez le sous-système Windows pour Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10) afin d’obtenir une version intégrée à Windows d’Ubuntu et Bash.
## Créer le rôle d’exécution
Créez le [rôle d'exécution](lambda-intro-execution-role.md) qui autorise votre fonction à accéder aux AWS ressources.
**Pour créer un rôle d’exécution**
1. Ouvrez la page [Roles (Rôles)](https://console.aws.amazon.com/iam/home#/roles) dans la console IAM.
1. Sélectionnez **Créer un rôle**.
1. Créez un rôle avec les propriétés suivantes :
+ **Entité de confiance** – Lambda.
+ **Autorisations** — **DBExecutionRôle AWSLambda Dynamo**.
+ **Nom de rôle** – **lambda-dynamodb-role**.
Le **DBExecutionrôle AWSLambda Dynamo** dispose des autorisations dont la fonction a besoin pour lire des éléments depuis DynamoDB et écrire des journaux dans des journaux. CloudWatch
## Créer la fonction
Créez une fonction Lambda qui traite vos événements DynamoDB. Le code de fonction écrit certaines des données d'événements entrants dans CloudWatch Logs.
------
#### [ .NET ]
**SDK pour .NET**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda).
Consommation d’un événement DynamoDB avec Lambda en utilisant .NET.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using System.Text.Json;
using System.Text;
using Amazon.Lambda.Core;
using Amazon.Lambda.DynamoDBEvents;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace AWSLambda_DDB;
public class Function
{
public void FunctionHandler(DynamoDBEvent dynamoEvent, ILambdaContext context)
{
context.Logger.LogInformation($"Beginning to process {dynamoEvent.Records.Count} records...");
foreach (var record in dynamoEvent.Records)
{
context.Logger.LogInformation($"Event ID: {record.EventID}");
context.Logger.LogInformation($"Event Name: {record.EventName}");
context.Logger.LogInformation(JsonSerializer.Serialize(record));
}
context.Logger.LogInformation("Stream processing complete.");
}
}
```
------
#### [ Go ]
**Kit SDK pour Go V2**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda).
Consommation d’un événement DynamoDB avec Lambda en utilisant Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package main
import (
"context"
"github.com/aws/aws-lambda-go/lambda"
"github.com/aws/aws-lambda-go/events"
"fmt"
)
func HandleRequest(ctx context.Context, event events.DynamoDBEvent) (*string, error) {
if len(event.Records) == 0 {
return nil, fmt.Errorf("received empty event")
}
for _, record := range event.Records {
LogDynamoDBRecord(record)
}
message := fmt.Sprintf("Records processed: %d", len(event.Records))
return &message, nil
}
func main() {
lambda.Start(HandleRequest)
}
func LogDynamoDBRecord(record events.DynamoDBEventRecord){
fmt.Println(record.EventID)
fmt.Println(record.EventName)
fmt.Printf("%+v\n", record.Change)
}
```
------
#### [ Java ]
**SDK pour Java 2.x**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda).
Consommation d’un événement DynamoDB avec Lambda en utilisant Java.
```
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.DynamodbEvent;
import com.amazonaws.services.lambda.runtime.events.DynamodbEvent.DynamodbStreamRecord;
import com.google.gson.Gson;
import com.google.gson.GsonBuilder;
public class example implements RequestHandler {
private static final Gson GSON = new GsonBuilder().setPrettyPrinting().create();
@Override
public Void handleRequest(DynamodbEvent event, Context context) {
System.out.println(GSON.toJson(event));
event.getRecords().forEach(this::logDynamoDBRecord);
return null;
}
private void logDynamoDBRecord(DynamodbStreamRecord record) {
System.out.println(record.getEventID());
System.out.println(record.getEventName());
System.out.println("DynamoDB Record: " + GSON.toJson(record.getDynamodb()));
}
}
```
------
#### [ JavaScript ]
**SDK pour JavaScript (v3)**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda).
Consommation d'un événement DynamoDB avec Lambda en utilisant. JavaScript
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
exports.handler = async (event, context) => {
console.log(JSON.stringify(event, null, 2));
event.Records.forEach(record => {
logDynamoDBRecord(record);
});
};
const logDynamoDBRecord = (record) => {
console.log(record.eventID);
console.log(record.eventName);
console.log(`DynamoDB Record: ${JSON.stringify(record.dynamodb)}`);
};
```
Consommation d'un événement DynamoDB avec Lambda en utilisant. TypeScript
```
export const handler = async (event, context) => {
console.log(JSON.stringify(event, null, 2));
event.Records.forEach(record => {
logDynamoDBRecord(record);
});
}
const logDynamoDBRecord = (record) => {
console.log(record.eventID);
console.log(record.eventName);
console.log(`DynamoDB Record: ${JSON.stringify(record.dynamodb)}`);
};
```
------
#### [ PHP ]
**Kit SDK pour PHP**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda).
Consommation d’un événement DynamoDB avec Lambda en utilisant PHP.
```
logger = $logger;
}
/**
* @throws JsonException
* @throws \Bref\Event\InvalidLambdaEvent
*/
public function handleDynamoDb(DynamoDbEvent $event, Context $context): void
{
$this->logger->info("Processing DynamoDb table items");
$records = $event->getRecords();
foreach ($records as $record) {
$eventName = $record->getEventName();
$keys = $record->getKeys();
$old = $record->getOldImage();
$new = $record->getNewImage();
$this->logger->info("Event Name:".$eventName."\n");
$this->logger->info("Keys:". json_encode($keys)."\n");
$this->logger->info("Old Image:". json_encode($old)."\n");
$this->logger->info("New Image:". json_encode($new));
// TODO: Do interesting work based on the new data
// Any exception thrown will be logged and the invocation will be marked as failed
}
$totalRecords = count($records);
$this->logger->info("Successfully processed $totalRecords items");
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**Kit SDK for Python (Boto3)**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda).
Consommation d’un événement DynamoDB avec Lambda en utilisant Python.
```
import json
def lambda_handler(event, context):
print(json.dumps(event, indent=2))
for record in event['Records']:
log_dynamodb_record(record)
def log_dynamodb_record(record):
print(record['eventID'])
print(record['eventName'])
print(f"DynamoDB Record: {json.dumps(record['dynamodb'])}")
```
------
#### [ Ruby ]
**Kit SDK pour Ruby**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda).
Consommation d’un événement DynamoDB avec Lambda en utilisant Ruby.
```
def lambda_handler(event:, context:)
return 'received empty event' if event['Records'].empty?
event['Records'].each do |record|
log_dynamodb_record(record)
end
"Records processed: #{event['Records'].length}"
end
def log_dynamodb_record(record)
puts record['eventID']
puts record['eventName']
puts "DynamoDB Record: #{JSON.generate(record['dynamodb'])}"
end
```
------
#### [ Rust ]
**SDK pour Rust**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-ddb-to-lambda).
Consommation d’un événement DynamoDB avec Lambda en utilisant Rust.
```
use lambda_runtime::{service_fn, tracing, Error, LambdaEvent};
use aws_lambda_events::{
event::dynamodb::{Event, EventRecord},
};
// Built with the following dependencies:
//lambda_runtime = "0.11.1"
//serde_json = "1.0"
//tokio = { version = "1", features = ["macros"] }
//tracing = { version = "0.1", features = ["log"] }
//tracing-subscriber = { version = "0.3", default-features = false, features = ["fmt"] }
//aws_lambda_events = "0.15.0"
async fn function_handler(event: LambdaEvent) ->Result<(), Error> {
let records = &event.payload.records;
tracing::info!("event payload: {:?}",records);
if records.is_empty() {
tracing::info!("No records found. Exiting.");
return Ok(());
}
for record in records{
log_dynamo_dbrecord(record);
}
tracing::info!("Dynamo db records processed");
// Prepare the response
Ok(())
}
fn log_dynamo_dbrecord(record: &EventRecord)-> Result<(), Error>{
tracing::info!("EventId: {}", record.event_id);
tracing::info!("EventName: {}", record.event_name);
tracing::info!("DynamoDB Record: {:?}", record.change );
Ok(())
}
#[tokio::main]
async fn main() -> Result<(), Error> {
tracing_subscriber::fmt()
.with_max_level(tracing::Level::INFO)
.with_target(false)
.without_time()
.init();
let func = service_fn(function_handler);
lambda_runtime::run(func).await?;
Ok(())
}
```
------
**Pour créer la fonction**
1. Copiez l’exemple de code dans un fichier nommé `example.js`.
1. Créez un package de déploiement.
```
zip function.zip example.js
```
1. Créez une fonction Lambda à l’aide de la commande `create-function`.
```
aws lambda create-function --function-name ProcessDynamoDBRecords \
--zip-file fileb://function.zip --handler example.handler --runtime nodejs24.x \
--role arn:aws:iam::111122223333:role/lambda-dynamodb-role
```
## Test de la fonction Lambda
Au cours de cette étape, vous appelez votre fonction Lambda manuellement à l'aide de la commande `invoke` AWS Lambda CLI et de l'exemple d'événement DynamoDB suivant. Copiez le code suivant dans un fichier nommé `input.txt`.
**Example input.txt**
```
{
"Records":[
{
"eventID":"1",
"eventName":"INSERT",
"eventVersion":"1.0",
"eventSource":"aws:dynamodb",
"awsRegion":"us-east-1",
"dynamodb":{
"Keys":{
"Id":{
"N":"101"
}
},
"NewImage":{
"Message":{
"S":"New item!"
},
"Id":{
"N":"101"
}
},
"SequenceNumber":"111",
"SizeBytes":26,
"StreamViewType":"NEW_AND_OLD_IMAGES"
},
"eventSourceARN":"stream-ARN"
},
{
"eventID":"2",
"eventName":"MODIFY",
"eventVersion":"1.0",
"eventSource":"aws:dynamodb",
"awsRegion":"us-east-1",
"dynamodb":{
"Keys":{
"Id":{
"N":"101"
}
},
"NewImage":{
"Message":{
"S":"This item has changed"
},
"Id":{
"N":"101"
}
},
"OldImage":{
"Message":{
"S":"New item!"
},
"Id":{
"N":"101"
}
},
"SequenceNumber":"222",
"SizeBytes":59,
"StreamViewType":"NEW_AND_OLD_IMAGES"
},
"eventSourceARN":"stream-ARN"
},
{
"eventID":"3",
"eventName":"REMOVE",
"eventVersion":"1.0",
"eventSource":"aws:dynamodb",
"awsRegion":"us-east-1",
"dynamodb":{
"Keys":{
"Id":{
"N":"101"
}
},
"OldImage":{
"Message":{
"S":"This item has changed"
},
"Id":{
"N":"101"
}
},
"SequenceNumber":"333",
"SizeBytes":38,
"StreamViewType":"NEW_AND_OLD_IMAGES"
},
"eventSourceARN":"stream-ARN"
}
]
}
```
Exécutez la commande suivante `invoke`.
```
aws lambda invoke --function-name ProcessDynamoDBRecords \
--cli-binary-format raw-in-base64-out \
--payload file://input.txt outputfile.txt
```
L'**cli-binary-format**option est obligatoire si vous utilisez AWS CLI la version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez `aws configure set cli-binary-format raw-in-base64-out`. Pour plus d’informations, consultez les [options de ligne de commande globales prises en charge par l’AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) dans le *Guide de l’utilisateur AWS Command Line Interface version 2*.
La fonction renvoie la chaîne `message` dans le corps de la réponse.
Vérifiez la sortie dans le fichier `outputfile.txt`.
## Créer une table DynamoDB avec un flux activé
Créez une table Amazon DynamoDB avec un flux activé.
**Pour créer une table DynamoDB**
1. Ouvrez la [console DynamoDB](https://console.aws.amazon.com/dynamodb).
1. Choisissez **Créer un tableau**.
1. Créez une table avec les paramètres suivants.
+ **Nom de la table** – **lambda-dynamodb-stream**
+ **Clé primaire** – **id** (chaîne)
1. Choisissez **Create (Créer)**.
**Pour activer les flux**
1. Ouvrez la [console DynamoDB](https://console.aws.amazon.com/dynamodb).
1. Choisissez **Tables**.
1. Choisissez la table **lambda-dynamodb-stream**.
1. Sous la section **Exports and streams (Exportations et flux)**, choisissez **DynamoDB stream details (Détails du flux DynamoDB)**.
1. Choisissez **Activer**.
1. Pour **Type de vue**, sélectionnez **Attributs de clé uniquement**.
1. Choisissez **Activer le streaming**.
Écrivez l’ARN du flux. Vous en aurez besoin à l’étape suivante pour associer le flux à votre fonction Lambda. Pour plus d’informations sur l’activation des flux, consultez [Capture d’activité Table avec DynamoDB Streams](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html).
## Ajouter une source d'événement dans AWS Lambda
Créez un mappage de source d’événement dans AWS Lambda. Ce mappage de source d’événement associe le flux DynamoDB avec votre fonction Lambda. Après avoir créé ce mappage des sources d'événements, AWS Lambda commence à interroger le flux.
Exécutez la commande suivante AWS CLI `create-event-source-mapping`. Une fois la commande exécutée, notez l’UUID. Vous aurez besoin de l’UUID pour faire référence au mappage de source d’événement dans les commandes (par exemple, lors de la suppression du mappage).
```
aws lambda create-event-source-mapping --function-name ProcessDynamoDBRecords \
--batch-size 100 --starting-position LATEST --event-source DynamoDB-stream-arn
```
Cela a pour effet de créer un mappage entre le flux DynamoDB spécifié et la fonction Lambda. Vous pouvez associer un flux diffuser à plusieurs fonctions Lambda, et associer la même fonction Lambda à plusieurs flux. Toutefois, les fonctions Lambda partagent le débit de lecture du flux qu’elles partagent.
Pour obtenir la liste des mappages de source d’événement, exécutez la commande suivante.
```
aws lambda list-event-source-mappings
```
Cette liste renvoie tous les mappages de source d’événement que vous avez créés et indique la valeur `LastProcessingResult` pour chacun d’eux, entre autres. Ce champ est utilisé pour fournir un message d’information en cas de problème. Des valeurs telles que `No records processed` (indique que le sondage n' AWS Lambda a pas commencé ou qu'il n'y a aucun enregistrement dans le flux) et `OK` (indique que les enregistrements du flux AWS Lambda ont été lus avec succès et que votre fonction Lambda a été invoquée) indiquent qu'il n'y a aucun problème. Dans le cas contraire, vous recevez un message d’erreur.
Si vous avez un grand nombre de mappages de source d’événement, utilisez le paramètre du nom de la fonction pour affiner les résultats.
```
aws lambda list-event-source-mappings --function-name ProcessDynamoDBRecords
```
## Tester la configuration
Testez l' end-to-endexpérience. A mesure que vous mettez la table à jour, DynamoDB écrit les enregistrements d’événement dans le flux. Quand AWS Lambda interroge le flux, il y détecte les nouveaux enregistrements et invoque pour vous la fonction Lambda en transmettant les événements à la fonction.
1. Dans la console DynamoDB, vous pouvez ajouter, mettre à jour et supprimer des éléments dans la table. DynamoDB écrit des enregistrements de ces actions dans le flux.
1. AWS Lambda interroge le flux et lorsqu'il détecte des mises à jour du flux, il invoque votre fonction Lambda en transmettant les données d'événements qu'il trouve dans le flux.
1. Votre fonction s'exécute et crée des journaux sur Amazon CloudWatch. Vous pouvez vérifier les journaux signalés dans la CloudWatch console Amazon.
## Étapes suivantes
Ce didacticiel vous a montré les principes de base du traitement des événements de flux DynamoDB avec Lambda. Pour les charges de travail de production, envisagez de mettre en œuvre une logique de réponse partielle de lot afin de gérer plus efficacement les échecs d’enregistrement individuels. L'[utilitaire de traitement par lots](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/) de Powertools for AWS Lambda est disponible en Python TypeScript, .NET et Java et fournit une solution robuste pour cela, en gérant automatiquement la complexité des réponses partielles par lots et en réduisant le nombre de tentatives pour les enregistrements traités avec succès.
## Nettoyage de vos ressources
Vous pouvez maintenant supprimer les ressources que vous avez créées pour ce didacticiel, sauf si vous souhaitez les conserver. En supprimant AWS les ressources que vous n'utilisez plus, vous évitez des frais inutiles pour votre Compte AWS.
**Pour supprimer la fonction Lambda**
1. Ouvrez la [page Functions (Fonctions)](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda.
1. Sélectionnez la fonction que vous avez créée.
1. Sélectionnez **Actions**, **Supprimer**.
1. Saisissez **confirm** dans la zone de saisie de texte et choisissez **Delete** (Supprimer).
**Pour supprimer le rôle d’exécution**
1. Ouvrez la [page Roles (Rôles)](https://console.aws.amazon.com/iam/home#/roles) de la console IAM.
1. Sélectionnez le rôle d’exécution que vous avez créé.
1. Sélectionnez **Delete (Supprimer)**.
1. Saisissez le nom du rôle dans le champ de saisie de texte et choisissez **Delete** (Supprimer).
**Pour supprimer la table DynamoDB**
1. Ouvrez la [page Tables (Tables)](https://console.aws.amazon.com//dynamodb/home#tables:) de la console DynamoDB.
1. Sélectionnez la table que vous avez créée.
1. Choisissez **Supprimer**.
1. Saisissez **delete** dans la zone de texte.
1. Choisissez **Supprimer la table**.
# Traiter les événements du cycle de vie Amazon EC2 avec une fonction Lambda
Vous pouvez utiliser AWS Lambda pour traiter des événements de cycle de vie d’Amazon Elastic Compute Cloud et gérer des ressources Amazon EC2. Amazon EC2 envoie des événements à [Amazon EventBridge (CloudWatch Events)](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) pour des [événements de cycle de vie](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-lifecycle.html), par exemple, quand une instance change d’état, quand un instantané de volume Amazon Elastic Block Store est terminé ou quand une instance Spot est planifiée pour être arrêtée. Vous configurez EventBridge (CloudWatch Events) pour transférer ces événements à une fonction Lambda en vue de leur traitement.
EventBridge (CloudWatch Events) appelle la fonction Lambda de manière asynchrone avec le document d’événement d’Amazon EC2.
**Example événement du cycle de vie d’une instance**
```
{
"version": "0",
"id": "b6ba298a-7732-2226-xmpl-976312c1a050",
"detail-type": "EC2 Instance State-change Notification",
"source": "aws.ec2",
"account": "111122223333",
"time": "2019-10-02T17:59:30Z",
"region": "us-east-1",
"resources": [
"arn:aws:ec2:us-east-1:111122223333:instance/i-0c314xmplcd5b8173"
],
"detail": {
"instance-id": "i-0c314xmplcd5b8173",
"state": "running"
}
}
```
Pour plus d’informations sur la configuration des événements, consultez [Invocation d’une fonction Lambda dans une planification](with-eventbridge-scheduler.md). Pour obtenir un exemple de fonction qui traite les notifications d’instantanés Amazon EBS, consultez [EventBridge Scheduler for Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-cloud-watch-events.html).
Vous pouvez également utiliser le kit SDK AWS pour gérer les instances et d’autres ressources avec l’API Amazon EC2.
## Octroi d’autorisations à EventBridge (CloudWatch Events)
Pour traiter les événements de cycle de vie d’Amazon EC2, EventBridge (CloudWatch Events) doit être autorisé à appeler votre fonction. Cette autorisation provient de la [stratégie basée sur les ressources](access-control-resource-based.md)de la fonction. Si vous utilisez la console EventBridge (CloudWatch Events) pour configurer un déclencheur d’événement, la console met à jour la stratégie basée sur une ressource en votre nom. Sinon, ajoutez une instruction comme suit :
**Example Déclaration de stratégie basée sur une ressource pour les notifications de cycle de vie Amazon EC2**
```
{
"Sid": "ec2-events",
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-1:12456789012:function:my-function",
"Condition": {
"ArnLike": {
"AWS:SourceArn": "arn:aws:events:us-east-1:12456789012:rule/*"
}
}
}
```
Pour ajouter une instruction, utilisez la commande `add-permission` AWS CLI.
```
aws lambda add-permission --action lambda:InvokeFunction --statement-id ec2-events \
--principal events.amazonaws.com --function-name my-function --source-arn 'arn:aws:events:us-east-1:12456789012:rule/*'
```
Si votre fonction utilise le kit SDK AWS pour gérer les ressources Amazon EC2, ajoutez des autorisations Amazon EC2 au [rôle d’exécution](lambda-intro-execution-role.md) de la fonction.
# Traitet les demandes d’Application Load Balancer avec Lambda
Vous pouvez utiliser une fonction Lambda pour traiter les demandes d’un Application Load Balancer. Elastic Load Balancing prend désormais en charge les fonctions Lambda en tant que cibles pour un Application Load Balancer. Utilisez les règles de l’équilibreur de charge pour acheminer les demandes HTTP vers une fonction, selon le chemin d’accès ou les valeurs des en-têtes. Traitez la demande et renvoyez une réponse HTTP à partir de votre fonction Lambda.
Elastic Load Balancing appelle votre fonction Lambda de façon synchrone avec un événement qui contient le corps et les métadonnées de la demande.
**Example Evénement de demande d’Application Load Balancer**
```
{
"requestContext": {
"elb": {
"targetGroupArn": "arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/lambda-279XGJDqGZ5rsrHC2Fjr/49e9d65c45c6791a"
}
},
"httpMethod": "GET",
"path": "/lambda",
"queryStringParameters": {
"query": "1234ABCD"
},
"headers": {
"accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8",
"accept-encoding": "gzip",
"accept-language": "en-US,en;q=0.9",
"connection": "keep-alive",
"host": "lambda-alb-123578498.us-east-1.elb.amazonaws.com",
"upgrade-insecure-requests": "1",
"user-agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36",
"x-amzn-trace-id": "Root=1-5c536348-3d683b8b04734faae651f476",
"x-forwarded-for": "72.12.164.125",
"x-forwarded-port": "80",
"x-forwarded-proto": "http",
"x-imforwards": "20"
},
"body": "",
"isBase64Encoded": False
}
```
Votre fonction traite l’événement et renvoie un document de réponse à l’équilibreur de charge en JSON. Elastic Load Balancing convertit le document en réponse de succès ou d’erreur HTTP, et la renvoie à l’utilisateur.
**Example format du document de réponse**
```
{
"statusCode": 200,
"statusDescription": "200 OK",
"isBase64Encoded": False,
"headers": {
"Content-Type": "text/html"
},
"body": "Hello from Lambda!
"
}
```
Pour configurer un Application Load Balancer comme déclencheur de fonction, accordez à Elastic Load Balancing l’autorisation d’exécuter la fonction, créez un groupe cible qui achemine les demandes vers la fonction, et ajoutez à l’équilibreur de charge une règle qui envoie les demandes au groupe cible.
Utilisez la commande `add-permission` pour ajouter une instruction d’autorisation à la stratégie basée sur les ressources de votre fonction.
```
aws lambda add-permission --function-name alb-function \
--statement-id load-balancer --action "lambda:InvokeFunction" \
--principal elasticloadbalancing.amazonaws.com
```
Vous devriez voir la sortie suivante:
```
{
"Statement": "{\"Sid\":\"load-balancer\",\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"elasticloadbalancing.amazonaws.com\"},\"Action\":\"lambda:InvokeFunction\",\"Resource\":\"arn:aws:lambda:us-west-2:123456789012:function:alb-function\"}"
}
```
Pour obtenir des instructions sur la configuration de l’écouteur de l’équilibreur de charge d’application et du groupe cible, consultez [Fonctions Lambda en tant que cibles](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html) dans le *Guide de l’utilisateur des Application Load Balancers*.
## Gestionnaire d'événements de Powertools pour Lambda AWS
Le gestionnaire d'événements du kit d'outils Powertools for AWS Lambda fournit le routage, le middleware, la configuration CORS, la génération de spécifications OpenAPI, la validation des demandes, la gestion des erreurs et d'autres fonctionnalités utiles lors de l'écriture de fonctions Lambda invoquées par un Application Load Balancer. L’utilitaire de gestionnaire d’événements est disponible pour Python. Pour plus d'informations, consultez [l'API REST du gestionnaire d'événements](https://docs.powertools.aws.dev/lambda/python/latest/core/event_handler/api_gateway/) dans la documentation de *Powertools for AWS Lambda (Python)*.
### Python
```
import requests
from requests import Response
from aws_lambda_powertools import Logger, Tracer
from aws_lambda_powertools.event_handler import ALBResolver
from aws_lambda_powertools.logging import correlation_paths
from aws_lambda_powertools.utilities.typing import LambdaContext
tracer = Tracer()
logger = Logger()
app = ALBResolver()
@app.get("/todos")
@tracer.capture_method
def get_todos():
todos: Response = requests.get("https://jsonplaceholder.typicode.com/todos")
todos.raise_for_status()
# for brevity, we'll limit to the first 10 only
return {"todos": todos.json()[:10]}
# You can continue to use other utilities just as before
@logger.inject_lambda_context(correlation_id_path=correlation_paths.APPLICATION_LOAD_BALANCER)
@tracer.capture_lambda_handler
def lambda_handler(event: dict, context: LambdaContext) -> dict:
return app.resolve(event, context)
```
# Invocation d’une fonction Lambda dans une planification
Le [planificateur Amazon EventBridge](https://docs.aws.amazon.com/scheduler/latest/UserGuide/what-is-scheduler.html) est un planificateur sans serveur qui vous permet de créer, d’exécuter et de gérer des tâches à partir d’un service central et géré. Avec le planificateur EventBridge, vous pouvez créer des planifications à l’aide d’expressions cron et rate pour les modèles récurrents, voire configurer des invocations ponctuelles. Vous pouvez configurer des fenêtres temporelles flexibles pour la livraison, définir des limites de nouvelles tentatives, ainsi que la durée de rétention maximale pour les événements non traités.
Lorsque vous configurez le planificateur EventBridge avec Lambda, le planificateur EventBridge invoque votre fonction Lambda de manière asynchrone. Cette page explique comment utiliser le planificateur EventBridge pour invoquer une fonction Lambda dans une planification.
## Configurer le rôle d’exécution
Lorsque vous créez une planification, le planificateur EventBridge doit être autorisé à invoquer son opération d’API cible en votre nom. Vous accordez ces autorisations au planificateur EventBridge à l’aide d’un *rôle d’exécution*. La politique d’autorisation que vous associez au rôle d’exécution de votre planification définit les autorisations requises. Ces autorisations dépendent de l’API cible que vous souhaitez que le planificateur EventBridge invoque.
Lorsque vous utilisez la console du planificateur EventBridge pour créer une planification, comme dans la procédure suivante, le planificateur EventBridge définit automatiquement un rôle d’exécution en fonction de la cible que vous avez sélectionnée. Si vous souhaitez créer une planification à l’aide de l’un des kits SDK du planificateur EventBridge, de la AWS CLI ou de CloudFormation, vous devez disposer d’un rôle d’exécution existant qui accorde les autorisations dont le planificateur EventBridge a besoin pour invoquer une cible. Pour plus d’informations sur la configuration manuelle d’un rôle d’exécution pour votre planification, voir [Configuration d’un rôle d’exécution](https://docs.aws.amazon.com/scheduler/latest/UserGuide/setting-up.html#setting-up-execution-role) dans le *Guide de l’utilisateur du planificateur EventBridge*.
## Créer une planification
**Pour créer une planification à l’aide de la console**
1. Ouvrez la console du planificateur Amazon EventBridge à l’adresse [https://console.aws.amazon.com/scheduler/home](https://console.aws.amazon.com/scheduler/home/).
1. Sur la page **Planifications**, choisissez **Créer une planification**.
1. Sur la page **Spécifier le détail de la planification**, dans la section **Nom et description de la planification**, procédez comme suit :
1. Pour **Nom de la planification**, saisissez un nom à attribuer à votre planification. Par exemple, **MyTestSchedule**.
1. (Facultatif) Dans le champ **Description**, saisissez une description de la planification. Par exemple, **My first schedule**.
1. Pour **Groupe de planifications**, choisissez un groupe de planifications dans la liste déroulante. Si vous n’avez pas de groupe, choisissez par **défaut**. Pour créer un groupe de planifications, choisissez **Crée votre propre planification**.
Vous utilisez des groupes de planifications pour leur ajouter des balises.
1.
1. Choisissez vos options de planification.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/with-eventbridge-scheduler.html)
1. (Facultatif) Si vous avez choisi **Planification récurrente** à l’étape précédente, dans la section **Délai**, procédez comme suit :
1. Dans le champ **Fuseau horaire**, choisissez un fuseau horaire.
1. Pour **Date et heure de début**, entrez une date valide au format `YYYY/MM/DD`, puis spécifiez un horodatage au format `hh:mm` de 24 heures.
1. Pour **Date et heure de fin**, entrez une date valide au format `YYYY/MM/DD`, puis spécifiez un horodatage au format `hh:mm` de 24 heures.
1. Choisissez **Suivant**.
1. Sur la page **Sélectionner la cible**, choisissez l’opération d’API AWS invoquée par le planificateur EventBridge :
1. Sélectionnez **Invoquer AWS Lambda**.
1. Dans la section **Invoquer**, sélectionnez une fonction ou choisissez **Créer une fonction Lambda**.
1. (Facultatif) Entrez une charge utile JSON. Si vous n’entrez aucune charge utile, le planificateur EventBridge utilise un événement vide pour invoquer la fonction.
1. Choisissez **Suivant**.
1. Sur la page **Settings (Paramètres)**, procédez comme suit :
1. Pour activer la planification, sous **État de la planification**, activez **Activer la planification**.
1. Pour configurer une stratégie de nouvelles tentatives pour votre planification, sous **Politique de nouvelle tentative et file d’attente de lettres mortes (DLQ)**, procédez comme suit :
+ Activez **Réessayer**.
+ Pour **Âge maximum de l’événement**, entrez le nombre maximum d’**heures** et de **minutes** de conservation d’un événement non traité par le planificateur EventBridge.
+ La durée maximale est 24 heures.
+ Pour **Nombre maximum de tentatives**, entrez le nombre maximum de tentatives de renvoi d’une erreur par le planificateur EventBridge.
La valeur maximale est 185 nouvelles tentatives.
Avec les stratégies de nouvelles tentatives, si une planification ne parvient pas à invoquer sa cible, le planificateur EventBridge la réexécute. Si elle est configurée, vous devez définir la durée de rétention maximale et les nouvelles tentatives pour la planification.
1. Choisissez où le planificateur EventBridge stocke les événements non livrés.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/with-eventbridge-scheduler.html)
1. Pour utiliser une clé gérée par le client afin de chiffrer votre entrée cible, sous **Chiffrement**, choisissez **Personnaliser les paramètres de chiffrement (avancé)**.
Si vous choisissez cette option, entrez un ARN de clé KMS existant ou choisissez **Créez un AWS KMS key**pour accéder à la console AWS KMS. Pour plus d’informations sur la façon dont le planificateur EventBridge chiffre vos données au repos, voir [Chiffrement au repos](https://docs.aws.amazon.com/scheduler/latest/UserGuide/encryption-rest.html) dans le *Guide de l’utilisateur du planificateur Amazon EventBridge*.
1. Pour que le planificateur EventBridge crée un rôle d’exécution pour vous, choisissez **Créer un rôle pour cette planification**. Ensuite, saisissez un nom pour **Nom du rôle**. Si vous choisissez cette option, le planificateur EventBridge associe au rôle les autorisations requises pour votre cible modélisée.
1. Choisissez **Suivant**.
1. Sur la page **Examiner et créer une planification**, examinez les détails de votre planification. Dans chaque section, choisissez **Modifier** pour revenir à cette étape et modifier ses détails.
1. Choisissez **Créer une planification**.
Vous pouvez consulter la liste de vos planifications nouvelles et existantes sur la page **Planifications**. Sous la colonne **État**, vérifiez que votre nouvelle planification est **activée**.
Pour confirmer que le planificateur EventBridge a invoqué la fonction, [consultez les Amazon CloudWatch Logs de la fonction](monitoring-cloudwatchlogs-view.md#monitoring-cloudwatchlogs-console).
## Ressources connexes
Pour de plus amples informations sur le planificateur EventBridge, veuillez consulter les ressources suivantes :
+ [Guide de l’utilisateur du planificateur EventBridge](https://docs.aws.amazon.com/scheduler/latest/UserGuide/what-is-scheduler.html)
+ [Référence de l’API du planificateur EventBridge](https://docs.aws.amazon.com/scheduler/latest/APIReference/Welcome.html)
+ [Tarification du planificateur EventBridge](https://aws.amazon.com/eventbridge/pricing/#Scheduler)
# Utilisation de AWS Lambda avec AWS IoT
AWS IoT fournit une communication sécurisée entre les périphériques connectés à Internet (tels que les capteurs) et le Cloud AWS. Vous pouvez ainsi collecter les données de télémétrie de plusieurs périphériques, les stocker et les analyser.
Vous pouvez créer des règles AWS IoT permettant à vos appareils d’interagir avec les Services AWS. Le [moteur de règles](https://docs.aws.amazon.com/iot/latest/developerguide/iot-rules.html) AWS IoT fournit un langage SQL pour sélectionner des données dans des charges utiles de messages, et les envoyer à d’autres services tels que Amazon S3, Amazon DynamoDB et AWS Lambda. Vous définissez une règle pour appeler une fonction Lambda lorsque vous souhaitez appeler un autre service AWS ou un service tiers.
Quand un message IoT entrant déclenche la règle, AWS IoT appelle votre fonction Lambda [de manière asynchrone](invocation-async.md), et lui transmet les données du message IoT à la fonction.
L’exemple suivant montre une mesure de l’humidité à partir d’un capteur de serre. Les valeurs **row** et **pos** identifient l’emplacement du capteur. Cet exemple d’événement est basé sur le type de serre indiqué dans les [didacticiels sur les règles AWS IoT](https://docs.aws.amazon.com/iot/latest/developerguide/iot-rules-tutorial.html).
**Example AWS IoTÉvénement de message**
```
{
"row" : "10",
"pos" : "23",
"moisture" : "75"
}
```
Pour l’appel asynchrone, Lambda met le message en file d’attente et fait une [nouvelle tentative](invocation-retries.md) si votre fonction renvoie une erreur. Configurez votre fonction avec une [destination](invocation-async-retain-records.md#invocation-async-destinations) pour conserver les événements que votre fonction n’a pas pu traiter.
Vous devez accorder au service AWS IoT l’autorisation d’appeler votre fonction Lambda. Utilisez la commande `add-permission` pour ajouter une instruction d’autorisation à la stratégie basée sur les ressources de votre fonction.
```
aws lambda add-permission --function-name my-function \
--statement-id iot-events --action "lambda:InvokeFunction" --principal iot.amazonaws.com
```
Vous devriez voir la sortie suivante:
```
{
"Statement": "{\"Sid\":\"iot-events\",\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"iot.amazonaws.com\"},\"Action\":\"lambda:InvokeFunction\",\"Resource\":\"arn:aws:lambda:us-east-1:123456789012:function:my-function\"}"
}
```
Pour plus d’informations sur l’utilisation de Lambda avec AWS IoT, consultez [Création d’une règle AWS Lambda](https://docs.aws.amazon.com/iot/latest/developerguide/iot-lambda-rule.html).
# Utilisation de Lambda pour traiter les enregistrements à partir d’Amazon Kinesis Data Streams
Vous pouvez utiliser une fonction Lambda pour traiter des enregistrements dans un [flux de données Amazon Kinesis](https://docs.aws.amazon.com/streams/latest/dev/introduction.html). Vous pouvez mapper une fonction Lambda à un consommateur à débit partagé (itérateur standard) Kinesis Data Streams ou à un consommateur à débit dédié avec [diffusion améliorée](https://docs.aws.amazon.com/kinesis/latest/dev/enhanced-consumers.html). Pour les itérateurs standard, Lambda interroge chaque partition de votre flux Kinesis pour des enregistrements qui utilisent le protocole HTTP. Le mappage de source d’événement partage le débit de lecture avec d’autres utilisateurs de la partition.
Pour plus d’informations sur les flux de données Kinesis, consultez [Lecture de données à partir d’Amazon Kinesis Data Streams](https://docs.aws.amazon.com/kinesis/latest/dev/building-consumers.html).
**Note**
Kinesis facture chaque partition et, pour les diffusions améliorées, les données lues à partir du flux. Pour obtenir des informations de tarification, consultez [Tarification Amazon Kinesis](https://aws.amazon.com/kinesis/data-streams/pricing).
## Flux d’interrogation et de mise en lots
Lambda lit les enregistrements du flux de données et invoque votre fonction [de manière synchrone](invocation-sync.md) avec un événement contenant des enregistrements de flux. Lambda lit les registres par lots et invoque votre fonction pour les traiter. Chaque lot contient des enregistrements provenant d’un seul flux de données/partition.
Votre fonction Lambda est une application consommateur pour votre flux de données. Elle traite un lot d’enregistrements à la fois à partir de chaque partition. Vous pouvez mapper une fonction Lambda à un consommateur à débit partagé (itérateur standard) ou à un consommateur à débit dédié avec diffusion améliorée.
+ **Itérateur standard :** Lambda interroge chaque partition de votre flux Kinesis afin d’obtenir des enregistrements à une fréquence de base d’une fois par seconde. Lorsque d’autres enregistrements sont disponibles, Lambda continue de traiter les lots jusqu’à ce que la fonction rattrape le flux. Le mappage de source d’événement partage le débit de lecture avec d’autres utilisateurs de la partition.
+ **Diffusion améliorée** : pour réduire la latence et optimiser le débit en lecture, créez un consommateur de flux de données avec [diffusion améliorée](https://docs.aws.amazon.com/streams/latest/dev/enhanced-consumers.html). Les consommateurs avec diffusion améliorée obtiennent une connexion dédiée pour chaque partition qui n’a pas d’impact sur les autres applications lisant sur le flux. Les consommateurs de flux utilisent HTTP/2 afin de réduire la latence en transférant les enregistrements à Lambda via une connexion longue durée et en comprimant les en-têtes de requête. Vous pouvez créer un consommateur de flux avec l’API [RegisterStreamConsumer](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_RegisterStreamConsumer.html) de Kinesis.
```
aws kinesis register-stream-consumer \
--consumer-name con1 \
--stream-arn arn:aws:kinesis:us-east-2:123456789012:stream/lambda-stream
```
Vous devriez voir la sortie suivante:
```
{
"Consumer": {
"ConsumerName": "con1",
"ConsumerARN": "arn:aws:kinesis:us-east-2:123456789012:stream/lambda-stream/consumer/con1:1540591608",
"ConsumerStatus": "CREATING",
"ConsumerCreationTimestamp": 1540591608.0
}
}
```
Pour augmenter la vitesse à laquelle votre fonction traite les enregistrements, [ajoutez des partitions à votre flux de données](https://repost.aws/knowledge-center/kinesis-data-streams-open-shards). Lambda traite les enregistrements de chaque partition dans l’ordre. Il arrête de traiter les enregistrements supplémentaires d’une partition si votre fonction renvoie une erreur. Plus de partitions signifient plus de lots traités en une seule fois, ce qui réduit l’impact des erreurs sur la simultanéité.
Si votre fonction ne peut pas augmenter sa capacité pour traiter le nombre total de lots simultanés, [demandez une augmentation de quota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) ou [réservez de la simultanéité](configuration-concurrency.md) pour votre fonction.
Par défaut, Lambda invoque votre fonction dès que des enregistrements sont disponibles. Si le lot que Lambda lit à partir de la source d’événements ne comprend qu’un seul enregistrement, Lambda envoie un seul registre à la fonction. Pour éviter d’invoquer la fonction avec un petit nombre de registres, vous pouvez indiquer à la source d’événement de les mettre en mémoire tampon pendant 5 minutes en configurant une *fenêtre de traitement par lots*. Avant d’invoquer la fonction, Lambda continue de lire les registres de la source d’événements jusqu’à ce qu’il ait rassemblé un lot complet, que la fenêtre de traitement par lot expire ou que le lot atteigne la limite de charge utile de 6 Mo. Pour de plus amples informations, consultez [Comportement de traitement par lots](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching).
**Avertissement**
Les mappages des sources d’événements Lambda traitent chaque événement au moins une fois, et le traitement des enregistrements peut être dupliqué. Pour éviter les problèmes potentiels liés à des événements dupliqués, nous vous recommandons vivement de rendre votre code de fonction idempotent. Pour en savoir plus, consultez [Comment puis-je rendre ma fonction Lambda idempotente ?](https://repost.aws/knowledge-center/lambda-function-idempotent) dans le Centre de connaissances AWS.
Lambda envoi le prochain lot pour traitement sans attendre que les [extensions](lambda-extensions.md) configurées soient terminées. En d’autres termes, vos extensions peuvent continuer à s’exécuter pendant que Lambda traite le prochain lot d’enregistrements. Cela peut causer des problèmes de limitation si vous enfreignez l’un des paramètres ou l’une des limites de [simultanéité](lambda-concurrency.md) de votre compte. Pour détecter s’il s’agit d’un problème éventuel, surveillez vos fonctions et vérifiez si vous observez des [métriques de simultanéité](monitoring-concurrency.md#general-concurrency-metrics) plus élevées que prévu pour votre mappage des sources d’événements. En raison de la brièveté des intervalles entre les invocations, Lambda peut brièvement signaler une utilisation simultanée supérieure au nombre de partitions. Cela peut être vrai même pour les fonctions Lambda sans extensions.
Configurez le paramètre [ParallelizationFactor](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-ParallelizationFactor) pour traiter une partition d’un flux de données Kinesis avec plusieurs invocations Lambda simultanément. Vous pouvez spécifier le nombre de lots simultanés que Lambda interroge à partir d’une partition via un facteur de parallélisation de 1 (par défaut) à 10. Par exemple, quand vous définissez `ParallelizationFactor` sur 2, vous pouvez avoir jusqu’à 200 invocations Lambda simultanés pour traiter 100 partitions de données Kinesis (bien que, dans la réalité, la métrique `ConcurrentExecutions` puisse indiquer une valeur différente). Cela permet d’augmenter le débit de traitement quand le volume de données est volatil et que la valeur du paramètre `IteratorAge` est élevée. Lorsque vous augmentez le nombre de lots simultanés par partition, Lambda assure toujours un traitement dans l’ordre au niveau clé de partition.
Vous pouvez également utiliser `ParallelizationFactor` avec l’agrégation Kinesis. Le comportement du mappage des sources d’événements varie selon que vous utilisez ou non une [diffusion améliorée](https://docs.aws.amazon.com/streams/latest/dev/enhanced-consumers.html) :
+ **Sans diffusion améliorée** : tous les événements d’un événement agrégé doivent avoir la même clé de partition. La clé de partition doit également correspondre à celle de l’événement agrégé. Si les événements contenus dans l’événement agrégé ont des clés de partition différentes, Lambda ne peut garantir le traitement dans l’ordre des événements par clé de partition.
+ **Avec une diffusion améliorée** : Lambda décode d’abord l’événement agrégé en événements individuels. L’événement agrégé peut avoir une clé de partition différente de celle des événements qu’il contient. Cependant, les événements qui ne correspondent pas à la clé de partition sont [supprimés et perdus](https://github.com/awslabs/kinesis-aggregation/blob/master/potential_data_loss.md). Lambda ne traite pas ces événements et ne les envoie pas vers une destination en cas de panne configurée.
## Exemple d’évènement
**Example**
```
{
"Records": [
{
"kinesis": {
"kinesisSchemaVersion": "1.0",
"partitionKey": "1",
"sequenceNumber": "49590338271490256608559692538361571095921575989136588898",
"data": "SGVsbG8sIHRoaXMgaXMgYSB0ZXN0Lg==",
"approximateArrivalTimestamp": 1545084650.987
},
"eventSource": "aws:kinesis",
"eventVersion": "1.0",
"eventID": "shardId-000000000006:49590338271490256608559692538361571095921575989136588898",
"eventName": "aws:kinesis:record",
"invokeIdentityArn": "arn:aws:iam::123456789012:role/lambda-role",
"awsRegion": "us-east-2",
"eventSourceARN": "arn:aws:kinesis:us-east-2:123456789012:stream/lambda-stream"
},
{
"kinesis": {
"kinesisSchemaVersion": "1.0",
"partitionKey": "1",
"sequenceNumber": "49590338271490256608559692540925702759324208523137515618",
"data": "VGhpcyBpcyBvbmx5IGEgdGVzdC4=",
"approximateArrivalTimestamp": 1545084711.166
},
"eventSource": "aws:kinesis",
"eventVersion": "1.0",
"eventID": "shardId-000000000006:49590338271490256608559692540925702759324208523137515618",
"eventName": "aws:kinesis:record",
"invokeIdentityArn": "arn:aws:iam::123456789012:role/lambda-role",
"awsRegion": "us-east-2",
"eventSourceARN": "arn:aws:kinesis:us-east-2:123456789012:stream/lambda-stream"
}
]
}
```
# Traitement des enregistrements Amazon Kinesis Data Streams avec Lambda
Pour traiter les enregistrements Amazon Kinesis Data Streams avec Lambda, créez un mappage des sources d’événements Lambda. Vous pouvez mapper une fonction Lambda à un flux de données itérateur standard ou à un consommateur de diffusion améliorée. Pour de plus amples informations, veuillez consulter [Flux d’interrogation et de mise en lots](with-kinesis.md#kinesis-polling-and-batching).
## Créer un mappage des sources d’événements Kinesis
Pour invoquer votre fonction Lambda avec des enregistrements provenant de votre flux de données, créez un [mappage des sources d’événements](invocation-eventsourcemapping.md). Vous pouvez créer plusieurs mappages de source d’événement pour traiter les mêmes données avec plusieurs fonctions Lambda, ou pour traiter des éléments en provenance de plusieurs flux de données avec une seule fonction. Lorsque vous traitez des éléments à partir de plusieurs flux, chaque lot ne contient que des enregistrements provenant d’une seule partition ou d’un seul flux.
Vous pouvez configurer des mappages de sources d’événements pour traiter les enregistrements d’un flux dans un autre Compte AWS. Pour en savoir plus, veuillez consulter la section [Création d’un mappage des sources d’événements entre comptes](#services-kinesis-eventsourcemapping-cross-account).
Avant de créer un mappage des sources d’événements, vous devez autoriser votre fonction Lambda à lire à partir d’un flux de données Kinesis. Lambda a besoin des autorisations suivantes pour gérer les ressources liées à votre flux de données Kinesis :
+ [kinésie : DescribeStream](https://docs.aws.amazon.com/lambda/latest/api/API_DescribeStream.html)
+ [kinésie : DescribeStreamSummary](https://docs.aws.amazon.com/lambda/latest/api/API_DescribeStreamSummary.html)
+ [kinésie : GetRecords](https://docs.aws.amazon.com/lambda/latest/api/API_GetRecords.html)
+ [kinésie : GetShardIterator](https://docs.aws.amazon.com/lambda/latest/api/API_GetShardIterator.html)
+ [kinésie : ListShards](https://docs.aws.amazon.com/lambda/latest/api/API_ListShards.html)
+ [kinésie : SubscribeToShard](https://docs.aws.amazon.com/lambda/latest/api/API_SubscribeToShard.html)
La politique AWS gérée [AWSLambdaKinesisExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaKinesisExecutionRole.html)inclut ces autorisations. Ajoutez cette politique gérée à votre fonction comme décrit dans la procédure suivante.
**Note**
Vous n’avez pas besoin de l’autorisation `kinesis:ListStreams` pour créer et gérer des mappages des sources d’événements pour Kinesis. Toutefois, si vous créez un mappage des sources d’événements dans la console et que vous ne disposez pas de cette autorisation, vous ne pourrez pas sélectionner un flux Kinesis dans une liste déroulante et la console affichera un message d’erreur. Pour créer le mappage des sources d’événements, vous devez saisir manuellement l’Amazon Resource Name (ARN) de votre flux.
Lambda effectue des appels d’API `kinesis:GetRecords` et `kinesis:GetShardIterator` lorsqu’il tente à nouveau des appels qui ont échoué.
------
#### [ AWS Management Console ]
**Pour ajouter des autorisations Kinesis à votre fonction**
1. Ouvrez la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda et choisissez votre fonction.
1. Sous l’onglet **Configuration**, sélectionnez **Autorisations**.
1. Dans le volet **Rôle d’exécution**, sous **Nom du rôle**, choisissez le lien vers le rôle d’exécution de votre fonction. Ce lien ouvre la page de ce rôle dans la console IAM.
1. Dans le volet **Politiques d’autorisations**, choisissez **Ajouter des autorisations**, puis sélectionnez **Attacher des politiques**.
1. Dans le champ de recherche, entrez **AWSLambdaKinesisExecutionRole**.
1. Cochez la case en regard de la politique, puis choisissez **Ajouter une autorisation**.
------
#### [ AWS CLI ]
**Pour ajouter des autorisations Kinesis à votre fonction**
+ Exécutez la commande de la CLI suivante pour ajouter la politique `AWSLambdaKinesisExecutionRole` au rôle d’exécution de votre fonction :
```
aws iam attach-role-policy \
--role-name MyFunctionRole \
--policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaKinesisExecutionRole
```
------
#### [ AWS SAM ]
**Pour ajouter des autorisations Kinesis à votre fonction**
+ Dans la définition de votre fonction, ajoutez la propriété `Policies` comme indiqué dans l’exemple ci-dessous :
```
Resources:
MyFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: ./my-function/
Handler: index.handler
Runtime: nodejs24.x
Policies:
- AWSLambdaKinesisExecutionRole
```
------
Après avoir configuré les autorisations requises, créez le mappage des sources d’événements.
------
#### [ AWS Management Console ]
**Pour créer le mappage des sources d’événements Kinesis**
1. Ouvrez la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda et choisissez votre fonction.
1. Dans le volet de **Présentation de la fonction**, choisissez **Ajouter un déclencheur**.
1. Sous **Configuration du déclencheur**, pour la source, sélectionnez **Kinesis**.
1. Sélectionnez le flux Kinesis pour lequel vous souhaitez créer le mappage des sources d’événements et, éventuellement, un consommateur de votre flux.
1. (Facultatif) Modifiez la **Taille de lot**, la **Position de départ** et la **Fenêtre de traitement par lot** de votre mappage des sources d’événements.
1. Choisissez **Ajouter**.
Lorsque vous créez le mappage de vos sources d'événements depuis la console, votre rôle IAM doit disposer des autorisations [kinesis : ListStreams](https://docs.aws.amazon.com/lambda/latest/api/API_ListStreams.html) et [kinesis](https://docs.aws.amazon.com/lambda/latest/api/API_ListStreamConsumers.html) :. ListStreamConsumers
------
#### [ AWS CLI ]
**Pour créer le mappage des sources d’événements Kinesis**
+ Exécutez la commande de la CLI suivante pour créer un mappage des sources d’événements Kinesis. Choisissez votre propre taille de lot et votre position de départ en fonction de votre cas d’utilisation.
```
aws lambda create-event-source-mapping \
--function-name MyFunction \
--event-source-arn arn:aws:kinesis:us-east-2:123456789012:stream/lambda-stream \
--starting-position LATEST \
--batch-size 100
```
Pour spécifier une fenêtre de traitement par lot, ajoutez l’option `--maximum-batching-window-in-seconds`. Pour plus d'informations sur l'utilisation de ce paramètre et d'autres paramètres, consultez [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html)la *référence des AWS CLI commandes*.
------
#### [ AWS SAM ]
**Pour créer le mappage des sources d’événements Kinesis**
+ Dans la définition de votre fonction, ajoutez la propriété `KinesisEvent` comme indiqué dans l’exemple ci-dessous :
```
Resources:
MyFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: ./my-function/
Handler: index.handler
Runtime: nodejs24.x
Policies:
- AWSLambdaKinesisExecutionRole
Events:
KinesisEvent:
Type: Kinesis
Properties:
Stream: !GetAtt MyKinesisStream.Arn
StartingPosition: LATEST
BatchSize: 100
MyKinesisStream:
Type: AWS::Kinesis::Stream
Properties:
ShardCount: 1
```
*Pour en savoir plus sur la création d'un mappage des sources d'événements pour Kinesis Data Streams AWS SAM in, consultez [Kinesis](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-property-function-kinesis.html) dans AWS Serverless Application Model le manuel du développeur.*
------
## Position de départ du sondage et du stream
Sachez que l’interrogation des flux lors des mises à jour et de la création du mappage des sources d’événements est finalement cohérente.
+ Lors de la création du mappage des sources d’événements, le démarrage de l’interrogation des événements depuis le flux peut prendre plusieurs minutes.
+ Lors des mises à jour du mappage des sources d’événements, l’arrêt et le redémarrage de l’interrogation des événements depuis le flux peuvent prendre plusieurs minutes.
Ce comportement signifie que si vous spécifiez `LATEST` comme position de départ du flux, le mappage des sources d’événements peut manquer des événements lors de la création ou des mises à jour. Pour vous assurer de ne manquer aucun événement, spécifiez la position de départ du flux comme `TRIM_HORIZON` ou `AT_TIMESTAMP`.
## Création d’un mappage des sources d’événements entre comptes
Amazon Kinesis Data Streams prend en charge les [politiques basées sur les ressources](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html). De ce fait, vous pouvez traiter les données ingérées dans un flux à l' Compte AWS aide d'une fonction Lambda dans un autre compte.
Pour créer un mappage de source d'événements pour votre fonction Lambda à l'aide d'un flux Kinesis dans un autre Compte AWS, vous devez configurer le flux à l'aide d'une politique basée sur les ressources afin d'autoriser votre fonction Lambda à lire des éléments. Pour savoir comment configurer votre stream afin d'autoriser l'accès entre comptes, consultez la section [Partage de l'accès avec des AWS Lambda fonctions multicomptes](https://docs.aws.amazon.com/streams/latest/dev/resource-based-policy-examples.html#Resource-based-policy-examples-lambda) dans le guide du développeur *Amazon Kinesis* Streams.
Une fois que vous avez configuré votre flux avec une politique basée sur les ressources qui donne à votre fonction Lambda les autorisations requises, créez le mappage des sources d’événements à l’aide de l’une des méthodes décrites dans la section précédente.
Si vous choisissez de créer votre mappage des sources d’événements à l’aide de la console Lambda, collez l’ARN de votre flux directement dans la zone de saisie. Si vous souhaitez spécifier un consommateur pour votre flux, le champ du flux est automatiquement rempli lorsque l’ARN du consommateur est collé.
# Configuration d’une réponse par lots partielle avec Kinesis Data Streams et Lambda
Lors de l’utilisation et du traitement de données de streaming à partir d’une source d’événement, par défaut, Lambda n’effectue un point de contrôle sur le numéro de séquence le plus élevé d’un lot que lorsque celui-ci est un succès complet. Lambda traite tous les autres résultats comme un échec complet et recommence à traiter le lot jusqu’à atteindre la limite de nouvelles tentatives. Pour autoriser des succès partiels lors du traitement des lots à partir d’un flux, activez `ReportBatchItemFailures`. Autoriser des succès partiels peut permettre de réduire le nombre de nouvelles tentatives sur un enregistrement, mais cela n’empêche pas entièrement la possibilité de nouvelles tentatives dans un enregistrement réussi.
Pour activer `ReportBatchItemFailures`, incluez la valeur enum **ReportBatchItemFailures** dans la liste[FunctionResponseTypes](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-FunctionResponseTypes). Cette liste indique quels types de réponse sont activés pour votre fonction. Vous pouvez configurer cette liste lorsque vous [créez](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) ou [mettez à jour](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html) un mappage des sources d’événements.
**Note**
Même lorsque le code de votre fonction renvoie des réponses d’échec partiel de lot, ces réponses ne seront pas traitées par Lambda à moins que la fonctionnalité `ReportBatchItemFailures` soit explicitement activée pour votre mappage des sources d'événements.
## Syntaxe du rapport
Lors de la configuration des rapports d’échec d’articles de lot, la classe `StreamsEventResponse` est renvoyée avec une liste d’échecs d’articles de lot. Vous pouvez utiliser un objet `StreamsEventResponse` pour renvoyer le numéro de séquence du premier enregistrement ayant échoué dans le lot. Vous pouvez également créer votre classe personnalisée en utilisant la syntaxe de réponse correcte. La structure JSON suivante montre la syntaxe de réponse requise :
```
{
"batchItemFailures": [
{
"itemIdentifier": ""
}
]
}
```
**Note**
Si le tableau `batchItemFailures` contient plusieurs éléments, Lambda utilise l’enregistrement portant le numéro de séquence le plus bas comme point de contrôle. Lambda réessaie ensuite tous les enregistrements à partir de ce point de contrôle.
## Conditions de réussite et d’échec
Lambda traite un lot comme un succès complet si vous renvoyez l’un des éléments suivants :
+ Une liste `batchItemFailure` vide
+ Une liste `batchItemFailure` nulle
+ Une `EventResponse` vide
+ Un nu `EventResponse`
Lambda traite un lot comme un échec complet si vous renvoyez l’un des éléments suivants :
+ Une chaîne vid `itemIdentifier`
+ Un `itemIdentifier` nul
+ Un `itemIdentifier` avec un nom de clé incorrect
Lambda effectue des nouvelles tentatives en cas d’échec en fonction de votre stratégie de nouvelle tentative.
## Diviser un lot
Si votre invocation échoue et que `BisectBatchOnFunctionError` est activé, le lot est divisé en deux quel que soit votre paramètre `ReportBatchItemFailures`.
Quand une réponse de succès partiel de lot est reçue et que les paramètres `BisectBatchOnFunctionError` et `ReportBatchItemFailures` sont activés, le lot est divisé au numéro de séquence renvoyé, et Lambda n’effectue de nouvelle tentative que sur les enregistrements restants.
Pour simplifier la mise en œuvre de la logique de réponse partielle par lots, pensez à utiliser l'[utilitaire Batch Processor](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/) de Powertools for AWS Lambda, qui gère automatiquement ces complexités pour vous.
Voici quelques exemples de code de fonction qui renvoie la liste des messages ayant échoué IDs dans le lot :
------
#### [ .NET ]
**SDK pour .NET**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda-with-batch-item-handling).
Signalement des échecs d’articles par lots Kinesis avec Lambda à l’aide de .NET.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using System.Text;
using System.Text.Json.Serialization;
using Amazon.Lambda.Core;
using Amazon.Lambda.KinesisEvents;
using AWS.Lambda.Powertools.Logging;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace KinesisIntegration;
public class Function
{
// Powertools Logger requires an environment variables against your function
// POWERTOOLS_SERVICE_NAME
[Logging(LogEvent = true)]
public async Task FunctionHandler(KinesisEvent evnt, ILambdaContext context)
{
if (evnt.Records.Count == 0)
{
Logger.LogInformation("Empty Kinesis Event received");
return new StreamsEventResponse();
}
foreach (var record in evnt.Records)
{
try
{
Logger.LogInformation($"Processed Event with EventId: {record.EventId}");
string data = await GetRecordDataAsync(record.Kinesis, context);
Logger.LogInformation($"Data: {data}");
// TODO: Do interesting work based on the new data
}
catch (Exception ex)
{
Logger.LogError($"An error occurred {ex.Message}");
/* Since we are working with streams, we can return the failed item immediately.
Lambda will immediately begin to retry processing from this failed item onwards. */
return new StreamsEventResponse
{
BatchItemFailures = new List
{
new StreamsEventResponse.BatchItemFailure { ItemIdentifier = record.Kinesis.SequenceNumber }
}
};
}
}
Logger.LogInformation($"Successfully processed {evnt.Records.Count} records.");
return new StreamsEventResponse();
}
private async Task GetRecordDataAsync(KinesisEvent.Record record, ILambdaContext context)
{
byte[] bytes = record.Data.ToArray();
string data = Encoding.UTF8.GetString(bytes);
await Task.CompletedTask; //Placeholder for actual async work
return data;
}
}
public class StreamsEventResponse
{
[JsonPropertyName("batchItemFailures")]
public IList BatchItemFailures { get; set; }
public class BatchItemFailure
{
[JsonPropertyName("itemIdentifier")]
public string ItemIdentifier { get; set; }
}
}
```
------
#### [ Go ]
**Kit SDK pour Go V2**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda-with-batch-item-handling).
Signalement des échecs d’articles par lots Kinesis avec Lambda à l’aide de Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package main
import (
"context"
"fmt"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func handler(ctx context.Context, kinesisEvent events.KinesisEvent) (map[string]interface{}, error) {
batchItemFailures := []map[string]interface{}{}
for _, record := range kinesisEvent.Records {
curRecordSequenceNumber := ""
// Process your record
if /* Your record processing condition here */ {
curRecordSequenceNumber = record.Kinesis.SequenceNumber
}
// Add a condition to check if the record processing failed
if curRecordSequenceNumber != "" {
batchItemFailures = append(batchItemFailures, map[string]interface{}{"itemIdentifier": curRecordSequenceNumber})
}
}
kinesisBatchResponse := map[string]interface{}{
"batchItemFailures": batchItemFailures,
}
return kinesisBatchResponse, nil
}
func main() {
lambda.Start(handler)
}
```
------
#### [ Java ]
**SDK pour Java 2.x**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda-with-batch-item-handling).
Signalement des échecs d’articles par lots Kinesis avec Lambda à l’aide de Java.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.KinesisEvent;
import com.amazonaws.services.lambda.runtime.events.StreamsEventResponse;
import java.io.Serializable;
import java.util.ArrayList;
import java.util.List;
public class ProcessKinesisRecords implements RequestHandler {
@Override
public StreamsEventResponse handleRequest(KinesisEvent input, Context context) {
List batchItemFailures = new ArrayList<>();
String curRecordSequenceNumber = "";
for (KinesisEvent.KinesisEventRecord kinesisEventRecord : input.getRecords()) {
try {
//Process your record
KinesisEvent.Record kinesisRecord = kinesisEventRecord.getKinesis();
curRecordSequenceNumber = kinesisRecord.getSequenceNumber();
} catch (Exception e) {
/* Since we are working with streams, we can return the failed item immediately.
Lambda will immediately begin to retry processing from this failed item onwards. */
batchItemFailures.add(new StreamsEventResponse.BatchItemFailure(curRecordSequenceNumber));
return new StreamsEventResponse(batchItemFailures);
}
}
return new StreamsEventResponse(batchItemFailures);
}
}
```
------
#### [ JavaScript ]
**SDK pour JavaScript (v3)**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/blob/main/integration-kinesis-to-lambda-with-batch-item-handling).
Signalement des échecs d’articles par lots Kinesis avec Lambda à l’aide de JavaScript.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
exports.handler = async (event, context) => {
for (const record of event.Records) {
try {
console.log(`Processed Kinesis Event - EventID: ${record.eventID}`);
const recordData = await getRecordDataAsync(record.kinesis);
console.log(`Record Data: ${recordData}`);
// TODO: Do interesting work based on the new data
} catch (err) {
console.error(`An error occurred ${err}`);
/* Since we are working with streams, we can return the failed item immediately.
Lambda will immediately begin to retry processing from this failed item onwards. */
return {
batchItemFailures: [{ itemIdentifier: record.kinesis.sequenceNumber }],
};
}
}
console.log(`Successfully processed ${event.Records.length} records.`);
return { batchItemFailures: [] };
};
async function getRecordDataAsync(payload) {
var data = Buffer.from(payload.data, "base64").toString("utf-8");
await Promise.resolve(1); //Placeholder for actual async work
return data;
}
```
Signaler les défaillances d'éléments de lot Kinesis avec Lambda à l'aide de. TypeScript
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import {
KinesisStreamEvent,
Context,
KinesisStreamHandler,
KinesisStreamRecordPayload,
KinesisStreamBatchResponse,
} from "aws-lambda";
import { Buffer } from "buffer";
import { Logger } from "@aws-lambda-powertools/logger";
const logger = new Logger({
logLevel: "INFO",
serviceName: "kinesis-stream-handler-sample",
});
export const functionHandler: KinesisStreamHandler = async (
event: KinesisStreamEvent,
context: Context
): Promise => {
for (const record of event.Records) {
try {
logger.info(`Processed Kinesis Event - EventID: ${record.eventID}`);
const recordData = await getRecordDataAsync(record.kinesis);
logger.info(`Record Data: ${recordData}`);
// TODO: Do interesting work based on the new data
} catch (err) {
logger.error(`An error occurred ${err}`);
/* Since we are working with streams, we can return the failed item immediately.
Lambda will immediately begin to retry processing from this failed item onwards. */
return {
batchItemFailures: [{ itemIdentifier: record.kinesis.sequenceNumber }],
};
}
}
logger.info(`Successfully processed ${event.Records.length} records.`);
return { batchItemFailures: [] };
};
async function getRecordDataAsync(
payload: KinesisStreamRecordPayload
): Promise {
var data = Buffer.from(payload.data, "base64").toString("utf-8");
await Promise.resolve(1); //Placeholder for actual async work
return data;
}
```
------
#### [ PHP ]
**Kit SDK pour PHP**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda-with-batch-item-handling).
Signalement des échecs d’articles par lots Kinesis avec Lambda à l’aide de PHP.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
logger = $logger;
}
/**
* @throws JsonException
* @throws \Bref\Event\InvalidLambdaEvent
*/
public function handle(mixed $event, Context $context): array
{
$kinesisEvent = new KinesisEvent($event);
$this->logger->info("Processing records");
$records = $kinesisEvent->getRecords();
$failedRecords = [];
foreach ($records as $record) {
try {
$data = $record->getData();
$this->logger->info(json_encode($data));
// TODO: Do interesting work based on the new data
} catch (Exception $e) {
$this->logger->error($e->getMessage());
// failed processing the record
$failedRecords[] = $record->getSequenceNumber();
}
}
$totalRecords = count($records);
$this->logger->info("Successfully processed $totalRecords records");
// change format for the response
$failures = array_map(
fn(string $sequenceNumber) => ['itemIdentifier' => $sequenceNumber],
$failedRecords
);
return [
'batchItemFailures' => $failures
];
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**Kit SDK for Python (Boto3)**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda-with-batch-item-handling).
Signalement des échecs d’articles par lots Kinesis avec Lambda à l’aide de Python.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def handler(event, context):
records = event.get("Records")
curRecordSequenceNumber = ""
for record in records:
try:
# Process your record
curRecordSequenceNumber = record["kinesis"]["sequenceNumber"]
except Exception as e:
# Return failed record's sequence number
return {"batchItemFailures":[{"itemIdentifier": curRecordSequenceNumber}]}
return {"batchItemFailures":[]}
```
------
#### [ Ruby ]
**Kit SDK pour Ruby**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda-with-batch-item-handling).
Signalement des échecs d’articles par lots Kinesis avec Lambda à l’aide de Ruby.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
require 'aws-sdk'
def lambda_handler(event:, context:)
batch_item_failures = []
event['Records'].each do |record|
begin
puts "Processed Kinesis Event - EventID: #{record['eventID']}"
record_data = get_record_data_async(record['kinesis'])
puts "Record Data: #{record_data}"
# TODO: Do interesting work based on the new data
rescue StandardError => err
puts "An error occurred #{err}"
# Since we are working with streams, we can return the failed item immediately.
# Lambda will immediately begin to retry processing from this failed item onwards.
return { batchItemFailures: [{ itemIdentifier: record['kinesis']['sequenceNumber'] }] }
end
end
puts "Successfully processed #{event['Records'].length} records."
{ batchItemFailures: batch_item_failures }
end
def get_record_data_async(payload)
data = Base64.decode64(payload['data']).force_encoding('utf-8')
# Placeholder for actual async work
sleep(1)
data
end
```
------
#### [ Rust ]
**SDK pour Rust**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda-with-batch-item-handling).
Signalement des échecs d’articles par lots Kinesis avec Lambda à l’aide de Rust.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
use aws_lambda_events::{
event::kinesis::KinesisEvent,
kinesis::KinesisEventRecord,
streams::{KinesisBatchItemFailure, KinesisEventResponse},
};
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
async fn function_handler(event: LambdaEvent) -> Result {
let mut response = KinesisEventResponse {
batch_item_failures: vec![],
};
if event.payload.records.is_empty() {
tracing::info!("No records found. Exiting.");
return Ok(response);
}
for record in &event.payload.records {
tracing::info!(
"EventId: {}",
record.event_id.as_deref().unwrap_or_default()
);
let record_processing_result = process_record(record);
if record_processing_result.is_err() {
response.batch_item_failures.push(KinesisBatchItemFailure {
item_identifier: record.kinesis.sequence_number.clone(),
});
/* Since we are working with streams, we can return the failed item immediately.
Lambda will immediately begin to retry processing from this failed item onwards. */
return Ok(response);
}
}
tracing::info!(
"Successfully processed {} records",
event.payload.records.len()
);
Ok(response)
}
fn process_record(record: &KinesisEventRecord) -> Result<(), Error> {
let record_data = std::str::from_utf8(record.kinesis.data.as_slice());
if let Some(err) = record_data.err() {
tracing::error!("Error: {}", err);
return Err(Error::from(err));
}
let record_data = record_data.unwrap_or_default();
// do something interesting with the data
tracing::info!("Data: {}", record_data);
Ok(())
}
#[tokio::main]
async fn main() -> Result<(), Error> {
tracing_subscriber::fmt()
.with_max_level(tracing::Level::INFO)
// disable printing the name of the module in every log line.
.with_target(false)
// disabling time is handy because CloudWatch will add the ingestion time.
.without_time()
.init();
run(service_fn(function_handler)).await
}
```
------
## Utilisation de Powertools pour le AWS Lambda traitement par lots
L'utilitaire de traitement par lots de Powertools for gère AWS Lambda automatiquement la logique de réponse partielle par lots, réduisant ainsi la complexité de la mise en œuvre du signalement des défaillances par lots. Voici des exemples d’utilisation de l’utilitaire de traitement par lots :
**Python**
Pour des exemples complets et des instructions de configuration, consultez la [documentation de l’utilitaire de traitement par lots](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/).
Traitement des enregistrements de flux Kinesis Data Streams à l'aide d' AWS Lambda un processeur par lots.
```
import json
from aws_lambda_powertools import Logger
from aws_lambda_powertools.utilities.batch import BatchProcessor, EventType, process_partial_response
from aws_lambda_powertools.utilities.data_classes import KinesisEvent
from aws_lambda_powertools.utilities.typing import LambdaContext
processor = BatchProcessor(event_type=EventType.KinesisDataStreams)
logger = Logger()
def record_handler(record):
logger.info(record)
# Your business logic here
# Raise an exception to mark this record as failed
def lambda_handler(event, context: LambdaContext):
return process_partial_response(
event=event,
record_handler=record_handler,
processor=processor,
context=context
)
```
**TypeScript**
Pour des exemples complets et des instructions de configuration, consultez la [documentation de l’utilitaire de traitement par lots](https://docs.aws.amazon.com/powertools/typescript/latest/features/batch/).
Traitement des enregistrements de flux Kinesis Data Streams à l'aide d' AWS Lambda un processeur par lots.
```
import { BatchProcessor, EventType, processPartialResponse } from '@aws-lambda-powertools/batch';
import { Logger } from '@aws-lambda-powertools/logger';
import type { KinesisEvent, Context } from 'aws-lambda';
const processor = new BatchProcessor(EventType.KinesisDataStreams);
const logger = new Logger();
const recordHandler = async (record: any): Promise => {
logger.info('Processing record', { record });
// Your business logic here
// Throw an error to mark this record as failed
};
export const handler = async (event: KinesisEvent, context: Context) => {
return processPartialResponse(event, recordHandler, processor, {
context,
});
};
```
**Java**
Pour des exemples complets et des instructions de configuration, consultez la [documentation de l’utilitaire de traitement par lots](https://docs.powertools.aws.dev/lambda/java/latest/utilities/batch/).
Traitement des enregistrements de flux Kinesis Data Streams à l'aide d' AWS Lambda un processeur par lots.
```
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.KinesisEvent;
import com.amazonaws.services.lambda.runtime.events.StreamsEventResponse;
import software.amazon.lambda.powertools.batch.BatchMessageHandlerBuilder;
import software.amazon.lambda.powertools.batch.handler.BatchMessageHandler;
public class KinesisStreamBatchHandler implements RequestHandler {
private final BatchMessageHandler handler;
public KinesisStreamBatchHandler() {
handler = new BatchMessageHandlerBuilder()
.withKinesisBatchHandler()
.buildWithRawMessageHandler(this::processMessage);
}
@Override
public StreamsEventResponse handleRequest(KinesisEvent kinesisEvent, Context context) {
return handler.processBatch(kinesisEvent, context);
}
private void processMessage(KinesisEvent.KinesisEventRecord kinesisEventRecord, Context context) {
// Process the stream record
}
}
```
**.NET**
Pour des exemples complets et des instructions de configuration, consultez la [documentation de l’utilitaire de traitement par lots](https://docs.aws.amazon.com/powertools/dotnet/utilities/batch-processing/).
Traitement des enregistrements de flux Kinesis Data Streams à l'aide d' AWS Lambda un processeur par lots.
```
using System;
using System.Threading;
using System.Threading.Tasks;
using Amazon.Lambda.Core;
using Amazon.Lambda.KinesisEvents;
using Amazon.Lambda.Serialization.SystemTextJson;
using AWS.Lambda.Powertools.BatchProcessing;
[assembly: LambdaSerializer(typeof(DefaultLambdaJsonSerializer))]
namespace HelloWorld;
public class OrderEvent
{
public string? OrderId { get; set; }
public string? CustomerId { get; set; }
public decimal Amount { get; set; }
public DateTime OrderDate { get; set; }
}
internal class TypedKinesisRecordHandler : ITypedRecordHandler
{
public async Task HandleAsync(OrderEvent orderEvent, CancellationToken cancellationToken)
{
if (string.IsNullOrEmpty(orderEvent.OrderId))
{
throw new ArgumentException("Order ID is required");
}
return await Task.FromResult(RecordHandlerResult.None);
}
}
public class Function
{
[BatchProcessor(TypedRecordHandler = typeof(TypedKinesisRecordHandler))]
public BatchItemFailuresResponse HandlerUsingTypedAttribute(KinesisEvent _)
{
return TypedKinesisStreamBatchProcessor.Result.BatchItemFailuresResponse;
}
}
```
# Retenir les enregistrements de lots supprimés pour une source d’événements de flux de données Kinesis dans Lambda
La gestion des erreurs pour les mappages des sources d’événements Kinesis n’est pas la même selon si l’erreur se produit avant que la fonction ne soit invoquée ou pendant l’invocation de la fonction :
+ **Avant l'appel :** si un mappage de source d'événement Lambda ne parvient pas à appeler la fonction en raison d'un ralentissement ou d'autres problèmes, il réessaie jusqu'à ce que les enregistrements expirent ou dépassent l'âge maximum configuré sur le mappage de source d'événement (). [MaximumRecordAgeInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumRecordAgeInSeconds)
+ **Pendant l'appel :** si la fonction est invoquée mais renvoie une erreur, Lambda réessaie jusqu'à ce que les enregistrements expirent, dépassent l'âge maximum [MaximumRecordAgeInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumRecordAgeInSeconds)() ou atteignent le quota de nouvelles tentatives configuré (). [MaximumRetryAttempts](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumRetryAttempts) Pour les erreurs de fonctionnement, vous pouvez également configurer [BisectBatchOnFunctionError](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-response-BisectBatchOnFunctionError), ce qui divise un lot défaillant en deux lots plus petits, isolant ainsi les mauvais enregistrements et évitant les délais d'attente. Le fractionnement des lots ne consomme pas le quota de nouvelles tentatives.
Si les mesures de gestion des erreurs échouent, Lambda ignore les enregistrements et poursuit le traitement des lots du flux. Avec les paramètres par défaut, cela signifie qu’un enregistrement défectueux peut bloquer le traitement sur la partition affectée pendant jusqu’à une semaine. Pour éviter cela, configurez le mappage de source d’événement de votre fonction avec un nombre raisonnable de nouvelles tentatives et un âge maximum d’enregistrement correspondant à votre cas d’utilisation.
## Configuration des destinations pour les invocations ayant échoué
Pour retenir les enregistrements des invocations de mappage de sources d’événements qui ont échoué, ajoutez une destination au mappage des sources d’événements de votre fonction. Chaque enregistrement envoyé à la destination est un document JSON contenant les métadonnées sur l’invocation ayant échoué. Pour les destinations Amazon S3, Lambda envoie également l’intégralité de l’enregistrement d’invocation avec les métadonnées. Vous pouvez configurer n'importe quelle rubrique Amazon SNS, n'importe quelle file d'attente Amazon SQS, n'importe quel compartiment Amazon S3 ou Kafka comme destination.
Avec les destinations Amazon S3, vous pouvez utiliser la fonctionnalité [Notifications d’événements Amazon S3](https://docs.aws.amazon.com/) pour recevoir des notifications lorsque des objets sont chargés dans votre compartiment S3 de destination. Vous pouvez également configurer les notifications d’événements S3 pour invoquer une autre fonction Lambda afin d’effectuer un traitement automatique des lots ayant échoué.
Votre rôle d’exécution doit disposer d’autorisations pour la destination :
+ **Pour une destination SQS : [sqs](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) :** SendMessage
+ **[Pour une destination SNS : SNS:Publish](https://docs.aws.amazon.com/sns/latest/api/API_Publish.html)**
+ **Pour une destination S3 :** [s3 : PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html) et [s3 : ListBucket](https://docs.aws.amazon.com/AmazonS3/latest/API/ListObjectsV2.html)
+ **Pour une destination Kafka : [kafka-cluster](https://docs.aws.amazon.com/msk/latest/developerguide/kafka-actions.html) :** WriteData
Vous pouvez configurer un sujet Kafka comme destination en cas d'échec pour vos mappages de sources d'événements Kafka. Lorsque Lambda ne parvient pas à traiter les enregistrements après avoir épuisé toutes les tentatives ou lorsque les enregistrements dépassent l'âge maximum, Lambda envoie les enregistrements ayant échoué à la rubrique Kafka spécifiée pour un traitement ultérieur. Reportez-vous à [Utiliser un sujet Kafka comme destination en cas d'échec](kafka-on-failure-destination.md).
Si vous avez activé le chiffrement avec votre propre clé KMS pour une destination S3, le rôle d'exécution de votre fonction doit également être autorisé à appeler [kms : GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html). Si la clé KMS et la destination du compartiment S3 se trouvent dans un compte différent de celui de votre fonction Lambda et de votre rôle d'exécution, configurez la clé KMS pour qu'elle approuve le rôle d'exécution à autoriser. kms: GenerateDataKey
Pour configurer une destination en cas de panne à l’aide de la console, procédez comme suit :
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez une fonction.
1. Sous **Function overview (Vue d’ensemble de la fonction)**, choisissez **Add destination (Ajouter une destination)**.
1. Pour **Source**, choisissez **Invocation du mappage des sources d’événements**.
1. Pour le **mappage des sources d’événements**, choisissez une source d’événements configurée pour cette fonction.
1. Pour **Condition**, sélectionnez **En cas d’échec**. Pour les invocations de mappage des sources d’événements, il s’agit de la seule condition acceptée.
1. Pour **Type de destination**, choisissez le type de destination auquel Lambda envoie les enregistrements d’invocation.
1. Pour **Destination**, choisissez une ressource.
1. Choisissez **Enregistrer**.
Vous pouvez également configurer une destination en cas de panne à l'aide de AWS Command Line Interface (AWS CLI). Par exemple, la [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html)commande suivante ajoute un mappage de source d'événement avec une destination SQS en cas de défaillance pour : `MyFunction`
```
aws lambda create-event-source-mapping \
--function-name "MyFunction" \
--event-source-arn arn:aws:kinesis:us-east-2:123456789012:stream/lambda-stream \
--destination-config '{"OnFailure": {"Destination": "arn:aws:sqs:us-east-1:123456789012:dest-queue"}}'
```
La [update-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-event-source-mapping.html)commande suivante met à jour le mappage d'une source d'événements afin d'envoyer les enregistrements d'invocation ayant échoué vers une destination SNS après deux tentatives, ou si les enregistrements datent de plus d'une heure.
```
aws lambda update-event-source-mapping \
--uuid f89f8514-cdd9-4602-9e1f-01a5b77d449b \
--maximum-retry-attempts 2 \
--maximum-record-age-in-seconds 3600 \
--destination-config '{"OnFailure": {"Destination": "arn:aws:sns:us-east-1:123456789012:dest-topic"}}'
```
Les paramètres mis à jour sont appliqués de façon asynchrone et ne sont pas reflétés dans la sortie tant que le processus n’est pas terminé. Utilisez la commande [get-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/get-event-source-mapping.html) pour afficher l’état actuel.
Pour supprimer une destination, entrez une chaîne vide comme argument du paramètre `destination-config` :
```
aws lambda update-event-source-mapping \
--uuid f89f8514-cdd9-4602-9e1f-01a5b77d449b \
--destination-config '{"OnFailure": {"Destination": ""}}'
```
### Pratiques exemplaires en matière de sécurité pour les destinations Amazon S3
La suppression d’un compartiment S3 configuré comme destination sans supprimer la destination de la configuration de votre fonction peut engendrer un risque de sécurité. Si un autre utilisateur connaît le nom de votre compartiment de destination, il peut recréer le compartiment dans son Compte AWS. Les enregistrements des invocations ayant échoué seront envoyés dans son compartiment, exposant potentiellement les données de votre fonction.
**Avertissement**
Pour vous assurer que les enregistrements d'invocation de votre fonction ne peuvent pas être envoyés vers un compartiment S3 d'un autre Compte AWS, ajoutez une condition au rôle d'exécution de votre fonction qui limite `s3:PutObject` les autorisations aux compartiments de votre compte.
L’exemple suivant présente une politique IAM qui limite les autorisations `s3:PutObject` de votre fonction aux seuls compartiments de votre compte. Cette politique donne également à Lambda l’autorisation `s3:ListBucket` dont il a besoin pour utiliser un compartiment S3 comme destination.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "S3BucketResourceAccountWrite",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::*/*",
"arn:aws:s3:::*"
],
"Condition": {
"StringEquals": {
"s3:ResourceAccount": "111122223333"
}
}
}
]
}
```
Pour ajouter une politique d'autorisations au rôle d'exécution de votre fonction à l'aide du AWS Management Console ou AWS CLI, reportez-vous aux instructions des procédures suivantes :
------
#### [ Console ]
**Pour ajouter une politique d’autorisations au rôle d’exécution d’une fonction (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Sélectionnez la fonction Lambda dont vous voulez modifier le rôle d’exécution.
1. Sous l’onglet **Configuration**, sélectionnez **Autorisations**.
1. Sous l’onglet **Rôle d’exécution**, sélectionnez le **Nom du rôle** de votre fonction pour ouvrir la page de console IAM du rôle.
1. Ajoutez une politique d’autorisations de au rôle en procédant comme suit :
1. Dans le volet **Politiques d’autorisations**, choisissez **Ajouter des autorisations**, puis **Créer une politique en ligne**.
1. Dans l’**Éditeur de politique**, sélectionnez **JSON**.
1. Collez la politique que vous souhaitez ajouter dans l’éditeur (en remplacement du JSON existant), puis choisissez **Suivant**.
1. Sous **Détails de la politique**, saisissez un **Nom de la politique**.
1. Choisissez **Create Policy** (Créer une politique).
------
#### [ AWS CLI ]
**Pour ajouter une politique d’autorisations au rôle d’exécution d’une fonction (CLI)**
1. Créez un document de politique JSON avec les autorisations requises et enregistrez-le dans un répertoire local.
1. Utilisez la commande `put-role-policy` de la CLI IAM pour ajouter des autorisations au rôle d’exécution de votre fonction. Exécutez la commande suivante depuis le répertoire dans lequel vous avez enregistré votre document de politique JSON et remplacez le nom du rôle, le nom de la politique et le document de politique par vos propres valeurs.
```
aws iam put-role-policy \
--role-name my_lambda_role \
--policy-name LambdaS3DestinationPolicy \
--policy-document file://my_policy.json
```
------
### Exemple d’enregistrement d’invocation Amazon SNS et Amazon SQS
L’exemple suivant montre ce que Lambda envoie à une file d’attente SQS ou à une rubrique SNS en cas d’échec de l’invocation d’une source d’événement Kinesis. Étant donné que Lambda envoie uniquement les métadonnées pour ces types de destination, utilisez les champs `streamArn`, `shardId`, `startSequenceNumber` et `endSequenceNumber` pour obtenir l’enregistrement original complet. Tous les champs présentés dans la propriété `KinesisBatchInfo` seront toujours présents.
```
{
"requestContext": {
"requestId": "c9b8fa9f-5a7f-xmpl-af9c-0c604cde93a5",
"functionArn": "arn:aws:lambda:us-east-2:123456789012:function:myfunction",
"condition": "RetryAttemptsExhausted",
"approximateInvokeCount": 1
},
"responseContext": {
"statusCode": 200,
"executedVersion": "$LATEST",
"functionError": "Unhandled"
},
"version": "1.0",
"timestamp": "2019-11-14T00:38:06.021Z",
"KinesisBatchInfo": {
"shardId": "shardId-000000000001",
"startSequenceNumber": "49601189658422359378836298521827638475320189012309704722",
"endSequenceNumber": "49601189658422359378836298522902373528957594348623495186",
"approximateArrivalOfFirstRecord": "2019-11-14T00:38:04.835Z",
"approximateArrivalOfLastRecord": "2019-11-14T00:38:05.580Z",
"batchSize": 500,
"streamArn": "arn:aws:kinesis:us-east-2:123456789012:stream/mystream"
}
}
```
Vous pouvez utiliser ces informations pour récupérer les enregistrements concernés à partir du flux à des fins de résolution de problèmes. Les enregistrements réels n’étant pas inclus, vous devez les récupérer du flux avant qu’ils expirent et soient perdus.
### Exemple d’enregistrement d’invocation Amazon S3
L’exemple suivant montre ce que Lambda envoie à un compartiment Amazon S3 ou à une invocation de source d’événement Kinesis. Outre tous les champs de l’exemple précédent pour les destinations SQS et SNS, le champ `payload` contient l’enregistrement d’invocation d’origine sous forme de chaîne JSON échappée.
```
{
"requestContext": {
"requestId": "c9b8fa9f-5a7f-xmpl-af9c-0c604cde93a5",
"functionArn": "arn:aws:lambda:us-east-2:123456789012:function:myfunction",
"condition": "RetryAttemptsExhausted",
"approximateInvokeCount": 1
},
"responseContext": {
"statusCode": 200,
"executedVersion": "$LATEST",
"functionError": "Unhandled"
},
"version": "1.0",
"timestamp": "2019-11-14T00:38:06.021Z",
"KinesisBatchInfo": {
"shardId": "shardId-000000000001",
"startSequenceNumber": "49601189658422359378836298521827638475320189012309704722",
"endSequenceNumber": "49601189658422359378836298522902373528957594348623495186",
"approximateArrivalOfFirstRecord": "2019-11-14T00:38:04.835Z",
"approximateArrivalOfLastRecord": "2019-11-14T00:38:05.580Z",
"batchSize": 500,
"streamArn": "arn:aws:kinesis:us-east-2:123456789012:stream/mystream"
},
"payload": "" // Only available in S3
}
```
L’objet S3 contenant l’enregistrement d’invocation utilise la convention de dénomination suivante :
```
aws/lambda///YYYY/MM/DD/YYYY-MM-DDTHH.MM.SS-
```
# Implémentation du traitement des flux de données Kinesis avec état dans Lambda
Les fonctions Lambda peuvent exécuter des applications de traitement de flux continu. Un flux représente des données illimitées qui circulent en continu dans votre application. Pour analyser les informations provenant de cette entrée de mise à jour continue, vous pouvez lier les enregistrements inclus à l’aide d’une fenêtre de temps définie.
Les fenêtres bascules sont des fenêtres temporelles distinctes qui s’ouvrent et se ferment à intervalles réguliers. Par défaut, les invocations Lambda sont sans état : vous ne pouvez pas les utiliser pour traiter des données sur plusieurs invocations continues sans base de données externe. Cependant, avec les fenêtres bascules, vous pouvez maintenir votre état au long des invocations. Cet état contient le résultat global des messages précédemment traités pour la fenêtre actuelle. Votre état peut être d’un maximum de 1 Mo par partition. S’il dépasse cette taille, Lambda met fin précocement à la fenêtre de traitement.
Chaque enregistrement d’un flux appartient à une fenêtre spécifique. La fonction Lambda traitera chaque enregistrement au moins une fois. Toutefois, elle ne garantit pas un seul traitement pour chaque enregistrement. Dans de rares cas, tels que pour la gestion des erreurs, certains enregistrements peuvent être sujet à de multiples traitements. Les dossiers sont toujours traités dans l’ordre dès la première fois. Si les enregistrements sont traités plusieurs fois, ils peuvent être traités dans le désordre.
## Regroupement et traitement
Votre fonction gérée par l’utilisateur est invoquée tant pour l’agrégation que pour le traitement des résultats finaux de celle-ci. Lambda regroupe tous les enregistrements reçus dans la fenêtre. Vous pouvez recevoir ces enregistrements en plusieurs lots, chacun sous forme d’invocation séparée. Chaque invocation reçoit un état. Ainsi, lorsque vous utilisez des fenêtres bascules, votre réponse de fonction Lambda doit contenir une propriété `state`. Si la réponse ne contient pas de propriété `state`, Lambda considère qu’il s’agit d’une invocation ayant échoué. Pour satisfaire à cette condition, votre fonction peut renvoyer un objet `TimeWindowEventResponse` ayant la forme JSON suivante :
**Example `TimeWindowEventResponse` values**
```
{
"state": {
"1": 282,
"2": 715
},
"batchItemFailures": []
}
```
**Note**
Pour les fonctions Java, nous vous recommandons d’utiliser `Map` pour représenter l’état.
À la fin de la fenêtre, l’indicateur `isFinalInvokeForWindow` est défini sur `true` pour indiquer qu’il s’agit de l’état final et qu’il est prêt pour le traitement. Après le traitement, la fenêtre et votre invocation final se terminent, puis l’état est supprimé.
À la fin de votre fenêtre, Lambda applique un traitement final pour les actions sur les résultats de l’agrégation. Votre traitement final est invoqué de manière synchrone. Une fois l’invocation réussie, votre fonction contrôle le numéro de séquence et le traitement du flux continue. Si l’invocation échoue, votre fonction Lambda suspend le traitement ultérieur jusqu’à ce que l’invocation soit réussie.
**Example KinesisTimeWindowEvent**
```
{
"Records": [
{
"kinesis": {
"kinesisSchemaVersion": "1.0",
"partitionKey": "1",
"sequenceNumber": "49590338271490256608559692538361571095921575989136588898",
"data": "SGVsbG8sIHRoaXMgaXMgYSB0ZXN0Lg==",
"approximateArrivalTimestamp": 1607497475.000
},
"eventSource": "aws:kinesis",
"eventVersion": "1.0",
"eventID": "shardId-000000000006:49590338271490256608559692538361571095921575989136588898",
"eventName": "aws:kinesis:record",
"invokeIdentityArn": "arn:aws:iam::123456789012:role/lambda-kinesis-role",
"awsRegion": "us-east-1",
"eventSourceARN": "arn:aws:kinesis:us-east-1:123456789012:stream/lambda-stream"
}
],
"window": {
"start": "2020-12-09T07:04:00Z",
"end": "2020-12-09T07:06:00Z"
},
"state": {
"1": 282,
"2": 715
},
"shardId": "shardId-000000000006",
"eventSourceARN": "arn:aws:kinesis:us-east-1:123456789012:stream/lambda-stream",
"isFinalInvokeForWindow": false,
"isWindowTerminatedEarly": false
}
```
## Configuration
Vous pouvez configurer des fenêtres bascule lorsque vous créez ou mettez à jour un mappage de source d’événement. Pour configurer une fenêtre variable, spécifiez la fenêtre en secondes ([TumblingWindowInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-TumblingWindowInSeconds)). L'exemple de commande suivant AWS Command Line Interface (AWS CLI) crée un mappage des sources d'événements de streaming dont la fenêtre de basculement est de 120 secondes. La fonction Lambda définie pour l’agrégation et le traitement est nommée `tumbling-window-example-function`.
```
aws lambda create-event-source-mapping \
--event-source-arn arn:aws:kinesis:us-east-1:123456789012:stream/lambda-stream \
--function-name tumbling-window-example-function \
--starting-position TRIM_HORIZON \
--tumbling-window-in-seconds 120
```
Lambda détermine les limites des fenêtres bascule en fonction de l’heure à laquelle les enregistrements ont été insérés dans le flux. Tous les enregistrements ont un horodatage approximatif disponible que Lambda utilise pour déterminer des limites.
Les agrégations de fenêtres bascule ne prennent pas en charge le repartitionnement. Quand une partition prend fin, Lambda considère que la fenêtre de traitement actuelle est fermée, et les partitions enfants entament leur propre fenêtre de traitement dans un nouvel état. Lorsqu’aucun nouvel enregistrement n’est ajouté à la fenêtre actuelle, Lambda attend jusqu’à 2 minutes avant de supposer que la fenêtre est terminée. Cela permet de garantir que la fonction lit tous les enregistrements de la fenêtre actuelle, même si les enregistrements sont ajoutés par intermittence.
Les fenêtres bascule prennent complètement en charge les stratégies de nouvelle tentative existantes `maxRetryAttempts` et `maxRecordAge`.
**Example Handler.py – Agrégation et traitement**
La fonction Python suivante montre comment regrouper et traiter votre état final :
```
def lambda_handler(event, context):
print('Incoming event: ', event)
print('Incoming state: ', event['state'])
#Check if this is the end of the window to either aggregate or process.
if event['isFinalInvokeForWindow']:
# logic to handle final state of the window
print('Destination invoke')
else:
print('Aggregate invoke')
#Check for early terminations
if event['isWindowTerminatedEarly']:
print('Window terminated early')
#Aggregation logic
state = event['state']
for record in event['Records']:
state[record['kinesis']['partitionKey']] = state.get(record['kinesis']['partitionKey'], 0) + 1
print('Returning state: ', state)
return {'state': state}
```
# Paramètres Lambda pour les mappages des sources d’événements Amazon Kinesis Data Streams
Tous les mappages de sources d’événements Lambda partagent les mêmes opérations d’API [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) et [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html). Cependant, seuls certains paramètres s’appliquent à Kinesis.
| Paramètre | Obligatoire | Par défaut | Remarques |
| --- | --- | --- | --- |
| [BatchSize](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-BatchSize) | N | 100 | Maximum : 10 000. |
| [BisectBatchOnFunctionError](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-BisectBatchOnFunctionError) | N | FAUX | none |
| [DestinationConfig](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-DestinationConfig) | N | N/A | File d’attente Amazon SQS ou destination de rubrique Amazon SNS pour les enregistrements supprimés. Pour de plus amples informations, consultez [Configuration des destinations pour les invocations ayant échoué](kinesis-on-failure-destination.md#kinesis-on-failure-destination-console). |
| [Activé](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-Enabled) | N | VRAI | none |
| [EventSourceArn](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-EventSourceArn) | Y | N/A | ARN du flux de données ou d’un consommateur de flux |
| [FunctionName](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-FunctionName) | Y | N/A | none |
| [FunctionResponseTypes](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-FunctionResponseTypes) | N | N/A | Pour permettre à votre fonction de signaler des échecs spécifiques dans un lot, incluez la valeur `ReportBatchItemFailures` dans `FunctionResponseTypes`. Pour de plus amples informations, consultez [Configuration d’une réponse par lots partielle avec Kinesis Data Streams et Lambda](services-kinesis-batchfailurereporting.md). |
| [MaximumBatchingWindowInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumBatchingWindowInSeconds) | N | 0 | none |
| [MaximumRecordAgeInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumRecordAgeInSeconds) | N | -1 | -1 signifie infini : Lambda ne supprime pas les enregistrements (les [paramètres de conservation des données Kinesis Data Streams](https://docs.aws.amazon.com/streams/latest/dev/kinesis-extended-retention.html) s’appliquent toujours) Minimum : -1 Maximum : 604 800 |
| [MaximumRetryAttempts](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumRetryAttempts) | N | -1 | -1 signifie infini : les registres qui ont échoué sont réessayés jusqu’à ce que le registre expire. Minimum : -1 Maximum : 10 000. |
| [ParallelizationFactor](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-ParallelizationFactor) | N | 1 | Maximum : 10 |
| [StartingPosition](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-StartingPosition) | O | N/A | AT\$1TIMESTAMP, TRIM\$1HORIZON ou DERNIER |
| [StartingPositionTimestamp](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-StartingPositionTimestamp) | N | N/A | Valide uniquement si StartingPosition est défini sur AT\$1TIMESTAMP. L’heure à partir de laquelle commencer la lecture, en secondes au format horaire Unix. |
| [TumblingWindowInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-TumblingWindowInSeconds) | N | N/A | Minimum : 0 Maximum : 900 |
# Utilisation du filtrage des événements avec une source d’événement Kinesis
Vous pouvez utiliser le filtrage d’événements pour contrôler les enregistrements d’un flux ou d’une file d’attente que Lambda envoie à votre fonction. Pour obtenir des informations générales sur le fonctionnement du filtrage des événements, consultez [Contrôle des événements envoyés par Lambda à votre fonction](invocation-eventfiltering.md).
Cette section porte sur le filtrage des événements pour les sources Kinesis.
**Note**
Les mappages des sources d’événements Kinesis prennent uniquement en charge le filtrage sur la clé `data`.
**Topics**
+ [Notions de base du filtrage des événements Kinesis](#filtering-kinesis)
+ [Filtrage des enregistrements agrégés de Kinesis](#filtering-kinesis-efo)
## Notions de base du filtrage des événements Kinesis
Supposons qu’un producteur insère des données au format JSON dans votre flux de données Kinesis. Un exemple d’enregistrement ressemblerait à ce qui suit, avec les données JSON converties en chaîne encodée en Base64 dans le champ `data`.
```
{
"kinesis": {
"kinesisSchemaVersion": "1.0",
"partitionKey": "1",
"sequenceNumber": "49590338271490256608559692538361571095921575989136588898",
"data": "eyJSZWNvcmROdW1iZXIiOiAiMDAwMSIsICJUaW1lU3RhbXAiOiAieXl5eS1tbS1kZFRoaDptbTpzcyIsICJSZXF1ZXN0Q29kZSI6ICJBQUFBIn0=",
"approximateArrivalTimestamp": 1545084650.987
},
"eventSource": "aws:kinesis",
"eventVersion": "1.0",
"eventID": "shardId-000000000006:49590338271490256608559692538361571095921575989136588898",
"eventName": "aws:kinesis:record",
"invokeIdentityArn": "arn:aws:iam::123456789012:role/lambda-role",
"awsRegion": "us-east-2",
"eventSourceARN": "arn:aws:kinesis:us-east-2:123456789012:stream/lambda-stream"
}
```
Tant que les données insérées dans le flux par le producteur sont des données JSON valides, vous pouvez utiliser le filtrage d’événements pour filtrer les enregistrements à l’aide de la clé `data`. Supposons qu’un producteur insère des enregistrements dans votre flux Kinesis au format JSON suivant.
```
{
"record": 12345,
"order": {
"type": "buy",
"stock": "ANYCO",
"quantity": 1000
}
}
```
Pour filtrer uniquement les enregistrements dont le type d’ordre est « buy », l’objet `FilterCriteria` serait le suivant.
```
{
"Filters": [
{
"Pattern": "{ \"data\" : { \"order\" : { \"type\" : [ \"buy\" ] } } }"
}
]
}
```
Pour plus de clarté, voici la valeur du `Pattern` de filtre étendu en JSON simple :
```
{
"data": {
"order": {
"type": [ "buy" ]
}
}
}
```
Vous pouvez ajouter votre filtre à l’aide de la console, d’AWS CLI ou d’un modèle AWS SAM.
------
#### [ Console ]
Pour ajouter ce filtre à l’aide de la console, suivez les instructions de [Attacher des critères de filtre à un mappage de sources d’événements (console)](invocation-eventfiltering.md#filtering-console) et saisissez la chaîne suivante comme **critère de filtre**.
```
{ "data" : { "order" : { "type" : [ "buy" ] } } }
```
------
#### [ AWS CLI ]
Pour créer un nouveau mappage des sources d’événements avec ces critères de filtrage à l’aide de l’outil AWS Command Line Interface (AWS CLI), exécutez la commande suivante.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:kinesis:us-east-2:123456789012:stream/my-stream \
--filter-criteria '{"Filters": [{"Pattern": "{ \"data\" : { \"order\" : { \"type\" : [ \"buy\" ] } } }"}]}'
```
Pour ajouter ces critères de filtre à un mappage des sources d’événements existant, exécutez la commande suivante.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"data\" : { \"order\" : { \"type\" : [ \"buy\" ] } } }"}]}'
```
------
#### [ AWS SAM ]
Pour ajouter ce filtre à l’aide d’AWS SAM, ajoutez l’extrait suivant au modèle YAML de votre source d’événement.
```
FilterCriteria:
Filters:
- Pattern: '{ "data" : { "order" : { "type" : [ "buy" ] } } }'
```
------
Pour filtrer correctement les événements provenant de sources Kinesis, le champ de données et vos critères de filtre pour le champ de données doivent être au format JSON valide. Si l’un ou l’autre des champs n’est pas dans un format JSON valide, Lambda rejette le message ou lance une exception. Le tableau suivant résume le comportement spécifique :
| Format des données entrantes | Pas de modèle de filtre pour les propriétés des données | Action obtenue. |
| --- | --- | --- |
| JSON valide | JSON valide | Lambda filtre en fonction de vos critères de filtre. |
| JSON valide | Pas de modèle de filtre pour les propriétés des données | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
| JSON valide | Non JSON | Lambda lance une exception au moment de la création ou de la mise à jour du mappage de sources d’événements. Le modèle de filtre des propriétés de données doit être au format JSON valide. |
| Non JSON | JSON valide | Lambda rejette l’enregistrement. |
| Non JSON | Pas de modèle de filtre pour les propriétés des données | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
| Non JSON | Non JSON | Lambda lance une exception au moment de la création ou de la mise à jour du mappage de sources d’événements. Le modèle de filtre des propriétés de données doit être au format JSON valide. |
## Filtrage des enregistrements agrégés de Kinesis
Avec Kinesis, vous pouvez agréger plusieurs enregistrements en un seul enregistrement Kinesis Data Streams pour augmenter le débit de vos données. Lambda ne peut appliquer des critères de filtrage aux enregistrements agrégés que lorsque vous utilisez la [distribution ramifiée améliorée](https://docs.aws.amazon.com/streams/latest/dev/enhanced-consumers.html) de Kinesis. Le filtrage des enregistrements agrégés avec Kinesis standard n’est pas pris en charge. Lorsque vous utilisez la distribution ramifiée améliorée, vous configurez un consommateur Kinesis à débit dédié pour qu’il serve de déclencheur à votre fonction Lambda. Lambda filtre alors les enregistrements agrégés et ne transmet que les enregistrements qui répondent à vos critères de filtrage.
Pour en savoir plus sur l’agrégation d’enregistrements Kinesis, reportez-vous à la section [Agrégation](https://docs.aws.amazon.com/streams/latest/dev/kinesis-kpl-concepts.html#kinesis-kpl-concepts-aggretation) sur la page Concepts clés de Kinesis Producer Library (KPL). Pour en savoir plus sur l’utilisation de Lambda avec la distribution ramifiée améliorée de Kinesis, consultez [Increasing real-time stream processing performance with Amazon Kinesis Data Streams enhanced fan-out and AWS Lambda](https://aws.amazon.com/blogs/compute/increasing-real-time-stream-processing-performance-with-amazon-kinesis-data-streams-enhanced-fan-out-and-aws-lambda/) sur le blog AWS compute.
# Tutoriel : Utilisation de Lambda avec les flux de données Kinesis
Dans ce tutoriel, vous créez une fonction Lambda pour consommer des événements à partir d’un flux de données Amazon Kinesis.
1. L’application personnalisée écrit les enregistrements dans le flux.
1. AWS Lambda interroge le flux et, lorsqu'il détecte de nouveaux enregistrements dans le flux, invoque votre fonction Lambda.
1. AWS Lambda exécute la fonction Lambda en assumant le rôle d'exécution que vous avez spécifié lors de la création de la fonction Lambda.
## Conditions préalables
### Installez le AWS Command Line Interface
Si vous ne l'avez pas encore installé AWS Command Line Interface, suivez les étapes décrites dans la [section Installation ou mise à jour de la dernière version du AWS CLI pour l'](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)installer.
Ce tutoriel nécessite un terminal de ligne de commande ou un shell pour exécuter les commandes. Sous Linux et macOS, utilisez votre gestionnaire de shell et de package préféré.
**Note**
Sous Windows, certaines commandes CLI Bash que vous utilisez couramment avec Lambda (par exemple `zip`) ne sont pas prises en charge par les terminaux intégrés du système d’exploitation. [Installez le sous-système Windows pour Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10) afin d’obtenir une version intégrée à Windows d’Ubuntu et Bash.
## Créer le rôle d’exécution
Créez le [rôle d'exécution](lambda-intro-execution-role.md) qui autorise votre fonction à accéder aux AWS ressources.
**Pour créer un rôle d’exécution**
1. Ouvrez la page [Roles (Rôles)](https://console.aws.amazon.com/iam/home#/roles) dans la console IAM.
1. Sélectionnez **Créer un rôle**.
1. Créez un rôle avec les propriétés suivantes :
+ **Entité de confiance** – **AWS Lambda**.
+ **Autorisations** — **AWSLambdaKinesisExecutionRole**.
+ **Nom de rôle** – **lambda-kinesis-role**.
La **AWSLambdaKinesisExecutionRole**politique dispose des autorisations dont la fonction a besoin pour lire des éléments provenant de Kinesis et écrire des journaux dans Logs. CloudWatch
## Créer la fonction
Créez une fonction Lambda qui traite vos messages Kinesis. Le code de fonction enregistre l'ID d'événement et les données d'événement de l'enregistrement Kinesis dans Logs. CloudWatch
Ce didacticiel utilise le runtime Node.js 24, mais nous avons également fourni des exemples de code dans d'autres langages d'exécution. Vous pouvez sélectionner l’onglet dans la zone suivante pour voir le code de l’exécution qui vous intéresse. Le JavaScript code que vous allez utiliser dans cette étape se trouve dans le premier exemple présenté dans l'**JavaScript**onglet.
------
#### [ .NET ]
**SDK pour .NET**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda).
Consommation d’un événement Kinesis avec Lambda à l’aide de .NET.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using System.Text;
using Amazon.Lambda.Core;
using Amazon.Lambda.KinesisEvents;
using AWS.Lambda.Powertools.Logging;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace KinesisIntegrationSampleCode;
public class Function
{
// Powertools Logger requires an environment variables against your function
// POWERTOOLS_SERVICE_NAME
[Logging(LogEvent = true)]
public async Task FunctionHandler(KinesisEvent evnt, ILambdaContext context)
{
if (evnt.Records.Count == 0)
{
Logger.LogInformation("Empty Kinesis Event received");
return;
}
foreach (var record in evnt.Records)
{
try
{
Logger.LogInformation($"Processed Event with EventId: {record.EventId}");
string data = await GetRecordDataAsync(record.Kinesis, context);
Logger.LogInformation($"Data: {data}");
// TODO: Do interesting work based on the new data
}
catch (Exception ex)
{
Logger.LogError($"An error occurred {ex.Message}");
throw;
}
}
Logger.LogInformation($"Successfully processed {evnt.Records.Count} records.");
}
private async Task GetRecordDataAsync(KinesisEvent.Record record, ILambdaContext context)
{
byte[] bytes = record.Data.ToArray();
string data = Encoding.UTF8.GetString(bytes);
await Task.CompletedTask; //Placeholder for actual async work
return data;
}
}
```
------
#### [ Go ]
**Kit SDK pour Go V2**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda).
Consommation d’un événement Kinesis avec Lambda à l’aide de Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package main
import (
"context"
"log"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func handler(ctx context.Context, kinesisEvent events.KinesisEvent) error {
if len(kinesisEvent.Records) == 0 {
log.Printf("empty Kinesis event received")
return nil
}
for _, record := range kinesisEvent.Records {
log.Printf("processed Kinesis event with EventId: %v", record.EventID)
recordDataBytes := record.Kinesis.Data
recordDataText := string(recordDataBytes)
log.Printf("record data: %v", recordDataText)
// TODO: Do interesting work based on the new data
}
log.Printf("successfully processed %v records", len(kinesisEvent.Records))
return nil
}
func main() {
lambda.Start(handler)
}
```
------
#### [ Java ]
**SDK pour Java 2.x**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda).
Consommation d’un événement Kinesis avec Lambda à l’aide de Java.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package example;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.LambdaLogger;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.KinesisEvent;
public class Handler implements RequestHandler {
@Override
public Void handleRequest(final KinesisEvent event, final Context context) {
LambdaLogger logger = context.getLogger();
if (event.getRecords().isEmpty()) {
logger.log("Empty Kinesis Event received");
return null;
}
for (KinesisEvent.KinesisEventRecord record : event.getRecords()) {
try {
logger.log("Processed Event with EventId: "+record.getEventID());
String data = new String(record.getKinesis().getData().array());
logger.log("Data:"+ data);
// TODO: Do interesting work based on the new data
}
catch (Exception ex) {
logger.log("An error occurred:"+ex.getMessage());
throw ex;
}
}
logger.log("Successfully processed:"+event.getRecords().size()+" records");
return null;
}
}
```
------
#### [ JavaScript ]
**SDK pour JavaScript (v3)**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/blob/main/integration-kinesis-to-lambda).
Utilisation d'un événement Kinesis avec Lambda à l'aide de. JavaScript
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
exports.handler = async (event, context) => {
for (const record of event.Records) {
try {
console.log(`Processed Kinesis Event - EventID: ${record.eventID}`);
const recordData = await getRecordDataAsync(record.kinesis);
console.log(`Record Data: ${recordData}`);
// TODO: Do interesting work based on the new data
} catch (err) {
console.error(`An error occurred ${err}`);
throw err;
}
}
console.log(`Successfully processed ${event.Records.length} records.`);
};
async function getRecordDataAsync(payload) {
var data = Buffer.from(payload.data, "base64").toString("utf-8");
await Promise.resolve(1); //Placeholder for actual async work
return data;
}
```
Utilisation d'un événement Kinesis avec Lambda à l'aide de. TypeScript
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import {
KinesisStreamEvent,
Context,
KinesisStreamHandler,
KinesisStreamRecordPayload,
} from "aws-lambda";
import { Buffer } from "buffer";
import { Logger } from "@aws-lambda-powertools/logger";
const logger = new Logger({
logLevel: "INFO",
serviceName: "kinesis-stream-handler-sample",
});
export const functionHandler: KinesisStreamHandler = async (
event: KinesisStreamEvent,
context: Context
): Promise => {
for (const record of event.Records) {
try {
logger.info(`Processed Kinesis Event - EventID: ${record.eventID}`);
const recordData = await getRecordDataAsync(record.kinesis);
logger.info(`Record Data: ${recordData}`);
// TODO: Do interesting work based on the new data
} catch (err) {
logger.error(`An error occurred ${err}`);
throw err;
}
logger.info(`Successfully processed ${event.Records.length} records.`);
}
};
async function getRecordDataAsync(
payload: KinesisStreamRecordPayload
): Promise {
var data = Buffer.from(payload.data, "base64").toString("utf-8");
await Promise.resolve(1); //Placeholder for actual async work
return data;
}
```
------
#### [ PHP ]
**Kit SDK pour PHP**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda).
Consommation d’un événement Kinesis avec Lambda à l’aide de PHP.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
logger = $logger;
}
/**
* @throws JsonException
* @throws \Bref\Event\InvalidLambdaEvent
*/
public function handleKinesis(KinesisEvent $event, Context $context): void
{
$this->logger->info("Processing records");
$records = $event->getRecords();
foreach ($records as $record) {
$data = $record->getData();
$this->logger->info(json_encode($data));
// TODO: Do interesting work based on the new data
// Any exception thrown will be logged and the invocation will be marked as failed
}
$totalRecords = count($records);
$this->logger->info("Successfully processed $totalRecords records");
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**Kit SDK for Python (Boto3)**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda).
Consommation d’un événement Kinesis avec Lambda à l’aide de Python.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
import base64
def lambda_handler(event, context):
for record in event['Records']:
try:
print(f"Processed Kinesis Event - EventID: {record['eventID']}")
record_data = base64.b64decode(record['kinesis']['data']).decode('utf-8')
print(f"Record Data: {record_data}")
# TODO: Do interesting work based on the new data
except Exception as e:
print(f"An error occurred {e}")
raise e
print(f"Successfully processed {len(event['Records'])} records.")
```
------
#### [ Ruby ]
**Kit SDK pour Ruby**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda).
Consommation d’un événement Kinesis avec Lambda à l’aide de Ruby.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
require 'aws-sdk'
def lambda_handler(event:, context:)
event['Records'].each do |record|
begin
puts "Processed Kinesis Event - EventID: #{record['eventID']}"
record_data = get_record_data_async(record['kinesis'])
puts "Record Data: #{record_data}"
# TODO: Do interesting work based on the new data
rescue => err
$stderr.puts "An error occurred #{err}"
raise err
end
end
puts "Successfully processed #{event['Records'].length} records."
end
def get_record_data_async(payload)
data = Base64.decode64(payload['data']).force_encoding('UTF-8')
# Placeholder for actual async work
# You can use Ruby's asynchronous programming tools like async/await or fibers here.
return data
end
```
------
#### [ Rust ]
**SDK pour Rust**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-kinesis-to-lambda).
Consommation d’un événement Kinesis avec Lambda à l’aide de Rust.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
use aws_lambda_events::event::kinesis::KinesisEvent;
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
async fn function_handler(event: LambdaEvent) -> Result<(), Error> {
if event.payload.records.is_empty() {
tracing::info!("No records found. Exiting.");
return Ok(());
}
event.payload.records.iter().for_each(|record| {
tracing::info!("EventId: {}",record.event_id.as_deref().unwrap_or_default());
let record_data = std::str::from_utf8(&record.kinesis.data);
match record_data {
Ok(data) => {
// log the record data
tracing::info!("Data: {}", data);
}
Err(e) => {
tracing::error!("Error: {}", e);
}
}
});
tracing::info!(
"Successfully processed {} records",
event.payload.records.len()
);
Ok(())
}
#[tokio::main]
async fn main() -> Result<(), Error> {
tracing_subscriber::fmt()
.with_max_level(tracing::Level::INFO)
// disable printing the name of the module in every log line.
.with_target(false)
// disabling time is handy because CloudWatch will add the ingestion time.
.without_time()
.init();
run(service_fn(function_handler)).await
}
```
------
**Pour créer la fonction**
1. Créez un répertoire pour le projet, puis passez à ce répertoire.
```
mkdir kinesis-tutorial
cd kinesis-tutorial
```
1. Copiez l'exemple de JavaScript code dans un nouveau fichier nommé`index.js`.
1. Créez un package de déploiement.
```
zip function.zip index.js
```
1. Créez une fonction Lambda à l’aide de la commande `create-function`.
```
aws lambda create-function --function-name ProcessKinesisRecords \
--zip-file fileb://function.zip --handler index.handler --runtime nodejs24.x \
--role arn:aws:iam::111122223333:role/lambda-kinesis-role
```
## Test de la fonction Lambda
Appelez votre fonction Lambda manuellement à l'aide de la commande `invoke` AWS Lambda CLI et d'un exemple d'événement Kinesis.
**Pour tester la fonction Lambda**
1. Copiez le code JSON suivant dans un fichier et enregistrez-le sous le nom `input.txt`.
```
{
"Records": [
{
"kinesis": {
"kinesisSchemaVersion": "1.0",
"partitionKey": "1",
"sequenceNumber": "49590338271490256608559692538361571095921575989136588898",
"data": "SGVsbG8sIHRoaXMgaXMgYSB0ZXN0Lg==",
"approximateArrivalTimestamp": 1545084650.987
},
"eventSource": "aws:kinesis",
"eventVersion": "1.0",
"eventID": "shardId-000000000006:49590338271490256608559692538361571095921575989136588898",
"eventName": "aws:kinesis:record",
"invokeIdentityArn": "arn:aws:iam::111122223333:role/lambda-kinesis-role",
"awsRegion": "us-east-2",
"eventSourceARN": "arn:aws:kinesis:us-east-2:111122223333:stream/lambda-stream"
}
]
}
```
1. Utilisez la commande `invoke` pour envoyer l’événement à la fonction.
```
aws lambda invoke --function-name ProcessKinesisRecords \
--cli-binary-format raw-in-base64-out \
--payload file://input.txt outputfile.txt
```
L'**cli-binary-format**option est obligatoire si vous utilisez AWS CLI la version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez `aws configure set cli-binary-format raw-in-base64-out`. Pour plus d’informations, consultez les [options de ligne de commande globales AWS CLI prises en charge](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) dans le *Guide de l’utilisateur AWS Command Line Interface version 2*.
La réponse est enregistrée dans `out.txt`.
## Créez un flux Kinesis
Pour créer un flux, utilisez la commande `create-stream `.
```
aws kinesis create-stream --stream-name lambda-stream --shard-count 1
```
Exécutez la commande `describe-stream` suivante pour obtenir l’ARN du flux.
```
aws kinesis describe-stream --stream-name lambda-stream
```
Vous devriez voir la sortie suivante:
```
{
"StreamDescription": {
"Shards": [
{
"ShardId": "shardId-000000000000",
"HashKeyRange": {
"StartingHashKey": "0",
"EndingHashKey": "340282366920746074317682119384634633455"
},
"SequenceNumberRange": {
"StartingSequenceNumber": "49591073947768692513481539594623130411957558361251844610"
}
}
],
"StreamARN": "arn:aws:kinesis:us-east-1:111122223333:stream/lambda-stream",
"StreamName": "lambda-stream",
"StreamStatus": "ACTIVE",
"RetentionPeriodHours": 24,
"EnhancedMonitoring": [
{
"ShardLevelMetrics": []
}
],
"EncryptionType": "NONE",
"KeyId": null,
"StreamCreationTimestamp": 1544828156.0
}
}
```
Vous utilisez l’ARN du flux à l’étape suivante pour associer le flux à la fonction Lambda.
## Ajouter une source d'événement dans AWS Lambda
Exécutez la commande suivante AWS CLI `add-event-source`.
```
aws lambda create-event-source-mapping --function-name ProcessKinesisRecords \
--event-source arn:aws:kinesis:us-east-1:111122223333:stream/lambda-stream \
--batch-size 100 --starting-position LATEST
```
Notez l’ID de mappage pour une utilisation ultérieure. Pour obtenir une liste des mappages de source d’événement, exécutez la commande suivante `list-event-source-mappings`.
```
aws lambda list-event-source-mappings --function-name ProcessKinesisRecords \
--event-source arn:aws:kinesis:us-east-1:111122223333:stream/lambda-stream
```
Dans la réponse, vous pouvez vérifier que la valeur d’état indique `enabled`. Les mappages de source d’événement peuvent être désactivés pour suspendre temporairement l’interrogation, ce qui entraîne la perte d’enregistrements.
## Tester la configuration
Pour tester le mappage de source d’événement, ajoutez des enregistrements d’événements à votre flux Kinesis. La valeur `--data` est une chaîne que la commande CLI encode en base 64 avant de l’envoyer à Kinesis. Vous pouvez exécuter la même commande plus d’une fois pour ajouter plusieurs enregistrements dans le flux.
```
aws kinesis put-record --stream-name lambda-stream --partition-key 1 \
--data "Hello, this is a test."
```
Lambda utilise le rôle d’exécution pour lire les enregistrements du flux. Ensuite, il invoque votre fonction Lambda en transmettant des lots d’enregistrements. La fonction décode les données de chaque enregistrement et les enregistre, en envoyant le résultat à CloudWatch Logs. Affichez les journaux dans la [console CloudWatch ](https://console.aws.amazon.com/cloudwatch).
## Nettoyage de vos ressources
Vous pouvez maintenant supprimer les ressources que vous avez créées pour ce didacticiel, sauf si vous souhaitez les conserver. En supprimant AWS les ressources que vous n'utilisez plus, vous évitez des frais inutiles pour votre Compte AWS.
**Pour supprimer le rôle d’exécution**
1. Ouvrez la [page Roles (Rôles)](https://console.aws.amazon.com/iam/home#/roles) de la console IAM.
1. Sélectionnez le rôle d’exécution que vous avez créé.
1. Sélectionnez **Delete (Supprimer)**.
1. Saisissez le nom du rôle dans le champ de saisie de texte et choisissez **Delete** (Supprimer).
**Pour supprimer la fonction Lambda**
1. Ouvrez la [page Functions (Fonctions)](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda.
1. Sélectionnez la fonction que vous avez créée.
1. Sélectionnez **Actions**, **Supprimer**.
1. Saisissez **confirm** dans la zone de saisie de texte et choisissez **Delete** (Supprimer).
**Pour supprimer le flux Kinesis**
1. [Connectez-vous à la console Kinesis AWS Management Console et ouvrez-la à https://console.aws.amazon.com l'adresse /kinesis.](https://console.aws.amazon.com/kinesis)
1. Sélectionnez le flux que vous avez créé.
1. Sélectionnez **Actions**, **Supprimer**.
1. Saisissez **delete** dans le champ de saisie de texte.
1. Sélectionnez **Supprimer**.
# Utilisation de Lambda avec Kubernetes
Vous pouvez déployer et gérer des fonctions Lambda avec l’API Kubernetes à l’aide d’[AWS Controllers for Kubernetes (ACK)](https://aws-controllers-k8s.github.io/community/docs/community/overview/) ou [Crossplane](https://docs.crossplane.io/latest/packages/providers/).
## AWS Controllers for Kubernetes (ACK)
Vous pouvez utiliser ACK pour déployer et gérer des ressources AWS de l’API Kubernetes. Par le biais d’ACK, AWS fournit des contrôleurs open source personnalisés pour des services AWS tels que Lambda, Amazon Elastic Container Registry (Amazon ECR), Amazon Simple Storage Service (Amazon S3) et Amazon SageMaker AI. Chaque service AWS pris en charge possède son propre contrôleur personnalisé. Dans votre cluster Kubernetes, installez un contrôleur pour chaque service AWS que vous souhaitez utiliser. Créez ensuite une [définition de ressource personnalisée (Custom Resource Definition, CRD)](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) pour définir les ressources AWS.
Nous vous recommandons d’utiliser [Helm 3.8 ou version ultérieure](https://helm.sh/docs/intro/install/) pour installer les contrôleurs ACK. Chaque contrôleur ACK est doté de ses propres Charts de Helm, qui installent le contrôleur, les CRD et les règles RBAC de Kubernetes. Pour plus d’informations, consultez [Installer un contrôleur ACK](https://aws-controllers-k8s.github.io/community/docs/user-docs/install/) dans la documentation ACK.
Après avoir créé la ressource personnalisée ACK, vous pouvez l’utiliser comme n’importe quel autre objet Kubernetes intégré. Par exemple, vous pouvez déployer et gérer des fonctions Lambda avec vos chaînes d’outils Kubernetes préférées, notamment [kubectl](https://kubernetes.io/docs/reference/kubectl/).
Voici quelques exemples de cas d’utilisation pour le provisionnement de fonctions Lambda via ACK :
+ Votre organisation utilise le [contrôle d’accès basé sur les rôles (RBAC)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) et des [rôles IAM pour les comptes de service](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) afin de créer les limites des autorisations. Avec ACK, vous pouvez réutiliser ce modèle de sécurité pour Lambda sans avoir à créer d’autres utilisateurs et stratégies.
+ Votre organisation dispose d’un processus DevOps pour déployer des ressources dans un cluster Amazon Elastic Kubernetes Service (Amazon EKS) à l’aide de manifestes Kubernetes. Avec ACK, vous pouvez utiliser un manifeste pour provisionner des fonctions Lambda sans créer d’infrastructure distincte sous forme de modèles de code.
Pour plus d’informations sur l’utilisation d’ACK, consultez le [didacticiel Lambda dans la documentation ACK](https://aws-controllers-k8s.github.io/community/docs/tutorials/lambda-oci-example/).
## Crossplane
[Crossplane](https://docs.crossplane.io/latest/packages/providers/) est un projet open source de la Cloud Native Computing Foundation (CNCF) qui utilise Kubernetes pour gérer les ressources de l’infrastructure cloud. Avec Crossplane, les développeurs peuvent demander une infrastructure sans avoir à en comprendre la complexité. Les équipes chargées de la plateforme gardent le contrôle de la manière dont l’infrastructure est provisionnée et gérée.
À l’aide de Crossplane, vous pouvez déployer et gérer des fonctions Lambda avec vos chaînes d’outils Kubernetes préférées, telles que [kubectl](https://kubernetes.io/docs/reference/kubectl/), et tout pipeline CI/CD capable de déployer des manifestes sur Kubernetes. Voici quelques exemples de cas d’utilisation pour le provisionnement de fonctions Lambda via Crossplane :
+ Votre entreprise souhaite renforcer la conformité en s’assurant que les fonctions Lambda disposent des [balises](configuration-tags.md) appropriées. Les équipes chargées de la plateforme peuvent utiliser [Compositions Crossplane](https://docs.crossplane.io/latest/get-started/get-started-with-composition/) pour définir cette stratégie par le biais d’abstractions d’API. Les développeurs peuvent ensuite utiliser ces abstractions pour déployer des fonctions Lambda avec des balises.
+ Votre projet utilise GitOps avec Kubernetes. Dans ce modèle, Kubernetes réconcilie en permanence le référentiel Git (état souhaité) avec les ressources qui s’exécutent à l’intérieur du cluster (état actuel). S’il existe des différences, le processus GitOps apporte automatiquement des modifications au cluster. Vous pouvez utiliser GitOps avec Kubernetes pour déployer et gérer des fonctions Lambda via Crossplane, à l’aide d’outils et de concepts Kubernetes bien connus tels que des [CRD](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) et des [contrôleurs](https://kubernetes.io/docs/concepts/architecture/controller/).
Pour en savoir plus sur l’utilisation de Crossplane avec Lambda, consultez les rubriques suivantes :
+ [Plans AWS pour Crossplane](https://github.com/awslabs/crossplane-on-eks/blob/main/examples/upbound-aws-provider/README.md#deploy-the-examples) : ce référentiel inclut des exemples d’utilisation de Crossplane pour déployer des ressources AWS, y compris les fonctions Lambda.
**Note**
Les plans AWS pour Crossplane sont en cours de développement et ne devraient pas être utilisés en production.
+ [Déploiement de Lambda avec Amazon EKS et Crossplane](https://www.youtube.com/watch?v=m-9KLq29K4k) : cette vidéo montre un exemple avancé de déploiement d’une architecture sans serveur AWS avec Crossplane, explorant la conception du point de vue du développeur et de la plateforme.
# Utilisation de Lambda avec Amazon MQ
**Note**
Si vous souhaitez envoyer des données à une cible autre qu'une fonction Lambda ou enrichir les données avant de les envoyer, consultez [Amazon EventBridge ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-pipes.html) Pipes.
Amazon MQ est un service d’agent de messages géré pour [Apache ActiveMQ](https://activemq.apache.org/) et [RabbitMQ](https://www.rabbitmq.com). Un *agent de messages* permet à des applications et composants logiciels de communiquer à l’aide de divers langages de programmation, systèmes d’exploitation et autres protocoles de messagerie formels par le biais de rubriques ou d’événements en file d’attente.
Amazon MQ peut également gérer des instances Amazon Elastic Compute Cloud (Amazon EC2) en votre nom en installant des agents ActiveMQ ou RabbitMQ, et en fournissant différentes topologies réseau et infrastructures.
Vous pouvez utiliser une fonction Lambda pour traiter des enregistrements de votre agent de messages Amazon MQ. Lambda invoque votre fonction via un [mappage de source d’événement](invocation-eventsourcemapping.md), une ressource Lambda qui lit les messages de votre agent et invoque la fonction [de manière synchrone](invocation-sync.md).
**Avertissement**
Les mappages des sources d’événements Lambda traitent chaque événement au moins une fois, et le traitement des enregistrements peut être dupliqué. Pour éviter les problèmes potentiels liés à des événements dupliqués, nous vous recommandons vivement de rendre votre code de fonction idempotent. Pour en savoir plus, consultez [Comment rendre ma fonction Lambda idempotente](https://repost.aws/knowledge-center/lambda-function-idempotent) dans le Knowledge Center. AWS
Le mappage de source d’événement Amazon MQ est sujet aux restrictions de configuration suivantes :
+ Simultanéité : les fonctions Lambda qui utilisent un mappage des sources d’événements Amazon MQ disposent d’un paramètre de [simultanéité](lambda-concurrency.md) maximale par défaut. Pour ActiveMQ, le service Lambda limite le nombre d’environnements d’exécution simultanés à cinq par mappage des sources d’événements Amazon MQ. Pour RabbitMQ, le nombre d’environnements d’exécution simultanés est limité à 1 par mappage des sources d’événements Amazon MQ. Même si vous modifiez les paramètres de simultanéité réservés ou fournis de votre fonction, le service Lambda ne mettra pas plus d’environnements d’exécution à disposition. Pour demander une augmentation de la simultanéité maximale par défaut pour un seul mappage de source d'événement Amazon MQ, Support contactez l'UUID du mappage de source d'événement, ainsi que la région. Étant donné que les augmentations sont appliquées au niveau de chaque mappage des sources d’événements, et non au niveau du compte ou de la région, vous devez demander manuellement une augmentation de mise à l’échelle pour chaque mappage des sources d’événements.
+ Traitement entre comptes – Lambda ne prend pas en charge le traitement entre comptes. Vous ne pouvez pas utiliser Lambda pour traiter des enregistrements d’un agent de messages Amazon MQ se trouvant dans un autre Compte AWS.
+ Authentification — Pour ActiveMQ, seul ActiveMQ est pris en charge. [SimpleAuthenticationPlugin](https://activemq.apache.org/security#simple-authentication-plugin) Pour RabbitMQ, seule l’authentification [PLAIN](https://www.rabbitmq.com/access-control.html#mechanisms) est prise en charge. Les utilisateurs doivent utiliser AWS Secrets Manager pour gérer leurs informations d'identification. Pour plus d’informations sur l’authentification ActiveMQ, consultez [Intégration d’agents ActiveMQ avec LDAP](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/security-authentication-authorization.html) dans le *Guide du développeur Amazon MQ*.
+ Quota de connexion – Les agents ont un nombre maximum de connexions autorisées par protocole de niveau filaire. Ce quota est basé sur le type d’instance de l’agent. Pour plus d’informations, consultez la section [Agents](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/amazon-mq-limits.html#broker-limits) de **Quotas dans Amazon** dans le *Manuel du développeur Amazon MQ*.
+ Connectivité – Vous pouvez créer des agents dans un cloud privé virtuel (VPC) public ou privé. Pour le mode privé VPCs, votre fonction Lambda doit accéder au VPC pour recevoir des messages. Pour plus d’informations, consultez [Configurer la sécurité réseau](process-mq-messages-with-lambda.md#process-mq-messages-with-lambda-networkconfiguration), plus loin dans cette section.
+ Destinations d’événements – Seules les destinations en file d’attente sont prises en charge. Toutefois, vous pouvez utiliser une rubrique virtuelle qui se comporte comme une rubrique en interne tout en interagissant avec Lambda en tant que file d’attente. Pour plus d’informations, consultez [Virtual Destinations (Destinations virtuelles)](https://activemq.apache.org/virtual-destinations) sur le site web Apache ActiveMQ, et [Virtual Hosts (Hôtes virtuels)](https://www.rabbitmq.com/vhosts.html) sur le site web RabbitMQ.
+ Topologie réseau – Pour ActiveMQ, un mappage de source d’événement prend en charge une seule instance ou un seul agent en veille. Pour RabbitMQ, un mappage de source d’événement prend en charge un seul agent d’instance ou un seul déploiement de cluster. Les agents à instance unique nécessitent un point de terminaison de basculement. Pour plus d’informations sur ces modes de déploiement d’agent, consultez [Architecture d’agent ActiveMQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/amazon-mq-broker-architecture.html) et [Architecture d’agent RabbitMQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/rabbitmq-broker-architecture.html) dans le *Guide du développeur Amazon MQ*.
+ Protocoles – Les protocoles pris en charge dépendent du type d’intégration d’Amazon MQ.
+ Pour les intégrations ActiveMQ, Lambda consomme les messages à l'aide OpenWire/Java du protocole Message Service (JMS). Aucun autre protocole n’est pris en charge pour la consommation de messages. Dans le protocole JMS, seuls [https://activemq.apache.org/components/cms/api_docs/activemqcpp-3.6.0/html/classactivemq_1_1commands_1_1_active_m_q_text_message.html](https://activemq.apache.org/components/cms/api_docs/activemqcpp-3.6.0/html/classactivemq_1_1commands_1_1_active_m_q_text_message.html) et [https://activemq.apache.org/components/cms/api_docs/activemqcpp-3.9.0/html/classactivemq_1_1commands_1_1_active_m_q_bytes_message.html](https://activemq.apache.org/components/cms/api_docs/activemqcpp-3.9.0/html/classactivemq_1_1commands_1_1_active_m_q_bytes_message.html) sont pris en charge. Lambda prend également en charge les propriétés personnalisées JMS. Pour plus d'informations sur le OpenWire protocole, consultez [OpenWire](https://activemq.apache.org/openwire.html)le site Web d'Apache ActiveMQ.
+ Pour les intégrations RabbitMQ, Lambda consomme des messages à l’aide du protocole AMQP 0-9-1. Aucun autre protocole n’est pris en charge pour la consommation de messages. Pour plus d’informations sur l’implémentation par RabbitMQ du protocole AMQP 0-9-1, consultez [Guide de référence complet AMQP 0-9-1](https://www.rabbitmq.com/amqp-0-9-1-reference.html) sur le site web de RabbitMQ.
Lambda prend automatiquement en charge les dernières versions d’ActiveMQ et de RabbitMQ qu’Amazon MQ prend en charge. Pour connaître les dernières versions prises en charge, consultez [Notes de mise à jour Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/amazon-mq-release-notes.html) dans le *Guide du développeur Amazon MQ*.
**Note**
Par défaut, Amazon MQ comporte une fenêtre de maintenance hebdomadaire pour les agents. Pendant cette période, les agents ne sont pas disponibles. Pendant ce temps, Lambda ne peut pas traiter les messages des agents sans veille.
**Topics**
+ [Comprendre le groupe de consommateurs Lambda pour Amazon MQ](#services-mq-configure)
+ [Configuration de source d’événements Amazon MQ pour Lambda](process-mq-messages-with-lambda.md)
+ [Paramètres de mappage des sources d’événements](services-mq-params.md)
+ [Filtrer les événement à partir d’une source d’événements Amazon MQ](with-mq-filtering.md)
+ [Résoudre les erreurs de mappage des sources d’événement Amazon MQ](services-mq-errors.md)
## Comprendre le groupe de consommateurs Lambda pour Amazon MQ
Pour interagir avec Amazon MQ, Lambda crée un groupe de consommateurs qui peut être lu à partir de vos agents Amazon MQ. Le groupe de consommateurs est créé avec le même ID qu’un mappage de source d’événements UUID.
Pour les sources d’événements Amazon MQ, Lambda réunit les enregistrements par lots et les envoie à votre fonction dans une seule charge utile. Pour contrôler le comportement, vous pouvez configurer la fenêtre de traitement par lots et la taille du lot. Lambda extrait les messages jusqu’à ce qu’il traite la taille maximale de la charge utile de 6 Mo, que la fenêtre de traitement par lots expire ou que le nombre d’enregistrements atteigne la taille totale du lot. Pour de plus amples informations, veuillez consulter [Comportement de traitement par lots](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching).
Le groupe de consommateurs récupère les messages sous forme de BLOB d’octets, puis les code en base64 dans une charge unique JSON puis invoque votre fonction. Si votre fonction renvoie une erreur pour l’un des messages d’un lot, Lambda réessaie le lot de messages complet jusqu’à ce que le traitement réussisse ou que les messages expirent.
**Note**
Alors que les fonctions Lambda ont généralement un délai d’expiration maximal de 15 minutes, les mappages des sources d’événement pour Amazon MSK, Apache Kafka autogéré, Amazon DocumentDB et Amazon MQ pour ActiveMQ et RabbitMQ ne prennent en charge que les fonctions dont le délai d’expiration maximal est de 14 minutes. Cette contrainte garantit que le mappage des sources d’événements peut gérer correctement les erreurs de fonction et effectuer de nouvelles tentatives.
Vous pouvez surveiller l'utilisation simultanée d'une fonction donnée à l'aide de la `ConcurrentExecutions` métrique d'Amazon CloudWatch. Pour de plus amples informations sur la simultanéité, consultez [Configuration de la simultanéité réservée pour une fonction](configuration-concurrency.md).
**Example Événements d’enregistrement Amazon MQ**
```
{
"eventSource": "aws:mq",
"eventSourceArn": "arn:aws:mq:us-east-2:111122223333:broker:test:b-9bcfa592-423a-4942-879d-eb284b418fc8",
"messages": [
{
"messageID": "ID:b-9bcfa592-423a-4942-879d-eb284b418fc8-1---mq---us-east-2.amazonaws.com.rproxy.goskope.com-37557-1234520418293-4:1:1:1:1",
"messageType": "jms/text-message",
"deliveryMode": 1,
"replyTo": null,
"type": null,
"expiration": "60000",
"priority": 1,
"correlationId": "myJMSCoID",
"redelivered": false,
"destination": {
"physicalName": "testQueue"
},
"data":"QUJDOkFBQUE=",
"timestamp": 1598827811958,
"brokerInTime": 1598827811958,
"brokerOutTime": 1598827811959,
"properties": {
"index": "1",
"doAlarm": "false",
"myCustomProperty": "value"
}
},
{
"messageID": "ID:b-9bcfa592-423a-4942-879d-eb284b418fc8-1---mq---us-east-2.amazonaws.com.rproxy.goskope.com-37557-1234520418293-4:1:1:1:1",
"messageType": "jms/bytes-message",
"deliveryMode": 1,
"replyTo": null,
"type": null,
"expiration": "60000",
"priority": 2,
"correlationId": "myJMSCoID1",
"redelivered": false,
"destination": {
"physicalName": "testQueue"
},
"data":"LQaGQ82S48k=",
"timestamp": 1598827811958,
"brokerInTime": 1598827811958,
"brokerOutTime": 1598827811959,
"properties": {
"index": "1",
"doAlarm": "false",
"myCustomProperty": "value"
}
}
]
}
```
```
{
"eventSource": "aws:rmq",
"eventSourceArn": "arn:aws:mq:us-east-2:111122223333:broker:pizzaBroker:b-9bcfa592-423a-4942-879d-eb284b418fc8",
"rmqMessagesByQueue": {
"pizzaQueue::/": [
{
"basicProperties": {
"contentType": "text/plain",
"contentEncoding": null,
"headers": {
"header1": {
"bytes": [
118,
97,
108,
117,
101,
49
]
},
"header2": {
"bytes": [
118,
97,
108,
117,
101,
50
]
},
"numberInHeader": 10
},
"deliveryMode": 1,
"priority": 34,
"correlationId": null,
"replyTo": null,
"expiration": "60000",
"messageId": null,
"timestamp": "Jan 1, 1970, 12:33:41 AM",
"type": null,
"userId": "AIDACKCEVSQ6C2EXAMPLE",
"appId": null,
"clusterId": null,
"bodySize": 80
},
"redelivered": false,
"data": "eyJ0aW1lb3V0IjowLCJkYXRhIjoiQ1pybWYwR3c4T3Y0YnFMUXhENEUifQ=="
}
]
}
}
```
Dans l’exemple RabbitMQ, `pizzaQueue` est le nom de la file d’attente RabbitMQ, et `/` est le nom de l’hôte virtuel. Lors de la réception de messages, la source d’événement répertorie les messages sous `pizzaQueue::/`.
# Configuration de source d’événements Amazon MQ pour Lambda
**Topics**
+ [Configurer la sécurité réseau](#process-mq-messages-with-lambda-networkconfiguration)
+ [Créer le mappage des sources d’événements](#services-mq-eventsourcemapping)
## Configurer la sécurité réseau
Pour donner à Lambda un accès complet à Amazon MQ via votre mappage des sources d’événements, soit votre agent doit utiliser un point de terminaison public (adresse IP publique), soit vous devez fournir un accès au VPC Amazon dans lequel vous avez créé l’agent.
Lorsque vous utilisez Amazon MQ avec Lambda, créez des [points de terminaison de VPC AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) qui permettent à votre fonction d’accéder aux ressources de votre Amazon VPC.
**Note**
AWS PrivateLink Les points de terminaison VPC sont requis pour les fonctions avec des mappages de sources d'événements qui utilisent le mode par défaut (à la demande) pour les sondeurs d'événements. Si le mappage de votre source d'événements utilise le [mode provisionné](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode), vous n'avez pas besoin de configurer les points de terminaison AWS PrivateLink VPC.
Créez un point de terminaison pour accéder aux ressources suivantes :
+ Lambda — Créez un point de terminaison pour le principal de service Lambda.
+ AWS STS — Créez un point de terminaison pour le AWS STS afin qu'un directeur de service assume un rôle en votre nom.
+ Secrets Manager : si votre agent utilise Secrets Manager pour stocker les informations d’identification, créez un point de terminaison pour Secrets Manager.
Vous pouvez également configurer une passerelle NAT sur chaque sous-réseau public d’Amazon VPC. Pour de plus amples informations, veuillez consulter [Activation de l’accès Internet pour les fonctions Lambda connectées à un VPC](configuration-vpc-internet.md).
Lorsque vous créez un mappage de sources d'événements pour Amazon MQ, Lambda vérifie si des interfaces réseau élastiques (ENIs) sont déjà présentes pour les sous-réseaux et les groupes de sécurité configurés pour votre Amazon VPC. Si Lambda trouve des objets existants ENIs, il essaie de les réutiliser. Sinon, Lambda en crée un nouveau ENIs pour se connecter à la source de l'événement et appeler votre fonction.
**Note**
Les fonctions Lambda s'exécutent toujours au sein VPCs du service Lambda. La configuration VPC de votre fonction n’affecte pas le mappage des sources d’événements. Seule la configuration réseau des sources d’événements détermine la manière dont Lambda se connecte à votre source d’événements.
Configurez les groupes de sécurité pour le VPC Amazon contenant votre agent. Par défaut, Amazon MQ utilise les ports suivants : `61617` (Amazon MQ pour ActiveMQ) `5671` et (Amazon MQ pour RabbitMQ).
+ Règles entrantes – Autorisent tout le trafic sur le port de l’agent par défaut pour le groupe de sécurité associé à votre source d’événement. Vous pouvez également utiliser une règle de groupe de sécurité avec référence circulaire pour autoriser l’accès à partir d’instances appartenant au même groupe de sécurité.
+ Règles de sortie : autorisez tout le trafic sur le port `443` pour les destinations externes si votre fonction doit communiquer avec les AWS services. Vous pouvez également utiliser une règle de groupe de sécurité à référencement automatique pour limiter l'accès au courtier si vous n'avez pas besoin de communiquer avec d'autres AWS services.
+ Règles entrantes relatives au point de terminaison Amazon VPC – Si vous utilisez un point de terminaison Amazon VPC, le groupe de sécurité associé à votre point de terminaison Amazon VPC doit autoriser le trafic entrant sur le port `443` en provenance du groupe de sécurité de l’agent.
Si votre agent utilise l’authentification, vous pouvez également restreindre la politique de point de terminaison pour le point de terminaison Secrets Manager. Pour appeler l’API Secrets Manager, Lambda utilise votre rôle de fonction, et non le principal de service Lambda.
**Example Politique de point de terminaison de VPC — Point de terminaison 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"
}
]
}
```
Lorsque vous utilisez des points de terminaison Amazon VPC, AWS achemine vos appels d'API pour appeler votre fonction à l'aide de l'Elastic Network Interface (ENI) du point de terminaison. Le directeur du service Lambda doit faire appel à tous `lambda:InvokeFunction` les rôles et fonctions qui les utilisent. ENIs
Par défaut, les points de terminaison Amazon VPC disposent de politiques IAM ouvertes qui permettent un accès étendu aux ressources. La meilleure pratique consiste à restreindre ces politiques pour effectuer les actions nécessaires à l’aide de ce point de terminaison. Pour garantir que votre mappage des sources d’événements est en mesure d’invoquer votre fonction Lambda, la politique de point de terminaison de VPC doit autoriser le principal de service Lambda à appeler `sts:AssumeRole` et `lambda:InvokeFunction`. Le fait de restreindre vos politiques de point de terminaison de VPC pour autoriser uniquement les appels d’API provenant de votre organisation empêche le mappage des sources d’événements de fonctionner correctement. C’est pourquoi `"Resource": "*"` est requis dans ces politiques.
Les exemples de politiques de point de terminaison de VPC suivants montrent comment accorder l’accès requis au principal de service Lambda pour les points de terminaison AWS STS et Lambda.
**Example Politique de point de terminaison VPC — point de terminaison AWS STS**
```
{
"Statement": [
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
**Example Politique de point de terminaison de VPC — Point de terminaison Lambda**
```
{
"Statement": [
{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
## Créer le mappage des sources d’événements
Créez un [mappage de source d’événement](invocation-eventsourcemapping.md) pour indiquer à Lambda d’envoyer des enregistrements d’un agent Amazon MQ à une fonction Lambda. Vous pouvez créer plusieurs mappages de source d’événement pour traiter les mêmes données avec plusieurs fonctions, ou pour traiter des éléments à partir de plusieurs sources avec une seule fonction.
Pour configurer votre fonction afin qu’elle lise à partir d’Amazon MQ, ajoutez les autorisations requises et créez un déclencheur **MQ** dans la console Lambda.
Pour lire les enregistrements d’un agent Amazon MQ, votre fonction Lambda a besoin des autorisations suivantes. Vous autorisez Lambda à interagir avec votre agent Amazon MQ et ses ressources sous-jacentes en ajoutant des déclarations d’autorisation à votre rôle d’[exécution de fonction](lambda-intro-execution-role.md) :
+ [mq : DescribeBroker](https://docs.aws.amazon.com/amazon-mq/latest/api-reference/brokers-broker-id.html#brokers-broker-id-http-methods)
+ [responsable des secrets : GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html)
+ [EC2 : CreateNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateNetworkInterface.html)
+ [EC2 : DeleteNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteNetworkInterface.html)
+ [EC2 : DescribeNetworkInterfaces](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeNetworkInterfaces.html)
+ [EC2 : DescribeSecurityGroups](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSecurityGroups.html)
+ [EC2 : DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html)
+ [EC2 : DescribeVpcs](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpcs.html)
+ [journaux : CreateLogGroup](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogGroup.html)
+ [journaux : CreateLogStream](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogStream.html)
+ [journaux : PutLogEvents](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html)
**Note**
Lorsque vous utilisez une clé gérée par le client chiffrée, ajoutez également l’autorisation `[kms:Decrypt](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-bootstrap-brokers.html#clusters-clusterarn-bootstrap-brokersget)`.
**Pour ajouter des autorisations et créer un déclencheur**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez le nom d’une fonction.
1. Choisissez l’onglet **Configuration**, puis **Permissions** (Autorisations).
1. Sous **Nom du rôle**, cliquez sur le lien vers votre rôle d’exécution. Ce lien ouvre le rôle dans la console IAM.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/execution-role.png)
1. Sélectionnez **Ajouter des autorisations**, puis **Ajouter la politique**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/inline-policy.png)
1. Dans l’**Éditeur de politique**, sélectionnez **JSON**. Saisissez la politique suivante. Votre fonction a besoin de ces autorisations pour lire à partir d’un agent Amazon MQ.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"mq:DescribeBroker",
"secretsmanager:GetSecretValue",
"ec2:CreateNetworkInterface",
"ec2:DeleteNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
```
------
**Note**
Lorsque vous utilisez une clé gérée par le client chiffrée, vous devez également ajouter l’autorisation `kms:Decrypt`.
1. Choisissez **Suivant**. Saisissez un nom de politique, puis choisissez **Créer une politique**.
1. Revenez à votre fonction dans la console Lambda. Sous **Function overview (Vue d’ensemble de la fonction)**, choisissez **Add trigger (Ajouter un déclencheur)**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/add-trigger.png)
1. Choisissez le type de déclencheur **MQ**.
1. Configurez les options requises, puis choisissez **Add (Ajouter)**.
Lambda prend en charge les options suivantes pour les sources d’événement Amazon MQ.
+ **MQ broker (Agent MQ)** – Sélectionnez un agent Amazon MQ.
+ **Batch size (Taille de lot)** – Définissez le nombre maximum de messages à extraire dans un lot.
+ **Queue name (Nom de file d’attente)** – Entrez la file d’attente Amazon MQ à consommer.
+ **Source access configuration (Configuration de l’accès source)** – Entrez les informations d’hôte virtuel et le secret Secrets Manager qui stocke vos informations d’identification d’agent.
+ **Enable trigger (Activer le déclencheur)** – Désactivez le déclencheur pour arrêter le traitement des enregistrements.
Pour activer ou désactiver le déclencheur (ou le supprimer), choisissez le déclencheur **MQ** dans le concepteur. Pour reconfigurer le déclencheur, utilisez les opérations d’API de mappage de source d’événement.
# Paramètres de mappage des sources d’événements
Tous les types de sources d’événement Lambda partagent les mêmes opérations d’API [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) et [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html). Cependant, seuls certains paramètres s’appliquent à Amazon MQ et à RabbitMQ.
| Paramètre | Obligatoire | Par défaut | Remarques |
| --- | --- | --- | --- |
| BatchSize | N | 100 | Maximum : 10 000. |
| Activé | N | VRAI | none |
| FunctionName | Y | N/A | none |
| FilterCriteria | N | N/A | [Contrôle des événements envoyés par Lambda à votre fonction](invocation-eventfiltering.md) |
| MaximumBatchingWindowInSeconds | N | 500 ms | [Comportement de traitement par lots](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching) |
| Files d’attente | N | N/A | Le nom de la file d’attente de destination de l’agent Amazon MQ à consommer. |
| SourceAccessConfigurations | N | N/A | Pour ActiveMQ, informations d’identification BASIC\$1AUTH. Pour RabbitMQ, il peut contenir à la fois des informations d’identification BASIC\$1AUTH et des informations VIRTUAL\$1HOST. |
# Filtrer les événement à partir d’une source d’événements Amazon MQ
Vous pouvez utiliser le filtrage d’événements pour contrôler les enregistrements d’un flux ou d’une file d’attente que Lambda envoie à votre fonction. Pour obtenir des informations générales sur le fonctionnement du filtrage des événements, consultez [Contrôle des événements envoyés par Lambda à votre fonction](invocation-eventfiltering.md).
Cette section porte sur le filtrage des événements pour les sources Amazon MQ.
**Note**
Les mappages des sources d’événements Amazon MQ prennent uniquement en charge le filtrage sur la clé `data`.
**Topics**
+ [Principes de base du filtrage des événements Amazon MQ](#filtering-AMQ)
## Principes de base du filtrage des événements Amazon MQ
Supposons que votre file d’attente de messages Amazon MQ contienne des messages au format JSON valide ou sous forme de chaînes simples. Un exemple d’enregistrement ressemblerait à ce qui suit, avec les données converties en chaîne encodée en Base64 dans le champ `data`.
------
#### [ ActiveMQ ]
```
{
"messageID": "ID:b-9bcfa592-423a-4942-879d-eb284b418fc8-1---mq---us-east-2.amazonaws.com.rproxy.goskope.com-37557-1234520418293-4:1:1:1:1",
"messageType": "jms/text-message",
"deliveryMode": 1,
"replyTo": null,
"type": null,
"expiration": "60000",
"priority": 1,
"correlationId": "myJMSCoID",
"redelivered": false,
"destination": {
"physicalName": "testQueue"
},
"data":"QUJDOkFBQUE=",
"timestamp": 1598827811958,
"brokerInTime": 1598827811958,
"brokerOutTime": 1598827811959,
"properties": {
"index": "1",
"doAlarm": "false",
"myCustomProperty": "value"
}
}
```
------
#### [ RabbitMQ ]
```
{
"basicProperties": {
"contentType": "text/plain",
"contentEncoding": null,
"headers": {
"header1": {
"bytes": [
118,
97,
108,
117,
101,
49
]
},
"header2": {
"bytes": [
118,
97,
108,
117,
101,
50
]
},
"numberInHeader": 10
},
"deliveryMode": 1,
"priority": 34,
"correlationId": null,
"replyTo": null,
"expiration": "60000",
"messageId": null,
"timestamp": "Jan 1, 1970, 12:33:41 AM",
"type": null,
"userId": "AIDACKCEVSQ6C2EXAMPLE",
"appId": null,
"clusterId": null,
"bodySize": 80
},
"redelivered": false,
"data": "eyJ0aW1lb3V0IjowLCJkYXRhIjoiQ1pybWYwR3c4T3Y0YnFMUXhENEUifQ=="
}
```
------
Pour les agents Active MQ et Rabbit MQ, vous pouvez utiliser le filtrage d’événements pour filtrer les enregistrements à l’aide de la clé `data`. Supposons que votre file d’attente Amazon MQ contienne des messages au format JSON suivant.
```
{
"timeout": 0,
"IPAddress": "203.0.113.254"
}
```
Pour filtrer uniquement les enregistrements dont le champ `timeout` est supérieur à 0, l’objet `FilterCriteria` serait le suivant.
```
{
"Filters": [
{
"Pattern": "{ \"data\" : { \"timeout\" : [ { \"numeric\": [ \">\", 0] } } ] } }"
}
]
}
```
Pour plus de clarté, voici la valeur du `Pattern` de filtre étendu en JSON simple :
```
{
"data": {
"timeout": [ { "numeric": [ ">", 0 ] } ]
}
}
```
Vous pouvez ajouter votre filtre à l’aide de la console, d’AWS CLI ou d’un modèle AWS SAM.
------
#### [ Console ]
pour ajouter ce filtre à l’aide de la console, suivez les instructions de [Attacher des critères de filtre à un mappage de sources d’événements (console)](invocation-eventfiltering.md#filtering-console) et saisissez la chaîne suivante comme **critère de filtre**.
```
{ "data" : { "timeout" : [ { "numeric": [ ">", 0 ] } ] } }
```
------
#### [ AWS CLI ]
Pour créer un nouveau mappage des sources d’événements avec ces critères de filtrage à l’aide de l’outil AWS Command Line Interface (AWS CLI), exécutez la commande suivante.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:mq:us-east-2:123456789012:broker:my-broker:b-8ac7cc01-5898-482d-be2f-a6b596050ea8 \
--filter-criteria '{"Filters": [{"Pattern": "{ \"data\" : { \"timeout\" : [ { \"numeric\": [ \">\", 0 ] } ] } }"}]}'
```
Pour ajouter ces critères de filtre à un mappage des sources d’événements existant, exécutez la commande suivante.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"data\" : { \"timeout\" : [ { \"numeric\": [ \">\", 0 ] } ] } }"}]}'
```
Pour ajouter ces critères de filtre à un mappage des sources d’événements existant, exécutez la commande suivante.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"data\" : { \"timeout\" : [ { \"numeric\": [ \">\", 0 ] } ] } }"}]}'
```
------
#### [ AWS SAM ]
Pour ajouter ce filtre à l’aide d’AWS SAM, ajoutez l’extrait suivant au modèle YAML de votre source d’événement.
```
FilterCriteria:
Filters:
- Pattern: '{ "data" : { "timeout" : [ { "numeric": [ ">", 0 ] } ] } }'
```
------
Avec Amazon MQ, vous pouvez également filtrer les enregistrements dont le message est une chaîne simple. Supposons que vous vouliez traiter uniquement les enregistrements dont le message commence par « Result: ». L’objet `FilterCriteria` se présente comme suit.
```
{
"Filters": [
{
"Pattern": "{ \"data\" : [ { \"prefix\": \"Result: \" } ] }"
}
]
}
```
Pour plus de clarté, voici la valeur du `Pattern` de filtre étendu en JSON simple :
```
{
"data": [
{
"prefix": "Result: "
}
]
}
```
Vous pouvez ajouter votre filtre à l’aide de la console, d’AWS CLI ou d’un modèle AWS SAM.
------
#### [ Console ]
Pour ajouter ce filtre à l’aide de la console, suivez les instructions de [Attacher des critères de filtre à un mappage de sources d’événements (console)](invocation-eventfiltering.md#filtering-console) et saisissez la chaîne suivante comme **critère de filtre**.
```
{ "data" : [ { "prefix": "Result: " } ] }
```
------
#### [ AWS CLI ]
Pour créer un nouveau mappage des sources d’événements avec ces critères de filtrage à l’aide de l’outil AWS Command Line Interface (AWS CLI), exécutez la commande suivante.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:mq:us-east-2:123456789012:broker:my-broker:b-8ac7cc01-5898-482d-be2f-a6b596050ea8 \
--filter-criteria '{"Filters": [{"Pattern": "{ \"data\" : [ { \"prefix\": \"Result: \" } ] }"}]}'
```
Pour ajouter ces critères de filtre à un mappage des sources d’événements existant, exécutez la commande suivante.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"data\" : [ { \"prefix\": \"Result: \" } ] }"}]}'
```
------
#### [ AWS SAM ]
Pour ajouter ce filtre à l’aide d’AWS SAM, ajoutez l’extrait suivant au modèle YAML de votre source d’événement.
```
FilterCriteria:
Filters:
- Pattern: '{ "data" : [ { "prefix": "Result " } ] }'
```
------
Les messages Amazon MQ doivent être des chaînes codées en UTF-8, soit des chaînes en texte brut, soit au format JSON. En effet, Lambda décode les tableaux d’octets Amazon MQ en UTF-8 avant d’appliquer des critères de filtre. Si vos messages utilisent un autre encodage, tel que UTF-16 ou ASCII, ou si le format du message ne correspond pas au format `FilterCriteria`, Lambda traite uniquement les filtres de métadonnées. Le tableau suivant résume le comportement spécifique :
| Format du du message entrant | Modèle de filtre de format pour les propriétés des messages | Action obtenue. |
| --- | --- | --- |
| Chaîne de texte brut | Chaîne de texte brut | Lambda filtre en fonction de vos critères de filtre. |
| Chaîne de texte brut | Pas de modèle de filtre pour les propriétés des données | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
| Chaîne de texte brut | JSON valide | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
| JSON valide | Chaîne de texte brut | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
| JSON valide | Pas de modèle de filtre pour les propriétés des données | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
| JSON valide | JSON valide | Lambda filtre en fonction de vos critères de filtre. |
| Chaîne non codée UTF-8 | JSON, chaîne de texte brut ou aucun modèle | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
# Résoudre les erreurs de mappage des sources d’événement Amazon MQ
Quand une fonction Lambda rencontre une erreur irrécupérable, votre consommateur Amazon MQ arrête le traitement des enregistrements. D’autres consommateurs peuvent continuer le traitement, à condition qu’ils ne rencontrent pas la même erreur. Pour déterminer la cause potentielle d’un consommateur arrêté, vérifiez le champ `StateTransitionReason` dans les détails de retour de votre `EventSourceMapping` pour l’un des codes suivants :
**`ESM_CONFIG_NOT_VALID`**
La configuration de mappage de source d’événement n’est pas valide.
**`EVENT_SOURCE_AUTHN_ERROR`**
Lambda n’a pas réussi à authentifier la source de l’événement.
**`EVENT_SOURCE_AUTHZ_ERROR`**
Lambda ne dispose pas des autorisations requises pour accéder à la source d’événement.
**`FUNCTION_CONFIG_NOT_VALID`**
La configuration de la fonction n’est pas valide.
Les enregistrements ne sont pas non plus traités si Lambda les abandonne en raison de leur taille. La taille limite pour les enregistrements Lambda est de 6 Mo. Pour relivrer des messages en cas d’erreur de fonction, vous pouvez utiliser une file d’attente de lettres mortes (DLQ). Pour plus d’informations, consultez [Message Redelivery and DLQ Handling (Relivraison des messages et gestion des DLQ)](https://activemq.apache.org/message-redelivery-and-dlq-handling), et le [Guide de fiabilité](https://www.rabbitmq.com/reliability.html) sur le site web RabbitMQ.
**Note**
Lambda ne prend pas en charge les stratégies de relivraison personnalisées. Au lieu de cela, Lambda utilise une stratégie avec les valeurs par défaut de la page [Stratégie de relivraison](https://activemq.apache.org/redelivery-policy) sur le site web d’Apache ActiveMQ, avec `maximumRedeliveries` défini sur 6.
# Utilisation AWS Lambda avec Amazon RDS
Vous pouvez connecter une fonction Lambda à une base de données Amazon Relational Database Service (Amazon RDS) directement via un proxy Amazon RDS. Les connexions directes sont utiles dans les scénarios simples, et les proxys sont recommandés pour la production. Un proxy de base de données gère un groupe de connexions partagées à la base de données qui permet à votre fonction d’atteindre des niveaux de simultanéité élevés sans épuiser les connexions de base de données.
Nous recommandons d’utiliser Proxy Amazon RDS pour les fonctions Lambda qui effectuent fréquemment de brèves connexions à la base de données, ou qui ouvrent et ferment un grand nombre de connexions à la base de données. Pour de plus amples informations, veuillez consulter la rubrique [Automatically connecting a Lambda function and a DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/lambda-rds-connect.html) du Guide du développeur Amazon Relational Database Service.
**Astuce**
Pour connecter rapidement une fonction Lambda à une base de données Amazon RDS, vous pouvez utiliser l’assistant guidé intégré à la console. Procédez comme suit pour ouvrir l’assistant :
Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
Sélectionnez la fonction à laquelle vous souhaitez connecter une base de données.
Dans l’onglet **Configuration**, sélectionnez **Bases de données RDS**.
Choisissez **Se connecter à la base de données RDS**.
Après avoir connecté votre fonction à une base de données, vous pouvez créer un proxy en choisissant **Ajouter un proxy**.
## Configuration de votre fonction pour qu’elle fonctionne avec les ressources RDS
Dans la console Lambda, vous pouvez allouer et configurer des instances de base de données et des ressources de proxy Amazon RDS. Vous pouvez le faire en accédant aux **Bases de données RDS** sous l’onglet **Configuration**. Vous pouvez également créer et configurer des connexions aux fonctions Lambda dans la console Amazon RDS. Lorsque vous configurez une instance de base de données RDS à utiliser avec Lambda, tenez compte des critères suivants :
+ Pour se connecter à une base de données, votre fonction doit résider dans le même Amazon VPC où votre base de données s’exécute.
+ Vous pouvez utiliser les bases de données Amazon RDS avec les moteurs MySQL, MariaDB, PostgreSQL ou Microsoft SQL Server.
+ Vous pouvez également utiliser des clusters de base de données Aurora avec des moteurs MySQL ou PostgreSQL.
+ Vous devez fournir un secret Secrets Manager pour l’authentification de la base de données.
+ Un rôle IAM doit autoriser l’utilisation du secret et une stratégie d’approbation doit autoriser Amazon RDS à endosser le rôle.
+ Le principal IAM qui utilise la console pour configurer la ressource Amazon RDS et la connecter à votre fonction doit disposer des autorisations suivantes :
### Exemple de politique d’autorisations
**Note**
Vous n’avez besoin des autorisations de Proxy Amazon RDS que si vous configurez un Proxy Amazon RDS pour gérer un pool de connexions à votre base de données.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateSecurityGroup",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:RevokeSecurityGroupEgress",
"ec2:CreateNetworkInterface",
"ec2:DeleteNetworkInterface",
"ec2:DescribeNetworkInterfaces"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"rds-db:connect",
"rds:CreateDBProxy",
"rds:CreateDBInstance",
"rds:CreateDBSubnetGroup",
"rds:DescribeDBClusters",
"rds:DescribeDBInstances",
"rds:DescribeDBSubnetGroups",
"rds:DescribeDBProxies",
"rds:DescribeDBProxyTargets",
"rds:DescribeDBProxyTargetGroups",
"rds:RegisterDBProxyTargets",
"rds:ModifyDBInstance",
"rds:ModifyDBProxy"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"lambda:CreateFunction",
"lambda:ListFunctions",
"lambda:UpdateFunctionConfiguration"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:CreateRole",
"iam:CreatePolicy"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetResourcePolicy",
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret",
"secretsmanager:ListSecretVersionIds",
"secretsmanager:CreateSecret"
],
"Resource": "*"
}
]
}
```
------
Amazon RDS facture un tarif horaire pour les proxys en fonction de la taille de l’instance de base de données. Consultez la [tarification des proxys RDS](https://aws.amazon.com/rds/proxy/pricing/) pour plus de détails. Pour plus d’informations sur les connexions de proxy en général, consultez [Utilisation de Proxy Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) dans le Guide de l’utilisateur Amazon RDS.
### Exigences SSL/TLS pour les connexions Amazon RDS
Pour établir des SSL/TLS connexions sécurisées à une instance de base de données Amazon RDS, votre fonction Lambda doit vérifier l'identité du serveur de base de données à l'aide d'un certificat sécurisé. Lambda gère ces certificats différemment selon le type de package de déploiement :
+ [Archives .zip](configuration-function-zip.md) : la gestion des certificats varie en fonction de l’environnement d’exécution :
+ **Node.js 18 et versions antérieures** : Lambda inclut automatiquement les certificats CA et RDS.
+ **Node.js 20 et versions ultérieures** : Lambda ne charge plus de certificats CA supplémentaires par défaut. Définissez la variable d'environnement `NODE_EXTRA_CA_CERTS` sur `/var/runtime/ca-cert.pem`.
L'ajout de nouveaux certificats Amazon RDS aux environnements d'exécution gérés par Lambda peut Régions AWS prendre jusqu'à 4 semaines.
+ [Images de conteneur](images-create.md) : les images AWS de base incluent uniquement les certificats CA. Si votre fonction se connecte à une instance de base de données Amazon RDS, vous devez inclure les certificats appropriés dans votre image de conteneur. Dans votre Dockerfile, téléchargez le [bundle de certificats correspondant à l' Région AWS endroit où vous hébergez votre](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html#UsingWithRDS.SSL.CertificatesDownload) base de données. Exemple :
```
RUN curl https://truststore.pki.rds.amazonaws.com/us-east-1/us-east-1-bundle.pem -o /us-east-1-bundle.pem
```
Cette commande télécharge le bundle de certificats Amazon RDS et l’enregistre sur le chemin absolu `/us-east-1-bundle.pem` dans le répertoire racine de votre conteneur. Lorsque vous configurez la connexion à la base de données dans le code de votre fonction, vous devez référencer ce chemin exact. Exemple :
------
#### [ Node.js ]
La fonction `readFileSync` est requise, car les clients de base de données Node.js ont besoin du contenu réel du certificat en mémoire, et pas seulement du chemin d’accès au fichier de certificat. Sans `readFileSync`, le client interprète la chaîne de chemin comme le contenu du certificat, ce qui entraîne une erreur « certificat autosigné dans la chaîne de certificats ».
**Example Configuration de la connexion pour la fonction OCI Node.js**
```
import { readFileSync } from 'fs';
// ...
let connectionConfig = {
host: process.env.ProxyHostName,
user: process.env.DBUserName,
password: token,
database: process.env.DBName,
ssl: {
ca: readFileSync('/us-east-1-bundle.pem') // Load RDS certificate content from file into memory
}
};
```
------
#### [ Python ]
**Example Configuration de la connexion pour la fonction OCI Python**
```
connection = pymysql.connect(
host=proxy_host_name,
user=db_username,
password=token,
db=db_name,
port=port,
ssl={'ca': '/us-east-1-bundle.pem'} #Path to the certificate in container
)
```
------
#### [ Java ]
Pour les fonctions Java utilisant des connexions JDBC, la chaîne de connexion doit inclure :
+ `useSSL=true`
+ `requireSSL=true`
+ Paramètre `sslCA` indiquant l’emplacement du certificat Amazon RDS dans l’image de conteneur
**Example Chaîne de connexion pour la fonction OCI Java**
```
// Define connection string
String connectionString = String.format("jdbc:mysql://%s:%s/%s?useSSL=true&requireSSL=true&sslCA=/us-east-1-bundle.pem", // Path to the certificate in container
System.getenv("ProxyHostName"),
System.getenv("Port"),
System.getenv("DBName"));
```
------
#### [ .NET ]
**Example Chaîne de connexion pour la connexion MySQL dans la fonction OCI .NET**
```
/// Build the Connection String with the Token
string connectionString = $"Server={Environment.GetEnvironmentVariable("RDS_ENDPOINT")};" +
$"Port={Environment.GetEnvironmentVariable("RDS_PORT")};" +
$"Uid={Environment.GetEnvironmentVariable("RDS_USERNAME")};" +
$"Pwd={authToken};" +
"SslMode=Required;" +
"SslCa=/us-east-1-bundle.pem"; // Path to the certificate in container
```
------
#### [ Go ]
Pour les fonctions Go utilisant des connexions MySQL, chargez le certificat Amazon RDS dans un groupe de certificats et enregistrez-le avec le pilote MySQL. La chaîne de connexion doit ensuite référencer cette configuration à l’aide du paramètre `tls`.
**Example Code Go pour la connexion MySQL dans la fonction OCI**
```
import (
"crypto/tls"
"crypto/x509"
"os"
"github.com/go-sql-driver/mysql"
)
...
// Create certificate pool and register TLS config
rootCertPool := x509.NewCertPool()
pem, err := os.ReadFile("/us-east-1-bundle.pem") // Path to the certificate in container
if err != nil {
panic("failed to read certificate file: " + err.Error())
}
if ok := rootCertPool.AppendCertsFromPEM(pem); !ok {
panic("failed to append PEM")
}
mysql.RegisterTLSConfig("custom", &tls.Config{
RootCAs: rootCertPool,
})
dsn := fmt.Sprintf("%s:%s@tcp(%s)/%s?allowCleartextPasswords=true&tls=custom",
dbUser, authenticationToken, dbEndpoint, dbName,
)
```
------
#### [ Ruby ]
**Example Configuration de connexion Ruby pour la fonction OCI**
```
conn = Mysql2::Client.new(
host: endpoint,
username: user,
password: token,
port: port,
database: db_name,
sslca: '/us-east-1-bundle.pem', # Path to the certificate in container
sslverify: true
)
```
------
## Connexion à une base de données Amazon RDS dans une fonction Lambda
L’exemple de code suivant illustre comment implémenter une fonction Lambda qui se connecte à une base de données Amazon RDS. La fonction effectue une simple requête de base de données et renvoie le résultat.
**Note**
Ces exemples de code ne sont valides que pour les [packages de déploiement .zip](configuration-function-zip.md). Si vous déployez votre fonction à l’aide d’une [image de conteneur](images-create.md), vous devez spécifier le fichier de certificat Amazon RDS dans le code de votre fonction, comme expliqué dans la [section précédente](#oci-certificate).
------
#### [ .NET ]
**SDK pour .NET**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-connect-rds-iam).
Connexion à une base de données Amazon RDS dans une fonction Lambda à l’aide de .NET.
```
using System.Data;
using System.Text.Json;
using Amazon.Lambda.APIGatewayEvents;
using Amazon.Lambda.Core;
using MySql.Data.MySqlClient;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace aws_rds;
public class InputModel
{
public string key1 { get; set; }
public string key2 { get; set; }
}
public class Function
{
///
// Handles the Lambda function execution for connecting to RDS using IAM authentication.
///
/// The input event data passed to the Lambda function
/// The Lambda execution context that provides runtime information
/// A response object containing the execution result
public async Task FunctionHandler(APIGatewayProxyRequest request, ILambdaContext context)
{
// Sample Input: {"body": "{\"key1\":\"20\", \"key2\":\"25\"}"}
var input = JsonSerializer.Deserialize(request.Body);
/// Obtain authentication token
var authToken = RDSAuthTokenGenerator.GenerateAuthToken(
Environment.GetEnvironmentVariable("RDS_ENDPOINT"),
Convert.ToInt32(Environment.GetEnvironmentVariable("RDS_PORT")),
Environment.GetEnvironmentVariable("RDS_USERNAME")
);
/// Build the Connection String with the Token
string connectionString = $"Server={Environment.GetEnvironmentVariable("RDS_ENDPOINT")};" +
$"Port={Environment.GetEnvironmentVariable("RDS_PORT")};" +
$"Uid={Environment.GetEnvironmentVariable("RDS_USERNAME")};" +
$"Pwd={authToken};";
try
{
await using var connection = new MySqlConnection(connectionString);
await connection.OpenAsync();
const string sql = "SELECT @param1 + @param2 AS Sum";
await using var command = new MySqlCommand(sql, connection);
command.Parameters.AddWithValue("@param1", int.Parse(input.key1 ?? "0"));
command.Parameters.AddWithValue("@param2", int.Parse(input.key2 ?? "0"));
await using var reader = await command.ExecuteReaderAsync();
if (await reader.ReadAsync())
{
int result = reader.GetInt32("Sum");
//Sample Response: {"statusCode":200,"body":"{\"message\":\"The sum is: 45\"}","isBase64Encoded":false}
return new APIGatewayProxyResponse
{
StatusCode = 200,
Body = JsonSerializer.Serialize(new { message = $"The sum is: {result}" })
};
}
}
catch (Exception ex)
{
Console.WriteLine($"Error: {ex.Message}");
}
return new APIGatewayProxyResponse
{
StatusCode = 500,
Body = JsonSerializer.Serialize(new { error = "Internal server error" })
};
}
}
```
------
#### [ Go ]
**Kit SDK pour Go V2**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-connect-rds-iam).
Connexion à une base de données Amazon RDS dans une fonction Lambda à l’aide de Go.
```
/*
Golang v2 code here.
*/
package main
import (
"context"
"database/sql"
"encoding/json"
"fmt"
"os"
"github.com/aws/aws-lambda-go/lambda"
"github.com/aws/aws-sdk-go-v2/config"
"github.com/aws/aws-sdk-go-v2/feature/rds/auth"
_ "github.com/go-sql-driver/mysql"
)
type MyEvent struct {
Name string `json:"name"`
}
func HandleRequest(event *MyEvent) (map[string]interface{}, error) {
var dbName string = os.Getenv("DatabaseName")
var dbUser string = os.Getenv("DatabaseUser")
var dbHost string = os.Getenv("DBHost") // Add hostname without https
var dbPort int = os.Getenv("Port") // Add port number
var dbEndpoint string = fmt.Sprintf("%s:%d", dbHost, dbPort)
var region string = os.Getenv("AWS_REGION")
cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
panic("configuration error: " + err.Error())
}
authenticationToken, err := auth.BuildAuthToken(
context.TODO(), dbEndpoint, region, dbUser, cfg.Credentials)
if err != nil {
panic("failed to create authentication token: " + err.Error())
}
dsn := fmt.Sprintf("%s:%s@tcp(%s)/%s?tls=true&allowCleartextPasswords=true",
dbUser, authenticationToken, dbEndpoint, dbName,
)
db, err := sql.Open("mysql", dsn)
if err != nil {
panic(err)
}
defer db.Close()
var sum int
err = db.QueryRow("SELECT ?+? AS sum", 3, 2).Scan(&sum)
if err != nil {
panic(err)
}
s := fmt.Sprint(sum)
message := fmt.Sprintf("The selected sum is: %s", s)
messageBytes, err := json.Marshal(message)
if err != nil {
return nil, err
}
messageString := string(messageBytes)
return map[string]interface{}{
"statusCode": 200,
"headers": map[string]string{"Content-Type": "application/json"},
"body": messageString,
}, nil
}
func main() {
lambda.Start(HandleRequest)
}
```
------
#### [ Java ]
**SDK pour Java 2.x**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-connect-rds-iam).
Connexion à une base de données Amazon RDS dans une fonction Lambda à l’aide de Java.
```
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyRequestEvent;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyResponseEvent;
import software.amazon.awssdk.auth.credentials.DefaultCredentialsProvider;
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.rdsdata.RdsDataClient;
import software.amazon.awssdk.services.rdsdata.model.ExecuteStatementRequest;
import software.amazon.awssdk.services.rdsdata.model.ExecuteStatementResponse;
import software.amazon.awssdk.services.rdsdata.model.Field;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
public class RdsLambdaHandler implements RequestHandler {
@Override
public APIGatewayProxyResponseEvent handleRequest(APIGatewayProxyRequestEvent event, Context context) {
APIGatewayProxyResponseEvent response = new APIGatewayProxyResponseEvent();
try {
// Obtain auth token
String token = createAuthToken();
// Define connection configuration
String connectionString = String.format("jdbc:mysql://%s:%s/%s?useSSL=true&requireSSL=true",
System.getenv("ProxyHostName"),
System.getenv("Port"),
System.getenv("DBName"));
// Establish a connection to the database
try (Connection connection = DriverManager.getConnection(connectionString, System.getenv("DBUserName"), token);
PreparedStatement statement = connection.prepareStatement("SELECT ? + ? AS sum")) {
statement.setInt(1, 3);
statement.setInt(2, 2);
try (ResultSet resultSet = statement.executeQuery()) {
if (resultSet.next()) {
int sum = resultSet.getInt("sum");
response.setStatusCode(200);
response.setBody("The selected sum is: " + sum);
}
}
}
} catch (Exception e) {
response.setStatusCode(500);
response.setBody("Error: " + e.getMessage());
}
return response;
}
private String createAuthToken() {
// Create RDS Data Service client
RdsDataClient rdsDataClient = RdsDataClient.builder()
.region(Region.of(System.getenv("AWS_REGION")))
.credentialsProvider(DefaultCredentialsProvider.create())
.build();
// Define authentication request
ExecuteStatementRequest request = ExecuteStatementRequest.builder()
.resourceArn(System.getenv("ProxyHostName"))
.secretArn(System.getenv("DBUserName"))
.database(System.getenv("DBName"))
.sql("SELECT 'RDS IAM Authentication'")
.build();
// Execute request and obtain authentication token
ExecuteStatementResponse response = rdsDataClient.executeStatement(request);
Field tokenField = response.records().get(0).get(0);
return tokenField.stringValue();
}
}
```
------
#### [ JavaScript ]
**SDK pour JavaScript (v3)**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-connect-rds-iam).
Connexion à une base de données Amazon RDS dans une fonction Lambda à l'aide de. JavaScript
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
/*
Node.js code here.
*/
// ES6+ example
import { Signer } from "@aws-sdk/rds-signer";
import mysql from 'mysql2/promise';
async function createAuthToken() {
// Define connection authentication parameters
const dbinfo = {
hostname: process.env.ProxyHostName,
port: process.env.Port,
username: process.env.DBUserName,
region: process.env.AWS_REGION,
}
// Create RDS Signer object
const signer = new Signer(dbinfo);
// Request authorization token from RDS, specifying the username
const token = await signer.getAuthToken();
return token;
}
async function dbOps() {
// Obtain auth token
const token = await createAuthToken();
// Define connection configuration
let connectionConfig = {
host: process.env.ProxyHostName,
user: process.env.DBUserName,
password: token,
database: process.env.DBName,
ssl: 'Amazon RDS'
}
// Create the connection to the DB
const conn = await mysql.createConnection(connectionConfig);
// Obtain the result of the query
const [res,] = await conn.execute('select ?+? as sum', [3, 2]);
return res;
}
export const handler = async (event) => {
// Execute database flow
const result = await dbOps();
// Return result
return {
statusCode: 200,
body: JSON.stringify("The selected sum is: " + result[0].sum)
}
};
```
Connexion à une base de données Amazon RDS dans une fonction Lambda à l'aide de. TypeScript
```
import { Signer } from "@aws-sdk/rds-signer";
import mysql from 'mysql2/promise';
// RDS settings
// Using '!' (non-null assertion operator) to tell the TypeScript compiler that the DB settings are not null or undefined,
const proxy_host_name = process.env.PROXY_HOST_NAME!
const port = parseInt(process.env.PORT!)
const db_name = process.env.DB_NAME!
const db_user_name = process.env.DB_USER_NAME!
const aws_region = process.env.AWS_REGION!
async function createAuthToken(): Promise {
// Create RDS Signer object
const signer = new Signer({
hostname: proxy_host_name,
port: port,
region: aws_region,
username: db_user_name
});
// Request authorization token from RDS, specifying the username
const token = await signer.getAuthToken();
return token;
}
async function dbOps(): Promise {
try {
// Obtain auth token
const token = await createAuthToken();
const conn = await mysql.createConnection({
host: proxy_host_name,
user: db_user_name,
password: token,
database: db_name,
ssl: 'Amazon RDS' // Ensure you have the CA bundle for SSL connection
});
const [rows, fields] = await conn.execute('SELECT ? + ? AS sum', [3, 2]);
console.log('result:', rows);
return rows;
}
catch (err) {
console.log(err);
}
}
export const lambdaHandler = async (event: any): Promise<{ statusCode: number; body: string }> => {
// Execute database flow
const result = await dbOps();
// Return error is result is undefined
if (result == undefined)
return {
statusCode: 500,
body: JSON.stringify(`Error with connection to DB host`)
}
// Return result
return {
statusCode: 200,
body: JSON.stringify(`The selected sum is: ${result[0].sum}`)
};
};
```
------
#### [ PHP ]
**Kit SDK pour PHP**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-connect-rds-iam).
Connexion à une base de données Amazon RDS dans une fonction Lambda à l’aide de PHP.
```
logger = $logger;
}
private function getAuthToken(): string {
// Define connection authentication parameters
$dbConnection = [
'hostname' => getenv('DB_HOSTNAME'),
'port' => getenv('DB_PORT'),
'username' => getenv('DB_USERNAME'),
'region' => getenv('AWS_REGION'),
];
// Create RDS AuthTokenGenerator object
$generator = new AuthTokenGenerator(CredentialProvider::defaultProvider());
// Request authorization token from RDS, specifying the username
return $generator->createToken(
$dbConnection['hostname'] . ':' . $dbConnection['port'],
$dbConnection['region'],
$dbConnection['username']
);
}
private function getQueryResults() {
// Obtain auth token
$token = $this->getAuthToken();
// Define connection configuration
$connectionConfig = [
'host' => getenv('DB_HOSTNAME'),
'user' => getenv('DB_USERNAME'),
'password' => $token,
'database' => getenv('DB_NAME'),
];
// Create the connection to the DB
$conn = new PDO(
"mysql:host={$connectionConfig['host']};dbname={$connectionConfig['database']}",
$connectionConfig['user'],
$connectionConfig['password'],
[
PDO::MYSQL_ATTR_SSL_CA => '/path/to/rds-ca-2019-root.pem',
PDO::MYSQL_ATTR_SSL_VERIFY_SERVER_CERT => true,
]
);
// Obtain the result of the query
$stmt = $conn->prepare('SELECT ?+? AS sum');
$stmt->execute([3, 2]);
return $stmt->fetch(PDO::FETCH_ASSOC);
}
/**
* @param mixed $event
* @param Context $context
* @return array
*/
public function handle(mixed $event, Context $context): array
{
$this->logger->info("Processing query");
// Execute database flow
$result = $this->getQueryResults();
return [
'sum' => $result['sum']
];
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**Kit SDK for Python (Boto3)**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-connect-rds-iam).
Connexion à une base de données Amazon RDS dans une fonction Lambda à l’aide de Python.
```
import json
import os
import boto3
import pymysql
# RDS settings
proxy_host_name = os.environ['PROXY_HOST_NAME']
port = int(os.environ['PORT'])
db_name = os.environ['DB_NAME']
db_user_name = os.environ['DB_USER_NAME']
aws_region = os.environ['AWS_REGION']
# Fetch RDS Auth Token
def get_auth_token():
client = boto3.client('rds')
token = client.generate_db_auth_token(
DBHostname=proxy_host_name,
Port=port
DBUsername=db_user_name
Region=aws_region
)
return token
def lambda_handler(event, context):
token = get_auth_token()
try:
connection = pymysql.connect(
host=proxy_host_name,
user=db_user_name,
password=token,
db=db_name,
port=port,
ssl={'ca': 'Amazon RDS'} # Ensure you have the CA bundle for SSL connection
)
with connection.cursor() as cursor:
cursor.execute('SELECT %s + %s AS sum', (3, 2))
result = cursor.fetchone()
return result
except Exception as e:
return (f"Error: {str(e)}") # Return an error message if an exception occurs
```
------
#### [ Ruby ]
**Kit SDK pour Ruby**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-connect-rds-iam).
Connexion à une base de données Amazon RDS dans une fonction Lambda à l’aide de Ruby.
```
# Ruby code here.
require 'aws-sdk-rds'
require 'json'
require 'mysql2'
def lambda_handler(event:, context:)
endpoint = ENV['DBEndpoint'] # Add the endpoint without https"
port = ENV['Port'] # 3306
user = ENV['DBUser']
region = ENV['DBRegion'] # 'us-east-1'
db_name = ENV['DBName']
credentials = Aws::Credentials.new(
ENV['AWS_ACCESS_KEY_ID'],
ENV['AWS_SECRET_ACCESS_KEY'],
ENV['AWS_SESSION_TOKEN']
)
rds_client = Aws::RDS::AuthTokenGenerator.new(
region: region,
credentials: credentials
)
token = rds_client.auth_token(
endpoint: endpoint+ ':' + port,
user_name: user,
region: region
)
begin
conn = Mysql2::Client.new(
host: endpoint,
username: user,
password: token,
port: port,
database: db_name,
sslca: '/var/task/global-bundle.pem',
sslverify: true,
enable_cleartext_plugin: true
)
a = 3
b = 2
result = conn.query("SELECT #{a} + #{b} AS sum").first['sum']
puts result
conn.close
{
statusCode: 200,
body: result.to_json
}
rescue => e
puts "Database connection failed due to #{e}"
end
end
```
------
#### [ Rust ]
**SDK pour Rust**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-connect-rds-iam).
Connexion à une base de données Amazon RDS dans une fonction Lambda à l’aide de Rust.
```
use aws_config::BehaviorVersion;
use aws_credential_types::provider::ProvideCredentials;
use aws_sigv4::{
http_request::{sign, SignableBody, SignableRequest, SigningSettings},
sign::v4,
};
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
use serde_json::{json, Value};
use sqlx::postgres::PgConnectOptions;
use std::env;
use std::time::{Duration, SystemTime};
const RDS_CERTS: &[u8] = include_bytes!("global-bundle.pem");
async fn generate_rds_iam_token(
db_hostname: &str,
port: u16,
db_username: &str,
) -> Result {
let config = aws_config::load_defaults(BehaviorVersion::v2024_03_28()).await;
let credentials = config
.credentials_provider()
.expect("no credentials provider found")
.provide_credentials()
.await
.expect("unable to load credentials");
let identity = credentials.into();
let region = config.region().unwrap().to_string();
let mut signing_settings = SigningSettings::default();
signing_settings.expires_in = Some(Duration::from_secs(900));
signing_settings.signature_location = aws_sigv4::http_request::SignatureLocation::QueryParams;
let signing_params = v4::SigningParams::builder()
.identity(&identity)
.region(®ion)
.name("rds-db")
.time(SystemTime::now())
.settings(signing_settings)
.build()?;
let url = format!(
"https://{db_hostname}:{port}/?Action=connect&DBUser={db_user}",
db_hostname = db_hostname,
port = port,
db_user = db_username
);
let signable_request =
SignableRequest::new("GET", &url, std::iter::empty(), SignableBody::Bytes(&[]))
.expect("signable request");
let (signing_instructions, _signature) =
sign(signable_request, &signing_params.into())?.into_parts();
let mut url = url::Url::parse(&url).unwrap();
for (name, value) in signing_instructions.params() {
url.query_pairs_mut().append_pair(name, &value);
}
let response = url.to_string().split_off("https://".len());
Ok(response)
}
#[tokio::main]
async fn main() -> Result<(), Error> {
run(service_fn(handler)).await
}
async fn handler(_event: LambdaEvent) -> Result {
let db_host = env::var("DB_HOSTNAME").expect("DB_HOSTNAME must be set");
let db_port = env::var("DB_PORT")
.expect("DB_PORT must be set")
.parse::()
.expect("PORT must be a valid number");
let db_name = env::var("DB_NAME").expect("DB_NAME must be set");
let db_user_name = env::var("DB_USERNAME").expect("DB_USERNAME must be set");
let token = generate_rds_iam_token(&db_host, db_port, &db_user_name).await?;
let opts = PgConnectOptions::new()
.host(&db_host)
.port(db_port)
.username(&db_user_name)
.password(&token)
.database(&db_name)
.ssl_root_cert_from_pem(RDS_CERTS.to_vec())
.ssl_mode(sqlx::postgres::PgSslMode::Require);
let pool = sqlx::postgres::PgPoolOptions::new()
.connect_with(opts)
.await?;
let result: i32 = sqlx::query_scalar("SELECT $1 + $2")
.bind(3)
.bind(2)
.fetch_one(&pool)
.await?;
println!("Result: {:?}", result);
Ok(json!({
"statusCode": 200,
"content-type": "text/plain",
"body": format!("The selected sum is: {result}")
}))
}
```
------
## Traitement des notifications d’événements provenant d’Amazon RDS
Vous pouvez utiliser Lambda pour traiter les notifications d’événements d’une base de données Amazon RDS. Amazon RDS envoie des notifications à une rubrique Amazon Simple Notification Service (Amazon SNS) que vous pouvez configurer pour invoquer une fonction Lambda. Amazon SNS enveloppe le message d’Amazon RDS dans son propre document d’événement, et l’envoie à votre fonction.
Pour plus d’informations sur la configuration d’une base de données Amazon RDS pour envoyer des notifications, consultez [Utilisation des notifications d’événements Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html).
**Example Message Amazon RDS dans un événement Amazon SNS**
```
{
"Records": [
{
"EventVersion": "1.0",
"EventSubscriptionArn": "arn:aws:sns:us-east-2:123456789012:rds-lambda:21be56ed-a058-49f5-8c98-aedd2564c486",
"EventSource": "aws:sns",
"Sns": {
"SignatureVersion": "1",
"Timestamp": "2023-01-02T12:45:07.000Z",
"Signature": "tcc6faL2yUC6dgZdmrwh1Y4cGa/ebXEkAi6RibDsvpi+tE/1+82j...65r==",
"SigningCertUrl": "https://sns.us-east-2.amazonaws.com/SimpleNotificationService-ac565b8b1a6c5d002d285f9598aa1d9b.pem",
"MessageId": "95df01b4-ee98-5cb9-9903-4c221d41eb5e",
"Message": "{\"Event Source\":\"db-instance\",\"Event Time\":\"2023-01-02 12:45:06.000\",\"Identifier Link\":\"https://console.aws.amazon.com/rds/home?region=eu-west-1#dbinstance:id=dbinstanceid\",\"Source ID\":\"dbinstanceid\",\"Event ID\":\"http://docs.amazonwebservices.com/AmazonRDS/latest/UserGuide/USER_Events.html#RDS-EVENT-0002\",\"Event Message\":\"Finished DB Instance backup\"}",
"MessageAttributes": {},
"Type": "Notification",
"UnsubscribeUrl": "https://sns.us-east-2.amazonaws.com/?Action=Unsubscribe&SubscriptionArn=arn:aws:sns:us-east-2:123456789012:test-lambda:21be56ed-a058-49f5-8c98-aedd2564c486",
"TopicArn":"arn:aws:sns:us-east-2:123456789012:sns-lambda",
"Subject": "RDS Notification Message"
}
}
]
}
```
## Tutoriel complet Lambda et Amazon RDS
+ [Utilisation d’une fonction Lambda pour accéder à une base de données Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-lambda-tutorial.html) — Dans le Guide de l’utilisateur Amazon RDS, découvrez comment utiliser une fonction Lambda pour écrire des données dans une base de données Amazon RDS via Proxy Amazon RDS. Votre fonction Lambda lira les enregistrements d’une file d’attente Amazon SQS et écrira de nouveaux éléments dans une table de votre base de données chaque fois qu’un message sera ajouté.
# Sélectionner un service de base de données pour vos applications basées sur Lambda
De nombreuses applications sans serveur ont besoin de stocker et de récupérer des données. AWS propose plusieurs options de base de données qui fonctionnent avec les fonctions Lambda. Les deux options les plus populaires sont Amazon DynamoDB, un service de base de données NoSQL, et Amazon RDS, une solution de base de données relationnelle traditionnelle. Les sections suivantes expliquent les principales différences entre ces services lorsque vous les utilisez avec Lambda, et vous aident à sélectionner le service de base de données adapté à votre application sans serveur.
Pour en savoir plus sur les autres services de base de données proposés par AWS, et pour comprendre leurs cas d'utilisation et leurs inconvénients de manière plus générale, voir [Choisir un service de AWS base de données](https://docs.aws.amazon.com/decision-guides/latest/databases-on-aws-how-to-choose/databases-on-aws-how-to-choose.html). Tous les services de base de données AWS sont compatibles avec Lambda, mais ils ne sont pas nécessairement tous adaptés à votre cas d’utilisation particulier.
## Quelles sont les options proposées lors de la sélection d’un service de base de données avec Lambda ?
AWS propose plusieurs services de base de données. Pour les applications sans serveur, DynamoDB et Amazon RDS sont deux des options les plus populaires.
+ **DynamoDB** est un service de base de données NoSQL entièrement géré, optimisé pour les applications sans serveur. Il offre une mise à l’échelle transparente et des performances constantes de l’ordre de quelques millisecondes à n’importe quelle échelle.
+ **Amazon RDS** est un service de base de données relationnelle géré qui prend en charge plusieurs moteurs de base de données, dont MySQL et PostgreSQL. Il fournit les fonctionnalités familières de SQL avec une infrastructure gérée.
## Recommandations si vous connaissez déjà vos besoins
Si vous connaissez déjà bien vos besoins, voici nos recommandations de base :
Nous recommandons [DynamoDB](with-ddb.md) pour les applications sans serveur qui ont besoin de performances constantes à faible latence et d’une mise à l’échelle automatique, et qui ne nécessitent pas de jointures ou de transactions complexes. Cette solution est particulièrement adaptée aux applications basées sur Lambda en raison de sa nature sans serveur.
[Amazon RDS](services-rds.md) est un meilleur choix lorsque vous avez besoin de requêtes SQL complexes, de jointures ou si vous avez des applications existantes utilisant des bases de données relationnelles. Sachez toutefois que la connexion des fonctions Lambda à Amazon RDS nécessite une configuration supplémentaire et peut avoir un impact sur les temps de démarrage à froid.
## Éléments à prendre en compte lors de la sélection d’un service de base de données
Lorsque vous choisissez entre DynamoDB et Amazon RDS pour vos applications Lambda, tenez compte des facteurs suivants :
+ Gestion des connexions et démarrages à froid
+ Modèles d’accès aux données
+ Complexité des requêtes
+ Exigences de cohérence des données
+ Caractéristiques de mise à l’échelle
+ Modèle de coût
La compréhension de ces facteurs vous permettra de choisir l’option qui répond le mieux aux besoins de votre cas d’utilisation.
### Gestion des connexions et démarrages à froid
+ DynamoDB utilise une API HTTP pour toutes les opérations. Les fonctions Lambda peuvent effectuer des requêtes immédiatement sans maintenir de connexion, ce qui améliore les performances de démarrage à froid. Chaque demande est authentifiée à l'aide AWS d'informations d'identification sans surcoût de connexion.
+ Amazon RDS nécessite de gérer des groupes de connexions, car il utilise des connexions de base de données traditionnelles. Cela peut affecter les démarrages à froid, car les nouvelles instances Lambda doivent établir des connexions. Vous devrez mettre en œuvre des stratégies de regroupement de connexions et éventuellement utiliser le [Proxy Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) pour gérer efficacement les connexions. Notez que l’utilisation du Proxy Amazon RDS entraîne des coûts supplémentaires.
### Modèles d’accès aux données
+ DynamoDB fonctionne mieux avec les modèles d’accès connus et les modèles à table unique. Il est idéal pour les applications Lambda qui ont besoin d’un accès constant à faible latence aux données sur la base de clés primaires ou d’index secondaires.
+ Amazon RDS offre de la flexibilité pour les requêtes complexes et les modèles d’accès changeants. Il est mieux adapté lorsque vos fonctions Lambda doivent effectuer des requêtes uniques et personnalisées, ou des jointures complexes sur plusieurs tables.
### Complexité des requêtes
+ DynamoDB excelle dans les opérations simples basées sur les clés et dans les modèles d’accès prédéfinis. Les requêtes complexes doivent être conçues autour de structures d’index, et les jointures doivent être gérées dans le code de l’application.
+ Amazon RDS prend en charge les requêtes SQL complexes avec des jointures, des sous-requêtes et des agrégations. Cela peut simplifier le code de votre fonction Lambda lorsque des opérations de données complexes sont nécessaires.
### Exigences de cohérence des données
+ DynamoDB propose à la fois des options de cohérence finale et de cohérence forte, la cohérence forte étant disponible pour les lectures d’un seul élément. Les transactions sont prises en charge, mais avec certaines restrictions.
+ Amazon RDS offre une conformité totale en matière d’atomicité, de cohérence, d’isolation et de durabilité (ACID) et une prise en charge des transactions complexes. Si vos fonctions Lambda nécessitent des transactions complexes ou une cohérence forte entre plusieurs enregistrements, Amazon RDS pourrait être plus adapté.
### Caractéristiques de mise à l’échelle
+ DynamoDB s’adapte automatiquement à votre charge de travail. Il peut gérer les pics de trafic soudains provenant des fonctions Lambda sans pré-approvisionnement. Vous pouvez utiliser le mode de capacité à la demande pour ne payer que ce que vous utilisez, ce qui correspond parfaitement au modèle de mise à l’échelle de Lambda.
+ Amazon RDS dispose d’une capacité fixe en fonction de la taille d’instance que vous choisissez. Si plusieurs fonctions Lambda tentent de se connecter simultanément, vous risquez de dépasser votre quota de connexions. Vous devez gérer avec soin les groupes de connexions et éventuellement implémenter une logique de nouvelle tentative.
### Modèle de coût
+ La tarification de DynamoDB est parfaitement adaptée aux applications sans serveur. Avec une capacité à la demande, vous ne payez que pour les lectures et écritures réellement utilisées par vos fonctions Lambda. Le temps d’inactivité n’est pas facturé.
+ Amazon RDS facture l’instance en cours d’exécution, quelle que soit son utilisation. Cela peut être moins rentable pour les charges de travail sporadiques, qui sont courantes dans les applications sans serveur. Toutefois, cela peut s’avérer plus économique pour les charges de travail à haut débit avec une utilisation constante.
## Commencer avec le service de base de données que vous avez choisi
Maintenant que vous avez pris connaissance des critères de sélection entre DynamoDB et Amazon RDS et des principales différences entre les deux, vous pouvez sélectionner l’option qui répond le mieux à vos besoins et utiliser les ressources suivantes pour commencer à l’utiliser.
------
#### [ DynamoDB ]
**Mise en route avec DynamoDB grâce aux ressources suivantes**
+ Pour une présentation du service DynamoDB, consultez [Qu’est-ce que DynamoDB ?](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) dans le *Guide du développeur Amazon DynamoDB*
+ Suivez le didacticiel [Utilisation de Lambda avec API Gateway](services-apigateway-tutorial.md) pour découvrir un exemple d’utilisation d’une fonction Lambda pour effectuer des opérations CRUD sur une table DynamoDB en réponse à une demande d’API.
+ Lisez [Programming with DynamoDB et AWS SDKs](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Programming.html) le manuel du *développeur Amazon DynamoDB pour en savoir plus sur la façon d'accéder à DynamoDB* depuis votre fonction Lambda en utilisant l'un des. AWS SDKs
------
#### [ Amazon RDS ]
**Mise en route avec Amazon RDS grâce aux ressources suivantes**
+ Pour une présentation du service Amazon RDS, consultez l’article [Qu’est-ce que Amazon Relational Database Service (Amazon RDS) ?](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) dans le *Guide de l’utilisateur Amazon Relational Database Service*.
+ Suivez le didacticiel [Utilisation d’une fonction Lambda pour accéder à une base de données Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-lambda-tutorial.html) dans le *Guide de l’utilisateur Amazon Relational Database Service*.
+ Pour en savoir plus sur l’utilisation de Lambda avec Amazon RDS, consultez [Utilisation AWS Lambda avec Amazon RDS](services-rds.md).
------
# Traiter les notifications d’événements Amazon S3 avec Lambda
Vous pouvez utiliser Lambda pour traiter les [notifications d’événement](https://docs.aws.amazon.com/AmazonS3/latest/userguide/NotificationHowTo.html) d’Amazon Simple Storage Service. Amazon S3 peut envoyer un événement à une fonction Lambda lors de la création ou de la suppression d’un objet. Vous configurez des paramètres de notification sur un compartiment et accordez à Amazon S3 l’autorisation d’appeler une fonction sur la stratégie d’autorisations basée sur une ressource de la fonction.
**Avertissement**
Si votre fonction Lambda utilise le même compartiment que celui qui la déclenche, la fonction risque de s’exécuter en boucle. Par exemple, si le compartiment déclenche une fonction chaque fois qu’un objet est chargé et que la fonction charge un objet dans le compartiment, la fonction se déclenche elle-même indirectement. Afin d’éviter cela, utilisez deux compartiments ou configurez le déclencheur pour qu’il s’applique uniquement à un préfixe utilisé pour les objets entrants.
Amazon S3 appelle votre fonction [de manière asynchrone](invocation-async.md) avec un événement contenant des détails sur l’objet. L’exemple suivant montre un événement envoyé par Amazon S3 lors du chargement d’un package de déploiement vers Amazon S3.
**Example Evénement de notification Amazon S3**
```
{
"Records": [
{
"eventVersion": "2.1",
"eventSource": "aws:s3",
"awsRegion": "us-east-2",
"eventTime": "2019-09-03T19:37:27.192Z",
"eventName": "ObjectCreated:Put",
"userIdentity": {
"principalId": "AWS:AIDAINPONIXQXHT3IKHL2"
},
"requestParameters": {
"sourceIPAddress": "205.255.255.255"
},
"responseElements": {
"x-amz-request-id": "D82B88E5F771F645",
"x-amz-id-2": "vlR7PnpV2Ce81l0PRw6jlUpck7Jo5ZsQjryTjKlc5aLWGVHPZLj5NeC6qMa0emYBDXOo6QBU0Wo="
},
"s3": {
"s3SchemaVersion": "1.0",
"configurationId": "828aa6fc-f7b5-4305-8584-487c791949c1",
"bucket": {
"name": "amzn-s3-demo-bucket",
"ownerIdentity": {
"principalId": "A3I5XTEXAMAI3E"
},
"arn": "arn:aws:s3:::lambda-artifacts-deafc19498e3f2df"
},
"object": {
"key": "b21b84d653bb07b05b1e6b33684dc11b",
"size": 1305107,
"eTag": "b21b84d653bb07b05b1e6b33684dc11b",
"sequencer": "0C0F6F405D6ED209E1"
}
}
}
]
}
```
Pour appeler votre fonction, Amazon S3 a besoin d’une autorisation de la [stratégie basée sur une ressource](access-control-resource-based.md). Lorsque vous configurez un déclencheur Amazon S3 dans la console Lambda, cette dernière modifie la stratégie basée sur une ressource pour permettre à Amazon S3 d’appeler la fonction si le nom du compartiment et l’ID de compte correspondent. Si vous configurez la notification dans Amazon S3, vous utilisez l’API Lambda pour mettre à jour la stratégie. Vous pouvez également utiliser l’API Lambda pour accorder une autorisation à un autre compte ou limiter l’autorisation à un alias désigné.
Si votre fonction utilise le AWS SDK pour gérer les ressources Amazon S3, elle a également besoin des autorisations Amazon S3 dans son [rôle d'exécution](lambda-intro-execution-role.md).
**Topics**
+ [Didacticiel : utilisation d’un déclencheur Amazon S3 pour invoquer une fonction Lambda](with-s3-example.md)
+ [Didacticiel : Utilisation d’un déclencheur Amazon S3 pour créer des images miniatures](with-s3-tutorial.md)
# Didacticiel : utilisation d’un déclencheur Amazon S3 pour invoquer une fonction Lambda
Dans ce didacticiel, vous allez utiliser la console pour créer une fonction Lambda et configurer un déclencheur pour un compartiment Amazon Simple Storage Service (Amazon S3). Chaque fois que vous ajoutez un objet à votre compartiment Amazon S3, votre fonction s'exécute et affiche le type d'objet dans Amazon CloudWatch Logs.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-s3-example/s3_tut_config.png)
Ce tutoriel montre comment :
1. Créez un compartiment Amazon S3.
1. Créez une fonction Lambda qui renvoie le type d’objet des objets dans un compartiment Amazon S3.
1. Configurez un déclencheur Lambda qui invoque votre fonction lorsque des objets sont chargés dans votre compartiment.
1. Testez votre fonction, d’abord avec un événement fictif, puis en utilisant le déclencheur.
En suivant ces étapes, vous apprendrez à configurer une fonction Lambda pour qu’elle s’exécute chaque fois que des objets sont ajoutés ou supprimés d’un compartiment Amazon S3. Vous pouvez compléter ce didacticiel en n’utilisant que la AWS Management Console.
## Créer un compartiment Amazon S3
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-s3-example/s3trigger_tut_steps1.png)
**Pour créer un compartiment Amazon S3**
1. Ouvrez la [console Amazon S3](https://console.aws.amazon.com/s3) et sélectionnez la page **Compartiments à usage général**.
1. Sélectionnez le Région AWS plus proche de votre situation géographique. Vous pouvez modifier votre région à l’aide de la liste déroulante en haut de l’écran. Plus loin dans le didacticiel, vous devez créer votre fonction Lambda dans la même région.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/console_region_select.png)
1. Choisissez **Create bucket** (Créer un compartiment).
1. Sous **Configuration générale**, procédez comme suit :
1. Pour le **type de compartiment**, veillez à sélectionner **Usage général**.
1. Pour le **nom du compartiment**, saisissez un nom unique au monde qui respecte les [règles de dénomination du compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html) Amazon S3. Les noms de compartiment peuvent contenir uniquement des lettres minuscules, des chiffres, de points (.) et des traits d’union (-).
1. Conservez les valeurs par défaut de toutes les autres options et choisissez **Créer un compartiment**.
## Charger un objet de test dans votre compartiment
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-s3-example/s3trigger_tut_steps2.png)
**Pour charger un objet de test**
1. Ouvrez la page [Compartiments](https://console.aws.amazon.com/s3/buckets) de la console Amazon S3 et choisissez le compartiment que vous avez créé à l’étape précédente.
1. Choisissez **Charger**.
1. Choisissez **Ajouter des fichiers** et sélectionnez l’objet que vous souhaitez charger. Vous pouvez sélectionner n’importe quel fichier (par exemple, `HappyFace.jpg`).
1. Choisissez **Ouvrir**, puis **Charger**.
Plus loin dans le tutoriel, vous testerez votre fonction Lambda à l’aide de cet objet.
## Création d’une stratégie d’autorisations
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-s3-example/s3trigger_tut_steps3.png)
Créez une politique d'autorisation qui permet à Lambda d'obtenir des objets depuis un compartiment Amazon S3 et d'écrire dans Amazon CloudWatch Logs.
**Pour créer la politique**
1. Ouvrez la [page stratégies](https://console.aws.amazon.com/iam/home#/policies) de la console IAM.
1. Choisissez **Créer une stratégie**.
1. Choisissez l’onglet **JSON**, puis collez la stratégie personnalisée suivante dans l’éditeur JSON.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:PutLogEvents",
"logs:CreateLogGroup",
"logs:CreateLogStream"
],
"Resource": "arn:aws:logs:*:*:*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": "arn:aws:s3:::*/*"
}
]
}
```
------
1. Choisissez **Suivant : Balises**.
1. Choisissez **Suivant : Vérification**.
1. Sous **Examiner une stratégie**, pour le **Nom** de la stratégie, saisissez **s3-trigger-tutorial**.
1. Choisissez **Créer une stratégie**.
## Créer un rôle d’exécution
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-s3-example/s3trigger_tut_steps4.png)
Un [rôle d'exécution](lambda-intro-execution-role.md) est un rôle Gestion des identités et des accès AWS (IAM) qui accorde à une fonction Lambda l'autorisation d' Services AWS accès et de ressources. Dans cette étape, vous créez un rôle d’exécution à l’aide de la politique d’autorisations que vous avez créée à l’étape précédente.
**Pour créer un rôle d’exécution et attacher votre politique d’autorisations personnalisée**
1. Ouvrez la [page Rôles](https://console.aws.amazon.com/iam/home#/roles) de la console IAM.
1. Sélectionnez **Créer un rôle**.
1. Pour le type d’entité de confiance, choisissez **Service AWS **, puis pour le cas d’utilisation, choisissez **Lambda**.
1. Choisissez **Suivant**.
1. Dans la zone de recherche de stratégie, entrez **s3-trigger-tutorial**.
1. Dans les résultats de la recherche, sélectionnez la stratégie que vous avez créée (`s3-trigger-tutorial`), puis choisissez **Suivant**.
1. Sous **Role details** (Détails du rôle), pour **Role name** (Nom du rôle), saisissez **lambda-s3-trigger-role**, puis sélectionnez **Create role** (Créer un rôle).
## Créer la fonction Lambda
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-s3-example/s3trigger_tut_steps5.png)
Créez une fonction Lambda dans la console à l'aide de l'environnement d'exécution Python 3.14.
**Pour créer la fonction Lambda**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Assurez-vous de travailler dans le même environnement que celui dans Région AWS lequel vous avez créé votre compartiment Amazon S3. Vous pouvez modifier votre région à l’aide de la liste déroulante en haut de l’écran.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/console_region_select.png)
1. Choisissez **Créer une fonction**.
1. Choisissez **Créer à partir de zéro**.
1. Sous **Basic information** (Informations de base), procédez comme suit :
1. Sous **Nom de la fonction**, saisissez `s3-trigger-tutorial`.
1. Pour **Runtime**, choisissez **Python 3.14**.
1. Pour **Architecture**, choisissez **x86\$164**.
1. Dans l’onglet **Modifier le rôle d’exécution par défaut**, procédez comme suit :
1. Ouvrez l’onglet, puis choisissez **Utiliser un rôle existant**.
1. Sélectionnez le `lambda-s3-trigger-role` que vous avez créé précédemment.
1. Choisissez **Créer une fonction**.
## Déployer le code de la fonction
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-s3-example/s3trigger_tut_steps6.png)
Ce didacticiel utilise le moteur d'exécution Python 3.14, mais nous avons également fourni des exemples de fichiers de code pour d'autres environnements d'exécution. Vous pouvez sélectionner l’onglet dans la zone suivante pour voir le code d’exécution qui vous intéresse.
La fonction Lambda récupère le nom de la clé de l’objet chargé et le nom du compartiment à partir du paramètre `event` qu’elle reçoit d’Amazon S3. La fonction utilise ensuite la méthode [get\$1object](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/s3/client/get_object.html) du AWS SDK pour Python (Boto3) pour récupérer les métadonnées de l'objet, y compris le type de contenu (type MIME) de l'objet chargé.
**Pour déployer le code de la fonction**
1. Choisissez l’onglet **Python** dans la zone suivante et copiez le code.
------
#### [ .NET ]
**SDK pour .NET**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-s3-to-lambda).
Utilisation d’un événement S3 avec Lambda en utilisant .NET.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using System.Threading.Tasks;
using Amazon.Lambda.Core;
using Amazon.S3;
using System;
using Amazon.Lambda.S3Events;
using System.Web;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace S3Integration
{
public class Function
{
private static AmazonS3Client _s3Client;
public Function() : this(null)
{
}
internal Function(AmazonS3Client s3Client)
{
_s3Client = s3Client ?? new AmazonS3Client();
}
public async Task Handler(S3Event evt, ILambdaContext context)
{
try
{
if (evt.Records.Count <= 0)
{
context.Logger.LogLine("Empty S3 Event received");
return string.Empty;
}
var bucket = evt.Records[0].S3.Bucket.Name;
var key = HttpUtility.UrlDecode(evt.Records[0].S3.Object.Key);
context.Logger.LogLine($"Request is for {bucket} and {key}");
var objectResult = await _s3Client.GetObjectAsync(bucket, key);
context.Logger.LogLine($"Returning {objectResult.Key}");
return objectResult.Key;
}
catch (Exception e)
{
context.Logger.LogLine($"Error processing request - {e.Message}");
return string.Empty;
}
}
}
}
```
------
#### [ Go ]
**Kit SDK pour Go V2**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-s3-to-lambda).
Utilisation d’un événement S3 avec Lambda en utilisant Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package main
import (
"context"
"log"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
"github.com/aws/aws-sdk-go-v2/config"
"github.com/aws/aws-sdk-go-v2/service/s3"
)
func handler(ctx context.Context, s3Event events.S3Event) error {
sdkConfig, err := config.LoadDefaultConfig(ctx)
if err != nil {
log.Printf("failed to load default config: %s", err)
return err
}
s3Client := s3.NewFromConfig(sdkConfig)
for _, record := range s3Event.Records {
bucket := record.S3.Bucket.Name
key := record.S3.Object.URLDecodedKey
headOutput, err := s3Client.HeadObject(ctx, &s3.HeadObjectInput{
Bucket: &bucket,
Key: &key,
})
if err != nil {
log.Printf("error getting head of object %s/%s: %s", bucket, key, err)
return err
}
log.Printf("successfully retrieved %s/%s of type %s", bucket, key, *headOutput.ContentType)
}
return nil
}
func main() {
lambda.Start(handler)
}
```
------
#### [ Java ]
**SDK pour Java 2.x**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-s3-to-lambda).
Utilisation d’un événement S3 avec Lambda en utilisant Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package example;
import software.amazon.awssdk.services.s3.model.HeadObjectRequest;
import software.amazon.awssdk.services.s3.model.HeadObjectResponse;
import software.amazon.awssdk.services.s3.S3Client;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.S3Event;
import com.amazonaws.services.lambda.runtime.events.models.s3.S3EventNotification.S3EventNotificationRecord;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class Handler implements RequestHandler {
private static final Logger logger = LoggerFactory.getLogger(Handler.class);
@Override
public String handleRequest(S3Event s3event, Context context) {
try {
S3EventNotificationRecord record = s3event.getRecords().get(0);
String srcBucket = record.getS3().getBucket().getName();
String srcKey = record.getS3().getObject().getUrlDecodedKey();
S3Client s3Client = S3Client.builder().build();
HeadObjectResponse headObject = getHeadObject(s3Client, srcBucket, srcKey);
logger.info("Successfully retrieved " + srcBucket + "/" + srcKey + " of type " + headObject.contentType());
return "Ok";
} catch (Exception e) {
throw new RuntimeException(e);
}
}
private HeadObjectResponse getHeadObject(S3Client s3Client, String bucket, String key) {
HeadObjectRequest headObjectRequest = HeadObjectRequest.builder()
.bucket(bucket)
.key(key)
.build();
return s3Client.headObject(headObjectRequest);
}
}
```
------
#### [ JavaScript ]
**SDK pour JavaScript (v3)**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-s3-to-lambda).
Consommation d'un événement S3 avec Lambda en utilisant. JavaScript
```
import { S3Client, HeadObjectCommand } from "@aws-sdk/client-s3";
const client = new S3Client();
export const handler = async (event, context) => {
// Get the object from the event and show its content type
const bucket = event.Records[0].s3.bucket.name;
const key = decodeURIComponent(event.Records[0].s3.object.key.replace(/\+/g, ' '));
try {
const { ContentType } = await client.send(new HeadObjectCommand({
Bucket: bucket,
Key: key,
}));
console.log('CONTENT TYPE:', ContentType);
return ContentType;
} catch (err) {
console.log(err);
const message = `Error getting object ${key} from bucket ${bucket}. Make sure they exist and your bucket is in the same region as this function.`;
console.log(message);
throw new Error(message);
}
};
```
Consommation d'un événement S3 avec Lambda en utilisant. TypeScript
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import { S3Event } from 'aws-lambda';
import { S3Client, HeadObjectCommand } from '@aws-sdk/client-s3';
const s3 = new S3Client({ region: process.env.AWS_REGION });
export const handler = async (event: S3Event): Promise => {
// Get the object from the event and show its content type
const bucket = event.Records[0].s3.bucket.name;
const key = decodeURIComponent(event.Records[0].s3.object.key.replace(/\+/g, ' '));
const params = {
Bucket: bucket,
Key: key,
};
try {
const { ContentType } = await s3.send(new HeadObjectCommand(params));
console.log('CONTENT TYPE:', ContentType);
return ContentType;
} catch (err) {
console.log(err);
const message = `Error getting object ${key} from bucket ${bucket}. Make sure they exist and your bucket is in the same region as this function.`;
console.log(message);
throw new Error(message);
}
};
```
------
#### [ PHP ]
**Kit SDK pour PHP**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-s3-to-lambda).
Consommation d’un événement S3 avec Lambda à l’aide de PHP.
```
logger = $logger;
}
public function handleS3(S3Event $event, Context $context) : void
{
$this->logger->info("Processing S3 records");
// Get the object from the event and show its content type
$records = $event->getRecords();
foreach ($records as $record)
{
$bucket = $record->getBucket()->getName();
$key = urldecode($record->getObject()->getKey());
try {
$fileSize = urldecode($record->getObject()->getSize());
echo "File Size: " . $fileSize . "\n";
// TODO: Implement your custom processing logic here
} catch (Exception $e) {
echo $e->getMessage() . "\n";
echo 'Error getting object ' . $key . ' from bucket ' . $bucket . '. Make sure they exist and your bucket is in the same region as this function.' . "\n";
throw $e;
}
}
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**Kit SDK for Python (Boto3)**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-s3-to-lambda).
Utilisation d’un événement S3 avec Lambda en utilisant Python.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
import json
import urllib.parse
import boto3
print('Loading function')
s3 = boto3.client('s3')
def lambda_handler(event, context):
#print("Received event: " + json.dumps(event, indent=2))
# Get the object from the event and show its content type
bucket = event['Records'][0]['s3']['bucket']['name']
key = urllib.parse.unquote_plus(event['Records'][0]['s3']['object']['key'], encoding='utf-8')
try:
response = s3.get_object(Bucket=bucket, Key=key)
print("CONTENT TYPE: " + response['ContentType'])
return response['ContentType']
except Exception as e:
print(e)
print('Error getting object {} from bucket {}. Make sure they exist and your bucket is in the same region as this function.'.format(key, bucket))
raise e
```
------
#### [ Ruby ]
**Kit SDK pour Ruby**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-s3-to-lambda).
Consommation d’un événement S3 avec Lambda à l’aide de Ruby.
```
require 'json'
require 'uri'
require 'aws-sdk'
puts 'Loading function'
def lambda_handler(event:, context:)
s3 = Aws::S3::Client.new(region: 'region') # Your AWS region
# puts "Received event: #{JSON.dump(event)}"
# Get the object from the event and show its content type
bucket = event['Records'][0]['s3']['bucket']['name']
key = URI.decode_www_form_component(event['Records'][0]['s3']['object']['key'], Encoding::UTF_8)
begin
response = s3.get_object(bucket: bucket, key: key)
puts "CONTENT TYPE: #{response.content_type}"
return response.content_type
rescue StandardError => e
puts e.message
puts "Error getting object #{key} from bucket #{bucket}. Make sure they exist and your bucket is in the same region as this function."
raise e
end
end
```
------
#### [ Rust ]
**SDK pour Rust**
Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-s3-to-lambda).
Utilisation d’un événement S3 avec Lambda en utilisant Rust.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
use aws_lambda_events::event::s3::S3Event;
use aws_sdk_s3::{Client};
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
/// Main function
#[tokio::main]
async fn main() -> Result<(), Error> {
tracing_subscriber::fmt()
.with_max_level(tracing::Level::INFO)
.with_target(false)
.without_time()
.init();
// Initialize the AWS SDK for Rust
let config = aws_config::load_from_env().await;
let s3_client = Client::new(&config);
let res = run(service_fn(|request: LambdaEvent| {
function_handler(&s3_client, request)
})).await;
res
}
async fn function_handler(
s3_client: &Client,
evt: LambdaEvent
) -> Result<(), Error> {
tracing::info!(records = ?evt.payload.records.len(), "Received request from SQS");
if evt.payload.records.len() == 0 {
tracing::info!("Empty S3 event received");
}
let bucket = evt.payload.records[0].s3.bucket.name.as_ref().expect("Bucket name to exist");
let key = evt.payload.records[0].s3.object.key.as_ref().expect("Object key to exist");
tracing::info!("Request is for {} and object {}", bucket, key);
let s3_get_object_result = s3_client
.get_object()
.bucket(bucket)
.key(key)
.send()
.await;
match s3_get_object_result {
Ok(_) => tracing::info!("S3 Get Object success, the s3GetObjectResult contains a 'body' property of type ByteStream"),
Err(_) => tracing::info!("Failure with S3 Get Object request")
}
Ok(())
}
```
------
1. Dans le volet **Code source** de la console Lambda, collez le code dans l’éditeur de code, en remplaçant le code créé par Lambda.
1. Dans la section **DÉPLOYER**, choisissez **Déployer** pour mettre à jour le code de votre fonction :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/getting-started-tutorial/deploy-console.png)
## Création d’un déclencheur Amazon S3
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-s3-example/s3trigger_tut_steps7.png)
**Pour créer le déclencheur Amazon S3**
1. Dans le volet de **Présentation de la fonction**, choisissez **Ajouter un déclencheur**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/overview-trigger.png)
1. Sélectionnez **S3**.
1. Sous **Compartiment**, sélectionnez le compartiment que vous avez créé précédemment dans le didacticiel.
1. Sous **Types d’événements**, assurez-vous que **Tous les événements de création d’objet** est sélectionné.
1. Sous **Invocation récursive**, cochez la case pour confirmer qu’il n’est pas recommandé d’utiliser le même compartiment Amazon S3 pour les entrées et les sorties.
1. Choisissez **Ajouter**.
**Note**
Lorsque vous créez un déclencheur Amazon S3 pour une fonction Lambda à l’aide de la console Lambda, Amazon S3 configure une [notification d’événement](https://docs.aws.amazon.com/AmazonS3/latest/userguide/EventNotifications.html) sur le compartiment que vous spécifiez. Avant de configurer cette notification d’événement, Amazon S3 effectue une série de vérifications pour confirmer que la destination de l’événement existe et dispose des politiques IAM requises. Amazon S3 effectue également ces tests sur toutes les autres notifications d’événements configurées pour ce compartiment.
En raison de cette vérification, si le compartiment a déjà configuré des destinations d’événements pour des ressources qui n’existent plus ou pour des ressources qui ne disposent pas des politiques d’autorisations requises, Amazon S3 ne sera pas en mesure de créer la nouvelle notification d’événement. Vous verrez le message d’erreur suivant indiquant que votre déclencheur n’a pas pu être créé :
```
An error occurred when creating the trigger: Unable to validate the following destination configurations.
```
Vous pouvez voir cette erreur si vous avez précédemment configuré un déclencheur pour une autre fonction Lambda utilisant le même compartiment, et si vous avez depuis supprimé la fonction ou modifié ses politiques d’autorisations.
## Test de votre fonction Lambda à l’aide d’un événement fictif
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-s3-example/s3trigger_tut_steps8.png)
**Pour tester la fonction Lambda à l’aide d’un événement fictif**
1. Dans la page de votre fonction de la console Lambda, choisissez l’onglet **Tester**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/test-tab.png)
1. Dans **Event name** (Nom de l’événement), saisissez `MyTestEvent`.
1. Dans le **JSON d’événement**, collez l’événement de test suivant. Veillez à remplacer les valeurs suivantes :
+ Remplacez `us-east-1` par la région dans laquelle vous avez créé votre compartiment Amazon S3.
+ Remplacez les deux instances de `amzn-s3-demo-bucket` par le nom de votre propre compartiment Amazon S3.
+ Remplacez `test%2FKey` par le nom de l’objet de test que vous avez chargé précédemment dans votre compartiment (par exemple, `HappyFace.jpg`).
```
{
"Records": [
{
"eventVersion": "2.0",
"eventSource": "aws:s3",
"awsRegion": "us-east-1",
"eventTime": "1970-01-01T00:00:00.000Z",
"eventName": "ObjectCreated:Put",
"userIdentity": {
"principalId": "EXAMPLE"
},
"requestParameters": {
"sourceIPAddress": "127.0.0.1"
},
"responseElements": {
"x-amz-request-id": "EXAMPLE123456789",
"x-amz-id-2": "EXAMPLE123/5678abcdefghijklambdaisawesome/mnopqrstuvwxyzABCDEFGH"
},
"s3": {
"s3SchemaVersion": "1.0",
"configurationId": "testConfigRule",
"bucket": {
"name": "amzn-s3-demo-bucket",
"ownerIdentity": {
"principalId": "EXAMPLE"
},
"arn": "arn:aws:s3:::amzn-s3-demo-bucket"
},
"object": {
"key": "test%2Fkey",
"size": 1024,
"eTag": "0123456789abcdef0123456789abcdef",
"sequencer": "0A1B2C3D4E5F678901"
}
}
}
]
}
```
1. Choisissez **Enregistrer**.
1. Sélectionnez **Tester)**.
1. Si votre fonction s’exécute correctement, vous obtiendrez un résultat similaire à celui qui suit dans l’onglet **Résultats de l’exécution**.
```
Response
"image/jpeg"
Function Logs
START RequestId: 12b3cae7-5f4e-415e-93e6-416b8f8b66e6 Version: $LATEST
2021-02-18T21:40:59.280Z 12b3cae7-5f4e-415e-93e6-416b8f8b66e6 INFO INPUT BUCKET AND KEY: { Bucket: 'amzn-s3-demo-bucket', Key: 'HappyFace.jpg' }
2021-02-18T21:41:00.215Z 12b3cae7-5f4e-415e-93e6-416b8f8b66e6 INFO CONTENT TYPE: image/jpeg
END RequestId: 12b3cae7-5f4e-415e-93e6-416b8f8b66e6
REPORT RequestId: 12b3cae7-5f4e-415e-93e6-416b8f8b66e6 Duration: 976.25 ms Billed Duration: 977 ms Memory Size: 128 MB Max Memory Used: 90 MB Init Duration: 430.47 ms
Request ID
12b3cae7-5f4e-415e-93e6-416b8f8b66e6
```
### Test de la fonction Lambda avec le déclencheur Amazon S3
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-s3-example/s3trigger_tut_steps9.png)
Pour tester votre fonction avec le déclencheur configuré, chargez un objet dans votre compartiment Amazon S3 à l’aide de la console. Pour vérifier que votre fonction Lambda s'est exécutée comme prévu, utilisez CloudWatch Logs pour afficher le résultat de votre fonction.
**Pour charger un objet dans votre compartiment Amazon S3**
1. Ouvrez la page [Compartiments](https://console.aws.amazon.com/s3/buckets) de la console Amazon S3 et choisissez le compartiment que vous avez créé précédemment.
1. Choisissez **Charger**.
1. Choisissez **Ajouter des fichiers** et utilisez le sélecteur de fichiers pour choisir l’objet que vous souhaitez charger. Cet objet peut être n’importe quel fichier que vous choisissez.
1. Choisissez **Ouvrir**, puis **Charger**.
**Pour vérifier l'invocation de la fonction à l'aide CloudWatch de Logs**
1. Ouvrez la console [CloudWatch](https://console.aws.amazon.com/cloudwatch/home).
1. Assurez-vous de travailler de la même manière que celle dans laquelle Région AWS vous avez créé votre fonction Lambda. Vous pouvez modifier votre région à l’aide de la liste déroulante en haut de l’écran.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/console_region_select.png)
1. Choisissez **Journaux**, puis **Groupes de journaux**.
1. Choisissez le groupe de journaux de votre fonction (`/aws/lambda/s3-trigger-tutorial`).
1. Sous **Flux de journaux**, sélectionnez le flux de journaux le plus récent.
1. Si votre fonction a été invoquée correctement en réponse à votre déclencheur Amazon S3, vous obtiendrez une sortie similaire à celle qui suit. Le `CONTENT TYPE` que vous voyez dépend du type de fichier que vous avez chargé dans votre compartiment.
```
2022-05-09T23:17:28.702Z 0cae7f5a-b0af-4c73-8563-a3430333cc10 INFO CONTENT TYPE: image/jpeg
```
## Nettoyage de vos ressources
Vous pouvez maintenant supprimer les ressources que vous avez créées pour ce didacticiel, sauf si vous souhaitez les conserver. En supprimant AWS les ressources que vous n'utilisez plus, vous évitez des frais inutiles pour votre Compte AWS.
**Pour supprimer la fonction Lambda**
1. Ouvrez la [page Functions (Fonctions)](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda.
1. Sélectionnez la fonction que vous avez créée.
1. Sélectionnez **Actions**, **Supprimer**.
1. Saisissez **confirm** dans la zone de saisie de texte et choisissez **Delete** (Supprimer).
**Pour supprimer le rôle d’exécution**
1. Ouvrez la [page Roles (Rôles)](https://console.aws.amazon.com/iam/home#/roles) de la console IAM.
1. Sélectionnez le rôle d’exécution que vous avez créé.
1. Sélectionnez **Delete (Supprimer)**.
1. Saisissez le nom du rôle dans le champ de saisie de texte et choisissez **Delete** (Supprimer).
**Pour supprimer le compartiment S3**
1. Ouvrez la [console Amazon S3](https://console.aws.amazon.com//s3/home#).
1. Sélectionnez le compartiment que vous avez créé.
1. Sélectionnez **Delete (Supprimer)**.
1. Saisissez le nom du compartiment dans le champ de saisie de texte.
1. Choisissez **Supprimer le compartiment**.
## Étapes suivantes
Dans [Didacticiel : Utilisation d’un déclencheur Amazon S3 pour créer des images miniatures](with-s3-tutorial.md), le déclencheur Amazon S3 invoque une fonction qui crée une image de miniature pour chaque fichier image qui est chargé dans votre compartiment. Ce didacticiel nécessite un niveau modéré de connaissance du AWS domaine Lambda. Il montre comment créer des ressources à l'aide de AWS Command Line Interface (AWS CLI) et comment créer un package de déploiement d'archives de fichiers .zip pour la fonction et ses dépendances.
# Didacticiel : Utilisation d’un déclencheur Amazon S3 pour créer des images miniatures
Dans ce tutoriel, vous allez créer et configurer une fonction Lambda qui redimensionne les images ajoutées à un compartiment Amazon Simple Storage Service (Amazon S3). Lorsque vous ajoutez un fichier image à votre compartiment, Amazon S3 invoque votre fonction Lambda. La fonction crée ensuite une version miniature de l’image et l’envoie vers un autre compartiment Amazon S3.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-s3-tutorial/s3thumb_tut_resources.png)
Pour compléter ce didacticiel, effectuez les tâches suivantes :
1. Créez des compartiments Amazon S3 source et de destination et chargez un exemple d’image.
1. Créez une fonction Lambda qui redimensionne une image et envoie une miniature vers un compartiment Amazon S3.
1. Configurez un déclencheur Lambda qui invoque votre fonction lorsque des objets sont chargés dans votre compartiment source.
1. Testez votre fonction, d’abord avec un événement fictif, puis en chargeant une image dans votre compartiment source.
En suivant ces étapes, vous apprendrez à utiliser Lambda pour effectuer une tâche de traitement de fichiers sur des objets ajoutés à un compartiment Amazon S3. Vous pouvez suivre ce didacticiel en utilisant le AWS Command Line Interface (AWS CLI) ou le AWS Management Console.
Si vous recherchez un exemple plus simple pour apprendre à configurer un déclencheur Amazon S3 pour Lambda, vous pouvez consulter le [Didacticiel : utilisation d’un déclencheur Amazon S3 pour invoquer une fonction Lambda](https://docs.aws.amazon.com/lambda/latest/dg/with-s3-example.html).
**Topics**
+ [Conditions préalables](#with-s3-example-prereqs)
+ [Création de deux compartiments Amazon S3](#with-s3-tutorial-prepare-create-buckets)
+ [Charger une image de test dans votre compartiment source](#with-s3-tutorial-test-image)
+ [Création d’une stratégie d’autorisations](#with-s3-tutorial-create-policy)
+ [Créer un rôle d’exécution](#with-s3-tutorial-create-execution-role)
+ [Créer le package de déploiement de la fonction](#with-s3-tutorial-create-function-package)
+ [Créer la fonction Lambda](#with-s3-tutorial-create-function-createfunction)
+ [Configurer Amazon S3 pour invoquer la fonction](#with-s3-tutorial-configure-s3-trigger)
+ [Test de votre fonction Lambda à l’aide d’un événement fictif](#with-s3-tutorial-dummy-test)
+ [Tester votre fonction à l’aide du déclencheur Amazon S3](#with-s3-tutorial-test-s3)
+ [Nettoyage de vos ressources](#s3-tutorial-cleanup)
## Conditions préalables
Si vous souhaitez utiliser le AWS CLI pour terminer le didacticiel, installez la [dernière version du AWS Command Line Interface]().
Pour le code de votre fonction Lambda, vous pouvez utiliser Python ou Node.js. Installez les outils de prise en charge linguistique et un gestionnaire de packages pour le langage que vous souhaitez utiliser.
### Installez le AWS Command Line Interface
Si vous ne l'avez pas encore installé AWS Command Line Interface, suivez les étapes décrites dans la [section Installation ou mise à jour de la dernière version du AWS CLI pour l'](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)installer.
Ce tutoriel nécessite un terminal de ligne de commande ou un shell pour exécuter les commandes. Sous Linux et macOS, utilisez votre gestionnaire de shell et de package préféré.
**Note**
Sous Windows, certaines commandes CLI Bash que vous utilisez couramment avec Lambda (par exemple `zip`) ne sont pas prises en charge par les terminaux intégrés du système d’exploitation. [Installez le sous-système Windows pour Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10) afin d’obtenir une version intégrée à Windows d’Ubuntu et Bash.
## Création de deux compartiments Amazon S3
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-s3-tutorial/s3thumb_tut_steps1.png)
Créez d’abord deux compartiments Amazon S3. Le premier compartiment est le compartiment source dans lequel vous allez charger vos images. Le second compartiment est utilisé par Lambda pour enregistrer la miniature redimensionnée lorsque vous invoquez votre fonction.
------
#### [ AWS Management Console ]
**Pour créer les compartiments Amazon S3 (console)**
1. Ouvrez la [console Amazon S3](https://console.aws.amazon.com/s3) et sélectionnez la page **Compartiments à usage général**.
1. Sélectionnez le Région AWS plus proche de votre situation géographique. Vous pouvez modifier votre région à l’aide de la liste déroulante en haut de l’écran. Plus loin dans le didacticiel, vous devez créer votre fonction Lambda dans la même région.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/console_region_select.png)
1. Choisissez **Create bucket** (Créer un compartiment).
1. Sous **Configuration générale**, procédez comme suit :
1. Pour le **type de compartiment**, veillez à sélectionner **Usage général**.
1. Pour le **nom du compartiment**, saisissez un nom unique au monde qui respecte les [règles de dénomination du compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html) Amazon S3. Les noms de compartiment peuvent contenir uniquement des lettres minuscules, des chiffres, de points (.) et des traits d’union (-).
1. Conservez les valeurs par défaut de toutes les autres options et choisissez **Créer un compartiment**.
1. Répétez les étapes 1 à 5 pour créer votre compartiment de destination. Pour **Nom du compartiment**, saisissez `amzn-s3-demo-source-bucket-resized`, où `amzn-s3-demo-source-bucket` est le nom du compartiment source que vous venez de créer.
------
#### [ AWS CLI ]
**Pour créer les compartiments Amazon S3 (AWS CLI)**
1. Exécutez la commande CLI suivante pour créer votre compartiment source. Le nom que vous choisissez pour votre compartiment doit être unique au monde et respecter les [Règles de dénomination du compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html) Amazon S3. Les noms peuvent contenir uniquement des lettres minuscules, des chiffres, de points (.) et des traits d’union (-). Pour `region` et `LocationConstraint`, choisissez la [Région AWS](https://docs.aws.amazon.com/general/latest/gr/lambda-service.html) la plus proche de votre emplacement géographique.
```
aws s3api create-bucket --bucket amzn-s3-demo-source-bucket --region us-east-1 \
--create-bucket-configuration LocationConstraint=us-east-1
```
Plus loin dans le didacticiel, vous devez créer votre fonction Lambda dans le même Région AWS emplacement que votre compartiment source. Notez donc la région que vous avez choisie.
1. Exécutez la commande suivante pour créer votre compartiment de destination. Pour le nom du compartiment, vous devez utiliser `amzn-s3-demo-source-bucket-resized`, où `amzn-s3-demo-source-bucket` est le nom du compartiment source que vous avez créé à l’étape 1. Pour `region` et`LocationConstraint`, choisissez le même Région AWS que celui que vous avez utilisé pour créer votre bucket source.
```
aws s3api create-bucket --bucket amzn-s3-demo-source-bucket-resized --region us-east-1 \
--create-bucket-configuration LocationConstraint=us-east-1
```
------
## Charger une image de test dans votre compartiment source
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-s3-tutorial/s3thumb_tut_steps2.png)
Plus loin dans le didacticiel, vous testerez votre fonction Lambda en l'invoquant à l'aide de la console Lambda ou de AWS CLI la console Lambda. Pour confirmer que votre fonction fonctionne correctement, votre compartiment source doit contenir une image de test. Cette image peut être n’importe quel fichier JPG ou PNG de votre choix.
------
#### [ AWS Management Console ]
**Pour charger une image de test dans votre compartiment source (console)**
1. Ouvrez la page [Compartiments](https://console.aws.amazon.com/s3/buckets) de la console Amazon S3.
1. Sélectionnez le compartiment source que vous avez créé à l’étape précédente.
1. Choisissez **Charger**.
1. Choisissez **Ajouter des fichiers** et utilisez le sélecteur de fichiers pour sélectionner l’objet que vous souhaitez charger.
1. Choisissez **Ouvrir**, puis **Charger**.
------
#### [ AWS CLI ]
**Pour charger une image de test dans votre compartiment source (AWS CLI)**
+ À partir du répertoire contenant l’image que vous souhaitez charger, exécutez la commande CLI suivante. Remplacez le paramètre `--bucket` par le nom de votre compartiment source. Pour les paramètres `--key` et `--body`, utilisez le nom de fichier de votre image de test.
```
aws s3api put-object --bucket amzn-s3-demo-source-bucket --key HappyFace.jpg --body ./HappyFace.jpg
```
------
## Création d’une stratégie d’autorisations
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-s3-tutorial/s3thumb_tut_steps3.png)
La première étape de la création de votre fonction Lambda consiste à créer une politique d’autorisations. Cette politique donne à votre fonction les autorisations dont elle a besoin pour accéder à d'autres AWS ressources. Pour ce didacticiel, la politique donne à Lambda des autorisations de lecture et d'écriture pour les compartiments Amazon S3 et lui permet d'écrire dans Amazon Logs. CloudWatch
------
#### [ AWS Management Console ]
**Pour créer une politique (console)**
1. Ouvrez la page [Politiques](https://console.aws.amazon.com/iamv2/home#policies) de la console Gestion des identités et des accès AWS (IAM).
1. Choisissez **Create Policy** (Créer une politique).
1. Choisissez l’onglet **JSON**, puis collez la stratégie personnalisée suivante dans l’éditeur JSON.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:PutLogEvents",
"logs:CreateLogGroup",
"logs:CreateLogStream"
],
"Resource": "arn:aws:logs:*:*:*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": "arn:aws:s3:::*/*"
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::*/*"
}
]
}
```
1. Choisissez **Suivant**.
1. Sous **Détails de la politique**, pour le **Nom** de la politique, saisissez `LambdaS3Policy`.
1. Choisissez **Create Policy** (Créer une politique).
------
#### [ AWS CLI ]
**Pour créer la politique (AWS CLI)**
1. Enregistrez le JSON suivant dans un fichier nommé `policy.json`.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:PutLogEvents",
"logs:CreateLogGroup",
"logs:CreateLogStream"
],
"Resource": "arn:aws:logs:*:*:*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": "arn:aws:s3:::*/*"
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::*/*"
}
]
}
```
1. À partir du répertoire dans lequel vous avez enregistré le document de politique JSON, exécutez la commande CLI suivante.
```
aws iam create-policy --policy-name LambdaS3Policy --policy-document file://policy.json
```
------
## Créer un rôle d’exécution
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-s3-tutorial/s3thumb_tut_steps4.png)
Un rôle d'exécution est un rôle IAM qui accorde à une fonction Lambda l'autorisation d' Services AWS accès et de ressources. Pour donner à votre fonction un accès en lecture et en écriture à un compartiment Amazon S3, vous attachez la politique d’autorisation que vous avez créée à l’étape précédente.
------
#### [ AWS Management Console ]
**Pour créer un rôle d’exécution et attacher votre politique d’autorisations (console)**
1. Accédez à la Page [Rôles](https://console.aws.amazon.com/iamv2/home#roles) de la console (IAM).
1. Choisissez **Créer un rôle**.
1. Pour **Type d’entité fiable**, sélectionnez **Service AWS**, et pour **Cas d’utilisation**, sélectionnez **Lambda**.
1. Choisissez **Suivant**.
1. Ajoutez la politique d’autorisations que vous avez créée à l’étape précédente en procédant comme suit :
1. Dans la zone de recherche de stratégie, entrez `LambdaS3Policy`.
1. Dans les résultats de la recherche, cochez la case pour `LambdaS3Policy`.
1. Choisissez **Suivant**.
1. Sous **Détails du rôle**, pour le **Nom du rôle** entrez `LambdaS3Role`.
1. Choisissez **Créer un rôle**.
------
#### [ AWS CLI ]
**Pour créer un rôle d’exécution et attacher votre politique d’autorisations (AWS CLI)**
1. Enregistrez le JSON suivant dans un fichier nommé `trust-policy.json`. Cette politique de confiance permet à Lambda d'utiliser les autorisations du rôle en autorisant le principal `lambda.amazonaws.com` du service à appeler l'action AWS Security Token Service (AWS STS)`AssumeRole`.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. À partir du répertoire dans lequel vous avez enregistré le document de politique d’approbation JSON, exécutez la commande CLI suivante pour créer le rôle d’exécution.
```
aws iam create-role --role-name LambdaS3Role --assume-role-policy-document file://trust-policy.json
```
1. Pour attacher la politique d’autorisations que vous avez créée à l’étape précédente, exécutez la commande CLI suivante. Remplacez le Compte AWS numéro indiqué dans l'ARN de la politique par votre propre numéro de compte.
```
aws iam attach-role-policy --role-name LambdaS3Role --policy-arn arn:aws:iam::123456789012:policy/LambdaS3Policy
```
------
## Créer le package de déploiement de la fonction
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-s3-tutorial/s3thumb_tut_steps5.png)
Pour créer votre fonction, vous créez un *package de déploiement* contenant le code de votre fonction et ses dépendances. Pour cette fonction `CreateThumbnail`, votre code de fonction utilise une bibliothèque distincte pour le redimensionnement de l’image. Suivez les instructions correspondant à la langue de votre choix pour créer un package de déploiement contenant la bibliothèque requise.
------
#### [ Node.js ]
**Pour créer le package de déploiement (Node.js)**
1. Créez un répertoire nommé `lambda-s3` pour votre code de fonction et vos dépendances et accédez-y.
```
mkdir lambda-s3
cd lambda-s3
```
1. Créez un nouveau projet Node.js avec `npm`. Appuyez sur `Enter` pour accepter les options par défaut fournies dans l’expérience interactive.
```
npm init
```
1. Enregistrez le code de fonction suivant dans un fichier nommé `index.mjs`. Assurez-vous de remplacer `us-east-1` par l’ Région AWS dans lequel vous avez créé vos propres compartiments source et de destination.
```
// dependencies
import { S3Client, GetObjectCommand, PutObjectCommand } from '@aws-sdk/client-s3';
import { Readable } from 'stream';
import sharp from 'sharp';
import util from 'util';
// create S3 client
const s3 = new S3Client({region: 'us-east-1'});
// define the handler function
export const handler = async (event, context) => {
// Read options from the event parameter and get the source bucket
console.log("Reading options from event:\n", util.inspect(event, {depth: 5}));
const srcBucket = event.Records[0].s3.bucket.name;
// Object key may have spaces or unicode non-ASCII characters
const srcKey = decodeURIComponent(event.Records[0].s3.object.key.replace(/\+/g, " "));
const dstBucket = srcBucket + "-resized";
const dstKey = "resized-" + srcKey;
// Infer the image type from the file suffix
const typeMatch = srcKey.match(/\.([^.]*)$/);
if (!typeMatch) {
console.log("Could not determine the image type.");
return;
}
// Check that the image type is supported
const imageType = typeMatch[1].toLowerCase();
if (imageType != "jpg" && imageType != "png") {
console.log(`Unsupported image type: ${imageType}`);
return;
}
// Get the image from the source bucket. GetObjectCommand returns a stream.
try {
const params = {
Bucket: srcBucket,
Key: srcKey
};
var response = await s3.send(new GetObjectCommand(params));
var stream = response.Body;
// Convert stream to buffer to pass to sharp resize function.
if (stream instanceof Readable) {
var content_buffer = Buffer.concat(await stream.toArray());
} else {
throw new Error('Unknown object stream type');
}
} catch (error) {
console.log(error);
return;
}
// set thumbnail width. Resize will set the height automatically to maintain aspect ratio.
const width = 200;
// Use the sharp module to resize the image and save in a buffer.
try {
var output_buffer = await sharp(content_buffer).resize(width).toBuffer();
} catch (error) {
console.log(error);
return;
}
// Upload the thumbnail image to the destination bucket
try {
const destparams = {
Bucket: dstBucket,
Key: dstKey,
Body: output_buffer,
ContentType: "image"
};
const putResult = await s3.send(new PutObjectCommand(destparams));
} catch (error) {
console.log(error);
return;
}
console.log('Successfully resized ' + srcBucket + '/' + srcKey +
' and uploaded to ' + dstBucket + '/' + dstKey);
};
```
1. Dans votre répertoire `lambda-s3`, installez la bibliothèque sharp en utilisant npm. Notez que la dernière version de sharp (0.33) n’est pas compatible avec Lambda. Installez la version 0.32.6 pour terminer ce didacticiel.
```
npm install sharp@0.32.6
```
La commande npm `install` crée un répertoire `node_modules` pour vos modules. Après cette étape, votre structure de répertoire doit se présenter comme suit.
```
lambda-s3
|- index.mjs
|- node_modules
| |- base64js
| |- bl
| |- buffer
...
|- package-lock.json
|- package.json
```
1. Créez un package de déploiement .zip contenant le code de votre fonction et ses dépendances. Sous macOS ou Linux, exécutez les commandes suivantes.
```
zip -r function.zip .
```
Sous Windows, utilisez l’utilitaire zip de votre choix pour créer un fichier .zip. Assurez-vous que vos fichiers `index.mjs`, `package.json`, et `package-lock.json` ainsi que votre répertoire `node_modules` se trouvent tous à la racine de votre fichier .zip.
------
#### [ Python ]
**Pour créer le package de déploiement (Python)**
1. Enregistrez l’exemple de code en tant que fichier nommé `lambda_function.py`.
```
import boto3
import os
import sys
import uuid
from urllib.parse import unquote_plus
from PIL import Image
import PIL.Image
s3_client = boto3.client('s3')
def resize_image(image_path, resized_path):
with Image.open(image_path) as image:
image.thumbnail(tuple(x / 2 for x in image.size))
image.save(resized_path)
def lambda_handler(event, context):
for record in event['Records']:
bucket = record['s3']['bucket']['name']
key = unquote_plus(record['s3']['object']['key'])
tmpkey = key.replace('/', '')
download_path = '/tmp/{}{}'.format(uuid.uuid4(), tmpkey)
upload_path = '/tmp/resized-{}'.format(tmpkey)
s3_client.download_file(bucket, key, download_path)
resize_image(download_path, upload_path)
s3_client.upload_file(upload_path, '{}-resized'.format(bucket), 'resized-{}'.format(key))
```
1. Dans le même répertoire que celui dans lequel vous avez créé votre fichier `lambda_function.py`, créez un nouveau répertoire nommé `package` et installez la bibliothèque [Pillow (PIL)](https://pypi.org/project/Pillow/) et AWS SDK pour Python (Boto3). Bien que l’exécution Lambda Python inclut une version du kit SDK Boto3, nous vous recommandons d’ajouter toutes les dépendances de votre fonction à votre package de déploiement, même si elles sont incluses dans l’exécution. Pour plus d’informations, consultez la [Dépendances d’exécution en Python](https://docs.aws.amazon.com/lambda/latest/dg/python-package.html#python-package-dependencies).
```
mkdir package
pip install \
--platform manylinux2014_x86_64 \
--target=package \
--implementation cp \
--python-version 3.12 \
--only-binary=:all: --upgrade \
pillow boto3
```
La bibliothèque Pillow contient du code C/C\$1\$1. En utilisant les options `--platform manylinux_2014_x86_64` et `--only-binary=:all:`, pip téléchargera et installera une version de Pillow contenant des fichiers binaires précompilés compatibles avec le système d’exploitation Amazon Linux 2. Cela garantit que votre package de déploiement fonctionnera dans l’environnement d’exécution Lambda, quels que soient le système d’exploitation et l’architecture de votre ordinateur de création local.
1. Créez un fichier .zip contenant le code de votre application et les bibliothèques Pillow et Boto3. Sous Linux ou macOS, exécutez les commandes suivantes depuis votre interface de ligne de commande.
```
cd package
zip -r ../lambda_function.zip .
cd ..
zip lambda_function.zip lambda_function.py
```
Sous Windows, utilisez l’outil zip de votre choix pour créer le fichier `lambda_function.zip`. Assurez-vous que votre fichier `lambda_function.py` et les dossiers contenant vos dépendances sont installés à la racine du fichier .zip.
Vous pouvez également créer votre package de déploiement à l’aide d’un environnement virtuel Python. Consultez [Travailler avec des archives de fichiers .zip pour les fonctions Lambda Python](python-package.md)
------
## Créer la fonction Lambda
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-s3-tutorial/s3thumb_tut_steps6.png)
Vous pouvez créer votre fonction Lambda à l'aide de la console Lambda AWS CLI ou de la console Lambda. Suivez les instructions correspondant à la langue de votre choix pour créer la fonction.
------
#### [ AWS Management Console ]
**Pour créer une fonction (console)**
Pour créer votre fonction Lambda à l’aide de la console, vous devez d’abord créer une fonction de base contenant du code « Hello world ». Vous remplacez ensuite ce code par votre propre code de fonction en chargeant le fichier .zip ou JAR que vous avez créé à l’étape précédente.
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Assurez-vous de travailler dans le même environnement que celui dans Région AWS lequel vous avez créé votre compartiment Amazon S3. Vous pouvez modifier votre région à l’aide de la liste déroulante en haut de l’écran.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/console_region_select.png)
1. Choisissez **Créer une fonction**.
1. Choisissez **Créer à partir de zéro**.
1. Sous **Informations de base**, procédez comme suit :
1. Sous **Nom de la fonction**, saisissez `CreateThumbnail`.
1. Pour **Environnement d’exécution**, choisissez **Node.js 22.x** ou **Python 3.12** en fonction du langage que vous avez choisi pour votre fonction.
1. Pour **Architecture**, choisissez **x86\$164**.
1. Dans l’onglet **Modifier le rôle d’exécution par défaut**, procédez comme suit :
1. Ouvrez l’onglet, puis choisissez **Utiliser un rôle existant**.
1. Sélectionnez le `LambdaS3Role` que vous avez créé précédemment.
1. Choisissez **Créer une fonction**.
**Pour charger le code de fonction (console)**
1. Dans le volet **Source du code**, choisissez **Charger à partir de**.
1. Choisissez **Fichier .zip**.
1. Choisissez **Charger**.
1. Dans le sélecteur de fichiers, sélectionnez votre fichier .zip et choisissez **Ouvrir**.
1. Choisissez **Enregistrer**.
------
#### [ AWS CLI ]
**Pour créer la fonction (AWS CLI)**
+ Exécutez la commande CLI pour la langue que vous avez choisie. Pour le `role` paramètre, assurez-vous de le remplacer `123456789012` par votre propre Compte AWS identifiant. Pour le paramètre `region`, remplacez `us-east-1` par la région dans laquelle vous avez créé vos compartiments Amazon S3.
+ Pour **Node.js**, exécutez la commande suivante depuis le répertoire contenant votre fichier `function.zip`.
```
aws lambda create-function --function-name CreateThumbnail \
--zip-file fileb://function.zip --handler index.handler --runtime nodejs24.x \
--timeout 10 --memory-size 1024 \
--role arn:aws:iam::123456789012:role/LambdaS3Role --region us-east-1
```
+ Pour **Python**, exécutez la commande suivante depuis le répertoire contenant votre fichier `lambda_function.zip`.
```
aws lambda create-function --function-name CreateThumbnail \
--zip-file fileb://lambda_function.zip --handler lambda_function.lambda_handler \
--runtime python3.14 --timeout 10 --memory-size 1024 \
--role arn:aws:iam::123456789012:role/LambdaS3Role --region us-east-1
```
------
## Configurer Amazon S3 pour invoquer la fonction
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-s3-tutorial/s3thumb_tut_steps7.png)
Pour que votre fonction Lambda s’exécute lorsque vous chargez une image dans votre compartiment source, vous devez configurer un déclencheur pour votre fonction. Vous pouvez configurer le déclencheur Amazon S3 à l’aide de la console ou de la AWS CLI.
**Important**
Cette procédure configure le compartiment Amazon S3 pour qu’il invoque votre fonction chaque fois qu’un objet est créé dans le compartiment. Veillez à configurer cela uniquement pour le compartiment source. Si votre fonction Lambda crée des objets dans le même compartiment que celui qui l’invoque, votre fonction peut être [invoquée en continu dans une boucle](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/recursive-runaway). Cela peut entraîner la facturation de frais imprévus à votre Compte AWS charge.
------
#### [ AWS Management Console ]
**Pour configurer le déclencheur Amazon S3 (console)**
1. Ouvrez la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda et choisissez votre fonction (`CreateThumbnail`).
1. Choisissez **Add trigger (Ajouter déclencheur)**.
1. Sélectionnez **S3**.
1. Sous **Compartiment**, sélectionnez votre compartiment source.
1. Sous **Types d’événements**, sélectionnez **Tous les événements de création d’objets**.
1. Sous **Invocation récursive**, cochez la case pour confirmer qu’il n’est pas recommandé d’utiliser le même compartiment Amazon S3 pour les entrées et les sorties. Vous pouvez en savoir plus sur les modèles d’invocation récursive dans Lambda en lisant la rubrique [Modèles récursifs qui provoquent des fonctions Lambda incontrôlables dans Serverless Land](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/recursive-runaway).
1. Choisissez **Ajouter**.
Lorsque vous créez un déclencheur à l’aide de la console Lambda, ce dernier crée automatiquement une [politique basée sur une ressource](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html) pour donner au service que vous sélectionnez l’autorisation d’invoquer votre fonction.
------
#### [ AWS CLI ]
**Pour configurer le déclencheur Amazon S3 (AWS CLI)**
1. Pour que votre compartiment source Amazon S3 invoque votre fonction lorsque vous ajoutez un fichier image, vous devez d’abord configurer les autorisations pour votre fonction à l’aide d’une [politique basée sur une ressource](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html). Une déclaration de politique basée sur les ressources donne à d'autres personnes Services AWS l'autorisation d'invoquer votre fonction. Pour autoriser Amazon S3 à invoquer votre fonction, exécutez la commande CLI suivante. Assurez-vous de remplacer le `source-account` paramètre par votre propre Compte AWS identifiant et d'utiliser votre propre nom de compartiment source.
```
aws lambda add-permission --function-name CreateThumbnail \
--principal s3.amazonaws.com --statement-id s3invoke --action "lambda:InvokeFunction" \
--source-arn arn:aws:s3:::amzn-s3-demo-source-bucket \
--source-account 123456789012
```
La politique que vous définissez à l’aide de cette commande permet à Amazon S3 d’invoquer votre fonction uniquement lorsqu’une action a lieu sur votre compartiment source.
**Note**
Bien que les noms des compartiments Amazon S3 soient globalement uniques, il est préférable de spécifier que le compartiment doit appartenir à votre compte lorsque vous utilisez des politiques basées sur les ressources. En effet, si vous supprimez un bucket, il est possible qu'un autre Compte AWS en crée un avec le même Amazon Resource Name (ARN).
1. Enregistrez le JSON suivant dans un fichier nommé `notification.json`. Lorsqu’il est appliqué à votre compartiment source, ce JSON configure le compartiment pour qu’il envoie une notification à votre fonction Lambda chaque fois qu’un nouvel objet est ajouté. Remplacez le Compte AWS numéro et, Région AWS dans la fonction Lambda, l'ARN par votre propre numéro de compte et votre propre région.
```
{
"LambdaFunctionConfigurations": [
{
"Id": "CreateThumbnailEventConfiguration",
"LambdaFunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:CreateThumbnail",
"Events": [ "s3:ObjectCreated:Put" ]
}
]
}
```
1. Exécutez la commande CLI suivante pour appliquer les paramètres de notification du fichier JSON que vous avez créé à votre compartiment source. Remplacez `amzn-s3-demo-source-bucket` par le nom de votre propre compartiment source.
```
aws s3api put-bucket-notification-configuration --bucket amzn-s3-demo-source-bucket \
--notification-configuration file://notification.json
```
Pour en savoir plus sur la `put-bucket-notification-configuration` commande et l'`notification-configuration`option, consultez le manuel de *référence [put-bucket-notification-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/put-bucket-notification-configuration.html)des commandes de la AWS CLI*.
------
## Test de votre fonction Lambda à l’aide d’un événement fictif
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-s3-tutorial/s3thumb_tut_steps8.png)
Avant de tester l’ensemble de votre configuration en ajoutant un fichier image à votre compartiment source Amazon S3, vous devez vérifier que votre fonction Lambda fonctionne correctement en l’invoquant avec un événement fictif. Un événement dans Lambda est un document au format JSON qui contient des données à traiter par votre fonction. Lorsque votre fonction est invoquée par Amazon S3, l’événement envoyé à votre fonction contient des informations telles que le nom du compartiment, l’ARN du compartiment et la clé de l’objet.
------
#### [ AWS Management Console ]
**Pour tester votre fonction Lambda à l’aide d’un événement fictif (console)**
1. Ouvrez la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda et choisissez votre fonction (`CreateThumbnail`).
1. Choisissez l’onglet **Test**.
1. Pour créer votre événement de test, dans le volet **Événement de test**, procédez comme suit :
1. Sous **Action d’événement de test**, sélectionnez **Créer un nouvel événement**.
1. Dans **Event name** (Nom de l’événement), saisissez **myTestEvent**.
1. Pour **Modèle**, sélectionnez **S3 Put**.
1. Remplacez les valeurs des paramètres suivants par vos propres valeurs.
+ Pour`awsRegion`, remplacez-le `us-east-1` par celui dans Région AWS lequel vous avez créé vos compartiments Amazon S3.
+ Pour `name`, remplacez `amzn-s3-demo-bucket` par le nom de votre propre compartiment source Amazon S3.
+ Pour `key`, remplacez `test%2Fkey` par le nom de fichier de l’objet de test que vous avez chargé dans votre compartiment source à l’étape [Charger une image de test dans votre compartiment source](#with-s3-tutorial-test-image).
```
{
"Records": [
{
"eventVersion": "2.0",
"eventSource": "aws:s3",
"awsRegion": "us-east-1",
"eventTime": "1970-01-01T00:00:00.000Z",
"eventName": "ObjectCreated:Put",
"userIdentity": {
"principalId": "EXAMPLE"
},
"requestParameters": {
"sourceIPAddress": "127.0.0.1"
},
"responseElements": {
"x-amz-request-id": "EXAMPLE123456789",
"x-amz-id-2": "EXAMPLE123/5678abcdefghijklambdaisawesome/mnopqrstuvwxyzABCDEFGH"
},
"s3": {
"s3SchemaVersion": "1.0",
"configurationId": "testConfigRule",
"bucket": {
"name": "amzn-s3-demo-bucket",
"ownerIdentity": {
"principalId": "EXAMPLE"
},
"arn": "arn:aws:s3:::amzn-s3-demo-bucket"
},
"object": {
"key": "test%2Fkey",
"size": 1024,
"eTag": "0123456789abcdef0123456789abcdef",
"sequencer": "0A1B2C3D4E5F678901"
}
}
}
]
}
```
1. Choisissez **Enregistrer**.
1. Dans le volet **Événement de test**, choisissez **Test**.
1. Pour vérifier que votre fonction a créé une version redimensionnée de votre image et l’a stockée dans votre compartiment Amazon S3 cible, procédez comme suit :
1. Ouvrez la [page Compartiments](https://console.aws.amazon.com/s3/buckets) de la console Amazon S3.
1. Choisissez votre compartiment cible et vérifiez que votre fichier redimensionné est répertorié dans le volet **Objets**.
------
#### [ AWS CLI ]
**Pour tester de votre fonction Lambda à l’aide d’un événement fictif (AWS CLI)**
1. Enregistrez le JSON suivant dans un fichier nommé `dummyS3Event.json`. Remplacez les valeurs des paramètres suivants par vos propres valeurs :
+ Pour`awsRegion`, remplacez-le `us-east-1` par celui dans Région AWS lequel vous avez créé vos compartiments Amazon S3.
+ Pour `name`, remplacez `amzn-s3-demo-bucket` par le nom de votre propre compartiment source Amazon S3.
+ Pour `key`, remplacez `test%2Fkey` par le nom de fichier de l’objet de test que vous avez chargé dans votre compartiment source à l’étape [Charger une image de test dans votre compartiment source](#with-s3-tutorial-test-image).
```
{
"Records": [
{
"eventVersion": "2.0",
"eventSource": "aws:s3",
"awsRegion": "us-east-1",
"eventTime": "1970-01-01T00:00:00.000Z",
"eventName": "ObjectCreated:Put",
"userIdentity": {
"principalId": "EXAMPLE"
},
"requestParameters": {
"sourceIPAddress": "127.0.0.1"
},
"responseElements": {
"x-amz-request-id": "EXAMPLE123456789",
"x-amz-id-2": "EXAMPLE123/5678abcdefghijklambdaisawesome/mnopqrstuvwxyzABCDEFGH"
},
"s3": {
"s3SchemaVersion": "1.0",
"configurationId": "testConfigRule",
"bucket": {
"name": "amzn-s3-demo-bucket",
"ownerIdentity": {
"principalId": "EXAMPLE"
},
"arn": "arn:aws:s3:::amzn-s3-demo-bucket"
},
"object": {
"key": "test%2Fkey",
"size": 1024,
"eTag": "0123456789abcdef0123456789abcdef",
"sequencer": "0A1B2C3D4E5F678901"
}
}
}
]
}
```
1. À partir du répertoire dans lequel vous avez enregistré votre fichier `dummyS3Event.json`, invoquez la fonction en exécutant la commande CLI suivante. Cette commande invoque votre fonction Lambda de manière synchrone en la spécifiant `RequestResponse` comme valeur du paramètre de type d’invocation. Pour en savoir plus sur l’invocation synchrone et asynchrone, consultez [Invocation de fonctions Lambda.](https://docs.aws.amazon.com/lambda/latest/dg/lambda-invocation.html)
```
aws lambda invoke --function-name CreateThumbnail \
--invocation-type RequestResponse --cli-binary-format raw-in-base64-out \
--payload file://dummyS3Event.json outputfile.txt
```
cli-binary-formatCette option est obligatoire si vous utilisez la version 2 du AWS CLI. Pour faire de ce paramètre le paramètre par défaut, exécutez `aws configure set cli-binary-format raw-in-base64-out`. Pour plus d’informations, veuillez consulter les [AWS CLI options de ligne de commande](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list).
1. Vérifiez que votre fonction a créé une version miniature de votre image et l’a enregistrée dans votre compartiment Amazon S3 cible. Exécutez la commande CLI suivante, en remplaçant `amzn-s3-demo-source-bucket-resized` par le nom de votre compartiment de destination.
```
aws s3api list-objects-v2 --bucket amzn-s3-demo-source-bucket-resized
```
Vous devez visualiser des résultats similaires à ce qui suit. Le paramètre `Key` indique le nom de fichier de votre fichier image redimensionné.
```
{
"Contents": [
{
"Key": "resized-HappyFace.jpg",
"LastModified": "2023-06-06T21:40:07+00:00",
"ETag": "\"d8ca652ffe83ba6b721ffc20d9d7174a\"",
"Size": 2633,
"StorageClass": "STANDARD"
}
]
}
```
------
## Tester votre fonction à l’aide du déclencheur Amazon S3
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-s3-tutorial/s3thumb_tut_steps9.png)
Maintenant que vous avez confirmé que votre fonction Lambda fonctionne correctement, vous êtes prêt à tester votre configuration complète en ajoutant un fichier image à votre compartiment source Amazon S3. Lorsque vous ajoutez votre image au compartiment source, votre fonction Lambda doit être automatiquement invoquée. Votre fonction crée une version redimensionnée du fichier et la stocke dans votre compartiment cible.
------
#### [ AWS Management Console ]
**Pour tester votre fonction Lambda à l’aide du déclencheur Amazon S3 (console)**
1. Pour charger une image dans votre compartiment Amazon S3, procédez comme suit :
1. Ouvrez la page [Compartiments](https://console.aws.amazon.com/s3/buckets) de la console Amazon S3 et choisissez votre compartiment source.
1. Choisissez **Charger**.
1. Choisissez **Ajouter des fichiers** et utilisez le sélecteur de fichiers pour sélectionner le fichier image que vous souhaitez charger. Votre objet image peut être n’importe quel fichier .jpg ou .png.
1. Choisissez **Ouvrir**, puis **Charger**.
1. Vérifiez que Lambda a enregistré une version redimensionnée de votre fichier image dans votre compartiment cible en procédant comme suit :
1. Retournez à la page [Compartiments](https://console.aws.amazon.com/s3/buckets) de la console Amazon S3 et choisissez votre compartiment de destination.
1. Dans le volet **Objets**, vous devriez maintenant voir deux fichiers image redimensionnés, un pour chaque test de votre fonction Lambda. Pour télécharger votre image redimensionnée, sélectionnez le fichier, puis choisissez **Télécharger**.
------
#### [ AWS CLI ]
**Pour tester votre fonction Lambda à l’aide du déclencheur Amazon S3 (AWS CLI)**
1. À partir du répertoire contenant l’image que vous souhaitez charger, exécutez la commande CLI suivante. Remplacez le paramètre `--bucket` par le nom de votre compartiment source. Pour les paramètres `--key` et `--body`, utilisez le nom de fichier de votre image de test. Votre image de test peut être n’importe quel fichier .jpg ou .png.
```
aws s3api put-object --bucket amzn-s3-demo-source-bucket --key SmileyFace.jpg --body ./SmileyFace.jpg
```
1. Vérifiez que votre fonction a créé une version miniature de votre image et l’a enregistrée dans votre compartiment Amazon S3 cible. Exécutez la commande CLI suivante, en remplaçant `amzn-s3-demo-source-bucket-resized` par le nom de votre compartiment de destination.
```
aws s3api list-objects-v2 --bucket amzn-s3-demo-source-bucket-resized
```
Si votre fonction s’exécute correctement, vous obtiendrez un résultat similaire à celui qui suit. Votre compartiment cible doit désormais contenir deux fichiers redimensionnés.
```
{
"Contents": [
{
"Key": "resized-HappyFace.jpg",
"LastModified": "2023-06-07T00:15:50+00:00",
"ETag": "\"7781a43e765a8301713f533d70968a1e\"",
"Size": 2763,
"StorageClass": "STANDARD"
},
{
"Key": "resized-SmileyFace.jpg",
"LastModified": "2023-06-07T00:13:18+00:00",
"ETag": "\"ca536e5a1b9e32b22cd549e18792cdbc\"",
"Size": 1245,
"StorageClass": "STANDARD"
}
]
}
```
------
## Nettoyage de vos ressources
Vous pouvez maintenant supprimer les ressources que vous avez créées pour ce didacticiel, sauf si vous souhaitez les conserver. En supprimant AWS les ressources que vous n'utilisez plus, vous évitez des frais inutiles pour votre Compte AWS.
**Pour supprimer la fonction Lambda**
1. Ouvrez la [page Functions (Fonctions)](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda.
1. Sélectionnez la fonction que vous avez créée.
1. Sélectionnez **Actions**, **Supprimer**.
1. Saisissez **confirm** dans la zone de saisie de texte et choisissez **Delete** (Supprimer).
**Suppression de la stratégie que vous avez créée**
1. Ouvrez la [page Policies (Stratégies)](https://console.aws.amazon.com/iam/home#/policies) de la console IAM.
1. Sélectionnez la politique que vous avez créée (**AWSLambdaS3Policy**).
1. Choisissez **Actions de stratégie**, **Supprimer**.
1. Sélectionnez **Delete (Supprimer)**.
**Pour supprimer le rôle d’exécution**
1. Ouvrez la [page Roles (Rôles)](https://console.aws.amazon.com/iam/home#/roles) de la console IAM.
1. Sélectionnez le rôle d’exécution que vous avez créé.
1. Sélectionnez **Delete (Supprimer)**.
1. Saisissez le nom du rôle dans le champ de saisie de texte et choisissez **Delete** (Supprimer).
**Pour supprimer le compartiment S3**
1. Ouvrez la [console Amazon S3](https://console.aws.amazon.com//s3/home#).
1. Sélectionnez le compartiment que vous avez créé.
1. Sélectionnez **Delete (Supprimer)**.
1. Saisissez le nom du compartiment dans le champ de saisie de texte.
1. Choisissez **Supprimer le compartiment**.
# Utiliser des secrets Secrets Manager dans des fonctions Lambda
AWS Secrets Manager vous aide à gérer les informations d'identification, les clés d'API et les autres secrets dont vos fonctions Lambda ont besoin. Vous disposez de deux approches principales pour récupérer des secrets dans vos fonctions Lambda, toutes deux offrant de meilleures performances et des coûts réduits par rapport à la récupération de secrets directement à l'aide du SDK : AWS
+ **AWS paramètres et secrets Extension Lambda** : solution indépendante de l'exécution qui fournit une interface HTTP simple pour récupérer les secrets
+ **Utilitaire Powertools for AWS Lambda Parameters** : solution intégrée au code qui prend en charge plusieurs fournisseurs (Secrets Manager, Parameter Store AppConfig) avec des transformations intégrées
Les deux approches conservent des caches locaux de secrets, ce qui évite à votre fonction d’appeler Secrets Manager pour chaque invocation. Lorsque votre fonction demande un secret, le cache est d’abord vérifié. Si le secret est disponible et n’a pas expiré, il est renvoyé immédiatement. Sinon, il est extrait de Secrets Manager, mis en cache et renvoyé. Ce mécanisme de mise en cache permet d’accélérer les temps de réponse et de réduire les coûts en minimisant les appels d’API.
## Choix d’une approche
Tenez compte des facteurs suivants lorsque vous choisissez entre l'extension et PowerTools :
Utilisez l'extension Lambda de AWS paramètres et de secrets lorsque :
+ Vous recherchez une solution indépendante de l’environnement d’exécution qui fonctionne avec n’importe quel environnement d’exécution Lambda
+ Vous préférez ne pas ajouter de dépendances de code à votre fonction
+ Vous souhaitez seulement récupérer des secrets à partir de Secrets Manager ou de Parameter Store
Utilisez Powertools pour l'utilitaire AWS Lambda de paramètres lorsque :
+ Vous souhaitez bénéficier d’une expérience de développement intégrée au code de votre application
+ Vous avez besoin d'assistance pour plusieurs fournisseurs (Secrets Manager, Parameter Store, AppConfig)
+ Vous souhaitez des transformations de données intégrées (analyse JSON, décodage Base64)
+ Vous utilisez des environnements d'exécution Python TypeScript, Java ou .NET
## Quand utiliser Secrets Manager avec Lambda
Les scénarios courants d’utilisation de Secrets Manager avec Lambda comprennent les suivants :
+ Stockage d’informations d’identification de base de données que votre fonction utilise pour se connecter à Amazon RDS ou d’autres bases de données
+ Gestion des clés d’API pour les services externes appelés par votre fonction
+ Stockage des clés de chiffrement ou d’autres données de configuration sensibles
+ Rotation automatique des informations d’identification sans qu’il soit nécessaire de mettre à jour le code de votre fonction
## Utilisation des AWS paramètres et des secrets de l'extension Lambda
L'extension Lambda de AWS paramètres et de secrets utilise une interface HTTP simple compatible avec n'importe quel environnement d'exécution Lambda. Par défaut, elle met en cache les secrets pendant 300 secondes (5 minutes) et peut contenir jusqu’à 1 000 secrets. Vous pouvez [personnaliser ces paramètres à l’aide de variables d’environnement](#lambda-secrets-manager-env-vars).
### Utiliser Secrets Manager dans une fonction Lambda
Cette section part du principe que vous possédez déjà un secret Secrets Manager. Pour créer un secret, voir [Création d'un AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html).
#### Création du package de déploiement
Choisissez votre environnement d’exécution préféré et suivez les étapes pour créer une fonction qui récupère les secrets depuis Secrets Manager. L’exemple de fonction extrait un secret dans Secrets Manager et peut être utilisé pour accéder aux informations d’identification de base de données, aux clés d’API ou à d’autres données de configuration sensibles dans vos applications.
------
#### [ Python ]
**Pour créer une fonction Python**
1. Créez et accédez à un nouveau répertoire de projet. Exemple :
```
mkdir my_function
cd my_function
```
1. Créez un fichier nommé `lambda_function.py` avec le code suivant. Pour `secret_name`, utilisez le nom ou l’Amazon Resource Name (ARN) de votre secret.
```
import json
import os
import requests
def lambda_handler(event, context):
try:
# Replace with the name or ARN of your secret
secret_name = "arn:aws:secretsmanager:us-east-1:111122223333:secret:SECRET_NAME"
secrets_extension_endpoint = f"http://localhost:2773/secretsmanager/get?secretId={secret_name}"
headers = {"X-Aws-Parameters-Secrets-Token": os.environ.get('AWS_SESSION_TOKEN')}
response = requests.get(secrets_extension_endpoint, headers=headers)
print(f"Response status code: {response.status_code}")
secret = json.loads(response.text)["SecretString"]
print(f"Retrieved secret: {secret}")
return {
'statusCode': response.status_code,
'body': json.dumps({
'message': 'Successfully retrieved secret',
'secretRetrieved': True
})
}
except Exception as e:
print(f"Error: {str(e)}")
return {
'statusCode': 500,
'body': json.dumps({
'message': 'Error retrieving secret',
'error': str(e)
})
}
```
1. Créez un fichier nommé `requirements.txt` avec ce contenu :
```
requests
```
1. Installez les dépendances :
```
pip install -r requirements.txt -t .
```
1. Créez un fichier .zip contenant tous les fichiers :
```
zip -r function.zip .
```
------
#### [ Node.js ]
**Pour créer une fonction Node.js.**
1. Créez et accédez à un nouveau répertoire de projet. Exemple :
```
mkdir my_function
cd my_function
```
1. Créez un fichier nommé `index.mjs` avec le code suivant. Pour `secret_name`, utilisez le nom ou l’Amazon Resource Name (ARN) de votre secret.
```
import http from 'http';
export const handler = async (event) => {
try {
// Replace with the name or ARN of your secret
const secretName = "arn:aws:secretsmanager:us-east-1:111122223333:secret:SECRET_NAME";
const options = {
hostname: 'localhost',
port: 2773,
path: `/secretsmanager/get?secretId=${secretName}`,
headers: {
'X-Aws-Parameters-Secrets-Token': process.env.AWS_SESSION_TOKEN
}
};
const response = await new Promise((resolve, reject) => {
http.get(options, (res) => {
let data = '';
res.on('data', (chunk) => { data += chunk; });
res.on('end', () => {
resolve({
statusCode: res.statusCode,
body: data
});
});
}).on('error', reject);
});
const secret = JSON.parse(response.body).SecretString;
console.log('Retrieved secret:', secret);
return {
statusCode: response.statusCode,
body: JSON.stringify({
message: 'Successfully retrieved secret',
secretRetrieved: true
})
};
} catch (error) {
console.error('Error:', error);
return {
statusCode: 500,
body: JSON.stringify({
message: 'Error retrieving secret',
error: error.message
})
};
}
};
```
1. Créez un fichier .zip contient le fichier `index.mjs`.
```
zip -r function.zip index.mjs
```
------
#### [ Java ]
**Pour créer une fonction Java**
1. Créez un projet Maven :
```
mvn archetype:generate \
-DgroupId=example \
-DartifactId=lambda-secrets-demo \
-DarchetypeArtifactId=maven-archetype-quickstart \
-DarchetypeVersion=1.4 \
-DinteractiveMode=false
```
1. Accédez au répertoire du projet :
```
cd lambda-secrets-demo
```
1. Ouvrez `pom.xml` et remplacez le contenu par ce qui suit :
```
4.0.0
example
lambda-secrets-demo
1.0-SNAPSHOT
11
11
com.amazonaws
aws-lambda-java-core
1.2.1
org.apache.maven.plugins
maven-shade-plugin
3.2.4
package
shade
false
function
```
1. Renommez `/lambda-secrets-demo/src/main/java/example/App.java` en `Hello.java` pour qu’il corresponde au nom du gestionnaire Java par défaut de Lambda (`example.Hello::handleRequest`) :
```
mv src/main/java/example/App.java src/main/java/example/Hello.java
```
1. Ouvrez le fichier `Hello.java` et remplacez son contenu par ce qui suit. Pour `secretName`, utilisez le nom ou l’Amazon Resource Name (ARN) de votre secret.
```
package example;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
public class Hello implements RequestHandler {
private final HttpClient client = HttpClient.newHttpClient();
@Override
public String handleRequest(Object input, Context context) {
try {
// Replace with the name or ARN of your secret
String secretName = "arn:aws:secretsmanager:us-east-1:111122223333:secret:SECRET_NAME";
String endpoint = "http://localhost:2773/secretsmanager/get?secretId=" + secretName;
HttpRequest request = HttpRequest.newBuilder()
.uri(URI.create(endpoint))
.header("X-Aws-Parameters-Secrets-Token", System.getenv("AWS_SESSION_TOKEN"))
.GET()
.build();
HttpResponse response = client.send(request,
HttpResponse.BodyHandlers.ofString());
String secret = response.body();
secret = secret.substring(secret.indexOf("SecretString") + 15);
secret = secret.substring(0, secret.indexOf("\""));
System.out.println("Retrieved secret: " + secret);
return String.format(
"{\"statusCode\": %d, \"body\": \"%s\"}",
response.statusCode(), "Successfully retrieved secret"
);
} catch (Exception e) {
e.printStackTrace();
return String.format(
"{\"body\": \"Error retrieving secret: %s\"}",
e.getMessage()
);
}
}
}
```
1. Supprimez le répertoire de test. Maven le crée par défaut, mais nous n’en avons pas besoin pour cet exemple.
```
rm -rf src/test
```
1. Générez le projet :
```
mvn package
```
1. Téléchargez le fichier JAR (`target/function.jar`) pour une utilisation ultérieure.
------
#### Créer la fonction
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez **Créer une fonction**.
1. Sélectionnez **Créer à partir de zéro**.
1. Sous **Nom de la fonction**, saisissez **secret-retrieval-demo**.
1. Choisissez votre **Environnement d’exécution** préféré.
1. Choisissez **Créer une fonction**.
**Charger un package de déploiement**
1. Dans l’onglet **Code** de la fonction, choisissez **Charger à partir de** et sélectionnez **Fichier .zip** (pour Python et Node.js) ou **Fichier .jar** (pour Java).
1. Chargez le package de déploiement créé précédemment.
1. Choisissez **Enregistrer**.
#### Ajouter l’extension
**Pour ajouter l'extension Lambda AWS Parameters and Secrets en tant que couche**
1. Dans l’onglet **Code** de la fonction, faites défiler la page jusqu’à **Couches**.
1. Choisissez **Add a layer (Ajouter une couche)**.
1. Sélectionnez **Couches AWS **.
1. Choisissez **AWS-Parameters-and-Secrets-Lambda-Extension**.
1. Sélectionnez la dernière version.
1. Choisissez **Ajouter**.
#### Ajout d’autorisations
**Ajouter des autorisations Secrets Manager à votre rôle d’exécution**
1. Choisissez l’onglet **Configuration**, puis **Permissions** (Autorisations).
1. Sous **Nom du rôle**, cliquez sur le lien vers votre rôle d’exécution. Ce lien ouvre le rôle dans la console IAM.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/execution-role-console.png)
1. Sélectionnez **Ajouter des autorisations**, puis **Ajouter la politique**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/create-inline-policy.png)
1. Choisissez l’onglet **JSON** et ajoutez la politique suivante. Pour `Resource`, saisissez l’ARN de votre secret.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:us-east-1:111122223333:secret:SECRET_NAME"
}
]
}
```
------
1. Choisissez **Suivant**.
1. Entrez le nom de la politique.
1. Choisissez **Create Policy** (Créer une politique).
#### Tester la fonction
**Pour tester la fonction**
1. Retournez à la console Lambda.
1. Sélectionnez l’onglet **Test**.
1. Sélectionnez **Tester)**. Vous devriez voir la réponse suivante :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/execution-results-secret.png)
### Variables d’environnement
L'extension Lambda AWS Parameters and Secrets utilise les paramètres par défaut suivants. Vous pouvez remplacer ces paramètres en créant les [variables d’environnement](configuration-envvars.md#create-environment-variables) correspondantes. Pour afficher les paramètres actuels d’une fonction, réglez `PARAMETERS_SECRETS_EXTENSION_LOG_LEVEL` sur `DEBUG`. L'extension enregistre ses informations de configuration dans CloudWatch Logs au début de chaque appel de fonction.
| Paramètre | Valeur par défaut | Valeurs valides | Variable d'environnement | Détails |
| --- | --- | --- | --- | --- |
| Port HTTP | 2773 | 1 – 65535 | PARAMETERS\$1SECRETS\$1EXTENSION\$1HTTP\$1PORT | Port du serveur HTTP local |
| Cache activé | TRUE | TRUE \$1 FALSE | PARAMETERS\$1SECRETS\$1EXTENSION\$1CACHE\$1ENABLED | Activer ou désactiver le cache |
| Taille du cache | 1 000 | 0 - 1000 | PARAMETERS\$1SECRETS\$1EXTENSION\$1CACHE\$1SIZE | Définissez cette valeur sur 0 pour désactiver la mise en cache |
| TTL de Secrets Manager | 300 secondes | 0 à 300 secondes | SECRETS\$1MANAGER\$1TTL | Time-to-live pour les secrets mis en cache. Définissez sur 0 pour désactiver la mise en cache. Cette variable est ignorée si la valeur de PARAMETERS\$1SECRETS\$1EXTENSION\$1CACHE\$1SIZE est de 0. |
| TTL du magasin de paramètres | 300 secondes | 0 à 300 secondes | SSM\$1PARAMETER\$1STORE\$1TTL | Time-to-live pour les paramètres mis en cache. Définissez sur 0 pour désactiver la mise en cache. Cette variable est ignorée si la valeur de PARAMETERS\$1SECRETS\$1EXTENSION\$1CACHE\$1SIZE est de 0. |
| Niveau de journalisation | INFO | DEBUG \$1 INFO \$1 WARN \$1 ERROR \$1 NONE | PARAMETERS\$1SECRETS\$1EXTENSION\$1LOG\$1LEVEL | Le niveau de détail indiqué dans les journaux pour l’extension |
| Nombre maximal de connexions | 3 | 1 ou plus | PARAMETERS\$1SECRETS\$1EXTENSION\$1MAX\$1CONNECTIONS | Nombre maximum de connexions HTTP pour les requêtes à Parameter Store ou Secrets Manager. |
| Délai d’expiration de Secrets Manager | 0 (n’expire pas) | Tous les nombres entiers | SECRETS\$1MANAGER\$1TIMEOUT\$1MILLIS | Délai d’expiration des requêtes adressées à Secrets Manager (en millisecondes) |
| Délai d’expiration de Parameter Store | 0 (n’expire pas) | Tous les nombres entiers | SSM\$1PARAMETER\$1STORE\$1TIMEOUT\$1MILLIS | Délai d’expiration des requêtes adressées au Parameter Store (en millisecondes) |
### Utilisation d’une rotation des secrets
Si vous alternez fréquemment les secrets, la durée de cache par défaut de 300 secondes peut entraîner l’utilisation de secrets obsolètes par votre fonction. Deux options s’offrent à vous pour vous assurer que votre fonction utilise la dernière valeur de secret :
+ Réduisez le TTL du cache en définissant la variable d’environnement `SECRETS_MANAGER_TTL` sur une valeur inférieure (en secondes). Par exemple, configurez-le sur `60` pour que votre fonction n’utilise jamais un secret vieux de plus d’une minute.
+ Utilisez les étiquettes intermédiaires `AWSCURRENT` ou `AWSPREVIOUS` dans votre demande de secret pour vous assurer d’obtenir la version spécifique que vous souhaitez :
```
secretsmanager/get?secretId=YOUR_SECRET_NAME&versionStage=AWSCURRENT
```
Choisissez l’approche qui équilibre le mieux vos besoins en matière de performances et de fraîcheur. Un TTL inférieur signifie des appels plus fréquents à Secrets Manager, mais garantit que vous travaillez avec les valeurs de secret les plus récentes.
## Utilisation de l'utilitaire de paramètres de Powertools pour AWS Lambda
L'utilitaire de paramètres de Powertools for AWS Lambda fournit une interface unifiée permettant de récupérer les secrets auprès de plusieurs fournisseurs, notamment Secrets Manager, le magasin de paramètres et. AppConfig Il gère la mise en cache, les transformations et fournit une expérience de développement plus intégrée par rapport à l’approche de l’extension.
### Avantages de l’utilitaire de paramètres
+ **Fournisseurs multiples** - Récupérez les paramètres depuis Secrets Manager, Parameter Store et AppConfig en utilisant la même interface
+ **Transformations intégrées** : analyse automatique du JSON, décodage Base64 et autres transformations de données
+ **Mise en cache intégrée** : mise en cache configurable avec prise en charge de TTL pour réduire les appels d’API
+ **Sécurité typographique** : prise en charge efficace de la saisie dans les environnements d'exécution compatibles TypeScript et dans les autres environnements d'exécution compatibles
+ **Gestion des erreurs** : logique de nouvelle tentative et gestion des erreurs intégrées
### Exemples de code
Les exemples suivants montrent comment récupérer des secrets à l’aide de l’utilitaire de paramètres dans différents environnements d’exécution :
**Python**
Pour obtenir des exemples complets et des instructions de configuration, consultez la [documentation de l’utilitaire de paramètres](https://docs.powertools.aws.dev/lambda/python/latest/utilities/parameters/).
Récupération de secrets depuis Secrets Manager à l'aide de l'utilitaire Powertools for AWS Lambda Parameters.
```
from aws_lambda_powertools import Logger
from aws_lambda_powertools.utilities import parameters
logger = Logger()
def lambda_handler(event, context):
try:
# Get secret with caching (default TTL: 5 seconds)
secret_value = parameters.get_secret("my-secret-name")
# Get secret with custom TTL
secret_with_ttl = parameters.get_secret("my-secret-name", max_age=300)
# Get secret and transform JSON
secret_json = parameters.get_secret("my-json-secret", transform="json")
logger.info("Successfully retrieved secrets")
return {
'statusCode': 200,
'body': 'Successfully retrieved secrets'
}
except Exception as e:
logger.error(f"Error retrieving secret: {str(e)}")
return {
'statusCode': 500,
'body': f'Error: {str(e)}'
}
```
**TypeScript**
Pour obtenir des exemples complets et des instructions de configuration, consultez la [documentation de l’utilitaire de paramètres](https://docs.aws.amazon.com/powertools/typescript/2.1.1/utilities/parameters/).
Récupération de secrets depuis Secrets Manager à l'aide de l'utilitaire Powertools for AWS Lambda Parameters.
```
import { Logger } from '@aws-lambda-powertools/logger';
import { getSecret } from '@aws-lambda-powertools/parameters/secrets';
import type { Context } from 'aws-lambda';
const logger = new Logger();
export const handler = async (event: any, context: Context) => {
try {
// Get secret with caching (default TTL: 5 seconds)
const secretValue = await getSecret('my-secret-name');
// Get secret with custom TTL
const secretWithTtl = await getSecret('my-secret-name', { maxAge: 300 });
// Get secret and transform JSON
const secretJson = await getSecret('my-json-secret', { transform: 'json' });
logger.info('Successfully retrieved secrets');
return {
statusCode: 200,
body: 'Successfully retrieved secrets'
};
} catch (error) {
logger.error('Error retrieving secret', { error });
return {
statusCode: 500,
body: `Error: ${error}`
};
}
};
```
**Java**
Pour obtenir des exemples complets et des instructions de configuration, consultez la [documentation de l’utilitaire de paramètres](https://docs.powertools.aws.dev/lambda/java/latest/utilities/parameters/).
Récupération de secrets depuis Secrets Manager à l'aide de l'utilitaire Powertools for AWS Lambda Parameters.
```
import software.amazon.lambda.powertools.logging.Logging;
import software.amazon.lambda.powertools.parameters.SecretsProvider;
import software.amazon.lambda.powertools.parameters.ParamManager;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
public class SecretHandler implements RequestHandler {
private final SecretsProvider secretsProvider = ParamManager.getSecretsProvider();
@Logging
@Override
public String handleRequest(Object input, Context context) {
try {
// Get secret with caching (default TTL: 5 seconds)
String secretValue = secretsProvider.get("my-secret-name");
// Get secret with custom TTL (300 seconds)
String secretWithTtl = secretsProvider.withMaxAge(300).get("my-secret-name");
// Get secret and transform JSON
MySecret secretJson = secretsProvider.get("my-json-secret", MySecret.class);
return "Successfully retrieved secrets";
} catch (Exception e) {
return "Error retrieving secret: " + e.getMessage();
}
}
public static class MySecret {
// Define your secret structure here
}
}
```
**.NET**
Pour obtenir des exemples complets et des instructions de configuration, consultez la [documentation de l’utilitaire de paramètres](https://docs.aws.amazon.com/powertools/typescript/latest/features/parameters/).
Récupération de secrets depuis Secrets Manager à l'aide de l'utilitaire Powertools for AWS Lambda Parameters.
```
using AWS.Lambda.Powertools.Logging;
using AWS.Lambda.Powertools.Parameters;
using Amazon.Lambda.Core;
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
public class Function
{
private readonly ISecretsProvider _secretsProvider;
public Function()
{
_secretsProvider = ParametersManager.SecretsProvider;
}
[Logging]
public async Task FunctionHandler(object input, ILambdaContext context)
{
try
{
// Get secret with caching (default TTL: 5 seconds)
var secretValue = await _secretsProvider.GetAsync("my-secret-name");
// Get secret with custom TTL
var secretWithTtl = await _secretsProvider.WithMaxAge(TimeSpan.FromMinutes(5))
.GetAsync("my-secret-name");
// Get secret and transform JSON
var secretJson = await _secretsProvider.GetAsync("my-json-secret");
return "Successfully retrieved secrets";
}
catch (Exception e)
{
return $"Error retrieving secret: {e.Message}";
}
}
public class MySecret
{
// Define your secret structure here
}
}
```
### Configuration et autorisations
Pour utiliser l’utilitaire de paramètres :
1. Installez Powertools AWS Lambda pour votre environnement d'exécution. Pour en savoir plus, consultez [Powertools pour AWS Lambda](powertools-for-lambda.md).
1. Ajoutez les autorisations IAM nécessaires au rôle d’exécution de votre fonction. Pour plus d'informations, consultez [Gestion des autorisations dans AWS Lambda](lambda-permissions.md).
1. Configurez tous les paramètres facultatifs par le biais de [variables d’environnement](configuration-envvars.md).
Les autorisations IAM requises sont les mêmes que pour l’approche de l’extension. L’utilitaire gère automatiquement la mise en cache et les appels d’API à Secrets Manager en fonction de votre configuration.
# Utilisation de Lambda avec Amazon SQS
**Note**
Si vous souhaitez envoyer des données à une cible autre qu'une fonction Lambda ou enrichir les données avant de les envoyer, consultez [Amazon EventBridge ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-pipes.html) Pipes.
Vous pouvez utiliser une fonction Lambda pour traiter les messages figurant dans une file d’attente Amazon Simple Queue Service (Amazon SQS). Lambda prend en charge à la fois les [files d’attente standard](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/standard-queues.html) et les [files d’attente FIFO (premier entré, premier sorti)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues.html) pour les [mappages des sources d’événements](invocation-eventsourcemapping.md). Vous pouvez également utiliser le mode provisionné pour allouer des ressources d'interrogation dédiées pour vos mappages de sources d'événements Amazon SQS. [La fonction Lambda et la file d'attente Amazon SQS doivent être Région AWS identiques, bien qu'elles puissent être différentes. Comptes AWS](with-sqs-cross-account-example.md)
Lorsque vous traitez des messages Amazon SQS, vous devez implémenter une logique de réponse partielle de lot afin d’éviter que les messages traités avec succès soient de nouveau essayés en cas d’échec de certains messages d’un lot. L'[utilitaire Batch Processor](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/) de Powertools AWS Lambda simplifie cette implémentation en gérant automatiquement la logique de réponse partielle par lots, en réduisant le temps de développement et en améliorant la fiabilité.
**Topics**
+ [Comprendre le comportement d’interrogation et de traitement par lots pour les mappages des sources d’événements Amazon SQS](#sqs-polling-behavior)
+ [Utilisation du mode provisionné avec les mappages de sources d'événements Amazon SQS](#sqs-provisioned-mode)
+ [Configuration du mode provisionné pour le mappage des sources d'événements Amazon SQS](#sqs-configuring-provisioned-mode)
+ [Exemple d’événement de message de file d’attente standard](#example-standard-queue-message-event)
+ [Exemple d’événement de message de file d’attente FIFO](#sample-fifo-queues-message-event)
+ [Création et configuration d’un mappage des sources d’événements Amazon SQS](services-sqs-configure.md)
+ [Configuration du comportement de mise à l’échelle pour les mappages des sources d’événements SQS](services-sqs-scaling.md)
+ [Gestion des erreurs pour une source d’événements SQS dans Lambda](services-sqs-errorhandling.md)
+ [Paramètres Lambda pour les mappages des sources d’événement Amazon SQS](services-sqs-parameters.md)
+ [Utilisation du filtrage des événements avec une source d’événement Amazon SQS](with-sqs-filtering.md)
+ [Didacticiel : utilisation de Lambda avec Amazon SQS](with-sqs-example.md)
+ [Didacticiel : utilisation d’une file d’attente Amazon SQS entre comptes en tant que source d’événement](with-sqs-cross-account-example.md)
## Comprendre le comportement d’interrogation et de traitement par lots pour les mappages des sources d’événements Amazon SQS
Avec les mappages des sources d’événements Amazon SQS, Lambda interroge la file d’attente et invoque votre fonction de [manière synchrone](invocation-sync.md) avec un événement. Chaque événement peut contenir un lot de plusieurs messages provenant de la file d’attente. Lambda reçoit ces événements un lot à la fois, et invoque votre fonction une fois pour chaque lot. Après que la fonction a traité un lot avec succès, Lambda supprime ses messages de la file d’attente.
Quand Lambda reçoit un lot, les messages restent dans la file d’attente mais sont masqués pendant toute la durée du [délai de visibilité](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html) de la file d’attente. Si votre fonction traite tous les messages d’un lot avec succès, Lambda supprime les messages depuis la file d’attente. Par défaut, si votre fonction rencontre une erreur lors du traitement d’un lot, tous les messages de ce lot redeviennent visibles dans la file d’attente une fois le délai de visibilité expiré. Pour cette raison, le code de votre fonction peut traiter le même message plusieurs fois sans effets secondaires involontaires.
**Avertissement**
Les mappages des sources d’événements Lambda traitent chaque événement au moins une fois, et le traitement des enregistrements peut être dupliqué. Pour éviter les problèmes potentiels liés à des événements dupliqués, nous vous recommandons vivement de rendre votre code de fonction idempotent. Pour en savoir plus, consultez [Comment rendre ma fonction Lambda idempotente](https://repost.aws/knowledge-center/lambda-function-idempotent) dans le Knowledge Center. AWS
Pour empêcher Lambda de traiter un message plusieurs fois, vous pouvez soit configurer le mappage de votre source d'événements pour inclure les [défaillances d'éléments de lot](services-sqs-errorhandling.md#services-sqs-batchfailurereporting) dans la réponse de votre fonction, soit utiliser l'[DeleteMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteMessage.html)API pour supprimer les messages de la file d'attente lorsque votre fonction Lambda les traite correctement.
Pour de plus amples informations sur les paramètres de configuration pris en charge par Lambda pour les mappages des sources d’événements SQS, consultez [Création d’un mappage des sources d’événements SQS](services-sqs-configure.md#events-sqs-eventsource).
## Utilisation du mode provisionné avec les mappages de sources d'événements Amazon SQS
Pour les charges de travail où vous devez optimiser le débit de votre mappage des sources d’événements, vous pouvez utiliser le mode provisionné. En mode provisionné, vous définissez des limites minimales et maximales pour le nombre de sondeurs d’événements alloués. Ces sondeurs d’événements alloués sont dédiés à votre mappage des sources d’événements et peuvent gérer les pics de messages inattendus grâce à une mise à l’échelle automatique réactive. Le mappage des sources d'événements Amazon SQS configuré en mode provisionné évolue 3 fois plus vite (jusqu'à 1 000 appels simultanés par minute) et prend en charge une simultanéité 16 fois supérieure (jusqu'à 20 000 appels simultanés) par rapport à la capacité de mappage des sources d'événements Amazon SQS par défaut. Nous vous recommandons d'utiliser le mode provisionné pour les charges de travail basées sur les événements Amazon SQS soumises à des exigences de performance strictes, telles que les sociétés de services financiers traitant les flux de données du marché, les plateformes de commerce électronique fournissant des recommandations personnalisées en temps réel et les sociétés de jeux gérant les interactions avec les joueurs en direct. L’utilisation du mode alloué génère des coûts supplémentaires. Pour connaître les tarifs détaillés, consultez la section [AWS Lambda des prix](https://aws.amazon.com/lambda/pricing/).
Chaque sondeur d'événements en mode provisionné peut gérer jusqu'à 1 % MB/s du débit, jusqu'à 10 appels simultanés ou jusqu'à 10 appels d'API d'interrogation Amazon SQS par seconde. La plage de valeurs acceptées pour le nombre minimum de sondeurs d'événements (MinimumPollers) est comprise entre 2 et 200, avec une valeur par défaut de 2. La plage de valeurs acceptées pour le nombre maximum de sondeurs d'événements (MaximumPollers) est comprise entre 2 et 2 000, avec une valeur par défaut de 200. MaximumPollers doit être supérieur ou égal à MinimumPollers.
### Déterminer les sondeurs d'événements requis
Pour estimer le nombre de sondeurs d'événements nécessaires pour garantir des performances de traitement des messages optimales lors de l'utilisation du mode provisionné pour SQS ESM, collectez les indicateurs suivants pour votre application : pic d'événements SQS par seconde nécessitant un traitement à faible latence, taille moyenne de la charge utile des événements SQS, durée moyenne de la fonction Lambda et taille de lot configurée.
Vous pouvez d'abord estimer le nombre d'événements SQS par seconde (EPS) pris en charge par un sondeur d'événements pour votre charge de travail à l'aide de la formule suivante :
```
EPS per event poller =
minimum(
ceiling(1024 / average event size in KB),
ceiling(10 / average function duration in seconds) * batch size,
min(100, 10 * batch size)
)
```
Ensuite, vous pouvez calculer le nombre minimum de sondeurs requis en utilisant la formule ci-dessous. Ce calcul garantit que vous fournissez une capacité suffisante pour répondre à vos besoins de trafic de pointe.
```
Required event pollers = (Peak number of events per second in Queue) / EPS per event poller
```
Prenons l'exemple d'une charge de travail avec une taille de lot par défaut de 10, une taille moyenne des événements de 3 Ko, une durée de fonctionnement moyenne de 100 ms et une exigence de gestion de 1 000 événements par seconde. Dans ce scénario, chaque sondeur d'événements prendra en charge environ 100 événements par seconde (EPS). Par conséquent, vous devez définir un nombre minimum de sondeurs à 10 pour répondre de manière adéquate à vos besoins de pointe en matière de trafic. Si votre charge de travail présente les mêmes caractéristiques mais avec une durée de fonctionnement moyenne d'une seconde, chaque sondeur ne prendra en charge que 10 EPS, ce qui vous obligera à configurer au moins 100 sondeurs pour prendre en charge 1 000 événements par seconde avec une faible latence.
Nous recommandons d'utiliser une taille de lot par défaut de 10 ou plus pour optimiser l'efficacité des sondeurs d'événements en mode provisionné. Des lots de plus grande taille permettent à chaque sondeur de traiter un plus grand nombre d'événements par appel, ce qui améliore le débit et la rentabilité. Lorsque vous planifiez votre capacité de sondeurs d'événements, tenez compte des pics de trafic potentiels et envisagez de définir une valeur de minimumPollers légèrement supérieure au minimum calculé pour créer une zone tampon. En outre, surveillez les caractéristiques de votre charge de travail au fil du temps, car les modifications de la taille des messages, de la durée des fonctions ou des modèles de trafic peuvent nécessiter des ajustements de la configuration de votre sondeur d'événements afin de maintenir des performances et une rentabilité optimales. Pour une planification précise de la capacité, nous vous recommandons de tester votre charge de travail spécifique afin de déterminer l'EPS réel que chaque enquêteur peut piloter.
## Configuration du mode provisionné pour le mappage des sources d'événements Amazon SQS
Vous pouvez configurer le mode provisionné pour le mappage de vos sources d'événements Amazon SQS à l'aide de la console ou de l'API Lambda.
**Pour configurer le mode provisionné pour un mappage de source d'événements Amazon SQS existant (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez la fonction avec le mappage des sources d'événements Amazon SQS pour laquelle vous souhaitez configurer le mode provisionné.
1. Choisissez **Configuration**, puis **Déclencheurs**.
1. **Choisissez le mappage des sources d'événements Amazon SQS pour lequel vous souhaitez configurer le mode provisionné, puis choisissez Modifier.**
1. Sous **Configuration du mappage des sources d’événements**, choisissez **Configurer le mode provisionné**.
+ Pour le **nombre minimal de sondeurs**, entrez une valeur comprise entre 2 et 200. Si vous ne spécifiez aucune valeur, Lambda choisit une valeur par défaut de 2.
+ Pour le **nombre maximum de sondeurs d'événements**, entrez une valeur comprise entre 2 et 2 000. Cette valeur doit être supérieure ou égale à la valeur du **Nombre minimal de sondeurs d’événements**. Si vous ne spécifiez aucune valeur, Lambda choisit la valeur par défaut 200.
1. Choisissez **Enregistrer**.
Vous pouvez configurer le mode provisionné par programmation à l'aide de l'`ProvisionedPollerConfig`objet de votre. `EventSourceMappingConfiguration` Par exemple, la commande `UpdateEventSourceMapping` CLI suivante configure une `MinimumPollers` valeur de 5 et une `MaximumPollers` valeur de 100.
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--provisioned-poller-config '{"MinimumPollers": 5, "MaximumPollers": 100}'
```
Après avoir configuré le mode alloué, vous pouvez observer l’utilisation des sondeurs d’événements pour votre charge de travail en surveillant la métrique `ProvisionedPollers`. Pour plus d'informations, consultez la section Métriques de mappage des sources d'événements.
Pour désactiver le mode provisionné et revenir au mode par défaut (à la demande), vous pouvez utiliser la commande `UpdateEventSourceMapping` CLI suivante :
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--provisioned-poller-config '{}'
```
**Note**
Le mode provisionné ne peut pas être utilisé conjointement avec le paramètre de simultanéité maximale. Lorsque vous utilisez le mode provisionné, vous contrôlez la simultanéité maximale grâce au nombre maximal de sondeurs d'événements.
Pour plus d'informations sur la configuration du mode provisionné, consultez[Création et configuration d’un mappage des sources d’événements Amazon SQS](services-sqs-configure.md).
## Exemple d’événement de message de file d’attente standard
**Example Événement de message Amazon SQS (file d’attente standard)**
```
{
"Records": [
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "Test message.",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {
"myAttribute": {
"stringValue": "myValue",
"stringListValues": [],
"binaryListValues": [],
"dataType": "String"
}
},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue",
"awsRegion": "us-east-2"
},
{
"messageId": "2e1424d4-f796-459a-8184-9c92662be6da",
"receiptHandle": "AQEBzWwaftRI0KuVm4tP+/7q1rGgNqicHq...",
"body": "Test message.",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082650636",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082650649"
},
"messageAttributes": {},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue",
"awsRegion": "us-east-2"
}
]
}
```
Par défaut, Lambda interroge jusqu’à 10 messages à la fois dans votre file d’attente, et envoie ce lot à votre fonction. Pour éviter d’invoquer la fonction avec un petit nombre d’enregistrements, vous pouvez configurer la source d’événement de manière à les mettre en mémoire tampon pendant 5 minutes en configurant une fenêtre de lot. Avant d’invoquer la fonction, Lambda continue d’interroger les messages de la file d’attente standard jusqu’à ce que la fenêtre de lot expire, que le [quota de taille des données utiles de l’invocation](gettingstarted-limits.md) soit atteint ou que la taille maximale configurée du lot soit atteinte.
Si vous utilisez une fenêtre de lot et que votre file d’attente SQS contient un trafic très faible, Lambda peut attendre 20 secondes avant d’invoquer votre fonction. C’est le cas même si vous définissez une fenêtre de lot inférieure à 20 secondes.
**Note**
Sous Java, vous pouvez rencontrer des erreurs de pointeur nul lors de la désérialisation de JSON. Cela peut être dû à la façon dont les cas « Records » (Enregistrements) et « eventSourceARN » sont convertis par le mappeur d’objets JSON.
## Exemple d’événement de message de file d’attente FIFO
Pour les files d’attente FIFO, les enregistrements contiennent des attributs supplémentaires liés à la déduplication et au séquençage.
**Example Événement de message Amazon SQS (file d’attente FIFO)**
```
{
"Records": [
{
"messageId": "11d6ee51-4cc7-4302-9e22-7cd8afdaadf5",
"receiptHandle": "AQEBBX8nesZEXmkhsmZeyIE8iQAMig7qw...",
"body": "Test message.",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1573251510774",
"SequenceNumber": "18849496460467696128",
"MessageGroupId": "1",
"SenderId": "AIDAIO23YVJENQZJOL4VO",
"MessageDeduplicationId": "1",
"ApproximateFirstReceiveTimestamp": "1573251510774"
},
"messageAttributes": {},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:fifo.fifo",
"awsRegion": "us-east-2"
}
]
}
```
# Création et configuration d’un mappage des sources d’événements Amazon SQS
Pour traiter les messages Amazon SQS avec Lambda, configurez votre file d’attente avec les paramètres appropriés, puis créez un mappage des sources d’événements Lambda.
**Topics**
+ [Configuration d’une file d’attente à utiliser avec Lambda](#events-sqs-queueconfig)
+ [Configuration des autorisations de rôle d’exécution Lambda](#events-sqs-permissions)
+ [Création d’un mappage des sources d’événements SQS](#events-sqs-eventsource)
## Configuration d’une file d’attente à utiliser avec Lambda
Si vous n’avez pas encore de file d’attente Amazon SQS, [créez-en une](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-create-queue.html) à utiliser en tant que source d’événement pour votre fonction Lambda. [La fonction Lambda et la file d'attente Amazon SQS doivent être Région AWS identiques, bien qu'elles puissent être différentes. Comptes AWS](with-sqs-cross-account-example.md)
Pour laisser à votre fonction le temps de traiter chaque lot d’enregistrements, définissez le [délai de visibilité](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html) de la file d’attente source à au moins six fois le [délai de configuration](configuration-timeout.md) sur votre fonction. Le délai supplémentaire permet à Lambda d’effectuer une nouvelle tentative si l’exécution de la fonction est limitée pendant le traitement d’un lot précédent.
**Note**
Le délai d’expiration de votre fonction doit être inférieur ou égal au délai d’expiration de visibilité de la file d’attente. Lambda valide cette exigence lorsque vous créez ou mettez à jour un mappage des sources d’événements, et renvoie une erreur si le délai d’expiration de la fonction dépasse le délai d’expiration de visibilité de la file d’attente.
Par défaut, si Lambda rencontre une erreur à un moment donné lors du traitement d’un lot, tous les messages de ce lot retournent dans la file d’attente. Après le [délai de visibilité](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html), les messages redeviennent visibles pour Lambda. Vous pouvez configurer le mappage des sources d’événements pour utiliser les [réponses par lots partielles](services-sqs-errorhandling.md#services-sqs-batchfailurereporting) afin que seuls les messages ayant échoué soient renvoyés dans la file d’attente. En outre, en cas d’échec répété du traitement d’un message, Amazon SQS peut envoyer celui-ci à une [file d’attente de lettres mortes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html). Nous vous recommandons de définir `maxReceiveCount` sur la [stratégie de redirection](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html#policies-for-dead-letter-queues) de votre file d’attente source sur au moins 5. Cela donne à Lambda la possibilité d’effectuer quelques tentatives avant d’envoyer les messages ayant échoué directement à la file d’attente de lettres mortes.
## Configuration des autorisations de rôle d’exécution Lambda
La politique [ AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html) AWS gérée inclut les autorisations dont Lambda a besoin pour lire depuis votre file d'attente Amazon SQS. Vous pouvez ajouter cette politique gérée au [rôle d’exécution](lambda-intro-execution-role.md) de votre fonction.
En option, si vous utilisez une file d’attente chiffrée, vous devez également ajouter l’autorisation suivante à votre rôle d’exécution :
+ [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html)
## Création d’un mappage des sources d’événements SQS
Créez un mappage de source d’événement pour indiquer à Lambda d’envoyer des éléments de votre file d’attente à une fonction Lambda. Vous pouvez créer plusieurs mappages de source d’événement pour traiter des éléments de plusieurs files d’attente avec une seule fonction. Quand Lambda invoque la fonction cible, l’événement peut contenir plusieurs éléments, jusqu’à une *taille de lot* maximale configurable.
Pour configurer votre fonction afin qu'elle puisse lire depuis Amazon SQS, associez la politique [ AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html) AWS gérée à votre rôle d'exécution. Créez ensuite un mappage des sources d’événements **SQS** à partir de la console en suivant les étapes suivantes.
**Pour ajouter des autorisations et créer un déclencheur**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez le nom d’une fonction.
1. Choisissez l’onglet **Configuration**, puis **Permissions** (Autorisations).
1. Sous **Nom du rôle**, cliquez sur le lien vers votre rôle d’exécution. Ce lien ouvre le rôle dans la console IAM.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/execution-role.png)
1. Choisissez **Ajouter des autorisations**, puis **Attacher des politiques**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/attach-policies.png)
1. Dans le champ de recherche, entrez `AWSLambdaSQSQueueExecutionRole`. Ajoutez cette politique à votre rôle d’exécution. Il s'agit d'une politique AWS gérée qui contient les autorisations dont votre fonction a besoin pour lire depuis une file d'attente Amazon SQS. Pour plus d'informations sur cette politique, consultez [ AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html)la *référence des politiques AWS gérées*.
1. Revenez à votre fonction dans la console Lambda. Sous **Function overview (Vue d’ensemble de la fonction)**, choisissez **Add trigger (Ajouter un déclencheur)**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/add-trigger.png)
1. Choisissez un type de déclencheur.
1. Configurez les options requises, puis choisissez **Add (Ajouter)**.
Lambda prend en charge les options de configuration suivantes pour les sources d’événements Amazon SQS :
**File d’attente SQS**
La file d’attente Amazon SQS à partir de laquelle lire les enregistrements. [La fonction Lambda et la file d'attente Amazon SQS doivent être Région AWS identiques, bien qu'elles puissent être différentes. Comptes AWS](with-sqs-cross-account-example.md)
**Activation du déclencheur**
L’état du mappage des sources d’événements. **Activez le déclencheur** est sélectionné par défaut.
**Taille de lot**
Le nombre maximum d’enregistrements à envoyer à la fonction dans chaque lot. Pour une file d’attente standard, cela peut aller jusqu’à 10 000 registres. Pour une file d’attente FIFO, le maximum est de 10. Pour une taille de lot supérieure à 10, vous devez également définir la fenêtre de lot (`MaximumBatchingWindowInSeconds`) sur au moins 1 seconde.
Configurez le [délai d’attente de votre fonction](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/configurations#timeouts) de façon à laisser suffisamment de temps pour traiter le lot entier d’éléments. Si les éléments sont longs à traiter, choisissez une taille de lot plus petite. Une grande taille de lot peut améliorer l’efficacité pour des charges de travail qui sont très rapides ou qui induisent beaucoup d’efforts supplémentaires. Si vous configurez une [simultanéité réservée](configuration-concurrency.md) sur votre fonction, définissez un minimum de cinq exécutions simultanées pour réduire le risque d’erreurs de limitation lorsque Lambda invoque votre fonction.
Lambda transmet tous les registres du lot à la fonction en un seul appel, tant que la taille totale des événements ne dépasse pas le [quota de taille des données utiles d’invocation](gettingstarted-limits.md) pour une invocation synchrone (6 Mo). Des métadonnées sont générées par Lambda et Amazon SQS pour chaque registre. Ces métadonnées supplémentaires sont comptabilisées dans la taille de charge utile totale, ce qui peut entraîner l’envoi dans un lot d’un nombre total d’enregistrements inférieur à la taille du lot configuré. Les champs de métadonnées qu’Amazon SQS envoie peuvent être de longueur variable. Pour plus d'informations sur les champs de métadonnées Amazon SQS, consultez la documentation relative aux opérations d'[ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)API dans le manuel *Amazon Simple Queue Service API Reference*.
**Fenêtre de lot**
Intervalle de temps maximal (en secondes) pour collecter des enregistrements avant d’invoquer la fonction. Cela s’applique uniquement aux files d’attente standards.
Si vous utilisez une fenêtre de lot supérieure à 0 seconde, vous devez tenir compte de l’augmentation du temps de traitement dans le [délai de visibilité](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html) de votre file d’attente. Nous vous recommandons de paramétrer votre délai de visibilité de file d’attente à six fois le [délai d’expiration de la fonction](configuration-timeout.md), en plus de la valeur de `MaximumBatchingWindowInSeconds`. Cela permet à votre fonction Lambda de traiter chaque lot d’événements et de réessayer en cas d’erreur de limitation.
Lorsque les messages sont disponibles, Lambda commence à les traiter par lots. Lambda commence à traiter cinq lots à la fois avec cinq invocations simultanés de votre fonction. Si les messages sont toujours disponibles, Lambda ajoute jusqu'à 300 appels simultanés de votre fonction par minute, jusqu'à un maximum de 1 250 appels simultanés. En mode provisionné, chaque sondeur d'événements peut gérer jusqu'à 1 % MB/s du débit, jusqu'à 10 appels simultanés ou jusqu'à 10 appels d'API d'interrogation Amazon SQS par seconde. Lambda adapte le nombre de sondeurs d'événements entre le minimum et le maximum configurés, en ajoutant rapidement jusqu'à 1 000 appels simultanés par minute afin de fournir un traitement à faible latence de vos événements Amazon SQS. Vous pouvez contrôler la mise à l'échelle et la simultanéité grâce à ces paramètres minimaux et maximaux d'un sondeur d'événements. Pour en savoir plus sur la mise à l'échelle et la simultanéité des fonctions, consultez[Présentation de la mise à l’échelle de fonction Lambda](lambda-concurrency.md).
Pour traiter plus de messages, vous pouvez optimiser votre fonction Lambda pour un débit plus élevé. Pour plus d'informations, consultez [Comprendre comment s' AWS Lambda adapte aux files d'attente standard Amazon SQS.](https://aws.amazon.com/blogs/compute/understanding-how-aws-lambda-scales-when-subscribed-to-amazon-sqs-queues/#:~:text=If there are more messages,messages from the SQS queue.)
**Critères de filtrage**
Ajoutez des critères de filtrage pour contrôler les événements que Lambda envoie à votre fonction pour traitement. Pour de plus amples informations, veuillez consulter [Contrôle des événements envoyés par Lambda à votre fonction](invocation-eventfiltering.md).
**Simultanéité maximum**
Le nombre maximum de fonctions simultanées que la source d’événement peut invoquer. Ne peut pas être utilisé lorsque le mode provisionné est activé. Pour de plus amples informations, veuillez consulter [Configuration de la simultanéité maximale pour les sources d’événements Amazon SQS](services-sqs-scaling.md#events-sqs-max-concurrency).
**Mode alloué**
Lorsque cette option est activée, alloue des ressources de sondage dédiées au mappage des sources de votre événement. Vous pouvez configurer le nombre minimum (2-200) et maximum (2-2000) de sondeurs d'événements. Chaque sondeur d'événements peut gérer jusqu'à 1 % MB/sec du débit, jusqu'à 10 appels simultanés ou jusqu'à 10 appels d'API d'interrogation Amazon SQS par seconde.
Remarque : vous ne pouvez pas utiliser simultanément le mode provisionné et la simultanéité maximale. Lorsque le mode provisionné est activé, utilisez le paramètre du nombre maximum de sondeurs pour contrôler la simultanéité.
# Configuration du comportement de mise à l’échelle pour les mappages des sources d’événements SQS
Vous pouvez contrôler le comportement de dimensionnement de vos mappages de sources d'événements Amazon SQS via des paramètres de simultanéité maximale ou en activant le mode provisionné. Ces options s'excluent mutuellement.
Par défaut, Lambda adapte automatiquement les sondeurs d'événements en fonction du volume des messages. Lorsque vous activez le mode provisionné, vous allouez un nombre minimum et maximum de ressources de sondage dédiées qui restent prêtes à gérer les modèles de trafic attendus. Cela vous permet d'optimiser les performances de votre mappage des sources d'événements de deux manières :
+ Mode standard (par défaut) : Lambda gère automatiquement le dimensionnement, en commençant par un petit nombre de sondeurs, puis en augmentant ou en diminuant en fonction de la charge de travail.
+ Mode provisionné : vous configurez des ressources d'interrogation dédiées avec des limites minimales et maximales, ce qui permet une mise à l'échelle 3 fois plus rapide et une capacité de traitement jusqu'à 16 fois supérieure.
Pour les files d’attente standard, Lambda utilise une [interrogation longue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-short-and-long-polling.html#sqs-long-polling) pour interroger une file d’attente jusqu’à ce qu’elle devienne active. Lorsque les messages sont disponibles, Lambda commence à traiter cinq lots à la fois avec cinq invocations simultanées de votre fonction. Si les messages sont toujours disponibles, Lambda augmente le nombre de processus lisant des lots de 300 appels simultanés supplémentaires par minute. Le nombre maximum d'appels qu'un mappage de source d'événement peut traiter simultanément est de 1 250. Lorsque le trafic est faible, Lambda réduit le traitement à cinq appels simultanés et peut l'optimiser jusqu'à deux appels simultanés afin de réduire les appels Amazon SQS et les coûts correspondants. Toutefois, cette optimisation n’est pas disponible lorsque vous activez le paramètre de simultanéité maximale.
Pour les files d’attente FIFO, Lambda envoie les messages à votre fonction dans l’ordre de leur réception. Lorsque vous envoyez un message à une file d’attente FIFO, vous spécifiez un [ID de groupe de messages](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/using-messagegroupid-property.html). Amazon SQS veille à ce que les messages du même groupe soient livrés à Lambda dans l’ordre. Lorsque Lambda lit vos messages par lots, chaque lot peut contenir des messages provenant de plusieurs groupes de messages, mais l’ordre des messages est conservé. Si la fonction renvoie une erreur, toutes les nouvelles tentatives sont effectuées sur les messages concernés avant que Lambda reçoive des messages supplémentaires du même groupe.
En mode provisionné, chaque sondeur d'événements peut gérer jusqu'à 1 % MB/sec du débit, jusqu'à 10 appels simultanés ou jusqu'à 10 appels d'API d'interrogation Amazon SQS par seconde. Lambda adapte le nombre d'interrogateurs d'événements entre le minimum et le maximum configurés, en ajoutant rapidement jusqu'à 1 000 appels simultanés par minute afin de fournir un traitement cohérent et à faible latence de vos événements Amazon SQS. L’utilisation du mode alloué génère des coûts supplémentaires. Pour connaître les tarifs détaillés, consultez [AWS Lambda les tarifs](https://aws.amazon.com/lambda/pricing/). Chaque sondeur d'événements utilise de [longs sondages dans](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-short-and-long-polling.html) votre file d'attente SQS, avec jusqu'à 10 sondages par seconde, ce qui entraîne des coûts liés aux demandes d'API SQS. Consultez la [tarification d'Amazon SQS](https://aws.amazon.com/sqs/pricing/ ) pour plus de détails. Vous pouvez contrôler la mise à l'échelle et la simultanéité par le biais de ces paramètres minimaux et maximaux d'un sondeur d'événements, plutôt que d'utiliser le paramètre de simultanéité maximale, car ces options ne peuvent pas être utilisées conjointement.
**Note**
Vous ne pouvez pas utiliser le paramètre de simultanéité maximale et le mode provisionné en même temps. Lorsque le mode provisionné est activé, vous contrôlez le dimensionnement et la simultanéité du mappage de votre source d'événements Amazon SQS via le nombre minimum et maximum de sondeurs d'événements.
## Configuration de la simultanéité maximale pour les sources d’événements Amazon SQS
Vous pouvez utiliser le paramètre de simultanéité maximale pour contrôler le comportement de mise à l’échelle de vos sources d’événements SQS. Notez que la simultanéité maximale ne peut pas être utilisée lorsque le mode provisionné est activé. Le paramètre de simultanéité maximale limite le nombre d’instances simultanées de la fonction qu’une source d’événements Amazon SQS peut invoquer. La simultanéité maximale est un paramètre de niveau source d’événement. Si vous avez plusieurs sources d’événements Amazon SQS mappées à une fonction, chaque source d’événements peut avoir un paramètre de simultanéité maximale séparé. Vous pouvez utiliser la simultanéité maximale pour empêcher une file d’attente d’utiliser toute la [simultanéité réservée](configuration-concurrency.md) de la fonction ou le reste du [quota de simultanéité du compte](gettingstarted-limits.md). La configuration de la simultanéité maximale sur une source d’événements Amazon SQS est gratuite.
Il est important de noter que la simultanéité maximale et la simultanéité réservée sont deux paramètres indépendants. Ne définissez pas une simultanéité maximale supérieure à la simultanéité réservée de la fonction. Si vous configurez la simultanéité maximale, assurez-vous que la simultanéité réservée de votre fonction est supérieure ou égale à la simultanéité maximale totale pour toutes les sources d’événements Amazon SQS sur la fonction. Sinon, Lambda peut limiter vos messages.
Lorsque le quota de simultanéité de votre compte est défini sur la valeur par défaut de 1 000, un mappage des sources d’événements Amazon SQS peut être mis à l’échelle pour invoquer des instances de fonction jusqu’à cette valeur, sauf si vous spécifiez une simultanéité maximale.
Si vous recevez une augmentation du quota de simultanéité par défaut de votre compte, Lambda risque de ne pas être en mesure d’invoquer des instances de fonctions concurrentes jusqu’à votre nouveau quota. Par défaut, Lambda peut effectuer une mise à l’échelle pour invoquer jusqu’à 1 250 instances de fonctions simultanées pour un mappage des sources d’événements Amazon SQS. Si cela ne correspond pas à votre cas d'utilisation, contactez le AWS support pour discuter d'une augmentation de la simultanéité du mappage des sources d'événements Amazon SQS de votre compte.
**Note**
Pour les files d'attente FIFO, les appels simultanés sont plafonnés soit par le nombre de [groupes de messages IDs](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/using-messagegroupid-property.html) (`messageGroupId`), soit par le paramètre de simultanéité maximal, selon le plus faible des deux. Par exemple, si vous avez six groupes de messages IDs et que la simultanéité maximale est fixée à 10, votre fonction peut avoir un maximum de six appels simultanés.
Vous pouvez configurer la simultanéité maximale sur les mappages des sources d’événements Amazon SQS nouveaux et existants.
**Configuration de la simultanéité maximale à l’aide de la console Lambda**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez le nom d’une fonction.
1. Sous **Function overview** (Vue d’ensemble des fonctions), choisissez **SQS**. Cela ouvre l’onglet **Configuration**.
1. Sélectionnez le déclencheur Amazon SQS et choisissez **Edit** (Modifier).
1. Pour **Maximum concurrency** (Simultanéité maximale), saisissez un nombre compris entre 2 et 1 000. Pour désactiver la simultanéité maximale, laissez la case vide.
1. Choisissez **Enregistrer**.
**Configurez la simultanéité maximale à l'aide de AWS Command Line Interface ()AWS CLI**
Utilisez la commande [update-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-event-source-mapping.html) avec l’option `--scaling-config`. Exemple :
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--scaling-config '{"MaximumConcurrency":5}'
```
Pour désactiver la simultanéité maximale, entrez une valeur vide pour `--scaling-config` :
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--scaling-config "{}"
```
**Configuration de la simultanéité maximale à l’aide de l’API Lambda**
Utilisez l'[UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)action [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)ou avec un [ScalingConfig](https://docs.aws.amazon.com/lambda/latest/api/API_ScalingConfig.html)objet.
# Gestion des erreurs pour une source d’événements SQS dans Lambda
Pour gérer les erreurs liées à une source d’événement SQS, Lambda utilise automatiquement une stratégie de nouvelle tentative associée à une stratégie de backoff. Vous pouvez également personnaliser le comportement de gestion des erreurs en configurant votre mappage des sources d’événements SQS de manière à renvoyer des [réponses par lots partielles](#services-sqs-batchfailurereporting).
## Stratégie d’interruption pour les invocations ayant échoué
Lorsqu’une invocation échoue, Lambda tente de réessayer l’invocation tout en mettant en œuvre une stratégie d’interruption. La stratégie d’interruption diffère légèrement selon que Lambda a rencontré l’échec à cause d’une erreur dans votre code de fonction, ou à cause de la limitation.
+ Si votre **code de fonction** est à l’origine de l’erreur, Lambda arrête le traitement et effectue une nouvelle tentative d’invocation. Dans le même temps, Lambda réduit progressivement les tentatives en diminuant la quantité de simultanéité allouée à votre mappage des sources d’événements Amazon SQS. Une fois le délai de visibilité de votre file d’attente expiré, le message réapparaît dans la file d’attente.
+ Si l’invocation échoue en raison d’une **limitation**, Lambda réduit progressivement les tentatives en diminuant la quantité de simultanéité allouée à votre mappage des sources d’événements Amazon SQS. Lambda continue à réessayer le message jusqu’à ce que l’horodatage du message dépasse le délai de visibilité de votre file d’attente, auquel cas Lambda abandonne le message.
## Mise en œuvre de réponses partielles de lot
Lorsque votre fonction Lambda rencontre une erreur lors du traitement d’un lot, tous les messages de ce lot redeviennent par défaut visibles dans la file d’attente, y compris les messages traités avec succès par Lambda. Par conséquent, votre fonction peut finir par traiter le même message plusieurs fois.
Pour éviter de retraiter les messages traités avec succès d’un lot en échec, vous pouvez configurer le mappage des sources d’événements pour que seuls les messages ayant échoué soient à nouveau visibles. C’est ce que l’on appelle une réponse partielle de lot. Pour activer les réponses partielles par lots, spécifiez `ReportBatchItemFailures` l'[FunctionResponseTypes](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html#lambda-UpdateEventSourceMapping-request-FunctionResponseTypes)action lors de la configuration du mappage des sources d'événements. Cela permet à votre fonction de renvoyer un succès partiel, ce qui peut contribuer à réduire le nombre de nouvelles tentatives inutiles sur les enregistrements.
**Note**
L'[utilitaire Batch Processor](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/) de Powertools for AWS Lambda gère automatiquement toute la logique de réponse partielle par lots. Cet utilitaire simplifie la mise en œuvre de modèles de traitement par lots et réduit le code personnalisé nécessaire pour gérer correctement les échecs d’éléments de lots. Il est disponible pour Python, Java, TypeScript et .NET.
Lorsque `ReportBatchItemFailures` est activé, Lambda ne [réduit pas la taille de l’interrogation des messages](#services-sqs-backoff-strategy) lorsque les invocations de fonctions échouent. Si vous vous attendez à ce que certains messages échouent et que vous ne voulez pas que ces échecs aient un impact sur le taux de traitement des messages, utilisez `ReportBatchItemFailures`.
**Note**
Gardez les points suivants à l’esprit lorsque vous utilisez des réponses partielles de lot :
Si la fonction génère une exception, l’ensemble du lot est considéré comme un échec complet.
Si vous utilisez cette fonctionnalité avec une file d’attente FIFO, votre fonction doit arrêter le traitement des messages après le premier échec et renvoyer tous les messages échoués et non traités dans `batchItemFailures`. Cela permet de préserver l’ordre des messages dans votre file d’attente.
**Pour activer les rapports partiels de lot**
1. Consultez les [bonnes pratiques pour la mise en œuvre des réponses partielles de lot](https://docs.aws.amazon.com/prescriptive-guidance/latest/lambda-event-filtering-partial-batch-responses-for-sqs/best-practices-partial-batch-responses.html).
1. Exécutez la commande suivante pour activer `ReportBatchItemFailures` pour votre fonction. Pour récupérer l'UUID du mappage de votre source d'événements, exécutez la [list-event-source-mappings](https://docs.aws.amazon.com/cli/latest/reference/lambda/list-event-source-mappings.html) AWS CLI commande.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--function-response-types "ReportBatchItemFailures"
```
1. Mettez à jour le code de votre fonction afin de capturer toutes les exceptions et de renvoyer les messages d’échec dans une réponse JSON `batchItemFailures`. La `batchItemFailures` réponse doit inclure une liste de messages IDs, sous forme de valeurs `itemIdentifier` JSON.
Supposons, par exemple, que vous disposiez d'un lot de cinq messages IDs `id1`, avec le message `id2``id3`,`id4`,, et`id5`. Votre fonction traite avec succès `id1`, `id3` et `id5`. Pour rendre les messages `id2` et `id4` visibles de nouveau dans la file d’attente, votre fonction doit renvoyer la réponse suivante :
```
{
"batchItemFailures": [
{
"itemIdentifier": "id2"
},
{
"itemIdentifier": "id4"
}
]
}
```
Voici quelques exemples de code de fonction qui renvoie la liste des messages ayant échoué IDs dans le lot :
------
#### [ .NET ]
**SDK pour .NET**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Signalement des échecs d’articles par lots SQS avec Lambda à l’aide de .NET.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using Amazon.Lambda.Core;
using Amazon.Lambda.SQSEvents;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace sqsSample;
public class Function
{
public async Task FunctionHandler(SQSEvent evnt, ILambdaContext context)
{
List batchItemFailures = new List();
foreach(var message in evnt.Records)
{
try
{
//process your message
await ProcessMessageAsync(message, context);
}
catch (System.Exception)
{
//Add failed message identifier to the batchItemFailures list
batchItemFailures.Add(new SQSBatchResponse.BatchItemFailure{ItemIdentifier=message.MessageId});
}
}
return new SQSBatchResponse(batchItemFailures);
}
private async Task ProcessMessageAsync(SQSEvent.SQSMessage message, ILambdaContext context)
{
if (String.IsNullOrEmpty(message.Body))
{
throw new Exception("No Body in SQS Message.");
}
context.Logger.LogInformation($"Processed message {message.Body}");
// TODO: Do interesting work based on the new message
await Task.CompletedTask;
}
}
```
------
#### [ Go ]
**Kit SDK pour Go V2**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Signalement des échecs d’articles par lots SQS avec Lambda à l’aide de Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package main
import (
"context"
"fmt"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func handler(ctx context.Context, sqsEvent events.SQSEvent) (map[string]interface{}, error) {
batchItemFailures := []map[string]interface{}{}
for _, message := range sqsEvent.Records {
if len(message.Body) > 0 {
// Your message processing condition here
fmt.Printf("Successfully processed message: %s\n", message.Body)
} else {
// Message processing failed
fmt.Printf("Failed to process message %s\n", message.MessageId)
batchItemFailures = append(batchItemFailures, map[string]interface{}{"itemIdentifier": message.MessageId})
}
}
sqsBatchResponse := map[string]interface{}{
"batchItemFailures": batchItemFailures,
}
return sqsBatchResponse, nil
}
func main() {
lambda.Start(handler)
}
```
------
#### [ Java ]
**SDK pour Java 2.x**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Signalement des échecs d’articles par lots SQS avec Lambda à l’aide de Java.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.SQSEvent;
import com.amazonaws.services.lambda.runtime.events.SQSBatchResponse;
import java.util.ArrayList;
import java.util.List;
public class ProcessSQSMessageBatch implements RequestHandler {
@Override
public SQSBatchResponse handleRequest(SQSEvent sqsEvent, Context context) {
List batchItemFailures = new ArrayList();
for (SQSEvent.SQSMessage message : sqsEvent.getRecords()) {
try {
//process your message
} catch (Exception e) {
//Add failed message identifier to the batchItemFailures list
batchItemFailures.add(new SQSBatchResponse.BatchItemFailure(message.getMessageId()));
}
}
return new SQSBatchResponse(batchItemFailures);
}
}
```
------
#### [ JavaScript ]
**SDK pour JavaScript (v3)**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Signaler les défaillances d'éléments de lot SQS avec JavaScript Lambda à l'aide de.
```
// Node.js 20.x Lambda runtime, AWS SDK for Javascript V3
export const handler = async (event, context) => {
const batchItemFailures = [];
for (const record of event.Records) {
try {
await processMessageAsync(record, context);
} catch (error) {
batchItemFailures.push({ itemIdentifier: record.messageId });
}
}
return { batchItemFailures };
};
async function processMessageAsync(record, context) {
if (record.body && record.body.includes("error")) {
throw new Error("There is an error in the SQS Message.");
}
console.log(`Processed message: ${record.body}`);
}
```
Signaler les défaillances d'éléments de lot SQS avec TypeScript Lambda à l'aide de.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import { SQSEvent, SQSBatchResponse, Context, SQSBatchItemFailure, SQSRecord } from 'aws-lambda';
export const handler = async (event: SQSEvent, context: Context): Promise => {
const batchItemFailures: SQSBatchItemFailure[] = [];
for (const record of event.Records) {
try {
await processMessageAsync(record);
} catch (error) {
batchItemFailures.push({ itemIdentifier: record.messageId });
}
}
return {batchItemFailures: batchItemFailures};
};
async function processMessageAsync(record: SQSRecord): Promise {
if (record.body && record.body.includes("error")) {
throw new Error('There is an error in the SQS Message.');
}
console.log(`Processed message ${record.body}`);
}
```
------
#### [ PHP ]
**Kit SDK pour PHP**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Signalement des échecs d’articles par lots SQS avec Lambda à l’aide de PHP.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
logger = $logger;
}
/**
* @throws JsonException
* @throws \Bref\Event\InvalidLambdaEvent
*/
public function handleSqs(SqsEvent $event, Context $context): void
{
$this->logger->info("Processing SQS records");
$records = $event->getRecords();
foreach ($records as $record) {
try {
// Assuming the SQS message is in JSON format
$message = json_decode($record->getBody(), true);
$this->logger->info(json_encode($message));
// TODO: Implement your custom processing logic here
} catch (Exception $e) {
$this->logger->error($e->getMessage());
// failed processing the record
$this->markAsFailed($record);
}
}
$totalRecords = count($records);
$this->logger->info("Successfully processed $totalRecords SQS records");
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**Kit SDK for Python (Boto3)**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Signalement des échecs d’articles par lots SQS avec Lambda à l’aide de Python.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def lambda_handler(event, context):
if event:
batch_item_failures = []
sqs_batch_response = {}
for record in event["Records"]:
try:
print(f"Processed message: {record['body']}")
except Exception as e:
batch_item_failures.append({"itemIdentifier": record['messageId']})
sqs_batch_response["batchItemFailures"] = batch_item_failures
return sqs_batch_response
```
------
#### [ Ruby ]
**Kit SDK pour Ruby**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda-with-batch-item-handling).
Signalement des échecs d’articles par lots SQS avec Lambda à l’aide de Ruby.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
require 'json'
def lambda_handler(event:, context:)
if event
batch_item_failures = []
sqs_batch_response = {}
event["Records"].each do |record|
begin
# process message
rescue StandardError => e
batch_item_failures << {"itemIdentifier" => record['messageId']}
end
end
sqs_batch_response["batchItemFailures"] = batch_item_failures
return sqs_batch_response
end
end
```
------
#### [ Rust ]
**SDK pour Rust**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Signalement des échecs d’articles par lots SQS avec Lambda à l’aide de Rust.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
use aws_lambda_events::{
event::sqs::{SqsBatchResponse, SqsEvent},
sqs::{BatchItemFailure, SqsMessage},
};
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
async fn process_record(_: &SqsMessage) -> Result<(), Error> {
Err(Error::from("Error processing message"))
}
async fn function_handler(event: LambdaEvent) -> Result {
let mut batch_item_failures = Vec::new();
for record in event.payload.records {
match process_record(&record).await {
Ok(_) => (),
Err(_) => batch_item_failures.push(BatchItemFailure {
item_identifier: record.message_id.unwrap(),
}),
}
}
Ok(SqsBatchResponse {
batch_item_failures,
})
}
#[tokio::main]
async fn main() -> Result<(), Error> {
run(service_fn(function_handler)).await
}
```
------
Si les événements ayant échoué ne retournent pas dans la file d'attente, voir [Comment résoudre les problèmes liés à la fonction Lambda SQS](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-sqs-report-batch-item-failures/) ? ReportBatchItemFailures dans le AWS Knowledge Center.
### Conditions de réussite et d’échec
Lambda traite un lot comme un succès complet si votre fonction renvoie l’un des éléments suivants :
+ Une liste `batchItemFailures` vide
+ Une liste `batchItemFailures` nulle
+ Une `EventResponse` vide
+ Une `EventResponse` nulle
Lambda traite un lot comme un échec complet si votre fonction renvoie l’un des éléments suivants :
+ Une réponse JSON non valide
+ Une chaîne `itemIdentifier` vide
+ Un `itemIdentifier` nul
+ Un `itemIdentifier` avec un nom de clé incorrect
+ Une valeur `itemIdentifier` avec un ID de message inexistant
### CloudWatch métriques
Pour déterminer si votre fonction signale correctement les défaillances d'articles par lots, vous pouvez surveiller les métriques `NumberOfMessagesDeleted` et `ApproximateAgeOfOldestMessage` Amazon SQS sur Amazon. CloudWatch
+ `NumberOfMessagesDeleted` suit le nombre de messages supprimés de votre file d’attente. Si cela tombe à 0, cela indique que la réponse de votre fonction ne renvoie pas correctement les messages d’échec.
+ `ApproximateAgeOfOldestMessage` suit combien de temps le message le plus ancien est resté dans votre file d’attente. Une forte augmentation de cette métrique peut indiquer que votre fonction ne renvoie pas correctement les messages d’échec.
### Utilisation de Powertools pour le AWS Lambda traitement par lots
L'utilitaire de traitement par lots de Powertools for gère AWS Lambda automatiquement la logique de réponse partielle par lots, réduisant ainsi la complexité de la mise en œuvre du signalement des défaillances par lots. Voici des exemples d’utilisation de l’utilitaire de traitement par lots :
**Python**
Pour des exemples complets et des instructions de configuration, consultez la [documentation de l’utilitaire de traitement par lots](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/).
Traitement des messages Amazon SQS à l'aide d'un AWS Lambda traitement par lots.
```
import json
from aws_lambda_powertools import Logger
from aws_lambda_powertools.utilities.batch import BatchProcessor, EventType, process_partial_response
from aws_lambda_powertools.utilities.data_classes import SQSEvent
from aws_lambda_powertools.utilities.typing import LambdaContext
processor = BatchProcessor(event_type=EventType.SQS)
logger = Logger()
def record_handler(record):
logger.info(record)
# Your business logic here
# Raise an exception to mark this record as failed
def lambda_handler(event, context: LambdaContext):
return process_partial_response(
event=event,
record_handler=record_handler,
processor=processor,
context=context
)
```
**TypeScript**
Pour des exemples complets et des instructions de configuration, consultez la [documentation de l’utilitaire de traitement par lots](https://docs.aws.amazon.com/powertools/typescript/latest/features/batch/).
Traitement des messages Amazon SQS à l'aide d'un AWS Lambda traitement par lots.
```
import { BatchProcessor, EventType, processPartialResponse } from '@aws-lambda-powertools/batch';
import { Logger } from '@aws-lambda-powertools/logger';
import type { SQSEvent, Context } from 'aws-lambda';
const processor = new BatchProcessor(EventType.SQS);
const logger = new Logger();
const recordHandler = async (record: any): Promise => {
logger.info('Processing record', { record });
// Your business logic here
// Throw an error to mark this record as failed
};
export const handler = async (event: SQSEvent, context: Context) => {
return processPartialResponse(event, recordHandler, processor, {
context,
});
};
```
# Paramètres Lambda pour les mappages des sources d’événement Amazon SQS
Tous les types de sources d'événements Lambda partagent les mêmes opérations [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)et les mêmes opérations d'[UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)API. Cependant, seuls certains paramètres s’appliquent à Amazon SQS.
| Paramètre | Obligatoire | Par défaut | Remarques |
| --- | --- | --- | --- |
| BatchSize | N | 10 | Pour les files d’attente standard, le maximum est de 10 000. Pour les files d’attente FIFO, le maximum est de 10. |
| Activé | N | VRAI | Aucune |
| EventSourceArn | Y | N/A | ARN du flux de données ou d’un consommateur de flux |
| FunctionName | Y | N/A | Aucune |
| FilterCriteria | N | N/A | [Contrôle des événements envoyés par Lambda à votre fonction](invocation-eventfiltering.md) |
| FunctionResponseTypes | N | N/A | Pour permettre à votre fonction de signaler des échecs spécifiques dans un lot, incluez la valeur `ReportBatchItemFailures` dans `FunctionResponseTypes`. Pour de plus amples informations, veuillez consulter [Mise en œuvre de réponses partielles de lot](services-sqs-errorhandling.md#services-sqs-batchfailurereporting). |
| MaximumBatchingWindowInSeconds | N | 0 | La fenêtre de traitement par lots n’est pas prise en charge pour les files d’attente FIFO |
| ProvisionedPollerConfig | N | N/A | Configure le nombre minimum (2-200) et maximum (2-2000) de sondeurs d'événements dédiés pour le mappage des sources d'événements SQS. Chaque sondeur peut gérer jusqu'à 1 % MB/sec du débit et 10 appels simultanés. |
| ScalingConfig | N | N/A | [Configuration de la simultanéité maximale pour les sources d’événements Amazon SQS](services-sqs-scaling.md#events-sqs-max-concurrency) |
# Utilisation du filtrage des événements avec une source d’événement Amazon SQS
Vous pouvez utiliser le filtrage d’événements pour contrôler les enregistrements d’un flux ou d’une file d’attente que Lambda envoie à votre fonction. Pour obtenir des informations générales sur le fonctionnement du filtrage des événements, consultez [Contrôle des événements envoyés par Lambda à votre fonction](invocation-eventfiltering.md).
Cette section porte sur le filtrage des événements pour les sources Amazon SQS.
**Note**
Les mappages des sources d’événements Amazon SQS prennent uniquement en charge le filtrage sur la clé `body`.
**Topics**
+ [Notions de base du filtrage des événements Amazon SQS](#filtering-SQS)
## Notions de base du filtrage des événements Amazon SQS
Supposons que votre file d’attente Amazon SQS contienne des messages au format JSON suivant.
```
{
"RecordNumber": 1234,
"TimeStamp": "yyyy-mm-ddThh:mm:ss",
"RequestCode": "AAAA"
}
```
Un exemple d’enregistrement pour cette file d’attente ressemblerait à ce qui suit.
```
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "{\n "RecordNumber": 1234,\n "TimeStamp": "yyyy-mm-ddThh:mm:ss",\n "RequestCode": "AAAA"\n}",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-west-2:123456789012:my-queue",
"awsRegion": "us-west-2"
}
```
Pour filtrer en fonction du contenu de vos messages Amazon SQS, utilisez la clé `body` dans l’enregistrement du message Amazon SQS. Supposons que vous vouliez traiter uniquement les enregistrements où le `RequestCode` de votre message Amazon SQS est « BBBB ». L’objet `FilterCriteria` serait le suivant.
```
{
"Filters": [
{
"Pattern": "{ \"body\" : { \"RequestCode\" : [ \"BBBB\" ] } }"
}
]
}
```
Pour plus de clarté, voici la valeur du `Pattern` de filtre étendu en JSON simple :
```
{
"body": {
"RequestCode": [ "BBBB" ]
}
}
```
Vous pouvez ajouter votre filtre à l’aide de la console, d’AWS CLI ou d’un modèle AWS SAM.
------
#### [ Console ]
Pour ajouter ce filtre à l’aide de la console, suivez les instructions de [Attacher des critères de filtre à un mappage de sources d’événements (console)](invocation-eventfiltering.md#filtering-console) et saisissez la chaîne suivante comme **critère de filtre**.
```
{ "body" : { "RequestCode" : [ "BBBB" ] } }
```
------
#### [ AWS CLI ]
Pour créer un nouveau mappage des sources d’événements avec ces critères de filtrage à l’aide de l’outil AWS Command Line Interface (AWS CLI), exécutez la commande suivante.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:sqs:us-east-2:123456789012:my-queue \
--filter-criteria '{"Filters": [{"Pattern": "{ \"body\" : { \"RequestCode\" : [ \"BBBB\" ] } }"}]}'
```
Pour ajouter ces critères de filtre à un mappage des sources d’événements existant, exécutez la commande suivante.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"body\" : { \"RequestCode\" : [ \"BBBB\" ] } }"}]}'
```
------
#### [ AWS SAM ]
Pour ajouter ce filtre à l’aide d’AWS SAM, ajoutez l’extrait suivant au modèle YAML de votre source d’événement.
```
FilterCriteria:
Filters:
- Pattern: '{ "body" : { "RequestCode" : [ "BBBB" ] } }'
```
------
Supposons que vous vouliez que votre fonction ne traite que les enregistrements où `RecordNumber` est supérieur à 9 999. L’objet `FilterCriteria` serait le suivant.
```
{
"Filters": [
{
"Pattern": "{ \"body\" : { \"RecordNumber\" : [ { \"numeric\": [ \">\", 9999 ] } ] } }"
}
]
}
```
Pour plus de clarté, voici la valeur du `Pattern` de filtre étendu en JSON simple :
```
{
"body": {
"RecordNumber": [
{
"numeric": [ ">", 9999 ]
}
]
}
}
```
Vous pouvez ajouter votre filtre à l’aide de la console, d’AWS CLI ou d’un modèle AWS SAM.
------
#### [ Console ]
Pour ajouter ce filtre à l’aide de la console, suivez les instructions de [Attacher des critères de filtre à un mappage de sources d’événements (console)](invocation-eventfiltering.md#filtering-console) et saisissez la chaîne suivante comme **critère de filtre**.
```
{ "body" : { "RecordNumber" : [ { "numeric": [ ">", 9999 ] } ] } }
```
------
#### [ AWS CLI ]
Pour créer un nouveau mappage des sources d’événements avec ces critères de filtrage à l’aide de l’outil AWS Command Line Interface (AWS CLI), exécutez la commande suivante.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:sqs:us-east-2:123456789012:my-queue \
--filter-criteria '{"Filters": [{"Pattern": "{ \"body\" : { \"RecordNumber\" : [ { \"numeric\": [ \">\", 9999 ] } ] } }"}]}'
```
Pour ajouter ces critères de filtre à un mappage des sources d’événements existant, exécutez la commande suivante.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"body\" : { \"RecordNumber\" : [ { \"numeric\": [ \">\", 9999 ] } ] } }"}]}'
```
------
#### [ AWS SAM ]
Pour ajouter ce filtre à l’aide d’AWS SAM, ajoutez l’extrait suivant au modèle YAML de votre source d’événement.
```
FilterCriteria:
Filters:
- Pattern: '{ "body" : { "RecordNumber" : [ { "numeric": [ ">", 9999 ] } ] } }'
```
------
Pour Amazon SQS, le corps du message peut être n’importe quelle chaîne. Toutefois, cela peut être problématique si votre `FilterCriteria` s’attend à ce que `body` se présente dans un format JSON valide. Le scénario inverse est également vrai, si le corps du message entrant est au format JSON, mais que votre critère de filtre s’attend à ce que `body` soit une chaîne de texte brut, cela peut entraîner un comportement inattendu.
Pour éviter ce problème, assurez-vous que le format du corps dans vos `FilterCriteria` correspond au format attendu de `body` dans les messages que vous recevez de votre file d’attente. Avant de filtrer vos messages, Lambda évalue automatiquement le format du corps de votre message entrant et de votre modèle de filtre pour `body`. En cas de décalage, Lambda abandonne le message. Le tableau suivant résume cette évaluation :
| Format du `body` du message entrant | Format du `body` du modèle de filtre | Action obtenue. |
| --- | --- | --- |
| Chaîne de texte brut | Chaîne de texte brut | Lambda filtre en fonction de vos critères de filtre. |
| Chaîne de texte brut | Pas de modèle de filtre pour les propriétés des données | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
| Chaîne de texte brut | JSON valide | Lambda rejette le message. |
| JSON valide | Chaîne de texte brut | Lambda rejette le message. |
| JSON valide | Pas de modèle de filtre pour les propriétés des données | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
| JSON valide | JSON valide | Lambda filtre en fonction de vos critères de filtre. |
# Didacticiel : utilisation de Lambda avec Amazon SQS
Dans ce didacticiel, vous créerez une fonction Lambda qui consomme les messages d’une file d’attente [Amazon Simple Queue Service (Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html). La fonction Lambda s’exécute chaque fois qu’un nouveau message est ajouté à la file d’attente. La fonction écrit les messages dans un flux Amazon CloudWatch Logs. Le diagramme suivant montre les ressources AWS utilisées pour compléter ce tutoriel.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/sqs_tut_resources.png)
Pour compléter ce didacticiel, effectuez les tâches suivantes :
1. Créez une fonction Lambda qui écrit des messages dans Logs. CloudWatch
1. Créer une file d’attente Amazon SQS.
1. Créez un mappage des sources d’événements Lambda. Le mappage des sources d’événements lit la file d’attente Amazon SQS et invoque votre fonction Lambda lorsqu’un nouveau message est ajouté.
1. Testez la configuration en ajoutant des messages à votre file d'attente et en surveillant les résultats dans CloudWatch Logs.
## Conditions préalables
### Installez le AWS Command Line Interface
Si vous ne l'avez pas encore installé AWS Command Line Interface, suivez les étapes décrites dans la [section Installation ou mise à jour de la dernière version du AWS CLI pour l'](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)installer.
Ce tutoriel nécessite un terminal de ligne de commande ou un shell pour exécuter les commandes. Sous Linux et macOS, utilisez votre gestionnaire de shell et de package préféré.
**Note**
Sous Windows, certaines commandes CLI Bash que vous utilisez couramment avec Lambda (par exemple `zip`) ne sont pas prises en charge par les terminaux intégrés du système d’exploitation. [Installez le sous-système Windows pour Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10) afin d’obtenir une version intégrée à Windows d’Ubuntu et Bash.
## Créer le rôle d’exécution
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/sqs_tut_steps1.png)
Un [rôle d'exécution](lambda-intro-execution-role.md) est un rôle Gestion des identités et des accès AWS (IAM) qui accorde à une fonction Lambda l'autorisation d' Services AWS accès et de ressources. Pour permettre à votre fonction de lire des éléments depuis Amazon SQS, joignez la politique d'**AWSLambdaSQSQueueExecutionRole**autorisation.
**Pour créer un rôle d’exécution et attacher une politique d’autorisations Amazon SQS**
1. Ouvrez la [page Rôles](https://console.aws.amazon.com/iam/home#/roles) de la console IAM.
1. Sélectionnez **Créer un rôle**.
1. Pour **Type d’entité de confiance**, choisissez **Service AWS **.
1. Pour **Cas d’utilisation**, choisissez **Lambda**.
1. Choisissez **Suivant**.
1. Dans le champ de recherche **Politiques d’autorisations**, saisissez **AWSLambdaSQSQueueExecutionRole**.
1. Sélectionnez la **AWSLambdaSQSQueueExecutionRole**politique, puis cliquez sur **Suivant**.
1. Sous **Détails du rôle**, pour **Nom du rôle**, saisissez **lambda-sqs-role**, puis sélectionnez **Créer un rôle**.
Après la création du rôle, notez l’Amazon Resource Name (ARN) de votre rôle d’exécution. Vous en aurez besoin dans les étapes suivantes.
## Créer la fonction
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/sqs_tut_steps2.png)
Créez une fonction Lambda qui traite vos messages Amazon SQS. Le code de fonction enregistre le corps du message Amazon SQS dans Logs. CloudWatch
Ce didacticiel utilise le runtime Node.js 24, mais nous avons également fourni des exemples de code dans d'autres langages d'exécution. Vous pouvez sélectionner l’onglet dans la zone suivante pour voir le code de l’exécution qui vous intéresse. Le JavaScript code que vous allez utiliser dans cette étape se trouve dans le premier exemple présenté dans l'**JavaScript**onglet.
------
#### [ .NET ]
**SDK pour .NET**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Utilisation d’un événement SQS avec Lambda en utilisant .NET.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using Amazon.Lambda.Core;
using Amazon.Lambda.SQSEvents;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace SqsIntegrationSampleCode
{
public async Task FunctionHandler(SQSEvent evnt, ILambdaContext context)
{
foreach (var message in evnt.Records)
{
await ProcessMessageAsync(message, context);
}
context.Logger.LogInformation("done");
}
private async Task ProcessMessageAsync(SQSEvent.SQSMessage message, ILambdaContext context)
{
try
{
context.Logger.LogInformation($"Processed message {message.Body}");
// TODO: Do interesting work based on the new message
await Task.CompletedTask;
}
catch (Exception e)
{
//You can use Dead Letter Queue to handle failures. By configuring a Lambda DLQ.
context.Logger.LogError($"An error occurred");
throw;
}
}
}
```
------
#### [ Go ]
**Kit SDK pour Go V2**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Consommation d’un événement SQS avec Lambda à l’aide de Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package integration_sqs_to_lambda
import (
"fmt"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func handler(event events.SQSEvent) error {
for _, record := range event.Records {
err := processMessage(record)
if err != nil {
return err
}
}
fmt.Println("done")
return nil
}
func processMessage(record events.SQSMessage) error {
fmt.Printf("Processed message %s\n", record.Body)
// TODO: Do interesting work based on the new message
return nil
}
func main() {
lambda.Start(handler)
}
```
------
#### [ Java ]
**SDK pour Java 2.x**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Utilisation d’un événement SQS avec Lambda à l’aide de Java.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.SQSEvent;
import com.amazonaws.services.lambda.runtime.events.SQSEvent.SQSMessage;
public class Function implements RequestHandler {
@Override
public Void handleRequest(SQSEvent sqsEvent, Context context) {
for (SQSMessage msg : sqsEvent.getRecords()) {
processMessage(msg, context);
}
context.getLogger().log("done");
return null;
}
private void processMessage(SQSMessage msg, Context context) {
try {
context.getLogger().log("Processed message " + msg.getBody());
// TODO: Do interesting work based on the new message
} catch (Exception e) {
context.getLogger().log("An error occurred");
throw e;
}
}
}
```
------
#### [ JavaScript ]
**SDK pour JavaScript (v3)**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/blob/main/integration-sqs-to-lambda).
Consommation d'un événement SQS avec JavaScript Lambda en utilisant.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
exports.handler = async (event, context) => {
for (const message of event.Records) {
await processMessageAsync(message);
}
console.info("done");
};
async function processMessageAsync(message) {
try {
console.log(`Processed message ${message.body}`);
// TODO: Do interesting work based on the new message
await Promise.resolve(1); //Placeholder for actual async work
} catch (err) {
console.error("An error occurred");
throw err;
}
}
```
Consommation d'un événement SQS avec TypeScript Lambda en utilisant.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import { SQSEvent, Context, SQSHandler, SQSRecord } from "aws-lambda";
export const functionHandler: SQSHandler = async (
event: SQSEvent,
context: Context
): Promise => {
for (const message of event.Records) {
await processMessageAsync(message);
}
console.info("done");
};
async function processMessageAsync(message: SQSRecord): Promise {
try {
console.log(`Processed message ${message.body}`);
// TODO: Do interesting work based on the new message
await Promise.resolve(1); //Placeholder for actual async work
} catch (err) {
console.error("An error occurred");
throw err;
}
}
```
------
#### [ PHP ]
**Kit SDK pour PHP**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Consommation d’un événement SQS avec Lambda à l’aide de PHP.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
logger = $logger;
}
/**
* @throws InvalidLambdaEvent
*/
public function handleSqs(SqsEvent $event, Context $context): void
{
foreach ($event->getRecords() as $record) {
$body = $record->getBody();
// TODO: Do interesting work based on the new message
}
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**Kit SDK for Python (Boto3)**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Utilisation d’un événement SQS avec Lambda à l’aide de Python.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def lambda_handler(event, context):
for message in event['Records']:
process_message(message)
print("done")
def process_message(message):
try:
print(f"Processed message {message['body']}")
# TODO: Do interesting work based on the new message
except Exception as err:
print("An error occurred")
raise err
```
------
#### [ Ruby ]
**Kit SDK pour Ruby**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Utilisation d’un événement SQS avec Lambda à l’aide de Ruby.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def lambda_handler(event:, context:)
event['Records'].each do |message|
process_message(message)
end
puts "done"
end
def process_message(message)
begin
puts "Processed message #{message['body']}"
# TODO: Do interesting work based on the new message
rescue StandardError => err
puts "An error occurred"
raise err
end
end
```
------
#### [ Rust ]
**SDK pour Rust**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Consommation d’un événement SQS avec Lambda à l’aide de Rust.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
use aws_lambda_events::event::sqs::SqsEvent;
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
async fn function_handler(event: LambdaEvent) -> Result<(), Error> {
event.payload.records.iter().for_each(|record| {
// process the record
tracing::info!("Message body: {}", record.body.as_deref().unwrap_or_default())
});
Ok(())
}
#[tokio::main]
async fn main() -> Result<(), Error> {
tracing_subscriber::fmt()
.with_max_level(tracing::Level::INFO)
// disable printing the name of the module in every log line.
.with_target(false)
// disabling time is handy because CloudWatch will add the ingestion time.
.without_time()
.init();
run(service_fn(function_handler)).await
}
```
------
**Pour créer une fonction Lambda Node.js.**
1. Créez un répertoire pour le projet, puis passez à ce répertoire.
```
mkdir sqs-tutorial
cd sqs-tutorial
```
1. Copiez l'exemple de JavaScript code dans un nouveau fichier nommé`index.js`.
1. Créez un package de déploiement à l’aide de la commande `zip` suivante.
```
zip function.zip index.js
```
1. Créez une fonction Lambda à l’aide de la commande AWS CLI [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html). Pour le paramètre `role`, entrez l’ARN du rôle d’exécution que vous avez créé précédemment.
**Note**
La fonction Lambda et la file d’attente Amazon SQS doivent se trouver dans la même Région AWS.
```
aws lambda create-function --function-name ProcessSQSRecord \
--zip-file fileb://function.zip --handler index.handler --runtime nodejs24.x \
--role arn:aws:iam::111122223333:role/lambda-sqs-role
```
## Tester la fonction
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/sqs_tut_steps3.png)
Appelez votre fonction Lambda manuellement à l'aide de la `invoke` AWS CLI commande et d'un exemple d'événement Amazon SQS.
**Pour invoquer la fonction Lambda avec un exemple d’événement**
1. Enregistrez le JSON suivant en tant que fichier nommé `input.json`. Ce JSON simule un événement qu’Amazon SQS pourrait envoyer à votre fonction Lambda, où `"body"` contient le message réel de la file d’attente. Dans cet exemple, le message est `"test"`.
**Example Événement Amazon SQS**
Il s’agit d’un événement de test : vous n’avez pas besoin de modifier le message ou le numéro de compte.
```
{
"Records": [
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "test",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {},
"md5OfBody": "098f6bcd4621d373cade4e832627b4f6",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-1:111122223333:my-queue",
"awsRegion": "us-east-1"
}
]
}
```
1. Exécutez la AWS CLI commande [d'appel](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/invoke.html) suivante. Cette commande renvoie CloudWatch les journaux dans la réponse. Pour de plus amples informations sur la récupération des journaux, veuillez consulter [Accédez aux journaux avec AWS CLI](monitoring-cloudwatchlogs-view.md#monitoring-cloudwatchlogs-cli).
```
aws lambda invoke --function-name ProcessSQSRecord --payload file://input.json out --log-type Tail \
--query 'LogResult' --output text --cli-binary-format raw-in-base64-out | base64 --decode
```
L'**cli-binary-format**option est obligatoire si vous utilisez AWS CLI la version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez `aws configure set cli-binary-format raw-in-base64-out`. Pour plus d’informations, consultez les [options de ligne de commande globales prises en charge par l’AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) dans le *Guide de l’utilisateur AWS Command Line Interface version 2*.
1. Recherchez le journal `INFO` dans la réponse. C’est ici que la fonction Lambda enregistre le corps du message. Vous devriez voir des journaux qui ressemblent à ceci :
```
2023-09-11T22:45:04.271Z 348529ce-2211-4222-9099-59d07d837b60 INFO Processed message test
2023-09-11T22:45:04.288Z 348529ce-2211-4222-9099-59d07d837b60 INFO done
```
## Créez une file d’attente Amazon SQS.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/sqs_tut_steps4.png)
Créez une file d’attente Amazon SQS que la fonction Lambda peut utiliser en tant que source d’événement. La fonction Lambda et la file d’attente Amazon SQS doivent se trouver dans la même Région AWS.
**Pour créer une file d’attente**
1. Ouvrez la [console Amazon SQS](https://console.aws.amazon.com/sqs).
1. Choisissez **Créez une file d’attente**.
1. Entrez un nom pour la queue. Conservez les paramètres par défaut de toutes les autres options.
1. Choisissez **Créez une file d’attente**.
Une fois la file d’attente créée, notez son ARN. Vous en aurez besoin à l’étape suivante lorsque vous associerez la file d’attente à votre fonction Lambda.
## Configurer la source de l’événement
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/sqs_tut_steps5.png)
Connectez la file d’attente Amazon SQS à votre fonction Lambda en créant un [mappage des sources d’événements](invocation-eventsourcemapping.md). Le mappage des sources d’événements lit la file d’attente Amazon SQS et invoque votre fonction Lambda lorsqu’un nouveau message est ajouté.
Pour créer un mappage entre votre file d'attente Amazon SQS et votre fonction Lambda, utilisez la commande. [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html) AWS CLI Exemple :
```
aws lambda create-event-source-mapping --function-name ProcessSQSRecord --batch-size 10 \
--event-source-arn arn:aws:sqs:us-east-1:111122223333:my-queue
```
Pour obtenir la liste de vos mappages de sources d'événements, utilisez la [list-event-source-mappings](https://awscli.amazonaws.com/v2/documentation/api/2.1.29/reference/lambda/list-event-source-mappings.html)commande. Exemple :
```
aws lambda list-event-source-mappings --function-name ProcessSQSRecord
```
## Envoyer un message de test
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/sqs_tut_steps6.png)
**Pour envoyer un message Amazon SQS à la fonction Lambda**
1. Ouvrez la [console Amazon SQS](https://console.aws.amazon.com/sqs).
1. Choisissez la queue que vous avez créée précédemment.
1. Choisissez **Envoyer et recevoir des messages**.
1. Sous **Corps du message**, entrez un message de test, tel que « ceci est un message de test ».
1. Choisissez **Send Message** (Envoyer un message).
Lambda interroge la file d’attente concernant les mises à jour. Lorsqu’il y a un nouveau message, Lambda invoque votre fonction avec ces nouvelles données d’événement de la file d’attente. Si le gestionnaire de la fonction revient sans exception, Lambda considère le message comme traité avec succès et commence à lire de nouveaux messages dans la file d’attente. Après avoir traité un message avec succès, Lambda le supprime automatiquement de la file d’attente. Si le gestionnaire renvoie une exception, Lambda considère que le traitement du lot de messages a échoué et invoque la fonction avec le même lot de messages.
## Consultez les CloudWatch journaux
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/sqs_tut_steps7.png)
**Pour confirmer que la fonction a traité le message**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez la SQSRecord fonction **Process**.
1. Sélectionnez **Monitor (Surveiller)**.
1. Choisissez **Afficher CloudWatch les journaux**.
1. Dans la CloudWatch console, choisissez le **flux de log** pour la fonction.
1. Recherchez le journal `INFO`. C’est ici que la fonction Lambda enregistre le corps du message. Vous devriez voir le message que vous avez envoyé depuis la file d’attente Amazon SQS. Exemple :
```
2023-09-11T22:49:12.730Z b0c41e9c-0556-5a8b-af83-43e59efeec71 INFO Processed message this is a test message.
```
## Nettoyage de vos ressources
Vous pouvez maintenant supprimer les ressources que vous avez créées pour ce didacticiel, sauf si vous souhaitez les conserver. En supprimant AWS les ressources que vous n'utilisez plus, vous évitez des frais inutiles pour votre Compte AWS.
**Pour supprimer le rôle d’exécution**
1. Ouvrez la [page Roles (Rôles)](https://console.aws.amazon.com/iam/home#/roles) de la console IAM.
1. Sélectionnez le rôle d’exécution que vous avez créé.
1. Sélectionnez **Delete (Supprimer)**.
1. Saisissez le nom du rôle dans le champ de saisie de texte et choisissez **Delete** (Supprimer).
**Pour supprimer la fonction Lambda**
1. Ouvrez la [page Functions (Fonctions)](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda.
1. Sélectionnez la fonction que vous avez créée.
1. Sélectionnez **Actions**, **Supprimer**.
1. Saisissez **confirm** dans la zone de saisie de texte et choisissez **Delete** (Supprimer).
**Pour supprimer la file d’attente Amazon SQS**
1. Connectez-vous à la console Amazon SQS AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/sqs/](https://console.aws.amazon.com/sqs/)
1. Sélectionnez la file d’attente que vous avez créée.
1. Sélectionnez **Delete (Supprimer)**.
1. Saisissez **confirm** dans le champ de saisie de texte.
1. Sélectionnez **Supprimer**.
# Didacticiel : utilisation d’une file d’attente Amazon SQS entre comptes en tant que source d’événement
Dans ce didacticiel, vous allez créer une fonction Lambda qui consomme les messages d'une file d'attente Amazon Simple Queue Service (Amazon SQS) d'un autre compte. AWS Ce didacticiel implique deux AWS comptes : le **compte A** fait référence au compte qui contient votre fonction Lambda, et le **compte B** fait référence au compte qui contient la file d'attente Amazon SQS.
## Conditions préalables
### Installez le AWS Command Line Interface
Si vous ne l'avez pas encore installé AWS Command Line Interface, suivez les étapes décrites dans la [section Installation ou mise à jour de la dernière version du AWS CLI pour l'](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)installer.
Ce tutoriel nécessite un terminal de ligne de commande ou un shell pour exécuter les commandes. Sous Linux et macOS, utilisez votre gestionnaire de shell et de package préféré.
**Note**
Sous Windows, certaines commandes CLI Bash que vous utilisez couramment avec Lambda (par exemple `zip`) ne sont pas prises en charge par les terminaux intégrés du système d’exploitation. [Installez le sous-système Windows pour Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10) afin d’obtenir une version intégrée à Windows d’Ubuntu et Bash.
## Création du rôle d’exécution (compte A)
Dans le **compte A**, créez un [rôle d'exécution](lambda-intro-execution-role.md) qui autorise votre fonction à accéder aux AWS ressources requises.
**Pour créer un rôle d’exécution**
1. Ouvrez la [page Rôles](https://console.aws.amazon.com/iam/home#/roles) dans la console Gestion des identités et des accès AWS (IAM).
1. Choisissez **Create role** (Créer un rôle).
1. Créez un rôle avec les propriétés suivantes :
+ **Trusted entity** (Entité de confiance) – **AWS Lambda**.
+ **Permissions (Autorisations** – **AWSLambdaSQSQueueExecutionRole**
+ **Nom de rôle** – **cross-account-lambda-sqs-role**
La **AWSLambdaSQSQueueExecutionRole**politique dispose des autorisations dont la fonction a besoin pour lire des éléments depuis Amazon SQS et pour écrire des journaux dans Amazon CloudWatch Logs.
## Créer la fonction (compte A)
Dans le **Compte A**, créez une fonction Lambda qui traite vos messages Amazon SQS. La fonction Lambda et la file d’attente Amazon SQS doivent se trouver dans la même Région AWS.
L'exemple de code Node.js suivant écrit chaque message dans CloudWatch un journal de connexion.
**Example index.mjs**
```
export const handler = async function(event, context) {
event.Records.forEach(record => {
const { body } = record;
console.log(body);
});
return {};
}
```
**Pour créer la fonction**
**Note**
Suivre ces étapes permet de créer une fonction Node.js. Pour les autres langages, les étapes sont similaires mais certains détails sont différents.
1. Enregistrez l’exemple de code en tant que fichier nommé `index.mjs`.
1. Créez un package de déploiement.
```
zip function.zip index.mjs
```
1. Créez la fonction à l'aide de la commande `create-function` AWS Command Line Interface (AWS CLI). Remplacez `arn:aws:iam::111122223333:role/cross-account-lambda-sqs-role` par l’ARN du rôle d’exécution que vous avez créé auparavant.
```
aws lambda create-function --function-name CrossAccountSQSExample \
--zip-file fileb://function.zip --handler index.handler --runtime nodejs24.x \
--role arn:aws:iam::111122223333:role/cross-account-lambda-sqs-role
```
## Testez la fonction (compte A)
Dans le **compte A**, testez votre fonction Lambda manuellement à l'aide de la `invoke` AWS CLI commande et d'un exemple d'événement Amazon SQS.
Si le gestionnaire revient normalement sans exception, Lambda considère le message comme traité avec succès et commence à lire de nouveaux messages dans la file d’attente. Après avoir traité un message avec succès, Lambda le supprime automatiquement de la file d’attente. Si le gestionnaire renvoie une exception, Lambda considère que le traitement du lot de messages a échoué et invoque la fonction avec le même lot de messages.
1. Enregistrez le JSON suivant en tant que fichier nommé `input.txt`.
```
{
"Records": [
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "test",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {},
"md5OfBody": "098f6bcd4621d373cade4e832627b4f6",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-1:111122223333:example-queue",
"awsRegion": "us-east-1"
}
]
}
```
Le JSON précédent simule un événement qu’Amazon SQS pourrait envoyer à votre fonction Lambda, où `"body"` contient le message réel de la file d’attente.
1. Exécutez la commande suivante `invoke` AWS CLI .
```
aws lambda invoke --function-name CrossAccountSQSExample \
--cli-binary-format raw-in-base64-out \
--payload file://input.txt outputfile.txt
```
L'**cli-binary-format**option est obligatoire si vous utilisez AWS CLI la version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez `aws configure set cli-binary-format raw-in-base64-out`. Pour plus d’informations, consultez les [options de ligne de commande globales AWS CLI prises en charge](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) dans le *Guide de l’utilisateur AWS Command Line Interface version 2*.
1. Vérifiez la sortie dans le fichier `outputfile.txt`.
## Créer une file d’attente Amazon SQS (Compte B)
Dans **Compte B**, créez une file d’attente Amazon SQS que la fonction Lambda dans **Compte B** peut utiliser comme source d’événement. La fonction Lambda et la file d’attente Amazon SQS doivent se trouver dans la même Région AWS.
**Pour créer une file d’attente**
1. Ouvrez la [console Amazon SQS](https://console.aws.amazon.com/sqs).
1. Choisissez **Créez une file d’attente**.
1. Créez une fille d’attente avec les propriétés suivantes.
+ **Type**–**Standard**
+ **Nom** – **LambdaCrossAccountQueue**
+ **Configuration**— Conservez les paramètres par défaut.
+ **Stratégie d’accès** – Choisissez **Avancé**. Collez dans la stratégie JSON suivante. Remplacez les valeurs suivantes :
+ `111122223333`: Compte AWS ID du **compte A**
+ `444455556666`: Compte AWS ID du **compte B**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [
{
"Sid": "Queue1_AllActions",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/cross-account-lambda-sqs-role"
]
},
"Action": "sqs:*",
"Resource": "arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue"
}
]
}
```
------
Cette stratégie accorde au rôle d’exécution Lambda dans**Compte A**autorisations pour consommer des messages de cette file d’attente Amazon SQS.
1. Après avoir créé la file d’attente, enregistrez son Amazon Resource Name (ARN). Vous en aurez besoin à l’étape suivante lorsque vous associerez la file d’attente à votre fonction Lambda.
## Configurer la source de l’événement (Compte A)
Dans le **compte A**, créez un mappage de source d'événement entre la file d'attente Amazon SQS du **compte B** et votre fonction Lambda en exécutant la commande suivante. `create-event-source-mapping` AWS CLI Remplacez `arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue` par l’ARN de la file d’attente Amazon SQS que vous avez créée à l’étape précédente.
```
aws lambda create-event-source-mapping --function-name CrossAccountSQSExample --batch-size 10 \
--event-source-arn arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue
```
Pour obtenir une liste de vos mappages de source d’événements, exécutez la commande suivante.
```
aws lambda list-event-source-mappings --function-name CrossAccountSQSExample \
--event-source-arn arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue
```
## Tester la configuration
Maintenant, vous pouvez tester la configuration comme suit :
1. Dans**Compte B**, ouvrez[Console Amazon SQS](https://console.aws.amazon.com/sqs).
1. Choisissez **LambdaCrossAccountQueue**celui que vous avez créé précédemment.
1. Choisissez **Send and receive messages (Envoyer et recevoir des messages)**.
1. Sous **Message body** (Corps du message), saisissez un message test.
1. Choisissez **Send Message (Envoyer un message)**.
Votre fonction Lambda dans**Compte A**doit recevoir le message. Lambda continuera d’interroger la file d’attente pour les mises à jour. Lorsqu’il y a un nouveau message, Lambda invoque votre fonction avec ces nouvelles données d’événement de la file d’attente. Votre fonction s'exécute et crée des journaux sur Amazon CloudWatch. Vous pouvez afficher les journaux dans la [console CloudWatch ](https://console.aws.amazon.com/cloudwatch).
## Nettoyage de vos ressources
Vous pouvez maintenant supprimer les ressources que vous avez créées pour ce didacticiel, sauf si vous souhaitez les conserver. En supprimant AWS les ressources que vous n'utilisez plus, vous évitez des frais inutiles pour votre Compte AWS.
Dans**Compte A**, nettoyez votre rôle d’exécution et votre fonction Lambda.
**Pour supprimer le rôle d’exécution**
1. Ouvrez la [page Roles (Rôles)](https://console.aws.amazon.com/iam/home#/roles) de la console IAM.
1. Sélectionnez le rôle d’exécution que vous avez créé.
1. Sélectionnez **Delete (Supprimer)**.
1. Saisissez le nom du rôle dans le champ de saisie de texte et choisissez **Delete** (Supprimer).
**Pour supprimer la fonction Lambda**
1. Ouvrez la [page Functions (Fonctions)](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda.
1. Sélectionnez la fonction que vous avez créée.
1. Sélectionnez **Actions**, **Supprimer**.
1. Saisissez **confirm** dans la zone de saisie de texte et choisissez **Delete** (Supprimer).
Dans**Compte B**, nettoyez la file d’attente Amazon SQS.
**Pour supprimer la file d’attente Amazon SQS**
1. Connectez-vous à la console Amazon SQS AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/sqs/](https://console.aws.amazon.com/sqs/)
1. Sélectionnez la file d’attente que vous avez créée.
1. Sélectionnez **Delete (Supprimer)**.
1. Saisissez **confirm** dans le champ de saisie de texte.
1. Sélectionnez **Supprimer**.
# Orchestration de fonctions Lambda avec Step Functions
AWS Step Functions fournit une orchestration visuelle du flux de travail pour coordonner les fonctions Lambda avec AWS d'autres services. Avec des intégrations natives à plus de 220 AWS services et une infrastructure entièrement gérée et ne nécessitant aucune maintenance, Step Functions est idéal lorsque vous avez besoin d'une conception visuelle de flux de travail et d'intégrations de services entièrement gérées.
Pour l'orchestration à l'aide de langages de programmation standard au sein de Lambda, où la logique du flux de travail côtoie la logique métier, pensez aux fonctions durables de [Lambda](durable-functions.md). Pour vous aider à choisir entre ces options, consultez [Durable functions ou Step Functions](durable-step-functions.md).
Par exemple, le traitement d’une commande peut nécessiter la validation des détails de la commande, la vérification des niveaux de stock, le traitement du paiement et la génération d’une facture. Écrivez des fonctions Lambda distinctes pour chaque tâche et utilisez Step Functions pour gérer le flux de travail. Step Functions coordonne le flux de données entre vos fonctions et gère les erreurs à chaque étape. Cette séparation facilite la visualisation, la modification et la maintenance de vos flux de travail à mesure qu’ils se complexifient.
## Quand utiliser Step Functions avec Lambda
Les scénarios suivants sont de bons exemples de situations dans lesquelles Step Functions convient particulièrement à l'orchestration d'applications basées sur Lambda.
+ [Traitement séquentiel](#sequential-processing)
+ [Gestion des erreurs complexes](#complex-error-handling)
+ [Flux de travail conditionnels et approbations humaines](#conditional-workflows-human-approvals)
+ [Traitement parallèle](#parallel-processing)
### Traitement séquentiel
Le traitement séquentiel se produit lorsqu’une tâche doit être terminée avant que la suivante puisse commencer. Par exemple, dans un système de traitement des commandes, le traitement des paiements ne peut pas commencer tant que la validation de la commande n’est pas terminée, et la génération des factures doit attendre la confirmation du paiement. Écrivez des fonctions Lambda distinctes pour chaque tâche et utilisez Step Functions pour gérer la séquence et le flux de données entre les fonctions.
#### Exemple d’anti-modèle
Une seule fonction Lambda gère l’ensemble du processus de traitement des commandes en :
+ Invoquant d’autres fonctions Lambda en séquence
+ Analysant et validant les réponses de chaque fonction
+ Implémentant la gestion des erreurs et la logique de récupération
+ Gérant le flux de données entre les fonctions
#### Approche recommandée
Utilisez deux fonctions Lambda : l’une pour valider la commande et l’autre pour traiter le paiement. Step Functions coordonne ces fonctions en :
+ Exécutant les tâches dans le bon ordre
+ Transmettant les données entre les fonctions
+ Implémentant la gestion des erreurs à chaque étape
+ Utilisant les états [Choice](https://docs.aws.amazon.com/step-functions/latest/dg/state-choice.html) pour s’assurer que seules les commandes valides sont réglées
**Example graphique de flux de travail**
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/sequential_workflow.png)
**Note**
**Alternative axée sur le code :** [pour le traitement séquentiel avec point de contrôle et nouvelle tentative basés sur le code, voir les étapes relatives aux fonctions durables de Lambda.](durable-basic-concepts.md)
### Gestion des erreurs complexes
Bien que Lambda propose des [fonctionnalités de nouvelle tentative pour les invocations asynchrones et les mappages des sources d’événements](invocation-retries.md), Step Functions fournit une gestion des erreurs plus sophistiquée pour les flux de travail complexes. Vous pouvez [configurer des nouvelles tentatives automatiques](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html#error-handling-retrying-after-an-error) avec un backoff exponentiel et définir différentes politiques de tentatives pour différents types d’erreurs. Lorsque les tentatives sont épuisées, utilisez `Catch` pour rediriger les erreurs vers un [état de secours](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html#error-handling-fallback-states). Cela est particulièrement utile lorsque vous avez besoin d’une gestion des erreurs au niveau du flux de travail qui coordonne plusieurs fonctions et services.
Pour en savoir plus sur la gestion des erreurs de fonction Lambda dans une machine à états, consultez la section [Gestion des erreurs dans *The AWS Step Functions *](https://catalog.workshops.aws/stepfunctions/handling-errors) Workshop.
#### Exemple d’anti-modèle
Une seule fonction Lambda gère tout ce qui suit :
+ Tentatives d’appel à un service de traitement des paiements
+ Si le service de paiement n’est pas disponible, la fonction attend et essaie à nouveau ultérieurement.
+ Implémente un backoff exponentiel personnalisé du temps d’attente
+ Quand toutes les tentatives échouent, détecte l’erreur et choisit un autre flux
#### Approche recommandée
Utilisez une seule fonction Lambda dédiée uniquement au traitement des paiements. Step Functions gère la gestion des erreurs en :
+ [Réessayant automatiquement les tâches ayant échoué avec des périodes de backoff configurables](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html#error-handling-retrying-after-an-error)
+ Appliquant différentes politiques de nouvelle tentative en fonction des types d’erreur
+ Acheminant différents types d’erreurs vers les états de secours appropriés
+ Maintenant l’état et l’historique de gestion des erreurs
**Example graphique de flux de travail**
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/error_handling_workflow.png)
**Note**
**Alternative axée sur le code :** les fonctions durables permettent de gérer les erreurs d'essai et de capture avec des stratégies de nouvelle tentative configurables. Voir [Gestion des erreurs dans les fonctions durables](durable-execution-sdk-retries.md).
### Flux de travail conditionnels et approbations humaines
Utilisez l'[état Step Functions Choice](https://docs.aws.amazon.com/step-functions/latest/dg/state-choice.html) pour acheminer les flux de travail en fonction du résultat de la fonction et le [suffixe waitForTask Token](https://docs.aws.amazon.com/step-functions/latest/dg/connect-to-resource.html#connect-wait-token) pour suspendre les flux de travail en fonction de décisions humaines. Par exemple, pour traiter une demande d’augmentation de limite de crédit, utilisez une fonction Lambda pour évaluer les facteurs de risque. Utilisez ensuite Step Functions pour acheminer les demandes à haut risque vers une approbation manuelle et les demandes à faible risque vers une approbation automatique.
Pour déployer un exemple de flux de travail utilisant un modèle d'intégration de jeton de tâche de [rappel, voir Rappel avec jeton de tâche dans *The AWS Step Functions *](https://catalog.workshops.aws/stepfunctions/integrating-services/3-callback-token) Workshop.
#### Exemple d’anti-modèle
Une fonction Lambda unique gère un flux de travail d’approbation complexe en :
+ Implémentant une logique conditionnelle imbriquée pour évaluer les demandes de crédit
+ Invoquant différentes fonctions d’approbation en fonction du montant des demandes
+ Gérant plusieurs voies d’approbation et points de décision
+ Suivant l’état des approbations en attente
+ Implémentant une logique de délai d’expiration et de notification pour les approbations
#### Approche recommandée
Utilisez trois fonctions Lambda : une pour évaluer le risque de chaque demande, une pour approuver les demandes à faible risque et une pour acheminer les demandes à haut risque vers un responsable pour examen. Step Functions gère le flux de travail en :
+ Utilisant les états [Choice](https://docs.aws.amazon.com/step-functions/latest/dg/state-choice.html) pour acheminer les demandes en fonction du montant et du niveau de risque
+ Suspendant l’exécution en attendant l’approbation humaine
+ Gérant les délais d’expiration pour les approbations en attente
+ Fournissant une visibilité sur l’état actuel de chaque demande
**Example graphique de flux de travail**
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/conditional_workflow.png)
**Note**
**Alternative axée sur le code :** les fonctions durables prennent en charge les rappels pour les flux de travail. human-in-the-loop Voir [Callbacks dans les fonctions durables.](durable-execution-sdk.md)
### Traitement parallèle
Step Functions propose trois méthodes pour gérer le traitement parallèle :
+ L’[état Parallel](https://docs.aws.amazon.com/step-functions/latest/dg/state-parallel.html) exécute simultanément plusieurs ramifications de votre flux de travail. Utilisez-le lorsque vous devez exécuter différentes fonctions en parallèle, comme la génération de vignettes lors de l’extraction des métadonnées des images.
+ L’[état Inline Map](https://docs.aws.amazon.com/step-functions/latest/dg/state-map-inline.html) traite des tableaux de données avec jusqu’à 40 itérations simultanées. Utilisez-le pour les jeux de données de petite ou moyenne taille dans lesquels vous devez effectuer la même opération sur chaque élément.
+ L’[état Distributed Map](https://docs.aws.amazon.com/step-functions/latest/dg/state-map-distributed.html) gère un traitement parallèle à grande échelle avec jusqu’à 10 000 exécutions simultanées, prenant en charge à la fois les tableaux JSON et les sources de données Amazon Simple Storage Service (Amazon S3). Utilisez-le lorsque vous traitez de grands jeux de données ou lorsque vous avez besoin d’une plus grande simultanéité.
#### Exemple d’anti-modèle
Une seule fonction Lambda tente de gérer le traitement en parallèle en :
+ Invoquant simultanément plusieurs fonctions de traitement d’image
+ Implémentant une logique d’exécution parallèle personnalisée
+ Gérant les délais d’attente et les erreurs pour chaque tâche parallèle
+ Collectant et agrégeant les résultats de toutes les fonctions
#### Approche recommandée
Utilisez trois fonctions Lambda : une pour créer une vignette, une pour ajouter un filigrane et une pour extraire les métadonnées. Step Functions gère ces fonctions en :
+ Exécutant simultanément toutes les fonctions à l’aide de l’état [Parallel](https://docs.aws.amazon.com/step-functions/latest/dg/state-parallel.html)
+ Collectant les résultats de chaque fonction dans un tableau ordonné
+ Gérant les délais d’expiration et les erreurs dans toutes les exécutions parallèles
+ Continuant uniquement lorsque toutes les ramifications parallèles sont terminées
**Example graphique de flux de travail**
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/parallel_workflow.png)
**Note**
**Alternative axée sur le code :** des fonctions `parallel()` et `map()` des opérations durables. Voir [Exécution parallèle](durable-execution-sdk.md).
## Quand ne pas utiliser Step Functions avec Lambda
Toutes les applications basées sur Lambda ne bénéficient pas de l’utilisation de Step Functions. Envisagez ces scénarios lorsque vous choisissez l’architecture de votre application.
+ [Applications simples](#simple-applications)
+ [Traitement de données complexes](#complex-data-processing)
+ [Charges de travail intensives en UC](#cpu-intensive)
### Applications simples
**Note**
Pour les flux de travail qui ne nécessitent pas de conception visuelle ou d'intégrations de services étendues, les fonctions [durables de Lambda](durable-functions.md) peuvent constituer une alternative plus simple qui permet de conserver la logique du flux de travail dans le code de Lambda.
Pour les applications qui ne nécessitent pas d’orchestration complexe, l’utilisation de Step Functions peut ajouter une complexité inutile. Par exemple, si vous traitez simplement des messages provenant d'une file d'attente Amazon SQS ou si vous répondez à EventBridge des événements Amazon, vous pouvez configurer ces services pour appeler directement vos fonctions Lambda. De même, si votre application ne comprend qu’une ou deux fonctions Lambda avec une gestion simple des erreurs, l’invocation directe de Lambda ou les architectures pilotées par les événements peuvent être plus simples à déployer et gérer.
### Traitement de données complexes
Vous pouvez utiliser l’état [Distributed Map](https://docs.aws.amazon.com/step-functions/latest/dg/state-map-distributed.html) de Step Functions pour traiter simultanément de grands jeux de données Amazon S3 avec des fonctions Lambda. Cela est efficace pour de nombreuses charges de travail parallèles à grande échelle, notamment pour le traitement de données semi-structurées, comme des fichiers JSON ou CSV. Toutefois, pour des transformations de données plus complexes ou l’analytique avancée, envisagez les alternatives suivantes :
+ **Pipelines de transformation des données** : AWS Glue à utiliser pour les tâches ETL qui traitent des données structurées ou semi-structurées provenant de sources multiples. AWS Glue est particulièrement utile lorsque vous avez besoin de fonctionnalités intégrées de gestion de schémas et de catalogues de données.
+ **Analytique des données :** utilisez Amazon EMR pour l’analytique des données à l’échelle du pétaoctet, en particulier lorsque vous avez besoin d’outils de l’écosystème Apache Hadoop ou pour des charges de travail de machine learning qui dépassent les limites de [mémoire](configuration-memory.md) de Lambda.
### Charges de travail intensives en UC
Bien que Step Functions puisse orchestrer des tâches gourmandes en ressources CPU, les fonctions Lambda peuvent ne pas être adaptées à ces charges de travail en raison de leurs ressources CPU limitées. Pour les opérations nécessitant des calculs intensifs au sein de vos flux de travail, envisagez les alternatives suivantes :
+ **Orchestration de conteneurs :** utilisez Step Functions pour gérer les tâches Amazon Elastic Container Service (Amazon ECS) afin d’obtenir des ressources de calcul plus cohérentes et faciles à mettre à l’échelle.
+ **Traitement par lots :** AWS Batch intégrez-le à Step Functions pour gérer les tâches par lots gourmandes en ressources informatiques qui nécessitent une utilisation soutenue du processeur.
# Invocation d’une fonction Lambda à l’aide d’événements par lots Amazon S3
Vous pouvez utiliser des opérations par lot Amazon S3 pour invoquer une fonction Lambda sur un grand ensemble d’objets Amazon S3. Amazon S3 effectue le suivi de la progression des opérations par lot, envoie des notifications et stocke un rapport d’achèvement indiquant le statut de chaque action.
Pour exécuter une opération par lot, vous créez une [tâche d’opérations par lot](https://docs.aws.amazon.com/AmazonS3/latest/dev/batch-ops-operations.html) Amazon S3. Lorsque vous créez le travail, vous fournissez un manifeste (la liste des objets) et configurez l’action à effectuer sur ces objets.
Lorsque la tâche par lots démarre, Amazon S3 appelle la fonction Lambda [de manière synchrone](invocation-sync.md) pour chaque objet figurant dans le manifeste. Le paramètre d’événement inclut les noms du compartiment et de l’objet.
L’exemple suivant illustre l’événement qu’Amazon S3 envoie à la fonction Lambda pour un objet nommé **customerImage1.jpg** dans le compartiment **amzn-s3-demo-bucket**.
**Example Événement de demande de lot Amazon S3**
```
{
"invocationSchemaVersion": "1.0",
"invocationId": "YXNkbGZqYWRmaiBhc2RmdW9hZHNmZGpmaGFzbGtkaGZza2RmaAo",
"job": {
"id": "f3cc4f60-61f6-4a2b-8a21-d07600c373ce"
},
"tasks": [
{
"taskId": "dGFza2lkZ29lc2hlcmUK",
"s3Key": "customerImage1.jpg",
"s3VersionId": "1",
"s3BucketArn": "arn:aws:s3:::amzn-s3-demo-bucket"
}
]
}
```
Votre fonction Lambda doit renvoyer un objet JSON avec les champs figurant dans l’exemple suivant. Vous pouvez copier `invocationId` et `taskId` à partir du paramètre d’événement. Vous pouvez renvoyer une chaîne dans `resultString`. Amazon S3 enregistre les valeurs `resultString` dans le rapport de fin de tâche.
**Example Réponse à la demande de lot Amazon S3**
```
{
"invocationSchemaVersion": "1.0",
"treatMissingKeysAs" : "PermanentFailure",
"invocationId" : "YXNkbGZqYWRmaiBhc2RmdW9hZHNmZGpmaGFzbGtkaGZza2RmaAo",
"results": [
{
"taskId": "dGFza2lkZ29lc2hlcmUK",
"resultCode": "Succeeded",
"resultString": "[\"Alice\", \"Bob\"]"
}
]
}
```
## Appel de fonctions Lambda à partir d’opérations par lot Amazon S3
Vous pouvez appeler la fonction Lambda avec un ARN de fonction qualifié ou non qualifié. Si vous souhaitez utiliser la même version de fonction pour l’ensemble du travail par lot, configurez une version de fonction spécifique dans le paramètre `FunctionARN` lorsque vous créez votre travail. Si vous configurez un alias ou le qualificateur \$1LATEST, le travail par lot commence immédiatement à appeler la nouvelle version de la fonction si l’alias ou \$1LATEST est mis à jour pendant l’exécution du travail.
Notez que vous ne pouvez pas réutiliser une fonction Amazon S3 basée sur un événement existante pour des opérations par lot. En effet, l’opération par lot Amazon S3 transmet un paramètre d’événement différent à la fonction Lambda, et attend un message en retour avec une structure JSON spécifique.
Dans la [stratégie basée sur une ressource](access-control-resource-based.md) que vous créez pour la tâche par lot Amazon S3, veillez à définir une autorisation pour que la tâche appelle votre fonction Lambda.
Dans le [rôle d’exécution](https://docs.aws.amazon.com/AmazonS3/latest/userguide/batch-ops-iam-role-policies.html) pour la fonction, définissez une stratégie d’approbation pour qu’Amazon S3 endosse ce rôle lors de l’exécution de votre fonction.
Si votre fonction utilise le AWS SDK pour gérer les ressources Amazon S3, vous devez ajouter des autorisations Amazon S3 dans le rôle d'exécution.
Lorsque le travail s’exécute, Amazon S3 démarre plusieurs instances de fonction pour traiter les objets Amazon S3 en parallèle, jusqu’à la [limite de simultanéité](lambda-concurrency.md) de la fonction. Amazon S3 limite la montée en puissance initiale des instances afin d’éviter des surcoûts pour les tâches de plus petite taille.
Si la fonction Lambda renvoie un code de réponse `TemporaryFailure`, Amazon S3 réessaie l’opération.
Pour plus d’informations les opérations par lot Amazon S3, consultez [Exécution d’opérations par lot](https://docs.aws.amazon.com/AmazonS3/latest/dev/batch-ops.html) dans le *Manuel du développeur Amazon S3*.
Pour voir un exemple d’utilisation d’une fonction Lambda dans des opérations par lot Amazon S3, consultez [Appel d’une fonction Lambda à partir d’opérations par lot Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/batch-ops-invoke-lambda.html) dans le *Manuel du développeur Amazon S3*.
# Invocation des fonctions Lambda à l’aide des notifications Amazon SNS
Utilisez une fonction Lambda pour traiter les notifications Amazon Simple Notification Service (Amazon SNS). Amazon SNS prend en charge les fonctions Lambda en tant que cibles pour les messages envoyés à une rubrique. Vous pouvez abonner votre fonction à des rubriques du même compte ou d’autres comptes AWS. Pour voir une procédure, consultez [Tutoriel : Utilisation AWS Lambda avec Amazon Simple Notification Service](with-sns-example.md).
Lambda prend en charge les déclencheurs SNS pour les rubriques SNS standard uniquement. Les rubriques FIFO ne sont pas prises en charge.
Lambda traite les messages SNS de manière asynchrone en les mettant en file d’attente et en gérant les nouvelles tentatives. Si Amazon SNS ne peut pas atteindre Lambda ou si le message est rejeté, Amazon SNS effectue de nouvelles tentatives à intervalles croissants pendant plusieurs heures. Pour plus de détails, consultes [Fiabilité](https://aws.amazon.com/sns/faqs/#Reliability) dans le FAQ sur Amazon SNS.
**Avertissement**
Les invocations asynchrones traitent chaque événement au moins une fois, et le traitement des enregistrements peut être dupliqué. Pour éviter les problèmes potentiels liés à des événements dupliqués, nous vous recommandons vivement de rendre votre code de fonction idempotent. Pour en savoir plus, consultez [Comment puis-je rendre ma fonction Lambda idempotente ?](https://repost.aws/knowledge-center/lambda-function-idempotent) dans le Centre de connaissances AWS.
## Utilitaire d’idempotence de Powertools pour AWS Lambda
L’utilitaire d’idempotence de Powertools pour AWS Lambda rend vos fonctions Lambda idempotentes. Il est disponible pour Python, TypeScript, Java et .NET. Pour plus d’informations, consultez [Utilitaire d’idempotence](https://docs.powertools.aws.dev/lambda/python/latest/utilities/idempotency/) dans la *documentation Powertools pour AWS Lambda (Python)*, [Utilitaire d’idempotence](https://docs.aws.amazon.com/powertools/typescript/2.1.1/utilities/idempotency/) dans la *documentation Powertools pour AWS Lambda (TypeScript)*, [Utilitaire d’idempotence](https://docs.powertools.aws.dev/lambda/java/latest/utilities/idempotency/) dans la *documentation Powertools pour AWS Lambda (Java)* et [Utilitaire d’idempotence](https://docs.powertools.aws.dev/lambda/dotnet/utilities/idempotency/) dans la *documentation Powertools pour AWS Lambda (.NET)*.
**Topics**
+ [Utilitaire d’idempotence de Powertools pour AWS Lambda](#services-sns-powertools-idempotency)
+ [Ajout d’une rubrique Amazon SNS comme déclencheur de fonction Lambda à l’aide de la console](#sns-trigger-console)
+ [Ajout manuel d’une rubrique Amazon SNS comme déclencheur de fonction Lambda](#sns-trigger-manual)
+ [Exemple de forme d’évènement SNS](#sns-sample-event)
+ [Tutoriel : Utilisation AWS Lambda avec Amazon Simple Notification Service](with-sns-example.md)
## Ajout d’une rubrique Amazon SNS comme déclencheur de fonction Lambda à l’aide de la console
Pour ajouter une rubrique SNS comme déclencheur d’une fonction Lambda, le moyen le plus simple consiste à utiliser la console Lambda. Lorsque vous ajoutez le déclencheur via la console, Lambda configure automatiquement les autorisations et les abonnements nécessaires pour commencer à recevoir des événements provenant de la rubrique SNS.
**Pour ajouter une rubrique SNS comme déclencheur d’une fonction Lambda (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez le nom de la fonction pour laquelle vous souhaitez ajouter le déclencheur.
1. Choisissez **Configuration**, puis **Déclencheurs**.
1. Choisissez **Add trigger (Ajouter déclencheur)**.
1. Sous **Configuration du déclencheur**, dans le menu déroulant, choisissez **SNS**.
1. Pour **Rubrique SNS**, choisissez la rubrique SNS à laquelle vous abonner.
## Ajout manuel d’une rubrique Amazon SNS comme déclencheur de fonction Lambda
Pour configurer manuellement un déclencheur SNS pour une fonction Lambda, vous devez suivre les étapes suivantes :
+ Définir une stratégie basée sur les ressources pour votre fonction afin de permettre à SNS de l’invoquer.
+ Abonner votre fonction Lambda à la rubrique Amazon SNS.
**Note**
Si votre rubrique SNS et votre fonction Lambda se trouvent sur des comptes AWS distincts, vous devez également octroyer des autorisations supplémentaires pour autoriser les abonnements entre comptes à la rubrique SNS. Pour plus d’informations, consultez [Accorder une autorisation multicompte pour l’abonnement Amazon SNS](with-sns-example.md#with-sns-subscription-grant-permission).
Vous pouvez utiliser l’AWS Command Line Interface (AWS CLI) pour effectuer ces deux étapes. Tout d’abord, pour définir une politique basée sur les ressources pour une fonction Lambda qui autorise les invocations SNS, utilisez la commande AWS CLI suivante. Assurez-vous de remplacer la valeur de `--function-name` par le nom de votre fonction Lambda et la valeur de `--source-arn` par l’ARN de votre rubrique SNS.
```
aws lambda add-permission --function-name example-function \
--source-arn arn:aws:sns:us-east-1:123456789012:sns-topic-for-lambda \
--statement-id function-with-sns --action "lambda:InvokeFunction" \
--principal sns.amazonaws.com
```
Pour abonner votre fonction à la rubrique SNS, utilisez la commande AWS CLI suivante. Remplacez la valeur de `--topic-arn` par le nom de votre rubrique ARN et la valeur de `--notification-endpoint` par l’ARN de votre fonction Lambda.
```
aws sns subscribe --protocol lambda \
--region us-east-1 \
--topic-arn arn:aws:sns:us-east-1:123456789012:sns-topic-for-lambda \
--notification-endpoint arn:aws:lambda:us-east-1:123456789012:function:example-function
```
## Exemple de forme d’évènement SNS
Amazon SNS appelle votre fonction [de façon asynchrone](invocation-async.md) avec un événement contenant un message et des métadonnées.
**Example Événement de message Amazon SNS**
```
{
"Records": [
{
"EventVersion": "1.0",
"EventSubscriptionArn": "arn:aws:sns:us-east-1:123456789012:sns-lambda:21be56ed-a058-49f5-8c98-aedd2564c486",
"EventSource": "aws:sns",
"Sns": {
"SignatureVersion": "1",
"Timestamp": "2019-01-02T12:45:07.000Z",
"Signature": "tcc6faL2yUC6dgZdmrwh1Y4cGa/ebXEkAi6RibDsvpi+tE/1+82j...65r==",
"SigningCertURL": "https://sns.us-east-1.amazonaws.com/SimpleNotificationService-ac565b8b1a6c5d002d285f9598aa1d9b.pem",
"MessageId": "95df01b4-ee98-5cb9-9903-4c221d41eb5e",
"Message": "Hello from SNS!",
"MessageAttributes": {
"Test": {
"Type": "String",
"Value": "TestString"
},
"TestBinary": {
"Type": "Binary",
"Value": "TestBinary"
}
},
"Type": "Notification",
"UnsubscribeUrl": "https://sns.us-east-1.amazonaws.com/?Action=Unsubscribe&SubscriptionArn=arn:aws:sns:us-east-1:123456789012:test-lambda:21be56ed-a058-49f5-8c98-aedd2564c486",
"TopicArn":"arn:aws:sns:us-east-1:123456789012:sns-lambda",
"Subject": "TestInvoke"
}
}
]
}
```
# Tutoriel : Utilisation AWS Lambda avec Amazon Simple Notification Service
Dans ce didacticiel, vous utiliserez une fonction Lambda intégrée pour vous abonner Compte AWS à une rubrique Amazon Simple Notification Service (Amazon SNS) dans une rubrique distincte. Compte AWS Lorsque vous publiez des messages sur votre rubrique Amazon SNS, votre fonction Lambda lit le contenu du message et le transmet à Amazon Logs. CloudWatch Pour terminer ce didacticiel, vous devez utiliser le AWS Command Line Interface (AWS CLI).
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-sns-tutorial/sns_tut_resources.png)
Pour compléter ce tutoriel, effectuez les tâches suivantes :
+ Dans le **compte A**, créez une rubrique Amazon SNS.
+ Dans le **compte B**, créez une fonction Lambda qui lira les messages de la rubrique.
+ Dans le **compte B**, créez un abonnement à la rubrique.
+ Publiez des messages sur la rubrique Amazon SNS du **compte A** et vérifiez que la fonction Lambda du **compte B les envoie dans Logs**. CloudWatch
En suivant ces étapes, vous apprendrez à configurer une rubrique Amazon SNS pour invoquer une fonction Lambda. Vous apprendrez également comment créer une politique Gestion des identités et des accès AWS (IAM) qui autorise une ressource d'une autre Compte AWS à invoquer Lambda.
Dans le tutoriel, vous utilisez deux Comptes AWS différents. Les AWS CLI commandes illustrent cela en utilisant deux profils nommés appelés `accountA` et`accountB`, chacun étant configuré pour être utilisé avec un profil différent Compte AWS. Pour savoir comment configurer le AWS CLI pour utiliser différents profils, consultez la section [Paramètres des fichiers de configuration et d'identification](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) dans le *guide de l'AWS Command Line Interface utilisateur de la version 2*. Assurez-vous de configurer la même valeur par défaut Région AWS pour les deux profils.
Si les AWS CLI profils que vous créez pour les deux Comptes AWS utilisent des noms différents, ou si vous utilisez le profil par défaut et un profil nommé, modifiez les AWS CLI commandes dans les étapes suivantes selon vos besoins.
## Conditions préalables
### Installez le AWS Command Line Interface
Si vous ne l'avez pas encore installé AWS Command Line Interface, suivez les étapes décrites dans la [section Installation ou mise à jour de la dernière version du AWS CLI pour l'](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)installer.
Ce tutoriel nécessite un terminal de ligne de commande ou un shell pour exécuter les commandes. Sous Linux et macOS, utilisez votre gestionnaire de shell et de package préféré.
**Note**
Sous Windows, certaines commandes CLI Bash que vous utilisez couramment avec Lambda (par exemple `zip`) ne sont pas prises en charge par les terminaux intégrés du système d’exploitation. [Installez le sous-système Windows pour Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10) afin d’obtenir une version intégrée à Windows d’Ubuntu et Bash.
## Créer une rubrique Amazon SNS (compte A)
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-sns-tutorial/sns_tut_steps_1.png)
**Pour créer la rubrique**
+ Dans le **compte A**, créez une rubrique standard Amazon SNS à l'aide de la commande suivante AWS CLI .
```
aws sns create-topic --name sns-topic-for-lambda --profile accountA
```
Vous devez visualiser des résultats similaires à ce qui suit.
```
{
"TopicArn": "arn:aws:sns:us-west-2:123456789012:sns-topic-for-lambda"
}
```
Notez l’Amazon Resource Name (ARN) de votre rubrique. Vous en aurez besoin plus tard dans le tutoriel lorsque vous ajouterez des autorisations à votre fonction Lambda pour vous abonner à cette rubrique.
## Créer un rôle d’exécution de fonction (compte B)
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-sns-tutorial/sns_tut_steps_2.png)
Un rôle d'exécution est un rôle IAM qui accorde à une fonction Lambda l'autorisation d' Services AWS accès et de ressources. Avant de créer votre fonction dans le **compte B**, vous devez créer un rôle qui donne à la fonction les autorisations de base pour écrire des journaux dans CloudWatch Logs. Nous ajouterons les autorisations de lecture à partir de votre rubrique Amazon SNS à une étape ultérieure.
**Pour créer un rôle d’exécution**
1. Dans le **compte B**, ouvrez la [page des rôles](https://console.aws.amazon.com/iam/home#/roles) dans la console IAM.
1. Choisissez **Créer un rôle**.
1. Pour **Type d’entité de confiance**, choisissez **Service AWS **.
1. Pour **Cas d’utilisation**, choisissez **Lambda**.
1. Choisissez **Suivant**.
1. Ajoutez une stratégie d’autorisations de base au rôle en procédant comme suit :
1. Dans le champ de recherche **Politiques d’autorisations**, saisissez **AWSLambdaBasicExecutionRole**.
1. Choisissez **Suivant**.
1. Finalisez la création du rôle en procédant comme suit :
1. Sous **Détails du rôle**, saisissez **lambda-sns-role** pour **Nom du rôle**.
1. Choisissez **Créer un rôle**.
## Créer une fonction Lambda (compte B)
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-sns-tutorial/sns_tut_steps_3.png)
Créez une fonction Lambda qui traite vos messages Amazon SNS. Le code de fonction enregistre le contenu des messages de chaque enregistrement dans Amazon CloudWatch Logs.
Ce didacticiel utilise le runtime Node.js 24, mais nous avons également fourni des exemples de code dans d'autres langages d'exécution. Vous pouvez sélectionner l’onglet dans la zone suivante pour voir le code de l’exécution qui vous intéresse. Le JavaScript code que vous allez utiliser dans cette étape se trouve dans le premier exemple présenté dans l'**JavaScript**onglet.
------
#### [ .NET ]
**SDK pour .NET**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sns-to-lambda).
Consommation d’un événement SNS avec Lambda à l’aide de .NET.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using Amazon.Lambda.Core;
using Amazon.Lambda.SNSEvents;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace SnsIntegration;
public class Function
{
public async Task FunctionHandler(SNSEvent evnt, ILambdaContext context)
{
foreach (var record in evnt.Records)
{
await ProcessRecordAsync(record, context);
}
context.Logger.LogInformation("done");
}
private async Task ProcessRecordAsync(SNSEvent.SNSRecord record, ILambdaContext context)
{
try
{
context.Logger.LogInformation($"Processed record {record.Sns.Message}");
// TODO: Do interesting work based on the new message
await Task.CompletedTask;
}
catch (Exception e)
{
//You can use Dead Letter Queue to handle failures. By configuring a Lambda DLQ.
context.Logger.LogError($"An error occurred");
throw;
}
}
}
```
------
#### [ Go ]
**Kit SDK pour Go V2**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sns-to-lambda).
Consommation d’un événement SNS avec Lambda à l’aide de Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package main
import (
"context"
"fmt"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func handler(ctx context.Context, snsEvent events.SNSEvent) {
for _, record := range snsEvent.Records {
processMessage(record)
}
fmt.Println("done")
}
func processMessage(record events.SNSEventRecord) {
message := record.SNS.Message
fmt.Printf("Processed message: %s\n", message)
// TODO: Process your record here
}
func main() {
lambda.Start(handler)
}
```
------
#### [ Java ]
**SDK pour Java 2.x**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sns-to-lambda).
Consommation d’un événement SNS avec Lambda à l’aide de Java.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package example;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.LambdaLogger;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.SNSEvent;
import com.amazonaws.services.lambda.runtime.events.SNSEvent.SNSRecord;
import java.util.Iterator;
import java.util.List;
public class SNSEventHandler implements RequestHandler {
LambdaLogger logger;
@Override
public Boolean handleRequest(SNSEvent event, Context context) {
logger = context.getLogger();
List records = event.getRecords();
if (!records.isEmpty()) {
Iterator recordsIter = records.iterator();
while (recordsIter.hasNext()) {
processRecord(recordsIter.next());
}
}
return Boolean.TRUE;
}
public void processRecord(SNSRecord record) {
try {
String message = record.getSNS().getMessage();
logger.log("message: " + message);
} catch (Exception e) {
throw new RuntimeException(e);
}
}
}
```
------
#### [ JavaScript ]
**SDK pour JavaScript (v3)**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/blob/main/integration-sns-to-lambda).
Consommation d'un événement SNS avec JavaScript Lambda en utilisant.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
exports.handler = async (event, context) => {
for (const record of event.Records) {
await processMessageAsync(record);
}
console.info("done");
};
async function processMessageAsync(record) {
try {
const message = JSON.stringify(record.Sns.Message);
console.log(`Processed message ${message}`);
await Promise.resolve(1); //Placeholder for actual async work
} catch (err) {
console.error("An error occurred");
throw err;
}
}
```
Consommation d'un événement SNS avec TypeScript Lambda en utilisant.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import { SNSEvent, Context, SNSHandler, SNSEventRecord } from "aws-lambda";
export const functionHandler: SNSHandler = async (
event: SNSEvent,
context: Context
): Promise => {
for (const record of event.Records) {
await processMessageAsync(record);
}
console.info("done");
};
async function processMessageAsync(record: SNSEventRecord): Promise {
try {
const message: string = JSON.stringify(record.Sns.Message);
console.log(`Processed message ${message}`);
await Promise.resolve(1); //Placeholder for actual async work
} catch (err) {
console.error("An error occurred");
throw err;
}
}
```
------
#### [ PHP ]
**Kit SDK pour PHP**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sns-to-lambda).
Utilisation d’un événement SNS avec Lambda à l’aide de PHP.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
getRecords() as $record) {
$message = $record->getMessage();
// TODO: Implement your custom processing logic here
// Any exception thrown will be logged and the invocation will be marked as failed
echo "Processed Message: $message" . PHP_EOL;
}
}
}
return new Handler();
```
------
#### [ Python ]
**Kit SDK for Python (Boto3)**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sns-to-lambda).
Utilisation d’un événement SNS avec Lambda à l’aide de Python.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def lambda_handler(event, context):
for record in event['Records']:
process_message(record)
print("done")
def process_message(record):
try:
message = record['Sns']['Message']
print(f"Processed message {message}")
# TODO; Process your record here
except Exception as e:
print("An error occurred")
raise e
```
------
#### [ Ruby ]
**Kit SDK pour Ruby**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sns-to-lambda).
Consommation d’un événement SNS avec Lambda à l’aide de Ruby.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def lambda_handler(event:, context:)
event['Records'].map { |record| process_message(record) }
end
def process_message(record)
message = record['Sns']['Message']
puts("Processing message: #{message}")
rescue StandardError => e
puts("Error processing message: #{e}")
raise
end
```
------
#### [ Rust ]
**SDK pour Rust**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sns-to-lambda).
Utilisation d’un événement S3 avec Lambda à l’aide de Rust.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
use aws_lambda_events::event::sns::SnsEvent;
use aws_lambda_events::sns::SnsRecord;
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
use tracing::info;
// Built with the following dependencies:
// aws_lambda_events = { version = "0.10.0", default-features = false, features = ["sns"] }
// lambda_runtime = "0.8.1"
// tokio = { version = "1", features = ["macros"] }
// tracing = { version = "0.1", features = ["log"] }
// tracing-subscriber = { version = "0.3", default-features = false, features = ["fmt"] }
async fn function_handler(event: LambdaEvent) -> Result<(), Error> {
for event in event.payload.records {
process_record(&event)?;
}
Ok(())
}
fn process_record(record: &SnsRecord) -> Result<(), Error> {
info!("Processing SNS Message: {}", record.sns.message);
// Implement your record handling code here.
Ok(())
}
#[tokio::main]
async fn main() -> Result<(), Error> {
tracing_subscriber::fmt()
.with_max_level(tracing::Level::INFO)
.with_target(false)
.without_time()
.init();
run(service_fn(function_handler)).await
}
```
------
**Pour créer la fonction**
1. Créez un répertoire pour le projet, puis passez à ce répertoire.
```
mkdir sns-tutorial
cd sns-tutorial
```
1. Copiez l'exemple de JavaScript code dans un nouveau fichier nommé`index.js`.
1. Créez un package de déploiement à l’aide de la commande `zip` suivante.
```
zip function.zip index.js
```
1. Exécutez la AWS CLI commande suivante pour créer votre fonction Lambda dans le **compte B.**
```
aws lambda create-function --function-name Function-With-SNS \
--zip-file fileb://function.zip --handler index.handler --runtime nodejs24.x \
--role arn:aws:iam:::role/lambda-sns-role \
--timeout 60 --profile accountB
```
Vous devez visualiser des résultats similaires à ce qui suit.
```
{
"FunctionName": "Function-With-SNS",
"FunctionArn": "arn:aws:lambda:us-west-2:123456789012:function:Function-With-SNS",
"Runtime": "nodejs24.x",
"Role": "arn:aws:iam::123456789012:role/lambda_basic_role",
"Handler": "index.handler",
...
"RuntimeVersionConfig": {
"RuntimeVersionArn": "arn:aws:lambda:us-west-2::runtime:7d5f06b69c951da8a48b926ce280a9daf2e8bb1a74fc4a2672580c787d608206"
}
}
```
1. Enregistrez l’Amazon Resource Name (ARN) de votre fonction. Vous en aurez besoin plus tard dans le tutoriel lorsque vous ajouterez les autorisations permettant à Amazon SNS d’invoquer votre fonction.
## Ajouter des autorisations à la fonction (compte B)
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-sns-tutorial/sns_tut_steps_4.png)
Pour qu’Amazon SNS puisse invoquer votre fonction, vous devez lui accorder une autorisation dans une instruction sur une [stratégie basée sur les ressources](access-control-resource-based.md). Vous ajoutez cette instruction à l'aide de la AWS CLI `add-permission` commande.
**Pour accorder à Amazon SNS l’autorisation d’invoquer votre fonction**
+ Dans le **compte B**, exécutez la AWS CLI commande suivante en utilisant l'ARN de votre rubrique Amazon SNS que vous avez enregistrée précédemment.
```
aws lambda add-permission --function-name Function-With-SNS \
--source-arn arn:aws:sns:us-east-1::sns-topic-for-lambda \
--statement-id function-with-sns --action "lambda:InvokeFunction" \
--principal sns.amazonaws.com --profile accountB
```
Vous devez visualiser des résultats similaires à ce qui suit.
```
{
"Statement": "{\"Condition\":{\"ArnLike\":{\"AWS:SourceArn\":
\"arn:aws:sns:us-east-1::sns-topic-for-lambda\"}},
\"Action\":[\"lambda:InvokeFunction\"],
\"Resource\":\"arn:aws:lambda:us-east-1::function:Function-With-SNS\",
\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"sns.amazonaws.com\"},
\"Sid\":\"function-with-sns\"}"
}
```
**Note**
Si le compte associé à la rubrique Amazon SNS est hébergé dans le cadre d'un [opt-in Région AWS](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html), vous devez spécifier la région dans le principal. Si vous travaillez par exemple avec une rubrique Amazon SNS dans la région Asie-Pacifique (Hong Kong), vous devez spécifier `sns.ap-east-1.amazonaws.com` au lieu de `sns.amazonaws.com` pour le principal.
## Accorder une autorisation multicompte pour l’abonnement Amazon SNS (compte A)
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-sns-tutorial/sns_tut_steps_5.png)
Pour que votre fonction Lambda dans le **compte B** s’abonne à la rubrique Amazon SNS que vous avez créée dans le **compte A**, vous devez accorder l’autorisation au **compte B** de s’abonner à votre rubrique. Vous accordez cette autorisation à l'aide de la AWS CLI `add-permission` commande.
**Pour accorder l’autorisation permettant au compte B de s’abonner à la rubrique**
+ Dans le **compte A**, exécutez la AWS CLI commande suivante. Utilisez l’ARN pour la rubrique Amazon SNS que vous avez enregistrée précédemment.
```
aws sns add-permission --label lambda-access --aws-account-id \
--topic-arn arn:aws:sns:us-east-1::sns-topic-for-lambda \
--action-name Subscribe ListSubscriptionsByTopic --profile accountA
```
## Créer un abonnement (compte B)
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-sns-tutorial/sns_tut_steps_6.png)
Dans le **compte B**, vous abonnez à présent votre fonction Lambda à la rubrique Amazon SNS que vous avez créée au début du tutoriel dans le **compte A**. Lorsqu’un message est envoyé à cette rubrique (`sns-topic-for-lambda`), Amazon SNS invoque votre fonction Lambda `Function-With-SNS` dans le **compte B**.
**Pour créer un abonnement**
+ Dans le **compte B**, exécutez la AWS CLI commande suivante. Utilisez la région par défaut dans laquelle vous avez créé votre sujet, ainsi que la région ARNs correspondant à votre sujet et la fonction Lambda.
```
aws sns subscribe --protocol lambda \
--region us-east-1 \
--topic-arn arn:aws:sns:us-east-1::sns-topic-for-lambda \
--notification-endpoint arn:aws:lambda:us-east-1::function:Function-With-SNS \
--profile accountB
```
Vous devez visualiser des résultats similaires à ce qui suit.
```
{
"SubscriptionArn": "arn:aws:sns:us-east-1::sns-topic-for-lambda:5d906xxxx-7c8x-45dx-a9dx-0484e31c98xx"
}
```
## Publier des messages sur la rubrique (compte A et compte B)
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/services-sns-tutorial/sns_tut_steps_7.png)
Maintenant que votre fonction Lambda dans le **compte B** est abonnée à votre rubrique Amazon SNS dans le **compte A**, il est temps de tester votre configuration en publiant des messages sur votre rubrique. Pour vérifier qu'Amazon SNS a invoqué votre fonction Lambda, utilisez CloudWatch Logs pour afficher le résultat de votre fonction.
**Pour publier un message sur votre rubrique et consulter le résultat de votre fonction**
1. Saisissez `Hello World` dans un fichier texte et enregistrez-le sous `message.txt`.
1. À partir du répertoire dans lequel vous avez enregistré votre fichier texte, exécutez la AWS CLI commande suivante dans le **compte A.** Utilisez l'ARN pour votre propre sujet.
```
aws sns publish --message file://message.txt --subject Test \
--topic-arn arn:aws:sns:us-east-1::sns-topic-for-lambda \
--profile accountA
```
Cette commande renverra un ID de message avec un identifiant unique, indiquant qu’Amazon SNS a accepté le message. Amazon SNS tente alors de livrer le message aux abonnés de la rubrique. Pour vérifier qu'Amazon SNS a invoqué votre fonction Lambda, utilisez CloudWatch Logs pour afficher le résultat de votre fonction :
1. Dans le **compte B**, ouvrez la page [Log groups](https://console.aws.amazon.com/cloudwatch/home#logsV2:log-groups) de la CloudWatch console Amazon.
1. Choisissez le groupe de journaux de votre fonction (`/aws/lambda/Function-With-SNS`).
1. Choisissez le flux de journaux le plus récent.
1. Si votre fonction a été correctement invoquée, vous verrez une sortie similaire à la suivante montrant le contenu du message que vous avez publié dans votre rubrique.
```
2023-07-31T21:42:51.250Z c1cba6b8-ade9-4380-aa32-d1a225da0e48 INFO Processed message Hello World
2023-07-31T21:42:51.250Z c1cba6b8-ade9-4380-aa32-d1a225da0e48 INFO done
```
## Nettoyage de vos ressources
Vous pouvez maintenant supprimer les ressources que vous avez créées pour ce didacticiel, sauf si vous souhaitez les conserver. En supprimant AWS les ressources que vous n'utilisez plus, vous évitez des frais inutiles pour votre Compte AWS.
Dans le **compte A**, nettoyez votre rubrique Amazon SNS.
**Pour supprimer la rubrique Amazon SNS**
1. Ouvrez la page [Topics (Rubriques)](https://console.aws.amazon.com//sns/home#topics:) de la console Amazon SNS.
1. Sélectionnez la rubrique que vous avez créée.
1. Choisissez **Supprimer**.
1. Saisissez **delete me** dans le champ de saisie de texte.
1. Sélectionnez **Delete (Supprimer)**.
Dans le **compte A**, nettoyez votre rôle d’exécution, votre fonction Lambda et votre abonnement Amazon SNS.
**Pour supprimer le rôle d’exécution**
1. Ouvrez la [page Roles (Rôles)](https://console.aws.amazon.com/iam/home#/roles) de la console IAM.
1. Sélectionnez le rôle d’exécution que vous avez créé.
1. Sélectionnez **Delete (Supprimer)**.
1. Saisissez le nom du rôle dans le champ de saisie de texte et choisissez **Delete** (Supprimer).
**Pour supprimer la fonction Lambda**
1. Ouvrez la [page Functions (Fonctions)](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda.
1. Sélectionnez la fonction que vous avez créée.
1. Sélectionnez **Actions**, **Supprimer**.
1. Saisissez **confirm** dans la zone de saisie de texte et choisissez **Delete** (Supprimer).
**Pour supprimer l’abonnement Amazon SNS**
1. Ouvrez la [page Subscriptions (Abonnements)](https://console.aws.amazon.com//sns/home#subscriptions:) de la console Amazon SNS.
1. Sélectionnez l’abonnement que vous avez créé.
1. Choisissez **Delete (Supprimer)**, **Delete (Supprimer)**.