Complete Azure Blob Storage guide covering architecture, tiers, security, pricing, and lifecycle management

Complete GuideBeginner to AdvancedAzure StorageBlob Storage2026

Azure Blob Storage Explained:
Complete Beginner-to-Advanced Guide

Azure Blob Storage is where Azure applications put everything that is not a database row: images, videos, logs, backups, ML datasets, and application binaries. It is also where most Azure engineers leave money on the table — storing cold data at hot prices, skipping lifecycle automation, and leaving public access open by default. This guide covers everything from first container to production-grade security, cost optimization, and architecture patterns.

$0.018

Per GB/month for Hot tier in East US (LRS). Archive tier costs $0.00099/GB — roughly 18× cheaper — for data you rarely access. Choosing the right tier is the single largest storage cost lever.

5 billion

Objects per container limit in Azure Blob Storage. Individual blob size is capped at 190.7 TiB for block blobs. No practical upper limit on total storage account size.

40–60%

Typical storage cost reduction from implementing lifecycle management policies that automatically move data from Hot to Cool and Archive tiers based on access patterns

15 hours

Standard rehydration time from Archive tier before a blob can be read. High-priority rehydration (at extra cost) can complete in under 1 hour for objects under 10 GB

Table of Contents

01What Is Azure Blob Storage? Core Concepts Explained
02Block Blobs, Append Blobs, and Page Blobs — When to Use Each
03Storage Account Types and Hierarchy
04Step-by-Step: Create a Storage Account and Upload Your First Blob
05Access Tiers: Hot, Cool, Cold, and Archive — Complete Breakdown
06Redundancy Options: LRS, ZRS, GRS, RA-GZRS Explained
07Lifecycle Management: Automate Tier Transitions and Deletions
08Security: Access Control, Private Endpoints, and Managed Identity
09AzCopy and the REST API — Moving Data at Scale
10Architecture Patterns: Blob Storage in Real-World Azure Solutions
11Cost Optimization: The 8 Rules That Keep Blob Storage Bills Predictable

What Is Azure Blob Storage? Core Concepts Explained

Azure Blob Storage is Microsoft's object storage service — a massively scalable repository for unstructured data that does not fit the row-and-column model of a relational database. "Blob" stands for Binary Large Object, and that is exactly what it holds: raw bytes of any type and size, addressed by a name rather than by schema. A JPEG image, a 10 TB video file, a compressed log archive, a Parquet dataset, a VM backup, and a trained machine learning model are all, from Azure Blob Storage's perspective, the same thing: a named sequence of bytes in a container.

The three-level hierarchy of Azure Blob Storage is Storage Account → Container → Blob. A storage account is the top-level Azure resource that provides a unique namespace for all your storage data — every blob's URL includes the storage account name. Inside a storage account, containers act like directories or S3 buckets — grouping blobs logically and holding access policies. Blobs are the actual objects stored inside containers.

Every blob is reachable via a predictable HTTPS endpoint: https://<account>.blob.core.windows.net/<container>/<blob>. This flat REST API is what makes Blob Storage cloud-native — any application that can make an HTTPS request can read or write blobs, without special drivers or protocols.

Figure 1 — Azure Blob Storage hierarchy: Storage Account → Container → Blob, with URL structure

Every blob is addressed by three components: the storage account name (in the hostname), the container name, and the blob name (which may include path-like prefixes using / to create a virtual directory structure). Containers are flat — the / in a blob name is just a character, not a real directory — but it is rendered as a folder hierarchy in the Azure Portal and Storage Explorer.

Block Blobs, Append Blobs, and Page Blobs — When to Use Each

Azure Blob Storage has three distinct blob types. Each is optimized for a different access pattern. You choose the type when the blob is created and cannot change it afterwards.

Block Blobs

