Azure
Intermediate 15 min read Azure

Azure Storage Accounts

Blob, Files, Queues, Tables and the tiers between them

One storage account hosts Blob, Files, Queues and Tables plus access tiers and replication. Choose the right service, tier and redundancy (LRS/ZRS/GRS) for the data.

Azure StorageBlobFilesaccess tierLRSZRSGRSSAS
Prerequisites: Azure Service Catalog
Before we start

What you will learn

  • Choose among Blob, Files, Queue and Table
  • Understand access tiers and lifecycle policies
  • Pick redundancy (LRS/ZRS/GRS) by durability need
In 60 seconds

A storage account bundles Blob (objects), Files (SMB), Queue (messages), Table (schemaless k/v). Underneath, redundancy is local (LRS), zone (ZRS) or geo (GRS); hot/cool/archive tiers trade cost for latency.

Introduction

What is this?

Azure Storage is a managed service exposing four data families: Blob (unlimited objects with tiers), Files (SMB/NFS mounts), Queue (at-least-once messages), Table (schema-less NoSQL). Redundancy options: LRS (3 copies in one facility), ZRS (3 copies across zones), GRS/RA-GRS (secondary region copies). Access tiers Hot, Cool, Cold, Archive change cost/latency; lifecycle management automates transitions and deletions.

Motivation

Why do you need it?

  • Blob is the default landing zone for uploads, backups and static assets.
  • Files gives you SMB without a file server — a migration fast-path for legacy apps.
  • Queues billet serverless workloads and decouple producers from consumers.
  • Choosing LRS vs GRS up front beats re-architecting when an auditor asks about durability.
Think about it

Mental model

Imagine

A warehouse with shelves, an office filing room, and a post room

Think of

Blob, Files, Queues

Blob = labeled boxes on shelves (objects); Files = the shared filing room everyone works in; Queues = the post room that hands messages along — everything has its landing zone and speed of access.

Mechanics

How it works

  • Blob containers organize objects; each object can sit in a tier: Hot (frequent), Cool (~30d), Cold (~90d), Archive (~180d, slow restore).
  • Files shares mount over SMB/NFS; Queues store up to 64KB messages with visibility timeout; Tables support indexable row storage.
  • Redundancy is configured per account: LRS/ZRS protect local/zone failures; GRS replicates async to a second region.
  • Access is controlled with account keys, SAS tokens (scoped+expiring), and Microsoft Entra-based access where supported.
  • Lifecycle policies + soft delete + versioning protect against deletion and control cost.

Choosing the right storage service and redundancy.

Objects/backups/media
Shared files for apps
Job messages
NoSQL rows
Redundancy
Real world

In production

  • A media app uploads to Blob (Hot), transcodes via Functions, and archives old originals to Cool then Archive by lifecycle rule.
  • A Windows legacy app mounts a Files share for shared config; new pipeline mirrors it to Blob.
  • A job runner enqueues work to a Queue consumed by a worker Function, with a dead-letter queue for failures.
Guidelines

Best practices

  • Enable soft delete + versioning before any incident; they make accidents reversible.
  • Assign customers/data sensitive to LRS/ZRS deliberately; reserved-confidential data often must stay in-region (GRS may violate that).
  • Use SAS with short expiry and restricted permissions instead of account keys.
  • Set lifecycle policies on buckets once; revisit tiering quarterly.
Watch out

Common mistakes

  • Using Blob like a filesystem — it's object storage with different latency/POSIX semantics.
  • Toggling GRS 'just in case' and paying for cross-region replication constantly.
  • Rotating stored account keys manually instead of using Entra-managed identity access.
  • Forgetting queue messages time out — a slow worker means 'lost' items unless you handle invisible messages.
Root cause analysis

Common issues

Error
Files mount hangs on Linux
Root cause

NSG/firewall blocks SMB/NFS 445/2049 or mount target routing

Fix

Allow the port/rule and verify the mount command's share URL path.

Error
Archive blob takes an hour to 'restore'
Root cause

You read from Archive tier without a rehydrate operation

Fix

Copy/Set-Tier to Hot/Cold and wait for rehydration status before reading.

Error
Queue messages processed twice
Root cause

Visibility timeout shorter than processing time, or crash after processing

Fix

Make consumers idempotent; extend visibility or use a processing-completion marker.

When things break

Debugging tips

  • Object missing? Check soft-delete/versioning state and lifecycle removal events.
  • Slow Blob downloads? Check tier (Archive restores are slow) and client location.
  • Queue items vanish? Review the visibility timeout and dual-consumer processing.
  • 'SharedAccessSignature' errors are expiry or scope problems — regenerate with correct scope.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/1
1

Which redundancy replicates to a second region for disaster recovery?

Go deeper

Official documentation

Azure — Storage overview
docs
Azure — Redundancy
docs
Azure — Blob access tiers
docs