Skip to content

Comparison: Cloud Storage (S3 vs Blob Storage)

Category: Cloud Provider Crosswalk Last meaningful update consideration: 2026-07 Scope: AWS S3 and Azure Blob Storage. GCP Cloud Storage pending.

Object storage is one of the areas where the surface similarity ("both are just buckets of files") hides the most operationally significant differences — mainly because Azure's parent boundary (the storage account) doesn't have a clean S3 equivalent.

Service Crosswalk

Azure concept Closest AWS concept Where the analogy breaks
Storage account No direct S3 equivalent Globally named parent boundary for containers and several storage services; shares keys, networking, redundancy, and limits.
Blob container S3 bucket Container name is unique only inside the account; many policies live at account level rather than container level.
Block blob S3 object Similar general object type; upload block/commit mechanics and tier behavior differ.
Append blob No direct S3 object type Optimized append semantics are explicit.
Page blob EBS backing/object with random-page semantics Not a normal S3 object pattern.
Blob access tier S3 storage class Azure Hot/Cool/Cold/Archive mapping is approximate; transition, minimum-duration, and rehydration details differ.
Archive tier S3 Glacier-style classes Azure Archive is an offline blob state inside the account, not a separate product family.
LRS Single-region multi-copy storage No exact S3 durability placement control equivalent exposed this way.
ZRS S3 regional multi-AZ durability Broadly similar intent.
GRS/GZRS Cross-Region Replication managed at account level Azure secondary region is selected by platform pairing rules and account replication mode; replication is asynchronous.
RA-GRS/RA-GZRS secondary endpoint Read replica region endpoint Application must understand the secondary endpoint; it is not automatic global routing.
Azure RBAC data role S3 IAM/bucket policy permission Azure management-plane roles and storage data-plane roles are separate and often confused.
Shared Key Root-style HMAC account credential One account key can authorize broad access across storage services.
SAS S3 presigned URL / temporary delegated access SAS can cover account, service, container, object, permissions, IP, and time; generation/auditing differs.
User delegation SAS Presigned request using temporary IAM credentials Signed from an Entra delegation key rather than the permanent account key.
Private Endpoint/Private Link VPC interface endpoint Similar private-IP model; DNS-zone wiring is central to success.
Service Endpoint S3 gateway endpoint plus service firewall identity Still uses public service endpoints and is tied to subnet identity/routing, not a private NIC.
Hierarchical namespace / ADLS Gen2 S3 plus filesystem-oriented lake semantics Adds real directories and POSIX-like ACLs; irreversible once enabled and not simply a UI feature.
Blob versioning S3 Versioning Similar outcome; lifecycle, restore, delete markers, and billing semantics differ.
Immutable Blob Storage S3 Object Lock Similar WORM purpose; policy scopes and locking workflow differ.

Migration Notes

  • The storage account is the real gotcha. An S3 bucket is both the namespace and the primary policy boundary. In Azure, those are split: the storage account is the shared-everything boundary (keys, redundancy, networking), and containers are just namespaces inside it. Engineers who map "storage account" to "bucket" in their head will misdesign account boundaries.
  • Management-plane vs. data-plane confusion is the #1 support ticket. Contributor on the storage account (management plane) does not grant blob read/write access (data plane) — that needs an explicit Storage Blob Data Reader/Contributor role assignment. There's no AWS equivalent split this sharp; IAM policies on S3 usually cover both at once.
  • Redundancy is chosen once, for the whole account. You can't put cheap LRS scratch data and expensive GZRS compliance data in the same account at different redundancy levels the way you might tag different S3 storage classes per-object. Split accounts by durability requirement.
  • Enabling hierarchical namespace (HNS/ADLS Gen2) is irreversible. There's no S3 equivalent decision this consequential — it's closer to choosing a filesystem at format time than toggling a bucket setting.

The Interview Answer

"What's the Azure equivalent of an S3 bucket?" — A blob container, but be ready for the follow-up: containers live inside a storage account, which is the real unit of policy, redundancy, and network configuration — closer to "a whole S3-like service instance" than to a single bucket.

"How do you lock down Blob Storage the way you'd lock down an S3 bucket?" — Disable public network access and Shared Key auth, use managed identity plus a scoped Storage Blob Data Contributor/Reader role assignment instead of account keys, and add a private endpoint (with correctly wired Private DNS) if the workload needs to stay off the public internet entirely.

See Also