Block blobs are the standard type for almost everything. A block blob is composed of up to 50,000 blocks, each up to 4,000 MiB, giving a maximum blob size of approximately 190.7 TiB. When you upload a large file, the Azure SDK splits it into blocks, uploads them in parallel, and then commits the block list — enabling high-throughput uploads with automatic retry of individual failed blocks. Block blobs support all four access tiers (Hot, Cool, Cold, Archive) and all lifecycle management features. Use block blobs for images, videos, documents, backups, datasets, and application binaries.

Append Blobs

Append blobs are optimized for write-once, read-later streaming data. You can only add data to the end of an append blob — you cannot modify or overwrite data already written. This makes them ideal for log files, audit trails, and diagnostic data where data is continuously appended. Append blobs do not support tiering to Archive or most lifecycle management features beyond deletion. Use append blobs for application logs, Azure Diagnostics output, and time-series data streams.

Page Blobs

Page blobs are optimized for random read/write operations. A page blob is divided into 512-byte pages. You can write to any specific page range without affecting other pages. Page blobs underpin Azure Virtual Machine OS and data disks (VHD/VHDX files) and Azure SQL Database data files. Unless you are implementing custom disk or database storage, you almost certainly do not need to work with page blobs directly — use block blobs instead.

Storage Account Types and Hierarchy

The storage account type determines which features are available and which blob types are supported. In 2026, General Purpose v2 (GPv2) is the correct choice for virtually every new deployment — it supports all blob types, all access tiers, all redundancy options, and all Azure Storage features at the most competitive pricing. The only reason to choose a different type is a very specific performance or compatibility requirement.

Account Type	Supports	Tiers Available	When to Choose
General Purpose v2 (GPv2)	Block, Append, Page Blobs + Azure Files, Queues, Tables	Hot, Cool, Cold, Archive	Default for all new storage accounts. All features, best pricing for most workloads.
Premium Block Blob	Block Blobs only	No tiering supported	Latency-sensitive workloads needing consistent sub-10ms response. Higher storage cost, lower transaction cost. Cannot use lifecycle tiering.
Premium Page Blob	Page Blobs only	No tiering	High-performance VM disk storage. Used internally by Azure Managed Disks.
Premium File Share	Azure Files only	N/A	High-IOPS SMB file shares. Not for blob workloads.
General Purpose v1 (GPv1)	Legacy — same as GPv2 but without Cool/Archive tiers	Hot only	Not recommended. Upgrade existing GPv1 accounts to GPv2 in-place with no downtime.

Step-by-Step: Create a Storage Account and Upload Your First Blob

The following procedure creates a GPv2 storage account with secure defaults — public blob access disabled, TLS 1.2 minimum, and Zone-Redundant Storage — then creates a container and uploads a blob. All steps work in Azure Cloud Shell or any terminal with the Azure CLI installed.

1

Set Variables and Create a Resource Group

Define your variables once and reference them throughout. All names must be globally unique — the storage account name becomes part of the public DNS entry for your blobs.

2

Create the Storage Account with Secure Defaults

Create a GPv2 account with ZRS redundancy, public blob access disabled, and minimum TLS version enforced. These three settings should be defaults for every production storage account.

3

Create a Container Inside the Storage Account

Containers are the top-level grouping inside a storage account. Set access level to Private — blobs are not publicly accessible by default, which is correct for most workloads. Public access requires an explicit container-level setting.

4

Upload a Blob to the Container

Upload a local file to the container using Entra ID (Azure AD) authentication — not the storage account key. The --auth-mode login flag uses your current Azure CLI login credentials, not a key.

5

List Blobs and Verify the Upload

Confirm the blob was uploaded, verify its properties, and retrieve the full URL for sharing or application configuration.

Azure CLI — Create storage account, container, and upload first blob# STEP 1: Set variables
RG="rg-storage-prod"
LOCATION="eastus"
SA="stprod$(date +%s | tail -c 6)" # Unique name with timestamp suffix
CONTAINER="app-data"

# Create resource group
az group create --name $RG --location $LOCATION

