Apparently both serve the same purpose for any application to get services as microservice from AWS Api-gateway. But there are some attributes to consider prior choosing the option from these two. Here I tried to point out the attributes and the pros and cons of each option so that it helps the application developer to decide upon the path to go about for their application’s requirements. There is no silver bullet like thing in software development architecture that works perfectly for all. ‘One for All’ doesn’t fit good anywhere I guess.

The comparison for different aspect:

High availability

High availability is one of Lambda’s main selling points, has some hidden downsides. On a “cold start,” or a function start after not calling the function for a long time, Lambda functions spin up a virtual machine and execute within approximately 100 milliseconds of being called. Sounds great as for something that isn’t customer facing, sure. But when a user application needs a latency of less than fifty milliseconds per call from start to finish, 100 milliseconds for startup alone suddenly starts to drag. On the other hand, an EC2 server will stay up for as long as needed and accept connections for as long and as quickly as it is configured to do so.

Configuration ability

Configuration used to be an issue, as we had to deploy applications across multiple accounts with multiple permissions. We ended up using several unwieldy configuration files. There was no way to automatically configure a Lambda until instance variables were introduced. Thankfully, this weakness is no longer an issue as of November 2016, when expression-specific environment variables were introduced and supported by AWS’s command line interface. On the other hand EC2 is fully configurable manually or with Beanstalk.

Security

With concrete timeouts, rate-based blacklisting, and containers being spun up and down as needed, Lambda expressions are by design, more DDoS attack resistant than EC2 instances. EC2 instances require additional services, such as AWS Web Application Firewall, load balancers, and elastic IP services, to resist heavy loads.

Scaling

Lambda scales on demand and as already said user only pays what (s)he actually uses or needs instead of underutilized baseline.

Unpredictable performance

A pitfall of Lambda is the unpredictable performance. While containers will be reused they need some warm up with each new instance. The first requests will usually be slow especially when using Java. Node.js is supposed to be lighter during startup, but slower during execution. For example, when a new 128 MB low memory Java instance is created and user’s Lambda has some libraries in it the first call can take 30 seconds or longer. The instances are freezed between requests. If the instance isn’t used for a while it takes longer to wake up again. Increasing memory can reduce the warm up and wakeup time. However, the main problem can be the access to the external data-sources. As the instances are freezed, between requests proper connection pooling isn’t supported. If one does connection pooling anyways (s)he can end up getting stale connections. Depending on database and driver opening and closing a connection can be quite expensive.

Dependency on S3

Any developers who had to deal with the S3 outage at the end of February 2017 know that putting all your eggs in one AWS basket carries risks with it. AWS Lambda, which relies on S3 for code storage, was suddenly unreachable, taking out API functions, Amazon Echo skills, and other codebases that relied on Lambda for execution. Of course, several other applications were effected, including EC2 instances that used S3 for new launches, so both services have this hidden dependency. Eventually, the start-up time may become too much of a blocker for any application for hosting functions in Lambda, accepting connections on an as-needed basis. It’s far better to have an EC2 server that listened for connections constantly to overcome this situation.

Pricing

Another lucrative selling point of Lambda (Serverless Architecture) is its cost (cost as per use). Lambda’s pricing and EC2’s pricing both are designed differently enough that cost analysis becomes a bit tricky. A Lambda function with 0.5 GB of memory run for 1 hour (or, more likely, as several calls of the same function adding up to an hour of uptime) costs $0.030024, while an on-demand EC2 server with the same statistics (at 2 nano server with 0.5 GB of memory) costs $0.0059 per hour. At first glance, this is clearly in favor of the EC2 server. However, that server is designed to be up and listening for connections 24/7, possibly only performing a few computations, whereas a Lambda expression that’s running for an hour straight. So EC2 cost will be multiplied by 24 again (24 * $0.0059). Now if we consider other way of calculation like –

While AWS supports Auto-Scaling for Elastic Beanstalk and EC2. One always should probably run at least two instances for failover behavior. Running two “nano” instances as a minimum for failover each instance costs user (without reserved instances discounts): $0.0059 * 24 * 30.5 = $4.31 for the VM and $0.05 * 8 GB = $0.40. So, one instance is $4.71 and two instances are $9.42. However, for the Auto-Scaling to work user need a Load-Balancer setting which is at least $0.0225 * 24 * 30.5 = $16.47 on top of that (ignoring LCU charges). The Load-Balancer can be shared by multiple services. For this calculation, I just split it up artificially by 10 and come the conclusion that one microservice using Eleastic Beanstalk or EC2 will cost you $9.62 + $1.65 = $11.27.

Now we see, how does that compare to Lambda? With Lambda, user pays per call and per Gigabyte second. I’m ignoring the call costs as it’s $0.20 per 1 million requests. 1 million requests are 0.4 requests per second in a month. If one have higher loads (s)he would have to pay for the Load Balancer LCU costs as well. Lambda is priced as $0.00001667 per GB-second. Elastic Beanstalk and EC2 will both consume parts of the nanos 512 MB memory for the operating system and the container. I just assume that 256 MB are actually usable. Having two instances this would be 2 * 256 MB/1024MB * 60 * 60 * 24 * 30.5 = 1317600 GB-seconds. This amount of GB-seconds would cost you 1317600 * $0.00001667 = $21.96 dollars. While this sounds more expensive bear in mind your traffic probably doesn’t distribute evenly so user would probably need more instances hence increasing the costs. With Lambda user only pay what (s)he actually uses.

Function size

AWS recommend small sized functions for Lambda to get the real taste of it and EC2 for comparatively larger functions. From this, people can think like Lambda is a poor tool for development, but that isn’t true. When properly used with managed expectations, AWS Lambda can be a strong mix of power and cost-effectiveness.

Other limits

As mentioned above connection pooling isn’t directly supported which can be a problem for database access or access to other systems in general. If you are using frameworks for your speeding up development they might be unsuitable for usage within Lambda.

There was a limitation like if one need some way to limit the number of instances of a Lambda function that can be running concurrently to prevent maxing out available database connections or hitting usage limits on third party APIs, had no way to do that. This limitation is over now. Nowadays Lambdas can run within a VPC. Even though I’m not sure of an official way to limit the number of concurrent instances, if one uses a VPC (s)he can restrict the subnet of available IPs and each Lambda will require an IP so you can limit the number of Lambda instances indirectly.

Good use-cases

If one doesn’t care too much about consistent performance Lambda is cheap and scalable. A very good fit is processing of small batches.

Conclusion

We can find these similar or analogical with a Function as a service (FAAS) and Platform as a service (PAAS). It seems like Lambda/Serverless architecture may be thought of as a Function as a service (FAAS), while EC2-Beanstalk falls under Platform as a service (PAAS). I won’t go to this debate here now. I just passed my view.

I would enjoy developing for Lambda in the situations it’s designed for. I would definitely recommend it to anyone looking to develop an application with highly variable load and short, frequent tasks, as long as they take its usefulness with a grain of salt and don’t buy into all Amazon’s hype.