azure blob storage

5 posts with the tag "azure blob storage"

AzCopy S3 to Azure: How It Works and the Limits to Check

Jul 31, 2026

AzCopy does not download S3 data through your computer

AzCopy's documented AWS S3 transfer uses Azure's Put Block From URL operation. AWS S3 and Azure Storage exchange the object data without using your computer's network bandwidth.^[1]

That makes AzCopy a strong option for teams comfortable with a command line. It can copy one object, a directory, a bucket, or broader groups of AWS buckets.

The migration still needs planning. Server-to-server describes the data route. It does not solve naming, metadata, authentication, or destination-tier decisions.

Authentication is different on each side

The Azure side can use Microsoft Entra ID or a SAS token. The documented AWS flow uses an AWS access key and secret access key supplied through environment variables.

Protect shell history, scripts, logs, and CI output from credentials. Use the narrowest permissions that cover the source and destination.

Bucket names may change

AWS S3 bucket names and Azure container names allow different characters. AzCopy rewrites names that Azure cannot accept.

Periods can become hyphens. Consecutive hyphens can also be rewritten. Two distinct S3 bucket names may therefore map to the same Azure container name, forcing another rename.

Create a bucket-to-container map before a large migration. Do not discover the naming plan from the destination after the copy is complete.

Invalid metadata needs an explicit choice

S3 and Azure also allow different metadata-key characters. AzCopy provides --s2s-handle-invalid-metadata with three behaviors:

• ExcludeIfInvalid omits incompatible metadata and logs a warning.
• FailIfInvalid fails that object.
• RenameIfInvalid changes the metadata key.

The default exclusion behavior can produce a successful object copy with missing metadata. If metadata affects retention, compliance, processing, or ownership, review this flag before running the job.

AWS S3 is not every S3-compatible service

Microsoft's documented S3 flow uses AWS S3 URL formats. Do not assume the same command accepts every Wasabi, Cloudflare R2, MinIO, DigitalOcean Spaces, or private S3-compatible endpoint.

Test the exact provider and endpoint. A tool that supports generic S3 endpoint URLs may be a better fit for non-AWS sources.

When a desktop workflow fits better

Use AzCopy when server-to-server speed, scripting, automation, and repeatable command lines suit the team.

Use a desktop tool when the operator needs visual file selection, browsing, previews, and fewer command flags. Blober connects AWS S3, Azure Blob Storage, and generic S3-compatible endpoints in one local interface. Its data path is different from AzCopy's server-side AWS path, so choose based on network, security, and operational needs rather than calling either design universally better.

AzCopy also supports job resume and restart. Its source code and current release details are published on GitHub.^[2]

Related Guides

• How to Transfer Files from AWS S3 to Azure Blob Storage
• Azure Blob Tiers vs S3 Storage Classes
• What S3-Compatible Really Means
• Azure Blob Storage Setup and Transfers

Get Blober

AzCopy is a good command-line tool for AWS S3. When you want visual browsing, previews, destination tier selection, and generic S3-compatible endpoints, Blober covers the same move from a desktop app.

Download Blober at blober.io

Tags:

• blober
• azcopy
• aws s3
• azure blob storage
• cloud migration

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

Jun 29, 2026

Azure calls them access tiers. Amazon S3 and Google Cloud Storage call them storage classes. Other providers call them tiers, classes, plans, or just pricing. The labels sound interchangeable, but they are not one-to-one.

The biggest trap is the word archive. Azure Archive is offline and must be rehydrated before you can read it. AWS S3 Glacier Flexible Retrieval and Deep Archive are also offline restore workflows. 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]. If you treat all three as the same thing, your restore plan will be wrong.

This guide maps the intent behind each tier or class: hot data, monthly access, quarterly access, offline archive, automatic tiering, and provider-specific variants.

Tiers and Classes at a Glance

Intent	Azure Blob	AWS S3	Google Cloud Storage	Other provider names
Active, frequently read data	Hot	S3 Standard	Standard	OCI Standard, IBM Standard, Cloudflare R2 Standard, DigitalOcean Spaces Standard, Wasabi Hot, Backblaze B2
Unknown or changing access	Smart tier, where available	S3 Intelligent-Tiering	Autoclass	IBM Smart Tier, OCI Auto-Tiering
Infrequent but online access	Cool	S3 Standard-IA, S3 One Zone-IA	Nearline	OCI Infrequent Access, IBM Vault, Cloudflare R2 Infrequent Access, DigitalOcean Spaces Cold Storage
Rare but still online access	Cold	S3 Glacier Instant Retrieval	Coldline	IBM Cold Vault
Archive with restore delay	Archive	S3 Glacier Flexible Retrieval, S3 Glacier Deep Archive	Not the same: Google Archive is still online	OCI Archive
High-performance special class	No direct Azure access-tier equivalent	S3 Express One Zone	Rapid storage	Provider-specific performance products

