Restrictions on Lambda@Edge - Amazon CloudFront (original) (raw)

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 DNS error (NonS3OriginDnsError).

If your function logic modifies the origin domain name, CloudFront will perform another DNS resolution on the updated domain name after the function has finished executing.

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 andedgelambda.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 thanAuto (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 Managing AWS Lambda dependencies with layers
Using AWS X-Ray
Lambda provisioned concurrency
Create a Lambda function using a container image
Lambda functions that use the arm64 architecture
Lambda functions with more than 512 MB of ephemeral storage
Using a customer managed key to encrypt your .zip deployment packages

Supported runtimes

Lambda@Edge supports the latest versions of Node.js and Python runtimes. For a list of supported versions and their future deprecation dates, see Supported runtimes in the AWS Lambda Developer Guide.

Tip

As a best practice, use the latest versions of the provided runtimes for performance improvements and new features.
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.

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 theCloudFront-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.