Introduction

In this post we'll take a look at ECS vs other Amazon Compute models and some key concepts in Amazon ECS.

ECS is a widely used container platform; here are the numbers previously shared by Amazon about ECS at re:Invent:

• Over 2.25 billion tasks are launched every week
• Tens of thousands of API requests are served per second
• ECS runs in 30 AWS regions, 6 continents
• 65% of all new AWS containers customers use Amazon ECS

ECS vs Other Amazon Compute Models

Amazon Web Services (AWS) operates on a shared responsibility model, where the cloud service provider, Amazon, manages certain components of the cloud infrastructure, while users are responsible for managing other specific aspects. The degree of user involvement varies based on the compute model selected. Here, we explore four of Amazon's compute models, ranked from the most to the least user effort required.

1. Amazon EC2 (Elastic Compute Cloud)
   • Flexibility and User Responsibility: EC2 offers high flexibility, allowing users to quickly provision virtual machines (VMs) and integrate them into networks. While Amazon provides a range of features, users are responsible for:
     • System patching
     • Security management
     • Connecting to appropriate load balancers
     • Performing similar maintenance tasks
   • EC2 is best suited for applications that require detailed, custom configurations.
2. Amazon ECS (Elastic Container Service) and EKS (Elastic Kubernetes Service)
   • Container Orchestration Platforms:
     • ECS: Amazon's native container orchestration service that supports both EC2-backed clusters and serverless container clusters. It simplifies running containers at scale.
     • EKS: Amazon's managed Kubernetes service, offering automated Kubernetes management.
   • Users can choose to run ECS on:some text
     • Traditional EC2 instances
     • Serverless infrastructures via AWS Fargate
   • Responsibilities in ECS and EKS primarily involve configuration and scaling decisions.
3. AWS Fargate
   • Serverless Container Execution: Fargate enables users to run containers without managing servers or clusters. This model abstracts the underlying server and infrastructure management, focusing user effort on:
     • Container configuration
     • Application scaling
   • Fargate integrates with both ECS and EKS, simplifying deployments and management of containers in a serverless environment.
4. AWS Lambda
   • Lowest Management Overhead: Lambda represents the pinnacle of AWS's serverless offerings, requiring minimal user management. It automatically handles:
     • Scaling
     • Infrastructure maintenance
     • Performance optimization
   • Users are primarily responsible for code deployment and setting the function's triggers.

The table below covers what AWS and you are expected to manage in each of the four models:

So if you look across all these compute models, they all expect development teams to still manage a number of tasks. Questions you are faced with can include: 

• What version of code are you deploying?
• What's your compute profile?
• What's your horizontal compute profile?
• How does your application react to different seasonality patterns?

So there are a lot of challenges that application teams face when they manage their applications.

The Three Layers of AWS ECS

Amazon Elastic Container Service (ECS) is designed to facilitate scalable and efficient container orchestration. Here's a brief overview of its three core layers:

1. Provisioning Layer
   • Methods for Provisioning ECS Clusters: AWS offers multiple approaches including the AWS CLI, Infrastructure as Code (IAC) with AWS CloudFormation, AWS Cloud Development Kit (CDK), and Terraform. These tools cater to different development preferences and operational requirements.
2. Controller Layer
   • Container Scheduler: Central to ECS, this fully managed scheduler handles container placement, lifecycle management, and auto-scaling, optimizing resource use and application performance.
3. Capacity Layer
   • Flexible Capacity Options: ECS supports various environments:some text
     • ECS on EC2: Customizable capacity using EC2 instances.
     • AWS Fargate: Serverless container execution without managing servers.
     • ECS Anywhere: Run ECS on external or on-premises environments.
     • AWS Outposts: Extend AWS infrastructure and services to any data center for a consistent hybrid experience.

Key Concepts in Amazon ECS

Amazon Elastic Container Service (ECS) offers a powerful solution for orchestrating containerized tasks and services. To grasp its core concepts and functionalities, let's delve into the fundamental components that make up ECS:

• Clusters play a pivotal role in ECS. Essentially, a cluster serves as a logical grouping mechanism for tasks, services, and container instances. In the context of ECS, a cluster can represent a collection of tasks or services utilizing the EC2 launch type, or it can also denote a logical grouping of capacity providers if you leverage them. By default, ECS creates a cluster for you upon initial use, but you have the flexibility to create multiple clusters within your account to maintain resource segregation effectively.
• Container instances are crucial building blocks within ECS. These instances refer to EC2 instances that run the ECS container agent and have been successfully registered with a specific ECS cluster. When you execute tasks using the EC2 launch type or leverage an Auto Scaling group capacity provider, ECS strategically places your tasks onto active container instances, ensuring seamless execution within your environment.
• Tasks and task definitions form the core entities within ECS. A task represents the live instantiation of a specific task definition, running either on a container instance or within the broader AWS ecosystem. Task definitions, on the other hand, serve as blueprints for your tasks, encompassing essential details such as task names, revisions, container definitions, volume information, and more. They act as comprehensive guidelines for ECS to understand the precise configuration and requirements of your tasks. Each task can have one or more containers, such as an app container. You may have an agent or a logging agent running with it. Or you might run containers as a single container application.
• ECS services empower you to maintain and manage a predetermined number of task instances based on your task definition. By utilizing ECS services, you can ensure a specified number of instances are consistently running within your ECS cluster. Should any task fail, the ECS service scheduler promptly launches a replacement task, guaranteeing the desired number of tasks is maintained for the service at all times.
  
  

As shown below, ECS tasks are deployed as Services that can be horizontally scaled. And if it's EC2-based you deploy it on a cluster to access sufficient EC2 capacity. If it's Fargate, it's simpler - Fargate resources are used, and you don’t need to worry about the additional complications of EC2.

Choosing EC2 or Fargate Launch Types

When choosing a launch type for deploying applications on Amazon Elastic Container Service (ECS), it's crucial to understand the differences between the available options—EC2 and Fargate.

EC2 provides granular control over your instances and is cost-effective for predictable workloads, requiring manual setup and scaling. In contrast, Fargate offers a simplified, serverless experience with automated scaling, making it ideal for unpredictable workloads and minimizing operational overhead. 

Below is a detailed comparison table that lays out these differences, helping you decide which launch type aligns best with your specific application needs and operational strategy.

AWS notes that while the headline costs of Fargate are more than EC2, there are less obvious costs to consider in deciding on the best model including system administration, security and compliance and scaling as shown below.

‍

‍