A company has a cluster of Linux Amazon EC2 Spot Instances that read many files from and write many files to attached Amazon Elastic Block Store (Amazon EBS) volumes. The EC2 instances are…

Question

Options

• AConfigure fast snapshot restore (FSR) on the snapshots that are used.
• BRestore each snapshot onto an unencrypted EBS volume. Encrypt the EBS volume when the
• CFormat the EBS volumes as XFS file systems before restoring the snapshots.
• DIncrease the Linux read-ahead buffer to 1 MiB.

• A
  79% (26)
• B
  12% (4)
• C
  6% (2)
• D
  3% (1)

Explanation

Fast Snapshot Restore (FSR) eliminates the "lazy loading" behavior of EBS volumes restored from snapshots - normally, blocks are pulled from S3 on first access, causing latency spikes until the full volume is hydrated. With FSR enabled, volumes are fully initialized at creation time, delivering full provisioned IOPS immediately upon attachment.

Why the distractors are wrong:

• B is a red herring - encryption status has no bearing on I/O initialization performance; the lazy-loading problem exists regardless of whether the volume is encrypted.
• C is incorrect because the file system format (XFS vs. ext4) does not affect whether EBS block data needs to be fetched from S3 on first read; that's an EBS-layer behavior, not a filesystem-layer one.
• D increasing the Linux read-ahead buffer improves sequential read throughput in steady state, but does nothing to pre-warm uninitialized EBS blocks - you'd still hit the cold-start penalty on first access.

Memory tip: Think of FSR as "pre-warming the oven" - without it, each block is fetched from S3 on first touch (cold oven); FSR ensures the volume is fully hydrated before any workload touches it, so you get full IOPS from the first I/O. The key phrase in the question is "restored from snapshot" + "initial performance lower than expected" - that pairing almost always points to FSR.

No community discussion yet for this question.