In today’s enterprise landscape, there’s a greater focus than ever before on scaling applications quickly and securely while also being mindful of resource use and cost optimization.
Containers provide a standard way to package your application’s code, configurations, and dependencies in a single object. They virtualize at the operating system level, rather than the hardware stack. Users can run multiple containers atop the OS kernel directly. As a result, they’re faster, more portable, and use less memory than virtual machines, and can be crucial in contributing to the success of your cloud environment.
With that said, the management of containers at scale, otherwise known as container orchestration, can be a source of confusion. In this post, we’ll compare and contrast two popular container orchestration services, Amazon ECS and Amazon EKS, to help you better determine which orchestration system is right for your organization.
Amazon Elastic Container Service (Amazon ECS) is a scalable, high-performance container orchestration service that supports Docker containers and allows you to easily run and scale containerized applications on AWS. ECS is built to perform at scale, offers high availability and security, and is deeply integrated with a variety of AWS services, including Elastic Load Balancing, Amazon VPC, AWS IAM, and more.
Additionally, Amazon ECS features AWS Fargate, so you can deploy containers without provisioning servers. This ultimately reduces management overhead and scaling complexities.
To keep up with your application’s growing needs, you can use Auto Scaling groups to manage EC2 instances. Use the managed scaling feature or manage the scaling yourself. You provide a target capacity, and ECS creates a scaling plan, helping you scale up or down as needed without getting out of control. Kubernetes doesn’t offer this fully managed option. Instead, you must configure requests, limits, and the Horizontal Pod Autoscaler (HPA) yourself to adjust the number of replicas and keep CPU use in check, as well as Cluster Autoscaler to manage worker nodes.
You can also use Amazon CloudWatch to monitor and aggregate your ECS and EKS metrics and logs using Container Insights. You can monitor, set alarms on, and troubleshoot all your AWS container resources in one place, including tracking metrics such as CPU and memory use, storage use, and task, service, and instance counts. These metrics can be filtered by ECS Cluster, Service and Task or EKS cluster, namespace, service, or pods.
ECS works with third-party monitoring tools such as Prometheus, too, via CloudWatch or native ingestion with a sidecar container or fluentbit/fluentd. You can also use Grafana dashboards with Prometheus to visualize your ECS metrics, however, these tools are most commonly leveraged in kubernetes environments.
There can be arguments made in favor of ECS over EKS: it’s simpler to use, requires less expertise and management overhead, and can be more cost-effective (albeit at the expense of flexibility) but before we delve into this further, let’s briefly review Amazon EKS.
Amazon Elastic Container Service for Kubernetes (Amazon EKS) makes it easy to deploy, manage, and scale containerized applications using Kubernetes on AWS. Since this service leverages the open-source tool Kubernetes, all applications managed by Amazon EKS are fully compatible with applications managed by any standard Kubernetes environment. In that sense, it can be argued that Amazon EKS is more extensible than Amazon ECS.
Kubernetes’ diverse ecosystem of tools includes, for example, the templating deployment tool Helm (with its large library of public charts), Istio, Envoy, and a diverse range of service meshes, certificate management tools like Jetstack’s cert-manager, and a vast array of tracing, monitoring, and metrics reporting solutions (Prometheus, Grafana, Jaeger, and more). ECS does not benefit from this wide range of enhancements, though it does support some of the same toolsets, such as Prometheus and Grafana.
Like ECS, EKS works with Fargate to reduce management overhead and CloudWatch Container Insights to track metrics.
Let’s go a step further and review some of the core differences between ECS and EKS.
Amazon ECS vs EKS: Compare and Contrast
One primary difference between ECS and EKS is the pricing model. With ECS, there is no additional charge for EC2 (Elastic Cloud Compute) launch types. Instead, users pay for AWS resources they create to store and run applications. You only pay for what you use, and there are no additional pricing concerns.
EKS’ pricing model includes the same conditions as ECS, but there are additional costs. Users pay $0.20/hour for each Amazon EKS cluster. This isn’t as bad as it sounds, though, as users can use a single cluster to run multiple applications by taking advantage of Kubernetes namespaces and IAM security.
Both ECS and EKS work with AWS Fargate, released late 2019. With this serverless compute engine, you pay only for the resources you need to run your containers — without worrying about choosing instances and scaling cluster capacity, potentially over-provisioning.
There can be arguments made in favor of both Amazon ECS and EKS with regards to security. Amazon ECS is deeply integrated with IAM, enabling customers to assign granular access permissions for each container and using IAM to restrict access to each service and delegate the resources that a container can access.
Although EKS does not have this same level of deep integration, IAM roles for service accounts close this gap considerably. When you associate an IAM role with a Kubernetes service account, containers in any pod using that service account can use those AWS permissions. Applications use an AWS software development kit (SDK) or command-line interface (CLI) to make API requests to authorized services.
ECS also integrates well with AWS Secrets Manager and AWS Systems Manager (SSM) Parameter Store. Simply reference parameters in your container definition to access secrets (or other sensitive information) stored in these services.
Although you can connect EKS with Secrets Manager, it requires third-party solutions such as kubernetes-external-secrets or the EKS controller solution Amazon described in April 2021. These solutions manage secrets exceedingly well, but do have a few more steps and more reliance on other services.
However, an argument for EKS is that it can support a much higher number of running pods (containers) per EC2 worker than ECS. This is due to the way it uses elastic network interfaces (ENIs). You can assign an ENI directly to a task in EC2 using the aws vpc network mode. The task has its own IP address and the same networking properties as EC2 instances. Each instance can support up to 120 tasks. In contrast, you can share ENIs between Kubernetes pods for up to 750 pods per instance. Additionally, the vast kubernetes ecosystem is vastly more flexible and powerful than the relatively prescriptive approach Amazon takes with ECS.
Since EKS is a Kubernetes-as-a-service offering for AWS, it can be ported to run on any Kubernetes infrastructure, or be part of a large federated cluster architecture. It’s easy to run on-premises or with a different service provider, especially with EKS Anywhere available in late 2021.
Although ECS previously ran exclusively on AWS, as of May 2021, ECS Anywhere now enables you to deploy ECS tasks on your own (or third-party) infrastructure. With the launch of ECS Anywhere and EKS Anywhere, compatibility with third-party infrastructure is less of a differentiating factor.
The Bigger Picture
Since Amazon ECS currently offers more in-depth AWS integration than Amazon EKS, it may be considered the advisable choice for straightforward container workloads if you’re looking to work solely in the AWS cloud. It is also far simpler for developers to learn, and has some rapid prototyping tools such as AWS Copilot. However, if you’re looking to run large microservices architectures, span deployments across multiple infrastructure providers, or need additional automation or flexibility provided by Kubernetes’ diverse toolsets, Amazon EKS offers more versatility with a much richer ecosystem of tools and resources.
Regardless of which solution you’re gravitating toward, Mission has expertise helping businesses transform their applications by leveraging both types of containerization technology. For more information about our containerization expertise, request a one-hour consultation with a Solutions Architect.