Fundamentação Teórica: Create and Configure a File Share in Azure Files

1. Intuição Inicial

Em qualquer empresa, existe a necessidade de um drive de rede compartilhado: uma pasta que múltiplos computadores e servidores acessam ao mesmo tempo, como se fosse uma pasta local, mas que na verdade está em um servidor central. No mundo corporativo on-premises, isso é feito com servidores de arquivos Windows (via protocolo SMB) ou servidores Linux (via NFS).

Azure Files é exatamente esse servidor de arquivos hospedado na nuvem. Ele expõe compartilhamentos de arquivos que qualquer máquina (Windows, Linux, macOS, VM Azure, servidor on-premises) pode montar como um drive de rede, sem precisar gerenciar o servidor subjacente.

Um file share (compartilhamento de arquivos) no Azure Files é o equivalente a um "drive compartilhado" ou "pasta de rede" que você monta com uma letra de drive (Z:, Y:) no Windows ou como um ponto de montagem no Linux.

2. Contexto

2.1 Por que Azure Files existe

Antes do Azure Files, migrar workloads para a nuvem que dependiam de compartilhamentos de arquivos era um problema difícil. Aplicações legadas usam chamadas de sistema de arquivos padrão (abrir, ler, escrever, renomear) que não funcionam contra APIs REST de blob storage.

Azure Files resolve isso ao expor um sistema de arquivos real via protocolos padrão da indústria, permitindo que aplicações sejam migradas sem alteração de código.

2.2 Posição no ecossistema Azure

100%

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

2.3 Casos de uso principais

Lift-and-shift de aplicações legadas: Aplicações que dependem de \\servidor\pasta funcionam sem modificação apontando para um file share Azure.
Armazenamento compartilhado para VMs: Múltiplas VMs montam o mesmo share para compartilhar configurações, logs ou dados de aplicação.
Substituição de servidores de arquivos on-premises: Eliminação de fileservers físicos.
Azure File Sync: Sincronização bidirecional entre servidores locais e Azure, com cache local.
Contêineres e AKS: Volumes persistentes compartilhados entre pods.

3. Construção dos Conceitos

3.1 Protocolos suportados

Azure Files suporta dois protocolos de compartilhamento de arquivos, e a escolha do protocolo é feita por file share, não por Storage Account:

SMB (Server Message Block):

Protocolo nativo do Windows para compartilhamento de arquivos
Versões suportadas: SMB 2.1 (sem criptografia) e SMB 3.x (com criptografia em trânsito)
Compatível com: Windows, Linux (via cliente cifs-utils), macOS
Porta: TCP 445

NFS (Network File System):

Protocolo nativo do Linux/Unix para compartilhamento de arquivos
Versão suportada: NFS 4.1
Compatível com: Linux apenas
Requer conta do tipo Premium FileStorage
Requer Private Endpoint ou Service Endpoint (sem acesso via internet pública)

Critério	SMB	NFS
Sistema operacional	Windows, Linux, macOS	Linux apenas
Tipo de conta necessário	Standard ou Premium	Premium FileStorage apenas
Acesso via internet pública	Sim (porta 445)	Não (requer VNet)
Autenticação baseada em identidade	Sim (Azure AD, AD DS)	Não (baseada em UID/GID)
Criptografia em trânsito	SMB 3.x	IPSec (configurado no cliente)

3.2 Tipos de storage account para Azure Files

Nem toda Storage Account suporta todos os tipos de file share. A escolha da conta determina as capacidades disponíveis:

Tipo de conta	Tier	Protocolo	IOPS máx	Latência
Standard GPv2	Hot/Cool	SMB	Até 10.000	Milissegundos duplos
Premium FileStorage	Premium SSD	SMB e NFS	Até 100.000+	Sub-milissegundo

Ponto importante: Premium FileStorage é um tipo de conta exclusivo para Azure Files. Não é o mesmo que Premium GPv2. Você não pode criar blob containers ou queues em uma conta FileStorage.

3.3 Capacidade e cotas

Standard (GPv2):

