As the above diagram indicates, there are 6 deployment options, for Containers in AWS. It is rather confusing. The deployment model will depend on use cases, skills, budget and how much of the infrastructure you as a client want, or don’t want to manage.
Amazon Elastic Container Service and Elastic Kubernetes Service both run containerized applications. But they do so in different ways.
ECS runs applications in containers on clusters of EC2 instances or via the AWS Fargate serverless service.
ECS Fargate. AWS managed and this service deploys, scales up and down, and otherwise manages the containerized application.
ECS on EC2. Client provisions the environment, the underlying infrastructure is managed by the client.
EKS runs containerized applications via Kubernetes orchestration and management on AWS or on-premises resources. EKS creates Kubernetes clusters on EC2 instances or Fargate. With EKS, Amazon manages the Kubernetes deployment.
K8s on EC2. The client manages the deployment as an IaaS.
ECS and EKS both support Fargate. This service automates much of the work related to infrastructure management. Thus, you can use Fargate to simplify infrastructure provisioning and scaling regardless of whether you choose ECS or EKS. Fargate is not a requirement of either service. It is possible to manage infrastructure manually under ECS or EKS, if desired.
To choose between ECS and EKS, evaluate them against application development and management priorities, as well as the skills of IT staff.
Skills and customization
In general, ECS is the simplest way to deploy containers in AWS. Unlike EKS, it doesn’t require you to understand the complexities of Kubernetes. It does not rely on native Kubernetes tooling to manage configurations, such as those that govern users and roles. With ECS, admins deploy containers and use AWS’ native tooling, such as the AWS Identity and Access Management framework, to manage the environment.
The trade-off for EKS’ more complex configuration and tooling is a greater degree of flexibility. It’s easier to customize application deployments and control how they operate with access to Kubernetes’ native tooling.
Security controls
In most respects, ECS and EKS are equally secure as components of the AWS cloud platform, but there is one major difference. Because EKS includes access to Kubernetes’ native security tooling, admins and developers can benefit from more security controls and tools when they use EKS versus ECS.
For example, admins can analyze Kubernetes audit logs to identify and investigate security incidents. This feature is not available in ECS.
Pricing
Whether you select ECS or EKS, you pay for the host infrastructure on which applications run. Pricing varies depending on whether you run the containerized applications on a Fargate serverless model or on EC2 instances, for example. But the pricing differences, in this respect, are the same for both ECS and EKS.
There is one important pricing difference between ECS and EKS. On EKS, you pay a fee of $0.10 per hour for each cluster you operate. With continuous 24/7 operation, that’s about $70 per month per cluster.
The added cost of EKS vs. ECS is not a huge expense if you operate just one or two clusters. But if you spread workloads across dozens of Kubernetes clusters, the monthly per-cluster fee of about $70 adds up.
In those multi-cluster deployments, ECS is likely to cost significantly less, because there are no additional, per-cluster charges on ECS.
Networking
In general, ECS is simpler for the IT organization to use, but provides less control than EKS. ECS users can define a few networking options when creating tasks. Tasks are essentially application deployment configurations for ECS. But this approach is relatively basic and doesn’t allow a great deal of customization.
In contrast, EKS provides granular control over networking. The default networking setup in EKS is relatively simplistic: Pods and nodes share network configurations. With custom CNI networking in EKS, the user can modify how pod networking is configured. This control enables more flexibility for applications. You can assign public and private addresses to different pods as needed with EKS and can operate across a range of subnets.
Some network configuration options aren’t supported on EKS in Fargate mode. If your containerized application will run on Fargate, the distinction between EKS and ECS networking is lessened. However, EKS networking remains more granular and extensible.
Portability and compatibility
EKS enables a greater degree of portability and reduces lock-in risks, as compared to ECS. Because it is proprietary, ECS has no equivalent in other public clouds. EKS is based on Kubernetes, which is open source and can run in any public cloud or on-premises location.
Designed to run in containers, applications will be portable regardless of whether you select ECS or EKS. However, because of its native AWS technology, ECS creates more ties to AWS. It will likely take more time to modify or rewrite deployment configurations to move from ECS to a different service. With EKS, you can port most configurations relatively easily to any other Kubernetes-based environment.
Although EKS is similar, in most respects, to other Kubernetes services, it’s not identical. There is a small degree of vendor lock-in when you choose EKS. Don’t expect to be able to drag and drop EKS workloads directly into another cloud provider’s Kubernetes services, like Microsoft Azure Kubernetes Service. Expect to modify configurations, like networking and access control rules, to migrate to another Kubernetes platform.
With this in mind, applications you deploy on either EKS or ECS are packaged as containers. In most cases, you can execute and deploy container images with any mainstream container orchestration service, regardless of where it is hosted. This includes any Kubernetes distribution, as well as other orchestration tools that support containers, such as HashiCorp’s Nomad.
Hybrid cloud options: Anywhere and Outposts
To run containers inside a hybrid cloud architecture, you can use both ECS and EKS in conjunction with AWS Outposts, which is Amazon’s hybrid cloud framework.
Alternatively, EKS and ECS now also both support hybrid clouds without using Outposts. Using EKS Anywhere or ECS Anywhere, you can manage EKS- or ECS-based clusters hosted on private infrastructure.
The EKS and ECS Anywhere approaches are easier to deploy than Outposts. They are also likely to prove less costly because they don’t require users to buy servers directly from AWS.