How Do You Reduce Azure Cache for Redis Costs Without Compromising Security or Performance?

Azure Cache for Redis is one of the most widely deployed caching services on Azure, but it is also one of the most commonly over-provisioned. Organizations select Premium tier "just in case," size instances for peak traffic that occurs a few hours per week, and leave non-SSL ports open because "that's how it was set up."

With Microsoft announcing the retirement of Azure Cache for Redis by 2028 in favour of Azure Managed Redis, there is an urgent window to optimize current spend, harden security, and build a clean baseline for migration.

What Problem This Solves

Most Azure Cache for Redis deployments suffer from one or more of the following cost and security anti-patterns:

This guide provides a systematic approach to each of these problems, with specific Azure CLI commands, cost models, and implementation sequences.

Azure Cache for Redis Tier Comparison Reference

Before optimizing, you need a clear view of what each tier provides and what it costs. The following table summarizes the current Azure Cache for Redis and Azure Managed Redis tiers.

How It Works

Cost Optimization

Right-Sizing: Matching Tier and SKU to Actual Usage

Right-sizing is the single highest-impact optimization for Azure Cache for Redis. The decision process follows a clear flowchart:

Right-Sizing Decision Flowchart
================================

[Start] Does the workload use clustering, geo-replication, or VNET injection?
  |
  +-- YES --> Premium tier required. Right-size the SKU within Premium.
  |             |
  |             +-- Check: Is memory utilization consistently < 50%?
  |                   |
  |                   +-- YES --> Downsize to next smaller Premium SKU
  |                   +-- NO  --> Current SKU is appropriate
  |
  +-- NO  --> Does the workload require an SLA?
        |
        +-- YES --> Standard tier. Right-size the SKU within Standard.
        |             |
        |             +-- Check: Is memory utilization consistently < 50%?
        |                   |
        |                   +-- YES --> Downsize to next smaller Standard SKU
        |                   +-- NO  --> Current SKU is appropriate
        |
        +-- NO  --> Basic tier (dev/test only).
                      |
                      +-- Check: Is this a production workload?
                            |
                            +-- YES --> Move to Standard (SLA required)
                            +-- NO  --> Basic is acceptable for dev/test

Tier memory limits for reference:

Use Azure Monitor to query actual memory and CPU usage over the past 30 days. The following query returns the peak and average memory utilization:

