AWS Lambda - Don't play with it without knowing this.

Let’s talk about one of my fav service in AWS!

Lambda is one of the simplest and most user-friendly services in AWS. Simplicity of such a powerful tool can make it a double-edged sword. Before play with it, it's important to understand a few key concepts to make the most of it without burning your hand. In this thread, I’ll explain what I know, and the comment space is open for you to add any additional points. I'll update the blog post with your insights to make it even better!

I’ve tried to add all relevant point in below Q&A flow chart:

1.) Do you know how pricing works in Lambda?

Lambda pricing is based on two main factors:

1. Requests

2. Execution time

You are charged for each request your function handles and for how long it runs. But it’s not just about counting requests. AWS also charges based on memory allocation and execution duration. You can choose memory anywhere between 128 MB and 10 GB for your function, and your bill will depend on the amount of memory you allocate and how long the function runs. Make sure you understand these pricing models and optimise them according to your requirements.

Now lets see how you can optimise the price: performance ratio of your lambda based on the requirements.

1.) Is your code is reviewed properly & Optimised?

"Code review time! Let’s find out what’s hiding in those curly braces!"

Code reviews help identify areas where Lambda functions can be more efficient in terms of memory usage, execution time, and resource allocation, which directly impacts cost optimisation and performance .

• Review the lambda best practices guidelines to write code: It may seem boring, but it will definitely improve the way you write code and results improve the user experience.

• Use code optimization tools, e.g., "AWS CodeGuru."

• Our code might be fine, but other bottlenecks could be causing issues. Always consider using tracing tools to identify these bottlenecks and adjust the code accordingly. Since we are talking about AWS, let’s consider AWS X-Ray (who comes up with the names for this services? It's funny and perfect name for a tracing tool, isn't it?).

2.) Is your compute configuration is optimised?

a) lets review the configuration, in lambda deployment You'll have to give only single compute configuration that is “Memory”

Wait, then what about CPU:?

Lambda allocates CPU power in proportion to the amount of memory configured. Memory is the amount of memory available to your Lambda function at runtime. You can increase or decrease the memory and CPU power allocated to your function using the Memory setting. You can configure memory between 128 MB and 10,240 MB in 1-MB increments. At 1,769 MB, a function has the equivalent of one vCPU (one vCPU-second of credits per second).

Refer this - docs.aws.amazon.com/lambda/latest/dg/config..

Allocating more memory can reduce execution time, but it might increase the cost. It’s important to find a balance between memory and execution time - there are some tools are available to tune this configuration
Basically, you can provide a Lambda function ARN as input and the state machine will invoke that function with multiple power configurations (from 128MB to 10GB, you decide which values). Then it will analyze all the execution logs and suggest you the best power configuration to minimize cost and/or maximize performance.

Refer - https://github.com/aws-samples/optimizations-for-lambda-functions

b) Set an Appropriate Timeout: Lambda functions can run for a maximum of 15 minutes. Setting a reasonable timeout ensures that your function doesn’t run longer than necessary, avoiding extra costs.

• Estimate Function Execution Time: Test your function’s average execution time under normal conditions to set an appropriate timeout. If your function is part of a workflow, ensure the timeout aligns with other services’ timeout settings (e.g., API Gateway or Step Functions).

• Avoid Too Long or Too Short Timeout: If the timeout is too short, your Lambda may fail before completing its task, and if it’s too long, you’ll be paying for idle time.

3.) Do you have a cold start problem and have you thought about using provisioned concurrency?

before jump into the provisioned concurrency, we have to understand the “cold start” problem,

Cold start happens when your Lambda function is invoked after being idle for some time or when AWS scales it up to handle increased traffic. This delay in starting the function can lead to slower response times, especially for real-time applications. For workloads where low latency is essential, this can be an issue. Cold starts aren’t always avoidable, but you can minimise their impact by using Provisioned Concurrency, which keeps a set number of Lambda instances pre-warmed and ready to go.

Now we know about cold start problem, and its always good to use provisioned concurrency for a SRE’s point of view but when business and cost comes to picture we should consider few other items also, I’ve put some of the consideration in below “decision making flow chart” - lets go through it.

4. ) Have you optimised the lambda invocation?

   managing Lambda invocations is key to improving performance and reducing costs, idea is simple its just reduce the invocation events without impacting the business logic.
   - One of the first things to do is to combine event processing. By grouping multiple records into a single invocation for event sources like SQS, DynamoDB Streams, or Kinesis, you can reduce the number of invocations and increase throughput.
   - Another important optimisation is event filtering, which ensures only relevant events reach your Lambda function. Using EventBridge rules, S3 event filters, and API Gateway request validation can help avoid unnecessary executions by processing only meaningful events

5. ) Have you make use of lambda commit usage discount? - Compute savings plan

   To further optimise Lambda costs, you can take advantage of Compute Savings Plans. These plans allow you to commit to a consistent amount of Lambda usage for a one- or three-year term in exchange for significant savings. By committing to a certain level of usage (measured in dollars per hour), you can reduce your Lambda costs by up to 17%. This is especially useful for workloads with predictable usage patterns, as it locks in lower pricing and helps avoid unexpected spikes in costs. So, if your Lambda functions run consistently, signing up for a Compute Savings Plan can be a great way to save while maintaining performance.

To wrap up, optimizing your AWS Lambda functions is essential for improving both performance and cost-efficiency. From minimizing cold starts with provisioned concurrency to optimizing code execution and resource usage, every step plays a key role in maximizing Lambda’s potential. By continuously monitoring performance metrics and making data-driven adjustments, you can ensure your Lambda functions scale efficiently, deliver faster responses, and maintain a smooth user experience. The goal is to find the right balance between cost and performance to get the most out of your serverless architecture.

📚 "Stay in the know! Subscribe to the blog for the latest insights on tech trends, SRE/ DevOps and Cloud strategies, and more. 📚#StayTuned
- Site Reliability.in