serverless.yml
configuration that defines a single permissions role for all functions deployed with this project:serverless.yml
file:func0
, func1
.role
directive on lines 9 and 12.subscribeToEmailNotification
function sanitizes input and then the sendNotification
function is triggered to process and deliver that input. You may be inclined to skip sanitization of any input event for the second function after having already sanitized the latter “subscribe” function. If at a later point in time, a new subscribeToSMSNotification
function is created which does not sanitize input, that again leads to allowing the sendNotification
function to process event data without sanitizing the data as well.lirantal/bazz-serverless
after being scanned and including several high, medium and low vulnerabilities. This is the source code for my serverless project which deploys several functions. Below the GitHub project repository we can see all six of the AWS Lambda functions that I deployed, and these are the actual functions as they are deployed and executed by AWS.${ssm:/github/api-key}
will return the encrypted value of that key and if we wanted to decrypt and return the actual value we need to specify ${ssm:/github/api-key~true}
.package.json
file with dependencies that are deployed with each and every function but may not all be explicitly required by all of the other functions.service
is like a project. It's where you define your AWS Lambda Functions, the events
that trigger them and any AWS infrastructure resources
they require, all in a file called serverless.yml
.service
.create
command. You must also pass in a runtime (e.g., node.js, python etc.) you would like to write the service in. You can also pass in a path to create a directory and auto-name your service:serverless.yml
handler.js
service
configuration is managed in the serverless.yml
file. The main responsibilities of this file are:events
section to automatically create the resources required for the event upon deploymentfunctions
definition which points to the handler.js
file. Any further service configuration will be done in this file.serverless.yml
translates to a single AWS CloudFormation template and a CloudFormation stack is created from that resulting CloudFormation template.handler.js
file contains your function code. The function definition in serverless.yml
will point to this handler.js
file and the function exported here.serverless invoke -p event.json
serverless.yml
are translated to an AWS CloudFormation template and deployed as a single CloudFormation stack.cd
into the relevant service directory:deploy
command:dev
stage and us-east-1
region on AWS, unless you specified these elsewhere, or add them in as options:remove
command.serverless remove -v
to trigger the removal process. As in the deploy step we're also running in the verbose
mode so you can see all details of the remove process.npm install -g serverless
. This way you have the Serverless CLI available for all your services.frameworkVersion
property in your serverless.yaml. Whenever you run a Serverless command from the CLI it checks if your current Serverless version is matching the frameworkVersion
range. The CLI uses Semantic Versioning so you can pin it to an exact version or provide a range. In general we recommend to pin to an exact version to ensure everybody in your team has the exact same setup and no unexpected problems happen.package.json
, then you can install Serverless as follows: