AWS CEO Matt Garman:创业公司撑起四成收入,云要为agent重新设计

1. 1690 亿美元、37% 增速，产能仍然要留给车库里的两个人

AWS 的年收入已经到了 1690 亿到 1700 亿美元，同比增长 37%。Matt Garman 是 EC2 的第一任总经理，2006 年那会儿这个数字还只是零。他并不认为这已经接近终点：今天绝大多数 workload 仍然跑在本地，人们每天消耗的算力比前一天更多，AI 与上云两股顺风同时在吹。

a16z 的 Raghu Raghuram 抛出的第一个问题就是分配难题——前沿大模型实验室会吃掉市面上几乎每一块能拿到的 GPU，而云厂商同时还要扶植那些"明天的企业客户"。Garman 的答案很直接：从 AWS 诞生的第一天起，创业公司就是核心业务的命脉，AWS 在产能上非常刻意地为创业公司留了一部分。他提到公司最近宣布，未来几年将采购 200 万块 NVIDIA GPU。账面另一边是资本支出：2026 年大约 2200 亿美元，且不打算很快放缓，因为需求太大。

2. 一份 2005 年的实习报告，把 AWS 押在了创业公司身上

2005 年，Garman 还在念商学院，实习项目是分析 AWS 最值得服务哪一类客户。结论是创业公司——这个答案今天听起来理所当然，但在当时它是一个内部项目的定位选择。他给了一个不算精确的估计：AWS 大约 30% 到 40% 的收入，来自那些在 AWS 生命周期内曾经是创业公司的客户。

钱之外的账更清楚：创业公司在技术的边缘，最早知道什么可能、最早知道自己想要什么。Garman 说，很多时候创业公司提要求比银行、医疗和政府都更靠前，而银行五年后才想要的能力，创业公司今天就要。对 AWS 来说，这等于提前拿到了未来需求的样张。

3. 创业公司本身也变了：第一天就值十亿

起步的形态完全不同了。过去一家创业公司可能融 1000 万美元，慢慢迭代一个应用想法；现在是从第一天就估值 10 亿美元、手上有 2 亿美元融资。Raghu 打趣说，这些团队基本上是从 a16z 的办公室直接走进 AWS 的办公室。

Garman 承认这种规模与野心本身就需要更多资本，也更贵——训一个模型或者做当下流行的那些事，成本结构跟十年前不是一个量级。这种"起手就是大公司"的速度，是这一代创业公司与上一代最直观的差别。

4. 没变的部分：架构、安全、IAM，以及为什么不去 Neocloud

规模上去了会怎样，这个老问题一点没少。创业公司依然在问：架构怎么设计才能扩、安全怎么做、性能怎么保证、IAM 怎么配，才能让公司在超过三个员工之后这套东西照样能跑。Garman 认为这正是他们选择 AWS 而不是 Neocloud 的原因——他们要的不只是裸算力，还有围绕训练的那一整套安全与配套能力。

底层构建块在他看来状态不错，真正在补的是上面那一层。而变的部分，是爬坡的速度：从两人团队到需要企业级治理，中间的过渡时间被压缩得很短。

5. 云的用户正在从人换成 agent

现在越来越多的团队要的不是一个对人友好的云，而是一个对 agent 友好的云。这件事落到工程上有很具体的含义：接口要定义得足够清晰，让 agent 能自己走通；数据库要能在 3 秒内起来。人未必会以那种方式访问数据，agent 却很乐意在 Aurora、S3 和各种数据源之间来回翻找。

为此 AWS 在 beta 或预览阶段做了一个叫 AWS context 的东西，用来搭一层上下文层，让 agent 更容易找到散布在各处数据源里的数据。另一件被重新拿出来看的是性能指标——吞吐量、延迟，以及尾延迟。人不一定在意 S3 的 P999 延迟，agent 会卡在那上面。Garman 把这视为 agentic 工作流在 AWS 上跑得比别处更好的原因之一。

6. 当 agent 自己写代码、自己挑数据库

真实场景已经长成这样：客户告诉自己的编程 agent——不管是 Kiro、Claude 还是 Codex——"我要在 AWS 上搭东西，这是我的凭证"，然后 agent 自己就去完成了部署。所谓"agent 帮你选数据库、选邮件服务器"的说法，在 Garman 这里对应的是底层组件被更好地封装，而不是把每一项服务推倒重写。

他坦承还有一类场景没有完全覆盖：用户本来就不在任何一朵云上，只是先试试，说一句"部署"，很多时候会走到那些在 AWS 之上做了更易用封装的合作伙伴那里。AWS 对此的态度是乐见其成，同时也在琢磨自己的那层可用性体验该怎么做。

7. 命脉与配额，是同一条逻辑

把这场对话里的几条线索拼起来，AWS 的自我判断其实很一致：创业公司依然是需求定义者，所以产能必须预留；agent 正在成为云的第二种用户，所以接口、延迟和上下文层都要按它们的习惯重做；而生意仍在早期——绝大部分 workload 还没上云，每天被消耗的算力比前一天更多。

三十年前那间车库里写下的实习结论，今天变成了采购两百万块 GPU 时的分配原则。真正的问题不在于云能不能服务 agent，而在于它是否愿意为此改掉那些为人类用户优化了二十年的默认设定。