That table is a mental map, not a pricing calculator. Always 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.

What the Names Mean Underneath

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].

Minimum Duration and Access Behavior

Provider	Class or tier	Minimum duration	Online read?	Restore or rehydrate behavior
Azure Blob	Hot	None	Yes, milliseconds	None
Azure Blob	Cool	30 days	Yes, milliseconds	None
Azure Blob	Cold	90 days	Yes, milliseconds	None
Azure Blob	Archive	180 days	No	Rehydrate to Hot, Cool, or Cold; can take up to 15 hours[5]
AWS S3	Standard	None	Yes, milliseconds	None
AWS S3	Standard-IA	30 days	Yes, milliseconds	Retrieval fees apply[6]
AWS S3	One Zone-IA	30 days	Yes, milliseconds	Retrieval fees apply; stored in one Availability Zone[7]
AWS S3	Glacier Instant Retrieval	90 days	Yes, milliseconds	Retrieval fees apply[8]
AWS S3	Glacier Flexible Retrieval	90 days	No	Restore first; expedited, standard, or bulk retrieval ranges from minutes to 12 hours[9]
AWS S3	Glacier Deep Archive	180 days	No	Restore first; AWS summarizes average retrieval as 9 to 48 hours[10]
Google Cloud Storage	Standard	None	Yes, milliseconds	None
Google Cloud Storage	Nearline	30 days	Yes, milliseconds	Retrieval fees apply
Google Cloud Storage	Coldline	90 days	Yes, milliseconds	Retrieval fees apply
Google Cloud Storage	Archive	365 days	Yes, milliseconds	No offline restore; higher access/operation costs and 365-day minimum[11]
Oracle Object Storage	Standard	None	Yes	None
Oracle Object Storage	Infrequent Access	31 days	Yes	Retrieval fees apply
Oracle Object Storage	Archive	90 days	No	Restore to Standard for access; Oracle says first byte is available at most an hour after restore request[12]
Cloudflare R2	Standard	None	Yes	No egress bandwidth charge, but operations still bill
Cloudflare R2	Infrequent Access	30 days	Yes	Data retrieval processing fee applies, but egress bandwidth remains free[13]
DigitalOcean Spaces	Standard	None	Yes	Included storage and outbound transfer bundle
DigitalOcean Spaces	Cold Storage	30 days	Yes	Retrieval fee, early deletion/update cost, and 128 KiB minimum billing units[14]

Where They Overlap

Hot / Standard / Active Storage

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.

The difference is not the meaning. It 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].

Monthly Access / Infrequent Access

Azure Cool, AWS S3 Standard-IA, Google Nearline, OCI Infrequent Access, IBM Vault, Cloudflare R2 Infrequent Access, and DigitalOcean Spaces Cold Storage all point at the same general idea: data you do not read often, but still want online when you do.

The common shape is a lower storage price, a 30-ish day minimum, and some cost when you read the data. The names differ: Azure calls it Cool, AWS calls it IA, Google calls it Nearline, Oracle says Infrequent Access, IBM says Vault, and Cloudflare says Infrequent Access. Treat them as cousins, not exact twins.

Quarterly or Rare Online Access

Azure Cold, AWS S3 Glacier Instant Retrieval, Google Coldline, and IBM Cold Vault are closer to each other in intention: data accessed at most a few times a year, but still available quickly. Azure Cold has millisecond access with a 90-day minimum. AWS Glacier Instant Retrieval has millisecond access with a 90-day minimum. Google Coldline has millisecond access with a 90-day minimum and retrieval charges^[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].

Offline Archive

Azure Archive, AWS S3 Glacier Flexible Retrieval, AWS S3 Glacier Deep Archive, and Oracle Archive are true archive workflows. The object exists, but you cannot just read it like a hot object. You initiate a restore or rehydration operation first.

This is where restore time becomes a product requirement. Azure Archive can take up to 15 hours to rehydrate. AWS Glacier Flexible Retrieval can restore in minutes to hours depending on retrieval tier. AWS Glacier Deep Archive is designed for hours-long restores, with AWS summarizing average retrieval as 9 to 48 hours. Oracle Archive restores objects to Standard for access.

Google Archive does not belong in this exact group. It is the coldest Google Cloud Storage class, but it remains online with millisecond access. Its archive-like behavior is economic: a 365-day minimum duration plus higher data access and operation costs^[19].

Where They Differ