# STEP 2: Create GPv2 storage account with secure defaults
az storage account create \
  --name $SA \
  --resource-group $RG \
  --location $LOCATION \
  --sku Standard_ZRS \ # Zone-Redundant Storage
  --kind StorageV2 \ # General Purpose v2
  --allow-blob-public-access false \ # No anonymous access
  --min-tls-version TLS1_2 \ # Enforce TLS 1.2+
  --https-only true \ # Block HTTP requests
  --access-tier Hot # Default tier (override per blob)

# STEP 3: Create a container
az storage container create \
  --name $CONTAINER \
  --account-name $SA \
  --auth-mode login # Use Entra ID, not storage key

# STEP 4: Upload a blob (replace ./report.pdf with your file)
az storage blob upload \
  --account-name $SA \
  --container-name $CONTAINER \
  --name "reports/monthly-2026-07.pdf" \
  --file ./report.pdf \
  --auth-mode login

# STEP 5: List blobs and verify
az storage blob list \
  --account-name $SA \
  --container-name $CONTAINER \
  --query "[].{Name:name,Size:properties.contentLength,Tier:properties.blobTier}" \
  --auth-mode login -o table

# Get the blob URL
echo "https://$SA.blob.core.windows.net/$CONTAINER/reports/monthly-2026-07.pdf"

Access Tiers: Hot, Cool, Cold, and Archive — Complete Breakdown

Access tiers are the primary cost optimization lever in Azure Blob Storage. Each tier offers a different trade-off between storage cost (lower as you move to cooler tiers) and access cost (higher as you move to cooler tiers). Choosing the wrong tier for your access pattern is the most common cause of unexpectedly high Azure storage bills.

Figure 2 — Azure Blob Storage access tiers: storage cost vs access cost trade-off and decision framework

Archive tier is roughly 18× cheaper than Hot tier for storage costs — but blobs in Archive cannot be read directly. They must be "rehydrated" (moved back online) before access. Standard rehydration takes up to 15 hours. High-priority rehydration (objects under 10 GB) can complete in under 1 hour at extra cost. Never put data in Archive that you might need to access urgently.

Tier	Storage Cost (LRS)	Min Retention	Access	128 KiB min billing?
Hot	$0.018/GB/mo	None	Immediate (online)	No
Cool	$0.013/GB/mo	30 days	Immediate (online)	Yes (as of July 2026 new accounts)
Cold	$0.004/GB/mo	90 days	Immediate (online)	Yes
Archive	$0.00099/GB/mo	180 days	Offline — rehydrate first (1–15 hours)	Yes

Important: 128 KiB Minimum Billable Object Size (July 2026)

For new accounts created after July 2026, the Cool, Cold, and Archive tiers apply a 128 KiB minimum billable object size. A 1 KB log file moved to Cool is billed as 128 KB. For pipelines generating millions of small objects, consolidate them into larger archives (Parquet files, daily zip bundles, tar archives) before moving to cooler tiers. This can reduce storage costs by 10–30× for small-object log pipelines.

Redundancy Options: LRS, ZRS, GRS, RA-GZRS Explained

Redundancy determines how many copies of your data Azure maintains, and how far apart they are geographically. More redundancy means higher durability against hardware failures and regional disasters — at a proportionally higher price. The choice of redundancy is almost always a cost vs. durability decision.

Figure 3 — Azure Blob Storage redundancy options: from single data centre (LRS) to cross-continent failover (RA-GZRS)

LRS protects against hardware failure within a data centre but not against zone or regional outages. ZRS (recommended for production) survives zone failures including physical building outages. GRS adds cross-region replication for disaster recovery but does not allow reading from the secondary region until a failover. RA-GRS and RA-GZRS allow reading from the secondary region at all times — useful for globally distributed read workloads and real-time DR verification.

Lifecycle Management: Automate Tier Transitions and Deletions

Lifecycle management policies are the most impactful cost feature in Azure Blob Storage. A policy is a JSON rule set that runs once per day and automatically moves blobs between tiers or deletes them based on conditions you define — last modified date, last accessed date, creation date, or blob name prefix. Once configured, lifecycle policies eliminate the need to manually manage tier placement as data ages.

