When looking at a list of services in AWS, you can easily be impressed by how many of them there are. There seem to be options for everything that is more or less standard. On the other hand, if you are new to the Amazon cloud, it is even overwhelming, and you consider hiring a certified AWS professional. There is more than one option even for running a simple Docker image. In this article, I explain your options and how to choose between them.
Thinking about running Docker images in AWS, two products immediately come to mind: EKS and ECS. I will focus on both technologies in the rest of the article.
What is EKS?
EKS is an acronym for Amazon Elastic Kubernetes Service. It is an AWS product that allows you to run Kubernetes without manually setting up the whole Kubernetes cluster. A lot of the operational overhead is taken care of by EKS.
An important factor in choosing EKS is the fact that EKS is compatible with Kubernetes.
EKS allows running a Kubernetes cluster in AWS. If you already have Kubernetes configuration, you can reuse it. Knowledge and experience with Kubernetes will not be a waste here either. You cannot forget that as it is just a service for running Kubernetes, it should be relatively easy to migrate from AWS to any other Kubernetes cluster provider if you decide to do that in the future.
The whole flexibility and extensibility come with Kubernetes here. Plugins that you would use in your own Kubernetes cluster, can be used in EKS as well. EKS allows users to take advantage of the whole Kubernetes ecosystem.
Kubernetes was created for easier management of multiple clusters. The same principle naturally applies to EKS. It suits well large-scale applications that require different clusters for different environments. The more complex your application is, the more useful will be the ability to define custom resources (CDR) or build Aggregated API.
What is ECS?
ECS stands for Amazon Elastic Container Service and is used for running Docker containers similar to what EKS does. It is an orchestration service that simplifies the deployment, management, and scaling of containers. It is a fully native AWS service, not using Kubernetes. It is a proprietary AWS solution. And because of that, as you can guess, it easily integrates with other AWS products like IAM, VPC, and CloudWatch.
It abstracts a lot of the container orchestration complexity. Whatever can be automated and can be done by someone else, is delegated to AWS. You don't have to worry about managing the control plane, or the infrastructure. You can even use AWS Fargate as a serverless computing engine for containers to reduce the contact with the underlying infrastructure even further.
EKS or ECS - which one to choose?
A decision between EKS and ECS should be considered based on 4 areas. However, some of them might be more important than others for your case. So there is not a single answer to this question.
Ease of use
If have vast experience in AWS, but not necessarily in Kubernetes, consider ECS. It will probably be easier for you to set it up and use it as a lot of configurational and operational work is done by AWS. On the other hand, if you feel confident with Kubernetes, give a point to EKS.
Configurability
Kubernetes is a good choice for many various applications, because of its flexibility. You can do a lot of different things with it. That flexibility stays with EKS - it might be a good choice for large applications that require a special setup. Not all configuration options are available in ECS.
Integration with AWS
AWS integration is a definite point on the ECS side. ECS is a proprietary AWS product and was designed in such a way that integrates well with other AWS products. Actually, it is even limited to the AWS ecosystem, so migration from the AWS will be difficult. EKS is just the opposite, if you need deeper integration with AWS products, you have to take care of it yourself, but if you decide to move to another cloud provider, it will be easier.
Performance and scalability
Both solutions provide excellent performance and scalability. However, EKS is more flexible. So some use cases require a special setup, which is possible in EKS but is not available in ECS. Generally, ECS works well for most projects, but very large applications sometimes require a little bit more, and then EKS should be considered.
Cost
The cost area is similar to the performance. ECS will be more cost-effective for small and medium-sized workloads, which can be further simplified by the usage of Fargate. However, large-scale workloads may get out of control easier. EKS's flexibility may help here for large applications. On the other hand, EKS's complexity may cost more in small projects.
Summary
Both ECS and EKS can be excellent choices in various cases. The decision has to be made based on specific needs and plans for the future. And even then, the final choice might not be optimal. By choosing one option, you sacrifice the benefits of another one.
Generally, ECS is a better choice for simpler projects that are tightly integrated (or plan to be) with other AWS products. Usually, it works better with small to medium-sized applications without special configuration needs.
In turn, EKS seems better for large non-standard projects, that might need unusual configuration. It is also a choice of teams that already have Kubernetes clusters and want to move to AWS with them.