Difference	Why it matters
Archive can mean offline or online	Azure Archive and AWS Glacier Flexible/Deep Archive require restore. Google Archive does not.
Minimum duration is not always the same	Azure Archive is 180 days; AWS Deep Archive is 180 days; Google Archive is 365 days; Oracle Archive is 90 days.
Retrieval fees are separate from egress	A provider can have free egress but still charge retrieval processing or operations, such as R2 Infrequent Access.
Automatic tiering is implemented differently	S3 Intelligent-Tiering is a storage class. Google Autoclass is a bucket feature. Azure Smart tier is an access-tier automation feature where available. OCI Auto-Tiering moves between Standard and Infrequent Access.
Some providers do not expose a full class ladder	Backblaze B2 and Wasabi focus on simple hot storage economics rather than many storage classes. Lifecycle rules may delete or hide old versions, but that is not the same as a cold storage class.
One-zone classes are about resilience, not just price	S3 One Zone-IA and S3 Express One Zone trade multi-AZ resilience for cost, latency, or locality. Do not map them directly to Azure Cool or Google Nearline without considering failure-domain risk.

S3 vs Azure Tier Changes

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 practical terms, a tier change is not a copy-over-self operation.

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.

Change method	Azure Blob	AWS S3
Manual immediate change	Set Blob Tier changes the access tier on the blob or version.	Console, CLI, SDK, and API changes are copy-based. AWS documents changing an existing object's class with aws s3 cp object object --storage-class ..., and the CopyObject API accepts x-amz-storage-class[22].
Lifecycle change	Azure lifecycle management can move blobs between tiers by policy.	S3 Lifecycle Transition changes the current object version to the specified storage class; NoncurrentVersionTransition changes noncurrent versions[23].
Versioning impact	A tier change does not create a copied object version the way a write/copy does. Explicitly tiered versions can change how Azure bills shared blocks and full content length[24].	Manual copy-over-self creates a new copied object version when destination bucket versioning is enabled; AWS says CopyObject returns the version ID of the newly created copy[25]. Lifecycle transitions do not create a new current version; they transition the applicable version.
Cost shape	Tier-down is billed as a write operation; tier-up is billed as a read operation for Set Blob Tier[26].	Copy requests are charged based on destination storage class and Region; the request can also trigger source retrieval charges, and cross-Region copies can incur data transfer charges[27]. Lifecycle transitions have transition request costs and minimum-duration rules.

The safe S3 cleanup pattern depends on intent. If you want data to 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.

Lifecycle Policies: Azure vs S3 Ease

Both Azure Blob and Amazon S3 can automatically move data to colder storage by rule. The difference is how much the 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].

Task	Azure Blob lifecycle	S3 Lifecycle	Easier in practice
Move logs or backups to a colder tier after N days	Add a rule for base blobs, set days since modified/created/accessed, choose Cool, Cold, or Archive.	Add a lifecycle rule, filter by prefix/tag/size, choose a storage-class transition and days after creation.	Tie for simple prefix-by-age rules. Azure reads closer to the access-tier model.
Use last-access behavior	Supported if last access tracking is enabled; lifecycle can also move blobs back from Cool to Hot when accessed[32].	S3 Lifecycle is mostly age/filter based. Use S3 Intelligent-Tiering when access pattern is unknown or changing.	Azure for explicit last-access rules; S3 for fully managed Intelligent-Tiering.
Manage old versions	Supports current versions, previous versions, and snapshots as lifecycle targets.	Very explicit current/noncurrent version actions, including transition and expiration of noncurrent versions[33].	S3 gives more version-specific knobs; Azure is simpler if you only need tier/delete policies.
Avoid tiny-object surprises	Fewer class-transition-specific size traps in the lifecycle model.	Objects smaller than 128 KB do not transition by default unless you override with size filters or headers; transition request costs can outweigh storage savings[34].	Azure is easier; S3 is more configurable but easier to misprice.
Rehydrate archived data automatically	Lifecycle policies cannot rehydrate Archive blobs to an online tier[35].	Lifecycle cannot transition Deep Archive back to warm classes; restore/copy workflows are needed for archived objects[36].	Neither. Archive restore is a separate workflow.
Know when it will happen	Policy changes can take up to 24 hours to go into effect and for first execution to start[37].	Lifecycle configuration propagation takes minutes, but actions are asynchronous and can complete later; billing usually changes when the rule is satisfied[38].	Neither is immediate. Use direct tier change/copy when you need right-now changes.

The short version: 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. That flexibility is useful, but it also makes S3 lifecycle rules easier to misconfigure.

Automatic Tiering: Similar Goal, Different Mechanic