Capacidade máxima por file share: 100 TiB (com Large File Shares habilitado)
Capacidade padrão sem Large File Shares: 5 TiB
Cobrança: por GB armazenado e por transações

Premium (FileStorage):

Capacidade definida na criação (provisionada)
Mínimo provisionado: 100 GiB
Máximo: 100 TiB
Cobrança: pela capacidade provisionada (não pelo uso real)
IOPS e throughput são proporcionais à capacidade provisionada

Diferença crítica de cobrança: Standard cobra pelo que você usa. Premium cobra pelo que você provisiona, mesmo que não use. Isso significa que você deve dimensionar Premium com cuidado.

3.4 Camadas de acesso em Standard file shares

Assim como Blob Storage tem camadas Hot/Cool/Archive, Azure Files Standard tem camadas:

Camada	Otimizada para	Custo de armazenamento	Custo de transação
Transaction Optimized	Workloads com muitas transações	Alto	Baixo
Hot	Uso frequente e equilibrado	Médio	Médio
Cool	Dados raramente acessados	Baixo	Alto

A camada padrão ao criar via portal é Transaction Optimized. Para shares de acesso infrequente, Cool reduz significativamente o custo de armazenamento ao preço de transações mais caras.

Um snapshot é uma cópia somente leitura e incremental do estado do file share em um momento específico. Snapshots capturam apenas as diferenças em relação ao estado anterior, economizando espaço.

Características:

Até 200 snapshots por file share
Retenção ilimitada (você escolhe quando deletar)
Podem ser usados para restaurar arquivos individuais ou o share inteiro
Podem ser acessados diretamente via Windows "Versões Anteriores" ou via path especial no Linux

3.6 Azure File Sync

Azure File Sync é um serviço separado que estende Azure Files criando um cache local em servidores Windows on-premises ou em VMs:

100%

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

O File Sync permite cloud tiering: arquivos raramente acessados ficam apenas na nuvem, liberando espaço local. Quando acessados, são baixados automaticamente e de forma transparente.

4. Visão Estrutural

100%

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

5. Funcionamento na Prática

Ao criar um file share, você define:

Nome: 3 a 63 caracteres, minúsculas, números e hífens. Deve começar e terminar com letra ou número.
Protocolo: SMB ou NFS (NFS apenas em contas Premium FileStorage).
Cota (quota): Tamanho máximo que o share pode atingir. Em Standard, é o limite de crescimento. Em Premium, é a capacidade provisionada que determina IOPS.
Camada de acesso: Transaction Optimized, Hot ou Cool (apenas Standard).
Backup: Habilitado via Azure Backup diretamente na criação.

O Azure Files fornece um script PowerShell pronto no portal (Connect > selecionar método de autenticação > copiar script). O script equivalente manual é:

# Montagem com chave de acesso (autenticação simples)
$connectTestResult = Test-NetConnection -ComputerName myaccount.file.core.windows.net -Port 445
if ($connectTestResult.TcpTestSucceeded) {
    # Armazenar credencial no gerenciador de credenciais do Windows
    cmd /c "cmdkey /add:`"myaccount.file.core.windows.net`" /user:`"localhost\myaccount`" /pass:`"<chave de acesso>`""
    
    # Montar o drive
    New-PSDrive -Name Z -PSProvider FileSystem -Root "\\myaccount.file.core.windows.net\myshare" -Persist
} else {
    Write-Error "Porta 445 bloqueada. Verifique o firewall."
}

Para persistir a montagem após reinicialização no Windows, use o parâmetro -Persist ou configure via Disk Management. As credenciais armazenadas no Windows Credential Manager são lembradas entre reinicializações.

5.3 Montando no Linux

# Instalar cliente SMB
sudo apt-get update && sudo apt-get install cifs-utils

# Criar diretório de montagem
sudo mkdir -p /mnt/myshare

# Montar o share
sudo mount -t cifs \
  //myaccount.file.core.windows.net/myshare \
  /mnt/myshare \
  -o vers=3.0,username=myaccount,password=<chave-de-acesso>,dir_mode=0777,file_mode=0777,serverino

