Lambda and Fargate are fundamentally different as serverless solutions and it can be difficult to understand this difference when looking solely at the AWS marketing or documentation pages. First we will go over the basics of each service so we can then compare them.
Fargate relies on docker containers to run your application. Containers run as ECS Tasks (similar to a Pod if you are familiar with Kubernetes), tasks are managed by Services (similar to a Kubernetes Deployment), and services can be set up with an Elastic Load Balancer to receive external traffic over HTTP. When used this way, tasks are persistent -- your containers will continue to run even if no requests are received, even when running on Fargate. Since your containers are always running, there is no warmup time caused by Fargate.
ECS Tasks can also be configured to run on a schedule or as the result of CloudWatch events. This allows you to use ECS Tasks for jobs that do not require a persistent docker container, and is well-suited for Fargate.
Here are some of the sources that can trigger a Lambda Function:
Since Lambda directly runs code that has been uploaded, developers are limited to the runtimes and versions currently supported by Lambda (as of June 2020):
You may notice that Docker is not included in the Lambda runtimes. That's because Lambda does not support running docker containers—only functions written in the languages and versions listed above. You can, however, implement a custom runtime to run languages that are not directly supported.
Since Fargate essentially just runs docker containers, you can develop locally using docker and run your docker images in Fargate without worrying about compatibility. Docker compose is a great dev tool for running docker containers locally and has the same features available for ECS tasks for configuring network, resource requirements, and easily managing many docker containers. Developing in docker is already very popular and community support is widely available for almost any imaginable scenario. In this sense Fargate outperforms Lambda since the architecture and development process can be completely independent of Fargate.
In Lambda’s early days, it was very difficult to develop because the runtime restrictions and lack of a clear way to run Lambda functions in dev could easily cause dependency issues between development and production. You had to run dev Lambda functions in an actual AWS account to know for sure how it would perform, which was difficult with teams of developers and required your organization to develop tooling to manage this process. In recent years, many tools have been developed by both AWS and the community to make it much easier to create, deploy, and manage Lambda functions:
Even with these tools, developing for Lambda can be challenging for large organizations and will require some effort on the part of your team to standardize which tools are used, and what the process looks like for development, QA, and deployment of Lambda functions.
If you have a little bit of historical data, you can use our cost predictor tool to project your AWS costs based on past usage.
Fargate is billed on CPU and memory used per hour. The current pricing is found here. ECS does not allow you to configure Fargate to use arbitrary amounts of CPU and memory, and the amount of memory available depends on the amount of configured CPU. SImilar to Lambda, any unused CPU or memory is essentially wasted money so you will want to try and size your application appropriately.
Since Fargate pricing is not based on number of requests or request length, it can be easier to determine the lower and upper bounds for usage and then get a good idea for the pricing range you will be in. You can simply count the number of containers you are using, match them to available Fargate CPU and memory configurations, and calculate the daily cost. You can use the CpuUtilized and MemoryUtilized metrics available with Container Insights to help you size your ECS Tasks in Fargate in production.
For very predictable workloads at higher scales, it may make sense to even use EC2 instances to run some ECS Tasks instead of relying solely on Fargate. You lose the “serverless” aspect of running ECS Tasks but EC2 can be significantly cheaper with spot or reserved instances. Pricing information for EC2 can be found here.
Lambda is billed on a combination of the number of requests, memory, and seconds of function execution. The current pricing is found here. When trying to manage Lambda costs it is important to size your function’s memory requirements properly since it directly affects cost. If you configure your function to use 512Mb of memory but it only consumes 128Mb during execution, you’ve essentially increased the cost of each invocation by 4x. Lambda offers many tiers for memory usage so it should not be too difficult to find a size that closely fits your actual usage.
If you are new to Lambda you should set up CloudWatch Billing Alarms so you can avoid surprises in your bill due to Lambda. You can view your Lambda Function logs to see the memory used and execution time of your lambda invocations to help you properly size your Lambda functions. If your Lambda function is triggered from an event stream such as Kinesis, you can configure your batch size to reduce the number of invocations as well.
Fargate exports metrics to CloudWatch automatically. You can check out this blog post which explains how to set up CloudWatch alarms for CPU and Memory utilization for ECS. Similarly to Lambda, most monitoring and logging tools support ECS and therefore Fargate. You can also send logs to CloudWatch and other providers with proper configuration.
Container Insights provides even more visibility into your ECS Tasks with improved logging and metrics. While this feature is only in beta, it looks promising that Amazon is willing to put more effort to increase visibility with ECS.
Important Lambda metrics are exported to CloudWatch automatically. You can check out our How to Monitor AWS Lambda with CloudWatch blog post for details on which metrics are useful and how to create CloudWatch alarms for them, or, if you prefer an automated approach that requires no setup, read How to Monitor AWS Lambda with Blue Matador. In addition to what is available in CloudWatch, there are plenty of monitoring and logging tools that support Lambda such as Blue Matador, SignalFX, SumoLogic, and many more.
One challenge with monitoring Lambda is that there is no underlying server to run monitoring agents on. You may find it necessary to emit application metrics from within your function to meet your monitoring needs, which can incur costs for both execution time and data transfer.
We’ve gone over the basics of what Lambda and Fargate are, how each one works in a development environment, how they are billed differently, and how they can both be monitored easily.
Lambda seems to be the true serverless champion of AWS, and is as close as possible to just running code directly without thinking about any infrastructure. On the other hand, the billing model makes it very difficult to predict costs, and its radically different deployment model can be a challenge for organizations that are used to more traditional deployment models.
Good use cases for Lambda include unpredictable or inconsistent workloads and applications that can be easily expressed as a single function with predictable resource usage on each invocation.
Fargate is clearly more aligned with docker than Lambda, and is likely a good choice for teams that rely heavily on Docker already but do not want to use Kubernetes. With Fargate you also avoid vendor lock-in since you can easily run your docker containers in other services and also other clouds.
Fargate is a good choice for consistent workloads or applications that want to use docker generally.