Elasticache(redis) cluster mode access issues

Hey, folks!

We’ve set up boundary for secure connections to our elasticcache multinode clusters.
Boundary target hosts are aws elasticcache(redis) configuration endpoints
Keys are distributed among different nodes, there is no node which stores all the keys in a cluster.
Tunnel is accessible on localhost port 7000, direct access to elasticcache is restricted by security groups.
When we connect to configuration endpoint and try to get sample redis keys, most of the time I get errors like:

MOVED 10116 redis7-prodlike-eu-central-1-redis-0002-001.redis7-prodlike-eu-central-1-redis.3gcxfr.euc1.cache.amazonaws.com:7000

But sometimes I get the key value back.
Seems like this it depends to the result on configuration endpoint DNS resolution. Here is sample of two different responses on the same command via boundary tunnel:

redis-cli --tls -h localhost -a PASS -p 7000 --user USER get mykey23
MOVED 10116 redis7-prodlike-eu-central-1-redis-0002-001.redis7-prodlike-eu-central-1-redis.3gcxfr.euc1.cache.amazonaws.com:7000

redis-cli --tls -h localhost -a PASS -p 7000 --user USER get mykey23

Using redis-cli with -c flag is not an option for us, because it tries direct access to nodes while following redirect, and we have tunnel to only one(via configuration endpoint fqdn) on localhost
There is an option to create target with hostset that include every nodes, but this will still require manual switching between targets.

Here is the same problem in goteleport:

The root of the problem is in how redis clients work with clusters, it needs direct access to every node and nodes redirect clients to other nodes when the don have requested key.
The protocol itself seems to be bastion unfriendly

So, the question is - Is there any recommended schemes/guides for accessing elasticcache clusters via boundary?
Or maybe somebody already dealt with the issue? I’d be grateful for any advice


We don’t have a particular solution for this yet, although something coming down the pipeline later may well help. It does seem to be in large part the protocol being bastion unfriendly as you said; in Vault we transparently forward requests from standby nodes to the active node and return the results as necessary to make it LB/bastion friendly but that is something that would have to be implemented within Redis :-/