How can we improve Azure Cache?

Add data persistence and VNET support in Standard Tier

The current plan design is completely unrealistic for real deployment:

1. Persistence is too important for many situations, for example using redis as a queue for job runner which is very common practice
2. VNET protection is also basic requirement. Read from redis:
https://redis.io/topics/security

REDIS on its own is not designed to work in public network, with or without SSL. Primary reason is being there is no rate limit for such cache, thus making brute force extremely efficient to ***** system password.

I think with these 2 issues resolved on Standard tier (and most people really dont need premier tier, again totally unrealistic size, instead people will need a few standard for segregation) then the product will be usable. In case if you did not peek over the wall - none of these is issue with AWS ElasticCache which is Redis offering as well.

39 votes
Vote
Sign in
(thinking…)
Sign in with: Microsoft
Signed in as (Sign out)
You have left! (?) (thinking…)
Van Pan shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

1 comment

Sign in
(thinking…)
Sign in with: Microsoft
Signed in as (Sign out)
Submitting...
  • Tim Lovell-Smith MSFT commented  ·   ·  Flag as inappropriate

    The password for Azure redis cache is generated using a cryptographic random generator and is sufficiently long so that it is not practical to brute force the password.

Feedback and Knowledge Base