2026 AWS Deadline Cloud 云渲染农场实战：三种计费模式真实单价 + CLI 五步上线 + 七个烧钱坑

Meta Description: AWS Deadline Cloud 云渲染农场实战：SMF/CMF/Wait and Save 三种计费的真实单价、10 个可用区域、CLI 五步上线、GPU 配额默认为 0 等七个烧钱坑，以及 100 帧作业四方案成本对比。

关键词：AWS Deadline Cloud、云渲染农场、AWS 渲染、Spot 实例、渲染成本、AWS 免费套餐、OpenJD、UBL 许可

写在前面：30 秒结论

如果你只想知道"要不要上 Deadline Cloud"，答案可以压缩成一句口诀：许可在云上买、机器用 Spot、队列设预算——三条都不做，就别上云渲染。

具体拆开是三句判断：

1. 机器费不是大头，许可费才是。 AWS 官方那个 400 帧、Arnold + Maya 的算例，账单 $176.60 里许可费 $132.00，占 74.8%；计算实例 110 + 45 + 45 小时合计只占 21.5%。你在云上折腾 Spot 中断率、Right-sizing、竞价策略，能优化的只是那 21%，而许可那 74% 是按小时硬收的。
2. Wait and Save 比 Spot 还便宜一半。 us-east-1 的 Wait and Save 是 $0.0059913853/vCPU-小时，16 vCPU 机器 = $0.0959/小时；同一份官方算例里 c5.4xlarge 的 Spot 价是 $0.1878/小时。也就是说，能等的作业用 Wait and Save，比 Spot 再省约 50%，比 On-Demand（$0.68/小时）省约 86%。
3. 默认配额跑不动真正的渲染农场。 每个区域的 On-Demand、Spot、Wait-and-save 各只有 50 vCPU，GPU 配额 默认是 0。也就是说开箱即用的账号最多跑 3 台 16 vCPU 机器，而 GPU 实例一台都起不来——报错是配额不足，不是配置错误。

所以本文的定位很明确：不是"教你点开控制台"，而是把三种计费模式的真实单价、四个可复算的算例、CLI 五步上线、七个会真花钱的坑一次讲清。文末有一张 100 帧作业的四方案成本对比表，SMF Spot 与自建 EC2 Spot 的差距只有约 2.5%，这 2.5% 就是"托管值不值"的全部答案。

⚠️ 本文所有单价为 2026 年 10 月 us-east-1 口径，取自 AWS 官方定价页、Price List API 与端点配额文档。价格随区域和官方调价变动，下单前请以 AWS 官网为准。

一、Deadline Cloud 到底是什么：三条硬边界先划清

AWS Deadline Cloud 是一个全托管的渲染农场调度服务。它自己不做渲染，做的是"把一帧一帧的渲染任务，分给一批临时开出来的 EC2 机器，跑完自动收回"。你可以把它理解成"渲染界的 AWS Batch"——只不过它内置了 DCC（数字内容创作）软件的集成、渲染器许可的按小时购买、以及作业级别的成本追踪。

它与两个容易混淆的东西的分界线如下：

关键在最后一行：Deadline Cloud 没有月固定费、没有预付费、没有最低消费。SMF（服务托管舰队）模式下的调度本身不收费，你付的是 EC2 实例费 + EBS 费；CMF（自管舰队）模式下才收 $0.015/worker-小时 的调度费。

但在动手之前，有三条硬边界必须先接受，否则后面全是白干：

边界一：只有 10 个区域，没有香港、没有中国区。

us-east-1、us-east-2、us-west-2、ap-northeast-1（东京）、ap-northeast-2（首尔）、ap-southeast-1（新加坡）、ap-southeast-2（悉尼）、eu-central-1、eu-west-1、eu-west-2。

