Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Networking

You configure network access for your Amazon Lambda MicroVMs by associating Network Connector resources with your MicroVM at run time. Network connectors are specified when you call run-microvm and cannot be changed while a MicroVM is running.

Overview

Each MicroVM can have independent ingress (inbound) and egress (outbound) network configurations:

A single connector can be reused across many MicroVMs – this is the intended usage pattern.

Inbound connectivity

Each Lambda MicroVM is reachable at a unique HTTPS endpoint URL, assigned when you call run-microvm. Clients send requests to this endpoint over HTTPS. Lambda routes each request to a port inside your MicroVM, where your application receives it.

By default, requests received at the endpoint are routed to port 8080 inside the MicroVM. To route to a different port, see Port routing.

The following protocols are supported on the inbound endpoint:

Port routing

Lambda selects the target port inside your MicroVM using the following order of priority:

Authentication

All requests to a MicroVM endpoint require a valid authentication token in the X-aws-proxy-auth header. You generate tokens using create-microvm-auth-token. Each token is an encrypted JWE (JSON Web Encryption) string scoped to:

The following example creates a token and uses it to send an authenticated request:

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'

For a complete walkthrough of creating tokens and connecting to a MicroVM, including WebSocket connections, see Connecting to a MicroVM.

Error responses

The following HTTP status codes are returned by the MicroVM endpoint when it cannot process or deliver a request to your application. These responses come from the endpoint, not from your application.

Request headers

The X-aws-proxy-* header namespace is reserved by Lambda for request metadata, such as the authentication token (X-aws-proxy-auth) and target port (X-aws-proxy-port). Lambda removes X-aws-proxy-* headers before forwarding the request to your application.

Request/response bandwidth

Each Lambda MicroVM has a request/response bandwidth that scales linearly with its size. This bandwidth applies to all traffic through the MicroVM endpoint, both inbound requests and outbound responses.

If you experience increased request latency due to network saturation, either reduce your request concurrency or payload size, or select a larger MicroVM size to increase the available bandwidth.

HTTP/2 support

Lambda MicroVMs supports HTTP/2 on the inbound endpoint. Lambda negotiates the protocol through ALPN (Application-Layer Protocol Negotiation) during the TLS handshake, preferring HTTP/2 and falling back to HTTP/1.1. An HTTP/2-capable client uses it automatically.

To use HTTP/2 between the endpoint and your application inside the MicroVM:

Outbound connectivity

By default, Lambda MicroVMs have public internet access on the egress path. To connect MicroVMs with resources in your private VPCs – such as RDS, ElastiCache, internal APIs, and on-premises systems through Direct Connect or VPN – create a Lambda Network Connector with your VPC configuration.

When using VPC egress, outbound traffic is subject to security group rules and network ACLs governing traffic in your VPC.

Working with egress network connectors

Egress network connectors route outbound traffic from your MicroVM through your VPC. You create a connector once, then reference it by ARN when starting MicroVMs through the run-microvm command.

Prerequisites

Before creating a network connector, you need an IAM role that allows Lambda to create elastic network interfaces (ENIs) in your VPC. The role requires the following permissions:

{
  "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"
        }
      }
    }
  ]
}

Creating a network connector

Create a connector by specifying your VPC subnets, security groups, and network protocol (IPv4 or 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

Network connector states

A connector must be in ACTIVE state before you can reference it in run-microvm.

Running a MicroVM with a network connector

Reference the connector ARN when running a 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}'