Amazon CloudFront
Developer Guide (API Version 2016-09-29)

Setting IAM Permissions and Roles for Lambda@Edge

Specific IAM permissions and an IAM execution role are required so that you can configure Lambda@Edge. Lambda@Edge also creates a service-linked role to replicate Lambda functions to CloudFront Regions.

IAM Permissions Required to Associate Lambda Functions with CloudFront Distributions

In addition to the IAM permissions that you need to use AWS Lambda, the IAM user needs the following IAM permissions to associate Lambda functions with CloudFront distributions:

  • lambda:GetFunction

    For the resource, specify the ARN of the function version that you want to execute when a CloudFront event occurs, as shown in the following example:


  • lambda:EnableReplication*

    For the resource, specify the ARN of the function version that you want to execute when a CloudFront event occurs, as shown in the following example:


  • iam:CreateServiceLinkedRole

    Used to create a service linked role used by Lambda@Edge to replicate Lambda functions in CloudFront. After this role has been created by the first distribution you use with Lambda@Edge, you do not need to add permission to other distributions you use with Lambda@Edge.

  • cloudfront:UpdateDistribution or cloudfront:CreateDistribution

    Choose cloudfront:UpdateDistribution to update a distribution or cloudfront:CreateDistribution to create a distribution.

For more information, see the following documentation:

Function Execution Role for Service Principals

You must create an IAM role that can be assumed by the service principals and This role is assumed by the service principals when they execute your function. For more information, see Creating the Roles and Attaching the Policies (Console) in the topic "AWS Managed Policies for Job Functions" in the IAM User Guide.

You add this role under the Trust Relationship tab in IAM (do not add it under the Permissions tab).

Here's an example role trust policy:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "", "" ] }, "Action": "sts:AssumeRole" } ] }

For information about the permissions that you need to grant to the execution role, see Manage Permissions: Using an IAM Role (Execution Role) in the AWS Lambda Developer Guide. Note the following:

  • By default, whenever a CloudFront event triggers a Lambda function, data is written to CloudWatch Logs. If you want to use these logs, the execution role needs permission to write data to CloudWatch Logs. You can use the predefined AWSLambdaBasicExecutionRole to grant permission to the execution role.

    For more information about CloudWatch Logs, see CloudWatch Metrics and CloudWatch Logs for Lambda Functions.

  • If your Lambda function code accesses other AWS resources, such as reading an object from an S3 bucket, the execution role needs permission to perform that operation.

Service-Linked Roles for Lambda@Edge

Lambda@Edge uses AWS Identity and Access Management (IAM) service-linked roles. A service-linked role is a unique type of IAM role that is linked directly to Lambda@Edge. Service-linked roles are predefined by Lambda@Edge and include all of the permissions that the service requires to call other AWS services on your behalf.

Lambda@Edge uses the following IAM service-linked role:

  • AWSServiceRoleForLambdaReplicator–Lambda@Edge uses this role to allow Lambda@Edge to replicate functions to AWS Regions.

When you first add a Lambda@Edge trigger in CloudFront, a role named AWSServiceRoleForLambdaReplicator is automatically created to allow Lambda@Edge to replicate functions to AWS Regions. This role is required for using Lambda@Edge functions. The ARN for the AWSServiceRoleForLambdaReplicator role looks like this:


A service-linked role makes setting up Lambda@Edge easier because you don’t have to manually add the necessary permissions. Lambda@Edge defines the permissions of its service-linked roles, and only Lambda@Edge can assume the roles. The defined permissions include the trust policy and the permissions policy. The permissions policy cannot be attached to any other IAM entity.

You must remove any associated CloudFront or Lambda@Edge resources before you can delete a service-linked role. This protects your Lambda@Edge resources because you can't inadvertently remove permission to access the resources.

For information about other services that support service-linked roles, see AWS Services That Work with IAM and look for the services that have Yes in the Service-Linked Role column.

Service-Linked Role Permissions for Lambda@Edge

Lambda@Edge uses the service-linked role named AWSServiceRoleForLambdaReplicator. This service-linked role allows Lambda to replicate Lambda@Edge functions to AWS Regions.

The AWSServiceRoleForLambdaReplicator service-linked role trusts the following service to assume the role:


The role permissions policy allows Lambda@Edge to complete the following actions on the specified resources:

  • Action: lambda:CreateFunction on arn:aws:lambda:*:*:function:*

  • Action: lambda:DeleteFunction on arn:aws:lambda:*:*:function:*

  • Action: lambda:DisableReplication on arn:aws:lambda:*:*:function:*

  • Action: iam:PassRole on all AWS resources

  • Action: cloudfront:ListDistributionsByLambdaFunction on all AWS resources

You must configure permissions to allow an IAM entity (such as a user, group, or role) to create or delete a service-linked role. For more information, see Service-Linked Role Permissions in the IAM User Guide.

Creating the Service-Linked Role for Lambda@Edge

You don't need to manually create the service-linked role for Lambda@Edge. When you first create a trigger, the service creates a role that allows Lambda to replicate Lambda@Edge functions to AWS Regions.

If you delete the service-linked role, the role will be created again when you add a new trigger for Lambda@Edge in a distribution.

Editing the Service-Linked Role for Lambda@Edge

Lambda@Edge does not allow you to edit the AWSServiceRoleForLambdaReplicator service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see Editing a Service-Linked Role in the IAM User Guide.

Deleting the Service-Linked Role for Lambda@Edge

If you no longer need to use Lambda@Edge, we recommend that you delete the service-linked role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up the Lambda@Edge resources in your account before you can manually delete the role.

To delete Lambda@Edge resources used by the AWSServiceRoleForLambdaReplicator

To remove the service-linked role, you must remove all Lambda@Edge associations from your distributions. To do this, update your distributions to remove all Lambda@Edge function triggers, or remove the distributions that use Lambda@Edge functions. For more information, see Deleting Lambda@Edge Functions and Replicas.

After you have removed all Lambda@Edge function associations from your distributions and CloudFront has removed the function replicas from AWS locations, then you can use the CloudFront console to delete the AWSServiceRoleForLambdaReplicator service-linked role.


If CloudFront hasn't finished updating, the service-linked role deletion might fail. If that happens, wait for a few minutes, and then try the steps again.

To manually delete the Lambda@Edge service-linked role (CloudFront console)

  1. Sign in to the AWS Management Console and open the CloudFront console at

  2. On the CloudFront Distributions page, click the avatar in the upper right.

  		      Screenshot that shows the avatar in the CloudFront.
  3. Choose Delete.

  	        Screenshot that shows the dialog for deleting the Lambda service-linked role in the CloudFront.

Supported Regions for CloudFront Service-Linked Roles

CloudFront supports using service-linked roles in the following regions.

Region name Region identity Support in CloudFront
US East (N. Virginia) us-east-1 Yes
US East (Ohio) us-west-2 Yes
US West (Oregon) us-west-2 Yes
Asia Pacific (Mumbai) ap-south-1 Yes
Asia Pacific (Tokyo) ap-northeast-1 Yes
Asia Pacific (Seoul) ap-northeast-2 Yes
Asia Pacific (Singapore) ap-southeast-1 Yes
Asia Pacific (Sydney) ap-southeast-2 Yes
EU (Frankfurt) eu-central-1 Yes
EU (London) eu-west-2 Yes
South America (São Paulo) sa-east-1 Yes