CH06-04: Object, File, and Durable Storage

Goal

The previous sections covered relational data and document-oriented data. This section moves to storage services that teams often describe casually as "files," even though the architecture responsibilities are different.

Azure Blob Storage and Azure Files can both hold data that looks like files to humans. They solve different jobs.

The durable idea is:

Blob Storage stores objects; Azure Files provides shared file semantics.

The Short Version

Azure Blob Storage is object storage for unstructured data such as images, documents, backups, logs, exports, media, and data lake files. In plain language, it stores objects that applications access through storage APIs, URLs, SDKs, or related protocols.

Azure Files provides managed file shares in Azure. In plain language, it gives applications or users a shared file system location that can be mounted and accessed through familiar file-share protocols such as SMB or NFS.

The design question is not "Where can I put this file?" The better question is:

Does the application need object access or file-share behavior?

The Responsibility Split

Use this simple comparison first:

Images, PDFs, backups, logs, exports -> Azure Blob Storage
Shared app folder or file share       -> Azure Files

Object storage and file shares differ in how applications interact with them.

Question	Blob Storage	Azure Files
Main job	Store objects such as blobs, documents, images, logs, and exports.	Provide managed shared file shares.
Common access pattern	Object APIs, SDKs, URLs, REST, storage tools, analytics pipelines.	Mounted paths, SMB or NFS-style access, file system APIs.
Data organization	Storage account, containers, blobs, metadata, prefixes.	Storage account, file shares, directories, files.
Strong fit	Product images, invoice PDFs, backups, archive data, logs, data lake zones.	Lift-and-shift apps, shared operational folders, user or application file shares.
Main risk	Treating object storage like a normal mounted file system.	Using file shares when object storage would be simpler and more scalable.

This distinction matters because protocol and application expectations drive the design.

Azure Blob Storage

Blob Storage is a strong fit when data is stored and retrieved as objects.

Examples include:

Product images.
User-uploaded documents.
Invoice PDFs.
Video and audio files.
Backup and restore files.
Logs and diagnostic exports.
Analytics extracts and data lake landing zones.
Static content for applications or websites.

The mental model is:

Storage account
	|
	+-- Container: product-images
	|       +-- product-123/main.jpg
	|       +-- product-123/detail-01.jpg
	|
	+-- Container: invoices
			+-- 2026/06/invoice-456.pdf

Applications usually store a reference to the blob in a database. For example, Azure SQL might store the invoice record, customer, amount, and status, while Blob Storage holds the PDF itself.

Azure Files

Azure Files is a strong fit when the requirement is shared file access.

Examples include:

A legacy application that expects a shared folder path.
A lift-and-shift workload that uses file shares for application data.
Shared operational folders used by multiple systems.
Developer, diagnostic, or tool shares in controlled environments.
Stateful containers or virtual machines that need shared file system access.

The mental model is:

Application instances or users
	|
	+-- Mounted Azure file share
			|
			+-- /operations/imports
			+-- /operations/exports
			+-- /shared-config

If an application uses file system APIs, expects directory paths, or depends on file-share behavior, Azure Files may be appropriate. If the application only needs to upload, download, serve, archive, or process objects, Blob Storage is usually the cleaner starting point.

Lifecycle and Retention

Storage design is not finished when data is uploaded.

For Blob Storage, lifecycle management is often a major part of the architecture. Objects may start hot because users access them frequently. Later they may move to cooler tiers or be deleted after a retention period. Logs and exports may grow quietly for years if nobody designs lifecycle rules.

Ask:

Which data is accessed frequently?
Which data must be retained for compliance or audit?
Which data can move to a cooler tier?
Which data can be deleted?
Which containers or prefixes need different lifecycle policies?
What restore or rehydration behavior does the business expect?

For Azure Files, lifecycle thinking is still important, but the conversation often includes share performance, snapshots, backup, user access, synchronization, and whether the file-share dependency should be modernized over time.

Security and Private Access

Both Blob Storage and Azure Files need deliberate security design.

Consider:

Identity-based access where possible.
Least-privilege authorization.
Private endpoints when storage should not be reached over the public internet.
Encryption and key management requirements.
Network rules and trusted access paths.
Logging, monitoring, and alerting.
Soft delete, versioning, snapshots, backup, or immutability where appropriate.
Separation into different storage accounts when redundancy, lifecycle, access, or ownership requirements differ.

Do not treat storage as a harmless utility. Storage often contains the business records, customer content, audit exports, and recovery material that the rest of the architecture depends on.

Example: Images, Invoices, and an Operations Share

Return to the commerce platform.

Product images should usually go to Blob Storage. The product catalog database can store image metadata and blob references, while the images themselves live as objects.

Invoice PDFs should also usually go to Blob Storage. The invoice record may live in Azure SQL, but the PDF is object data with retention, access control, and lifecycle needs.

Analytics exports may go to Blob Storage as files for downstream processing.

A small legacy operations process may need Azure Files if it reads from and writes to a shared folder path that several application instances or users mount.

Azure SQL
	|
	+-- invoice record and blob reference
			|
			v
		Blob Storage: invoice PDF

Legacy operations tool
	|
	v
Azure Files: shared operations folder

The design is clearer because Blob Storage and Azure Files are not treated as interchangeable.

Common Mistakes

Choosing Azure Files when object access would be simpler.
Choosing Blob Storage when the application truly requires file-share semantics.
Ignoring lifecycle policies and access tiers for growing object data.
Forgetting private endpoints, identity, authorization, encryption, monitoring, and backup decisions.
Storing large objects in relational tables because it feels convenient at first.
Keeping shared file workflows forever without a modernization review point.

If Someone Asks You

How do you choose between Blob Storage and Azure Files?

A good answer is:

I choose Blob Storage when the workload stores objects such as images, PDFs, logs, backups, exports, or data lake files and can access them through object APIs or URLs. I choose Azure Files when the requirement is a managed file share with SMB or NFS-style behavior, mounted paths, or legacy file system expectations. Both choices still need lifecycle, redundancy, security, private access, monitoring, and cost design.

What You Should Remember

Choose Blob Storage for object access and Azure Files when file-share behavior is the requirement.

Questions to Check Understanding

Why is object storage different from a file share?
What kinds of data fit Blob Storage well?
When would Azure Files be a better fit than Blob Storage?