Containerisation is complex and involves application building, the use of Docker, a CI-CD pipeline, infrastructure, IaC and the use of Terraform with Helm or Cloud Formation Templates, and the integration of the deployment with monitoring, logging and security services and products. It may take a team, which is new to Containerisation, many months if not years, to fully understand and be comfortable with this deployment model.
For the most part we recommend that clients use Cloud Native PaaS and their Container platforms, to manage their container deployments. In AWS there are a variety of models to choose from when deploying Containers, so which is the right one? https://aws.amazon.com/blogs/containers/amazon-ecs-vs-amazon-eks-making-sense-of-aws-container-services/
ECS is a fully managed service, it doesn’t have as many moving parts, components and functionality as K8s and EKS. Once ECS is set up, users can start deploying tasks straight away from AWS console.
EKS requires a more complex deployment configuration and expertise. After setting it up in the AWS console, the user is required to configure and deploy Pods via Kubernetes, using Kops. You will be using Terraform+Helm or CFT to deploy the related infrastructure. You will need to understand the underlying networking, CI-CD pipeline and integrate EKS with other relevant AWS services around security, logging and monitoring. It is not straightforward.
Ease of Deployment
ECS is a more straightforward platform while EKS is a little more complex and requires more configuration. ECS is AWS native solution, and there is no control plane, EKS is based on Kubernetes, and there is a control plane (managed). For both ECS and EKS there is a data plane. The deployment of both a data and control plane should be automated and this will add complications if you select EKS.
Compatibility/Portability
ECS is an AWS proprietary technology, whereas EKS based on Kubernetes which is open source.
While both ECS and EKS are AWS-specific services, Kubernetes-as-a-service can be used with any cloud provider and on-premise. By using a managed Kubernetes service like EKS, you’re still investing in a cloud-agnostic platform, both in terms of tech and expertise. This isn’t the case for ECS, though, as it’s offered exclusively for AWS.
Security
ECS and EKS, both supports IAM roles per task/container. Both are based on mTLS and both offer layered security from the network, firewall to the data plane pods and containers.
Namespaces
Unlike ECS, Kubernetes has a “namespaces” concept (from Linux), which is a feature intended to isolate workloads running in the same cluster. This seems like an insignificant feature, but it does offer some advantages. For example, you could have staging and production namespaces running in the same cluster while sharing resources across environments, reducing spare capacity in your clusters.
Networking
With ECS, ENIs can be allocated to a ‘Task’, and an EC2 instance can support up to 120 tasks. With EKS, ENIs can be allocated to and shared between Kubernetes pods, enabling the user to place up to 750 Kubernetes pods per EC2 instance (depends on instance type) which achieves a much higher container density than ECS.
Pricing
For both, EKS and ECS — You simply pay for the compute resources consumed by your containers, whether that be on EC2 instances or serverless compute with Fargate.
EKS is subjected to an additional cost of running Master nodes (Control plane), as EKS manages the master nodes (that run across multiple availability zones) separate from the worker nodes ($0.10/hour/cluster). While that’s not the case with ECS.
Community and Support
Kubernetes is an open-source platform with a large and ever-growing community behind that brings apparent advantages. On the other hand, being proprietary, ECS gets less community support, although you’ll have excellent corporate support from AWS.
Kubernetes (EKS) is way more widespread than ECS, given its multi-platform support.
EKS
1. Large or hybrid deployments – prefer EKS for its stronger customization and improved portability between clouds and on-premises systems.
2. If you are experienced and looking for a better way to scale clusters, perhaps EKS is the solution.
3. If you already have containers running on Kubernetes or want an advanced orchestration solution with more compatibility, you should use EKS.
4. Legacy workloads – if you are transitioning to a containerized environment, plain Kubernetes may be the best choice, as it will allow you to build a dev/test/production environment on-premises, and then move it to the cloud.
ECS
1. If you are new to containers and you are looking for a solution that combines simplicity and availability, then ECS is the right choice for you.
2. Small deployments – prefer ECS due to its seamless deployment and configuration.
3. ECS has free control plane.
Kubernetes is the more future-proof and versatile approach. ECS quickly becomes too limiting when the application starts to grow in complexity and size.
Summary
ECS and EKS both are very capable container orchestration solutions which will help you to manage containers at scale. Choosing between EKS and ECS depends on the size and nature of project.