Organizations that implement lifecycle policies typically see 40–60% storage cost reduction within the first three months as historical data that has been accumulating in Hot tier is automatically moved to appropriate cooler tiers. The policies are free — you only pay the standard Set Blob Tier operation cost when a tier transition occurs.

Lifecycle Policy Design Patterns

The most common pattern is a three-stage cascade: Hot (0–30 days) → Cool (30–90 days) → Archive (90+ days), with deletion at a fixed retention boundary. This matches the natural access pattern of most data: heavily accessed immediately after creation, rarely accessed after 30 days, and only retained for compliance after 90 days.

JSON — Complete lifecycle management policy covering logs, backups, and blob versions{
  "rules": [
    {
      "name": "tier-logs",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToCold": { "daysAfterModificationGreaterThan": 90 },
            "delete": { "daysAfterModificationGreaterThan": 365 }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["logs/", "diagnostics/"]
        }
      }
    },
    {
      "name": "archive-backups",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 7 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 30 },
            "delete": { "daysAfterModificationGreaterThan": 2555 } // 7 years
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["backups/"]
        }
      }
    },
    {
      "name": "delete-old-versions",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "version": {
            "delete": { "daysAfterCreationGreaterThan": 90 }
          }
        },
        "filters": { "blobTypes": ["blockBlob"] }
      }
    }
  ]
}

# Apply the lifecycle policy via Azure CLI
az storage account management-policy create \
  --account-name $SA \
  --resource-group $RG \
  --policy @lifecycle-policy.json

# Enable last-access-time tracking (required for access-time-based policies)
az storage account blob-service-properties update \
  --account-name $SA \
  --resource-group $RG \
  --enable-last-access-tracking true

Lifecycle Policy Caveats

Policies run once per day — changes do not take effect immediately. A blob moved to Cool today will not immediately have the access-time tracking policy evaluate it.

Archive rehydration cannot be triggered by lifecycle policy — you can only move blobs to cooler tiers via lifecycle policy, not back to warmer tiers. Rehydration must be done via Set Blob Tier API or Copy Blob.

Minimum retention penalties — if a blob in Cool (30-day min) or Cold (90-day min) is deleted or moved to a warmer tier before the minimum period, Azure charges an early deletion fee for the remaining days. Build this into your policy design.

Immutable blobs — lifecycle policy delete actions will not work on blobs in immutable containers (WORM storage). The delete action puts soft-deleted blobs into a soft-delete state rather than permanently removing them.

Security: Access Control, Private Endpoints, and Managed Identity

Azure Blob Storage has three layers of access control. Understanding all three — and which to use in which situation — is the difference between a secure storage implementation and a data breach waiting to happen.

Layer 1: Network Access

By default, a storage account is accessible from any IP address over the public internet. The first security control is network restriction: limit which networks can reach your storage account. For production workloads, use Private Endpoints — a network interface in your VNet that gives the storage account a private IP address visible only within your virtual network. Blobs accessed via private endpoint never traverse the public internet.

Layer 2: Authentication and Authorization (RBAC)

Azure Blob Storage supports two authentication methods: storage account keys (shared keys) and Azure Entra ID (Azure Active Directory) with RBAC role assignments. Always prefer Entra ID authentication in production. Storage account keys are equivalent to root credentials — anyone with a key has full access to everything in the account, with no audit trail of individual operations. Entra ID authentication provides fine-grained RBAC, per-identity audit logs in Azure Monitor, and supports Managed Identity — eliminating the need to store credentials in application configuration entirely.

Layer 3: Container-Level Access Policies

Individual containers can have Shared Access Signatures (SAS tokens) generated for time-limited, scope-limited delegated access. A SAS token grants a specific set of permissions (read, write, delete) on a specific container or blob, expiring at a defined time. Use SAS tokens for temporary external access to specific blobs — not for application-to-blob authentication, where Managed Identity is superior.

