Lambda Top 10 Tips

A really quick post on some top tips when building Lambda applications to ensure they are well architected.

1. Save money by changing the CloudWatch logs retention period.

   By default this is infinite. Set the log group to something more sensible to automatically delete older logs. As a best practice create the log group in your infrastructure as code with a defined retention period.

   

2. Understand the default service quotas (limits) before going into production.

   Key limits to be aware of are:

   • 1,000 concurrency per region per account (soft limit - increase via support ticket)
   • 500-3000 burst concurrency, depending on region (hard limit)
   • 15 minute function timeout limit (hard limit)
   • 50 MB zipped, 250 MB unzipped deployment package size (hard limit)
   • 10,240 MB max memory (hard limit)

   Full list of Lambda service quotas

3. Use the Lambda PowerTools for useful libraries.

   This suite of utilities for Lambda functions enables you to easily adopt best practices for tracing, structured logging, custom metrics and parameter caching with a simple to use set of libraries. Available for Python, TypeScript and Java.

       from aws_lambda_powertools import Logger
   
       logger = Logger(service="payment")
   
       @logger.inject_lambda_context
       def handler(event, context):
           logger.info("Collecting payment")
   
           # You can log entire objects too
           logger.info({
           "operation": "collect_payment",
           "charge_id": event['charge_id']
           })
           ...
   

4. Don’t store secrets in your code!

   Put your secrets in an encrypted Lambda environment variable, or use AWS Parameter Store SecureString or AWS Secrets Manager to retrieve at runtime. Parameter Store is more cost effective that Secrets Manager (it’s free!), just be careful of the low default 40 TPS limit.

5. Use Step Functions for orchestration, don’t call another Lambda function from Lambda!

   If you call a Lambda function from another Lambda function synchronously you will be paying for idle wait time. Use Step Functions instead to help monitor and manage the orchestration, and only pay for state transitions.

6. Only attach a Lambda function to a VPC if necessary.

   Somewhere at some point people misunderstood Lambda VPC attachments and believed them to add additional security to a functions configuration. Only configure a VPC attachment if your Lambda function needs to access something in the VPC e.g. and RDS database. Otherwise don’t bother.

7. Reuse the execution environment correctly.

   This is covered in more detail in another post but make sure you understand how Lambda reuses execution environments on subsequent requests. This can help reduce your function execution time and save on your bill. Essentially you can cache into memory and into /tmp.

8. Tune your function’s memory.

   Use the AWS Lambda Power tuning tool to choose the best memory configuration for your function. Sometimes increases the memory can save money as the performance boost will reduce the overall execution time. This tool will help you choose the optimal value!

   

9. Minimize the deployment package size to only what is necessary.

   Keeping your deployment zip file (or container image!) as small as possible will help reduce cold start times (as the execution environment will need to download and unzip this each time). A smaller deployment package usually means less code and dependencies meaning a faster function and one that’s easier for someone else to understand!

10. Keep it simple!

    Lambda functions are designed to be small and lightweight. Break up larger functions into smaller ones and keep things simple. This makes them easier to understand and support and faster to run!