AWS Lambda Guide — Functions

Developer world
Jul 6, 2018 · 6 min read

If you are using AWS as a provider, all functions inside the service are AWS Lambda functions.

#Configuration

All of the Lambda functions in your serverless service can be found in serverless.yml under the functions property.

service: myService provider:  name: aws  runtime: nodejs6.10  memorySize: 512  timeout: 10  versionFunctions: false functions:  hello:  handler: handler.hello  name: ${self:provider.stage}-lambdaName  description: Description of what the lambda function does  runtime: python2.7  memorySize: 512  timeout: 10  reservedConcurrency: 5

The handler property points to the file and module containing the code you want to run in your function.

module.exports.functionOne = function(event, context, callback) {}

You can add as many functions as you want within this property.

service: myService provider:  name: aws  runtime: nodejs6.10 functions:  functionOne:  handler: handler.functionOne  description: optional description for your Lambda  functionTwo:  handler: handler.functionTwo  functionThree:  handler: handler.functionThree

Your functions can either inherit their settings from the provider property.

service: myService provider:  name: aws  runtime: nodejs6.10  memorySize: 512 functions:  functionOne:  handler: handler.functionOne

Or you can specify properties at the function level.

service: myService provider:  name: aws  runtime: nodejs6.10 functions:  functionOne:  handler: handler.functionOne  memorySize: 512

You can specify an array of functions, which is useful if you separate your functions in to different files:

... functions:  - ${file(../foo-functions.yml)}  - ${file(../bar-functions.yml)}getFoo:  handler: handler.foo deleteFoo:  handler: handler.foo

#Permissions

Every AWS Lambda function needs permission to interact with other AWS infrastructure resources within your account. These permissions are set via an AWS IAM Role. You can set permission policy statements within this role via the provider.iamRoleStatements property.

service: myService provider:  name: aws  runtime: nodejs6.10  iamRoleStatements:  - Effect: Allow  Action:  - dynamodb:DescribeTable  - dynamodb:Query  - dynamodb:Scan  - dynamodb:GetItem  - dynamodb:PutItem  - dynamodb:UpdateItem  - dynamodb:DeleteItem  Resource: "arn:aws:dynamodb:us-east-1:*:*" functions:  functionOne:  handler: handler.functionOne  memorySize: 512

Another example:

service: myService provider:  name: aws  iamRoleStatements:  - Effect: "Allow"  Action:  - "s3:ListBucket"  Resource: { "Fn::Join" : ["", ["arn:aws:s3:::", { "Ref" : "ServerlessDeploymentBucket"} ] ] }  - Effect: "Allow"  Action:  - "s3:PutObject"  Resource:  Fn::Join:  - ""  - - "arn:aws:s3:::"  - "Ref" : "ServerlessDeploymentBucket"  - "/*" functions:  functionOne:  handler: handler.functionOne  memorySize: 512

You can also use an existing IAM role by adding your IAM Role ARN in the role property. For example:

service: new-service provider:  name: aws  role: arn:aws:iam::YourAccountNumber:role/YourIamRole

See the documentation about IAM for function level IAM roles.

#VPC Configuration

You can add VPC configuration to a specific function in serverless.yml by adding a vpc object property in the function configuration. This object should contain the securityGroupIds and subnetIds array properties needed to construct VPC for this function. Here's an example configuration:

service: service-name provider: aws functions:  hello:  handler: handler.hello  vpc:  securityGroupIds:  - securityGroupId1  - securityGroupId2  subnetIds:  - subnetId1  - subnetId2

Or if you want to apply VPC configuration to all functions in your service, you can add the configuration to the higher level provider object, and overwrite these service level config at the function level. For example:

service: service-name provider:  name: aws  vpc:  securityGroupIds:  - securityGroupId1  - securityGroupId2  subnetIds:  - subnetId1  - subnetId2 functions:  hello:  handler: handler.hello  vpc:  securityGroupIds:  - securityGroupId1  - securityGroupId2  subnetIds:  - subnetId1  - subnetId2  users:  handler: handler.users

Then, when you run serverless deploy, VPC configuration will be deployed along with your lambda function.

VPC IAM permissions

The Lambda function execution role must have permissions to create, describe and delete Elastic Network Interfaces (ENI). When VPC configuration is provided the default AWS AWSLambdaVPCAccessExecutionRole will be associated with your Lambda execution role. In case custom roles are provided be sure to include the proper ManagedPolicyArns. For more information please check configuring a Lambda Function for Amazon VPC Access

VPC Lambda Internet Access

