Skip to content

Portal | Level: L1: Foundations | Topics: Azure Blob Storage, Cloud Deep Dive | Domain: Cloud

Azure Blob Storage - Primer

Accuracy note: Azure changes quickly. Limits and defaults below were checked against Microsoft Learn documentation as of July 2026. Items marked verify for region/SKU are intentionally not presented as universal because Azure capabilities, quotas, and rollout status can differ by region, subscription, API version, and resource SKU.

Why This Matters

Azure Blob Storage is Azure's object-storage service and is the closest equivalent to Amazon S3. The most important structural difference is that blobs live inside a storage account, and the storage account is a shared security, networking, redundancy, naming, and often billing boundary for multiple Azure Storage services.

The hierarchy is:

subscription
└── resource group
    └── storage account (globally unique DNS name)
        └── blob service
            └── container
                └── blob

An S3 bucket is globally named and is itself the major policy/configuration boundary. In Azure, the globally named unit is the storage account; containers are subordinate namespaces inside it.

Storage Account Types

For most object workloads, use a general-purpose v2 (StorageV2) account. Specialized premium block blob accounts exist for high transaction rates/low latency, but feature compatibility and pricing differ. Standard and premium are not merely access tiers; they are account/performance classes and cannot always be converted in place.

A storage account can expose Blob, Queue, Table, and File endpoints. Its redundancy selection normally applies across the services in that account. Microsoft explicitly recommends separate accounts when workloads require different redundancy choices. (Microsoft Learn: Storage account overview)

Blob Types

  • Block blobs: General object storage; uploaded as blocks and committed into a blob. This is the normal S3-like object type.
  • Append blobs: Optimized for append operations, such as certain logging patterns.
  • Page blobs: Random read/write pages; historically used for VHD-style workloads and underlying unmanaged disk scenarios.

Do not choose append/page blobs merely because the workload is a file. Most application objects should be block blobs.

Flat Namespace versus Hierarchical Namespace

Normal Blob Storage is a flat object namespace. Slashes in names are delimiters used by clients to emulate folders.

Enabling hierarchical namespace (HNS) adds Azure Data Lake Storage Gen2 semantics:

  • Real directory operations.
  • Atomic directory rename/move.
  • POSIX-like ACLs in addition to Azure RBAC.
  • dfs.core.windows.net endpoint and Data Lake APIs.

HNS is valuable for analytics and filesystem-oriented tools, but it is a one-way architectural choice: after enabling it, you cannot revert the account to a flat namespace. Feature integration has improved, but some Blob features still have HNS-specific restrictions. (Microsoft Learn: Hierarchical namespace)

Access Tiers

Current standard Blob Storage access tiers are:

  • Hot: Higher capacity price, lower access/transaction price.
  • Cool: Online tier for less-frequent access; GPv2 objects generally have a 30-day minimum retention charge.
  • Cold: Online tier for rarer access; GPv2 objects generally have a 90-day minimum retention charge.
  • Archive: Offline tier with the lowest storage price and rehydration delay; a 180-day minimum retention charge commonly applies.

Archive blobs cannot be read or modified until rehydrated to an online tier. Standard-priority rehydration can take up to 15 hours. (Microsoft Learn: Blob access tiers)

Redundancy

Common redundancy modes:

  • LRS: Multiple synchronous copies in one physical location/region scope.
  • ZRS: Synchronous copies across availability zones in one region.
  • GRS: LRS in primary plus asynchronous replication to a paired secondary region.
  • RA-GRS: GRS plus read access to the secondary endpoint.
  • GZRS: ZRS in primary plus asynchronous replication to a secondary region.
  • RA-GZRS: GZRS plus read access to secondary.

Geo-redundancy is asynchronous. It is not a zero-data-loss guarantee, and failover changes account behavior and replication state. Account-level failover is not equivalent to S3 Multi-Region Access Points.

Authorization Layers

Blob data access can be authorized through:

  • Microsoft Entra ID and Azure RBAC data roles.
  • User delegation SAS.
  • Service SAS.
  • Account SAS.
  • Shared Key using storage account keys.
  • Anonymous public access when both account and container configuration permit it.

The management plane and data plane are separate. Contributor on the storage account can manage the resource but does not automatically grant blob-content read access. Data roles such as Storage Blob Data Reader or Storage Blob Data Contributor are required for Entra-authorized object access.

Microsoft recommends disabling Shared Key where possible. By default, however, storage accounts can still authorize with Entra credentials or account keys unless Shared Key is explicitly disabled. (Microsoft Learn: Prevent Shared Key authorization)

Data Protection Features

Blob Storage provides overlapping mechanisms:

  • Blob soft delete.
  • Container soft delete.
  • Blob versioning.
  • Point-in-time restore for supported account configurations.
  • Snapshots.
  • Immutable storage/WORM policies.
  • Legal holds.
  • Object replication.
  • Lifecycle management.

These are not free. Versioning and soft-deleted copies are billed storage, and poorly bounded retention can multiply capacity silently.

See Also

Wiki Navigation

Prerequisites

Related Content

  • AWS CloudWatch (Topic Pack, L2) — Cloud Deep Dive
  • AWS Devops Flashcards (CLI) (flashcard_deck, L1) — Cloud Deep Dive
  • AWS EC2 (Topic Pack, L1) — Cloud Deep Dive
  • AWS ECS (Topic Pack, L2) — Cloud Deep Dive
  • AWS General Flashcards (CLI) (flashcard_deck, L1) — Cloud Deep Dive
  • AWS IAM (Topic Pack, L1) — Cloud Deep Dive
  • AWS Lambda (Topic Pack, L2) — Cloud Deep Dive
  • AWS Networking (Topic Pack, L1) — Cloud Deep Dive
  • AWS Route 53 (Topic Pack, L2) — Cloud Deep Dive
  • AWS S3 Deep Dive (Topic Pack, L1) — Cloud Deep Dive