Introducing the AWS ECS technical series

Content

• Take aways
• Introduction
• Components
  • Cluster
  • Services
  • Task Definitions
  • Tasks
  • Elastic Container Registry - ECR
• Identity Access Management
  • Execution Role
  • Task Roles
• The Series
  1. Setting up AWS VPC
  2. Containerizing the application + AWS ECR
  3. Setting up the AWS ECS Infrastructure
  4. Setting up CI/CD with Github Actions
  5. Setting up blue-green canary with AWS Codedeploy

Take aways

AWS Elastic Container Service (ECS) is a great platform offered by AWS for managing and orchestrating your containerized solutions. It simplifies the way you build, deploy and scale your infrastructure because you are operating on containers.

The simplicity of ECS comes at the expense of flexibility. With ECS, you are working on the level of docker containers, the instance types and configuration options are quite narrow. On the plus side, it also mean less to worry about from a security point of view since there are less options.

So, if you have specific workloads that require optimization in network, memory, compute and storage (ie graphic processing, machine learning models) then ECS might not be a good fit (at least, at this time but it could change). You will have to consult the documentation and likely do some performance testing to see if it fits your requirements.

It is important to know what you are willing to trade off because each project is different. If you are a smaller team with one operations person, ECS might be an attractive option. Besides, you might not need all the flexibility that EC2 offers if you are just trying to ship a product and have it scale to X.

On the other hand, if you are a larger company with a dedicated operations teams, and there are existing in-house solutions available that need to be integrated on bare machines then the benefits might not be as enticing.

Furthermore, depending on the type of project and domain, you may have strict requirements for performance. There will be more limitations when it comes to fine tuning ECS to meet your needs.

Introduction

ECS is a container orchestration service which simplifies your infrastructure. The big idea is you are operating on the level of docker containers.

You describe to AWS ECS a “state” you want on a set of hosts (EC2 or Fargate) and the orchestrator figures out how to make that happen on a pool of resources.

Example:

40 copies of my containers distributed across 5 Availability Zones (AZS) and connected to this Application Load Balancer (ALB)

It works with your auto scaling group to scale in and out depending on the work loads. The way it handles this is via clustering, and as a bonus, it helps to solve the problem of having idle capacity that you might see in a traditional setup using EC2 with auto scaling.

ECS offers several configuration options out of the box, and that is done through the container definition file. This is something we will visit later.

ECS Supports both EC2 and Fargate. Fargate is AWS’s fully managed container service where AWS is responsible for everything below the container, and you handle everything above it via configurations.

This dramatically reduces the operational burden of building, deploying, securing and scaling your websites or web applications.

It can be very beneficial if you have a small team or just don’t have a dedicated DevOps team member available. You can spend more time focusing on the product rather than focusing on operating the infrastructure. Delegate the task that AWS excels at, which is infrastructure.

Trade offs

ECS does indeed make it very simple. However, the trade offs made here is the flexibility.

There are limitations around options available. Even though EC2 is supported by ECS, there are still limitation with the types EC2 instances that you can run.

Just be mindful of that if you do decide on using ECS. Be sure to ensure that it meets your performance requirements in network, compute and storage.

Every project requirement will vary, most projects may be fine with ECS but it is always best to benchmark in order to be sure there are no bottlenecks.

Components

ECS includes several components. They all serve a distinct purpose.

Cluster

This is a logical grouping of tasks or services. These are region specific and uses a variety of launch types (AWS Fargate, EC2, and external instances).

The ECS agent runs on here to ensure provides updates on the information within the containers on that machine. In addition, it will receive instructions to launch more containers if required.

Services

The service is part of the cluster and helps to manage the tasks within the cluster which are just docker containers.

This is where most of the granular configurations occur:

• launch types (ie EC2, Fargate)
• load balancers
• network configurations (VPC)
• desired number of tasks to maintain
• and many more options

Task definitions

These are specific instructions to run the tasks within a service.

The options include and are not limited to:

