AWS ECS is NOT Docker Swarm

calendar Aug 14, 2020 · 3 min read  devops en knowledgebase  · aws  ·
Share on: linkedin copy

Amazon Elastic Container services (ECS) is the Amazon Solution for running  docker containers on Amazon.

ECS is not a docker swarm implementation. I am writing this article to stress this, because this point is not very clear digging in the tutorials (it is explained a bit in the question "What is the difference between Docker Swarm, Kubernetes, and Amazon ECS" but then the tuytorials mix the things up too much).

ECS is based on Amazon Cloud infrastructure, and offers two different implementations: one based on EC2 instances and one on AWS FarGate. I will describe here the EC2 solution, for sake of simplicity.

ECS uses the already known Amazon technology (like Cloud Formation) to deploy a cluster of EC2 machines. These machines provide a docker ce container in standard mode (no swarm). You can even log in on these clones and inspect them a bit. On the following example you can even see a EFS file system mount:

[root@ip-172-31-43-196 ec2-user]# docker --version ; docker stats --no-stream ; df -h
Docker version 19.03.6-ce, build 369ce74

CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
0b97273ed0ba        ecs-agent           0.01%               9.633MiB / 1.909GiB   0.49%               0B / 0B             0B / 0B             13

Filesystem                                 Size  Used Avail Use% Mounted on
devtmpfs                                   965M     0  965M   0% /dev
tmpfs                                      978M     0  978M   0% /dev/shm
tmpfs                                      978M  444K  978M   1% /run
tmpfs                                      978M     0  978M   0% /sys/fs/cgroup
/dev/nvme0n1p1                              30G  1.6G   28G   6% /
overlay                                     30G  1.6G   28G   6% /var/lib/docker/overlay2/111ea79897f6e79e7adebf0d7f7cadb0de1ead7aa86cda6b8beee94ad6e9db24/merged
shm                                         64M     0   64M   0% /var/lib/docker/containers/0b97273ed0ba044c4dbecef0dd018e361bdec4b6e8e17ab307e9026e9b4f91bf/mounts/shm
fs-y8ed1te4.efs.us-west-1.amazonaws.com:/  8.0E     0  8.0E   0% /var/lib/ecs/volumes/ecs-ecs-services-18-myEFSVolume-c2e2a5cddd8ca8c96a00
tmpfs                                      196M     0  196M   0% /run/user/1000
tmpfs                                      196M     0  196M   0% /run/user/0

The ecs-agent (line 5) is the agent running as docker container, which enable the ECS to work.

This solution is not based on docker swarm: but from documentation it seems able to understand docker-compose version 3 specification. Anyway seems impossible to define scale factors and replica rules using the version 3 specification (the "deploy" subsection is unsupported).

So it seems basically a docker-compose version 2 which can be integrated with Amazon vpc/scaling/replica/load balancing feature via an extra configuration file (called ecs-params.yml). This is a bit weird.

For this reason ECS is great for running docker-compose images, but not seem a good fit for docker swarm "stacks" of services.

Where ECS shines are the following areas:

  1. Provisioning: You can ask for spot instances setting a price.
  2. Elastic rescale and resilience: for instance if a EC2 instance goes down, the Amazon infrastructure will bring ti back from death (a manual rescale (ecs-cli scale) anyway will bring down the services, so this operation is not completely hassle-free).
  3. You can provision a brand new cluster in about 3 minutes versus the 15 minutes required by a FarGate K8s cluster.
  4. Your costs are based on EC2 instances, so easy to manage (because EC2 cost management is critical for your forecast in a medium sized company)
The cons of ECS2 are:
  1. ECS works via "ecs tasks" syntax: it seems complex to deploy a docker swarm stack without a deep rework of the docker-compose.yml file
  2. ECS need the other AWS resources to work with (like Load balancers and so on)
  3. ECS create images with fixed EBS disk size of 30GB (reducing this size seems not so easy).
  4. Standard docker logging is a dead end. You must relay on amazon cloud driver to collect logs. It would be nice to support it in an automatic way without extra costs.