Azure Blob Tiers vs AWS S3 Storage Classes (and Google Nearline/Coldline)

Azure calls them access tiers. Amazon S3 and Google Cloud Storage call them storage classes. Other providers call them tiers, classes, plans, or just list a price. The labels sound interchangeable, but they don't map one to one.

The word "archive" causes the most mistakes. Azure Archive is offline and must be rehydrated before you can read it, and AWS S3 Glacier Flexible Retrieval and Deep Archive are also offline and need a restore first. Google Cloud Storage Archive, despite the name, still has millisecond access; it is colder mainly because of retrieval charges and a 365-day minimum storage duration^[1]. A restore plan that treats all three the same will be wrong.

Below, each tier or class is grouped by what it is for: hot data, monthly access, quarterly access, offline archive, automatic tiering, and provider-specific variants.

The table matches tiers by purpose and leaves prices out. Check the current pricing page before committing data, because minimum durations, request charges, retrieval fees, and regional prices can matter more than the storage price.

Storage tiers are usually a trade between four things:

• Storage price: colder classes cost less per GB-month.
• Access price: colder classes usually charge more to read, retrieve, or operate on data.
• Minimum duration: colder classes often bill as if the object stayed for 30, 90, 180, or 365 days.
• Access latency: online classes return data immediately; offline archive classes require a restore or rehydration step.

Azure states the ladder clearly: Hot has the highest storage cost and lowest access cost; Cool and Cold reduce storage cost but increase access and transaction costs; Archive is offline, lowest storage cost, and highest access cost^[2]. AWS frames S3 classes by use case, from Standard for frequent access, to Standard-IA for monthly access, to Glacier classes for archive and restore workflows^[3]. Google keeps every primary storage class online, even Archive, and makes the difference mostly price, availability, retrieval fees, and minimum storage duration^[4].

Azure Hot, AWS S3 Standard, Google Standard, OCI Standard, IBM Standard, Cloudflare R2 Standard, Backblaze B2, and Wasabi Hot are all meant for data that can be read at any time without a restore step. This is where you put application assets, active backups, staging data, media currently in production, and datasets you expect to query often.

What differs is the billing model. AWS, Azure, and Google separate storage, requests, retrieval, and transfer in more detail. Wasabi publishes no separate egress or API request charges but applies a 90-day minimum storage duration and a minimum storage amount^[15]. Backblaze B2 positions itself as always-hot storage with no minimum storage duration and free egress up to 3x average monthly stored data^[16].

Azure Cool, AWS S3 Standard-IA, Google Nearline, OCI Infrequent Access, IBM Vault, Cloudflare R2 Infrequent Access, and DigitalOcean Spaces Cold Storage all aim at data you read rarely and still want online when you do.

They share a lower storage price, a minimum of about 30 days, and some cost when you read the data. Azure calls it Cool, AWS calls it IA, Google calls it Nearline, IBM says Vault, and Oracle and Cloudflare say Infrequent Access. The classes are close, but the details differ from one provider to the next.

Azure Cold, AWS S3 Glacier Instant Retrieval, Google Coldline, and IBM Cold Vault are closer to each other in intent: data accessed at most a few times a year that still has to come back quickly. Azure Cold, AWS Glacier Instant Retrieval, and Google Coldline all have millisecond access with a 90-day minimum, and Google lists retrieval charges for Coldline^[17]. IBM Cold Vault is the IBM name for cold workloads where data is accessed every 90 days or less, with larger retrieval charges than Vault^[18].

Azure Archive, AWS S3 Glacier Flexible Retrieval, AWS S3 Glacier Deep Archive, and Oracle Archive are true archive workflows. The object exists, but you have to start a restore or rehydration before you can read it.

For these classes, restore time has to be part of the plan. Azure Archive can take up to 15 hours to rehydrate. AWS Glacier Flexible Retrieval can restore in minutes to hours depending on the retrieval tier. AWS Glacier Deep Archive is designed for hours-long restores, and AWS summarizes average retrieval as 9 to 48 hours. Oracle Archive restores objects to Standard for access.

Google Archive is not in this group. It is the coldest Google Cloud Storage class, but it stays online with millisecond access. What makes it archive-like is cost: a 365-day minimum duration plus higher data access and operation costs^[19].

Changing the class or tier of existing data is one place where Azure and S3 differ sharply.

Azure Blob has a Set Blob Tier operation. It sets the access tier on a blob, snapshot, or specific blob version by using the comp=tier request and an x-ms-access-tier value^[20]. Azure's versioning docs treat tiering as an operation you can apply to any version of a block blob, while version creation is described around write operations such as Put Blob, Put Block List, Copy Blob, and Set Blob Metadata^[21]. In practice, an Azure tier change does not copy the blob over itself.

Amazon S3 can also change an existing object's storage class without downloading it to your machine, but the mechanism depends on how you do it.

On S3, the safer method depends on what you want. If data should age into colder classes predictably, lifecycle rules are usually cleaner. If you need to change specific objects right now, manual copy-over-self works, but versioned buckets will keep the old version until lifecycle or explicit deletion removes it.

Both Azure Blob and Amazon S3 can automatically move data to colder storage by rule. They differ in how much each rule system asks you to think about.

