Restrictions on Lambda@Edge
The following restrictions apply only to Lambda@Edge.
Contents
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 DNS error (NonS3OriginDnsError).
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 Set up 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 environment variables (except for reserved environment variables, which are automatically supported)
-
Lambda functions with Managing AWS Lambda dependencies with layers
-
Lambda provisioned concurrency
Note
Lambda@Edge functions share the same Regional concurrency capabilities as all Lambda functions. For more information, see Quotas on Lambda@Edge.
-
Lambda functions with more than 512 MB of ephemeral storage
-
Capturing Lambda function logs in JSON structured format
-
Controlling the log level granularity of Lambda function logs
-
Setting which Amazon CloudWatch log group Lambda sends logs to
Supported runtimes
Lambda@Edge supports Lambda functions with the following runtimes:
Node.js |
Python |
---|---|
|
|
¹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
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 Add 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 limits 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 limits 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 limit is 40 KB.
-
For origin request events, the body limit is 1 MB.
-
-
If the Lambda@Edge function returns the body as base64 encoded text:
-
For viewer request events, the body limit is 53.2 KB.
-
For origin request events, the body limit is 1.33 MB.
-
-
Note
If your Lambda@Edge function returns a body that exceeds these limits, your request will fail with an HTTP 502 status code (Lambda validation error). We recommend that you update your Lambda@Edge function so that the body doesn't exceed these limits.
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.