没有 ap-east-1 香港、没有中国大陆区域、没有孟买 ap-south-1、没有圣保罗。 所以"香港机房渲染"这个需求在 Deadline Cloud 上是明确做不到的，港台与国内团队最近的选择是东京、首尔或新加坡（延迟分别约 30–50ms、40–60ms、50–80ms 量级）。资产如果存在香港 S3 桶，跨区传输费要单独算。

边界二：没有免费套餐。

AWS 免费套餐页全文检索 deadline 命中 0。它既不在 30+ 项"永久免费"清单里，也没有"前 12 个月每月 X 小时"这种按月额度。能用的只有账号级的 2026 免费计划：注册赠 $100 + 探索基础服务最多再 $100，合计最高 $200 额度，免费计划有效期 6 个月、额度需在 12 个月内用完，到期或额度耗尽（先到者为准）账号会被关闭、数据保留 90 天。另外提醒一句：一旦加入 AWS Organizations 或建 Control Tower landing zone，这个免费计划立即失效并自动转付费计划，之后也没有资格再申请。

$200 额度换算成渲染量大概是多少？按 16 vCPU 的 Wait and Save（$0.0959/小时）算，约 2,085 机时；按官方算例里的 Arnold UBL（$0.66/小时）算，只够 303 小时的许可。也就是说额度够你做一次小规模试跑，不够跑一部短片。

边界三：GPU 配额默认是 0。

这是全篇最值钱的一条。新建账号、建好 fleet、提交一个需要 GPU 的 Redshift 或 Karma 渲染任务，worker 会一直起不来，控制台报的是配额不足而不是配置错误——很多人会在这里怀疑是 AMI 选错、实例类型不支持、IAM 权限不够，实际上去 Service Quotas 把 OnDemand G instances 和 Spot G instances 两个配额提上去就好了。同理，三个 vCPU 配额（On-Demand / Spot / Wait-and-save）各 50，想上 100 台机器必须先提额，否则"弹性扩到几千台"在你自己账号里根本不成立。

二、五个概念：farm → queue → fleet → worker → job 的层级关系

Deadline Cloud 的对象模型是严格分层的，搞混层级是新手最常犯的错（比如在"队列"里找 GPU 配置——那其实在"舰队"里）。自上而下只有五层：

Farm（农场：一个区域的顶层容器，配额 2 个/区域）
 └── Queue（队列：作业排队的地方，20 个/农场）
      └── Fleet（舰队：worker 的规格定义，5 个/农场）
           └── Worker（工作节点：真正跑渲染的 EC2 实例，7500 个/农场）
                └── Job（作业）→ Step（步骤）→ Task（任务）→ Chunk（分块，≤150）

Farm（农场） 是顶层隔离单元。一个农场对应"一个项目组"或"一个工作室"，每个区域默认只能建 2 个。它是最像"租户"的一层——权限、预算、存储配置都挂在农场上。创建时只需要 --display-name，没有 --role-arn 参数（这一点和直觉相反，凭感觉写 role-arn 会直接报未知参数）。

Queue（队列） 是作业排队的逻辑队列，默认 20 个/农场。队列和舰队之间是多对多关系，靠 queue-fleet-association 连起来——一个队列可以同时挂"Spot 16 vCPU"和"Wait and Save 8 vCPU"两个舰队，让同一个作业先试便宜的、排队超时再上贵的。这是 Deadline Cloud 里最实用的一个设计，也是最容易被忽略的一个。

Fleet（舰队） 定义"worker 长什么样"：操作系统（LINUX / WINDOWS / MACOS）、CPU 架构（x86_64 / arm64）、最小 vCPU 数与内存、以及市场类型（on-demand / spot / wait-and-save）。GPU 型号、实例类型上限、最大 worker 数全在这里配。 一个舰队最多 5 个/农场，所以不要把"每种机器一个舰队"玩到极致。

