Simplificando o Gerenciamento de File Shares no Azure Files

A Microsoft anunciou uma novidade relevante para quem usa Azure Files: um novo modelo de gerenciamento centrado em file share (Microsoft.FileShares) que está em pré-visualização. A ideia é tornar mais simples criar, gerenciar e controlar compartilhamentos de arquivos na nuvem sem ter que se preocupar com detalhes de storage account que antes adicionavam complexidade.

O que muda com o novo modelo

Até agora, para usar um compartilhamento de arquivos (file share) no Azure, você precisava criar ou gerenciar uma storage account, depois dentro dela configurar os shares. Isso envolvia fazer planejamento de capacidade, definir configurações da conta de armazenamento, monitorar limites de IOPS/throughput da storage account, configurar redes e segurança na storage account inteira, etc.

Com o novo modelo:

• Cada file share passa a ser um recurso de primeiro nível, como máquinas virtuais ou discos. Ou seja, o file share pode ser criado, configurado e gerenciado independentemente da storage account subjacente, via recurso “Microsoft.FileShares”. 

• Você confere controles de segurança por compartilhamento: regras de rede, políticas de acesso e configurações específicas podem ser aplicadas direto no file share, não em nível de storage account. Isso permite isolamento entre diferentes workloads. 

• A escalabilidade e o faturamento ficam mais simples: cada share pode escalar dentro dos limites do serviço, independentemente de outros compartilhamentos, e cada share passa a ser responsável pelo seu custo. Isso facilita cobrar custo por departamento ou projeto. 

• Preços transparentes com Provisioned v2 para file shares (SSD) — você provisiona o que precisa em termos de capacidade, IOPS e throughput, o que ajuda a evitar surpresas de custo. 

Benefícios práticos

• Redução da sobrecarga administrativa: menos configurações relacionadas à storage account para se preocupar.

• Maior isolamento e segurança: se um file share precisa de configurações diferentes (rede ou acesso seguro) você faz isso individualmente.

• Previsibilidade de custo: com cada file share tendo seu próprio controle de recursos, não há “contaminação” de uso entre shares diferentes.

• Performance melhor: na pré-visualização observaram que criar um file share usando o novo modelo foi cerca de duas vezes mais rápido do que via modelo clássico de storage account. (TECHCOMMUNITY.MICROSOFT.COM)

Limitações atuais e pontos de atenção

• O modelo em pré-visualização não suporta ainda compartilhamentos SMB (para agora só NFS com SSD). 

• Algumas funcionalidades ainda não disponíveis: uso de chaves de cliente (customer-managed keys, CMK), exclusão suave (soft delete) para certos shares, integração AKS via CSI driver, entre outros.

• A pré-visualização está disponível em regiões limitadas; nem todos os locais que suportam Azure Files têm esse modelo liberado ainda. 

Como começar a usar o novo modelo

Aqui está um guia prático para você testar e adotar o modelo Microsoft.FileShares no seu ambiente:

1. Verifique em quais regiões o novo modelo está disponível para a sua assinatura Azure. Se não estiver disponível na sua região, será necessário aguardar sua liberação.

2. No portal do Azure, vá para criar um novo recurso e pesquise por “File Shares” usando o modelo Microsoft.FileShares.

3. Ao criar, selecione o tipo de file share que você necessita (por enquanto NFS com SSD) e configure os recursos que quer provisionar: armazenamento, IOPS, throughput.

4. Defina regras de segurança específicas para o file share, como configurações de rede, pontos finais de conexão (endpoints), políticas de acesso.

5. Use tags, políticas (Azure Policy) e templates (ARM / Bicep) para implementar esse novo recurso de forma automatizada e consistente, especialmente se você tem muitos shares ou múltiplas equipes/projetos.

6. Monitore o uso, performance e custo dos file shares via métricas do Azure Monitor e relatórios de custo. Verifique se o desempenho atende às necessidades e ajusta os recursos (se possível dentro do modelo novo) conforme necessário.

