AWS Container and Kubernetes Services

The following is the summary of the various features/capabilities of ECS:

The Control Plane if fully managed by AWS
Support for both Linux and Windows
An ECS Task is an instance of a running docker container
An ECS task is configured using a Task Definition which is a blueprint for launching a docker container application
An ECS Service defines how to run the ECS tasks and has the following features:
- Control how to perform Auto Scaling to maintain a desired count of ECS tasks
- For attaching a Load Balancer
An ECS Cluster is a logical grouping of ECS services or tasks
Launching a docker container on ECS is actually launching ECS tasks on the ECS cluster
An ECS cluster can run across Availability Zones in a Region
AWS manages the lifecycle of starting/stopping the ECS tasks
One can attach an Application Load Balancer (ALB) or Network Load Balancer (NLB) in front of ECS tasks

An ECS Launch Type defines the type of environment to run the ECS tasks on. The following are the two ECS Launch Types:

EC2 Launch Type

Leverages customer provisioned and managed EC2 Instances
An ECS Container Instance is an EC2 Instance that includes an ECS Container Agent
An ECS Container Agent exposes APIs for gathering details about the container instance on which the container agent is running and the associated tasks running on that container instance
The ECS container agent is include in the Amazon ECS Optimized AMI
The ECS container instance can be either On-Demand or Spot EC2 Instances
Charges are based on per running ECS container instance

Fargate Launch Type

There is NO need to provision/maintain infrastructure and is a fully managed serverless environment
ECS Tasks are allocated a minimum of 20 GiB of free ephemeral storage
Can be attached ONLY to a single Instance
The customer just creates task definitions and AWS will run the ECS tasks based on the CPU/RAM requirements
Charges are based on per running ECS task

The following are some features on the IAM Roles based on the ECS launch type:

EC2 Launch Type

One needs to assign an IAM Instance Role to the ECS container instance which provides permissions for the EC2 instance
One needs to assign an IAM Task Role to the ECS task which provides permissions to the task

Fargate Launch Type

One needs to ONLY assign an IAM Task Role to the ECS task which provides permissions to the task

NOTE :: IAM task roles are defined in the ECS task definition.

The following are some features on the two categories of ECS Auto Scaling:

ECS Service Auto Scaling

Automatically adjusts the desired ECS task count up or down using CloudWatch Metrics to trigger the application auto scaling
Target Tracking - scale based on the target value for specific CloudWatch metrics
Step Scaling - scale based on the specified CloudWaych Alarm
Scheduled Scaling - scale based on based on specific date/time

ECS Cluster Auto Scaling

Automatically adjusts the number of ECS container instances using the CloudWatch Metrics that measure the utilization of the underlying EC2 Instances to trigger the EC2 Auto Scaling Group

For EC2 Launch Type, one needs to define BOTH the ECS service auto scaling AND ECS cluster auto scaling.

Fargate Launch Type ONLY needs the ECS service auto scaling.

The following are some features on ECR:

Supports Open Container Initiative (OCI) and Docker Registry HTTP API v2 standards
Container images and artifacts are stored in AWS S3
One can use Namespaces to organize repositories
Supports both private and public repositories
A private repository for customer container images is not publicly accessible and controlled via either IAM Access Control or Resource-based Policies
The Lifecycle Policies allow one to manage the lifecycle of the container images in a repository
The Image Scanning option allows one to identify software vulnerabilities in the customer container images
One can enable Cross-Region and Cross-Account replication for container image replication

The following are some features on EKS:

Kubernetes is an open-source container orchestration system for automatic depoloyment, scaling, and management of containerized applications
Kubernetes is cloud agnostic and can be used on any cloud provider OR on-prem
One can use Namespaces to organize repositories
With EKS one can manage Kubernetes clusters and applications in a hybrid deployment between AWS and on-prem
One can use EKS cluster with Kubernetes Jobs API to run sequential or parallel batch workloads
One can use Kubeflow with EKS to model Machine Learning workflows and efficiently run distributed training jobs using the latest EC2 GPU-powered Instances
One can also deploy web applications that automatically scale up and down across multiple Availability Zones in a Region
EKS has two types of launch environments - EC2 for deploying Worker Nodes and Fargate to deploy serverless containers
EKS Pods is where the containers are run
A EKS Worker Node is a grouping of EKS pods
An EKS Cluster consists of an EKS Control Plane and a group of EKS worker nodes

The following are some features on the two categories EC2 Launch Types (both of which allow the use of On-Demand and Spot Instances) for an EKS worker node managed by an Auto Scaling Group:

The following are some features of the two categories of EKS Cluster Auto Scaling:

Vertical Pod Autoscaler - automatically adjusts the CPU and Memory reservations for the EKS pods to right-size the applications
Horizontal Pod Autoscaler - automatically scales the number of EKS pods in the Replica Set based on the resource CPU utilization

Supports both the Application Load Balancer (ALB) and Network Load Balancer (NLB)
AWS Load Balancer Controller manages the Load Balancers for the EKS Cluster, which can be installed using Helm V3 or later
The Load Balancer Controller provisions an ALB when one creates a Kubernetes Ingress type
The Load Balancer Controller provisions a NLB when one creates a Kubernetes LoadBalancer type