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:
- Provisioning: You can ask for spot instances setting a price.
- 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).
- You can provision a brand new cluster in about 3 minutes versus the 15 minutes required by a FarGate K8s cluster.
- 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:
- 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
- ECS need the other AWS resources to work with (like Load balancers and so on)
- ECS create images with fixed EBS disk size of 30GB (reducing this size seems not so easy).
- 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.