View a markdown version of this page

Réseaux - AWS Lambda

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

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

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

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, voirRoutage des ports.

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

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

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

  2. 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.

  3. 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

Toutes les demandes adressées à un point de terminaison microVM nécessitent un jeton d'authentification valide dans l'X-aws-proxy-authen-tête. Vous générez des jetons en utilisantcreate-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

Réponses d'erreur

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.

En-têtes de demandes

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

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

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: trueen-tête dans votre demande à utiliser HTTP/2 lors de la connexion à votre application.

Connectivité sortante

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

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

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

Créez un connecteur en spécifiant vos sous-réseaux VPC, vos groupes de sécurité et votre protocole réseau (IPv4ou) : 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

Un connecteur doit être en ACTIVE état pour que vous puissiez le référencerrun-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

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.