AWS vs Google Cloud vs Azure storage: S3, Cloud Storage, and Blob by workload

October 26, 2026 · 10 min read

Start with object, shared-file, and block access, then compare S3, Cloud Storage, and Azure Blob Storage for consistency, redundancy, archive access, recovery, and encryption keys. Include retrieval and transfer when evaluating storage cost.

Choose between objects, files, and blocks first

Product images, a batch application using shared files, and a database on a VM need different operations even at equal capacity. Start with objects for storing and retrieving by key, shared files for clients accessing common paths, and block storage for disks managed by an OS.

Access model	AWS examples	Google Cloud examples	Azure examples
Object API	Amazon S3	Cloud Storage	Azure Blob Storage
Shared files	Amazon EFS (NFS), applicable FSx offerings	Filestore (NFS)	Azure Files (supported SMB or NFS configurations)
Durable blocks	Amazon EBS	Hyperdisk / Persistent Disk	Azure Managed Disks

Mounting objects does not establish equivalent locking, partial updates, renames, or concurrent writes to an existing filesystem. For an unchanged application requiring NFS, test the actual operations on shared-file candidates. Attaching block storage to multiple VMs also requires a supported configuration and filesystem coordination.

Fix the configuration before comparing S3, Cloud Storage, and Blob Storage

Candidate	Settings to choose first	Effect on the decision
Amazon S3	Bucket type, region, storage class, required replication	Some classes target a single zone; the S3 name alone does not define resilience
Cloud Storage	Bucket location, storage class, retention and recovery settings	Check location separately from class; multi-region alone does not guarantee an RPO
Azure Blob Storage	Storage account type, redundancy, access tier	LRS, ZRS, GRS, GZRS, and related settings change failure coverage and secondary access

Consider product-image delivery and retention of older originals. Fix object sizes, retention, read counts, cross-region communication, and the recovery window after deletion. Equal capacity is not a fair comparison if access and failure requirements differ.

Separate write consistency from caches and replica visibility

S3 provides strong read-after-write consistency for object PUT and DELETE operations; Cloud Storage also provides strong consistency for object reads after writes and object listing. A browser or CDN can still serve a cached old image after the origin changes. Design origin consistency separately from delivery-cache lifetime.

Azure GRS and GZRS replicate asynchronously to a secondary region. Check settings such as RA-GRS or RA-GZRS for secondary reads; a successful primary write does not establish an up-to-date secondary read. Keep normal primary-endpoint reads separate from the behavior of an asynchronous copy.

Consider storing images under versioned content keys and recording the key in the database. If relying on overwrites and cache invalidation, define how long stale display is acceptable.
Distinguish uploaded, inspected, and publishable states. Database publication state and object storage can fail independently, so reconcile intermediate states.
Test reads from the origin, through the CDN, and from replica endpoints separately, checking the requested version.

Infrequent access: archive does not imply the same wait

Example	Retrieval behavior	Cost and operating considerations
S3 Glacier Instant Retrieval	Archive class intended for immediate access	Infrequent-access conditions, minimum duration, retrieval and other charges
S3 Glacier Flexible Retrieval / Deep Archive	Classes requiring a restore request and wait	Restore option, acceptable delay, temporary copies, retrieval cost
Cloud Storage Archive	Access without an offline restore wait	Minimum storage duration, data retrieval and other charges
Azure Blob Archive	Requires rehydration into an online tier	Time to availability, priority, minimum duration, charges

An original that must download immediately after a click has different options from one an investigator can receive the next day. Age alone does not determine the tier. Include time from request to availability in the recovery target, and verify that the user workflow still works after transitioning data.

Treat redundancy, version protection, and encryption keys as recovery requirements

Disk failure, zone outage, regional disaster, and accidental deletion are different failures. Azure LRS copies data inside one data center; ZRS copies across zones in the primary region. GRS and GZRS replicate asynchronously to a secondary region, so regional failover requires checks for possible data loss and application recovery. This follows the same distinction as database HA versus DR.

Replicating the latest state alone may not recover an authorized accidental deletion or overwrite. Combine versioning, deletion protection, retention rules, and independent copies as needed. Verify the database references to restored object versions as well as the objects themselves.

With customer-managed encryption keys, recovery needs both the data and access to the key. For example, rotating a Cloud Storage CMEK to a new version leaves existing objects dependent on older versions. Identify dependencies and complete required rewrites and read checks before retiring an old version. Do not apply that product-specific procedure unchanged to another provider; check the selected service's behavior.

Recovery test scope: validate versions, references, keys, and delivery paths as well as data copies

Define failure scope, RTO, and RPO → Retrieve the required versions and copies → Verify decryption and database references → Validate delivery and authorization before resuming work

Count retrieval, transfer, operations, and old versions as well as storage

Assume one million originals of 10 MB each, with MB equal to one million bytes. Current versions total 10,000 GB. Reading 10% once per month retrieves 1,000 GB through 100,000 reads. If two older versions per object are retained on average, a simplified total is three times current storage, or 30,000 GB. Actual storage depends on version sizes and retention periods.

Estimate categories, to be mapped to each provider's billing units; not a calculated price

total = storage(current_versions + retained_versions + replicas)
      + requests(reads + writes + list + transitions)
      + retrieval + restore + transfer
      + early_deletion_or_minimum_duration_charges
      + key_management + operations

Here, replicas means separately billed copies in the selected architecture. Do not multiply storage by the number of internal redundant copies already included in the service's unit price. The 1,000 GB read is not necessarily internet egress either; separate application-local use and CDN caching by path. Include early deletion, retained audit versions, and bulk retrieval when estimating a representative month and a recovery event.

Test three cases before adoption

Product images: interrupt uploads, validate pre-publication inspection, check display after updates, and test access after signed links expire.
Original retention: retrieve real test objects from the infrequent-access tier and check delay, billing categories, and user guidance.
Recovery: distinguish deleted-version recovery, regional unavailability, and lost key access; record recovery conditions and ownership.