Skip to main content

Azure Storage

Storage Account Types

  • Standard general-purpose v2: Blob, Queue and Table storage, Azure Files
    Recommended for most scenarios.

  • Premium block blobs: Blob storage (block blobs and append blobs)
    Recommended for scenarios with high transaction rates, or low storage latency.

  • Premium page blobs: Page blobs only
    Premium storage account type for page blobs only.

  • Premium file shares: Page blobs only
    Premium storage account type for file shares only.

Premium account offer higher performance by using solid-state drives.

Azure Blob Storage Resource Types

Blob consists of three types of resources:

  • Storage account: provides unique namespace for the data.

  • Container: organises a set of blobs, similar to directory in file system.

  • Blob: three types of blobs are supported:

    • Block blobs - store text or binary data, up to about 4.7 TB.
    • Append blobs - similar to block blobs, but optimised for append operations (like logging data).
    • Page blobs - store random access files up to 8 TB in size. Store virtual hard drive (VHD) files and serve as disks for Azure VMs.

Security Features

All data encrypted at rest by default using Storage Service Encryption (SSE).

Supports the following access control:

  • Azure Active Directory (Azure AD)
  • RBAC

For securing data in transit one of the following can be used:

  • Client-side Encryption
  • SMB 3.0

OS and dat disks for Azure VMs can be encrypted using Azure Disk Encryption.

Types of encryption keys supported:

  • Microsoft-managed keys
  • Customer-managed keys
  • Customer-provided keys for blob read/write operations.

Redundancy Options

Redundancy in the primary region:

  • Locally redundant storage (LRS): data copied synchronously three times within a single physical location in the primary region.
  • Zone-redundant storage (ZRS): data copied synchronously across three Azure availability zones in the primary region.

Redundancy in the secondary region:

  • Geo-redundant storage (GRS):
    synchronous LRS in the primary region,
    then asynchronous copy a single physical location in the secondary region,
    and then synchronous LRS in the secondary region.
  • Geo-zone-redundant storage (GZRS):
    synchronous ZRS in the primary region,
    then asynchronous copy to a single physical location in the secondary region,
    and then synchronous ZRS in the secondary region.

Block Blobs Access Tiers

Selecting the right access tier helps to make solution more cost-effective. Access tiers can be switched any time.

  • Hot (online): optimised for frequent access.
  • Cool (online): optimised for large amounts of data that is infrequently accessed and stored for at least 30 days.
  • Archive (offline): optimised for data that can tolerate several hours of retrieval latency and will remain in the Archive tier for at least 180 days.


  • Transition blobs to a cooler storage tier to optimise for performance and cost.
  • Delete blobs at the end of their lifecycles.
  • Define rules to be run once per day at the storage account level.
  • Apply rules to containers or a subset of blobs (using prefixes as filters).

Blob Storage Lifecycle Policies

Rule actions:

  • tierToCool
  • enableAutoTierToHotFromCool
  • tierToArchive
  • delete

When multiple actions are applicable, lifecycle management applies the least expensive action to the blob.

Rule action conditions:

  • daysAfterModificationGreaterThan
  • daysAfterCreationGreaterThan


"rules": [
"enabled": true,
"name": "move-to-cool",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"tierToCool": {
"daysAfterModificationGreaterThan": 30
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "sample-container/log" ]

Blob Data Rehydration From Archive Tier

Rehydration can be done in either of two ways:

  • Copy an archived blob to an online tier by using copy blob or copy blob from URL operation.
  • Change a blob's access tier to an online tier by using set blob tier operation.

Rehydration priority can be set by using x-ms-rehydrate-priority header. Options include:

  • Standard priority
    • request will be processed in the order it was received
    • may take up to 15 hours.
  • High priority
    • request will be prioritised over standard priority
    • may complete in under 1 hour for objects under 10 GB in size.

Preperties and Metadata

Blob containers support:

  • System properties: exist on each blob storage resource. Some can be read or set, while others are read-only.
  • User-defined metadata: name/value pairs that are valid HTTP header, so should adhere to all restrictions governing HTTP headers.