In lambda security, there are two types of IAM roles:

• Invoking the lambda: This means having the permissions to actually invoke and run a lambda function. For example, this could be from an API Gateway or another service.
• Granting lambda function read and write access to specific AWS resources: For example, you would allow a Lambda function to read from a DynamoDB table.

In addition, the Key Management Service (KMS), which is an AWS-managed service for keys, allows you to perform encryption and decryption on data at rest such as in a database or a NoSQL data store, such as DynamoDB. Amazon Virtual Private Cloud is another option where Lambda runs, by default, within a secure VPC. However, you may want to run it inside your own private AWS VPC if there are resources you need to access, such as elastic clash clusters or RDS, that are within this private VPC. Here is a work flow representation of using AWS Lambda using AWS KMS and AWS VPC:

For API Gateway security, there are three ways you can control who can call your API method. This is known as request authorization, shown in the following diagram:

Here are the different ways to control who can call your API:

• IAM roles and policies: This provides access to the API Gateway. API Gateway will use these roles and policies to verify the caller's signature upon request.
• Amazon Cognito user pools: This controls who can access the API. In this case, the user will have to sign in to access the API.
• An API Gateway custom authorizer: This is a request, such as a bearer token or lambda function, that deals with validation and checks whether the client is authorized to call the API.

If you get requests from a domain other than your API's own domain, you must enable cross-origin resource sharing. In addition, API Gateway supports SSL certificates and certificate authorities. API Gateway may need authorization via an IAM role to call or invoke specific resources within AWS, such as with Kinesis streams or to invoke a Lambda function.