Esse novo modelo de gerenciamento de file shares torna o Azure Files muito mais amigável para uso corporativo. Ele reduz complexidade, melhora controle, oferece segurança granular e facilita a gestão de custos.

Se sua empresa depende bastante de compartilhamentos de arquivos na nuvem ou está migrando workloads de servidores de arquivos tradicionais, vale muito testar o modelo Microsoft.FileShares assim que estiver disponível na sua região, para entender os impactos práticos.

Abaixo está um passo a passo prático, detalhado e pronto para você executar — em linguagem direta, com tudo que precisa saber para criar, configurar, montar e operar um file share usando o novo modelo top-level Microsoft.FileShares (pré-visualização). As instruções cobrem portal, Bicep/ARM, CLI/PowerShell, rede, permissões, migração de dados, monitoramento e boas práticas. Os exemplos de código já estão preenchidos para você copiar e colar.

Preparação e pré-requisitos
Antes de qualquer coisa, verifique se sua assinatura tem acesso à pré-visualização do novo recurso e se a região onde você quer criar o file share já oferece o provider. Confirme que você tem permissões de contribuinte (Contributor) na assinatura ou no resource group onde o recurso será criado. Para NFS você vai precisar de VMs Linux ou clientes Linux que possam montar NFS; para cenários corporativos verifique também regras de NSG, rotas e conectividade entre sub-redes. Decida as métricas de desempenho que precisa: armazenamento provisionado (GiB), IOPS e throughput (MiB/s); esses parâmetros são configuráveis no momento da criação e impactam faturamento.

Registrar o Resource Provider (caso necessário)
Se for a primeira vez que você usa o resource provider Microsoft.FileShares na assinatura, registre o resource provider antes de tentar criar recursos. No portal vá até Subscriptions → selecione sua assinatura → Resource providers e registre Microsoft.FileShares. Pela CLI, se preferir, execute:

az provider register --namespace Microsoft.FileShares

Criar um file share via Portal (fluxo rápido)
No portal do Azure, pesquise por “File shares” (o novo tipo top-level) e clique em criar. Escolha assinatura, resource group e nome do file share (nome com 3–63 caracteres, letras minúsculas, números e hífen). Selecione a região, defina o protocolo como NFS, escolha SSD (o preview suporta apenas SSD/NFS) e informe os valores de provisionamento: tamanho em GiB, IOPS e throughput. Em Networking configure se o acesso público será habilitado; para produção o mais recomendado é desabilitar acesso público e restringir por sub-redes (use o campo allowedSubnets para apontar o ID da(s) sub-rede(s) que terão acesso). Revise e crie. O portal também fornece o comando de montagem pronto (na guia Connect/Overview), use esse comando no client Linux.

Criar com Bicep (exemplo pronto)
Abaixo um arquivo Bicep de exemplo que cria um file share NFS com provisionamento. Substitua os placeholders (subscription ids, nomes de vnet/subnet, location) pelos valores do seu ambiente e execute az deployment group create apontando para ele.

fileshare.bicep

param fileShareName string = 'myfileshare'
param location string = 'eastus'
param allowedSubnetResourceId string = '/subscriptions/<sub-id>/resourceGroups/<rg-name>/providers/Microsoft.Network/virtualNetworks/<vnet-name>/subnets/<subnet-name>'

resource fileShare 'Microsoft.FileShares/fileShares@2025-06-01-preview' = {
  name: fileShareName
  location: location
  properties: {
    mediaTier: 'SSD'
    protocol: 'NFS'
    mountName: fileShareName
    provisionedStorageGiB: 1024        // ajuste conforme necessidade
    provisionedIOPerSec: 4000         // IOPS provisonado
    provisionedThroughputMiBPerSec: 128
    nfsProtocolProperties: {
      rootSquash: 'NoRootSquash'      // ajuste conforme política de segurança
    }
    publicNetworkAccess: 'Disabled'   // recomenda-se Disabled em produção
    publicAccessProperties: {
      allowedSubnets: [
        allowedSubnetResourceId
      ]
    }
    redundancy: 'Zone'                // 'Local' ou 'Zone'
  }
  tags: {
    project: 'fileshare-migration'
    owner: 'infra-team'
  }
}