Figure 4 — Azure Blob Storage security architecture: three layers of access control for production deployments

A production Blob Storage security architecture layers all three controls. Private endpoint restricts network access to the VNet. Managed Identity authenticates without credentials. RBAC grants least-privilege access. Soft delete, versioning, and immutable storage protect against data loss and tampering. Encryption at rest (AES-256) is enabled by default and cannot be disabled.

Azure CLI — Assign Managed Identity access to a storage account (recommended pattern)# Step 1: Enable System-Assigned Managed Identity on a Web App
az webapp identity assign \
  --name my-web-app \
  --resource-group rg-prod

# Get the Principal ID of the Managed Identity
PRINCIPAL_ID=$(az webapp identity show \
  --name my-web-app \
  --resource-group rg-prod \
  --query principalId -o tsv)

# Get the Storage Account Resource ID
SA_ID=$(az storage account show \
  --name $SA \
  --resource-group $RG \
  --query id -o tsv)

# Step 2: Assign Storage Blob Data Contributor role to the Managed Identity
az role assignment create \
  --assignee $PRINCIPAL_ID \
  --role "Storage Blob Data Contributor" \
  --scope $SA_ID

# Step 3: Disable storage account key access (optional but recommended for production)
az storage account update \
  --name $SA \
  --resource-group $RG \
  --allow-shared-key-access false

# Step 4: Create a Private Endpoint for the storage account in your VNet
az network private-endpoint create \
  --name pe-storage-prod \
  --resource-group $RG \
  --vnet-name vnet-prod \
  --subnet snet-app \
  --private-connection-resource-id $SA_ID \
  --group-id blob \
  --connection-name psc-storage-blob

# Step 5: Restrict storage account to private endpoint only
az storage account update \
  --name $SA \
  --resource-group $RG \
  --default-action Deny \
  --bypass None

AzCopy and the REST API — Moving Data at Scale

For moving large volumes of data into or out of Azure Blob Storage — bulk uploads, cross-account copies, migrations — the Azure CLI's blob commands are functional but not optimized for throughput. AzCopy is the purpose-built data transfer tool that parallelizes transfers automatically, resumes interrupted uploads, and achieves near-network-speed throughput for large transfers.

AzCopy Essentials

AzCopy is a standalone executable — no installation required beyond downloading the binary. It supports authentication via Entra ID (preferred) and SAS tokens. The most important commands for production use:

AzCopy — Essential commands for production data movement# Authenticate with your Azure identity (Entra ID)
azcopy login

# Upload a single file
azcopy copy "./report.pdf" \
  "https://$SA.blob.core.windows.net/app-data/reports/report.pdf"

# Upload an entire folder recursively
azcopy copy "./data-export/" \
  "https://$SA.blob.core.windows.net/app-data/exports/" \
  --recursive=true

# Download a container to local directory
azcopy copy \
  "https://$SA.blob.core.windows.net/app-data/" \
  "./local-download/" \
  --recursive=true

# Copy between storage accounts (server-side, no bandwidth consumed locally)
azcopy copy \
  "https://$SA_SOURCE.blob.core.windows.net/source-container/" \
  "https://$SA_DEST.blob.core.windows.net/dest-container/" \
  --recursive=true

# Sync (copy only changed/new files)
azcopy sync \
  "./local-data/" \
  "https://$SA.blob.core.windows.net/app-data/" \
  --recursive=true \
  --delete-destination=false # Keep blobs not in source

# Upload with explicit blob tier (set to Cool on upload)
azcopy copy "./archive-data.zip" \
  "https://$SA.blob.core.windows.net/backups/archive-data.zip" \
  --block-blob-tier=Cool

# List active jobs (useful for monitoring large transfers)
azcopy jobs list
# Resume a failed/interrupted transfer by job ID
azcopy jobs resume <job-id>

Architecture Patterns: Blob Storage in Real-World Azure Solutions