# Para persistência, adicionar ao /etc/fstab:
# //myaccount.file.core.windows.net/myshare /mnt/myshare cifs vers=3.0,username=myaccount,password=<key>,dir_mode=0777,file_mode=0777,serverino 0 0

Comportamento não óbvio no Linux: A versão SMB padrão no Linux pode ser 1.0, que é insegura e pode ser bloqueada pela Storage Account se "Secure transfer required" estiver ativo. Sempre especifique vers=3.0 ou vers=3.1.1.

5.4 Porta 445: o principal obstáculo

A porta TCP 445 é usada pelo protocolo SMB. Muitos ISPs e redes corporativas bloqueiam essa porta por questões de segurança (foi explorada por ransomwares como WannaCry). Isso é o problema mais comum ao montar file shares via SMB fora da rede Azure.

Soluções quando a porta 445 está bloqueada:

Solução	Como funciona
VPN Point-to-Site	O tráfego SMB viaja pela VPN (tunel criptografado)
ExpressRoute	Conexão privada, contorna o ISP
Azure File Sync	Cache local via HTTPS (porta 443), sem porta 445
Private Endpoint	Acesso via IP privado dentro da VNet
SMB over QUIC	SMB encapsulado em QUIC (UDP 443), disponível em Premium

5.5 SMB over QUIC

SMB over QUIC é uma funcionalidade que encapsula o protocolo SMB dentro do protocolo QUIC (que usa UDP 443 em vez de TCP 445). Isso resolve o problema da porta 445 bloqueada sem necessidade de VPN.

Requisitos:

Storage Account Premium FileStorage
Clientes Windows 11 ou Windows Server 2022 (ou posterior)
Habilitado explicitamente na conta Premium

6. Formas de Implementação

6.1 Portal Azure

Quando usar: Criação inicial, exploração de configurações, geração de scripts de montagem.

No portal, navegue até a Storage Account > Data storage > File shares > + File share. O portal apresenta as opções de protocolo, cota e camada em uma única tela.

Um recurso valioso do portal é o botão "Connect" em cada file share, que gera automaticamente o script de montagem correto para Windows, Linux e macOS, considerando o método de autenticação selecionado.

Limitação: Não escalável para múltiplos file shares ou contas.

6.2 Azure CLI

Criando o file share:

# Standard SMB com cota de 100 GiB
az storage share-rm create \
  --resource-group myRG \
  --storage-account myaccount \
  --name myfileshare \
  --quota 100 \
  --access-tier Hot

# Premium SMB com 500 GiB provisionados
az storage share-rm create \
  --resource-group myRG \
  --storage-account mypremiumaccount \
  --name premiumshare \
  --quota 500

# NFS 4.1 (requer conta Premium FileStorage)
az storage share-rm create \
  --resource-group myRG \
  --storage-account mypremiumaccount \
  --name nfsshare \
  --quota 500 \
  --enabled-protocols NFS \
  --root-squash RootSquash

Listando file shares:

az storage share-rm list \
  --resource-group myRG \
  --storage-account myaccount \
  --output table

Ajustando cota (redimensionamento):

az storage share-rm update \
  --resource-group myRG \
  --storage-account myaccount \
  --name myfileshare \
  --quota 200

6.3 Azure PowerShell

# Criar contexto de storage
$ctx = New-AzStorageContext `
  -StorageAccountName "myaccount" `
  -StorageAccountKey "<key>"

# Criar file share Standard
New-AzStorageShare `
  -Name "myfileshare" `
  -Context $ctx `
  -QuotaGiB 100

# Criar diretório dentro do share
New-AzStorageDirectory `
  -ShareName "myfileshare" `
  -Path "department/finance" `
  -Context $ctx

# Upload de arquivo para o share
Set-AzStorageFileContent `
  -ShareName "myfileshare" `
  -Source "/local/path/report.xlsx" `
  -Path "department/finance/report.xlsx" `
  -Context $ctx

6.4 Bicep

// Storage Account Standard para Azure Files
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'myfilestorageacct'
  location: location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
  properties: {
    largeFileSharesState: 'Enabled'
    supportsHttpsTrafficOnly: true
    minimumTlsVersion: 'TLS1_2'
  }
}

