How Permissions Work in AWS Lambda
Published on May 18, 2021

When working with AWS Lambda, many users struggle with permissions using other AWS services. More specifically, how to access services like S3, RDS, Transcribe, or others.

Vonage API Account

To complete this tutorial, you will need a Vonage API account. If you don’t have one already, you can sign up today and start building with free credit. Once you have an account, you can find your API Key and API Secret at the top of the Vonage API Dashboard.

This tutorial also uses a virtual phone number. To purchase one, go to Numbers > Buy Numbers and search for one that meets your needs.

Many create a new IAM user, and set AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in environment variables. The AWS SDK "automagically" uses those keys or values from an AWS Credentials File. (See the documentation on how the SDK uses those values.) However, adding those credentials for a Lambda would be a mistake.

Mistaken Identity

Attempting the following .env file prevents an application from accessing AWS services from within Lambda. Connection failure is regardless of how you configured the IAM user.

AWS_ACCESS_KEY_ID={{YOUR-ACCESS-KEY-HERE}} AWS_SECRET_ACCESS_KEY={{YOUR-SECRET-HERE}}

As the Lambda function deploys, the environment variables shown above get generated by Lambda. Meaning, the values of the file .env do not get set as expected.

To read more about deploying with Serverless, check out AWS Lambda With PHP Using Bref and Serverless Framework or Serverless Python with AWS Lambda.

Setting Permissions

With environment variables AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY set by Lambda, the role permissions also need set during deployment. All AWS services also get handled directly in the Lambda function instead of an IAM user.

Below is a partial yaml example using the Serverless framework to deploy an AWS Lambda function.

provider:
    name: aws
    region: us-east-1
    runtime: provided
    iamRoleStatements:
        - Effect: Allow
          Action:
              - s3:PutObject
              - s3:GetObject
              - s3:DeleteObject
          Resource: 'arn:aws:s3:::bucket-name/*'
        - Effect: Allow
          Action: transcribe:*
          Resource: '*'

Note the iamRoleStatements block in the example above. In it, the Lambda is granted s3:PutObject, s3:GetObject, and s3:DeleteObject permissions to the resource bucket-name and anything in it. Also, the function has access to transcribe:* services.

The example above is very similar to how IAM permissions get set in the examples below:

aws_iam_s3_policyAWS IAM S3 Policy Example

amazon_iam_transcribe_policyAWS IAM Transcribe Policy Example

Examining Permissions

Upon successful deployment to AWS Lambda, the active permissions of the function can be viewed in the AWS Console. Do this by navigating to the Permissions tab of the function console.

lambda_function_permissionsAWS Lambda Function Permissions

From there, you can click into the permissions of each service for a more detailed breakdown of how you set them.

What Next

Documentation about possible permissions to various AWS services are available in the AWS Identity and Access Management Documentation. Also, watch for future posts with examples of using these permissions in action.

Adam CulpVonage Alumni

Adam is a developer and consultant who enjoys ultra-running, blogging/vlogging, and helping others tame technology to accomplish amazing things with an insatiable desire to mentor and help.

Ready to start building?

Experience seamless connectivity, real-time messaging, and crystal-clear voice and video calls-all at your fingertips.

Subscribe to Our Developer Newsletter

Subscribe to our monthly newsletter to receive our latest updates on tutorials, releases, and events. No spam.