Configuring networking for AWS Lambda Web Functions

A Web Function accepts requests from clients. It can also reach other resources to do its work, such as a database in your VPC, an internal API, or a service on the public internet. You configure these two directions independently. You can expose an endpoint to callers without granting it VPC access, or give a function private outbound access without changing who can invoke it.

Inbound traffic reaches a Web Function through an endpoint. The endpoint defines its domain name, endpoint type, Regions, and authorization configuration. Outbound traffic is configured on a revision. A revision with no egress network connector reaches public IPv4 destinations directly. A revision that references a connector sends its outbound traffic through your VPC. A Web Function runs on infrastructure that Lambda owns and manages, not inside your VPC. An egress network connector adds outbound VPC access only. It doesn't change how clients reach the endpoint or who is allowed to invoke it.

Inbound connectivity

Clients invoke a Web Function through a Lambda-managed public HTTPS endpoint. Lambda terminates TLS and forwards the request to your application's HTTP server. The managed endpoint supports HTTP/1.1. It does not expose a private VPC address or accept direct connections to the execution environment.

IamAuth controls who can invoke an endpoint, but it does not make the endpoint private at the network layer. For authorization options, see Lambda Web Function endpoint access control.

The endpoint controls request routing, authorization, throttling, and scaling. Its endpoint type and Region set are fixed when you create it. To change either property, create a new endpoint and move clients to its new domain name.

Endpoint configuration is independent of VPC egress. Adding an egress network connector to a revision doesn't make the endpoint private and doesn't restrict inbound requests.

When revision weights split traffic between revisions with different connector configurations, requests use different network paths. When you diagnose intermittent connectivity, check the endpoint's auto-deployment mode and revision weights first. For how they route requests to revisions, see Deployment patterns.

Add an HTTP front door in front of an endpoint

A front door is a service that receives client requests and forwards them to your endpoint. It adds capabilities such as a custom domain, caching, or web application firewall protection. Web Function endpoints do not support custom domain names or direct AWS WAF association. Use Amazon CloudFront in front of the endpoint when you need a custom domain, edge caching, HTTP/2 or HTTP/3 between the viewer and the edge, response compression, or AWS WAF controls.

The following diagram shows a production front door. A client connects to a CloudFront custom domain protected by AWS WAF. CloudFront sends the request to a protected Web Function endpoint, which routes it to an execution environment. Without an egress network connector, the application can call public AWS service or internet endpoints. It can't reach resources that have only private VPC addresses. To reach those resources, see Connecting a Web Function to your VPC. With IamAuth, CloudFront signs each origin request, and Lambda authorizes the request before invoking your function. Lambda preserves the viewer's original Authorization header and forwards it to your function. The Lambda-provided domain accepts only signed requests from principals with permission to invoke it, and rejects unsigned direct requests, such as a browser calling the domain directly. To ensure the endpoint accepts calls only from your distribution, add a resource-based policy that grants invoke permission to the CloudFront service principal and scopes it to your distribution's Amazon Resource Name (ARN) with a source ARN condition. With ApplicationManaged, the endpoint is public, and direct requests bypass CloudFront and AWS WAF.

For the CloudFront authorization procedure, see CloudFront integration.

Browser access and CORS

Lambda does not add Cross-Origin Resource Sharing (CORS) headers for Web Functions. Your application or front door must handle preflight and actual requests.

Streaming and protocol limitations

Web Functions stream request bodies to your application as they arrive and stream responses back to the client over HTTP/1.1. The request path is half-duplex: Lambda forwards the full request body before it delivers your application's response. Read the request body completely before you write the response. Set timeoutSeconds to cover streaming in both directions: receiving the request body and sending the response. When the timeout elapses, Lambda ends the response. The client receives the status code already sent, with a truncated body. Stop upstream work when the client disconnects.

Lambda does not support WebSocket upgrades. Lambda removes connection-specific upgrade headers before forwarding the request. Use server-sent events when one-way server-to-client streaming is sufficient.

For the complete header and method contract, see HTTP requests and responses.

Outbound connectivity

You choose the outbound network path for each revision.

Referencing a connector replaces the default outbound path. A connector places traffic in your VPC, but it doesn't provide internet access. To reach public IPv4 destinations, the connector subnets need a route to a NAT gateway. To reach public IPv6 destinations, they need a route to an egress-only internet gateway.

There is no stable source IP address for connector traffic. Configure destination security groups to allow the connector's security groups. If a destination doesn't support security-group references, allow the connector subnet CIDR blocks instead of an individual address.

