Using AWS Lambda functions – development of serverless applications

Bartosz Nowak | Cloud Services | 24.11.2021

AWS Lambda

At a time when the popularity of microservices architecture is growing, in addition to designing and writing applications, you should also take care to manage these applications, choose solutions for orchestration, network layer management, etc. This usually involves building a dedicated and specialized team. If you want to avoid this and make life a bit easier, you can write an application using serverless architecture such as AWS Lambda. Read on to find out more about using the AWS Lambda function, the costs involved, as well as the advantages and disadvantages of AWS Lambda.

What is AWS Lambda?

AWS Lambda is an event-driven serverless Function as a service (FaaS). The Lambda function allows you to write code and manage the application without the need to maintain your own servers. It allows you to create applications in the cloud, e.g. using the popular ZIP deployment method.

AWS Lambda

AWS Lambda functions

Function as a Service is gaining popularity because the user only pays for the processing time of a given function. For example, in the case of the REST service that triggers Lambda, the fee is charged only for a single endpoint call (this approach is known as pay-as-you-go) while maintaining availability, reliability and scalability.

How does AWS Lambda work?  

AWS Lambda cloud computing


This is an event that tigers AWS Lambda. The tiger can be 1 or more events from different AWS services, e.g.:

  • Call via API Gateway (REST call)
  • The addition, modification or deletion of a new file on Amazon S3
  • Message from the SQS queue or from external systems such as Atlassian, Symantec, PagerDuty and many others.

Each of these events could be a topic for a separate article, so if you would like to explore this matter further, I encourage you to read the Lambda Amazon Web Services documentation where everything is described in detail.

It is worth mentioning the type of the function call (InvocationType). Lambda can be triggered in two modes:

Synchronous – This mode can be compared to a REST call in which a request is sent and a response is received, which is why it is called a request/response type.

Asynchronous – In this mode, the request to Lambda is sent to the event queue. If an error occurs, the request will be sent twice at most. AWS does not guarantee that all messages will be delivered – for example, when an application cannot handle a given number of queued events. Since we do not know whether the function has been executed, using DLQ (dead-letter-queue) might be useful. In this case, the Destination Block helps us. This mode of triggering is called event triggering.

Serverless applications – supported programming languages

