

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.

# Réseaux
<a name="microvms-networking"></a>

Vous configurez l'accès réseau pour vos AWS Lambda microVM en associant les ressources du connecteur réseau à votre microVM au moment de l'exécution. Les connecteurs réseau sont spécifiés lorsque vous appelez `run-microvm` et ne peuvent pas être modifiés lorsqu'une microVM est en cours d'exécution.

## Présentation de
<a name="microvms-networking-overview"></a>

Chaque microVM peut avoir des configurations réseau d'entrée (entrante) et de sortie (sortante) indépendantes :
+ Les **connecteurs réseau d'entrée** permettent la connectivité entrante. Les clients se connectent à un point de terminaison HTTPS géré par un service, et Lambda transmet le trafic aux ports que vous configurez au sein de la microVM. Les connecteurs d'entrée sont AWS gérés : vous les référencez par ARN lorsque vous exécutez une microVM.
+ Les **connecteurs réseau de sortie** permettent le trafic sortant. Par défaut, les microVM disposent d'un accès public à Internet. Vous pouvez créer un connecteur de sortie VPC géré par le client pour acheminer le trafic sortant via votre VPC à la place.

Un seul connecteur peut être réutilisé sur de nombreuses microVM. C'est le modèle d'utilisation prévu.

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

Chaque microVM Lambda est accessible via une URL de point de terminaison HTTPS unique, attribuée lorsque vous appelez. `run-microvm` Les clients envoient des demandes à ce point de terminaison via HTTPS. Lambda achemine chaque demande vers un port de votre microVM, où votre application la reçoit.

Par défaut, les demandes reçues sur le point de terminaison sont acheminées vers le port 8080 à l'intérieur de la microVM. Pour effectuer un routage vers un autre port, voir[Routage des ports](#microvms-networking-port-routing).

Les protocoles suivants sont pris en charge sur le point de terminaison entrant :
+ HTTP/1.1
+ HTTP/2
+ WebSockets
+ gRPC
+ Server-Sent Événements (SSE)

**Note**  
Le trafic entre votre client et le point de terminaison microVM est toujours chiffré avec le protocole TLS. Votre application peut traiter des requêtes via HTTP ou HTTPS en interne.

### Routage des ports
<a name="microvms-networking-port-routing"></a>

Lambda sélectionne le port cible à l'intérieur de votre microVM selon l'ordre de priorité suivant :

1. **`X-aws-proxy-port`en-tête** — Pour les requêtes HTTP standard, incluez cet en-tête avec le numéro de port cible.

