Tag Archives: Why and where to use ECS

Amazon ECS basics

Amazon ECS basics for beginners

An article about Amazon ECS foundational topics for beginners

ECS basics.

Amazon ECS stands for Amazon Elastic Container Service. We will walk you through ECS bit by bit to help you understand what is ECS. We will touch base below topics –

  • What is ECS?
  • Use cases for ECS
  • ECS component concepts
  • Pricing

What is ECS?

Amazon ECS is a fully managed container orchestration service. It aimed to do all the heavy lifting of managing container orchestration clusters for customers while customers can focus on developing their containerized application.

If you are new to containers, please read our container articles –

In a nutshell, ECS is Amazon’s own homegrown container orchestration service. If you have learned about Docker Swarm then consider ECS as Amazon’s version of Swarm to manage your containers.

Browse through KernelTalk’s Amazon ECS articles.

Amazon ECS deep dive!

Amazon’s other service ‘Elastic Beanstalk’ actually using ECS in the background to spin up clusters of containers running your desired applications.

Where to use ECS?

In this section, we will see the use cases of Amazon ECS. This service sees uses cases mainly in two sectors:

Microservices

Application following microservices architecture approach can make most of ECS! The Microservices approach aims at decoupling the design so that architecture is failure-proof, can be scaled at the service level, etc. These benefits can be leveraged using containers! Containers can be spun using immutable images, tested locally, scaled using ECS clusters, each service can be defined using different tasks, and pipelined using CI/CD.

Batch Jobs

Since containers are easy, quick to spin up, and terminate they are perfect for running batch jobs. Using containers you can cut down your time to spin up EC2 instances for processing jobs, save time for their terminations, get away with the huge billing associated with them. And all of this can be well managed by AWS in the backend when you spin your containers using ECS. Fargate launch type in ECS is well suited for batch jobs since it doesn’t require to spin us even EC2 container instances. It’s like serverless and you pay for the resources you used and the time you used them.

ECS concepts

With a little bit of foundation let’s dive into a few ECS concepts. While using ECS you will come across the below terms –

  • Clusters
  • Container Instance
  • Task definitions
  • Launch types
  • Services
  • Amazon ECR
Cluster

Cluster is a grouping of tasks and/or services. These tasks/services are run on container instances (in case of EC2 launch types), in that case, EC2 container instances also come under this logical grouping called a cluster. You can have one or more clusters in your account.

Container instance

When you are running a task/service using the EC2 launch type, it will run on EC2 instances. These instances (Linux/Windows) are created when you are creating clusters. Basically, those are normal EC2 instances with docker software, ECS agent preinstalled. You can even connect to them like any other EC2 instances using SSH or RDP. You can view them in the EC2 dashboard of your account as well. Under ECS those will be referred to as container instances.

Tasks definitions

Task definitions are a collection of settings required to run a container in the Amazon ECS cluster. It has numerous parameters that you can configure including container definitions as well. The core of the task definition is container definition and launch type, where you define how your container should be instantiated. In short, you can visualize it as a container Dockerfile.

Launch types

It’s a type of compute on which containers should be instantiated. Amazon offers 2 launch types –

  1. EC2 Launch type
    • Runs containers on cluster container instances
    • You will be billed for EC2 instances, not the container runtimes
  2. Fargate types
    • Runs containers on serverless/managed infra in the backend
    • You will be billed on the number of resources used and for the duration, they are used
Services

Services are the schedulers that are responsible to maintain the desired number of containers of running tasks in a cluster. So container instantiation and termination to match the given conditions is done by services.

Amazon ECR

It’s Amazon Elastic Container Registry. It’s your own private container registry hosted on AWS. You can use IAM authentications to control the access to ECR and it can be connected to various apps for CI/CD purposes. Container definitions under tasks can refer to ECR images securely.

Pricing

ECS is a free service just like cloudformation! You will be billed only for the resources you deployed/used for using ECS.

When creating clusters, the container instance type should be selected. As I explained earlier these are normal EC2 instances that can be viewed in the EC2 dashboard as well. So they will be billed like any other EC2 instances (instance types and time for which they are running).

Another billing you can incur is when running containers on fargate launch type. It’s considered as pretty costly than the EC2 launch type and hence should be used only for short-running tasks. You will be billed for the number of resources you are using and the duration for which they are being used.

If you are leveraging ECR to maintain your own private container image repository then ECR charges will be applied to your account as well. ECR charges include two components :

  1. Storage. Billed for total storage being used by all of the images
  2. Data transfer. Data in and out bills i.e. data transferred from/to ECR during image pull/push operations

Conclusion

That’s pretty much about ECS basics. So, if you are working on a self-hosted container environment, it’s time to move to ECS and let AWS manage the stuff for you while you can concentrate on developing apps in containers!