Cluster Simulator
Visually explore how Services and Standalone Tasks behave differently when failures occur.
add_circle Deploy Resources
terminal Event Log
Which one do I need?
Choosing the wrong deployment type can lead to downtime (using Standalone for web apps) or wasted resources (using Service for one-off scripts).
Is this application meant to run indefinitely?
ECS Service
Think of a Service as a manager that employs workers (tasks). Its job is to ensure a specific number of workers are always active.
- check_circle Self-Healing: If a task crashes, the Service Scheduler automatically replaces it.
- check_circle Load Balancing: Automatically registers tasks with an ALB/NLB to distribute traffic.
- check_circle Deployments: Handles rolling updates (e.g., replace v1 tasks with v2 tasks gradually).
Typical Use Cases
Standalone Task
A Standalone Task is a "fire and forget" mechanism. You ask the cluster to run a container once.
- warning No Restart: If the code fails or finishes, the task stops. ECS does not restart it.
- check_circle Scheduled (Cron): Can be triggered by EventBridge Scheduler for periodic jobs.
- info Manual Run: Useful for administrative scripts or debugging inside the VPC.
Typical Use Cases
How to run them?
terminal AWS CLI: Create Service
--cluster my-cluster \
--service-name my-web-app \
--task-definition web-server:1 \
--desired-count 3 \
--load-balancers ...
Notice `desired-count` and `service-name`. This creates a persistent entity.
terminal AWS CLI: Run Task
--cluster my-cluster \
--task-definition batch-job:1 \
--count 1 \
--launch-type FARGATE
Just launches it. No service name, no future guarantee.