A company has two general purpose Amazon EC2 instances that run a software package. Each EC2 instance is attached to its own 500 GiB General Purpose SSD (gp2) Amazon Elastic Block Store (Amazon EBS)…

Question

Options

• AMigrate the attached EBS volumes to Throughput Optimized HDD (st1) EBS volumes.
• BConfigure Amazon ElastiCache integration on the EC2 instances.
• CMigrate the workload to two storage optimized EC2 instances.
• DMigrate the attached EBS volumes to General Purpose SSD (gp3) EBS volumes. Provision the

• A
  3% (1)
• B
  10% (3)
• C
  6% (2)
• D
  81% (25)

Explanation

Option D is correct because gp3 EBS volumes allow you to independently provision IOPS up to 16,000 (vs. gp2's maximum of 16,000 tied to volume size), and crucially, gp3 decouples IOPS from storage size - you can provision exactly the IOPS needed (5x the current limit) without resizing the volume, while still providing the durable, per-instance block storage the software requires.

Why the distractors are wrong:

• A (st1 HDD): Throughput Optimized HDD volumes are optimized for sequential throughput (streaming large data), not random IOPS - switching to st1 would make IOPS performance worse, not better.
• B (ElastiCache): ElastiCache is an in-memory caching service, not durable storage. It doesn't replace EBS and wouldn't solve the IOPS bottleneck on the persistent storage layer.
• C (Storage optimized instances): Storage optimized instances (i3/i4i) use local NVMe SSDs, which are ephemeral - data is lost if the instance stops or terminates, violating the "durable storage" requirement.

Memory tip: Think of gp3 as "gp2 unchained" - gp2 ties IOPS to volume size (3 IOPS/GiB), while gp3 lets you set IOPS freely and independently. Whenever a question mentions hitting IOPS limits on gp2 with a need to scale, gp3 with provisioned IOPS is almost always the answer.

No community discussion yet for this question.