# Query Azure Monitor metrics for Redis memory utilization (last 30 days)
az monitor metrics list \
  --resource "/subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Cache/redis/{name}" \
  --metric "usedmemorypercentage" \
  --interval PT1H \
  --start-time $(date -u -d '30 days ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --aggregation Maximum Average \
  --output table

If the maximum memory utilization over 30 days is below 50%, the instance is a strong candidate for downsizing. Audit Premium feature usage before downgrading tier:

# Audit Premium feature usage across all Redis instances
az redis list --output json | jq -r '
  .[] | select(.sku.family == "P") |
  {
    name: .name,
    resourceGroup: .resourceGroup,
    sku: .sku.name,
    shardCount: .shardCount,
    subnetId: (.subnetId // "none"),
    linkedServers: (.linkedServers | length),
    persistence: (if .redisConfiguration.rdbBackupEnabled == "true" then "enabled" else "disabled" end)
  }' | jq -s '.'

If shardCount is 0 or 1, subnetId is "none," linkedServers is 0, and persistence is "disabled," the instance is not using any Premium-exclusive features and can be downgraded to Standard tier.

Reservations: Committed-Use Discounts

Azure Reservations provide the second-largest cost lever for Redis. The discount structure is straightforward:

The decision framework should consider both the immediate savings and the service retirement timeline:

Reservation Decision Tree
=========================

[Start] Is the Redis instance expected to run for 12+ months?
  |
  +-- NO  --> Pay-as-you-go (no commitment)
  |
  +-- YES --> Is the workload stable (no planned migration in < 12 months)?
        |
        +-- NO  --> Pay-as-you-go or short-term savings plan
        |
        +-- YES --> Consider retirement timeline:
              |
              +-- Current date + 1 year < retirement date (2028)?
              |     |
              |     +-- YES --> 1-year reservation (up to 35% savings)
              |     +-- NO  --> Pay-as-you-go (migration imminent)
              |
              +-- Current date + 3 years < retirement date?
                    |
                    +-- YES --> 3-year reservation (up to 55% savings)
                    +-- NO  --> 1-year reservation maximum

Note: As of Feb 2026, a 1-year reservation still provides
~22 months of discounted usage before the 2028 retirement.
A 3-year reservation extends beyond the retirement window
and would require careful evaluation of Microsoft's refund/
transfer policy for retired services.

Automated Scaling

For workloads with predictable daily or weekly traffic patterns, scheduled scaling can reduce costs by scaling down during off-peak hours. Azure Cache for Redis supports tier and SKU changes via the management API, though the operation takes several minutes and involves a brief connectivity interruption.

The following PowerShell runbook can be deployed as an Azure Automation runbook with a recurring schedule:

# Azure Automation Runbook: Scheduled Redis Scaling
# Schedule: Scale down at 20:00 UTC, scale up at 06:00 UTC

param(
    [string]$ResourceGroupName = "rg-production",
    [string]$CacheName = "redis-app-prod",
    [string]$Action = "ScaleDown"  # ScaleDown or ScaleUp
)

Connect-AzAccount -Identity

$cache = Get-AzRedisCache -ResourceGroupName $ResourceGroupName -Name $CacheName

if ($Action -eq "ScaleDown") {
    # Scale from C3 (6 GB) to C2 (2.5 GB) during off-peak
    if ($cache.Sku -eq "Standard" -and $cache.Size -eq "C3") {
        Set-AzRedisCache -ResourceGroupName $ResourceGroupName \
            -Name $CacheName -Size C2
        Write-Output "Scaled down $CacheName from C3 to C2"
    }
}
elseif ($Action -eq "ScaleUp") {
    # Scale from C2 (2.5 GB) to C3 (6 GB) before business hours
    if ($cache.Sku -eq "Standard" -and $cache.Size -eq "C2") {
        Set-AzRedisCache -ResourceGroupName $ResourceGroupName \
            -Name $CacheName -Size C3
        Write-Output "Scaled up $CacheName from C2 to C3"
    }
}

Architecture Reassessment

Sometimes the most effective cost optimization is eliminating the Redis instance entirely. Two patterns are especially common:

Pattern 1: Redis Duplicating Cosmos DB

Many applications cache Cosmos DB results in Redis to reduce latency. But Cosmos DB with a properly tuned indexing policy and partition key strategy often delivers sub-10ms reads natively. The Redis layer adds cost, complexity, and a cache invalidation problem.

Before: App --> Redis Cache (P2, $650/mo) --> Cosmos DB ($400/mo)
         Total: $1,050/mo
         Latency: 2-5ms (cache hit), 15-25ms (cache miss)

After:  App --> Cosmos DB with optimized indexing ($450/mo)
         Total: $450/mo
         Latency: 5-10ms (consistent)

Savings: $600/mo (57% reduction)
Trade-off: Slightly higher p50 latency, but more consistent p99

Pattern 2: Premium Tier for Simple Caching

A common anti-pattern is deploying Premium P2 (13 GB, ~$650/mo) for a workload that stores 800 MB of session data with no clustering, persistence, or VNET requirements. Standard C3 (6 GB, ~$135/mo) provides identical functionality at 80% lower cost.

Before: Premium P2 (13 GB)  --> $650/mo
         Actual usage: 800 MB session data
         Premium features used: none

After:  Standard C3 (6 GB)   --> $135/mo
         Headroom: 5.2 GB available
         SLA: 99.9% (same as Premium for non-clustered)

Savings: $515/mo (79% reduction)

Alternative Messaging Backends

Redis is frequently used as a lightweight message broker via Pub/Sub or list-based queues. While this works, it lacks durability guarantees -- if the Redis instance restarts, in-flight messages are lost. Azure Service Bus provides a more robust alternative:

If Redis is used exclusively for messaging (no caching), migrating to Service Bus can eliminate the Redis instance entirely.

Cost Optimization Impact Summary

Security

Disable Non-SSL Port

Azure Cache for Redis exposes two ports: 6380 (TLS/SSL) and 6379 (non-SSL). Port 6379 transmits data and authentication credentials in cleartext. Despite being a known security risk, many production instances still have this port enabled because it was the default in early deployments.

The remediation sequence is:

# Step 2: Enforce TLS 1.2 minimum
az redis update \
  --name <cache-name> \
  --resource-group <rg-name> \
  --set minimumTlsVersion=1.2

# Step 3: Disable non-SSL port
az redis update \
  --name <cache-name> \
  --resource-group <rg-name> \
  --set enableNonSslPort=false

# Step 4: Rotate access keys (regenerate primary key)
az redis regenerate-key \
  --name <cache-name> \
  --resource-group <rg-name> \
  --key-type Primary

# Verify the configuration
az redis show \
  --name <cache-name> \
  --resource-group <rg-name> \
  --query "{name:name, nonSslPort:enableNonSslPort, tlsVersion:minimumTlsVersion}" \
  --output table

To enforce this across all subscriptions, deploy an Azure Policy that denies Redis instances with the non-SSL port enabled:

{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Cache/redis"
        },
        {
          "field": "Microsoft.Cache/redis/enableNonSslPort",
          "equals": "true"
        }
      ]
    },
    "then": {
      "effect": "deny"
    }
  },
  "parameters": {},
  "displayName": "Azure Cache for Redis should disable non-SSL port",
  "description": "Denies creation or update of Azure Cache for Redis instances with non-SSL port (6379) enabled. All connections must use TLS on port 6380."
}

