No exame AZ-104, o domínio de armazenamento corresponde a 15–20% do total. À primeira vista, há muitos termos desconhecidos, mas abordá-los por meio de analogias do cotidiano torna tudo muito mais fácil de entender. Neste artigo, os conceitos essenciais são explicados um a um — configuração de contas de armazenamento, controle de acesso, Blob Storage e Azure Files — de forma amigável e acessível.
Contas de armazenamento
Uma conta de armazenamento é como o cofre de um banco. Assim como um banco tem diferentes tipos de cofres (conta corrente, poupança, cofre individual), dentro de uma conta de armazenamento do Azure existem vários tipos de espaços de armazenamento (Blob, Files, Queue, Table). A própria conta de armazenamento funciona como um "contêiner" que agrupa e gerencia tudo isso.
Por exemplo, é possível gerenciar os arquivos de imagem do site da empresa, os registros de logs e as pastas compartilhadas dos funcionários, tudo em uma única conta de armazenamento. A primeira coisa a decidir ao criar uma conta de armazenamento é a Redundância — ou seja, quantas cópias dos dados serão mantidas e em quais locais.
Opções de redundância
Redundância é sobre "em quantos lugares fazer backup dos dados". Para evitar a perda de dados quando um disco rígido falha repentinamente, quando um prédio inteiro fica sem energia ou mesmo quando um desastre natural danifica um data center inteiro, é necessário criar cópias em vários locais.
| Opção | Local das cópias | Proteção contra desastres regionais | Resumo em uma linha | |-------|-----------------|-------------------------------------|---------------------| | LRS | 3 cópias dentro de um único data center | Não | A mais barata; protege dentro do mesmo prédio | | ZRS | Cópias em 3 Zonas de Disponibilidade (AZs) na mesma região | Não | Protege contra falhas no nível de prédio | | GRS | LRS + cópia em outra região a centenas de km (6 no total) | Sim (leitura indisponível antes do failover) | Protege contra desastres regionais | | RA-GRS | Igual ao GRS + acesso de leitura na região remota | Sim (leitura disponível) | Mantém o serviço de leitura mesmo durante um desastre | | GZRS | ZRS + LRS na região remota (6 no total) | Sim (maior durabilidade) | A proteção mais robusta disponível |
Entendendo com analogias do cotidiano
LRS é como fazer três cópias de documentos importantes em três arquivos diferentes do escritório. Se um estragar, tudo bem, mas se o prédio do escritório pegar fogo, tudo se perde. ZRS é como guardar documentos em cofres de três prédios diferentes na mesma cidade. Mesmo que um prédio desabe, os dados sobrevivem nos outros. GRS é como manter o original em um escritório de uma cidade e esconder uma cópia em um armazém de outra cidade. Mesmo que toda a primeira cidade seja atingida por um desastre, a cópia na segunda cidade permanece. No entanto, em condições normais não é possível acessar diretamente essa cópia — é preciso passar por um processo de recuperação primeiro. RA-GRS é igual ao GRS, com a diferença de que é possível acessar o armazém remoto no modo "somente leitura" a qualquer momento. É possível até configurar para que as solicitações de leitura sejam atendidas pela região remota quando a região principal estiver muito ocupada. GZRS é a combinação definitiva de ZRS e GRS. Dentro da mesma região, os dados são distribuídos entre três prédios, e uma cópia adicional é mantida em uma região remota.
No exame, se for pedido para escolher a "opção mais barata", selecione LRS; se for necessário "proteção contra desastres regionais + leitura remota", selecione RA-GRS.
!5 opções de redundância de armazenamento
Controle de acesso
O controle de acesso trata de gerenciar quem pode acessar a conta de armazenamento e como. É como um sistema de controle de entrada em um prédio — gerencia chaves e crachás para que apenas pessoas autorizadas possam entrar.
Chaves de acesso
As chaves de acesso são a chave mestra da conta de armazenamento. Com apenas essa chave, é possível acessar e modificar todos os dados dessa conta de armazenamento. É como uma chave mestra que pode abrir todos os cômodos do prédio. Por isso é muito poderosa — e igualmente perigosa. Jamais deve ser escrita diretamente no código ou exposta externamente; recomenda-se fortemente armazená-la com segurança no Azure Key Vault.
SAS (Shared Access Signature)
SAS é como um crachá de visitante temporário. É usado quando não se deseja entregar a chave mestra, mas se quer conceder acesso a uma sala específica, por um tempo limitado e com permissões específicas apenas (como somente leitura).
Por exemplo, se você quiser fornecer a um parceiro externo um link para baixar um arquivo de imagem por apenas 24 horas, basta gerar uma URL com um token SAS e compartilhá-la. Após 24 horas, o link é invalidado automaticamente.
Os tipos de SAS são os seguintes:
SAS de serviço: Concede acesso a um serviço específico (por exemplo, apenas Blob ou apenas Files). SAS de conta: Concede acesso a vários serviços dentro de uma conta de armazenamento. Política de acesso armazenada (Stored Access Policy): Ao associar um SAS a uma política, é possível invalidar centralmente todos os tokens SAS relacionados simplesmente excluindo ou modificando essa política. É como mudar a "política de emissão de crachás de visitante da empresa" — todos os crachás emitidos sob essa política ficam inválidos imediatamente.
Firewall de armazenamento
O firewall de armazenamento é como um portão de segurança do prédio. Permite acesso apenas de uma rede corporativa específica (VNet) ou de endereços IP específicos, e bloqueia todos os demais acessos. Por exemplo, ao configurar o armazenamento para ser acessível apenas pela rede interna da empresa, é possível bloquear na raiz o acesso não autorizado de fora.
Blob Storage
Blob Storage é como um armazém digital. Pode armazenar quase qualquer tipo de arquivo — imagens, vídeos, documentos, arquivos de log, dados de backup — independentemente do formato. "Blob" é a abreviação de Binary Large Object e é otimizado para armazenar dados não estruturados.
Tipos de Blob
Mesmo dentro do Blob Storage existem três tipos, dependendo das características dos dados armazenados. Assim como um armazém tem prateleiras comuns, um freezer e um arquivo de documentos — cada um com uma finalidade diferente.
Block Blob: O tipo mais comum. Utilizado para dados que são armazenados e lidos em "blocos" — imagens, vídeos, documentos, arquivos de música. É o tipo padrão usado na maioria dos cenários. Como os arquivos são divididos em vários blocos para upload, mesmo arquivos grandes são tratados com eficiência.
Page Blob: Um tipo especializado em armazenar arquivos de disco de máquinas virtuais (VM) (VHD). É usado quando há muitas operações de leitura e gravação aleatória em posições específicas — como um disco rígido. Quando uma VM é criada, o Page Blob atua internamente como o disco.
Append Blob: Um tipo otimizado para dados que "só são adicionados ao final" — como dados de log. Uma vez escrito, o conteúdo não pode ser modificado ou excluído; só é possível adicionar novo conteúdo ao final. Adequado para dados que se acumulam em ordem cronológica, como registros de acesso ao servidor ou logs de eventos do sistema.
Camadas de armazenamento e ciclo de vida
O Blob Storage pode ser gerenciado em quatro camadas com custos diferentes, dependendo da frequência de acesso aos dados. É semelhante ao aluguel de um armazém — os itens acessados com frequência ficam em um armazém próximo, e os raramente usados vão para um mais distante, porém mais barato.
Hot: Dados acessados com frequência. O custo de armazenamento é alto, mas o custo de leitura é baixo. Adequado para imagens ou documentos que estão sendo servidos atualmente. Cool: Dados que não são muito usados por 30 dias ou mais. O custo de armazenamento é menor que o Hot, mas o custo de leitura é maior. Adequado para arquivos consultados apenas ocasionalmente, como relatórios mensais. Cold: Dados raramente usados por 90 dias ou mais. Ainda mais econômico, mas o custo de leitura é ainda maior. Archive: Dados quase nunca acessados por 180 dias ou mais. A camada mais barata, mas para ler os dados é preciso passar primeiro por um processo de "reidratação" (que leva várias horas). Por estar offline, os dados não podem ser lidos imediatamente. Adequado para documentos antigos sujeitos a requisitos legais de retenção ou backups de longo prazo.
Política de gerenciamento do ciclo de vida
Decidir manualmente todos os dias "este arquivo já deveria ser movido para Cool" não é realista. As políticas de gerenciamento do ciclo de vida automatizam esse processo. Por exemplo, é possível criar uma política como "mover automaticamente os arquivos não acessados em 30 dias ou mais para a camada Cool, mover para Archive os que estão sem acesso por 90 dias ou mais, e excluir automaticamente os arquivos após 1 ano" — e o Azure cuidará disso por você.
!Os 4 níveis do Blob Storage
Proteção de dados
Para proteger contra exclusão acidental ou substituição de dados importantes, o Azure oferece vários recursos de proteção de dados.
Exclusão temporária (Soft Delete)
A exclusão temporária funciona como uma lixeira de reciclagem. Mesmo que você exclua um arquivo, ele não desaparece imediatamente — fica mantido na lixeira por um período configurado (por exemplo, 14 dias). Pode ser recuperado a qualquer momento dentro desse período. Esse recurso é um salva-vidas quando você exclui acidentalmente um arquivo importante.
Controle de versão de Blob
O controle de versão de Blob é como o histórico de salvamento automático de um editor de documentos. Cada vez que um arquivo é modificado, a versão anterior é preservada automaticamente. Em situações como "quero voltar para a versão de ontem", é possível restaurar uma versão anterior a qualquer momento.
Instantâneos de Blob
Um instantâneo é um recurso que tira uma fotografia do estado de um arquivo em um momento específico. Ao contrário do c