The function code can be written using one of the languages supported by AWS. Currently, we can choose from programming languages such as:

  • .NET (C#)
  • Java
  • GO
  • Node.js
  • Python
  • Ruby

Using technology such as e.g. Node.js, you can take advantage of the built-in editor to write a function. You can also provide the code for an externally created function as a package in a ZIP file. There are various plugins for development tools that can help you create a structured code package (such as Apache Maven Shade creating Uber-JAR).


This block is responsible for sending notifications about the status of the function execution. In the case of correct or incorrect execution, AWS can send a notification to one of the 3 available channels:

  • Topic SNS
  • Message on SQS
  • EventBridge

or run another Lambda function.

However, this functionality will only work while triggering the Lambda function asynchronously. When testing Lambda in UI AWS, the Destination Block will not work because the request is sent in the request/response mode, not event mode.

AWS Lambda Infrastructure

AWS Lambda is an FaaS which means that Amazon Web Services manages the infrastructure. The function code itself is stored on AWS S3. We should remember the limits, such as those concerning the amount of code in GB that can be stored in a given cloud region, among others. For the European region, the limit is 75 GB.

What is the life cycle of your application?

Lambda functions

When the request is sent to the Lambda function, it is launched as an instance of our service in the internal environment. It is similar to the AWS EC2 environment (virtual machines on AWS). However, the user does not have access to this environment. When we try to launch an instance, the AWS mechanisms check whether such an instance has already been launched, and – if it is running – whether it is processing the request. If the instance is busy, AWS Lambda mechanisms create a new instance of the function. Otherwise, it uses the current instance or, if the instance does not exist, creates a new one. If a function instance remains unused for a long time (AWS manages the time itself), the function instance is removed.

AWS Lambda and scalability

Now let’s move on to an aspect which is inseparable from the cloud, namely scalability. AWS Lambda, like any other service, has certain limitations, one of which is the limit of active instances for a given region – in the case of European AWS regions it is 1000 active instances. This pertains to all of the Lambda functions we have in our account in a given region. To ensure that the minimum number of instances is always launched when needed, you can book the number of instances per function in the Lambda configuration. Also, it is worth mentioning that each Lambda instance has access to the internal memory (/tmp) with a capacity of 512 MB which is not deleted until the instance is removed.

AWS Lambda parameters and configuration

When creating Lambda, two important parameters must be provided:

Memory – this is the available RAM assigned to the instance of our service. In the event of exceeding the memory limit, the instance is stopped. Currently, the maximum memory limit is 10 GB.

Timeout – the maximum time for the function execution. This is a very important cost-limiting parameter. If we set this parameter, for example to 30 seconds, and our function execution time is longer than the response time, this function will be stopped. You can set the maximum time of 15 minutes.

AWS Lambda – important configuration elements:

  • Environmental variables – this is where you can set the variables that will be transferred to your function (e.g. a bucket location on AWS S3). 
  • Permissions – Lambda access settings, e.g. to S3, RDS AWS etc. 
  • Network Settings – From Security Groups to Subnets to VPC. This is important if, for example, the database is in a specific Virtual Private Cloud. 

What else is worth remembering when creating AWS Lambda?

  • The selection of the technology in which the functions are written – this has an impact on the performance of the application. Using AWS Lambda, we pay for the duration of the service and memory used. The “thicker” the application is, the more memory it uses, and the longer the cold-start takes. This means that when triggering the function for the first time, we will simply pay more. In addition, the application will have a larger codebase, which will use more space on the Amazon S3. Among the technologies I have had the opportunity to use, the performance of Node.js was the best.
  • Error logging – the response from Lambda itself will not provide us with useful information, and Lambda monitoring and debugging is very limited. Keep in mind that logging on to AWS also includes costs if you need more advanced use than the free tier (trial version) allows. For this reason, I encourage you to familiarize yourself with Amazon CloudWatch pricing.
  • Creating Lambda with AWS CloudFormation – using AWS services will allow you to save time on creating and configuring resources and looking for dependencies. Moreover, it allows you to avoid many problems related to e.g. access or VPC (such as VPC configuration, so that AWS Lambda is visible to a database, or other services that we do not make available to the public).

The cost of Lambda AWS. Is it good value for money?

The answer is: it depends. In AWS Lambda, you pay for the amount of time you use the function for and the memory used. The billing unit used by AWS is gigabytes per second (GB / sec). You also pay for the number of requests; however, in the starter package for a new account (free tier) you get 1 million requests per month and 400,000 GB / sec. That’s quite a lot for free testing of AWS cloud solutions.

Example of costs

  • 1 million requests cost $0.20
  • 1 GB / sec. costs 0.0000166667 $ (in the case x86 architecture)

Let’s assume that we have an application serving 500,000 requests a day which needs 512 MB of memory. The total monthly cost is approximately $267. This is the only cost we will bear as we don’t need to maintain the application infrastructure (k8s, Service Mesh etc.).

I wouldn’t like to compare the costs to the server instance here, e.g. EC2, because this comparison would not be adequate. I will leave everyone to judge which approach is more viable for them.

Read also: Building WordPress on AWS

AWS Lambda – advantages and disadvantages

Lambda functions – advantages

  • Using a scripting language, you can quickly write an optimized function
  • Saving time on infrastructure management
  • Automatic scalability

Lambda functions – disadvantages

  • Depending on the selected technology (e.g. Java with Spring Boot), there may be a long boot time on the first call (cold-start) 
  • Monitoring limitations and low application debugging capabilities 
  • Due to the relatively short maximum time of function execution and the RAM limit, it will not work well for applications with a high computational overhead.  

Using AWS Lambda – summary

It is worth considering whether AWS Lambda will “lighten” our infrastructure and allow for cost optimization. As part of the analysis, it may turn out to be a tailor-made solution. Of course, AWS Lambda is not an ideal tool. It has its limitations, and it will not always allow you to achieve your goal. I hope that I have been able to introduce AWS Lambda, along with its advantages and disadvantages. I encourage all who are interested to explore this subject further and learn about the solutions allowing us to use the potential of AWS Lambda – S3 or SQS libraries. It is also worth investigating solutions allowing you to reduce the “cold-start”. There are many of them – AWS Serverless Java Container Spring to name one – but that is a topic for a separate article.


The author of the post is:

Java Developer

Despite his experience, he still has the feeling that there is a great deal of programming knowledge still to explore. Bartosz learns something new every day and admits that something constantly surprises him. He is fond of algorithmics, cloud solutions, and difficult programming problems. In his private life, he’s a fan of strength athletics and puzzles.

Add comment: