A finance company runs a business-critical application on current-generation Linux EC2 instances with a self-managed MySQL database that has heavy I/O. The application handles moderate traffic most of the month but slows during the final three days because of month-end reporting. The infrastructure already uses ELBs and Auto Scaling for compute. Which action will let the database handle the month-end load with the least performance impact?

Migrating to Amazon RDS for MySQL allows for easier scaling and management. Creating read replicas offloads read-heavy month-end reporting, distributing the load and improving performance without impacting the primary database. This is a common and effective strategy for handling predictable spikes in read traffic. Pre-warming ELBs and moving to a larger instance type addresses compute, not the database I/O bottleneck. Changing to GP2 volumes might not be sufficient for "heavy I/O" and doesn't offer the read scaling benefits of RDS replicas. Dynamically changing EBS volume types/sizes/IOPS with CloudWatch and Lambda is complex, carries risks of performance degradation during changes, and doesn't provide the read scaling of replicas. Replacing EBS volumes with PIOPS by snapshotting and reverting is a manual, high-downtime, and complex operation that doesn't scale reads effectively.