AWS has a confusing number of ways to run your code, and the names do not tell you how they relate. EC2, ECS, Fargate, Lambda, and more, all "compute," all overlapping. Beginners pick one semi-randomly and stick with it. Let me lay out what each actually is, how much of the work AWS does for you versus you, and a simple way to decide, so you choose on purpose instead of by habit.
The one axis that organizes all of them
Every compute option sits on a single spectrum: how much of the operational work do you do versus how much AWS does. More control means more responsibility; less responsibility means less control. That is the whole tradeoff.
From most-you-manage to least:
EC2: you get a virtual server
EC2 (Elastic Compute Cloud) gives you a virtual machine. You pick the size, the operating system, and you are responsible for the OS, patching, scaling, and what runs on it. It is the most flexible and the most work.
Use it when: you need full control of the environment, you are running something that expects a real server (legacy apps, specific OS tuning), or you want to manage the machine yourself.
The catch: you own the undifferentiated heavy lifting, patching, scaling, keeping it healthy. Powerful, but you are the sysadmin.
Containers: ECS and the Fargate question
Containers package your app with its dependencies so it runs the same everywhere. To run containers on AWS you need two decisions: an orchestrator (what schedules and manages your containers) and a launch type (what the containers actually run on).
ECS (Elastic Container Service) is the orchestrator. It decides where your containers run, restarts them if they die, and scales them. But ECS still needs something to run the containers on, and that is where the two launch types come in:
- ECS on EC2: your containers run on EC2 instances that you manage. You still own the servers under the containers.
- ECS on Fargate: you do not manage any servers at all. You hand AWS a container and say "run this," and Fargate provisions the compute invisibly. No instances to patch or scale.
So Fargate is not a separate orchestrator, it is a serverless way to run containers. ECS (or EKS, the Kubernetes version) is the brain; Fargate is the "no servers to manage" launch option under it.
Use containers when: you want portability and consistent deploys, and you are running services (APIs, workers) that stay up. Choose Fargate over EC2 launch type unless you have a specific reason to manage the underlying instances (cost tuning at scale, special hardware).
Lambda: you give AWS a function
Lambda is the far end of the spectrum: you upload a function, and AWS runs it in response to an event (an HTTP request, a file upload, a queue message). No servers, no containers to manage, no capacity to plan. You pay per invocation and per millisecond of run time, and when nothing calls it, you pay nothing.
Use it when: your workload is event-driven, bursty, or intermittent, individual tasks are short, and you do not want to run anything 24/7. Great for glue code, webhooks, scheduled jobs, and light APIs.
The catch: cold starts (the first call after idle waits for the function to spin up), execution time limits, and it is a poor fit for long-running or steady heavy workloads (where always-on compute is cheaper).
A decision shortcut
Ask these in order:
- Is it event-driven, short, and intermittent? Lambda. Do not run a server for something that fires a few times an hour.
- Is it a long-running service you want portable and easy to deploy? Containers on ECS/EKS, and use Fargate so you do not manage servers, unless you have a reason to.
- Do you need full control of the machine, a specific OS, or are you running something that expects a real server? EC2.
- Not sure and want the least operational burden? Start serverless (Lambda for functions, Fargate for containers) and move toward EC2 only if you hit a wall or a cost crossover.
The cost angle in one line
Roughly: Lambda is cheapest for spiky, low-volume work (you pay only when it runs); containers on Fargate are a sweet spot for steady services without server management; EC2 becomes cheapest per unit at large, steady scale if you manage it well (rightsizing, commitments). "Serverless is always cheaper" and "EC2 is always cheaper" are both wrong, it depends on the shape of the workload.
The take
AWS compute is one spectrum from "you manage the server" (EC2) to "you hand AWS a function" (Lambda), with containers (ECS/EKS, run on EC2 or serverless Fargate) in between. Pick based on the shape of your workload and how much operational work you want to own: event-driven and short means Lambda, steady portable services mean containers on Fargate, full control means EC2. Choose on purpose, and you get the right tradeoff instead of whatever you used last time.
Which compute option did you default to when you started, and did you later realize a different one fit better? A lot of people run everything on EC2 first, then discover half of it should have been Lambda or Fargate.
Top comments (0)