Fundamentação Teórica: Configure Azure Storage Redundancy

1. Intuição Inicial

Imagine que você tem um documento extremamente importante: o contrato de uma empresa. Você não guarda apenas uma cópia. Você faz uma cópia no cofre do escritório, outra em casa e outra em um cartório em outra cidade. Se o escritório pegar fogo, você ainda tem as outras duas cópias.

Redundância de armazenamento é exatamente esse princípio aplicado ao Azure: o serviço mantém automaticamente múltiplas cópias dos seus dados em locais físicos diferentes, de forma que falhas de hardware, de datacenter ou até desastres geográficos não causem perda de dados.

A diferença entre as opções de redundância está em quantas cópias existem e onde elas ficam fisicamente.

2. Contexto

Toda Storage Account no Azure tem uma configuração de redundância. Essa configuração determina:

O SLA de disponibilidade da conta
A durabilidade dos dados (probabilidade de não perda)
O custo do armazenamento
A capacidade de recuperação em caso de falha regional

A Microsoft garante durabilidade de pelo menos 11 noves (99,999999999%) para todas as opções de redundância, mas o que varia é o tipo de falha contra o qual cada opção protege.

Outros serviços do Azure que dependem da redundância configurada:

Azure Backup
Azure Site Recovery
Diagnósticos de VMs
Azure Functions (storage interno)
Qualquer aplicação que use Azure Storage SDK

3. Construção dos Conceitos

3.1 A estrutura física que você precisa entender primeiro

Antes de falar em redundância, é preciso entender a hierarquia física do Azure:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Região: Um conjunto de datacenters em uma área geográfica (ex: East US, Brazil South).
Zona de Disponibilidade (AZ): Um datacenter fisicamente separado dentro de uma região, com energia, resfriamento e rede independentes. Nem toda região tem zonas.
Fault Domain: Um rack ou conjunto de racks que compartilham energia e switch de rede. Uma falha em um fault domain (ex: queda de energia de um rack) não afeta outro.

Cada opção de redundância espalha as cópias de formas diferentes dentro dessa hierarquia.

3.2 As seis opções de redundância

O Azure oferece seis configurações. Elas se organizam em dois grupos: locais (dentro de uma região) e geográficas (entre regiões).

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

3.3 LRS: Locally Redundant Storage

O que é: Mantém 3 cópias síncronas dos dados dentro de um único datacenter, em fault domains diferentes.

Analogia: Três cópias do contrato guardadas em três armários diferentes do mesmo escritório.

Proteção contra: Falha de hardware (disco, servidor, rack).

Não protege contra: Falha do datacenter inteiro (incêndio, inundação, falta de energia prolongada).

Atributo	Valor
Cópias	3
Localização	1 datacenter, múltiplos fault domains
Durabilidade	11 noves (99,999999999%)
SLA de disponibilidade (leitura)	99,9%
SLA de disponibilidade (escrita)	99,9%
Custo relativo	Mais barato

Quando a escrita é confirmada: A escrita é considerada bem-sucedida somente após ser replicada para as 3 cópias de forma síncrona.

3.4 ZRS: Zone Redundant Storage

O que é: Mantém 3 cópias síncronas dos dados, cada uma em uma Zona de Disponibilidade diferente dentro da mesma região.

Analogia: Três cópias do contrato em três prédios diferentes da mesma cidade, cada um com sua própria geração de energia.

Proteção contra: Falha de um datacenter inteiro, falha de rede local, desastres que afetem uma zona.

Não protege contra: Desastre que afete a região inteira (terremoto, apagão regional).

Atributo	Valor
Cópias	3
Localização	3 zonas de disponibilidade na mesma região
Durabilidade	12 noves (99,9999999999%)
SLA de disponibilidade (leitura)	99,9%
SLA de disponibilidade (escrita)	99,9%
Custo relativo	Moderado

Restrição importante: ZRS só está disponível em regiões que possuem Zonas de Disponibilidade. Verifique a disponibilidade por região antes de escolher.

3.5 GRS: Geo-Redundant Storage

O que é: Combina LRS na região primária (3 cópias síncronas) com replicação assíncrona para uma região secundária geograficamente distante (onde mais 3 cópias LRS são mantidas). Total de 6 cópias.

Analogia: Três cópias no escritório em São Paulo e três cópias em um arquivo em Miami. As cópias de Miami são atualizadas com um pequeno atraso.

