Fundamentação Teórica: Create and Configure Storage Accounts

1. Intuição Inicial

Imagine que você precisa guardar documentos, fotos, vídeos e backups de uma empresa inteira. No mundo físico, você contrataria um serviço de armazenamento: escolheria o tamanho do espaço, o nível de segurança, a localização do galpão e as regras de acesso.

O Azure Storage Account é exatamente isso: um contêiner lógico e gerenciável dentro do Azure que agrupa diferentes tipos de armazenamento sob uma única identidade, uma única fatura e um único conjunto de configurações de segurança e replicação.

Tudo que você armazena no Azure (arquivos, blobs, filas, tabelas) vive dentro de uma Storage Account. Ela é a unidade fundamental de armazenamento no Azure.

2. Contexto

A Storage Account existe porque o Azure precisava de uma abstração que:

Agrupasse recursos de armazenamento sob um namespace único (mystorageaccount.blob.core.windows.net)
Permitisse aplicar configurações globais (replicação, segurança, desempenho) de uma vez
Oferecesse isolamento de cobrança e de controle de acesso

Dentro do ecossistema Azure, a Storage Account é usada por:

Azure VMs (para discos não gerenciados e diagnósticos)
Azure Functions (para estado interno)
Azure Logic Apps
AKS (Kubernetes) para volumes persistentes
Aplicações web para armazenar assets, logs e dados estruturados

3. Construção dos Conceitos

3.1 Tipos de dados que uma Storage Account suporta

Uma Storage Account não é um único serviço: ela é um guarda-chuva que abriga quatro serviços internos:

Serviço	Nome no portal	Para que serve
Blob Storage	Containers	Arquivos não estruturados: imagens, vídeos, backups, logs
Azure Files	File shares	Compartilhamento de arquivos via SMB/NFS (como um drive de rede)
Queue Storage	Queues	Filas de mensagens para comunicação assíncrona entre sistemas
Table Storage	Tables	Dados NoSQL de chave-valor estruturados, sem esquema rígido

Cada um desses serviços tem seu próprio endpoint dentro da mesma conta.

3.2 Tipos de Storage Account

Este é um dos pontos mais cobrados no AZ-104. Existem tipos diferentes de contas, cada uma com capacidades distintas:

Tipo	Nome técnico	Serviços suportados	Uso recomendado
Standard General Purpose v2	StorageV2	Blob, Files, Queue, Table	Padrão para a maioria dos casos
Premium Block Blobs	BlockBlobStorage	Apenas Blob (bloco)	Workloads de alto I/O, transações frequentes
Premium File Shares	FileStorage	Apenas Azure Files	Compartilhamentos de alta performance (SMB/NFS)
Premium Page Blobs	StorageV2 Premium	Apenas Page Blobs	Discos de VMs não gerenciados

Ponto importante: O tipo Standard General Purpose v2 é o recomendado pela Microsoft para quase todos os cenários novos. O GPv1 existe por compatibilidade, mas não deve ser escolhido em projetos novos.

3.3 Camadas de acesso (Access Tiers)

Dentro do Blob Storage, o Azure permite definir camadas de acesso que equilibram custo de armazenamento versus custo de acesso:

Camada	Custo de armazenamento	Custo de acesso	Latência	Uso típico
Hot	Alto	Baixo	Imediata	Dados acessados frequentemente
Cool	Médio	Médio	Imediata	Dados acessados raramente (30+ dias)
Cold	Baixo	Alto	Imediata	Dados acessados muito raramente (90+ dias)
Archive	Muito baixo	Muito alto	Horas (reidratação)	Dados raramente acessados (180+ dias)

A camada padrão é definida no nível da conta, mas pode ser sobrescrita individualmente por blob.

Comportamento não óbvio: A camada Archive não permite leitura direta. Antes de acessar um blob arquivado, é preciso "reidratá-lo" para Hot ou Cool, o que pode levar de 1 a 15 horas dependendo da prioridade escolhida.

3.4 Replicação

A replicação define quantas cópias dos dados existem e onde. Esta é uma decisão de durabilidade e disponibilidade:

