

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.

# Configuration de la mise en réseau pour AWS Lambda Fonctions Web
<a name="web-functions-networking"></a>

Une fonction Web accepte les demandes des clients. Il peut également accéder à d'autres ressources pour effectuer son travail, comme une base de données dans votre VPC, une API interne ou un service sur Internet public. Vous configurez ces deux directions indépendamment. Vous pouvez exposer un point de terminaison aux appelants sans lui accorder un accès VPC, ou accorder à une fonction un accès sortant privé sans changer qui peut l'invoquer.

Le trafic entrant atteint une fonction Web via un point de terminaison. Le point de terminaison définit son nom de domaine, son type de point de terminaison, ses régions et sa configuration d'autorisation. Le trafic sortant est configuré lors d'une révision. Une révision sans connecteur réseau de sortie atteint directement les `IPv4` destinations publiques. Une révision qui fait référence à un connecteur envoie son trafic sortant via votre VPC. Une fonction Web s'exécute sur une infrastructure que Lambda possède et gère, et non au sein de votre VPC. Un connecteur réseau de sortie ajoute uniquement un accès VPC sortant. Cela ne change pas la manière dont les clients atteignent le point de terminaison ni les personnes autorisées à l'invoquer.

**Note**  
Les noms de domaine des points de terminaison Web Function sont accessibles depuis l'Internet public. AWS PrivateLink les points de terminaison d'interface ne sont pas disponibles pour les noms de domaine de point de terminaison des fonctions Web. Utilisez la configuration d'autorisation du terminal pour contrôler l'accès.

## Connectivité entrante
<a name="web-functions-networking-inbound"></a>

Les clients invoquent une fonction Web via un point de terminaison HTTPS Lambda-managed public. Lambda met fin au protocole TLS et transmet la demande au serveur HTTP de votre application. Le point de terminaison géré prend en charge HTTP/1.1. Il n'expose pas d'adresse VPC privée et n'accepte pas de connexions directes à l'environnement d'exécution.

`IamAuth`contrôle qui peut invoquer un point de terminaison, mais cela ne rend pas le point de terminaison privé au niveau de la couche réseau. Pour les options d'autorisation, voir[Contrôle d'accès aux terminaux Lambda Web Function](web-functions-endpoint-access-control.md).

Le point de terminaison contrôle le routage, l'autorisation, la régulation et le dimensionnement des demandes. Son type de point de terminaison et son ensemble de régions sont fixes lorsque vous le créez. Pour modifier l'une ou l'autre des propriétés, créez un nouveau point de terminaison et déplacez les clients vers son nouveau nom de domaine.

La configuration du point de terminaison est indépendante de la sortie du VPC. L'ajout d'un connecteur réseau de sortie à une révision ne rend pas le point de terminaison privé et ne limite pas les demandes entrantes.

**Important**  
Vous ne pouvez utiliser les connecteurs réseau de sortie qu'avec des points de `HomeRegion` terminaison. Lambda rejette les tentatives de routage d'un `MultiRegion` point de `PerRegion` terminaison vers une révision qui fait référence à un connecteur réseau de sortie.

Lorsque les pondérations de révision répartissent le trafic entre des révisions avec des configurations de connecteurs différentes, les demandes utilisent des chemins réseau différents. Lorsque vous diagnostiquez une connectivité intermittente, vérifiez d'abord le mode de déploiement automatique du terminal et les pondérations de révision. Pour savoir comment ils acheminent les demandes vers les révisions, voir[Modèles de déploiement](web-functions-deployment.md).

### Ajouter une porte d'entrée HTTP devant un point de terminaison
<a name="web-functions-networking-front-door"></a>

Une porte d'entrée est un service qui reçoit les demandes des clients et les transmet à votre terminal. Il ajoute des fonctionnalités telles qu'un domaine personnalisé, la mise en cache ou la protection par pare-feu des applications Web. Les points de terminaison Web Function ne prennent pas en charge les noms de domaine personnalisés ni AWS WAF l'association directe. Utilisez Amazon CloudFront devant le point de terminaison lorsque vous avez besoin d'un domaine personnalisé, d'une mise en cache périphérique, HTTP/2 ou HTTP/3 entre le lecteur et le périphérique, d'une compression des réponses ou de AWS WAF contrôles.

