Going cloud-native and choosing AWS as your cloud platform is an important decision. Once you’ve set your mind to that path, the next step is to select the right managed services for your infrastructure. If you’re implementing a microservice approach on AWS, there are multiple options for hosting your containerized services. Here is a high-level overview of ECS, Fargate, and EKS and tips for choosing the best container orchestration option for your organization.
Elastic Container Service (ECS)
ECS is the most AWS specific managed container hosting environment offered. If your infrastructure is already built on EC2 and you have defined your own auto-scaling capabilities, ECS may be a more natural migration for you.
Overview
ECS utilizes EC2 underneath to power its compute resources. The EC2 instances are deployed and managed within your AWS resources and registered to an ECS Cluster that you define.
The ECS Cluster can be set up in an already existing VPC, taking advantage of the AWS infrastructure you may have in place, and manages the deployment of containers to the EC2 instances. The metadata specifying how a container is deployed and runs corresponds to an ECS Task.
ECS Tasks detail the repository for the docker image, port mappings, environment variables, and volumes to attach. Most everything used in a command line run from Docker will be mapped to the Task definition.
Once your Tasks are defined, ECS Services detail the auto-scaling nature of the Tasks. If a Task is stopped, the corresponding ECS Service can restart the Task or launch a new instance to replace it.
Fargate
ECS has two launch types that can define how the compute resources will be managed. The traditional EC2 launch type detailed in the overview above utilizes your own EC2 instances. Fargate removes the responsibility of provisioning, configuring and managing the EC2 instances by allowing AWS to manage the EC2 instances.
Fargate eliminates the need to manage servers, but also puts a requirement of your Task definitions to be stateless. Currently, no volumes can be attached to the containers defined in your Tasks which eliminates some types of containers (such as datastores requiring persistent storage) to be able to run in the ECS environment.
Why use it?
ECS EC2 (traditional)
- You are all-in on AWS
- You have an existing AWS footprint such as an already defined VPC and subnets, processes for provisioning and managing EC2 instances
- You have an Ops team in place to manage AWS resources
ECS Fargate
- You are mostly utilizing AWS and may or may not have an existing VPC
- You may or may not be currently utilizing ECS and do not want or are looking to reduce your operations responsibility on AWS
- Your applications are stateless or manage state through S3, RDS or other external services from your containers.
Elastic Container Service for Kubernetes (EKS)
EKS is the managed Kubernetes hosting environment supported by AWS. If you are already using an on-premise or cloud provided host for Kubernetes, or are looking to utilize a defacto industry standard for open source orchestration of containers, EKS can provide many benefits of Kubernetes without the operations responsibility of hosting and configuring the Kubernetes environment.
Overview
EKS utilizes EC2 instances that are specifically defined by AWS to be Kubernetes Nodes. The Nodes are registered with an AWS managed Kubernetes Control Plane which is all defined within your EKS Cluster. When you are defining your EKS Cluster, the VAC used must conform to RFC 1918.
Once your EKS Cluster is configured, the management, monitoring, and deployment of infrastructure will move away from the custom AWS specific processes to the open source Kubernetes processes. For example, a majority of the configuration of your cluster and monitoring of your pods will be handled by the Kubernetes command line, kubectl.
Why use it?
- You are utilizing AWS but want to keep your infrastructure portable for other cloud providers
- You want to utilize the most flexible and future-proof managed container environment
- You want to ensure open source tools are used as much as possible
- You want developers and operations to be able to determine how containers are managed
If you’ve chosen a cloud-native microservices approach, selected your platform, and are all in on containers, one of the first decisions you’ll run into is what to use for orchestration. Contact us for recommendations that are best suited to your team, infrastructure, and business needs.
