Exam AWS Certified Solutions Architect - Associate SAA-C03 topic 1 question 593 discussion

It seems like "Multi-AZ Redis replication group" (A) and "Multi-AZ Redis cluster" (C) are different wordings for the same configuration. However, "to minimize the impact of a node failure, we recommend that your implementation use multiple nodes in each shard" - and that is mentioned only in A.

Multi-AZ is only supported on Redis clusters that have more than one node in each shard (node groups). https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/AutoFailover.html#:~:text=node%20in%20each-,shard.,-Topics

high availability at the node level = shard and Multi A-Z = region level

did client ask for improved performance, unfortunately they didn't, so C is good to have but not part of the business requirement. My answer A.

A Multi-AZ is only option. It is regional service so can use backup to replicate but can not use for failover.

C. Use a Multi-AZ Redis cluster with more than one read replica in the replication group. In summary, option C, using a Multi-AZ Redis cluster with more than one read replica, is designed to provide both node-level and AWS Region-level high availability, making it the most suitable choice for the given requirements.

the replication structure is contained within a shard (called node group in the API/CLI) which is contained within a Redis cluster A shard (in the API and CLI, a node group) is a hierarchical arrangement of nodes, each wrapped in a cluster. Shards support replication. Within a shard, one node functions as the read/write primary node. All the other nodes in a shard function as read-only replicas of the primary node.

C is correct. Not A because in replication mode, shard have multiple nodes by default. B and D not correct because that not an option

its c for me

C: Cluster mode will create multiple shards, when node level failure, request of shard that not impacted will not has any performance impact. If the issue at AZ level, spread traffic between multiple shards shall also reduce the performance degrade.

c. Option A is not ideal because it doesn't mention read replicas, and it's generally better to have read replicas for both performance and high availability. Option B mentions Redis append-only files (AOF), but AOF alone doesn't provide high availability or fault tolerance. Option D mentions Auto Scaling, but this doesn't directly address high availability at the Region level or data replication

Multi-AZ is only supported on Redis clusters that have more than one node in each shard.

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.html

Multi-AZ replication groups provide automatic failover between AZs if there is an issue with the primary AZ. This provides high availability at the region level

Enabling ElastiCache Multi-AZ with automatic failover on your Redis cluster (in the API and CLI, replication group) improves your fault tolerance. This is true particularly in cases where your cluster's read/write primary cluster becomes unreachable or fails for any reason. Multi-AZ with automatic failover is only supported on Redis clusters that support replication

I would go with A too I would go with A, Using AOF can't protect you from all failure scenarios. For example, if a node fails due to a hardware fault in an underlying physical server, ElastiCache will provision a new node on a different server. In this case, the AOF is not available and can't be used to recover the data.

Hate to say this, but I read the two docs linked below, and I still think the answer is A. Turning on AOF helps in data persistence after failure, but it does nothing for availability unless you use Multi-AZ replica groups.