t3.small EC2运行ECS awsvpc任务触发RESOURCE:ENI错误及任务数受限咨询

你遇到的实际表现和文档描述的差异，完全来自两个对配额计算逻辑的误解，不存在文档标注偏差：

• 对t3.small实例的ENI挂载总配额记忆错误：t3.small的单实例最多可挂载3块弹性网络接口，主网络接口计入该配额，即除去主ENI外，仅能额外挂载2块自定义ENI。
• 对awsvpc模式下任务和ENI的绑定逻辑理解错误：你当前遇到的场景属于未启用分支ENI（Trunking）的传统挂载模式，该模式下每个awsvpc任务会单独占用一个独立的ENI挂载槽位，和单块ENI上可分配的私有IP数量没有直接关联。
  • 这就解释了为什么你仅使用单主ENI时最多只能运行2个任务：3个总ENI槽位里主ENI占1个，剩余2个槽位刚好能分配给2个独立的任务ENI，和子网是否为公网、是否绑定公网IP完全无关。
  • 这也解释了为什么你手动额外挂载一块ENI后，仅能多运行1个任务：新增的手动ENI本身要占1个总槽位，3个总槽位扣掉主ENI1个、手动ENI1个，仅剩1个槽位可分配给任务，总任务数加1，和你的实测结果完全匹配。
  • 你之前预期“单ENI上的多IP可以对应多个任务”，是分支ENI（Trunking）模式下的计算逻辑，不是传统模式的规则。

在保留awsvpc网络模式的前提下，仅通过配置调整就能大幅提升t3.small的任务承载上限：

• 启用ECS awsvpc分支ENI（Trunking）机制
  1. 将ECS实例上的ECS Agent升级到1.59及以上版本，该版本开始默认支持自动配置分支ENI。
  2. 该机制的核心逻辑是：实例上仅需挂载少量Trunk类型的ENI（这类ENI仍然占用实例的ENI总挂载槽位），所有运行的awsvpc任务对应的都是挂在Trunk口下的分支ENI，分支ENI本身不占用实例的ENI总配额，仅消耗Trunk口上的辅助IP配额。
  3. 对应t3.small的参数计算：单块Trunk ENI最多可分配4个私有IP，扣除Trunk口本身使用的主IP，剩余3个辅助IP可承载3个任务；t3.small总共3个ENI槽位可全部作为Trunk口，理论上最多可承载9个awsvpc任务，完全符合小型容器部署的最佳实践。
• 清理残留的无效ENI占用
  部分任务异常退出时会残留未释放的任务ENI，持续占用ENI槽位或辅助IP配额。可在ECS控制台的实例详情页查看已挂载的ENI列表，将没有关联运行中任务的残留ENI手动分离，释放可用配额。
• 优化辅助IP分配规则
  不要在Trunk ENI上绑定不必要的公网IP，公网IP会占用ENI的主IP配额，减少可分配给分支ENI的辅助IP数量；确保每个Trunk ENI上的可用辅助IP数量拉满，避免因IP不足触发ENI资源报错。
• 修正ECS Agent的误判逻辑
  老旧版本的ECS Agent存在ENI配额计算bug，会在实际配额充足的情况下误报RESOURCE:ENI错误，升级到最新版本即可消除这类误判。

注意：分支ENI机制要求EC2实例为支持NVMe弹性网络适配器的新一代虚拟化实例，t3系列实例从发布开始就满足该要求，无需更换硬件配置即可启用。

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