Worker（工作节点） 是从舰队定义里现开出来的 EC2 实例，跑完任务后按策略缩容。这里有个默认值坑：--min-worker-count 不填时默认是 0，也就是空闲时缩到零、不花钱；但如果你为了让"任务来了不用等启动"而设成 3，那这 3 台会7×24 空转计费——一个 16 vCPU 的 Wait and Save 舰队空转一个月约 $70，Spot 舰队空转一个月约 $137。

Job（作业） 采用 OpenJD（Open Job Description）开放规范定义，2023-09 版本。作业往下拆成 Step → Task → Chunk：一个 Step 是一段可并行的阶段（比如"渲染 1–100 帧"），Task 是其中最小调度单元（通常一帧一个 Task），Chunk 是把多个 Task 打包给同一个 worker 以减少启动开销（上限 150）。

用一帧一个 Task 还是 10 帧一个 Chunk，对成本影响很直接：Chunk 太小，worker 的启动、软件初始化、资产下载开销会重复发生，一个 8 秒的渲染任务可能配上两分钟的机器启动；Chunk 太大，又会让负载不均、尾部拖长。经验值是单 Chunk 的渲染时长控制在 3–10 分钟。

Storage profile（存储配置） 是第 6 个隐藏概念，默认 50 个/农场，绑定一个 OS 系列。它决定作业资产（job attachments）怎么落地：资产本体存 S3（按 S3 计费），worker 本地盘从 EBS 来（SMF 模式下由 Deadline Cloud 计费，见下一节）。如果你需要"装一次软件、后续作业复用"，就要用 EBS persistent storage——root volume 跨会话保留，省掉每次重装 Arnold/Houdini 的 20 分钟。

OpenJD 的意义值得单独说一句：因为作业模板是开放规范而不是私有格式，同一份 job.json 理论上可以迁到别的支持 OpenJD 的调度器上。AWS 在 GitHub 上放了 aws-deadline 与 OpenJobDescription 两个仓库，样例覆盖 Blender、Maya、Nuke 等。这是它相对 Thinkbox Deadline 10 的一个真实优势——不被单一厂商的私有作业格式锁死（虽然实际上迁移成本仍然很高）。

除了渲染，这套模型也被用来跑蒙特卡洛模拟、合成数据生成、Gaussian splatting、LoRA 微调、蛋白折叠、流体/物理仿真。原因很简单：这些负载的形状就是"几百个互不依赖的任务 + 一批临时机器"，和渲染一模一样。

三、三种计费模式真实单价：SMF Spot / Wait and Save / CMF

Deadline Cloud 的账单由三部分构成：舰队类型（决定谁收费）→ 实例规格（决定单价）→ 任务时长（决定乘数），另外叠加 UBL 渲染器许可、EBS、数据传输、VPC Resource Endpoint 四项。

三种舰队类型的收费逻辑完全不同，这是全文最容易看错的地方：

3.1 Wait and Save：10 个区域的真实单价

Wait and Save 是 SMF 里的第三档市场类型，官方描述是"as low as $0.006/vCPU-hr"。实际逐区域取值如下（USD / vCPU-小时）：

从这张表能读出三件事：

第一，Windows 是 Linux 的约 9.7 倍，而且差额恒定为 +$0.0520/vCPU-小时。 十个区域无一例外。这说明它不是按比例定价，而是"Linux 计算价 + Windows 许可价"两段相加，那 $0.052 就是 Windows 许可本身。渲染农场里一台上 Windows 节点的钱，够开九台 Linux 节点。

第二，最便宜与最贵差 23%。 us-east-2 的 0.005835 对 eu-west-2 的 0.007201。区域选择上，亚洲团队用首尔（0.006419）比用东京（0.006914）便宜约 7%，比新加坡（0.006905）也便宜。

第三，16 vCPU 机器的实际小时价 = 16 × 0.0059914 = $0.0959。 对比同规格 c5.4xlarge 的 Spot 价 $0.1878——Wait and Save 约为 Spot 的一半；对比 On-Demand $0.68 则便宜约 86%。代价是启动要等，且官方明确说明这一档只覆盖计算时间，不含许可、存储、数据传输和其它 AWS 服务。

