ECS on Fargate 成本结构分解 - Spot、ARM 与扩缩的实践组合
从 CPU、内存、存储三个维度分解 ECS on Fargate 的计费体系，解析 Fargate Spot、Graviton（ARM）和 Service Auto Scaling 组合的成本优化实践。
准确理解 Fargate 计费体系
Fargate 成本优化从准确理解计费体系开始。Fargate 按 vCPU 秒和内存 GB 秒两个维度计费。单价因区域而异且会调整，目标区域的 vCPU 单价和内存单价请在 AWS 官方的 Fargate 价格页面确认。容易忽略的是任务定义中指定的 CPU 和内存组合有约束。例如 0.25 vCPU 只能搭配 0.5/1/2 GB 内存（组合表见 AWS 官方文档，截至 2026 年 9 月）。选择不当会导致为未使用的资源付费。
Fargate Spot 实现最高 70% 成本削减
Fargate Spot 利用 AWS 剩余容量以最高 70% 折扣（AWS 官方 Fargate 价格页面截至 2026 年 9 月的表述）运行 Fargate 任务。与 EC2 Spot 实例类似，容量不足时会在 2 分钟通知后中断任务。有效利用 Fargate Spot 需要正确评估工作负载的中断容忍度。批处理、数据转换流水线、CI/CD 构建作业等可中断工作负载是理想候选。ECS 服务的容量提供者策略可混合使用 Fargate 和 Fargate Spot。
Graviton（ARM）以低 20% 的成本运行相同配置
Fargate 自 2021 年起支持 Graviton（ARM64）架构（ECS on Fargate 的 Graviton2 支持于 2021 年 11 月在 AWS 官方博客发布）。基于 Graviton 的 Fargate 任务比 x86 约便宜 20%（依据 AWS 在 2021 年 11 月发布时给出的“成本降低 20%”数字，当前单价差请在官方价格页面确认）。性能表现因工作负载特性而异，迁移前建议在自己的环境中比较测量。迁移门槛在于需要为 ARM64 构建容器镜像。Go、Node.js、Python、Java 等语言的官方基础镜像已提供 ARM64 版本，多数情况下只需在 docker build 时指定 --platform linux/arm64。
Service Auto Scaling 设计模式
Fargate 成本优化中最容易被忽视的是 Service Auto Scaling 的适当配置。扩缩太慢会在峰值时性能劣化，太快会启动不必要的任务增加成本。ECS Service Auto Scaling 支持目标跟踪扩缩、步进扩缩和计划扩缩，以及基于历史模式的预测扩缩（AWS 官方文档，截至 2026 年 9 月）。首先容易考虑的是目标跟踪扩缩，设置 CPU 利用率目标（如 70%）后自动调整任务数。
成本优化的优先级与实践步骤
Fargate 成本优化应按效果从大到小依次应用。第一步是审视任务定义的 CPU 和内存设置。通过 CloudWatch Container Insights 确认实际资源使用率，将过度预置的任务调整为适当大小。削减幅度取决于当前的过度预置程度（本文以 20-40% 左右为参考，这并非 AWS 公布的数字）。第二步是迁移到 Graviton，Graviton 的单价差异会直接体现在费用上。第三步是对可中断工作负载引入 Fargate Spot。第四步是优化 Auto Scaling 策略。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。