AWS Identity and Access Management (IAM) is where you set up users and groups to create and assign roles and permissions to those users. You may want to assign a user with specific access to certain functionality that will be used by a Lambda, or a user login for someone to log into AWS and view logs. All of these things are done here in IAM.
You can set up a group of permissions as a policy, or use a pre-existing policy, and then assign those to a user.
An example of a pre-existing policy just pulled at random from the policy list is: arn:aws:iam::aws:policy/AmazonElasticTranscoder_JobsSubmitter which is described as 'Grants users permission to change presets, submit jobs, and view Elastic Transcoder settings. This policy also grants some read-only access to some other services required to use the Elastic Transcode console, including S3, IAM, and SNS.’
Many different policies exist, and there is a huge amount of customization and fine-tuning that can be done to user permissions, so it’s worthwhile coming up with a plan early on. However, if you are just going to be using some Lambdas to do some data processing you can actually leave it up to the config defined in Serverless to assign permissions to the user.
When setting up the various elements in your Lambda config you will need to make sure you set up the correct permissions so that the user that runs the Lambda has the permission to access the required features. If your Lambda user only has access to S3, and you then decide to include a queue with SQS, you will need to update the permissions.