1. **WebSocket sous-protocole** — Si votre WebSocket client ne parvient pas à définir des en-têtes personnalisés, spécifiez le port cible sous forme de sous-protocole nommé`lambda-microvms.port.{{N}}`, où {{N}} est le numéro de port. Vous fournissez des sous-protocoles lorsque vous ouvrez la WebSocket connexion. Pour obtenir un exemple, consultez [Protocoles](microvms-launching.md#microvms-launching-websocket).

1. **Par défaut (8080)** — Si aucun des deux n'est spécifié, demande la route vers le port 8080.

**Important**  
Le port cible doit être compris dans les limites `allowedPorts` définies dans le jeton d'authentification. Les demandes adressées à des ports non autorisés reçoivent une réponse 403 Forbidden.

### Authentification
<a name="microvms-networking-auth"></a>

Toutes les demandes adressées à un point de terminaison microVM nécessitent un jeton d'authentification valide dans l'`X-aws-proxy-auth`en-tête. Vous générez des jetons en utilisant`create-microvm-auth-token`. Chaque jeton est une chaîne JWE (JSON Web Encryption) cryptée dont la portée est la suivante :
+ Une microVM spécifique (identifiée par un ID).
+ Un ensemble de ports autorisés (port unique, plage ou tous les ports).
+ Un délai d'expiration (configuré lors de la création du jeton).

L'exemple suivant crée un jeton et l'utilise pour envoyer une demande authentifiée :

```
aws lambda-microvms create-microvm-auth-token \
  --microvm-identifier {{microvm-id}} \
  --expiration-in-minutes 30 \
  --allowed-ports '[{"port":8080}]'
```

```
curl 'https://{{microvm-endpoint}}' \
  -H 'X-aws-proxy-auth: {{TOKEN}}' \
  -H 'X-aws-proxy-port: 8080'
```

Pour une présentation complète de la création de jetons et de la connexion à une microVM, y compris WebSocket les connexions, voir. [Connexion à une microVM](microvms-launching.md#microvms-launching-connecting)

### Réponses d'erreur
<a name="microvms-networking-errors"></a>

Les codes d'état HTTP suivants sont renvoyés par le point de terminaison microVM lorsqu'il ne peut pas traiter ou envoyer une demande à votre application. Ces réponses proviennent du point de terminaison, et non de votre application.


| Code | Statut | Cause et résolution | 
| --- | --- | --- | 
| 400 | Demande erronée | Demande mal formée, en-tête de port ou WebSocket sous-protocole non valide. Vérifiez le format. | 
| 403 | Accès interdit | Jeton manquant, expiré ou non valide ; ou le port demandé ne figure pas dans celui du jetonallowedPorts. Générez un nouveau jeton ou utilisez un port autorisé. | 
| 429 | Nombre de demandes trop élevé | Limite de débit dépassée (au niveau du compte ou par microVM). Réessayez avec un recul exponentiel. | 
| 500 | Erreur de serveur interne | Une erreur interne s’est produite. Réitérez la demande. | 
| 502 | Passerelle erronée | L'application ne répond pas ou la reprise automatique n'a pas réussi dans le nombre maximal de tentatives. Consultez [Auto-resume](microvms-launching.md#microvms-launching-auto-resume). | 

### En-têtes de demandes
<a name="microvms-networking-headers"></a>

L'espace de noms `X-aws-proxy-*` d'en-tête est réservé par Lambda aux métadonnées de demande, telles que le jeton d'authentification `X-aws-proxy-auth` () et le port `X-aws-proxy-port` cible (). Lambda supprime les `X-aws-proxy-*` en-têtes avant de transmettre la demande à votre application.

### Request/response bande passante
<a name="microvms-networking-bandwidth"></a>

Chaque microVM Lambda dispose d'une request/response bande passante qui s'adapte linéairement à sa taille. Cette bande passante s'applique à tout le trafic passant par le point de terminaison MicroVM, à la fois aux demandes entrantes et aux réponses sortantes.


| Taille de la microVM (référence) | Bande passante maximale | 
| --- | --- | 
| 0,5 Go, 0,25 vCPU | 1 MB/s (8 Mbits/s) | 
| 1 Go, 0,5 vCPU | 2 MB/s (16 Mbits/s) | 
| 2 Go, 1 vCPU | 4 MB/s (32 Mbits/s) | 
| 4 Go, 2 vCPU | 8 MB/s (64 Mbits/s) | 
| 8 Go, 4 vCPU | 16 MB/s (128 Mbits/s) | 

Si la latence des demandes augmente en raison de la saturation du réseau, réduisez la simultanéité de vos demandes ou la taille de la charge utile, ou sélectionnez une taille de microVM plus grande pour augmenter la bande passante disponible.

### HTTP/2 soutien
<a name="microvms-networking-http2"></a>

Lambda MicroVMS prend en charge HTTP/2 le point de terminaison entrant. Lambda négocie le protocole via ALPN (Application-Layer Protocol Negotiation) lors de la poignée de main TLS, en préférant et en se rabattant sur. HTTP/2 HTTP/1.1 Un HTTP/2-capable client l'utilise automatiquement.

À utiliser HTTP/2 entre le point de terminaison et votre application dans le microVM :
+ **Votre application utilise le protocole TLS** : Lambda HTTP/2 négocie avec votre application via ALPN, puis revient à la solution si elle n'est pas prise HTTP/1.1 en HTTP/2 charge.
+ **Votre application sert du HTTP en texte brut** : incluez l'`X-aws-proxy-force-h2: true`en-tête dans votre demande à utiliser HTTP/2 lors de la connexion à votre application.

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

Par défaut, les microVM Lambda disposent d'un accès Internet public sur le chemin de sortie. Pour connecter des microVM aux ressources de vos VPC privés, telles que le RDS ElastiCache, les API internes et les systèmes sur site via Direct Connect ou VPN, créez un connecteur réseau Lambda avec votre configuration VPC.

Lorsque vous utilisez la sortie VPC, le trafic sortant est soumis aux règles des groupes de sécurité et aux ACL du réseau qui régissent le trafic dans votre VPC.

## Utilisation de connecteurs réseau de sortie
<a name="microvms-networking-connectors"></a>

Les connecteurs réseau de sortie acheminent le trafic sortant de votre microVM via votre VPC. Vous créez un connecteur une fois, puis vous le référencez par ARN lors du démarrage de MicroVMS via la `run-microvm` commande.

### Conditions préalables
<a name="microvms-networking-connectors-prereqs"></a>

Avant de créer un connecteur réseau, vous avez besoin d'un rôle IAM qui permet à Lambda de créer des interfaces réseau élastiques (ENI) dans votre VPC. Ce rôle requiert les autorisations suivantes :

```
{
  "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 réseau
<a name="microvms-networking-connectors-create"></a>

Créez un connecteur en spécifiant vos sous-réseaux VPC, vos groupes de sécurité et votre protocole réseau (`IPv4`ou) : `DualStack`

```
aws lambda-core create-network-connector \
  --name my-connector \
  --configuration '{
    "VpcEgressConfiguration": {
      "SubnetIds": ["{{subnet-xxx}}"],
      "SecurityGroupIds": ["{{sg-xxx}}"],
      "NetworkProtocol": "IPv4",
      "AssociatedComputeResourceTypes": ["MicroVm"]
    }
  }' \
  --operator-role arn:aws:iam::{{123456789012}}:role/NetworkConnectorOperatorRole
```

### États du connecteur réseau
<a name="microvms-networking-connectors-states"></a>

Un connecteur doit être en `ACTIVE` état pour que vous puissiez le référencer`run-microvm`.


| State | Description | 
| --- | --- | 
| PENDING | Le connecteur est en cours de création (les ENI sous-jacents sont en cours de provisionnement). | 
| ACTIVE | Le connecteur est prêt à être utilisé. | 
| INACTIVE | Le connecteur est temporairement inactif. | 
| FAILED | Le provisionnement ou la mise à jour ont échoué. Vérifiez StateReason. | 
| DELETING | Le connecteur est en cours de suppression ; les ENI sont en cours de nettoyage. | 
| DELETE\_FAILED | La suppression a échoué. | 

### Exécution d'une microVM avec un connecteur réseau
<a name="microvms-networking-connectors-run"></a>

Référencez l'ARN du connecteur lors de l'exécution d'une microVM :

```
aws lambda-microvms run-microvm \
  --image-identifier arn:aws:lambda:us-east-1:{{123456789012}}:microvm-image:my-microvm-image \
  --egress-network-connectors {{connector-arn}} \
  --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":1800,"autoResumeEnabled":false}'
```

**Note**  
Avant de mettre à jour ou de supprimer un connecteur, assurez-vous que toutes les microVM qui l'utilisent sont hors service. La modification d'un connecteur activement utilisé peut entraîner des problèmes de connectivité réseau lors de l'exécution de microVM.