3.2 CMF：按"连接时长"计费，挂机也在烧钱

CMF（Customer-Managed Fleets）适合已有本地工作站或自有 EC2 的场景，费率统一 $0.015/worker-小时，本地机器与 AWS 机器同价。它的计价口径有一个必须记住的特征：按 worker 的连接时长计费，不是按实际渲染时长。

官方例子写得直白：一台 worker 连了 10 小时、另一台连了 25 小时，账单按 35 worker-小时计，不管你中间有没有在渲染。所以 CMF 的正确用法是"任务结束就让 worker 断开"，而不是"开着等下一个任务"。一个 20 台的本地农场如果 7×24 挂着，一个月是 20 × 730 × 0.015 = $219——纯调度费，一台机器没跑也算。

在 AWS 上跑 CMF 时，实例费由 EC2 账单收，不走 Deadline Cloud；这也意味着 CMF 的账单会分散在两个服务里，做成本分析时要合并看。

3.3 渲染器许可（UBL）：真正的账单主体

UBL（Usage-Based Licensing）是 Deadline Cloud 最有价值也最容易让人心惊的功能——它让你不用提前买 Arnold/Nuke/Houdini 的永久许可，按小时付。us-east-1 单价：

两点必须说清：其一，Nuke、Houdini Engine、Karma 都是阶梯价，超过 60 / 600 小时后单价下探，本文只取到第一档，长期跑量的团队务必去官方页面对完整阶梯（本文不给假数字）；其二，Redshift、Red Giant、Cinema 4D 在 SMF 与 CMF 下是两个价，CMF 是 SMF 的两倍，因为托管模式里 AWS 承担了许可服务器的运维。

3.4 容易被忽略的三项附加成本

• SMF 的 EBS：gp3 存储 $0.096/GB-月（官方算例里按四舍五入的 $0.10 计算），预置 IOPS $0.006/IOPS-月，预置吞吐 $49.152/GiBps-月。对比 EC2 自身的 gp3 $0.080/GB-月，SMF 的 EBS 贵约 20% ——这是"托管也有加价项"的诚实一面。
• VPC Resource Endpoint：$0.004/GB，且双向各算一次，另加 VPC Lattice 的数据处理费。走私有网络连本地存储的团队要留意这笔。
• 作业附件：资产存 S3，按 S3 标准价计费；跨区取资产还要加数据传输费。

四、四个算例：从 $176 的短片到 $6.4 的百帧作业

数字只有放进算例才有意义。这里给出两个 AWS 官方算例（已逐项复算）与两个自测算例，方便你对号入座。

4.1 官方算例一：400 帧短片，SMF Spot + Arnold UBL

设定：400 帧 × 30 分钟渲染，Arnold/Maya，≥16 vCPU / 32 GiB，250 GB EBS。

这张表最反直觉的地方是许可费占 74.8%（$132 / $176.60），计算实例只占 21.5%（$37.88）。

由此得出本文的核心判断：云渲染"省机器"的天花板就是那 21%。 你花两周时间做 Spot 竞价策略优化，最好情况是把 $37.88 压到 $25，省 $13；而如果你有 Arnold 的永久许可或浮动许可可以带到云上（用 CMF + 自有许可服务器），$132 那行直接归零——账单从 $176.60 掉到 $44.60，降幅 75%。

所以第一件该问的事不是"哪个实例便宜"，而是"我的渲染器许可能不能上云"。

4.2 官方算例二：CMF 本地 + AWS 混合

设定：600 帧 × 1 小时，自有许可服务器，所以没有 UBL 行。

CMF 的 $9 只占 10%，机器费是主体，且由 EC2 账单收取不是 Deadline Cloud。这个算例说明：CMF 的调度费便宜到几乎可以忽略，真正要算的是机器。反过来说，如果你已经有本地农场，只是溢出到云上跑，CMF 是成本结构最干净的选择——但也别把 worker 挂着不关（见 3.2 节）。

