EC2 Mac 按秒计费，专用主机却从 24 小时起租

摘要

云计算擅长把机器拆成很小的购买单位。到了 Mac，秒表仍然精细，起租却相当豪迈。开发团队可以只需要完成一次构建，采购到手的却是一台至少分配 24 小时的专用主机。

这里的冲突不在于计时精度。秒表可以准确到秒，订单照样有最低份量。把构建任务跑得更快，缩短的是任务；它没有顺手把那份主机订单改小。

AWS 的EC2 问答把规则并排写出：EC2 Mac 按秒计费，专用主机最低分配期为 24 小时，并将这项门槛归因于 Apple macOS 软件许可协议。最低期结束后可以释放，不再承担后续主机承诺。真正的购买单位于是露了出来：团队买的是一段机器的独占分配，不是一张按成功编译分钟结算的加工单。

EC2 Mac 产品文档说明，计费单位是 Dedicated Host，运行其上的实例没有额外实例费；每台主机只能运行一个 Mac 实例。服务采用裸机形态，可用于 Apple 平台应用的开发、构建、测试与签名。

这种安排有明确的用途。企业不用先把一台 Mac 运到自己的办公室，就能把相关工作接入云端流程。但机器进入云，采购的粒度没有因此变成每一个小任务。多个团队各自申请一台，得到的是多份主机分配，而不是系统自动把几分钟工作拼成一份小账单。

同一 AWS 组织内的账户或组织单元可以共享专用主机。共享提供了组织安排的空间，没有把一台主机变成可以同时开出多个 Mac 实例的公寓楼。如何安排兼容任务，谁有优先权，谁需要独立环境，仍是企业自己的决定。

这让短任务的成本解释变得尴尬。一项任务可能只占很少的计算时间，却是开启整份分配的原因。另一项任务利用已经存在的环境，边际采购需求可能不同。如果部门只按各自的编译分钟分摊账单，触发主机购买的人与享用剩余时段的人就可能互相补贴。

专用主机定价页明确列出 EC2 Mac 的 24 小时最低主机分配与计费时长，并把释放主机列为终止相应按需主机计费的动作。其他专用主机的通用最低秒数不能搬来解释 Mac。选择产品时，细小的例外行比醒目的“按秒”更接近实际订单。

然后，第二只钟出现了。AWS 的停止与终止说明描述了一道清理流程：停止或终止 Mac 实例后，底层主机会擦除内部 SSD、清除持久 NVRAM 变量，并更新设备固件。主机暂时进入 pending 状态。

进入这个状态后，计量和计费暂停。AWS 不收清理期间的钱。同时，客户不能启动原先停止的实例，也不能在该主机上启动新实例，必须等主机重新 available。清理在账单上可以是零，在发布日程上却不是零。

文档给出的清理时间并不短：x86 Mac 最长可达 50 分钟，需要更新固件时最长可达 3 小时；Apple silicon Mac 最长可达 4.5 小时。这些是可能持续的时间，不是每次构建的固定罚时。它们足以说明，任务结束后立刻停止实例，并不等于下一份工作随到随开。

清理也有实在的内容。磁盘状态、固件与持久变量不会因为项目名称变了就自行归零。把它当作没有产出的浪费，会看漏交接过程本来要完成的工作。真正要算清的是谁为这段不可用的时间安排余量，而不是设法跳过它。

24 小时最低期与清理暂停计费，需要同时保留在采购判断里。官方页面没有提供把某次清理直接从最低账单中扣减的完整算例；实际账单和状态记录才够回答那个金额问题。文章能够确认的关系更直接：获得使用权、发生收费、真正可运行任务，是三个不同的条件。

启动也不是按键即用。对 AWS 提供的镜像，文档给出约 6 至 20 分钟的启动准备时间，卷大小、用户脚本或自定义镜像的软件还能把时间拉长。短构建之前可能有准备，之后可能有清理。只看构建日志中那一小段，很容易把整段交付当成一台理想的秒表。

因此，把兼容的工作安排在同一份已有分配内，有一个朴素的商业理由：减少为零散需求分别开启主机订单的机会。但工作能否合并，还取决于版本、环境和隔离要求。不能为了让利用率图好看，就把本应分开的任务塞到一起。

相反，保留一个随时可用的环境，也可以是一项有价服务。需要立刻出版本的团队，买的是少等待的可能；允许排队的团队，接受的是另一种交付条件。二者若共用一个“每次构建多少钱”的报价，客户收到的承诺就比计费口径丰富得多。

EC2 Mac 没有 Spot 或 Reserved Instance 购买方式，Savings Plans 可以降低支出。折扣处理的是价格，最低分配与交接处理的是时间。折扣足够好，也不会把一台正在清理的机器变成此刻可用的产能。

客户实际的任务到达时间、主机占用和等待成本尚未给出，它们决定保留就绪环境还是释放后再申请更划算。至少，采购讨论可以从正确的问题开始：这一次要买多少工作，还是要买多久的随时开工？秒表回答前一半。主机订单把后一半寄给财务。