Recommend a Solution for Storing Unstructured Data — Lesson

This lesson teaches you how to evaluate Azure's unstructured-storage portfolio — Blob, File, Queue, Table, and Data Lake Storage Gen2 — and recommend the right service, account kind, and access tier for a given workload. The decisions you make here cascade through the rest of an architecture: cost, durability, throughput, and even what compute and analytics services you can choose downstream all hinge on whether you picked the right storage shape upstream.

Reference: AZ-305 exam study guide, Unit 2 (Data storage design).

Why This Matters

Unstructured data is the largest data class in most enterprises — backups, telemetry, media, IoT events, ML training sets, document archives. On AZ-305 it accounts for at least one design scenario per exam, and it underpins analytics, business continuity, and content-delivery solutions you will meet in later units. Choosing wrong is expensive: putting an archive on Hot doubles your storage bill, putting a chatty SAP workload on Standard FileStorage throttles your business, and using a flat blob container when the workload is analytics throws away the directory semantics that make Data Lake Storage Gen2 fast. As a solutions architect you do not write to these services — you pick them — and the exam tests your ability to map requirements to the right SKU.

Prerequisites

• Azure resource hierarchy (subscription → resource group → resource). Self-check: where does a storage account live in that hierarchy?
• Regions and availability zones. Self-check: name an Azure region that supports availability zones.
• Authentication models (Microsoft Entra ID, Shared Key, SAS). Self-check: which auth method should new applications prefer for blob access?
• Basic networking (private endpoints, service endpoints, public endpoints). Self-check: what does a private endpoint give you that a service endpoint does not?
• Cost model basics (storage cost vs. transaction cost vs. egress). Self-check: which of those three is typically dominant for archive workloads?

Learning Objectives

By the end of this lesson you will be able to:

1. Recommend the correct storage account kind (General Purpose v2, BlockBlobStorage, FileStorage) for a given workload.
2. Evaluate the four block-blob access tiers (Hot, Cool, Cold, Archive) against access-frequency and minimum-retention constraints.
3. Differentiate block, append, and page blobs and pick the correct type for backups, logs, and VHDs.
4. Decide when to enable hierarchical namespace (Data Lake Storage Gen2) versus using flat blob containers.
5. Design a file-share solution by choosing between SMB and NFS, Standard and Premium, and Azure File Sync for hybrid scenarios.
6. Recommend between Azure Queue Storage and Service Bus for asynchronous messaging in an architecture.

Building Blocks

Storage account — Think of it as a physical warehouse with multiple loading bays. Formally, the top-level Azure resource that exposes one or more of Blob, File, Queue, Table, Data Lake endpoints under a globally unique DNS name. It matters because the account (not the container) is where you configure replication, network rules, encryption, and pricing tier — get the account wrong and everything below inherits the wrong settings.

Blob — Like a file in a flat folder. Formally, an immutable-by-default object addressed by https://<account>.blob.core.windows.net/<container>/<name>. It matters because almost every "unstructured" requirement on AZ-305 lands on blob storage by default, and the exam tests sub-flavours (block / append / page) and tiers.

Container — A logical bucket inside an account, similar to an S3 bucket. Formally, a flat namespace that groups blobs and is the unit at which public-access level and most policies are set. It matters because IAM and lifecycle rules often scope to the container, not the account.

Hierarchical namespace (HNS) — Real folders, not name-prefix folders. Formally, a feature toggle on a storage account that promotes blob "directories" from string-prefix tricks to first-class, atomically-renameable directory objects with POSIX ACLs. It matters because analytic engines (Spark, Synapse, Databricks) need atomic directory rename for fast commit semantics; without HNS, listing a million-file directory is $\text{O}(n)$ across pages.

Access tier — A pricing dial per blob (or default for the account). Formally, one of Hot, Cool, Cold, Archive, where storage cost decreases and per-read cost and minimum-retention period increase as you move down. It matters because tiering wrong is the single biggest blob-cost mistake on the exam.

File share — A network-mounted folder that talks SMB or NFS. Formally, a fully managed share inside a storage account, addressed as \\<account>.file.core.windows.net\<share> (SMB) or <account>.file.core.windows.net:/<account>/<share> (NFS). It matters because lift-and-shift Windows servers and Linux HPC clusters expect a real network share, not a blob container.

