Azure Cache for Redis is on a retirement clock. The Enterprise tier closed to new creation earlier this year, and the replacement product is Azure Managed Redis. So the migration path is not optional for anyone who needs a current Redis version on Azure.
On 29 September 2026, the replacement would not place in West Europe. Nor in North Europe. Twenty-four attempts, twenty-four refusals.
This is what we measured, what we could not make work, and what we did instead.
The refusals
One ordinary pay-as-you-go subscription. One ARM template, unchanged between regions. Five sizes spanning the Balanced, Memory Optimized and Compute Optimized tiers, each submitted with high availability enabled and disabled.
| West Europe | North Europe | |
|---|---|---|
| Attempts | 14 | 10 |
| Created | 0 | 0 |
| Error | InsufficientCapacity | InsufficientCapacity |
| Stage | allocator | allocator |
| Time to refuse | 33 to 34 seconds | 33 to 34 seconds |
The message was the same every time:
Request failed due to insufficient capacity. Retry using a different Azure Managed Redis size or region.
Two details in that table matter more than the count.
The refusals came from the allocator, not from preflight. A quota problem, an entitlement problem or an unsupported configuration is rejected earlier and with a different code. Reaching the allocator means Azure accepted the request as valid, went looking for somewhere to put the cluster, and did not find one.
The timing was consistent. Thirty-three to thirty-four seconds, every attempt, with a single forty-two second outlier. That is the shape of a placement search that runs and comes back empty, not a transient error.
The control
The same subscription, the same template and the same day, pointed at five other regions:
| Region | Result | Time |
|---|---|---|
| Belgium Central | placed | 7 to 9 minutes |
| France Central | placed | 7 to 9 minutes |
| UK South | placed | 7 to 9 minutes |
| UK West | placed | 7 to 9 minutes |
| Poland Central | placed | 7 to 9 minutes |
Five for five, first time. That is the part that makes the West Europe result a placement finding rather than an account problem.
On paired regions
North Europe is West Europe's paired region. It is worth being precise about what that does and does not mean here.
Region pairing is a platform construct. It governs things like sequential platform updates and geo-redundant storage replication. It does not mean the allocator holds spare stock in the pair, and nothing here suggests existing caches in either region were affected. They were not. This is about creating something new.
The practical consequence is narrower but still worth knowing: if your recovery plan involves standing up a new cache in the paired region, that assumption is worth testing before you need it, not during an incident. Redis disaster recovery normally relies on geo-replication between instances that already exist, which is a different mechanism and not affected by any of this.
Why the obvious fallbacks did not help
The instinct when a new product will not place is to fall back to the old one. That did not work either, for two separate reasons.
Azure Cache for Redis Enterprise is closed to new creation. Preflight refuses it in about two seconds, in both regions, with a message pointing at the retirement:
Creation of new Azure Cache for Redis Enterprise resources is no longer supported. Azure Cache for Redis Enterprise is retiring, please create Azure Managed Redis instead.
The classic Basic, Standard and Premium tiers cap at Redis 6.0. We submitted all three
at 7.4, 7.2 and 6.0. Both 7.x requests were rejected by the resource provider as an
invalid redisVersion, and all three tiers provisioned at 6.0 and reported 6.0 on the
resource afterwards.
If your workload needs Redis 7, the old product is not a fallback. It is a different version of Redis.
The workaround
A private endpoint lives in a subnet. The resource it points at does not have to be in the same region.
So the cache went into Belgium Central, and its private endpoint went into the West Europe virtual network. A private DNS zone in that VNet resolves the cache hostname to the local endpoint address. Clients in West Europe connect privately, over the same network path they would have used, with no peering and no public exposure.
This is a supported Private Link pattern rather than a trick. It is also the reason the build was not blocked for a week.
What the hop costs
The obvious question is what you pay in latency for putting the data in another country, and the obvious failure mode is to guess. We measured it.
Three runs, overlapping in time so they shared network conditions: the cache from a VM in its own region, the same cache from a VM in West Europe through the cross-region endpoint, and a raw network round trip between the two VMs as a control. 34,200 samples.
| Reading | |
|---|---|
| Added latency per command, cross-region | 3.4 ms |
| Difference against the raw network control | 66 microseconds |
| Connection setup, same region | 8.27 ms |
| Connection setup, cross-region | 18.64 ms |
The first two lines are the finding. The cross-region hop costs one network round trip and essentially nothing else. The private endpoint, the DNS indirection and the Private Link path add no measurable overhead of their own. What you pay is distance, and distance in this pair is 3.4 milliseconds.
The third and fourth lines are the warning. Opening a connection costs roughly three round trips, because of the TCP handshake and the TLS negotiation on top of it. Cross-region, that is over 18 milliseconds every time a client opens a connection.
So the decision rule is about pooling, not geography. A client that holds its connections pays 3.4 ms per command. A client that opens a connection per request pays that, plus more than 18 ms of setup, on every request. If your application is the second kind, fix that before you worry about which country the cache is in.
That cache ran with high availability disabled, which is fine for a measurement and is not what you would run in production. Treat the numbers as the cost of the network path, not as a production benchmark.
A note on what you cannot ask Azure
One thing that made the investigation slower than it should have been: there is no reliable way to query where a SKU can actually be deployed.
The resource SKUs API, at the time of testing, listed no Managed Redis tiers at all for West Europe, while still offering the retired Enterprise tiers in thirty-four locations. UK West was absent from the response entirely, and a cache built there first time.
The API is being populated progressively, so the specific numbers will move. The general point will not: the list of things Azure says you can deploy somewhere and the list of things that will actually deploy there are not the same list. The only reliable test is to try.
That is the same conclusion we reached from a different direction when an eight-GPU VM refused sixty-eight deployment attempts over seventeen days while its published price and eviction band never moved.
What we are not claiming
This is one subscription, on two days, in one region pair. It says nothing about capacity in West Europe today, and capacity is specific to a size and a moment rather than a region as a whole. West Europe did place the smallest Balanced size once, on 27 September, and then refused it on six further attempts spread across the following two days.
Existing caches were not affected, and nothing here suggests they were.
We have not measured the cross-region data transfer cost of the workaround, only its latency. For a cache workload the volumes are small, but they are not zero, and that is a line on the bill you should check rather than assume.
The honest summary
The cross-region private endpoint is a bridge, not a design. Moving the cache back to West Europe later means creating a new cache and changing a hostname, because you cannot relocate one. But it unblocks a build in an afternoon while a support case runs in the background, and it costs one network round trip to do.
If you are hitting this, the useful sequence is: confirm the refusal comes from the allocator rather than preflight, test placement in nearby regions to rule out your subscription, and then decide whether 3.4 milliseconds and a future hostname change is cheaper than waiting.
Receipts: all figures from probes run in a single pay-as-you-go Azure subscription on 27 and 29 September 2026, using Azure CLI 2.90.0 and a fixed ARM template at api-version 2025-07-01. Placement results are 24 Managed Redis attempts in West Europe and North Europe and 5 in comparison regions. Latency figures are from three overlapping runs, West Europe to Belgium Central, 34,200 samples, with the cache at Balanced_B1 and high availability disabled. Capacity is a reading at a point in time and will have moved.