Serverless Consulting

Serverless Showdown: Fargate vs. Lambda

Is There an Obvious Winner?

Serverless Showdown: Fargate vs. Lambda

Nikola Pantic
May 3, 2021

In 2021, we can easily say that serverless computing isn’t a new thing anymore to most people. Even though it’s been around for many years, some engineering organizations have consistently shied away from its cost and overall complexity. This complexity usually comes with managing virtual machines and physical servers hosted on clouds like Amazon Web Services (AWS).

When it comes to serverless options on AWS, and if you’re interested in jumping aboard the new age that’s before us, you should stay tuned while we compare ECS Fargate and AWS Lambda so you can understand better which one is the best fit for your business needs.

Making Careful Decisions

Don’t be fooled that choosing a vendor so you could move into the cloud is where everything will be over, as that’s only half the battle. The other half includes making more decisions like which service is the one that’ll fit all the requirements that your application has. The available choices range from IaaS (Infrastructure asa Service) to FaaS (Function as a Service), including numerous different paradigms found in between that also offer various abstraction levels.

To make a successful choice among these services, you have to consider two primary measures that’ll dictate how viable your app will be on the selected cloud. What this means is that you’ll have to deal with operational burden and cost when operating on the cloud. One of these two is often sacrificed for the benefit of the other.Therefore, choosing the appropriate service means you’ll have to balance these two measures to achieve the optimal experience.

At the moment, AWS is offering IaaS computing services thanks to its famous container service, EC2.Moreover, you can opt out for serverless Lambda functions (FaaS) or even a recently released product known as Fargate, a Container as a Service (CaaS)computing service. Fargate and Lambda are two entirely different serverless solutions, and that’s why it can be pretty challenging to understand their differences when you’re looking at AWS’s documentation pages.

Let’s go through the basics of both Fargate and Lambda so we can make an adequate comparison.

Fargate 101

AWS Fargate is an excellent solution from Amazon that runs docker containers, but it doesn’t require you to worry about server management for container orchestration.Please don’t let it confuse you, as Fargate is a single solution that allows you to run containers within Amazon’s ECS, but there are other solutions as well. Amazon ECS will enable users to run containers with both Fargate and other EC2 instances, which ultimately makes it quite complicated to find apiece of good information on Fargate so you could successfully compare it to a serverless-only solution. 

Additionally, Fargate relies exclusively on docker containers so it could successfully run your app.If you’re familiar with Kubernetes, you’ll quickly understand how Fargate works since containers run as ECS Tasks. At the same time, tasks are managed byServices, which is quite similar to how Kubernetes Deployment works. More over, if you want to receive external traffic via HTTP, you can set these services up with an Elastic Load Balancer (ELB). If you do so when using Fargate, your tasks will become persistent, which means your containers will run even in case they don’t receive any requests. Now, considering your containers are continuously running, Fargate won’t cause any additional warmup time.

It’s possible to configure ECS Tasks to run due to various CloudWatch events or on schedule.This is well-suited for Fargate, and it’s pretty useful as it allows you to utilize ECS Tasks for different jobs that don’t need persistent docker containers.

Accelerate your team across a breadth of disciplines and prevent obstacles  through comprehensive support:

What is AWS Lambda?

AWS Lambda allows developers to run their codes via AWS without having to manage or provision servers. Commonly, developers can easily upload their code and specify the needed amount of memory for a function to work when invoked. Therefore, Lambda functions are also known as transient. This means that the code will run only when it’s invoked, but it won’t consume any resources when it's not needed.Considering that the code isn’t running constantly, there’s a particular warmup time that rarely executed functions require.

These are some ofLambda function triggers:

  • DynamoDB Events
  • API Gateway
  • ELB Target Groups
  • S3 Events

As Lambda runs code that’s been uploaded, developers are pretty limited to specific runtimes and versions supported by Lambda (as of mid-2020):

  • Java (ver. 8, 11)
  • Node.js (ver. 10, 12)
  • .NET Core (ver. 2.1, 3.1)
  • Go (ver. 1x)
  • Ruby (ver. 2.5, 2.7)
  • Python (ver. 2.7, 3.6, 3.7, 3.8)