Azure File Sync — A Windows Server agent that turns a local server into a cache of an Azure file share. Formally, a tiering and sync service that keeps hot files local and cool files in Azure with a stub on-prem. It matters when the requirement is "keep on-prem performance for active files but move cold data to Azure" — a common AZ-305 hybrid scenario.

Queue — A simple FIFO mailbox. Formally, an HTTP-accessible message queue with 64 KB per message and 7-day default TTL. It matters as the "good enough" decoupling primitive when you do not need Service Bus features.

Premium Block Blob — SSD-backed, low-latency blob storage. Formally, a BlockBlobStorage account on the Premium performance tier, billed by provisioned capacity rather than per-GB stored. It matters for sub-10 ms read scenarios — interactive analytics, IoT-at-scale, AI inference caches.

Deep Dive

Storage account kinds — pick the chassis first

Every unstructured-storage decision starts with the account kind, because the kind locks in which sub-services and which performance tier are available. Three modern choices matter on the exam.

General Purpose v2 (GPv2) is the default. It supports Blob, File, Queue, Table and (with HNS turned on) Data Lake Gen2, all on the Standard performance tier (HDD-backed). Pick GPv2 when you need more than one service in the same account or when cost is the primary driver. GPv2 is what you should propose unless the scenario explicitly demands sub-10 ms latency or the special features below.

BlockBlobStorage (Premium) supports only block and append blobs, on SSD. Pick it for high-transaction, low-latency workloads — IoT ingest, AI training data hot sets, interactive query layers. The trade-off: page blobs and file shares are not available, and storage cost per GB is roughly 4–10× GPv2 Hot.

FileStorage (Premium) supports only file shares, on SSD. Pick it for SAP, HPC, or Windows-server workloads where IOPS and sub-millisecond latency matter. It also unlocks NFS 4.1 shares — Standard FileStorage shares are SMB-only.

[!IMPORTANT] Account kind cannot be changed after creation for BlockBlobStorage and FileStorage. If your scenario allows a future shift to Premium, design for it now (e.g., use a separate account so you can migrate without disturbing GPv2 data).

A minimal, production-ready GPv2 account with HNS, GZRS replication, and locked-down defaults looks like this in Bicep:

Blob types — block, append, page

Inside a blob container, every object is one of three types and the type is fixed at creation.

Block blobs are what most people mean by "blob": files of up to $190.7 TiB composed of $50{,}000$ blocks of up to $4{,}000$ MiB each. They are optimized for streaming and parallel uploads (PutBlock + PutBlockList). Pick them for media, backups, ML datasets, and anything where you write once and read many times.

Append blobs behave like log files: you can append blocks but cannot modify or delete individual blocks (you can only delete the whole blob). Maximum size is 195 GiB. Pick them for diagnostic logs, audit trails, and any append-only telemetry stream.

Page blobs are random-access 512-byte page collections, up to 8 TiB. They are the storage primitive behind unmanaged Azure VM disks and any workload that needs in-place sector-level writes. Pick them only when an application explicitly requires random-access semantics — most architectures should prefer Managed Disks (which use page blobs internally) over raw page blobs.

[!WARNING] If a scenario says "store VHD files for IaaS VMs", the correct exam answer is almost always Managed Disks rather than directly recommending page blobs. Raw page blobs leave you managing the LRS/ZRS replication and snapshots yourself.

Access tiers and lifecycle management

Block blobs (and only block blobs) have an access tier:

Archive is offline — you cannot read directly from it. You must rehydrate (to Hot or Cool) the blob first, which takes up to 15 hours for standard priority. Choose Hot priority rehydration ($\leq 1$ hour, premium charge) when SLA matters.

Lifecycle management policies move blobs between tiers automatically based on last-modified or last-accessed timestamps. A typical policy:

To move an individual blob on demand:

[!TIP] Tiering down before the minimum-retention day on the destination tier triggers an early-deletion fee equal to the remaining storage you would have paid. Cool-after-10-days then archive-after-15-days is almost always more expensive than letting blobs age 30 days as Cool first.