Opção	Sigla	Cópias	Onde	Protege contra
Locally Redundant Storage	LRS	3	Mesmo datacenter	Falhas de hardware
Zone Redundant Storage	ZRS	3	3 zonas na mesma região	Falha de datacenter inteiro
Geo-Redundant Storage	GRS	6	2 regiões (primária + secundária)	Desastre regional
Geo-Zone Redundant Storage	GZRS	6	3 zonas primária + 1 região secundária	Falha zonal + desastre regional
Read-Access GRS	RA-GRS	6	Igual ao GRS	Igual + leitura na secundária
Read-Access GZRS	RA-GZRS	6	Igual ao GZRS	Igual + leitura na secundária

Ponto crítico: Com GRS e GZRS, o failover para a região secundária não é automático por padrão. É necessário iniciar o failover manualmente ou configurar o failover gerenciado pelo cliente. As variantes RA-GRS e RA-GZRS permitem leitura da região secundária sem precisar de failover.

4. Visão Estrutural

100%

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

100%

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

5. Funcionamento na Prática

5.1 Criação de uma Storage Account: o que você define

Ao criar uma Storage Account, você toma decisões que não podem ser alteradas depois e outras que podem ser modificadas. Conhecer a diferença é essencial.

Decisões imutáveis (definidas na criação):

Nome da conta (globalmente único, 3 a 24 caracteres, apenas minúsculas e números)
Região (location)
Tipo de conta (Standard/Premium, GPv2/BlockBlobStorage/FileStorage)
Tipo de replicação (pode mudar com restrições)

Decisões modificáveis depois:

Camada de acesso padrão (Hot/Cool)
Configurações de rede (firewalls, private endpoints)
Políticas de ciclo de vida
Soft delete, versioning
Chaves de acesso

5.2 Namespace e endpoints

Cada Storage Account gera automaticamente endpoints públicos no formato:

https://<nome-da-conta>.blob.core.windows.net
https://<nome-da-conta>.file.core.windows.net
https://<nome-da-conta>.queue.core.windows.net
https://<nome-da-conta>.table.core.windows.net
https://<nome-da-conta>.dfs.core.windows.net  (se ADLS Gen2 habilitado)

O nome da conta precisa ser globalmente único em todo o Azure, não apenas dentro da sua assinatura.

5.3 Hierarchical Namespace (ADLS Gen2)

Ao habilitar o Hierarchical Namespace (HNS) durante a criação, a Storage Account passa a funcionar como um Azure Data Lake Storage Gen2, permitindo:

Estrutura de diretórios real (não apenas prefixos simulados)
Permissões POSIX-style por diretório
Performance superior para workloads de analytics

Atenção: O Hierarchical Namespace não pode ser habilitado após a criação da conta. É uma decisão que deve ser tomada antes.

6. Formas de Implementação

6.1 Portal Azure

Quando usar: Criações únicas, exploração de opções, ambientes de desenvolvimento.

O portal guia você por abas (Basics, Advanced, Networking, Data Protection, Encryption, Tags) e apresenta todas as opções com descrições. Ideal para entender o que cada configuração faz.

Limitações: Lento para múltiplas criações; não reproduzível de forma consistente.

6.2 Azure CLI

Quando usar: Automação simples, scripts de provisionamento, pipelines CI/CD.

az storage account create \
  --name mystorageaccount \
  --resource-group myResourceGroup \
  --location eastus \
  --sku Standard_LRS \
  --kind StorageV2 \
  --access-tier Hot \
  --https-only true \
  --min-tls-version TLS1_2

Os parâmetros --sku e --kind juntos determinam o tipo da conta:

`--kind`	`--sku`	Resultado
StorageV2	Standard_LRS / ZRS / GRS / GZRS	Standard GPv2
BlockBlobStorage	Premium_LRS / ZRS	Premium Block Blob
FileStorage	Premium_LRS / ZRS	Premium File Shares

6.3 Azure PowerShell

New-AzStorageAccount `
  -ResourceGroupName "myResourceGroup" `
  -Name "mystorageaccount" `
  -Location "EastUS" `
  -SkuName "Standard_LRS" `
  -Kind "StorageV2" `
  -AccessTier "Hot" `
  -EnableHttpsTrafficOnly $true `
  -MinimumTlsVersion "TLS1_2"

6.4 Bicep / ARM Template

Quando usar: Infraestrutura como código, deploys repetíveis, ambientes padronizados.

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'mystorageaccount'
  location: 'eastus'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
    supportsHttpsTrafficOnly: true
    minimumTlsVersion: 'TLS1_2'
    allowBlobPublicAccess: false
  }
}

