Azure Managed Redis Network performaces

Azure Managed Redis supports scaling down to compatible smaller SKUs, but network bandwidth, CPU capacity, and connection limits are separate constraints that must each be evaluated before selecting the destination SKU.^1^

CPU and network performance are related, but not the same

• CPU/vCPUs determine how much command processing, TLS processing, and connection handling the cache can perform. More vCPUs generally improve throughput and latency under load.
• Network bandwidth limits how quickly data can enter and leave the cache. Larger instances and higher-performance tiers generally have more bandwidth because of their underlying VM.
• Client connections have a separate per-SKU limit. A cache can run out of connections even when CPU and bandwidth have headroom.^2^

Consequently, higher CPU often accompanies higher network performance, but one does not measure or guarantee the other. Determine the active bottleneck independently:

Microsoft recommends preferring CPU over Server Load for node-level investigation. Cache Read and Cache Write are rate metrics measured in bytes per second.^3^

“Moderate,” “high,” and “highest” network categories

Treat these labels as relative SKU categories, not guaranteed fixed bandwidth values. Microsoft publishes observed bandwidth and benchmark figures for some configurations, but they are reference results rather than an SLA and might not map cleanly to those qualitative labels—especially for Flash Optimized.

For capacity planning:

1. In Azure portal → Managed Redis instance → Monitoring → Metrics, collect peak Cache Read, Cache Write, CPU, Connected Clients, latency, and memory usage over a representative busy period.
2. Compare peak Cache Read and Cache Write rates with the observed bandwidth information for the exact destination SKU.
3. Compare peak connections with that destination SKU’s connection limit.
4. Benchmark the destination configuration using the same payload sizes, command mix, connection count, pipelining, TLS, and cluster policy as production.^4^
5. Leave headroom for bursts and scaling activity rather than sizing directly to an observed maximum.

A smaller destination SKU normally must be tested using a separate temporary instance before downsizing; the current instance cannot emulate the destination SKU’s CPU, bandwidth, and shard configuration in place.

For an OSS-cluster-policy cache using TLS, a representative test command is:

memtier_benchmark \
  -h <cache>.<region>.redis.azure.net -p 10000 \
  -a "$REDIS_ACCESS_KEY" --tls --cluster-mode \
  --clients=50 --threads=6 --pipeline=10 \
  --ratio=0:1 --data-size=1024 --test-time=300

Do not use --tls-skip-verify in production. An access key supplied on the command line can also appear in process listings or shell history; use a short-lived test credential or Microsoft Entra authentication where practical.

Why Flash Optimized has no simple network classification

Flash Optimized performance depends heavily on whether values are in RAM or NVMe:

• Approximately 20% of capacity is RAM and 80% is flash.
• Hot values in RAM can perform nearly like in-memory tiers.
• Cold values must move from NVMe to RAM before access, increasing latency and reducing throughput.
• Empty or lightly populated benchmarks can therefore substantially overstate production performance.^5^

Benchmark Flash with a realistically filled dataset and production-like hot/cold access pattern. Network bandwidth alone does not describe its effective application performance.

Scale-down support and the documentation inconsistency

The scaling documentation explicitly supports scaling down, subject to these restrictions:

• Current memory usage must be below the destination capacity.
• The target must have a compatible vCPU and shard configuration.
• Only a subset of smaller SKUs may be offered.
• You cannot move between Flash Optimized and the in-memory tier family.
• Geo-replicated instances have additional restrictions.
• The underlying IP can change, so clients, firewalls, and NSGs should use the DNS name rather than a hard-coded IP.^1^

To see the targets available for your instance:

1. Open Azure portal → Azure Managed Redis → Scale.
2. Select a proposed Cache type.
3. If Save is disabled, that target is not a supported path from the current configuration.
4. Schedule the operation during low-to-moderate traffic while CPU, memory, and bandwidth still have spare capacity.

The architecture page still says scale-down is unsupported,^6^ while the dedicated scaling page documents and implements restricted scale-down. These pages are internally inconsistent; use the dedicated scaling page and the targets enabled in the portal’s Scale blade for the current supported operation.

References

1. Scale an Azure Managed Redis instance - Azure Managed Redis
2. What is Azure Managed Redis?
3. Azure Managed Redis monitoring data reference
4. Performance testing with Azure Managed Redis
5. Best practices for the Flash Optimized tier - Azure Managed Redis
6. Azure Managed Redis architecture