Comparison · 2026-07-20 · 9 min read
S3 is one of the best pieces of infrastructure ever shipped. It has been up for two decades, the API is so well designed that half the industry cloned it, and it does the unglamorous job of not losing your objects with remarkable consistency. Any comparison that opens by pretending otherwise is not worth your time.
It is also a service owned by one company, priced by that company, and governed by an agreement that lets that company decide things about your data. For most workloads that is a perfectly reasonable arrangement. For some it is not, and those are the ones worth talking about honestly.
The mental model maps almost one to one
If you know S3, you already know most of Walrus. You put bytes in, you get an identifier, you store that identifier next to your application data, you fetch by identifier later. The one genuinely new concept is where the identifier comes from. An S3 object lives at a key you chose inside a bucket you rent — s3://my-bucket/uploads/logo.png. A Walrus blob is content-addressed: the identifier is derived from the bytes themselves, and the fact that the network is storing it is registered on the Sui blockchain. There is no bucket, no namespace to own, and no account to be suspended — access is tied to keys you hold.
| Concept | Amazon S3 | Walrus |
|---|---|---|
| Addressing | Bucket plus key you choose | Blob ID derived from the content |
| Namespace ownership | You rent the bucket | There is no namespace |
| Redundancy | Replicated within a region | Erasure-coded across independent operators |
| Proof it is stored | The provider’s SLA | A record on a public blockchain |
| Reading it back | Free in-region, charged out | Free |
| Access control | IAM, policies, presigned URLs | Anyone with the blob ID can read it |
| Confidentiality | Server-side or client-side encryption | Yours to add before upload |
| Mutability | Overwrite a key, versioning available | Immutable — new bytes are a new blob |
| Deletion | Delete the object | Delete the blob object, or let it expire |
| Billing | Monthly, by storage plus requests plus egress | Up front, by size and duration |
The four differences that actually change decisions
Egress
Reading your own data out of S3 to the public internet is a metered cost, and at scale it is often the largest line on the bill. On Walrus, reads are free — there is no provider boundary to cross, because the data is already distributed. If you serve a lot of bytes to users, this is not a rounding difference, and it also removes the quiet penalty on ever migrating away. That dynamic is worth understanding on its own terms: Vendor Lock-In and the Cost of Leaving.
Access control
This is where S3 is unambiguously ahead, and it would be dishonest to spin it. IAM, bucket policies, presigned URLs and object ownership form a mature, fine-grained system. Walrus has nothing equivalent: a blob is public, and holding its identifier is enough to read it. If your objects are private, that means encrypting before upload and treating the blob ID as a capability. It is a workable pattern and plenty of systems are built that way, but it is a design constraint you must plan for, not a checkbox you enable later.
What the durability guarantee rests on
S3 offers an extremely strong durability figure backed by a contract with a company. Walrus offers redundancy backed by erasure coding across operators who have no relationship with each other, plus a public on-chain record that the data is being stored. The practical difference is what you are trusting: an institution’s promise and continued operation, versus a mathematical property and a network with no centre. Neither is automatically better — but only one of them survives the institution. The erasure coding explainer covers why losing a chunk of the network does not lose the file.
Who can turn you off
An AWS account can be suspended — for a billing problem, a compliance review, a policy interpretation, or a sanctions regime that has nothing to do with you personally. It is uncommon and it is also not hypothetical. There is no such lever on Walrus, because there is no account. Whether that matters depends entirely on what you are building; if it does matter, no amount of S3 engineering quality substitutes for it.
When to pick which
| If your workload is… | Pick |
|---|---|
| Private user data needing per-object permissions | S3 |
| Frequently overwritten objects and mutable state | S3 |
| Tightly coupled to Lambda, Athena, CloudFront and friends | S3 |
| Public assets served at volume where egress dominates | Walrus |
| Archives and records that must outlive any vendor | Walrus |
| Data whose integrity you need to prove to a third party | Walrus |
| Anything that must not depend on one account staying open | Walrus |
| Most ordinary application storage | Honestly, S3 — and that is fine |
The useful question is not which is better. It is which failure you would rather be exposed to: a company changing its mind, or a network you have to understand.
Trying it without touching your architecture
The cheapest way to build real intuition is to store one object end to end and look at what comes back. Walrus Drive does this in a browser with no setup: connect a Sui wallet, upload, see the exact cost before approving, and inspect the resulting blob ID and its on-chain record. From there, the developer docs cover the S3-style HTTP surface — reads are live today and the metered write API is in private beta — and A Developer’s Guide to Building on Decentralized Storage goes through the integration patterns that actually hold up in production.
One last piece of practical advice, learned the hard way by everyone who tries this: persist your blob IDs as carefully as you persist your primary keys. They are your handles to the data, and unlike a bucket listing, there is no console you can browse to recover one you lost track of.