Unused EBS Fast Snapshot Restore

It is enabled per snapshot and per Availability Zone, and each snapshot and AZ pair is billed for every minute it stays enabled, whether or not any volume is ever restored from it. The charge is separate from, and in addition to, normal snapshot storage.

FSR is typically turned on for a specific need, such as a golden AMI pipeline, an autoscaling launch path, a disaster recovery drill, or a large migration, and then left on after the need has passed. It is easy to miss because it is a snapshot attribute rather than a running resource. Two behaviors make it persist: FSR is not disabled when a Data Lifecycle Manager policy that enabled it is deleted or disabled, and the cost scales with the number of AZs, so enabling it across every AZ in a Region multiplies the charge.

FSR is billed in Data Services Unit-Hours (DSU-hours), one per snapshot per Availability Zone where it is enabled.

Snapshot and AZ pair

Each snapshot enabled for FSR in one Availability Zone is billed separately; the same snapshot in three AZs is billed three times

DSU-hour

The FSR billing unit, billed per minute with a one-hour minimum for as long as FSR stays enabled; AWS lists $0.75 per DSU-hour in US East (N. Virginia)

Billing stops on disable

Charges continue until FSR is disabled for the snapshot in that AZ, or the snapshot is deleted

Shared snapshots

When you enable FSR on a snapshot shared with you, your account is billed, not the snapshot owner

• Run describe-fast-snapshot-restores with the filter state=enabled in each Region to list every snapshot and AZ pair with FSR on, along with its EnabledTime
• For each pair, run describe-volumes with the filter fast-restored=true and compare the volumes' SnapshotId, AvailabilityZone, and CreateTime to see whether any volume has been restored from it recently
• Check the CloudWatch metric FastSnapshotRestoreCreditsBalance (dimensions SnapshotId and AvailabilityZone); a balance that sits at FastSnapshotRestoreCreditsBucketSize for weeks means no volumes are consuming credits
• Compare the AZs where FSR is enabled with the AZs your launch templates, Auto Scaling groups, or recovery runbooks actually use
• Review Data Lifecycle Manager policies that enable FSR, and snapshots whose policy was deleted or disabled, since those snapshots stay FSR-enabled until disabled manually
• Use Cost Explorer or the Cost and Usage Report to find fast snapshot restore charges and attribute them to snapshot IDs

• Disable FSR with disable-fast-snapshot-restores (or the snapshot's Manage fast snapshot restore action in the EC2 console) for snapshot and AZ pairs that no longer serve a launch or recovery path
• Limit FSR to the AZs where volumes are actually created from the snapshot instead of enabling it in every AZ
• In Data Lifecycle Manager schedules, set the FSR period (age-based retention) or the maximum number of FSR-enabled snapshots (count-based retention) so older snapshots drop out of FSR automatically
• Before deleting or disabling a Data Lifecycle Manager policy that enabled FSR, disable FSR on the snapshots it created, because deleting the policy does not do this
• Where predictable initialization time is enough, consider an EBS Provisioned Rate for Volume Initialization (100 to 300 MiB/s), which is charged once per volume created, per GiB of snapshot data, rather than per hour per AZ; or manually initialize restored volumes by reading all blocks

• Amazon EBS fast snapshot restoredocs.aws.amazon.com
• Check the fast snapshot restore state for an Amazon EBS snapshotdocs.aws.amazon.com
• Amazon CloudWatch metrics for Amazon EBSdocs.aws.amazon.com
• Create Amazon Data Lifecycle Manager custom policy for EBS snapshotsdocs.aws.amazon.com
• Amazon EBS pricingaws.amazon.com