Provider	Feature	What it does	Watch out for
Azure Blob	Smart tier	Automatically moves data between Hot, Cool, and Cold based on usage patterns, where available[39].	It does not include Archive in the same online ladder. Confirm account and API support before designing around it.
AWS S3	Intelligent-Tiering	Keeps the storage class as Intelligent-Tiering while moving objects through Frequent, Infrequent, Archive Instant, and optional Archive/Deep Archive access tiers[40].	Monitoring/automation fees apply; objects under 128 KB are not auto-tiered. Optional archive tiers require restore.
Google Cloud Storage	Autoclass	Moves objects to colder storage classes when not accessed, and back to Standard when read[41].	Management and enablement charges can apply; manual storage class changes are ignored in Autoclass buckets.
Oracle Object Storage	Auto-Tiering	Moves objects larger than 1 MiB from Standard to Infrequent Access and back to Standard based on access patterns[42].	It is a Standard to Infrequent Access optimizer, not a deep archive policy.
IBM Cloud Object Storage	Smart Tier	Bills dynamic workloads by automatically classifying data into hot, cool, and cold tiers based on monthly usage patterns[43].	It is bucket-class pricing, not the same mechanics as S3 Intelligent-Tiering or Google Autoclass.

Azure-to-AWS-to-Google Mapping

If you use Azure...	Closest AWS S3 class	Closest Google class	Practical meaning
Hot	S3 Standard	Standard	Active data; lowest read friction; highest storage cost among general classes.
Cool	S3 Standard-IA	Nearline	Infrequent online data, roughly monthly access, 30-day minimum.
Cold	S3 Glacier Instant Retrieval	Coldline	Rare online data, roughly quarterly access, 90-day minimum.
Archive	S3 Glacier Flexible Retrieval or Deep Archive	No exact equivalent	Offline restore workflow. Google Archive is colder economically but still online.
Smart tier	S3 Intelligent-Tiering	Autoclass	Let the provider move data across warmer and colder classes based on access.

Same Intention, Different Name

If your thought is...	Choose this kind of class	Examples
"This data is active and users or apps read it constantly."	Hot/standard	Azure Hot, S3 Standard, GCS Standard, R2 Standard, IBM Standard, OCI Standard.
"I read this monthly, but it still needs to come back instantly."	Online infrequent access	Azure Cool, S3 Standard-IA, GCS Nearline, R2 Infrequent Access, OCI Infrequent Access, IBM Vault.
"I read this quarterly or rarely, but a restore delay would be painful."	Online cold	Azure Cold, S3 Glacier Instant Retrieval, GCS Coldline, IBM Cold Vault.
"This is compliance/archive data and waiting hours is acceptable."	Offline archive	Azure Archive, S3 Glacier Flexible Retrieval, S3 Glacier Deep Archive, OCI Archive.
"I do not know the access pattern yet."	Auto tiering	Azure Smart tier, S3 Intelligent-Tiering, Google Autoclass, IBM Smart Tier, OCI Auto-Tiering.
"I want simple predictable billing more than fine-grained classes."	Flat hot storage	Backblaze B2, Wasabi, many S3-compatible specialists.

Which One Should You Choose?

Choose Hot / 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 / Nearline when the data is still important but usually sits untouched for weeks. This is a good fit for backups, completed projects, and archives that are still likely to be restored within a month.

Choose Cold / Glacier Instant Retrieval / 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 / Deep Archive / OCI Archive only when restore delay is acceptable. These are not CDN origins, app storage, or active backup targets. They are for data you preserve more than you use.

Choose automatic tiering when you genuinely do not know the access pattern. Do not use it as a substitute for understanding a known workflow. If half a bucket is active data and half is never-read backup data, separate prefixes or buckets plus lifecycle rules may be clearer and cheaper.

Migration Notes

When you move data between clouds, do not just map names. Map behavior.

• 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 direction: the data becomes offline until rehydrated.
• Moving AWS Deep Archive to Azure Archive keeps the offline-archive idea, but restore times and minimum durations differ.

Blober 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 connector includes a storage-class field, so you can use provider-documented class names where the destination supports x-amz-storage-class.

The Traps to Check Before You Pick a Tier

• 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 vs 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.

Frequently Asked Questions

Is Azure Cool the same as S3 Standard-IA? Conceptually, yes: 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 intention: rare-access online storage with a 90-day minimum and fast reads. Do not confuse either with Azure Archive or S3 Glacier Deep Archive, which are restore-first archive workflows.

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 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 expected, retrieval, operation, early deletion, and restore costs can erase the storage savings. The cheapest class is usually only cheapest when the access pattern matches the class.

Related Guides

• 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

Get Blober

Pick the right storage class before you move the data. Blober transfers between S3, S3-compatible storage, Azure Blob, Google Drive, Dropbox, local storage, and more, and can write Azure Blob data straight to the tier you choose.

Download Blober at blober.io

Tags:

