Elastic beanstalk vs ECS for multi container docker

Question

Working on a multi-container system. I was evaluating the pros and cons of elastic beanstalk and ECS. There are many questions like this which says ECS has more precise control over containers when compared to EB, but they have not listed out. In my perspective here is the difference between them:

+--------------------------------------------+--------------------------------------------------+
|              Elastic Beanstalk             |                        ECS                       |
+--------------------------------------------+--------------------------------------------------+
| Natively support auto-scaling and load     | Auto-scaling can be done with                    |
| balancing. Has the ability to deploy       | some extra efforts. But other AWS resources      |
| other AWS resources along with the         | cannot be deployed with ECS.                     |
| containers.                                |                                                  |
+--------------------------------------------+--------------------------------------------------+
| Container definitions are written in       | Container definitions has to be written in a     |
| dockerrun.aws.json file. All the links     | separate task definition file. Scaling of the    |
| can be written here. This is more like     | container can be specified in                    |
| docker compose file.                       | service definitions.                             |
+--------------------------------------------+--------------------------------------------------+
| Scaling happens based on CloudWatch        | Here, we have a precise control to scale         |
| metric. But when a new instance is         | a particular task (container). This is more      |
| launched, the whole containers in          | like declarative. It does not take in to account |
| task definition file will be launched      | about the instances, it maintains the count of   |
| again (imperative), even though some       | tasks correctly. Scales based on the             |
| of the containers actually has no traffic. | CPU/Memory usage of a specific container.        |
+--------------------------------------------+--------------------------------------------------+

I am not sure of the third point. Correct me If I am wrong. If there are other differences between these two, let me know.

Answer 1

The first point: if you aren't using Elastic Beanstalk and want to deploy other AWS resources with your application, create a CloudFormation template and use CloudFormation change sets to launch, upgrade and tear down your application.

With the third point, Elastic Beanstalk uses the AWS Auto Scaling feature, which only works on the level of creating and deleting EC2 instances. So, if you are using the single container/multi container environment in Elastic Beanstalk, scaling up won't just create another container, but an entire EC2 instance running Docker with all the same containers. Auto Scaling can also be used from a CloudFormation template without using Elastic Beanstalk. It still only works on the level of EC2 instances.

Another option is to use Elastic Beanstalk with its Auto Scaling, set the environment to a single container docker with the container you want scaled, and add the other containers as AWS::ECS::Service custom resources . For example, your single container can be the processing-heavy frontend, while the other container can be the shared data store. This way, you get the nice versioning/deployment/rollout from Elastic Beanstalk, but have containers that are single-instance (per Elastic Beanstalk environment).