Azure Blob Storage vs Amazon S3 vs Google Cloud Storage

Object storage is the cleanest mapping in the whole cross-cloud table — the same bucket-of-files idea wearing three names. Then Azure slips an extra layer underneath it, and that's the part worth reading.

New to cloud? CAMPUX is a free, build-first course. Start here →

Azure Blob Storage, Amazon S3, and Google Cloud Storage are the same service: cheap, durable object storage where you drop unstructured files, address them by name over HTTPS, and pay pennies to keep them. The concepts map almost perfectly — tiers, lifecycle rules, signed URLs, static hosting, all three have them. The one real difference is structural: on AWS and GCP a bucket is a top-level thing you create directly, while Azure makes you stand up a storage account first and puts containers inside it. That extra layer is the whole gotcha.

If you already know S3, this is the easiest cloud you'll ever cross into. Object storage is the workhorse behind backups, static websites, data lakes, media libraries, and log archives on every cloud, and it works the same way everywhere: unlimited flat storage, no filesystem to manage, an object addressed by a key, served over HTTP. Ninety percent of what you know carries straight over. It's the last ten percent — Azure's storage account — that this note is really about, because it's the single thing that trips up S3 people on their first Azure day.

What all three actually are

Same primitive on every cloud: a place to put a blob (a "binary large object" — really just a file) and get it back by name. You don't mount it like a disk and you don't query it like a database. You PUT an object with a key, you GET it by that key, and the platform handles durability by copying it across hardware behind the scenes. It scales to effectively unlimited size, costs very little per gigabyte, and charges you separately for storage, requests, and egress. That description fits Blob Storage, S3, and Cloud Storage without changing a word.

The terminology, side by side

Three vocabularies for one design. The only row that isn't a clean synonym is the container, and only because of what sits above it on Azure — more on that in a minute.

The tiers line up cleanly

Every one of the three lets you pick how hot or cold each object is, priced on the same trade-off: the colder the tier, the cheaper to store and the more you pay (in money and latency) to read it back. Set the tier per object or per container, and the names slot together almost one-to-one.

And you don't move objects between tiers by hand. All three have lifecycle management: you write a rule once — "anything not touched in 30 days drops to Cool, anything past 180 days goes to Archive, delete after seven years" — and the platform demotes objects on schedule. Same feature, same reason, near-identical policy syntax in spirit. It's how you stop paying hot prices for logs nobody's read since last quarter.

The one place it breaks: Azure's storage account

Here's the thing that isn't a synonym. On AWS you create a bucket directly in your account, and on GCP you create a bucket directly in your project. The bucket's name is globally unique across the entire cloud, and that's the whole hierarchy — bucket, then objects inside it. Two levels.

Azure inserts a level in the middle. You don't create a container first — you create a storage account, and blob containers live inside that account. The globally-unique name you have to fight for isn't the container's, it's the storage account's. The container name is a second-level namespace, unique only within its account. So the endpoint reads myaccount.blob.core.windows.net/mycontainer/myblob — account, then container, then blob. Three levels, not two.

An S3 bucket is about equal parts Azure storage account plus container — and you can't make the container without the account first.

And the storage account isn't only for blobs. It's a shared wrapper that also holds Azure Files, Queues, and Tables — four storage services under one account. There's simply no equivalent object on AWS or GCP; a bucket there is its own top-level thing with nothing bundled alongside it.

The other setting that lives at the account level on Azure is redundancy. You choose LRS, ZRS, GRS, or RA-GRS — how many copies, across how many zones or regions — once, for the whole storage account, and every container inside inherits it. On AWS and GCP that regional or multi-region choice is made per bucket instead. So the mental swap isn't just "bucket becomes container." It's "the durability and naming decisions you make per bucket on AWS get made one level up, per storage account, on Azure."

What maps without a fight

Almost everything else. A few worth naming because people ask:

• Consistency. All three are now strongly consistent for reads after a write — upload an object and the very next read returns it, no eventual-consistency window to reason about. S3 dropped its old caveat here years ago; Azure and GCS behave the same.
• Static website hosting. Every one can serve a bucket or container straight to the browser as a static site, index page and all. Same feature, different toggle location.
• Temporary links. Need to hand someone a download that expires, or let a browser upload directly without a public bucket? That's a SAS token on Azure, a presigned URL on S3, and a signed URL on GCS. Identical idea — a signed, time-boxed, scoped URL — three names.

None of those will cost you a weekend. The storage account is the one that does, so it's the one to internalize before you touch the portal.

So how should you think about it?

If object storage is your entry point into a second cloud, do the translation in one direction and keep it simple: the service and the tiers are synonyms you'll stop looking up by week two, and the SAS-token / presigned-URL / signed-URL trio is a straight rename. Spend your attention on the storage account, because it's the only concept here that doesn't exist on the other two. Once you've built one by hand — created the account, set its redundancy, added a container, uploaded a blob — the S3 model reads back as "Azure with the account layer collapsed away," and you'll never confuse a bucket for a container again. That's the order we teach it in the storage accounts class, and it's the same lesson the broader subscription vs account vs project comparison teaches at the billing layer: map on the role, then re-learn the shape.

Common questions