> ## Content Index > Fetch the complete content index at: https://www.azurebrasil.cloud/llms.txt > Use this file to discover other available public pages before exploring further. # Azure Cache for Redis Está Sendo Aposentado: O Que Você Precisa Saber e Como Se Preparar - URL: https://www.azurebrasil.cloud/blog/azure-cache-for-redis-esta-sendo-aposentado-o-que-voce-precisa-saber-e-como-se-preparar/ - Published: 2026-07-10T11:43:13.000Z - Updated: 2026-07-10T11:43:13.000Z - Author: Rafael dos Santos 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 | .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: 1. Exporte o RDB do seu cache atual para uma Storage Account 2. Crie uma nova instância Azure Managed Redis 3. Importe o arquivo RDB para a nova instância 4. 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: 1. Modifique sua aplicação para escrever em **ambos** os caches 2. Continue lendo do cache antigo 3. Após período suficiente de sincronização, mude as leituras para o novo cache 4. 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) ```bash riotx replicate redis://source redis://target ``` #### Live Migration (sem downtime) ```bash 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`: ```bash riotx replicate --struct redis://source redis://target ``` **Instalação do RIOT-X**: Windows (via Scoop): ```powershell scoop bucket add redis https://github.com/redis/scoop.git scoop install riotx ``` macOS: ```bash 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 1. Acesse o portal do Azure → seu cache Enterprise → **Overview** 2. Verifique o campo **Status** — ele mostra algo como "Running - Enterprise 8GB (2 x 4GB)" 3. 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 1. Pesquise por "Azure Managed Redis" na barra de busca 2. Clique em **Create** 3. 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: ```csharp // 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: ```csharp 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](mailto: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 1. **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. 2. **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. 3. **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. 4. **Valide a compatibilidade do seu client.** Se você usa clustering, verifique se sua biblioteca cliente suporta o modo cluster do Azure Managed Redis. 5. **Considere Microsoft Entra ID.** Se você ainda usa access keys, esta é uma boa oportunidade para modernizar a autenticação. 6. **Revise comandos multi-key.** Em modo cluster, chaves em comandos multi-key precisam estar no mesmo slot. Pode ser necessário usar hash tags. 7. **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](https://techcommunity.microsoft.com/blog/azure-managed-redis/azure-cache-for-redis-retirement-what-to-know-and-how-to-prepare/4458721?ref=azurebrasil.cloud) — Anúncio oficial da Microsoft com todas as datas ### Migração - [Migration Overview & Guidance](https://learn.microsoft.com/azure/redis/migrate/migrate-overview?ref=azurebrasil.cloud) — Guia completo de migração com comparação de features - [Data Migration with RIOT-X for Azure Managed Redis](https://techcommunity.microsoft.com/blog/azure-managed-redis/data-migration-with-riot-x-for-azure-managed-redis/4404672?ref=azurebrasil.cloud) — Tutorial detalhado do RIOT-X ### Azure Managed Redis - [What is Azure Managed Redis?](https://learn.microsoft.com/azure/redis/overview?ref=azurebrasil.cloud) — Visão geral do serviço - [Choosing the Right Tier](https://learn.microsoft.com/azure/redis/overview?ref=azurebrasil.cloud#choosing-the-right-tier) — Como escolher entre Memory Optimized, Balanced e Compute Optimized - [Azure Managed Redis Architecture](https://learn.microsoft.com/azure/redis/architecture?ref=azurebrasil.cloud) — Detalhes de arquitetura do serviço ### Quickstarts - [Quickstart: Create an Azure Managed Redis Instance](https://learn.microsoft.com/azure/redis/quickstart-create-managed-redis?ref=azurebrasil.cloud) — 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.*