You are performing a Load Testing exercise on your application that is hosted on AWS. While testing your Amazon RDS MySQL DB Instance, you notice that your application becomes non-responsive when you reach 100% CPU utilization. Your application is read-heavy. Which methods would help scale your data-tier to meet the application’s needs? (Select Three)

Answer options:

A.Add Amazon RDS DB Read Replicas, and have your application direct read queries to them.
B.Add your Amazon RDS DB instance to Storage Auto Scaling, and set your desired maximum storage limit.
C.Use an Amazon SQS queue to throttle data going to the Amazon RDS DB Instance.
D.Use ElastiCache to cache common queries of your Amazon RDS DB.E.Shard your data set among multiple Amazon RDS DB Instances.
F.Enable Multi-AZ for your Amazon RDS DB Instance.

Correct Answers - A, D, and E
Amazon RDS Read Replicas provide enhanced performance and durability for database (DB) instances. This replication feature makes it easy to elastically scale out beyond the capacity constraints of a single DB Instance for read-heavy database workloads. You can create one or more replicas of a given source DB Instance and serve high-volume application read traffic from multiple copies of your data, thereby increasing aggregate read throughput.
For more information on Read Replicas, please refer to the link below.
https://aws.amazon.com/rds/details/read-replicas/
Sharding is a common concept to split data across multiple tables in a database. Let`s consider the following example.
Application Shards
In this example, we assume that our application currently doesn`t have enough load to need an application shard for each category, but we want to plan ahead with growth in mind. To make future growth easier, we make use of application shards. So our application code will act as if it has seven shards, but Hibernate will map those seven shards onto a smaller number of application shards. Each application shard will map to a MySQL database instance. By using this mapping, we can distribute the load to best suit our needs. For our application, assume that sports and entertainment generate as much load as the other five categories combined. These two categories will map to one application shard, and the other five categories will map to the other application shard. The two application shards will be mapped as follows.
For more information on sharding, please refer to the link below.
https://forums.aws.amazon.com/thread.jspa?messageID=203052
Amazon ElastiCache is a web service that makes it easy to deploy, operate, and scale an in-memory data store or cache in the cloud. The service improves the performance of web applications by allowing you to retrieve information from fast, managed, in-memory data stores instead of relying entirely on slower disk-based databases.
For more information on ElastiCache, please refer to the link below.
https://aws.amazon.com/elasticache/
Option B is incorrect because it is not an ideal way to scale a database. Amazon RDS Auto Scaling is to scale the storage capacity. If the storage capacity threshold is reached, then capacity will be scaled through Auto Scaling. RDS Auto Scaling does not look for the CPU utilization threshold. So it cannot be a solution for bottlenecks to read heavy databases.
Option C is not an ideal choice. Because our application is read-heavy and this is the cause of the problem we face with the RDS. So for this issue, Creating Read replicas, Elastic cache implementation, and Sharding the dataset are the ways through which we can tackle this issue. But if we have too many PUT requests for the DB that is causing the issue, we can create an SQS queue and store these PUT requests in the message queue and then process it accordingly.
Option F is invalid because the Multi-AZ feature is only a failover option.