Le schéma suivant montre une porte d'entrée de production. Un client se connecte à un domaine CloudFront personnalisé protégé par AWS WAF. CloudFront envoie la demande à un point de terminaison de fonction Web protégé, qui l'achemine vers un environnement d'exécution. Sans connecteur réseau de sortie, l'application peut appeler le AWS service public ou des points de terminaison Internet. Il ne peut pas accéder aux ressources qui n'ont que des adresses VPC privées. Pour accéder à ces ressources, voir[Connexion d'une fonction Web à votre VPC](#web-functions-networking-vpc). Avec`IamAuth`, CloudFront signe chaque demande d'origine et Lambda autorise la demande avant d'appeler votre fonction. Lambda préserve l'`Authorization`en-tête original du visualiseur et le transmet à votre fonction. Le Lambda-provided domaine accepte uniquement les demandes signées émanant des principaux autorisés à l'invoquer, et rejette les demandes directes non signées, telles qu'un navigateur appelant directement le domaine. Pour vous assurer que le point de terminaison accepte uniquement les appels provenant de votre distribution, ajoutez une politique basée sur les ressources qui accorde l'autorisation d'appel au principal du CloudFront service et l'étend au nom de ressource Amazon (ARN) de votre distribution avec une condition d'ARN source. Avec`ApplicationManaged`, le point de terminaison est public et les demandes directes contournent CloudFront et AWS WAF.

![Les spectateurs se connectent à une CloudFront distribution avec votre domaine personnalisé, protégé par AWS WAF. CloudFront signe les demandes d'origine à un point de terminaison de fonction Web qui utilise IamAuth. Les demandes directes non signées adressées au Lambda-provided domaine sont rejetées.](https://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/web-functions-production-front-door.png)


1. Configurez le domaine Web Function en tant qu'origine personnalisée HTTPS.

1. Joignez le certificat et le nom de domaine alternatif à la distribution, et faites pointer les enregistrements de votre système de noms de domaine (DNS) vers la distribution.

1. Transférez uniquement les en-têtes, les cookies et les chaînes de requête dont l'application a besoin. Ne transférez pas l'`Host`en-tête du visualiseur, car Lambda achemine `Host` et renvoie HTTP 404 lorsqu'il ne s'agit pas du domaine du point de terminaison. Si vous utilisez une politique de demande d'origine gérée qui transmet tous les en-têtes des lecteurs, choisissez`AllViewerExceptHostHeader`. Les limites d'en-têtes de point de terminaison incluent les en-têtes transférés.

1. (Facultatif) Joignez une ACL AWS WAF Web lorsque vous avez besoin d'une inspection par IP, par bot, basée sur le taux ou par règles gérées.

1. Protégez l'origine afin que les clients ne puissent pas contourner la distribution. Pour un IAM-authorized point de terminaison, accordez l'accès uniquement à l'identité d'entrée prévue. Pour une autorisation gérée par l'application, exigez et validez un secret d'origine ou une autre preuve au niveau de l'application attestant que la demande est bien passée par la distribution.

Pour la procédure CloudFront d'autorisation, voir[CloudFront intégration](web-functions-endpoint-access-control.md#web-functions-endpoint-access-control-cloudfront).

### Accès au navigateur et CORS
<a name="web-functions-networking-cors"></a>

Lambda n'ajoute pas d'en-têtes CORS ( Cross-Origin Resource Sharing) pour les fonctions Web. Votre demande ou votre porte d'entrée doit traiter les demandes avant le vol et les demandes réelles.
+ Renvoie l'origine autorisée au lieu de refléter chaque `Origin` valeur.
+ N'autorisez que les méthodes et les en-têtes de requête utilisés par l'application.
+ Lorsque les navigateurs envoient des informations d'identification, utilisez une origine explicite et retournez`Access-Control-Allow-Credentials: true`. Ne combinez pas les informations d'identification avec une origine générique.
+ Testez `OPTIONS` les demandes avant le vol séparément de la méthode d'application.
+ Authentifiez et autorisez chaque demande protégée. Le CORS n'est pas un contrôle d'authentification.

### Limitations du streaming et du protocole
<a name="web-functions-networking-protocols"></a>

Les fonctions Web transmettent les corps des demandes à votre application au fur et à mesure qu'ils arrivent et retransmettent les réponses au client HTTP/1.1. Le chemin de la demande est semi-duplex : Lambda transmet le corps complet de la demande avant de fournir la réponse de votre application. Lisez le corps de la demande dans son intégralité avant de rédiger la réponse. Réglé `timeoutSeconds` pour couvrir le streaming dans les deux sens : réception du corps de la demande et envoi de la réponse. Lorsque le délai est écoulé, Lambda met fin à la réponse. Le client reçoit le code de statut déjà envoyé, avec un corps tronqué. Arrêtez le travail en amont lorsque le client se déconnecte.

Lambda ne prend pas en charge WebSocket les mises à niveau. Lambda supprime les en-têtes de mise à niveau spécifiques à la connexion avant de transférer la demande. Utilisez des événements envoyés par le serveur lorsque le streaming unidirectionnel de serveur à client est suffisant.

Pour le contrat complet d'en-tête et de méthode, voir[Requêtes et réponses HTTP](web-functions-http.md).

## Connectivité sortante
<a name="web-functions-networking-outbound"></a>

Vous choisissez le chemin du réseau sortant pour chaque révision.
+ Sans connecteur réseau de sortie : la révision atteint directement les `IPv4` destinations publiques sans passer par votre VPC. L'adresse source est Lambda-managed, n'est pas stable et ne convient pas à une liste d'autorisations. La révision n'a aucune route vers les ressources privées de votre VPC.
+ Avec un connecteur réseau de sortie : la révision envoie le trafic sortant via des interfaces réseau élastiques situées dans les sous-réseaux du connecteur. Vos tables de routage, groupes de sécurité et listes de contrôle d'accès réseau (ACL) VPC s'appliquent. Utilisez cette option pour accéder à des ressources VPC privées, à des réseaux locaux connectés via un VPN Direct Connect ou à des destinations nécessitant du trafic provenant de votre espace d'adressage.

Le référencement d'un connecteur remplace le chemin sortant par défaut. Un connecteur place le trafic dans votre VPC, mais il ne fournit pas d'accès à Internet. Pour atteindre des `IPv4` destinations publiques, les sous-réseaux du connecteur ont besoin d'une route vers une passerelle NAT. Pour atteindre des `IPv6` destinations publiques, ils ont besoin d'un itinéraire vers une passerelle Internet de sortie uniquement.

Il n'existe aucune adresse IP source stable pour le trafic du connecteur. Configurez les groupes de sécurité de destination pour autoriser les groupes de sécurité du connecteur. Si une destination ne prend pas en charge les références aux groupes de sécurité, autorisez les blocs CIDR du sous-réseau du connecteur au lieu d'une adresse individuelle.

Lambda exécute les opérations de connecteur de manière asynchrone. Un connecteur indique `PENDING` lorsque Lambda crée ses interfaces réseau et `ACTIVE` quand les révisions peuvent y faire référence. Les autres états incluent `INACTIVE``FAILED`,`DELETING`, et`DELETE_FAILED`.

Après une mise à jour`InProgress`, `LastUpdateStatus` recherchez`Successful`, ou`Failed`. Si une opération échoue, utilisez le motif de l'état et le code du motif pour identifier le sous-réseau, le groupe de sécurité, les autorisations ou la capacité de l'adresse IP concernés.

### Résolution DNS
<a name="web-functions-networking-dns"></a>

Pour les noms DNS privés, activez le support DNS et les noms d'hôte DNS dans le VPC du connecteur. Associez toutes les zones hébergées privées Route 53 requises à ce VPC.

Chaque environnement d'exécution met en cache les réponses DNS. Après avoir modifié un enregistrement DNS, les environnements existants continuent d'utiliser l'ancienne réponse jusqu'à ce que la valeur mise en cache expire ou que Lambda remplace l'environnement. Pour forcer un déploiement impeccable, créez une nouvelle révision et transférez le trafic des terminaux vers celle-ci.

Lors du dépannage, testez séparément la résolution des noms et l'accessibilité au réseau. Connectez-vous à une destination par adresse IP pour vérifier le chemin réseau, puis testez son nom DNS.

## Connexion d'une fonction Web à votre VPC
<a name="web-functions-networking-vpc"></a>

Un connecteur réseau de sortie est une ressource Lambda réutilisable. Vous créez le connecteur une seule fois et vous référencez une version publiée du connecteur à partir de chaque révision de fonction Web nécessitant un accès VPC.

Pour les fonctions Web, la référence du connecteur possède les propriétés suivantes :
+ Une révision fait référence à zéro ou à un connecteur.
+ L'ARN du connecteur doit inclure un qualificatif de version.
+ Le connecteur doit se trouver dans le même AWS compte et dans la même région que la fonction Web.
+ Le connecteur doit avoir `WebFunction` comme type de ressource de calcul associé.
+ Seul un `HomeRegion` point de terminaison prend en charge les révisions qui font référence à un connecteur réseau de sortie.
+ Vous ne pouvez pas modifier la référence une fois que vous l'avez définie. Pour l'ajouter, le modifier ou le supprimer, créez une nouvelle révision.

### Conditions préalables
<a name="web-functions-networking-vpc-prerequisites"></a>

Avant de créer le connecteur :
+ Choisissez au moins deux sous-réseaux dans différentes zones de disponibilité avec des adresses IP disponibles.
+ Choisissez les groupes de sécurité qui autorisent le trafic sortant requis.
+ Autorisez le trafic entrant en provenance des groupes de sécurité du connecteur sur chaque destination.
+ Configurez les itinéraires depuis les sous-réseaux du connecteur vers les destinations privées, locales ou publiques requises.
+ Créez un rôle d'opérateur qui accorde à Lambda l'autorisation de gérer les interfaces réseau.
+ Assurez-vous que l'identité qui crée le connecteur et la révision possède les autorisations nécessaires[Autorisations pour configurer le réseau](web-functions-permissions.md#web-functions-permissions-networking), y compris `lambda:PassNetworkConnector` sur le connecteur et `iam:PassRole` sur le rôle d'opérateur.

Le rôle d'opérateur du connecteur et le rôle d'exécution de la révision ont des objectifs différents. Le rôle d'opérateur gère les interfaces réseau de votre VPC. Le rôle d'exécution autorise votre application à appeler AWS des API. Vous n'ajoutez pas d'autorisations d'interface réseau du connecteur au rôle d'exécution.

### Autorisations relatives au rôle d'opérateur
<a name="web-functions-networking-vpc-operator-role"></a>

Lambda assume le rôle d'opérateur du connecteur pour gérer les interfaces réseau du connecteur. La politique de confiance du rôle doit permettre au principal du service Lambda de `lambda.amazonaws.com` l'assumer :

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

Associez une politique d'autorisation telle que la suivante au rôle d'opérateur du connecteur. Cette politique permet à Lambda de créer et de baliser les interfaces réseau du connecteur :

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CreateENI",
      "Effect": "Allow",
      "Action": "ec2:CreateNetworkInterface",
      "Resource": [
        "arn:aws:ec2:*:*:network-interface/*",
        "arn:aws:ec2:*:*:subnet/*",
        "arn:aws:ec2:*:*:security-group/*"
      ]
    },
    {
      "Sid": "TagENI",
      "Effect": "Allow",
      "Action": "ec2:CreateTags",
      "Resource": "arn:aws:ec2:*:*:network-interface/*",
      "Condition": {
        "StringEquals": {
          "ec2:ManagedResourceOperator": "network-connectors.lambda.amazonaws.com"
        }
      }
    }
  ]
}
```

### Création d’un connecteur
<a name="web-functions-networking-vpc-create-connector"></a>

La AWS CLI commande suivante crée un `IPv4` connecteur pour Web Functions. Remplacez le nom du connecteur, les ID de sous-réseau, l'ID du groupe de sécurité et l'ARN du rôle d'opérateur par vos propres valeurs.

```
aws lambda-core create-network-connector \
  --name my-connector \
  --configuration '{
    "VpcEgressConfiguration": {
      "SubnetIds": [
        "subnet-0ab1c2d3e4f5a6b78",
        "subnet-1bc2d3e4f5a6b7c89"
      ],
      "SecurityGroupIds": ["sg-0123456789abcdef0"],
      "NetworkProtocol": "IPv4",
      "AssociatedComputeResourceTypes": ["WebFunction"]
    }
  }' \
  --operator-role arn:aws:iam::123456789012:role/NetworkConnectorOperatorRole
