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_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.
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.
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.
With environment variables
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: '*'
iamRoleStatements block in the example above. In it, the Lambda is granted
s3:DeleteObject permissions to the resource
bucket-name and anything in it. Also, the function has access to
The example above is very similar to how IAM permissions get set in the examples below:
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.
From there, you can click into the permissions of each service for a more detailed breakdown of how you set them.
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.