An IoT data processing application runs on a fleet of Amazon EC2 instances in an Auto Scaling group. The instances ingest real-time sensor metrics and write raw telemetry logs to an attached Amazon EBS gp3 volume before compiling them. During periodic peak events, the application experiences severe write latencies and high CPU wait states on the EC2 instances, while CPU utilization remains under 40%. The current EBS gp3 configuration is at the default baseline performance of 3,000 IOPS and 125 MiB/s. Which of the following solutions will resolve the performance bottleneck in the most cost-effective manner?
- ARequest AWS Support to pre-warm the Application Load Balancer (ALB) to absorb the traffic spikes and prevent CPU wait state degradation.
- BProvision an Amazon RDS database with Multi-AZ enabled, and route the raw telemetry log writes directly to the standby database instance.
- Increase the provisioned IOPS and throughput on the existing EBS gp3 volumes to match peak workload requirements.Answer
- DConfigure the Auto Scaling group to decrease the cooldown period to allow rapid scale-out of instances to distribute the write operations.
Answer
Increase the provisioned IOPS and throughput on the existing EBS gp3 volumes to match peak workload requirements.
The combination of low CPU utilization and high CPU wait states indicates that the EC2 instances are blocked waiting for disk I/O operations to complete. Since gp3 volumes allow independent scaling of performance metrics, increasing the provisioned IOPS and throughput directly addresses this storage bottleneck without incurring the cost of provisioning additional storage capacity or launching unnecessary EC2 instances.
Step-by-Step Solution
Key Concept
EBS gp3 volumes support independent provisioning of storage capacity, IOPS, and throughput, allowing performance optimization without scaling storage size.