```

Un connecteur prend en charge un type de ressource de calcul. Un connecteur pour Web Functions ne prend pas en charge un autre type de calcul Lambda, et son type de ressource de calcul est immuable.

Lambda crée le connecteur de manière asynchrone. Utilisez cette `get-network-connector` option pour attendre que ce `State` soit `ACTIVE` le cas et notez le numéro de version actuel.

### Référencer le connecteur à partir d'une révision
<a name="web-functions-networking-vpc-reference-revision"></a>

`serviceConfig.egressNetworkConnectorArn`Défini lorsque vous créez la première révision de la fonction Web ou une révision ultérieure. Utilisez un ARN qualifié par version :

```
arn:aws:lambda:us-east-1:123456789012:network-connector:nc-0a1b2c3d4e5f6a7b8:4
```

La AWS CLI commande suivante crée une révision qui fait référence à la version 4 du connecteur. Remplacez le nom de la fonction, l'ARN du rôle d'exécution, l'ARN du connecteur et la région par vos propres valeurs.

```
aws lambda-web create-web-function-revision \
  --function-name my-web-function \
  --build-config file://build-config.json \
  --service-config '{
    "executionRoleArn": "arn:aws:iam::123456789012:role/WebFunctionExecutionRole",
    "timeoutSeconds": 30,
    "egressNetworkConnectorArn": "arn:aws:lambda:us-east-1:123456789012:network-connector:nc-0a1b2c3d4e5f6a7b8:4"
  }' \
  --region us-east-1
