Furthering Elasticity with Automatic Scaling for Amazon ECS

Amazon announced its Elastic Container Service (ECS) at re:Invent 2014 using Pristine as a case study. Given Flux7’s Amazon expertise, it’s likely no surprise to frequent readers of this blog that Pristine is a Flux7 customer who we have been working with for some time now.


While containers can run natively on VMs and it is possible to either fix the container to VM mapping or write home grown scripts to schedule containers on VMs, Docker orchestration engines including Kuberenetes, Swarm, and ECS provide a strong foundation for Docker projects. Of these, ECS is a very popular choice for our customers wanting to use Docker in AWS.

When creating ECS clusters for clients, our AWS consultants are commonly asked if they can leverage AWS auto-scaling, a hallmark use case of the elasticity that the cloud provides. However, until recenty, it was only possible to auto-scale the actual resources in the cluster; individual services had to be scaled manually or using home grown code.

Announcing Auto-Scaling of ECS Services

With this announcement however, AWS has introduced a new feature which allows auto-scaling of ECS services. Note that auto-scaling was already possible for ECS clusters where more nodes could be added to the ECS cluster. Now, Amazon ECS can automatically scale container-based applications by dynamically growing and shrinking the number of tasks (containers) run by an Amazon ECS service.

This new feature can increase the number of actual containers assigned to a single service based on dynamically collected metrics — such as the number of access queries to the service or the resource utilization of the containers constituting the service. In the past, ECS users used to get a basic form of auto-scaling implemented using AWS Lambda functions outline here https://aws.amazon.com/blogs/compute/scaling-amazon-ecs-services-automatically-using-amazon-cloudwatch-and-aws-lambda/. In summary, the Lambda functions query different metrics about an ECS service and use the ECS API to modify the number of containers in a service based on coded rules. While this solution was a good start, a managed and well-supported solution really is a must-have, and is a feature many people expected. So much so that since the announcement last week, we’ve seen a large number of our customers — and ECS users more broadly — really excited to take active advantage of it.

ECS and Microservices

In the experience of our AWS architecture experts, ECS is a great enabler for companies looking for an AWS-based microservices architecture. It allows for a very quick setup of a cluster which enables developers to create microservices, especially HTTP-based services. These services can be internal and public facing and there is a very simple path to implementing Continuous Integration and Continuous Delivery.

Using ECS, our AWS consultants have built both blue-green and rolling update solutions within a matter of days, if not hours. We expect nearly all those using ECS for RESTful services to benefit from the newly announced ECS auto-scaling service, especially one of our clients who is a Fortune 1000 retailer. They engaged our consultants to help them implement an ECS cluster to support SAP Hybris. While the project was nearly complete, one of our last goals before we marked it production ready was to add auto-scaling. Rather than pursue the original plan — implementing it in-house — our experts will now use the new Amazon auto-scaling feature. Time permitting, we will share the results to the community via this blog as this project unfolds.

Are you exploring the use of Docker on AWS, Docker at large, ECS, or microservices architectures? If so, contact us today and we’d be happy to share our expertise and assess how these technologies can specifically benefit your organization.

Did you find this useful? 

Interested in getting tips, best practices and commentary delivered regularly? Click the button below to sign up for our blog and set your topic and frequency preferences.