Serverless computing enables DevOps teams to build applications without maintaining or managing servers in the cloud.
This enables teams to focus on developing new features and deploying new releases instead of worrying about infrastructure. It can also significantly reduce IT workloads in terms of server maintenance and management.
Amazon Web Services (AWS) offers multiple serverless options for compute, storage, databases, message queueing, and stream processing.
This post compares AWS Lambda, AWS Step Functions, and Lambda@Edge services in terms of pricing, use cases, and runtimes.
What is AWS Lambda?
AWS Lambda is a serverless computing service offered by AWS. Developers can use Lambda to execute their code in the cloud. AWS Lambda uses Lambda functions to enable the use of the most popular coding languages.
You can run these functions independently of other code and output a result directly to users, other functions, or for consumption by other services. With Lambda, you only have to worry about your function and how output is used; the backend infrastructure is managed for you.
Similar to any serverless system, Lambda manages and provisions cloud infrastructure. Including servers, databases, backend, and security logic. You can build front-end applications without the complexities of physical hardware. The pricing of Lambda is based on the number of executions, and functions are offered as a service.
AWS Lambda use cases include:
- File processing—imagine you have an application that provides files at random times, and you want to convert these files to a different format. You can convert these files by sending them to a Lambda function.
- Website hosting—you can host websites on S3 and outsource all computations to AWS Lambda. This enables you to run your website without paying for any actual server hosting.
- Security updates—you can monitor your website’s log files with Lambda functions. You need to trigger your Lambda code when a log file changes.
Practical advice from AWS experts to help you weather the storm
With extensive insights, advice, and best practices from cloud leaders, our brand new white paper is the ultimate guide to optimizing your business with AWS.
How AWS Lambda works
Before getting started with AWS Lambda, let’s get to know its system components, execution models, and specs.
AWS Lambda components include:
- Function code—the function you want to run when Lambda is triggered.
- Configuration specs—details defining how functions are executed and what resources are required.
- Event triggers—an optional source that triggers the function from other AWS services or external services. You can also trigger functions manually.
- Handler—a method that processes events in your function and returns the results. It is used as the communication between the function and external services.
- Environment variables—enables you to store runtime information in key-value pairs. You can use these to define function configuration externally.
Here is how AWS Lambda execution model works:
- Containers—Lambda allocates a container and loads the code resources necessary to execute a function. It may reuse the same container to improve performance.
- Instances—each instance can only process one invocation at a time. To handle simultaneous invocations, the number of instances can autoscale to meet request demands.
- Events—events trigger Lambda functions. You can trigger events with several AWS or third-party services.
- Stateless functions—containers are ephemeral with no persistent storage and functions are stateless. You can use temporary storage in the container, such as to retain loaded dependencies but the function itself retains no history of previous runtimes.
Here are some AWS Lambda specs you need to understand:
- Supported languages and runtimes—supports Node.js: 10, 12 Python 2.7, 3.6, 3.7 and 3.8, Ruby 2.5, 2.7, Go 1.x, .NET Core: 2.1, 3.1, and Java 8, 11.
- Functions run inside containers—each with a 64-bit Amazon Linux AMI image. This limits you to binaries that can be compiled in that environment.
- Memory capacity—you can define memory resources between 128 MB and 3,008 MB in 64-MB increments. The amount you allocate is linearly proportional to CPU available with every 1,792 MB of memory granting access to the equivalent of one vCPU.
- Function timeout—Lambda allows a function to run for a limited time before stopping. The default is three seconds. The maximum allowed time is 15 minutes.
- The /tmp directory—is used as ephemeral disk space. Subsequent triggers don’t have access to the /tmp directory.
- Function packages—uncompressed function packages are limited to 250MB, and compressed function packages are limited to 50MB.
What is AWS Lambda@Edge?
AWS Lambda@Edge is an extension of AWS Lambda that grants greater flexibility and lower latency to distributed Lambda functions. You can run Lambda@Edge functions with Node.js and Python.
The benefit of Lambda@Edge is that it uses the Amazon CloudFront content delivery network (CDN) to enable you to deliver function results globally. This is in contrast to Lambda, which requires you to provision instances in each location you want to operate from.
For example, imagine you are managing a serverless application in Chicago. With Lambda, a user in London would have to wait for a function request to travel all the way to your host server in the US and back.
To reduce this time, you would need to configure a mirror in Europe and manage two Lambda configurations.
With Lambda@Edge, you can manage your single configuration in the US and the CloudFront CDN automatically runs your function in the closest server to the user. This reduces latency without requiring additional management on your part.
Lambda@Edge use cases
There are many uses for Lambda@Edge processing. For example:
- Dynamic edge applications—you can combine Lambda@Edge with other AWS services when building applications at the network edge.
- A/B testing—you can release updates to your website while testing different versions of your website without changing the URL or redirect.
- User authorization and authentication—you can authorize and authenticate users by filtering out unauthorized requests before they reach your infrastructure. For instance, you can trigger a Lambda function to authorize each user request by calling authentication services like Amazon Cognito.
- User prioritization—you can prioritize and control access to your website by routing users to different pages. For instance, you can trigger a Lambda function to prioritize paid users on your eCommerce website for surges during peak traffic.
- Website security and privacy—you can add HTTP security headers on all responses without modifying your application code. This helps improve privacy and security while delivering content at low latencies using CloudFront.
- User Tracking and Analytics—you can analyze and track user activity on your website and mobile applications, including clickstream analysis.
What are AWS Step Functions?
AWS Step Functions are designed to help DevOps teams manage multiple operations on AWS using a visual workflow editor. For example, you can create linked process steps with the output of one step becoming the input for the following step.
Step Functions translate your application development workflow into an easy-to-understand machine diagram. Step Functions automatically triggers and tracks each step of the process, and retries when there are errors.
You can use it to simplify complex workflows like machine learning model training, IT automation, and report generation.
How AWS Step Functions works
AWS Step Functions is based on the concepts of state machines and tasks. These functions are used to pass state information from task to task once a defined event trigger is sent.
State Machine
State machines represent the states you need to create in your process, the relationships of those states, and their input and output. For instance, you can create a state machine that coordinates each task in a workflow to improve customer experience. To create a state machine, you need to create a JSON template using the API or the AWS Console. The template must follow the Amazon States Language.
State
States are the individual elements of a state machine. Each state can make decisions based on the input, perform actions, and pass the output to other states. You can refer to a state by its name. The name must be a unique string within the scope of the entire state machine.
Task
Tasks define how your states get their work done. Tasks can perform work through Lambda functions, by using an activity, or by passing parameters to the API of other services. These services include Simple Queue Service (SQS), Simple Notification Service (SNS), and DynamoDB.
An activity consists of program code that waits for an operator to perform an action or to provide input. You can host activities on Amazon EC2, Amazon ECS, or even on mobile devices.
How AWS Step Functions scales and orchestrates serverless apps
Often, organizations want to scale applications according to their growing workloads, while paying less, and allowing different teams to work simultaneously on the app.
In the serverless model, you can achieve these goals by separating business logic into several decoupled services. A large serverless application can include a few hundred services.
The challenge comes when a large number of services need access to different parts of a shared state. In that case, you need to orchestrate the flow of data through all application services in a single place.
Step Functions help you handle all the data and state management necessary to keep serverless systems working effectively and at scale.
AWS Step Functions limits
AWS Step Functions have several limits per workflow and per AWS account. You can change those limitations by submitting a limit increase request via the AWS support center. However, some limits can’t be changed:
- Execution history of 25,000 items in a workflow—your workflow can’t have more than 25,000 state transitions in a single execution.
- Maximum request size of 1MB—a Step Functions request can’t have a payload larger than 1MB. Consider using S3 storage if you want to use larger files as inputs.
- AWS API requests spikes—if some parts of your workflow use the AWS API inefficiently, a large number of requests from your workflow can trigger the API limits.
- 50 tags per resource—you can’t apply more than 50 tags to any of the step functions resources.
AWS Step Functions use cases
AWS Step Functions enables you to automate many tasks, including:
- Media files transcoding—you can use S3 to trigger Lambda to process data immediately after an upload. For instance, you can use Lambda to create image thumbnails, process logs, transcode videos, and index files.
- Sequence batch processing jobs—you can coordinate multiple AWS Batch jobs for analysis of raw data.
- Coordinate tasks in microservices—you can use Step Functions to decide how to process data. For example, a Step Functions workflow can determine whether to use AWS Fargate or AWS Lambda in order to optimize costs.
- Coordinate machine learning tasks—you can create an Amazon SageMaker job to train your model, automate data pre-processing with AWS Glue, and trigger SageMaker job to deploy your model into production.
Pricing
AWS offers a free tier with some basic functionalities. Beyond the free tier, you are charged for the services you use, for as long as you use them.
Step Function pricing
The AWS free tier offers 4,000 Step Functions state transitions per month. In other tiers, Step Functions are billed at $0.025 per 1,000 state transitions. The charges of Step Functions come in addition to any AWS services you use.
AWS Lambda pricing
The free tier includes one million requests per month, and 400,000 GB-seconds of compute time per month. The Lambda free tier is available permanently to both new and existing AWS customers, they don’t expire automatically.
The requests tier includes one million free requests per month. After you run out of free requests, this tier costs $0.20 per one million requests.
The duration tier comes with 3.2 million seconds of free computing time. After you run out of free computing time, tier costs $0.00001667 per every GB-second used.
Lambda@Edge pricing
There is no free tier for Lambda@Edge. You are billed for the total number of requests across all your functions. Request pricing is $0.60 per one million requests. Duration is calculated from the time you execute your code until it stops running or otherwise terminated.
You are billed $0.00005001 for every GB-second.
For example, if you allocate 256MB available memory per execution, then your duration charge will be $0.0128256 for every 256MB-second used.
TLDR: AWS Lambda vs Lambda@Edge vs Step Functions
All three services can help you reduce your IT workloads when used carefully. These services can help you automate tasks, optimize budgets, and significantly lighten the burden of managing hardware. However, AWS Lambda, AWS Step Function, and AWS Lambda@Edge have different use cases, pricing, and runtimes you need to consider.
Before deploying a serverless application in AWS, evaluate all your options and decide what service best suits your needs. The following guide can help you determine where to start.
| AWS Lambda | Lambda @Edge | Step Functions | |
| Use cases | File processing, website hosting, mobile applications, data analytics | Security and privacy, dynamic web application, A/B testing, authentication and authorization, user prioritization | Media files transcoding, batch processing, publishing events from serverless workflows, managing container tasks, managing machine learning tasks |
| Supported runtimes | Node.js: 12, 10 Python 2.7 3.6, 3.7 and 3.8
Ruby 2.7, 2.5 Go 1.x .NET Core: 3.1, 2.1 Java 11, 8 |
Node.js 10.x, 12.x
Python 3.7, 3.8 |
Node.js 10.x, 12.x, Python 2.7, 3.6, 3.7 and 3.8
Go 1.x .NET 3.1, 2.1 |
| Execution unit | Lambda functions | Lambda @Edge functions | State Machine, Tasks, Lambda functions and triggers |
| Pricing | Free tier—one million requests per month
Requests tier—$0.20 per one million requests Duration tier—$0.00001667 per every GB-second |
No free tier
$0.60 per one million requests |
Free tier—4,000 Step Functions state transitions per month
Beyond free tier— $0.025 per 1,000 state transitions |
Roy Hirsch is a software engineer with a passion for serverless technology. In his role as a Customer Success Manager at Lumigo, the serverless monitoring and debugging platform, Roy enjoys learning from customers about their serverless use cases, and providing solutions to their serverless challenges.
