Azure Cache for Redis Está Sendo Aposentado: O Que Você Precisa Saber e Como Se Preparar

Recebi uma mensagem no Teams de um cliente que dizia:

"Acabei de receber uma notificação do Azure Service Health. O Azure Cache for Redis vai ser aposentado. O que isso significa pra gente?"

Se você também recebeu essa notificação (ou está descobrindo agora), respire fundo. Você tem tempo para se preparar — mas precisa começar a planejar agora.

A Microsoft anunciou oficialmente o retirement do Azure Cache for Redis em todas as suas versões: Basic, Standard, Premium, Enterprise e Enterprise Flash. O substituto? Azure Managed Redis, uma evolução construída sobre o Redis Enterprise com recursos mais robustos e uma experiência de primeira classe no Azure.

O Cronograma Que Você Precisa Conhecer

Vamos direto ao ponto. As datas variam dependendo do tier que você usa:

Basic, Standard e Premium

Marco	Data
Criação bloqueada para novos clientes	1º de abril de 2026
Criação bloqueada para todos os clientes	1º de outubro de 2026
Retirement (instâncias desabilitadas)	30 de setembro de 2028

Enterprise e Enterprise Flash

Marco	Data
Criação bloqueada para todos os clientes	1º de abril de 2026
Migração automática para Azure Managed Redis	A partir de 1º de abril de 2027

Atenção: Se você usa Enterprise ou Enterprise Flash, suas instâncias serão migradas automaticamente pela Microsoft a partir de abril de 2027. Mesmo assim, recomendo fortemente que você faça a migração antes, no seu próprio ritmo.

Até as datas de retirement, suas instâncias continuarão funcionando normalmente e receberão manutenção regular.

Por Que Migrar para Azure Managed Redis?

Não é apenas uma troca de nome. O Azure Managed Redis representa uma evolução significativa:

1. Performance e Custo-Benefício

O Azure Managed Redis é construído sobre o Redis Enterprise, oferecendo performance superior em todos os níveis quando comparado ao Azure Cache for Redis. Você obtém mais throughput e menor latência com recursos equivalentes.

2. Recursos Enterprise em Todos os Tiers

Active Geo-Replication: diferente da geo-replicação passiva do Premium, aqui você tem replicação ativa entre regiões
Redis Modules: acesso a módulos como RediSearch, RedisJSON, RedisTimeSeries
Até 99.999% de SLA com geo-replicação habilitada

3. Zone Redundancy por Padrão

No Azure Managed Redis, a redundância de zona vem habilitada automaticamente quando você ativa High Availability em regiões com múltiplas zonas de disponibilidade.

4. Opção Sem HA para Dev/Test

Uma novidade bem-vinda: você pode criar instâncias sem High Availability para ambientes de desenvolvimento e teste. Isso reduz o custo pela metade, tornando muito mais econômico ter ambientes de homologação.

5. Autenticação com Microsoft Entra ID

Suporte nativo a Microsoft Entra ID (antigo Azure AD) para autenticação. Chega de gerenciar access keys manualmente — você pode usar identidades gerenciadas e RBAC.

6. Experiência Azure Nativa

Diferente do Enterprise atual (que usa componentes do Marketplace), o Azure Managed Redis é um serviço first-party. Provisionamento, gerenciamento e billing funcionam como qualquer outro serviço nativo do Azure.

O Que Muda na Sua Aplicação

Aqui está o que você precisa considerar ao migrar:

Mudanças de Conexão

Aspecto	Azure Cache for Redis	Azure Managed Redis
DNS Suffix	`.redis.cache.windows.net`	`<region>.redis.azure.net`
Porta TLS	6380	10000
Porta não-TLS	6379	Não suportada
Versão do Redis	6.x	7.4

Clustering por Padrão

O Azure Managed Redis usa clustering por padrão. A maioria das bibliotecas cliente (como StackExchange.Redis) funciona sem alterações, mas verifique a documentação da sua biblioteca para suporte a cluster.

Para caches até 25GB, existe a opção de modo não-clusterizado, mas o clustering é recomendado para melhor performance e escalabilidade.

