ECS内存Binpack策略为何在有可用资源时仍扩容EC2实例？

问题描述 #

使用ECS并以Auto Scaling组作为容量提供商，在t3.micro（2 vCPU、1GB内存）EC2实例上部署任务，已将任务放置策略设置为基于内存的Binpack。但即使现有实例有足够CPU和内存可用，ECS仍会扩容新EC2实例部署新任务，导致单实例仅运行一个任务，预期是有足够内存时任务应集中在单个实例。

已排查内容 #

• 端口冲突：任务定义中网络模式设为awsvpc，每个任务拥有独立ENI，无端口冲突问题。
• EC2存储：每个EC2实例配备30GB EBS GP3存储，容器为基于Nginx的Web应用，仅含1MB静态文件，存储完全充足。

相关配置 #

容量提供商配置 #

capacity provider: autoscaling group
base: 0
weight: 100
target capacity: 100%
managed instance draining: true
managed instance scaling: true
scale in protection: false

ECS服务配置 #

desired count: 1
placement strategy:
  type: binpack
  field: memory
scheduling strategy: REPLICA
service connect:
  enabled: true
  namespace: my_namespace
  services:
    - port name: web
      discovery name: hello
      client aliases:
        - port: 80
          dns name: hello

ECS任务定义 #

network mode: awsvpc
CPU: 256
Memory: 128
container definitions:
  - name: web
    image: nginx
    port mappings:
      - name: web
        container port: 80
        protocol: tcp

补充信息 #

将实例类型改为t3.small（2 vCPU、2GB内存）并部署4个ECS任务后，集群扩容了2个EC2实例，每个实例运行2个任务。

分析与建议 #

核心原因：awsvpc网络模式的ENI配额限制 #

t3.micro实例的弹性网络接口（ENI）默认配额为2个（1个主ENI用于实例本身，1个附加ENI）。当使用awsvpc网络模式时，每个任务需要占用1个附加ENI，因此t3.micro实例最多只能运行1个任务。当尝试部署第二个任务时，ECS检测到现有实例无法分配额外ENI，只能触发Auto Scaling扩容新实例。

这完全匹配你的测试结果：t3.small实例默认ENI配额为3个（1个主ENI + 2个附加ENI），所以每个实例可运行2个任务，4个任务需要2台实例。

解决方案建议 #

1. 调整网络模式：将任务网络模式改为bridge，多个任务可共享实例主ENI，无需额外ENI。注意需配置动态端口映射避免端口冲突。
2. 升级实例类型：选用ENI配额更高的实例型号（如t3.small及以上），满足多任务的ENI需求，同时也能提供更充足的计算资源。
3. 申请ENI配额提升：若坚持使用t3.micro，可向AWS提交配额申请提高其ENI配额，但需注意t3.micro本身资源有限，多任务运行可能引发性能瓶颈，此方式仅适合轻量场景。

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