Data Lake Storage Gen2 — when flat is not enough

Data Lake Storage Gen2 (ADLS Gen2) is not a separate service — it is Blob Storage with the hierarchical namespace feature turned on at account creation. Two consequences:

1. Atomic directory rename. In flat blob storage, "renaming /raw to /raw-archived" is $\text{O}(n)$ blob copies. With HNS it is one metadata operation.
2. POSIX ACLs at directory and file level, which Spark/Hadoop ecosystems expect.

Pick ADLS Gen2 when the workload is analytics-driven: Azure Synapse, Databricks, HDInsight, Azure Data Factory all gain large performance and cost wins from HNS. Pick flat blob when the workload is ingestion, archival, or generic object storage and you do not need directory semantics.

[!NOTE] HNS is enable-only at creation and cannot be turned off. Microsoft does offer a one-way migration utility from flat blob to HNS, but no path back. Bake this decision into the account-design step.

File shares — SMB, NFS, Standard, Premium, Sync

Azure Files exposes managed SMB and NFS shares. Four design knobs:

1. Protocol: SMB 3.x (Windows-friendly, supports identity-based auth via Microsoft Entra Domain Services or AD DS) or NFS 4.1 (Linux-friendly, security via network rules only).
2. Performance tier: Standard (HDD, transaction-billed) or Premium (SSD, provisioned-capacity billed). Premium runs on FileStorage accounts, Standard on GPv2.
3. Redundancy: LRS, ZRS, GRS, GZRS. Premium supports only LRS and ZRS.
4. Hybrid: pair the share with Azure File Sync to cache hot files on a Windows Server and tier cold files to Azure.

Queue Storage vs. Service Bus

Both decouple producers from consumers. Queue Storage is the cheap, simple option: 64 KB max message, 500 TB queue size, no ordering guarantees beyond best-effort, no built-in dead-letter or transactions. Service Bus is the enterprise option: 256 KB (Standard) or 100 MB (Premium) messages, FIFO with sessions, transactions, dead-letter queues, topics/subscriptions for pub/sub.

Recommend Queue Storage when the architecture only needs basic decoupling and cost-per-message is the dominant constraint. Recommend Service Bus when the design calls for ordering, pub/sub, transactions, or message sizes above 64 KB.

Worked Examples

Easy — Contoso media archive

Problem. Contoso uploads 10 TB of video originals per month. Editors access this month's videos daily; videos older than 6 months are accessed less than once per quarter; videos older than 3 years are kept only for legal compliance and may never be opened. Recommend a storage solution and tiering.

Solution.

1. Account: GPv2 (Blob is the only sub-service used; no Premium SLA required).
2. Container: one container, replication GRS (legal compliance over media).
3. Blob type: block blobs (write-once, read-many).
4. Tiering policy: lifecycle rule moves blobs to Cool after 30 days, Cold after 180 days, Archive after 1095 days, delete after 3650 days.

[!NOTE] The "3 years then maybe never" pattern is a textbook archive case. Cold (rather than Cool) for the 6-month-to-3-year band is cheaper now that Cold exists.

Medium — Fabrikam SAP HANA on Azure

Problem. Fabrikam is migrating SAP HANA to Azure. They need a shared /sapmnt and /usr/sap/trans mount accessible to several Linux VMs, with sub-millisecond latency, $20{,}000$ IOPS, and zone-redundancy. Recommend a storage solution.

Solution.

1. Account kind: FileStorage (Premium tier — required for NFS and for IOPS).
2. Protocol: NFS 4.1 (Linux + low-latency).
3. Redundancy: ZRS (Premium FileStorage supports LRS and ZRS only; ZRS satisfies zone-redundancy).
4. Provisioned capacity: $\geq 1$ TiB (IOPS scales with provisioned size; $20{,}000$ IOPS requires $\sim 4$ TiB).

[!NOTE] Do not be tempted by Standard FileStorage here — it is HDD-backed and SMB-only. SAP support requires Premium NFS for /sapmnt.

Hard — Globex IoT analytics platform

