

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éploiement du code de fonction Web depuis Amazon S3
<a name="web-functions-code-s3"></a>

Vous fournissez le code Lambda Web Function sous forme de package de déploiement .zip dans un compartiment Amazon S3. C'est le seul moyen de fournir du code pour une fonction Web. Lorsque vous créez une fonction Web ou une révision, spécifiez l'objet dans le `s3Object` champ, qui est imbriqué dans `codeConfig` celui de `buildConfig` la demande. Dans`s3Object`, incluez le bucket, la clé et un versionId facultatif. Lambda référence votre code directement depuis votre bucket. Comme Lambda associe chaque révision à une version d'objet spécifique, vos déploiements sont reproductibles. Vous pouvez réutiliser un seul package de déploiement entre les comptes et AWS les régions.

**Topics**
+ [Conditions préalables](#web-functions-code-s3-requirements)
+ [Autorisations requises](#web-functions-code-s3-permissions)
+ [Création d'une fonction Web avec du code provenant d'Amazon S3](#web-functions-code-s3-creating)
+ [Cycle de vie des objets](#web-functions-code-s3-lifecycle)
+ [Multi-Region déploiements](#web-functions-code-s3-multi-region)

## Conditions préalables
<a name="web-functions-code-s3-requirements"></a>

Avant de déployer le code de fonction Web depuis Amazon S3, assurez-vous que votre compartiment et votre package de déploiement répondent aux exigences suivantes :

Versionnage S3  
La gestion des [versions S3 doit être activée sur le](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html) compartiment. Lambda utilise des versions d'objets pour savoir quelle version de votre code est utilisée par une révision.

ID de version  
Le `versionId` paramètre est facultatif dans la demande. Si vous l'omettez, Lambda utilise la dernière version de l'objet au moment de sa création. Quoi qu'il en soit, Lambda associe la révision à une version d'objet spécifique.

Taille maximale du package de déploiement  
512 Mo (décompressé).

Fichier d'entrée  
Le package de déploiement doit contenir le fichier d'entrée de votre application. Par défaut, le moteur d'exécution `index.js` se charge à la racine du package. Pour utiliser un autre fichier d'entrée, définissez la variable d'`AWS_LAMBDA_NODEJS_ENTRYPOINT`environnement de la révision sur le chemin du fichier par rapport à la racine du package. Après avoir chargé le fichier d'entrée, le moteur d'exécution attend que votre serveur HTTP commence à écouter l'hôte et le port à partir de la variable d'`AWS_LAMBDA_HTTP_ENDPOINT`environnement. Si le moteur d'exécution ne parvient pas à résoudre le fichier d'entrée ou si le serveur ne commence jamais à écouter, l'initialisation échoue et les demandes adressées au point de terminaison échouent.  
Lambda ne vérifie pas que votre serveur commence à écouter lorsqu'il crée ou met à jour un point de terminaison pour utiliser la révision. La révision et le point final peuvent toujours s'afficher `Active` dans ces cas. Après chaque déploiement, envoyez une demande de test et consultez les journaux de votre application.

Emplacement du godet  
Le bucket peut se trouver dans un AWS compte et dans une AWS région différents de ceux de la fonction Web. Le bucket doit se trouver dans la même AWS partition que la fonction Web. Le compartiment ne peut pas se trouver dans une région optionnelle (une région qui n'est pas activée par défaut). Si l'une des conditions n'est pas remplie, Lambda rejette la demande. Cross-Region la récupération d'objets entraîne des coûts de transfert de données supplémentaires sur Amazon S3. Pour plus d’informations sur la tarification, consultez [Tarification Amazon S3](https://aws.amazon.com/s3/pricing/).

## Autorisations requises
<a name="web-functions-code-s3-permissions"></a>

Pour déployer le code de fonction Web depuis Amazon S3, vous devez configurer des autorisations pour l'identité d'appel et pour le principal de service Lambda.

### Autorisations de l'appelant
<a name="web-functions-code-s3-caller-permissions"></a>

Pour créer la fonction Web ou la révision, votre identité IAM a besoin des autorisations suivantes sur l'objet S3 :
+ `s3:GetObject`
+ `s3:GetObjectVersion`

Pour les buckets multicomptes, la politique des compartiments doit également accorder à l'identité appelante l'accès à l'objet.

### Politique relative aux compartiments pour Lambda
<a name="web-functions-code-s3-bucket-policy"></a>

La politique du bucket doit accorder le principal du service Lambda (`lambda.amazonaws.com`) `s3:GetObject` et les `s3:GetObjectVersion` autorisations. Définissez la politique avec une `aws:SourceArn` condition qui correspond au modèle ARN de révision. `ArnLike`À utiliser avec un caractère générique pour l'ID de révision, car Lambda génère l'ID de révision lorsque vous créez la révision.

Si l'objet est chiffré avec une AWS KMS clé (SSE-KMS), la politique des clés doit également `lambda.amazonaws.com` permettre `kms:Decrypt` d'appeler cette clé. Lambda vérifie l'accès du principal du service lorsque vous créez la révision et rejette la demande si l'accès est manquant.

L'exemple de politique de compartiment suivant accorde à Lambda l'accès pour lire vos packages de déploiement pour toute révision de la fonction Web spécifiée.

```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowLambdaWebFunctionCodeAccess",
            "Effect": "Allow",
            "Principal": {
                "Service": "lambda.amazonaws.com"
            },
            "Action": [
                "s3:GetObject",
                "s3:GetObjectVersion"
            ],
            "Resource": "arn:aws:s3:::{{my-bucket}}/*",
            "Condition": {
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:lambda:{{us-east-1}}:{{111122223333}}:web-function/{{my-function}}/revision/*"
                }
            }
        }
    ]
}
```

Pour limiter l'accès au préfixe clé qui contient vos packages de déploiement, remplacez la `Resource` valeur par`arn:aws:s3:::{{my-bucket}}/{{my-prefix}}/*`, où {{my-bucket}} se trouvent le nom de votre bucket et {{my-prefix}} le préfixe clé. Conservez le `/*` à la fin du préfixe. Ne modifiez pas le `revision/*` joker. `aws:SourceArn`

## Création d'une fonction Web avec du code provenant d'Amazon S3
<a name="web-functions-code-s3-creating"></a>

Vous spécifiez votre package de déploiement S3 dans la `codeConfig` section de`buildConfig`. Les procédures suivantes montrent comment créer une fonction Web et comment créer une nouvelle révision à l'aide du AWS CLI.

**Pour créer une fonction Web avec du code provenant d'Amazon S3 (AWS CLI)**
+ Exécutez la commande suivante pour créer une fonction Web qui fait référence à votre package de déploiement .zip dans Amazon S3.

  ```
  aws lambda-web create-web-function \
      --function-name {{my-web-app}} \
      --revision-config '{
        "buildConfig": {
          "codeConfig": {
            "s3Object": { "bucket": "{{my-bucket}}", "key": "{{my-app.zip}}" }
          },
          "runtimeConfig": { "runtime": "nodejs24.x" }
        },
        "serviceConfig": {
          "executionRoleArn": "arn:aws:iam::{{111122223333}}:role/{{my-web-function-role}}"
        }
      }' \
      --endpoint-config '{
        "endpointName": "{{my-endpoint}}",
        "endpointType": "HomeRegion",
        "authType": "ApplicationManaged"
      }'
  ```

  Lorsque vous omettez`versionId`, Lambda utilise la dernière version de l'objet au moment de sa création.

**Pour créer une nouvelle révision avec une version d'objet spécifique (AWS CLI)**
+ Exécutez la commande suivante pour créer une nouvelle révision qui utilise une version spécifique de votre package de déploiement.

  ```
  aws lambda-web create-web-function-revision \
      --function-name {{my-web-app}} \
      --build-config '{
        "codeConfig": {
          "s3Object": {
            "bucket": "{{my-bucket}}",
            "key": "{{my-app.zip}}",
            "versionId": "{{abc123def456}}"
          }
        },
        "runtimeConfig": { "runtime": "nodejs24.x" }
      }' \
      --service-config '{
        "executionRoleArn": "arn:aws:iam::{{111122223333}}:role/{{my-web-function-role}}"
      }'
  ```

  En spécifiant`versionId`, vous épinglez la révision sur une version exacte de l'objet plutôt que sur la dernière version.

## Cycle de vie des objets
<a name="web-functions-code-s3-lifecycle"></a>

**Ne supprimez pas les objets S3 et ne supprimez pas l'accès Lambda pour les révisions actives**  
Lambda référence votre code depuis votre compartiment Amazon S3. Si vous supprimez l'objet S3 utilisé par une révision, ou la version d'objet spécifique utilisée par la révision, la révision passe à l'`Failed`état lorsque Lambda vérifie ensuite l'accès à l'objet, puis ne peut plus desservir le trafic. Conservez les versions des objets pour toutes les révisions que vous utilisez encore.  
La suppression de l'accès du principal du service Lambda au bucket a le même effet. Si vous modifiez la politique de compartiment pour refuser ou supprimer `s3:GetObject` et `s3:GetObjectVersion` les autorisations pour`lambda.amazonaws.com`, les révisions existantes qui font référence aux objets de ce compartiment passent à l'`Failed`état. Conservez à la fois les objets et l'accès en lecture du principal du service Lambda tant qu'une révision fait référence à ces objets.  
L'`Failed`État est permanent. La restauration de l'objet supprimé ou des autorisations du bucket ne renvoie pas de révision à l'`Active`état. Pour effectuer une restauration, créez une nouvelle révision qui fait référence à une version d'objet disponible, puis mettez à jour les poids de révision de vos points de terminaison pour acheminer le trafic vers cette version. Pour les modèles de déploiement, voir[Modèles de déploiement](web-functions-deployment.md).

Lambda ne détourne pas automatiquement le trafic d'une `Failed` révision. Les demandes acheminées par un point de terminaison vers une `Failed` révision sont rejetées avec le code d'état HTTP 409 et un en-tête de `lambda-web-error-type` réponse de`Platform.RevisionNotActive`. Si le point de terminaison pondère le trafic entre plusieurs révisions, seule la part des demandes acheminées vers la `Failed` révision est affectée ; les demandes acheminées vers des révisions saines sont traitées normalement. Pour mettre fin aux échecs, mettez à jour les pondérations de révision du point de terminaison afin de supprimer la `Failed` révision.

Le remplacement de l'objet par un nouveau téléchargement crée une nouvelle version de S3. Cela n'affecte pas les révisions existantes : lorsque vous créez une révision, Lambda résout et épingle la version exacte de l'objet, même si vous l'omettez. `versionId` Toutefois, si vous supprimez une ancienne version d'objet à laquelle une révision fait référence, cette révision passe à l'`Failed`état actuel. Le téléchargement d'un objet de remplacement n'est pas utile, car le remplacement est une nouvelle version avec un ID de version différent.

## Multi-Region déploiements
<a name="web-functions-code-s3-multi-region"></a>

Pour les fonctions Web avec `MultiRegion` ou `PerRegion` points de terminaison, Lambda lit votre objet source à partir du compartiment que vous spécifiez, quelle que soit la région dans laquelle se trouve le compartiment. Lambda réplique ensuite l'artefact de code préparé qu'il dérive de cet objet vers les autres régions. Il n'est pas nécessaire de copier votre package de déploiement dans des compartiments situés dans d'autres régions. Pour plus d'informations sur ce que Lambda réplique, consultez. [Ce que Lambda reproduit](web-functions-endpoint-replication.md#web-functions-endpoint-replication-what)