Red
El acceso de red de las MicroVM de AWS Lambda se configura mediante la asociación de recursos de conector de red a la MicroVM en el momento de la ejecución. Los conectores de red se especifican al llamar a run-microvm y no se pueden modificar mientras una MicroVM está en ejecución.
Descripción general
Cada MicroVM puede tener configuraciones de red independientes para la entrada (tráfico entrante) y la salida (tráfico saliente):
-
Conectores de red de entrada: habilitan la conectividad entrante. Los clientes se conectan a un punto de conexión HTTPS administrado por el servicio y Lambda reenvía el tráfico a los puertos configurados en la MicroVM. Los conectores de entrada están administrados por AWS. Al ejecutar una MicroVM, se hace referencia a estos mediante su ARN.
-
Conectores de red de salida: habilitan el tráfico saliente. De forma predeterminada, las MicroVM tienen acceso público a Internet. Puede crear un conector de salida de VPC administrado por el cliente para, en su lugar, enrutar el tráfico saliente a través de la VPC.
Un mismo conector se puede reutilizar en varias MicroVM. Este es el patrón de uso previsto.
Conectividad entrante
Cada MicroVM de Lambda está disponible mediante una URL única de punto de conexión HTTPS, que se asigna al llamar a run-microvm. Los clientes envían solicitudes a este punto de conexión mediante HTTPS. Lambda enruta cada solicitud a un puerto dentro de la MicroVM, donde la aplicación la recibe.
De forma predeterminada, las solicitudes que recibe el punto de conexión se enrutan al puerto 8080 dentro de la MicroVM. Para enrutar las solicitudes a otro puerto, consulte Enrutamiento de puertos.
El punto de conexión de entrada admite los siguientes protocolos:
-
HTTP/1.1
-
HTTP/2
-
WebSockets
-
gRPC
-
Eventos enviados por el servidor (SSE)
nota
El tráfico entre el cliente y el punto de conexión de la MicroVM siempre se cifra mediante TLS. La aplicación puede atender solicitudes internamente mediante HTTP o HTTPS.
Enrutamiento de puertos
Lambda selecciona el puerto de destino dentro de la MicroVM según el siguiente orden de prioridad:
-
Encabezado
X-aws-proxy-port: para las solicitudes HTTP estándar, incluya este encabezado con el número del puerto de destino. -
Subprotocolo WebSocket: si el cliente WebSocket no puede establecer encabezados personalizados, especifique el puerto de destino como un subprotocolo denominado
lambda-microvms.port., dondeNNes el número de puerto. Los subprotocolos se proporcionan al abrir la conexión WebSocket. Para ver un ejemplo, consulta Protocolos. -
Valor predeterminado (8080): si no se especifica ninguno de los dos, las solicitudes se enrutan al puerto 8080.
importante
El puerto de destino se debe encontrar dentro de los allowedPorts definidos en el token de autenticación. Las solicitudes dirigidas a puertos no autorizados reciben una respuesta 403 Prohibido.
Autenticación
Todas las solicitudes a un punto de conexión de MicroVM requieren un token de autenticación válido en el encabezado X-aws-proxy-auth. Los tokens se generan mediante create-microvm-auth-token. Cada token es una cadena cifrada de cifrado web de JSON (JWE) cuyo alcance se limita a:
-
Una MicroVM específica, identificada mediante su ID.
-
Un conjunto de puertos permitidos, ya sea un solo puerto, un intervalo o todos los puertos.
-
Una hora de vencimiento, configurada al crear el token.
En el siguiente ejemplo se crea un token y se utiliza para enviar una solicitud autenticada:
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'
Para obtener una guía completa sobre la creación de tokens y la conexión a una MicroVM, incluidas las conexiones WebSocket, consulte Conexión a una MicroVM.
Respuestas de error
El punto de conexión de la MicroVM devuelve los siguientes códigos de estado HTTP cuando no puede procesar una solicitud ni entregarla a la aplicación. Estas respuestas proceden del punto de conexión, no de la aplicación.
| Código | Status | Causa y resolución |
|---|---|---|
| 400 | solicitud errónea | Solicitud con formato incorrecto, encabezado de puerto no válido o subprotocolo WebSocket no válido. Compruebe el formato. |
| 403 | Prohibido | El token no está presente, ha vencido o no es válido; o bien, el puerto solicitado no está incluido en los allowedPorts del token. Genere un nuevo token o use un puerto permitido. |
| 429 | Demasiadas solicitudes | Se superó el límite de solicitudes, ya sea en el nivel de la cuenta o por MicroVM. Vuelva a intentarlo con retroceso exponencial. |
| 500 | Internal Server Error | Se ha producido un error interno. Intente realizar de nuevo la solicitud. |
| 502 | Puerta de enlace incorrecta | La aplicación no responde o la reanudación automática no se completó correctamente dentro del número máximo de reintentos. Consulte Reanudación automática. |
Encabezados de solicitudes
Lambda reserva el espacio de nombres de los encabezados X-aws-proxy-* para los metadatos de las solicitudes, como el token de autenticación (X-aws-proxy-auth) y el puerto de destino (X-aws-proxy-port). Lambda elimina los encabezados X-aws-proxy-* antes de reenviar la solicitud a la aplicación.
Ancho de banda de solicitudes y respuestas
Cada MicroVM de Lambda tiene un ancho de banda de solicitudes y respuestas que escala linealmente con su tamaño. Este ancho de banda se aplica a todo el tráfico que pasa por el punto de conexión de la MicroVM, tanto a las solicitudes entrantes como a las respuestas salientes.
| Tamaño de la MicroVM (valor de referencia) | Ancho de banda máximo |
|---|---|
| 0,5 GB; 0,25 vCPU | 1 MB/s (8 Mbps) |
| 1 GB; 0,5 vCPU | 2 MB/s; (16 Mbps) |
| 2 GB; 1 vCPU | 4 MB/s; (32 Mbps) |
| 4 GB; 2 vCPU | 8 MB/s; (64 Mbps) |
| 8 GB; 4 vCPU | 16 MB/s; (128 Mbps) |
Si aumenta la latencia de las solicitudes debido a la saturación de la red, reduzca la simultaneidad de solicitudes o el tamaño de la carga útil, o bien, cambie a un tamaño de MicroVM mayor para aumentar el ancho de banda disponible.
Compatibilidad con HTTP/2
Las MicroVM de Lambda admiten HTTP/2 en el punto de conexión de entrada. Lambda negocia el protocolo mediante ALPN (negociación de protocolos de capa de aplicación) durante el establecimiento de comunicación TLS. Da prioridad a HTTP/2 y recurre a HTTP/1.1 si es necesario. Los clientes compatibles con HTTP/2 lo utilizan automáticamente.
Para usar HTTP/2 entre el punto de conexión y la aplicación dentro de la MicroVM:
-
La aplicación usa TLS: Lambda negocia HTTP/2 con la aplicación mediante ALPN y recurre a HTTP/1.1 si la aplicación no admite HTTP/2.
-
La aplicación atiende solicitudes mediante HTTP en texto plano: incluya el encabezado
X-aws-proxy-force-h2: trueen la solicitud para usar HTTP/2 en la conexión con la aplicación.
Conectividad saliente
De forma predeterminada, las MicroVM de Lambda tienen acceso público a Internet en la ruta de salida. Para conectar las MicroVM con recursos de las VPC privadas, como RDS, ElastiCache, las API internas y los sistemas en las instalaciones mediante Direct Connect o una VPN, cree un conector de red de Lambda con la configuración de la VPC.
Cuando se usa la salida de VPC, el tráfico saliente está sujeto a las reglas de los grupos de seguridad y a las listas de control de acceso (ACL) de red que regulan el tráfico de la VPC.
Uso de los conectores de red de salida
Los conectores de red de salida enrutan el tráfico saliente de la MicroVM a través de la VPC. El conector se crea una sola vez y, posteriormente, se hace referencia a este mediante su ARN al iniciar las MicroVM con el comando run-microvm.
Requisitos previos
Antes de crear un conector de red, se necesita un rol de IAM que permita a Lambda crear interfaces de red elásticas (ENI) en la VPC. El rol requiere los siguientes permisos:
{ "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" } } } ] }
Creación de un conector de red
Para crear un conector, especifique las subredes y los grupos de seguridad de la VPC, así como el protocolo de red (IPv4 o 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
Estados de los conectores de red
Un conector se debe encontrar en el estado ACTIVE antes de poder hacer referencia a este en run-microvm.
| Estado | Descripción |
|---|---|
PENDING |
El conector está en proceso de creación (las ENI subyacentes están en proceso de aprovisionamiento). |
ACTIVE |
El conector está listo para su uso. |
INACTIVE |
El conector está inactivo temporalmente. |
FAILED |
Se produjo un error en el aprovisionamiento o la actualización. Compruebe lo siguiente StateReason. |
DELETING |
El conector está en proceso de eliminación; se realiza la limpieza de las ENI. |
DELETE_FAILED |
Se produjo un error en la eliminación. |
Ejecución de una MicroVM con un conector de red
Al ejecutar una MicroVM, haga referencia al ARN del conector:
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}'
nota
Antes de actualizar o eliminar un conector, compruebe que se hayan terminado todas las MicroVM que lo utilizan. La modificación de un conector que se encuentra en uso puede causar problemas de conectividad de red en las MicroVM en ejecución.