# Overprovisioned Azure Cache for Redis instance Canonical: https://www.pointfive.co/efficiency-hub/inefficiencies/overprovisioned-azure-cache-for-redis-instance Azure Cache for Redis is billed at a fixed rate determined entirely by the provisioned tier and cache size - not by actual utilization. By: Aaran Bhambra Updated: 2026-09-28 [Cloud Efficiency Hub](https://www.pointfive.co/efficiency-hub) # Overprovisioned Azure Cache for Redis Instance The short version Azure Cache for Redis is billed at a fixed rate determined entirely by the provisioned tier and cache size - not by actual utilization. [Aaran Bhambra](https://www.linkedin.com/in/aaran-bhambra/) FinOps Engineer / DevOps Engineer @ WTW Azure service [Azure Cache for Redis](https://www.pointfive.co/efficiency-hub/cloud-services/azure-cache-for-redis) Category [Databases](https://www.pointfive.co/efficiency-hub/service-category/databases) Reference CER-0310 Type Overprovisioned Resource ## Explanation Why the waste happens and who it affects. A cache instance that consumes only a fraction of its available memory and throughput incurs the same cost as one running at full capacity. This means that when a cache is sized larger than the workload demands, the unused memory and throughput headroom represent pure waste with no corresponding benefit. Overprovisioning commonly occurs when teams size caches for anticipated peak loads that never materialize, or when workload patterns shift over time - such as after a migration, application refactor, or traffic decline - without a corresponding review of cache sizing. Because there is no option to stop or pause billing on a cache instance, and charges accrue continuously from the moment the cache is created until it is deleted, oversized caches quietly accumulate unnecessary costs around the clock. An important constraint compounds this issue: scaling down between tiers is not supported. An organization that initially provisions a Premium-tier cache but later determines that a Standard tier would suffice cannot simply downgrade in place - it must create a new cache at the appropriate tier and migrate data. This friction often delays right-sizing efforts and prolongs overspend. Azure Cache for Redis is also being retired: the Enterprise and Enterprise Flash tiers retire on March 31, 2027, and the Basic, Standard, and Premium tiers retire on September 30, 2028. Microsoft recommends migrating to Azure Managed Redis now. Because Azure Managed Redis SKUs are sized directly on memory and performance and include non-high-availability options for dev/test, the migration is the natural point to right-size rather than copying the current cache size. ## Billing model The pricing dimensions that drive this cost. Azure Cache for Redis billing is based on fixed, capacity-driven charges with no consumption-based component: - Caches are billed per-minute at a fixed hourly rate determined by the selected tier (Basic, Standard, Premium, Enterprise, or Enterprise Flash) and cache size, as detailed on the Azure Cache for Redis pricing page - Billing begins at cache creation and continues until the cache is deleted - there is no option to stop, pause, or hibernate a cache to reduce costs - The charge is identical whether the cache is fully utilized or sitting idle, making provisioned capacity the sole cost driver - Additional costs may apply for data persistence storage (Premium tier), geo-replication data transfer, and outbound data transfer - Reserved pricing with one-year or three-year commitments is available for the Premium tier, and for the Enterprise and Enterprise Flash tiers through a sales representative, offering discounts over pay-as-you-go rates; existing Azure Cache for Redis reservations are supported only until September 30, 2028 ## How to detect 7 checks to find it in your estate. - Identify cache instances where memory utilization has remained consistently low relative to provisioned capacity over a representative period - Review cache throughput and connection metrics to assess whether the provisioned size and tier exceed actual workload demand - Evaluate cache hit and miss ratios to determine whether the dataset stored in the cache justifies the provisioned memory size - Assess server load patterns over time to confirm whether the cache is operating well below its performance ceiling - Review whether any cache instances were originally provisioned for peak-load scenarios that no longer apply due to application changes or traffic shifts - Identify cache instances running on higher tiers (such as Premium or Enterprise) where the workload does not require tier-specific features like clustering, persistence, or geo-replication - Confirm whether any cache instances are no longer referenced by active applications and may be candidates for deletion ## How to fix 7 ways to remove the waste. - Downsize overprovisioned cache instances to a smaller size within the same tier that better aligns with observed utilization and workload requirements - Where a cache is running on a higher tier than necessary and does not use tier-specific features, create a new cache at the appropriate lower tier and migrate data - note that in-place scaling down between tiers is not supported - Delete cache instances that are no longer referenced by any active application or service - For Basic-tier caches used in development or testing, plan scaling operations during maintenance windows, as resizing causes downtime and complete data loss - Establish periodic right-sizing reviews to catch overprovisioned caches before costs accumulate, particularly after application refactors, traffic changes, or environment decommissions - Avoid new long-term Azure Cache for Redis reservations, since existing reservations are supported only until September 30, 2028 and a new three-year term would outlive the service; for stable, right-sized caches, evaluate one-year or three-year reserved pricing on the target Azure Managed Redis SKU after migration instead - Plan migration to Azure Managed Redis ahead of the retirement dates, choosing the target size from observed memory and throughput rather than the current cache size ## Documentation Vendor references for pricing and configuration. - [What is Azure Cache for Redis? - Azure Cache for Redis learn.microsoft.com](https://learn.microsoft.com/en-us/azure/azure-cache-for-redis/cache-overview) - [Pricing - Azure Cache for Redis azure.microsoft.com](https://azure.microsoft.com/en-us/pricing/details/cache/) - [Scale an Azure Cache for Redis instance - Azure Cache for Redis learn.microsoft.com](https://learn.microsoft.com/en-us/azure/azure-cache-for-redis/cache-how-to-scale) - [Best practices for scaling - Azure Cache for Redis learn.microsoft.com](https://learn.microsoft.com/en-us/azure/azure-cache-for-redis/cache-best-practices-scale) - [Azure Cache for Redis planning FAQs - Azure Cache for Redis learn.microsoft.com](https://learn.microsoft.com/en-us/azure/azure-cache-for-redis/cache-planning-faq) - [Monitor Azure Cache for Redis - Azure Managed Redis learn.microsoft.com](https://learn.microsoft.com/en-us/azure/redis/monitor-cache) - [Frequently asked questions (FAQ) on the retirement of Azure Cache for Redis - Azure Cache for Redis learn.microsoft.com](https://learn.microsoft.com/en-us/azure/azure-cache-for-redis/retirement-faq) ## Related inefficiencies [Browse the library](https://www.pointfive.co/efficiency-hub) - Azure SQL CER-0028 ### [Overprovisioned Compute Tier in Azure SQL Database](https://www.pointfive.co/efficiency-hub/inefficiencies/overprovisioned-compute-tier-in-azure-sql-database) Azure SQL Database resources are frequently overprovisioned due to default configurations, conservative sizing, or legacy requirements that no longer apply. This inefficiency appears across all deployment models: Single Databases may be... Databases - Azure Database for PostgreSQL - Flexible Server CER-0148 ### [Overprovisioned Azure Database for PostgreSQL Flexible Server](https://www.pointfive.co/efficiency-hub/inefficiencies/overprovisioned-azure-database-for-postgresql-flexible-server) Azure Database for PostgreSQL - Flexible Server often defaults to general-purpose D-series VMs, which may be oversized for many production or development workloads. Many PostgreSQL workloads do not need high sustained CPU and can run on... Databases - Azure SQL CER-0164 ### [Overprovisioned Storage in Azure SQL Elastic Pools or Managed Instances](https://www.pointfive.co/efficiency-hub/inefficiencies/overprovisioned-storage-in-azure-sql-elastic-pools-or-managed-instances) Azure SQL deployments often reserve more storage than needed, either due to default provisioning settings or anticipated future growth. Over time, if actual usage remains low, these oversized allocations generate unnecessary storage costs.... Databases --- Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.