摘要

  • EBS 快速快照恢复按每个快照在每个已启用可用区的时间收费，按分钟计算，最低一小时；实际恢复次数没有进入这项计费公式，费用持续到关闭功能。
  • 完整加速效果还取决于各组合的卷生成额度。共享快照由启用加速的接收账户付费；撤销该账户对自定义加密密钥的访问，不会自动关闭其 FSR。

打开45分钟，付一小时的钱。AWS 的 EBS 价格页把这个例子写得很直白：在美国东部弗吉尼亚北部区域，为一个快照、一个可用区启用 Fast Snapshot Restore，45分钟后关闭，按最低一小时收取0.75美元。

这张小账单里，没有“恢复了几次”这一栏。启用的对象、地点和时间已经足够把钱算出来。恢复团队没有等到紧急任务，往往是好事；计费器没有因此获得调休。

FSR 买的是什么？EBS 功能说明说，它让从快照创建的卷在创建时就完成初始化，消除首次访问数据块时的初始化延迟。对需要压缩这段等待的服务，提前准备有明确用途。

钱也付在这段提前准备上。同一个快照多准备一个可用区，公式里就多一个组合。仅数“保留了几个快照”的预算表，会漏掉准备铺到了多少地方。

一次恢复做完，下一次的准备仍在待命

价格页另一个区域示例，把一个快照放在三个已启用可用区，维持90分钟。计算为1 × 3 × 1.5 × 0.75美元，得到3.375美元的 FSR 费用。两个例子都针对页面列出的弗吉尼亚北部费率。

页面明确写着，费用持续到停用 FSR。创建完一个卷，可以结束一次恢复任务，却把为下一次准备的功能留在原处。若这正是服务设计，付费等待便是购买内容的一部分。

托管商承诺客户少等一会儿，需要为这种准备找到预算。没有恢复请求的日子，也可能仍需要维持目标位置的准备。单看近期恢复次数，很难决定它值不值。

更具体的问题是：现在还有哪项服务需要这个组合？恢复目标换了可用区，基准快照更新了，一次性任务结束了，旧准备是否继续保留，都需要重新作决定。业务会议上的“完成”不会替账户执行关闭。

AWS 的账单代码说明把 FastSnapshotRestore 单列为按可用区计算的 DSU 小时。快照存储、卷容量、额外 IOPS、吞吐量和直接 API 请求各有别的项目。存储量少了、请求少了，可以解释别处的节省，却没有直接交代这只时间表走了多久。

付了待命费，还要看能接多少次创建

准备也有容量条件。卷生成额度文档为每个“快照—可用区”组合设置独立的额度池。启用时从零开始，随后按时间补充。每创建一个卷消耗一份额度；不足一份时，卷仍会创建，但没有 FSR 的加速效果。

额度池的容量和补充速度，取决于对应原始卷大小的快照大小。官方例子是一块200 GiB的卷，写入150 GiB数据，采用200 GiB作为计算依据。这里的额度约束享受加速的创建次数，和账单里的美元是两套计量。

状态文档又区分了发出启用请求、优化中和 enabled。优化阶段提供部分性能收益；完整收益需要 enabled 状态与足够额度同时具备。功能对快照大小、使用位置和配置性能也有文档规定的适用条件。

因此，付费保留某个组合，还要配合预期时点的创建需求。哪个可用区要同时生成多少卷，能否得到需要的初始化准备，都可以落实到具体记录。CloudWatch 可监控额度；卷创建后，fastRestored 值可以用于核验它是否实际获得 FSR。开关亮着和目标卷得到加速，分别有各自的证据。

收回钥匙，接收方还有一个收费开关

共享快照把付费关系切得更清楚。接收账户可以为共享给自己的快照启用 FSR，费用由该接收账户承担。启用和停用的操作作用于执行操作的账户。持有原始快照的人，与购买快速恢复准备的人，可以分属两边。

FSR 配置指南列出几种不同的结束方式。所有者删除共享快照或取消共享，会自动停用接收账户中的 FSR。另一个情况却不同：对于使用自定义 CMK 加密的共享快照，所有者撤销接收方对该密钥的访问，不会自动停用 FSR，仍需手动关闭。

负责密钥的人可以已经完成撤权，付钱的账户里却还有一步待办。安全记录写下“访问已撤销”，还需要把消息交到管理 FSR 的人手上。访问结束和费用结束，是这份文档明确分开的动作。

判断某个买方的实际情况，还缺其启用组合与时长、适用费率、额度和恢复需求记录。拿到这些，就能决定哪些准备支撑现有服务，哪些已经失去用途。短等待有它的售价。忘记结束的等待，则从经营者的利润里付账。