• blober
• azure
• azure blob storage
• aws s3
• google cloud storage
• storage tiers
• storage classes
• cost optimization

How to Bulk Change Azure Blob Storage Access Tiers (Hot, Cool, Cold, Archive)

May 11, 2026

Azure Storage Tiers and the Problem with Managing Them

Azure Blob Storage offers four generally available access tiers for block blob data: Hot, Cool, Cold, and Archive. Each tier has different storage and retrieval costs. The idea is straightforward: keep frequently accessed data on Hot, move older data to Cool or Cold, and archive rarely needed files to Archive for the lowest per-GB rate^[1].

In practice, managing tiers is not that simple. The Azure portal is fine for occasional manual changes, but repeatable bulk work usually means PowerShell, Azure CLI, direct API calls, or lifecycle management policies. If you want to move 500 blobs from Hot to Archive right now, you are either doing manual portal work or writing and testing a script.

Lifecycle policies help with automated transitions, but they operate on rules and schedules. They are not designed for the case where you look at a set of files and decide, right now, that these specific blobs need to be on a different tier.

Hot, Cool, Cold, and Archive: The Tiers at a Glance

Azure Blob Storage has four access tiers. The colder the tier, the less you pay to store data and the more you pay, in both money and time, to read it back. Here is the practical comparison.

Tier	Storage cost	Read cost	Minimum retention	Time to first byte	Best for
Hot	Highest	Lowest	None	Milliseconds	Data in active use
Cool	Lower	Higher	30 days	Milliseconds	Backups, data read about monthly
Cold	Lower still	Higher still	90 days	Milliseconds	Rarely touched data you still want instantly
Archive	Lowest	Highest	180 days	Hours (rehydration)	Long-term archive and compliance copies

Two things catch people out:

• Archive is offline. You cannot read an archived blob directly. You first rehydrate it to Hot, Cool, or Cold, which can take up to 15 hours. Plan for that latency before you archive anything you might need quickly.
• Early deletion penalty. If you delete, overwrite, or move a blob out of Cool (30 days), Cold (90 days), or Archive (180 days) before its minimum retention elapses, Azure charges a prorated early deletion fee. Moving a blob to Archive and pulling it back two weeks later is not free.

Moving an online blob to another online tier, or down to Archive, is an immediate tier operation. Only the reverse, rehydrating from Archive to an online tier, is a pending restore workflow that can take hours^[2].

What Blober Does Differently

Blober is a desktop app that connects to Azure Blob Storage as one of its supported providers. Beyond the usual read, write, list, and delete operations, Blober supports something called mutations for Azure Blob. Mutations let you change properties of existing blobs without transferring any data.

Today, Blober supports two types of Azure mutations:

Storage Tier Changes

Select any number of blobs in the Blober file browser, choose a target tier (Hot, Cool, Cold, or Archive), and run the mutation. Every selected blob gets moved to the new tier. No re-upload, no script, no waiting for a lifecycle policy to kick in.

This is useful when you realize a project is finished and its assets should move to Archive, or when you need to bring archived files back to Cool for a review cycle.

Container Access Level Changes

Azure containers can be set to Private, Blob-level public access, or Container-level public access. Changing access levels usually means navigating to each container in the portal and updating the setting. With Blober, you select the containers you want to modify, pick the access level, and apply.

A Real Example: Post-Production Archival

Say you run a media production company. You have a container called project-alpine-2025 with 800 GB of raw footage sitting on Hot storage. The project wrapped three months ago and no one is accessing those files. You are paying Hot rates for storage that should be on Archive.

With Azure CLI, you would write something like:

az storage blob list --container-name project-alpine-2025 --output tsv | \
while read line; do
  az storage blob set-tier --container-name project-alpine-2025 --name "$line" --tier Archive
done

This works, but you need to set up authentication, handle pagination for large containers, deal with blobs that are already archived, and test the script before running it on production data.

With Blober, you open your Azure Blob connection, navigate to the container, select all files, choose "Archive" as the target tier, and click run. Done.

More Mutations Coming

Tier changes and access levels are the first mutations Blober supports for Azure. The architecture is designed to extend this to other providers and other types of modifications. Future mutations could include things like metadata updates, blob tagging, or replication settings. The goal is to give you the same visual, point-and-click control over blob properties that you already have for transfers.

Setting Up Azure Blob Storage in Blober

Connecting Azure to Blober takes about a minute:

1. Open Blober and add a new provider
2. Select Azure Blob Storage
3. Paste your connection string (the same one you would use with Azure Storage Explorer or the SDK)
4. Blober verifies the connection and lists your containers

From there, you can browse blobs, transfer files to or from Azure, and run mutations on existing blobs.

Configuration Options

When using Azure as a destination, Blober lets you configure:

