AWS Lambda Best practices: All in one place.

A curated list of best practices for developers to architects based on learnings and experience

If you have been following me I am sharing my best practices on various cloud services as an “All in one place” blog post series. It’s a consolidation of the learnings and experiences on one blog post so that my readers can easily digest and reference it when needed.

I usually group my best practices along standard Well architected Framework pillars from AWS as much as possible.

AWS Step Functions Best practices — All in one place.

Optimization for Performance :

• Interpreter-based languages are faster for first-time requests and compiler-based languages are better for subsequent requests.
• Use provisioned concurrency to address cold start issues.
• Lambda VPC mode has network overheads and also avoids DNS resolution to resources that you would access via the lambda function.
• Keep the dependencies lean — smaller functions with fewer dependencies would minimize cold starts.
• Use static variables and singleton to minimize the initialization time
• Define database connections globally
• When optimizing for performance consider concurrency execution limits.
• Cache static assets in the execution environments
• Cache stateless communication pipes like HTTP connections and Db Connections. You may have to check connection liveliness manually.
• Use AWS CloudWatch metrics and alarms to monitor the performance and usage of your Lambda functions. This can help you identify and optimize under-utilized or over-utilized functions.
• Use AWS Lambda layers to share standard code and dependencies across multiple functions. This can help you reduce duplication and improve the maintainability and performance of your functions.

Bonus Information — Just keep this in the back of your mind when designing with Lambda.

As you know memory size defines the amount of computing capacity you get. You will have one vCPU capacity when you reach a memory limit of 1,792 MB.

While setting up monitors keep in mind AWS will always keep an unreserved concurrency pool with a minimum of 100 concurrent executions to process the requests of functions that don’t have any specific limit set up

Optimizing for Cost :

• Make sure you use the optimal memory for your function. Here is a tool — AWS Lambda Power Tuning that can help you determine the optimal size.
• Use AWS Lambda reserved concurrency to manage the number of instances of your functions that are running at any given time. This can help you reduce idle time and minimize the number of instances that are running unnecessarily.
• If you are running languages like java and If you have a single-threaded app, you shouldn’t select more than 1,792 MB RAM, as it cannot make use of the additional CPU and the cost will increase. Conversely, if you have chosen less than 1,792 MB RAM and have multi-thread you would not be able to utilize the CPU power.
• If your downstream applications are resource-constrained or less time-sensitive then you can throttle the requests to protect the downstream systems.
• It's recommended to configure reserved concurrency — 500–3000 based on the AWS region.

Here is an article that talks about creating a succesful FinOps culture in the organization.

Path to successful cloud FinOps

Security :

• Use IAM roles to grant the least privilege access to your Lambda functions. This means giving your functions only the permissions they need to perform their intended tasks, and no more.
• Enable function-level permissions in your Lambda functions. This allows you to control which users or resources can invoke your functions.
• Use resource-based policies to control access to your Lambda functions. This allows you to specify which users or services can access your functions, and what actions they can perform.
• Enable encryption for your Lambda functions and their associated resources. This ensures that your data is protected while it is in transit and at rest.
• Monitor and audit your Lambda function for security events and suspicious activity. This allows you to detect and respond to potential security threats in a timely manner.
• Use AWS WAF to protect your Lambda functions from common web exploits and attacks. This can help prevent malicious actors from accessing or disrupting your functions.
• Regularly update and patch your Lambda functions to ensure that they are running the latest security updates and fixes. This can help prevent vulnerabilities and exploits from being exploited.
• Use AWS Config to track and monitor changes to your Lambda functions and their associated resources. This can help you detect and prevent unauthorized or malicious changes to your functions.

Reliability :

• Use SAM or Serverless frameworks to group the components and functionality into smaller pieces.
• Instead of using heavy frameworks ( eg Flask, Express) use AWS services directly. Also, avoid the monolith lambda function.
• Use AWS Lambda along with step-functions when complex workflow orchestration is needed. Step-Functions takes care of the heavy lifting and improves reliability.
• Use Multiple accounts for development teams as you may quite soon hit the account limits and that would impact productivity and testing.
• It is advised to always configure reserved concurrency.
• Where there is a huge influx of requests that cannot be processed write the failed and excess load to a data store and retry them with some intervals — individually or as batches with controlled sizes
• Use Lambda Alias for canary deployment — https://github.com/davidgf/serverless-plugin-canary-deployments
• Use RDS Proxy when using RDS from Lambda

Operational Excellence :

• Use the AWS Lambda function versions and aliases feature to manage and deploy different versions of your lambda. This can help in canary deployments or A/B testing without impacting existing workloads.
• In case you accidentally deployed a lambda that has a cyclic dependency or recursion then set the Reserved Concurrency to 0 so that the calls throttle and call the same instance. Once they settle down you can deploy your fix.
• Use Lambda Layers to hold common libraries and helpers.
• Do not cache dynamic data in the execution environment.
• These are cloud best practices 101, but I would still put them here for the sake of completeness

Automated scripts to create, update, repair, and tear down environments.

Save logs to Amazon CloudWatch.