Great question! Let’s break down your proposed solutions first, then dive into the most efficient ways to handle ECS health checks.

Feasibility of Your Three Solutions #

All three approaches are valid, but each serves a slightly different purpose:

1. Monitor ECS Metrics & Dimensions #

This is a solid passive monitoring approach. ECS exposes a range of metrics (like StatusCheckFailed, CPUUtilization, and RunningTasksCount) via CloudWatch, which you can track against your normal thresholds. It works well for overall service health visibility, but it’s more about observation than automated recovery—you’ll need to pair it with alerts or automation to act on anomalies.

2. CloudWatch Alarm for StatusCheckFailed #

Your CloudWatch Alarm configuration is fully viable and actually an AWS-recommended method for detecting failed status checks. A quick note: your setup monitors the combined StatusCheckFailed metric, which includes both task and container instance failures. If you need finer granularity, use StatusCheckFailed_Task or StatusCheckFailed_Instance as the metric name. This approach excels at triggering timely alerts (via SNS) and can even be tied to Lambda or Auto Scaling for automated remediation.

3. CloudWatch Event Rule for Stopped Tasks #

This event-driven approach is also perfectly valid. By listening for ECS Task State Change events where tasks stop due to essential container exits, you get real-time notifications of critical failures. Just make sure to replace the placeholder values (clusterArn, service-group) with your actual resource ARNs and service groups to ensure the rule matches your workloads. This is ideal for immediate incident response or triggering custom automation (like restarting tasks or updating service configurations via Lambda).

More Efficient ECS Health Check Approaches #

While your solutions work, the most efficient method leverages ECS’s native health check capabilities—it’s built into the platform and eliminates the need for external monitoring to handle basic self-healing:

1. ECS Container Health Checks (Built-In) #

Configure health checks directly in your ECS task definition. ECS will automatically run these checks on your containers, and if they fail repeatedly, it will stop the unhealthy task and spin up a replacement. This is proactive, self-contained, and far more efficient than relying on external alerts for basic recovery.

Example task definition snippet:

TaskDefinition:
  Type: AWS::ECS::TaskDefinition
  Properties:
    ContainerDefinitions:
      - Name: my-service-container
        Image: my-app-image:latest
        HealthCheck:
          Command: ["CMD-SHELL", "curl -f http://localhost:8080/health || exit 1"]
          Interval: 30  # Check every 30 seconds
          Timeout: 5    # Fail if check takes longer than 5 seconds
          Retries: 3    # Replace task after 3 consecutive failures
          StartPeriod: 60  # Wait 60 seconds before starting checks (for app boot time)

2. ECS Service Auto Recovery #

Pair container health checks with ECS Service Auto Recovery, which ensures your service maintains its desired number of running tasks even if failures occur (e.g., AZ outages, task terminations). You can enable this via the ECS console or in your CloudFormation service configuration:

ECSService:
  Type: AWS::ECS::Service
  Properties:
    Cluster: !Ref ClusterName
    TaskDefinition: !Ref TaskDefinition
    DesiredCount: 3
    HealthCheckGracePeriodSeconds: 60  # Give new tasks time to boot before health checks apply
    DeploymentConfiguration:
      MaximumPercent: 200
      MinimumHealthyPercent: 100

3. Combined Approach for Full Coverage #

For robust health monitoring, combine:

• Native container health checks for automatic task replacement
• CloudWatch Alarms for service-level metrics (e.g., RunningTasksCount falling below desired count, high CPU/memory usage)
• CloudWatch Events for capturing critical events (e.g., deployment failures, container instance terminations) for real-time alerts and custom automation

内容的提问来源于stack exchange，提问作者Serhii Dykyi