4.3 自测算例：100 帧、16 vCPU、50 个 worker 小时

设定：100 帧，每帧约 30 分钟，16 vCPU 机器共跑 50 机时，250 GB EBS 挂 50 小时（≈16.8 GB-月），不含许可。

这张表回答了一个具体问题：SMF Spot 跟自己拿 EC2 Spot + 自写调度器，差多少钱？

答案是 $11.00 对 $10.73，只差 2.5%，而这点差距恰好就是 SMF 那 20% 的 EBS 加价（$0.096 vs $0.080）。也就是说，Deadline Cloud 在纯机器成本上几乎没有溢价，你多付的 2.5% 换来的是调度器、监控、UBL 直购、AI 排障和预算刹车。任何"自建更便宜"的说法，在把运维人力算进去之后都不成立。

如果这批帧用 Arnold 渲染，还要再叠 50 × $0.66 = $33 的许可，账单变成 $44——许可占总成本的 75%，与官方算例的比例一致。

4.4 四方案成本对比总表（100 帧，含许可与不含许可）

最后一行是全文的"标准答案"：自带许可 + Spot 机器，成本只有买 UBL 方案的四分之一。代价是你要有可搬迁的浮动许可服务器，而且得把它接到云上（License endpoints 每区域 5 个、每个 endpoint 500 个会话，这两个配额都可提额）。

五、CLI 五步上线：从空账号到跑起第一个作业

控制台的 Quickstart 会一次性建好 farm + 默认队列 + 默认舰队 + 计算配置——所以"我什么都没配，怎么就已经有 fleet 了"是预期行为。但 Quickstart 建出来的舰队参数是通用的，max-worker-count 往往偏小、min-worker-count 可能非零，必须回头看一遍再上生产。真正可控的路径是 CLI：

第 1 步，建农场。 只需要显示名：

aws deadline create-farm --display-name studio-farm --region us-east-1

可选参数只有 --description、--kms-key-arn、--cost-scale-factor。没有 --role-arn——这是最常踩的一个语法坑。

第 2 步，建存储配置与队列。

aws deadline create-storage-profile --farm-id farm-xxxx --display-name smf-linux --os-family LINUX
aws deadline create-queue --farm-id farm-xxxx --display-name render

create-queue 的 --role-arn 是可选的，--job-attachment-settings、--allowed-storage-profile-ids、--default-budget-action 也都是可选。队列本身不定义机器规格，机器规格在下一步。

第 3 步，建舰队（关键一步）。 下面是一个 Spot / Linux / 16 vCPU 起的服务托管舰队：

aws deadline create-fleet --farm-id farm-xxxx --display-name spot-16vcpu \
  --role-arn arn:aws:iam::123456789012:role/DeadlineCloudWorkerRole \
  --max-worker-count 50 \
  --configuration '{"serviceManagedEc2":{"instanceCapabilities":{"osFamily":"LINUX","cpuArchitectureType":"x86_64","vCpuCount":{"min":16},"memoryMiB":{"min":16384}},"instanceMarketOptions":{"type":"spot"}}}'

五个必填：--farm-id、--display-name、--role-arn、--max-worker-count、--configuration。--configuration 是 tagged union，customerManaged 与 serviceManagedEc2 只能二选一；instanceMarketOptions.type 三值为 on-demand / spot / wait-and-save。想要 GPU 机器，就在 instanceCapabilities 里加 GPU 型号并把配额提上去。

第 4 步，把队列和舰队关联起来。

aws deadline create-queue-fleet-association --farm-id farm-xxxx \
  --queue-id queue-xxxx --fleet-id fleet-xxxx

不做这一步，队列里的作业永远等不到 worker——这是新手第二大坑（第一大是 GPU 配额）。

第 5 步，提交作业。 作业模板是 OpenJD 的 JSON：

