Azure Managed Redis - Creation Failed

Question

We are unable to provision Azure Managed Redis (Microsoft.Cache/redisEnterprise) in our staging subscription. The same configuration deploys successfully in our production subscription.

Environment:

• Region: East US (also tried East US 2 — same failure)
• Resource type: Microsoft.Cache/redisEnterprise
• SKUs attempted: Balanced_B0 (0.5 GB), Balanced_B3 (3 GB)
• High Availability: Enabled (also tried Disabled — same failure)
• Microsoft.Cache provider: Registered

What we tried:

1. Deployed via Bicep (ARM template) using Microsoft.Cache/redisEnterprise@2025-04-01 with Balanced_B0 SKU — Failed
2. Created manually via Azure Portal with identical settings — Failed
3. Changed resource names multiple times — Failed
4. Tried different region (East US 2) — Failed
5. Tried different SKU (Balanced_B3) — Failed
6. Verified no Deny policies exist (only Audit/AuditIfNotExists)

Error:

{
  "code": "ResourceDeploymentFailure",
  "target": "Microsoft.Cache/redisEnterprise/aic-amr-stg",
  "message": "The resource write operation failed to complete successfully, because it reached terminal provisioning state 'Failed'.",
  "details": [{"code": "OperationFailed", "message": "The operation failed."}]
}

Working production environment (same tenant):

• Same Bicep template, same config (Balanced_B0, HA Enabled, East US)
• Deploys and runs successfully.

Questions:

1. Is there a subscription-level entitlement or capacity restriction preventing Azure Managed Redis (redisEnterprise) provisioning in this subscription?
2. The error message is generic ("The operation failed") — is there a way to get more detailed diagnostic information?
3. Are there any known regional capacity constraints for Balanced-tier AMR in East US?

Additional context:

• The subscription has an existing Azure Cache for Redis (Standard) running successfully
• VM quota shows 100% usage for B3/Total Regional VMs in East US — could internal VM allocation for AMR be affected by this?
• Subscription type: Pay-as-you-go (not free tier or Dev/Test)

Answer 1

Hi @Saravanan Subramanian

This behavior is currently due to capacity constraints affecting Azure Managed Redis (Redis Enterprise) deployments in the target region. When capacity is unavailable, deployments may remain in provisioning for an extended period and eventually fail with a generic error, similar to what you are experiencing.

As a workaround, please consider the following:

Try deploying the Azure Managed Redis instance in an alternative region where capacity is available.

If possible, test with a different SKU, as availability can vary by SKU.

If deployment is required in the current region, we recommend retrying after some time, as capacity availability is dynamic and may change.

The issue is not related to your template, resource naming, provider registration, or subscription configuration.

We understand the impact this may have and appreciate your patience. Please let us know if you have any questions or if you need assistance validating deployment in an alternate region.

Answer 2

Azure Managed Redis (Microsoft.Cache/redisEnterprise) has some subscription and regional constraints, but the provided context only supports a limited set of conclusions.

1. Subscription-level entitlement or capacity restriction

Azure Managed Redis (redisEnterprise) is the same resource type referenced in the ARM/Bicep and CLI documentation. The context states that:

• Redis Enterprise (Microsoft.Cache/redisEnterprise) is also known as Azure Managed Redis and is deployed at the resource-group scope.
• It requires a Microsoft.Cache/redisEnterprise/databases child resource to function properly.

However, the context does not describe subscription-level entitlements, quota behavior, or capacity-based blocking conditions for redisEnterprise. It also does not describe differences between subscriptions in the same tenant. Therefore, no subscription-level entitlement or capacity restriction can be confirmed or denied from the provided material.

2. Getting more detailed diagnostics for the failure

From the ARM/Bicep and CLI guidance in the context:

• redisEnterprise resources can be deployed via ARM templates, Bicep, and CLI (az redisenterprise create).
• When using Bicep/ARM, failures surface as generic deployment errors (like ResourceDeploymentFailure) at the deployment layer.

The context does not provide a mechanism beyond standard ARM deployment diagnostics for obtaining deeper internal error details (for example, no mention of additional logs or specific redisEnterprise troubleshooting tooling). It only shows that redisEnterprise is deployed like other ARM resources and that deployments can fail and later be deleted (as in the Q&A example where a Redis resource was stuck in Creating and then deleted once it moved to Failed).

So, based on the context, the only supported diagnostic path is to:

• Use standard ARM/Bicep deployment diagnostics (deployment operations view) and CLI/PowerShell output to inspect the detailed error records.

No additional redisEnterprise-specific diagnostic channel is documented in the provided material.

3. Known regional capacity constraints for Balanced-tier AMR in East US

The context describes how to create Azure Managed Redis using CLI, ARM templates, and Bicep, and notes that:

• The cache name must be unique in the Azure region.
• location should be an Azure region near other services.
• sku should be chosen based on features and performance.

It does not document any regional capacity constraints or specific limitations for Balanced-tier SKUs in East US (or any other region). It also does not mention interaction with VM quotas or internal VM allocation for Azure Managed Redis.

Therefore, no regional capacity constraint information for Balanced_B0/B3 in East US can be provided from this context.

4. Other relevant points from the context

• For ARM/Bicep/Terraform: redisEnterprise requires a Microsoft.Cache/redisEnterprise/databases child resource to function properly. Any deployment must ensure that the parent redisEnterprise resource and its required database child resource are both defined and deployed.
• For CLI: az redisenterprise create requires name, location, resourceGroup, and sku. Microsoft Entra authentication and TLS 1.2–1.3 are enabled by default for new caches.
• A Q&A example shows that a Redis resource can be stuck in Creating and later move to Failed, after which it can be deleted; however, that example does not provide root-cause detail or capacity/entitlement explanations.

Because the context does not cover subscription-specific entitlement checks, internal capacity behavior, or detailed failure diagnostics for redisEnterprise, no further supported conclusions can be drawn.

---

References:

• Microsoft.Cache redisEnterprise 2025-04-01 (deployment-language-arm-template)
• Microsoft.Cache redisEnterprise 2025-08-01-preview (deployment-language-arm-template)
• Microsoft.Cache redisEnterprise 2022-01-01 (deployment-language-bicep)
• Microsoft.Cache redisEnterprise 2021-08-01 (deployment-language-bicep)
• Microsoft.Cache redisEnterprise 2021-03-01 (deployment-language-bicep)
• Microsoft.Cache redisEnterprise (deployment-language-terraform)
• Quickstart: Create an Azure Managed Redis cache using Bicep
• Manage an Azure Managed Redis cache using the Azure CLI (azure-managed-redis)
• Stuck in Creating / Failed provisioning Redis Cache - Microsoft Q&A