AWS Lambda: Hidden treasures

Factors most developers don’t apply when working with AWS Lambda functions

No matter your level of expertise in AWS, there’s a high chance you’ll be working, or you already worked with AWS Lambda. It is a service that provides us the ease of launching and implementing our code without worrying much about server related maintenance and tasks.

Still there are features and components that many developers are not aware of that could be of great benefit to your projects.

Provided Environment Variables

AWS Lambda allows you to configure Environment variables for your functions:

https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html#configuration-envvars-config

This is great, but what I’ve seen from some developers is that they add environment variables with values such as: Account number, region, runtime, selected language selected, etc.

The thing is that AWS Lambda provides a set of environment variables in which you can use in your code and avoid defining it in your “Environment variables”.

If you want to see the list of Environment variables your function has (aws provided and user defined), then just simply print it.

Here’s an example of how to show all the environment variables in Node.js:

Dependencies

In our day-to-day tasks as developers, we take on suggestions from our saviors (Stackoverflow & github) in which mostly we adopt new libraries/dependencies on our code.

AWS Lambda has an internal library repository in which provides the dependencies for your project, but I still recommend you provide those dependencies anyway it because of the following reasons:

1. The repository updates constantly, which brings the risks of your code failing. The dependency might update one day and remove or modify a code you’re using.
   2. Not all libraries you’re using are available in the internal library repository that Lambda provides.

I recommend you upload your libraries to an AWS Lambda Layer which provides assurance that your code will continue working as expected.

More info: https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html

Versioning

It’s always important to keep track of your function changes in AWS Lambda and its history (versions).

I’ve seen most developers when implementing a change, at hand they have the new package they want to upload and the previous package in case they need to rollback.

It is not a good strategy because of the large amount of human error it may inflict to your project. The good thing is that AWS Lambda has the feature in which you can version your instance changes (Makes rolling back easier).

More info: https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html

Alias

When working with AWS Lambda function you may establish a connection with other services such as: API Gateway, Firehose, EventBridge, etc.

You can establish which version of your AWS Lambda function to use to interact with those other services (if not, then it uses the latest version).

Which is great, but each time you change the version, then you must also change it in the connection you’ve established with those other services.

AWS Lambda provides a feature called “Alias” that acts as a pointer in which you specify the version you want to use for that connection, then in the connection to those other services you only specify the Alias instead of the version.

This makes it easier to deploy or rollback changes directly in AWS Lambda Alias and avoid changes to the connections to the other services.

This makes AWS Lambda reliable when your function connects to multiple services.

More information: https://docs.aws.amazon.com/lambda/latest/dg/configuration-aliases.html

Concurrency

Eventually you will topple with the capacity that AWS Lambda provides. When you expect a large number of events to reach your functions, then it is best to be prepared.

As you work with AWS Lambda, the term “concurrency” will appear. Concurrency determines the amount of instances your AWS Lambda function will have at your disposal.

More information: https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html

Which is great because you’ve established an initial number of instances for your function to handle that large traffic, but what happens if it continues to grow beyond your expectation?

No worries, you can increase the number of instances you’ve established in your concurrency by creating Application Auto Scaling for the function. It’s a bit difficult at first, but provides assurance that your function will continue working.

More information: https://docs.aws.amazon.com/autoscaling/application/userguide/services-that-can-integrate-lambda.html

Parameter Storage

At the beginning of this post I wrote about “Environment variables”.

You may encounter situations in which many of your functions contain the same environment variable; this can be time consuming if you need to change each function manually.

The best solution would be to use a “key-value” storage service in AWS that allows you define that environment variable just to keep it in one place and just invoke it from your functions. In which centralizes the environment variable and reduces that maintenance burden.

AWS provides two services which are AWS SSM Parameter Store and AWS Secret Manager that are ideal to use for that scenario (and many others). I was always recommended to use AWS Secrets Manager because it provides more features.

You decide: https://tutorialsdojo.com/aws-secrets-manager-vs-systems-manager-parameter-store/#:~:text=Parameter%20Store%20only%20allows%20one,versions%20by%20the%20staging%20labels.

Logging

Like many services in AWS, AWS Lambda can also write logs and metrics to the AWS CloudWatch service in which provides a simple to search and analyze its status.

Of course, it’s simple enough to write logs towards AWS CloudWatch, but you must consider how you’re going to write it.

This is a factor that may affect you’re troubleshooting when querying your logs (don’t write just anything to your logs).

I’d recommend the following because it has helped me in my projects involving AWS Lambda: https://aws.amazon.com/blogs/apn/complexities-and-best-practices-for-aws-lambda-logging/

Code Integrity

In this previous post it shows how to establish code integrity for code packages in AWS Lambda using AWS Signer:

Sign your AWS Lambda packages

AWS Signer allows you to sign AWS Lambda packages and maintain control of which ones to allows or reject.

DevOps

One of the traits that we “the developers” share is the love for automation, we desire to continue working on new projects instead of managing repetitive manual tasks.

In regard to AWS Lambda, we want to avoid running the usual steps to prepare a package: build project, run unit tests, code coverage report, etc.

Luckily AWS provided an array of services that allows you to automate by applying DevOps strategy, which allows you to just push your code to your repository and continue with your other tasks while the Pipeline takes care of the rest.

A fellow blogger posted an example on how to do that with AWS Codepipeline: https://medium.com/hatchsoftware/setting-up-ci-cd-for-lambda-functions-using-aws-codepipeline-880567769dde

Conclusion

AWS Lambda is a service you’ll be using in 85% of your projects, it is of great use, as well as great maintenance.

There are many factors I must’ve not contemplated, please leave a comment about that as well as something you would like to share related with your experience with projects using AWS Lambda.

Hope you found this useful, it was a bit difficult to leverage. Still proud of the results.

Thank you as always and Gracias!!!