Examkin

Question

Difficulty: MediumOptimizing Compute and Storage Performance

An organization runs a batch processing application on Amazon EC2 instances in an Auto Scaling Group. The workload uses memory-optimized `r5.xlarge` instances, each attached to a `100 GiB100\text{ GiB}` Amazon EBS General Purpose SSD (`gp2`) volume. A Solutions Architect reviews Amazon CloudWatch metrics and notes the following: average CPU utilization is `85%85\%` during peak operations, average memory utilization is `12%12\%`, and the EBS volumes are experiencing I/O throttling at `300 IOPS300\text{ IOPS}`, leading to high disk I/O wait times. Which configuration change should the Solutions Architect recommend to optimize both compute and storage performance while minimizing costs?

  1. A
    Modify the Auto Scaling Group launch template to use `r5.2xlarge` instances, and request Application Load Balancer pre-warming from AWS Support to resolve the disk I/O latency during peak periods.
  2. B
    Configure an Amazon RDS Multi-AZ DB instance deployment to offload the active file processing and scale read queries to the standby database instance, reducing EC2 EBS workload.
  3. Modify the Auto Scaling Group launch template to use `c5.xlarge` instances, and upgrade the EBS volumes to `gp3` with a configuration of `3000 IOPS3000\text{ IOPS}.Answer
  4. D
    Migrate the application to run on AWS Fargate, and purchase EC2 Instance Savings Plans to optimize the Fargate compute costs.

Answer

Modify the Auto Scaling Group launch template to use `c5.xlarge` instances, and upgrade the EBS volumes to `gp3` with a configuration of `3000 IOPS3000\text{ IOPS}.
The correct answer identifies that the workload is compute-bound rather than memory-bound, meaning a switch from `r5` (memory-optimized) to `c5` (compute-optimized) instances reduces cost while providing the necessary CPU. Furthermore, the storage bottleneck is caused by the `3 IOPS/GiB3\text{ IOPS/GiB}` limitation of the `100 GiB100\text{ GiB}` `gp2` volume (yielding only `300 IOPS300\text{ IOPS}`). Moving to `gp3` provides a baseline of `3000 IOPS3000\text{ IOPS}` immediately, resolving the throttling and improving performance at a lower storage price point.

Step-by-Step Solution

1
Analyze the compute utilization profile.
CPU utilization is high (`85%85\%`) while memory utilization is low (`12%12\%`), showing the memory-optimized `r5` instances are over-provisioned for memory and under-provisioned for CPU.
Identifying the mismatch between actual resource utilization and instance type helps determine the correct instance family to choose.
2
Identify the storage bottleneck.
The `100 GiB100\text{ GiB}` `gp2` EBS volumes are limited to `300 IOPS300\text{ IOPS}` (based on the standard `3 IOPS/GiB3\text{ IOPS/GiB}` ratio), leading to I/O throttling.
Determining the baseline performance of the existing storage clarifies why the application is facing high disk wait times.
3
Evaluate remediation paths for compute and storage.
Switching to compute-optimized `c5.xlarge` instances matching the CPU needs reduces costs. Migrating to `gp3` EBS volumes provides a free baseline performance of `3000 IOPS3000\text{ IOPS}`, eliminating the I/O bottleneck.
Combining these two optimizations resolves both the compute resource allocation mismatch and the storage performance constraint at a lower cost.

Key Concept

Compute and Storage Performance Optimization
Estimated Time:2m 0s
Rate this question

Topics

Optimizing Compute and Storage Performance