What happens when a single IAM role is shared across multiple Lambda functions?

Why a Shared IAM Role Changes the Security Boundary

When several Lambda functions assume the same role, they stop having distinct permission boundaries. The role becomes the common trust anchor for every function that uses it, so any permission granted to support one function is available to all of them. That weakens least privilege and makes it harder to reason about which code path is allowed to reach which resource.

This is especially important in serverless environments because functions are often built for narrow tasks and deployed independently. A shared role collapses those differences into one access profile, which means operational convenience can quietly become an authorization design flaw.

Using separate execution roles preserves isolation between functions and gives each function only the permissions it actually needs. It also makes permission reviews and change tracking more meaningful, because you can see exactly which function depends on which access.

How Shared Roles Affect Blast Radius and Accountability

A shared role increases blast radius. If one Lambda function is compromised, abused, or simply misdesigned, the attacker or bug inherits the same permissions as the other functions using that role. The issue is not only data exposure, but also lateral movement through shared privilege.

That shared access also blurs accountability. When permissions are common across functions, it becomes harder to answer a basic question: was a given action legitimate for this specific function, or only permitted because another function needed it? Separate roles make investigation and ownership clearer.

In practice, role sharing often hides unnecessary access creep. Teams add permissions to avoid breaking one function, then every other function bound to the role silently gains those rights. Over time, the role becomes a bundle of exceptions rather than a precise authorization boundary.

Designing Lambda Permissions for Least Privilege

The cleanest pattern is to assign each Lambda function its own role unless the functions are truly identical in trust and access needs. Where multiple functions share a role for convenience, treat that as an exception that must be justified by a matching permission profile and the same operational owner.

The most useful design check is simple: if one function does not need a permission, it should not inherit it just because another function in the same role does. That principle matters most when functions touch production data, admin APIs, queues, or other high-value resources.

Shared roles are also a sign to review surrounding controls, such as logging, alerting, and deployment separation. If you cannot easily tell which function used which permission, the role structure is probably too coarse for reliable governance.

Risk and Threat Considerations

Shared roles create a single compromise path across multiple functions, so one weak Lambda can become a gateway to the others. The main risk is not merely overpermission, but shared trust that turns a small failure into a broader access incident.

Failure mechanism: A vulnerable function, bad deployment, or leaked credentials tied to the shared role can be used to exercise every permission granted to that role, which widens the attacker’s available actions without requiring a separate privilege escalation step.

Impact: The result can be unauthorized data access, destructive changes, or movement into adjacent services that were only meant to be reachable by one function, not the whole group.

Practitioner Guidance

What to verify: Check whether every Lambda function using the role has the same resource access requirements, deployment owner, and blast-radius tolerance. If the functions differ materially, the shared role is usually masking an authorization boundary that should be split.

Decision rule: If the role can reach a production resource that only one function truly needs, break the role apart before adding more permissions to keep the shared design alive.

Practitioner takeaway: Treat the IAM role as part of the function’s security boundary, not as a reusable convenience object, because shared permissions make both compromise impact and governance drift much harder to contain.

Related resources from NHI Mgmt Group

• How should NHS trusts govern shared IAM across multiple organisations?
• What should IAM teams do when AI agents spread across multiple functions?
• What happens when a shared machine credential expires across multiple services?
• What happens when organisations try to manage IAM and PAM separately across multiple SaaS tools?