Skip to main content
emnode / learn
Compliance Medium severity

AWS Security Hub · ECS

ECS.12: ECS clusters should use Container Insights

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub ECS.12 check?

ECS.12 checks whether each ECS cluster has CloudWatch Container Insights enabled, via the Config rule ecs-container-insights-enabled. It fails any cluster whose containerInsights setting is off.

Why does ECS.12 matter?

An unmonitored cluster is a liability that surfaces at the worst moment. When a service starts thrashing memory or restarting in a loop, the team with Container Insights sees it on a dashboard with alarms; the team without it is reading raw task logs at 2am reconstructing what happened. It is also the data you need to right-size Fargate task sizes — without it, every container is sized by guesswork.

How do I fix ECS.12?

  1. Enable Container Insights on each cluster (containerInsights setting, or the account-level default).
  2. Confirm the ECS task or instance role can publish metrics to CloudWatch.
  3. Build dashboards and alarms on the per-service CPU, memory, and restart-failure signals it produces.

Remediation script · bash

# Inventory: flag containers running as root or with a writable root filesystem.
for fam in $(aws ecs list-task-definition-families --status ACTIVE \
    --query 'families[]' --output text); do
  aws ecs describe-task-definition --task-definition "$fam" \
    --query "taskDefinition.containerDefinitions[?user==null || user=='root' || user=='0' || readonlyRootFilesystem!=\`true\`].{Family:'$fam',Name:name,User:user,ReadOnly:readonlyRootFilesystem}" \
    --output text
done

# Harden at the source. Dockerfile:
#   RUN addgroup -S app && adduser -S -G app appuser
#   USER appuser
# Task definition: non-root user, read-only root with one narrow tmpfs, secrets via ARN.
#   "user": "1000:1000",
#   "readonlyRootFilesystem": true,
#   "mountPoints": [{ "sourceVolume": "scratch", "containerPath": "/tmp", "readOnly": false }],
#   "secrets": [{ "name": "DB_PASSWORD",
#     "valueFrom": "arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/checkout/db-AbCdEf" }]

# Register the hardened revision and roll it out (tasks only update on redeploy).
aws ecs register-task-definition --cli-input-json file://checkout-api-hardened.json
aws ecs update-service --cluster prod --service checkout-api \
  --task-definition checkout-api --force-new-deployment

Full walkthrough (console steps, edge cases and verification) in the lesson Harden ECS container workloads.

Full lesson Harden ECS container workloads Step-by-step remediation with CLI, code and persona-specific context.
AWS documentation for ECS controls ↗ Check your own account for ECS.12 →
Part of the learning path Lock down access

More ECS controls

  • ECS.2 An ECS service auto-assigns public IPs to tasks
  • ECS.3 A task definition shares the host PID namespace
  • ECS.4 A container runs in privileged mode
  • ECS.5 A container has a writable root filesystem
  • ECS.8 Secrets are passed as plaintext container env vars
  • ECS.9 A task definition has no logging configuration
  • ECS.10 Fargate services should run latest platform version
  • ECS.16 An ECS task set auto-assigns public IPs
  • ECS.18 ECS task defs should encrypt EFS volumes in transit
  • ECS.19 Capacity providers managed termination protection
  • ECS.20 Linux containers should run as non-root users
  • ECS.21 Windows containers should run as non-admin users