// File Share Standard Hot 100 GiB
resource fileShare 'Microsoft.Storage/storageAccounts/fileServices/shares@2023-01-01' = {
  name: '${storageAccount.name}/default/myfileshare'
  properties: {
    shareQuota: 100
    accessTier: 'Hot'
    enabledProtocols: 'SMB'
  }
}

6.5 Criando snapshots

# Criar snapshot via CLI
az storage share snapshot \
  --account-name myaccount \
  --name myfileshare \
  --account-key <key>

# Listar snapshots
az storage share list \
  --account-name myaccount \
  --include-snapshot \
  --output table

# Restaurar arquivo de um snapshot para o share ativo
az storage file copy start \
  --account-name myaccount \
  --source-share myfileshare \
  --source-path "docs/relatorio.docx" \
  --source-snapshot <snapshot-datetime> \
  --destination-share myfileshare \
  --destination-path "docs/relatorio-restaurado.docx"

7. Controle e Segurança

7.1 Métodos de autenticação para SMB

Azure Files suporta quatro métodos de autenticação para acesso SMB:

1. Chave de acesso da Storage Account (Storage Account Key)

Equivale ao acesso de "administrador root"
Não é integrado ao Active Directory
Útil para scripts de montagem e troubleshooting
Não recomendado para usuários finais

2. Azure Active Directory Domain Services (Azure AD DS)

Integração com Azure AD via serviço gerenciado
Não requer controlador de domínio on-premises
Usuários autenticam com credenciais Azure AD
Permissões via RBAC no nível do share e ACLs no nível de arquivo/diretório

3. Active Directory Domain Services on-premises (AD DS)

Integração com Active Directory tradicional (Windows Server)
Ideal para ambientes híbridos com controladores de domínio existentes
Usuários usam credenciais corporativas já existentes
Requer ingresso da Storage Account no domínio

4. Azure AD Kerberos (para identidades híbridas)

Autenticação Kerberos usando Azure AD como KDC
Ideal para hybrid joined e Azure AD joined devices
Não requer AD DS on-premises

100%

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

7.2 Permissões: dois níveis

Azure Files com autenticação baseada em identidade usa dois níveis de permissão que trabalham juntos:

Nível 1: RBAC no nível do share

Define o que o usuário pode fazer no share inteiro:

Role	Permissão
Storage File Data SMB Share Reader	Leitura de arquivos e listagem de diretórios
Storage File Data SMB Share Contributor	Leitura, escrita e exclusão
Storage File Data SMB Share Elevated Contributor	Leitura, escrita, exclusão e modificação de ACLs (permissões NTFS)

Nível 2: ACLs Windows (NTFS) no nível de arquivo e diretório

Após montar o share, você aplica permissões NTFS normais via Windows Explorer ou icacls. Essas ACLs são armazenadas nos metadados dos arquivos no Azure.

A lógica de avaliação: A permissão efetiva é a mais restritiva entre o RBAC e a ACL NTFS. Um usuário com RBAC Contributor mas ACL NTFS "Somente Leitura" na pasta só poderá ler.

7.3 Criptografia

Em repouso: AES-256 automático, sempre ativo.
Em trânsito SMB: Requer SMB 3.x para criptografia. Se a Storage Account tiver "Secure transfer required" ativo, conexões SMB 2.x (sem criptografia) são rejeitadas.
Em trânsito NFS: Não tem criptografia nativa no protocolo NFS 4.1. A segurança é garantida pela rede privada (VNet, Private Endpoint, IPSec).

7.4 Configurações de segurança SMB avançadas

Para contas Premium FileStorage, você pode configurar:

Versões SMB permitidas: Restringir para SMB 3.1.1 apenas, rejeitando versões mais antigas.
Tipos de autenticação Kerberos: Limitar a AES-256 apenas (rejeitar RC4-HMAC).
Criptografia de canal: Exigir AES-256-GCM ou AES-128-GCM.

az storage account update \
  --name mypremiumaccount \
  --resource-group myRG \
  --file-auth-method Kerberos \
  --smb-versions 3.1.1 \
  --smb-channel-encryption AES-256-GCM