Comandos Multi-Key

Se sua aplicação usa comandos que operam em múltiplas chaves (como MGET, MSET, RENAME), elas precisam estar no mesmo slot de hash em modo cluster. Isso pode exigir ajustes no design das suas chaves.

Estratégias de Migração

A Microsoft está disponibilizando ferramentas para facilitar a transição. Escolha a estratégia que melhor se adapta ao seu cenário:

1. Ferramenta de Migração via CLI (Recomendada)

A Microsoft está lançando uma experiência de migração via linha de comando em fases:

Fevereiro 2026: Suporte para caches Basic (preview)
Março 2026: Suporte para tiers Enterprise

O grande benefício: a ferramenta permite preservar o mesmo hostname e access key da instância original. Isso significa mudanças mínimas na sua aplicação.

Downtime esperado: apenas alguns segundos durante a atualização do registro DNS — similar ao que ocorre durante manutenções regulares.

2. Export/Import via Arquivo RDB

Disponível para o tier Premium:

Exporte o RDB do seu cache atual para uma Storage Account
Crie uma nova instância Azure Managed Redis
Importe o arquivo RDB para a nova instância
Atualize a connection string da sua aplicação

Prós: Preserva snapshot dos dados
Contras: Dados escritos após o export serão perdidos

3. Dual-Write Strategy

Para aplicações que não podem ter perda de dados:

Modifique sua aplicação para escrever em ambos os caches
Continue lendo do cache antigo
Após período suficiente de sincronização, mude as leituras para o novo cache
Remova o cache antigo

Prós: Zero downtime, transição segura
Contras: Custo temporário de duas instâncias

4. Migração com RIOT-X

O RIOT-X (Redis Input/Output Tools) é uma ferramenta da Redis Inc. que oferece opções flexíveis de migração:

Snapshot Migration (com downtime planejado)

riotx replicate redis://source redis://target

Live Migration (sem downtime)

riotx replicate --mode live redis://source redis://target

O modo live replica continuamente as alterações do cache de origem para o destino, permitindo migração com zero downtime.

Importante sobre versões diferentes

Como o Azure Cache for Redis usa versão 6.x e o Azure Managed Redis usa 7.4, adicione o argumento --struct:

riotx replicate --struct redis://source redis://target

Instalação do RIOT-X:

Windows (via Scoop):

scoop bucket add redis https://github.com/redis/scoop.git
scoop install riotx

macOS:

brew install redis/tap/riotx

Como Escolher o SKU Correto

O Azure Managed Redis usa uma estrutura de SKUs baseada em três tiers de performance:

Memory Optimized (M): Para workloads com uso intensivo de memória
Balanced (B): Equilíbrio entre memória e compute — bom ponto de partida se você não tem certeza
Compute Optimized (X): Para workloads com alto throughput ou baixa latência
Flash Optimized (F): Para quem usa Enterprise Flash atualmente

Mapeamento de SKUs

Aqui está uma tabela de referência para migração do Basic/Standard/Premium:

SKU Atual	SKU Recomendado Azure Managed Redis
Basic/Standard C0	Balanced B0
Basic/Standard C1	Balanced B1
Basic/Standard C2	Balanced B3
Basic/Standard C3	Balanced B5
Basic/Standard C4-C6	Memory Optimized M10-M50
Premium P1	Balanced B5
Premium P2-P3	Balanced B10-B20
Premium P4-P5	Balanced B50-B100

Dica: Verifique o pico de uso de memória do último mês no Azure Monitor antes de escolher. Se seu uso de memória é consistentemente baixo, você pode economizar escolhendo um tier menor.

Para Enterprise/Enterprise Flash

Acesse o portal do Azure → seu cache Enterprise → Overview
Verifique o campo Status — ele mostra algo como "Running - Enterprise 8GB (2 x 4GB)"
Some a memória total e escolha um SKU do Azure Managed Redis com capacidade equivalente ou superior

Passo a Passo: Criando Sua Primeira Instância Azure Managed Redis

1. No Portal do Azure

