VOOZH about

URL: https://thenewstack.io/a-2020-guide-to-computing-on-amazon-web-services/

⇱ A 2020 Guide to Computing on Amazon Web Services - The New Stack


TNS
SUBSCRIBE
Join our community of software engineering leaders and aspirational developers. Always stay in-the-know by getting the most important news and exclusive content delivered fresh to your inbox to learn more about at-scale software development.
REQUIRED
It seems that you've previously unsubscribed from our newsletter in the past. Click the button below to open the re-subscribe form in a new tab. When you're done, simply close that tab and continue with this form to complete your subscription.
The New Stack does not sell your information or share it with unaffiliated third parties. By continuing, you agree to our Terms of Use and Privacy Policy.
Welcome and thank you for joining The New Stack community!
Please answer a few simple questions to help us deliver the news and resources you are interested in.
REQUIRED
REQUIRED
REQUIRED
REQUIRED
REQUIRED
Great to meet you!
Tell us a bit about your job so we can cover the topics you find most relevant.
REQUIRED
REQUIRED
REQUIRED
REQUIRED
REQUIRED
Welcome!

We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.

What’s next?

Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.

Follow TNS on your favorite social media networks.

Become a TNS follower on LinkedIn.

Check out the latest featured and trending stories while you wait for your first TNS newsletter.

PREV
1 of 2
NEXT
VOXPOP
As a JavaScript developer, what non-React tools do you use most often?
Angular
0%
Astro
0%
Svelte
0%
Vue.js
0%
Other
0%
I only use React
0%
I don't use JavaScript
0%
Thanks for your opinion! Subscribe below to get the final results, published exclusively in our TNS Update newsletter:
NEW! Try Stackie AI
From clobbered drafts to real-time sync
Apr 14th 2026 10:00am, by David Moore
TypeScript 6.0 RC arrives as a bridge to a faster future
Mar 14th 2026 9:00am, by Darryl K. Taft
Mastra empowers web devs to build AI agents in TypeScript
Jan 28th 2026 11:00am, by Loraine Lawson
2020-10-20 12:00:47
A 2020 Guide to Computing on Amazon Web Services
contributed,sponsor-thundra,sponsored,sponsored-post-contributed,
Cloud Services / Serverless

A 2020 Guide to Computing on Amazon Web Services

In terms of compute services, Amazon EC2, AWS Fargate and AWS Lambda are the popular choices in the paradigms of IaaS, CaaS, and FaaS respectively.
Oct 20th, 2020 12:00pm by Sarjeel Yusuf
👁 Featued image for: A 2020 Guide to Computing on Amazon Web Services
Thundra sponsored this post.

Thundra sponsored this post.

As cloud vendors vie for market share, Amazon Web Services seems to be winning the battle for cloud computing in terms of annual revenue.

👁 Image

Data source: Canalys

Sarjeel Yusuf
Sarjeel is a Product Manager at Atlassian, responsible for orienting Atlassian tools to facilitate DevOps capabilities in their feature sets.

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). Ultimately, it comes down to whether you want to go down the route of serverless applications, or make use of containers — or even implement a hybrid architecture.

In terms of compute services, Amazon EC2, AWS Fargate and AWS Lambda are the popular choices in the paradigms of IaaS, CaaS, and FaaS respectively.

If these three services were to be put on a spectrum, where one end of the spectrum was containers and the opposite end was serverless, AWS Fargate would sit in between both of them. This is because AWS Fargate is a serverless container and can also be defined as a CaaS service.

So let us dive into these services, to understand what they have to offer.

AWS Containers in the Cloud

In 2014, following the success of Kubernetes, AWS launched its own container management service called Amazon Elastic Container Service (Amazon ECS) — allowing you to manage the orchestration of your Amazon Elastic Compute Cloud (Amazon EC2) instances. Since then, we have seen an increase in the interest of EC2 containers. So what was the big deal with ECS and EC2?

Firstly, ECS is simply a container orchestration service. It allows you to visualize EC2 containers in the form of tasks, where a single task is one or more EC2 instances that already have Docker installed in them. Each EC2 instance with Docker then communicates with the AWS backend. Several EC2 instances forming a cluster will run within the ECS auto-scaling groups, with scaling rules that you define. That means the ECS Container Agent is continuously polling the ECS API, to check which containers need to be stopped or run according to the task requirements. All of this seems alluring, but the problem is that you still have to manage each EC2 instance — and this is where the difficulties begin.

EC2 orchestration, just like any other container orchestration, is a daunting task; giving AWS Lambda the upper hand in this aspect. Even though ECS makes it easier to manage tasks, you still have to perform management on the container level. You still have to manage scaling, monitoring, securing, networking, and other operational issues of the EC2 instances. The management at the container level not only makes using containers an operational burden, but also vulnerable security-wise and unreliable performance-wise.

For example, even though you may have specified fitting rules for the ECS auto-scaling groups, automatically increasing or decreasing the tasks as per the needs, the EC2 instances themselves may not have enough memory or CPU provisioned to them. Additionally, there is no clear metric to scale EC2 clusters and also no proper solution regarding the scaling, when task allotment fails due to lack of EC2 cluster resources. Another problem is scaling down EC2 clusters without killing any tasks.

