AWS ECS Auto Scaling 2026: Target Tracking, Step Scaling & Fargate

ECS Fargate autoscaling solves a billing problem and a reliability problem simultaneously. Without it, you either overprovision (paying for idle capacity) or underprovision (task crashes under load). The key is choosing the right scaling policy: target tracking for steady-state workloads, step scaling for predictable burst patterns.

Scaling Policy Comparison

Terraform: ECS Service with Autoscaling

# terraform/ecs-service.tf

# ECS Cluster
resource "aws_ecs_cluster" "main" {
  name = "${var.app_name}-cluster"

  setting {
    name  = "containerInsights"
    value = "enabled"  # CloudWatch Container Insights
  }
}

# ECS Service (Fargate)
resource "aws_ecs_service" "app" {
  name            = "${var.app_name}-app"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.app.arn
  desired_count   = 2  # Starting count (autoscaling overrides this)
  launch_type     = "FARGATE"

  network_configuration {
    subnets          = var.private_subnet_ids
    security_groups  = [aws_security_group.app.id]
    assign_public_ip = false
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.app.arn
    container_name   = "app"
    container_port   = 3000
  }

  # Prevent Terraform from resetting desired_count on every apply
  lifecycle {
    ignore_changes = [desired_count]
  }

  depends_on = [aws_lb_listener.https]
}

# ─── Autoscaling Target ───────────────────────────────────────────────────────

resource "aws_appautoscaling_target" "ecs" {
  max_capacity       = 20   # Hard ceiling on task count
  min_capacity       = 2    # Always keep at least 2 tasks (HA)
  resource_id        = "service/${aws_ecs_cluster.main.name}/${aws_ecs_service.app.name}"
  scalable_dimension = "ecs:service:DesiredCount"
  service_namespace  = "ecs"
}

# ─── Policy 1: Target Tracking on CPU (primary) ──────────────────────────────

resource "aws_appautoscaling_policy" "cpu_tracking" {
  name               = "${var.app_name}-cpu-target-tracking"
  policy_type        = "TargetTrackingScaling"
  resource_id        = aws_appautoscaling_target.ecs.resource_id
  scalable_dimension = aws_appautoscaling_target.ecs.scalable_dimension
  service_namespace  = aws_appautoscaling_target.ecs.service_namespace

  target_tracking_scaling_policy_configuration {
    target_value       = 50.0   # Keep average CPU at 50%
    scale_in_cooldown  = 300    # 5 min before scaling in (avoids flapping)
    scale_out_cooldown = 60     # 1 min before adding tasks (fast response)

    predefined_metric_specification {
      predefined_metric_type = "ECSServiceAverageCPUUtilization"
    }
  }
}

# ─── Policy 2: Target Tracking on Memory ─────────────────────────────────────

resource "aws_appautoscaling_policy" "memory_tracking" {
  name               = "${var.app_name}-memory-target-tracking"
  policy_type        = "TargetTrackingScaling"
  resource_id        = aws_appautoscaling_target.ecs.resource_id
  scalable_dimension = aws_appautoscaling_target.ecs.scalable_dimension
  service_namespace  = aws_appautoscaling_target.ecs.service_namespace

  target_tracking_scaling_policy_configuration {
    target_value       = 70.0   # Scale out when memory hits 70%
    scale_in_cooldown  = 300
    scale_out_cooldown = 60

    predefined_metric_specification {
      predefined_metric_type = "ECSServiceAverageMemoryUtilization"
    }
  }
}

# ─── Policy 3: Step Scaling on ALB Request Count (for burst protection) ───────

resource "aws_appautoscaling_policy" "request_step" {
  name               = "${var.app_name}-request-step-scaling"
  policy_type        = "StepScaling"
  resource_id        = aws_appautoscaling_target.ecs.resource_id
  scalable_dimension = aws_appautoscaling_target.ecs.scalable_dimension
  service_namespace  = aws_appautoscaling_target.ecs.service_namespace

  step_scaling_policy_configuration {
    adjustment_type          = "PercentChangeInCapacity"  # Scale by % of current
    cooldown                 = 60
    metric_aggregation_type  = "Average"

    step_adjustment {
      metric_interval_lower_bound = 0    # CPU 70–80%: add 25%
      metric_interval_upper_bound = 10
      scaling_adjustment          = 25
    }
    step_adjustment {
      metric_interval_lower_bound = 10   # CPU 80–90%: add 50%
      metric_interval_upper_bound = 20
      scaling_adjustment          = 50
    }
    step_adjustment {
      metric_interval_lower_bound = 20   # CPU >90%: double capacity
      scaling_adjustment          = 100
    }
  }
}

# CloudWatch alarm that triggers step scaling
resource "aws_cloudwatch_metric_alarm" "cpu_high" {
  alarm_name          = "${var.app_name}-cpu-high"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 2
  metric_name         = "CPUUtilization"
  namespace           = "AWS/ECS"
  period              = 60
  statistic           = "Average"
  threshold           = 70.0

  dimensions = {
    ClusterName = aws_ecs_cluster.main.name
    ServiceName = aws_ecs_service.app.name
  }

  alarm_actions = [aws_appautoscaling_policy.request_step.arn]
}

# ─── Policy 4: Scheduled Scaling (pre-scale before business hours) ────────────

