Introduction

Updating an ECS service is usually just a task definition change followed by a deployment, but the operational quality of that deployment depends on how the service is configured. Good ECS practice is not "replace the tasks somehow". It is "create an immutable task definition revision, roll it out with health checks, and keep rollback simple".

Update by Registering a New Task Definition Revision

In ECS, you do not edit a running task in place. You register a new task definition revision and point the service to it.

That means the normal flow is:

1. build and push a new image
2. register a new task definition revision
3. update the ECS service to use that revision

A CLI example:

1aws ecs update-service \
2  --cluster prod-cluster \
3  --service api-service \
4  --task-definition api-task:42

This keeps deployments auditable and rollback-friendly.

Prefer Immutable Image References

Using floating tags such as latest makes ECS updates harder to reason about. It is better to publish images with immutable tags such as a Git SHA or build number and reference that tag in the task definition.

That way, task definition revision 42 always points to the exact same container image content.

Configure Rolling Deployment Settings Deliberately

For the default ECS rolling update strategy, minimumHealthyPercent and maximumPercent control how replacement happens.

Typical service settings:

• 'minimumHealthyPercent = 100'
• 'maximumPercent = 200'

This lets ECS start replacement tasks before stopping healthy old ones, assuming capacity is available. It reduces downtime risk for normal stateless services.

Use Health Checks That Reflect Reality

An ECS rollout is only as good as the signal used to declare the new task healthy. Container health checks, load balancer health checks, and application startup behavior all matter.

If the application needs time to warm up, configure that explicitly rather than hoping the rollout timing lines up by accident.

1{
2  "healthCheck": {
3    "command": ["CMD-SHELL", "curl -f http://localhost:8080/health || exit 1"],
4    "interval": 30,
5    "timeout": 5,
6    "retries": 3,
7    "startPeriod": 20
8  }
9}

This makes deployments much safer than relying on container process startup alone.

Know When Blue-Green Is Worth It

For higher-risk changes, ECS with CodeDeploy blue-green deployment can reduce impact and improve rollback behavior. That is especially useful when:

• startup is slow
• rollback must be fast
• you want traffic shifting rather than immediate replacement

For many internal stateless services, rolling deployment is enough. For high-traffic customer-facing services, blue-green is often worth the extra setup.

Force New Deployment Only for Valid Reasons

Sometimes you want ECS to replace tasks without changing the task definition, such as when pulling a newly pushed mutable image tag or refreshing environment attachment state.

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

This is useful, but it should not become a substitute for proper immutable task definition updates.

Keep Rollback Simple

Rollback should mean pointing the service back to the previous known-good task definition revision. That only stays easy if you:

1. keep revisions traceable
2. avoid mutable deployment artifacts
3. monitor health during rollout

If a deployment fails, the previous task definition should already be available as the rollback target.

Common Pitfalls

• Reusing mutable image tags such as latest in production task definitions.
• Treating ECS service updates like in-place task mutation.
• Rolling out without meaningful application health checks.
• Using force-new-deployment as a default instead of versioned task revisions.
• Forgetting to validate capacity when maximumPercent allows extra tasks during rollout.

Summary

• Update ECS services by creating a new task definition revision and deploying that revision.
• Prefer immutable image tags so deployments and rollbacks are predictable.
• Tune rolling deployment settings and health checks deliberately.
• Use blue-green deployments when rollback speed and traffic control matter.
• Keep rollback easy by preserving clear revision history and monitoring each rollout.