Vantagem: Idempotente, versionável, integrável com DevOps.

7. Controle e Segurança

7.1 Autenticação e autorização

Existem quatro formas de controlar acesso a uma Storage Account:

1. Chaves de acesso (Storage Account Keys)

Dois pares de chaves geradas automaticamente
Acesso total à conta
Devem ser rotacionadas regularmente
Nunca expostas em código ou repositórios

2. Shared Access Signatures (SAS)

Tokens com permissões e validade definidas
Tipos: Account SAS, Service SAS, User Delegation SAS
User Delegation SAS é a forma mais segura (usa credenciais Azure AD)

3. Azure AD + RBAC

Controle baseado em papéis (roles)
Papéis relevantes:

Role	O que permite
Storage Blob Data Owner	Leitura, escrita, exclusão e controle de permissões em blobs
Storage Blob Data Contributor	Leitura, escrita e exclusão em blobs
Storage Blob Data Reader	Apenas leitura de blobs
Storage File Data SMB Share Contributor	Leitura, escrita em file shares via SMB

4. Acesso público (anonymous)

Pode ser habilitado por container (não recomendado)
Deve ser desabilitado no nível da conta em ambientes de produção

7.2 Configurações de rede

Por padrão, Storage Accounts aceitam tráfego de qualquer IP. Para produção, restrinja:

Firewall de IP: Permite apenas CIDRs específicos.

Virtual Network Service Endpoints: O tráfego de VNets autorizadas não sai pela internet pública.

Private Endpoints: Cria uma interface de rede privada dentro da VNet, com IP privado. O DNS resolve o nome da conta para esse IP interno. Esta é a opção mais segura.

100%

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

7.3 Criptografia

Em repouso: Todos os dados são criptografados automaticamente com AES-256. Não é opcional.
Chaves gerenciadas: Por padrão, chaves são gerenciadas pela Microsoft (MMK). É possível usar Customer-Managed Keys (CMK) via Azure Key Vault para maior controle.
Em trânsito: Habilitar "Secure transfer required" força HTTPS em todas as conexões. Recomendado sempre.
Versão mínima de TLS: Configure como TLS 1.2 no mínimo.

7.4 Proteção de dados

Recurso	O que faz	Quando usar
Soft Delete (Blobs)	Mantém blobs excluídos por N dias	Proteção contra exclusão acidental
Soft Delete (Containers)	Mantém containers excluídos por N dias	Proteção contra exclusão de container
Versioning	Mantém versões anteriores automaticamente	Histórico e recuperação de versões
Change Feed	Log de todas as alterações em blobs	Auditoria e replicação personalizada
Point-in-time Restore	Restaura blobs a um estado anterior	Recuperação de desastres lógicos
Immutability Policies	Impede alteração ou exclusão (WORM)	Compliance regulatório

Dependência importante: Point-in-time Restore requer que Soft Delete, Versioning e Change Feed estejam habilitados simultaneamente.

8. Tomada de Decisão

8.1 Qual tipo de replicação escolher?

Situação	Escolha	Motivo
Dados não críticos, menor custo	LRS	3 cópias no mesmo datacenter
Alta disponibilidade regional obrigatória	ZRS	Proteção contra falha de zona
Requisito de continuidade de negócios geográfica	GRS ou GZRS	Cópia em segunda região
Leitura da região secundária sem failover	RA-GRS ou RA-GZRS	Read access na secundária
Dados de analytics de alto volume	LRS + backup externo	Custo menor, durabilidade gerenciada separadamente

8.2 Qual camada de acesso escolher?

Padrão de acesso	Camada	Motivo
Acesso diário ou semanal	Hot	Custo de acesso baixo compensa
Acesso mensal ou menos	Cool	Equilíbrio entre armazenamento e acesso
Retenção de 90 a 180 dias	Cold	Armazenamento mais barato
Retenção longa, acesso raro	Archive	Menor custo de armazenamento

8.3 Qual tipo de conta escolher?

Cenário	Tipo de conta
Caso geral (aplicações, backups, logs)	Standard GPv2
Workload intensivo em transações de blob	Premium Block Blob
Compartilhamento de arquivos de alta performance	Premium File Shares
Analytics com estrutura hierárquica	Standard GPv2 + HNS (ADLS Gen2)
Discos de VM não gerenciados	Premium Page Blob

