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.
# Développez votre application sans serveur avec AWS SAM
Cette section contient des rubriques relatives à la validation de votre AWS SAM modèle et à la création de votre application avec des dépendances. Il contient également des rubriques relatives à l'utilisation AWS SAM dans certains cas d'utilisation tels que l'utilisation de couches Lambda, l'utilisation d'applications imbriquées, le contrôle de l'accès à API Gateway APIs, l'orchestration des ressources avec AWS Step Functions et la signature de code de vos applications. Les trois étapes principales que vous devez franchir pour développer votre application sont répertoriées ci-dessous.
**Topics**
+ [Créez votre application dans AWS SAM](using-sam-cli-init.md)
+ [Définissez votre infrastructure avec AWS SAM](serverless-authoring.md)
+ [Créez votre application avec AWS SAM](serverless-building.md)
# Créez votre application dans AWS SAM
Après avoir terminé [Getting started](serverless-getting-started.md) et lu[Comment utiliser AWS Serverless Application Model (AWS SAM)](chapter-using-sam.md), vous serez prêt à créer un AWS SAM projet dans votre environnement de développement. Votre AWS SAM projet servira de point de départ pour l'écriture de votre application sans serveur. Pour obtenir la liste des options de AWS SAMCLI `sam init` commande, consultez[sam init](sam-cli-command-reference-sam-init.md).
La AWS Serverless Application Model commande Command Line Interface (AWS SAMCLI) `sam init` fournit des options permettant d'initialiser une nouvelle application sans serveur composée des éléments suivants :
+ Un AWS SAM modèle pour définir votre code d'infrastructure.
+ Une structure de dossiers qui organise votre application.
+ Configuration de vos AWS Lambda fonctions.
Pour créer un AWS SAM projet, reportez-vous aux rubriques de ces sections.
**Note**
`sam init`inclut des modèles de projet pour les fonctions durables dans les environnements d'exécution pris en charge (PythonTypeScript, Java). Ces modèles fournissent le code de démarrage et la configuration nécessaires à la création d'applications sans serveur dynamiques.
**Topics**
+ [Initialiser une nouvelle application sans serveur](#using-sam-cli-init-new)
+ [Options pour sam init](#using-sam-cli-init-options)
+ [Résolution des problèmes](#using-sam-cli-init-troubleshooting)
+ [Exemples](#using-sam-cli-init-examples)
+ [En savoir plus](#using-sam-cli-init-learn)
+ [Étapes suivantes](#w2aac18c11c39)
## Initialiser une nouvelle application sans serveur
**Pour initialiser une nouvelle application sans serveur à l'aide de la CLI AWS SAM**
1. `cd` vers un répertoire de départ.
1. Dans la ligne de commande, exécutez la commande suivante :
```
$ sam init
```
1. La CLI AWS SAM vous guidera à travers un flux interactif pour créer une nouvelle application sans serveur.
**Note**
Comme indiqué dans[Tutoriel : Déployer une application Hello World avec AWS SAM](serverless-getting-started-hello-world.md), cette commande initialise votre application sans serveur et crée le répertoire de votre projet. Ce répertoire contiendra plusieurs fichiers et dossiers. Le fichier le plus important est`template.yaml`. Il s'agit de votre AWS SAM modèle. Votre version de python doit correspondre à la version de python répertoriée dans le `template.yaml` fichier créé par la **sam init** commande.
### Choisir un modèle de départ
Un *modèle* se compose des éléments suivants :
1. Un AWS SAM modèle pour votre code d'infrastructure.
1. Un répertoire de départ qui organise les fichiers de votre projet. Par exemple, cela peut inclure :
1. Une structure pour votre code de fonction Lambda et leurs dépendances.
1. Un dossier `events` qui contient les événements de test pour les tests locaux.
1. Un dossier `tests` destiné à faciliter les tests d'unités.
1. Un fichier `samconfig.toml` pour configurer les paramètres du projet.
1. Un fichier `ReadMe` et d'autres fichiers de base du projet de départ.
Voici un exemple de répertoire de projet de départ :
```
sam-app
├── README.md
├── __init__.py
├── events
│ └── event.json
├── hello_world
│ ├── __init__.py
│ ├── app.py
│ └── requirements.txt
├── samconfig.toml
├── template.yaml
└── tests
├── __init__.py
├── integration
│ ├── __init__.py
│ └── test_api_gateway.py
├── requirements.txt
└── unit
├── __init__.py
└── test_handler.py
```
Vous pouvez choisir parmi une liste de *modèles de démarrage rapide AWS * disponibles ou fournir votre propre *emplacement de modèle personnalisé*.
**Pour choisir un modèle de démarrage AWS rapide**
1. Lorsque vous y êtes invité, sélectionnez **modèles de démarrage rapide AWS **.
1. Sélectionnez un modèle de démarrage AWS rapide pour commencer. Voici un exemple :
```
Which template source would you like to use?
1 - AWS Quick Start Templates
2 - Custom Template Location
Choice: 1
Choose an AWS Quick Start application template
1 - Hello World Example
2 - Multi-step workflow
3 - Serverless API
4 - Scheduled task
5 - Standalone function
6 - Data processing
7 - Hello World Example With Powertools
8 - Infrastructure event management
9 - Serverless Connector Hello World Example
10 - Multi-step workflow with Connectors
11 - Lambda EFS example
12 - DynamoDB Example
13 - Machine Learning
Template: 4
```
**Pour choisir l'emplacement de votre modèle personnalisé**
1. Lorsque vous y êtes invité, sélectionnez l'**emplacement du modèle personnalisé**.
```
Which template source would you like to use?
1 - AWS Quick Start Templates
2 - Custom Template Location
Choice: 2
```
1. La CLI AWS SAM vous invitera à indiquer l'emplacement du modèle.
```
Template location (git, mercurial, http(s), zip, path):
```
Indiquez l'un des emplacements suivants pour l'archive du fichier .zip de votre modèle :
+ **Référentiel GitHub** : chemin d'accès au fichier .zip de votre référentiel GitHub. Le fichier doit se trouver à la racine de votre référentiel.
+ **Référentiel Mercurial** : chemin d'accès au fichier .zip de votre référentiel Mercurial. Le fichier doit se trouver à la racine de votre référentiel.
+ **Chemin .zip** : chemin HTTPS ou local vers votre fichier .zip.
1. La CLI AWS SAM initialisera votre application sans serveur à l'aide de votre modèle personnalisé.
### Choisir une exécution
Lorsque vous choisissez un *modèle de démarrage rapide AWS *, la CLI AWS SAM vous invite à sélectionner une exécution pour vos fonctions Lambda. La liste des options affichées par la CLI AWS SAM correspond aux exécutions prises en charge nativement par Lambda.
+ Le [runtime](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-concepts.html#gettingstarted-concepts-runtime) fournit un environnement spécifique au langage qui s’exécute dans un environnement d’exécution.
+ [Lorsqu'il est déployé sur le AWS Cloud, le service Lambda appelle votre fonction dans un environnement d'exécution.](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html)
Vous pouvez utiliser n'importe quel autre langage de programmation doté d'une exécution personnalisée. Pour ce faire, vous devez créer manuellement la structure de votre application de départ. Vous pouvez ensuite utiliser `sam init` pour initialiser rapidement votre application en configurant un emplacement de modèle personnalisé.
À partir de votre sélection, la CLI AWS SAM crée le répertoire de départ pour votre code de fonction Lambda et vos dépendances.
Si Lambda prend en charge plusieurs gestionnaires de dépendances pour votre exécution, vous serez invité à choisir votre gestionnaire de dépendances préféré.
### Choisir un type de package
Lorsque vous choisissez un *modèle de démarrage rapide AWS *, et une *exécution* laCLI AWS SAM vous invite à sélectionner un *type de package*. Le type de package détermine la manière dont vos fonctions Lambda sont déployées pour être utilisées avec le service Lambda. Les deux types de packages pris en charge sont les suivants :
1. **Image du conteneur** : contient le système d'exploitation de base, l'exécution, les extensions Lambda, le code de votre application et ses dépendances.
1. **.zip file archive** : contient le code de votre application et ses dépendances.
Pour en savoir plus sur le package de déploiement, consultez [Packages de déploiement Lambda](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-package.html) dans le *Guide du développeur AWS Lambda *.
Voici un exemple de structure de répertoires d'une application avec une fonction Lambda packagée sous forme d'image de conteneur. AWS SAMCLITélécharge l'image et en crée une `Dockerfile` dans le répertoire de la fonction pour spécifier l'image.
```
sam-app
├── README.md
├── __init__.py
├── events
│ └── event.json
├── hello_world
│ ├── Dockerfile
│ ├── __init__.py
│ ├── app.py
│ └── requirements.txt
├── samconfig.toml
├── template.yaml
└── tests
├── __init__.py
└── unit
├── __init__.py
└── test_handler.py
```
Voici un exemple de structure de répertoires d'une application avec une fonction packagée sous forme d'archive de fichier .zip.
```
sam-app
├── README.md
├── __init__.py
├── events
│ └── event.json
├── hello_world
│ ├── __init__.py
│ ├── app.py
│ └── requirements.txt
├── samconfig.toml
├── template.yaml
└── tests
├── __init__.py
├── integration
│ ├── __init__.py
│ └── test_api_gateway.py
├── requirements.txt
└── unit
├── __init__.py
└── test_handler.py
```
### Configuration du AWS X-Ray suivi
Vous pouvez choisir d'activer le AWS X-Ray suivi. Pour en savoir plus, consultez [Qu'est-ce que c'est AWS X-Ray ?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) dans le *Guide AWS X-Ray du développeur*.
Si vous l'activez, votre AWS SAM modèle AWS SAMCLI est configuré. Voici un exemple :
```
Globals:
Function:
...
Tracing: Active
Api:
TracingEnabled: True
```
### Configurer la surveillance avec Amazon CloudWatch Application Insights
Vous pouvez choisir d'activer la surveillance à l'aide d'Amazon CloudWatch Application Insights. Pour en savoir plus, consultez [Amazon CloudWatch Application Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-application-insights.html) dans le *guide de CloudWatch l'utilisateur Amazon*.
Si vous l'activez, votre AWS SAM modèle AWS SAMCLI est configuré. Voici un exemple :
```
Resources:
ApplicationResourceGroup:
Type: AWS::ResourceGroups::Group
Properties:
Name:
Fn::Join:
- ''
- - ApplicationInsights-SAM-
- Ref: AWS::StackName
ResourceQuery:
Type: CLOUDFORMATION_STACK_1_0
ApplicationInsightsMonitoring:
Type: AWS::ApplicationInsights::Application
Properties:
ResourceGroupName:
Fn::Join:
- ''
- - ApplicationInsights-SAM-
- Ref: AWS::StackName
AutoConfigurationEnabled: 'true'
DependsOn: ApplicationResourceGroup
```
### Nommer votre application
Saisissez un nom pour votre application. La CLI AWS SAM crée un dossier de niveau supérieur pour votre application sous ce nom.
## Options pour sam init
Voici quelques-unes des principales options que vous pouvez utiliser avec la commande `sam init`. Pour obtenir la liste de toutes les options, consultez [sam init](sam-cli-command-reference-sam-init.md).
### Initialiser une application à l'aide d'un emplacement de modèle personnalisé
Utilisez l'option `--location` et indiquez un emplacement de modèle personnalisé pris en charge. Voici un exemple :
```
$ sam init --location https://github.com/aws-samples/sessions-with-aws-sam/raw/master/starter-templates/web-app.zip
```
### Initialiser une application sans le flux interactif
Utilisez l'option `--no-interactive` et indiquez vos choix de configuration sur la ligne de commande pour ignorer le flux interactif. Voici un exemple :
```
$ sam init --no-interactive --runtime go1.x --name go-demo --dependency-manager mod --app-template hello-world
```
## Résolution des problèmes
Pour résoudre le problème AWS SAMCLI, voir[Résolution des problèmes de la CLI AWS SAM](sam-cli-troubleshooting.md).
## Exemples
### Initialiser une nouvelle application sans serveur à l'aide du modèle de démarrage Hello World AWS
Pour cet exemple, consultez [Étape 1 : initialisation de l'exemple d'application Hello World](serverless-getting-started-hello-world.md#serverless-getting-started-hello-world-init) dans le *didacticiel : déploiement de l'application Hello World*.
### Initialiser une nouvelle application sans serveur avec un emplacement de modèle personnalisé
Vous trouverez ci-dessous des exemples d'ajout d'un emplacement GitHub à votre modèle personnalisé :
```
$ sam init --location gh:aws-samples/cookiecutter-aws-sam-python
$ sam init --location git+sh://git@github.com/aws-samples/cookiecutter-aws-sam-python.git
$ sam init --location hg+ssh://hg@bitbucket.org/repo/template-name
```
Voici un exemple de chemin d'accès à un fichier local :
```
$ sam init --location /path/to/template.zip
```
Voici un exemple de chemin accessible par HTTPS :
```
$ sam init --location https://github.com/aws-samples/sessions-with-aws-sam/raw/master/starter-templates/web-app.zip
```
## En savoir plus
Pour en savoir plus sur l'utilisation de la commande `sam init`, reportez-vous à ce qui suit :
+ **[Apprentissage AWS SAM : sam init](https://www.youtube.com/watch?v=9m3R-leD5Xo)** — Série Serverless Land « Learning AWS SAM » surYouTube.
+ **[Structurer des applications sans serveur pour les utiliser avec la CLI AWS SAM(sessions avec SAM S2E7)](https://www.youtube.com/watch?v=k9IRdgze9fQ)** – sessions avec les séries AWS SAM sur YouTube.
## Étapes suivantes
Maintenant que vous avez créé votre AWS SAM projet, vous êtes prêt à créer votre application. Consultez [Définissez votre infrastructure avec AWS SAM](serverless-authoring.md) les instructions détaillées sur les tâches que vous devez effectuer pour ce faire.
# Définissez votre infrastructure avec AWS SAM
Maintenant que vous avez créé votre projet, vous êtes prêt à définir votre infrastructure d'applications avec AWS SAM. Pour ce faire, configurez votre AWS SAM modèle pour définir les ressources et les propriétés de votre application, c'est-à-dire le `template.yaml` fichier de votre AWS SAM projet.
Les rubriques de cette section fournissent du contenu sur la définition de votre infrastructure dans votre AWS SAM modèle (votre `template.yaml` fichier). Il contient également des rubriques sur la définition de ressources pour des cas d'utilisation spécifiques, tels que l'utilisation de couches Lambda, l'utilisation d'applications imbriquées, le contrôle de l'accès à API Gateway APIs, l'orchestration des ressources avec AWS Step Functions, la signature de code de vos applications et la validation de votre modèle. AWS SAM
**Topics**
+ [Définissez les ressources de l'application dans votre AWS SAM modèle](authoring-define-resources.md)
+ [Configuration et gestion de l'accès aux ressources dans votre AWS SAM modèle](sam-permissions.md)
+ [Contrôlez l'accès aux API avec votre AWS SAM modèle](serverless-controlling-access-to-apis.md)
+ [Améliorez l'efficacité en utilisant les couches Lambda avec AWS SAM](serverless-sam-cli-layers.md)
+ [Réutilisez le code et les ressources à l'aide d'applications imbriquées dans AWS SAM](serverless-sam-template-nested-applications.md)
+ [Gérez les événements temporels avec le EventBridge planificateur dans AWS SAM](using-eventbridge-scheduler.md)
+ [Orchestrer les AWS SAM ressources avec AWS Step Functions](serverless-step-functions-in-sam.md)
+ [Configurer la signature de code pour votre AWS SAM application](authoring-codesigning.md)
+ [Valider les fichiers AWS SAM modèles](serverless-sam-cli-using-validate.md)
# Définissez les ressources de l'application dans votre AWS SAM modèle
Vous définissez les AWS ressources utilisées par votre application sans serveur dans la `Resources` section de votre AWS SAM modèle. Lorsque vous définissez une ressource, vous identifiez ce qu'elle est, comment elle interagit avec les autres ressources et comment elle est accessible (c'est-à-dire les autorisations de la ressource).
La `Resources` section de votre AWS SAM modèle peut contenir une combinaison de CloudFormation ressources et de AWS SAM ressources. En outre, vous pouvez utiliser AWS SAM la syntaxe abrégée pour les ressources suivantes :
| AWS SAM syntaxe abrégée | Ce qu'il fait avec une AWS ressource connexe |
| --- | --- |
| [AWS::Serverless::Api](sam-resource-api.md) | Crée une collection de ressources et de méthodes API Gateway qui peuvent être invoquées via des points de terminaison HTTPS. |
| [AWS::Serverless::Application](sam-resource-application.md) | Intègre une application sans serveur à partir du [AWS Serverless Application Repository](https://serverlessrepo.aws.amazon.com/applications) ou à partir d'un compartiment Amazon S3 comme application imbriquée. |
| [AWS::Serverless::Connector](sam-resource-connector.md) | Configure les autorisations entre deux ressources. Pour obtenir une présentation des connecteurs, veuillez consulter [Gestion des autorisations relatives aux ressources à l'aide de AWS SAM connecteurs](managing-permissions-connectors.md). |
| [AWS::Serverless::Function](sam-resource-function.md) | Crée une AWS Lambda fonction, un rôle d'exécution Gestion des identités et des accès AWS (IAM) et des mappages de sources d'événements qui déclenchent la fonction. |
| [AWS::Serverless::GraphQLApi](sam-resource-graphqlapi.md) | crée et configure une AWS AppSync GraphQL API pour votre application sans serveur. |
| [AWS::Serverless::HttpApi](sam-resource-httpapi.md) | Crée une API HTTP Amazon API Gateway, qui vous permet de créer RESTful APIs avec une latence et des coûts inférieurs à ceux de REST APIs. |
| [AWS::Serverless::LayerVersion](sam-resource-layerversion.md) | Crée un Lambda LayerVersion qui contient la bibliothèque ou le code d'exécution nécessaire à une fonction Lambda. |
| [AWS::Serverless::SimpleTable](sam-resource-simpletable.md) | Crée une table DynamoDB avec une clé primaire d'attribut unique. |
| [AWS::Serverless::StateMachine](sam-resource-statemachine.md) | Crée une machine à AWS Step Functions états, que vous pouvez utiliser pour orchestrer des AWS Lambda fonctions et d'autres AWS ressources afin de créer des flux de travail complexes et robustes. |
Les ressources ci-dessus sont également répertoriées dans[AWS SAM ressources et propriétés](sam-specification-resources-and-properties.md).
Pour obtenir des informations de référence sur tous les types de AWS ressources et de propriétés CloudFormation ainsi que sur le AWS SAM support, voir la [référence aux types de AWS ressources et de propriétés](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html) dans le *guide de AWS CloudFormation l'utilisateur*.
# Configuration et gestion de l'accès aux ressources dans votre AWS SAM modèle
Pour que vos AWS ressources puissent interagir les unes avec les autres, l'accès et les autorisations appropriés doivent être configurés entre vos ressources. Pour ce faire, vous devez configurer les utilisateurs, les rôles et les politiques Gestion des identités et des accès AWS (IAM) pour effectuer votre interaction de manière sécurisée.
Les rubriques de cette section concernent toutes la configuration de l'accès aux ressources définies dans votre modèle. Cette section commence par les meilleures pratiques générales. Les deux rubriques suivantes passent en revue deux options dont vous disposez pour configurer l'accès et les autorisations entre les ressources référencées dans votre application sans serveur : les AWS SAM connecteurs et les modèles de AWS SAM politique. La dernière rubrique fournit des détails sur la gestion de l'accès des utilisateurs à l'aide des mêmes mécanismes que CloudFormation ceux utilisés pour gérer les utilisateurs.
Pour en savoir plus, veuillez consulter la rubrique [Contrôle de l'accès avec Gestion des identités et des accès AWS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html) dans le *Guide de l'utilisateur AWS CloudFormation *.
Le AWS Serverless Application Model (AWS SAM) propose deux options qui simplifient la gestion des accès et des autorisations pour vos applications sans serveur.
1. AWS SAM connecteurs
1. Modèles de politique AWS SAM
## AWS SAM connecteurs
Les connecteurs permettent de fournir des autorisations entre deux ressources. Pour ce faire, décrivez comment ils doivent interagir les uns avec les autres dans votre AWS SAM modèle. Ils peuvent être définis à l'aide de l'attribut de ressource `Connectors` ou du type de ressource `AWS::Serverless::Connector`. Les connecteurs prennent en charge le provisionnement `Read` et l'`Write`accès aux données et aux événements entre une combinaison de AWS ressources. Pour en savoir plus sur les AWS SAM connecteurs, voir[Gestion des autorisations relatives aux ressources à l'aide de AWS SAM connecteurs](managing-permissions-connectors.md).
## Modèles de politique AWS SAM
AWS SAM les modèles de politique sont des ensembles prédéfinis d'autorisations que vous pouvez ajouter à vos AWS SAM modèles pour gérer l'accès et les autorisations entre vos AWS Lambda fonctions, vos machines AWS Step Functions d'état et les ressources avec lesquelles elles interagissent. Pour en savoir plus sur les modèles de AWS SAM politiques, consultez[Modèles de politique AWS SAM](serverless-policy-templates.md).
## AWS CloudFormation mécanismes
CloudFormation les mécanismes incluent la configuration des utilisateurs, des rôles et des politiques IAM pour gérer les autorisations entre vos AWS ressources. Pour en savoir plus, veuillez consulter la section [Gestion des AWS SAM autorisations à l'aide de CloudFormation mécanismes](sam-permissions-cloudformation.md).
## Bonnes pratiques
Dans l'ensemble de vos applications sans serveur, vous pouvez utiliser plusieurs méthodes pour configurer les autorisations entre vos ressources. Vous pouvez donc sélectionner la meilleure option pour chaque scénario et utiliser plusieurs options ensemble dans vos applications. Voici quelques éléments à prendre en compte lors du choix de l'option la mieux adaptée à votre cas :
+ AWS SAM les connecteurs et les modèles de politique réduisent tous deux l'expertise IAM requise pour faciliter les interactions sécurisées entre vos AWS ressources. Utilisez des connecteurs et des modèles de politique lorsque cela est possible.
+ AWS SAM les connecteurs fournissent une syntaxe abrégée simple et intuitive pour définir les autorisations dans vos AWS SAM modèles et nécessitent le moins d'expertise en matière d'IAM. Lorsque les AWS SAM connecteurs et les modèles de politique sont pris en charge, utilisez des AWS SAM connecteurs.
+ AWS SAM les connecteurs peuvent fournir des données `Read` et des événements et `Write` y accéder entre les ressources AWS SAM source et de destination prises en charge. Pour afficher la liste des ressources prises en charge, consultez [AWS SAM référence du connecteur](reference-sam-connector.md). Lorsque cela est pris en charge, utilisez AWS SAM des connecteurs.
+ Bien que les modèles de AWS SAM politique soient limités aux autorisations entre vos fonctions Lambda, les machines d'état Step Functions et les AWS ressources avec lesquelles elles interagissent, les modèles de politique prennent en charge toutes les opérations CRUD. Lorsque cela est pris en charge et qu'un modèle de AWS SAM stratégie adapté à votre scénario est disponible, utilisez des modèles AWS SAM de stratégie. Pour afficher la liste des modèles de politique disponibles, consultez [Modèles de politique AWS SAM](serverless-policy-templates.md).
+ Pour tous les autres scénarios, ou lorsque la granularité est requise, utilisez CloudFormation des mécanismes.
# Gestion des autorisations relatives aux ressources à l'aide de AWS SAM connecteurs
Les connecteurs sont un AWS Serverless Application Model (AWS SAM) type de ressource abstrait, identifié comme tel`AWS::Serverless::Connector`, qui fournit des autorisations simples et bien définies entre les ressources de vos applications sans serveur.
## Avantages des AWS SAM connecteurs
En composant automatiquement les politiques d'accès appropriées entre les ressources, les connecteurs vous permettent de créer vos applications sans serveur et de vous concentrer sur l'architecture de votre application sans avoir besoin d'expertise en matière de fonctionnalités d' AWS autorisation, de langage de politique et de paramètres de sécurité spécifiques aux services. Par conséquent, les connecteurs constituent un avantage considérable pour les développeurs novices en matière de développement sans serveur, mais également pour les développeurs chevronnés qui souhaitent augmenter leur vitesse de développement.
## Utilisation de AWS SAM connecteurs
Utilisez l'attribut de ressource `Connectors` en l'incorporant dans une ressource **source**. Définissez ensuite votre ressource de **destination** et décrivez comment les données ou les événements doivent circuler entre ces ressources. AWS SAM compose ensuite les politiques d'accès nécessaires pour faciliter les interactions requises.
Voici un aperçu de la façon dont cet attribut de ressource est écrit :
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
...
Resources:
:
Type:
...
Connectors:
:
Properties:
Destination:
Permissions:
...
```
## Fonctionnement des connecteurs
**Note**
Cette section explique comment les connecteurs fournissent les ressources nécessaires en arrière-plan. Cela se produit automatiquement lorsque vous utilisez des connecteurs.
Tout d'abord, l'attribut de ressource `Connectors` intégré est transformé en un type de ressource `AWS::Serverless::Connector`. Son identifiant logique est automatiquement créé en tant que**.
Par exemple, voici un connecteur intégré :
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
...
Resources:
MyFunction:
Type: AWS::Lambda::Function
Connectors:
MyConn:
Properties:
Destination:
Id: MyTable
Permissions:
- Read
- Write
MyTable:
Type: AWS::DynamoDB::Table
```
Cela générera la ressource `AWS::Serverless::Connector` suivante :
```
Transform: AWS::Serverless-2016-10-31
Resources:
...
MyFunctionMyConn:
Type: AWS::Serverless::Connector
Properties:
Source:
Id: MyFunction
Destination:
Id: MyTable
Permissions:
- Read
- Write
```
**Note**
Vous pouvez également définir des connecteurs dans votre AWS SAM modèle à l'aide de cette syntaxe. Cela est recommandé lorsque votre ressource source est définie sur un modèle distinct de votre connecteur.
Ensuite, les politiques d'accès nécessaires à cette connexion sont automatiquement élaborées. Pour plus d'informations sur les ressources générées par les connecteurs, consultez [CloudFormation ressources générées lorsque vous spécifiez AWS::Serverless::Connector](sam-specification-generated-resources-connector.md).
## Exemple de connecteurs
L'exemple suivant montre comment utiliser des connecteurs pour écrire des données d'une AWS Lambda fonction dans une table Amazon DynamoDB.
![\[Fonction Lambda écrivant des données dans une table DynamoDB à l'aide de connecteurs. AWS SAM\]](http://docs.aws.amazon.com/fr_fr/serverless-application-model/latest/developerguide/images/managing-connectors-example.png)
```
Transform: AWS::Serverless-2016-10-31
Resources:
MyTable:
Type: AWS::Serverless::SimpleTable
MyFunction:
Type: AWS::Serverless::Function
Connectors:
MyConn:
Properties:
Destination:
Id: MyTable
Permissions:
- Write
Properties:
Runtime: nodejs16.x
Handler: index.handler
InlineCode: |
const AWS = require("aws-sdk");
const docClient = new AWS.DynamoDB.DocumentClient();
exports.handler = async (event, context) => {
await docClient.put({
TableName: process.env.TABLE_NAME,
Item: {
id: context.awsRequestId,
event: JSON.stringify(event)
}
}).promise();
}
Environment:
Variables:
TABLE_NAME: !Ref MyTable
```
L'attribut de ressource `Connectors` est intégré à la ressource source de la fonction Lambda. La table DynamoDB est définie comme la ressource de destination à l'aide de la propriété `Id`. Les connecteurs fourniront des autorisations `Write` entre ces deux ressources.
Lorsque vous déployez votre AWS SAM modèle sur CloudFormation, il compose AWS SAM automatiquement les politiques d'accès nécessaires au bon fonctionnement de cette connexion.
## Connexions prises en charge entre les ressources source et de destination
Les connecteurs prennent en charge les types d'autorisations `Read` et `Write` pour les données et les événements entre une combinaison choisie de connexions de ressources source et destination. Par exemple, ils prennent en charge une connexion `Write` entre une ressource source `AWS::ApiGateway::RestApi` et une ressource destination `AWS::Lambda::Function`.
Les ressources source et de destination peuvent être définies à l'aide d'une combinaison de propriétés prises en charge. Les exigences en matière de propriété dépendent de la connexion que vous établissez et de l'endroit où les ressources sont définies.
**Note**
Les connecteurs peuvent attribuer des autorisations entre les types de ressources sans serveur et non sans serveur pris en charge.
Pour obtenir la liste des connexions aux ressources prises en charge et de leurs exigences en matière de propriétés, consultez [Types de ressources source et de destination pris en charge pour les connecteurs](reference-sam-connector.md#supported-connector-resource-types).
# Définissez les autorisations de lecture et d'écriture dans AWS SAM
Dans AWS SAM, `Read` et `Write` les autorisations peuvent être allouées au sein d'un seul connecteur :
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
...
Resources:
MyFunction:
Type: AWS::Lambda::Function
Connectors:
MyTableConn:
Properties:
Destination:
Id: MyTable
Permissions:
- Read
- Write
MyTable:
Type: AWS::DynamoDB::Table
```
Pour plus d'informations sur l'utilisation des connecteurs, reportez-vous à[AWS SAM référence du connecteur](reference-sam-connector.md).
# Définissez les ressources à l'aide d'autres propriétés prises en charge dans AWS SAM
Pour les ressources source et de destination, lorsqu'elles sont définies dans le même modèle, utilisez la propriété `Id`. Sinon, un élément `Qualifier` peut être ajouté pour réduire la portée de la ressource que vous avez définie. Quand les ressources ne se trouvent pas dans le même modèle, utilisez une combinaison d'autres propriétés prises en charge.
+ Pour obtenir la liste des combinaisons de propriétés prises en charge pour les ressources source et de destination, consultez [Types de ressources source et de destination pris en charge pour les connecteurs](reference-sam-connector.md#supported-connector-resource-types).
+ Pour obtenir une description des propriétés que vous pouvez utiliser avec les connecteurs, reportez-vous à la section [AWS::Serverless::Connector](sam-resource-connector.md).
Lorsque vous définissez une ressource source avec une propriété autre que la propriété `Id`, utilisez la propriété `SourceReference`.
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
...
Resources:
:
Type:
...
Connectors:
:
Properties:
SourceReference:
Qualifier:
Destination:
Permissions:
```
Voici un exemple d'utilisation d'un élément `Qualifier` pour réduire la portée d'une ressource Amazon API Gateway :
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
...
Resources:
MyApi:
Type: AWS::Serverless::Api
Connectors:
ApiToLambdaConn:
Properties:
SourceReference:
Qualifier: Prod/GET/foobar
Destination:
Id: MyFunction
Permissions:
- Write
...
```
Voici un exemple utilisant une combinaison prise en charge d'éléments `Arn` et `Type` pour définir une ressource de destination à partir d'un autre modèle :
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
...
Resources:
MyFunction:
Type: AWS::Serverless::Function
Connectors:
TableConn:
Properties:
Destination:
Type: AWS::DynamoDB::Table
Arn: !GetAtt MyTable.Arn
...
```
Pour plus d'informations sur l'utilisation des connecteurs, reportez-vous à[AWS SAM référence du connecteur](reference-sam-connector.md).
# Créez plusieurs connecteurs à partir d'une seule source dans AWS SAM
Au sein d'une ressource source, vous pouvez définir plusieurs connecteurs, chacun ayant une ressource de destination différente.
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
...
Resources:
MyFunction:
Type: AWS::Serverless::Function
Connectors:
BucketConn:
Properties:
Destination:
Id: amzn-s3-demo-bucket
Permissions:
- Read
- Write
SQSConn:
Properties:
Destination:
Id: MyQueue
Permissions:
- Read
- Write
TableConn:
Properties:
Destination:
Id: MyTable
Permissions:
- Read
- Write
TableConnWithTableArn:
Properties:
Destination:
Type: AWS::DynamoDB::Table
Arn: !GetAtt MyTable.Arn
Permissions:
- Read
- Write
...
```
Pour plus d'informations sur l'utilisation des connecteurs, reportez-vous à[AWS SAM référence du connecteur](reference-sam-connector.md).
# Créez des connecteurs à destinations multiples dans AWS SAM
Au sein d'une ressource source, vous pouvez définir un connecteur unique avec plusieurs ressources de destination. Voici un exemple de ressource source d'une fonction Lambda connectée à un compartiment Amazon Simple Storage Service (Amazon S3) et à une table DynamoDB :
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
...
Resources:
MyFunction:
Type: AWS::Serverless::Function
Connectors:
WriteAccessConn:
Properties:
Destination:
- Id: OutputBucket
- Id: CredentialTable
Permissions:
- Write
...
OutputBucket:
Type: AWS::S3::Bucket
CredentialTable:
Type: AWS::DynamoDB::Table
```
Pour plus d'informations sur l'utilisation des connecteurs, reportez-vous à[AWS SAM référence du connecteur](reference-sam-connector.md).
# Définissez les attributs des ressources à l'aide de connecteurs dans AWS SAM
Les attributs de ressource peuvent être définis pour les ressources afin de spécifier des comportements et des relations supplémentaires. Pour plus d'informations sur les attributs des ressources, consultez [Référence d'attribut de ressource](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-product-attribute-reference.html) dans le *Guide de l'utilisateur AWS CloudFormation *.
Vous pouvez ajouter des attributs de ressource à votre connecteur intégré en les définissant au même niveau que les propriétés de votre connecteur. Lorsque votre AWS SAM modèle est transformé lors du déploiement, les attributs sont transmis aux ressources générées.
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
...
Resources:
MyFunction:
Type: AWS::Serverless::Function
Connectors:
MyConn:
DeletionPolicy: Retain
DependsOn: AnotherFunction
Properties:
...
```
Pour plus d'informations sur l'utilisation des connecteurs, reportez-vous à[AWS SAM référence du connecteur](reference-sam-connector.md).
## En savoir plus
Pour plus d'informations sur l'utilisation des AWS SAM connecteurs, consultez les rubriques suivantes :
+ [AWS::Serverless::Connector](sam-resource-connector.md)
+ [Définissez les autorisations de lecture et d'écriture dans AWS SAM](connector-usage-define.md)
+ [Définissez les ressources à l'aide d'autres propriétés prises en charge dans AWS SAM](connector-usage-other-properties.md)
+ [Créez plusieurs connecteurs à partir d'une seule source dans AWS SAM](connector-usage-single-source.md)
+ [Créez des connecteurs à destinations multiples dans AWS SAM](connector-usage-multi-destination.md)
+ [Définissez les autorisations de lecture et d'écriture dans AWS SAM](connector-usage-define.md)
+ [Définissez les attributs des ressources à l'aide de connecteurs dans AWS SAM](connector-usage-resource-attributes.md)
## Faire un commentaire
Pour fournir des commentaires sur les connecteurs, [soumettez un nouveau problème](https://github.com/aws/serverless-application-model/issues/new?assignees=&labels=area%2Fconnectors,stage%2Fneeds-triage&template=other.md&title=%28Feature%20Request%29) dans le *serverless-application-model AWS GitHubréférentiel*.
# Modèles de politique AWS SAM
Le AWS Serverless Application Model (AWS SAM) vous permet de choisir parmi une liste de modèles de politiques pour étendre les autorisations de vos fonctions Lambda et de vos machines d' AWS Step Functions état aux ressources utilisées par votre application.
AWS SAM les applications du AWS Serverless Application Repository qui utilisent des modèles de politique ne nécessitent aucun accusé de réception spécial du client pour déployer l'application depuis le. AWS Serverless Application Repository
Si vous souhaitez demander un nouveau modèle de stratégie à ajouter, procédez comme suit :
1. Soumettez une pull request sur le fichier source policy\$1templates.json dans la branche du `develop` projet. AWS SAM GitHub Vous pouvez trouver le fichier source dans [policy\$1templates.json](https://github.com/aws/serverless-application-model/blob/develop/samtranslator/policy_templates_data/policy_templates.json) sur le site Web. GitHub
1. Soumettez un problème dans le AWS SAM GitHub projet qui inclut les raisons de votre pull request et un lien vers la demande. Utilisez ce lien pour soumettre un nouveau problème : [AWS Serverless Application Model : Problèmes](https://github.com/aws/serverless-application-model/issues/new).
## Syntaxe
Pour chaque modèle de stratégie que vous spécifiez dans votre fichier de AWS SAM modèle, vous devez toujours spécifier un objet contenant les valeurs d'espace réservé du modèle de stratégie. Si un modèle de stratégie ne nécessite aucune valeur d'espace réservé, vous devez spécifier un objet vide.
### YAML
```
MyFunction:
Type: AWS::Serverless::Function
Properties:
Policies:
- PolicyTemplateName1: # Policy template with placeholder value
Key1: Value1
- PolicyTemplateName2: {} # Policy template with no placeholder value
```
**Note**
Si vous avez configuré une politique IAM normale ou si vous avez géré des politiques via Lambda, le modèle de stratégie peut être défini sans utiliser d'objet vide.
## Exemples
### Exemple 1 : Modèle de stratégie avec des valeurs d'espace réservé
L'exemple suivant montre que le modèle de stratégie [SQSPollerPolicy](serverless-policy-template-list.md#sqs-poller-policy) attend un `QueueName` comme ressource. Le AWS SAM modèle récupère le nom de la file « `MyQueue` » Amazon SQS, que vous pouvez créer dans la même application ou demander en tant que paramètre de l'application.
```
1. MyFunction:
2. Type: 'AWS::Serverless::Function'
3. Properties:
4. CodeUri: ${codeuri}
5. Handler: hello.handler
6. Runtime: python2.7
7. Policies:
8. - SQSPollerPolicy:
9. QueueName:
10. !GetAtt MyQueue.QueueName
```
### Exemple 2 : modèle de stratégie sans valeurs d'espace réservé
L'exemple suivant contient le modèle de stratégie[CloudWatchPutMetricPolicy](serverless-policy-template-list.md#cloudwatch-put-metric-policy), qui n'a pas de valeurs d'espace réservé.
**Note**
Même s'il n'y a pas de valeurs d'espace réservé, vous devez spécifier un objet vide, sinon une erreur se produira.
```
1. MyFunction:
2. Type: 'AWS::Serverless::Function'
3. Properties:
4. CodeUri: ${codeuri}
5. Handler: hello.handler
6. Runtime: python2.7
7. Policies:
8. - CloudWatchPutMetricPolicy: {}
```
### Exemple 3 : modèle de politique avec des valeurs d'espace réservé et une politique IAM normale
L'exemple suivant contient la politique et [DynamoDBCrudPolicy](serverless-policy-template-list.md#dynamo-db-crud-policy) le modèle de politique Amazon SQSFull Access. La politique Amazon SQSFull Access est une politique IAM et non une AWS SAM politique. Il n'est donc pas nécessaire de spécifier un objet vide car la politique serait directement transmise au CloudFormation.
```
1. MyFunction:
2. Type: 'AWS::Serverless::Function'
3. Properties:
4. CodeUri: ${codeuri}
5. Handler: hello.handler
6. Runtime: python2.7
7. Policies:
8. - AmazonSQSFullAccess // IAM policy could be set without passing an empty object
9. - DynamoDBCrudPolicy: // SAM specific policy, has a defined structure
10. TableName:
11. !Ref SampleTable
```
## Tableau de modèle de stratégie
Voici un tableau des modèles de stratégie disponibles.
****
| Modèle de stratégie | Description |
| --- | --- |
| [AcmGetCertificatePolicy](serverless-policy-template-list.md#acm-get-certificate-policy) | Donne l'autorisation de lire un certificat à partir de AWS Certificate Manager. |
| [AMIDescribePolicy](serverless-policy-template-list.md#ami-describe-policy) | Donne l'autorisation de décrire Amazon Machine Images (AMIs). |
| [AthenaQueryPolicy](serverless-policy-template-list.md#athena-query-policy) | Donne des autorisations pour exécuter des requêtes Athena. |
| [AWSSecretsManagerGetSecretValuePolicy](serverless-policy-template-list.md#secrets-manager-get-secret-value-policy) | Donne l'autorisation d'obtenir la valeur secrète pour le secret AWS Secrets Manager spécifié. |
| [AWSSecretsManagerRotationPolicy](serverless-policy-template-list.md#secrets-manager-rotation-policy) | Donne l'autorisation de faire pivoter un secret dans AWS Secrets Manager. |
| [CloudFormationDescribeStacksPolicy](serverless-policy-template-list.md#cloud-formation-describe-stacks-policy) | Donne l'autorisation de décrire les CloudFormation piles. |
| [CloudWatchDashboardPolicy](serverless-policy-template-list.md#cloudwatch-dashboard-policy) | Permet de placer des métriques à appliquer sur les CloudWatch tableaux de bord. |
| [CloudWatchDescribeAlarmHistoryPolicy](serverless-policy-template-list.md#cloudwatch-describe-alarm-history-policy) | Permet de décrire l'historique des CloudWatch alarmes. |
| [CloudWatchPutMetricPolicy](serverless-policy-template-list.md#cloudwatch-put-metric-policy) | Donne l'autorisation d'envoyer des métriques à CloudWatch. |
| [CodeCommitCrudPolicy](serverless-policy-template-list.md#codecommit-crud-policy) | Donne des autorisations aux create/read/update/delete objets d'un CodeCommit référentiel spécifique. |
| [CodeCommitReadPolicy](serverless-policy-template-list.md#codecommit-read-policy) | Permet de lire des objets au sein d'un CodeCommit référentiel spécifique. |
| [CodePipelineLambdaExecutionPolicy](serverless-policy-template-list.md#code-pipeline-lambda-execution-policy) | Permet à une fonction Lambda invoquée par CodePipeline de signaler l'état de la tâche. |
| [CodePipelineReadOnlyPolicy](serverless-policy-template-list.md#code-pipeline-readonly-policy) | Donne l'autorisation de lecture pour obtenir des informations sur un CodePipeline pipeline. |
| [ComprehendBasicAccessPolicy](serverless-policy-template-list.md#comprehend-basic-access-policy) | Donne l'autorisation de détecter des entités, des expressions clés, des langues et des sentiments. |
| [CostExplorerReadOnlyPolicy](serverless-policy-template-list.md#cost-explorer-readonly-policy) | Donne une autorisation en lecture seule à Cost APIs Explorer en lecture seule pour l'historique de facturation. |
| [DynamoDBBackupFullAccessPolicy](serverless-policy-template-list.md#ddb-back-full-policy) | Donne l'autorisation de lecture/écriture aux sauvegardes DynamoDB à la demande pour une table. |
| [DynamoDBCrudPolicy](serverless-policy-template-list.md#dynamo-db-crud-policy) | Donne les autorisations de créer, lire, mettre à jour, supprimer à une table Amazon DynamoDB. |
| [DynamoDBReadPolicy](serverless-policy-template-list.md#dynamo-db-read-policy) | Donne l'autorisation de lecture seule à une table DynamoDB. |
| [DynamoDBReconfigurePolicy](serverless-policy-template-list.md#dynamo-db-reconfigure-policy) | Donne l'autorisation de reconfigurer une table DynamoDB. |
| [DynamoDBRestoreFromBackupPolicy](serverless-policy-template-list.md#ddb-restore-from-backup-policy) | Donne l'autorisation de restaurer une table DynamoDB à partir d'une sauvegarde. |
| [DynamoDBStreamReadPolicy](serverless-policy-template-list.md#dynamo-db-stream-read-policy) | Donne l'autorisation de décrire et de lire les flux DynamoDB Streams ainsi que les enregistrements. |
| [DynamoDBWritePolicy](serverless-policy-template-list.md#dynamo-db-write-policy) | Donne l'autorisation d'écriture seule à une table DynamoDB. |
| [EC2CopyImagePolicy](serverless-policy-template-list.md#ec2-copy-image-policy) | Donne l'autorisation de copier les images Amazon EC2. |
| [EC2DescribePolicy](serverless-policy-template-list.md#ec2-describe-policy) | Donne l'autorisation de décrire des instances Amazon Elastic Compute Cloud (Amazon EC2). |
| [EcsRunTaskPolicy](serverless-policy-template-list.md#ecs-run-task-policy) | Donne l'autorisation de démarrer une nouvelle tâche pour une définition de tâche. |
| [EFSWriteAccessPolicy](serverless-policy-template-list.md#efs-write-access-policy) | Donne l'autorisation de monter un système de fichiers Amazon EFS avec accès en écriture. |
| [EKSDescribePolicy](serverless-policy-template-list.md#eks-describe-policy) | Donne l'autorisation de décrire ou de répertorier les clusters Amazon EKS. |
| [ElasticMapReduceAddJobFlowStepsPolicy](serverless-policy-template-list.md#elastic-map-reduce-add-job-flows-policy) | Donne l'autorisation d'ajouter de nouvelles étapes à un cluster en cours d'exécution. |
| [ElasticMapReduceCancelStepsPolicy](serverless-policy-template-list.md#elastic-map-reduce-cancel-steps-policy) | Donne l'autorisation d'annuler une étape ou des étapes en attente dans un cluster en cours d'exécution. |
| [ElasticMapReduceModifyInstanceFleetPolicy](serverless-policy-template-list.md#elastic-map-reduce-modify-instance-fleet-policy) | Donne l'autorisation de répertorier les détails et de modifier les capacités des flottes d'instances au sein d'un cluster. |
| [ElasticMapReduceModifyInstanceGroupsPolicy](serverless-policy-template-list.md#elastic-map-reduce-modify-instance-groups-policy) | Donne l'autorisation de répertorier les détails et de modifier les réglages des groupes d'instances au sein d'un cluster. |
| [ElasticMapReduceSetTerminationProtectionPolicy](serverless-policy-template-list.md#elastic-map-reduce-set-termination-protection-policy) | Donne l'autorisation de définir une protection contre l'arrêt pour un cluster. |
| [ElasticMapReduceTerminateJobFlowsPolicy](serverless-policy-template-list.md#elastic-map-reduce-terminate-job-flows-policy) | Donne l'autorisation d'arrêter un cluster. |
| [ElasticsearchHttpPostPolicy](serverless-policy-template-list.md#elastic-search-http-post-policy) | Donne l'autorisation POST à Amazon OpenSearch Service. |
| [EventBridgePutEventsPolicy](serverless-policy-template-list.md#eventbridge-put-events-policy) | Donne l'autorisation d'envoyer des événements à EventBridge. |
| [FilterLogEventsPolicy](serverless-policy-template-list.md#filter-log-events-policy) | Donne l'autorisation de filtrer CloudWatch les événements des journaux à partir d'un groupe de journaux spécifié. |
| [FirehoseCrudPolicy](serverless-policy-template-list.md#firehose-crud-policy) | Donne l'autorisation de créer, d'écrire, de mettre à jour et de supprimer un flux de diffusion Firehose. |
| [FirehoseWritePolicy](serverless-policy-template-list.md#firehose-write-policy) | Donne l'autorisation d'écrire dans un flux de diffusion Firehose. |
| [KinesisCrudPolicy](serverless-policy-template-list.md#kinesis-crud-policy) | Donne l'autorisation de créer, publier et supprimer un flux Amazon Kinesis. |
| [KinesisStreamReadPolicy](serverless-policy-template-list.md#kinesis-stream-read-policy) | Donne l'autorisation d'afficher et de lire un flux Amazon Kinesis. |
| [KMSDecryptPolicy](serverless-policy-template-list.md#kms-decrypt-policy) | Donne l'autorisation de déchiffrer avec une clé AWS Key Management Service (AWS KMS). |
| [KMSEncryptPolicy](serverless-policy-template-list.md#kms-encrypt-policy) | Donne l'autorisation de chiffrer avec une clé AWS Key Management Service (AWS KMS). |
| [LambdaInvokePolicy](serverless-policy-template-list.md#lambda-invoke-policy) | Donne l'autorisation d'invoquer une AWS Lambda fonction, un alias ou une version. |
| [MobileAnalyticsWriteOnlyAccessPolicy](serverless-policy-template-list.md#mobile-analytics-write-only-access-policy) | Donne uniquement l'autorisation d'écriture pour placer les données d'événements pour toutes les ressources d'application. |
| [OrganizationsListAccountsPolicy](serverless-policy-template-list.md#organizations-list-accounts-policy) | Donne l'autorisation en lecture seule de répertorier les noms de comptes enfants et. IDs |
| [PinpointEndpointAccessPolicy](serverless-policy-template-list.md#pinpoint-endpoint-access-policy) | Donne l'autorisation d'obtenir et de mettre à jour les points de terminaison pour une application Amazon Pinpoint. |
| [PollyFullAccessPolicy](serverless-policy-template-list.md#polly-full-access-policy) | Donne l'autorisation d'accès complet aux ressources de lexique Amazon Polly. |
| [RekognitionDetectOnlyPolicy](serverless-policy-template-list.md#rekognition-detect-only-policy) | Donne l'autorisation de comparer et de détecter les visages et les étiquettes. |
| [RekognitionFacesManagementPolicy](serverless-policy-template-list.md#rekognition-face-management-policy) | Donne l'autorisation d'ajouter, de supprimer et de rechercher des visages dans une collection Amazon Rekognition. |
| [RekognitionFacesPolicy](serverless-policy-template-list.md#rekognition-faces-policy) | Donne l'autorisation de comparer et de détecter les visages et les étiquettes. |
| [RekognitionLabelsPolicy](serverless-policy-template-list.md#rekognition-labels-policy) | Donne l'autorisation de détecter les étiquettes d'objet et de modération. |
| [RekognitionNoDataAccessPolicy](serverless-policy-template-list.md#rekognition-no-data-access-policy) | Donne l'autorisation de comparer et de détecter les visages et les étiquettes. |
| [RekognitionReadPolicy](serverless-policy-template-list.md#rekognition-read-policy) | Donne l'autorisation de lister et de rechercher des visages. |
| [RekognitionWriteOnlyAccessPolicy](serverless-policy-template-list.md#rekognition-write-only-access-policy) | Donne l'autorisation de créer des collections et d'indexer des visages. |
| [Route53ChangeResourceRecordSetsPolicy](serverless-policy-template-list.md#route53-change-resource-record-sets-policy) | Donne l'autorisation de modifier des jeux d'enregistrements de ressources dans Route 53. |
| [S3CrudPolicy](serverless-policy-template-list.md#s3-crud-policy) | Donne l'autorisation de créer, lire, mettre à jour et supprimer pour agir sur les objets d'un compartiment Amazon S3. |
| [S3FullAccessPolicy](serverless-policy-template-list.md#s3-full-access-policy) | Donne l'autorisation d'accès complet pour agir sur les objets d'un compartiment Amazon S3. |
| [S3ReadPolicy](serverless-policy-template-list.md#s3-read-policy) | Donne l'autorisation de lire des objets en lecture seule dans un compartiment Amazon Simple Storage Service (Amazon S3). |
| [S3WritePolicy](serverless-policy-template-list.md#s3-write-policy) | Donne l'autorisation d'écrire des objets dans un compartiment Amazon S3. |
| [SageMakerCreateEndpointConfigPolicy](serverless-policy-template-list.md#sagemaker-create-endpoint-config-policy) | Donne l'autorisation de créer une configuration de point de terminaison dans SageMaker AI. |
| [SageMakerCreateEndpointPolicy](serverless-policy-template-list.md#sagemaker-create-endpoint-policy) | Donne l'autorisation de créer un point de terminaison dans SageMaker AI. |
| [ServerlessRepoReadWriteAccessPolicy](serverless-policy-template-list.md#serverlessrepo-read-write-access-policy) | Donne l'autorisation de créer et de répertorier des applications dans le AWS Serverless Application Repository service. |
| [SESBulkTemplatedCrudPolicy](serverless-policy-template-list.md#ses-bulk-templated-crud-policy) | Donne l'autorisation d'envoyer des e-mails, des e-mails modélisés, des e-mails groupés et de vérifier l'identité. |
| [SESBulkTemplatedCrudPolicy\$1v2](serverless-policy-template-list.md#ses-bulk-templated-crud-policy-v2) | Donne l'autorisation d'envoyer des e-mails Amazon SES, des e-mails modélisés, des e-mails groupés et de vérifier l'identité. |
| [SESCrudPolicy](serverless-policy-template-list.md#ses-crud-policy) | Donne l'autorisation d'envoyer un e-mail et de vérifier l'identité. |
| [SESEmailTemplateCrudPolicy](serverless-policy-template-list.md#ses-email-template-crud-policy) | Donne l'autorisation de créer, obtenir, répertorier, mettre à jour et supprimer les modèles d'e-mail Amazon SES. |
| [SESSendBouncePolicy](serverless-policy-template-list.md#ses-send-bounce-policy) | Donne SendBounce l'autorisation d'utiliser une identité Amazon Simple Email Service (Amazon SES). |
| [SNSCrudPolicy](serverless-policy-template-list.md#sns-crud-policy) | Donne l'autorisation de créer et de publier des rubriques Amazon SNS, et de s'y abonner. |
| [SNSPublishMessagePolicy](serverless-policy-template-list.md#sqs-publish-message-policy) | Donne l'autorisation de publier un message dans une rubrique Amazon Simple Notification Service (Amazon SNS). |
| [SQSPollerPolicy](serverless-policy-template-list.md#sqs-poller-policy) | Donne l'autorisation d'interroger une file d'attente Amazon Simple Queue Service (Amazon SQS). |
| [SQSSendMessagePolicy](serverless-policy-template-list.md#sqs-send-message-policy) | Donne l'autorisation d'envoyer un message à une file d'attente Amazon SQS. |
| [SSMParameterReadPolicy](serverless-policy-template-list.md#ssm-parameter-read-policy) | Donne l'autorisation d'accéder à un paramètre à partir d'un magasin de paramètres Amazon EC2 Systems Manager (SSM) pour charger des secrets dans ce compte. À utiliser lorsque le nom du paramètre n'est pas précédé d'une barre oblique. |
| [SSMParameterWithSlashPrefixReadPolicy](serverless-policy-template-list.md#ssm-parameter-slash-read-policy) | Donne l'autorisation d'accéder à un paramètre à partir d'un magasin de paramètres Amazon EC2 Systems Manager (SSM) pour charger des secrets dans ce compte. À utiliser lorsque le nom du paramètre est précédé d'une barre oblique. |
| [StepFunctionsExecutionPolicy](serverless-policy-template-list.md#stepfunctions-execution-policy) | Donne l'autorisation de lancer l'exécution d'une machine d'état Step Functions. |
| [TextractDetectAnalyzePolicy](serverless-policy-template-list.md#textract-detect-analyze-policy) | Donne l'accès permettant de détecter et d'analyser des documents avec Amazon Textract. |
| [TextractGetResultPolicy](serverless-policy-template-list.md#textract-get-result-policy) | Donne l'accès permettant d'obtenir des documents détectés et analysés avec Amazon Textract. |
| [TextractPolicy](serverless-policy-template-list.md#textract-policy) | Donne l'accès complet à Amazon Textract. |
| [VPCAccessPolicy](serverless-policy-template-list.md#vpc-access-policy) | Donne l'accès pour créer, supprimer, décrire et détacher des interfaces réseau élastiques. |
## Résolution des problèmes
### Erreur SAM CLI : « Vous devez spécifier des valeurs de paramètres valides pour le modèle de politique '< policy-template-name >' »
Lors de l'exécution de `sam build`, l'erreur suivante s'affiche :
```
"Must specify valid parameter values for policy template ''"
```
Cela signifie que vous n'avez pas transmis d'objet vide lors de la déclaration d'un modèle de stratégie qui ne contient aucune valeur d'espace réservé.
Pour résoudre ce problème, déclarez la stratégie comme l'exemple suivant pour [CloudWatchPutMetricPolicy](serverless-policy-template-list.md#cloudwatch-put-metric-policy).
```
1. MyFunction:
2. Policies:
3. - CloudWatchPutMetricPolicy: {}
```
# AWS SAM liste de modèles de politiques
Vous trouverez ci-dessous les modèles de politiques disponibles, ainsi que les autorisations appliquées à chacun d'entre eux. AWS Serverless Application Model (AWS SAM) renseigne automatiquement les éléments réservés (tels que AWS la région et le numéro de compte) avec les informations appropriées.
**Topics**
+ [AcmGetCertificatePolicy](#acm-get-certificate-policy)
+ [AMIDescribePolicy](#ami-describe-policy)
+ [AthenaQueryPolicy](#athena-query-policy)
+ [AWSSecretsManagerGetSecretValuePolicy](#secrets-manager-get-secret-value-policy)
+ [AWSSecretsManagerRotationPolicy](#secrets-manager-rotation-policy)
+ [CloudFormationDescribeStacksPolicy](#cloud-formation-describe-stacks-policy)
+ [CloudWatchDashboardPolicy](#cloudwatch-dashboard-policy)
+ [CloudWatchDescribeAlarmHistoryPolicy](#cloudwatch-describe-alarm-history-policy)
+ [CloudWatchPutMetricPolicy](#cloudwatch-put-metric-policy)
+ [CodePipelineLambdaExecutionPolicy](#code-pipeline-lambda-execution-policy)
+ [CodePipelineReadOnlyPolicy](#code-pipeline-readonly-policy)
+ [CodeCommitCrudPolicy](#codecommit-crud-policy)
+ [CodeCommitReadPolicy](#codecommit-read-policy)
+ [ComprehendBasicAccessPolicy](#comprehend-basic-access-policy)
+ [CostExplorerReadOnlyPolicy](#cost-explorer-readonly-policy)
+ [DynamoDBBackupFullAccessPolicy](#ddb-back-full-policy)
+ [DynamoDBCrudPolicy](#dynamo-db-crud-policy)
+ [DynamoDBReadPolicy](#dynamo-db-read-policy)
+ [DynamoDBReconfigurePolicy](#dynamo-db-reconfigure-policy)
+ [DynamoDBRestoreFromBackupPolicy](#ddb-restore-from-backup-policy)
+ [DynamoDBStreamReadPolicy](#dynamo-db-stream-read-policy)
+ [DynamoDBWritePolicy](#dynamo-db-write-policy)
+ [EC2CopyImagePolicy](#ec2-copy-image-policy)
+ [EC2DescribePolicy](#ec2-describe-policy)
+ [EcsRunTaskPolicy](#ecs-run-task-policy)
+ [EFSWriteAccessPolicy](#efs-write-access-policy)
+ [EKSDescribePolicy](#eks-describe-policy)
+ [ElasticMapReduceAddJobFlowStepsPolicy](#elastic-map-reduce-add-job-flows-policy)
+ [ElasticMapReduceCancelStepsPolicy](#elastic-map-reduce-cancel-steps-policy)
+ [ElasticMapReduceModifyInstanceFleetPolicy](#elastic-map-reduce-modify-instance-fleet-policy)
+ [ElasticMapReduceModifyInstanceGroupsPolicy](#elastic-map-reduce-modify-instance-groups-policy)
+ [ElasticMapReduceSetTerminationProtectionPolicy](#elastic-map-reduce-set-termination-protection-policy)
+ [ElasticMapReduceTerminateJobFlowsPolicy](#elastic-map-reduce-terminate-job-flows-policy)
+ [ElasticsearchHttpPostPolicy](#elastic-search-http-post-policy)
+ [EventBridgePutEventsPolicy](#eventbridge-put-events-policy)
+ [FilterLogEventsPolicy](#filter-log-events-policy)
+ [FirehoseCrudPolicy](#firehose-crud-policy)
+ [FirehoseWritePolicy](#firehose-write-policy)
+ [KinesisCrudPolicy](#kinesis-crud-policy)
+ [KinesisStreamReadPolicy](#kinesis-stream-read-policy)
+ [KMSDecryptPolicy](#kms-decrypt-policy)
+ [KMSEncryptPolicy](#kms-encrypt-policy)
+ [LambdaInvokePolicy](#lambda-invoke-policy)
+ [MobileAnalyticsWriteOnlyAccessPolicy](#mobile-analytics-write-only-access-policy)
+ [OrganizationsListAccountsPolicy](#organizations-list-accounts-policy)
+ [PinpointEndpointAccessPolicy](#pinpoint-endpoint-access-policy)
+ [PollyFullAccessPolicy](#polly-full-access-policy)
+ [RekognitionDetectOnlyPolicy](#rekognition-detect-only-policy)
+ [RekognitionFacesManagementPolicy](#rekognition-face-management-policy)
+ [RekognitionFacesPolicy](#rekognition-faces-policy)
+ [RekognitionLabelsPolicy](#rekognition-labels-policy)
+ [RekognitionNoDataAccessPolicy](#rekognition-no-data-access-policy)
+ [RekognitionReadPolicy](#rekognition-read-policy)
+ [RekognitionWriteOnlyAccessPolicy](#rekognition-write-only-access-policy)
+ [Route53ChangeResourceRecordSetsPolicy](#route53-change-resource-record-sets-policy)
+ [S3CrudPolicy](#s3-crud-policy)
+ [S3FullAccessPolicy](#s3-full-access-policy)
+ [S3ReadPolicy](#s3-read-policy)
+ [S3WritePolicy](#s3-write-policy)
+ [SageMakerCreateEndpointConfigPolicy](#sagemaker-create-endpoint-config-policy)
+ [SageMakerCreateEndpointPolicy](#sagemaker-create-endpoint-policy)
+ [ServerlessRepoReadWriteAccessPolicy](#serverlessrepo-read-write-access-policy)
+ [SESBulkTemplatedCrudPolicy](#ses-bulk-templated-crud-policy)
+ [SESBulkTemplatedCrudPolicy\$1v2](#ses-bulk-templated-crud-policy-v2)
+ [SESCrudPolicy](#ses-crud-policy)
+ [SESEmailTemplateCrudPolicy](#ses-email-template-crud-policy)
+ [SESSendBouncePolicy](#ses-send-bounce-policy)
+ [SNSCrudPolicy](#sns-crud-policy)
+ [SNSPublishMessagePolicy](#sqs-publish-message-policy)
+ [SQSPollerPolicy](#sqs-poller-policy)
+ [SQSSendMessagePolicy](#sqs-send-message-policy)
+ [SSMParameterReadPolicy](#ssm-parameter-read-policy)
+ [SSMParameterWithSlashPrefixReadPolicy](#ssm-parameter-slash-read-policy)
+ [StepFunctionsExecutionPolicy](#stepfunctions-execution-policy)
+ [TextractDetectAnalyzePolicy](#textract-detect-analyze-policy)
+ [TextractGetResultPolicy](#textract-get-result-policy)
+ [TextractPolicy](#textract-policy)
+ [VPCAccessPolicy](#vpc-access-policy)
## AcmGetCertificatePolicy
Donne l'autorisation de lire un certificat à partir de AWS Certificate Manager.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"acm:GetCertificate"
],
"Resource": {
"Fn::Sub": [
"${certificateArn}",
{
"certificateArn": {
"Ref": "CertificateArn"
}
}
]
}
}
]
```
## AMIDescribePolicy
Donne l'autorisation de décrire Amazon Machine Images (AMIs).
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeImages"
],
"Resource": "*"
}
]
```
## AthenaQueryPolicy
Donne des autorisations pour exécuter des requêtes Athena.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"athena:ListWorkGroups",
"athena:GetExecutionEngine",
"athena:GetExecutionEngines",
"athena:GetNamespace",
"athena:GetCatalogs",
"athena:GetNamespaces",
"athena:GetTables",
"athena:GetTable"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"athena:StartQueryExecution",
"athena:GetQueryResults",
"athena:DeleteNamedQuery",
"athena:GetNamedQuery",
"athena:ListQueryExecutions",
"athena:StopQueryExecution",
"athena:GetQueryResultsStream",
"athena:ListNamedQueries",
"athena:CreateNamedQuery",
"athena:GetQueryExecution",
"athena:BatchGetNamedQuery",
"athena:BatchGetQueryExecution",
"athena:GetWorkGroup"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:athena:${AWS::Region}:${AWS::AccountId}:workgroup/${workgroupName}",
{
"workgroupName": {
"Ref": "WorkGroupName"
}
}
]
}
}
]
```
## AWSSecretsManagerGetSecretValuePolicy
Donne l'autorisation d'obtenir la valeur secrète pour le AWS Secrets Manager secret spécifié.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": {
"Fn::Sub": [
"${secretArn}",
{
"secretArn": {
"Ref": "SecretArn"
}
}
]
}
}
]
```
## AWSSecretsManagerRotationPolicy
Donne l'autorisation de faire pivoter un secret dans AWS Secrets Manager.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:DescribeSecret",
"secretsmanager:GetSecretValue",
"secretsmanager:PutSecretValue",
"secretsmanager:UpdateSecretVersionStage"
],
"Resource": {
"Fn::Sub": "arn:${AWS::Partition}:secretsmanager:${AWS::Region}:${AWS::AccountId}:secret:*"
},
"Condition": {
"StringEquals": {
"secretsmanager:resource/AllowRotationLambdaArn": {
"Fn::Sub": [
"arn:${AWS::Partition}:lambda:${AWS::Region}:${AWS::AccountId}:function:${functionName}",
{
"functionName": {
"Ref": "FunctionName"
}
}
]
}
}
}
},
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetRandomPassword"
],
"Resource": "*"
}
]
```
## CloudFormationDescribeStacksPolicy
Donne l'autorisation de décrire les CloudFormation piles.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudformation:DescribeStacks"
],
"Resource": {
"Fn::Sub": "arn:${AWS::Partition}:cloudformation:${AWS::Region}:${AWS::AccountId}:stack/*"
}
}
]
```
## CloudWatchDashboardPolicy
Permet de placer des métriques à appliquer sur les CloudWatch tableaux de bord.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:GetDashboard",
"cloudwatch:ListDashboards",
"cloudwatch:PutDashboard",
"cloudwatch:ListMetrics"
],
"Resource": "*"
}
]
```
## CloudWatchDescribeAlarmHistoryPolicy
Permet de décrire l'historique des CloudWatch alarmes Amazon.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:DescribeAlarmHistory"
],
"Resource": "*"
}
]
```
## CloudWatchPutMetricPolicy
Donne l'autorisation d'envoyer des métriques à CloudWatch.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData"
],
"Resource": "*"
}
]
```
## CodePipelineLambdaExecutionPolicy
Permet à une fonction Lambda invoquée par AWS CodePipeline de signaler l'état de la tâche.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:PutJobSuccessResult",
"codepipeline:PutJobFailureResult"
],
"Resource": "*"
}
]
```
## CodePipelineReadOnlyPolicy
Donne l'autorisation de lecture pour obtenir des informations sur un CodePipeline pipeline.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:ListPipelineExecutions"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:codepipeline:${AWS::Region}:${AWS::AccountId}:${pipelinename}",
{
"pipelinename": {
"Ref": "PipelineName"
}
}
]
}
}
]
```
## CodeCommitCrudPolicy
Permet de créer, de lire, de mettre à jour et de supprimer des objets dans un CodeCommit référentiel spécifique.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"codecommit:GitPull",
"codecommit:GitPush",
"codecommit:CreateBranch",
"codecommit:DeleteBranch",
"codecommit:GetBranch",
"codecommit:ListBranches",
"codecommit:MergeBranchesByFastForward",
"codecommit:MergeBranchesBySquash",
"codecommit:MergeBranchesByThreeWay",
"codecommit:UpdateDefaultBranch",
"codecommit:BatchDescribeMergeConflicts",
"codecommit:CreateUnreferencedMergeCommit",
"codecommit:DescribeMergeConflicts",
"codecommit:GetMergeCommit",
"codecommit:GetMergeOptions",
"codecommit:BatchGetPullRequests",
"codecommit:CreatePullRequest",
"codecommit:DescribePullRequestEvents",
"codecommit:GetCommentsForPullRequest",
"codecommit:GetCommitsFromMergeBase",
"codecommit:GetMergeConflicts",
"codecommit:GetPullRequest",
"codecommit:ListPullRequests",
"codecommit:MergePullRequestByFastForward",
"codecommit:MergePullRequestBySquash",
"codecommit:MergePullRequestByThreeWay",
"codecommit:PostCommentForPullRequest",
"codecommit:UpdatePullRequestDescription",
"codecommit:UpdatePullRequestStatus",
"codecommit:UpdatePullRequestTitle",
"codecommit:DeleteFile",
"codecommit:GetBlob",
"codecommit:GetFile",
"codecommit:GetFolder",
"codecommit:PutFile",
"codecommit:DeleteCommentContent",
"codecommit:GetComment",
"codecommit:GetCommentsForComparedCommit",
"codecommit:PostCommentForComparedCommit",
"codecommit:PostCommentReply",
"codecommit:UpdateComment",
"codecommit:BatchGetCommits",
"codecommit:CreateCommit",
"codecommit:GetCommit",
"codecommit:GetCommitHistory",
"codecommit:GetDifferences",
"codecommit:GetObjectIdentifier",
"codecommit:GetReferences",
"codecommit:GetTree",
"codecommit:GetRepository",
"codecommit:UpdateRepositoryDescription",
"codecommit:ListTagsForResource",
"codecommit:TagResource",
"codecommit:UntagResource",
"codecommit:GetRepositoryTriggers",
"codecommit:PutRepositoryTriggers",
"codecommit:TestRepositoryTriggers",
"codecommit:GetBranch",
"codecommit:GetCommit",
"codecommit:UploadArchive",
"codecommit:GetUploadArchiveStatus",
"codecommit:CancelUploadArchive"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:codecommit:${AWS::Region}:${AWS::AccountId}:${repositoryName}",
{
"repositoryName": {
"Ref": "RepositoryName"
}
}
]
}
}
]
```
## CodeCommitReadPolicy
Permet de lire des objets dans un CodeCommit référentiel spécifique.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"codecommit:GitPull",
"codecommit:GetBranch",
"codecommit:ListBranches",
"codecommit:BatchDescribeMergeConflicts",
"codecommit:DescribeMergeConflicts",
"codecommit:GetMergeCommit",
"codecommit:GetMergeOptions",
"codecommit:BatchGetPullRequests",
"codecommit:DescribePullRequestEvents",
"codecommit:GetCommentsForPullRequest",
"codecommit:GetCommitsFromMergeBase",
"codecommit:GetMergeConflicts",
"codecommit:GetPullRequest",
"codecommit:ListPullRequests",
"codecommit:GetBlob",
"codecommit:GetFile",
"codecommit:GetFolder",
"codecommit:GetComment",
"codecommit:GetCommentsForComparedCommit",
"codecommit:BatchGetCommits",
"codecommit:GetCommit",
"codecommit:GetCommitHistory",
"codecommit:GetDifferences",
"codecommit:GetObjectIdentifier",
"codecommit:GetReferences",
"codecommit:GetTree",
"codecommit:GetRepository",
"codecommit:ListTagsForResource",
"codecommit:GetRepositoryTriggers",
"codecommit:TestRepositoryTriggers",
"codecommit:GetBranch",
"codecommit:GetCommit",
"codecommit:GetUploadArchiveStatus"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:codecommit:${AWS::Region}:${AWS::AccountId}:${repositoryName}",
{
"repositoryName": {
"Ref": "RepositoryName"
}
}
]
}
}
]
```
## ComprehendBasicAccessPolicy
Donne l'autorisation de détecter des entités, des expressions clés, des langues et des sentiments.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"comprehend:BatchDetectKeyPhrases",
"comprehend:DetectDominantLanguage",
"comprehend:DetectEntities",
"comprehend:BatchDetectEntities",
"comprehend:DetectKeyPhrases",
"comprehend:DetectSentiment",
"comprehend:BatchDetectDominantLanguage",
"comprehend:BatchDetectSentiment"
],
"Resource": "*"
}
]
```
## CostExplorerReadOnlyPolicy
Donne une autorisation en lecture seule à l'utilisateur en lecture seule (Cost AWS Cost Explorer Explorer) APIs pour l'historique de facturation.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"ce:GetCostAndUsage",
"ce:GetDimensionValues",
"ce:GetReservationCoverage",
"ce:GetReservationPurchaseRecommendation",
"ce:GetReservationUtilization",
"ce:GetTags"
],
"Resource": "*"
}
]
```
## DynamoDBBackupFullAccessPolicy
Donne l'autorisation de lecture/écriture aux sauvegardes DynamoDB à la demande pour une table.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:CreateBackup",
"dynamodb:DescribeContinuousBackups"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:dynamodb:${AWS::Region}:${AWS::AccountId}:table/${tableName}",
{
"tableName": {
"Ref": "TableName"
}
}
]
}
},
{
"Effect": "Allow",
"Action": [
"dynamodb:DeleteBackup",
"dynamodb:DescribeBackup",
"dynamodb:ListBackups"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:dynamodb:${AWS::Region}:${AWS::AccountId}:table/${tableName}/backup/*",
{
"tableName": {
"Ref": "TableName"
}
}
]
}
}
]
```
## DynamoDBCrudPolicy
Donne les autorisations de créer, lire, mettre à jour, supprimer à une table Amazon DynamoDB.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:DeleteItem",
"dynamodb:PutItem",
"dynamodb:Scan",
"dynamodb:Query",
"dynamodb:UpdateItem",
"dynamodb:BatchWriteItem",
"dynamodb:BatchGetItem",
"dynamodb:DescribeTable",
"dynamodb:ConditionCheckItem"
],
"Resource": [
{
"Fn::Sub": [
"arn:${AWS::Partition}:dynamodb:${AWS::Region}:${AWS::AccountId}:table/${tableName}",
{
"tableName": {
"Ref": "TableName"
}
}
]
},
{
"Fn::Sub": [
"arn:${AWS::Partition}:dynamodb:${AWS::Region}:${AWS::AccountId}:table/${tableName}/index/*",
{
"tableName": {
"Ref": "TableName"
}
}
]
}
]
}
]
```
## DynamoDBReadPolicy
Donne l'autorisation de lecture seule à une table DynamoDB.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:Scan",
"dynamodb:Query",
"dynamodb:BatchGetItem",
"dynamodb:DescribeTable"
],
"Resource": [
{
"Fn::Sub": [
"arn:${AWS::Partition}:dynamodb:${AWS::Region}:${AWS::AccountId}:table/${tableName}",
{
"tableName": {
"Ref": "TableName"
}
}
]
},
{
"Fn::Sub": [
"arn:${AWS::Partition}:dynamodb:${AWS::Region}:${AWS::AccountId}:table/${tableName}/index/*",
{
"tableName": {
"Ref": "TableName"
}
}
]
}
]
}
]
```
## DynamoDBReconfigurePolicy
Donne l'autorisation de reconfigurer une table DynamoDB.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:UpdateTable"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:dynamodb:${AWS::Region}:${AWS::AccountId}:table/${tableName}",
{
"tableName": {
"Ref": "TableName"
}
}
]
}
}
]
```
## DynamoDBRestoreFromBackupPolicy
Donne l'autorisation de restaurer une table DynamoDB à partir d'une sauvegarde.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:RestoreTableFromBackup"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:dynamodb:${AWS::Region}:${AWS::AccountId}:table/${tableName}/backup/*",
{
"tableName": {
"Ref": "TableName"
}
}
]
}
},
{
"Effect": "Allow",
"Action": [
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:GetItem",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:BatchWriteItem"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:dynamodb:${AWS::Region}:${AWS::AccountId}:table/${tableName}",
{
"tableName": {
"Ref": "TableName"
}
}
]
}
}
]
```
## DynamoDBStreamReadPolicy
Donne l'autorisation de décrire et de lire les flux DynamoDB Streams ainsi que les enregistrements.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:DescribeStream",
"dynamodb:GetRecords",
"dynamodb:GetShardIterator"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:dynamodb:${AWS::Region}:${AWS::AccountId}:table/${tableName}/stream/${streamName}",
{
"tableName": {
"Ref": "TableName"
},
"streamName": {
"Ref": "StreamName"
}
}
]
}
},
{
"Effect": "Allow",
"Action": [
"dynamodb:ListStreams"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:dynamodb:${AWS::Region}:${AWS::AccountId}:table/${tableName}/stream/*",
{
"tableName": {
"Ref": "TableName"
}
}
]
}
}
]
```
## DynamoDBWritePolicy
Donne l'autorisation d'écriture seule à une table DynamoDB.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:BatchWriteItem"
],
"Resource": [
{
"Fn::Sub": [
"arn:${AWS::Partition}:dynamodb:${AWS::Region}:${AWS::AccountId}:table/${tableName}",
{
"tableName": {
"Ref": "TableName"
}
}
]
},
{
"Fn::Sub": [
"arn:${AWS::Partition}:dynamodb:${AWS::Region}:${AWS::AccountId}:table/${tableName}/index/*",
{
"tableName": {
"Ref": "TableName"
}
}
]
}
]
}
]
```
## EC2CopyImagePolicy
Donne l'autorisation de copier EC2 des images Amazon.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CopyImage"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:ec2:${AWS::Region}:${AWS::AccountId}:image/${imageId}",
{
"imageId": {
"Ref": "ImageId"
}
}
]
}
}
]
```
## EC2DescribePolicy
Donne l'autorisation de décrire les instances Amazon Elastic Compute Cloud (Amazon EC2).
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeRegions",
"ec2:DescribeInstances"
],
"Resource": "*"
}
]
```
## EcsRunTaskPolicy
Donne l'autorisation de démarrer une nouvelle tâche pour une définition de tâche.
```
"Statement": [
{
"Action": [
"ecs:RunTask"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:ecs:${AWS::Region}:${AWS::AccountId}:task-definition/${taskDefinition}",
{
"taskDefinition": {
"Ref": "TaskDefinition"
}
}
]
},
"Effect": "Allow"
}
]
```
## EFSWriteAccessPolicy
Donne l'autorisation de monter un système de fichiers Amazon EFS avec accès en écriture.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticfilesystem:ClientMount",
"elasticfilesystem:ClientWrite"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:elasticfilesystem:${AWS::Region}:${AWS::AccountId}:file-system/${FileSystem}",
{
"FileSystem": {
"Ref": "FileSystem"
}
}
]
},
"Condition": {
"StringEquals": {
"elasticfilesystem:AccessPointArn": {
"Fn::Sub": [
"arn:${AWS::Partition}:elasticfilesystem:${AWS::Region}:${AWS::AccountId}:access-point/${AccessPoint}",
{
"AccessPoint": {
"Ref": "AccessPoint"
}
}
]
}
}
}
}
]
```
## EKSDescribePolicy
Donne l'autorisation de décrire ou de répertorier des clusters Amazon Elastic Kubernetes Service (Amazon EKS).
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:DescribeCluster",
"eks:ListClusters"
],
"Resource": "*"
}
]
```
## ElasticMapReduceAddJobFlowStepsPolicy
Donne l'autorisation d'ajouter de nouvelles étapes à un cluster en cours d'exécution.
```
"Statement": [
{
"Action": "elasticmapreduce:AddJobFlowSteps",
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:elasticmapreduce:${AWS::Region}:${AWS::AccountId}:cluster/${clusterId}",
{
"clusterId": {
"Ref": "ClusterId"
}
}
]
},
"Effect": "Allow"
}
]
```
## ElasticMapReduceCancelStepsPolicy
Donne l'autorisation d'annuler une étape ou des étapes en attente dans un cluster en cours d'exécution.
```
"Statement": [
{
"Action": "elasticmapreduce:CancelSteps",
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:elasticmapreduce:${AWS::Region}:${AWS::AccountId}:cluster/${clusterId}",
{
"clusterId": {
"Ref": "ClusterId"
}
}
]
},
"Effect": "Allow"
}
]
```
## ElasticMapReduceModifyInstanceFleetPolicy
Donne l'autorisation de répertorier les détails et de modifier les capacités des flottes d'instances au sein d'un cluster.
```
"Statement": [
{
"Action": [
"elasticmapreduce:ModifyInstanceFleet",
"elasticmapreduce:ListInstanceFleets"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:elasticmapreduce:${AWS::Region}:${AWS::AccountId}:cluster/${clusterId}",
{
"clusterId": {
"Ref": "ClusterId"
}
}
]
},
"Effect": "Allow"
}
]
```
## ElasticMapReduceModifyInstanceGroupsPolicy
Donne l'autorisation de répertorier les détails et de modifier les réglages des groupes d'instances au sein d'un cluster.
```
"Statement": [
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups",
"elasticmapreduce:ListInstanceGroups"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:elasticmapreduce:${AWS::Region}:${AWS::AccountId}:cluster/${clusterId}",
{
"clusterId": {
"Ref": "ClusterId"
}
}
]
},
"Effect": "Allow"
}
]
```
## ElasticMapReduceSetTerminationProtectionPolicy
Donne l'autorisation de définir une protection contre l'arrêt pour un cluster.
```
"Statement": [
{
"Action": "elasticmapreduce:SetTerminationProtection",
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:elasticmapreduce:${AWS::Region}:${AWS::AccountId}:cluster/${clusterId}",
{
"clusterId": {
"Ref": "ClusterId"
}
}
]
},
"Effect": "Allow"
}
]
```
## ElasticMapReduceTerminateJobFlowsPolicy
Donne l'autorisation d'arrêter un cluster.
```
"Statement": [
{
"Action": "elasticmapreduce:TerminateJobFlows",
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:elasticmapreduce:${AWS::Region}:${AWS::AccountId}:cluster/${clusterId}",
{
"clusterId": {
"Ref": "ClusterId"
}
}
]
},
"Effect": "Allow"
}
]
```
## ElasticsearchHttpPostPolicy
Donne les autorisations POST et PUT à Amazon OpenSearch Service.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"es:ESHttpPost",
"es:ESHttpPut"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:es:${AWS::Region}:${AWS::AccountId}:domain/${domainName}/*",
{
"domainName": {
"Ref": "DomainName"
}
}
]
}
}
]
```
## EventBridgePutEventsPolicy
Donne l'autorisation d'envoyer des événements à Amazon EventBridge.
```
"Statement": [
{
"Effect": "Allow",
"Action": "events:PutEvents",
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:events:${AWS::Region}:${AWS::AccountId}:event-bus/${eventBusName}",
{
"eventBusName": {
"Ref": "EventBusName"
}
}
]
}
}
]
```
## FilterLogEventsPolicy
Donne l'autorisation de filtrer CloudWatch les événements des journaux à partir d'un groupe de journaux spécifié.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:FilterLogEvents"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:logs:${AWS::Region}:${AWS::AccountId}:log-group:${logGroupName}:log-stream:*",
{
"logGroupName": {
"Ref": "LogGroupName"
}
}
]
}
}
]
```
## FirehoseCrudPolicy
Donne l'autorisation de créer, d'écrire, de mettre à jour et de supprimer un flux de diffusion Firehose.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"firehose:CreateDeliveryStream",
"firehose:DeleteDeliveryStream",
"firehose:DescribeDeliveryStream",
"firehose:PutRecord",
"firehose:PutRecordBatch",
"firehose:UpdateDestination"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:firehose:${AWS::Region}:${AWS::AccountId}:deliverystream/${deliveryStreamName}",
{
"deliveryStreamName": {
"Ref": "DeliveryStreamName"
}
}
]
}
}
]
```
## FirehoseWritePolicy
Donne l'autorisation d'écrire dans un flux de diffusion Firehose.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"firehose:PutRecord",
"firehose:PutRecordBatch"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:firehose:${AWS::Region}:${AWS::AccountId}:deliverystream/${deliveryStreamName}",
{
"deliveryStreamName": {
"Ref": "DeliveryStreamName"
}
}
]
}
}
]
```
## KinesisCrudPolicy
Donne l'autorisation de créer, publier et supprimer un flux Amazon Kinesis.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"kinesis:AddTagsToStream",
"kinesis:CreateStream",
"kinesis:DecreaseStreamRetentionPeriod",
"kinesis:DeleteStream",
"kinesis:DescribeStream",
"kinesis:DescribeStreamSummary",
"kinesis:GetShardIterator",
"kinesis:IncreaseStreamRetentionPeriod",
"kinesis:ListTagsForStream",
"kinesis:MergeShards",
"kinesis:PutRecord",
"kinesis:PutRecords",
"kinesis:SplitShard",
"kinesis:RemoveTagsFromStream"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:kinesis:${AWS::Region}:${AWS::AccountId}:stream/${streamName}",
{
"streamName": {
"Ref": "StreamName"
}
}
]
}
}
]
```
## KinesisStreamReadPolicy
Donne l'autorisation d'afficher et de lire un flux Amazon Kinesis.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"kinesis:ListStreams",
"kinesis:DescribeLimits"
],
"Resource": {
"Fn::Sub": "arn:${AWS::Partition}:kinesis:${AWS::Region}:${AWS::AccountId}:stream/*"
}
},
{
"Effect": "Allow",
"Action": [
"kinesis:DescribeStream",
"kinesis:DescribeStreamSummary",
"kinesis:GetRecords",
"kinesis:GetShardIterator"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:kinesis:${AWS::Region}:${AWS::AccountId}:stream/${streamName}",
{
"streamName": {
"Ref": "StreamName"
}
}
]
}
}
]
```
## KMSDecryptPolicy
Donne l'autorisation de déchiffrer avec une clé AWS Key Management Service (AWS KMS). Notez qu'`keyId`il doit s'agir d'un identifiant de AWS KMS clé et non d'un alias de clé.
```
"Statement": [
{
"Action": "kms:Decrypt",
"Effect": "Allow",
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:kms:${AWS::Region}:${AWS::AccountId}:key/${keyId}",
{
"keyId": {
"Ref": "KeyId"
}
}
]
}
}
]
```
## KMSEncryptPolicy
Donne l'autorisation de chiffrer avec une AWS KMS clé. Notez que KeyID doit être un identifiant de AWS KMS clé et non un alias de clé.
```
"Statement": [
{
"Action": "kms:Encrypt",
"Effect": "Allow",
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:kms:${AWS::Region}:${AWS::AccountId}:key/${keyId}",
{
"keyId": {
"Ref": "KeyId"
}
}
]
}
}
]
```
## LambdaInvokePolicy
Donne l'autorisation d'invoquer une AWS Lambda fonction, un alias ou une version.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:lambda:${AWS::Region}:${AWS::AccountId}:function:${functionName}*",
{
"functionName": {
"Ref": "FunctionName"
}
}
]
}
}
]
```
## MobileAnalyticsWriteOnlyAccessPolicy
Donne uniquement l'autorisation d'écriture pour placer les données d'événements pour toutes les ressources d'application.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"mobileanalytics:PutEvents"
],
"Resource": "*"
}
]
```
## OrganizationsListAccountsPolicy
Donne l'autorisation en lecture seule de répertorier les noms de comptes enfants et. IDs
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"organizations:ListAccounts"
],
"Resource": "*"
}
]
```
## PinpointEndpointAccessPolicy
Donne l'autorisation d'obtenir et de mettre à jour les points de terminaison pour une application Amazon Pinpoint.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"mobiletargeting:GetEndpoint",
"mobiletargeting:UpdateEndpoint",
"mobiletargeting:UpdateEndpointsBatch"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:mobiletargeting:${AWS::Region}:${AWS::AccountId}:apps/${pinpointApplicationId}/endpoints/*",
{
"pinpointApplicationId": {
"Ref": "PinpointApplicationId"
}
}
]
}
}
]
```
## PollyFullAccessPolicy
Donne l'autorisation d'accès complet aux ressources de lexique Amazon Polly.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"polly:GetLexicon",
"polly:DeleteLexicon"
],
"Resource": [
{
"Fn::Sub": [
"arn:${AWS::Partition}:polly:${AWS::Region}:${AWS::AccountId}:lexicon/${lexiconName}",
{
"lexiconName": {
"Ref": "LexiconName"
}
}
]
}
]
},
{
"Effect": "Allow",
"Action": [
"polly:DescribeVoices",
"polly:ListLexicons",
"polly:PutLexicon",
"polly:SynthesizeSpeech"
],
"Resource": [
{
"Fn::Sub": "arn:${AWS::Partition}:polly:${AWS::Region}:${AWS::AccountId}:lexicon/*"
}
]
}
]
```
## RekognitionDetectOnlyPolicy
Donne l'autorisation de comparer et de détecter les visages et les étiquettes.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"rekognition:DetectFaces",
"rekognition:DetectLabels",
"rekognition:DetectModerationLabels",
"rekognition:DetectText"
],
"Resource": "*"
}
]
```
## RekognitionFacesManagementPolicy
Donne l'autorisation d'ajouter, de supprimer et de rechercher des visages dans une collection Amazon Rekognition.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"rekognition:IndexFaces",
"rekognition:DeleteFaces",
"rekognition:SearchFaces",
"rekognition:SearchFacesByImage",
"rekognition:ListFaces"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:rekognition:${AWS::Region}:${AWS::AccountId}:collection/${collectionId}",
{
"collectionId": {
"Ref": "CollectionId"
}
}
]
}
}
]
```
## RekognitionFacesPolicy
Donne l'autorisation de comparer et de détecter les visages et les étiquettes.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"rekognition:CompareFaces",
"rekognition:DetectFaces"
],
"Resource": "*"
}
]
```
## RekognitionLabelsPolicy
Donne l'autorisation de détecter les étiquettes d'objet et de modération.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"rekognition:DetectLabels",
"rekognition:DetectModerationLabels"
],
"Resource": "*"
}
]
```
## RekognitionNoDataAccessPolicy
Donne l'autorisation de comparer et de détecter les visages et les étiquettes.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"rekognition:CompareFaces",
"rekognition:DetectFaces",
"rekognition:DetectLabels",
"rekognition:DetectModerationLabels"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:rekognition:${AWS::Region}:${AWS::AccountId}:collection/${collectionId}",
{
"collectionId": {
"Ref": "CollectionId"
}
}
]
}
}
]
```
## RekognitionReadPolicy
Donne l'autorisation de lister et de rechercher des visages.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"rekognition:ListCollections",
"rekognition:ListFaces",
"rekognition:SearchFaces",
"rekognition:SearchFacesByImage"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:rekognition:${AWS::Region}:${AWS::AccountId}:collection/${collectionId}",
{
"collectionId": {
"Ref": "CollectionId"
}
}
]
}
}
]
```
## RekognitionWriteOnlyAccessPolicy
Donne l'autorisation de créer des collections et d'indexer des visages.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"rekognition:CreateCollection",
"rekognition:IndexFaces"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:rekognition:${AWS::Region}:${AWS::AccountId}:collection/${collectionId}",
{
"collectionId": {
"Ref": "CollectionId"
}
}
]
}
}
]
```
## Route53ChangeResourceRecordSetsPolicy
Donne l'autorisation de modifier des jeux d'enregistrements de ressources dans Route 53.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"route53:ChangeResourceRecordSets"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:route53:::hostedzone/${HostedZoneId}",
{
"HostedZoneId": {
"Ref": "HostedZoneId"
}
}
]
}
}
]
```
## S3CrudPolicy
Donne l'autorisation de créer, lire, mettre à jour et supprimer pour agir sur les objets d'un compartiment Amazon S3.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:GetBucketLocation",
"s3:GetObjectVersion",
"s3:PutObject",
"s3:PutObjectAcl",
"s3:GetLifecycleConfiguration",
"s3:PutLifecycleConfiguration",
"s3:DeleteObject"
],
"Resource": [
{
"Fn::Sub": [
"arn:${AWS::Partition}:s3:::${bucketName}",
{
"bucketName": {
"Ref": "BucketName"
}
}
]
},
{
"Fn::Sub": [
"arn:${AWS::Partition}:s3:::${bucketName}/*",
{
"bucketName": {
"Ref": "BucketName"
}
}
]
}
]
}
]
```
## S3FullAccessPolicy
Donne l'autorisation d'accès complet pour agir sur les objets d'un compartiment Amazon S3.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:GetObjectAcl",
"s3:GetObjectVersion",
"s3:PutObject",
"s3:PutObjectAcl",
"s3:DeleteObject",
"s3:DeleteObjectTagging",
"s3:DeleteObjectVersionTagging",
"s3:GetObjectTagging",
"s3:GetObjectVersionTagging",
"s3:PutObjectTagging",
"s3:PutObjectVersionTagging"
],
"Resource": [
{
"Fn::Sub": [
"arn:${AWS::Partition}:s3:::${bucketName}/*",
{
"bucketName": {
"Ref": "BucketName"
}
}
]
}
]
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation",
"s3:GetLifecycleConfiguration",
"s3:PutLifecycleConfiguration"
],
"Resource": [
{
"Fn::Sub": [
"arn:${AWS::Partition}:s3:::${bucketName}",
{
"bucketName": {
"Ref": "BucketName"
}
}
]
}
]
}
]
```
## S3ReadPolicy
Donne l'autorisation de lire des objets en lecture seule dans un compartiment Amazon Simple Storage Service (Amazon S3).
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:GetBucketLocation",
"s3:GetObjectVersion",
"s3:GetLifecycleConfiguration"
],
"Resource": [
{
"Fn::Sub": [
"arn:${AWS::Partition}:s3:::${bucketName}",
{
"bucketName": {
"Ref": "BucketName"
}
}
]
},
{
"Fn::Sub": [
"arn:${AWS::Partition}:s3:::${bucketName}/*",
{
"bucketName": {
"Ref": "BucketName"
}
}
]
}
]
}
]
```
## S3WritePolicy
Donne l'autorisation d'écrire des objets dans un compartiment Amazon S3.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl",
"s3:PutLifecycleConfiguration"
],
"Resource": [
{
"Fn::Sub": [
"arn:${AWS::Partition}:s3:::${bucketName}",
{
"bucketName": {
"Ref": "BucketName"
}
}
]
},
{
"Fn::Sub": [
"arn:${AWS::Partition}:s3:::${bucketName}/*",
{
"bucketName": {
"Ref": "BucketName"
}
}
]
}
]
}
]
```
## SageMakerCreateEndpointConfigPolicy
Donne l'autorisation de créer une configuration de point de terminaison dans SageMaker AI.
```
"Statement": [
{
"Action": [
"sagemaker:CreateEndpointConfig"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:sagemaker:${AWS::Region}:${AWS::AccountId}:endpoint-config/${endpointConfigName}",
{
"endpointConfigName": {
"Ref": "EndpointConfigName"
}
}
]
},
"Effect": "Allow"
}
]
```
## SageMakerCreateEndpointPolicy
Donne l'autorisation de créer un point de terminaison dans SageMaker AI.
```
"Statement": [
{
"Action": [
"sagemaker:CreateEndpoint"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:sagemaker:${AWS::Region}:${AWS::AccountId}:endpoint/${endpointName}",
{
"endpointName": {
"Ref": "EndpointName"
}
}
]
},
"Effect": "Allow"
}
]
```
## ServerlessRepoReadWriteAccessPolicy
Donne l'autorisation de créer et de répertorier des applications dans le service AWS Serverless Application Repository (AWS SAM).
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"serverlessrepo:CreateApplication",
"serverlessrepo:CreateApplicationVersion",
"serverlessrepo:GetApplication",
"serverlessrepo:ListApplications",
"serverlessrepo:ListApplicationVersions"
],
"Resource": [
{
"Fn::Sub": "arn:${AWS::Partition}:serverlessrepo:${AWS::Region}:${AWS::AccountId}:applications/*"
}
]
}
]
```
## SESBulkTemplatedCrudPolicy
Donne l'autorisation d'envoyer des e-mails Amazon SES, des e-mails modélisés, des e-mails groupés et de vérifier l'identité.
**Note**
L'action `ses:SendTemplatedEmail` nécessite un modèle d'ARN. Utilisez `SESBulkTemplatedCrudPolicy_v2` à la place.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"ses:GetIdentityVerificationAttributes",
"ses:SendEmail",
"ses:SendRawEmail",
"ses:SendTemplatedEmail",
"ses:SendBulkTemplatedEmail",
"ses:VerifyEmailIdentity"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:ses:${AWS::Region}:${AWS::AccountId}:identity/${identityName}",
{
"identityName": {
"Ref": "IdentityName"
}
}
]
}
}
]
```
## SESBulkTemplatedCrudPolicy\$1v2
Donne l'autorisation d'envoyer des e-mails Amazon SES, des e-mails modélisés, des e-mails groupés et de vérifier l'identité.
```
"Statement": [
{
"Action": [
"ses:SendEmail",
"ses:SendRawEmail",
"ses:SendTemplatedEmail",
"ses:SendBulkTemplatedEmail"
],
"Effect": "Allow",
"Resource": [
{
"Fn::Sub": [
"arn:${AWS::Partition}:ses:${AWS::Region}:${AWS::AccountId}:identity/${identityName}",
{
"identityName": {
"Ref": "IdentityName"
}
}
]
},
{
"Fn::Sub": [
"arn:${AWS::Partition}:ses:${AWS::Region}:${AWS::AccountId}:template/${templateName}",
{
"templateName": {
"Ref": "TemplateName"
}
}
]
}
]
},
{
"Action": [
"ses:GetIdentityVerificationAttributes",
"ses:VerifyEmailIdentity"
],
"Effect": "Allow",
"Resource": "*"
}
]
```
## SESCrudPolicy
Donne l'autorisation d'envoyer un e-mail et de vérifier l'identité.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"ses:GetIdentityVerificationAttributes",
"ses:SendEmail",
"ses:SendRawEmail",
"ses:VerifyEmailIdentity"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:ses:${AWS::Region}:${AWS::AccountId}:identity/${identityName}",
{
"identityName": {
"Ref": "IdentityName"
}
}
]
}
}
]
```
## SESEmailTemplateCrudPolicy
Donne l'autorisation de créer, obtenir, répertorier, mettre à jour et supprimer les modèles d'e-mail Amazon SES.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"ses:CreateTemplate",
"ses:GetTemplate",
"ses:ListTemplates",
"ses:UpdateTemplate",
"ses:DeleteTemplate",
"ses:TestRenderTemplate"
],
"Resource": "*"
}
]
```
## SESSendBouncePolicy
Donne SendBounce l'autorisation d'utiliser une identité Amazon Simple Email Service (Amazon SES).
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"ses:SendBounce"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:ses:${AWS::Region}:${AWS::AccountId}:identity/${identityName}",
{
"identityName": {
"Ref": "IdentityName"
}
}
]
}
}
]
```
## SNSCrudPolicy
Donne l'autorisation de créer et de publier des rubriques Amazon SNS, et de s'y abonner.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"sns:ListSubscriptionsByTopic",
"sns:CreateTopic",
"sns:SetTopicAttributes",
"sns:Subscribe",
"sns:Publish"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:sns:${AWS::Region}:${AWS::AccountId}:${topicName}*",
{
"topicName": {
"Ref": "TopicName"
}
}
]
}
}
]
```
## SNSPublishMessagePolicy
Donne l'autorisation de publier un message dans une rubrique Amazon Simple Notification Service (Amazon SNS).
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"sns:Publish"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:sns:${AWS::Region}:${AWS::AccountId}:${topicName}",
{
"topicName": {
"Ref": "TopicName"
}
}
]
}
}
]
```
## SQSPollerPolicy
Donne l'autorisation d'interroger une file d'attente Amazon Simple Queue Service (Amazon SQS).
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"sqs:ChangeMessageVisibility",
"sqs:ChangeMessageVisibilityBatch",
"sqs:DeleteMessage",
"sqs:DeleteMessageBatch",
"sqs:GetQueueAttributes",
"sqs:ReceiveMessage"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:sqs:${AWS::Region}:${AWS::AccountId}:${queueName}",
{
"queueName": {
"Ref": "QueueName"
}
}
]
}
}
]
```
## SQSSendMessagePolicy
Donne l'autorisation d'envoyer un message à une file d'attente Amazon SQS.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"sqs:SendMessage*"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:sqs:${AWS::Region}:${AWS::AccountId}:${queueName}",
{
"queueName": {
"Ref": "QueueName"
}
}
]
}
}
]
```
## SSMParameterReadPolicy
Permet d'accéder à un paramètre depuis un magasin de paramètres Amazon EC2 Systems Manager (SSM) pour charger des secrets dans ce compte. À utiliser lorsque le nom du paramètre n'est pas précédé d'une barre oblique.
**Note**
Si vous n'utilisez pas la clé par défaut, vous aurez également besoin de la stratégie `KMSDecryptPolicy`.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:DescribeParameters"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetParameters",
"ssm:GetParameter",
"ssm:GetParametersByPath"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:ssm:${AWS::Region}:${AWS::AccountId}:parameter/${parameterName}",
{
"parameterName": {
"Ref": "ParameterName"
}
}
]
}
}
]
```
## SSMParameterWithSlashPrefixReadPolicy
Permet d'accéder à un paramètre depuis un magasin de paramètres Amazon EC2 Systems Manager (SSM) pour charger des secrets dans ce compte. À utiliser lorsque le nom du paramètre est précédé d'une barre oblique.
**Note**
Si vous n'utilisez pas la clé par défaut, vous aurez également besoin de la stratégie `KMSDecryptPolicy`.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:DescribeParameters"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetParameters",
"ssm:GetParameter",
"ssm:GetParametersByPath"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:ssm:${AWS::Region}:${AWS::AccountId}:parameter${parameterName}",
{
"parameterName": {
"Ref": "ParameterName"
}
}
]
}
}
]
```
## StepFunctionsExecutionPolicy
Donne l'autorisation de lancer l'exécution d'une machine d'état Step Functions.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"states:StartExecution"
],
"Resource": {
"Fn::Sub": [
"arn:${AWS::Partition}:states:${AWS::Region}:${AWS::AccountId}:stateMachine:${stateMachineName}",
{
"stateMachineName": {
"Ref": "StateMachineName"
}
}
]
}
}
]
```
## TextractDetectAnalyzePolicy
Donne l'accès permettant de détecter et d'analyser des documents avec Amazon Textract.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"textract:DetectDocumentText",
"textract:StartDocumentTextDetection",
"textract:StartDocumentAnalysis",
"textract:AnalyzeDocument"
],
"Resource": "*"
}
]
```
## TextractGetResultPolicy
Donne l'accès permettant d'obtenir des documents détectés et analysés avec Amazon Textract.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"textract:GetDocumentTextDetection",
"textract:GetDocumentAnalysis"
],
"Resource": "*"
}
]
```
## TextractPolicy
Donne l'accès complet à Amazon Textract.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"textract:*"
],
"Resource": "*"
}
]
```
## VPCAccessPolicy
Donne l'accès pour créer, supprimer, décrire et détacher des interfaces réseau élastiques.
```
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:DeleteNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DetachNetworkInterface"
],
"Resource": "*"
}
]
```
# Gestion des AWS SAM autorisations à l'aide de CloudFormation mécanismes
Pour contrôler l'accès aux AWS ressources, le AWS Serverless Application Model (AWS SAM) peut utiliser les mêmes mécanismes que CloudFormation. Pour plus d’informations, consultez [Contrôle de l’accès à l’aide de Gestion des identités et des accès AWS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html) dans le *Guide de l’utilisateur AWS CloudFormation *.
Il existe trois options principales pour accorder à un utilisateur l’autorisation de gérer des applications sans serveur. Chaque option offre aux utilisateurs différents niveaux de contrôle d’accès.
+ Accorder des autorisations d’administrateur
+ Joignez les politiques AWS gérées nécessaires.
+ Accordez des autorisations spécifiques Gestion des identités et des accès AWS (IAM).
Selon l'option choisie, les utilisateurs ne peuvent gérer que les applications sans serveur contenant des AWS ressources auxquelles ils sont autorisés à accéder.
Les sections suivantes décrivent chaque option plus en détail.
## Accorder des autorisations d’administrateur
Si vous accordez des autorisations d'administrateur à un utilisateur, celui-ci peut gérer des applications sans serveur contenant n'importe quelle combinaison de AWS ressources. C’est l’option la plus simple, mais elle accorde également aux utilisateurs l’ensemble d’autorisations le plus étendu, ce qui leur permet de réaliser des actions d’un impact le plus élevé.
Pour plus d’informations sur l’attribution d’autorisations d’administrateur à un utilisateur, consultez [Création de votre premier utilisateur administrateur et groupe IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html) dans le *Guide de l’utilisateur IAM*
## Joindre les politiques AWS gérées nécessaires
Vous pouvez accorder aux utilisateurs un sous-ensemble d’autorisations en utilisant des [stratégies gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies), plutôt que d’accorder des autorisations d’administrateur complètes. Si vous utilisez cette option, assurez-vous que l'ensemble de politiques AWS gérées couvre toutes les actions et ressources requises pour les applications sans serveur gérées par les utilisateurs.
Par exemple, les politiques AWS gérées suivantes sont suffisantes pour [déployer l'exemple d'application Hello World](serverless-getting-started-hello-world.md) :
+ AWSCloudFormationFullAccess
+ IAMFullAccès
+ AWSLambda\$1FullAccess
+ APIGatewayAdministrateur Amazon
+ Amazon S3 FullAccess
+ Amazon EC2 ContainerRegistryFullAccess
Pour plus d’informations sur l’attachement de stratégies à un utilisateur IAM, consultez [Modification des autorisations d’un utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html) dans le *Guide de l’utilisateur IAM*.
## Accorder des autorisations (IAM) spécifiques.
Pour un niveau de contrôle d’accès plus détaillé, vous pouvez accorder des autorisations IAM spécifiques aux utilisateurs à l’aide des [déclarations de stratégie](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_statement.html). Si vous utilisez cette option, assurez-vous que la déclaration de stratégie comprenne toutes les actions et ressources requises pour les applications sans serveur gérées par les utilisateurs.
La bonne pratique avec cette option consiste à refuser aux utilisateurs l’autorisation de créer des rôles, y compris des rôles d’exécution Lambda, afin qu’ils ne puissent pas s’accorder eux-mêmes des autorisations progressives. Ainsi, en tant qu’administrateur, vous devez d’abord créer un [Rôle d’exécution Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) qui sera spécifié dans les applications sans serveur que les utilisateurs vont gérer. Pour plus d’informations sur la création de rôles d’exécution Lambda, consultez [Création d’un rôle d’exécution dans la console IAM](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html#permissions-executionrole-console).
Pour l'[exemple d'application Hello World](serverless-getting-started-hello-world.md), **AWSLambdaBasicExecutionRole**c'est suffisant pour exécuter l'application. Après avoir créé un rôle d'exécution Lambda, modifiez le fichier AWS SAM modèle de l'exemple d'application Hello World pour ajouter la propriété suivante à la `AWS::Serverless::Function` ressource :
```
Role: lambda-execution-role-arn
```
Lorsque l’application Hello World modifiée est en place, la déclaration de stratégie suivante accorde des autorisations suffisantes aux utilisateurs pour le déploiement, la mise à jour et l’élimination de l’application :
**Note**
L’exemple de déclaration de stratégie de cette section vous permet de déployer, de mettre à jour et d’éliminer l’[exemple d’application Hello World](serverless-getting-started-hello-world.md). Si vous ajoutez des types de ressources supplémentaires à l’application, vous devez mettre à jour la déclaration de stratégie pour inclure les éléments suivants :
Autorisation permettant à l’application d’appeler les actions du service.
Le principal du service, si nécessaire pour les actions du service.
Par exemple, si vous ajoutez un flux de travail Step Functions, vous devrez peut-être ajouter des autorisations pour les actions répertoriées [ici](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsstepfunctions.html#awsstepfunctions-actions-as-permissions) et le `states.amazonaws.com`principal du service.
Pour plus d’informations sur la gestion des stratégies IAM, consultez [Gestion des stratégies IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) dans le *Guide de l’utilisateur IAM*.
# Contrôlez l'accès aux API avec votre AWS SAM modèle
Le contrôle de l'accès à votre API Gateway APIs permet de garantir que votre application sans serveur est sécurisée et n'est accessible que par le biais de l'autorisation que vous autorisez. Vous pouvez activer l'autorisation dans votre AWS SAM modèle pour contrôler qui peut accéder à votre API Gateway APIs.
AWS SAM prend en charge plusieurs mécanismes pour contrôler l'accès à votre API Gateway APIs. L'ensemble des mécanismes pris en charge diffère entre les types de ressources `AWS::Serverless::HttpApi` et `AWS::Serverless::Api`.
Le tableau suivant récapitule les mécanismes pris en charge par type de ressource.
| Mécanismes de contrôle de l'accès | AWS::Serverless::HttpApi | AWS::Serverless::Api |
| --- | --- | --- |
| Mécanismes d'autorisation Lambda | ✓ | ✓ |
| Autorisations IAM | | ✓ |
| Groupes d'utilisateurs Amazon Cognito | ✓ \$1 | ✓ |
| Clés d’API | | ✓ |
| Politiques basées sur une ressource | | ✓ |
| OAuth 2.0/Autorisateurs JWT | ✓ | |
\$1 Vous pouvez utiliser Amazon Cognito en tant qu'auteur de jeton web JSON (JWT) avec le type de ressource `AWS::Serverless::HttpApi`.
+ **Mécanismes d'autorisation** – Un mécanisme d'autorisation Lambda (anciennement appelé *Custom Authorizer (mécanisme d'autorisation personnalisée)*) est une fonction Lambda vous permettant de contrôler l'accès à vos API. Lorsque votre API est appelée, cette fonction Lambda est appelée avec un contexte de requête ou un jeton d'autorisation fourni par l'application cliente. La fonction Lambda répond si l'appelant est autorisé à effectuer l'opération demandée.
Les types de ressources `AWS::Serverless::HttpApi` et `AWS::Serverless::Api` prennent tous deux en charge les mécanismes d'autorisation Lambda.
Pour plus d'informations sur les autorisateurs Lambda avec`AWS::Serverless::HttpApi`, consultez la section [Working with AWS Lambda authorizers for HTTP dans le Guide du développeur APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-lambda-authorizer.html) d'*API* Gateway. Pour plus d'informations sur les mécanismes d'autorisation Lambda avec `AWS::Serverless::Api`, consultez [Utilisation des mécanismes d'autorisation Lambda API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html) dans le *Guide du développeur API Gateway*.
Pour obtenir des exemples de mécanismes d'autorisation Lambda pour l'un ou l'autre des deux type de ressource, consultez [Exemples d'autorisateurs Lambda pour AWS SAM](serverless-controlling-access-to-apis-lambda-authorizer.md).
+ **Autorisations IAM** – Vous pouvez contrôler les personnes pouvant appeler votre API en utilisant [Gestion des identités et des accès AWS (IAM) autorisations](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html). Les utilisateurs appelant votre API doivent être authentifiés avec des informations d'identification IAM. Les appels vers votre API ne réussissent que s'il existe une stratégie IAM attachée à l'utilisateur IAM qui représente l'appelant API, un groupe IAM qui contient l'utilisateur ou un rôle IAM assumé par l'utilisateur.
Seul le type de ressource `AWS::Serverless::Api` prend en charge les autorisations IAM.
Pour plus d'informations, consultez le [Contrôle de l'accès à une API avec des autorisations IAM](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html) dans le *Guide du développeur API*. Pour obtenir un exemple, consultez [Exemple d'autorisation IAM pour AWS SAM](serverless-controlling-access-to-apis-permissions.md).
+ **Groupes d'utilisateurs Amazon Cognito** – Les groupes d'utilisateurs Amazon Cognito sont des répertoires d'utilisateurs dans Amazon Cognito. Un client de votre API doit d'abord se connecter à un groupe d'utilisateurs et obtenir un jeton d'identité ou d'accès pour l'utilisateur. Ensuite, le client appelle votre API avec l'un des jetons renvoyés. L'appel d'API réussit uniquement si le jeton requis est valide.
Le type de ressource `AWS::Serverless::Api` prend en charge les groupes d'utilisateurs Amazon Cognito. Le type de ressource `AWS::Serverless::HttpApi` prend en charge l'utilisation d'Amazon Cognito en tant qu'auteur de JWT.
Pour plus d'informations, consultez [Contrôle de l'accès à une API REST à l'aide de groupes d'utilisateurs Amazon Cognito en tant que mécanisme d'autorisation](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html) dans le *Guide du développeur API Gateway*. Pour obtenir un exemple, consultez [Exemple de groupe d'utilisateurs Amazon Cognito pour AWS SAM](serverless-controlling-access-to-apis-cognito-user-pool.md).
+ Les **clés API** sont des valeurs de chaînes alphanumériques que vous distribuez aux clients développeurs d'applications pour leur accorder l'accès à votre API.
Seul le type de ressource `AWS::Serverless::Api` prend en charge les clés API.
Pour plus d'informations concernant les clés API, consultez [Création et utilisation de plans d'utilisation avec les clés API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-usage-plans.html) dans le *Guide du développeur API Gateway*. Pour obtenir un exemple de clés API, voir[Exemple de clé d'API pour AWS SAM](serverless-controlling-access-to-apis-keys.md).
+ **Stratégies de ressources** – Les stratégies de ressources sont des documents de stratégie JSON que vous pouvez attacher à une API API Gateway. Vous pouvez utiliser les stratégies de ressources pour contrôler si un mandataire spécifié (généralement, un utilisateur ou un rôle IAM) peut appeler l'API.
Seul le type de `AWS::Serverless::Api` ressource prend en charge les politiques de ressources en tant que mécanisme de contrôle de l'accès à API Gateway APIs.
Pour plus d'informations sur les stratégies de ressources, consultez [Contrôle de l'accès à une API avec des stratégies de ressources API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies.html) dans le *Guide du développeur API*. Pour un exemple de stratégies de ressources, consultez [Exemple de politique de ressources pour AWS SAM](serverless-controlling-access-to-apis-resource-policies.md).
+ **OAuth Autorisateurs 2.0/JWT** — Vous pouvez les utiliser dans JWTs le cadre des frameworks OpenID [Connect (OIDC)](https://openid.net/specs/openid-connect-core-1_0.html) et [OAuth 2.0](https://oauth.net/2/) pour contrôler l'accès à votre. APIs API Gateway valide les JWTs demandes d'API soumises par les clients et autorise ou refuse les demandes en fonction de la validation du jeton et, éventuellement, des étendues du jeton.
Seul le type de `AWS::Serverless::HttpApi` ressource prend en charge les autorisateurs OAuth 2.0/JWT.
Pour plus d'informations, consultez la section [Contrôle de l'accès au protocole HTTP APIs avec les autorisateurs JWT](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html) dans le guide du *développeur d'API Gateway*. Pour obtenir un exemple, consultez [OAuth Exemple d'autorisateur 2.0/JWT pour AWS SAM](serverless-controlling-access-to-apis-oauth2-authorizer.md).
## Choix d'un mécanisme de contrôle d'accès
Le mécanisme que vous choisissez d'utiliser pour contrôler l'accès à votre API Gateway APIs dépend de plusieurs facteurs. Par exemple, si vous avez un projet inédit sans autorisation ni contrôle d'accès configuré, les groupes d'utilisateurs Amazon Cognito peuvent constituer votre meilleure option. En effet, lorsque vous configurez des groupes d'utilisateurs, vous configurez également automatiquement l'authentification et le contrôle d'accès.
Cependant, si votre application a déjà configuré l'authentification, l'utilisation de mécanismes d'autorisation Lambda pourrait être votre meilleur choix. Cela est dû au fait que vous pouvez appeler votre service d'authentification existant et renvoyer un document de stratégie basé sur la réponse. En outre, si votre application nécessite une authentification personnalisée ou une logique de contrôle d'accès que les groupes d'utilisateurs ne prennent pas en charge, alors les autorisations Lambda pourraient constituer votre meilleure option.
Lorsque vous avez choisi le mécanisme à utiliser, consultez la section correspondante [Exemples](#serverless-controlling-access-to-apis-examples) pour savoir comment l'utiliser AWS SAM pour configurer votre application afin qu'elle utilise ce mécanisme.
## Personnalisation des réponses d'erreur
Vous pouvez l'utiliser AWS SAM pour personnaliser le contenu de certaines réponses d'erreur d'API Gateway. Seul le type de ressource `AWS::Serverless::Api` prend en charge les réponses personnalisées API Gateway.
Pour plus d'informations sur les réponses API Gateway, consultez [Réponses de passerelle dans API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-gatewayResponse-definition.html) dans le *Guide du développeur API Gateway*. Pour obtenir un exemple de réponses personnalisées, consultez [Exemple de réponse personnalisée pour AWS SAM](serverless-controlling-access-to-apis-customize-response.md).
## Exemples
+ [Exemples d'autorisateurs Lambda pour AWS SAM](serverless-controlling-access-to-apis-lambda-authorizer.md)
+ [Exemple d'autorisation IAM pour AWS SAM](serverless-controlling-access-to-apis-permissions.md)
+ [Exemple de groupe d'utilisateurs Amazon Cognito pour AWS SAM](serverless-controlling-access-to-apis-cognito-user-pool.md)
+ [Exemple de clé d'API pour AWS SAM](serverless-controlling-access-to-apis-keys.md)
+ [Exemple de politique de ressources pour AWS SAM](serverless-controlling-access-to-apis-resource-policies.md)
+ [OAuth Exemple d'autorisateur 2.0/JWT pour AWS SAM](serverless-controlling-access-to-apis-oauth2-authorizer.md)
+ [Exemple de réponse personnalisée pour AWS SAM](serverless-controlling-access-to-apis-customize-response.md)
# Exemples d'autorisateurs Lambda pour AWS SAM
Le type de ressource `AWS::Serverless::Api` prend en charge deux types de mécanismes d'autorisation Lambda : les mécanismes d'autorisation de `TOKEN` et les mécanismes d'autorisation de `REQUEST`. Le type de ressource `AWS::Serverless::HttpApi` prend uniquement en charge les mécanismes d' autorisation `REQUEST`. Voici des exemples de chaque type.
## Exemples d'autorisation Lambda `TOKEN` (AWS::Serverless::Api)
Vous pouvez contrôler l'accès à votre APIs en définissant un `TOKEN` autorisateur Lambda dans votre modèle. AWS SAM Vous devez pour cela utiliser le type de données [ApiAuth](sam-property-api-apiauth.md).
Voici un exemple de section de AWS SAM modèle pour un autorisateur Lambda `TOKEN` :
**Note**
Dans l'exemple suivant, le SAM `FunctionRole` est généré implicitement.
```
Resources:
MyApi:
Type: AWS::Serverless::Api
Properties:
StageName: Prod
Auth:
DefaultAuthorizer: MyLambdaTokenAuthorizer
Authorizers:
MyLambdaTokenAuthorizer:
FunctionArn: !GetAtt MyAuthFunction.Arn
MyFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: ./src
Handler: index.handler
Runtime: nodejs12.x
Events:
GetRoot:
Type: Api
Properties:
RestApiId: !Ref MyApi
Path: /
Method: get
MyAuthFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: ./src
Handler: authorizer.handler
Runtime: nodejs12.x
```
Pour plus d'informations sur les mécanismes d'autorisation Lambda, consultez [Utilisation des mécanismes d'autorisation pour les API Gateway Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html) dans le *Guide du développeur API Gateway*.
## Exemples d'autorisation Lambda `REQUEST` (AWS::Serverless::Api)
Vous pouvez contrôler l'accès à votre APIs en définissant un `REQUEST` autorisateur Lambda dans votre modèle. AWS SAM Vous devez pour cela utiliser le type de données [ApiAuth](sam-property-api-apiauth.md).
Voici un exemple de section de AWS SAM modèle pour un autorisateur Lambda `REQUEST` :
```
Resources:
MyApi:
Type: AWS::Serverless::Api
Properties:
StageName: Prod
Auth:
DefaultAuthorizer: MyLambdaRequestAuthorizer
Authorizers:
MyLambdaRequestAuthorizer:
FunctionPayloadType: REQUEST
FunctionArn: !GetAtt MyAuthFunction.Arn
Identity:
QueryStrings:
- auth
MyFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: ./src
Handler: index.handler
Runtime: nodejs12.x
Events:
GetRoot:
Type: Api
Properties:
RestApiId: !Ref MyApi
Path: /
Method: get
MyAuthFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: ./src
Handler: authorizer.handler
Runtime: nodejs12.x
```
Pour plus d'informations sur les mécanismes d'autorisation Lambda, consultez [Utilisation des mécanismes d'autorisation pour les API Gateway Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html) dans le *Guide du développeur API Gateway*.
## Exemples d'autorisation Lambda (AWS::Serverless::HttpApi)
Vous pouvez contrôler l'accès à votre HTTP APIs en définissant un autorisateur Lambda dans votre modèle. AWS SAM Vous devez pour cela utiliser le type de données [HttpApiAuth](sam-property-httpapi-httpapiauth.md).
Voici un exemple de section de AWS SAM modèle pour un autorisateur Lambda :
```
Resources:
MyApi:
Type: AWS::Serverless::HttpApi
Properties:
StageName: Prod
Auth:
DefaultAuthorizer: MyLambdaRequestAuthorizer
Authorizers:
MyLambdaRequestAuthorizer:
FunctionArn: !GetAtt MyAuthFunction.Arn
FunctionInvokeRole: !GetAtt MyAuthFunctionRole.Arn
Identity:
Headers:
- Authorization
AuthorizerPayloadFormatVersion: 2.0
EnableSimpleResponses: true
MyFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: ./src
Handler: index.handler
Runtime: nodejs12.x
Events:
GetRoot:
Type: HttpApi
Properties:
ApiId: !Ref MyApi
Path: /
Method: get
PayloadFormatVersion: "2.0"
MyAuthFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: ./src
Handler: authorizer.handler
Runtime: nodejs12.x
```
# Exemple d'autorisation IAM pour AWS SAM
Vous pouvez contrôler l'accès à votre APIs en définissant les autorisations IAM dans votre AWS SAM modèle. Vous devez pour cela utiliser le type de données [ApiAuth](sam-property-api-apiauth.md).
Voici un exemple de AWS SAM modèle utilisé pour les autorisations IAM :
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
MyApi:
Type: AWS::Serverless::Api
Properties:
StageName: Prod
Description: 'API with IAM authorization'
Auth:
DefaultAuthorizer: AWS_IAM #sets AWS_IAM auth for all methods in this API
MyFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: python3.10
Events:
GetRoot:
Type: Api
Properties:
RestApiId: !Ref MyApi
Path: /
Method: get
InlineCode: |
def handler(event, context):
return {'body': 'Hello World!', 'statusCode': 200}
```
Pour plus d'informations sur les autorisations IAM, consultez le [Contrôle de l'accès à une API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html) dans le *Guide du développeur API Gateway*.
# Exemple de groupe d'utilisateurs Amazon Cognito pour AWS SAM
Vous pouvez contrôler l'accès à votre compte APIs en définissant des groupes d'utilisateurs Amazon Cognito dans votre AWS SAM modèle. Vous devez pour cela utiliser le type de données [ApiAuth](sam-property-api-apiauth.md).
Voici un exemple de section de AWS SAM modèle pour un groupe d'utilisateurs :
```
Resources:
MyApi:
Type: AWS::Serverless::Api
Properties:
StageName: Prod
Cors: "'*'"
Auth:
DefaultAuthorizer: MyCognitoAuthorizer
Authorizers:
MyCognitoAuthorizer:
UserPoolArn: !GetAtt MyCognitoUserPool.Arn
MyFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: ./src
Handler: lambda.handler
Runtime: nodejs12.x
Events:
Root:
Type: Api
Properties:
RestApiId: !Ref MyApi
Path: /
Method: GET
MyCognitoUserPool:
Type: AWS::Cognito::UserPool
Properties:
UserPoolName: !Ref CognitoUserPoolName
Policies:
PasswordPolicy:
MinimumLength: 8
UsernameAttributes:
- email
Schema:
- AttributeDataType: String
Name: email
Required: false
MyCognitoUserPoolClient:
Type: AWS::Cognito::UserPoolClient
Properties:
UserPoolId: !Ref MyCognitoUserPool
ClientName: !Ref CognitoUserPoolClientName
GenerateSecret: false
```
Pour plus informations sur les groupes d'utilisateurs Amazon Cognito, consultez [Contrôle de l'accès à une API REST à l'aide de groupes d'utilisateurs Amazon Cognito en tant que mécanisme d'autorisation](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html) dans le *Guide du développeur API Gateway*.
# Exemple de clé d'API pour AWS SAM
Vous pouvez contrôler l'accès à votre APIs en exigeant des clés d'API dans votre AWS SAM modèle. Vous devez pour cela utiliser le type de données [ApiAuth](sam-property-api-apiauth.md).
Voici un exemple de section de AWS SAM modèle pour les clés d'API :
```
Resources:
MyApi:
Type: AWS::Serverless::Api
Properties:
StageName: Prod
Auth:
ApiKeyRequired: true # sets for all methods
MyFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: .
Handler: index.handler
Runtime: nodejs12.x
Events:
ApiKey:
Type: Api
Properties:
RestApiId: !Ref MyApi
Path: /
Method: get
Auth:
ApiKeyRequired: true
```
Pour plus d'informations concernant les clés API, consultez [Création et utilisation de plans d'utilisation avec les clés API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-usage-plans.html) dans le *Guide du développeur API Gateway*.
# Exemple de politique de ressources pour AWS SAM
Vous pouvez contrôler l'accès à votre APIs en joignant une politique de ressources à votre AWS SAM modèle. Vous devez pour cela utiliser le type de données [ApiAuth](sam-property-api-apiauth.md).
Voici un exemple de AWS SAM modèle pour une API privée. Une API privée doit disposer d'une politique de ressources pour être déployée.
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
MyPrivateApi:
Type: AWS::Serverless::Api
Properties:
StageName: Prod
EndpointConfiguration: PRIVATE # Creates a private API. Resource policies are required for all private APIs.
Auth:
ResourcePolicy:
CustomStatements:
- Effect: 'Allow'
Action: 'execute-api:Invoke'
Resource: ['execute-api:/*/*/*']
Principal: '*'
- Effect: 'Deny'
Action: 'execute-api:Invoke'
Resource: ['execute-api:/*/*/*']
Principal: '*'
MyFunction:
Type: 'AWS::Serverless::Function'
Properties:
InlineCode: |
def handler(event, context):
return {'body': 'Hello World!', 'statusCode': 200}
Handler: index.handler
Runtime: python3.10
Events:
AddItem:
Type: Api
Properties:
RestApiId:
Ref: MyPrivateApi
Path: /
Method: get
```
Pour plus d'informations sur les stratégies de ressources, consultez [Contrôle de l'accès à une API avec des stratégies de ressources API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies.html) dans le *Guide du développeur API*. Pour plus d'informations sur le mode privé APIs, consultez [la section Création d'une API privée dans Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-private-apis.html) dans le *guide du développeur d'API Gateway*.
# OAuth Exemple d'autorisateur 2.0/JWT pour AWS SAM
[Vous pouvez contrôler l'accès à votre APIs utilisation dans JWTs le cadre des [frameworks OpenID Connect (OIDC) et OAuth 2.0](https://openid.net/specs/openid-connect-core-1_0.html).](https://oauth.net/2/) Vous devez pour cela utiliser le type de données [HttpApiAuth](sam-property-httpapi-httpapiauth.md).
Voici un exemple de section de AWS SAM modèle pour un autorisateur OAuth 2.0/JWT :
```
Resources:
MyApi:
Type: AWS::Serverless::HttpApi
Properties:
Auth:
Authorizers:
MyOauth2Authorizer:
AuthorizationScopes:
- scope
IdentitySource: $request.header.Authorization
JwtConfiguration:
audience:
- audience1
- audience2
issuer: "https://www.example.com/v1/connect/oidc"
DefaultAuthorizer: MyOauth2Authorizer
StageName: Prod
MyFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: ./src
Events:
GetRoot:
Properties:
ApiId: MyApi
Method: get
Path: /
PayloadFormatVersion: "2.0"
Type: HttpApi
Handler: index.handler
Runtime: nodejs12.x
```
*Pour plus d'informations sur les autorisateurs OAuth 2.0/JWT, consultez la section [Contrôle de l'accès au HTTP APIs avec les autorisateurs JWT dans le guide du développeur](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html) d'API Gateway.*
# Exemple de réponse personnalisée pour AWS SAM
Vous pouvez personnaliser certaines réponses d'erreur API Gateway en définissant des en-têtes de réponse dans votre modèle AWS SAM . Vous devez pour cela utiliser le type de données [Objet de réponse de passerelle](https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#gateway-response-object).
Voici un exemple de AWS SAM modèle qui crée une réponse personnalisée à l'`DEFAULT_5XX`erreur.
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
MyApi:
Type: AWS::Serverless::Api
Properties:
StageName: Prod
GatewayResponses:
DEFAULT_5XX:
ResponseParameters:
Headers:
Access-Control-Expose-Headers: "'WWW-Authenticate'"
Access-Control-Allow-Origin: "'*'"
ErrorHeader: "'MyCustomErrorHeader'"
ResponseTemplates:
application/json: "{\"message\": \"Error on the $context.resourcePath resource\" }"
GetFunction:
Type: AWS::Serverless::Function
Properties:
Runtime: python3.10
Handler: index.handler
InlineCode: |
def handler(event, context):
raise Exception('Check out the new response!')
Events:
GetResource:
Type: Api
Properties:
Path: /error
Method: get
RestApiId: !Ref MyApi
```
Pour plus d'informations sur les réponses API Gateway, consultez [Réponses de passerelle dans API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-gatewayResponse-definition.html) dans le *Guide du développeur API Gateway*.
# Améliorez l'efficacité en utilisant les couches Lambda avec AWS SAM
En utilisant AWS SAM, vous pouvez inclure des couches dans vos applications sans serveur. AWS Lambda les couches vous permettent d'extraire le code d'une fonction Lambda dans une couche Lambda qui peut ensuite être utilisée dans plusieurs fonctions Lambda. Cela vous permet de réduire la taille de vos packages de déploiement, de séparer la logique des fonctions de base des dépendances et de partager les dépendances entre plusieurs fonctions. Pour plus d'informations sur les couches, consultez la section [Couches Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) dans le Guide du *AWS Lambda développeur*.
Cette rubrique fournit des informations sur les éléments suivants :
+ Inclusion de couches dans votre application
+ Comment les couches sont mises en cache localement
Pour plus d'informations sur la création de couches personnalisées, consultez [Création de couches Lambda dans AWS SAM](building-layers.md).
## Inclusion de couches dans votre application
Pour inclure des couches dans votre application, utilisez la propriété `Layers` du type de ressource [AWS::Serverless::Function](sam-resource-function.md).
Voici un exemple de AWS SAM modèle avec une fonction Lambda qui inclut une couche :
```
ServerlessFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: .
Handler: my_handler
Runtime: Python3.7
Layers:
-
```
## Comment les couches sont mises en cache localement
Lorsque vous appelez votre fonction à l'aide de l'une des commandes `sam local`, le package de couches de votre fonction est téléchargé et mis en cache sur votre hôte local.
Le tableau suivant montre les emplacements de répertoire des mises en cache par défaut pour les différents systèmes d'exploitation.
****
| Système d’exploitation | Location |
| --- | --- |
| Windows 7 | C:\$1Users\$1\$1AppData\$1Roaming\$1AWS SAM |
| Windows 8 | C:\$1Users\$1\$1AppData\$1Roaming\$1AWS SAM |
| Windows 10 | C:\$1Users\$1\$1AppData\$1Roaming\$1AWS SAM |
| macOS | \$1/.aws-sam/layers-pkg |
| Unix | \$1/.aws-sam/layers-pkg |
Une fois que le package est mis en cache, la CLI AWS SAM superpose les couches sur une image Docker utilisée pour invoquer votre fonction. AWS SAMCLIGénère les noms des images qu'il crée, ainsi que celles LayerVersions qui sont conservées dans le cache. Vous trouverez davantage de détails sur le schéma dans les sections suivantes.
Pour inspecter les couches superposées, exécutez la commande suivante pour démarrer une séance bash dans l'image à inspecter :
```
docker run -it --entrypoint=/bin/bash samcli/lambda: -i
```
**Schéma de nom de répertoire de mise en cache des couches**
Étant donné LayerVersionArn qu'un est défini dans votre modèle, la AWS SAMCLI version LayerName et est extraite de l'ARN. Elle crée un répertoire pour y placer le contenu de la couche, qui sera nommé `LayerName-Version-`.
Exemple :
```
ARN = arn:aws:lambda:us-west-2:111111111111:layer:myLayer:1
Directory name = myLayer-1-926eeb5ff1
```
**Schéma de balises pour les images Docker**
Pour calculer le hachage des couches uniques, combinez tous les noms de couches uniques avec un délimiteur « - », prenez le SHA256 hachage, puis les 10 premiers caractères.
Exemple :
```
ServerlessFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: .
Handler: my_handler
Runtime: Python3.7
Layers:
- arn:aws:lambda:us-west-2:111111111111:layer:myLayer:1
- arn:aws:lambda:us-west-2:111111111111:layer:mySecondLayer:1
```
Les noms uniques sont calculés de la même manière que le schéma de nom du répertoire de mise en cache des couches :
```
arn:aws:lambda:us-west-2:111111111111:layer:myLayer:1 = myLayer-1-926eeb5ff1
arn:aws:lambda:us-west-2:111111111111:layer:mySecondLayer:1 = mySecondLayer-1-6bc1022bdf
```
Pour calculer le hachage des couches uniques, combinez tous les noms de couches uniques avec un délimiteur de '-', prenez le hachage sha256, puis prenez les 25 premiers caractères.
```
myLayer-1-926eeb5ff1-mySecondLayer-1-6bc1022bdf = 2dd7ac5ffb30d515926aef
```
Combinez ensuite cette valeur avec l'exécution et l'architecture de la fonction, avec un délimiteur de '-' :
```
python3.7-x86_64-2dd7ac5ffb30d515926aefffd
```
# Réutilisez le code et les ressources à l'aide d'applications imbriquées dans AWS SAM
Une application sans serveur peut comporter une ou plusieurs **applications imbriquées**. Une application imbriquée fait partie d'une application plus vaste et peut être empaquetée et déployée en tant qu'artefact autonome ou en tant que composant d'une application plus vaste. Les applications imbriquées vous permettent de transformer le code fréquemment utilisé en une seule application qui peut ensuite être réutilisée dans une application sans serveur plus importante ou dans plusieurs applications sans serveur.
Au fur et à mesure que vos architectures sans serveur se développent, des modèles communs apparaissent généralement dans lesquels les mêmes composants sont définis dans plusieurs modèles d'applications. Les applications imbriquées vous permettent de réutiliser le code, les fonctionnalités, les ressources et les configurations courants dans des AWS SAM modèles distincts, ce qui vous permet de ne gérer que le code provenant d'une source unique. Cela permet de réduire le code et les configurations dupliqués. En outre, cette approche modulaire rationalise le développement, améliore l'organisation du code et facilite la cohérence entre les applications sans serveur. Avec les applications imbriquées, vous pouvez rester plus concentré sur la logique métier propre à votre application.
Pour définir une application imbriquée dans votre application sans serveur, utilisez le type de ressource [AWS::Serverless::Application](sam-resource-application.md).
Vous pouvez définir des applications imbriquées à partir des deux sources suivantes :
+ Une **application AWS Serverless Application Repository ** – Vous pouvez définir des applications imbriquées à l'aide d'applications disponibles pour votre compte dans le AWS Serverless Application Repository. Celles-ci peuvent être des applications *privées* dans votre compte, des applications qui sont *partagé de manière privée* avec votre compte, ou des applications qui sont *publiquement partagées * dans le AWS Serverless Application Repository. Pour plus d'informations sur les différents niveaux d'autorisation de déploiement, consultez [Autorisations de déploiement d'applications](https://docs.aws.amazon.com/serverlessrepo/latest/devguide/serverless-app-consuming-applications.html#application-deployment-permissions) et [Publication des applications](https://docs.aws.amazon.com/serverlessrepo/latest/devguide/serverless-app-publishing-applications.html) dans le *Guide du développeur AWS Serverless Application Repository *.
+ Une **application locale** – Vous pouvez définir des applications imbriquées à l'aide d'applications qui sont stockées sur votre système de fichiers local.
Consultez les sections suivantes pour savoir comment AWS SAM définir ces deux types d'applications imbriquées dans votre application sans serveur.
**Note**
Le nombre maximal d'applications pouvant être imbriquées dans une application sans serveur est de 200.
Le nombre maximal de paramètres qu'une application imbriquée peut avoir est de 60.
## Définition d'une application imbriquée à partir du AWS Serverless Application Repository
Vous pouvez définir des applications imbriquées à l'aide d'applications qui sont disponibles pour votre compte dans le AWS Serverless Application Repository. Vous pouvez également stocker et distribuer des applications qui contiennent des applications imbriquées à l'aide du AWS Serverless Application Repository. Pour consulter les détails d'une application imbriquée dans le AWS Serverless Application Repository, vous pouvez utiliser le AWS SDK, la console Lambda ou la AWS CLI console Lambda.
Pour définir une application hébergée AWS Serverless Application Repository dans le AWS SAM modèle de votre application sans serveur, utilisez le bouton **Copier en tant que ressource SAM** sur la page détaillée de chaque AWS Serverless Application Repository application. Pour cela, procédez comme suit :
1. Assurez-vous que vous êtes connecté à la AWS Management Console.
1. Trouvez l'application dans laquelle vous souhaitez vous intégrer AWS Serverless Application Repository en suivant les étapes décrites dans la section [Navigation, recherche et déploiement d'applications](https://docs.aws.amazon.com/serverlessrepo/latest/devguide/serverless-app-consuming-applications.html#browse-and-search-applications ) du *guide du AWS Serverless Application Repository développeur*.
1. Cliquez sur le bouton **Copier comme ressource SAM**. La section de modèle SAM de l'application que vous consultez est maintenant dans votre Presse-papiers.
1. Collez la section du modèle SAM dans la section `Resources:` du fichier de modèle SAM pour l'application que vous souhaitez imbriquer dans cette application.
Voici un exemple de section de modèle SAM pour une application imbriquée hébergée dans le AWS Serverless Application Repository :
```
Transform: AWS::Serverless-2016-10-31
Resources:
applicationaliasname:
Type: AWS::Serverless::Application
Properties:
Location:
ApplicationId: arn:aws:serverlessrepo:us-east-1:123456789012:applications/application-alias-name
SemanticVersion: 1.0.0
Parameters:
# Optional parameter that can have default value overridden
# ParameterName1: 15 # Uncomment to override default value
# Required parameter that needs value to be provided
ParameterName2: YOUR_VALUE
```
Si aucun paramètre n'est requis, vous pouvez omettre la section `Parameters:` du modèle.
**Important**
Les applications qui contiennent des applications imbriquées hébergées dans le AWS Serverless Application Repository héritent des restrictions de partage des applications imbriquées.
Supposons, par exemple, qu'une application soit partagée publiquement, mais qu'elle contienne une application imbriquée qui n'est partagée en privé qu'avec le AWS compte qui a créé l'application parent. Dans ce cas, si votre AWS compte n'est pas autorisé à déployer l'application imbriquée, vous ne pouvez pas déployer l'application parent. Pour plus d'informations sur les autorisation de déploiement des applications, consultez [Autorisations de déploiement d'applications](https://docs.aws.amazon.com/serverlessrepo/latest/devguide/serverless-app-consuming-applications.html#application-deployment-permissions) et [Publication des applications](https://docs.aws.amazon.com/serverlessrepo/latest/devguide/serverless-app-publishing-applications.html) dans le *Guide du développeur AWS Serverless Application Repository *.
## Définition d'une application imbriquée à partir du système de fichiers local
Vous pouvez définir des applications imbriquées à l'aide d'applications qui sont stockées sur votre système de fichiers local. Pour ce faire, spécifiez le chemin d'accès au fichier AWS SAM modèle stocké sur votre système de fichiers local.
Voici un exemple de section de modèle SAM pour une application imbriquée :
```
Transform: AWS::Serverless-2016-10-31
Resources:
applicationaliasname:
Type: AWS::Serverless::Application
Properties:
Location: ../my-other-app/template.yaml
Parameters:
# Optional parameter that can have default value overridden
# ParameterName1: 15 # Uncomment to override default value
# Required parameter that needs value to be provided
ParameterName2: YOUR_VALUE
```
S'il n'y a pas de réglage de paramètres, vous pouvez omettre la section `Parameters:` du modèle.
## Déploiement d'applications imbriquées
Vous pouvez déployer votre application imbriquée en utilisant la commande `sam deploy` de la CLI AWS SAM. Pour en savoir plus, consultez [Déployez votre application et vos ressources avec AWS SAM](serverless-deploying.md).
**Note**
Lorsque vous déployez une application qui contient des applications imbriquées, vous devez reconnaître qu'elle contient des applications imbriquées. Pour ce faire, passez `CAPABILITY_AUTO_EXPAND` à l'[CreateCloudFormationChangeSet API](https://docs.aws.amazon.com/goto/WebAPI/serverlessrepo-2017-09-08/CreateCloudFormationChangeSet) ou utilisez la [https://docs.aws.amazon.com/cli/latest/reference/serverlessrepo/create-cloud-formation-change-set.html](https://docs.aws.amazon.com/cli/latest/reference/serverlessrepo/create-cloud-formation-change-set.html) AWS CLI commande.
Pour plus d'informations sur la reconnaissance des applications imbriquées, consultez [Reconnaissance des rôles, des stratégies de ressources et des applications imbriquées IAM lors du déploiement d'applications](https://docs.aws.amazon.com/serverlessrepo/latest/devguide/acknowledging-application-capabilities.html) dans le *Guide du développeur AWS Serverless Application Repository *.
# Gérez les événements temporels avec le EventBridge planificateur dans AWS SAM
Le contenu de cette rubrique explique en détail ce qu'est Amazon EventBridge Scheduler, quelles sont les AWS SAM offres d'assistance, comment créer des événements Scheduler, ainsi que des exemples auxquels vous pouvez vous référer lors de la création d'événements Scheduler.
## Qu'est-ce qu'Amazon EventBridge Scheduler ?
Utilisez le EventBridge planificateur pour planifier des événements dans vos AWS SAM modèles. Amazon EventBridge Scheduler est un service de planification qui vous permet de créer, de lancer et de gérer des dizaines de millions d'événements et de tâches dans tous les AWS services. Ce service est particulièrement utile pour les événements liés au temps. Vous pouvez l'utiliser pour planifier des événements et des appels récurrents basés sur le temps. Il prend également en charge les événements ponctuels ainsi que les expressions de taux et de chronologie avec une heure de début et de fin.
Pour en savoir plus sur Amazon EventBridge Scheduler, consultez [Qu'est-ce qu'Amazon EventBridge ](https://docs.aws.amazon.com/scheduler/latest/UserGuide/what-is-scheduler.html) Scheduler ? dans le guide de l'*utilisateur EventBridge du planificateur*.
**Topics**
+ [Qu'est-ce qu'Amazon EventBridge Scheduler ?](#using-eventbridge-scheduler-intro)
+ [EventBridge Support du planificateur dans AWS SAM](#using-eventbridge-scheduler-sam-support)
+ [Création d' EventBridge événements du planificateur dans AWS SAM](#using-eventbridge-scheduler-sam-create)
+ [Exemples](#using-eventbridge-scheduler-examples)
+ [En savoir plus](#using-eventbridge-scheduler-learn)
## EventBridge Support du planificateur dans AWS SAM
La spécification du modèle AWS Serverless Application Model (AWS SAM) fournit une syntaxe simple et abrégée que vous pouvez utiliser pour planifier des événements avec EventBridge Scheduler for et. AWS Lambda AWS Step Functions
## Création d' EventBridge événements du planificateur dans AWS SAM
Définissez la `ScheduleV2` propriété comme type d'événement dans votre AWS SAM modèle pour définir votre événement EventBridge Scheduler. Cette propriété prend en charge les types de ressources `AWS::Serverless::Function` et `AWS::Serverless::StateMachine`.
```
MyFunction:
Type: AWS::Serverless::Function
Properties:
Events:
CWSchedule:
Type: ScheduleV2
Properties:
ScheduleExpression: 'rate(1 minute)'
Name: TestScheduleV2Function
Description: Test schedule event
MyStateMachine:
Type: AWS::Serverless::StateMachine
Properties:
Events:
CWSchedule:
Type: ScheduleV2
Properties:
ScheduleExpression: 'rate(1 minute)'
Name: TestScheduleV2StateMachine
Description: Test schedule event
```
EventBridge La planification des événements du planificateur prend également en charge les *files d'attente de lettres mortes (DLQ*) pour les événements non traités. *Pour plus d'informations sur les files d'attente de lettres mortes, consultez la [section Configuration d'une file d'attente de lettres mortes pour le planificateur dans le guide de l'utilisateur du EventBridge planificateur](https://docs.aws.amazon.com/scheduler/latest/UserGuide/configuring-schedule-dlq.html). EventBridge *
Lorsqu'un ARN DLQ est spécifié, AWS SAM configure les autorisations pour que le planificateur planifie l'envoi de messages au DLQ. Lorsqu'aucun ARN DLQ n'est spécifié, la AWS SAM ressource DLQ est créée.
## Exemples
### Exemple de base de définition d'un événement EventBridge Scheduler avec AWS SAM
```
Transform: AWS::Serverless-2016-10-31
Resources:
MyLambdaFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: python3.8
InlineCode: |
def handler(event, context):
print(event)
return {'body': 'Hello World!', 'statusCode': 200}
MemorySize: 128
Events:
Schedule:
Type: ScheduleV2
Properties:
ScheduleExpression: rate(1 minute)
Input: '{"hello": "simple"}'
MySFNFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: python3.8
InlineCode: |
def handler(event, context):
print(event)
return {'body': 'Hello World!', 'statusCode': 200}
MemorySize: 128
StateMachine:
Type: AWS::Serverless::StateMachine
Properties:
Type: STANDARD
Definition:
StartAt: MyLambdaState
States:
MyLambdaState:
Type: Task
Resource: !GetAtt MySFNFunction.Arn
End: true
Policies:
- LambdaInvokePolicy:
FunctionName: !Ref MySFNFunction
Events:
Schedule:
Type: ScheduleV2
Properties:
ScheduleExpression: rate(1 minute)
Input: '{"hello": "simple"}'
```
## En savoir plus
Pour en savoir plus sur la définition de la propriété `ScheduleV2` EventBridge Scheduler, voir :
+ [ScheduleV2](sam-property-function-schedulev2.md) pour `AWS::Serverless::Function`.
+ [ScheduleV2](sam-property-statemachine-statemachineschedulev2.md) pour `AWS::Serverless::StateMachine`.
# Orchestrer les AWS SAM ressources avec AWS Step Functions
Vous pouvez l'utiliser [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/)pour orchestrer des AWS Lambda fonctions et d'autres AWS ressources afin de créer des flux de travail complexes et robustes. Step Functions pour indiquer à votre application quand et dans quelles conditions vos AWS ressources, telles que AWS Lambda les fonctions, sont utilisées. Cela simplifie le processus de création de flux de travail complexes et robustes. À l'aide de[AWS::Serverless::StateMachine](sam-resource-statemachine.md), vous définissez les différentes étapes de votre flux de travail, associez des ressources à chaque étape, puis séquencez ces étapes ensemble. Vous ajoutez également des transitions et des conditions là où elles sont nécessaires. Cela simplifie le processus de création d'un flux de travail complexe et robuste.
**Note**
Pour gérer les AWS SAM modèles contenant des machines d'état Step Functions, vous devez utiliser la version 0.52.0 ou ultérieure du AWS SAMCLI. Pour vérifier la version dont vous disposez, exécutez la commande `sam --version`.
Step Functions repose sur les concepts de [tâches](https://docs.aws.amazon.com/step-functions/latest/dg/amazon-states-language-task-state.html) et de [machines d'état](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-states.html). Vous définissez les machines d'état à l'aide du [Langage des états Amazon](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-amazon-states-language.html) basé sur JSON. La [console Step Functions](https://console.aws.amazon.com/states/home?region=us-east-1#/) affiche une vue graphique de la structure de votre machine d'état, ce qui vous permet de vérifier visuellement la logique de votre machine d'état et de contrôler les exécutions.
Grâce à la prise en charge de Step Functions dans AWS Serverless Application Model (AWS SAM), vous pouvez effectuer les opérations suivantes :
+ Définissez des machines à états, soit directement dans un AWS SAM modèle, soit dans un fichier séparé
+ Créez des rôles d'exécution de machines à états via des modèles de AWS SAM politiques, des politiques intégrées ou des politiques gérées
+ Déclenchez des exécutions automatiques à l'aide d' EventBridge événements API Gateway ou Amazon, selon un calendrier défini dans un AWS SAM modèle ou en appelant APIs directement
+ Utiliser des [AWS SAM Modèles de stratégie](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-policy-templates.html) disponibles pour les modèles de développement courants Step Functions.
## Exemple
L'extrait d'un fichier AWS SAM modèle suivant définit une machine d'état Step Functions dans un fichier de définition. Remarque : le fichier `my_state_machine.asl.json` doit être écrit dans la [Langue des états Amazon](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-amazon-states-language.html).
```
AWSTemplateFormatVersion: "2010-09-09"
Transform: AWS::Serverless-2016-10-31
Description: Sample SAM template with Step Functions State Machine
Resources:
MyStateMachine:
Type: AWS::Serverless::StateMachine
Properties:
DefinitionUri: statemachine/my_state_machine.asl.json
...
```
Pour télécharger un exemple d' AWS SAM application qui inclut une machine d'état Step Functions, voir [Create a Step Functions State Machine Using AWS SAM](https://docs.aws.amazon.com/step-functions/latest/dg/tutorial-state-machine-using-sam.html) dans le *manuel du AWS Step Functions développeur*.
## En savoir plus
Pour en savoir plus sur Step Functions et son utilisation avec Step Functions AWS SAM, consultez les rubriques suivantes :
+ [Fonctionnement de AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/how-step-functions-works.html)
+ [AWS Step Functions et AWS Serverless Application Model](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-sam-sfn.html)
+ [Tutoriel : Création d'une machine à états Step Functions à l'aide de AWS SAM](https://docs.aws.amazon.com/step-functions/latest/dg/tutorial-state-machine-using-sam.html)
+ [AWS SAM Spécification : AWS::Serverless::StateMachine](sam-resource-statemachine.md)
# Configurer la signature de code pour votre AWS SAM application
Pour garantir que seul le code fiable est déployé, vous pouvez AWS SAM activer la signature de code avec vos applications sans serveur. La signature de votre code permet de garantir que le code n'a pas été modifié depuis la signature et que seuls les packages de code signés provenant d'éditeurs approuvés s'exécutent dans vos fonctions Lambda. Cela permet aux entreprises de se libérer de la charge de créer des composants de contrôle d'accès dans leurs pipelines de déploiement.
Pour plus d'informations sur la signature de code, consultez la [section Configuration de la signature de code pour les fonctions Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-codesigning.html) dans le Guide du *AWS Lambda développeur*.
Avant de configurer la signature de code pour votre application sans serveur, vous devez créer un profil de signature à l'aide de AWS Signer. Vous utiliserez ce profil de signature pour les tâches suivantes :
1. **Création d'une configuration de signature de code** – Déclarez une ressource [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-codesigningconfig.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-codesigningconfig.html) pour spécifier les profils de signature des éditeurs approuvés et définir l'action de stratégie pour les vérifications de validation. Vous pouvez déclarer cet objet dans le même AWS SAM modèle que votre fonction sans serveur, dans un autre AWS SAM modèle ou dans un CloudFormation modèle. Vous activez ensuite la signature de code pour une fonction sans serveur en spécifiant la propriété [https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html#sam-function-codesigningconfigarn](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html#sam-function-codesigningconfigarn) avec la fonction Amazon Resource Name (ARN) d'une ressource [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-codesigningconfig.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-codesigningconfig.html).
1. **Signature de votre code** – Utilisez la commande [https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-package.html](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-package.html) ou [https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-deploy.html](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-deploy.html) avec l'option `--signing-profiles`.
**Note**
Afin de signer avec succès votre code avec les commandes `sam package` ou `sam deploy`, la gestion des versions doit être activée pour le compartiment Amazon S3 que vous utilisez avec ces commandes. Si vous utilisez le compartiment Amazon S3 AWS SAM créé pour vous, le versionnement est activé automatiquement. Pour de plus amples informations sur la gestion des versions du compartiment Amazon S3 et des instructions sur l'activation de la gestion des versions sur un compartiment Amazon S3 que vous fournissez, consultez [Utilisation de la gestion des versions dans les compartiments Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html) dans le *Guide du emploi Amazon Simple Storage Service*.
Lorsque vous déployez une application sans serveur, Lambda effectue des vérifications de validation sur toutes les fonctions pour lesquelles vous avez activé la signature de code. Lambda effectue également des vérifications de validation sur toutes les couches dont ces fonctions dépendent. Pour de plus amples informations sur les vérifications de validation de Lambda, consultez [Validation de signature](https://docs.aws.amazon.com/lambda/latest/dg/configuration-codesigning.html#config-codesigning-valid) dans le *Guide du développeur AWS Lambda *.
## Exemple
### Création d'un profil de signature
Pour créer un profil de signature, exécutez la commande suivante :
```
aws signer put-signing-profile --platform-id "AWSLambda-SHA384-ECDSA" --profile-name MySigningProfile
```
Si la commande précédente réussit, vous voyez l'ARN du profil de signature renvoyé. Par exemple :
```
{
"arn": "arn:aws:signer:us-east-1:111122223333:/signing-profiles/MySigningProfile",
"profileVersion": "SAMPLEverx",
"profileVersionArn": "arn:aws:signer:us-east-1:111122223333:/signing-profiles/MySigningProfile/SAMPLEverx"
}
```
Le champ `profileVersionArn` contient l'ARN à utiliser lors de la création de la configuration de signature de code.
### Création d'une configuration de signature de code et activation de la signature de code pour une fonction
L'exemple de AWS SAM modèle suivant déclare une [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-codesigningconfig.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-codesigningconfig.html)ressource et active la signature de code pour une fonction Lambda. Dans cet exemple, il existe un profil approuvé et les déploiements sont rejetés si les vérifications de signature échouent.
```
Resources:
HelloWorld:
Type: AWS::Serverless::Function
Properties:
CodeUri: hello_world/
Handler: app.lambda_handler
Runtime: python3.7
CodeSigningConfigArn: !Ref MySignedFunctionCodeSigningConfig
MySignedFunctionCodeSigningConfig:
Type: AWS::Lambda::CodeSigningConfig
Properties:
Description: "Code Signing for MySignedLambdaFunction"
AllowedPublishers:
SigningProfileVersionArns:
- MySigningProfile-profileVersionArn
CodeSigningPolicies:
UntrustedArtifactOnDeployment: "Enforce"
```
### Signature de votre code
Vous pouvez signer votre code lors de l'empaquetage ou du déploiement de votre application. Spécifiez l'option `--signing-profiles` avec la commande `sam package` ou `sam deploy`, comme illustré dans l'exemple de commandes suivant.
Signer votre code de fonction lors de l'empaquetage de votre application :
```
sam package --signing-profiles HelloWorld=MySigningProfile --s3-bucket amzn-s3-demo-bucket --output-template-file packaged.yaml
```
Signer à la fois votre code de fonction et une couche dont votre fonction dépend, lors de l'empaquetage de votre application :
```
sam package --signing-profiles HelloWorld=MySigningProfile MyLayer=MySigningProfile --s3-bucket amzn-s3-demo-bucket --output-template-file packaged.yaml
```
Signer votre code de fonction et une couche, puis effectuer un déploiement :
```
sam deploy --signing-profiles HelloWorld=MySigningProfile MyLayer=MySigningProfile --s3-bucket amzn-s3-demo-bucket --template-file packaged.yaml --stack-name --region us-east-1 --capabilities CAPABILITY_IAM
```
**Note**
Afin de signer avec succès votre code avec les commandes `sam package` ou `sam deploy`, la gestion des versions doit être activée pour le compartiment Amazon S3 que vous utilisez avec ces commandes. Si vous utilisez le compartiment Amazon S3 AWS SAM créé pour vous, le versionnement est activé automatiquement. Pour de plus amples informations sur la gestion des versions du compartiment Amazon S3 et des instructions sur l'activation de la gestion des versions sur un compartiment Amazon S3 que vous fournissez, consultez [Utilisation de la gestion des versions dans les compartiments Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html) dans le *Guide du emploi Amazon Simple Storage Service*.
## Fournir des profils de signature avec `sam deploy --guided`
Lorsque vous exécutez la `sam deploy --guided` commande avec une application sans serveur configurée avec la signature de code, elle vous AWS SAM invite à fournir le profil de signature à utiliser pour la signature de code. Pour plus d'informations sur les invites `sam deploy --guided`, consultez [sam deploy](sam-cli-command-reference-sam-deploy.md) dans la référence des commandes de la CLI AWS SAM.
# Valider les fichiers AWS SAM modèles
Validez vos modèles avec `sam validate`. Actuellement, cette commande valide le fait que le modèle fourni est un JSON/YAML valide. Comme avec la plupart des commandes CLI AWS SAM, elle recherche un fichier `template.[yaml|yml]` par défaut dans votre répertoire de travail actuel. Vous pouvez spécifier un autre modèle à l' file/location aide de l'`--template`option `-t` ou.
Exemple :
```
$ sam validate
/template.yaml is a valid SAM Template
```
**Note**
La `sam validate` commande nécessite la configuration des AWS informations d'identification. Pour de plus amples informations, veuillez consulter [Configuration de la CLI AWS SAM](using-sam-cli-configure.md).
# Créez votre application avec AWS SAM
Après avoir ajouté votre infrastructure sous forme de code (iAc) à votre AWS SAM modèle, vous serez prêt à commencer à créer votre application à l'aide de la **sam build** commande. Cette commande crée des artefacts de construction à partir des fichiers du répertoire de votre projet d'application (c'est-à-dire votre fichier AWS SAM modèle, le code de l'application et tous les fichiers et dépendances spécifiques au langage applicable). Ces artefacts de build préparent votre application sans serveur pour les étapes ultérieures du développement de votre application, telles que les tests locaux et le déploiement AWS dans le cloud. Les tests et le déploiement utilisent des artefacts de construction comme entrées.
Vous pouvez l'utiliser **sam build** pour créer l'intégralité de votre application sans serveur. En outre, vous pouvez créer des versions personnalisées, par exemple des versions avec des fonctions, des couches ou des environnements d'exécution personnalisés spécifiques. Pour en savoir plus sur comment et pourquoi vous l'utilisez**sam build**, consultez les rubriques de cette section. Pour une introduction à l'utilisation de la commande `sam build`, consultez [Initiation à la construction avec AWS SAM](using-sam-cli-build.md).
**Topics**
+ [Initiation à la construction avec AWS SAM](using-sam-cli-build.md)
+ [Construit par défaut avec AWS SAM](serverless-sam-cli-using-build.md)
+ [Personnalisez les builds avec AWS SAM](building-lambda-functions.md)
# Initiation à la construction avec AWS SAM
Utilisez la AWS Serverless Application Model commande Command Line Interface (AWS SAMCLI) `sam build` pour préparer votre application sans serveur aux étapes suivantes de votre flux de travail de développement, telles que les tests locaux ou le déploiement sur le AWS Cloud. Cette commande crée un répertoire `.aws-sam` qui structure votre application dans un format et un emplacement que `sam local` et `sam deploy` nécessitent.
+ Pour une introduction à la AWS SAMCLI, voir[Qu'est-ce que c'est AWS SAMCLI ?](what-is-sam-overview.md#what-is-sam-cli).
+ Pour obtenir la liste des options de commande `sam build`, consultez [sam build](sam-cli-command-reference-sam-build.md).
+ Pour un exemple d'utilisation de `sam build` dans le cadre d'un flux de travail de développement classique, consultez [Étape 2 : créer votre application](serverless-getting-started-hello-world.md#serverless-getting-started-hello-world-build).
**Note**
L'utilisation de `sam build` nécessite que vous commenciez avec les composants de base d'une application sans serveur sur votre machine de développement. Cela inclut un AWS SAM modèle, un code de AWS Lambda fonction, ainsi que tous les fichiers et dépendances spécifiques au langage. Pour en savoir plus, veuillez consulter la section [Créez votre application dans AWS SAM](using-sam-cli-init.md).
**Topics**
+ [Création d'applications avec sam build](#using-sam-cli-build-apps)
+ [Test et déploiement au niveau local](#using-sam-cli-build-test-deploy)
+ [Bonnes pratiques](#using-sam-cli-build-best)
+ [Options pour sam build](#using-sam-cli-build-options)
+ [Résolution des problèmes](#using-sam-cli-build-troubleshooting)
+ [Exemples](#using-sam-cli-build-examples)
+ [En savoir plus](#using-sam-cli-build-learn)
## Création d'applications avec sam build
Avant de l'utiliser`sam build`, pensez à configurer les éléments suivants :
1. **Fonctions et couches Lambda** : la commande `sam build` permet de créer des fonctions et des couches Lambda. Pour en savoir plus sur les couches Lambda, consultez [Création de couches Lambda dans AWS SAM](building-layers.md).
1. **Exécution Lambda** : l'*exécution* fournit un environnement spécifique au langage qui exécute votre fonction dans un environnement d'exécution lorsqu'elle est invoquée. Vous pouvez configurer des environnements d'exécution natifs et personnalisés.
1. **Exécution native** : créez vos fonctions Lambda dans une exécution Lambda prise en charge et créez vos fonctions pour utiliser une exécution Lambda native dans le AWS Cloud.
1. **Exécution personnalisée** : créez vos fonctions Lambda à l'aide de n'importe quel langage de programmation et créez votre exécution à l'aide d'un processus personnalisé défini dans un makefile ou dans un créateur tiers tel que esbuild. Pour en savoir plus, veuillez consulter la section [Création de fonctions Lambda avec des environnements d'exécution personnalisés dans AWS SAM](building-custom-runtimes.md).
1. **Type de package Lambda** : les fonctions Lambda peuvent être packagées dans les types de packages de déploiement Lambda suivants :
1. **.zip file archive** : contient le code de votre application et ses dépendances.
1. **Image du conteneur** : contient le système d'exploitation de base, l'exécution, les extensions Lambda, le code de votre application et ses dépendances.
Ces paramètres d'application peuvent être configurés lors de l'initialisation d'une application à l'aide de `sam init`.
+ Pour en savoir plus sur l'utilisation de `sam init`, consultez [Créez votre application dans AWS SAM](using-sam-cli-init.md).
+ Pour en savoir plus sur la configuration de ces paramètres dans votre application, consultez [Construit par défaut avec AWS SAM](serverless-sam-cli-using-build.md).
**Pour créer une application**
1. `cd` à la racine de votre projet. Il s'agit du même emplacement que celui de votre AWS SAM modèle.
```
$ cd sam-app
```
1. Exécutez les commandes suivantes :
```
sam-app $ sam build
```
**Note**
Une option couramment utilisée est `--use-container`. Pour en savoir plus, veuillez consulter la section [Création d'une fonction Lambda à l'intérieur d'un conteneur fourni](#using-sam-cli-build-options-container).
Voici un exemple de réponse générée par la CLI AWS SAM :
```
sam-app $ sam build
Starting Build use cache
Manifest file is changed (new hash: 3298f1304...d4d421) or dependency folder (.aws-sam/deps/4d3dfad6-a267-47a6-a6cd-e07d6fae318c) is missing for (HelloWorldFunction), downloading dependencies and copying/building source
Building codeuri: /Users/.../sam-app/hello_world runtime: python3.12 metadata: {} architecture: x86_64 functions: HelloWorldFunction
Running PythonPipBuilder:CleanUp
Running PythonPipBuilder:ResolveDependencies
Running PythonPipBuilder:CopySource
Running PythonPipBuilder:CopySource
Build Succeeded
Built Artifacts : .aws-sam/build
Built Template : .aws-sam/build/template.yaml
Commands you can use next
=========================
[*] Validate SAM template: sam validate
[*] Invoke Function: sam local invoke
[*] Test Function in the Cloud: sam sync --stack-name {{stack-name}} --watch
[*] Deploy: sam deploy --guided
```
1. La CLI AWS SAM crée un répertoire de création `.aws-sam`. Voici un exemple :
```
.aws-sam
├── build
│ ├── HelloWorldFunction
│ │ ├── __init__.py
│ │ ├── app.py
│ │ └── requirements.txt
│ └── template.yaml
└── build.toml
```
En fonction de la configuration de votre application, la CLI AWS SAM effectue les opérations suivantes :
1. Elle télécharge, installe et organise les dépendances dans le répertoire `.aws-sam/build`.
1. Elle prépare votre code Lambda. Il peut s'agir de compiler votre code, de créer des fichiers binaires exécutables et de créer des images de conteneurs.
1. Elle copie les artefacts de création dans le répertoire `.aws-sam`. Le format varie en fonction du type du package de l'application.
1. Pour les types de packages .zip, les artefacts ne sont pas encore compressés afin de pouvoir être utilisés pour des tests locaux. La CLI AWS SAM compresse votre application lorsqu'elle utilise `sam deploy`.
1. Pour les types de packages d'images de conteneurs, une image de conteneur est créée localement et référencée dans le fichier `.aws-sam/build.toml`.
1. Copie le AWS SAM modèle `.aws-sam` dans le répertoire et le modifie avec de nouveaux chemins de fichiers si nécessaire.
Les principaux composants qui constituent vos artefacts de création dans le répertoire `.aws-sam` sont les suivants :
+ **Le répertoire de création** : contient vos fonctions et couches Lambda structurées indépendamment les unes des autres. La structure est donc unique pour chaque fonction ou couche du répertoire `.aws-sam/build`.
+ **Le AWS SAM modèle** : modifié avec des valeurs mises à jour en fonction des modifications apportées au cours du processus de création.
+ **Le fichier build.toml : fichier** de configuration contenant les paramètres de construction utilisés par le. AWS SAMCLI
## Test et déploiement au niveau local
Lorsque vous effectuez des tests locaux avec `sam local` ou un déploiement avec `sam deploy`, la CLI AWS SAM effectue les opérations suivantes :
1. Il vérifie d'abord si un `.aws-sam` répertoire existe et si un AWS SAM modèle se trouve dans ce répertoire. Si ces conditions sont remplies, la CLI AWS SAM considère qu'il s'agit du répertoire racine de votre application.
1. Si ces conditions ne sont pas remplies, l' AWS SAMCLIemplacement d'origine de votre AWS SAM modèle est considéré comme le répertoire racine de votre application.
Lors du développement, si des modifications sont apportées à vos fichiers d'application originaux, exécutez `sam build` pour mettre à jour le répertoire `.aws-sam` avant de tester localement.
## Bonnes pratiques
+ Ne modifiez aucun code dans le répertoire `.aws-sam/build`. Mettez plutôt à jour votre code source original dans le dossier de votre projet et exécutez `sam build` pour mettre à jour le répertoire `.aws-sam/build`.
+ Lorsque vous modifiez vos fichiers originaux, exécutez `sam build` pour mettre à jour le répertoire `.aws-sam/build`.
+ Il se peut que vous souhaitiez que la CLI AWS SAM fasse référence au répertoire racine d'origine de votre projet plutôt qu'au répertoire `.aws-sam`, par exemple lors du développement et des tests avec `sam local`. Supprimez le `.aws-sam` répertoire ou le AWS SAM modèle dans le `.aws-sam` répertoire pour que le répertoire de votre projet d'origine soit AWS SAMCLI reconnu comme le répertoire racine du projet. Lorsque vous êtes prêt, exécutez à nouveau `sam build` pour créer le répertoire `.aws-sam`.
+ Lorsque vous exécutez `sam build`, le répertoire `.aws-sam/build` est remplacé à chaque fois. Le répertoire `.aws-sam` ne l'est pas. Si vous souhaitez stocker des fichiers, tels que des journaux, stockez-les dans `.aws-sam` pour éviter qu'ils ne soient remplacés.
## Options pour sam build
### Création d'une seule ressource
Fournissez l'ID logique de la ressource pour ne créer que cette ressource. Voici un exemple :
```
$ sam build HelloWorldFunction
```
Pour créer une ressource d'une application ou d'une pile imbriquée, fournissez l'identifiant logique de l'application ou de la pile avec l'identifiant logique de la ressource en utilisant le format `/` :
```
$ sam build MyNestedStack/MyFunction
```
### Création d'une fonction Lambda à l'intérieur d'un conteneur fourni
L'option `--use-container` télécharge une image de conteneur et l'utilise pour créer vos fonctions Lambda. Le conteneur local est ensuite référencé dans votre fichier `.aws-sam/build.toml`.
Cette option nécessite que Docker soit installé. Pour obtenir des instructions, veuillez consulter [Installation de Docker](install-docker.md).
Voici un exemple de cette commande :
```
$ sam build --use-container
```
Vous pouvez spécifier l'image de conteneur à utiliser avec l'option `--build-image`. Voici un exemple :
```
$ sam build --use-container --build-image amazon/aws-sam-cli-build-image-nodejs20.x
```
Pour spécifier l'image du conteneur à utiliser pour une seule fonction, fournissez l'ID logique de la fonction. Voici un exemple :
```
$ sam build --use-container --build-image Function1=amazon/aws-sam-cli-build-image-python3.12
```
### Transmettre des variables d'environnement au conteneur de création
Utilisez `--container-env-var` pour transmettre les variables d'environnement au conteneur de création. Voici un exemple :
```
$ sam build --use-container --container-env-var Function1.GITHUB_TOKEN= --container-env-var GLOBAL_ENV_VAR=
```
Pour transmettre des variables d'environnement à partir d'un fichier, utilisez l'option `--container-env-var-file`. Voici un exemple :
```
$ sam build --use-container --container-env-var-file
```
Exemple de fichier `env.json` :
```
{
"MyFunction1": {
"GITHUB_TOKEN": "TOKEN1"
},
"MyFunction2": {
"GITHUB_TOKEN": "TOKEN2"
}
}
```
### Accélérez la création d'applications contenant plusieurs fonctions
Lorsque vous exécutez `sam build` sur une application comportant plusieurs fonctions, la CLI AWS SAM crée chaque fonction une par une. Pour accélérer le processus de création, utilisez l'option `--parallel`. Cela crée toutes les fonctions et couches en même temps.
Voici un exemple de cette commande :
```
$ sam build —-parallel
```
### Accélérez les temps de création en créant votre projet dans le dossier source
Pour les systèmes d'exécution et les méthodes de création pris en charge, vous pouvez utiliser l'option `--build-in-source` permettant de créer votre projet directement dans le dossier source. Par défaut, il est AWS SAM CLI compilé dans un répertoire temporaire, ce qui implique de copier le code source et les fichiers de projet. Avec`--build-in-source`, les AWS SAM CLI builds se trouvent directement dans votre dossier source, ce qui accélère le processus de compilation en supprimant le besoin de copier des fichiers dans un répertoire temporaire.
Pour obtenir une liste des systèmes d’exécution ainsi que des méthodes de création pris en charge, consultez `--build-in-source`.
## Résolution des problèmes
Pour résoudre le problème AWS SAMCLI, voir[Résolution des problèmes de la CLI AWS SAM](sam-cli-troubleshooting.md).
## Exemples
### Création d'une application utilisant une exécution native et un type de package .zip
Pour cet exemple, consultez [Tutoriel : Déployer une application Hello World avec AWS SAM](serverless-getting-started-hello-world.md).
### Création d'une application utilisant une exécution native et un type de package d'images
Tout d'abord, nous exécutons `sam init` pour initialiser une nouvelle application. Au cours du flux interactif, nous sélectionnons le type de package `Image`. Voici un exemple :
```
$ sam init
...
Which template source would you like to use?
1 - AWS Quick Start Templates
2 - Custom Template Location
Choice: 1
Choose an AWS Quick Start application template
1 - Hello World Example
2 - Multi-step workflow
3 - Serverless API
4 - Scheduled task
5 - Standalone function
6 - Data processing
7 - Hello World Example With Powertools
8 - Infrastructure event management
9 - Serverless Connector Hello World Example
10 - Multi-step workflow with Connectors
11 - Lambda EFS example
12 - DynamoDB Example
13 - Machine Learning
Template: 1
Use the most popular runtime and package type? (Python and zip) [y/N]: ENTER
Which runtime would you like to use?
...
10 - java8
11 - nodejs20.x
12 - nodejs18.x
13 - nodejs16.x
...
Runtime: 12
What package type would you like to use?
1 - Zip
2 - Image
Package type: 2
Based on your selections, the only dependency manager available is npm.
We will proceed copying the template using npm.
Would you like to enable X-Ray tracing on the function(s) in your application? [y/N]: ENTER
Would you like to enable monitoring using CloudWatch Application Insights?
For more info, please view https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-application-insights.html [y/N]: ENTER
Project name [sam-app]: ENTER
Cloning from https://github.com/aws/aws-sam-cli-app-templates (process may take a moment)
-----------------------
Generating application:
-----------------------
Name: sam-app
Base Image: amazon/nodejs18.x-base
Architectures: x86_64
Dependency Manager: npm
Output Directory: .
Configuration file: sam-app/samconfig.toml
Next steps can be found in the README file at sam-app/README.md
...
```
AWS SAMCLIInitialise une application et crée le répertoire de projet suivant :
```
sam-app
├── README.md
├── events
│ └── event.json
├── hello-world
│ ├── Dockerfile
│ ├── app.mjs
│ ├── package.json
│ └── tests
│ └── unit
│ └── test-handler.mjs
├── samconfig.toml
└── template.yaml
```
Ensuite, nous exécutons `sam build` pour créer notre application :
```
sam-app $ sam build
Building codeuri: /Users/.../build-demo/sam-app runtime: None metadata: {'DockerTag': 'nodejs18.x-v1', 'DockerContext': '/Users/.../build-demo/sam-app/hello-world', 'Dockerfile': 'Dockerfile'} architecture: arm64 functions: HelloWorldFunction
Building image for HelloWorldFunction function
Setting DockerBuildArgs: {} for HelloWorldFunction function
Step 1/4 : FROM public.ecr.aws/lambda/nodejs:18
---> f5b68038c080
Step 2/4 : COPY app.mjs package*.json ./
---> Using cache
---> 834e565aae80
Step 3/4 : RUN npm install
---> Using cache
---> 31c2209dd7b5
Step 4/4 : CMD ["app.lambdaHandler"]
---> Using cache
---> 2ce2a438e89d
Successfully built 2ce2a438e89d
Successfully tagged helloworldfunction:nodejs18.x-v1
Build Succeeded
Built Artifacts : .aws-sam/build
Built Template : .aws-sam/build/template.yaml
Commands you can use next
=========================
[*] Validate SAM template: sam validate
[*] Invoke Function: sam local invoke
[*] Test Function in the Cloud: sam sync --stack-name {{stack-name}} --watch
[*] Deploy: sam deploy --guided
```
### Création d'une application qui inclut un langage de programmation compilé
Dans cet exemple, nous créons une application contenant une fonction Lambda à l'aide de l'exécution Go.
Tout d'abord, nous initialisons une nouvelle application en utilisant `sam init` et configurons notre application pour qu'elle utilise Go :
```
$ sam init
...
Which template source would you like to use?
1 - AWS Quick Start Templates
2 - Custom Template Location
Choice: 1
Choose an AWS Quick Start application template
1 - Hello World Example
2 - Multi-step workflow
3 - Serverless API
...
Template: 1
Use the most popular runtime and package type? (Python and zip) [y/N]: ENTER
Which runtime would you like to use?
...
4 - dotnetcore3.1
5 - go1.x
6 - go (provided.al2)
...
Runtime: 5
What package type would you like to use?
1 - Zip
2 - Image
Package type: 1
Based on your selections, the only dependency manager available is mod.
We will proceed copying the template using mod.
Would you like to enable X-Ray tracing on the function(s) in your application? [y/N]: ENTER
Would you like to enable monitoring using CloudWatch Application Insights?
For more info, please view https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-application-insights.html [y/N]: ENTER
Project name [sam-app]: ENTER
Cloning from https://github.com/aws/aws-sam-cli-app-templates (process may take a moment)
-----------------------
Generating application:
-----------------------
Name: sam-app
Runtime: go1.x
Architectures: x86_64
Dependency Manager: mod
Application Template: hello-world
Output Directory: .
Configuration file: sam-app/samconfig.toml
Next steps can be found in the README file at sam-app-go/README.md
...
```
AWS SAMCLIInitialise ensuite l'application. Voici un exemple de la structure du répertoire de l'application :
```
sam-app
├── Makefile
├── README.md
├── events
│ └── event.json
├── hello-world
│ ├── go.mod
│ ├── go.sum
│ ├── main.go
│ └── main_test.go
├── samconfig.toml
└── template.yaml
```
Nous référençons le fichier `README.md` pour les exigences de cette application.
```
...
## Requirements
* AWS CLI already configured with Administrator permission
* [Docker installed](https://www.docker.com/community-edition)
* [Golang](https://golang.org)
* SAM CLI - [Install the SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html)
...
```
Ensuite, nous exécutons `sam local invoke` pour tester notre fonction. Cette commande provoque une erreur, car Go n'est pas installé sur notre machine locale :
```
sam-app $ sam local invoke
Invoking hello-world (go1.x)
Local image was not found.
Removing rapid images for repo public.ecr.aws/sam/emulation-go1.x
Building image.................................................................................................................................................................................................................................................
Using local image: public.ecr.aws/lambda/go:1-rapid-x86_64.
Mounting /Users/.../Playground/build/sam-app/hello-world as /var/task:ro,delegated inside runtime container
START RequestId: c6c5eddf-042b-4e1e-ba66-745f7c86dd31 Version: $LATEST
fork/exec /var/task/hello-world: no such file or directory: PathError
null
END RequestId: c6c5eddf-042b-4e1e-ba66-745f7c86dd31
REPORT RequestId: c6c5eddf-042b-4e1e-ba66-745f7c86dd31 Init Duration: 0.88 ms Duration: 175.75 ms Billed Duration: 176 ms Memory Size: 128 MB Max Memory Used: 128 MB
{"errorMessage":"fork/exec /var/task/hello-world: no such file or directory","errorType":"PathError"}%
```
Ensuite, nous exécutons `sam build` pour créer notre application. Nous rencontrons une erreur car Go n'est pas installée sur notre machine locale :
```
sam-app $ sam build
Starting Build use cache
Cache is invalid, running build and copying resources for following functions (HelloWorldFunction)
Building codeuri: /Users/.../Playground/build/sam-app/hello-world runtime: go1.x metadata: {} architecture: x86_64 functions: HelloWorldFunction
Build Failed
Error: GoModulesBuilder:Resolver - Path resolution for runtime: go1.x of binary: go was not successful
```
Bien que nous puissions configurer notre machine locale pour créer correctement notre fonction, nous utilisons plutôt l'option `--use-container` avec `sam build`. AWS SAMCLITélécharge une image de conteneur, construit notre fonction en utilisant le natif GoModulesBuilder et copie le binaire obtenu `.aws-sam/build/HelloWorldFunction` dans notre répertoire.
```
sam-app $ sam build --use-container
Starting Build use cache
Starting Build inside a container
Cache is invalid, running build and copying resources for following functions (HelloWorldFunction)
Building codeuri: /Users/.../build/sam-app/hello-world runtime: go1.x metadata: {} architecture: x86_64 functions: HelloWorldFunction
Fetching public.ecr.aws/sam/build-go1.x:latest-x86_64 Docker container image.....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Mounting /Users/.../build/sam-app/hello-world as /tmp/samcli/source:ro,delegated inside runtime container
Running GoModulesBuilder:Build
Build Succeeded
Built Artifacts : .aws-sam/build
Built Template : .aws-sam/build/template.yaml
Commands you can use next
=========================
[*] Validate SAM template: sam validate
[*] Invoke Function: sam local invoke
[*] Test Function in the Cloud: sam sync --stack-name {{stack-name}} --watch
[*] Deploy: sam deploy --guided
```
Voici un exemple du répertoire `.aws-sam` :
```
.aws-sam
├── build
│ ├── HelloWorldFunction
│ │ └── hello-world
│ └── template.yaml
├── build.toml
├── cache
│ └── c860d011-4147-4010-addb-2eaa289f4d95
│ └── hello-world
└── deps
```
Ensuite, nous exécutons `sam local invoke`. Notre fonction est appelée avec succès :
```
sam-app $ sam local invoke
Invoking hello-world (go1.x)
Local image is up-to-date
Using local image: public.ecr.aws/lambda/go:1-rapid-x86_64.
Mounting /Users/.../Playground/build/sam-app/.aws-sam/build/HelloWorldFunction as /var/task:ro,delegated inside runtime container
START RequestId: cfc8ffa8-29f2-49d4-b461-45e8c7c80479 Version: $LATEST
END RequestId: cfc8ffa8-29f2-49d4-b461-45e8c7c80479
REPORT RequestId: cfc8ffa8-29f2-49d4-b461-45e8c7c80479 Init Duration: 1.20 ms Duration: 1782.46 ms Billed Duration: 1783 ms Memory Size: 128 MB Max Memory Used: 128 MB
{"statusCode":200,"headers":null,"multiValueHeaders":null,"body":"Hello, 72.21.198.67\n"}%
```
## En savoir plus
Pour en savoir plus sur l'utilisation de la commande `sam build`, reportez-vous à ce qui suit :
+ **[Learning AWS SAM : sam build](https://www.youtube.com/watch?v=fDhYKp4op_g)** — Série « Learning AWS SAM » de Serverless Land surYouTube.
+ **[Learning AWS SAM \$1 sam build \$1 E3](https://www.youtube.com/watch?v=vsAvRyLnB7Y)** — Serverless Land « Learning AWS SAM » série surYouTube.
+ **[AWS SAM build : comment il fournit des artefacts pour le déploiement (sessions avec SAM S2E8)](https://www.youtube.com/watch?v=bNbBd6XoDHg)** — Sessions avec AWS SAM série activée. YouTube
+ **[AWS SAM versions personnalisées : Comment utiliser les Makefiles pour personnaliser les versions dans SAM (S2E9) — Sessions](https://www.youtube.com/watch?v=wpccutnSbAk)** avec séries activées. AWS SAM YouTube
# Construit par défaut avec AWS SAM
Pour créer votre application sans serveur, utilisez la commande `sam build`. Cette commande rassemble également les artefacts de construction des dépendances de votre application et les place dans le format et l'emplacement appropriés pour les prochaines étapes, telles que les tests locaux, l'empaquetage et le déploiement.
Vous spécifiez les dépendances de votre application dans un fichier manifeste, tel que `requirements.txt` (Python) ou `package.json` (Node.js), ou à l'aide de la propriété `Layers` d'une ressource de fonction. La propriété `Layers` contient une liste de ressources de [couche AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) dont dépend la fonction Lambda.
Le format des artefacts de construction de votre application dépend de la propriété `PackageType` de chaque fonction. Les options pour cette propriété sont :
+ **`Zip`** – Une archive de fichiers .zip, comportant le code de votre application et ses dépendances. Si vous empaquetez le code sous la forme d’une archive de fichiers .zip, vous devez spécifier une exécution Lambda pour la fonction.
+ **`Image`** : une image de conteneur incluant le système d’exploitation de base, l’exécution et les extensions, en plus du code de l’application et ses dépendances.
Pour de plus amples informations sur les types de packages Lambda, consultez [Packages de déploiement Lambda](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-package.html) dans le *Guide du développeur AWS Lambda *.
**Topics**
+ [Création d'une archive de fichier .zip](#build-zip-archive)
+ [Création d'une image de conteneur](#build-container-image)
+ [Fichier de variables d'environnement du conteneur.](#serverless-sam-cli-using-container-environment-file)
+ [Accélérez les temps de création en créant votre projet dans le dossier source](#serverless-sam-cli-using-build-in-source)
+ [Exemples](#building-applications-examples)
+ [Fonctions du bâtiment en dehors de AWS SAM](#building-applications-skip)
## Création d'une archive de fichier .zip
Pour créer votre application sans serveur en tant qu'archive de fichier .zip, déclarez `PackageType: Zip` pour votre fonction sans serveur.
AWS SAM construit votre application pour l'[architecture](sam-resource-function.md#sam-function-architectures) que vous spécifiez. Si vous ne spécifiez pas d'architecture, AWS SAM utilise `x86_64` par défaut.
Si votre fonction Lambda dépend de packages qui ont compilé nativement des programmes, utilisez l'indicateur `--use-container`. Cet indicateur compile localement vos fonctions dans un conteneur qui se comporte comme un environnement Lambda, afin qu'elles soient au bon format lorsque vous les déployez dans le Cloud. AWS
Lorsque vous utilisez `--use-container` cette option, l'image du conteneur AWS SAM est extraite par défaut d'[Amazon ECR Public.](https://docs.aws.amazon.com/AmazonECR/latest/public/what-is-ecr.html) Si vous souhaitez extraire une image de conteneur d'un autre référentiel ou pour une version spécifique de AWS SAM CLI, vous pouvez utiliser l'`--build-image`option et fournir l'URI d'une autre image de conteneur. Voici deux exemples de commandes permettant de créer des applications à l'aide d'images de conteneur issues d'une version spécifique de la AWS SAM CLI :
```
# Build a Node.js 20 application using a container image for a specific version of AWS SAM CLI (1.136.0)
sam build --use-container --build-image public.ecr.aws/sam/build-nodejs22.x:1.136.0
# Build a function resource using the Python 3.13 container image from a specific version of AWS SAM CLI (1.136.0)(
sam build --use-container --build-image Function1=public.ecr.aws/sam/build-python3.13:1.136.0
```
Pour obtenir d'autres exemples de création d'une application d'archivage de fichiers .zip, reportez-vous à la section Exemples plus loin dans cette rubrique.
## Création d'une image de conteneur
Pour créer votre application sans serveur en tant qu'image de conteneur, déclarez `PackageType: Image` pour votre fonction sans serveur. Vous devez également déclarer l'attribut de ressource `Metadata` avec les entrées suivantes :
`Dockerfile`
Nom du Dockerfile associé à la fonction Lambda.
`DockerContext`
Emplacement du fichier journal.
`DockerTag`
(Facultatif) Balise à appliquer à l'image créée.
`DockerBuildArgs`
Arguments de construction pour la création.
Le AWS SAMCLI ne supprime ni ne masque les informations que vous incluez dans les arguments. `DockerBuildArgs` Nous vous recommandons vivement de ne pas utiliser cette section pour stocker des informations sensibles, telles que des mots de passe ou des secrets.
Voici un exemple de section d'attribut de ressource `Metadata` :
```
Metadata:
Dockerfile: Dockerfile
DockerContext: ./hello_world
DockerTag: v1
```
Pour télécharger un exemple d'application configuré avec le type de `Image` package, consultez[Tutoriel : Déployer une application Hello World avec AWS SAM](serverless-getting-started-hello-world.md). En réponse à l'invite demandant quel type de package vous souhaitez installer, choisissez `Image`.
**Note**
Si vous spécifiez une image de base multi-architecture dans votre Dockerfile, AWS SAM crée votre image de conteneur pour l'architecture de votre machine hôte. Pour créer une architecture différente, spécifiez une image de base qui utilise l'architecture cible spécifique.
## Fichier de variables d'environnement du conteneur.
Pour fournir un fichier JSON qui contient des variables d'environnement pour le conteneur de construction, utilisez l'argument `--container-env-var-file` avec la commande `sam build`. Vous pouvez fournir une variable d'environnement unique qui s'applique à toutes les ressources sans serveur, ou des variables d'environnement différentes pour chaque ressource.
### Format
Le format de transmission des variables d'environnement à un conteneur de construction dépend du nombre de variables d'environnement que vous fournissez pour vos ressources.
Pour fournir une variable d'environnement unique pour toutes les ressources, spécifiez un objet `Parameters` se présentant comme suit :
```
{
"Parameters": {
"GITHUB_TOKEN": "TOKEN_GLOBAL"
}
}
```
Pour fournir différentes variables d'environnement pour chaque ressource, spécifiez des objets pour chaque ressource comme suit :
```
{
"MyFunction1": {
"GITHUB_TOKEN": "TOKEN1"
},
"MyFunction2": {
"GITHUB_TOKEN": "TOKEN2"
}
}
```
Enregistrez vos variables d'environnement en tant que fichier, par exemple nommé `env.json`. La commande suivante utilise ce fichier pour transmettre vos variables d'environnement au conteneur de construction :
```
sam build --use-container --container-env-var-file env.json
```
### Priorité
+ Les variables d'environnement que vous fournissez pour des ressources spécifiques seront prioritaires sur la variable d'environnement unique pour toutes les ressources.
+ Les variables d'environnement que vous fournissez sur la ligne de commande seront prioritaires sur les variables d'environnement d'un fichier.
## Accélérez les temps de création en créant votre projet dans le dossier source
Pour les systèmes d'exécution et les méthodes de création pris en charge, vous pouvez utiliser l'option `--build-in-source` permettant de créer votre projet directement dans le dossier source. Par défaut, il est AWS SAM CLI compilé dans un répertoire temporaire, ce qui implique de copier le code source et les fichiers de projet. Avec`--build-in-source`, les AWS SAM CLI builds se trouvent directement dans votre dossier source, ce qui accélère le processus de compilation en supprimant le besoin de copier des fichiers dans un répertoire temporaire.
Pour obtenir une liste des systèmes d’exécution ainsi que des méthodes de création pris en charge, consultez `--build-in-source`.
## Exemples
### Exemple 1 : archive de fichier .zip
Les commandes `sam build` suivantes créent une archive de fichier .zip :
```
# Build all functions and layers, and their dependencies
sam build
# Run the build process inside a Docker container that functions like a Lambda environment
sam build --use-container
# Build a Node.js 20 application using a container image for a specific version of AWS SAM CLI (1.136.0)
sam build --use-container --build-image public.ecr.aws/sam/build-nodejs22.x:1.136.0
# Build a function resource using the Python 3.13 container image from a specific version of AWS SAM CLI (1.136.0)(
sam build --use-container --build-image Function1=public.ecr.aws/sam/build-python3.13:1.136.0
# Build and run your functions locally
sam build && sam local invoke
# For more options
sam build --help
```
### Exemple 2 : image de conteneur
Le AWS SAM modèle suivant est créé sous forme d'image de conteneur :
```
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Properties:
PackageType: Image
ImageConfig:
Command: ["app.lambda_handler"]
Metadata:
Dockerfile: Dockerfile
DockerContext: ./hello_world
DockerTag: v1
```
Voici un exemple de Dockerfile :
```
FROM public.ecr.aws/lambda/python:3.12
COPY app.py requirements.txt ./
RUN python3.12 -m pip install -r requirements.txt
# Overwrite the command by providing a different command directly in the template.
CMD ["app.lambda_handler"]
```
### Exemple 3 : npm ci
Pour les applications Node.js, vous pouvez utiliser `npm ci` au lieu de `npm install` pour installer les dépendances. Pour utiliser `npm ci`, spécifiez `UseNpmCi: True` sous `BuildProperties` dans votre attribut de ressource `Metadata` de la fonction Lambda. Pour utiliser `npm ci`, votre application doit disposer d'un fichier `package-lock.json` ou `npm-shrinkwrap.json` présent dans le `CodeUri`pour votre fonction Lambda.
L'exemple suivant utilise `npm ci` pour installer des dépendances lorsque vous exécutez `sam build` :
```
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: hello-world/
Handler: app.handler
Runtime: nodejs20.x
Architectures:
- x86_64
Events:
HelloWorld:
Type: Api
Properties:
Path: /hello
Method: get
Metadata:
BuildProperties:
UseNpmCi: True
```
### Paquets parents Python
Pour les applications Python, vous pouvez conserver la structure de votre package pendant le processus de construction afin de permettre des importations absolues. Pour préserver la structure du package, spécifiez `ParentPackageMode` under `BuildProperties` dans l'attribut de `Metadata` ressource de votre fonction Lambda.
L'exemple suivant préserve la structure `app` du package lorsque vous exécutez `sam build` :
```
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: hello-world/
Handler: app.main.handler
Runtime: python3.12
Architectures:
- x86_64
Metadata:
BuildProperties:
ParentPackageMode: explicit
ParentPackages: app
```
Avec cette configuration, votre code peut utiliser des importations absolues `from app.utils import logger` au lieu d'importations relatives telles que`from .utils import logger`.
## Fonctions du bâtiment en dehors de AWS SAM
Par défaut, lorsque vous exécutez**sam build**, AWS SAM crée toutes les ressources de vos fonctions. Les autres options sont les suivantes :
+ **Construire toutes les ressources fonctionnelles en dehors de AWS SAM** — Si vous créez toutes vos ressources fonctionnelles manuellement ou via un autre outil, cela n'**sam build**est pas obligatoire. Vous pouvez ignorer **sam build** et passer à l'étape suivante de votre processus, par exemple effectuer des tests locaux ou déployer votre application.
+ **Création de ressources fonctionnelles en dehors de AWS SAM** : si vous AWS SAM souhaitez créer certaines de vos ressources fonctionnelles tout en créant d'autres ressources fonctionnelles en dehors de AWS SAM celles-ci, vous pouvez le spécifier dans votre AWS SAM modèle.
### Créez des ressources fonctionnelles en dehors de AWS SAM
Pour AWS SAM ignorer une fonction lors de son utilisation**sam build**, configurez les éléments suivants dans votre AWS SAM modèle :
1. Ajoutez la propriété de métadonnées `SkipBuild: True` à votre fonction.
1. Spécifiez le chemin d'accès à vos ressources de fonction créées.
Voici un exemple, avec `TestFunction` configuré pour être ignoré. Ses ressources créées se trouvent à cet emplacement : `built-resources/TestFunction.zip`.
```
TestFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: built-resources/TestFunction.zip
Handler: TimeHandler::handleRequest
Runtime: java11
Metadata:
SkipBuild: True
```
Maintenant, lorsque vous exécuterez**sam build**, vous AWS SAM ferez ce qui suit :
1. AWS SAM ignorera les fonctions configurées avec`SkipBuild: True`.
1. AWS SAM créera toutes les autres ressources fonctionnelles et les mettra en cache dans le répertoire de `.aws-sam` construction.
1. Pour les fonctions ignorées, leur modèle dans le répertoire de création `.aws-sam` est automatiquement mis à jour pour référencer le chemin spécifié vers les ressources de vos fonctions créées.
Voici un exemple du modèle mis en cache pour `TestFunction` dans le répertoire de création `.aws-sam` :
```
TestFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: ../../built-resources/TestFunction.zip
Handler: TimeHandler::handleRequest
Runtime: java11
Metadata:
SkipBuild: True
```
# Personnalisez les builds avec AWS SAM
Vous pouvez personnaliser votre build pour inclure des fonctions Lambda ou des couches Lambda spécifiques. Une fonction est une ressource que vous pouvez appeler pour exécuter votre code dans Lambda. Une couche Lambda vous permet d'extraire le code d'une fonction Lambda qui peut ensuite être réutilisé dans plusieurs fonctions Lambda. Vous pouvez choisir de personnaliser votre build avec des fonctions Lambda spécifiques lorsque vous souhaitez vous concentrer sur le développement et le déploiement de fonctions sans serveur individuelles sans la complexité liée à la gestion de dépendances ou de ressources partagées. En outre, vous pouvez choisir de créer une couche Lambda pour vous aider à réduire la taille de vos packages de déploiement, à séparer la logique des fonctions de base des dépendances et à partager les dépendances entre plusieurs fonctions.
Les rubriques de cette section explorent certaines des différentes manières de créer des fonctions Lambda. AWS SAM Cela inclut la création de fonctions Lambda avec les environnements d'exécution des clients et la création de couches Lambda. Les environnements d'exécution personnalisés vous permettent d'installer et d'utiliser un langage qui n'est pas répertorié dans les environnements d'exécution Lambda du Guide du développeur. AWS Lambda Cela vous permet de créer un environnement d'exécution spécialisé pour exécuter des fonctions et des applications sans serveur. La création de couches Lambda uniquement (au lieu de créer l'intégralité de votre application) peut vous être bénéfique de plusieurs manières. Cela peut vous aider à réduire la taille de vos packages de déploiement, à séparer la logique des fonctions de base des dépendances et à partager les dépendances entre plusieurs fonctions.
Pour plus d'informations sur les fonctions, consultez les [concepts Lambda](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-concepts.html) dans le Guide du *AWS Lambda développeur*.
**Topics**
+ [Création de fonctions Lambda dans Node.js avec esbuild AWS SAM](serverless-sam-cli-using-build-typescript.md)
+ [Création de fonctions Lambda .NET avec une compilation native AOT dans AWS SAM](build-dotnet7.md)
+ [Création de fonctions Rust Lambda avec in Cargo Lambda AWS SAM](building-rust.md)
+ [Création de fonctions Lambda en Python avec in uv AWS SAM](building-python-uv.md)
+ [Création de fonctions Lambda avec des environnements d'exécution personnalisés dans AWS SAM](building-custom-runtimes.md)
+ [Création de couches Lambda dans AWS SAM](building-layers.md)
# Création de fonctions Lambda dans Node.js avec esbuild AWS SAM
Pour créer et empaqueter AWS Lambda les fonctions Node.js, vous pouvez les utiliser AWS SAMCLI avec le JavaScript bundler esbuild. Le bundler esbuild prend en charge les fonctions Lambda que vous écrivez. TypeScript
Pour créer une fonction Lambda Node.js avec esbuild, ajoutez un objet `Metadata` à votre `AWS:Serverless::Function` ressource et spécifiez `esbuild` pour `BuildMethod`. Lorsque vous exécutez la **sam build** commande, AWS SAM utilise esbuild pour regrouper le code de votre fonction Lambda.
## Propriétés de métadonnées
L'objet `Metadata` prend en charge les propriétés suivantes pour esbuild.
### BuildMethod
Spécifie le bundler de votre application. La seule valeur prise en charge est `esbuild`.
### BuildProperties
Spécifie les propriétés de création du code de votre fonction Lambda.
L'objet `BuildProperties` prend en charge les propriétés suivantes pour esbuild. Toutes les propriétés sont facultatives. Par défaut, AWS SAM utilise votre gestionnaire de fonctions Lambda comme point d'entrée.
**EntryPoints**
Spécifie les points d'entrée de votre application.
**Externe**
Spécifie la liste des packages à omettre de la création. Pour plus d'informations, veuillez consulter la section [Externe](https://esbuild.github.io/api/#external) sur le *site Web esbuild* (langue française non garantie).
**Format**
Spécifie le format de sortie des JavaScript fichiers générés dans votre application. Pour plus d'informations, consultez la section [Format](https://esbuild.github.io/api/#format) du *site Web esbuild*.
**Chargeur**
Spécifie la liste des configurations de chargement des données pour un type de fichier donné.
**MainFields**
Spécifie les champs `package.json` à essayer d'importer lors de la résolution d'un package. La valeur par défaut est `main,module`.
**Réduire**
Spécifie s'il faut réduire le code de sortie groupé. La valeur par défaut est `true`.
**OutExtension**
Personnalisez l'extension des fichiers générés par esbuild. Pour plus d'informations, veuillez consulter [Out extension](https://esbuild.github.io/api/#out-extension) sur le *site Web esbuild*.
**Carte source**
Spécifie si le bundler produit un fichier de carte source. La valeur par défaut est `false`.
Lorsqu'il a la valeur `true`, `NODE_OPTIONS: --enable-source-maps` est ajouté aux variables d'environnement de la fonction Lambda, et une carte source est générée et incluse dans la fonction.
Sinon, lorsque `NODE_OPTIONS: --enable-source-maps` est inclus dans les variables d'environnement de la fonction, `Sourcemap` est automatiquement défini sur `true`.
En cas de conflit, `Sourcemap: false` a la priorité sur `NODE_OPTIONS: --enable-source-maps`.
Par défaut, Lambda chiffre toutes les variables d'environnement au repos avec AWS Key Management Service (AWS KMS). Lorsque vous utilisez des cartes sources, pour que le déploiement réussisse, le rôle d'exécution de votre fonction doit avoir l'autorisation d'effectuer l'action `kms:Encrypt`.
**SourcesContent**
Indique s'il faut inclure votre code source dans votre fichier de carte source. Configurez cette propriété lorsque `Sourcemap` est définie sur `'true'`.
+ Spécifiez `SourcesContent: 'true'` pour inclure tout le code source.
+ Spécifiez `SourcesContent: 'false'` pour exclure tout le code source. Cela permet de réduire la taille des fichiers de cartes sources, ce qui est utile en production en réduisant les temps de démarrage. Cependant, le code source ne sera pas disponible dans le débogueur.
La valeur par défaut est `SourcesContent: true`.
Pour plus d'informations, consultez la section [Contenu des sources](https://esbuild.github.io/api/#sources-content) du *site web esbuild*.
**Cible**
Spécifie la ECMAScript version cible. La valeur par défaut est `es2020`.
## TypeScript Exemple de fonction Lambda
L'exemple d'extrait de AWS SAM modèle suivant utilise esbuild pour créer une fonction Lambda Node.js à partir du code dans. TypeScript `hello-world/app.ts`
```
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: hello-world/
Handler: app.handler
Runtime: nodejs20.x
Architectures:
- x86_64
Events:
HelloWorld:
Type: Api
Properties:
Path: /hello
Method: get
Environment:
Variables:
NODE_OPTIONS: --enable-source-maps
Metadata:
BuildMethod: esbuild
BuildProperties:
Format: esm
Minify: false
OutExtension:
- .js=.mjs
Target: "es2020"
Sourcemap: true
EntryPoints:
- app.ts
External:
- ""
```
# Création de fonctions Lambda .NET avec une compilation native AOT dans AWS SAM
Créez et empaquetez vos AWS Lambda fonctions .NET 8 avec le AWS Serverless Application Model (AWS SAM), en utilisant la compilation native Ahead-of-Time (AOT) pour améliorer les temps de démarrage à AWS Lambda froid.
**Topics**
+ [Présentation de .NET 8 Native AOT](#build-dotnet7-overview)
+ [Utilisation AWS SAM avec vos fonctions Lambda .NET 8](#build-dotnet7-sam)
+ [Installer les prérequis](#build-dotnet7-prerequisites)
+ [Définissez les fonctions Lambda .NET 8 dans votre modèle AWS SAM](#build-dotnet7-sam-define)
+ [Créer votre application à l'aide de la CLI AWS SAM](#build-dotnet7-sam-build)
+ [En savoir plus](#build-dotnet7-learn-more)
## Présentation de .NET 8 Native AOT
Historiquement, les fonctions Lambda .NET ont eu des temps de démarrage à froid affectant l'expérience utilisateur, la latence du système et les coûts d'utilisation de vos applications sans serveur. Avec la compilation .NET Native AOT, vous pouvez améliorer les temps de démarrage à froid de vos fonctions Lambda. Pour en savoir plus sur l'AOT natif pour .NET 8, voir [Utilisation de l'AOT natif](https://github.com/dotnet/runtime/tree/main/src/coreclr/nativeaot#readme) dans le référentiel * GitHub Dotnet*.
## Utilisation AWS SAM avec vos fonctions Lambda .NET 8
Procédez comme suit pour configurer vos fonctions Lambda .NET 8 avec le AWS Serverless Application Model ()AWS SAM :
+ Installez les prérequis sur votre machine de développement.
+ Définissez les fonctions Lambda .NET 8 dans votre AWS SAM modèle.
+ Créez votre application à l'aide du AWS SAMCLI.
## Installer les prérequis
Les prérequis sont les suivants :
+ Le AWS SAMCLI
+ La CLI .NET Core
+ L'outil global .NET Core d'Amazon.Lambda.Tools
+ Docker
**Installer la CLI AWS SAM**
1. Pour vérifier si la CLI AWS SAM est déjà installée, procédez comme suit :
```
sam --version
```
1. Pour installer le AWS SAMCLI, voir[Installer la CLI AWS SAM](install-sam-cli.md).
1. Pour mettre à niveau une version installée du AWS SAMCLI, voir[Mise à niveau de la CLI AWS SAM en cours](manage-sam-cli-versions.md#manage-sam-cli-versions-upgrade).
**Installer la CLI .NET Core**
1. Pour télécharger et installer la CLI .NET Core, veuillez consulter la rubrique [Télécharger .NET](https://dotnet.microsoft.com/download) (langue française non garantie) du site web Microsoft.
1. Pour plus d'informations sur la CLI .NET Core, veuillez consulter la rubrique [Interface de ligne de commande .NET Core](https://docs.aws.amazon.com/lambda/latest/dg/csharp-package-cli.html) dans le *Guide du développeur AWS Lambda *.
**Installer l'outil global .NET Core d'Amazon.Lambda.Tools**
1. Exécutez la commande suivante :
```
dotnet tool install -g Amazon.Lambda.Tools
```
1. Si cet outil est déjà installé, vous pouvez vérifier qu'il s'agit de la dernière version avec la commande suivante :
```
dotnet tool update -g Amazon.Lambda.Tools
```
1. Pour plus d'informations sur l'outil global .NET Core d'Amazon.Lambda.Tools, consultez les extensions [AWS pour le référentiel .NET](https://github.com/aws/aws-extensions-for-dotnet-cli) CLI sur. GitHub
**Installer Docker**
+ Docker doit être installé pour permettre la création avec la compilation anticipée native. Pour obtenir des instructions d’installation, consultez [Installation de Docker pour une utilisation avec la CLI AWS SAM](install-docker.md).
## Définissez les fonctions Lambda .NET 8 dans votre modèle AWS SAM
Pour définir un. NET8 Fonction Lambda dans votre AWS SAM modèle, procédez comme suit :
1. Exécutez la commande suivante depuis le répertoire de départ de votre choix :
```
sam init
```
1. Sélectionnez `AWS Quick Start Templates` pour choisir un modèle de départ.
1. Choisissez le modèle `Hello World Example`.
1. Choisissez de ne pas utiliser le moteur d'exécution et le type de package les plus populaires en saisissant`n`.
1. Pour l'exécution, choisissez`dotnet8`.
1. Pour le type de package, choisissez`Zip`.
1. Pour votre modèle de démarrage, choisissez`Hello World Example using native AOT`.
**Installer Docker**
+ Docker doit être installé pour permettre la création avec la compilation anticipée native. Pour obtenir des instructions d’installation, consultez [Installation de Docker pour une utilisation avec la CLI AWS SAM](install-docker.md).
```
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: ./src/HelloWorldAot/
Handler: bootstrap
Runtime: dotnet8
Architectures:
- x86_64
Events:
HelloWorldAot:
Type: Api
Properties:
Path: /hello
Method: get
```
**Note**
Lorsque la `Event` propriété de an `AWS::Serverless::Function` est définie sur`Api`, mais que la `RestApiId` propriété n'est pas spécifiée, AWS SAM la `AWS::ApiGateway::RestApi` CloudFormation ressource est générée.
## Créer votre application à l'aide de la CLI AWS SAM
Depuis le répertoire racine de votre projet, exécutez la `sam build` commande pour commencer à créer votre application. Si la `PublishAot` propriété a été définie dans votre fichier de projet .NET 8, elle AWS SAMCLI sera compilée avec la compilation native AOT. Pour en savoir plus sur la propriété `PublishAot`, veuillez consulter la rubrique [Déploiement anticipé natif](https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/) (langue française non garantie) dans la *documentation .NET* de Microsoft.
Pour créer votre fonction, la CLI AWS SAM invoque la CLI .NET Core qui utilise l'outil global .NET Core d'Amazon.Lambda.Tools.
**Note**
Lors de la création, si un fichier `.sln` existe dans le même répertoire ou dans le répertoire parent de votre projet, le répertoire contenant le fichier `.sln` sera monté dans le conteneur. Si aucun fichier `.sln` n'est trouvé, seul le dossier du projet est monté. Par conséquent, si vous créez une application multi-projets, assurez-vous que le fichier `.sln` est bien localisé.
## En savoir plus
Pour plus d'informations sur la création de fonctions Lambda .NET 8, consultez [Présentation du moteur d'exécution .NET 8](https://aws.amazon.com/blogs/compute/introducing-the-net-8-runtime-for-aws-lambda/) pour. AWS Lambda
Pour obtenir la référence de la commande **sam build**, consultez [sam build](sam-cli-command-reference-sam-build.md).
# Création de fonctions Rust Lambda avec in Cargo Lambda AWS SAM
| |
| --- |
| Cette fonctionnalité est en version préliminaire AWS SAM et est sujette à modification. |
Utilisez l'interface de ligne de AWS Serverless Application Model commande (AWS SAMCLI) avec vos AWS Lambda fonctions Rust.
**Topics**
+ [Conditions préalables](#building-rust-prerequisites)
+ [Configuration AWS SAM à utiliser avec les fonctions Rust Lambda](#building-rust-configure)
+ [Exemples](#building-rust-examples)
## Conditions préalables
**Langage Rust**
Pour installer Rust, consultez la section [Installer Rust](https://www.rust-lang.org/tools/install) sur le *site web du langage Rust*.
**Cargo Lambda**
La CLI AWS SAM nécessite l'installation de [https://www.cargo-lambda.info/guide/what-is-cargo-lambda.html](https://www.cargo-lambda.info/guide/what-is-cargo-lambda.html), une sous-commande pour Cargo. Pour les instructions d'installation, consultez la rubrique [Installation](https://www.cargo-lambda.info/guide/installation.html) dans la *documentation Cargo Lambda*.
**Docker**
La création et le test de fonctions Lambda Rust nécessitent Docker. Pour obtenir des instructions d’installation, consultez [Installation de Docker](install-docker.md).
**Activer la fonctionnalité bêta de la CLI AWS SAM**
Cette fonctionnalité étant en cours de prévisualisation, vous devez l'activer en utilisant l'une des méthodes suivantes :
1. Utiliser la variable d'environnement : `SAM_CLI_BETA_RUST_CARGO_LAMBDA=1`.
1. Ajoutez ce qui suit à votre fichier `samconfig.toml` :
```
[default.build.parameters]
beta_features = true
[default.sync.parameters]
beta_features = true
```
1. Utilisez l'option `--beta-features` lorsque vous utilisez une commande de la CLI AWS SAM prise en charge. Par exemple :
```
$ sam build --beta-features
```
1. Choisissez l'option `y` lorsque la CLI AWS SAM vous y invite. Voici un exemple :
```
$ sam build
Starting Build use cache
Build method "rust-cargolambda" is a beta feature.
Please confirm if you would like to proceed
You can also enable this beta feature with "sam build --beta-features". [y/N]: y
```
## Configuration AWS SAM à utiliser avec les fonctions Rust Lambda
### Étape 1 : Configuration de votre AWS SAM modèle
Configurez votre AWS SAM modèle avec les éléments suivants :
+ **Binaire** : facultatif. Spécifiez quand votre modèle contient plusieurs fonctions Lambda Rust.
+ **BuildMethod** – `rust-cargolambda`.
+ **CodeUri**— chemin d'accès à votre `Cargo.toml` fichier.
+ **Gestionnaire** : `bootstrap`.
+ **Exécution** : `provided.al2`.
Pour en savoir plus sur les environnements d'exécution personnalisés, consultez la section [AWS Lambda Runtimes personnalisés](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html) dans le manuel du *AWS Lambda développeur*.
Voici un exemple de AWS SAM modèle configuré :
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
...
Resources:
MyFunction:
Type: AWS::Serverless::Function
Metadata:
BuildMethod: rust-cargolambda
BuildProperties: function_a
Properties:
CodeUri: ./rust_app
Handler: bootstrap
Runtime: provided.al2
...
```
### Étape 2 : utiliser la CLI AWS SAM avec votre fonction Lambda Rust
Utilisez n'importe quelle AWS SAMCLI commande avec votre AWS SAM modèle. Pour de plus amples informations, veuillez consulter [AWS SAM CLI](using-sam-cli.md).
## Exemples
### Exemple Hello World
**Dans cet exemple, nous créons l'exemple d'application Hello World en utilisant Rust comme notre exécution.**
Tout d'abord, nous initialisons une nouvelle application sans serveur en utilisant `sam init`. Au cours du flux interactif, nous sélectionnons l'**application Hello World** et choisissons l'exécution **Rust**.
```
$ sam init
...
Which template source would you like to use?
1 - AWS Quick Start Templates
2 - Custom Template Location
Choice: 1
Choose an AWS Quick Start application template
1 - Hello World Example
2 - Multi-step workflow
3 - Serverless API
...
Template: 1
Use the most popular runtime and package type? (Python and zip) [y/N]: ENTER
Which runtime would you like to use?
1 - dotnet8
2 - dotnet6
3 - go (provided.al2)
...
18 - python3.11
19 - python3.10
20 - ruby3.3
21 - ruby3.2
22 - rust (provided.al2)
23 - rust (provided.al2023)
Runtime: 22
Based on your selections, the only Package type available is Zip.
We will proceed to selecting the Package type as Zip.
Based on your selections, the only dependency manager available is cargo.
We will proceed copying the template using cargo.
Would you like to enable X-Ray tracing on the function(s) in your application? [y/N]: ENTER
Would you like to enable monitoring using CloudWatch Application Insights?
For more info, please view https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-application-insights.html [y/N]: ENTER
Project name [sam-app]: hello-rust
-----------------------
Generating application:
-----------------------
Name: hello-rust
Runtime: rust (provided.al2)
Architectures: x86_64
Dependency Manager: cargo
Application Template: hello-world
Output Directory: .
Configuration file: hello-rust/samconfig.toml
Next steps can be found in the README file at hello-rust/README.md
Commands you can use next
=========================
[*] Create pipeline: cd hello-rust && sam pipeline init --bootstrap
[*] Validate SAM template: cd hello-rust && sam validate
[*] Test Function in the Cloud: cd hello-rust && sam sync --stack-name {stack-name} --watch
```
Voici la structure de notre application Hello World :
```
hello-rust
├── README.md
├── events
│ └── event.json
├── rust_app
│ ├── Cargo.toml
│ └── src
│ └── main.rs
├── samconfig.toml
└── template.yaml
```
Dans notre AWS SAM modèle, notre Rust fonction est définie comme suit :
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
...
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Metadata:
BuildMethod: rust-cargolambda
Properties:
CodeUri: ./rust_app
Handler: bootstrap
Runtime: provided.al2
Architectures:
- x86_64
Events:
HelloWorld:
Type: Api
Path: /hello
Method: get
```
Ensuite, nous exécutons `sam build` pour créer notre application et préparer son déploiement. La CLI AWS SAM crée un répertoire `.aws-sam` et organise nos artefacts de création. Notre fonction est construite en utilisant Cargo Lambda et stockée sous forme de binaire exécutable à l'emplacement suivant : `.aws-sam/build/HelloWorldFunction/bootstrap`.
**Note**
Si vous envisagez d'exécuter la **sam local invoke** commande sous macOS, vous devez créer des fonctions différentes avant de l'invoquer. Pour ce faire, utilisez la commande suivante :
**SAM\$1BUILD\$1MODE=debug sam build**
Cette commande n'est nécessaire que si des tests locaux doivent être effectués. Cela n'est pas recommandé lors de la création en vue du déploiement.
```
hello-rust$ sam build
Starting Build use cache
Build method "rust-cargolambda" is a beta feature.
Please confirm if you would like to proceed
You can also enable this beta feature with "sam build --beta-features". [y/N]: y
Experimental features are enabled for this session.
Visit the docs page to learn more about the AWS Beta terms https://aws.amazon.com/service-terms/.
Cache is invalid, running build and copying resources for following functions (HelloWorldFunction)
Building codeuri: /Users/.../hello-rust/rust_app runtime: provided.al2 metadata: {'BuildMethod': 'rust-cargolambda'} architecture: x86_64 functions: HelloWorldFunction
Running RustCargoLambdaBuilder:CargoLambdaBuild
Running RustCargoLambdaBuilder:RustCopyAndRename
Build Succeeded
Built Artifacts : .aws-sam/build
Built Template : .aws-sam/build/template.yaml
Commands you can use next
=========================
[*] Validate SAM template: sam validate
[*] Invoke Function: sam local invoke
[*] Test Function in the Cloud: sam sync --stack-name {{stack-name}} --watch
[*] Deploy: sam deploy --guided
```
Ensuite, nous déployons notre application en utilisant `sam deploy --guided`.
```
hello-rust$ sam deploy --guided
Configuring SAM deploy
======================
Looking for config file [samconfig.toml] : Found
Reading default arguments : Success
Setting default arguments for 'sam deploy'
=========================================
Stack Name [hello-rust]: ENTER
AWS Region [us-west-2]: ENTER
#Shows you resources changes to be deployed and require a 'Y' to initiate deploy
Confirm changes before deploy [Y/n]: ENTER
#SAM needs permission to be able to create roles to connect to the resources in your template
Allow SAM CLI IAM role creation [Y/n]: ENTER
#Preserves the state of previously provisioned resources when an operation fails
Disable rollback [y/N]: ENTER
HelloWorldFunction may not have authorization defined, Is this okay? [y/N]: y
Save arguments to configuration file [Y/n]: ENTER
SAM configuration file [samconfig.toml]: ENTER
SAM configuration environment [default]: ENTER
Looking for resources needed for deployment:
...
Uploading to hello-rust/56ba6585d80577dd82a7eaaee5945c0b 817973 / 817973 (100.00%)
Deploying with following values
===============================
Stack name : hello-rust
Region : us-west-2
Confirm changeset : True
Disable rollback : False
Deployment s3 bucket : aws-sam-cli-managed-default-samclisam-s3-demo-bucket-1a4x26zbcdkqr
Capabilities : ["CAPABILITY_IAM"]
Parameter overrides : {}
Signing Profiles : {}
Initiating deployment
=====================
Uploading to hello-rust/a4fc54cb6ab75dd0129e4cdb564b5e89.template 1239 / 1239 (100.00%)
Waiting for changeset to be created..
CloudFormation stack changeset
---------------------------------------------------------------------------------------------------------
Operation LogicalResourceId ResourceType Replacement
---------------------------------------------------------------------------------------------------------
+ Add HelloWorldFunctionHelloW AWS::Lambda::Permission N/A
orldPermissionProd
...
---------------------------------------------------------------------------------------------------------
Changeset created successfully. arn:aws:cloudformation:us-west-2:012345678910:changeSet/samcli-deploy1681427201/f0ef1563-5ab6-4b07-9361-864ca3de6ad6
Previewing CloudFormation changeset before deployment
======================================================
Deploy this changeset? [y/N]: y
2023-04-13 13:07:17 - Waiting for stack create/update to complete
CloudFormation events from stack operations (refresh every 5.0 seconds)
---------------------------------------------------------------------------------------------------------
ResourceStatus ResourceType LogicalResourceId ResourceStatusReason
---------------------------------------------------------------------------------------------------------
CREATE_IN_PROGRESS AWS::IAM::Role HelloWorldFunctionRole -
CREATE_IN_PROGRESS AWS::IAM::Role HelloWorldFunctionRole Resource creation
...
---------------------------------------------------------------------------------------------------------
CloudFormation outputs from deployed stack
---------------------------------------------------------------------------------------------------------
Outputs
---------------------------------------------------------------------------------------------------------
Key HelloWorldFunctionIamRole
Description Implicit IAM Role created for Hello World function
Value arn:aws:iam::012345678910:role/hello-rust-HelloWorldFunctionRole-10II2P13AUDUY
Key HelloWorldApi
Description API Gateway endpoint URL for Prod stage for Hello World function
Value https://ggdxec9le9.execute-api.us-west-2.amazonaws.com/Prod/hello/
Key HelloWorldFunction
Description Hello World Lambda Function ARN
Value arn:aws:lambda:us-west-2:012345678910:function:hello-rust-HelloWorldFunction-
yk4HzGzYeZBj
---------------------------------------------------------------------------------------------------------
Successfully created/updated stack - hello-rust in us-west-2
```
Pour tester, nous pouvons appeler notre fonction Lambda à l'aide du point de terminaison de l'API.
```
$ curl https://ggdxec9le9.execute-api.us-west-2.amazonaws.com/Prod/hello/
Hello World!%
```
Pour tester notre fonction localement, nous devons d'abord nous assurer que la propriété `Architectures`de notre fonction correspond à notre ordinateur local.
```
...
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function # More info about Function Resource: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction
Metadata:
BuildMethod: rust-cargolambda # More info about Cargo Lambda: https://github.com/cargo-lambda/cargo-lambda
Properties:
CodeUri: ./rust_app # Points to dir of Cargo.toml
Handler: bootstrap # Do not change, as this is the default executable name produced by Cargo Lambda
Runtime: provided.al2
Architectures:
- arm64
...
```
Comme nous avons modifié notre architecture en passant de `x86_64` à `arm64` dans cet exemple, nous exécutons `sam build` pour mettre à jour nos artefacts de création. Nous exécutons ensuite `sam local invoke` pour appeler notre fonction localement.
```
hello-rust$ sam local invoke
Invoking bootstrap (provided.al2)
Local image was not found.
Removing rapid images for repo public.ecr.aws/sam/emulation-provided.al2
Building image.....................................................................................................................................
Using local image: public.ecr.aws/lambda/provided:al2-rapid-arm64.
Mounting /Users/.../hello-rust/.aws-sam/build/HelloWorldFunction as /var/task:ro,delegated, inside runtime container
START RequestId: fbc55e6e-0068-45f9-9f01-8e2276597fc6 Version: $LATEST
{"statusCode":200,"body":"Hello World!"}END RequestId: fbc55e6e-0068-45f9-9f01-8e2276597fc6
REPORT RequestId: fbc55e6e-0068-45f9-9f01-8e2276597fc6 Init Duration: 0.68 ms Duration: 130.63 ms Billed Duration: 131 ms Memory Size: 128 MB Max Memory Used: 128 MB
```
### Projet de fonction Lambda unique
**Voici un exemple d'application sans serveur contenant une fonction Lambda Rust.**
Structure du répertoire du projet :
```
.
├── Cargo.lock
├── Cargo.toml
├── src
│ └── main.rs
└── template.yaml
```
AWS SAM modèle :
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
...
Resources:
MyFunction:
Type: AWS::Serverless::Function
Metadata:
BuildMethod: rust-cargolambda
Properties:
CodeUri: ./
Handler: bootstrap
Runtime: provided.al2
...
```
### Projet de fonctions Lambda multiples
**Voici un exemple d'application sans serveur contenant plusieurs fonctions Lambda Rust.**
Structure du répertoire du projet :
```
.
├── Cargo.lock
├── Cargo.toml
├── src
│ ├── function_a.rs
│ └── function_b.rs
└── template.yaml
```
AWS SAM modèle :
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
...
Resources:
FunctionA:
Type: AWS::Serverless::Function
Metadata:
BuildMethod: rust-cargolambda
BuildProperties:
Binary: function_a
Properties:
CodeUri: ./
Handler: bootstrap
Runtime: provided.al2
FunctionB:
Type: AWS::Serverless::Function
Metadata:
BuildMethod: rust-cargolambda
BuildProperties:
Binary: function_b
Properties:
CodeUri: ./
Handler: bootstrap
Runtime: provided.al2
```
Fichier `Cargo.toml` :
```
[package]
name = "test-handler"
version = "0.1.0"
edition = "2021"
[dependencies]
lambda_runtime = "0.6.0"
serde = "1.0.136"
tokio = { version = "1", features = ["macros"] }
tracing = { version = "0.1", features = ["log"] }
tracing-subscriber = { version = "0.3", default-features = false, features = ["fmt"] }
[[bin]]
name = "function_a"
path = "src/function_a.rs"
[[bin]]
name = "function_b"
path = "src/function_b.rs"
```
# Création de fonctions Lambda en Python avec in uv AWS SAM
| |
| --- |
| Cette fonctionnalité est en version préliminaire AWS SAM et est sujette à modification. |
Utilisez l'interface de ligne de AWS Serverless Application Model commande (AWS SAMCLI) avecuv, un installateur et un résolveur rapides de paquets Python, pour créer vos AWS Lambda fonctions Python.
**Topics**
+ [Conditions préalables](#building-python-uv-prerequisites)
+ [Configuration AWS SAM à utiliser avec les fonctions Lambda en Python et uv](#building-python-uv-configure)
+ [Exemples](#building-python-uv-examples)
## Conditions préalables
**Python**
Pour installer Python, consultez [la section Télécharger Python](https://www.python.org/downloads/) sur le *site Web de Python*.
**uv**
AWS SAMCLINécessite l'installation d'[https://docs.astral.sh/uv/](https://docs.astral.sh/uv/)un programme d'installation et d'un résolveur de paquets Python extrêmement rapides. Pour les instructions d'installation, consultez la rubrique [Installation](https://docs.astral.sh/uv/getting-started/installation/) dans la *documentation uv*.
**Activer la fonctionnalité bêta de la CLI AWS SAM**
Cette fonctionnalité étant en cours de prévisualisation, vous devez l'activer en utilisant l'une des méthodes suivantes :
1. Utiliser la variable d'environnement : `SAM_CLI_BETA_PYTHON_UV=1`.
1. Ajoutez ce qui suit à votre fichier `samconfig.toml` :
```
[default.build.parameters]
beta_features = true
[default.sync.parameters]
beta_features = true
```
1. Utilisez l'option `--beta-features` lorsque vous utilisez une commande de la CLI AWS SAM prise en charge. Par exemple :
```
$ sam build --beta-features
```
1. Choisissez l'option `y` lorsque la CLI AWS SAM vous y invite. Voici un exemple :
```
$ sam build
Starting Build use cache
Build method "python-uv" is a beta feature.
Please confirm if you would like to proceed
You can also enable this beta feature with "sam build --beta-features". [y/N]: y
```
## Configuration AWS SAM à utiliser avec les fonctions Lambda en Python et uv
### Étape 1 : Configuration de votre AWS SAM modèle
Configurez votre AWS SAM modèle avec les éléments suivants :
+ **BuildMethod** – `python-uv`.
+ **CodeUri**— chemin d'accès au répertoire de votre code de fonction contenant `pyproject.toml` ou`requirements.txt`.
+ **Handler** — votre gestionnaire de fonctions (par exemple,`app.lambda_handler`).
+ **Runtime** — Version d'exécution de Python (par exemple,`python3.12`).
Voici un exemple de AWS SAM modèle configuré :
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
...
Resources:
MyFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: ./my_function
Handler: app.lambda_handler
Runtime: python3.12
Metadata:
BuildMethod: python-uv
...
```
## Exemples
### Exemple Hello World
**Dans cet exemple, nous créons un exemple d'application Hello World en utilisant Python uv comme gestionnaire de packages.**
uvpeut utiliser l'un `pyproject.toml` ou l'autre ou `requirements.txt` pour lire les dépendances. Si les deux sont fournis, `sam build` je lirai depuis `requirements.txt` pour les dépendances.
Voici la structure de notre application Hello World :
```
hello-python-uv
├── README.md
├── events
│ └── event.json
├── hello_world
│ ├── __init__.py
│ ├── app.py
│ └── pyproject.toml
├── samconfig.toml
└── template.yaml
```
Fichier `pyproject.toml` :
```
[project]
name = "my-function"
version = "0.1.0"
requires-python = ">=3.12"
dependencies = [
"requests>=2.31.0",
"boto3>=1.28.0",
]
```
Dans notre AWS SAM modèle, notre fonction Python est définie comme suit :
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
...
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: hello_world/
Handler: app.lambda_handler
Runtime: python3.12
Architectures:
- x86_64
Metadata:
BuildMethod: python-uv
```
Ensuite, nous exécutons `sam build` pour créer notre application et préparer son déploiement. La CLI AWS SAM crée un répertoire `.aws-sam` et organise nos artefacts de création. Nos dépendances fonctionnelles sont installées à uv l'aide de`.aws-sam/build/HelloWorldFunction/`.
```
hello-python-uv$ sam build
Starting Build use cache
Build method "python-uv" is a beta feature.
Please confirm if you would like to proceed
You can also enable this beta feature with "sam build --beta-features". [y/N]: y
Experimental features are enabled for this session.
Visit the docs page to learn more about the AWS Beta terms https://aws.amazon.com/service-terms/.
Cache is invalid, running build and copying resources for following functions (HelloWorldFunction)
Building codeuri: /Users/.../hello-python-uv/hello_world runtime: python3.12 metadata: {'BuildMethod': 'python-uv'} architecture: x86_64 functions: HelloWorldFunction
Running PythonUvBuilder:UvBuild
Running PythonUvBuilder:CopySource
Build Succeeded
Built Artifacts : .aws-sam/build
Built Template : .aws-sam/build/template.yaml
Commands you can use next
=========================
[*] Validate SAM template: sam validate
[*] Invoke Function: sam local invoke
[*] Test Function in the Cloud: sam sync --stack-name {{stack-name}} --watch
[*] Deploy: sam deploy --guided
```
**Note**
La méthode de `python-uv` construction est configurée par fonction dans la `Metadata` section. Chaque fonction de votre modèle peut utiliser une méthode de construction différente, ce qui vous permet de mélanger des fonctions uv `pip` basées avec des fonctions basées dans le même AWS SAM modèle. Si aucune méthode de construction n'est spécifiée, elle `pip` est utilisée par défaut.
# Création de fonctions Lambda avec des environnements d'exécution personnalisés dans AWS SAM
Vous pouvez utiliser la commande `sam build` pour créer des exécutions personnalisées requises pour votre fonction Lambda. Vous déclarez votre fonction Lambda pour utiliser une exécution personnalisée en spécifiant `Runtime: provided` pour la fonction.
Pour créer une exécution personnalisée, déclarez l'attribut de ressource `Metadata` avec une entrée `BuildMethod: makefile`. Vous fournissez un makefile personnalisé, où vous déclarez une cible de génération du formulaire `build-function-logical-id` qui contient les commandes de création de votre exécution. Votre makefile est responsable de la compilation de l'exécution personnalisée si nécessaire, et de la copie des artefacts de construction dans l'emplacement approprié requis pour les étapes suivantes de votre flux. L'emplacement du makefile est spécifié par la propriété `CodeUri` de la ressource de fonction, et doit être nommé `Makefile`.
## Exemples
### Exemple 1 : exécution personnalisée pour une fonction écrite en Rust
**Note**
Nous vous recommandons de créer des fonctions Lambda avec Cargo Lambda. Pour en savoir plus, veuillez consulter la section [Création de fonctions Rust Lambda avec in Cargo Lambda AWS SAM](building-rust.md).
Le AWS SAM modèle suivant déclare une fonction qui utilise un environnement d'exécution personnalisé pour une fonction Lambda écrite en Rust et demande d'exécuter les `sam build` commandes pour la `build-HelloRustFunction` cible de construction.
```
Resources:
HelloRustFunction:
Type: AWS::Serverless::Function
Properties:
FunctionName: HelloRust
Handler: bootstrap.is.real.handler
Runtime: provided
MemorySize: 512
CodeUri: .
Metadata:
BuildMethod: makefile
```
Le makefile suivant contient la cible de génération et les commandes qui seront exécutées. Notez que la propriété `CodeUri` est définie sur `.`. Le makefile doit donc se trouver dans le répertoire racine du projet (c'est-à-dire dans le même répertoire que le fichier de modèle de l'application AWS SAM ). Le nom de fichier doit être `Makefile`.
```
build-HelloRustFunction:
cargo build --release --target x86_64-unknown-linux-musl
cp ./target/x86_64-unknown-linux-musl/release/bootstrap $(ARTIFACTS_DIR)
```
Pour de plus amples informations sur la configuration de votre environnement de développement afin d'exécuter la commande `cargo build` dans le `makefile` précédent, consultez l'article de blog [Exécution Rust pour AWS Lambda](https://aws.amazon.com/blogs/opensource/rust-runtime-for-aws-lambda/).
### Exemple 2 : générateur de fichiers Makefile pour Python3.12 (alternative à l'utilisation du générateur groupé)
Vous pouvez utiliser une bibliothèque ou un module qui n'est pas inclus dans un générateur groupé. Cet exemple montre un AWS SAM modèle pour un environnement d'exécution Python3.12 avec un générateur de makefile.
```
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: hello_world/
Handler: app.lambda_handler
Runtime: python3.12
Metadata:
BuildMethod: makefile
```
Le makefile suivant contient la cible de génération et les commandes qui seront exécutées. Notez que la propriété `CodeUri` est définie sur `hello_world`. Le makefile doit donc se trouver dans la racine du répertoire `hello_world`, et le nom de fichier doit être `Makefile`.
```
build-HelloWorldFunction:
cp *.py $(ARTIFACTS_DIR)
cp requirements.txt $(ARTIFACTS_DIR)
python -m pip install -r requirements.txt -t $(ARTIFACTS_DIR)
rm -rf $(ARTIFACTS_DIR)/bin
```
# Création de couches Lambda dans AWS SAM
Vous pouvez l'utiliser AWS SAM pour créer des couches Lambda personnalisées. Les couches Lambda vous permettent d'extraire le code d'une fonction Lambda qui peut ensuite être réutilisé dans plusieurs fonctions Lambda. La création de couches Lambda uniquement (au lieu de créer l'intégralité de votre application) peut vous être bénéfique de plusieurs manières. Cela peut vous aider à réduire la taille de vos packages de déploiement, à séparer la logique des fonctions de base des dépendances et à partager les dépendances entre plusieurs fonctions. Pour davantage d'informations sur les couches, consultez [Couches Lambda AWS](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) dans le *Guide du développeur AWS Lambda *.
## Comment créer une couche Lambda dans AWS SAM
**Note**
Avant de créer une couche Lambda, vous devez d'abord écrire une couche Lambda dans votre modèle. AWS SAM Pour obtenir des informations et des exemples à ce sujet, consultez[Améliorez l'efficacité en utilisant les couches Lambda avec AWS SAM](serverless-sam-cli-layers.md).
Pour créer une couche personnalisée, déclarez-la dans votre fichier modèle AWS Serverless Application Model (AWS SAM) et incluez une section d'attribut de `Metadata` ressource avec une `BuildMethod` entrée. Les valeurs valides pour `BuildMethod` sont des identifiants pour une [exécution AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html), ou `makefile`. Incluez une entrée `BuildArchitecture` pour préciser les architectures de jeux d'instructions prises en charge par votre couche. Les valeurs valides pour `BuildArchitecture` sont [Architectures du jeu d'instructions Lambda](https://docs.aws.amazon.com/lambda/latest/dg/foundation-arch.html).
Si vous spécifiez `makefile`, vous fournissez un makefile personnalisé, où vous déclarez une cible de génération du formulaire `build-layer-logical-id` qui contient les commandes de création de votre couche. Votre makefile est responsable de la compilation de la couche si nécessaire, et de la copie des artefacts de construction dans l'emplacement approprié requis pour les étapes suivantes de votre flux. L'emplacement du makefile est spécifié par la propriété `ContentUri` de la ressource de couche, et doit être nommé `Makefile`.
**Note**
Lorsque vous créez une couche personnalisée, AWS Lambda cela dépend des variables d'environnement pour trouver votre code de couche. Les exécutions Lambda incluent des chemins dans le répertoire `/opt` dans lequel votre code de couche est copié. La structure de dossier d'artefact de construction de votre projet doit correspondre à la structure de dossier attendue de l'exécution pour que votre code de couche personnalisé puisse être trouvé.
Par exemple, pour Python, vous pouvez placer votre code dans le sous-répertoire `python/`. Pour NodeJS, vous pouvez placer votre code dans le sous-répertoire `nodejs/node_modules/`.
Pour de plus amples informations, consultez [Inclusion de dépendances de bibliothèques dans une couche](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html#configuration-layers-path) dans le *Guide du développeur AWS Lambda *.
Voici un exemple de section d'attribut de ressource `Metadata`.
```
Metadata:
BuildMethod: python3.12
BuildArchitecture: arm64
```
**Note**
Si vous n'incluez pas la section `Metadata` des attributs de ressource, AWS SAM cela ne crée pas la couche. Au lieu de cela, il copie les artefacts de construction à partir de l'emplacement spécifié dans la propriété `CodeUri` de la ressource de couche. Pour plus d'informations, consultez la propriété [ContentUri](sam-resource-layerversion.md#sam-layerversion-contenturi) du type de ressource `AWS::Serverless::LayerVersion`.
Lorsque vous incluez la section `Metadata` des attributs de ressource, vous pouvez utiliser la `sam build` commande pour créer la couche, à la fois en tant qu'objet indépendant ou en tant que dépendance d'une AWS Lambda fonction.
+ ****En tant qu'objet indépendant.**** Vous pouvez souhaiter créer uniquement l'objet de la couche, par exemple si vous testez localement une modification de code de la couche et que vous n'avez pas besoin de créer l'ensemble de votre application. Pour créer la couche indépendamment, spécifiez la ressource de couche à l'aide de la commande `sam build layer-logical-id`.
+ **En tant que dépendance d'une fonction Lambda.** Lorsque vous incluez l'ID logique d'une couche dans la propriété `Layers` d'une fonction Lambda dans le même fichier modèle AWS SAM , la couche sera une dépendance de cette fonction Lambda. Lorsque cette couche inclut également une section d'attribut de ressource `Metadata` avec une entrée `BuildMethod`, vous créez la couche soit en créant la totalité de l'application à l'aide de l'option `sam build` ou en spécifiant la ressource de fonction avec la commande `sam build function-logical-id`.
## Exemples
### Exemple de modèle 1 : création d'une couche dans l'environnement d'exécution Python 3.12
L'exemple de AWS SAM modèle suivant crée une couche sur l'environnement d'exécution Python 3.12.
```
Resources:
MyLayer:
Type: AWS::Serverless::LayerVersion
Properties:
ContentUri: my_layer
CompatibleRuntimes:
- python3.12
Metadata:
BuildMethod: python3.12 # Required to have AWS SAM build this layer
```
### Exemple de modèle 2 : création d'une couche à l'aide d'un makefile personnalisé
L'exemple de AWS SAM modèle suivant utilise un modèle personnalisé `makefile` pour créer la couche.
```
Resources:
MyLayer:
Type: AWS::Serverless::LayerVersion
Properties:
ContentUri: my_layer
CompatibleRuntimes:
- python3.12
Metadata:
BuildMethod: makefile
```
Le `makefile` suivant contient la cible de génération et les commandes qui seront exécutées. Notez que la propriété `ContentUri` est définie sur `my_layer`. Le makefile doit donc se trouver dans la racine du répertoire `my_layer`, et le nom de fichier doit être `Makefile`. Notez également que les artefacts de construction sont copiés dans le `python/` sous-répertoire afin que AWS Lambda celui-ci puisse trouver le code de couche.
```
build-MyLayer:
mkdir -p "$(ARTIFACTS_DIR)/python"
cp *.py "$(ARTIFACTS_DIR)/python"
python -m pip install -r requirements.txt -t "$(ARTIFACTS_DIR)/python"
```
**Note**
Lorsque le `makefile` est appelé, la cible appropriée est déclenchée et les artefacts doivent être copiés dans la variable environnementale exposée`$ARTIFACTS_DIR`. Pour plus d'informations, reportez-vous [aws-lambda-builders à GitHub](https://github.com/aws/aws-lambda-builders/blob/develop/aws_lambda_builders/workflows/custom_make/DESIGN.md).
### Exemple de commandes de création sam
Procédez comme suit : les commandes `sam build` créent des couches qui incluent la section d'attribut de ressource `Metadata`.
```
# Build the 'layer-logical-id' resource independently
$ sam build layer-logical-id
# Build the 'function-logical-id' resource and layers that this function depends on
$ sam build function-logical-id
# Build the entire application, including the layers that any function depends on
$ sam build
```