Scope changes to AMR only and fix HA sizing guidance

- Remove ACRE file changes (enterprise-tiers and cache memory management)
  since those docs are for ACRE only, not AMR
- Fix misleading HA capacity guidance: SKU memory limits already account
  for replication, customers should size based on actual dataset not 2x
- Add recommendation to monitor Used Memory Percentage instead of raw
  Used Memory since it already accounts for the SKU limit
- Simplify MEMORY USAGE command guidance

Co-authored-by: Copilot <[email protected]>

Author: 2 people

articles/azure-cache-for-redis/cache-best-practices-enterprise-tiers.md

@@ -205,15 +205,6 @@ Many customers want to use persistence to take periodic backups of the data on t
 
 The E1 SKU is intended for dev/test scenarios, primarily. E1 runs on smaller [burstable VMs](/azure/virtual-machines/b-series-cpu-credit-model/b-series-cpu-credit-model). Burstable VMs offer variable performance based on how much CPU is consumed. Unlike other Enterprise SKU offerings, you can't _scale out_ the E1 SKU, although it's still possible to _scale up_ to a larger SKU. The E1 SKU also doesn't support [active geo-replication](cache-how-to-active-geo-replication.md).
 
-## Memory management
-
-For guidance on understanding memory usage, capacity planning, and eviction policies, see [Memory management for Azure Managed Redis](/azure/redis/best-practices-memory-management). Key points for Enterprise tier caches:
-
-- The **Used Memory** metric includes memory from both primary and replica shards when High Availability is enabled, which can make the value appear twice as large as the actual dataset.
-- Each key has internal metadata overhead beyond the raw value size. For workloads with many small keys, this overhead can be significant.
-- Use the Redis `MEMORY USAGE` command to check the exact per-key memory cost.
-
 ## Related content
 
-- [Memory management for Azure Managed Redis](/azure/redis/best-practices-memory-management)
 - [Development](cache-best-practices-development.md)

articles/azure-cache-for-redis/cache-best-practices-memory-management.md

@@ -59,8 +59,6 @@ Eviction can increase server load and memory fragmentation. For more information
 
 - [Memory policies](cache-configure.md#memory-policies)
 - [Troubleshoot high memory usage](cache-troubleshoot-timeouts.md#high-memory-usage)
-- [Best practices for Enterprise tiers](cache-best-practices-enterprise-tiers.md)
-- [Memory management for Azure Managed Redis](/azure/redis/best-practices-memory-management)
 - [Best practices for scaling](cache-best-practices-scale.md)
 - [Best practices for development](cache-best-practices-development.md)
 - [Azure Cache for Redis development FAQs](cache-development-faq.yml)

articles/redis/best-practices-memory-management.md

@@ -29,15 +29,15 @@ When planning the memory you need, account for these factors beyond just the raw
 - **Per-key overhead**: Each key stored in Redis includes internal metadata (pointers, type info, expiration tracking). This overhead is typically 50 to 100 bytes per key, depending on the key name length and value type. For large numbers of small keys, this overhead can be significant.
 - **Key names**: The memory used to store your key names adds up at scale. Shorter key names help reduce memory usage.
 - **Expiration tracking**: Keys with a TTL set consume extra memory for expiration bookkeeping.
-- **High Availability replication**: With High Availability enabled, the dataset is replicated, roughly doubling the total memory consumed. Plan for approximately twice your expected dataset size.
+- **High Availability replication**: With High Availability enabled, the dataset is replicated. The **Used Memory** metric reflects both primary and replica memory, but the SKU memory limit already accounts for this. You don't need to choose a larger SKU to accommodate replication — select a SKU based on your actual dataset size.
 
 To check the exact memory cost of a specific key, use the Redis [`MEMORY USAGE`](https://redis.io/commands/memory-usage) command:
 
 ```
 MEMORY USAGE <your_key_name>
 ```
 
-This command returns the total bytes consumed by a key, including all internal overhead. Multiply the result by your total key count and by two (if High Availability is enabled) for a practical memory estimate.
+This command returns the total bytes consumed by a key, including all internal overhead. Use this to validate your per-key memory estimates against actual usage.
 
 ## Eviction policy
 
@@ -49,7 +49,9 @@ Set an expiration value on your keys. An expiration removes keys proactively ins
 
 ## Monitor memory usage
 
-Add alerting on the **Used Memory Percentage** metric to ensure that you don't run out of memory and have the chance to scale your cache before seeing issues. If your **Used Memory Percentage** is consistently over 75%, consider increasing your memory by scaling to a higher tier. For information on tiers, see [Architecture](architecture.md#sharding-configuration).
+We recommend monitoring the **Used Memory Percentage** metric rather than raw **Used Memory**. The percentage metric already accounts for your SKU's total memory limit, including High Availability replication, so it gives you a straightforward view of how close you are to capacity without needing to mentally adjust for replica memory.
+
+Add alerting on **Used Memory Percentage** to ensure that you don't run out of memory and have the chance to scale your cache before seeing issues. If your **Used Memory Percentage** is consistently over 75%, consider increasing your memory by scaling to a higher tier. For information on tiers, see [Architecture](architecture.md#sharding-configuration).
 
 ## Related content