Summary

  • EBS Fast Snapshot Restore bills each enabled snapshot-zone pair by the minute, with a one-hour minimum. Restore count is absent from that price unit; charges continue until FSR is disabled.
  • Each pair also has credits limiting volume creations that receive the FSR benefit. A recipient enabling FSR on a shared snapshot pays; revoking access to a custom encryption key does not automatically disable that FSR.

AWS has a small example for anyone who thinks the absence of a restore means the absence of a restore bill. Enable Fast Snapshot Restore on one EBS snapshot in one Availability Zone for 45 minutes, then disable it. In the pricing page’s Northern Virginia example, the one-hour minimum costs US$0.75.

No restore count appears in the calculation. The purchase is enabled preparation, priced by place and time. An uneventful day can please the recovery team while leaving the meter with a perfectly ordinary day’s work.

The EBS guide explains what the preparation provides. FSR creates a volume from a snapshot already fully initialised, removing the latency of first access to a block. A service with little patience for that delay has a concrete reason to buy it.

That purchase attaches to a particular snapshot in a particular zone. Prepare the same source in another zone and another billable pair joins the list. Counting snapshots alone leaves out part of the quantity being bought.

A completed restore can leave a paid appointment open

The pricing page’s other example enables one snapshot in three zones for 90 minutes. At its US$0.75 per DSU-hour rate, 1 × 3 × 1.5 × US$0.75 produces US$3.375 of FSR charges. Both examples use the stated Northern Virginia rate.

AWS says charges continue until FSR is disabled. Finishing one volume creation can close a restore task while keeping the preparation for the next one. If that is the intended service, the interval is part of the purchase.

A hosting business may deliberately pay for quiet hours. Its customer wants a shorter wait when a volume is needed, and much of that preparation may go unused. A low restore count alone does little to establish whether the purchase is sensible. The useful question is which current service still needs each prepared destination.

A new recovery zone, a replacement source snapshot or the end of a one-off job changes that question. The old pair needs a decision of its own. Closing the work ticket does not tell AWS to close its enabled setting.

The EBS billing-code guide gives FSR its own DSU-hours per zone. Snapshot storage, volume capacity, extra IOPS and throughput, and direct API requests have separate entries. A reduction in stored gigabytes or request counts can describe a real saving elsewhere while leaving this readiness charge unexplained.

Paid time and available creations need separate arithmetic

FSR has another count that matters to the service being sold. The volume-creation credit guide assigns each snapshot-zone pair its own bucket. It starts at zero and fills over time. Creating a volume consumes one credit. With less than one credit, the volume is created without the FSR benefit.

Bucket capacity and refill rate use the snapshot size corresponding to the source volume’s size. AWS’s example starts with a 200 GiB volume holding 150 GiB of data and uses 200 GiB for this calculation. These credits govern creations receiving the benefit; they are separate from money on the bill.

The state guide also distinguishes an activation request, optimisation and enabled. Optimisation offers some performance benefit; the full benefit needs enabled and sufficient credits. The feature has documented conditions for size, supported locations and provisioned performance as well.

Expected demand therefore needs a location and a time: how many volumes will need creating together in that zone? CloudWatch can track credits. After creation, the fastRestored value can establish whether the particular volume received FSR. An enabled setting, an available creation and the resulting volume each have something observable behind them.

Take back the key, then check the paying account

FSR can be enabled on a shared snapshot. The receiving account that enables it pays its own charges. Enabling and disabling apply to the account performing the operation, separating the owner of the source from the buyer of its readiness.

The configuration guide distinguishes endings that might otherwise sound interchangeable. When the owner deletes or unshares a shared snapshot, FSR is automatically disabled in the receiving account. For a shared snapshot encrypted with a custom CMK, revoking the recipient’s access to that key does not automatically disable FSR. It must be disabled manually.

The key administrator can finish the access task while the receiving account still has a paid setting to address. The closure message needs to reach whoever operates FSR in that account. One completed access record does not fill in the separate record of readiness being ended.

Assessing a particular buyer needs its enabled pairs and durations, applicable rate, available credits and restore demand. With those records, it can keep the preparation supporting its current service and close pairs whose job has ended. A shorter wait deserves a place in the selling price. A forgotten wait will find a place in the margin.