S3 改变了什么：一个让所有人都有「无限硬盘」的小协议

朴素科技第三篇文章，从亚马逊的一个内部想法说起，聊 S3 如何成为对象存储的事实标准、它的对手有多孤独，以及它如何悄悄撑起了整个互联网的存储层。

2026年9月5日

📖 约 5 分钟阅读

S3 改变了什么：一个让所有人都有「无限硬盘」的小协议

这是「朴素科技」的第三篇文章。上次我们聊了 Kubernetes——它把成百上千个容器安排得井井有条。今天我们退一步，去看看这些容器、这些应用、这些网站背后最朴素的一块「地基」：存储。

一、先回答一个问题：什么是「对象存储」

聊 S3 之前，得先聊一个更基础的概念——对象存储 (Object Storage)。

我们日常说的“存文件”，其实在计算机里有三种不同的方式：

块存储 (Block Storage)：把硬盘切成一摞“积木块”给你用，最贴近物理硬件，速度最快。典型代表是服务器本地盘、AWS EBS。
文件存储 (File Storage)：在块存储之上加一层文件夹结构，能 mkdir / cd / ls，多台机器可以共享访问。典型代表是 NAS、NFS。
对象存储 (Object Storage)：扔掉文件夹的概念，每一份文件都是一个独立的“对象”—— 存进一个扁平的命名空间里，靠 HTTP 协议访问。

对象存储最大的特点，是它不挑数据量大小。你存 1 个文件也行，存 100 亿个文件也行；每个文件最大可以是几十 TB；存多少、用多久，都按实际用量计费。

它的代价也很直接：不能像硬盘那样随机修改中间一段，也不像数据库那样支持复杂查询——它就是「放进去，取出来」。

听起来很简陋对吧？但就是这种简陋，让它成了整个互联网的底层仓库。

二、亚马逊的那次「无心插柳」

S3 的故事，要从 2006 年 3 月说起。

那时候的“云计算”还只是一个模糊的概念。亚马逊有一个内部基础设施团队——后来被叫做 AWS—— 想把自己公司庞大的电商基础设施做成可对外租用的服务。

2006 年 3 月 14 日，亚马逊正式发布了 S3 (Simple Storage Service)。注意一个有意思的细节：S3 甚至比 EC2 (Elastic Compute Cloud) 还要早几个月上线。也就是说，AWS 公开发布的第一个服务不是“云主机”，而是“云硬盘”。

最初的 S3 简单得几乎粗暴：

你通过 HTTP PUT 一个文件上去，它就给你返回一个 URL；
之后任何人通过那个 URL（或它的变体）都可以下载；
计费按存储量和流量，没有最低消费，没有承诺。

在那个年代，这是一件匪夷所思的事。之前的存储服务，要么是按容量买断的、要么要签长合同；谁能想象“用多少付多少、想存多少存多少、几分钟就能开通”这种事？

S3 的设计文档里有句话被后来的工程师们反复引用：

“We wanted to remove the friction of buying storage.”

我们想去掉“买存储”这件麻烦事。

——这又是一种朴素的科技：用一个简单的 HTTP 接口，让“存东西”这件事回归它最本来的样子。

三、S3 是怎么成为「事实标准」的

在 S3 出现的头两年，市面上还有不少对手—— 微软的 Azure Blob Storage（2010 年上线）、Google 的 Cloud Storage、各家自研的对象存储服务。

但十几年过去后，行业里出现了一个奇怪的现象：

几乎所有对象存储，都在努力让自己“长得像 S3”。

为什么？因为 S3 太早、太简单、太普及了。

1. 开发者已经会用了

S3 的 API 是 REST 风格，每一个开发者上手几分钟就能用。在无数教程、博客、开源项目里，“把文件存到 S3”几乎是默认写法。一个新人学存储，学的就是 S3。

2. 工具链全部跟着 S3 走

boto3（AWS 官方 SDK）、aws-cli、各种备份工具、CI/CD 工具、CDN、Terraform 模块…… 几乎所有的工具都把 S3 作为“一等公民”。这种生态一旦形成，后来者要么兼容、要么自建。

3. 兼容 S3 几乎不需要代价

S3 的 API 公开、稳定、好理解。重新造一套完全不同的 API，意味着要让用户重新学习、要让自己的工具链重新适配—— 对一个新进入者来说，成本远大于收益。

