More than 25 SSL certificates with ECS

Andreas Wittig – 05 Jun 2019

Both the Application Load Balancer (ALB) and the Network Load Balancer (NLB) provide TLS/HTTPS listeners allowing you to encrypt the data in transit from the clients to your cloud infrastructure. Together, with the Amazon Certificate Manager (ACM) which provides public SSL certificates for free with little operational effort, AWS is doing a great job to make the Internet a safer place.

Encryption of data-in-transig

However, there is an annoying limitation: the combination of the Amazon Elastic Container Service (ECS) and ALB/NLB does not support more than 25 certificates per ECS service. Which typically limits the maximum number of public domain names per ECS service to 25 as well.

Why is that? Each load balancer supports no more than 25 certificates. On top of that, the Amazon Elastic Container Service (ECS) does only allow registering a container (task) at a single load balancer.

A side note: I’ve asked the AWS support to increase the limit of 25 certificates per load balancer. But AWS rejected my request, and I don’t understand why. I cannot think of a technical limitation. Please let me know if you know or can think of the reason for the hard limit of 25 certificates per load balancer.

So what to do if you need more than 25 certificates to encrypt the data in transit to your ECS service?

Of course, you can decide not to use the ALB/NLB and operate your own load balancer instead. For example, HTTPS at Jimdo describes a possible solution. Besides, you might want to check out lua-resty-auto-ssl , a plugin for NGINX. Or Traefik which integrates Let’s Encrypt & Docker.

Cover of Amazon Web Services in Action

Level up, strengthen your AWS skills.

Our book Amazon Web Services in Action is a comprehensive introduction to computing, storing, and networking in the AWS cloud. You'll find clear, relevant coverage of all the essential AWS services, emphasizing best practices for security, high availability, and scalability. Get the first chapter for free!

But, operating a customized load balancer infrastructure is a challenge. So, I came up with the workaround - illustrated in the following figure - using AWS building blocks only.

  • 1..n ALB with up to 25 certificates each
  • 1 NLB
  • 1 ECS service which registers its task at the NLB

SSL for ECS with ALB and NLB

Each ALB supports only 25 certificates. But you can add as many ALBs as needed to the cloud infrastructure. The static private IP addresses of the NLB are registered as the targets of each ALB. The NLB checks the health of the ECS tasks by sending HTTP requests.

To be fair, this workaround has some downsides as well.

  • Additional costs for the NLB (operating hours, processed traffic, …).
  • The NLB health checks are a lot slower when checking the health of new tasks which increases the waiting time during a deployment (up to 5 minutes).
  • The ALB tries to keep connections to your ECS service alive between multiple requests. ECS drains containers from the NLB, but doing so does not close open connections from the ALB. You need to make sure that the container is gracefully shutting down all open connections.
  • The security group of the ECS instance or task allows incoming traffic from the whole IP address range of the ALBs. Referencing the security group of the ALBs is currently not supported.

Besides these downsides, the solution with multiple ALBs pointing to a single NLB works fine as a workaround for the 25 certificates per load balancer limit.


Looking for a way to get started with AWS or to prepare for a certification? I’m offering an on-site training AWS Technical Essentials and Architecting on AWS training from July 16th to July 19th in Stuttgart (Germany). The training language is German. Register today!

Andreas Wittig

Andreas Wittig

I’m an independent consultant, technical writer, and programming founder. All these activities have to do with AWS. I’m writing this blog and all other projects together with my brother Michael.

In 2009, we joined the same company as software developers. Three years later, we were looking for a way to deploy our software—an online banking platform—in an agile way. We got excited about the possibilities in the cloud and the DevOps movement. It’s no wonder we ended up migrating the whole infrastructure of Tullius Walden Bank to AWS. This was a first in the finance industry, at least in Germany! Since 2015, we have accelerated the cloud journeys of startups, mid-sized companies, and enterprises. We have penned books like Amazon Web Services in Action and Rapid Docker on AWS, we regularly update our blog, and we are contributing to the Open Source community. Besides running a 2-headed consultancy, we are entrepreneurs building Software-as-a-Service products.

We are available for projects.

You can contact me via Email, Twitter, and LinkedIn.

Briefcase icon
Hire me