aws deadline create-job --farm-id farm-xxxx --queue-id queue-xxxx --priority 50 \
  --template "$(cat job.json)" --template-type JSON

注意 --template 是 string 类型，CLI 不会读取 file://（file:// 只对 blob 类参数生效）。直接写 --template file://job.json 会让服务端收到字面量字符串，然后报模板解析失败。必须用 "$(cat job.json)"。

一个最简的 Blender 批量渲染模板骨架（1–100 帧，每 5 帧一个 chunk）：

{
  "specificationVersion": "jobtemplate-2023-09",
  "name": "blender-batch",
  "steps": [{
    "name": "Render",
    "parameterSpace": {"taskParameterDefinitions": [
      {"name": "Frame", "type": "INT", "range": "1-100"}
    ]},
    "script": {
      "actions": {"onRun": {"command": "blender", "args": [
        "-b", "{{Param.SceneFile}}", "-o", "/tmp/out_####",
        "-F", "PNG", "-f", "{{Task.Param.Frame}}"
      ]}}
    }
  }]
}

chunk 大小由作业级的 taskChunking 设置控制（上限 150），超时与重试在 step 上配。生产环境还要配 storageProfile、jobAttachments 与预算（见下一节的 create-budget）。

上线顺序建议：先提配额（GPU + vCPU）→ 建农场 → 建存储配置 → 建队列 → 建舰队 → 关联 → 建预算刹车 → 提交一个 1 帧的冒烟作业 → 再放量。跳过冒烟作业直接上 400 帧，是"第一次用就烧掉一个月的钱"最常见的方式。

六、七个烧钱坑：每一条都能让你多付一个月工资

下面这七条按"踩中概率 × 损失金额"排序，前三条几乎每个新账号都会中。

坑 1：GPU 配额默认是 0。 提交 GPU 渲染任务后 worker 永远 pending，控制台只说配额不足。很多人会花半天查 AMI、查实例类型、查 IAM 信任策略。正确处理：Service Quotas 里把 OnDemand G instances 和 Spot G instances（按 g/g5/g6 家族分）提上去，两个都要提，只提一个会在换市场类型时再卡一次。

坑 2：vCPU 配额三档各 50。 On-Demand、Spot、Wait-and-save 各 50 vCPU，等于"最多 3 台 16 vCPU"。一个 200 帧的作业如果 16 vCPU 机器每帧 30 分钟，串行要 100 小时；想压到 5 小时需要 20 台机器 = 320 vCPU，必须提前提额。提额申请通过通常要几小时到一天，赶交付的团队应该在上线前就把配额提到目标值的 2 倍。

坑 3：min-worker-count 大于 0 就是 7×24 空转。 默认是 0（正确），但控制台 Quickstart 建的默认舰队参数不一定符合你的用量，max-worker-count 也可能只有 10。开箱后第一件事就是 aws deadline list-fleets 把每个舰队的 min/max 核一遍。一个 min=3 的 16 vCPU Wait and Save 舰队，什么都不跑，一个月 $70；Spot 则约 $137。

坑 4：用 Windows 节点渲 Linux 能跑的东西。 3.1 节的表已经写死：Windows 是 Linux 的约 9.7 倍，差额恒定 $0.052/vCPU-小时。Maya、3ds Max、Houdini、Blender 全部有 Linux 版，只有极少数插件（部分旧版 V-Ray 插件、部分 AE 插件流程）才必须 Windows。这条坑的损失是小时单价直接乘十。

坑 5：以为许可是小钱。 官方算例里 Arnold 占 74.8%。50 机时的渲染，机器 $9.39、许可 $33——许可是机器的 3.5 倍。更进一步，Nuke / Houdini Engine / Karma 都是阶梯价，跑量大的团队如果按第一档单价做预算，会系统性高估（或低估，取决于你对阶梯的假设），必须去官方页面核对完整阶梯。能自带浮动许可就用 CMF，这一条比任何机器优化都值钱。

