Amazon is leading in the great Cloud War, and this is not just theory or blatant skepticism. With the migration to the cloud being the recent status quo in the software industry, tech giants such as Amazon, Microsoft, and Google are all vying for top place. At the moment though, AWS seems to be winning the battle for cloud computing by consolidating the largest market share.

However, choosing a vendor to move into the cloud with is just half the battle. The other half involves deciding which service best fits your specific application. Your choices range all the way from Infrastructure-as-a-Service (IaaS) to Functions-as-a-Service (FaaS), with all the different paradigms in between offering different levels of abstraction.

Choosing among these various services involves two main measures which ultimately dictate the viability of your application on the cloud. These include the operational burden of operating on the cloud and cost, where one is usually sacrificed for the other. Hence choosing the right service means balancing the two measures to achieve the optimal experience, and this balancing act is performed according to the cloud paradigm you choose.

Currently, AWS offers computing services in form of IaaS with its famous EC2 container service, FaaS in the form of its serverless Lambda functions, and CaaS with its newly released Fargate product. The pros and cons of these various products can be found scattered in various blogs and forums, but they do not directly answer which service you should use specific to your application. Thus, that is the point of this article, to help you decide which of the three main AWS cloud computing services would best comply with your specific use case, according to the two measures mentioned.

Operational Comparison

One of the attractive promises of cloud computing is the major reduction in the complexity of managing server hardware. With the rise of IaaS offerings, people could simply delegate hardware management responsibilities away to the cloud vendors. However, developers now had to learn how to provision the virtual servers over cloud vendor platforms, introducing a new type of operational burden. IaaS has since evolved over the years to Containers-as-a-Service (CaaS) to Platform-as-a-Service (PaaS) to finally Functions-as-a-Service (FaaS). These different paradigms all offer different levels of abstraction, with FaaS being the easiest paradigm to use within cloud computing as it has the most levels of abstraction.

As mentioned before, there are three computing services to choose from within the AWS cloud environment, where EC2 has the most operational burden, AWS Lambda has the least and AWS Fargate is somewhat in the middle on the spectrum.

However, there is a catch. With more abstraction leading to lesser operational burdens, one has to sacrifice flexibility and endure operational limitations. For example, with EC2 Instances you have to specify rules, networking security monitoring and much more. Apart from container orchestration, the major issue also is auto-scaling with defining scaling rules at a container level being extremely arduous. All this extra burden in operation does mean however that you are allowed to configure your environment almost in any way you would like. So you could choose any runtime for example, not have to worry about timeout limitations and also define granular auto-scaling rules that best fit your business needs.

With AWS Lambda, on the other hand, all of that can either be abstracted away or complimented with tools such as Thundra.io for monitoring. Another benefit is that the service performs extremely well when it comes to auto-scaling. There are slight drawbacks in terms of monitoring as AWS Lambda is notorious for its inability to provide substantial monitoring, but with Thundra.io you can get full observability of your business code at an extent that even surpasses monitoring in the other two AWS services. So with all these SaaS tools and ease of operation surrounding AWS Lambda, using the service allows you to focus primarily on your business logic. However, you have to now deal with the operational limitations of the service.

AWS Lambda really does restrict the flexibility of operation as compared to EC2 on the other side of the spectrum. Some of these limitations include a 512MB ephemeral disk space limitation and 50MB deployment package size among, and a few others. Hence, even though you no longer have to worry about provisioning your containers and defining scaling rules, you would still have to worry about such limitations.

AWS Fargate however, sits between EC2 and AWS Lambda on the spectrum and provides respite from Lambda limitations. So is Fargate the way to go. Well, it depends on how much ease of operation you want to achieve. For example, with Fargate you no longer have to worry about patching similar to EC2, but you still have to update your underlying containers. Additionally, even though with Fargate you can escape from EC2 orchestration, you still have to register your containers on the ECS service as Fargate is managed via ECS, which does add more operational complexity.

Therefore, when it comes to operational cost you can either go for full flexibility with EC2 or full operational ease with AWS Lambda or even reach a compromise with Fargate. But no matter what you choose according to your business needs, you will still have to pay for the service, and this is where the second parameter comes in.

Financial Analysis

Migrating to the cloud notably could burn a hole in your pocket, or it could save you a lot of money. It all depends on the service you choose and how you utilize AWS’ pricing plans. Hence it is imperative that we understand which service best fits our use case especially when it comes to paying for the cloud. The general rule of thumb is that the more levels of abstraction we have, the costlier the service tends to be, but that does not always have to be the case.

Firstly comparing the cost of AWS Lambda, an EC2 instance, and AWS Fargate is not a straightforward task as the cost incurred depends on different factors. For example, owing to the serverless nature of AWS Lambda and Fargate, the services follow a pay-as-you-go model. AWS Lambda charges you per invocation and duration of each invocation whereas AWS Fargate charges you for the vCPU and memory resources of your containerized applications use per second.

Conversely, billing for EC2 instances depends on which of the four types of pricing models you opt for. This includes On-Demand, Reserved Instances, Spot Instances, and Dedicated Hosts. You can find the respective prices of each pricing model by going over to the EC2 pricing page.

Hence, it can be seen that comparing the different services head-on is not a simple task, but we shall still do it. Otherwise, what is the point of this blog?

In comparing the prices let us first level the playing field by ignoring the free tier plan offers and consider on-demand EC2 instances to get costs incurred per hour. Furthermore, we shall choose an adequately powerful m4.large instance that includes 2 vCPUs and memory of 8GiB, all costing $0.10/hour. Comparatively, AWS Fargate would cost you $0.11652/hour for the same configurations, slightly more expensive than the EC2 instance. The graph below shows a comparison between EC2 and Fargate across instance types in order to provide a better understanding of how costs between the two services differ. Keep in mind though that you would only be charged using Fargate if your task is running as compared to the fixed charge incurred by EC2.

Now considering AWS Lambda, we have to think in terms of invocations. That means how many invocations would it take, as per the current price rate of invocation and duration during the time of writing this article, to break even with the cost of an EC2 instance. Since we choose an m4.large EC2 instance to do the comparison with, the graph below shows how many invocations per hour we would need to break even depending on different memory allocations.

As can be seen by the chart, if the duration of each invocation is presumed to be half a minute then you can achieve around 16000 invocations per hour to break even with the cost of an m4.large EC2 instance. However, if you allocate the maximum memory of 3008MB then you can only achieve 660 invocations per hour.

Hence it can be seen that deciding on the AWS service depends on how much you want to sacrifice on operational ease, and if choosing AWS Lambda, how many invocations you expect to perform.

Do we Have A Winner

If you read this entire piece hoping for a definitive answer on which service is the best, I am afraid to tell you that you shall be very disappointed. Each service has its pros and cons. Fargate and AWS Lambda greatly reduce the overbearing complexity of orchestrating EC2 containers, but they can potentially add a little bit of cost. Lambda functions could be considered a more viable option but they have their limitations. Hence at the end of the day choosing the right service completely depends on your specific use case.

It can be said, however, that if you do not expect a lot of invocations only sparse calls to your applications, then you should opt for the serverless AWS Lambda to get away from the unnecessary complexity of Fargate and EC2 under the ECS platform. If you expect a resource-intensive application but lightweight in terms of usage, do consider Fargate. If none of the above, then EC2 is always there to save the day. But no matter what you do, stay away from on-premise servers. Don’t make decisions in the dark, one size does NOT fit them all.