AWS Fargate: Serverless Containers
By the end of this lesson, you'll be able to:
- Explain what AWS Fargate provides and correct the "no servers" misconception
- Explain the relationship between ECS (orchestration) and Fargate (compute)
- Compare ECS on EC2 with ECS on Fargate at a conceptual, trade-off level
Prerequisites: "Amazon ECS: Running Containers on AWS"
Fargate: managed compute for ECS tasks
AWS Fargate provides the compute capacity ECS tasks run on, without the customer provisioning or managing the underlying EC2 instances themselves. This is the same "serverless" shift Module 7 introduced for Lambda, applied here to containers: the servers still exist — Fargate doesn't mean there's no server running your container, it means AWS operates that server instead of you.
ECS schedules; Fargate is one place tasks can run
This is worth stating precisely: Fargate does not replace ECS. ECS remains the service deciding where tasks run, keeping the desired count of tasks running, and integrating with load balancers — Fargate is one option for where the underlying compute capacity for those tasks comes from.
ECS on EC2 versus ECS with Fargate
ECS supports more than one way to supply compute capacity for its tasks:
- ECS on EC2 — the customer provisions and manages the EC2 instances tasks run on, giving more direct control over the underlying instance type, capacity planning, and configuration, at the cost of managing that infrastructure.
- ECS with Fargate — AWS manages the underlying compute capacity; the customer specifies what a task needs (CPU, memory) without provisioning or patching instances themselves.
Neither is universally better — the right choice depends on the actual requirement: workloads needing fine-grained control over the underlying instance (specific hardware capabilities, tightly optimized cost at large steady scale) may lean toward ECS on EC2; workloads that benefit from AWS handling instance management, or whose traffic is spiky and unpredictable, often lean toward Fargate. This is the same "choose by actual requirement, not by which sounds more modern" discipline Module 7 taught when comparing serverless to EC2-based designs generally.
A brief note on Kubernetes
AWS also offers Amazon EKS (Elastic Kubernetes Service), a managed Kubernetes option, for teams that specifically need Kubernetes's own orchestration model. This course doesn't go deeper into EKS or Kubernetes — ECS and Fargate are the container services this module focuses on — but it's worth knowing EKS exists as another path, should a future project's requirements call for it specifically.
Exercise
A teammate says "Fargate means there's no server running our container anymore." Using this lesson's correction, explain what's actually true instead. Then describe one scenario where choosing ECS on EC2 instead of Fargate might make sense, and one scenario where Fargate's trade-off fits better.
Show hint
The servers still exist — think about who operates them. For the scenarios, consider steady large-scale workloads versus spiky, unpredictable ones.
AWS Fargate: Serverless Containers Quiz
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
AWS Fargate provides managed compute capacity for ECS tasks, so the underlying EC2 instances a task runs on are provisioned and operated by AWS rather than the customer — the servers still exist, exactly as Module 7 taught for Lambda, and ECS continues to handle orchestration either way; running ECS tasks on customer-managed EC2 instances remains a valid alternative with a different set of trade-offs.