resource "aws_appautoscaling_scheduled_action" "scale_up_morning" {
  name               = "${var.app_name}-scale-up-morning"
  service_namespace  = aws_appautoscaling_target.ecs.service_namespace
  resource_id        = aws_appautoscaling_target.ecs.resource_id
  scalable_dimension = aws_appautoscaling_target.ecs.scalable_dimension

  schedule = "cron(0 8 ? * MON-FRI *)"  # 8 AM UTC Monday–Friday

  scalable_target_action {
    min_capacity = 4   # Pre-warm to 4 tasks
    max_capacity = 20
  }
}

resource "aws_appautoscaling_scheduled_action" "scale_down_evening" {
  name               = "${var.app_name}-scale-down-evening"
  service_namespace  = aws_appautoscaling_target.ecs.service_namespace
  resource_id        = aws_appautoscaling_target.ecs.resource_id
  scalable_dimension = aws_appautoscaling_target.ecs.scalable_dimension

  schedule = "cron(0 20 ? * MON-FRI *)"  # 8 PM UTC

  scalable_target_action {
    min_capacity = 2   # Back to minimum at night
    max_capacity = 20
  }
}

Scale-In Protection for Long-Running Tasks

// lib/ecs/scale-protection.ts
// Prevent ECS from killing a task mid-job

import {
  ECSClient,
  UpdateTaskProtectionCommand,
} from "@aws-sdk/client-ecs";

const ecs = new ECSClient({ region: process.env.AWS_REGION! });

const CLUSTER_ARN = process.env.ECS_CLUSTER_ARN!;

function getOwnTaskArn(): string | null {
  // ECS injects this via task metadata endpoint
  return process.env.ECS_TASK_ARN ?? null;
}

export async function enableScaleInProtection(
  expiresAfterMinutes = 60
): Promise<void> {
  const taskArn = getOwnTaskArn();
  if (!taskArn) return; // Not running in ECS (local dev)

  await ecs.send(new UpdateTaskProtectionCommand({
    cluster:                CLUSTER_ARN,
    tasks:                  [taskArn],
    protectionEnabled:      true,
    expiresInMinutes:       expiresAfterMinutes,
  }));
}

export async function disableScaleInProtection(): Promise<void> {
  const taskArn = getOwnTaskArn();
  if (!taskArn) return;

  await ecs.send(new UpdateTaskProtectionCommand({
    cluster:           CLUSTER_ARN,
    tasks:             [taskArn],
    protectionEnabled: false,
  }));
}

// Usage in a long-running job:
// async function processLargeBatch() {
//   await enableScaleInProtection(120); // Protect for up to 2 hours
//   try {
//     await doExpensiveWork();
//   } finally {
//     await disableScaleInProtection(); // Always release
//   }
// }

CloudWatch Dashboard for ECS Scaling

resource "aws_cloudwatch_dashboard" "ecs" {
  dashboard_name = "${var.app_name}-ecs-scaling"

  dashboard_body = jsonencode({
    widgets = [
      {
        type = "metric"
        properties = {
          title   = "ECS Task Count"
          metrics = [
            ["ECS/ContainerInsights", "RunningTaskCount",
             "ClusterName", "${var.app_name}-cluster",
             "ServiceName", "${var.app_name}-app"]
          ]
          period = 60
        }
      },
      {
        type = "metric"
        properties = {
          title   = "CPU and Memory Utilization"
          metrics = [
            ["AWS/ECS", "CPUUtilization",    "ClusterName", "${var.app_name}-cluster", "ServiceName", "${var.app_name}-app"],
            ["AWS/ECS", "MemoryUtilization", "ClusterName", "${var.app_name}-cluster", "ServiceName", "${var.app_name}-app"],
          ]
          period = 60
        }
      }
    ]
  })
}

Scaling Configuration Reference

Pricing and Delivery Estimates

More on This Topic

• AWS ECS Fargate Deployment
• Terraform AWS Infrastructure
• AWS ECR Image Scanning
• AWS CloudFront Cache Policies
• AWS RDS Read Replicas

---

How Viprasol Helps

ECS autoscaling misconfiguration is expensive in both directions: a 5-minute scale-in cooldown that's too short causes thrashing (tasks added and removed repeatedly), while a CPU target of 80% leaves too little headroom (new tasks aren't ready by the time CPU spikes). Our Terraform module sets sensible defaults: CPU target 50%, scale-out cooldown 60s, scale-in cooldown 300s, lifecycle ignore_changes on desired_count.

What we deliver:

• aws_ecs_service: Fargate, private subnets, ALB target group, lifecycle { ignore_changes = [desired_count] }
• aws_appautoscaling_target: min 2, max 20, ECSServiceDesiredCount dimension
• Target tracking: ECSServiceAverageCPUUtilization target 50%, ECSServiceAverageMemoryUtilization target 70%
• Step scaling: PercentChangeInCapacity at 70/80/90% CPU thresholds (25%/50%/100% increase)
• Scheduled: cron(0 8 ? * MON-FRI *) scale-up morning, cron(0 20 ? * MON-FRI *) scale-down evening
• UpdateTaskProtectionCommand: enableScaleInProtection(minutes) / disableScaleInProtection() for job workers
• CloudWatch dashboard: RunningTaskCount + CPU/Memory utilization

Talk to our team about your ECS infrastructure →

Or explore our cloud infrastructure services.