Best Practices for AWS Lambda & Optimization Strategies

Overview

AWS Lambda is a classic illustration of a series of cloud innovation products prevalently known as serverless or function-as-a-service or FaaS because it lets its clients run the code without provisioning or overseeing servers.

Before deep diving into best practices and optimization strategies, let us try to understand how does AWS Lambda pricing work.

AWS Lambda Pricing

AWS Lamba registers a request each time the execution begins in reaction to invoke call, or an event notification triggers for example Amazon S3, Amazon Event Bridge, and Amazon SNS. Here the time is calculated from the time code begins executing until it returns, or even in the case when the function stops, rounded up to the closest 1 ms.

The cost depends on the sum of memory you designate to your function. Within the AWS Lambda resource model, you select the sum of memory, you need for your function, and are allocated corresponding CPU power and other resources. An increase in memory and size triggers a comparable increase in CPU available to your work.

Timeouts

The maximum timeout esteems you’ll be able to arrange for an AWS Lambda function is 15 minutes. Whereas it may well be enticing to continuously set a timeout of 15 minutes (to dodge the timeout alarm) whereas it’s not a great thought to do so.

In reality, to keep an eye on performance/latency issues, Lambda function timeouts ought to be or maybe conservative – if a given function ought to execute beneath a second then the configured timeout ought to reflect that.

Otherwise, you may hazard superfluous costs – if a bug was introduced to your most-invoked function, bumping its length to example 15 minutes you wouldn’t even take note due to its high timeout value (but you’ll certainly notice the contrast on your AWS bill). Apart from that, your End-user experience will suffer since the client will be holding up for a long time for a response from your function.

Data Transfer Charges

AWS Lambda function costs for data exchanged “in” and “out” of your AWS Lambda functions are free within the same AWS region between services such as Amazon DynamoDB, Amazon Kinesis, and Amazon S3.    Additional charges are subject to apply on the off chance that you use other AWS services or transfer data, for case, reading or writing information to or from Amazon S3. This will include extra costs for reading/writing requests and data stored in S3.

Lambda Ephemeral Storage Pricing

Ephemeral storage cost depends on the sum of ephemeral storage you designate to your function, and function execution length, measured in milliseconds. You’ll designate any additional amount of storage to your function between 512 MB and 10240 MB, in 1 MB increases. You can design ephemeral storage for functions running on both x86 and Arm structures. 512 MB of ephemeral storage is accessible to each Lambda work at no additional cost. You simply pay for the additional ephemeral storage you configure.

Provisioned Concurrency Pricing

Provisioned Concurrency is calculated from the time you empower it on your function until it is disabled, adjusted up to the closest five minutes. The cost depends on the amount of memory you designate to your function and the amount of concurrency merely configure on it. Duration is calculated from the time your code starts executing until it returns or the function stops/ends, adjusted up to the closest 1ms

How to enhance the performance of Amazon Lambda and Reduce Cost?

A major factor in Lambda pricing is the overall duration of the invocation. The longer the function takes to run, the more it costs and the higher the latency in your application. The following are the best practices for writing efficient lambda code.

• Reduce the complexity of dependencies.
• Take the power of execution reuse. Initialize SDK clients and database associations outside the function handler, and cache inactive resources locally within the /tmp(temporary) directory. Consequent invocations can reuse open connections and resources in memory and in /tmp.
• Minimize deployment bundle size to its runtime necessities. This decreases the sum of time it takes for the bundle to be downloaded and unpacked.
• Avoid using recursive code
• Use environment variables to pass the static parameters to your function. It empowers you to dynamically pass settings to your function code and libraries, without making changes to your code. Environment variables are key-value pairs that merely make and modify as the portion of your function configuration.

Conclusion

Efficient code makes way better utilization of resources. Optimization ought to be a persistent cycle of improvement in the application and mapping out your prerequisites and how much it’ll cost to bring your idea into reality is the primary step toward getting started with serverless architecture.

About CloudThat

CloudThat is also the official AWS (Amazon Web Services) Advanced Consulting Partner and Training partner and Microsoft gold partner, helping people develop knowledge of the cloud and help their businesses aim for higher goals using best in industry cloud computing practices and expertise. We are on a mission to build a robust cloud computing ecosystem by disseminating knowledge on technological intricacies within the cloud space. Our blogs, webinars, case studies, and white papers enable all the stakeholders in the cloud computing sphere.

Drop a query if you have any questions regarding AWS Lambda and I will get back to you quickly.

To get started, go through our Consultancy page and Managed Services Package that is CloudThat’s offerings.