Proteção contra: Desastres regionais completos.

Não protege contra: Dados escritos recentemente que ainda não foram replicados (RPO não é zero).

Atributo	Valor
Cópias	6 (3 primária LRS + 3 secundária LRS)
Localização	2 regiões geograficamente separadas
Durabilidade	16 noves (99,99999999999999%)
SLA de disponibilidade (leitura)	99,9% (somente primária)
SLA de disponibilidade (escrita)	99,9%
Custo relativo	Alto

Comportamento crítico: Por padrão, a região secundária do GRS não aceita leitura. Ela existe apenas para failover. Você não pode acessar esses dados a menos que inicie um failover ou use RA-GRS.

RPO (Recovery Point Objective): Como a replicação é assíncrona, em caso de desastre pode haver perda de dados dos últimos minutos. A Microsoft documenta o RPO típico como inferior a 15 minutos, mas não há garantia contratual desse valor.

3.6 GZRS: Geo-Zone Redundant Storage

O que é: Combina ZRS na região primária (3 cópias em 3 zonas diferentes) com replicação assíncrona para a região secundária (onde LRS mantém 3 cópias adicionais). Total de 6 cópias.

Analogia: Três cópias em três prédios diferentes em São Paulo e três cópias em Miami.

Esta é a opção de maior resiliência disponível no Azure Storage.

Atributo	Valor
Cópias	6 (3 primária ZRS + 3 secundária LRS)
Localização	3 zonas primária + 1 região secundária
Durabilidade	16 noves
SLA de disponibilidade (leitura)	99,99% (com RA-GZRS)
SLA de disponibilidade (escrita)	99,9%
Custo relativo	Mais alto

3.7 RA-GRS e RA-GZRS: Read-Access

As variantes RA-GRS e RA-GZRS são idênticas ao GRS e GZRS respectivamente, com uma única diferença: habilitam leitura da região secundária a qualquer momento, sem necessidade de failover.

O endpoint de leitura da região secundária tem o sufixo -secondary:

https://mystorageaccount-secondary.blob.core.windows.net

Isso é útil para:

Distribuir carga de leitura geograficamente
Manter disponibilidade de leitura mesmo se a região primária cair
Aplicações que aceitam dados levemente desatualizados

Modelo de consistência na secundária: Os dados lidos da região secundária podem estar ligeiramente atrás da primária. Isso é chamado de eventual consistency. Não use a secundária para leituras que exigem dados absolutamente atuais.

4. Visão Estrutural Comparativa

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5. Funcionamento na Prática

5.1 Como a replicação síncrona funciona (LRS e ZRS)

Quando sua aplicação faz uma escrita no Azure Storage com LRS ou ZRS:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

A resposta 200 OK só é devolvida após todas as 3 cópias confirmarem. Isso garante que em caso de falha imediata após a escrita, nenhum dado é perdido.

5.2 Como a replicação assíncrona funciona (GRS e GZRS)

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

A confirmação para a aplicação é imediata após a replicação local. A replicação para a região secundária acontece em segundo plano. Este é o ponto onde o RPO não é zero.

5.3 Failover e o que acontece

Quando a região primária falha com GRS/GZRS:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Comportamento crítico: Após o failover, a conta retorna ao estado LRS. Você precisa reconfigurar manualmente para GRS/GZRS depois que a região original se recuperar.

6. Formas de Implementação

6.1 Portal Azure

Na criação da Storage Account, a opção está na aba Basics, campo Redundancy.

Para alterar em uma conta existente: Storage Account > Configuration > Replication.

Vantagem: Visual, com descrições de cada opção. Limitação: Não escalável para múltiplas contas.

6.2 Azure CLI

Na criação:

az storage account create \
  --name mystorageaccount \
  --resource-group myRG \
  --location eastus \
  --sku Standard_RAGZRS \
  --kind StorageV2

Alterando em conta existente:

az storage account update \
  --name mystorageaccount \
  --resource-group myRG \
  --sku Standard_GRS

Os valores válidos para --sku:

SKU	Opção de redundância
Standard_LRS	LRS
Standard_ZRS	ZRS
Standard_GRS	GRS
Standard_GZRS	GZRS
Standard_RAGRS	RA-GRS
Standard_RAGZRS	RA-GZRS
Premium_LRS	Premium LRS
Premium_ZRS	Premium ZRS

