Apply Storage Access Tiers

You've built apps that store blobs, but your monthly bill is creeping up because every byte sits in the same high-performance tier. Azure Storage access tiers — Hot, Cool, and Archive — let you match storage cost to data temperature, so you don't overpay for rarely accessed backups or underperform for active files. In this lesson, you'll learn how to apply storage access tiers in Azure, complete a hands-on exercise, and know exactly when to choose each tier.

The problem this lesson solves

Blob storage is cheap, but it's not one price. If you store every file in the Hot tier — the default for fast access — you're paying premium rates for data you touch once a quarter. That's like renting a Ferrari to drive to the mailbox. Conversely, if you dump everything into Archive to save money, users hit 15-minute retrieval delays for files they need now.

The core pain: cost vs. access speed. Without a strategy, you either overpay for cold data or suffer latency for hot data. This lesson gives you a simple switch — the access tier — that lets you optimize both.

Core concept / mental model

Think of access tiers as storage temperatures:

• Hot = freshly cooked meal — instant access, highest cost.
• Cool = leftovers in the fridge — cheap, a bit slower, fine for occasional use.
• Archive = freezer — very cheap, but you must thaw it (rehydrate) before eating.

In Azure Blob Storage, a tier is a property on a blob (or a storage account default). It controls where data is physically stored (SSD-backed for Hot, HDD for Cool, offline for Archive) and the price per GB and per operation.

Key definitions: - Blob — an object (file) in Azure Blob Storage. - Storage account — the container that holds blobs; has a default access tier. - Rehydration — moving an Archive blob to Hot or Cool so it becomes readable.

Visualize it as a sliding scale:

Hot (fast, $$)  →  Cool (slower, $)  →  Archive (offline, $)

You can set a default tier at the account level (applies to new blobs) or per blob at upload time or after (by changing the tier property).

How it works step by step

1. Create a storage account (if you don't have one). Choose a default tier — typically Hot for new dev projects.
2. Upload blobs — either let them inherit the default or explicitly set a tier using the Azure portal, CLI, SDK, or REST API.
3. Review access patterns — identify data that's rarely accessed (logs, old media) vs. frequently read (user uploads, images).
4. Change the tier — for existing blobs, update the tier property. This is a metadata operation (instant) for Hot↔Cool; for Archive, you must rehydrate before reading.
5. Monitor costs — use Azure Cost Management to see the impact per tier.

What causes tier changes? - Manual — you call Set Blob Tier or use the portal. - Automated — Azure lifecycle management policies can move blobs automatically after N days (e.g., Hot after 30 days, Cool after 90).

Hands-on walkthrough

Let's get your hands dirty. We'll use the Azure CLI and Python to apply tiers to blobs in a test account.

Prerequisites

• Azure subscription (free tier works)
• Azure CLI installed, or use Azure Cloud Shell (bash)
• Python 3.10+ if you prefer the SDK approach

Step 1: Create a storage account (CLI)

# Set variables
RESOURCE_GROUP="rg-tiers-demo"
STORAGE_ACCOUNT="sttiersdemo"
LOCATION="eastus"

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

# Create storage account (default tier Hot)
az storage account create \
  --name $STORAGE_ACCOUNT \
  --resource-group $RESOURCE_GROUP \
  --location $LOCATION \
  --sku Standard_LRS \
  --access-tier Hot

Step 2: Upload blobs with different tiers

# Upload a file as Hot (default)
az storage blob upload \
  --account-name $STORAGE_ACCOUNT \
  --container-name data \
  --name active.log \
  --file ./active.log \
  --auth-mode login

# Upload as Cool
az storage blob upload \
  --account-name $STORAGE_ACCOUNT \
  --container-name data \
  --name archive.log \
  --file ./old.log \
  --tier Cool \
  --auth-mode login

# Check the tier of a blob
az storage blob show \
  --account-name $STORAGE_ACCOUNT \
  --container-name data \
  --name archive.log \
  --query properties.accessTier \
  --auth-mode login

Expected output: The last command prints Cool.

Step 3: Change tier with Python SDK

from azure.storage.blob import BlobServiceClient

# Connect (use DefaultAzureCredential for production)
conn_str = "<connection_string>"
service = BlobServiceClient.from_connection_string(conn_str)

container = service.get_container_client("data")
blob = container.get_blob_client("active.log")

# Move from Hot to Cool
blob.set_http_headers(content_settings=None)
blob.set_standard_blob_tier("Cool")

# Verify
print(f"Tier after change: {blob.get_blob_properties().access_tier}")

Pro tip: In the CLI, use --tier on upload. For existing blobs, use az storage blob set-tier.

Step 4: Archive and rehydrate

# Set to Archive
az storage blob set-tier \
  --account-name $STORAGE_ACCOUNT \
  --container-name data \
  --name archive.log \
  --tier Archive \
  --auth-mode login

# Try to read (will fail)
az storage blob download \
  --account-name $STORAGE_ACCOUNT \
  --container-name data \
  --name archive.log \
  --file ./from_archive.log \
  --auth-mode login
# ERROR: Blob is in Archive tier, rehydrate first

# Rehydrate (copy to Hot)
az storage blob copy start \
  --source-blob archive.log \
  --destination-account $STORAGE_ACCOUNT \
  --destination-container data \
  --destination-blob active.log \
  --tier Hot \
  --auth-mode login

# Wait a few minutes, then download works

Compare options / when to choose what

When to choose what: - Hot for anything you read/write in real time (user uploads, session data). - Cool for data you access occasionally but want in milliseconds (old reports, infrequent analytics). - Archive for data you must keep but rarely touch (audit logs, legal holds) — you accept the rehydration delay.

Variations: - Premium tier — for high-performance block blobs (SSD-backed), not an access tier but a performance tier. - Lifecycle management — automate tier transitions with JSON policy rules (e.g., "move to Cool after 30 days, Archive after 90"). - Azure Data Lake Storage Gen2 — same tiers, but you can set them on directories too.

Troubleshooting & edge cases

Error: "Blob is in Archive tier" - You tried to read an Archive blob. Run a copy operation with --tier Hot to rehydrate. Set --rehydrate-priority Standard (default) or High for faster (but more expensive) retrieval.

Tier change stuck in "Pending" - For Archive → Hot, rehydration takes 1–15 hours (Standard) or <1 hour (High). Monitor with az storage blob show --query properties.rehydrationStatus.

Cost surprises - Changing tier from Cool to Hot incurs a write operation and early deletion fee (if data is deleted within 30 days of Cool or 180 days of Archive). Plan transitions to avoid charges.

Account default tier doesn't apply to existing blobs - The account default only affects new blobs. Existing blobs keep their tier. Use lifecycle policies or manual set-tier for bulk changes.

SDK authentication failure - Use DefaultAzureCredential with managed identity (see earlier lessons) instead of connection strings in production. The CLI --auth-mode login works with your Azure login.

What you learned & what's next

You now understand the core idea behind applying storage access tiers: matching storage cost to data temperature. You can create a storage account, upload blobs, and switch between Hot, Cool, and Archive using the Azure CLI and Python SDK. You also know the trade-offs — latency vs. cost — and how to troubleshoot common errors like rehydration delays.

Key points to remember: - Set a default tier at the account level for new blobs, but override per blob when needed. - Archive requires rehydration before reading — plan for >15 min latency. - Lifecycle management automates tier transitions, but manual set-tier works fine for small adjustments.

What's next: In the next lesson, you'll explore lifecycle management policies to automate tier transitions at scale — turning today's manual steps into a self-managing cost optimization strategy.