ElastiCache Serverless (Valkey): Single read replica across AZs causing cross-AZ latency - Can we ensure one replica per AZ?

ElastiCache Serverless for Valkey automatically manages a replicated Multi-AZ architecture that's designed to handle availability zone failures transparently for your application. However, there are some important points to understand about how it works:

For ElastiCache Serverless caches, the replica distribution across AZs is managed automatically by the service. Unlike self-designed clusters where you can explicitly configure the number and placement of replicas, serverless caches handle this internally based on their own scaling algorithms.

ElastiCache Serverless automatically mitigates availability zone failures through its Multi-AZ architecture, but it doesn't guarantee that replicas will be placed in every AZ where you have subnets defined. The service optimizes for availability and performance based on its internal metrics and algorithms.

Regarding your specific questions:

• It's not currently possible to explicitly configure ElastiCache Serverless to maintain one read replica per AZ. The replica placement is managed automatically by the service.

• The exact criteria for when ElastiCache Serverless spawns additional replicas across multiple AZs isn't publicly documented in detail. The service uses internal algorithms to determine when to scale and where to place replicas based on factors like load, traffic patterns, and availability requirements.

• There are no published thresholds or metrics that you can monitor to predict when additional replicas will be created across AZs. The scaling decisions are handled internally by the service.

For your use case with latency concerns, you might want to consider:

1. If consistent low latency across all percentiles is critical for your application, you might need to evaluate using a self-designed ElastiCache cluster instead of Serverless, as this would give you more control over replica placement.

2. With self-designed clusters, you can explicitly configure replicas per shard and ensure they're distributed across multiple AZs to minimize cross-AZ traffic.

3. For self-designed clusters with Multi-AZ enabled, you need to ensure you have at least one replica per shard, and you can distribute your nodes across as many Availability Zones as possible to mitigate AZ failures.
   Sources
   Resilience in Amazon ElastiCache - Amazon ElastiCache
   Amazon ElastiCache Well-Architected Lens Reliability Pillar - Amazon ElastiCache
   Creating a cluster for Valkey or Redis OSS - Amazon ElastiCache
   Valkey or Redis OSS nodes and shards - Amazon ElastiCache