6.3 Azure PowerShell

# Criar com redundância
New-AzStorageAccount `
  -ResourceGroupName "myRG" `
  -Name "mystorageaccount" `
  -Location "eastus" `
  -SkuName "Standard_RAGZRS" `
  -Kind "StorageV2"

# Alterar redundância existente
Set-AzStorageAccount `
  -ResourceGroupName "myRG" `
  -Name "mystorageaccount" `
  -SkuName "Standard_GRS"

6.4 Bicep / ARM

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'mystorageaccount'
  location: 'eastus'
  sku: {
    name: 'Standard_RAGZRS'
  }
  kind: 'StorageV2'
  properties: {}
}

6.5 Azure Policy (automação de conformidade)

Para garantir que toda Storage Account use no mínimo ZRS:

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Storage/storageAccounts"
      },
      {
        "field": "Microsoft.Storage/storageAccounts/sku.name",
        "in": ["Standard_LRS", "Premium_LRS"]
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

7. Controle e Segurança

7.1 Quais mudanças são permitidas (e quais não são)

Nem toda transição de redundância é possível diretamente:

De	Para	Possível?	Como
LRS	ZRS	Sim (algumas regiões)	Live migration ou recriar
LRS	GRS/RA-GRS	Sim	Direto no portal/CLI
LRS	GZRS/RA-GZRS	Sim	Direto
ZRS	LRS	Sim	Direto
ZRS	GZRS/RA-GZRS	Sim	Direto
GRS	RA-GRS	Sim	Direto
GRS	LRS	Sim	Direto
GRS	ZRS	Não direto	Recriar conta ou live migration
GZRS	RA-GZRS	Sim	Direto
RA-GRS	GRS	Sim	Direto

Regra geral: Conversões que envolvem mudança entre replicação local e zonal (LRS para ZRS e vice-versa) exigem migração dos dados, não apenas alteração de configuração.

7.2 Live Migration para ZRS

Quando você solicita migração de LRS para ZRS via suporte Microsoft:

Os dados são copiados para as zonas restantes de forma transparente
Sem downtime para a aplicação
Disponível apenas em regiões com zonas de disponibilidade
Pode levar dias dependendo do volume de dados

8. Tomada de Decisão

8.1 Guia de decisão por cenário

Situação	Melhor escolha	Motivo
Dados de desenvolvimento/teste	LRS	Custo mínimo, dados não críticos
Aplicação produção em região com AZs	ZRS	Proteção zonal sem custo geo
Requisito regulatório de continuidade	GRS ou GZRS	Dados replicados em segunda região
Alta disponibilidade de leitura global	RA-GRS ou RA-GZRS	Leitura na secundária sem failover
Máxima resiliência disponível	GZRS ou RA-GZRS	ZRS primária + geo replicação
Dados de analytics de grande volume	LRS	Volume alto, custo geo inviável
Conformidade regulatória LGPD/GDPR	LRS ou ZRS	Dados não saem da região/país
Backup de dados críticos	GRS	Segunda região garante recuperação
Aplicação tolerante a dados levemente defasados	RA-GRS	Leitura da secundária com consistência eventual

8.2 Trade-offs de custo versus resiliência

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Custo aumenta da esquerda para a direita. Resiliência também.

8.3 Replicação síncrona vs assíncrona: o que isso significa para o RPO

Replicação	RPO	Significa
LRS / ZRS (síncrona)	0	Nenhum dado perdido em falha
GRS / GZRS (assíncrona para geo)	Tipicamente < 15 min	Pode perder dados recentes em desastre

O RPO (Recovery Point Objective) é o máximo de dados que podem ser perdidos. Isso é uma decisão de negócio, não apenas técnica.

9. Boas Práticas

Defina a redundância durante a criação: Alterar depois, especialmente para ZRS, exige migração e pode gerar complexidade operacional.
Use ZRS como padrão mínimo para produção em regiões que suportam zonas de disponibilidade.
Prefira RA-GRS ou RA-GZRS em vez de GRS/GZRS quando a aplicação pode se beneficiar de leitura da secundária.
Documente o RPO e RTO esperados para cada Storage Account e alinhe com a escolha de redundância.
Teste failover em ambientes de homologação antes de depender dele em produção.
Use Azure Policy para garantir que contas de produção não sejam criadas com LRS inadvertidamente.
Considere conformidade regulatória: Em alguns países ou setores, dados não podem sair da região. Nesse caso, LRS ou ZRS são obrigatórios.
Para ADLS Gen2 (HNS habilitado), verifique suporte: Nem todas as opções de redundância estão disponíveis para todas as combinações de tipo de conta.

10. Erros Comuns

Erro	Por que acontece	Como evitar
Acreditar que GRS garante RPO zero	Replicação geo é assíncrona	Entender que existe janela de perda de dados
Tentar ler da secundária sem RA-GRS	Secundária não é acessível por padrão com GRS	Use RA-GRS ou RA-GZRS quando leitura da secundária é necessária
Não reconfigurar geo após failover	Após failover a conta fica em LRS	Reativar GRS/GZRS manualmente após recuperação da primária
Usar LRS em produção por hábito	LRS é padrão na interface	Configure ZRS como padrão via Policy
Achar que mudar SKU é instantâneo	Migração para ZRS pode levar dias	Planeje com antecedência
Ignorar que ZRS não está disponível em todas regiões	Regiões sem AZs não suportam ZRS	Verifique disponibilidade por região antes de projetar
Usar GRS com dados regulatórios que não podem sair do país	GRS replica para outra região/país	Use LRS ou ZRS para dados com restrição geográfica

11. Operação e Manutenção

11.1 Monitorando a saúde da replicação

No Azure Monitor, você pode monitorar:

GeoReplicationStatus: Informa se a replicação geográfica está ativa e em que estado.
LastSyncTime: O timestamp do último momento em que a região secundária estava totalmente sincronizada com a primária. Use isso para entender o RPO atual real.

Para verificar o LastSyncTime via CLI:

az storage account show \
  --name mystorageaccount \
  --resource-group myRG \
  --query geoReplicationStats

Retorna:

{
  "canFailover": true,
  "lastSyncTime": "2025-01-15T10:30:00Z",
  "status": "Live"
}

11.2 Como iniciar failover manual

Quando a região primária falha e você precisa promover a secundária:

az storage account failover \
  --name mystorageaccount \
  --resource-group myRG

Via PowerShell:

Invoke-AzStorageAccountFailover `
  -ResourceGroupName "myRG" `
  -Name "mystorageaccount"

O failover não é instantâneo. Durante o processo, a conta pode ficar temporariamente indisponível para escrita.

11.3 Failover gerenciado pelo cliente vs pela Microsoft

Tipo	Quem inicia	Quando ocorre
Customer-managed failover	Administrador Azure	Manualmente, quando decidir
Microsoft-managed failover	Microsoft	Automaticamente se Microsoft declarar desastre e não conseguir recuperar a primária

O failover gerenciado pelo cliente requer que canFailover seja true no retorno de geoReplicationStats.

12. Integração e Automação

12.1 Azure Policy para compliance de redundância

Crie iniciativas de política que impeçam LRS em ambientes de produção:

az policy assignment create \
  --name "require-zrs-or-higher" \
  --policy "/providers/Microsoft.Authorization/policyDefinitions/<id>" \
  --scope "/subscriptions/<subscription-id>/resourceGroups/production-rg"

12.2 Monitoramento automatizado do LastSyncTime

Configure alertas no Azure Monitor quando o LastSyncTime exceder um limiar:

Crie uma métrica customizada ou use Log Analytics
Dispare alertas se LastSyncTime tiver mais de 30 minutos de atraso
Integre com Azure Action Groups para notificação por email/Teams/PagerDuty

12.3 Terraform (IaC)

resource "azurerm_storage_account" "example" {
  name                     = "mystorageaccount"
  resource_group_name      = azurerm_resource_group.example.name
  location                 = "eastus"
  account_tier             = "Standard"
  account_replication_type = "RAGZRS"
}

Os valores válidos para account_replication_type: LRS, ZRS, GRS, GZRS, RAGRS, RAGZRS.

13. Resumo Final

As seis opções e o que protegem:

LRS: 3 cópias em 1 datacenter. Protege contra falha de hardware. Menor custo.
ZRS: 3 cópias em 3 zonas. Protege contra falha de datacenter inteiro. Requer zonas na região.
GRS: LRS primária + LRS secundária em outra região (assíncrono). Protege contra desastre regional. Secundária inacessível por padrão.
GZRS: ZRS primária + LRS secundária. Máxima resiliência. Secundária inacessível por padrão.
RA-GRS: Igual ao GRS, mas com leitura habilitada na secundária.
RA-GZRS: Igual ao GZRS, mas com leitura habilitada na secundária.

Diferenças críticas:

Replicação síncrona (LRS, ZRS): RPO zero. Escrita só confirmada após todas as cópias.
Replicação assíncrona (geo): RPO não zero. Escrita confirmada antes da replicação para a secundária. Dados recentes podem ser perdidos em desastre.
GRS vs RA-GRS: Apenas a variante RA permite leitura da secundária sem failover.
Após failover: A conta retorna para LRS. É necessário reconfigurar geo-redundância manualmente.

O que precisa ser lembrado:

A mudança entre LRS e ZRS pode exigir migração de dados (não é apenas troca de configuração).
ZRS não está disponível em todas as regiões.
O LastSyncTime é o indicador prático do RPO atual de contas geo-redundantes.
Dados com restrição regulatória de localização geográfica devem usar LRS ou ZRS.
Após um failover, a reconfiguração para geo-redundância é responsabilidade do administrador.
Contas Premium suportam apenas LRS e ZRS (não GRS ou GZRS).

1. Intuição Inicial​

2. Contexto​

3. Construção dos Conceitos​

3.1 A estrutura física que você precisa entender primeiro​

3.2 As seis opções de redundância​

3.3 LRS: Locally Redundant Storage​

3.4 ZRS: Zone Redundant Storage​

3.5 GRS: Geo-Redundant Storage​

3.6 GZRS: Geo-Zone Redundant Storage​

3.7 RA-GRS e RA-GZRS: Read-Access​

4. Visão Estrutural Comparativa​

5. Funcionamento na Prática​

5.1 Como a replicação síncrona funciona (LRS e ZRS)​

5.2 Como a replicação assíncrona funciona (GRS e GZRS)​

5.3 Failover e o que acontece​

6. Formas de Implementação​

6.1 Portal Azure​

6.2 Azure CLI​

6.3 Azure PowerShell​

6.4 Bicep / ARM​

6.5 Azure Policy (automação de conformidade)​

7. Controle e Segurança​

7.1 Quais mudanças são permitidas (e quais não são)​

7.2 Live Migration para ZRS​

8. Tomada de Decisão​

8.1 Guia de decisão por cenário​

8.2 Trade-offs de custo versus resiliência​

8.3 Replicação síncrona vs assíncrona: o que isso significa para o RPO​

9. Boas Práticas​

10. Erros Comuns​

11. Operação e Manutenção​

11.1 Monitorando a saúde da replicação​

11.2 Como iniciar failover manual​

11.3 Failover gerenciado pelo cliente vs pela Microsoft​

12. Integração e Automação​

12.1 Azure Policy para compliance de redundância​

12.2 Monitoramento automatizado do LastSyncTime​

12.3 Terraform (IaC)​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

3. Construção dos Conceitos

3.1 A estrutura física que você precisa entender primeiro

3.2 As seis opções de redundância

3.3 LRS: Locally Redundant Storage

3.4 ZRS: Zone Redundant Storage

3.5 GRS: Geo-Redundant Storage

3.6 GZRS: Geo-Zone Redundant Storage

3.7 RA-GRS e RA-GZRS: Read-Access

4. Visão Estrutural Comparativa

5. Funcionamento na Prática

5.1 Como a replicação síncrona funciona (LRS e ZRS)

5.2 Como a replicação assíncrona funciona (GRS e GZRS)

5.3 Failover e o que acontece

6. Formas de Implementação

6.1 Portal Azure

6.2 Azure CLI

6.3 Azure PowerShell

6.4 Bicep / ARM

6.5 Azure Policy (automação de conformidade)

7. Controle e Segurança

7.1 Quais mudanças são permitidas (e quais não são)

7.2 Live Migration para ZRS

8. Tomada de Decisão

8.1 Guia de decisão por cenário

8.2 Trade-offs de custo versus resiliência

8.3 Replicação síncrona vs assíncrona: o que isso significa para o RPO

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

11.1 Monitorando a saúde da replicação

11.2 Como iniciar failover manual

11.3 Failover gerenciado pelo cliente vs pela Microsoft

12. Integração e Automação

12.1 Azure Policy para compliance de redundância

12.2 Monitoramento automatizado do LastSyncTime

12.3 Terraform (IaC)

13. Resumo Final