Deploy Bicep:

az deployment group create --resource-group my-rg --template-file ./fileshare.bicep

Criar com ARM JSON (exemplo mínimo)
Se preferir ARM JSON, use a estrutura type: "Microsoft.FileShares/fileShares", apiVersion: "2025-06-01-preview" e inclua o mesmo bloco properties mostrado no Bicep. Depois faça o deploy com az deployment group create --resource-group my-rg --template-file ./fileshare.json.

Criar via Azure CLI/PowerShell genérico
Como se trata de um provider novo, a forma mais robusta é fazer deploy do template (Bicep/ARM) com az deployment ou usar New-AzResource no PowerShell. Exemplo PowerShell (modelo simplificado):

$props = @{
  mediaTier = 'SSD'
  protocol = 'NFS'
  mountName = 'myfileshare'
  provisionedStorageGiB = 1024
  provisionedIOPerSec = 4000
  provisionedThroughputMiBPerSec = 128
  publicNetworkAccess = 'Disabled'
  publicAccessProperties = @{ allowedSubnets = @('/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Network/virtualNetworks/<vnet>/subnets/<subnet>') }
  redundancy = 'Zone'
  nfsProtocolProperties = @{ rootSquash = 'NoRootSquash' }
}

New-AzResource -ResourceGroupName my-rg -ResourceType 'Microsoft.FileShares/fileShares' -ApiVersion '2025-06-01-preview' -ResourceName 'myfileshare' -Properties $props -Location 'eastus'

Rede e conectividade (como montar e controles de acesso de rede)
No preview NFS, geralmente o acesso é feito via rede privada; o fluxo recomendado é: crie o file share com publicNetworkAccess desabilitado e defina allowedSubnets apontando para o(s) subnet(s) que terão acesso. Em muitos casos você vai preferir configurar um Private Endpoint ou usar VNet peering para permitir que suas VMs/clients atinjam o serviço. Para montar o NFS em um Linux, abra a guia Connect / Overview do file share no portal e copie o comando de montagem sugerido pelo portal (ele instala o helper AZNFS quando necessário). Um exemplo genérico de montagem NFS (substitua pelo endpoint/paths fornecidos no portal):

sudo mkdir -p /mnt/myfileshare
sudo mount -t nfs -o vers=4.1,proto=tcp <fileShareMountEndpoint>:/<mountName> /mnt/myfileshare

Observação importante: o portal exibe o endpoint correto e as opções recomendadas. NFS em Azure normalmente usa a porta 2049; verifique NSGs/rotas e permita tráfego entre cliente e a sub-rede do file share.

Permissões e controle de acesso (RBAC e data roles)
Apesar de ser NFS, você ainda deve controlar quem pode gerenciar o resource via Azure RBAC. Para conceder acesso a operações de dados (no caso de SMB/híbrido) há roles específicas como Storage File Data SMB Share Reader, Storage File Data SMB Share Contributor e Storage File Data SMB Share Elevated Contributor. Para gerenciamento do recurso em si (criar/alterar o file share) o papel Contributor no resource group é suficiente. Para NFS, o controle de acesso ao conteúdo será feito por políticas de rede, root squash e ACLs no lado cliente; planeje o modelo de autenticação/autorização conforme o seu cenário.

Migração de dados a partir de file shares clássicos ou on-prem
Se você estiver migrando arquivos de um file share existente (dentro de storage account) para o novo fileShares, a forma mais direta é montar ambas — o compartilhamento clássico e o novo file share — em uma VM (ou em máquinas de origem/destino) e copiar usando robocopy, rsync ou AzCopy. Se precisar de alta velocidade, monte em VMs dentro da mesma região/sub-rede e faça cópia direta. Alternativamente, para grandes volumes considere Azure Data Box ou ferramentas de terceiros que suportem sincronização incremental. Teste primeiro em uma amostra antes de migrar tudo.

