# Productionizing AWS ECS for production container workloads

DevFeed: [Productionizing AWS ECS for production container workloads](<https://devfeed.tech/articles/productionalizing-ecs-26524.md>)

Original publisher: [Read original article](<http://engineering.curalate.com/2018/05/16/productionalizing-ecs.html>)

Author: Anton Kropp was a Software Engineer

Published: 2018-05-16T09:45:39Z

Content type: tutorial

Language: en

Sources: [Curalate](<https://devfeed.tech/sources/curalate.md>)

Topics: [Containers](<https://devfeed.tech/topics/containers.md>), [Amazon Web Services](<https://devfeed.tech/topics/aws.md>), [Amazon EC2](<https://devfeed.tech/topics/amazon-ec2.md>), [Docker](<https://devfeed.tech/topics/docker.md>), [Monitoring](<https://devfeed.tech/topics/monitoring.md>)

Tags: [aws](<https://devfeed.tech/tags/aws.md>), [containers](<https://devfeed.tech/tags/containers.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [docker](<https://devfeed.tech/tags/docker.md>), [ec2](<https://devfeed.tech/tags/ec2.md>), [ecs](<https://devfeed.tech/tags/ecs.md>), [monitoring](<https://devfeed.tech/tags/monitoring.md>)

## AI overview

This engineering article describes a company's migration from AMI-based virtual machines to AWS ECS containers and the challenges of making ECS production-ready. It covers cluster scaling, cluster image upgrades, container monitoring, cleanup of container artifacts, and remote debugging of JVM processes.

## Source excerpt

In January of last year we decided as a company to move towards containerization and began a migration to move onto AWS ECS. We pushed to move to containers, and off of AMI based VM deployments, in order to speed up our deployments, simplify our build tooling (since it only has to work on containers), get the benefits of being able to run our production code in a sandbox even locally on our dev machines (something you can't really do easily with AMI's), and lower our costs by getting more out of the resources we're already paying for. However, making ECS production ready was actually quite the challenge. In this post I'll discuss: Scaling the underlying ECS cluster Upgrading the backing cluster images Monitoring our containers Cleanup of images, container artifacts Remote debugging of our JVM processes Which is a short summary of the things we encountered and our solutions, finally making ECS a set it and forget it system. Scaling the cluster The first thing we struggled with was how to scale our cluster. ECS is a container orchestrator, analogous to Kubernetes or Rancher, but you still need to have a set of EC2 machines to run as a cluster. The machines all need to have the ECS Docker agent installed on it and ECS doesn't provide a way to automatically scale and manage your cluster for you. While this has changed recently with the announcement of Fargate, Fargate's pricing makes it cost prohibitive for organizations with a lot of containers. The general recommendation that AWS gave with ECS was to scale based on CPU reservation limit OR memory limit. There's no clear way to scale with a combination of the two, since auto scaling rules need to apply to a single CloudWatch metric or you face potential thrashing. Our first attempt on scaling was to try and scale on container placement failures. ECS logs a message when containers are unable to be placed due to constraints (not enough memory on the cluster, or not enough CPU reservation left), but there is no way to act