DEV Community

Cover image for Amazon Elastic Container Service (ECS)- Practical Guide πŸš€πŸš€(Cheat Sheet)
Tanmay Shukla
Tanmay Shukla

Posted on • Edited on

Amazon Elastic Container Service (ECS)- Practical Guide πŸš€πŸš€(Cheat Sheet)

Amazon Elastic Container Service is a highly scalable, fast, container management service that makes it easy to run, stop and manage docker containers on a cluster of amazon EC2 instances.

  • It let's you launch and stop contianer-enabled applications with simple API calls, that allows us to get the state of our cluster from a centralized service, and gives us access to many familiar EC2 features.
  • Through ECS we can schedule the placement of containers across our cluster based on resource needs, isolation policies, and availability requirements.
  • ECS eliminates the need for you to operate you own cluster (management) and configuration management or even worry about scaling your management infrastructure.
  • ECS also has integration with the Application Load balancer to expose your service to the world.

ECS has two launch types:

1. Amazon ECS - EC2 launch Type:
Image 2

  • ECS = Elastic Container Service
  • Launch Docker containers on AWS = Launch ECS Tasks on ECS Clusters
  • EC2 Launch Type: you must provision & maintain the infrastructure (the EC2 instances)
  • Each EC2 Instance must run the ECS Agent to register in the ECS Cluster
  • AWS takes care of starting / stopping containers.

2. Amazon ECS - Fargate Launch Type:
Image 2

  • Launch Docker containers on AWS.
  • We do Not have to provision the infrastructure(EC2 instances), which makes it simpler and easy to use!
  • It's all Serverless.
  • AWS runs the contaiers for us based on the CPU/RAM we need.
  • We just create task definitions. Then the fargate service will launch the task and there is no need to create EC2 instance beforehand(which makes it lot easier).
  • To access this fargate tasks, we're going to have elastic network interfaces(ENI) that are also going to launched within our VPC to bind this task to a network IP. So, the more tasks we have, more ENI's(distinct and private IP; so make sure we have enough IP addresses in our VPC) will be created and they are going to be unique for all of these tasks. Image 3
  • To scale, we just need to increase the number of tasks. Much simpler than EC2 instances.

🚩🚩🚩 Note: All these ECS Tasks will maybe perform some operations on you AWS services. For example they may need to interact with DynamoDB or S3, so therefore they need IAM roles. So lets look at IAM roles for ECS tasks now.

IAM Roles for ECS Tasks

  • EC2 Instance Profile (EC2 Launch Type only):

    • Used by the ECS agent
    • Makes API calls to ECS service
    • Send container logs to CloudWatch Logs
    • Pull Docker image from ECR
    • Reference sensitive data in Secrets Manager or SSM Parameter Store. Image 4
  • ECS Task Role:

    • When you create a task you attach task role to it.
    • Tasks Role is defined in the task defintion.
    • It Allows each task to have a specific role. While it's also advisable to create new ECS task role for new task, as it ensures better security when accessing services.
    • That's why we use different roles for the different ECS Services we run.
    • As its a much better separation of security & you have as many task roles as different types of tasks.

🚩🚩🚩 Note: You can question like how these services share data? It's much more complex topic that you think so I'll cover this in another blog but for now let take a high level understanding.

ECS Data Volumes:

  • ECS has an integration with the EFS(Elastics file system) which is a NFS(network file sysytem). Image 6
  • If we have an EC2 instance and multiple tasks running, it is possible to create an EFS file system and to mount the file system directly onto these ECS tasks. - It works for both EC2 Tasks and Fargate tasks.
  • Tasks launched in any AZ will be able to share same data in the EFS volume.
  • With the combination of Fargate + EFS we get truly serverless offering (i.e. serverless, data storage without managing servers)
  • The main Usecase is during persistent multi-AZ shared storage for your containers.

Connect with me

Top comments (0)