8. Tomada de Decisão

8.1 Standard vs Premium

Situação	Melhor escolha	Motivo
Compartilhamento geral de arquivos corporativos	Standard Hot	Custo controlado, performance adequada
Banco de dados, ERP, aplicações de alto I/O	Premium SMB	Sub-milissegundo, IOPS garantido
Workloads Linux com NFS nativo	Premium NFS	Único suporte a NFS 4.1
Backup e arquivamento	Standard Cool	Menor custo de armazenamento
Desenvolvimento e testes	Standard Transaction Optimized	Muitas operações pequenas
Volume persistente para AKS de alta performance	Premium NFS	Performance e compatibilidade Linux

8.2 SMB vs NFS

Situação	Melhor escolha	Motivo
Ambiente predominantemente Windows	SMB	Nativo, sem instalação adicional
Servidores Linux com workloads POSIX	NFS	Semântica de arquivo Unix, permissões UID/GID
Ambiente misto Windows e Linux	SMB	Maior compatibilidade cross-platform
Requisito de integração com Active Directory	SMB	NFS não suporta autenticação AD
Alta performance em Linux sem AD	NFS	Menor overhead de protocolo

8.3 Azure File Sync vs acesso direto

Situação	Melhor escolha	Motivo
Usuários remotos com acesso ocasional	Azure File Sync	Cache local, sem dependência de latência constante
VMs Azure acessando o share	Acesso direto (montagem)	Baixa latência dentro da região Azure
Servidor on-premises substituindo fileserver	Azure File Sync	Cache local + backup em nuvem
Porta 445 bloqueada pelo ISP	Azure File Sync	Sincroniza via HTTPS (443)

9. Boas Práticas

Habilite Large File Shares antes de precisar: em contas Standard GPv2, habilite largeFileSharesState: Enabled para permitir até 100 TiB por share (o padrão é 5 TiB e não pode ser expandido depois sem habilitar esse recurso).
Use autenticação baseada em identidade (Azure AD DS, AD DS ou Azure AD Kerberos) em vez de chaves de acesso para usuários finais.
Nunca exponha chaves de acesso em scripts armazenados em repositórios. Use Azure Key Vault ou variáveis de ambiente seguras.
Configure "Secure transfer required" para rejeitar conexões SMB 2.x sem criptografia.
Implemente snapshots regulares via Azure Backup ou via scripts agendados para proteção contra exclusão acidental.
Separe file shares por função ou departamento dentro da mesma Storage Account para aplicar cotas e controles individuais.
Para Premium, dimensione com margem: IOPS = 400 + (1 IOPS por GiB provisionado). Um share de 1 TiB tem 1.424 IOPS. Dimensione para o pico de carga.
Use Private Endpoints para file shares em ambientes de produção, eliminando exposição do endpoint público.
Monitore o uso de cota para evitar que shares Standard atinjam o limite e comecem a falhar nas escritas.

10. Erros Comuns

Erro	Por que acontece	Como evitar
Erro de montagem "Porta 445 bloqueada"	ISP ou firewall corporativo bloqueia TCP 445	Usar VPN, File Sync ou SMB over QUIC
"Access denied" ao montar com chave de acesso	"Secure transfer required" ativo e cliente usa SMB 2.x	Verificar versão SMB no cliente (usar `vers=3.0` no Linux)
Share Premium não aceita redução de cota	Premium não permite reduzir abaixo do uso atual	Planejar capacidade inicial adequadamente
Permissões NTFS não aplicadas após montagem	Montado com chave de acesso, não com identidade AD	Usar autenticação baseada em identidade para ACLs NTFS
NFS configurado em conta Standard	NFS 4.1 só está disponível em Premium FileStorage	Criar conta Premium FileStorage especificamente
Snapshot falha com "MaxSnapshotCount"	Limite de 200 snapshots atingido	Implementar política de retenção e deleção de snapshots antigos
File share inacessível após "Secure transfer" habilitado	Clientes SMB 2.1 sem criptografia são rejeitados	Atualizar clientes ou confirmar suporte a SMB 3.x
Large file share não ativável após criação	Contas criadas sem `largeFileSharesState` têm limite de 5 TiB	Habilitar na criação da conta ou via atualização da conta (possível em GPv2)