于是今天我们看到，全球绝大多数对象存储服务，都在接口层面对 S3 做了高度兼容：

AWS S3 — 原版，无需多说。
Cloudflare R2 — 完全兼容 S3 API，主打零出口流量费。
阿里云 OSS — 大部分操作兼容 S3，命令行工具 ossutil 也提供 S3 模式。
腾讯云 COS — 提供了 S3 兼容接口。
华为云 OBS — 提供 S3 兼容模式。
Google Cloud Storage — 通过 s3互操作 模式支持大部分 S3 API。
Backblaze B2 — 完全兼容 S3，价格只有 AWS 的大约 1/4。
Wasabi — 完全兼容 S3，定位于“热存储”档。
MinIO / Ceph RGW — 开源对象存储，自带 S3 兼容网关。

4. 那个孤独的例外

在这片「S3 海洋」里，有一个始终坚持自己 API 的玩家——微软 Azure Blob Storage。

Azure Blob 早在 2010 年就上线了，那时候 S3 也才 4 岁。 Azure 选择走自己的 REST API 路线，有它自己的设计考量：更贴近 Windows / .NET 生态、更早支持服务端加密和分层存储、目录树概念比 S3 略强一些。

这件事直到今天仍然让不少开发者头疼：一份 aws s3 cp 命令，在 Azure Blob 上要换成 az storage blob upload； boto3 的代码迁到 Azure，要换成 azure-storage-blob。

但 Azure 也有它的底气—— 它背靠庞大的企业市场，许多微软栈公司“非 Azure 不可”。

事实标准的形成，从来不是技术一家的胜负。 S3 赢，是因为它早 + 简单 + 通用 + 长期稳定； Azure Blob 还在，是因为它有自己的山头。

四、几朵公有云上的“对象存储”

站在 2026 年这个时间点，把公有云上的对象存储简单梳理一下，大概是这样一幅图：

服务	厂商	区域	与 S3 的关系
S3	AWS	全球	原版
Cloud Storage	Google Cloud	全球	提供 S3 互操作
Blob Storage	Azure	全球	不兼容 S3
OSS	阿里云	中国/海外	大部分兼容 S3
COS	腾讯云	中国/海外	提供 S3 兼容接口
OBS	华为云	中国/海外	提供 S3 兼容模式
R2	Cloudflare	全球	完全兼容 S3
B2	Backblaze	北美/欧盟	完全兼容 S3
Wasabi	Wasabi	北美/欧盟/亚太	完全兼容 S3

除了公有云，还有一大块世界是自建的对象存储—— 特别是在企业内部、对成本敏感的项目、需要数据本地化的场景下。这就轮到开源登场了。

五、那些撑起自建世界的好工具

如果你想在自己的服务器、香橙派甚至树莓派阵列上跑一个「S3 兼容存储」，下面这几个开源项目是绕不开的：

1. MinIO

「S3 兼容对象存储的事实标准。」

MinIO 是过去几年最火的自建对象存储，接口完全兼容 S3。部署非常简单——一个二进制文件、几条命令，就能跑起来一个生产可用的存储集群。

单节点可以当开发环境用；
多节点可以组成 EC 风格的分布式集群；
性能极强，常被用作 AI 训练数据的底层仓库。

如果你只想存一些家里的照片、备份，或者公司内部的文件归档，MinIO 通常是首选。

2. Ceph RGW

Ceph 是一个统一的分布式存储系统，可以同时提供块、文件、对象三种接口。其中的 RGW (RADOS Gateway) 负责对象存储这一块，接口兼容 S3 和 Swift。

Ceph 的部署和运维比 MinIO 复杂得多，但好处是生态成熟—— OpenStack、Proxmox、各种云平台默认的存储后端，都是 Ceph。

在大型企业的存储方案里，你大概率会碰到 Ceph。

3. SeaweedFS

一个 Go 写的小巧文件系统，主打海量小文件。在某些场景下比 MinIO 更轻量、更适合边缘设备。

4. Garage

由法国 CNRS 团队开发的轻量对象存储，目标是自托管 + 低资源占用，适合小集群、自家机房的实验性场景。

公有云的「S3 海洋」背后，是开源世界的「兼容 S3 协议联盟」。它们一起，让「对象存储」这件事在任何角落都能用上。

六、S3 对我们意味着什么

回到我们的主题：S3 这种「朴素的科技」，对我们意味着什么？