Azure Blob Storage is rarely used in isolation — it is the storage layer that appears in nearly every Azure architecture. Understanding the standard integration patterns prevents common design mistakes.

Pattern 1: Static Web Content Serving

Enable the Static Website feature on a storage account to serve HTML, CSS, and JavaScript directly from Blob Storage via the $web container — with a public endpoint, no App Service required. Pair with Azure CDN or Azure Front Door for global edge caching and custom domain support with HTTPS. Best for single-page applications, documentation sites, and marketing pages that don't require server-side rendering.

Pattern 2: Event-Driven Processing with Azure Functions

Blob Storage integrates natively with Azure Functions via the Blob Trigger — a Function fires automatically when a new blob is created in a container. This enables serverless processing pipelines: a document uploaded to the input container triggers a Function that processes it (resizes an image, extracts text, runs inference, validates format) and writes the result to an output container. No polling, no queue management, no server to manage.

Pattern 3: Data Lake with ADLS Gen2

When you create a Blob Storage account with --enable-hierarchical-namespace true, you create an Azure Data Lake Storage Gen2 account. ADLS Gen2 adds a true hierarchical directory structure to flat object storage, enabling efficient directory-level operations that Blob Storage cannot perform natively. Renaming a directory with 100,000 files requires 100,000 API calls in plain Blob Storage — it is one atomic operation in ADLS Gen2. Used by Azure Synapse Analytics, Azure Databricks, and Microsoft Fabric as the standard data lake storage layer.

Pattern 4: Application Backup and Disaster Recovery

GRS or RA-GZRS storage accounts provide automatic cross-region replication for disaster recovery. App Service backups, Azure SQL Database long-term retention, and VM disk snapshots all write to Blob Storage. Use lifecycle policies to automatically archive backups older than 30 days and delete backups older than the retention requirement — preventing backup storage from becoming an unbounded cost center.

Figure 5 — Event-driven blob processing pattern: upload triggers serverless pipeline without polling or queues

The Blob Trigger pattern is the most common Blob Storage integration in Azure. No polling — Azure Event Grid notifies the Function within milliseconds of a new blob appearing. The Function reads the blob via Managed Identity (no keys), processes it, and writes the result. This pattern scales automatically: 10,000 simultaneous uploads trigger 10,000 parallel Function invocations.

Cost Optimization: The 8 Rules That Keep Blob Storage Bills Predictable

Azure Blob Storage bills are more complex than a per-GB rate suggests. The actual bill is the sum of storage costs (per GB at tier rate), transaction costs (per PUT, GET, LIST, COPY operation), retrieval costs (for Cool, Cold, Archive tiers), early deletion penalties (for data deleted before minimum retention period), and egress costs (data transferred out of Azure or between regions). Understanding each component prevents "bill shock" surprises.

The 8 Cost Optimization Rules

1Implement lifecycle management before anything else. Organizations that implement lifecycle policies typically see 40–60% cost reduction within three months as accumulated hot data cascades to cooler tiers automatically. Set it up on day one for every storage account, not after the first large bill.

2Batch small files before moving to Cool/Cold/Archive. Due to the 128 KiB minimum billable object size on cooler tiers (as of July 2026 new accounts), a pipeline generating millions of small JSON events will cost 10–30× more if each is tiered individually. Consolidate into hourly or daily Parquet/ZIP archives before lifecycle policies can move them.

3Never put data in Archive that might be needed urgently. Archive rehydration takes 1–15 hours and incurs retrieval fees ($0.02/GB) plus expensive read operation costs ($5.50–$6.50 per 10,000 requests). Archive is strictly for data you are confident will not be accessed for months. When in doubt, use Cold tier instead.

4Use ZRS for production, LRS for dev/test, not GRS for everything. Downgrading non-critical storage from GRS to LRS cuts the storage bill for those accounts roughly in half. Most dev/test data does not require cross-region redundancy. Reserve GRS and RA-GZRS for production data with actual disaster recovery requirements.

