These rules identify ECS clusters and services that are underutilized, running on non-Graviton hardware, or missing autoscaling configuration.
| Rule ID | Scan Type | Severity | Name |
|---|---|---|---|
| CLDBRN-AWS-ECS-1 | Discovery | Medium | ECS Container Instance Without Graviton |
| CLDBRN-AWS-ECS-2 | Discovery | High | ECS Cluster Low CPU Utilization |
| CLDBRN-AWS-ECS-3 | Discovery and IaC | Medium | ECS Service Missing Autoscaling Policy |
CLDBRN-AWS-ECS-1
ECS Container Instance Without Graviton
Scan type: Discovery
Severity: Medium
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 has a known architecture that is not arm64 AND the EC2 instance type family is in the Graviton review set. Instances with no reported architecture are skipped.
How to remediate
- Verify your container images support
linux/arm64(most public images do; rebuild custom images for multi-arch if needed) - Update your ECS capacity provider or launch template to use a Graviton instance type:
m8g,c8g, orr8gfamily - 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
Severity: High
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%.
Coverage
A cluster with no averageCpuUtilizationLast14Days value (CloudWatch history for the cluster is missing or incomplete) is reported as unknown coverage instead of a pass.
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 and IaC
Severity: Medium
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
In discovery scans, service status is ACTIVE, scheduling strategy is REPLICA, and loaded autoscaling evidence shows either no scalable target or no scaling policy. The rule skips a service when its autoscaling evidence could not be loaded.
In IaC scans, the cluster and service names must be known, the scheduling strategy must be REPLICA, and a matching scalable target or scaling policy must be missing. There is no runtime status check.
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"
}
}'
IaC resources checked
| IaC Tool | Resource Type |
|---|---|
| Terraform | aws_ecs_service, aws_appautoscaling_target, aws_appautoscaling_policy |
| CloudFormation | AWS::ECS::Service, AWS::ApplicationAutoScaling::ScalableTarget, AWS::ApplicationAutoScaling::ScalingPolicy |
See Also
- CLI discover command — scan live ECS resources
- CLI scan command — scan IaC templates for ECS issues
- SDK Reference — run discovery programmatically