Common Questions

1. Will downscaling Redis cause data loss?

Scaling within the same tier (e.g., Standard C3 to C2) does not cause data loss -- Azure migrates the data to the new instance. However, the operation takes 10-30 minutes and may cause brief connectivity interruptions. Scaling between tiers (Premium to Standard) requires creating a new resource and migrating data manually.

2. Can I use reservations if I plan to migrate to Azure Managed Redis?

Yes, but choose your term carefully. A 1-year reservation purchased in early 2026 will still provide ~22 months of discounted usage before the 2028 retirement. A 3-year reservation extends beyond the retirement window, so you would need to confirm Microsoft's refund or transfer policy for retired services. Generally, 1-year reservations are the safer choice given the retirement timeline.

3. How do I know if my Premium instance actually needs Premium features?

Run the Premium feature audit CLI command provided above. If shardCount is 0 or 1, subnetId is "none," linkedServers is 0, and persistence is disabled, the instance is not using Premium-exclusive features. Verify with the application team that no planned features depend on Premium capabilities before downgrading.

4. Is Azure Managed Redis ready for production?

Azure Managed Redis reached General Availability (GA) and is supported for production workloads. However, it uses the Valkey engine rather than Redis, so application compatibility should be validated. The migration is not in-place -- it requires a new resource and data transfer, making it a project rather than a simple upgrade.

5. What is the risk of disabling the non-SSL port?

The risk is that any client connecting on port 6379 without TLS will immediately fail. The mitigation is to audit all connection strings before making the change. Modern Redis client libraries (StackExchange.Redis, Lettuce, redis-py) all support TLS natively. The configuration change itself is instant and does not require a Redis restart.

6. Can I apply these optimizations across multiple tenants simultaneously?

Yes. MSPs can script the audit and right-sizing recommendations across all tenants using Azure Lighthouse or by iterating over subscriptions with the Azure CLI. The policy enforcement for non-SSL port can be applied at the Management Group level to cover all subscriptions at once.

7. How much does scheduled scaling actually save?