• Storage Tier: Choose which tier new uploads land on (Hot, Cool, Cold, or Archive)
• Write Behavior: Overwrite existing blobs, skip if a blob already exists, or skip only if the blob is archived

These options are set per-workflow, so you can have one workflow that uploads to Hot and another that uploads directly to Archive.

Who Needs This

• DevOps teams managing storage costs across multiple containers and projects
• Media companies archiving completed project assets
• Backup administrators moving cold data to cheaper tiers
• Anyone who has outgrown Azure Portal's one-blob-at-a-time tier management

Common Questions About Azure Blob Tiers

Does changing a blob's access tier create a new version? No. Changing the tier with the Set Blob Tier operation does not create a new blob version. When versioning is enabled, the operations that create a version are writes: Put Blob, Put Block List, Copy Blob, and Set Blob Metadata. Set Blob Tier is not one of them; Azure documents tiering as an access-tier operation that can be applied to a blob version^[3][4]. If you already keep multiple versions, each version holds its own tier, and explicitly tiering a version changes how that version is billed, but no new version is generated.

Is this different from changing an Amazon S3 storage class? Yes. Azure has a Set Blob Tier operation for changing a blob or version's tier. In S3, an immediate manual storage-class change is copy-based: AWS documents changing an existing object's storage class with a copy to the same object URI, and CopyObject returns the version ID of the newly created copy when versioning is enabled^[5]. S3 Lifecycle transitions are different: they transition the current or noncurrent object version selected by the rule rather than creating a new current version^[6]. See Azure Blob Tiers vs AWS S3 Storage Classes for the full comparison.

Can I set the tier per file share or only per storage account? That question is about Azure Files, which is separate from Azure Blob Storage. For Azure Blob, the tier is a property of each blob, so you set it per blob, and Blober changes many at once. For Azure Files, pay-as-you-go classic file shares have access tiers such as transaction optimized, hot, and cool, while the SSD/HDD media tier is a file-share planning choice. Microsoft documents that after you create a file share in a storage account, you cannot directly move it to a different media tier; to move from HDD to SSD, for example, you create a new share and copy the data^[7]. Blober's bulk tier change applies to Azure Blob blobs.

How long does a tier change take? Moving from a warmer tier to a cooler one, such as Hot to Cool or Cool to Archive, is instantaneous. Bringing a blob back from Archive to an online tier is a rehydration that can take up to 15 hours, depending on the priority you choose.

Can I move blobs to Archive in bulk without PowerShell? Yes. Select the blobs in Blober, choose Archive as the target tier, and run the mutation. No script, no lifecycle policy, no Azure CLI. The same works in reverse to rehydrate selected blobs to Hot, Cool, or Cold.

Will changing tiers re-upload my data? No. A tier change is a service-side access-tier operation on the blob. Nothing is downloaded or re-uploaded by Blober, so there is no tool-side data transfer for the change itself. Azure still bills the Set Blob Tier request as a write operation for tier-down and a read operation for tier-up^[8].

Related Guides

• Azure Blob Tiers vs AWS S3 Storage Classes
• How to Transfer Files from AWS S3 to Azure Blob Storage
• Cloud Storage Ingress vs Egress Fees

Get Blober

Blober is a one-time purchase. No subscriptions. No transfer fees. No transfer limits.

Download Blober at blober.io

Tags:

• blober
• azure
• azure blob storage
• storage tiers
• cloud storage
• cost optimization

How to Move Data from Azure Blob Storage to Cloudflare R2

May 11, 2026

The Egress Problem

Azure Blob Storage charges $0.087 per GB for data leaving their network. If you serve 1 TB of files per month to users or external systems, that is $87/month in egress alone, on top of storage costs.

Cloudflare R2 charges $0 for egress. Zero. Nothing. You pay for storage ($0.015/GB/month) and operations, but downloading data from R2 is free. For applications that serve files to users, APIs, CDNs, or other services, switching to R2 can cut your cloud bill significantly.

Why People Make This Move

The most common reason is cost. If your Azure Blob account is mostly used for serving static assets, media files, backups that get restored frequently, or API responses, the egress fees can dwarf your storage costs. R2 removes that variable entirely.

Another reason is simplicity. R2 is S3-compatible, meaning any tool or SDK that works with S3 works with R2. If your application already uses the S3 API (many do, even on Azure), the migration is mostly about moving data and updating the endpoint.

How to Transfer with Blober

Blober supports both Azure Blob Storage and Cloudflare R2 as native providers. The transfer works like any other Blober workflow: connect both accounts, select files, run.

Step 1: Connect Azure Blob Storage

Add Azure Blob as a provider with your connection string. Blober lists your containers and their contents.

Step 2: Connect Cloudflare R2

