You already have your images stored in ECR (subchapter 17.2). Now it's time to run them: get your containers running in production, scale them, and keep them healthy. For this, AWS offers ECS (Elastic Container Service), its service for orchestrating containers. In this subchapter, you'll understand its key concepts and an important decision: Fargate or EC2.

Running a container on your laptop is easy (docker run). But in production you need much more:

• Run many containers spread across several servers.
• Restart them automatically if they crash.
• Scale them according to demand (more copies at peak times).
• Distribute traffic among them (with a load balancer, Chapter 13).

Doing all this manually would be unfeasible. A container orchestrator automates it. ECS is AWS's orchestrator.

Analogy: an orchestrator is like the conductor of an orchestra. The musicians are the containers; the conductor makes sure they play in harmony, that the right one comes in, that if one fails another covers for it, and that the whole sounds good. You provide the score (the configuration) and the conductor (ECS) coordinates everything.

A task definition is the "recipe" for how to run your container: which image to use (from ECR), how much CPU and memory it needs, which ports it opens, which environment variables it has, etc. It's a blueprint that describes how your application should run.

A task is a task definition in execution: a live instance of your container (or group of containers) running according to that recipe. It is to ECS what a container is to an image.

A service is responsible for keeping the number of tasks you want running and connecting them to a load balancer. You tell it "I always want 3 copies of my API running," and the service makes sure that's the case: if one goes down, it starts another; if you want to scale, it adds more.

Sound familiar? It's the same concept as the Auto Scaling Group from Chapter 13, but for containers instead of EC2 instances. The service maintains the desired number of tasks and repairs them. And, as with the ASG, it integrates with a load balancer to distribute traffic among the tasks.

ECS needs machines to run the containers. Here you have two modes, and choosing well is important:

In EC2 mode, you manage a group of EC2 instances (Chapter 4) where ECS places the containers. You have full control over those servers (instance type, configuration), but also the responsibility of managing them: patching, scaling, maintaining them.

In Fargate mode, AWS provides and manages the servers for you. You just say "run this task with this CPU and memory," and Fargate takes care of everything else. You don't see or manage any EC2 instances: it's serverless for containers.

Connection with Chapter 14: Fargate is to containers what Lambda is to functions: in both, AWS hides and manages the servers. You forget about the infrastructure and just focus on your application.

Recommendation to start: use Fargate. It takes away the burden of managing servers and keeps things simple. EC2 mode makes sense when you grow a lot, have very constant loads (where it can be cheaper), or need special control over the servers. For most teams, Fargate is the default option nowadays.

Bringing together the three container subchapters so far:

• ECS (Elastic Container Service) is AWS's container orchestrator: it runs, repairs, scales, and distributes traffic for your containers automatically (the "orchestra conductor").
• Task Definition: the "recipe" for how to run your container (image, CPU, memory, ports). Task: a recipe in execution. Service: keeps the desired number of tasks running, repairs and scales them (like an Auto Scaling Group, but for containers).
• Two execution modes: EC2 (you manage the servers, more control and effort) and Fargate (AWS manages the servers, serverless for containers, minimal effort).
• Fargate is Lambda for containers: forget about servers. It's the recommended option to start; EC2 makes sense at large, constant scale or with special control needs.

In the last subchapter of the chapter (and of Part IV) we'll see the most powerful and complex alternative: EKS (Kubernetes on AWS), and when it's worth it compared to ECS.