Why use Lambda resource permission over API Gateway assumable role?

Question

I'm struggling to understand the practical differences between an execution role that can be assumed by API gateway to grant the permission to execute a lambda over a lambda resource-based policy.

For example, the documentation here provides an example of a policy that can be assumed by the API gateway to invoke a Lambda.

However, the API Gateway console will grant itself permission to access a Lambda via a lambda resource-based policy.

Both achieve the desired outcome of allowing the API Gateway to execute a Lambda. So is there a reason to choose one over the other?

user_3844353 · Answer

Apart from the general use case / advantages of having resource-based policy that is explained pretty well here

does not have to give up his or her permissions to receive the role permissions

In this specific case, I have experienced 2 distintive advantages using Lambda's resource based policy over role

The creator of Lambda - API Gateway integration does not need to have access to IAM. No role created
Because no role is created, no role need to be cleaned up. The developer delete the Lambda function he created to play around and everyone can forget about it

user_157605 · Answer

I think one of the significant advantages of resource-based policies is that they can be applied to specific versions or aliases. This is unlike IAM roles, which cannot target a specific version or alias.

Why use Lambda resource permission over API Gateway assumable role?

2 Answers