serverless-dotenv-plugin | Preload Environment Variables with Dotenv into Serverless | Serverless library

After some research we were able to connect our lambda to our vpc using serverless. The solution was: Stop using serverless-vpc-plugin.

It turns out that serverless-vpc-plugin, automatically creates a AWS VPC, which is not what we were looking for. We already had our VPC created using terraform.

From serverless-vpc-plugin documentation

Automatically creates an AWS Virtual Private Cloud (VPC) using all available Availability Zones (AZ) in a region.

In other words, serverless-vpc-plugin doesn't make sense when the target vpc already exists

Looks like adding externals: all to custom.bundle in serverless.yml fixed the issue.

The answer was pretty mundane. Serverless 2.32+ introduced some change that broke the pipeline. Reverting to version 2.31.0 resolved the issue.

Under your provider add timeout, maximum value of timeout in lambda is 900 seconds, place it according to your execution time like 30 seconds and see what happens

I used to get this error due to low or intermittent internet bandwidth.

serverless-bundle only includes the JS code that you use in your handler and strips everything else to minimize your bundle. That means the chrome binaries are excluded.

To include those binaries, add the following to your serverless.yml:

So, upon further investigation of this topic I think I have the solution. SSM Parameter Store vs Secrets Manager is an entirely different topic, but for my purpose, SSM Paremeter Store is a choice that I chose to go along with for this problem. And basically it can be done in 2 ways.

1. Use AWS Parameter Store

Simply by adding a secret in your AWS Parameter Store Console, then referencing the value in your serverless.yml as a Lambda environement variable. Serverless Framework is able to fetch the value from your AWS Parameter Store account on deploy.

provider: environement: stripeSecretKey: ${ssm:stripeSecretKey}

Finally, you can reference it in your code just as before:

const stripe = Stripe(process.env.stripeSecretKey);

PROS: This can be used along with a local .env file for both local and remote usage while keeping your Lambda code the same, ie. process.env.stripeSecretKey

CONS: Since the secrets are decrypted and then set as Lambda environment variables on deploy, if you go to your Lambda console, you'll be able to see the secret values in plain text. (Which kinda indicates some security issues)

That brings me to the second way of doing this, which I find more secure and which I ultimately choose:

2. Store in AWS Parameter Store, and decrypt at runtime To avoid exposing the secrets in plain text in your AWS Lambda Console, you can decrypt them at runtime instead. Here is how:

• Add the secrets in your AWS Parameter Store Console just as in the above step.

• Change your Lambda code to call the Parameter Store directly and decrypt the value at runtime:

  import stripePackage from 'stripe'; const aws = require('aws-sdk'); const ssm = new aws.SSM();

  const stripeSecretKey = ssm.getParameter( {Name: 'stripeSecretKey', WithDecryption: true} ).promise(); const stripe = stripePackage(stripeSecretKey.Parameter.Value);

(Small tip: If your Lambda is defined as async function, make sure to use await keyword before ssm.getParameter(...).promise(); )

PROS: Your secrets are not exposed in plain text at any point.

CONS: Your Lambda code does get a bit more complicated, and there is an added latency since it needs to fetch the value from the store. (But considering it's only one parameter and it's free, it's a good trade-off I guess)

For the conclusion I just want to mention that all this in order to work will require you to tweak your lambda's policy so it can access Systems Manager and your secret that's stored in Parameter Store, but that's easily inspected trough CloudWatch.

Hopefully this helps someone out, happy coding :)