You probably realized already that Lambda runtimes don’t include Dockers because running docker containers isn’t supported by Lambda. Therefore, only functions that are written in languages and their specified versions (listed above) support docker containers. However, you can do something, which is to implement a custom runtime so it could run languages that aren’t supported directly.

Fargate vs. Lambda - Development

There’s an area that’s most often overlooked in comparison articles. This area is all about how these technologies operate within the development. It’s not enough just to develop your app efficiently, as it’s just as essential to make your app run efficiently. That’s why you must consider how different solutions work within a developer environment.


AWS Fargate — A Beginner's Guide To AWS Elastic Container Service | by  Vishal Padghan | Edureka | Medium

What Fargate does is it just runs docker containers, and you can develop locally by utilizingDocker. You can also run your docker images via Fargate, and you won’t have to worry about compatibility. Docker Compose is an excellent tool for running docker containers locally. Moreover, Docker Compose has the same features that are available for ECS tasks. These features are used for easier management of multiple docker containers, resource requirements, network configuration, etc.Developing within Docker is quite popular. Besides, you can rely on community support as it’s widely available for almost any possible scenario you may encounter. If you consider these facts, you’ll understand that Fargate outperforms Lambda by far because the development and architecture processes are usually entirely independent.


Early on, because of dependency issues between production and development, the lack of a straightforward way to run Lambda functions in the dev cloud, along with runtime restrictions, made it incredibly difficult to develop within Lambda.You had to run dev Lambda functions using an AWS account to know how it would perform. This method was complex with teams of developers, and it required your organization to come up with tooling that could help you manage this process.However, this has changed for the better. In recent years, AWS and its community have developed numerous tools to help you create, manage, and deployLambda functions:

  • Step-Through Debugging Lambda Functions (locally)
  • LocalStack - A functional local AWS cloud stack (fully functonal)
  • AWS Serverless developer tools

Even with full access to these fantastic tools, developing for Lambda can be pretty challenging for large companies. It requires lots of effort from your teams to figure out which tools are used and what the process will look like for Lambda functions’ QA, deployment, or development.

Fargate vs.Lambda – Operational Comparison

Probably the most attractive promise that cloud computing has to offer is the considerable reduction in physical server management. With the constant rise of IaaS offerings, people can now delegate hardware management responsibilities away and let the cloud vendors do this for them. However, developers had to learn more about provisioning. Devs have to provision all virtual servers through cloud vendor platforms, which becomes yet another operational burden. Moreover,Infrastructure-as-a-Service (IaaS) evolved over the years to CaaS (Containers-as-a-Service), PaaS (Platform-as-a-Service), and finally to FaaS (Functions-as-a-Service). These different paradigms offer entirely different abstraction levels, with FaaS being one of the easiest paradigms to utilize within serverless computing since it has more abstraction levels than others.

As we’ve already mentioned, the AWS cloud environment offers three specific computing services:

  • EC2 is the option with the most operational burden.
  • AWS Fargate is in the middle.
  • AWS Lambda is the lowest one on the spectrum.

However, there’s a catch you should know about. As more abstraction leads to lesser operational burdens, you have to sacrifice flexibility and endure various operational limitations. A good example is that with EC2 Instances, as you’ll have to specify a set of rules, networking security, monitoring, and many others.Besides container orchestration, one of the significant issues is auto-scaling, which requires you to define scaling rules at a container level. All this extra burden in operation allows you to configure your environment almost in any way you need it configured. Therefore, it’s possible to choose whatever runtime you want without worrying about timeout limits. Moreover, you can specify rules for granular auto-scaling so it would fit your business requirements in the best way possible.

When it comes to AWS Lambda, you can either abstract it away or complement it with various monitoring tools. Another essential thing worth mentioning is auto-scaling, as this service works incredibly well. However, you’ll notice slight drawbacks when it comes to monitoring since AWS Lambda can’t provide many monitoring features to its users. Monitoring your functions requires utilization of third-party vendors’ tools provided by,, etc. All these tools and ease of operation surrounding AWS Lambda allow you to focus your energy on business logic instead of monitoring and observing your code.However, there are other things you have to deal with, like operational limits.

Looking to become a skilled cloud developer with a focus on serverless development on AWS? Look no further: Zero-to-Paid Professional Course

