Who This Is For

If you are using AWS Lambda to build serverless applications and you have never stopped to look closely at the IAM roles attached to your functions, this blog is for you.

We are going to talk about what a Lambda execution role is, why the way most people set them up creates a security problem, and exactly what you should do instead. Every term will be explained along the way.

A Quick Refresher: What Is an Execution Role?

When a Lambda function runs, it needs permission to interact with other AWS services. For example, if your function reads data from a database or writes a file to S3 (AWS's file storage service), AWS needs to know whether your function is allowed to do that.

This permission is controlled by something called an IAM execution role. IAM stands for Identity and Access Management. It is the system AWS uses to control who or what can access which resources.

Every Lambda function has an execution role attached to it. When the function runs, it automatically assumes that role and gets whatever permissions the role has. Think of it like a staff ID card. The card determines which rooms in the building you are allowed to enter.

What Is the Least Privilege Principle?

The principle of least privilege is a security concept that says: every user, system, or service should have only the minimum permissions it needs to do its job, and nothing more.

If a Lambda function only needs to read from one specific DynamoDB table (a type of AWS database), it should have permission to read from that one table. It should not have permission to read from all tables, write to tables, delete tables, or access any other AWS service.

This sounds obvious. But in practice, it is almost never what happens.

How Execution Roles Are Usually Set Up

When you create a Lambda function for the first time, AWS creates a basic execution role for you automatically. This default role usually includes permission to write logs to CloudWatch (AWS's logging service), which is fine.

But here is where the problem starts.

As you build your function and it needs to access more services, the easiest thing to do is go to the role and add more permissions. Need to read from S3? Add s3:GetObject. Actually, to save time, just add s3:* which gives the function permission to do everything in S3. Need to write to DynamoDB? Add dynamodb:*. Need to send messages? Add sns:*.

Within a few iterations, your Lambda function has a role that can read, write, and delete across half your AWS account.

And then there is the even worse pattern: one shared role for all Lambda functions. Instead of creating a separate role for each function, many developers just reuse the same role across every function in the project. It is faster to set up. But now every single function has every permission that any function ever needed.

Why This Is a Real Problem

You might be thinking: my app is not a high value target, nobody is going to attack my Lambda function.

That thinking is what attackers rely on.

Lambda functions are often triggered by external events. An API Gateway request, an S3 file upload, an SNS message. Any of these entry points can potentially be exploited if there is a vulnerability in your code, a dependency with a known security issue, or even a misconfigured trigger.

If an attacker gains control of one Lambda function that has an overly permissive role, they do not just have access to what that function was supposed to do. They have access to everything that role allows. That could mean reading sensitive data from your database, writing files to your storage, sending messages to your users, or even modifying other parts of your infrastructure.

One compromised function becomes a key to your entire account.

The Three Most Common Mistakes

Mistake 1: Using wildcard permissions

A wildcard in IAM policy looks like this:

{
  "Effect": "Allow",
  "Action": "dynamodb:*",
  "Resource": "*"
}

The dynamodb:* means allow all DynamoDB actions. The "Resource": "*" means on all resources. So this one policy line gives your Lambda function full DynamoDB access across your entire account. If your function only needed to read from one table, this is massively over-permissioned.

Mistake 2: Sharing one role across multiple Lambda functions

Every function has different responsibilities. A function that sends a password reset email should not have the same permissions as a function that processes payments. When you share a role, you are taking the maximum permissions needed by any one function and giving them to all functions.

Mistake 3: Never revisiting the role after initial setup

During development, it is common to grant broad permissions just to get things working. The problem is that most developers never go back to tighten those permissions before going live. The overly permissive development role becomes the production role.

How to Fix It

Fix 1: One role per Lambda function

Each Lambda function should have its own dedicated execution role. Yes, this means more roles to manage. But it means a compromised function can only access what it specifically needs, not what any other function needs.

Fix 2: Scope permissions to specific actions and resources

Instead of dynamodb:* on *, write out exactly what the function needs:

{
  "Effect": "Allow",
  "Action": [
    "dynamodb:GetItem",
    "dynamodb:PutItem"
  ],
  "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MySpecificTable"
}

This gives permission only to read and write items, and only on one specific table. Nothing more.

The arn in the resource field is a unique identifier for a specific AWS resource. Every resource in AWS has one. Using it in your policy means you are granting access to that one resource, not everything in the service.

Fix 3: Use IAM Access Analyzer to generate policies from actual usage

IAM Access Analyzer is a free AWS tool that can look at your CloudTrail logs (the record of every action taken in your AWS account) and tell you exactly which permissions your Lambda function actually used over a given time period.

Instead of guessing what permissions a function needs, you can run it for a while, then use Access Analyzer to generate a policy based on real usage. This is one of the most accurate ways to arrive at a least privilege policy.

To use it, go to IAM in the AWS console, find the role attached to your Lambda function, and look for the "Generate policy" option under Access Analyzer.

Fix 4: Use permission boundaries as a safety net

A permission boundary is a policy that sets a ceiling on what permissions a role can ever have. Even if someone attaches a broad policy to the role later, the boundary limits the effective permissions.

This is especially useful in team environments where multiple developers are creating and modifying Lambda functions. It acts as a guardrail so that even if someone makes a mistake, the damage is contained.

A Simple Checklist Before You Deploy

Before your Lambda function goes live, go through these:

Does this function have its own dedicated execution role, not shared with any other function?

Does the role use specific actions like dynamodb:GetItem instead of dynamodb:*?

Does the role point to specific resource ARNs instead of *?

Have you removed any permissions that were added during development and are no longer needed?

If you are working in a team, is there a permission boundary in place?

Conclusion

Least privilege is one of the most talked about security principles in cloud development. But it is also one of the most commonly ignored in practice, not because developers do not care, but because the default path leads away from it.

AWS makes it easy to create broad roles. It is faster to write dynamodb:* than to list out every specific action. It is more convenient to reuse one role across all your functions. But each of those shortcuts quietly widens the blast radius if something goes wrong.

Fixing this does not require rebuilding anything. It just requires going back to your Lambda functions one by one, looking at their execution roles, and asking: does this function actually need all of this?

Most of the time, the answer will be no.

Need Help?

If you want help auditing your Lambda execution roles or figuring out what permissions your functions actually need, feel free to reach out.

Email me at khantanseer43@gmail.com