• container image
• cpu
• memory
• port mapping
• environment variables
• logging
• task role arn
• execution role role arn
• Secrets (from SSM)
• and many more options

All configuration options are “app” specific configurations.

Tasks

These are just set of tasks that run within a service using the provided task definitions. Each task has a specific version of the task definition so if it gets updated, it will not change the existing service unless a new deployment is initialized.

Elastic container registry

Technically not part of the ECS but it is tightly integrated into the AWS container offerings. This offers a private registry to deploy docker images to.

It uses AWS IAM to manage the permissions. So, you need to ensure your resources has the proper permissions to manage ECR (put and get images). Other than that, everything is exactly the same within the docker registry development and release workflow.

We will go deeper into this later when we start building out the infrastructure.

Identity Access Management

The IAM or Identity Access Management of ECS can be broken into two distinct categories. They are the execution role and the task role.

1. Execution Role

This is the IAM role attach to your services which enables the “management” of your tasks.

These actions mostly include the management of ECS/ECR related tasks (getting new images, storage of logs in AWS Cloudwatch).

2. Task roles

This is the IAM role attach to your tasks which enables them to interact with other AWS services.

These actions may include being able to access to S3 bucket or a database (DynamoDB, RDS etc.).

The Series

In the technical series, we will be building out our infrastructure from scratch using terraform and AWS from VPC to AWS ECS and the whole CI/CD using github actions.

At the end of the series, you should have a fully functional AWS ECS pipeline built using Infrastructure as Code (IaC) that is enough for production. You may need to fine tune a few things but it should be pretty much there!

This series will be broken up into several posts or modules so it is more digestable:

1. AWS ECS - Setting up VPC

Module 1: AWS ECS technical series part I

In this module, we will be building out our own Virtual Private Cloud (VPC) network. This is where all our AWS resources (ECS) will live.

2. AWS ECS - Containerizing the application + AWS ECR (for CI/CD)

Module 2: AWS ECS technical series part II

In this module, we will start containerizing our application using docker in preparation for continuous integration.

Before we automate it, we will be manually going through the steps so we can build a good mental map of what goes on in these custom Github Actions.

Likewise, we will be setting up the AWS ECR and IAM required for the continuous integration pipeline.

3. AWS ECS - Setting up the AWS ECS Infrastructure

Module 3: AWS ECS technical series part III

In this module, we will be setting up the AWS ECS infrastructure. This includes the AWS ECS clusters and task definitions.

4. AWS ECS - Setting up CI/CD with github actions

Module 4: AWS ECS technical series part IV

In this module, we will start building out the automated pipeline to update to a new version of our application with code changes.

This will include uploading our new container image to AWS ECR, updating the task definitions, and triggering a deployment of a new ECS “task” within our cluster and service.

5. AWS ECS - Setting up continuous delivery (CD) with blue-green canary deployment + automatic rollback (BONUS)

Module 5: AWS ECS technical series part V

In this module, we will enhance our pipeline by adding safety into our delivery process in the fully automated process.

We will be using a blue-green canary release where we roll out a percent (25% in our example) of the containers using the new version while the rest remains on the existing version.

This will allow us to “test the waters” on the new version of our application for a certain period of time.

The load balancer will handle the traffic shifting between the two versions, and after a certain time has passed, it will roll over to the new version (if all metrics look healthy).

Configuration:

Time Interval: 10 minutes (2-3 alarm periods)
Percentage: 25%

Finally, this setup will include automatic rollback trigger based on cloudwatch alarm thresholds during release. This way we can reduce service downtime and/or disruptions when errors do occur. The best part about all of this is that the whole process is automated, no manual step involved!

Conclusion

AWS ECS is an interesting technology that allows you to simplify your infrastructure and digital operations. However, just be mindful that by using ECS you are trading off flexibility in the configuration options of storage, compute and network.

As for the series, this will be the first of of many posts of diving deep into AWS ECS where we build out real life system with CI/CD. So, Stay tuned!