AWS ECS Service Config Builder

About This Tool

Build an ECS service configuration with a deployment circuit breaker (auto-rollback on failed deployment) layered with CloudWatch alarm-based rollback, plus optional Service Connect for service-to-service DNS-based discovery without a separate load balancer or mesh. The deployment circuit breaker and alarm-based rollback are two independent failure-detection mechanisms: the circuit breaker watches ECS-level deployment health (tasks failing to start or stabilize), while Alarms watches your own CloudWatch alarms (like an application error-rate metric), a deployment can pass the circuit breaker's checks (new tasks start fine) while still tripping an alarm-based rollback because the new code is running but throwing errors, they catch different failure classes.

When to Use This Tool

• •Enabling DeploymentCircuitBreaker with Rollback: true so a deployment where new tasks repeatedly fail to reach a healthy state automatically rolls back to the previous task definition, instead of leaving the service stuck in a degraded, partially-deployed state.
• •Adding an Alarms block referencing application-level CloudWatch alarms (5xx rate, latency) alongside the circuit breaker, so a deployment that technically starts healthy tasks but causes a spike in application errors also triggers automatic rollback, a failure mode the circuit breaker alone wouldn't catch.
• •Enabling ServiceConnectConfiguration so other services in the same namespace can reach this service via a stable DNS name (backend-api) regardless of which underlying tasks or IPs are currently running, without needing a separate internal load balancer.
• •Setting MaximumPercent to 200 and MinimumHealthyPercent to 100 for a service that needs true zero-downtime deployment, ensuring a full set of new tasks starts before any old tasks are stopped, at the cost of temporarily running double capacity during the deployment window.

Pro Tips

How It Works Under the Hood

Frequently Asked Questions

If the deployment circuit breaker doesn't trigger, does that mean my deployment is definitely healthy?

No, the circuit breaker only watches ECS-level task health (whether tasks start and reach a steady, non-crashing state), it has no visibility into your application's actual behavior. A new task definition can start perfectly healthy tasks that then serve a spike of application-level errors, the circuit breaker alone wouldn't catch that, which is exactly why pairing it with alarm-based rollback (watching your own error-rate or latency alarms) covers a different, important failure class.

What's the tradeoff of setting MaximumPercent above 100%?

A MaximumPercent above 100 (200 in the example) lets ECS start new tasks before stopping old ones during a deployment, giving you rolling, largely uninterrupted capacity, but it means the service briefly runs at up to double its normal task count, which needs corresponding cluster capacity headroom (for EC2 launch type) or is simply billed for the extra Fargate tasks during that window. A cluster or account without enough spare capacity can see a deployment stall waiting for room to start the new tasks.

Does Service Connect replace the need for a load balancer entirely?

Not for external or internet-facing traffic, Service Connect provides internal service-to-service DNS-based discovery and (via its Envoy-based proxy) some traffic management within the mesh of services sharing a namespace, but a service still needs a real load balancer (ALB/NLB) via the LoadBalancers configuration for traffic coming from outside that Service Connect namespace, as the example config shows both configured together, not as alternatives.

Related Learning Guides

• EC2 Instance Types Explained24 min read
• ECS vs EKS Decision Guide24 min read