Why use Lambda resource permission over API Gateway assumable role?

2
votes

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?

2
amazon-web-servicesaws-lambda
That is a question I asked myself as well, so I am looking forward to a answer by someone knowledgable. From my experience, I can only think of two things. First, to limit "blast radius". Imagine a single role that is allowed to invoke all the gateways Lambdas. If something happens to that single role (delete/misconfigured etc), all of the Lambdas of that Gateway will stop working. Second, ease of deployment. If you use Terraform for example, it is "better", because instead of extending a role you have two distinct resources (Lambda and Permissions) that you associated, which is easier. – Jens

2 Answers

0
votes

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
0
votes

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.