9. Boas Práticas

Um Storage Account por ambiente: Separe dev, staging e produção em contas distintas para isolamento de acesso e cobrança.
Desabilite acesso público a blobs no nível da conta em produção (allowBlobPublicAccess: false).
Force HTTPS (supportsHttpsTrafficOnly: true) sempre.
Configure TLS 1.2 como versão mínima.
Use Azure AD + RBAC em vez de chaves de acesso sempre que possível.
Habilite Soft Delete com pelo menos 7 dias de retenção.
Use Private Endpoints para Storage Accounts que só devem ser acessadas de dentro da VNet.
Rotacione chaves de acesso regularmente e use Azure Key Vault para armazená-las.
Aplique lifecycle management policies para mover dados automaticamente entre camadas (Hot → Cool → Archive) com base na idade.
Nomeie de forma padronizada: <ambiente><projeto><tipo><região> (ex: prodmyappstgeastus).

10. Erros Comuns

Erro	Por que acontece	Como evitar
Nome da conta já em uso	O namespace é global no Azure	Use um prefixo único por organização
Não consegue habilitar HNS após criação	HNS é imutável	Decida antes de criar
Blob em Archive não pode ser lido	Requer reidratação	Planeje a latência de acesso
Acesso negado mesmo com chave correta	"Secure transfer required" ativo e conexão via HTTP	Use sempre HTTPS
Failover não ocorre automaticamente com GRS	GRS não tem failover automático	Use RA-GRS e planeje failover manual
Custo inesperadamente alto	Dados em Hot sendo raramente acessados	Configure lifecycle policies
SAS token expirado em produção	Validade curta definida incorretamente	Automatize rotação ou use User Delegation SAS
Exclusão acidental de container	Soft Delete de container não estava habilitado	Habilite na criação

11. Operação e Manutenção

11.1 Monitoramento

O Azure Monitor coleta métricas de Storage Accounts automaticamente:

Transactions: Número de requisições por tipo e status
Ingress / Egress: Volume de dados transferidos
Availability: Porcentagem de requisições bem-sucedidas
SuccessE2ELatency / SuccessServerLatency: Latências de ponta a ponta e no servidor

Configure alertas para:

Disponibilidade abaixo de 99,9%
Latência acima do esperado
Erros de autenticação (possível tentativa de acesso indevido)

11.2 Lifecycle Management

Políticas de ciclo de vida automatizam a movimentação e exclusão de blobs:

{
  "rules": [
    {
      "name": "tiering-rule",
      "type": "Lifecycle",
      "definition": {
        "filters": { "blobTypes": ["blockBlob"] },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 180 },
            "delete": { "daysAfterModificationGreaterThan": 365 }
          }
        }
      }
    }
  ]
}

11.3 Limites importantes

Recurso	Limite
Capacidade máxima por conta	5 PiB
Taxa de requisição máxima	20.000 requisições/s
Throughput máximo por conta	60 Gbps (ingress) / 60 Gbps (egress) para GRS; 120 Gbps para LRS/ZRS
Tamanho máximo de um único blob	190,7 TiB (Block Blob)
Número de containers por conta	Ilimitado

12. Integração e Automação

12.1 Azure Event Grid

Storage Accounts emitem eventos para o Event Grid quando:

Um blob é criado ou excluído
Um container é criado ou excluído

Esses eventos podem acionar Azure Functions, Logic Apps ou qualquer endpoint HTTP. Padrão comum para pipelines de processamento de dados.

12.2 Azure Data Factory e Synapse

Usam Storage Accounts como fonte e destino em pipelines ETL. O formato ADLS Gen2 (HNS habilitado) é o padrão para Data Lake moderno no Azure.

12.3 AzCopy

Ferramenta de linha de comando otimizada para transferências de alto volume:

azcopy copy 'https://source.blob.core.windows.net/container' \
             'https://destination.blob.core.windows.net/container' \
             --recursive

Suporta autenticação via SAS token ou Azure AD.

12.4 Azure Policy

Garanta conformidade em escala atribuindo políticas como:

