Compare AWS Lambda vs. AWS Fargate for serverless
AWS Lambda and Fargate are two serverless services tailored for application deployment. Choose the right tool to meet your performance needs while keeping costs down.
Serverless computing can provide advantages when deploying business applications and workloads. Two serverless AWS tools might give cloud admins what they need to succeed:
- AWS Lambda. This serverless compute service enables AWS users to upload software, or functions. Users define triggers that execute specific code. Behind the scenes, Lambda code runs on EC2 servers, but users never have to manage those servers.
- AWS Fargate. This simplifies the process of deploying containerized applications in AWS. Developers can package apps as containers, upload them and set up configuration variables. Fargate automatically deploys the containers without requiring users to manually set up host infrastructure or install a container orchestrator.
Both achieve the same end goal: enabling application deployment using a serverless compute strategy. However, they work in different ways and cater to disparate use cases. Learn more about the differences between these services to find the best serverless tool for your applications.
Architecture and app packaging
AWS Lambda and AWS Fargate are both serverless services, but they differ in how they are architected and how they scale.
Lambda
Lambda architecture supports any type of application or deployment strategy. Lambda uses event-driven architecture, which means that specific events, conditions or triggers cause another event to happen, like the execution of a Lambda function. While creating a Lambda function from a container is possible, it isn't designed especially for containers. Lambda works best with short-lived workloads and managing responses to events, like file processing and HTTP requests.
Fargate
Fargate is a serverless compute engine that can run containers with Amazon Elastic Container Service (ECS) and Elastic Kubernetes Service (EKS). It specifically deploys applications packaged as containers. Once deployed, workloads operate continuously. Admins benefit from considering Fargate for their long-running, complex workloads that require reliable performance and can scale on demand.
Response and execution time
On the back end, Lambda and Fargate take different approaches to deploying applications. Each comes with important consequences for application response times and scaling capabilities.
Lambda
An untriggered function must undergo a cold start before it becomes fully operational. This can lead to delayed response times for applications that infrequently receive requests. However, apps that receive frequent requests will likely see better performance. Lambda imposes a hard limit of 15 minutes on execution time and terminates any function that exceeds the time limit.
Fargate
There is an initial deployment delay, but applications can run constantly after that. Fargate applications remain fully responsive and are not subject to cold startup delays. Because Fargate applications run continuously, there are no limits on how long a task can take to execute.
Pricing
Comparing AWS Lambda and AWS Fargate pricing can be tricky because it is based on various factors such as how they are billed, the usage model and the required resources.
Lambda
Lambda delivers the most value for applications that run frequently and with short durations. It charges based on the number of invocations and total execution time. Customers don't pay for periods when functions sit idle.
The free tier offers the following:
- First 1 million requests per month free.
- Free 400,000 GB-seconds of compute time per month.
- Free 100 gibibytes of HTTP response streaming per month beyond the first 6 MB per request.
After the free tier, it's priced at $0.20 per 1 million requests and varies for execution time depending on the architecture -- x86 or Arm -- and the allocated amount of memory. Other pricing considerations include the following:
- Provisioned Concurrency. Users keeping functions initialized to respond in double-digit milliseconds -- these prices differ from normal execution and duration prices.
- Ephemeral storage costs. Temporary storage that is free until hitting 512 MB.
- SnapStart pricing. For increasing startup performance that uses snapshots.
- Data transfer fees. For data that crosses the Region boundary.
Fargate
Fargate workloads typically run constantly, and users incur charges for them as long as the workloads run. This means that Fargate is most cost-effective for hosting continuously active workloads. Pricing is based per second with a one-minute minimum, and the duration is rounded up to the nearest second.
For Windows containers, billing is calculated per second with a five-minute minimum.
Fargate pricing is based on the following:
- Virtual CPU.
- Memory.
- Operating system.
- CPU architecture.
- Storage resources for the Amazon ECS task or Amazon EKS Pod.
Other considerations include Fargate Spot pricing for Amazon ECS tasks on spare capacity at a discount. Tasks and Pods beyond 20 GB incur additional ephemeral storage costs. Containers that use other AWS services or transfer data incur additional fees.
Both services can take advantage of Compute Savings Plans, which offer lower prices in exchange for a one- or three-year commitment to a consistent usage amount. Use AWS Pricing Calculator to get a cost estimate.
Target use cases
While each service's use cases overlap somewhat, the two mostly address distinct workload deployment scenarios.
Lambda use cases
- Applications that exist in the form of raw code or binaries.
- Apps with relatively short execution times.
- Certain events or conditions that need to trigger the application to run and respond.
- Request volumes for the apps vary but rarely reach zero for an extended period.
Fargate use cases
- Workloads that are packaged as containers.
- Applications that need to run continuously.
- Any fluctuation in workload demand is limited.
Chris Tozzi is a freelance writer, research adviser, and professor of IT and society. He has previously worked as a journalist and Linux systems administrator.
