A SysOps administrator manages an Amazon RDS for MySQL instance that experiences high CPU utilization during business hours. The application is read-heavy. Which action will most effectively improve performance and reduce cost?
Trap 1: Enable Multi-AZ deployment.
Multi-AZ deployment creates a synchronous standby replica in a different Availability Zone, but this standby is not active for serving reads or writes; it exists only for automatic failover. Because the primary instance continues to process all application traffic, enabling Multi-AZ does not reduce CPU utilization on the primary. It improves high availability and durability, not read performance, and therefore doesn't address a CPU bottleneck caused by read-heavy workloads.
Trap 2: Scale up the instance size to a larger instance class.
Scaling up to a larger instance class, such as moving from db.m6g.large to db.m6g.xlarge, vertically increases the vCPU and memory available to the primary instance. While this can temporarily lower CPU utilization, it is a costly approach because the entire primary is resized, and it does not specifically separate read traffic from write traffic. For a read-heavy workload, distributing reads onto a read replica provides equivalent CPU relief at a lower incremental cost than scaling the primary and is the more cost-optimized solution.
Trap 3: Enable automated backups.
Automated backups create daily snapshots of the DB instance and stream transaction logs to Amazon S3 for point-in-time recovery, typically within a reserved maintenance window. These backup operations run in the background and may actually add temporary I/O and CPU overhead on the primary instance during the backup window. They do not provide any additional compute capacity for serving queries, so enabling automated backups has no effect on the persistent CPU utilization caused by application read traffic.
- A
Enable Multi-AZ deployment.
Why wrong: Multi-AZ deployment creates a synchronous standby replica in a different Availability Zone, but this standby is not active for serving reads or writes; it exists only for automatic failover. Because the primary instance continues to process all application traffic, enabling Multi-AZ does not reduce CPU utilization on the primary. It improves high availability and durability, not read performance, and therefore doesn't address a CPU bottleneck caused by read-heavy workloads.
- B
Scale up the instance size to a larger instance class.
Why wrong: Scaling up to a larger instance class, such as moving from db.m6g.large to db.m6g.xlarge, vertically increases the vCPU and memory available to the primary instance. While this can temporarily lower CPU utilization, it is a costly approach because the entire primary is resized, and it does not specifically separate read traffic from write traffic. For a read-heavy workload, distributing reads onto a read replica provides equivalent CPU relief at a lower incremental cost than scaling the primary and is the more cost-optimized solution.
- C
Add a read replica.
A read replica is an asynchronous MySQL replica that continuously syncs changes from the primary and can serve read-only traffic, including SELECT queries and reporting workloads. By routing non-critical reads to the replica, the primary's CPU cycles are freed up for write operations, reducing overall CPU utilization on the primary instance. This is a cost-effective scale-out approach because you add a smaller replica instance rather than resizing the primary, and read replicas can be promoted or removed as demand changes.
- D
Enable automated backups.
Why wrong: Automated backups create daily snapshots of the DB instance and stream transaction logs to Amazon S3 for point-in-time recovery, typically within a reserved maintenance window. These backup operations run in the background and may actually add temporary I/O and CPU overhead on the primary instance during the backup window. They do not provide any additional compute capacity for serving queries, so enabling automated backups has no effect on the persistent CPU utilization caused by application read traffic.