11. Operação e Manutenção

11.1 Monitoramento de métricas

No Azure Monitor, as métricas mais relevantes para Azure Files:

Métrica	O que indica
FileShareCapacityQuotaUsedPercentage	% da cota utilizada por share
Transactions	Volume de operações (útil para detectar anomalias)
SuccessE2ELatency	Latência ponta a ponta das operações
Availability	Disponibilidade do serviço de arquivos

Configure alertas para FileShareCapacityQuotaUsedPercentage > 80 para ser notificado antes de atingir o limite.

11.2 Gerenciando snapshots no Windows

Quando o share é montado em Windows com autenticação AD, os snapshots ficam acessíveis via "Versões Anteriores": clique com o botão direito em qualquer arquivo ou pasta > "Propriedades" > aba "Versões Anteriores". O usuário pode restaurar arquivos sem intervenção do administrador.

11.3 Limites importantes

Recurso	Limite
File shares por Storage Account	250 (Standard), sem limite documentado (Premium)
Tamanho máximo por share Standard (com Large File Shares)	100 TiB
Tamanho máximo por share Premium	100 TiB
Snapshots por share	200
Tamanho máximo de arquivo individual	4 TiB
Profundidade máxima de diretórios	2.000
Conexões SMB simultâneas por share	2.000

12. Integração e Automação

12.1 Azure Backup para file shares

O Azure Backup suporta backup nativo de file shares Standard SMB:

az backup protection enable-for-azurefileshare \
  --vault-name myRecoveryVault \
  --resource-group myRG \
  --storage-account myaccount \
  --azure-file-share myfileshare \
  --policy-name DailyBackupPolicy

O Backup usa snapshots internamente e permite restauração de arquivos individuais ou do share completo para um ponto no tempo.

12.2 Kubernetes (AKS) com Azure Files

Para volumes persistentes compartilhados entre pods:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azurefile-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: azurefile-csi
  resources:
    requests:
      storage: 100Gi

O ReadWriteMany é o diferencial do Azure Files frente a Azure Disk (que é ReadWriteOnce). Múltiplos pods em diferentes nós podem montar o mesmo file share simultaneamente.

12.3 Azure File Sync: configuração básica

# 1. Criar Storage Sync Service
az storagesync create \
  --resource-group myRG \
  --name myStorageSyncService \
  --location eastus

# 2. Criar Sync Group
az storagesync sync-group create \
  --resource-group myRG \
  --storage-sync-service myStorageSyncService \
  --name mySyncGroup

# 3. Registrar file share como cloud endpoint
az storagesync sync-group cloud-endpoint create \
  --resource-group myRG \
  --storage-sync-service myStorageSyncService \
  --sync-group-name mySyncGroup \
  --name myCloudEndpoint \
  --storage-account-resource-id <storage-account-id> \
  --azure-file-share-name myfileshare

# 4. O agente File Sync é instalado manualmente no servidor Windows
# e o servidor endpoint é criado via portal ou PowerShell após registro do agente

13. Resumo Final

Conceitos essenciais:

Azure Files é um serviço de compartilhamento de arquivos gerenciado que expõe shares via SMB e NFS, substituindo fileservers tradicionais.
Um file share vive dentro de uma Storage Account e é a unidade de montagem que clientes conectam como drive de rede.
Protocolo SMB suporta Windows, Linux e macOS. Protocolo NFS suporta apenas Linux e requer conta Premium FileStorage.

Diferenças críticas:

Standard vs Premium: Standard cobra por uso com capacidade elástica; Premium cobra por capacidade provisionada com performance garantida (IOPS proporcional ao provisionamento).
Chave de acesso vs autenticação por identidade: Chave de acesso dá acesso total sem integração AD. Autenticação por identidade permite ACLs NTFS granulares por usuário.
SMB vs NFS: SMB tem suporte multi-OS e integração AD. NFS tem melhor semântica POSIX para Linux mas sem autenticação AD e exige rede privada.
Azure File Sync vs acesso direto: File Sync cria cache local e sincroniza via HTTPS (resolve bloqueio de porta 445). Acesso direto é mais simples mas depende de conectividade SMB.