AWS Lambda’s operational flexibility is quite restricted if you compare it to EC2. It limits temporary disk space to 512MB, which restricts the flexibility of operation compared to EC2 on the other side of the spectrum. Some of these limitations include a 50MB deployment package and 512MB temporary disk space. Even though you don’t need to worry about defining scaling rules and provisioning your containers, these limitations are something you have to consider.

On the other hand, AWS Fargate sits right between AWS Lambda and EC2, and it provides respite from allLambda limitations we've mentioned earlier. You might be wondering if Fargate is the best solution, and here’s what you should know before deciding. Fargate might look like possibly the best solution, but it mostly depends on how much ease of operation you’re trying to achieve. A good example is that withFargate, you won’t have to worry about patches that are similar to EC2, and you’ll have to update your underlying containers. Additionally, Fargate allows you to skip EC2 orchestration. Regardless, you’ll still have to use ECS to register your containers since ECS manages Fargate, and this brings additional operational complexity.

From all this, you’ll realize that your operational cost options are divided into several choices, including total operational ease via AWS Lambda, complete flexibility provided by EC2, and last but not least, compromising with Fargate. Besides, the options your business may require, in most cases, don’t come for free. This means you’ll have to pay for the service regardless of which options you choose to utilize.

Monitoring –Fargate vs. Lambda

As much as it may sound very straightforward, monitoring serverless apps can be pretty challenging. Traditional tools for server monitoring don’t translate very well to Fargate and Lambda. If you think about how fast they’re changing thanks to developers, it can be tough to remain at the very top of the ever-growing serverless infrastructure.


Fargate has a very straightforward task to export metrics to CloudWatch, and it does it automatically. You can send logs to CloudWatch and other providers if you properly configure everything. Like Lambda, most logging and monitoring tools support ECS, which means that they also support Fargate.

Your ECS Tasks have improved metrics and logging, along with more visibility thanks to ContainerInsights. Even though this new feature is in its beta phase, it looks pretty promising as Amazon is willing to put more effort into increasing ECS’s visibility.


Crucial Lambda metrics are automatically exported directly to CloudWatch. Besides standard features provided by CloudWatch, many others logging and monitoring tools support Lambda and offer other useful features. Some of them are SumoLogic, Blue Matador, SignalFx, etc.

When it comes to monitoring Lambda, there’s a huge challenge you have to know about. With Lambda, there’s no underlying server on which you can run your monitoring agents. Therefore, you’ll have to emit app metrics from inside your function to meet the monitoring needs you require, and this can incur additional costs(data transfer and execution time).

Use Case Scenarios

Fargate Approach to Base Security and Architecture

Fargate has proven to be the best choice for serverless container deployment as it helps remove the usually necessary maintenance for the execution of critical tasks that come from your container services. Moreover, it delegates the entire security management to Amazon Web Services and their toolset for securing services and infrastructure. Fargate is capable of operating from anywhere within your cloud. The only thing it requires is constant internet access because a publicIP allows it to pull out ECR service images. Considering that these scripts don’t need exposed ports like any other running service, ideally, you’ll require a security policy that doesn’t have an enabled inbound port.

If the task requires connection to a service running on your cloud (API and MYSQL Database), you’re required to add the correct VPC peering and proper routes to all your tables if you’re using a setup with multiple VPC. Let us show you how this looks like in the diagram below:       

Think About Docker Image

Think about setting up a new image repository directly on the ECR service. Although the entire process is pretty simple, there’s more to it. Another essential thing to do is creating a Fargate cluster by selecting “Networking Only” and adding a name to it, and you’re done, meaning your Fargate cluster is now up and ready. From there, you should choose the VPC at the exact container launch time.

Once your repository is set and ready to receive the docker image, you should start working on the image itself. The image comprises these three elements: the entrypoint, the Dockerfile, and the scripts representing the task you need to run to the cloud. A very useful Dockerfile for this case scenario can look something like this:

Then you should create an entrypoint which is a script that executes on container startup, and you can pass variables to it. You can select which script you want to run with the entrypoint and what parameters you should use for the container’s execution. This simple entrypoint works as a wrapper, and it’s capable of calling any python or bash script that you’ve put in src/usr/scripts/app/ with the desired parameters. If you wish to invoke it, you’ll need to execute these commands:

