AWS Lambda Function Permissions

In this article we will explore the permissions and connection capabilities that allow AWS Lambda and other AWS services to connect to each other.

Lambda functions involve two aspects that determine the required permissions:
Execution Permission: Authorization for the Lambda function to interact with other services.
Invoking Permission: Granting permission to invoke the function, it is controlled using an IAM resource-based policy.

Let's break it down

Execution role

The execution role gives your function permissions to interact with other services. You provide this role when you create a function, and Lambda assumes the role when your function is invoked.

Execution role definitions
Let's assume you have an S3 bucket that your Lambda function needs to read from and write to. Your execution role would look like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::your-bucket-name/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:*"
    }
  ]
}

The trust policy defines who (or what) can assume the role. In the case of AWS Lambda, the principal is the Lambda service, and it's given permission to assume the role using the AWS STS AssumeRole action. Here's an example trust policy:

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

This policy explicitly states that the AWS Lambda service (identified by the service principal "lambda.amazonaws.com") is allowed to assume the role by calling the sts:AssumeRole action.
When you create an IAM role for your Lambda function, you would attach this trust policy to the role. It ensures that the Lambda service has the necessary permissions to assume the role and execute the Lambda function on behalf of your AWS account.

Here is a screenshot showing where to configure both the function "Execution Role" (or Permission), and the "Trust policy"

Resource-based policy
A resource policy (also called a function policy) tells the Lambda service which principals have permission to invoke the Lambda function. An AWS principal may be a user, role, another AWS service, or another AWS account.

Here is an example of a Resource-based policy

{
    "Version": "2012-10-17",
    "Id": "default",
    "Statement": [
        {
            "Sid": "lambda-allow-s3-my-function",
            "Effect": "Allow",
            "Principal": {
              "Service": "s3.amazonaws.com"
            },
            "Action": "lambda:InvokeFunction",
            "Resource":  "arn:aws:lambda:us-east-2:123456789012:function:my-function",
            "Condition": {
              "StringEquals": {
                "AWS:SourceAccount": "123456789012"
              },
              "ArnLike": {
                "AWS:SourceArn": "arn:aws:s3:::my-bucket"
              }
            }
        }
     ]
}

Read more about Resource-based policy from AWS documentation

What if I need a function to connect to AWS resource in a VPC like EC2 or RDS instance?
And is it possible to call the function from an EC2 instance in a private subnet?

Accessing resources in a VPC
Enabling your Lambda function to access resources inside your VPC requires additional VPC-specific configuration information, such as VPC subnet IDs and security group IDs. This functionality allows Lambda to access resources in the VPC. It does not change how the function is secured. You also need an execution role with permissions to create, describe, and delete elastic network interfaces. Lambda provides a permissions policy for this purpose named "AWSLambdaVPCAccessExecutionRole".

learn more about attaching your Lambda functions to a VPC, in the AWS Lambda Developer Guide.

Lambda and AWS PrivateLink
AWS Lambda supports AWS PrivateLink, enabling you to securely create, manage, and invoke Lambda functions within your VPC or on-premises data centers without exposing traffic to the public Internet.
For a private link between your VPC and Lambda, set up an interface VPC endpoint. This utilizes AWS PrivateLink, allowing private access to Lambda APIs without the need for an internet gateway, NAT device, VPN, or AWS Direct Connect. No public IP addresses are required for instances in your VPC to communicate with Lambda APIs, ensuring that traffic between your VPC and Lambda stays within the AWS network.

learn more about AWS PrivateLink and AWS Lambda, in the AWS Lambda Developer Guide.

Conclusion
In this article we covered the permissions to control who can do what in regard to AWS Lambda and other AWS services.
And then we talked about the ability to of AWS Lambda to connect to AWS services in a VPC, and a resource in private VPC that needs to call Lambda functions privately.