"Storage accounts should use customer-managed keys"
"Secure transfer to storage accounts should be enabled"
"Storage accounts should restrict network access"

13. Resumo Final

Conceitos essenciais:

Uma Storage Account é o contêiner lógico que agrupa Blob, Files, Queue e Table sob um único namespace, configuração e cobrança.
O tipo Standard GPv2 é o padrão recomendado para a maioria dos cenários.
Tipos Premium existem para workloads de alta performance e são restritos a um único serviço de armazenamento.
A replicação define durabilidade e disponibilidade: LRS é local, ZRS é zonal, GRS é geográfica.
As camadas de acesso (Hot, Cool, Cold, Archive) equilibram custo de armazenamento versus custo de acesso.

Decisões imutáveis (defina antes de criar):

Nome da conta
Região
Tipo de conta (kind/sku)
Hierarchical Namespace (ADLS Gen2)

Diferenças críticas:

GRS vs RA-GRS: GRS replica para segunda região, mas não permite leitura sem failover. RA-GRS permite leitura da secundária diretamente.
Archive vs Cool/Cold: Archive exige reidratação (horas) antes do acesso. Cool e Cold têm acesso imediato.
Chaves de acesso vs RBAC: Chaves dão acesso total à conta. RBAC é granular e auditável.
Service Endpoint vs Private Endpoint: Service Endpoint mantém tráfego na rede Microsoft, mas o IP público permanece. Private Endpoint elimina o IP público completamente.

O que precisa ser lembrado:

O nome da Storage Account é globalmente único em todo o Azure.
Soft Delete, Versioning e Change Feed devem estar habilitados para usar Point-in-time Restore.
Desabilite acesso público a blobs e exija HTTPS em todo ambiente de produção.
Lifecycle Management policies são essenciais para controlar custo em ambientes com grande volume de dados.
TLS 1.2 é o mínimo aceitável; configure explicitamente.

1. Intuição Inicial​

2. Contexto​

3. Construção dos Conceitos​

3.1 Tipos de dados que uma Storage Account suporta​

3.2 Tipos de Storage Account​

3.3 Camadas de acesso (Access Tiers)​

3.4 Replicação​

4. Visão Estrutural​

5. Funcionamento na Prática​

5.1 Criação de uma Storage Account: o que você define​

5.2 Namespace e endpoints​

5.3 Hierarchical Namespace (ADLS Gen2)​

6. Formas de Implementação​

6.1 Portal Azure​

6.2 Azure CLI​

6.3 Azure PowerShell​

6.4 Bicep / ARM Template​

7. Controle e Segurança​

7.1 Autenticação e autorização​

7.2 Configurações de rede​

7.3 Criptografia​

7.4 Proteção de dados​

8. Tomada de Decisão​

8.1 Qual tipo de replicação escolher?​

8.2 Qual camada de acesso escolher?​

8.3 Qual tipo de conta escolher?​

9. Boas Práticas​

10. Erros Comuns​

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

11.1 Monitoramento​

11.2 Lifecycle Management​

11.3 Limites importantes​

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

12.1 Azure Event Grid​

12.2 Azure Data Factory e Synapse​

12.3 AzCopy​

12.4 Azure Policy​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

3. Construção dos Conceitos

3.1 Tipos de dados que uma Storage Account suporta

3.2 Tipos de Storage Account

3.3 Camadas de acesso (Access Tiers)

3.4 Replicação

4. Visão Estrutural

5. Funcionamento na Prática

5.1 Criação de uma Storage Account: o que você define

5.2 Namespace e endpoints

5.3 Hierarchical Namespace (ADLS Gen2)

6. Formas de Implementação

6.1 Portal Azure

6.2 Azure CLI

6.3 Azure PowerShell

6.4 Bicep / ARM Template

7. Controle e Segurança

7.1 Autenticação e autorização

7.2 Configurações de rede

7.3 Criptografia

7.4 Proteção de dados

8. Tomada de Decisão

8.1 Qual tipo de replicação escolher?

8.2 Qual camada de acesso escolher?

8.3 Qual tipo de conta escolher?

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

11.1 Monitoramento

11.2 Lifecycle Management

11.3 Limites importantes

12. Integração e Automação

12.1 Azure Event Grid

12.2 Azure Data Factory e Synapse

12.3 AzCopy

12.4 Azure Policy

13. Resumo Final