Let us start with a simple introduction of all the three offerings from AWS.
AWS EKS (Elastic Kubernetes Service)
- This is a standard Kubernetes offering from AWS which helps you to manage your Kubernetes application on the cloud. Using this service, you can deploy and scale your Kubernetes service as you would do with an on-premise solution.
On-premise - It is a term used for services (web server, database, kubernetes cluster etc.) that is self-hosted and self managed on your own private hardware.
AWS ECS (Elastic Container Service)
- This is a fully managed container orchestration service created and managed by AWS. You can think of this as
AWS' own implementation of Kubernetes like service.
Now that we have seen what each service means on a high level, let's dive more deep into it.
How AWS EKS and AWS ECS are similar ?
The goal of both these services is to run and scale your application containers.
In EKS the container run within a pod, while in ECS the container runs within a task. In both the AWS services, the worker nodes where pods/tasks run are essentially an EC2 instance which is managed by you. You are responsible for creating and managing the EC2 cluster.
Difference between EKS and ECS ? When to prefer one over the other ?
When it comes to EKS, it is an open source implementation of Kubernetes on AWS, but ECS is an AWS proprietary technology. So if you want multi-cloud support or if you already have a Kubernetes cluster running elsewhere (on-premise or other cloud vendors) then choosing EKS over ECS makes more sense because you can easily move over your existing application over to EKS with very minimal spec change.
If you want to optimize the cost and your application was not deployed on any container orchestration service before, then you may want to prefer ECS. With ECS, you do not have to pay for control plane (master) nodes, and you only pay for worker nodes that your cluster has. In contrast with EKS you pay for control plane (master) nodes as well as worker nodes.
If your application uses a lot of AWS services, the ECS might be a better option because it provides out of the box integration with a lot of AWS services like IAM (Identity Access and Management), ELB (Elastic Load Balancer) etc. With EKS the integration is not as rich as ECS, but it is not too bad either. You may have to manage your own middleware (integration with other AWS Services) in some cases.
If you have a very specific use-case where you want to manage your own control plane nodes, then you can do that with EKS. AWS has a provision to allow you to manage your own control plane nodes by spinning up your own control plane in an AWS EC2 instance.
Conclusion
Choose ECS,
If you want to run on less cost and your application was not using any container orchestration service earlier. You will get better integration with other AWS services. The downside is once you move your application to ECS you will loose the flexibility to move to other cloud vendors or move to an on-prem solution if need be.
Choose EKS,
If you already have an Kubernetes based application running elsewhere(either on-premise or on some other cloud vendor) and you want to move into AWS. Though it is more costly than ECS but you can provision and manage your own control plane nodes exactly as you like. With that said you do have to manage some of the middleware to other AWS services using your own code.
Top comments (0)