A company runs its SAP ERP system on AWS using a multi-tier architecture. The SAP application servers are in an Auto Scaling group across two Availability Zones, and the SAP HANA database runs on a single large EC2 instance (r5.24xlarge) with 768 GB of memory and EBS Provisioned IOPS SSD (io1) volumes. The operations team recently noticed that the database performance degrades intermittently during peak business hours. CloudWatch metrics show that the database instance's CPU utilization remains below 40%, but the ReadLatency and WriteLatency for the EBS volumes spike above 10 ms during these periods, and the VolumeQueueLength metric increases significantly. The database instance uses a single EBS volume for /hana/data and another for /hana/log. The team has already verified that there are no network bottlenecks and that the SAP application servers are not overwhelming the database with queries. What is the MOST likely cause of the latency spikes, and what action should be taken?
Upgrading to a Nitro-based instance like r5b.24xlarge provides higher EBS bandwidth and dedicated hardware for EBS, reducing latency and queueing, which directly addresses the issue of EBS volume saturation.
Why this answer
The symptoms indicate that the EBS volumes are experiencing queueing due to insufficient I/O performance. The r5.24xlarge instance uses the Xen hypervisor, which has lower EBS bandwidth compared to Nitro-based instances like r5b.24xlarge. Upgrading to a Nitro instance provides dedicated EBS bandwidth and lower latency, addressing the latency spikes.
Option A is incorrect because st1 (throughput optimized) is not suitable for low-latency database workloads; it is designed for large sequential I/O. Option B is incorrect because adding more application servers would increase the database load, exacerbating the issue. Option C is incorrect because EBS encryption does not improve I/O performance.