For a typical workload that is idle 12 hours per day and on weekends, scheduled scaling can reduce costs by 15-30%. The exact savings depend on the SKU difference and the scaling schedule. Note that scaling operations themselves take time and may cause brief interruptions, so this approach works best for workloads with clear off-peak windows.

8. Should I migrate to Azure Managed Redis now or wait?

Optimize your current deployment first. Migrating an over-provisioned, misconfigured deployment to Azure Managed Redis just transfers the waste to a new platform. Right-size, apply reservations for the remaining service life, harden security, and then migrate a lean, well-understood workload. This approach reduces both cost and migration risk.

9. What happens to my reservation when Azure Cache for Redis retires?

Microsoft has historically allowed reservation exchanges or refunds when services are retired, but this is not guaranteed. Check the current Azure reservation exchange policy before purchasing long-term commitments on services with announced retirement dates. A 1-year reservation is generally safe; a 3-year reservation should be discussed with your Microsoft account team.

10. How does Spotto help with Redis cost optimization?

Spotto continuously monitors your Azure Cache for Redis instances and identifies right-sizing opportunities, reservation savings, security gaps (like open non-SSL ports), and redundant cache layers. Rather than running one-off audits, Spotto provides ongoing visibility and alerts when instances drift from optimal configuration -- especially valuable for MSPs managing many tenants.

Use-Case and Scenario Coverage

Implementation Guidance

Pre-Optimization Audit Checklist

Preconditions

Required Inputs

Optimization-to-Migration Path

The following diagram shows how optimization flows into eventual migration:

Optimization-to-Migration Path
===============================

Phase 1: Audit (Week 1-2)
  [Inventory] --> [Metrics Collection] --> [Feature Audit] --> [Security Scan]
       |                |                       |                    |
       v                v                       v                    v
  Instance list    Usage data            Premium features      Non-SSL ports
                                          in use/unused         open/closed

Phase 2: Optimize (Week 3-6)
  [Right-Size SKU] --> [Downgrade Tier] --> [Apply Reservations] --> [Harden Security]
       |                     |                     |                       |
       v                     v                     v                       v
  Smaller SKU          Premium-->Standard    1-year commitment      TLS 1.2 + key rotation
  within tier          where possible        on stable workloads    + policy enforcement

Phase 3: Reassess Architecture (Week 7-10)
  [Cache necessity audit] --> [Messaging audit] --> [Eliminate/Replace]
       |                            |                       |
       v                            v                       v
  Remove redundant            Redis Pub/Sub -->       Decommission
  Redis-over-Cosmos           Service Bus             unused instances

Phase 4: Prepare for Migration (Week 11+)
  [Optimized baseline] --> [Compatibility testing] --> [Azure Managed Redis POC]
       |                          |                            |
       v                          v                            v
  Lean, right-sized         Valkey engine              Migration plan with
  deployment                validation                 known-good config

Rollout Approach

Failure Modes

Rollback Strategy

Every optimization should have a clear rollback path:

Optimize Now, Migrate Prepared

The 2028 retirement of Azure Cache for Redis is coming regardless of whether you optimize now. But the organizations that right-size, secure, and rationalize their Redis deployments today will have a massive advantage when migration time arrives:

Start with a simple inventory command to see the scope of your optimization opportunity:

# Inventory all Azure Cache for Redis instances across all subscriptions
az account list --query "[].id" -o tsv | while read sub; do
  az redis list --subscription "$sub" --output json 2>/dev/null | jq -r '
    .[] | [.name, .resourceGroup, .sku.name, .sku.family, .sku.capacity,
           (.enableNonSslPort // false), .minimumTlsVersion, .provisioningState] |
    @tsv'
done | column -t -s $'\t' -N "Name,ResourceGroup,SKU,Family,Capacity,NonSSL,TLS,State"

That single command will tell you which instances are over-provisioned, which have open non-SSL ports, and where to focus your optimization effort. From there, follow the decision flowcharts and implementation sequences in this guide to systematically reduce cost and harden security across your entire Redis estate.

Key Takeaways and Summary