Guided architecture tour · 6–8 min
ECS and Fargate architecture
Separate an image, task definition, task, and service. Keep a container application running with managed compute.
This tour teaches architecture decisions. Its services are not provisioned in the emulator.
Play this architecture tour1. Describe what runs
You have a container image. ECS needs to know its image reference, resource needs, and container settings.
Where is that configuration defined?
An ECS task definition.
The task definition is the blueprint. A task is a running instantiation of it.
The image is described by a task definition with CPU, memory, and container settings.
requiresCompatibilities: ["FARGATE"]
networkMode: "awsvpc"
containerDefinitions: [{ name: "web", image: "YOUR_IMAGE" }]2. Maintain the desired count
The web application should keep two tasks running. One task exits.
Which ECS concept maintains the desired task count?
An ECS service.
A service manages the desired number of tasks. A standalone task is not a replacement policy by itself.
The service replaces the exited task to work toward its desired count.
Service → desiredCount: 2 → tasks
Exited task → replacement task3. Repair missing connectivity
A task in a private subnet cannot pull its container image. Fargate manages compute, but network configuration still matters.
What should you inspect?
Image registry access, task execution role, and the subnet’s network path.
Managed compute does not remove image permissions or connectivity requirements. Check the exact startup failure.
The investigation separates execution-role permissions from registry network access.
Image pull failure → registry + execution role + routes/endpointsPractice, then check your understanding
In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.
Read the official AWS documentation for service behavior and production details.