To create a storage account, you choose an account type, which dictates supported services. General-purpose v2 accounts support blobs, files, queues, and tables. For premium performance, options include Premium block blob, Premium page blob, or Premium file share. Data durability is configured via replication strategies like locally-redundant storage (LRS) or geo-redundant storage (GRS). To optimize costs, data can be assigned to different access tiers: Hot, Cool, or Archive. Security involves enabling secure transfer (HTTPS), configuring network rules to restrict traffic, and utilizing private endpoints. You should use Microsoft Entra ID for authentication, disable anonymous read access, and disallow shared key authorization. Data protection features include blob soft delete, container soft delete, blob versioning, and immutability policies.
Zone-redundant storage (ZRS) synchronously copies data across three availability zones within a region, protecting against a datacenter failure. For disaster recovery, geo-redundant storage (GRS) or geo-zone-redundant storage (GZRS) asynchronously copies data to a secondary region. To allow read access during an outage, you can enable read-access geo-redundant storage (RA-GRS) or RA-GZRS. A failover makes the secondary region the new active primary. An unplanned failover carries a risk of data loss and converts the account to LRS, requiring you to manually re-enable geo-redundancy afterward. When evaluating redundancy, balance cost versus availability, determine if you need cross-region protection, and assess if read access during an outage is required.
Object replication asynchronously copies block blobs between a source and destination storage account based on defined policies and rules. It is used for scenarios like minimizing latency, optimizing compute workloads across regions, and meeting compliance requirements. Both source and destination accounts must have blob versioning enabled, and the source requires the blob change feed. Replication is asynchronous, so the destination is not immediately in sync. It does not support customer-managed failover and serves as a data synchronization tool rather than a full disaster recovery solution. Costs include egress charges for data moving between regions and transaction costs for reading the change feed.
Azure Storage service-side encryption (SSE) automatically encrypts all data at rest using 256-bit AES encryption by default with Microsoft-managed keys. For more control, you can use customer-managed keys stored in Azure Key Vault or customer-provided keys supplied with each request. Encryption scopes let you apply different encryption rules to specific containers or blobs within the same account. For the highest security, you can enable infrastructure encryption, which applies double encryption—once at the service level and again at the infrastructure level. To enable customer-managed keys, you need an Azure Key Vault with Soft Delete and Purge Protection enabled, and you must assign a managed identity to the storage account.
Manage Data by Using Azure Storage Explorer and AzCopy
AzCopy is a high-performance command-line utility for moving data into, out of, and between Azure storage accounts. It supports authorization via Microsoft Entra ID or Shared Access Signature (SAS) tokens. The azcopy copy command performs a one-time transfer, while azcopy sync replicates changes by comparing files. Azure Storage Explorer is a graphical tool for managing storage accounts and performing ad-hoc operations like upload and download. For security, use RBAC and SAS tokens with least privilege, enforce HTTPS, and utilize firewalls and private endpoints. For operational control, use AzCopy's log files to resume interrupted jobs and tune performance by adjusting concurrency settings.
To create a file share, you first create a storage account. You choose between premium performance (on SSD) for low latency or standard performance (on HDD) for cost-effectiveness. Standard accounts offer access tiers: Transaction Optimized, Hot, and Cool. For authentication, Azure Files supports on-premises AD DS, Microsoft Entra Domain Services, or Microsoft Entra Kerberos using the Kerberos protocol. Authorization involves two layers: Azure RBAC for share-level permissions and Windows ACLs for directory/file-level permissions. For network security, use Private Endpoints or Service Endpoints to block public internet access. On-premises clients typically need a VPN or ExpressRoute, or you can enable SMB over QUIC to use Port 443.
Securing Blob Storage involves combining multiple controls. A stored access policy provides server-side management for SAS tokens. A SAS token itself grants delegated, time-limited access. You also assign Azure RBAC roles for identity-based access. You can set the AllowBlobPublicAccess property to false to block anonymous access. When creating a container, you can apply immutability policies for Write Once, Read Many (WORM) compliance, either as time-based retention or a legal hold. You can also attach metadata or tags to the container for organization and cost tracking.
Azure Blob Storage offers four access tiers: Hot, Cool, Cold, and Archive. The Hot tier has the highest storage cost but lowest transaction fees. Cool and Cold have lower storage costs but higher access fees and minimum retention periods (30 and 90 days respectively). The Archive tier is offline and requires a rehydration process to access data. You can set a default tier at the account level and override it per blob. To automate movement, use lifecycle management policies with JSON rules. Be aware of early deletion penalties if you delete or move data before its minimum retention period ends. Azure Files standard shares can also move between Hot and Cool tiers, with each transition incurring transaction fees.
Soft delete protects against accidental deletions by placing resources in a temporary, recoverable state. For containers, soft delete hides the container and its contents for a configurable retention period (1-365 days). For blobs, it preserves files, snapshots, and versions if they are deleted or overwritten. It is managed at the storage account level. For maximum protection, combine container soft delete, blob soft delete, and blob versioning. To restore items, use the "Show deleted" setting in the portal and execute an undelete operation. Keeping soft-deleted items increases storage costs and can slow performance if you have over 1,000 items.
Share snapshots are incremental, read-only copies of a file share. Azure Backup can automate snapshot creation and retention. You can retain up to 200 snapshots per share for up to 10 years. If a file share is deleted and soft delete is enabled, it enters a soft-deleted state, allowing you to restore the entire share and its snapshots. Soft delete for Azure Files operates at the share level only; to recover individual files, you must use share snapshots or Azure Backup. Standard shares in a soft-deleted state incur normal storage costs, while premium shares are billed at snapshot rates.
Lifecycle management policies use JSON rules to automatically transition or delete blobs based on criteria like age or last accessed time. If using last accessed time, you must enable access time tracking on the storage account. Rules can filter by prefix, blob type, or custom tags. The policy engine runs in the background, typically scanning once per day, and can take up to 24 hours to apply changes. To monitor execution, route the LifecyclePolicyCompleted event through Azure Event Grid. For troubleshooting, query Azure Monitor logs for the ObjectLifeCycleScanner user agent to find failures.
Blob versioning automatically saves a previous version of a blob each time it is modified. It works with blob soft delete to form a resilient safety net. When both are enabled, deleting a current version changes its status to a previous version, while deleting a previous version moves it to a soft-deleted state. You can restore data via an Undelete Blob operation or promote a specific version back to current using Copy Blob. You enable versioning at the storage account level. It increases storage consumption, so Microsoft recommends keeping fewer than 1,000 versions per blob. Use lifecycle management policies to transition old versions to cheaper tiers or delete them.
StudyCerts
StudyCerts