Problem. Globex ingests 5 billion device events per day ($\sim 1.5$ KB each) into Azure. The data science team needs to run Synapse Spark jobs over the last 90 days; raw events older than 90 days move to an immutable archive for 7 years for regulatory reasons; a Power BI dashboard hits a curated view of last-24-hour data that must respond in under 500 ms. Recommend an end-to-end storage design.

Solution.

1. Hot ingest layer: BlockBlobStorage (Premium) for the last 24 hours' events, partitioned by device-region/yyyy/mm/dd/hh. Premium gives the sub-500 ms latency the Power BI dashboard needs and the IOPS for sustained ingest.
2. Analytics layer: separate GPv2 account with hierarchical namespace enabled (ADLS Gen2). Daily job copies events from Premium to ADLS Gen2 in Hot tier. Synapse Spark reads ADLS Gen2 directly, gaining atomic directory rename for MERGE INTO operations.
3. Archive: lifecycle policy on the ADLS Gen2 account moves blobs to Cool after 90 days, Archive after 1 year, deletes after 7 years. Container-level immutability policy (time-based retention) prevents tampering.
4. Auth: Microsoft Entra ID–issued user-delegation SAS tokens for Power BI; managed identity for Synapse and the ingest service.

[!NOTE] Splitting hot ingest from analytics into two accounts is the trick the exam likes — one account cannot be both BlockBlobStorage Premium and GPv2 + HNS. Architecting two accounts and a daily lift is cheaper and faster than putting everything on Premium.

Visual Explanations

Figure 1 — Decision tree for unstructured-storage selection.

This decision tree is the mental model for the exam. The first split — file vs. blob vs. queue vs. table — is set by the data shape; later splits are set by performance and feature requirements.

Figure 2 — Lifecycle of a blob across access tiers.

A blob's life is a one-way slide down the tiering staircase, with rehydration as the only path back up. Notice rehydration jumps directly to Hot or Cool — there is no "rehydrate to Cold" path.

Figure 3 — Hub-and-spoke storage topology with private endpoints (TikZ).

This is the canonical "private storage" topology. The two storage accounts (one Blob, one File) live outside the VNet, but are reachable only through private endpoints with IPs inside the hub. Spokes route to the hub via peering and never see public IPs.

Figure 4 — Blob type comparison.

Blob type is set at creation and cannot be changed. The exam tests this by giving you a workload pattern (write-once, append-only, random-write) and asking which type fits.

Common Mistakes

❌ Myth: Premium block blob is just "faster Hot" — pick it whenever cost allows. ✅ Reality: BlockBlobStorage Premium cannot live in the same account as GPv2's other services and does not support Cool/Cold/Archive tiering. Lifecycle rules silently no-op on Premium block blobs. Why it's tricky: the portal lets you create the account fine, but architects discover after 6 months that nothing has tiered down and the bill has not dropped.

❌ Myth: Hierarchical namespace can be turned on later if you need it. ✅ Reality: HNS is set at account creation. Microsoft offers a one-way migration utility from flat blob to HNS, but there is no supported way back. Why it's tricky: the architect imagines toggling a checkbox; the team rebuilds the account three months in, and downstream connection strings change.

❌ Myth: Standard FileStorage and Premium FileStorage both support NFS. ✅ Reality: NFS 4.1 is only available on Premium FileStorage (Premium file shares). Standard tier is SMB-only, regardless of OS. Why it's tricky: the requirement "Linux file share" pulls candidates toward Standard for cost reasons, missing that Standard cannot serve NFS at all without a cifs-utils SMB workaround that defeats the purpose.

❌ Myth: Queue Storage and Service Bus are interchangeable for "send a message". ✅ Reality: Queue Storage caps at 64 KB per message, has no FIFO guarantee across consumers, and no transactions or dead-letter. Service Bus offers all of those plus topics/subscriptions. Why it's tricky: the exam scenario sometimes asks "cheapest decoupling option that works" — that is Queue Storage. Other times it asks for "ordered, transactional, 200 KB messages" — that is Service Bus, and Queue Storage is wrong.

Practice Exercises

Exercise 1 — 🟢 Easy. A startup wants to host a static website's images and CSS in Azure as cheaply as possible, with global users. Which account kind, redundancy, and feature should you recommend?

▶💡 Hint