1. 对开发者：硬盘这件事，不再是瓶颈

在 S3 之前，一个团队要存用户上传的图片、备份数据库、或者托管静态资源，需要自己买硬盘、买 NAS、搞 Raid、怕硬盘坏…… 在 S3 之后，这些事全部外包给了一个 HTTP 接口。你写的代码就是 boto3.client('s3').upload_file(...)，背后有多少台机器、跨了多少个数据中心，都是 S3 的事。

「业务」和「基础设施」之间的边界，被 S3 推到了一个新的位置。

2. 对公司：从 CAPEX 到 OPEX 的转变

以前要建一个能存 1 PB 数据的存储系统，需要采购、机房、运维、预算流程。现在注册一个 AWS 账号，几分钟就有 1 PB 用，按月付费，用完就走。

这种从「资本支出 (CAPEX)」到「运营支出 (OPEX)」的转变，让初创公司可以在第一天就拥有和大厂一样的存储能力。

3. 对普通人：看不见的相册

你手机里那张自动同步到云端的照片、你下载的电影、你在电商网站看到的产品图、你刷短视频时的封面—— 这些数据大部分都躺在某个对象存储桶里。

你不会感觉到它的存在，但如果没有 S3 这种东西，今天我们习以为常的“手机相册永不丢失”、“短视频秒级加载”都不会发生。

4. 对开源：又一次「标准的力量」

S3 的故事，是开源世界非常熟悉的那种剧本—— 一个好用的、开放的协议，被市场用脚投票成为事实标准，后来者必须兼容，否则就要付出巨大的生态代价。

HTTP、SQL、SMTP、Git……这些都是这种剧本。它告诉我们：在技术世界里，「被最多人用」往往比「技术上更优秀」更有力量。

七、一点朴素的感想

写到这里，我想起了自己第一次接触 MinIO 的那个下午。

那是一段有点尴尬的经历。子公司的业务要上线一个需要「对象存储」的系统，但当时子公司这边并没有准备—— 不是没买云服务，而是整个子公司都跑在私网里，不允许连任何公有云。时间又紧，临时找不到更合适的方案，我被拉去解决问题，几乎是从零开始上手 MinIO。

那也是我第一次明白：所谓“S3 兼容”并不只是一句宣传语。一行命令拉起一个容器，写一份最简单的 yaml 把卷和路径配好，再把 mc 客户端装好——一个能跑业务的对象存储，就这么搭起来了。

后来没过多久，总部这边也上线了私有云的对象存储，大部分子公司都迁了上去。但那些一时半会没条件上的子公司，今天仍然在用 MinIO—— 简单、稳、不依赖外网，刚好够用。

还有一件有意思的事，是关于 Azure Blob + MinIO Gateway 的部分。我们在海外的 UAT 环境里用的就是 Azure Blob——那边既没有 S3 也没有 S3 兼容的存储，只有 Azure 一套。生产环境（部分跑在 GCP，部分跑在本地私有云）则全是 S3 或兼容 S3 的存储。

我们这套程序是「全球化」的——总部、子公司、海外分公司都跑同一份代码。如果当年直接接 Blob 的 SDK，UAT 没问题，生产就要大改一遍；反过来直接接 S3 的 SDK，生产没问题，UAT 又要绕一道。

于是我们就只在 UAT 这一层用 MinIO Gateway 把 Blob 也包成了 S3 接口—— 让所有 SDK 全部按 S3 写，底下各跑各的，互不干扰。

这件事让我再一次感受到：标准的价值，往往不在它本身有多先进，而在它让两套本不兼容的东西，可以和平地坐在同一个屋檐下。

S3 之所以成为对象存储的事实标准，它不漂亮、不炫技、不需要你理解它—— 它只是安静地、可靠地、十几年如一日地，把「存东西」这件事变得朴素起来。

下一次，我们会把镜头从云上往下拉一拉，去看一个更安静、更沉默、却支撑着几乎一切的基础—— Linux，以及把它带到这个世界的 Linus，和维护着它的 Linux 基金会。

参考资料

Amazon S3 官方文档：docs.aws.amazon.com/s3
A Brief History of Amazon S3 (Jeff Barr, AWS News Blog)
MinIO 官方文档：min.io/docs
Ceph 官方文档：docs.ceph.com
公有云对象存储对比（多家云厂商公开文档）

— RCLiLong，写于 2026 年秋