Monitoramento, logs e alertas
Ative Diagnostic Settings para o recurso file share e direcione métricas e logs para um workspace do Log Analytics, storage account ou Event Hub. Monitore métricas como IOPS, throughput, latência e utilização de provisioned storage. Configure alertas no Azure Monitor para thresholds (por exemplo, quando IOPS se aproximar do provisionado ou quando throughput exceder o provisionado). Use também Cost Management para acompanhar faturamento por file share.

Backup e recuperação
O novo modelo ainda pode não suportar todas as integrações de backup de forma idêntica ao modelo clássico. Se backups são críticos, mantenha cópias via Azure Backup (se suportado) ou soluções de terceiros, ou use snapshots / cópia periódica para outro storage. Verifique se o preview já oferece soft delete ou snapshot; se não, planeje uma estratégia de backup externa.

Limitações práticas e pontos a observar
O recurso em pré-visualização hoje suporta apenas o protocolo NFS e requer SSD (tier SSD / provisioned v2). SMB e outros recursos avançados podem não estar disponíveis ainda neste modelo; se você precisa de SMB, mantenha o modelo clássico (storage account + file share). Nem todas as regiões suportam o provider ainda. Algumas integrações (Azure File Sync, certos drivers CSI para Kubernetes) podem não suportar estes fileShares top-level no momento; valide antes. Documente e teste as dependências de aplicativos que vão usar o file share.

Exemplo de workflow mínimo (resumo executável)
Primeiro registre o provider, depois crie um resource group se necessário. Em seguida faça o deploy do Bicep com valores de provisionamento ajustados. Depois restrinja a conectividade por allowedSubnets ou Private Endpoint. Em seguida monte o share a partir de uma VM Linux usando o comando que o portal fornece. Realize testes de leitura/escrita e monitore métricas para ajustar IOPS/throughput. Por fim, implemente cópia/migração dos dados antigos, configure backups e habilite alertas.

Boas práticas 
Sempre testar em ambiente não-prod antes do rollout. Documente a política de provisionamento (como dimensionar GiB/IOPS/Throughput). Use tags para custo e governança. Mantenha snapshots/backups até provar que a solução de produção está estável. Use RBAC restritivo e prefira publicNetworkAccess = 'Disabled' em produção, expondo somente through private networking.

Passo a passo via Azure Portal

Passo 1 — entrar no Portal e iniciar a criação: acesse o portal do Azure (portal.azure.com), use a caixa de pesquisa no topo para procurar por “file share” (ou “file shares”) e selecione o recurso correspondente. Clique em + Create para iniciar o assistente de criação do novo file share. Esta experiência cria um recurso do tipo Microsoft.FileShares/fileShares (modelo novo, preview). 

Passo 2 — aba “Basics”: na guia Basics preencha Assinatura e Grupo de Recursos, escolha um nome para o file share (o nome deve ter entre 3 e 63 caracteres, usar apenas letras minúsculas, números e hífen, e começar/terminar com letra ou número) e selecione a região onde o recurso será criado. Note que o preview atual suporta apenas NFS como protocolo e exige SSD (mediaTier = SSD); se você precisa de SMB ou de disco HDD, use o modelo clássico.

Passo 3 — capacidade, IOPS e throughput: ainda na Basics informe a Provisioned capacity (GiB) — o preview aceita valores entre 32 GiB e 262.144 GiB. O modo de faturamento no preview é provisioned v2: a fatura é baseada no que você provisiona. O portal oferece uma recomendação automática de IOPS e throughput baseada na capacidade provisionada; você pode aceitar a recomendação ou optar por especificar manualmente os valores de Provisioned IOPS e Provisioned throughput (MiB/s) conforme sua carga. Planeje esses valores com atenção porque impactam custo e desempenho. 

Passo 4 — aba “Advanced”: se precisar, abra a guia Advanced para definir opções de NFS, como root squash (opções de root squash para controle de permissões) e para especificar um mount name diferente do nome do recurso (útil quando você quer um ponto de montagem diferente do nome do file share). Essas configurações são opcionais, mas importantes em cenários NFS para compatibilidade e segurança. 