Pesquise por "Azure Managed Redis" na barra de busca
Clique em Create
Selecione:
- Subscription e Resource Group
- Cache name: escolha um nome único
- Region: preferencialmente a mesma do cache atual
- Performance tier: Balanced, Memory Optimized ou Compute Optimized
- Cache size: baseado no mapeamento acima

2. Configurações de Rede

Por padrão, o cache é criado com acesso público. Para ambientes de produção, considere:

Private Endpoint: para acesso exclusivo via VNet
VNet Integration: se sua aplicação já está em uma VNet

3. Configurações Avançadas

High Availability: desabilite para dev/test (economia de 50%)
Microsoft Entra ID: habilite para autenticação moderna
Clustering Policy: OSS (padrão) ou Enterprise

4. Atualize Sua Aplicação

Após criar o cache, atualize sua connection string:

// Antes (Azure Cache for Redis)
var connection = "myredis.redis.cache.windows.net:6380,password=xxx,ssl=True";

// Depois (Azure Managed Redis)
var connection = "myredis.eastus.redis.azure.net:10000,password=xxx,ssl=True";

Se estiver usando Microsoft Entra ID:

var configurationOptions = ConfigurationOptions.Parse("myredis.eastus.redis.azure.net:10000");
configurationOptions.Ssl = true;
await configurationOptions.ConfigureForAzureWithTokenCredentialAsync(new DefaultAzureCredential());

Features e Regiões: O Que Está Por Vir

O Azure Managed Redis ainda está expandindo. Aqui estão os ETAs para features importantes:

Feature/Região	ETA
Scheduling de maintenance windows	Fevereiro 2026
Keyspace notifications	Março 2026
SKUs maiores (até 500GB)	Maio 2026
US Gov Cloud	Julho 2026
China Cloud	Julho 2026
France Central	Disponível
Qatar Central	Dezembro 2026

Se você precisa de uma feature ou região que ainda não está disponível, entre em contato com o suporte ou envie email para AzureManagedRedis@microsoft.com.

E as Reservations?

Se você tem reserved capacity para Azure Cache for Redis, pode cancelar ou trocar suas reservations existentes conforme documentação do Microsoft Cost Management. Não fique preso a reservations de um serviço que será aposentado.

Lições e Recomendações

Não espere até o último momento. As datas de retirement parecem distantes (2028 para Basic/Standard/Premium), mas migrações de infraestrutura sempre levam mais tempo que o esperado.
Use a ferramenta de migração da Microsoft quando disponível. A preservação de hostname e access key minimiza mudanças na aplicação.
Comece testando em dev/test. O modo sem HA é perfeito para isso — custa metade e permite validar sua aplicação com o novo serviço.
Valide a compatibilidade do seu client. Se você usa clustering, verifique se sua biblioteca cliente suporta o modo cluster do Azure Managed Redis.
Considere Microsoft Entra ID. Se você ainda usa access keys, esta é uma boa oportunidade para modernizar a autenticação.
Revise comandos multi-key. Em modo cluster, chaves em comandos multi-key precisam estar no mesmo slot. Pode ser necessário usar hash tags.
Planeje a migração de dados. Se seu cache contém dados que não podem ser perdidos (sessões de longa duração, por exemplo), use dual-write ou RIOT-X em modo live.

Referências

Anúncio e Timeline

Azure Cache for Redis Retirement: What to Know and How to Prepare — Anúncio oficial da Microsoft com todas as datas

Migração

Migration Overview & Guidance — Guia completo de migração com comparação de features
Data Migration with RIOT-X for Azure Managed Redis — Tutorial detalhado do RIOT-X

Azure Managed Redis

What is Azure Managed Redis? — Visão geral do serviço
Choosing the Right Tier — Como escolher entre Memory Optimized, Balanced e Compute Optimized
Azure Managed Redis Architecture — Detalhes de arquitetura do serviço

Quickstarts

Quickstart: Create an Azure Managed Redis Instance — Passo a passo para criar sua primeira instância

Você já começou a planejar sua migração? Compartilhe nos comentários quais desafios está enfrentando ou se tem dúvidas específicas sobre o processo.