Add Cloudflare R2 as a provider. You will need your Account ID along with an S3-compatible Access Key ID and Secret Access Key from the Cloudflare dashboard. If you also provide a Cloudflare API token, Blober can list your buckets through Cloudflare's native API with server-side pagination, which is more efficient for accounts with many buckets.

Step 3: Create a Workflow

Set Azure Blob as the source and Cloudflare R2 as the destination. Browse your Azure containers, select the files or containers you want to migrate, and choose the destination bucket in R2.

Step 4: Run

Blober streams data from Azure through your machine to R2. It uses parallel uploads on both ends, so large files move efficiently. If the transfer is interrupted, Blober resumes from where it stopped.

What About Azure Egress Fees During Migration?

This is the unavoidable part. Moving data out of Azure means paying egress. For the initial migration, you will pay $0.087/GB to get your data from Azure to your machine (where Blober runs), and from there to R2.

For 1 TB, that is about $87 in egress fees. That is a one-time cost. After the migration, your ongoing egress from R2 is $0.

If you were paying $87/month in Azure egress, the migration pays for itself in the first month.

Migration Cost Estimate

Data Size	Azure Egress Cost (one-time)	Monthly Savings on R2
500 GB	~$43	Depends on egress pattern
1 TB	~$87	Up to $87/month
5 TB	~$435	Up to $435/month
10 TB	~$870	Up to $870/month

R2 Is S3-Compatible

This matters because your application code likely uses the AWS SDK or an S3-compatible client. After migrating data to R2, updating your app is often as simple as changing the endpoint URL and credentials. No SDK changes, no API rewrites.

Blober connects to R2 using the same S3 protocol, so the transfer is seamless.

When Azure Is Still the Right Choice

R2 is excellent for serving files and eliminating egress. But Azure has features that R2 does not:

• Storage tiers (Hot, Cool, Cold, Archive) for lifecycle cost optimization
• Geo-redundant replication built into the platform
• Azure Functions and event triggers tied to blob operations
• Enterprise compliance certifications that some industries require

If you need those features, Azure is worth the egress premium. Many teams keep some data on Azure (for processing and compliance) and move the served/public data to R2 (for cost savings).

Get Blober

One-time purchase. Transfer as much data as you need.

Download Blober at blober.io

Tags:

• blober
• azure blob storage
• cloudflare r2
• cloud migration
• egress fees
• cloud transfer

How to Transfer Files from AWS S3 to Azure Blob Storage

May 11, 2026

Moving Between AWS S3 and Azure Blob

AWS S3 and Azure Blob Storage are the two most popular object storage services in the world. Companies move data between them for all sorts of reasons: switching primary cloud vendors, setting up multi-cloud redundancy, following compliance requirements, or simply taking advantage of Azure's pricing for certain workloads.

The transfer itself is the hard part. Both providers have their own tools (AWS DataSync, Azure Data Box, AzCopy), but those tools are designed for their own ecosystem. Cross-cloud transfers with native tools usually require intermediate steps, scripting, or third-party managed services that charge per-GB.

The Usual Approaches

AzCopy + AWS CLI

You can download from S3 using the AWS CLI and upload to Azure using AzCopy. This requires local disk space for the intermediate files, separate authentication for each tool, and scripting to coordinate the two.

Managed Migration Services

Services like Flexify charge per-GiB transferred. For large migrations (10 TB+), the fees add up. Your data also routes through their infrastructure, which may not meet compliance requirements.

rclone

rclone supports both S3 and Azure Blob. It works, but you need to configure both remotes, handle multipart upload settings, and manage the transfer from the command line.

How Blober Handles It

Blober connects to both AWS S3 and Azure Blob Storage natively. You configure both providers with their respective credentials, create a workflow, and run the transfer. Files stream from S3 through your machine to Azure without intermediate storage.

What Blober Does That Matters for This Transfer

Parallel uploads to Azure. Blober uses Azure's uploadStream with configurable concurrency. Large files are streamed in parallel chunks, which makes a noticeable difference on fast connections.

S3 streamed reads. On the source side, Blober reads S3 objects as streams through the AWS SDK. Large objects do not need to be staged as full local files before Azure upload begins.

Azure tier selection. When setting up Azure as your destination, you choose which storage tier new blobs land on: Hot, Cool, Cold, or Archive. This means you can migrate directly to the tier that matches your access pattern without a second step to change tiers after upload.

Write behavior options. You can configure Blober to overwrite existing blobs, skip files that already exist at the destination, or skip only archived blobs. This is useful for incremental migrations where you want to resume without re-transferring what is already there.

Step-by-Step

