How does IAM work in serverless applications?

Trace identity across the complete request path

A user may authenticate through an identity provider, call an API, and cause a function to access a table and publish an event. Each hop has its own authorization decision; an authenticated entry request does not automatically constrain every downstream action.

Draw the principal, action, resource, account, region, and relevant conditions for each edge. This reveals accidental privilege inheritance and makes denied requests diagnosable.

Distinguish execution roles and resource policies

A Lambda execution role grants the function permission to call other AWS APIs. A Lambda resource-based policy grants a principal, account, or AWS service permission to invoke or otherwise access the function resource.

Other services use their own combinations of identity and resource policies. Read the authorization model for each integration instead of copying a policy that happened to work elsewhere.

Build least privilege from real operations

Grant only required actions against explicit resources and conditions. Separate roles by workload responsibility so one compromised function does not inherit unrelated database, queue, secret, or administration access.

Use logs and policy-analysis tools to refine permissions after observing legitimate use. Avoid broad wildcards and long-lived exceptions, and test both allowed and denied paths as part of delivery.

Protect deployment and runtime separately

A deployment identity often needs permission to create roles and resources, which is more powerful than a runtime function role. Limit who can deploy, constrain role creation and passing, and use separate accounts or stages where risk requires it.

Record changes in infrastructure as code and audit API activity with CloudTrail. Alerts should cover unexpected policy changes, denied access patterns, sensitive secret or key use, and cross-account activity.