A team frequently launches new volumes from a "golden" snapshot to seed fresh environments, but sees degraded I/O performance on first access to blocks that haven't been touched yet, until the whole volume has been "warmed up". Which feature directly addresses this?
- Provisioned IOPS (io1/io2), since only Provisioned IOPS volumes can be created from a snapshot at all
- EBS Multi-Attach, since spreading reads across multiple attached instances hides the latency
- Fast Snapshot Restore (FSR), enabled per snapshot per Availability Zone, which makes a volume created from that snapshot fully initialized immediately, delivering its full provisioned performance from the first I/O instead of lazily pulling unread blocks from Amazon S3 on first access
- EBS encryption by default, since encrypted volumes skip the lazy-loading step entirely
Why C? And why not the others?
Correct answer: C. Fast Snapshot Restore (FSR), enabled per snapshot per Availability Zone, which makes a volume created from that snapshot fully initialized immediately, delivering its full provisioned performance from the first I/O instead of lazily pulling unread blocks from Amazon S3 on first access
Without Fast Snapshot Restore, a volume created from a snapshot lazily loads each block from the snapshot's data in Amazon S3 the first time it's accessed, which causes exactly the first-touch latency penalty this team is seeing until every block has eventually been read at least once; enabling FSR for a specific snapshot in a specific Availability Zone means any volume subsequently created from that snapshot in that zone is fully initialized at creation and delivers all of its provisioned performance immediately, with no lazy-loading period at all. The option proposing Provisioned IOPS volumes is wrong because any of the standard EBS volume types can be created from a snapshot; the choice of io1/io2 versus gp2/gp3 doesn't change whether lazy-loading happens. The option proposing Multi-Attach is unrelated, since Multi-Attach is about sharing one volume across multiple instances, not about eliminating a single volume's first-access latency. The option proposing default encryption is also unrelated: encryption and decryption happen transparently regardless of whether a block has been lazily loaded yet, and enabling encryption by default does nothing to change the lazy-loading behavior itself.
Source: AWS EBS documentation: Amazon EBS fast snapshot restore (FSR)