As we discussed earlier, AWS Lambda is the central component in a serverless stack, or the integration connector with your custom code, triggered by events between AWS managed services. A Lambda function always has an execution IAM role associated with it, and using policies attached to that role is one of the best, and most secure, ways to deny or grant it access to other AWS resources. The beauty is that there is no need to manage or exchange any keys or passwords for a lot of the AWS managed services, such as S3, DynamoDB, and Kinesis Stream. There are some exceptions, such as some of the Amazon Relational Database Service (RDS), such as SQL Server, but MySQL or PostgreSQL do support IAM database authentication. The following diagram shows the workings of Lambda functions:

As the preceding diagram shows, there are generally two IAM roles involved in a Lambda function:

• Invoking the Lambda, for example, from API Gateway or AWS Step Functions
• Granting read and write access to AWS resources, for example, granting a Lambda read access to to a DynamoDB table

In addition, note the following:

• Key Management Service (KMS) can be used for the encryption/decryption of data at rest in DynamoDB or RDS, but also to encrypt passwords or keys, for example, should you need them to integrate with a third party API or database.
• Lambda is launched in a secure Virtual Private Cloud (VPC) by default. However, you can also run it inside your own private VPC if there are resources you need to access, such as ElastiCache clusters or RDS. You may also do so to add another layer of security.