How do zero-downtime deployments with ECS work?

Question

We have an ECS cluster running a single task on Fargate. We want to set up deployments so that we have zero downtime while ensuring that traffic routes to only one task at a time.

By setting desiredCount to 1, minimumHealthyPercent to 100%, and maximumPercent to 200%, ECS will launch one new task without first stopping the existing task. This gives us zero downtime.

However, how is traffic handled during this process? When ECS launches the new task, will it stop sending traffic to the existing task before routing traffic to the new one (which is our desired behavior)? Or will ECS route traffic to both tasks until the old task is stopped (which is what we want to avoid)?

Answer 1

ECS doesn't handle the traffic routing in this scenario, your load balancer handles the traffic routing. By default the load balancer will do round-robin traffic routing. Once two task instances are available in the target group, the load balancer will send every other request to a different instance of your task. This means that for a short time during your deployment, both ECS task instances will be handling traffic.

The routing algorithms available for you to configure on your Target Group are documented here. As you can see, they are all some form of spreading out the requests across all your available targets. So modifying the routing algorithm isn't going to help you achieve your desired goal.

You could try enabling sticky sessions on the target group. This would prevent a single user's session from having their requests spread across both task instances, but that is also going to lock any existing sessions to the old ECS task instance until that instance is deregistered (when ECS starts the shutdown process for that task).

If you set the Deregistration Delay setting of the target group to 0, it should (in theory) deregister the old task instance, and stop sending traffic to it, as soon as the new instance passes your health check Healthy Threshold Count. I think that is the closest you can get to achieving your stated goal of "stop sending traffic to the existing task before routing traffic to the new one".