By default, when a Lambda function is executed inside a VPC, it loses internet access and some resources inside AWS may become unavailable. In order for S3 resources and DynamoDB resources to be available for your Lambda function running inside the VPC, a VPC end point needs to be created. For more information please check VPC Endpoint for Amazon S3. In order for other services such as Kinesis streams to be made available, a NAT Gateway needs to be configured inside the subnets that are being used to run the Lambda, for the VPC used to execute the Lambda. For more information, please check Enable Outgoing Internet Access within VPC

#Environment Variables

You can add environment variable configuration to a specific function in serverless.yml by adding an environment object property in the function configuration. This object should contain a key-value pairs of string to string:

service: service-name provider: aws functions:  hello:  handler: handler.hello  environment:  TABLE_NAME: tableName

Or if you want to apply environment variable configuration to all functions in your service, you can add the configuration to the higher level provider object. Environment variables configured at the function level are merged with those at the provider level, so your function with specific environment variables will also have access to the environment variables defined at the provider level. If an environment variable with the same key is defined at both the function and provider levels, the function-specific value overrides the provider-level default value. For example:

service: service-name provider:  name: aws  environment:  SYSTEM_NAME: mySystem  TABLE_NAME: tableName1 functions:  hello:  handler: handler.hello  users:  handler: handler.users  environment:  TABLE_NAME: tableName2

If you want your function’s environment variables to have the same values from your machine’s environment variables, please read the documentation about Referencing Environment Variables.

Using the tags configuration makes it possible to add key / value tags to your functions.

Those tags will appear in your AWS console and make it easier for you to group functions by tag or find functions with a common tag.

functions:  hello:  handler: handler.hello  tags:  foo: bar

Or if you want to apply tags configuration to all functions in your service, you can add the configuration to the higher level provider object. Tags configured at the function level are merged with those at the provider level, so your function with specific tags will get the tags defined at the provider level. If a tag with the same key is defined at both the function and provider levels, the function-specific value overrides the provider-level default value. For exemple:

service: service-name provider:  name: aws  tags:  foo: bar  baz: qux functions:  hello:  handler: handler.hello  users:  handler: handler.users  tags:  foo: quux

Real-world use cases where tagging your functions is helpful include:

  • Cost estimations (tag functions with an environment tag: environment: Production)

#Log Group Resources

By default, the framework will create LogGroups for your Lambdas. This makes it easy to clean up your log groups in the case you remove your service, and make the lambda IAM permissions much more specific and secure.

#Versioning Deployed Functions

By default, the framework creates function versions for every deploy. This behavior is optional, and can be turned off in cases where you don’t invoke past versions by their qualifier. If you would like to do this, you can invoke your functions as arn:aws:lambda:....:function/myFunc:3 to invoke version 3 for example.

To turn off this feature, set the provider-level option versionFunctions.

provider:  versionFunctions: false

These versions are not cleaned up by serverless, so make sure you use a plugin or other tool to prune sufficiently old versions. The framework can’t clean up versions because it doesn’t have information about whether older versions are invoked or not. This feature adds to the number of total stack outputs and resources because a function version is a separate resource from the function it refers to.

#Dead Letter Queue (DLQ)

When AWS lambda functions fail, they are retried. If the retries also fail, AWS has a feature to send information about the failed request to a SNS topic or SQS queue, called the Dead Letter Queue, which you can use to track and diagnose and react to lambda failures.

You can setup a dead letter queue for your serverless functions with the help of a SNS topic and the onError config parameter.

Note: You can only provide one onError config per function.

#DLQ with SNS

The SNS topic needs to be created beforehand and provided as an arn on the function level.

service: service provider:  name: aws  runtime: nodejs6.10 functions:  hello:  handler: handler.hello  onError: arn:aws:sns:us-east-1:XXXXXX:test

#DLQ with SQS

Although Dead Letter Queues support both SNS topics and SQS queues, the onError config currently only supports SNS topic arns due to a race condition when using SQS queue arns and updating the IAM role.

We’re working on a fix so that SQS queue arns will be supported in the future.

#KMS Keys

AWS Lambda uses AWS Key Management Service (KMS) to encrypt your environment variables at rest.

The awsKmsKeyArn config variable enables you a way to define your own KMS key which should be used for encryption.

service:  name: service-name  awsKmsKeyArn: arn:aws:kms:us-east-1:XXXXXX:key/some-hash provider:  name: aws  environment:  TABLE_NAME: tableName1 functions:  hello:  handler: handler.hello  awsKmsKeyArn: arn:aws:kms:us-east-1:XXXXXX:key/some-hash  environment:  TABLE_NAME: tableName2  goodbye:  handler: handler.goodbye

#Secrets using environment variables and KMS

When storing secrets in environment variables, AWS strongly suggests encrypting sensitive information. AWS provides a tutorial on using KMS for this purpose.

Originally published at serverless.com.

Developerworld

Learn to code, test and deploy.