Lambda runs connector operations asynchronously. A connector reports PENDING while Lambda creates its network interfaces, and ACTIVE when revisions can reference it. Other states include INACTIVE, FAILED, DELETING, and DELETE_FAILED.

After an update, check LastUpdateStatus for InProgress, Successful, or Failed. If an operation fails, use its state reason and reason code to identify the affected subnet, security group, permissions, or IP address capacity.

DNS resolution

For private DNS names, enable DNS support and DNS hostnames in the connector's VPC. Associate any required Route 53 private hosted zones with that VPC.

Each execution environment caches DNS answers. After changing a DNS record, existing environments continue using the old answer until the cached value expires or Lambda replaces the environment. To force a clean rollout, create a new revision and shift endpoint traffic to it.

When troubleshooting, test name resolution and network reachability separately. Connect to a destination by IP address to verify the network path, then test its DNS name.

Connecting a Web Function to your VPC

An egress network connector is a reusable Lambda resource. You create the connector once and reference a published connector version from each Web Function revision that needs VPC access.

For Web Functions, the connector reference has the following properties:

Prerequisites

Before you create the connector:

The connector's operator role and the revision's execution role serve different purposes. The operator role manages network interfaces in your VPC. The execution role grants your application permission to call AWS APIs. You don't add connector network-interface permissions to the execution role.

Operator role permissions

Lambda assumes the connector's operator role to manage the connector's network interfaces. The role's trust policy must allow the Lambda service principal, lambda.amazonaws.com, to assume it:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Attach a permissions policy like the following to the connector's operator role. This policy allows Lambda to create and tag the connector's network interfaces:

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

Create a connector

The following AWS CLI command creates an IPv4 connector for Web Functions. Replace the connector name, subnet IDs, security group ID, and operator role ARN with your own values.

aws lambda-core create-network-connector \
  --name my-connector \
  --configuration '{
    "VpcEgressConfiguration": {
      "SubnetIds": [
        "subnet-0ab1c2d3e4f5a6b78",
        "subnet-1bc2d3e4f5a6b7c89"
      ],
      "SecurityGroupIds": ["sg-0123456789abcdef0"],
      "NetworkProtocol": "IPv4",
      "AssociatedComputeResourceTypes": ["WebFunction"]
    }
  }' \
  --operator-role arn:aws:iam::123456789012:role/NetworkConnectorOperatorRole

A connector supports one compute resource type. A connector for Web Functions doesn't support another Lambda compute type, and its compute resource type is immutable.

Lambda creates the connector asynchronously. Use get-network-connector to wait until its State is ACTIVE, and note the current version number.

Reference the connector from a revision

Set serviceConfig.egressNetworkConnectorArn when you create the Web Function's first revision or a later revision. Use a version-qualified ARN:

arn:aws:lambda:us-east-1:123456789012:network-connector:nc-0a1b2c3d4e5f6a7b8:4

The following AWS CLI command creates a revision that references connector version 4. Replace the function name, execution role ARN, connector ARN, and Region with your own values.

aws lambda-web create-web-function-revision \
  --function-name my-web-function \
  --build-config file://build-config.json \
  --service-config '{
    "executionRoleArn": "arn:aws:iam::123456789012:role/WebFunctionExecutionRole",
    "timeoutSeconds": 30,
    "egressNetworkConnectorArn": "arn:aws:lambda:us-east-1:123456789012:network-connector:nc-0a1b2c3d4e5f6a7b8:4"
  }' \
  --region us-east-1

An unqualified ARN, connector name, or connector ID isn't accepted on a revision. After creating the revision:

The endpoint's automatic deployment mode determines whether creating an active revision updates routing automatically. In all modes, confirm which revision is serving before testing its connector.

Updating or removing VPC connectivity

Updating a connector publishes a new version. Existing revisions remain pinned to the version in their connector ARN.

To roll out a connector change:

Updating the connector without creating a revision that references its new version doesn't change the network configuration of running Web Functions.

To remove VPC connectivity, create a revision without egressNetworkConnectorArn. A HomeRegion endpoint in LatestRevision mode picks it up when it becomes active. For an endpoint in Disabled mode, shift traffic by updating its revision weights. The new revision uses Lambda-managed public IPv4 egress and no longer has private VPC access.

IPv6 support

The default outbound path and an IPv4 connector support IPv4 only. To use IPv6, configure the connector with NetworkProtocol set to DualStack.

For dual-stack connectivity:

Don't determine IPv6 availability by inspecting interfaces inside an execution environment. Verify it by making an IPv6 connection from application code and checking VPC Flow Logs.