In the end, you have to create scripts that can fully describe the task that’s about to be executed.

Does everything you’ve learned about Fargate sound good so far? If so, that’s great!

Now, let’s see how much it’ll cost you!

Fargate Cost Breakdown

As much as it may look overly complicated, Fargate pricing is a relatively easy thing to figure out as long as you know how it calculates the cost. By learning how this calculation works, you’ll quickly see if Fargate is a good fit for your needs from the fiscal stance.

Estimating Fargate Costs

If you want to have a cost estimate on utilizing Fargate, all you have to do is determine how many GBs of RAM your active services use. Moreover, you can break down the cost calculation by learning how many vCPUs your operating services require, as this will allow you to foresee the potential costs and determine your next step.

Fargate pricing comprises spot instances and on-demand instances as shown in the table below:

EC2 allows you to create instances as container hosts or even standalone machines. Besides, AWS works in the background of EC2, providing Fargate and Lambda services, and here’s its cost breakdown:

By learning all these little things, you’ll know if Fargate cost is what you expected it to be or if it’s far out of your reach and needs. However, we’ll mention some ideas and tips on reducing the overall costs, which is, ultimately, everyone's goal.

Comparing EC2, Lambda, and Fargate Billing Options

It’s vital to learn all your options before you decide to push your workloads to AWS. There are plenty of available services, but the standard ones include EC2, Lambda, and Fargate, as all of them can host services and run your workloads. However, different services provide different support methods, and you should know what to expect from each one.

Have a look at the graph below, and you’ll see how different Lambda, EC2, and Fargate are cost-wise:

Fargate Cost Reduction Ideas

There are several practical cost-reducing methods. Everyone’s primary goal is to get the highest return on investment possible, and some of these methods may help you achieve that goal. You could reduce the costs by creating easier workload management, eliminating all wasted resources, and getting the best out of available pricing plans.

In the graph below, you’ll see some of the most common cost reduction methods:

Is There a Clear Winner?

If you were at any moment hoping for an answer about which service is the better one, you’d probably be disappointed to know that there isn’t a clear winner. Both service shave their pros and cons, and with that said, to know which service is the better one, you have to understand your requirements. Keep in mind that bothAWS Lambda and Fargate can significantly reduce the complex orchestration ofEC2 containers, but they’ll potentially become more costly. Even though Lambda functions are possibly a more viable option, even Lambda has its limitations.Therefore, choosing the proper service mainly depends on your specific needs and use case.

On the other hand, if you’re not expecting plenty of invocations but only sporadic calls to your apps, choosing AWS Lambda will help you distance yourself from the complexities of the ECS platform and the EC2 Fargate services that it brings. However, if your app is lightweight but resource-intensive when it comes to its usage, you should definitely opt for Fargate. Even if none of these two options is good enough for you, choosing EC2 is always a safe bet. Regardless of your service choices, make sure to distance yourself from on-premise servers. Always inspect all your options before deciding which one is the one to go with further.

Wrapping Up

These were some basics of what Fargate and Lambda are, how you can monitor them with ease, how their billing systems work, and how each one of them operates within a development environment.

Although Lambda may seem like the true serverless title-holder of AWS and is very close to running code directly without thinking of infrastructure, it’s still not the best as there are some downsides like its billing model. Lambda’s billing model makes it incredibly hard to predict the costs, and its utterly different deployment model can be quite a challenge for anyone familiar with traditional deployment models.

However, the upsides of Lambda include good use cases of Lambda with inconsistent or unpredictable applications and workloads that you can easily express as a solitary function that has predictable resource usage for each invocation.

Alternatively, Fargate is more aligned with Docker than Lambda is, and it’s likely an excellent choice for teams that heavily rely on Docker if they don’t want to utilize Kubernetes.Fargate allows you to avoid vendor lock-in because you can run your Docker containers in several other services as well as in other clouds. Fargate is an excellent choice for anyone that requires consistent applications or workloads and for all who generally want to use Docker.

What are your thoughts on this comparison? Do you possess valuable experience using these services you’d like to share with our readers and us? Feel completely free to share all your thoughts and knowledge with us as we strive to progress every step of the way.