ECS Rules

ECS Rules

These rules identify ECS clusters and services that are underutilized, running on non-Graviton hardware, or missing autoscaling configuration.

CLDBRN-AWS-ECS-1

ECS Container Instance Without Graviton

Scan type: Discovery

What it checks

Flags EC2-backed ECS container instances that are not using Graviton (ARM64) instance types. Graviton instances offer better price-to-performance ratios than equivalent x86 instance types.

Why it matters

Graviton3 instances (m7g, c7g, r7g) and Graviton4 instances (m8g, c8g, r8g) typically provide 20-40% better price/performance than comparable x86 instances. For ECS clusters running continuous workloads, the savings compound across every container instance in the cluster.

What triggers a finding

The container instance's EC2 instance type family is in the Graviton review set AND the instance architecture is not arm64.

How to remediate

1. Verify your container images support linux/arm64 (most public images do; rebuild custom images for multi-arch if needed)
2. Update your ECS capacity provider or launch template to use a Graviton instance type: m8g, c8g, or r8g family
3. Drain the existing instance and launch a new one with the Graviton type

CLDBRN-AWS-ECS-2

ECS Cluster Low CPU Utilization

Scan type: Discovery

What it checks

Flags ECS clusters with average CPU utilization below 10% over the past 14 days. Clusters running at very low utilization are paying for provisioned capacity that is largely idle.

Why it matters

EC2 instances in an ECS cluster are billed by the hour regardless of CPU utilization. A cluster idling at 3% CPU is paying for roughly 97% of its compute capacity unnecessarily. Consolidating tasks, rightsizing, or moving to Fargate can eliminate this waste.

What triggers a finding

averageCpuUtilizationLast14Days is less than 10%.

How to remediate

• Consolidate services from multiple low-utilization clusters into a single cluster
• Reduce the number or size of container instances using a smaller instance type
• Consider migrating to Fargate for workloads with variable or low traffic — you pay only for task-level CPU/memory, not idle instance capacity
• Review whether the cluster's services can be scheduled more densely

CLDBRN-AWS-ECS-3

ECS Service Missing Autoscaling Policy

Scan type: Discovery

What it checks

Flags active ECS services using the REPLICA scheduling strategy that have no Application Auto Scaling configured. Without autoscaling, services run at a fixed task count that must be sized for peak load, paying for peak capacity at all times.

Why it matters

A service sized for peak traffic at all times pays full cost around the clock even when traffic is low. Adding autoscaling allows the task count to drop during off-peak hours, potentially cutting ECS service cost by 30-70% depending on traffic patterns.

What triggers a finding

Service status is ACTIVE, scheduling strategy is REPLICA, and either no scalable target or no scaling policy is registered for the service.

How to remediate

Register the service as a scalable target and attach a scaling policy:

# Register as scalable target
aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 1 \
  --max-capacity 10

# Attach a target tracking policy (CPU-based)
aws application-autoscaling put-scaling-policy \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-name cpu-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageCPUUtilization"
    }
  }'

See Also

• CLI discover command — scan live ECS resources
• SDK Reference — run discovery programmatically