Scribbles for my memory

Need to restart an ECS service to pick up a changed SSM Parameter Store value (env vars/secrets are resolved when a task starts, so any fresh task picks up the new value). Two ways to force a restart look equivalent but aren't.

aws ecs update-service --force-new-deployment runs a normal rolling deployment, governed by the service's deploymentConfiguration:

aws ecs update-service --cluster my-cluster --service my-service --force-new-deployment

desiredCount never changes. If maximumPercent is above 100 (e.g. 200%), ECS starts the new task first, waits for it to pass the ALB health check, then drains and stops the old one — new and old run side by side for a moment, so there's effectively zero downtime.

Scaling desiredCount to 0 and back to 1 is a hard stop-then-start: every running task is killed first, the target group is empty until the new task comes up and passes health checks, and anything hitting the service in that window fails. It also completely bypasses the rolling-deployment logic — there's no overlap to make it graceful.

Same end state (new task, new config), different path to get there. Two things to check before relying on force-new-deployment for a "safe" restart: maximumPercent needs to allow >100%, or you get the same stop-then-start behavior with the failure mode you were trying to avoid; and deploymentCircuitBreaker — if it's disabled, a broken new task version just cycles and retries forever without rolling back, while the old task quietly keeps serving traffic, so the deployment looks non-disruptive but never actually finishes.