View a markdown version of this page

Red - AWS Lambda

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:

  1. Encabezado X-aws-proxy-port: para las solicitudes HTTP estándar, incluya este encabezado con el número del puerto de destino.

  2. Subprotocolo WebSocket: si el cliente WebSocket no puede establecer encabezados personalizados, especifique el puerto de destino como un subprotocolo denominado lambda-microvms.port.N, donde N es el número de puerto. Los subprotocolos se proporcionan al abrir la conexión WebSocket. Para ver un ejemplo, consulta Protocolos.

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

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: true en 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-connectors connector-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.