ECS: Tasks vs Services

ECS is an AWS container management service for running containerized apps on a cluster. There are two important concepts to understand in AWS ECS, which are Tasks and Services that we will compare in this article.

Let’s start off where tasks and services are alike and then move on to differences. Both of them need something called a Task Definition which is basically a configuration of a task - sort of what the Docker Image is to a Docker Container. Task Definition holds the information how many containers to create for the task, what containers should be linked together, how much CPU should be allocated, connecting logs, defining environment etc.


Going back to a docker analogy, a task is a single “instance” of a task definition. It is created when ran directly and launches all the containers that were defined in its Task Definition. Running tasks directly is great for running jobs that have a clear start and finish like for example what is usually accomplished by CRON jobs.

Important thing to note is that if a task fails for some reason it won’t be recreated and it does not have access to a Load Balancer.


Using the docker analogy again, a service would probably be docker-compose as it orchestrates tasks but unlike docker-compose it also keeps them running which is known as a Service Scheduler. This means that should a task fail or shut down for some reason, the ECS Service would create a new instance according to user instructions in the Task Definition and Service Definition. Apart from this “self-healing”, ECS Services can also be run behind a load balancer which will distribute traffic across all tasks associated with it.

ECS Service is a good choice for long running tasks like web servers that should be restarted automatically in case they fail for some reason.


As I understand it, the Task is a single instance of a Task Definition that I have to run myself. It will do its job and then shut down but should it fail the job simply won’t be done. Service, however, is the middleman that will take that task definition, take instructions (service definition) on how many tasks should be spun up in however many regions and will keep an eye on it for me. Should any task fail, the Service will create a new instance automatically. One additional but very important difference between them is also that singular Tasks - ones that I run myself - cannot be ran behind a Load Balancer. This is logical as we have only one Task but still important to keep in mind.

Below a simplified diagram of my mental model of how all this works.