Passo 5 — aba “Networking”: escolha a forma de restringir acesso ao file share. Para o preview você pode usar service endpoints apontando para sub-redes específicas (permite acesso apenas de sub-redes autorizadas) ou configurar um Private Endpoint (IP privado no VNet) — a experiência de criação do Private Endpoint normalmente é feita após a criação do file share (o portal tem um fluxo dedicado para criar o private endpoint e associá-lo ao recurso Microsoft.FileShares/fileShares). Lembre-se de que o private endpoint precisa estar no mesmo região que sua VNet e que a integração com zona DNS privada costuma ser recomendada para resolução interna.

Passo 6 — tags, revisão e criação: adicione tags se quiser categorizar o recurso, vá para a aba Review + create, aguarde a validação e clique em Create para provisionar o file share. O botão Create só fica disponível depois que todos os campos obrigatórios estiverem preenchidos e a validação passar. 

Passo 7 — configurar private endpoint (fluxo pós-criação): após a criação do file share, pesquise por Private endpoint no portal e clique em Create. Deixe assinatura e resource group iguais, forneça um nome para o endpoint, escolha a região (mesma região da VNet), em Resource selecione Microsoft.FileShares como Resource type e escolha o FileShare como Target sub-resource. Em Networking selecione a VNet e subnet desejadas, mantenha IP dinâmico se for o caso, habilite integração com Private DNS zone quando fizer sentido e finalize o wizard (Next: Review + create → Create). Esse passo garante que o tráfego fique dentro da rede privada. 

Passo 8 — pós-criação: montar e usar o share: como este preview cria um recurso NFS, os clientes Linux poderão montar o share usando o endpoint e o mount name configurado; consulte o procedimento de montagem NFS no documento “mount an NFS file share on Linux” para comandos e opções de segurança. Se for usar automações ou VMs, valide permissões de rede (NSG/rotas), resoluções DNS privadas e regras de firewall da VNet. 

Observações e troubleshooting importantes: o Microsoft.FileShares está em preview e tem limitações (suporte atual focado em NFS + SSD e redundâncias LRS/ZRS). Se você não encontrar a opção File shares (preview) no portal, verifique se o resource provider necessário está registrado na assinatura (em Subscriptions → sua subscription → Settings → Resource providers) e confirme se sua subscrição tem acesso ao preview; em alguns casos previews específicos podem estar habilitados somente para assinaturas/tenants com o preview ativo. Se necessário, registre o provider ou peça ao dono da assinatura para registrar. 

Alternativa (se você precisa de SMB ou de modelos clássicos): se o seu requisito é SMB, HDD, ou modelos de faturamento pay-as-you-go, crie um file share clássico dentro de uma Storage Account. O caminho é: abra a Storage Account desejada, no menu vá em Data storage → File shares e clique em + File share para criar o share no modelo tradicional (nesse fluxo você terá opções de protocol, quotas, etc., compatíveis com SMB). Use esse caminho quando precisar montar via SMB em Windows ou usar funcionalidades que o preview ainda não oferece.

Dicas práticas finais: planeje a capacidade e IOPS com base em amostras de carga para não superprovisionar; prefira private endpoints para cenários corporativos por segurança; valide nomes e limites antes de criar (regras de nomenclatura e tamanho mínimo/máximo estão no assistente); e, se for um ambiente de produção crítico que precisa de SMB, mantenha o uso do modelo clássico em storage account até que o novo modelo ofereça suporte completo ao SMB e HDD. 

Se quiser, eu já escrevo para você a sequência exata que apareceria no portal com valores de exemplo (por exemplo: nome do resource group, nome do file share, capacidade provisonada e valores de IOPS/throughput sugeridos) para você só colar no portal — ou posso gerar os comandos Azure CLI / PowerShell equivalentes para automação. Quer que eu já gere com exemplos (diz só a região e um nome de resource group que você use)?

Para mais: Simplifying file share management and control for Azure Files | Microsoft Community Hub

Me acompanhe em outras redes sociais: iamjuliaribeiro | Instagram, Twitch | Linktree