Azure Managed Redis deployment fails with AllocationFailed in East US 2 due to insufficient capacity

Saikumar Polavaram 20 Reputation points
2026-07-21T00:07:15.8366667+00:00

I am trying to deploy an Azure Managed Redis instance in the East US 2 region using Azure CLI and Bicep.

However, the deployment fails with the following error:


I have already retried the deployment multiple times, but I receive the same error.

I have a few questions:

  1. Is this a temporary capacity issue in the East US 2 region for Azure Managed Redis?
  2. Is there a way to check which Azure Managed Redis SKUs or sizes currently have available capacity in this region?
  3. Are there any recommended SKUs or deployment configurations that are more likely to succeed?
  4. My organization requires deployment in East US 2. If changing the region is not an option, what is the recommended approach to resolve this issue?
  5. Is opening an Azure Support ticket the only way to request additional capacity, or are there other alternatives?

Any guidance or recommendations would be greatly appreciated.

Thank you

Azure Cache for Redis
Azure Cache for Redis

An Azure service that provides access to a secure, dedicated Redis cache, managed by Microsoft.


2 answers

Sort by: Most helpful
  1. Ganesh Chelluri 90 Reputation points Microsoft External Staff Moderator
    2026-08-02T07:08:41.7433333+00:00

    Hi @Saikumar Polavaram ,

    This one isn't your Bicep or CLI.

    Your template passed validation and got all the way to the allocation step, so the config is fine - East US 2 just can't allocate that Redis size right now. It's a regional capacity constraint, not a permanent thing, but I can't give you an ETA. On your questions: There's no way to check free capacity yourself. AMR has no real-time inventory API. listSkusForScaling needs an existing cluster and only shows what you can scale to, and the "available by region" page only means the SKU is offered there, not that it's free today.

    No safer SKU either, but worth a try: the tiers sit on different hardware families (Memory Optimized, Balanced, Compute Optimized), so switching family is a better test than just changing size. For a quick non-prod check you can also create with --high-availability Disabled, since that's a single node instead of two and usually slips through. Don't do that for prod though - no replication, lower SLA, and you can't change it later. Also delete the failed resource before each retry, otherwise it leaves DNS and private endpoint leftovers behind.

    If East US 2 is non-negotiable, raise a support request asking for a regional capacity review for Microsoft.Cache/redisEnterprise in East US 2. Include your subscription ID, the SKUs and sizes you tried with UTC timestamps, the correlation/request IDs from the failed deployments, and the full error. That's the only route to get capacity added - a quota increase won't help here, quota and capacity are two different systems. If you can, spin the same SKU up in East US or Central US in the meantime just to confirm it's region-specific and have a fallback ready. Drop the SR number here once you've raised it and I'll keep following the thread.

    Was this answer helpful?

    0 comments No comments

  2. Christos Panagiotidis 3,301 Reputation points
    2026-07-21T06:16:56.5566667+00:00

    AllocationFailed with “insufficient capacity” means the requested Azure Managed Redis size cannot currently be allocated in East US 2; it is not a Bicep or CLI syntax failure. Microsoft publishes regional service availability, but not real-time inventory of free Redis capacity, so successful validation does not guarantee provisioning.

    Record the correlation ID, UTC time, region, SKU, capacity, high-availability setting, and instance count. Test the same template with another supported size or performance tier to separate template issues from capacity, and retry later because inventory can change. There is no universally preferred SKU: choose one that meets documented memory and throughput requirements. If East US 2 is mandatory and alternatives fail, open an Azure Support request for Azure Managed Redis provisioning or capacity and include those details. Support can confirm the regional constraint and available options; repeated CLI retries or a quota increase cannot reserve unavailable platform capacity.

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.