An Azure storage account can provide Blob Storage, Azure Files, Queue Storage, and Table Storage under shared regional, redundancy, network, and security settings.
Blob Storage is designed for objects such as application assets, backups, logs, and datasets. Azure Files exposes managed file shares, queues support simple asynchronous messages, and tables provide key-value entities.
Storage design must choose redundancy, access tier, identity model, public access, lifecycle, recovery features, and network path before applications depend on it.
Select the storage service from the access pattern, then choose locally redundant, zone-redundant, geo-redundant, or geo-zone-redundant storage according to durability, availability, recovery, and cost needs.
Prefer Microsoft Entra authorization with data roles. Use a user-delegation SAS or narrowly scoped SAS when temporary delegated access is required, and protect account keys as high-impact credentials.
Restrict public network access with firewall rules or private endpoints where required. Enable soft delete, versioning, immutability, or point-in-time recovery according to the data threat and service support.
Lifecycle rules can tier or delete blobs based on age and state. Review transaction volume, retrieval charges, replication, snapshots, versions, and egress rather than considering capacity alone.
A storage account is the Azure Resource Manager boundary that holds supported blob containers, file shares, queues, and tables under common Region, redundancy, naming, network, encryption, and billing settings. Separate accounts when workloads need different owners, network exposure, redundancy, performance, lifecycle, or blast radius rather than putting every data type into one account.
Blob Storage stores objects addressed by container and blob name. Azure Files exposes managed SMB or NFS shares under supported configurations. Queue Storage carries simple messages, and Table Storage stores schemaless key-value entities by partition and row keys. They share an account but not an access model or application semantic.
Choose the account kind, performance tier, hierarchical namespace, and feature set only after checking service compatibility. Some choices cannot be changed cheaply later. Record which application owns each container, share, queue, and table and how it is removed at end of life.
LRS keeps replicas in one primary-region datacenter scope, while ZRS synchronously spreads supported storage across Availability Zones. GRS and GZRS add asynchronous replication to a paired secondary Region; read-access variants allow reads from the secondary under their service contract. Select from required availability, durability, recovery, latency, and cost.
Geo-replication is asynchronous, so regional failover can lose the most recent writes within the replication lag. Customer-managed and Microsoft-managed failover paths have different prerequisites and consequences. Define who declares failover, how applications find the new endpoint, what data loss is accepted, and whether failback is supported and tested.
Redundancy replicates current state and can copy deletion or corruption. Soft delete, versioning, snapshots, backup, immutability, and independent copies protect different risks. Use an explicit recovery matrix rather than assuming more replicas equal a backup.
Prefer Microsoft Entra authorization with service-specific data roles and managed identities. A Contributor who can manage the storage account does not automatically have blob, queue, table, or file data permission. Assign the narrow data role at account, container, or supported child scope and test the actual read or write.
A shared access signature delegates selected service, resource, permission, protocol, IP, start, and expiry conditions. Prefer a user-delegation SAS for Blob Storage when it fits because its signing authority derives from Entra credentials. Keep lifetime and scope small, transmit it as a secret, and remember that a leaked SAS remains usable until expiry or its signing authority is revoked.
Account keys grant broad shared-key authority and are difficult to attribute. Disable shared-key authorization where supported and compatible, store unavoidable keys in a vault, rotate them through a two-key process, and remove them from code, URLs, logs, and automation output. Regeneration without dependency inventory can cause an outage.
Storage network controls can allow selected public networks, trusted Azure service paths, service endpoints, or private endpoints according to service support. A private endpoint creates a private IP for a storage subresource in a VNet; Blob, File, Queue, Table, Data Lake, and secondary endpoints may require separate subresource and DNS planning.
Private DNS must resolve the normal storage hostname to the private endpoint for clients that should use it. Connected on-premises and peered networks need resolver forwarding or linked zones. A successful public test from an administrators laptop does not prove the private application path works.
Network restriction does not replace data authorization, and a private endpoint does not stop every public endpoint unless public network access and firewall policy are configured accordingly. Test approved clients, denied public clients, name resolution, failover endpoints, and diagnostic access before production.
Blob tiers trade access cost, storage cost, and retrieval behavior. Use lifecycle management rules to tier or delete base blobs, snapshots, and versions according to prefixes, tags, age, and state supported by the account. Model transaction, minimum-duration, rehydration, and data retrieval cost before moving short-lived or frequently accessed data colder.
Blob versioning and soft delete can recover overwrites and deletion but increase retained capacity. Point-in-time restore and change feed have account and feature requirements. Immutability policies and legal holds prevent modification for retention scenarios and require controlled administration because an incorrect locked policy can be operationally difficult or impossible to reverse.
Use block-blob upload APIs and SDK retry behavior for large data, validate expected size and checksum, and clean abandoned temporary work. Treat filenames, content type, metadata, and payload as untrusted input. Event Grid consumers must handle duplicate and out-of-order notifications safely.
Azure Files requires protocol, identity, directory integration, share quota, performance, snapshot, backup, and network decisions. Test client reconnect and file-lock behavior across the intended platform. A file share is not a drop-in replacement for every local filesystem workload.
Queue messages can become visible again when processing exceeds the visibility interval or fails, so consumers need idempotency, poison-message handling, bounded retries, and age monitoring. Table Storage access begins with partition and row keys; a poor partition key can concentrate traffic and make broad scans the accidental query model.
Enable the metrics, resource logs, audit destinations, inventory, and alerts required for availability, authorization failure, capacity, latency, throttling, and suspicious access. Practice restoring a blob version, file share data, and application state represented in queue or table workflows. Recovery succeeds only after the consuming application validates it.
Track retirement and migration guidance for account types, TLS versions, shared-key access, SDKs, diagnostic categories, and individual storage features. Test migrations against authorization, private DNS, redundancy, lifecycle, and recovery before the service deadline rather than changing only the client endpoint.
Use identity-based access instead of account keys so the storage lesson stays aligned with least-privilege practice.
az storage container create \
--account-name tldemostore001 \
--name invoices \
--auth-mode login
az storage blob upload \
--account-name tldemostore001 \
--container-name invoices \
--name sample-invoice.json \
--file ./sample-invoice.json \
--auth-mode loginAn operator deletes a customer export that must be recovered.
Constraints: Public access and shared keys are disabled; soft delete and versioning are enabled.
Decision: Use an Entra-authorized operator role to locate the deleted version and restore it as the current object.
Verification: The checksum and metadata match, the operation appears in diagnostic logs, and anonymous access remains denied.
Failure test: Try the same operation with a reader-only identity and confirm it cannot restore data.Expected evidence: The checksum and metadata match, the operation appears in diagnostic logs, and anonymous access remains denied.Explore 500+ free tutorials across 20+ languages and frameworks.