Adam Culp

Vonage Team Member

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.

[Read more]
< Tutorial />

How Permissions Work in AWS Lambda

Last updated 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.

Screenshot of new Meetings API session in progress
Start developing in minutes with free credits on us. No credit card required!

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_policy
aws_iam_s3_policy

amazon_iam_transcribe_policy
amazon_iam_transcribe_policy

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_permissions
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.