Help us improve the AWS re:Post Knowledge Center by sharing your feedback in a brief survey. Your input can influence how we create and update our content to better support your AWS journey.
EBS initialize cost horribly long time
I restored a 4TiB EBS volume(provisioned IOPS 16000, throughput 500MB/s) from a snapshot, and copying the data in the block to the instance store of the ec2 (I need the data to be in the instance store, and I think this can also be regarded as a initialize process.)
There's around 2.5TiB data to be copied, and copying has lasted over a week, while the disk's latency is still too high and the throughput is just 3~5MiB/s:
I know that a new restored EBS volume from snapshot is lazy loading but I also read from this blog post that there's a background process keeps doing this:
The replicated volume loads data in the background so that you can begin using it immediately. If you access data that hasn’t been loaded yet, the volume immediately downloads the requested data from Amazon S3, and then continues loading the rest of the volume’s data in the background
May I know how this background process works exactly? Since my initializing process(the copying process) is ongoing as well, will this background job runs as well?
- Newest
- Most votes
- Most comments
The overall process works based on disk access. You can try and initialize it faster by hitting every block of the disk to attempt to load it faster. Otherwise it may be beneficial for you to look into FRS https://aws.amazon.com/blogs/aws/new-amazon-ebs-fast-snapshot-restore-fsr/
The new Amazon EBS Provisioned Rate for Volume Initialization feature is designed to directly solve the issue reported in the referenced re:Post question about slow initialization times when restoring an EBS volume from a snapshot.
https://aws.amazon.com/about-aws/whats-new/2025/05/ebs-provisioned-rate-volume-initialization/
With the new Provisioned Rate for Volume Initialization, you can specify a predictable initialization rate (between 100 and 300 MiB/s) at the time of volume creation. This ensures that snapshot data is downloaded and written to the volume at the specified rate, making initialization time both faster and predictable, regardless of how the volume is accessed after creation.
Key Benefits for the Reported Scenario:
- Predictable and Faster Initialization: Instead of waiting for the first access to each block, the entire volume is initialized at the rate you specify, so you know exactly how long the process will take.
- No Need for Manual Block Reads: This eliminates the need for manual scripts or utilities to read every block just to trigger initialization.
- Works at Scale: The feature is especially useful when initializing multiple volumes concurrently, as in mass EC2 launches or disaster recovery scenarios.
Relevant content
- asked 4 years ago
- asked 3 years ago
Could you elaborate more on "The overall process works based on disk access"? How it based on disk access? I know the FRS mechanism but just want to know how the initilize works in background when we use the disk normally.