AWS Fargate vs. Lambda: Comparing Two Serverless Solutions

Neo Financial, a Canadian Fintech startup, is carving out its space in the traditional banking system with simpler and agile digital products for customers. The organization has its entire infrastructure on AWS and innovates using scalable serverless services on AWS.

It uses ECS (Elastic Compute Service) with AWS Fargate to achieve the desired scalability for its machine learning applications and AWS Lambda to simplify other workloads, such as users’ credit card requests. Employing such solutions, Neo successfully developed and launched Neo Card in 9 months, when a traditional bank would take twice the amount of time to launch a credit card.

That said, choosing the right services that fit your serverless project’s requirements can be challenging. Moreover, as AWS continues to dominate the cloud space, its services have evolved substantially in terms of features, availability zones, the complexity of its offerings, and more.

When it comes to serverless computing, AWS has numerous solutions. This article attempts to compare two serverless compute options from AWS– Fargate and Lambda. It discusses performance, scalability, pricing, use cases, and more, along with examples and real-life case studies.

Let’s begin!

Suppose you want to use AWS to construct containerized applications. In that case, you’re likely to go for one of its fully managed container services, such as ECS (which manages and deploys Docker containers) or EKS (which manages and deploys Kubernetes containers).

However, if you explore ECS or EKS with the EC2 launch type, you must create many configurations and manage the underlying infrastructure. Also, familiarizing yourself with numerous infrastructure components and resources is necessary. That’s where AWS Fargate comes into play.

Fargate is a serverless compute engine that allows you to run containers without managing the infrastructure. It complements ECS/EKS and makes launching container-based applications much more effortless.

Therefore, you can focus on building your applications while AWS does the heavy lifting of provisioning, configuring, and scaling servers or clusters. All you need to do is define the infrastructure parameters, and Fargate will launch the containers for you.

Babble, the world’s best-selling language learning app with millions of customers and thousands of courses in multiple languages, chose AWS Fargate with ECS to run containers. It was the right choice for its architecture as it abstracts the maintenance required for underlying ECS machines. It also integrates with other AWS services and their Terraform database.

Lambda, an event-driven compute engine, is another serverless technology from AWS. It reduces the operational overhead of managing the infrastructure with a pay-per-use model and no upfront cost. In addition, it enables you to run code in response to events and automatically provisions for and manages the compute resources required.

Here’s a simple use case– you upload the code (creating a function) and specify the resources for a function that will run when invoked. Also, specify AWS resources to trigger functions. Lambda then allocates, manages, and administers all the resources necessary to execute the functions.

Moreover, Lambda can be highly functional in AWS designs as many AWS services have a built-in ability to trigger Lambda functions.

Both Fargate and Lambda are serverless technologies from AWS. Both services reduce the operational overhead of managing the infrastructure with a pay-per-use model and no upfront cost. However, the technologies differ in their functionalities.

While Fargate is a Container as a Service (CaaS) offering, AWS Lambda is a Function as a Service (FaaS offering). Therefore, Lambda functions do not necessarily need to be packaged into containers, making it easier to get started with Lambda. But if you have containerized applications, Fargate is the way to go.

To help you choose a service with a deeper understanding of the technologies, we have compared Fargate vs. Lambda based on various factors below.

An aspect often overlooked while comparing Fargate vs. Lambda, it is essential to consider how both the solutions operate within a developer environment.

Fargate: Developers can build locally using Docker and run the container images directly in the cloud with Fargate. It takes care of everything in-between. Developing with Docker is quite popular as its features can be used for easily managing multiple containers, network configurations, resource requirements, etc., and it has larger community support.

Moreover, you have access to more memory/CPU size options and the length of time your code needs to run with Fargate. It can outperform Lambda in this case since the development process is independent of Fargate.

Lambda: Recently, AWS and its community have developed numerous tools to develop, create, and manage Lambda functions seamlessly. Earlier, developing with Lambda was a complex process as it lacked a straightforward procedure to run Lambda functions in the cloud, along with runtime restrictions. However, even with the current toolset, it requires efforts to standardize what tools to use and what the processes will look like for QA, development, and deployment of Lambda functions.

Both Lambda and Fargate run on-demand. Thus, the applications or functions shut down or become idle after a predetermined amount of time. However, due to the idle time, the environment is not immediately accessible as it normally is while live and running.

Fargate: Typically, the startup time for Fargate containers is 60-90 seconds which is more than Lambda. However, Fargate has dedicated resources and no runtime limitations, so the environment remains in a warm state. But it may take more startup time if there is a sudden spike of requests, and it takes longer to scale up.

Lambda: On the other hand, the initial Lambda startup takes 5 seconds, following which the same functions have a negligible startup time. But a Lambda function stops running after 15 minutes until triggered by an event, causing cold starts. However, there are multiple ways and techniques to reduce and prevent Lambda cold starts that you can read in our blog post on how to avoid Lambda cold starts.

The graph below shows the proportion of startup time to the total of a task or function. Each line’s initial steepness shows a rapid decrease in the startup overhead. Following this, the lines flatten, showing a diminishing rate of efficiency.

Thus, the startup delay becomes less important as the total duration increases and factors such as cost become more significant. However, the key to fairly comparing AWS Fargate vs. Lambda for performance would be to consider specific use cases of your application.

When it comes to pricing, Fargate and Lambda use completely different billing models. Again, a fair pricing comparison will highly depend on your use cases.

Fargate: AWS Fargate pricing is calculated per second based on the allocated memory, vCPUs, OSs, CPU infrastructure, and storage resources used. You can configure these five dimensions independently. It calculates the time from when downloading of a container image starts until a task or pod terminates.

Lambda: AWS Lambda pricing is calculated per millisecond based on the number of requests, the memory and runtime used by functions, and the network traffic. But Lambda has limitations in terms of CPU and RAM available for use. A Lambda function can use 3GB of memory, and the CPU is allocated based on how much RAM is selected. Therefore, it is essential to size your CPU and memory requirements appropriately as it directly affects the costs in both cases.

To illustrate a pricing comparison between the two, let’s take the example of a workload that needs 2000 concurrent containers or instances with two vCPUs and 4GB memory. With Lambda, the nearest memory configuration we can get is 4096MB, providing 2.41 vCPUs.

	AWS Lambda	AWS Fargate
Unit Pricing	$0.0000166667 per GB-second	$0.04048 per vCPU-hour + $0.004445 per GB-hour
Calculation	$0.0000166667 x 4 GB x 60 seconds x 60 minutes x 2000 containers	($0.04048 * 2 vCPUs + $0.004445 * 4 GB) x 2000 tasks
Price per Hour for 2000 instances (4GB memory / *2 vCPUs)	$480.00	$197.48

We will not consider Lambda’s per 1 million requests pricing as the requests for batch processing will be relatively low, making minor cost impact. Also, given that our batch processing workload is meant to run many processing jobs over hours, the calculation is based on an hour of fully-utilized processing.

Both these serverless solutions offer different abstraction levels. While it leads to lesser operational burdens, you may have to compromise on flexibility and endure a few operational limitations.

The operational complexity and flexibility of these services largely depend on the elements that users have control over in the system and the elements managed by the platform provider, as shown in the graph below.

Fargate: It comes with additional complexity as you still have to register your containers with ECS. But it offers significantly more flexibility in that you have full access to the configuration of each container.

Samsung built a secure developer portal with AWS Fargate. However, before moving to Fargate, it had admins and operators managing the web services, which resulted in more operational overhead. But soon after migrating to Fargate, it experienced significant improvements in operational efficiency. The company saved big on operational costs while also improving developer efficiency.

Lambda: Similar to Fargate, it entirely abstracts the whole infrastructure layer, allowing you to focus on your critical application functionalities. But its operational flexibility is restricted as it limits temporary disk space to 512MB and includes a 50MB deployment package. Moreover, developers only have access to the memory dedicated to the functions, limiting their ability to modify the machine’s configuration.

For both Fargate and Lambda, AWS manages the underlying infrastructure, leaving the developers more time to focus on the application code. But the services differ in terms of scalability and maintenance.

Fargate: In the case of Fargate, you need to set up autoscaling. Also, you need to shut down Fargate tasks on a manual or scheduled basis as it cannot scale to 0, adding to maintenance. Moreover, in Fargate, the developers must keep the base container images updated. So it again adds to the maintenance but allows for more control. However, it immediately adds tasks and allocates compute power required automatically, adding capacity in a stair-step manner.

