Serverless computing or function-based computing is a way by which customers can develop backend systems or event-driven pipelines without worrying about the underlying infrastructure, which is managed by the cloud provider. It is billed based on the invocations and the duration of execution. While powerful, serverless computing has special security considerations that organizations must address. This is the first of three blogposts to discuss how best to secure your serverless computing environment in AWS Lambda.

What Is AWS Lambda?

Amazon Web Services (AWS) accounts for over 33% of the global market share in cloud computing. At the time of this writing, there are over 200 services provided by AWS in various fields including compute, storage, big data, machine learning, artificial intelligence, and security.

AWS Lambda is one of these services: a stateless event-based function as a service (FaaS) from Amazon that allows users to run applications on the cloud based on a trigger. A trigger can be an event that is either external or within the AWS ecosystem. Responding to incoming HTTP requests, invoking a function when a file is updated in S3, consuming messages from a queue, etc. are examples of triggers that can be integrated with AWS Lambda. It provides an interface for customers to run and execute code without the need to provision a dedicated server or container. AWS takes care of this once the Lambda function starts. AWS Lambda has native support for major programming languages, including Java, Python, and Go. It is a fully managed service that lets developers focus more on business logic instead of dealing with servers.

How Does a Lambda Function Work?

Lambda functions are usually associated with triggers that define when the functions need to execute. Many services within the AWS ecosystem can act as a trigger, including an S3 bucket, an SNS topic, an EventBridge rule, etc.

Figure 1: Basic architecture of a Lambda function

A very common use case for Lambda functions is to process RAW images for websites. In the figure above, a user uploads a RAW image to an S3 bucket and defines triggers on the bucket to execute a function. The filename is passed as an event payload to the Lambda function, which then resizes and creates two different images, one for the web and one for mobile.

Lambda functions can be scaled and run in parallel based on the number of requests received. This makes it highly scalable and robust for various types of workloads. Of course, there are some limitations while using a Lambda function; for example, the maximum duration within which a function can be executed is 15 minutes. Similarly, there are throttling limits, which means only certain concurrent executions are possible, while requests beyond that limit will be throttled.

Use Cases for AWS Lambda

Lambda functions are stateless and event-driven, which makes them suitable for a large number of use cases; some of the most common ones are discussed below.

Microservices Architecture

The cloud computing market has seen an increasing demand for microservice architecture. In such a setup, domains are split into microservices, with each service having its own function and database. These functions are independent of one another so that in case one microservice stops working, the other services remain unimpacted.

Figure 2: Microservices architecture sample diagram

The figure above highlights a simple architecture where products, orders, and payments are classified as microservices and each has its own database. User requests are routed through Amazon API Gateway to the appropriate microservice for processing.

Event-Driven Pipelines

Event-driven architecture is a pattern of integrating loosely-coupled applications by means of events or messages. An event can be considered as the unit of information based on which a downstream application can be triggered. Creating a file in S3, ordering products in an e-commerce store, etc. are examples of simple events. Since Lambda functions can be driven by triggers, they are a perfect candidate while designing event-driven pipelines. In this architecture, there may be one or many Lambda functions that respond to an event. In the figure below, an order is placed, which is the event.

Figure 3: An example of an event-driven pipeline

This event is then fed to an SNS topic to which three Lambda functions are subscribed. The first function is responsible for sending a confirmation email to the customer using AWS SES; the second updates the inventory database; and the third function dispatches the order details to the delivery service.

In our next blog post in this series, we’ll discuss the unique security considerations for AWS Lambda.

You may also like