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 :
-
X-aws-proxy-porten-tête — Pour les requêtes HTTP standard, incluez cet en-tête avec le numéro de port cible. -
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., oùNNest le numéro de port. Vous fournissez des sous-protocoles lorsque vous ouvrez la WebSocket connexion. Pour obtenir un exemple, consultez Protocoles. -
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-identifiermicrovm-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-connectorsconnector-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.