Static hosting is a built-in feature of one specific kind of account.

▶✅ Solution

GPv2 account, RA-GZRS (or LRS if budget is tight), with Static Website enabled and Azure Front Door Standard or Front Door in front. The Hot tier is fine since traffic is steady.

Exercise 2 — 🟢 Easy. Which Azure Storage object type would you recommend for a security tool that streams diagnostic events line-by-line for a year before rotation?

▶💡 Hint

Three blob types — only one is append-only.

▶✅ Solution

Append blob. Block blobs would require rewriting the whole blob on each batch; page blobs are random-write and overkill.

Exercise 3 — 🟡 Medium. A compliance team must keep 50 TB of historical PDFs for 10 years; access happens only during occasional audits ($\leq 4$ times per year, 24-hour notice). Recommend a tier and any policy.

▶💡 Hint

24-hour notice rules out Archive's standard rehydration window. Or does it?

▶✅ Solution

Archive tier with Hot priority rehydration on demand (rehydration completes in $\leq 1$ hour, well under 24 hours). Add a time-based immutability policy of 10 years on the container. Lifecycle rule: tierToArchive immediately on upload; delete after 3650 days.

Exercise 4 — 🟡 Medium. Contoso runs a Linux-based ML training cluster of 200 VMs that all need to read the same 10 TB training set with high throughput. Recommend a storage shape.

▶💡 Hint

Read-heavy, parallel, identical dataset — file share or blob?

▶✅ Solution

GPv2 blob storage with BlobFuse (or direct SDK) on each VM. For higher throughput, BlockBlobStorage Premium is justified at this scale. NFS file share is a viable alternative (Premium NFS) but blob is cheaper and parallelizes better for read-only training sets.

Exercise 5 — 🔴 Hard. A bank's payments app produces 200 KB messages that must arrive in strict order per account, support transactions, and dead-letter on failure. Which Azure messaging service do you recommend, and what stops you from using the cheaper option?

▶💡 Hint

Recall the 64 KB and FIFO limits.

▶✅ Solution

Service Bus (Standard or Premium tier). Queue Storage is ruled out by the 64 KB message limit, lack of strict FIFO across consumers, and absence of transactions and DLQ. Use Service Bus sessions to enforce per-account ordering.

Exercise 6 — 🔴 Hard. An architect proposes one Premium FileStorage account hosting both a Standard SMB share for office documents and a Premium NFS share for a Linux database. What is wrong with the design?

▶💡 Hint

What account kinds support what tiers?

▶✅ Solution

A FileStorage account is always Premium and cannot host Standard shares. The architect needs two accounts: one GPv2 for the Standard SMB share and one FileStorage for the Premium NFS share.

Exercise 7 — 🔴 Hard. A retail chain wants on-prem branch servers to keep performant local file access while consolidating 80% of cold data in Azure for cost. They have 50 branches. Recommend a design.

▶💡 Hint

On-prem cache + Azure tail = which Azure feature?

▶✅ Solution

Azure File Sync. Each branch runs a Windows Server registered to a Sync Group; the local server keeps recently-accessed files and tiers cold files as stubs. Use Standard SMB shares (Sync does not support Premium NFS) and GRS for cross-region resilience.

Summary & Concept Map

• Choose the account kind first: GPv2 for default and mixed workloads; BlockBlobStorage for low-latency blobs; FileStorage for low-latency or NFS file shares.
• Pick the blob type by mutability pattern: block (write-once), append (logs), page (random-write VHDs).
• Tier blobs by access frequency and minimum-retention rules: Hot → Cool (30 d) → Cold (90 d) → Archive (180 d).
• Enable HNS at creation when the workload is analytics; you cannot toggle it later.
• File shares: SMB everywhere, NFS only on Premium; pair with Azure File Sync for hybrid scenarios.
• Messaging: prefer Queue Storage for cheap decoupling, escalate to Service Bus when you need ordering, transactions, or messages over 64 KB.
• Lock down access with private endpoints and Microsoft Entra ID identity; never make a production storage account publicly accessible by default.

The concept map turns the lesson into a four-step recipe — kind → sub-service → type → policy — that you can apply to any AZ-305 unstructured-storage scenario.