Qoala, an Indonesian insurtech startup, seamlessly scaled applications to handle sudden traffic increases with Fargate. Its applications handled an increase in data transactions from 10,000 to 100,000 in a day with minimal effort and no performance issues.

Lambda: Lambda functions are scalable by design, so they automatically launch instances to meet the increases in demand. Apart from rapid auto-scaling, it can also scale to 0. So, you don’t have to pay for idle applications, which is useful for low traffic workloads. This ability of Lambda to scale from 0-1000 rapidly is essential for spiky and unpredictable traffic. Moreover, you can spin architectures easily with Lambda as it requires only simple functions and application setup and maintenance.

For Utopus, a renewable energy analytics provider, AWS Lambda proved highly scalable and powerful. The company could process 200 billion signals in 2 hours every day as opposed to 2 weeks on-premises.

In both cases, security is a shared responsibility between the users and AWS. While AWS ensures the security of the infrastructure, you need to set up compute resources with permissions (using IAM) to allow functions or containers to perform actions on other AWS resources. The difference lies in how the IAM roles are created and maintained in both the services.

Fargate: With Fargate, permissions are associated with containers or pods the tasks are run in. All Fargate tasks run in their individual, isolated compute environments without sharing any underlying resources (kernel, CPU/memory, Elastic Network Interface) with other tasks.

For Vanguard, an American investment management company, Fargate improved its infrastructure’s security, maintenance, and stability. By design, any issues present would be self-contained to that single application.

Lambda: With Lambda, you can set up IAM roles that each function or service will assume. AWS Identity and Access Management (IAM) modules ensure that only the right users can access the function or the application. Moreover, functions have dedicated execution environments that are never shared with other functions.

For example, Northmill, a fast-growing Swedish neobank, has tighter security controls due to Lambda’s fully managed environment. It eliminates the chances for anyone to manipulate local data and time as their code runs in Lambda.

To sum up and answer the question about which of the two to choose, you can consider the following benefits and use cases of Fargate and Lambda before making your decision.

• Deploys and scales applications easily, from single-use utility applications to entirely containerized microservices architectures.
• Eliminates the operational overhead of choosing server types, patching, sizing, cluster scheduling, optimizing cluster packing, and more.
• Allows you to pay only for what you use as Fargate’s fully managed container environment automatically allocates the required compute power on-demand.
• Integrates with a range of sibling AWS services for networking, CI/CD, security, monitoring, etc.
• Allows developers to have workload isolation.
• Improves security with isolated compute environments.

Fargate is a good option for consistent and predictable workloads or applications that want to use Docker/Kubernetes generally.

It is suitable for the following use cases:

• Long-running compute jobs that are longer than 15 minutes
• Applications that require more compute than Lambda offers, i.e., more than 3GB of memory
• Applications with predictable scaling and where longer start times are acceptable
• Latency-sensitive and storage-intensive applications
• Applications that need inter-container communication
• Containerized machine learning applications

• Reduces costs because you only pay for the resources you use.
• Scales automatically to handle a few requests per day or even thousands of requests per second.
• Reduces operational overhead such as administration, maintenance, security patching, resizing, and adding servers for any type of application or backend services.
• Allows developers to spend more time on innovation with quicker iterations.
• Supports multiple programming languages.
• Allows packaging and deploying of functions as container images, expanding its use cases.
• Easily integrates with other innovative AWS services.

As Lambda has a generic and simple application model, it can be used for almost any type of application. However, it can be most suitable for applications with unknown demands and lighter-weight apps with stateless computing. Also, if you wish to hand over most of the operational complexities to AWS and enable ease of development, you can opt for AWS Lambda.

It is suitable for the following use cases:

• Web applications and websites that require dynamic scaling to handle excessive traffic loads at peak hours and save money when there is no traffic.
• For applications that can be easily expressed as single functions with predictable usage of resources on each invocation.
• Event-driven workloads and apps.
• Custom mobile and IoT backends.
• Asynchronous, small jobs to be managed in tandem.
• File processing and automated file synchronization.
• Real-time log analysis and data processing.
• IT automation.

Simform is an Advanced AWS Consulting Partner with an expert team of AWS-certified professionals who can assist you develop serverless solutions using the right AWS services. We’ve helped customers across every industry with their cloud infrastructure, building and deploying large-scale cloud applications, and migrating apps and workloads to AWS.

Get in touch with us now to learn more about how we can help you leverage the best technologies for your serverless project!