ECS Fargate服务夜间缩容配置疑问及状态恢复需求

问题背景 #

为降低Fargate成本，计划将包含约100个ECS服务的开发环境在夜间及周末缩容，已通过Terraform配置自动扩缩容，代码如下：

resource "aws_appautoscaling_target" "service_to_target" {
  for_each           = local.services_for_offpeak_scaling
  max_capacity       = 1
  min_capacity       = 1
  resource_id        = "service/applications/${each.value}"
  scalable_dimension = "ecs:service:DesiredCount"
  service_namespace  = "ecs"
}

// create a scheuled action to scale down all targets in local.services_for_offpeak_scaling at 10pm
resource "aws_appautoscaling_scheduled_action" "scale_service_down" {
  for_each           = aws_appautoscaling_target.service_to_target
  name               = "${each.key}-scale-down"
  service_namespace  = "ecs"
  resource_id        = each.value.resource_id
  scalable_dimension = each.value.scalable_dimension
  schedule           = "cron(0 22 ? * MON-FRI *)"
  timezone           = "Europe/London"

  scalable_target_action {
    min_capacity = 0
    max_capacity = 0
  }
}

// create a scheuled action to scale up all targets in local.services_for_offpeak_scaling weekdays only
resource "aws_appautoscaling_scheduled_action" "scale_service_up" {
  for_each           = aws_appautoscaling_target.service_to_target
  name               = "${each.key}-scale-up"
  service_namespace  = "ecs"
  resource_id        = each.value.resource_id
  scalable_dimension = each.value.scalable_dimension
  schedule           = "cron(0 6 ? * MON-FRI *)"
  timezone           = "Europe/London"

  scalable_target_action {
    min_capacity = 1
    max_capacity = 1
  }
  depends_on = [aws_appautoscaling_scheduled_action.scale_service_down]
}

疑问点 #

1. aws_appautoscaling_target中的max_capacity和min_capacity参数作用是什么？ECS服务定义中已配置desired_count，二者是否存在冗余？
2. 原本期望实现“22点缩容，次日6点恢复至缩容前状态”，但不知如何无需显式配置固定扩缩容值来实现该需求？

解答 #

1. aws_appautoscaling_target的min/max_capacity作用及与ECS desired_count的关系 #

• min_capacity和max_capacity是Auto Scaling服务对ECS服务desired_count的硬约束范围：所有通过Auto Scaling执行的扩缩容操作（包括计划任务、动态扩缩容策略），最终设置的desired_count都不能超出这个区间。
• 和ECS服务的desired_count不存在冗余：ECS的desired_count是服务的初始实例数，而Auto Scaling的范围是后续所有扩缩容操作的边界。比如你当前配置的min=1、max=1，是让Auto Scaling默认只能维持1个实例，直到计划任务临时修改这个范围（比如缩容动作把范围改成0/0，强制desired_count降到0）。

2. 实现“恢复至缩容前状态”的方案 #

Auto Scaling的计划任务本身不记录服务缩容前的desired_count，因此无法直接通过计划任务实现“自动恢复之前状态”，需要借助外部存储或工具来实现：

• 方案一：用Lambda+SSM Parameter Store记录并恢复

  1. 创建CloudWatch Event计划，在22点缩容前触发Lambda函数：遍历目标ECS服务，读取每个服务当前的desired_count，将值存储到SSM Parameter Store（比如路径/ecs/services/{service-name}/pre-scale-down-count）。
  2. 修改现有的缩容计划任务，或者让Lambda函数同时执行缩容操作（设置desired_count为0）。
  3. 创建次日6点的恢复计划任务，触发另一个Lambda函数：从SSM读取对应服务的预缩容数值，将ECS服务的desired_count设置回该值，同时重置Auto Scaling目标的min/max_capacity到原有范围。

• 方案二：基于Terraform状态恢复
  如果你的ECS服务desired_count是通过Terraform定义管理的，可以在次日6点触发Terraform apply操作，将服务的desired_count重置回Terraform配置中的初始值。这种方式需要确保Terraform状态是最新的，且有安全的执行环境（比如用ECS任务或Lambda运行Terraform）。

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