AWS Lambda has gained good traction for building applications on AWS. But, is it really the best fit for all use cases?
Since its introduction in 2014, Lambda has seen enthusiastic adoption – by startups and enterprises alike. There is no doubt that it marks a significant evolution in cloud computing, leveraging the possibilities of the cloud to offer distinct advantages over a more traditional model such as EC2.
In this comparison between AWS EC2 and Lambda, we will cover various aspects of cloud native features. Let’s begin with a quick reminder of what these two services offer, and how they differ.
In this article:
AWS Lambda vs EC2: Which One Should You Choose?
Amazon Web Services’ Elastic Compute Cloud (EC2) service was introduced to ease the provision of computing resources for developers. Its primary job is to provide self-service, on-demand, and resilient infrastructure.
AWS Lambda was launched to eliminate infrastructure management of computing. It enables developers to concentrate on writing the function code without having to worry about provisioning infrastructure. We don’t need to do any forecasting of the resources (CPU, Memory, Storage, etc.). It can scale resources up and down automatically. It is the epitome of Serverless Architecture.
Before we start comparing the different features of both of these services, let’s understand a few key things about Lambda:
Here are a few use cases in which EC2 beats Lambda hands-off.
Stateful workloads
If you need to set up a database like Couchbase or MongoDB, you have to go with EC2. Another example would be a hosting environment for backup and disaster recovery – again, EC2 would be the only choice.
High-Performance Computing (HPC) applications
Although Lambda claims that it can perform real-time stream processing, if these processes need high compute, it cannot handle it. Remember, Lambda has only 3 GB of memory. And it may cause you high execution time, leading to either timeout issues or a higher bill. EC2 has no such restriction and is an ideal fit for these kinds of requirements.
Security sensitive applications
AWS claims that it takes care of Lambda security very well. But remember that Lambda functions are running in a shared VPC that may be shared with other customers in a multi-tenancy setup. So, if an application has highly sensitive data, and security is your primary concern, Lambda functions should be running under a dedicated VPC or use EC2 only. And don’t forget, running the Lambda under VPC has its own challenges like increased cold start time, limited concurrent executions, etc.
DevOps and local testing
DevOps has been developed for EC2 for years and has reached a good level of maturity, but Lambda is still going through that journey. AWS SAM and Serverless Framework are addressing those concerns. Local testing is another aspect you need to consider while using Lambda as it has few important limitations.
Here are the key use cases Lambda was built for.
Event-driven applications
Lambda has been primarily designed for handling event-based functions and it does that best. So if a new record is added to DynamoDB or a new file added to an S3 bucket needs processing, Lambda is the best fit. It’s very easy to set up and saves cost as well.
Infrequently-accessed Applications or scheduled jobs
If an application is used rarely or should be invoked based on schedule, Lambda is the right fit for it. It will save money as there is no need to run the server all the time.
Now, let’s take a deeper look at the key differences between Lambda and EC2.
Amazon EC2: For setting up a simple application on EC2, first, we need to forecast how much capacity the application would need. Then, we have to configure it to spin up the Virtual Machine.
After that, one needs to set up a bastion server to securely SSH to the VM and install the required software, web server, and so on. You’ll need to manage the scaling as well by setting up an Auto Scaling group. And that’s not all. ALB also needs to be set up to do the load balancing in case multiple instances of applications are installed using multiple EC2 instances.
AWS Lambda: In the case of Lambda, you won’t need to worry about the provisioning of VMs, software, scaling, or load balancing. It is all handled by the Lambda service. We just need to compile the code and deploy it to Lambda service. Scaling is automated. We just need to configure how many max concurrent executions we want to allow for a function. Load balancing will be handled by Lambda itself.
And the winner is: Lambda is a clear winner with significantly easier setup and management.
Amazon EC2: For EC2, we essentially have to pay for the amount of time EC2 instances are up and running.
AWs Lambda: For Lambda, you are billed according to the amount of time functions are up and running. The reason is that Lambda is brought up and spun down automatically based on event sources and triggers. This is something we don’t get out of the box while using EC2.
And the winner is: While an EC2 container is always available, Lambda is available based on the request invocation. Lambda functions are the winner, since they do not require you to pay for the idle time between invocations, which can save a lot of money in the long run.
There are various aspects to cover when we take performance into consideration. Let’s discuss them one by one.
Amazon EC2: With EC2, we have full control in implementing the concurrency and scaling. We can use EC2 Auto Scaling groups to define the policies for scaling up and down. These policies involve defining conditions (avg. threshold limits) and actions (# of instances to be added or deleted). However, it requires a lot of effort to identify the threshold limits and accurately forecast the # of instances required. It can only be done by carefully monitoring the metrics (CloudWatch, NewRelic, etc.).
AWS Lambda: With Lambda, concurrency and scaling are handled as a built-in feature. We simply have to define the maximum number of concurrent executions we want a function to be restricted to. There are a few limitations though:
And the winner is: EC2 gives you more flexibility but requires manual configuration and forecasting. Lambda is designed to do all of that by itself but has a few limitations. So each one has a relative advantage.
Amazon EC2: It is inevitable that applications will have dependencies on external libraries. When we use EC2, there is no constraint to limit the number of dependencies for an application. However, the more dependencies an application has, the more time it will take to start. It will add a burden to the CPU as well.
AWS Lambda: With Lambda, there are constraints in terms of the maximum size of a package – 50 MB (zipped, for direct upload) and 250 MB (unzipped, including layers). Sometimes, these sizes are not sufficient, especially for ML programs where we need a lot of third-party libraries.
AWS recommends using /tmp directory to install and download the dependencies during function runtime. However, it can take significant time to download all the dependencies from scratch when a new container is being created. So, this option is good when your lambda container is up most of the time, otherwise, it may cause a long cold start time for each invocation. Also, /tmp folder can hold a maximum of 512MB only. So, it is again restricted for limited use only.
And the winner is: EC2 is a clear winner with its unlimited support for dependencies.
Comparing latency between EC2 and Lambda depends on your use case. Let’s look at two examples.
Related content: Read our detailed guide to lambda performance
Amazon EC2: With EC2, the application will run for the whole day, latency for the first request will be high but for all subsequent requests will be comparatively low. The reason is, when the EC2 instance is provisioned, all the scripts are run to set up the OS, software, EBS and other things.
AWS Lambda: if we use Lambda, the application doesn’t need to be running for a whole day. Lambda containers can be spun up based on each request. However, it will involve cold start time, which is not significant compared to the EC2 instance setup time.
Who wins out? For this use case, Lambda will have better latency per request than EC2 but significantly less than the EC2’s first request. To reduce this time, you can assign Provisioned Concurrency, which means keeping a certain number of function containers ready for invocations. However, you are charged for Provisioned Concurrency, so you need to keep a balance.
Amazon EC2: In this case, EC2 will need to scale up to handle the increased volume of requests. This will impact the latency of the requests.
AWS Lambda: Scaling will be comparatively fast, with lower latency.
Who wins out: For this use case, Lambda wins out overall for latency.
So, latency will ultimately depend on the use cases and other local factors (cold start time for Lambda and resources setup time for EC2).
Amazon EC2: EC2 doesn’t have any restriction on running time – you can run an EC2 instance indefinitely. However, there are two reasons in which an EC2 instance would time out:
AWS Lambda: Lambda has significant timeout constraints (read our guide to AWS Lambda timeout). If you have long-running workloads, Lambda may not be the right choice as it has a hard timeout limit of 15 minutes. Also, if you have a Lambda function exposed as REST API through API Gateway, it has a timeout limit of 29 seconds at the gateway.
AWS has introduced Step Functions to overcome the Lambda timeout constraint (learn more in our guide to AWS Step Functions).
And the winner is: Amazon EC2 has less restrictive timeout functionality.
Video – Take a deeper dive into serverless troubleshooting with Yan Cui
To understand how EC2 and Lambda services compare on cost, let’s run through a couple of examples.
Related content: Read our guide to AWS Lambda cost
To get the same hardware resources, you can use a t2.nano EC2 instance. If we look at the cost for this instance, it will be $4.25.
Who wins out? The cost of AWS Lambda in this case ($0.16) is just ~4% of the EC2 price ($4.25).
If we use EC2, t3.micro instances should be able to handle this load, and it will cost only $7.62.
Who wins out? In this case, EC2 is a cheaper solution than Lambda due to the high number of requests, execution time and memory requirements.
Who wins out: In this case Lambda can handle the load balancing internally so no extra cost is added, and there is no infrastructure overhead, so Lambda will be cheaper.
Amazon EC2: For EC2, you have full control over system-level security. However, because you need to configure the security groups, Network ACLs, and VPC subnet route tables to control traffic in and out of the instance, it can take time to ensure the system is fully secure. Security groups can grow in number and become overlapping and confusing over time.
AWS Lambda: With Lambda, most of the onus is on the AWS side which includes OS patching, upgrades, and other infrastructure-level security concerns. In addition, many cyber threats, the sit idle on a server for a long time until attackers take action. This is not possible in Lambda as it is stateless in nature.
And the winner is: Lambda is more secure out of the box, while EC2 provides more control over security (at the expense of more administrative overhead).
Amazon EC2: When running EC2 instances, you need to closely track several metrics:
To summarize, most metrics can be tracked using CloudWatch and CloudTrail, but there are a few gaps to be filled. AWS Lambda: Cloudwatch provides all the basic telemetry about the health of the Lambda function out of the box:
In addition to these built-in metrics, you can also record custom metrics and publish them to CloudWatch Metrics.
However, there are a few limitations to these metrics:
And the winner is: Amazon EC2 clearly provides a richer ecosystem for monitoring relevant operational metrics.
Lambda monitoring with Lumigo: Lumigo is a free tool that can help you identify and resolve critical issues in your AWS Lambda environment. It lets you:
Learn more about Lumigo and get a free acount
It’s clear that if a team doesn’t want to deal with infrastructure, then Lambda is probably the right choice. However, it comes with limitations in terms of the use cases it’s best suited to. Also, constant monitoring is a must to ensure there is a good balance between the ease it provides and the cost.
EC2 has established itself as the standard choice for hosting any application and gives us full flexibility to configure our infrastructure. However, it is not best suited to all needs, and that’s what Lambda comes into the picture.
Keep using both services based on the considerations I have shared and do let me know your feedback.