坑 6：Budget 到点只"停止调度"，手上任务还在跑。 create-budget 的 actions[].type 只有两个值：STOP_SCHEDULING_AND_COMPLETE_TASKS（跑完手上的再停）和 STOP_SCHEDULING_AND_CANCEL_TASKS（连手上的一起取消）。选前者时，超预算那一刻可能还有几十台机器在跑满一小时，账单继续涨。赶时间的项目要选后者。 另一个限制：schedule 只支持 fixed{startTime,endTime}，没有"每月循环"，做月度预算要自己每月重建，或者用 EventBridge 定时触发重建。

坑 7：CMF 按"连接时长"收费，挂机也掏钱。 $0.015/worker-小时看着便宜，但 20 台常驻 = $219/月 纯调度费，一台都没跑也算。CMF 的正确姿势是作业结束主动断开 worker（或让脚本在空闲 N 分钟后退出），别把它当"常开的本地农场"用。

预算刹车的完整命令如下，建议在放量前就建好：

aws deadline create-budget --farm-id farm-xxxx --display-name monthly-500 \
  --usage-tracking-resource '{"queueId":"queue-xxxx"}' \
  --approximate-dollar-limit 500 \
  --actions '[{"type":"STOP_SCHEDULING_AND_CANCEL_TASKS","thresholdPercentage":100}]' \
  --schedule '{"fixed":{"startTime":"2026-11-01T00:00:00Z","endTime":"2026-12-01T00:00:00Z"}}'

预算可以挂在整个队列上，也可以挂到单个作业；每个农场 20 个预算。配合 Usage Explorer（近实时的按项目花费视图）才是完整的护栏——一个看趋势，一个做硬刹车。

七、按规模推荐：三种团队的三条路线

个人艺术家的核心诉求是"别为闲置付费"：min-worker 设 0、用 Wait and Save、预算卡在 $100。这种人最容易踩坑 1（GPU）和坑 5（许可比机器贵），所以选一个 UBL 便宜的渲染器（Karma $0.1875、Mantra 免费）比选机器更重要。

中小工作室的核心诉求是"交付不能等"：同一个队列挂两个舰队，便宜的先跑、卡住再上 Spot；软件装在 EBS persistent storage 里跨会话复用，省掉每台机器 20 分钟的 Arnold/Houdini 初始化。这一层要开始用 Budget Manager 按项目设阈值。

有本地农场的大厂的核心诉求是"许可不重复买"：CMF 把本地机器接进来，用自有 License endpoint（每区域 5 个、每个 500 会话，都可提额），只把峰值溢出到 SMF。这一层必须配 IAM Identity Center（支持 Okta / AD / 任意 SAML 2.0 或 OIDC）和四级权限 Viewer / Contributor / Manager / Owner，否则谁都能改 max-worker-count 就是灾难。

一条通用的选址建议：亚洲团队优先东京或首尔。首尔的 Wait and Save 单价（0.006419）比东京（0.006914）低 7%，比新加坡（0.006905）也低；如果资产在 S3 香港桶，跨区传输费要单独评估，别只看单价。

相关阅读

• AWS EC2 实例购买方式全解：按需、Spot、预留、Savings Plans 怎么选
• AWS Budgets 预算与告警实战：把云账单关进笼子
• AWS MWAA 托管 Airflow 实战：批处理编排的另一条路
• AWS 数据湖实战：Glue Catalog + Lake Formation + Athena
• AWS EBS 块存储选型深度实战：gp3、io2 与快照成本

⚠️ 文中价格为 2026 年 10 月 us-east-1 参考价，实际费用随区域和官方调价变动，请以 AWS 官网为准。UBL 阶梯价仅列第一档，长期跑量请核对官方完整阶梯。

🚀 需要 AWS 国际版账号？通过 3.chengzicloud.cloud 获取最新注册教程与专属优惠，助你轻松上云。

本文由 3.chengzicloud.cloud 提供，点击访问首页了解更多