Azure Blob lifecycle management is built around access-tier actions. A policy is a JSON document made of rules; each rule has conditions, actions, and filters. Conditions can use creation time, last modified time, and last accessed time if access tracking is enabled. Actions can move current versions, previous versions, or snapshots to cooler tiers, delete them, or move blobs back from Cool to Hot when they are accessed. Filters can include path prefixes and blob index tags^[28]. In the Azure portal, this is exposed under Data management => Lifecycle management, with a list view for common rules and a code view for JSON policies^[29].

Amazon S3 Lifecycle is broader. A bucket lifecycle configuration can have rules that transition objects to other storage classes, expire current versions, transition noncurrent versions, permanently delete noncurrent versions, remove expired delete markers, and abort incomplete multipart uploads. Rules can target all objects or filter by prefix, tags, and object size^[30]. You can create them in the S3 console under the bucket Management tab, or manage them with CLI, SDKs, or the REST API^[31].

Azure is usually easier when your rule is "move these blobs by age, prefix, tag, or access time to Hot/Cool/Cold/Archive." S3 is more flexible when you need full object lifecycle management across current versions, noncurrent versions, delete markers, multipart cleanup, object-size filters, and multiple storage-class transitions. The extra options also make S3 lifecycle rules easier to misconfigure.

Choose Hot or Standard when users, apps, or jobs read the data regularly. If your object is a website asset, current media project, active backup, training dataset, or API payload, keep it online and warm.

Choose Cool, Standard-IA, or Nearline when the data still matters but usually sits untouched for weeks. These suit backups, completed projects, and archives that are still likely to be restored within a month.

Choose Cold, Glacier Instant Retrieval, or Coldline when you expect rare access but cannot tolerate a restore delay. These classes are good for quarterly compliance checks, disaster recovery material, and media that might need quick retrieval but not frequent reads.

Choose Archive, Glacier Flexible Retrieval, Deep Archive, or OCI Archive only when a restore delay is acceptable. Don't use them as CDN origins, app storage, or active backup targets; they suit data you preserve more than you use.

Choose automatic tiering when you do not know the access pattern. If you do know it, for example half a bucket is active data and half is backup data nobody reads, separate prefixes or buckets plus lifecycle rules may be clearer and cheaper.

When you move data between clouds, check that the destination class behaves the way the source class did, whatever it is called.

• Moving Azure Cool to S3 Standard-IA usually preserves the monthly-access intent.
• Moving Azure Cold to S3 Glacier Instant Retrieval preserves fast retrieval better than moving it to Glacier Flexible Retrieval.
• Moving Azure Archive to Google Archive changes behavior: the data becomes online in Google, but with a 365-day minimum and retrieval/operation charges.
• Moving Google Archive to Azure Archive changes behavior the other way: the data is offline until rehydrated.
• Moving AWS Deep Archive to Azure Archive keeps the data offline, but restore times and minimum durations differ.

Blober transfers between S3, S3-compatible storage, Azure Blob, Google Drive, Dropbox, local storage, and other providers. It can write new Azure Blob uploads directly to Hot, Cool, Cold, or Archive in a workflow, and it can bulk-change existing Azure blobs between those tiers with Azure mutations. For S3-compatible destinations, the generic S3-Compatible provider includes a storage-class field, so you can use provider-documented class names where the destination supports x-amz-storage-class.

• Minimum duration. Cool/IA/Nearline usually means 30 days. Cold/Coldline/Glacier Instant often means 90 days. Deep/archive classes can mean 180 or 365 days.
• Online or offline. Azure Archive and S3 Glacier Flexible/Deep Archive require restore. Google Archive does not.
• Retrieval fees. Cold storage often charges when you read, copy, move, or rewrite data.
• Operation fees. Moving, rewriting, lifecycle transitions, and metadata-heavy workflows can cost more in colder classes.
• Minimum billable object size. S3 IA and Glacier Instant use 128 KB minimums; DigitalOcean Cold Storage also documents 128 KiB minimum billable object/read behavior.
• Auto-tiering eligibility. Small objects may not auto-tier. AWS Intelligent-Tiering and Google Autoclass both document 128 KB/KiB style thresholds for automatic transitions.
• Provider-specific semantics. Some providers set class at the bucket level, some per object, some through lifecycle only, and some avoid classes entirely.

Is Azure Cool the same as S3 Standard-IA? Close: both target long-lived, infrequently accessed data that still needs millisecond access and has a 30-day minimum. Pricing, operations, and redundancy details differ.

Is Azure Cold the same as Google Coldline? They are close in intent: rare-access online storage with a 90-day minimum and fast reads. Neither should be confused with Azure Archive or S3 Glacier Deep Archive, which need a restore before you can read the data.

Is Google Archive the same as Azure Archive? No. Google Archive is still online with millisecond access. Azure Archive is offline and must be rehydrated before reading.

Which S3 class maps to Azure Archive? S3 Glacier Flexible Retrieval and S3 Glacier Deep Archive are the closest behavioral matches, because they are archived and require a restore before normal access. S3 Glacier Instant Retrieval maps more closely to Azure Cold.

Does the cheapest storage class always save money? No. If you read the data more often than the class expects, retrieval, operation, early deletion, and restore costs can erase the storage savings.

• How to Bulk Change Azure Blob Storage Access Tiers
• How to Transfer Files from AWS S3 to Azure Blob Storage
• Cloud Storage Ingress vs Egress Fees
• S3-Compatible Storage Providers: The Complete List