O que precisa ser lembrado:

A porta TCP 445 é o principal obstáculo para montagem SMB fora da rede Azure. Verifique sempre antes de planejar a arquitetura.
Large File Shares (Standard) deve ser habilitado antes de precisar de mais de 5 TiB por share.
NFS 4.1 requer conta Premium FileStorage e não suporta acesso via internet pública.
Snapshots no Azure Files não substituem backup completo. Use Azure Backup para proteção com retenção longa.
Em Kubernetes, Azure Files é a única opção nativa de storage Azure com ReadWriteMany (múltiplos pods simultâneos).
Permissões em Azure Files com identidade AD operam em dois níveis: RBAC (no share) e ACLs NTFS (em arquivos e diretórios), e a mais restritiva prevalece.

1. Intuição Inicial​

2. Contexto​

2.1 Por que Azure Files existe​

2.2 Posição no ecossistema Azure​

2.3 Casos de uso principais​

3. Construção dos Conceitos​

3.1 Protocolos suportados​

3.2 Tipos de storage account para Azure Files​

3.3 Capacidade e cotas​

3.4 Camadas de acesso em Standard file shares​

3.5 Snapshots de file share​

3.6 Azure File Sync​

4. Visão Estrutural​

5. Funcionamento na Prática​

5.1 Criando um file share: o que você define​

5.2 Montando o file share no Windows​

5.3 Montando no Linux​

5.4 Porta 445: o principal obstáculo​

5.5 SMB over QUIC​

6. Formas de Implementação​

6.1 Portal Azure​

6.2 Azure CLI​

6.3 Azure PowerShell​

6.4 Bicep​

6.5 Criando snapshots​

7. Controle e Segurança​

7.1 Métodos de autenticação para SMB​

7.2 Permissões: dois níveis​

7.3 Criptografia​

7.4 Configurações de segurança SMB avançadas​

8. Tomada de Decisão​

8.1 Standard vs Premium​

8.2 SMB vs NFS​

8.3 Azure File Sync vs acesso direto​

9. Boas Práticas​

10. Erros Comuns​

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

11.1 Monitoramento de métricas​

11.2 Gerenciando snapshots no Windows​

11.3 Limites importantes​

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

12.1 Azure Backup para file shares​

12.2 Kubernetes (AKS) com Azure Files​

12.3 Azure File Sync: configuração básica​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

2.1 Por que Azure Files existe

2.2 Posição no ecossistema Azure

2.3 Casos de uso principais

3. Construção dos Conceitos

3.1 Protocolos suportados

3.2 Tipos de storage account para Azure Files

3.3 Capacidade e cotas

3.4 Camadas de acesso em Standard file shares

3.5 Snapshots de file share

3.6 Azure File Sync

4. Visão Estrutural

5. Funcionamento na Prática

5.1 Criando um file share: o que você define

5.2 Montando o file share no Windows

5.3 Montando no Linux

5.4 Porta 445: o principal obstáculo

5.5 SMB over QUIC

6. Formas de Implementação

6.1 Portal Azure

6.2 Azure CLI

6.3 Azure PowerShell

6.4 Bicep

6.5 Criando snapshots

7. Controle e Segurança

7.1 Métodos de autenticação para SMB

7.2 Permissões: dois níveis

7.3 Criptografia

7.4 Configurações de segurança SMB avançadas

8. Tomada de Decisão

8.1 Standard vs Premium

8.2 SMB vs NFS

8.3 Azure File Sync vs acesso direto

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

11.1 Monitoramento de métricas

11.2 Gerenciando snapshots no Windows

11.3 Limites importantes

12. Integração e Automação

12.1 Azure Backup para file shares

12.2 Kubernetes (AKS) com Azure Files

12.3 Azure File Sync: configuração básica

13. Resumo Final