These operational burdens are not only seen with AWS EC2, but across all of the container services out there. With all of his work, when would you have the actual time to concentrate on your business logic? This is why AWS introduced Fargate, bringing you salvation by abstracting all of those container orchestration responsibilities.

AWS Fargate presents Containers-as-a-Service (CaaS), as compared to the Infrastructure-as-a-Service (IaaS) that EC2 is. That means the containers have already been set up, including the networking, security, and most importantly the scaling. These major operational burdens are abstracted away, providing you with the ability to run containers directly on the cloud. With this service, you simply have to specify the resources for each container instance and let Fargate work its magic under the hood.

👁 Image

At the end of the day, each Fargate instance comes with its dedicated ENI to allow communication between inter-task clusters, whereas clusters of the same task are communicated via localhost. Moreover, the management of these tasks is again done by ECS. In fact, Fargate is defined as a compute engine of ECS, providing a different way of managing tasks; and this is the defining characteristic of Fargate linking it to container services. However, this is only one side of Fargate, there is an entire serverless side too.

👁 Image

AWS Resources on Demand with Serverless

So, AWS Fargate lets you run containers directly in the cloud. But how? Well, this is where the serverless part of the service comes into play. AWS Fargate can be considered a subset of AWS’ serverless compute services. That means instead of going to the other extreme of the spectrum, you can now take advantage of serverless without having to leave the flexibility of containers.

Terming Fargate as a serverless compute service also breaks one of the greatest misconceptions of the concept. Many believe that serverless equates to Functions as a Service (FaaS). The misconstrued association is due to the success of AWS Lambda, and so AWS Lambda functions became synonymous with the serverless concept.

But a service can be defined as serverless if it possesses the following three features:

  • Server management is abstracted to a vendor;
  • Pay-as-you-go model, where you only pay for what you use; and
  • Automatically scalable and highly available.

Considering the above-mentioned properties, AWS Fargate is truly serverless. This is because, as already stated, with CaaS all of the underlying architecture up till the container level is abstracted to the vendor. Furthermore, similar to AWS Lambda, Fargate also follows a pay-as-you-go model. The difference though is that with the Lambda service, billing is calculated per invocation whereas; with Fargate, you are charged according to the vCPU and memory you consume per second. Finally, the distinct and most crucial characteristic that Fargate possesses, justifying its serverless tag, is the auto-scalability feature. Similar to AWS Lambda, Fargate is also scalable and highly available; and this is expected, since both services have AWS Firecracker running under the hood.

Officially released at AWS re:Invent 2018, Firecracker is a greatly powerful virtualization tool that uses a Kernel-based Virtualization Machine (KVM). Designed to be secure and extremely lightweight, the technology has allowed AWS to enhance the serverless experience for both its Lambda and Fargate services. According to AWS Chief Evangelist Jeff Bar, Firecracker is “what a virtual machine would look like if it was designed for today’s world of containers and functions.”

Hence, with the support of Firecracker, AWS has brought CaaS into the fold of serverless computing services. The myth of serverless only meaning FaaS is now rightly being challenged, ushering in a new era of solutions into the domain. However, this was long overdue as the limitations of AWS Lambda have been acting as a deterrent for many to move their architectures towards serverless. This is where Fargate has some benefits over Lambda services.

Conclusion

The cloud has dominated the conversation of how software systems are now being built. Vendors such as AWS, Azure and Google Cloud are producing solutions to facilitate this development in the cloud, providing a myriad of services to meet the needs of different applications. AWS alone provides three primary services across the computing spectrum of IaaS to FaaS. The question then is, which service best fits your use case and business model? This requires comparing the different services to understand their desirability as compute solutions in different use cases.

This is what we at Thundra have explored, by analyzing and comparing the different AWS services. Our team has written about the various comparisons that can be made between the three services and documented their findings in Thundra’s whitepaper on the topic, which you can download now.

Amazon Web Services is a sponsor of The New Stack.

Feature image via Pixabay.

Thundra Foresight empowers developers to build successful CI pipelines by providing deep analytics and debugging capabilities. With observability into the CI process, Thundra Foresight helps optimize build duration, enable more frequent deployments, increase productivity, and lower CI costs.
Learn More
The latest from Thundra
TRENDING STORIES
Sarjeel is a Product Manager at Atlassian, responsible for orienting Atlassian tools to facilitate DevOps capabilities in their feature sets.
Read more from Sarjeel Yusuf
Thundra sponsored this post.
SHARE THIS STORY
TRENDING STORIES
TNS owner Insight Partners is an investor in: Docker.
SHARE THIS STORY
TRENDING STORIES
TNS DAILY NEWSLETTER Receive a free roundup of the most recent TNS articles in your inbox each day.
The New Stack does not sell your information or share it with unaffiliated third parties. By continuing, you agree to our Terms of Use and Privacy Policy.