EKS, ECS, or maybe Lambda? AWS has several serverless compute options. When should I use what?
AWS came a long way since EC2 and offers 10 different compute services that can be used in many ways. In this article, we'll shed some light on the most common serverless compute options to make it easier to take an informed decision when designing a new cloud-based application.
December 15 2022 · 6 min read
Why Hello, Why world
AWS has several serverless compute options - Lambda, ECS Fargate Task / Service, and EKS - And each one excels in different scenarios. Let's do a short review of your options, and then discuss how to best utilize them.
AWS Lambda needs no introduction - it's one of the most famous AWS services. If you're just starting with serverless computing, or just starting out - this is probably the solution for you. All you need to do is add your code (or Docker image), and your lambda will be ready to work.
AWS Lambda is scalable by design - out of the box, you can have up to 1,000 lambdas instances invoked in a single region simultaneously (and it can be increased by demand).
Lambda does have it's caveats, though:
- It's limited to 15 minutes of run time
- The Lambda vCPU is allocated proportionally to the amount of memory - so ~1,800MB of memory will get you ~1 vCPU
- If your Lambda wasn't running for a while, the first run might take longer than usual ("Cold Start").
- See here for more Lambda quota limits
So, for any "regular" web-request-response tasks, that doesn't use too much CPU, and ends quickly, Lambda is probably your go-to.
AWS ECS is short for Elastic Container Service - where the general idea is that you can upload your images, and with a little configuration, AWS will run and manage them for you.
ECS comes in 2 flavours - one for when you want to provision your own instances and resources (VPC, subnets, auto scaling groups), and Fargate, which is the serverless version.
When using ECS with a Fargate cluster, you don't need to provision or set up any of these resources - You only need to pick the image and your vCPU and memory requirements, and AWS will provision and handle these resources for you.
Unlike in the Lambda, when you're using ECS you're not limited by runtime, and you can specify exactly how much memory and vCPU you need. You can run several images on the same task, use App Mesh for service discovery and container monitoring, connect volumes to the containers, and so on.
ECS supports 2 run types: A Task and a Service
An ECS Task is a job that runs to completion, and then ends - You can specify how many instances you want running, and how many images, but eventually, when they've done their job - the task ends.
This makes ECS tasks very useful when you have long running tasks that need to run on trigger, on scheduled times, or invoked on demand - like an offline data enrichment process, periodical data crunching, and so forth.
An ECS Service is exactly what you would imagine: A collection of tasks, with a set number of tasks running at any time, a load balancer to split the requests between them, and an auto scaling group to add/remove task instances based on load / utilization.
These features make the ECS Service very useful for your "always-on" infrastructure - for example, a web-service that needs to scale (up or down) according to the amount of requests.
EKS stands for Elastic Kubernetes Service - it's AWS's managed Kubernetes solution. Kubernetes is an extremely useful and popular framework for automating deployment, scaling, and management of containerized applications. However, it's also quite complicated to manage and has quite a steep learning curve.
When using the EKS version of Kubernetes, AWS handles a lot of details for you - you don't have to install the master nodes that control the Kubernetes cluster, and you can add worker nodes easily without the need to install them manually.
Like ECS, EKS also supports 2 flavours - EC2 instances fleets, or Fargate, which is the "serverless" option. The Fargate version of EKS saves you the need to provision and manage your services, but it's not optimized for long running applications like web servers or applications that require a lot of persistent volumes / file systems .
So, which one should you use?
Lambda, ECS and EKS are not mutually exclusive - each of these solutions is great for one set of problems, and sub-optimal for others. In most cases, the best solution will come up from using a few of these services together.
So the more important question is not "Which solution should I choose", but more of "How do I make it as easy as possible for me to switch between the solutions according to my needs".
Imagine you're at the first stages of your project, still trying to understand the traction, the usage patterns, or just the good-old market fit. Lambda's probably the best solution for you: It has a minimum amount of overhead, it scales automatically so you have less chances of being surprised, and you pay only for what you use (which can also be limited) - so you can take measures to limit your monthly bill.
A couple of weeks later, you realize you need to run some long-running tasks once a week to crunch some data and provide info for your marketing people - you can utilize an ECS Task with Fargate. You don't need to overthink it, provision a machine, select instance types - you just define the task, let AWS provision it for you and push your outputs to an S3 bucket or an Aurora RDS table when done.
When you've reached a point when you're running multiple services that need to communicate with each other to generate a response to the user, with enough complexity / traction to require full blown services - ECS Fargate Service is probably the go for you.
And when you've reached the point when you need to deploy multiple environments for different complex products, each made of multiple services, that might be your queue to dive into EKS.
So the best thing about Serverless is that none of these solutions is mutually exclusive - you can run several Lambdas for you basic CRUD service, while utilizing ECS Fargate tasks to do a weekly data processing for your marketing team, and still run an couple of ECS/EKS Services to support your more frequently used endpoints - and since all these service support using Docker images, you don't even need to change your code - you can use the same Docker image on Lambda, ECS Task, ECS Service, or EKS.
Using Altostra, you can easily create a diverse infrastructure using Lambda, ECS Tasks and ECS Services.
Want to get early access to EKS or a free consulate? Book a time with one of our experts.