Restrictions on Lambda@Edge

The following restrictions apply only to Lambda@Edge.

For information about quotas, see Quotas on Lambda@Edge.

DNS resolution

CloudFront performs a DNS resolution on the origin domain name before it executes your origin request Lambda@Edge function. If the DNS service for your domain is experiencing issues and CloudFront can't resolve the domain name to get the IP address, your Lambda@Edge function will not invoke. CloudFront will return an HTTP 502 status code (Bad Gateway) to the client. For more information, see HTTP 502 status code (DNS error).

For more information about managing DNS failover, see Configuring DNS failover in the Amazon Route 53 Developer Guide.

HTTP status codes

Lambda@Edge functions for viewer response events cannot modify the HTTP status code of the response, regardless of whether the response came from the origin or the CloudFront cache.

Lambda function version

You must use a numbered version of the Lambda function, not $LATEST or aliases.

Lambda Region

The Lambda function must be in the US East (N. Virginia) Region.

Lambda role permissions

The IAM execution role associated with the Lambda function must allow the service principals lambda.amazonaws.com and edgelambda.amazonaws.com to assume the role. For more information, see IAM permissions and roles for Lambda@Edge.

Lambda features

The following Lambda features are not supported by Lambda@Edge:

• Lambda runtime management configurations other than Auto (default)

• Configuration of your Lambda function to access resources inside your VPC

• Lambda function dead letter queues

• Lambda environment variables (except for reserved environment variables, which are automatically supported)

• Lambda functions with AWS Lambda layers

• Using AWS X-Ray

• Lambda provisioned concurrency

  Note

  Lambda@Edge functions have the same Regional concurrency capabilities as Lambda functions. However, when the quota is increased for concurrent Lambda@Edge executions, the quota is increased for all the AWS Regions where the Lambda@Edge function is replicated. For more information, see Quotas on Lambda@Edge.

• Lambda functions defined as container images

• Lambda functions that use the arm64 architecture

• Lambda functions with more than 512 MB of ephemeral storage

Supported runtimes

Lambda@Edge supports Lambda functions with the following runtimes:

Node.js	Python
Node.js 20 Node.js 18 Node.js 16¹ Node.js 14² Node.js 12² Node.js 10² Node.js 8² Node.js 6²	Python 3.12 Python 3.11 Python 3.10 Python 3.9 Python 3.8 Python 3.7

¹This version of Node.js has reached end of life, and will soon be deprecated by AWS Lambda.

²This version of Node.js has reached end of life, and is fully deprecated by AWS Lambda.

You can’t create or update functions with deprecated versions of Node.js. You can only associate existing functions with these versions with CloudFront distributions. Functions with these versions that are associated with distributions will continue to run. However, we recommend that you move your function to newer versions of Node.js. For more information, see Runtime deprecation policy in the AWS Lambda Developer Guide and the Node.js release schedule on GitHub.

Tip

As a best practice, use the latest versions of the provided runtimes for performance improvements and new features.

CloudFront headers

Lambda@Edge functions can read, edit, remove, or add any of the CloudFront headers listed in Adding CloudFront request headers.

Notes

• If you want CloudFront to add these headers, you must configure CloudFront to add them by using a cache policy or origin request policy.

• CloudFront adds the headers after the viewer request event, which means the headers aren't available to Lambda@Edge functions in a viewer request. The headers are only available to Lambda@Edge functions in an origin request and origin response.

• If the viewer request includes headers that have these names, and you configured CloudFront to add these headers using a cache policy or origin request policy, then CloudFront overwrites the header values that were in the viewer request. Viewer-facing functions see the header value from the viewer request, while origin-facing functions see the header value that CloudFront added.

• If a viewer request function adds the CloudFront-Viewer-Country header, it fails validation and CloudFront returns HTTP status code 502 (Bad Gateway) to the viewer.

Restrictions on the request body with the include body option

When you choose the Include Body option to expose the request body to your Lambda@Edge function, the following information and size quotas apply to the portions of the body that are exposed or replaced.

• CloudFront always base64 encodes the request body before exposing it to Lambda@Edge.

• If the request body is large, CloudFront truncates it before exposing it to Lambda@Edge, as follows:

  • For viewer request events, the body is truncated at 40 KB.

  • For origin request events, the body is truncated at 1 MB.

• If you access the request body as read-only, CloudFront sends the full original request body to the origin.

• If your Lambda@Edge function replaces the request body, the following size quotas apply to the body that the function returns:

  • If the Lambda@Edge function returns the body as plain text:

    • For viewer request events, the body is truncated at 40 KB.

    • For origin request events, the body is truncated at 1 MB.

  • If the Lambda@Edge function returns the body as base64 encoded text:

    • For viewer request events, the body is truncated at 53.2 KB.

    • For origin request events, the body is truncated at 1.33 MB.

Response timeout and keep-alive timeout (custom origins only)

If you're using Lambda@Edge functions to set the response timeout or keep-alive timeout for your distribution origins, verify that you're specifying a value that your origin can support. For more information, see Response and keep-alive timeout quotas.