More than 25 SSL certificates with ECS

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.

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.

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

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.