AWS Guide
ECS Fargate is the standard way to run containerized applications on AWS without managing servers. This guide explains what it is, how it works, when to use it, and how to deploy to it — with or without Terraform.
Amazon Elastic Container Service (ECS) is AWS's managed container orchestration service — the AWS equivalent of Kubernetes, but simpler to operate. ECS runs Docker containers at scale.
Fargate is the serverless launch type for ECS. Instead of running your containers on EC2 instances you manage, Fargate provisions compute on demand for each task. You never SSH into a host, patch an OS, or plan cluster capacity.
Together, ECS Fargate gives you a fully managed container runtime on AWS where you only define your container (image, CPU, memory, env vars) and AWS handles the rest.
No server management
You never SSH into a host, patch an OS, or worry about instance capacity. AWS provisions compute on demand for each task.
Pay for what you use
Fargate charges per-second based on vCPU and memory allocated to running tasks. Scale to zero overnight and pay nothing.
Task-level isolation
Each Fargate task runs in its own micro-VM (Firecracker). Stronger isolation than shared EC2 — each task has its own kernel.
Fast horizontal scaling
ECS service auto-scaling adds new Fargate tasks within 30–60 seconds in response to CPU or memory pressure, or custom CloudWatch metrics.
You'll encounter these terms whenever you work with ECS. Understanding them is essential for deploying and operating Fargate services.
A logical grouping of ECS services and tasks. Think of it as the "namespace" for your container workloads in a given environment. You can have one cluster per environment (staging, prod) or share a cluster.
A blueprint for your container. It defines the Docker image to run, CPU and memory limits, environment variables, port mappings, IAM role, and log configuration. Versioned — you can roll back to a previous task definition.
The long-running deployment of a task definition. The ECS Service maintains a desired count of running tasks, replaces failed tasks, and integrates with an Application Load Balancer for traffic routing.
The serverless compute mode for ECS. With Fargate, AWS manages the underlying EC2 instances — you only specify CPU and memory per task. You pay per-second for what you use, with no idle instance costs.
A running instance of a task definition. If your desired count is 3, ECS runs 3 tasks (containers). Fargate starts new tasks in seconds on AWS-managed compute.
The Application Load Balancer routes HTTP/HTTPS traffic to an ALB Target Group, which contains your running ECS tasks. Health checks run against each task — unhealthy tasks are automatically replaced.
ECS supports two launch types. For most startups and growth-stage companies, Fargate is the right default.
| Aspect | Fargate (serverless) | EC2 launch type |
|---|---|---|
| Server management | AWS manages all compute — serverless | You manage EC2 instances, OS patches, capacity |
| Scaling | Scale tasks only — no cluster node management | Scale cluster nodes + tasks separately |
| Cost model | Pay per-second per vCPU/GB used by tasks | Pay for reserved/on-demand EC2 instances |
| Cold start | 15–30s for new task allocation | Fast (containers start on warm instances) |
| Use case | Most workloads — simpler, no server ops | High-throughput, cost-optimized at scale |
| Bin packing | AWS handles packing automatically | Manual — you control instance types |
Recommendation: Start with Fargate. Switch to EC2 launch type only if you have sustained high-throughput workloads where reserved instance pricing would meaningfully cut costs, or if you need GPU instances.
These are the three most common patterns for startup applications on ECS Fargate.
The most common pattern. An ECS Fargate service behind an ALB handles HTTP/HTTPS traffic. An RDS PostgreSQL instance in a private subnet stores application data. Credentials injected via Secrets Manager.
Web-facing ECS service for request handling, a background worker ECS service for async jobs (no ALB), and ElastiCache Redis for queuing and caching. Classic SaaS backend pattern.
Multiple ECS services, each with its own task definition, scaling policy, and IAM role. Internal ALBs route traffic between services inside the VPC. API Gateway at the edge.
Setting up ECS Fargate manually requires writing task definitions, configuring ALB listener rules, setting up IAM roles, creating VPC subnets, and wiring CI/CD — typically 2–5 days for a senior engineer. NoahOps automates all of this. Connect your AWS account and GitHub repo, and get a complete Fargate deployment with VPC, RDS, ALB, and CI/CD in under 15 minutes.
NoahOps handles: