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

The following restrictions apply only to Lambda@Edge.

Contents

• DNS resolution
• HTTP status codes
• Lambda function version
• Lambda Region
• Lambda role permissions
• Lambda features
• Supported runtimes
• CloudFront headers
• Restrictions on the request body with the include body option
• Response timeout and keep-alive timeout (custom origins only)

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 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 Lambda functions with the following runtimes:

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

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.