Which service should you choose to manage your containers on AWS?
This is a concern that we frequently address with our clients when building new infrastructure, migrating to AWS, or even optimizing existing infrastructure for cloud-native technologies. Indeed, AWS customers have the choice between ECS Amazon Elastic Container Service and EKS Elastic Container Service for Kubernetes.
The objective of this article is to introduce you to these two services and their modes of execution, in order to give you some keys to determine when you should use one or the other of these options.
Container orchestration on AWS
Amazon Elastic Container Service (ECS) is the service designed by AWS for container orchestration. It is designed to simplify the management of containerized applications. With ECS, you can easily deploy, run, manage and scale your applications.
ECS is a reliable and secure solution, and many AWS services are based on ECS. As it is a native AWS solution, it can be easily integrated into your AWS infrastructure. AWS customers recognize ECS for its ease of management and its seamless integration with the AWS environment.
Amazon EKS is a managed service that allows you to run Kubernetes on AWS. Kubernetes is the most widely used open source container orchestration system for deploying and managing containerised applications at scale today. Kubernetes is praised for its community, ecosystem, abundance of open source APIs, and service flexibility.
With its principle of portability, Kubernetes is a very interesting solution for avoiding "vendor lock-in" with a cloud provider or for hybrid and multi-cloud environments.
So, the choice between ECS and EKS is rather strategic than technological, simplicity VS flexibility.
A quick aside on the vendor lock-in issue : it is theoretically easier to migrate from one cloud to another with Kubernetes; in reality, a migration will always require some effort. However, you should not forget to take into account the technical skills of your team !
Kubernetes is a solution with many advantages, but before you can use it to its full potential, you will need to master a number of concepts that are sometimes rather abstract: Pod, Node, Service, Selector, Endpoint, etc. The need to master and implement these concepts should not be underestimated.
In summary, your choice can be made on the following elements:
- Operational preferences
- Requirement of your environment
- Technical skills
Execution mode on AWS
With Amazon EKS and Amazon ECS, AWS offers different execution modes for container jobs. Let's take a closer look at EC2 and Fargate modes.
EC2 mode means that you have full control over the underlying EC2 instances. This means that you can configure your infrastructure to match your needs (such as choosing instances that are optimized for networking or GPU). On the other hand, it also means that you are responsible for instance selection, network, security configurations, and upgrades.
AWS Fargate applies the serverless model to container orchestration and allows you to run containerised applications without having to manage a cluster of instances.
The Fargate service allows you to abstract the need to provision and manage the servers on which container jobs are run. Fargate enables faster implementation and simplified management of container jobs. In addition, with Fargate you only pay for the resources needed to run your containers.
In short, Fargate simplifies infrastructure administration while EC2 mode gives you more control over your infrastructure.
Nevertheless, using Fargate comes at a price. Here is an example of a comparison between a T3 medium EC2 instance that by default stays "on" and its equivalent with Fargate for a task that would run continuously.
Fargate and EC2 respond to different needs, however, you are not obligated to choose one over the other. You can have a mixed fleet and combine EC2 and Fargate modes. So, for example, you could have a baseline with EC2 compute and Fargate would come in as an “add-on” to your scaling strategy.
Furthermore, we recommend using Fargate in the following cases:
- For short and periodic jobs (like crons)
- For certain jobs for which Lambda would not be adequate.
- If you only want to use managed services.