Execution policies are not to be confused with function-or resource-based policies. These policies explicitly grant permission for another AWS service to invoke that particular function. You might notice that the previous policy did not mention the lambda:InvokeFunction action, and that's because an execution policy defines what the Lambda can do once it is executing. 

You can also use a function policy to allow a service in another AWS account to invoke the function. Policies are added using the AddPermission action in the Lambda API, SDKs, and also by using the CLI.

Let's look at an example using the CLI:

aws lambda add-permission 
 --function-name StoreMessageInS3 
 --statement-id sns 
 --action lambda:InvokeFunction 
 --principal sns.amazonaws.com

This is a simple permission that allows the Simple Notification Service to invoke a Lambda function. This function is likely to be subscribed to an SNS topic, and the function will be invoked with the payload of a message that's been published to that topic.

We can also be more granular about our permissions. The following is an example of adding a permission to allow a specific ARN to invoke the lambda:

aws lambda add-permission 
    --region ap-southeast-2 
    --function-name GetRegionalForecast 
    --statement-id forecast1
    --action lambda:InvokeFunction
    --principal apigateway.amazonaws.com
    --source-arn "arn:aws:execute-api:southeast-2:"${ACCOUNT_ID}":"${API_ID}"/*/GET/weather/*/regional"

The source ARN is a particular Amazon API gateway method that is deployed in another account. This is an example of cross-account invocation. 

It was important to learn how to secure our functions right from the beginning. Now, we understand the types of policy and permission we need to keep safe while developing and deploying code. In the next section, we will learn about the ways a function can be invoked.