1. Connect AWS S3: Add S3 as a provider with your Access Key ID, Secret Access Key, and region. Blober lists your buckets.
2. Connect Azure Blob: Add Azure Blob Storage with your connection string. Blober verifies and lists your containers.
3. Create a workflow: Set S3 as source, Azure Blob as destination. Browse and select files or entire buckets.
4. Choose Azure options: Pick the storage tier and write behavior.
5. Run: Blober transfers with progress tracking. If you stop and rerun later, skip-existing avoids sending blobs that already landed.

Migrating Buckets in Bulk

Most S3-to-Azure jobs are not a single file, they are whole buckets or whole prefixes. Blober is built for that.

• Select an entire bucket or prefix. Browse your S3 bucket in Blober, select everything at the top level or drill into a prefix, and queue it all in one workflow. You do not enumerate keys by hand or script a loop.
• Mass transfers run in parallel. Blober reads from S3 as streams and uploads to Azure with parallel streams, so a bucket with thousands of objects moves as a continuous pipeline rather than one object at a time.
• Repeatable with skip-existing. Set the write behavior to skip blobs that already exist at the destination. If a multi-terabyte run is interrupted, or you stop and continue tomorrow, re-running the workflow picks up only what has not transferred yet. That is what makes a mass migration practical: you are not forced to start the whole job over.
• Land directly on the right tier. Pick the Azure tier for the whole job, so a bulk archive migration writes straight to Cool, Cold, or Archive instead of landing on Hot and needing a second pass.

For a move of 5 TB across 200,000 objects from us-east-1 to westeurope, you point Blober at the bucket, choose the destination container and tier, turn on skip-existing, and let it run. Progress is tracked per file, and rerunning the workflow after an interruption skips blobs that already completed.

Cross-Region Awareness

If your S3 bucket is in us-east-1 and your Azure storage account is in westeurope, Blober handles the cross-region transfer. S3's cross-region copy limitations (which affect native S3-to-S3 copies) do not apply here because the data flows through your machine.

The tradeoff is that transfer speed depends on your internet connection. For very large migrations (50 TB+), this is usually slower than a datacenter-to-datacenter transfer. But for gigabytes to a few terabytes, running through Blober on a fast connection can be simpler than coordinating a managed migration service.

Pricing Comparison

For an S3-to-Azure move, price the transfer in parts instead of trusting a single headline number:

• AWS S3 source cost: data transfer out, source reads, and any retrieval fees if the source objects are in an infrequent-access or archive class^[1].
• Azure destination cost: Blob Storage usually does not charge for inbound data transfer, but new writes, storage tier, redundancy, and operation charges still matter^[2].
• Future Azure egress: if the data later leaves Azure, outbound bandwidth is priced separately by route, zone, and volume^[3].

Azure can be cheaper for some storage-heavy workloads, while S3 can be better when the surrounding AWS ecosystem matters. The right choice depends on access pattern, region, redundancy, tier, request volume, and where the data will go next.

Frequently Asked Questions

How do I copy data from S3 to Azure Blob without AzCopy or scripts? Connect both providers in Blober, create a workflow with S3 as the source and Azure Blob as the destination, select your buckets, and run. There is no AzCopy command, no AWS CLI loop, and no intermediate download to your disk. Files stream from S3 straight to Azure.

Can I migrate a whole bucket, or only individual files? Either. Select a single object, a prefix, or an entire bucket. Whole-bucket and mass-data migrations are the common case.

Does the data land on the tier I want? Yes. You choose the Azure access tier (Hot, Cool, Cold, or Archive) for the destination, and new blobs are written to that tier on arrival. There is no second pass to re-tier after upload.

Who pays for the data transfer? AWS charges egress (data transfer out) when data leaves S3, billed per GB. Azure lists data transfer in as free, while outbound bandwidth is priced separately^[4]. So the transfer cost usually sits on the AWS side, the same as it would with any tool that reads from S3. Blober adds no per-GB fee of its own.

How large a migration can this handle? Transfers run through your machine, so speed depends on your connection. For moderate migrations, Blober avoids managed-service setup and can be rerun with skip-existing if interrupted. For datacenter-scale moves of 50 TB and up, a provider appliance or assisted migration may finish sooner.

Related Guides

• Azure Blob Tiers vs AWS S3 Storage Classes for choosing the right destination tier
• How to Bulk Change Azure Blob Storage Access Tiers once your data is on Azure
• How to Move Azure Blob to Cloudflare R2 for moving off Azure later
• Provider setup: AWS S3 and Azure Blob

Get Blober

Migrate S3 buckets to Azure Blob in bulk, with no AzCopy scripts and no per-GB transfer fee from us. One-time purchase, no subscription.

Download Blober at blober.io

Tags:

• blober
• aws s3
• azure blob storage
• cloud migration
• enterprise
• cloud transfer