# Restrictions on edge functions
The following topics describe the restrictions that apply to CloudFront Functions and Lambda@Edge. Some restrictions apply to all edge functions, while others apply only to CloudFront Functions or Lambda@Edge.
Each topic provides detailed information about the limitations and constraints you should consider when you develop and deploy edge functions with CloudFront.
Understanding these restrictions helps you ensure that your edge functions operate as expected and comply with the supported features.
**Topics**
+ [Restrictions on all edge functions](edge-function-restrictions-all.md)
+ [Restrictions on CloudFront Functions](cloudfront-function-restrictions.md)
+ [Restrictions on Lambda@Edge](lambda-at-edge-function-restrictions.md)
For information about quotas (formerly referred to as limits), see [Quotas on CloudFront Functions](cloudfront-limits.md#limits-functions) and [Quotas on Lambda@Edge](cloudfront-limits.md#limits-lambda-at-edge).
# Restrictions on all edge functions
The following restrictions apply to all edge functions, both CloudFront Functions and Lambda@Edge.
**Topics**
+ [AWS account ownership](#function-restrictions-account-ownership)
+ [Combining CloudFront Functions with Lambda@Edge](#function-restrictions-combining-functions)
+ [HTTP status codes](#function-restrictions-status-codes)
+ [HTTP headers](#function-restrictions-headers)
+ [Query strings](#function-restrictions-query-strings)
+ [URI](#function-restrictions-uri)
+ [URI, query string, and headers encoding](#function-restrictions-encoding)
+ [Microsoft Smooth Streaming](#function-restrictions-microsoft-smooth-streaming)
+ [Tagging](#function-restrictions-tagging)
## AWS account ownership
To associate an edge function with a CloudFront distribution, the function and distribution must be owned by the same AWS account.
## Combining CloudFront Functions with Lambda@Edge
For a given cache behavior, the following restrictions apply:
+ Each event type (viewer request, origin request, origin response, and viewer response) can have only one edge function association.
+ You can’t combine CloudFront Functions and Lambda@Edge in viewer events (viewer request and viewer response).
All other combinations of edge functions are allowed. The following table explains the allowed combinations.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/edge-function-restrictions-all.html)
## HTTP status codes
CloudFront doesn't invoke edge functions for viewer response events when the origin returns HTTP status code 400 or higher.
Lambda@Edge functions for origin response events are invoked for *all* origin responses, including when the origin returns HTTP status code 400 or higher. For more information, see [Update HTTP responses in origin response triggers](lambda-generating-http-responses.md#lambda-updating-http-responses).
## HTTP headers
Certain HTTP headers are disallowed, which means they're not exposed to edge functions and functions can't add them. Other headers are read-only, which means functions can read them but can't add, modify, or delete them.
**Topics**
+ [Disallowed headers](#function-restrictions-disallowed-headers)
+ [Read-only headers](#function-restrictions-read-only-headers)
### Disallowed headers
The following HTTP headers are not exposed to edge functions, and functions can't add them. If your function adds one of these headers, it fails CloudFront validation and CloudFront returns HTTP status code 502 (Bad Gateway) to the viewer.
+ `Connection`
+ `Expect`
+ `Keep-Alive`
+ `Proxy-Authenticate`
+ `Proxy-Authorization`
+ `Proxy-Connection`
+ `Trailer`
+ `Upgrade`
+ `X-Accel-Buffering`
+ `X-Accel-Charset`
+ `X-Accel-Limit-Rate`
+ `X-Accel-Redirect`
+ `X-Amz-Cf-*`
+ `X-Amzn-Auth`
+ `X-Amzn-Cf-Billing`
+ `X-Amzn-Cf-Id`
+ `X-Amzn-Cf-Xff`
+ `X-Amzn-Errortype`
+ `X-Amzn-Fle-Profile`
+ `X-Amzn-Header-Count`
+ `X-Amzn-Header-Order`
+ `X-Amzn-Lambda-Integration-Tag`
+ `X-Amzn-RequestId`
+ `X-Cache`
+ `X-Edge-*`
+ `X-Forwarded-Proto`
+ `X-Real-IP`
### Read-only headers
The following headers are read-only. Your function can read them and use them as input to the function logic, but it can't change the values. If your function adds or edits a read-only header, the request fails CloudFront validation and CloudFront returns HTTP status code 502 (Bad Gateway) to the viewer.
#### Read-only headers in viewer request events
The following headers are read-only in viewer request events.
+ `CDN-Loop`
+ `Content-Length`
+ `Host`
+ `Transfer-Encoding`
+ `Via`
#### Read-only headers in origin request events (Lambda@Edge only)
The following headers are read-only in origin request events, which exist only in Lambda@Edge.
+ `Accept-Encoding`
+ `CDN-Loop`
+ `Content-Length`
+ `If-Modified-Since`
+ `If-None-Match`
+ `If-Range`
+ `If-Unmodified-Since`
+ `Transfer-Encoding`
+ `Via`
#### Read-only headers in origin response events (Lambda@Edge only)
The following headers are read-only in origin response events, which exist only in Lambda@Edge.
+ `Transfer-Encoding`
+ `Via`
#### Read-only headers in viewer response events
The following headers are read-only in viewer response events for both CloudFront Functions and Lambda@Edge.
+ `Warning`
+ `Via`
The following headers are read-only in viewer response events for Lambda@Edge.
+ `Content-Length`
+ `Content-Encoding`
+ `Transfer-Encoding`
## Query strings
The following restrictions apply to functions that read, update, or create a query string in a request URI.
+ (Lambda@Edge only) To access the query string in an origin request or origin response function, your cache policy or origin request policy must be set to **All** for **Query strings**.
+ A function can create or update a query string for viewer request and origin request events (origin request events exist only in Lambda@Edge).
+ A function can read a query string, but cannot create or update one, for origin response and viewer response events (origin response events exist only in Lambda@Edge).
+ If a function creates or updates a query string, the following restrictions apply:
+ The query string can't include spaces, control characters, or the fragment identifier (`#`).
+ The total size of the URI, including the query string, must be less than 8,192 characters.
+ We recommend that you use percent encoding for the URI and query string. For more information, see [URI, query string, and headers encoding](#function-restrictions-encoding).
## URI
If a function changes the URI for a request, that doesn't change the cache behavior for the request or the origin that the request is forwarded to.
The total size of the URI, including the query string, must be less than 8,192 characters.
## URI, query string, and headers encoding
The values for the URI, query string, and headers that are passed to edge functions are UTF-8 encoded. Your function should use UTF-8 encoding for the URI, query string, and header values that it returns. Percent encoding is compatible with UTF-8 encoding.
The following list explains how CloudFront handles encoding for the URI, query string, and headers:
+ When values in the request are UTF-8 encoded, CloudFront forwards the values to your function without changing them.
+ When values in the request are [ISO-8859-1 encoded](https://en.wikipedia.org/wiki/ISO/IEC_8859-1), CloudFront converts the values to UTF-8 encoding before forwarding them to your function.
+ When values in the request are encoded using some other character encoding, CloudFront assumes that they're ISO-8859-1 encoded and tries to convert from ISO-8859-1 to UTF-8.
**Important**
The converted characters might be an inaccurate interpretation of the values in the original request. This might cause your function or your origin to produce an unintended result.
The values for the URI, query string, and headers that CloudFront forwards to your origin depend on whether a function changes the values:
+ If a function doesn't change the URI, query string, or header, CloudFront forwards the values that it received in the request to your origin.
+ If a function changes the URI, query string, or header, CloudFront forwards the UTF-8 encoded values.
## Microsoft Smooth Streaming
You can't use edge functions with a CloudFront distribution that you're using for streaming media files that you've transcoded into the Microsoft Smooth Streaming format.
## Tagging
You can't add tags to edge functions. For more information about tagging in CloudFront, see [Tag a distribution](tagging.md).
# Restrictions on CloudFront Functions
The following restrictions apply only to CloudFront Functions.
**Contents**
+ [Logs](#cloudfront-function-restrictions-logs)
+ [Request body](#cloudfront-function-restrictions-request-body)
+ [Using temporary credentials with the CloudFront KeyValueStore API](#regional-endpoint-for-key-value-store)
+ [Runtime](#cloudfront-function-runtime-restrictions)
+ [Compute utilization](#cloudfront-function-restrictions-compute-utilization)
For information about quotas (formerly referred to as limits), see [Quotas on CloudFront Functions](cloudfront-limits.md#limits-functions).
## Logs
Function logs in CloudFront Functions are truncated at 10 KB.
## Request body
CloudFront Functions can't access the body of the HTTP request.
## Using temporary credentials with the CloudFront KeyValueStore API
You can use AWS Security Token Service (AWS STS) to generate temporary security credentials (also known as *session tokens*). Session tokens allow you to temporarily assume an AWS Identity and Access Management (IAM) role so that you can access AWS services.
To call the [CloudFront KeyValueStore API](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_Operations_Amazon_CloudFront_KeyValueStore.html), use a *Regional* endpoint in AWS STS to return a *version 2* session token. If you use the *global* endpoint for AWS STS (`sts.amazonaws.com`), AWS STS will generate a *version 1* session token, which isn't supported by Signature Version 4A (SigV4A). As a result, you will receive an authentication error.
To call the CloudFront KeyValueStore API, you can use the following options:
**AWS CLI and AWS SDKs**
You can configure the AWS CLI or an AWS SDK to use Regional AWS STS endpoints. For more information, see [AWS STS Regionalized endpoints](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html) in the *AWS SDK and Tools Reference Guide*.
For more information about available AWS STS endpoints, see [Regions and endpoints](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html#id_credentials_region-endpoints) in the *IAM User Guide*.
**SAML**
You can configure SAML to use Regional AWS STS endpoints. For more information, see the [How to use regional SAML endpoints for failover](https://aws.amazon.com/blogs/security/how-to-use-regional-saml-endpoints-for-failover/) blog post.
**`SetSecurityTokenServicePreferences` API**
Instead of using a Regional AWS STS endpoint, you can configure the global endpoint for AWS STS to return version 2 session tokens. To do so, use the [SetSecurityTokenServicePreferences](https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetSecurityTokenServicePreferences.html) API operation to configure your AWS account.
**Example: IAM CLI command**
```
aws iam set-security-token-service-preferences --global-endpoint-token-version v2Token
```
We recommend that you use the AWS STS Regional endpoints instead of this option. Regional endpoints provide higher availability and failover scenarios.
**Custom identity provider**
If you're using a custom identity provider that does the federation and assumes the role, use one of the previous options for the parent identity provider system that is responsible for generating the session token.
## Runtime
The CloudFront Functions runtime environment doesn't support dynamic code evaluation, and it restricts access to the network, file system, environment variables, and timers. For more information, see [Restricted features](functions-javascript-runtime-10.md#writing-functions-javascript-features-restricted-features).
**Note**
To use CloudFront KeyValueStore, your CloudFront function must use [JavaScript runtime 2.0](functions-javascript-runtime-20.md).
## Compute utilization
CloudFront Functions have a limit on the time they can take to run, measured as *compute utilization*. Compute utilization is a number between 0 and 100 that indicates the amount of time that the function took to run as a percentage of the maximum allowed time. For example, a compute utilization of 35 means that the function completed in 35% of the maximum allowed time.
When you [test a function](test-function.md), you can see the compute utilization value in the output of the test event. For production functions, you can view the [compute utilization metric](viewing-cloudfront-metrics.md#monitoring-console.cloudfront-functions) on the [Monitoring page in the CloudFront console](https://console.aws.amazon.com/cloudfront/v4/home?#/monitoring), or in CloudWatch.
# Restrictions on Lambda@Edge
The following restrictions apply only to Lambda@Edge.
**Contents**
+ [DNS resolution](#lambda-at-edge-restrictions-dns)
+ [HTTP status codes](#lambda-at-edge-restrictions-status-codes)
+ [Lambda function version](#lambda-at-edge-restrictions-version)
+ [Lambda Region](#lambda-at-edge-restrictions-region)
+ [Lambda role permissions](#lambda-at-edge-restrictions-role-permissions)
+ [Lambda features](#lambda-at-edge-restrictions-features)
+ [Supported runtimes](#lambda-at-edge-restrictions-runtime)
+ [CloudFront headers](#lambda-at-edge-restrictions-cloudfront-headers)
+ [Restrictions on the request body with the include body option](#lambda-at-edge-restrictions-request-body)
+ [Response timeout and keep-alive timeout (custom origins only)](#timeout-for-lambda-edge-functions)
For information about quotas, see [Quotas on Lambda@Edge](cloudfront-limits.md#limits-lambda-at-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)](http-502-bad-gateway.md) to the client. For more information, see [DNS error (`NonS3OriginDnsError`)](http-502-bad-gateway.md#http-502-dns-error).
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](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html) 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-edge-permissions.md).
## Lambda features
The following Lambda features are not supported by Lambda@Edge:
+ [Lambda runtime management configurations](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-update.html#runtime-management-controls) other than **Auto** (default)
+ Configuration of your Lambda function to access resources inside your VPC
+ [Lambda function dead letter queues](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#dlq)
+ [Lambda environment variables](https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html) (except for reserved environment variables, which are automatically supported)
+ Lambda functions with [Managing AWS Lambda dependencies with layers](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html)
+ [Using AWS X-Ray](https://docs.aws.amazon.com/lambda/latest/dg/lambda-x-ray.html)
+ Lambda provisioned concurrency
**Note**
Lambda@Edge functions share the same [Regional concurrency](https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html) capabilities as all Lambda functions. For more information, see [Quotas on Lambda@Edge](cloudfront-limits.md#limits-lambda-at-edge).
+ [Create a Lambda function using a container image](https://docs.aws.amazon.com/lambda/latest/dg/images-create.html)
+ [Lambda functions that use the arm64 architecture](https://docs.aws.amazon.com/lambda/latest/dg/foundation-arch.html)
+ Lambda functions with more than 512 MB of ephemeral storage
+ Using a [customer managed key to encrypt your .zip deployment packages](https://docs.aws.amazon.com/lambda/latest/dg/encrypt-zip-package.html)
## 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](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html#runtimes-supported) 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](https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html) in the *AWS Lambda Developer Guide* and the [Node.js release schedule](https://github.com/nodejs/Release#release-schedule) on GitHub.
## CloudFront headers
Lambda@Edge functions can read, edit, remove, or add any of the CloudFront headers listed in [Add CloudFront request headers](adding-cloudfront-headers.md).
**Notes**
If you want CloudFront to add these headers, you must configure CloudFront to add them by using a [cache policy](controlling-the-cache-key.md) or [origin request policy](controlling-origin-requests.md).
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](controlling-the-cache-key.md) or [origin request policy](controlling-origin-requests.md), 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](http-502-bad-gateway.md#http-502-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](DownloadDistValuesOrigin.md#response-keep-alive-timeout-quota).