What Happens When Restoring an EBS Snapshot Without FSR?

When you restore an Amazon Elastic Block Store volume from a snapshot stored in Amazon Simple Storage Service without enabling Fast Snapshot Restore, the new volume becomes available for attachment immediately while its data loads lazily in the background. Any read request to a block that has not yet been transferred from Amazon S3 triggers an immediate on-demand fetch, which introduces higher input/output latency on first access. This article explains the mechanics of lazy loading, the performance implications of first-read latency, and how to pre-warm restored volumes to achieve baseline performance.

How EBS Snapshot Restoration Works

Amazon EBS snapshots are point-in-time backups of volumes stored incrementally in Amazon S3. When you create a new EBS volume from a snapshot without Fast Snapshot Restore (FSR), AWS does not wait for all data blocks to copy from Amazon S3 before marking the volume state as available. Instead, the volume is provisioned almost instantaneously so you can attach it to an Amazon EC2 instance and begin using it right away.

Behind the scenes, Amazon EBS uses a mechanism called lazy loading. While the volume is attached and operational, a background process continuously transfers blocks from the snapshot in Amazon S3 to the underlying storage medium of the new EBS volume.

The Impact of Lazy Loading and First-Touch Latency

Because data restoration occurs asynchronously in the background, blocks on the newly created volume exist in one of two states: hydrated (already copied from Amazon S3) or unhydrated (still residing only in Amazon S3).

When your EC2 instance issues an I/O request to a restored volume, the behavior depends on the operation and the state of the target block:

• Reading an unhydrated block: If an application attempts to read a storage block that has not yet been loaded by the background process, the I/O operation must pause while Amazon EBS fetches that specific block directly from Amazon S3, writes it to the volume, and returns the data to the instance. This synchronous retrieval causes a significant spike in I/O latency, often referred to as the first-touch penalty.
• Reading a hydrated block: Once a block has been fetched—either on-demand or via the background process—subsequent reads to that block execute at the native performance and latency of the EBS volume type (such as gp3 or io2).
• Writing to a block: Writing new data directly to a block overwrites it on the EBS volume, marking it as initialized without needing to pull the older snapshot data from Amazon S3 (unless the write is smaller than the underlying block size, which requires a read-modify-write cycle).

The effective average read latency \(L_{\text{avg}}\) during the initial operation of an unhydrated volume can be modeled as:

\[L_{\text{avg}} = (1 - p) \cdot L_{\text{native}} + p \cdot L_{\text{S3}}\]

where \(p\) is the proportion of read operations hitting unhydrated blocks, \(L_{\text{native}}\) is the normal latency of the EBS volume, and \(L_{\text{S3}}\) is the latency incurred when synchronously retrieving a block from Amazon S3. As the volume becomes fully hydrated, \(p\) approaches \(0\), and \(L_{\text{avg}}\) converges to \(L_{\text{native}}\).

Workload Scenarios Affected by Unhydrated Volumes

While lazy loading reduces the time to attach and mount a volume, the resulting I/O latency spikes and reduced throughput can degrade performance for several common workloads:

1. Production Databases: Relational and NoSQL databases executing table scans or index lookups across unaccessed blocks will experience high read latency and potential query timeouts until the working set is hydrated.
2. Root Volumes During Boot: Launching an EC2 instance from a custom Amazon Machine Image (AMI) backed by an EBS snapshot relies on reading operating system binaries and startup dependencies. While essential boot blocks are typically small, heavy application initialization during startup can be slowed down by synchronous S3 fetches.
3. High-Throughput Analytics: Workloads that immediately stream large datasets from disk will be bottlenecked by the rate at which blocks are pulled from Amazon S3 rather than the provisioned IOPS or throughput of the EBS volume.

How to Mitigate First-Read Latency Without FSR

If you do not use Fast Snapshot Restore—which pre-initializes the volume at creation time for an additional hourly fee per snapshot and Availability Zone—you can manually initialize (pre-warm) the volume before placing it into production service.

Pre-warming forces the immediate retrieval of all blocks from Amazon S3 by sequentially reading every block on the volume.

Pre-Warming on Linux

On a Linux EC2 instance, you can use the fio or dd utility to read every block on the newly attached volume. Using fio is generally recommended because it supports concurrent asynchronous reads, which speeds up hydration:

sudo fio --filename=/dev/nvme1n1 --rw=read --bs=128k --iodepth=32 --ioengine=libaio --direct=1 --name=volume-initialize

Alternatively, you can use dd:

sudo dd if=/dev/nvme1n1 of=/dev/null bs=1M

Replace /dev/nvme1n1 with the actual device name of your attached EBS volume. Because these commands only read from the device and write to /dev/null, existing data on the volume is preserved while forcing all blocks to hydrate from Amazon S3.

Pre-Warming on Windows

On a Windows EC2 instance, you can use the dd utility for Windows or run a PowerShell command or disk benchmarking tool (such as Diskspd) to perform a full sequential read across the drive or raw partition.

Comparing Standard Restore vs. Fast Snapshot Restore

Choosing whether to rely on default lazy loading, manual pre-warming, or Fast Snapshot Restore depends on your recovery time objective (RTO) and cost constraints: