Introduction

In Amazon ECS, you do not usually "restart a container" the way you might on a single Docker host. ECS manages tasks and services, so the practical restart operation is usually "replace the running task with a new one."

That difference matters because the best command depends on whether the container is part of an ECS service or a standalone task. Service-managed workloads are restarted by replacing tasks. One-off tasks are restarted by stopping them and launching new ones.

Restart A Service-Managed Workload

If the container runs inside an ECS service, the cleanest restart method is a forced new deployment. ECS then starts new tasks from the current task definition and drains the old ones.

With the AWS CLI:

1aws ecs update-service \
2  --cluster my-cluster \
3  --service my-service \
4  --force-new-deployment

This is usually the right answer when you want to refresh containers after:

• a secret or config change
• a broken in-memory state
• a new image pushed under the same tag
• a manual recovery operation

From the console, the equivalent action is updating the service and enabling the force-new-deployment behavior.

Stop A Task To Let The Service Replace It

Another service-oriented option is to stop one running task. If the service's desired count stays the same, ECS launches a replacement automatically.

aws ecs list-tasks --cluster my-cluster --service-name my-service
aws ecs stop-task --cluster my-cluster --task <task-arn> --reason "manual restart"

This is useful when you only want to restart one unhealthy task rather than rolling the whole service.

The important nuance is that the replacement happens because the service scheduler notices desired count is no longer satisfied. Without a service, stopping a task just stops it.

Restart A Standalone Task

If the container is running as a standalone ECS task and not under a service, there is no service scheduler to recreate it automatically. In that case, the restart sequence is:

1. stop the old task
2. run a new task from the task definition

Example:

1aws ecs stop-task --cluster my-cluster --task <task-arn> --reason "manual restart"
2
3aws ecs run-task \
4  --cluster my-cluster \
5  --launch-type FARGATE \
6  --task-definition my-task:12 \
7  --network-configuration 'awsvpcConfiguration={subnets=[subnet-123],securityGroups=[sg-123],assignPublicIp=ENABLED}'

That is the ECS equivalent of a manual restart for one-off workloads.

Be Clear About What Changed

If the goal is to pick up a new container image, remember that ECS only launches what the task definition describes. If you changed the image tag or task settings, register or select the correct task definition revision first. --force-new-deployment by itself does not invent a new revision. It simply replaces running tasks using the service's configured task definition.

This is why "restart" and "deploy" are closely related in ECS. The restart mechanism is usually task replacement, and the replacement uses the task definition currently attached to the service.

Watch Health Checks And Desired Count

A restart in ECS is safest when:

• the service has a healthy desired count greater than zero
• the load balancer or service discovery can shift traffic cleanly
• health checks are configured well enough to avoid serving traffic too early

For zero-downtime behavior, ECS needs enough capacity to start the new task before stopping the old one, depending on the deployment settings. If desired count is one and the app has slow startup, a "restart" may still cause a noticeable interruption.

Common Pitfalls

One common mistake is looking for a literal container restart button in ECS. ECS thinks in tasks and services, not individual Docker restart semantics. Another is force-deploying a service and expecting a different image when the service still points at the old task definition revision. Developers also often stop a standalone task and are surprised that nothing comes back, because there is no ECS service managing replacement. Finally, if health checks are weak or missing, a restart can appear successful while the new task is still not actually ready to serve traffic.

Summary

• In ECS, restarting usually means replacing tasks rather than restarting a container in place.
• For an ECS service, use update-service --force-new-deployment or stop one task and let the service replace it.
• For a standalone task, stop it and run a new task manually.
• Make sure the service points to the correct task definition revision before expecting new code or images.
• Health checks and desired count determine how cleanly the restart behaves in production.