```

Un ARN, un nom de connecteur ou un ID de connecteur non qualifié ne sont pas acceptés lors d'une révision. Après avoir créé la révision :
+ Attendez que l'état de la révision soit atteint`Active`.
+ Lisez la révision et confirmez qu'elle `egressNetworkConnectorArn` contient la version de connecteur attendue.
+ Vérifiez que le point de terminaison achemine le trafic vers la révision. Un `HomeRegion` point de terminaison en `LatestRevision` mode récupère automatiquement la dernière révision active. Pour un point de terminaison en `Disabled` mode, mettez à jour ses pondérations de révision.
+ Testez une destination VPC et confirmez le trafic à l'aide des journaux de flux VPC.

Le mode de déploiement automatique du terminal détermine si la création d'une révision active met automatiquement à jour le routage. Dans tous les modes, vérifiez quelle version est diffusée avant de tester son connecteur.

## Mettre à jour ou supprimer la connectivité VPC
<a name="web-functions-networking-update-remove"></a>

La mise à jour d'un connecteur entraîne la publication d'une nouvelle version. Les révisions existantes restent associées à la version dans l'ARN de leur connecteur.

Pour effectuer un changement de connecteur, procédez comme suit :
+ Mettez à jour le connecteur avec`update-network-connector`. Le connecteur doit être`ACTIVE`. Fournissez l'intégralité`VpcEgressConfiguration`, y compris tous les ID de sous-réseau et de groupe de sécurité que vous souhaitez conserver, car la mise à jour remplace la configuration existante.
+ Attendez que le connecteur `LastUpdateStatus` devienne`Successful`.
+ Procurez-vous la nouvelle version du connecteur.
+ Créez une révision qui fait référence à l'ARN qualifié pour la nouvelle version.
+ Pour un `HomeRegion` point de terminaison en `LatestRevision` mode, vérifiez qu'il a bien pris en compte la nouvelle révision active. Pour un point de terminaison en `Disabled` mode, déplacez le trafic en mettant à jour ses pondérations de révision.

La mise à jour du connecteur sans créer de révision faisant référence à sa nouvelle version ne modifie pas la configuration réseau des fonctions Web en cours d'exécution.

Pour supprimer la connectivité VPC, créez une révision sans. `egressNetworkConnectorArn` Un `HomeRegion` point de terminaison en `LatestRevision` mode le récupère lorsqu'il devient actif. Pour un point de terminaison en `Disabled` mode, déplacez le trafic en mettant à jour ses pondérations de révision. La nouvelle révision utilise une `IPv4` sortie Lambda-managed publique et ne dispose plus d'un accès VPC privé.

**Note**  
Avant de supprimer un connecteur réseau de sortie, éloignez le trafic du point de terminaison de chaque révision de fonction Web qui fait référence à une version du connecteur, puis supprimez ces révisions. La suppression d'un connecteur alors qu'une révision active y fait toujours référence interrompt la connectivité réseau pour les environnements d'exécution existants et nouveaux desservant cette révision.

## Prise en charge d’IPv6
<a name="web-functions-networking-ipv6"></a>

Le chemin sortant par défaut et un support de `IPv4` connecteur `IPv4` uniquement. Pour l'utiliser`IPv6`, configurez le connecteur avec la `NetworkProtocol` valeur définie sur`DualStack`.

Pour une connectivité à double pile :
+ Les sous-réseaux du VPC et du connecteur doivent comporter `IPv6` des blocs CIDR.
+ Les tables de routage doivent contenir des itinéraires pour les `IPv6` destinations requises.
+ Les groupes de sécurité et les ACL réseau doivent autoriser `IPv6` le trafic.
+ `IPv6`L'accès public nécessite une route : :/0 vers une passerelle Internet de sortie uniquement.
+ Référencez la version du connecteur créée lorsque vous avez mis à jour le connecteur vers`DualStack`.

Ne déterminez pas `IPv6` la disponibilité en inspectant les interfaces au sein d'un environnement d'exécution. Vérifiez-le en établissant une `IPv6` connexion à partir du code de l'application et en consultant les journaux de flux VPC.