Your application uses an ELB in front of an Auto Scaling group of web/application servers deployed across two AZs and a Multi-AZ RDS Instance for data persistence. The database CPU is often above 80% usage, and 90% of I/O operations on the database are reads. To improve the performance, you recently added a single-node Memcached ElastiCache Cluster to cache frequent DB query results. In the next weeks, the overall workload is expected to grow by 30%. Do you need to change anything in the architecture to maintain the high availability of the application with the anticipated additional load, and why?

Answer options:

A.Yes. You should deploy two Memcached ElastiCache clusters in different AZ`s with a change in application logic to support both clusters because the RDS instance will not be able to handle the load if the cache node fails.
B.No. If the cache node fails, the automated ElastiCache node recovery feature will prevent any availability impact.
C.Yes. You should deploy the Memcached ElastiCache Cluster with two nodes in the same AZ as the RDS DB master instance to handle the load if one cache node fails.
D.No. If the cache node fails, you can always get the same data from the DB without having any availability impact.

Answer - A
Option A is CORRECT because having two clusters in different AZs provides high availability of the cache nodes, removing the single point of failure. It will help caching the data; hence, reducing the overload on the database, maintaining the availability, and reducing the impact.
Option B is incorrect because, even though AWS will automatically recover the failed node, there are no other nodes in the cluster once the failure happens. So, the data from the cluster would be lost once that single node fails. For higher availability, there should be multiple nodes. Also, once the cache node fails, all the cached read load will go to the database, which will not be able to handle the load with a 30% increase to current levels. This means there will be an availability impact.
Option C is incorrect because provisioning the nodes in the same AZ does not tolerate an AZ failure. For higher availability, the nodes should be spread across multiple AZs.
Option D is incorrect because the very purpose of the cache node was to reduce the impact on the database by not overloading it. If the cache node fails, the database will not be able to handle the 30% increase in the load; so, it will have an availability impact.
More information on this topic from AWS Documentation:
http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/BestPractices.html
Mitigating Node Failures
To mitigate the impact of a node failure, spread your cached data over more nodes. Because Memcached does not support replication, a node failure will always result in some data loss from your cluster.
When you create your Memcached cluster, you can create it with 1 to 20 nodes or more by special request. Partitioning your data across a greater number of nodes means you’ll lose less data if a node fails. For example, if you partition your data across 10 nodes, any single node stores approximately 10% of your cached data. In this case, a node failure loses approximately 10% of your cache which needs to be replaced when a replacement node is created and provisioned.
Mitigating Availability Zone Failures
To mitigate the impact of an availability zone failure, locate your nodes in as many availability zones as possible. In the unlikely event of an AZ failure, you will lose only the data cached in that AZ, not the data cached in the other AZs.