5Enable last-access-time tracking and build access-pattern-based policies. Age-based lifecycle policies (move after 30 days) miss data that is still actively accessed. Access-time-based policies (move only if not accessed for 30 days) are more accurate and avoid the higher access costs of putting frequently-read data in Cool tier.

6Monitor transaction costs, not just storage costs. A single poorly-designed application that calls LIST on large containers repeatedly can generate thousands of dollars in transaction charges on a storage account with only a few GB of data. Set Azure Cost Management alerts on storage transaction volume — transaction charges routinely add 30–70% to the theoretical storage-only bill.

7Delete soft-deleted blobs and old versions regularly. When soft delete is enabled (recommended: 30-day window), deleted blobs are retained and billed at their storage tier rate. If soft-deleted blobs and old versions are not explicitly cleaned up by lifecycle policy, they accumulate silently — billing you for data you believe you have deleted. Add a version cleanup rule to every lifecycle policy.

8Use Reserved Capacity for Hot tier at scale. Committing to 1 or 3 years of Hot tier storage capacity reduces the effective per-GB rate by up to 38%. For data that is permanently in Hot tier (active application data, media serving), reserved capacity is one of the highest-return FinOps investments in the Azure storage billing model.

Frequently Asked Questions

What is the difference between Azure Blob Storage and Azure Files?

Azure Blob Storage is object storage accessed via HTTP/HTTPS REST APIs — each blob is retrieved by its URL, making it ideal for application data, media files, backups, and cloud-native workloads where the application constructs the blob URL programmatically. Azure Files provides managed file shares accessed via SMB (Windows file shares) and NFS protocols — it mounts as a network drive on Windows or Linux servers. If your application expects a file system with directories you can browse, mount, and access with standard OS file operations, use Azure Files. If your application was written to work with object storage APIs (or S3-compatible APIs), use Blob Storage. Most cloud-native applications use Blob Storage; most lift-and-shift migrations from on-premises file servers use Azure Files.

Can I change the storage account type or redundancy option after creation?

You can upgrade the redundancy level after creation (e.g., LRS → ZRS, LRS → GRS) without downtime or data migration. However, you cannot downgrade redundancy in-place (e.g., GRS → LRS requires creating a new storage account and migrating data). You cannot convert a GPv1 account to Premium Block Blob or vice versa — you would need to create a new account and use AzCopy to migrate data. The ADLS Gen2 hierarchical namespace (HNS) setting is irrevocable at creation time — you cannot enable or disable it on an existing storage account. Plan your storage account type and HNS requirement before creating the account.

How do I serve blobs publicly for a static website or CDN without enabling public access on the whole account?

For a static website, enable the Static Website feature on the storage account (not public blob access) — this serves files from the special $web container via the static website endpoint without making other containers public. For selective public access to specific blobs (e.g., product images), you can generate SAS tokens with long expiry for CDN origins, or use Azure CDN with the storage account as a private origin using the CDN's managed identity for authentication — this keeps allow-blob-public-access set to false while still serving content publicly through the CDN layer. Never enable account-level public blob access for production workloads containing non-public data.

My lifecycle policy is configured but data isn't moving tiers. What's wrong?

The most common causes in order of frequency: (1) The policy hasn't run yet — policies run once per day and the first execution may take up to 24 hours after creation. (2) The blob was modified recently — a blob uploaded 25 days ago with a "move to Cool after 30 days" rule won't move for another 5 days; the daysAfterModificationGreaterThan condition uses the last modification timestamp. (3) The prefix doesn't match — prefix filters are case-sensitive and must match the blob name exactly including any virtual directory path. (4) The account is Premium Block Blob — lifecycle tiering is not supported on Premium Block Blob accounts. (5) The blobs are append or page blobs — tiering is only supported for block blobs. Check the lifecycle policy execution logs in Azure Monitor: az monitor diagnostic-settings create to route storage diagnostics to a Log Analytics workspace and query StorageBlobLogs for lifecycle execution events.