O design de soluções de armazenamento é uma das áreas com maior peso no exame AZ-305. Vai muito além de memorizar nomes de serviços: a habilidade real está em combinar as características de desempenho, as opções de replicação e as regras de transição entre camadas de cada serviço para selecionar a arquitetura ideal para cada requisito. Este guia reúne os padrões fundamentais extraídos do análise de 53 questões reais do exame, abordando Blob Storage, Azure Files, Managed Disks, NetApp Files, opções de replicação e Lifecycle Management, tudo em um único lugar.
---
Design do Blob Storage e Camadas de Acesso
Blob Storage é o principal armazenamento de objetos do Azure para dados não estruturados — imagens, vídeos, logs, backups e muito mais. É acessível diretamente por meio de REST APIs HTTP/HTTPS e se integra nativamente ao Azure CDN e ao Front Door.
O tipo de conta de armazenamento é o ponto de partida do design. General Purpose v2 (GPv2) é o tipo de uso geral que suporta todas as quatro camadas de acesso (Hot, Cool, Cold, Archive) e as políticas de Lifecycle Management. Habilitar o namespace hierárquico (HNS) em uma conta GPv2 a transforma em ADLS Gen2. Premium Block Blob é baseado em SSD e oferece latência consistente abaixo de 1 ms, mas suporta apenas a camada Hot e não oferece suporte a políticas de Lifecycle Management. FileStorage é exclusivo para Azure Files Premium e não pode ser criado a partir de uma conta GPv2.
As camadas de acesso representam um equilíbrio entre custo de armazenamento e custo de leitura. Hot é adequado para dados acessados frequentemente; Cool, para dados retidos por 30 dias ou mais; Cold, por 90 dias ou mais; e Archive, por 180 dias ou mais. Se os dados são acessados de forma irregular — como em auditorias trimestrais — mas precisam ser lidos imediatamente quando necessário, Cool é a escolha correta. As políticas de Lifecycle Management funcionam apenas em contas GPv2; Cool tem retenção mínima de 30 dias, Archive de 180 dias, e encargos de exclusão antecipada se aplicam caso os dados sejam movidos antes do prazo.
As opções de proteção de dados servem a propósitos distintos. Blob Versioning retém automaticamente versões anteriores quando um blob é sobrescrito. Soft Delete permite a recuperação por até 365 dias após a exclusão — mas, como um administrador pode restaurar os dados, não atende aos requisitos de WORM. Point-in-Time Restore é exclusivo para Block Blob e requer a habilitação simultânea de três recursos: Soft Delete, Versioning e Change Feed. Uma política de imutabilidade (WORM) no estado bloqueado impede que até mesmo administradores de assinatura modifiquem ou excluam dados dentro do período de retenção, tornando-a adequada para conformidade com regulamentações como SEC 17a-4 em contextos financeiros, de saúde e jurídicos.
---
Azure Files e Design de Compartilhamentos de Arquivo
Azure Files é um serviço de compartilhamento de arquivos em nuvem totalmente gerenciado que suporta os protocolos SMB e NFS. Está disponível em dois níveis: Standard (conta GPv2, baseado em HDD, latência de dezenas a centenas de milissegundos) e Premium (conta FileStorage, baseado em SSD, latência de um único dígito de milissegundos). Premium suporta apenas LRS e ZRS — GRS e RA-GRS não estão disponíveis.
Não é possível criar um compartilhamento de arquivo Premium a partir de uma conta GPv2. Se for necessário compartilhamento de arquivos com baixa latência, é obrigatório escolher o tipo de conta FileStorage.
A seleção do método de autenticação é um tópico frequente no exame. Em ambientes onde o uso de Shared Key está desabilitado e é necessária autenticação SMB com uma conta do Entra ID, habilite a autenticação do Azure Files com Entra ID (Kerberos). A autenticação AD DS é para ambientes híbridos com Active Directory local.
Azure File Sync mantém os servidores de arquivos das filiais sincronizados automaticamente com o Azure Files. Mesmo quando o servidor local está offline, os funcionários podem acessar o Azure Files diretamente na nuvem, garantindo a continuidade do negócio. O cloud tiering retém localmente apenas os arquivos de uso frequente, reduzindo as necessidades de armazenamento local em até 99%. Se três requisitos surgirem simultaneamente — baixa latência na filial, sincronização centralizada e tolerância a falhas — a combinação de Azure Files e Azure File Sync é a resposta correta.
---
Managed Disks e Design de Discos para VM
Managed Disks são o armazenamento em bloco conectado às máquinas virtuais do Azure. O desempenho aumenta nesta ordem: Standard HDD (desenvolvimento/teste), Standard SSD (servidores web em geral), Premium SSD (SQL Server, produção), Premium SSD v2 (OLTP de alto desempenho, latência de submilissegundos, ajuste independente de IOPS e throughput) e Ultra Disk (maior desempenho, limitado a zonas de disponibilidade). Se o custo e a complexidade operacional do Ultra Disk são excessivos, o Premium SSD v2 é uma alternativa sólida.
A configuração de Host Caching é crítica em cenários com SQL Server. Para discos de arquivos de dados, use cache Read-Only: as leituras são servidas a partir da memória, reduzindo os IOPS, enquanto as gravações vão diretamente para o disco, eliminando o risco de perda de dados caso o cache seja perdido. Para discos de log de transações, configure o cache como None. As gravações vão diretamente para o disco sem cache, garantindo a durabilidade de escrita; o padrão de escrita sequencial dos logs de transações proporciona desempenho suficiente mesmo sem cache.
---
Opções de Replicação e Disponibilidade de Dados (LRS/ZRS/GRS/GZRS)
| Opção | Escopo de replicação | Falha de DC único | Falha de região | Durabilidade | |-------|---------------------|-------------------|-----------------|---------------| | LRS | 3 cópias dentro de um único datacenter | Vulnerável | Vulnerável | 11 noves | | ZRS | 3 zonas de disponibilidade na mesma região | Protegido | Vulnerável | 12 noves | | GRS | LRS + replicação assíncrona para região secundária | Vulnerável | Protegido | 16 noves | | RA-GRS | GRS + acesso de leitura à região secundária | Vulnerável | Protegido + Leitura | 16 noves | | GZRS | ZRS + replicação assíncrona para região secundária | Protegido | Protegido | 16 noves |
Critérios de seleção: escolha LRS para minimizar custos sem necessidade de recuperação de desastres; ZRS para tolerância a falhas de um único DC quando a replicação entre regiões é proibida por soberania de dados ou regulamentação; RA-GRS para recuperação de desastres regional com disponibilidade de leitura durante uma interrupção; GZRS quando é necessária proteção contra falhas de zona e de região simultaneamente.
Azure Files Premium suporta apenas LRS e ZRS. Se for necessária tolerância à falha de um único datacenter, ZRS é a única opção de alta disponibilidade. Se o acesso frequente é esperado, manter os dados na camada Hot é necessário para preservar a latência de leitura no nível de milissegundos.
!Comparação das opções de replicação do Azure Storage
Tabela Comparativa de Serviços
| Serviço | Caso de uso principal | Protocolo | Opções de replicação | Suporte a camadas | |---------|----------------------|-----------|---------------------|--------------------| | Blob Storage GPv2 | Armazenamento de objetos não estruturados | HTTP/HTTPS | Todas (LRS a GZRS) | Hot/Cool/Cold/Archive | | Azure Files Standard | Compartilhamento de arquivos, substituição de servidores | SMB, NFS | LRS/ZRS/GRS/RA-GRS | - | | Azure Files Premium | Compartilhamento de arquivos de alto desempenho e baixa latência | SMB, NFS | Apenas LRS, ZRS | - | | Managed Disks | Armazenamento em bloco para VM | - | LRS/ZRS | - | | NetApp Files | NAS empresarial de alto desempenho | NFS v3/v4.1, SMB | Hardware dedicado | Ultra/Premium/Standard | | ADLS Gen2 | Data lake para big data e análise | ABFS/HTTP | Todas (LRS a GZRS) | Hot/Cool/Archive |
O nível de serviço Ultra do NetApp Files oferece 128 MiB/s por TiB de throughput e latência de submilissegundos — um NAS de nível empresarial. Se as palavras-chave são throughput máximo, menor latência e prioridade de desempenho, Azure NetApp Files é a resposta. Porém, se a compatibilidade com SMB é o requisito principal e a eficiência de custos também importa, Azure Files Premium é a opção mais adequada.
---
Critérios de Seleção que Confundem no Exame
Armazenamento com Conformidade WORM
Se o requisito é que nem mesmo os administradores possam excluir os dados, juntamente com conformidade com SEC 17a-4 e retenção de longo prazo, escolha uma política de imutabilidade do Blob Storage no estado bloqueado. Soft Delete não se qualifica como WORM porque um administrador pode restaurar os dados excluídos. As políticas de retenção do Azure Backup não protegem o blob de origem. Um Resource Lock apenas impede a exclusão da conta de armazenamento — não fornece proteção em nível de blob.
Data Lake + ACLs de Pasta + Spark
Quando são exigidos simultaneamente uma estrutura hierárquica de pastas, POSIX ACLs e integração com Apache Spark, escolha ADLS Gen2 (GPv2 com HNS habilitado). O HNS só pode ser habilitado no momento da criação da conta. O RBAC controla apenas o nível de conta e contêiner; para permissões granulares de pasta e arquivo, são necessários POSIX ACLs (que exigem HNS).
Blob de Alto Throughput + Baixa Latência + WORM Simultaneamente
Se milhares de gravações de log por segundo, conformidade WORM e latência de submilissegundos são todos exigidos ao mesmo tempo, escolha Premium Block Blob Storage. Standard GPv2 é baseado em HDD e não consegue atender a esses requisitos. Premium Block Blob é baseado em SSD, suporta completamente as políticas de imutabilidade (WORM) e, combinado com ZRS, também fornece proteção contra falhas no datacenter.
Criptografia Independente por Departamento em uma Única Conta
Se CMKs diferentes são necessários por contêiner dentro da mesma conta de armazenamento, escolha Blob Encryption Scope. Um CMK