Running a service on ECS Fargate

Having argued that most teams should run containers on ECS with Fargate rather than Kubernetes, this lesson shows what that actually looks like: the handful of concepts you need, and how a real service runs on it. ECS is genuinely simpler than Kubernetes, and once you see its pieces you will understand why it is the pragmatic default for containers on AWS. This lesson is running a service on ECS Fargate.

The ECS concepts

ECS has fewer moving parts than Kubernetes, and they map cleanly onto ideas you already know from the containers module:

• Task definition — a blueprint describing how to run your container(s): which image, how much CPU and memory, which ports, environment variables, the IAM role, and where logs go. It is the ECS equivalent of the "how to run this" part of a Kubernetes pod spec. You register a task definition, and it is versioned.
• Task — a running instance of a task definition (one or more containers running together). Analogous to a pod.
• Service — keeps a desired number of tasks running, replaces failed ones, and connects them to a load balancer. This is the ECS equivalent of a Kubernetes Deployment + Service: "run 3 copies of this task, keep them healthy, put them behind the load balancer." Desired-state and self-healing, the same idea as everywhere in this course.
• Cluster — a logical grouping your services run in. With Fargate, the cluster has no servers you manage — AWS provides the compute per task.

That is essentially it: a task definition (how to run it), a service (keep N running, load-balanced), in a cluster. Compared with Kubernetes' pods, deployments, replicasets, services, ingresses, configmaps and the rest, ECS is a much smaller surface — which is the whole point.

Fargate: no servers to manage

Running that service on Fargate means you never provision or manage EC2 instances. You specify, in the task definition, how much CPU and memory each task needs (e.g. 0.25 vCPU, 512 MB), and AWS runs the task on compute it manages, billing you for what the task uses while it runs. No node pool to scale, patch or right-size; no capacity planning for a fleet. You think only about your containers and their resource requirements.

This is the operational saving the previous lessons promised: with Fargate + ECS, going from "here is my container image" to "it is running in production, load-balanced, self-healing, autoscaling" involves a task definition and a service — and no servers at all. For a team that just wants their containers running reliably on AWS, that is dramatically less to operate than a Kubernetes cluster.

How a real service fits together

A typical containerised web service on ECS Fargate wires up like this:

• Your image lives in ECR (Elastic Container Registry — the pipelines module builds and pushes to it).
• A task definition references that image, sets CPU/memory, the container port, environment variables (config), a task role (its AWS permissions — the access lesson's keyless pattern), and a log configuration sending logs to CloudWatch Logs.
• A service runs N tasks of that definition across your private subnets (the networking module), registers them with an Application Load Balancer in the public subnets, and keeps the desired count healthy.
• The ALB receives internet traffic on 443, terminates TLS, and forwards to the tasks; security groups (the networking module) allow the ALB → tasks and restrict everything else.
• Health checks on the service and load balancer ensure only healthy tasks receive traffic, and replace unhealthy ones — the same readiness idea as Kubernetes.

So all the networking and security you learned assembles here: private subnets for the tasks, a public ALB, security groups chaining internet → ALB → tasks, a keyless task role for AWS access, logs to CloudWatch. ECS is the orchestrator tying them together, and Fargate removes the servers.

Scaling and deployment on ECS

ECS handles the operational essentials the same way you would expect:

• Autoscaling — ECS service autoscaling adjusts the number of tasks based on load (CPU, memory, or request count), the same idea as Kubernetes' HPA. Under a traffic spike it adds tasks; when it subsides it removes them.
• Rolling deployments — deploying a new task-definition version does a rolling update by default: it starts new-version tasks, waits for them to be healthy, shifts traffic, and stops old ones — zero downtime, gated by health checks, exactly like the deployment-strategies lesson. ECS also integrates with CodeDeploy for blue-green deployments when you want them.
• Rollback — deploy the previous task-definition version to roll back, the same "keep versions, redeploy a known-good one" pattern.

Everything the DevOps Foundation taught about deployment strategies applies here; ECS just provides it with less machinery than Kubernetes. The takeaway: ECS on Fargate gives you production-grade container orchestration — self-healing, load balancing, autoscaling, rolling deploys, keyless AWS access — with a small concept surface and no servers to manage. For the many teams that do not need Kubernetes specifically, this is how you run containers on AWS, and it is why the previous lesson pointed here.

Check your work

ECS concepts: task definition (blueprint — image, CPU/memory, ports, env, IAM role, logs; versioned), task (a running instance ≈ pod), service (keep N tasks running, self-heal, load-balance ≈ Deployment + Service), cluster (grouping; with Fargate, no servers you manage). A much smaller surface than Kubernetes.

Fargate: no EC2 to provision/manage — you set per-task CPU/memory and AWS runs it, billed for what runs. From image to production (load-balanced, self-healing, autoscaling) is a task definition + a service, no servers.

A real service: image in ECR → task definition (image, CPU/mem, port, env, task role, CloudWatch logs) → service running N tasks in private subnets behind an ALB in public subnets → security groups chain internet → ALB → tasks → health checks. All the module's networking/security/keyless-access assembles here.

Scaling/deploys: service autoscaling (like HPA), rolling deployments by default (zero-downtime, health-gated; CodeDeploy for blue-green), rollback by redeploying the prior task-def version. Production-grade orchestration with less machinery than K8s.

Practice

1. Map ECS's task definition, task, and service onto the Kubernetes concepts they resemble.
2. Explain what Fargate removes compared with running ECS on EC2 nodes.
3. Describe how a containerised web service assembles on ECS Fargate: ECR, task definition, service, ALB, subnets, security groups, logs.
4. Explain how the task role gives the service AWS permissions without stored keys.
5. Explain how ECS does autoscaling and rolling deployments, relating them to the DevOps Foundation.
6. Argue why ECS Fargate delivers production container orchestration with less to operate than EKS.

Official documentation

• AWS — Amazon ECS developer guide — Clusters, task definitions and services.
• AWS — AWS Fargate for ECS — Serverless container compute.
• AWS — Service auto scaling — Scaling ECS services on load.

Next: Graviton, Spot and right-sizing.