Amazon Commits $220 Billion Capex to Pivot AWS Toward AI Agents

亚马逊承诺投入2200亿美元资本支出推动AWS转向AI智能体 随着自主智能体工作负载取代人类操作员，AWS正全面重构核心云原语，并适度分流GPU算力以支持早期构建者，而非向前沿实验室倾斜全部资源。 AWS首席执行官Matt Garman阐述了支持自主AI智能体所需的架构与运营演进，重点介绍了Firecracker沙箱、低延迟上下文层以及精简账户入驻流程等新原语。针对供应紧张问题，Garman解释了亚马逊为何承诺投入约2200亿美元资本支出，并特意为早期初创公司预留稀缺GPU算力，而非全部分配给前沿模型实验室。他还详细介绍了AWS自研芯片的战略轨迹——从Nitro和Graviton到Trainium崛起成为主力推理工具，并评估了企业如何通过强大的评估流程、数据隐私保护措施以及智能体驱动的内部工程小组来克服信任壁垒。 亚马逊正投入约2200亿美元年度资本支出以扩展AI和云能力，承诺采购约200万颗NVIDIA GPU，并特意为早期初创公司划分算力配额，而非全部售予前沿模型实验室。 (17:27) AWS正在针对自主智能体全面重构核心云原语，推出30秒无缝账户入驻流程，构建跨代码库的数据上下文层，并改造Firecracker微虚拟机（microVM）沙箱以执行不可信的智能体生成代码。 (8:49) 自研芯片已成为AWS的核心成本效益引擎：前100大客户中超90%采用了基于ARM架构的Graviton CPU，而Trainium 3在发展成为大规模推理主力后，产能已售罄至明年底。 (34:44) AWS内部产品工程正转向智能体优先工作流，仅需三至四名工程师监督自主智能体的小组，即可交付以往需要十人团队才能完成的功能。 (53:25)

AWS CEO Matt Garman argues that the rise of autonomous AI agents requires fundamentally re-architecting cloud infrastructure, energy pipelines, and organizational design, prompting Amazon to project roughly $220 billion in capital expenditures to sustain surging compute demand. Redesigning Cloud Primitives for Autonomous Workloads (6:45) Garman observes that autonomous agents interact with cloud infrastructure differently than human operators, generating rapid, parallel programmatic calls that make systems acutely sensitive to p99.9 tail latency. To accommodate agentic patterns, AWS is testing AWS Context in preview to semantically bridge fragmented data silos like Amazon S3 and Aurora. Additionally, AWS is overhauling account onboarding to allow developers and agents to provision functional, default-configured accounts in under 30 seconds without credit cards or manual Virtual Private Cloud (VPC) setup. Agent workloads also require specialized architectural primitives. Because coding agents routinely spin up databases to test tasks for minutes before tearing them down, infrastructure must offer instantaneous provisioning without abandoning durability. AWS is addressing this through isolated execution environments powered by open-source Firecracker microVMs, time-boxed permissions rather than static human credentials, and specialized agent gateways designed to regulate non-human access. Managing $220B CapEx and Infrastructure Bottlenecks (17:27) To keep pace with AI demand, Amazon is deploying an estimated $220 billion in capital expenditures and has committed to purchasing approximately 2 million NVIDIA GPUs over the coming years. Garman notes that operational constraints cycle continuously between power availability, data center shell construction, high-bandwidth memory, accelerator chips, and skilled trade labor. To manage these constraints, AWS plans utility-scale energy projects up to 20 years out—funding direct renewable and nuclear power generation—while tracking supply chains four to five tiers deep. Despite heavy demand from frontier AI research labs, Garman emphasizes that AWS deliberately avoids selling 100% of its accelerator fleets to hyperscale labs. AWS intentionally carves out capacity for startups and enterprise production workloads, currently fulfilling approximately 60% of incoming accelerator requests by adjusting schedules, regions, or hardware configurations. Garman dismisses concerns of a systemic AI bubble for AWS, asserting that enterprise clients report positive business ROI and that revenue is diversified across production applications rather than concentrated in single model providers. Custom Silicon from Nitro to Trainium (34:44) AWS's custom processor development began over a decade ago with Project Nitro, which offloaded network and storage virtualization onto bespoke ARM-based cards. By stripping the virtualization tax from host CPUs, Nitro delivered bare-metal performance and strict security isolation. This hardware architecture paved the way for the Graviton CPU family—now AWS's most deployed server processor, delivering an estimated 20% cost reduction and 20% performance boost—which Garman states is utilized by more than 90% of AWS's top 100 customers. In machine learning silicon, AWS's Trainium architecture has evolved from a dedicated training processor into a heavily utilized inference platform due to the clustered memory and networking requirements of modern foundation models. Garman reports that Trainium 3 capacity is sold out through late next year, supporting major workloads for partners like Anthropic and OpenAI alongside the vast majority of Amazon Bedrock's customer traffic, while teams prepare for the announced Trainium 4 architecture. Enterprise Evaluation Loops, Security, and Governance (43:06) While mid-to-large enterprises are experimenting with AI agents, Garman explains that most deployments remain cautious and maintain humans in the loop. The primary hurdle is establishing verifiable evaluation frameworks: enterprises struggle to build continuous offline testing harnesses, label domain-specific data, and monitor live models for drift. In response, AWS deploys Forward Deployed Engineers on targeted 45-day sprints to help internal enterprise teams establish production pipelines and achieve operational self-sufficiency. Addressing security and intellectual property concerns, Garman states that Amazon Bedrock enforces strict data boundaries, ensuring customer data remains isolated within their VPC and is never shared with third-party model providers or used to train foundation models. Simultaneously, AWS is leveraging frontier models defensively through Continuum, a security service that analyzes contextual IAM permissions and network topology to identify and remediate complex vulnerabilities at machine speed. Agent-First Development and Compressed Engineering Pods (51:33) Internally, Amazon rolled out Amazon Q across its global workforce, allowing departments such as HR and finance to automate cross-functional planning and regulatory compliance without waiting for developer resources. Software engineering velocity has seen the most dramatic acceleration, driven by internal "frontier teams" where autonomous agents write entire codebases under human supervision rather than simple inline code completion. This workflow shift is altering organizational structures across AWS. Product initiatives that historically required teams of ten engineers are now delivered by compact pods of three to four people. Garman notes that while these compressed pods substantially accelerate iteration cycles, management faces the emerging challenge of operating rapidly generated systems while dynamically rotating personnel onto new product problems. While Garman reports strong customer demand and enterprise ROI across AWS's cloud services, the platform's long-term scale depends on clearing persistent physical constraints in power, silicon packaging, and trade labor, as well as establishing reliable governance frameworks for workloads increasingly run by autonomous agents rather than humans.

## Background 本期内容由 a16z 官方频道于 2026 年 10 月 8 日发布在 YouTube 平台。视频中 a16z 的 Raghu Raghuram 深入对话 AWS 首席执行官 Matt Garman，围绕 AI 如何从底层重塑云计算基础设施展开，探讨了 AI 原生初创生态、面向智能体（Agent）的云架构升级、自研芯片布局以及亚马逊数百亿美元资本开支背后的长远考量。 ## TL;DR AWS CEO Matt Garman 全面阐述了 AWS 在 AI 代理时代的基础设施变革，重点说明了如何针对 Agent 工作流优化尾延迟、重塑 IAM 瞬态权限以及利用 Firecracker 微虚拟机打造轻量沙箱。面对行业极度的算力饥渴，AWS 坚决为初创公司锁定稀缺 GPU 配额，并通过高达 2200 亿美元的资本开支推动长达 20 年的电力基建与供应链长线统筹。与此同时，Garman 深入复盘了自研 Nitro、Graviton 和 Trainium 芯片的演进路径，并分享了 AWS 内部如何通过 Amazon Q 与“Agent 优先”的精简 Pod 模式实现研发效率的数量级跃升。 ## Atmosphere & style 整场对话兼具产业领袖的全局战略视野与工程老兵的务实硬核。Raghu 与 Garman 基于深厚的技术和行业背景谈笑风生，穿插着老派云计算竞争的幽默调侃，使高密度的干货输出毫不枯燥。Garman 展现出亚马逊标志性的坦诚与自我批判精神，既不避讳行业对数据中心建设的舆论误解和 AI 泡沫质疑，又对底层物理世界的算力与电力挑战保持着极度清醒的务实定力，让人深刻感受到技术巨头在时代剧变下的厚重底蕴与敏锐变革。 ## Bulletin - [00:55](https://www.youtube.com/watch?v=rn_afJaPldg&t=55s) AWS 当前年化收入达 1690 亿至 1700 亿美元且保持 37% 的高增速；到 2026 年亚马逊年度资本支出（CapEx）将攀升至创纪录的 2200 亿美元，并计划在未来数年采购多达 200 万张英伟达 GPU。 - [17:27](https://www.youtube.com/watch?v=rn_afJaPldg&t=1047s) 面对顶级前沿模型实验室（如 Anthropic、OpenAI、Meta）吞噬算力的现状，AWS 拒绝将产能倾销给单一巨头，而是通过强制预留专属配额保障 AI 原生初创公司的 GPU 供给。 - [24:43](https://www.youtube.com/watch?v=rn_afJaPldg&t=1483s) 数据中心扩容瓶颈已从单纯的服务器芯片演变为长达 20 年的能源基础设施竞赛，AWS 正在从依赖传统电网转向出资直建太阳能与核能电站的“自备能源”（Bring our own power）模式。 - [37:30](https://www.youtube.com/watch?v=rn_afJaPldg&t=2250s) AWS 自研芯片生态加速扩张：每年部署的 Graviton CPU 数量已超过其他 CPU，而第三代 AI 加速芯片 Trainium 3 产能已全部售罄至次年年底，且因独特的架构优势反向成为大模型推理的首选主力芯片。 ## Key takeaways - [02:51](https://www.youtube.com/watch?v=rn_afJaPldg&t=171s) 初创企业是推动 AWS 架构演进的核心引擎，其前瞻性需求通常领先银行与政企 5 年，目前 AWS 约 30% 至 40% 的营收来自伴随其一同成长的原初创公司。 - [07:24](https://www.youtube.com/watch?v=rn_afJaPldg&t=444s) AI 代理（Agent）的深度多步骤工具调用链对云底座提出了极苛刻的要求，系统尾延迟（Tail Latency）的微小卡顿会被级联放大，倒逼 AWS 针对代理逻辑深度重构存储与上下文层。 - [08:49](https://www.youtube.com/watch?v=rn_afJaPldg&t=529s) 为了适应代理编写代码并直接部署云资源的趋势，AWS 正在推出 30 秒内用 Gmail 即可开户、后台静默配置 VPC 与 IAM 默认值的极速无感上云体验。 - [12:26](https://www.youtube.com/watch?v=rn_afJaPldg&t=746s) 代理的瞬态生命周期颠覆了传统架构假设，催生出“时间窗口严格受限的瞬态权限模型”以及以 Firecracker 为代表的“极速启动安全轻量沙箱”等全新云原语。 - [20:43](https://www.youtube.com/watch?v=rn_afJaPldg&t=1243s) AWS 极高的客户分散度（最大单一客户营收占比仅为个位数）以及企业生产负载对计算、存储和推理的实质 ROI 需求，使其抵御所谓“AI CapEx 泡沫”的能力显著强于新兴算力云。 - [27:17](https://www.youtube.com/watch?v=rn_afJaPldg&t=1637s) 供应链管理遵循《目标》法则，瓶颈在电力、TSMC 先进制程、HBM、接插件等要素之间动态轮换，且算力需求具备极强的属地属性，无法简单通过跨区电力调配解决。 - [33:07](https://www.youtube.com/watch?v=rn_afJaPldg&t=1987s) 自研芯片战略脱胎于 13 年前突破虚拟化开销的痛点，从最初的网络卸载卡演变为 Nitro 裸金属架构，进而顺理成章地孵化出 Graviton 通用 CPU 与 Trainium AI 加速芯片。 - [40:06](https://www.youtube.com/watch?v=rn_afJaPldg&t=2406s) 企业在落地 Agent 时常陷入“机械复刻人类串行流程”的误区，必须转向“白板思维”，充分利用 Agent 大规模并行探索 50 种路径的超人类能力重构业务。 - [43:06](https://www.youtube.com/watch?v=rn_afJaPldg&t=2586s) 针对企业在 Agent 生产环境中的安全信任与 Eval（评估系统）能力缺失，AWS 推出 45 天 FDE 驻场赋能模式，以“授人以渔”的方式帮助企业建立自主掌控的评测闭环。 - [45:34](https://www.youtube.com/watch?v=rn_afJaPldg&t=2734s) 保护核心数据资产是企业落地大模型的底线，Amazon Bedrock 通过严格的 VPC 级别隔离保证数据不回传给模型厂商，而 SageMaker 则成为企业基于专有数据进行开源模型微调与蒸馏的核心底座。 - [49:28](https://www.youtube.com/watch?v=rn_afJaPldg&t=2968s) 面对新型机器级威胁，AWS 推出安全服务 Continuum，利用前沿模型理解客户云上拓扑与补偿性控制措施，以“机器速度”自动化评估并排期修复安全漏洞。 - [53:26](https://www.youtube.com/watch?v=rn_afJaPldg&t=3206s) 在内部软件工程变革中，AWS 工程师的角色已从逐行编写代码升级为“管理一个 Agent 团队”，驱动传统 10 人维护团队缩减为 3 至 4 人的轻量敏捷 Pod，实现研发交付的涡轮增压。 ## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=rn_afJaPldg&t=0s) 开篇：AI 代理与算力争夺战 在访谈开场片花中，AWS 首席执行官 Matt Garman 阐述了 AWS 在 AI 代理（AI Agents）架构上的原生优势：从计算沙箱（compute sandboxes）、网关到区分“代理 vs. 人类”的权限模型（agent permissions），AWS 已经并正在积极构建这些基础设施，使得代理式工作流在 AWS 上的运行表现普遍优于其他平台。与此同时，前沿大模型实验室正在吞食市场上所有可用的 GPU，而 AWS 必须在供给极度紧缺的局面下，刻意为初创公司锁定稀缺算力。Garman 透露，AWS 近期宣布将在未来几年内采购 200 万张 NVIDIA GPU，且 2026 年资本支出（CapEx）将高达 2200 亿美元，面对庞大的市场需求，这一扩张节奏短期内不会放缓。针对企业 CEO 们普遍关注的 AI 存亡风险以及 Hugging Face 攻击事件等安全话题，对话也埋下了探讨伏笔。 ### [00:55](https://www.youtube.com/watch?v=rn_afJaPldg&t=55s) 从 2006 年的第一美元到 1690 亿美元规模 主持人 Raghu Raghuram 回顾了 Matt Garman 在 AWS 的起点：2006 年，Garman 出任 EC2 的首位总经理（GM），亲历了业务从“拿到第一块钱收入”的阶段起步。时至今日，AWS 已发展成一家年化收入约 1690 亿至 1700 亿美元、年增速高达 37% 的云计算巨头。在如此巨大的基数下维持 37% 的增长，令 Raghu 直呼不可思议。 Garman 指出，尽管数字惊人，但从客户机遇和业务潜力来看，云计算实际上仍处于早期阶段。当今大部分工作负载依然运行在本地数据中心（on-premises），而全社会每天消耗的算力都在持续攀升。AI 带来的算力需求顺风与传统本地工作负载向云端迁移的浪潮相互叠加，为 AWS 提供了强劲且持久的增长动能。Raghu 幽默地插话称，自己过去在 VMware 竭尽全力想把客户留在本地，而 Garman 则笑称如今正在把当年 Raghu 留在本地的那些东西全面迁入 AWS。 - **业务规模**：AWS 当前年化收入达 1690 亿至 1700 亿美元。 - **增长速率**：在千亿级体量下保持 37% 的高速同比增长。 - **市场潜力**：全球海量 IT 工作负载仍停留在本地（on-prem），叠加生成式 AI 爆发，算力总需求远未见顶。 ### [02:51](https://www.youtube.com/watch?v=rn_afJaPldg&t=171s) 初创公司：AWS 的创新血脉与未来企业 回顾服务初创公司的历史，Garman 分享了一个趣事：2005 年他在商学院就读期间在 AWS 实习，当时 AWS 还是亚马逊内部的一个早期探索项目。他的实习课题是分析谁会成为 AWS 最具价值的核心客户，得出的结论正是“初创公司”。从正式上线的第一天起，初创公司就被确立为 AWS 的“命脉”（lifeblood）。 AWS 与初创公司的绑定不仅基于极具吸引力的基础设施与弹性定价，更在于全方位的赋能支持。AWS 不仅提供底层算力，还为创始人提供公司冷启动建议与可扩展的架构设计指导。从商业回报来看，Garman 估算，目前 AWS 约有 30% 到 40% 的收入来自在其生命周期中曾是初创企业的客户。初创公司会成长为未来的大型企业，更关键的是，他们是推动技术边界的创新先锋。与传统银行、医疗机构或政府部门相比，车库里的极客更早触及技术极限，不断向 AWS 提出更为苛刻的功能与性能需求，倒逼 AWS 提前 5 年为未来主流企业的需求做好架构准备。 ```mermaid flowchart LR accTitle: 初创企业驱动 AWS 创新的正向飞轮 accDescr: 展示初创企业向 AWS 输入前沿需求，推动底层架构创新，最终辐射并惠及主流大型企业的商业正向循环。 subgraph StartupCycle["初创生态推动力"] A["车库初创企业<br/>探索前沿场景与极限"] --> B["向 AWS 反馈苛刻需求<br/>(低延迟/高吞吐/新算力)"] end subgraph AWSPlatform["平台能力演进"] B --> C["AWS 快速迭代基础设施<br/>架构与安全能力升级"] end subgraph EnterpriseScale["商业落地与回流"] C --> D["企业级能力沉淀<br/>5年后满足银行/政企需求"] D --> E["初创成长为成熟企业<br/>贡献 30%-40% 平台收入"] end E -.-> A ``` - **历史渊源**：Garman 2005 年实习期间完成商业论证，确立初创企业为首要目标客群。 - **收入贡献**：估算当前 AWS 约 30% 至 40% 的营收直接来自伴随其一同成长起来的原初创公司。 - **技术牵引力**：初创团队总在探索最激进的用例，其前瞻性需求通常领先银行与政府机构 5 年左右。 ### [04:48](https://www.youtube.com/watch?v=rn_afJaPldg&t=288s) 新一代 AI 初创企业的剧变与不变 对比十几年前与当下的初创生态，Garman 指出了两项翻天覆地的变化： 1. **启动规模与资本体量急剧膨胀**：过去团队拿 1000 万美元融资慢慢打磨一款 App，如今很多项目仅凭一个创始团队和一个想法，第一天估值就高达 10 亿美元、手握 2 亿美元融资。Raghu 打趣称：“他们拿了 a16z 的钱就直接送去你们办公室买算力了。”模型训练与前沿 AI 研发极其昂贵，野心与资本门槛同步抬升。 2. **服务对象扩展到智能代理**：新一代团队不再只为人类工程师挑选云服务，他们需要一个“专门适配 AI 代理（Agents）而非仅供人类使用”的云基础设施。 然而，软件工程的基础规律依然保持不变。初创公司依然极其看重架构的扩展性、安全性、高性能以及完善的 IAM（身份与访问管理）权限设计。这也是初创团队没有彻底倒向新兴“新势力云”（Neoclouds）的原因——当团队规模超过三个人时，只有像 AWS 这样具备全套企业级合规、安全控制与稳定网络的基础设施，才能支撑起生产环境的长期运转。 ### [07:24](https://www.youtube.com/watch?v=rn_afJaPldg&t=444s) 为“代理原生”重塑云基础设施：上下文层与尾延迟 针对 Raghu 关于 AWS 是否推出了专门针对 AI 代理的新服务的提问，Garman 阐述了 AWS 的产品策略：既有构建代理的专用工具（如 Agent Core 与 Amazon Bedrock），也在全面针对代理的工作模式改造现有基石服务。以绝大多数企业存储数据湖的 Amazon S3 为例，人类和 AI 代理在数据检索和交互的逻辑上存在本质差异。 为此，AWS 正在公测名为 **AWS Context** 的全新上下文层服务。该服务允许企业在 Aurora、S3 以及各类数据湖之上架设统一的上下文层。人类用户很少会跨多个离散存储服务发起网状遍历，但 AI 代理非常热衷于在各类异构存储间自动化穿梭检索。此外，代理往往串联着深度的多步骤工具调用链，任何单一环节的迟滞都会被级联放大，这导致开发团队对底层算力引擎的吞吐量，尤其是“尾延迟（tail latencies）”，提出了人类交互时代从未有过的苛刻要求。 - **专属工具与基石升级**：提供 Bedrock、Agent Core 等编排服务的同时，改造 S3、Aurora 等核心存储底座。 - **AWS Context**：当前处于预览/测试阶段，跨异构存储构建统一上下文层，方便 AI 代理无缝索引与读取多模态数据。 - **性能敏感点转移**：AI 代理自动化流水线对系统的“尾延迟”容忍度极低，单点波动会造成下游代理决策链路严重积压。 ### [08:49](https://www.youtube.com/watch?v=rn_afJaPldg&t=529s) AI Agent时代下的云性能与极速上云体验 随着AI Agent（智能体）逐渐接管应用开发与系统管理，底层云基础设施的延迟指标被赋予了全新的意义。Matt Garman指出，人类开发者可能不会太在意S3存储桶的P99.9长尾延迟，但对于AI Agent来说，这种极微小的卡顿会直接造成阻塞，从而拖慢整个自动化执行流。正因AWS长期深耕并死磕此类极致性能瓶颈，Agent在AWS上的工作流表现往往显著优于其他平台。Raghu Raghuram随即提问：既然如今大量初创公司已完全由Agent负责编写代码、挑选数据库乃至配置邮件服务器，AWS那些历经十年沉淀的“传统（legacy）服务”是否正在经历重新架构？ Matt Garman回应称，AWS的核心底层构件依然非常扎实，目前正在发力的是易用性层（Usability Layer）。多数开发者会直接向Cursor、Claude或Codex等代码生成Agent提供AWS凭证并下达部署指令，Agent能够很好地执行；但在开发者尚未开通云账号、只想快速尝试部署的场景下，往往会选择转向上层封装更简单友好的生态伙伴平台。为了消除这一门槛，AWS正在逐步推出全新的简化注册机制： - **30秒无感开户**：新用户无需提前绑定信用卡，直接使用Gmail账号即可完成注册，不到30秒就能拥有一个功能完备的AWS真实账户。 - **免除初始化繁琐配置**：过去20年间必须手动配置的VPC（虚拟私有云）、IAM角色与权限等复杂设置，如今全部在后台静默完成默认配置，消除了Agent在部署初期被网络与权限门槛卡住的痛点。 - **平滑渐进扩展能力**：该方案并非阉割版的过渡账户，当项目逐步壮大需要组织管理、多账户协同和精细调优时，用户直接在原账户上扩展即可，完全省去了日后迁移数据的痛苦。 ```mermaid flowchart TD accTitle: AWS简化上云演进路径 accDescr: 展示从传统的复杂开户配置到新型Agent友好型无感开户与无缝扩展架构 subgraph Legacy["传统繁琐开通流程（20年惯例）"] L1["手动注册并绑定信用卡"] --> L2["手动规划与搭建 VPC 网络"] L2 --> L3["精细配置 IAM 角色与策略"] L3 --> L4["耗时耗力，Agent 易受阻"] end subgraph Modern["新型极速接入机制（Agent 友好）"] M1["Gmail 一键登录，无需信用卡"] --> M2["后台静默初始化 VPC 与 IAM 默认值"] M2 --> M3["30 秒内就绪，Agent 直接部署"] end Modern -->|"业务规模扩大"| Scale["原地无缝解锁企业级深度功能（无迁移损耗）"] ``` --- ### [12:26](https://www.youtube.com/watch?v=rn_afJaPldg&t=746s) Agent重构基础设施：短暂生命周期与全新原语 当AI Agent取代应用开发者、乃至逐渐取代底层运维（Infra）团队时，底层架构的本质假设正在发生深刻裂变。Matt Garman坦言，AWS的部分经典系统在Agent眼中甚至显得“有些过度工程化（Overengineered）”。例如，许多Agent在运行过程中只想临时创建一个数据库做少量任务，随后立即将其销毁；对于这种瞬态任务，传统生产级数据库如Amazon Aurora所执着追求的“5个9”（99.999%）持久性与高可用性就显得冗余而沉重。然而，AWS也不希望简单提供一个低可靠性的临时选项，因为系统很难预判某个临时创建的数据库未来会不会演变成核心业务资产。如何在极低开销、秒级创建和销毁的同时，保留其原地平滑成长为大规模持久生产系统的能力，是AWS当前正在攻坚的核心技术权衡。 除了对既有组件的改造，Agent的爆发还催生了一批前所未有的全新云架构原语（Building Blocks）： - **瞬态细粒度权限模型**：过去赋予具体员工或服务角色的IAM策略已不再适用。面对Agent，系统需要严格限制时间窗口（Time-boxed）的临时权限，且权限粒度必须精确到单次操作或特定数据，绝不能直接赋予某个工具的全量执行权。 - **轻量级安全计算沙箱**：计算虚拟化正在迎来新一轮复兴（Act 2）。传统大体积虚拟机的冷启动开销无法支撑Agent高频调用的需求，而AWS在约十年前自研并开源的Firecracker微虚拟机（MicroVM），凭借瞬时启动能力与极强的安全隔离边界，意外成为了当下大量沙箱初创公司构建Agent运行环境的黄金底层标准。 --- ### [16:24](https://www.youtube.com/watch?v=rn_afJaPldg&t=984s) 算力饥渴与GPU配额分配挑战 随着话题转向全球初创公司最为焦虑的核心痛点——“如何拿到GPU”，Raghu Raghuram指出，顶级的前沿大模型实验室（Frontier Labs）几乎吞噬了市场上所有可用的GPU算力，AWS内部如何平衡大客户胃口与未来潜在独角兽初创公司的算力配额，成为了一大难题。 Matt Garman承认，当前满足所有人计算需求所需的资本支出（CapEx）规模极其庞大，整个行业面临着严峻的物理与财务挑战。面对这种极度紧张的供需矛盾，AWS正努力在超大规模客户的吞吐需求与扶持新兴初创公司之间寻找平衡点。 ### [17:27](https://www.youtube.com/watch?v=rn_afJaPldg&t=1047s) 资本支出破纪录与算力分配难题 谈及资本支出规模，Raghu Raghuram 问及 AWS 的投资体量，Matt Garman 确认到 2026 年亚马逊的 CapEx 将高达 2200 亿美元。Garman 直言，这可能是单家公司有史以来单年最大的资本开支，但 AWS 完全没有放缓投资节奏的打算，因为市场需求实在太庞大。眼下制约扩张步伐的瓶颈随处可见：数据中心建设速度、资本投放效率、高带宽内存与芯片的供应，甚至连建筑工人都成了极度紧缺的资源。各类软硬件和人力瓶颈在不同时期交替出现。 在拼命扩充基础设施的同时，如何分配这些依然供不应求的宝贵算力，成了极其讲究策略的问题。AWS 拥有 Anthropic、OpenAI、Meta 等前沿大模型实验室（Frontier Labs），也有 Salesforce、摩根大通（JPMC）等传统企业客户——后者往往需要较小规模的 GPU 集群或自研加速芯片 Trainium。但 Garman 强调，AWS 拒绝把所有算力全盘卖给少数几家顶级实验室直接省事了事，而是特意为初创公司圈定了一块专属配额。因为健康多元的生态系统对 AWS 的长远发展至关重要，这些初创企业终将长成参天大树。目前面对客户纷至沓来的算力请求，AWS 最终能对大约 60% 的需求答复“可以”，不过可能伴随时间推迟、更换可用区域或微调硬件配置等妥协。 - **2026 年 CapEx 规划**：达到创纪录的 2200 亿美元。 - **采购规模**：未来几年内，AWS 计划采购多达 200 万张英伟达（NVIDIA）GPU。 - **初创企业算力保障**：拒绝将产能全部绑定于前沿实验室，为广大初创公司强制预留可用额度。 - **需求满足比例**：各类算力请求中约 60% 能以不同形式最终落地交付。 ```mermaid flowchart TD accTitle: AWS 算力分配战略与客户结构 accDescr: 展示有限的 GPU 与算力资源如何在三大客户群体之间进行平衡分配。 subgraph CapEx["核心算力供应池 (2200 亿美元 CapEx / 200 万张 GPU)"] GPU["NVIDIA GPU 集群"] ASIC["AWS Trainium 加速器"] end subgraph Allocation["算力分配策略"] direction TB L1["前沿大模型实验室\n(Anthropic, OpenAI, Meta)"] L2["大型传统企业客户\n(Salesforce, JPMC 等)"] L3["AI 原生初创公司\n(坚决保留专属份额以培育生态)"] end CapEx -->|"大批量核心基座训练"| L1 CapEx -->|"小规模微调与自研芯片应用"| L2 CapEx -->|"多区域/弹性配置，满足约 60% 请求"| L3 ``` --- ### [20:43](https://www.youtube.com/watch?v=rn_afJaPldg&t=1243s) AI 投资是否存在泡沫？以及 AWS 的抗风险底气 回顾资本开支的增长历程，Garman 坦言已很难确切记起 CapEx 是何时突破 10 亿或 100 亿美元关口的，但在过去三到四年中，伴随 AI 的爆发，整个投资曲线呈现出极为陡峭的加速。过去云计算赖以成名的“弹性供给”在暴涨的 GPU 需求面前几乎被打破，不过核心计算与存储资源的弹性依然稳固。 针对市场上关于“AI 资本支出泡沫”的普遍担忧，Garman 阐述了 AWS 底气十足的核心原因。首先是极高的客户分散度：不同于某些新兴算力云（Neoclouds）依赖一两家客户贡献 30% 到 60% 的收入，AWS 最大单一客户的占比仅为个位数的百分比，甚至更低，单客违约或流失风险极小。其次，AWS 是企业级核心生产负载（Production Workloads）的集聚地，当前绝大多数调用均集中于核心计算、存储以及与实际应用紧密绑定的推理环节（Inference）。企业客户普遍反馈，以当下的模型能力和成本，他们已经取得了确凿的正向 ROI（投资回报率），这些务实业务根本不会凭空蒸发。 Garman 借用风险投资和早期互联网的规律来对照当下的 AI 热潮：正如风投投 10 家公司可能只有 1 家跑赢并覆盖所有成本，或者互联网泡沫破裂淘汰了一大批公司但造就了 Google 和亚马逊一样，很多估值十亿美元的初创公司也许无法活下来，但这绝不意味着技术趋势本身是伪命题。拥有坚固商业模式的公司终将胜出。AWS 拥有无与伦比的全局视野，横跨全球各区域、各类企业级客户及大模型实验室，因此能够最先感知需求的风向标。 --- ### [24:43](https://www.youtube.com/watch?v=rn_afJaPldg&t=1483s) 电力与能源：基础设施规划范式的根本转变 随着资本支出从昔日的单笔千万美元激增至动辄上百亿美元，AWS 面临的长期规划与决策机制发生了翻天覆地的转变。最大的挑战在于：如何预测乃至保障 2028 年甚至更长远的需求？其中最为根本的分水岭是数据中心能源的获取模式。 Garman 回忆道，如果退回 15 年前，AWS 要是缺电，只需给当地公用电力公司打个电话，申请增加几兆瓦（MW）乃至几十兆瓦的供电配额即可，电网能毫不费力地直接供应。但如今，单点激增的负荷让传统电网不堪重负，AWS 必须转变为“自备能源”（Bring our own power）的模式。作为过去十年间全球最大的可再生能源采购商之一，AWS 正在直接资助和建设太阳能电站、核电项目以及各类清洁能源项目，全面介入表后（Behind the meter）及大型发电侧项目的落地。数据中心扩张的竞争边界，已经从单纯的芯片和机房采购，彻底延展为长周期的电力基础设施开发竞赛。 ### [25:57](https://www.youtube.com/watch?v=rn_afJaPldg&t=1557s) 电力基建与长周期供应链规划 Raghu Raghuram 询问 AWS 在电力获取上是直接投资电厂项目，还是与电网运营商合作。Matt Garman 表示 AWS 采取的是混合模式：既直接出资建设大型电力项目并并网获取额度，也根据实际情况采用“表后”（behind-the-meter）直供电方案。在这个庞大的体量下，AWS 必须制定长达 20 年的规划，覆盖电力来源、输电网络以及巨额资本开支，而这些是过去云计算业务完全不需要考虑的维度。 ```mermaid flowchart TD accTitle: AWS 电力与供应链规划流程 accDescr: 展示 AWS 如何从 20 年期电力布局与多年供应链规划转化为客户无需自建的云端核心价值 subgraph Power["长周期能源规划 (可达20年)"] P1["出资新建电厂并网获取额度"] P2["表后直供电 (Behind-the-Meter)"] P3["电网输电容量协调"] end subgraph Supply["供应链长线统筹 (跨数年)"] S1["2026-2028 硬件需求预测"] S2["内存/HBM/晶圆代工锁定"] end subgraph CustomerValue["客户价值转化"] V["免除底层基建焦虑<br/>专注于自身业务创新"] end Power --> CustomerValue Supply --> CustomerValue ``` 与电力规划类似，服务器硬件需求的预测周期也发生了翻天覆地的变化。过去 AWS 只需按季度预测需求并与供应商沟通，而如今必须提前数年规划 2026、2027 甚至 2028 年的需求。Garman 指出，这正是 AWS 为客户创造的核心价值所在：绝大多数企业根本无法亲自去跑电力谈判，也不可能预先规划 2028 年的内存采购量，AWS 承担了这部分极度复杂的重资产规划与执行工作。 ### [27:17](https://www.youtube.com/watch?v=rn_afJaPldg&t=1637s) 动态供应链瓶颈与《目标》法则 当 Raghu Raghuram 谈到 AWS 几乎是所有服务器零部件的最大采购商，并询问 2027 至 2028 年最严峻的供应链瓶颈会在哪里时，Garman 引用了本科时期读过的经典管理学著作《目标》（*The Goal*）。他指出供应链中“从来不存在单一的瓶颈，永远只有最新的瓶颈”。每当解决了一个瓶颈，下一个限制因素就会浮出水面。 对 AWS 而言，瓶颈处于月度轮转中：当月可能是电力短缺；电力问题一旦缓解，紧接着就可能是内存、TSMC（台积电）晶圆产能、HBM（高带宽内存）、网络元器件，甚至是供应链中某个小接插件的短缺。此外，容量并不完全具有通用互换性，区域分布同样至关重要——比如印尼可能有充足电力，但德国可能就极度受限。为了应对这些挑战，AWS 追踪着数十万种零部件，很多实行直接统筹管理，并且在十多年前泰国洪灾导致全球硬盘断供之后，就已将供应链预警体系下潜到四至五级供应商，全面推进生产制造的多元化布局。 - 瓶颈动态轮换：电力、台积电先进制程产能、HBM、高规格网络组件、接插件等交替受限。 - 地缘与区域差异：算力需求具有属地性，部分地区的电力盈余无法轻易填补其他地区的算力缺口。 - 深度供应链管理：建立深入 4-5 层供应链的追踪机制，吸取过去泰国洪灾硬盘危机与内存短缺的历史教训。 ### [30:22](https://www.youtube.com/watch?v=rn_afJaPldg&t=1822s) 数据中心的社会效益与行业反思 针对社会各界对数据中心建设的广泛争议，Garman 进行了坦诚的“内部反思”（vocally self-critical）。他承认云厂商在向公众解释“数据中心为何对美国和全球有益”方面做得不够主动和清晰。部分违规操作、不顾监管或匆忙上马的同行破坏了整个行业的公众形象，导致合规运营的企业也一同承受负面舆论。 Garman 强调，AWS 大力推行可再生能源，主要采用自然风冷技术，耗水量极低，并致力于实现“水资源正效益”（Water Positive）。此外，数据中心还为当地社区创造了高薪岗位与丰厚的税收。他分享了一个案例：在 AWS 运营的某个县，由于 AWS 缴纳的巨额税款，当地居民人均少缴 5,000 美元的税款，但居民对此完全不知情。由于数据中心带来的实惠隐形化，外界往往只看到一座庞大的建筑，却忽略了它支撑着流媒体等日常应用，并切实减轻了居民的税收负担。行业内部需要更多透明度，AWS 也计划更积极地发声，展现负责任企业的实际贡献。 ### [33:07](https://www.youtube.com/watch?v=rn_afJaPldg&t=1987s) 自研芯片之路：从虚拟化卸载到 Nitro 架构 在转向硬件底层创新时，Raghu 回忆起双方早期在 AWS Nitro 架构上的深度合作，并探寻 AWS 决心自研芯片的战略起因。Garman 表示，这是 AWS 坚持渐进式创新、小步快跑迭代直至做大格局的典型范例，其历程可以追溯到大约 13 至 14 年前。 当时，虚拟化技术对底层服务器物理资源造成的“虚拟化税”（性能损耗与开销）非常严重。面对客户对物理机级别（Bare Metal）极致性能的迫切呼声，AWS 没有一开始就尝试自研全套芯片，而是从最痛的点切入： ```mermaid flowchart LR accTitle: AWS 自研芯片与 Nitro 演进历程 accDescr: 展示 AWS 从网络卸载卡起步逐步演进至全面自研架构的历程 subgraph Step1["早期探索"] A["网络虚拟化卸载<br/>(网络卸载卡)"] end subgraph Step2["功能拓展"] B["存储虚拟化卸载需求<br/>(市场上无现有解决方案)"] end subgraph Step3["架构整合与自研"] C["研发定制芯片与 Nitro 架构"] D["迈向通用 CPU 与 AI 算力<br/>(Graviton & Trainium)"] end A --> B B --> C C --> D ``` AWS 首先利用网络卸载卡将网络虚拟化负荷完全剥离出去，使网络性能显著逼近物理机体验。这一尝试大获成功后，团队又设法将存储虚拟化开销同样剥离，但当时市场上根本没有任何现成的网络卸载卡能够同时兼顾这项需求。这最终倒逼 AWS 走上了自研定制芯片并打造 Nitro 架构的道路，进而为后续开发 Graviton（通用 CPU）与 Trainium（AI 训练加速芯片）奠定了硬件工程与底层虚拟化基础。 ### [034:44] 从 Nitro 架构到自研 CPU：Graviton 的诞生与规模化 AWS 自研芯片的征程始于对数据中心底层架构瓶颈的突破。Matt Garman 回顾道，团队当年发现了一家在硬件卸载卡（offload card）上配置 ARM 核心的创新团队（即 Annapurna Labs）。AWS 主动与对方展开深度迭代，探讨能否将存储虚拟化、网络虚拟化等繁重任务从主 CPU 剥离，转移到专用卡上执行。这促成了 AWS 对该团队的收购，并最终孕育出奠定 AWS 近十年底层竞争优势的核心架构——AWS Nitro。 ```mermaid flowchart TD accTitle: 从传统虚拟机到 Nitro 裸金属架构与芯片演进 accDescr: 展示虚拟化卸载促成 Nitro、Graviton 和 Trainium 的演化路径 subgraph OLD["传统服务器架构"] A["主 CPU"] --> B["虚拟机管理程序 / 资源损耗"] B --> C["用户业务 VM"] end subgraph NITRO["AWS Nitro 架构"] D["主 CPU 裸金属"] --> E["100% 算力归用户业务"] F["Nitro 卸载卡 (ARM 核心)"] --> G["接管网络与存储虚拟化"] F --> H["API 级隔离 / 零运维访问"] end subgraph CHIPS["芯片自研演进"] F --> I["Graviton (通用 CPU)"] I --> J["性价比优势: +20% 性能 / -20% 成本"] F --> K["Trainium (AI 训练与推理芯片)"] end ``` 通过 Nitro 架构，AWS 得以推出真正的裸金属（Bare Metal）服务器：主芯片上不再运行任何虚拟机管理程序，所有虚拟化功能完全通过专用卡上的 API 实现。这不仅大幅提升了计算性能与资源利用率，更在安全隔离上实现了质的飞跃——AWS 可以理直气壮地告知客户，云平台工程师在物理上完全无法访问运行在宿主机上的任何虚拟机。随后，团队萌生了更具颠覆性的想法：既然卸载卡上的 ARM 核心表现优异，为什么不直接用 ARM 做通用服务器 CPU？这推动了第一代 Graviton 的面世。尽管初期性能偏弱，但随着 AWS 押注 ARM 能效曲线的交叉点并大力推动软件生态成熟，Graviton 现已成为巨大的商业成功。 - **机队占比**：AWS 每年部署的 Graviton 芯片数量已超过任何其他类型的 CPU。 - **性价比优势**：在过去五到六年中，Graviton 持续保持比同代 x86 芯片“性能高出 20%，成本降低 20%”的固定优势。 - **顶级客户渗透**：AWS 排名前 100 的客户中，有超过 90% 已经在其机队中不同程度地使用了 Graviton。 - **降本实效**：转向 Graviton 是客户降低云账单最直接有效的手段；Matt Garman 指出，不少客户在全量迁移后，因性能大幅提升，直接将所需服务器节点总数缩减了一半，叠加单机单价更低的优势，带来了显著的成本效益。 --- ### [037:30] 押注 AI 定制芯片：Trainium 的产能告罄与“推理神卡”反转 大约在五六年前，AWS 预见到 AI 计算需求的激增，着手研发自研 AI 加速芯片 Trainium。如今，该产品已迭代至第三代 Trainium 3，并已对外公布了 Trainium 4 的路线图。Matt Garman 透露，由于市场反响极为热烈，Trainium 的可用算力目前已全部售罄，排期一直满载到次年年底左右。AWS 当前正在努力腾挪出部分稀缺容量，专门留给初创团队探索使用。在客户生态方面，除 Anthropic、OpenAI 等大模型领军企业外，已有十余家初创公司在基于 Trainium 构建核心业务，AWS 自身的 Bedrock 服务中绝大多数流量也在 Trainium 上运行。 在命名上，Garman 自嘲 AWS 具有“极为坦诚的自我批评精神”（vocally self-critical），坦言团队在产品命名方面“做得很糟糕”。最初，团队规划了用于推理的 Inferentia 和用于训练的 Trainium，但随着前沿基础模型体积指数级膨胀，行业发现极大规模模型的推理同样需要超大型系统的支撑。这导致 Trainium 反而成为了当前市场上在绝对性能与性价比两方面都极为强悍的“推理首选芯片”。 - **推理架构优势**：凭借独特的底层架构设计与极具竞争力的硬件成本，Trainium 在运行 Bedrock 等超大模型推理工作负载时展现了极高的能效比。 - **超大规模训练集群**：尽管广大企业客户目前的核心诉求集中于模型调用与推理，但头部客户对 Trainium 3 和 Trainium 4 在万卡训练集群方面的架构表现同样抱有极高期待，将其视为长期训练底座的关键支撑。 --- ### [40:06](https://www.youtube.com/watch?v=rn_afJaPldg&t=2406s) 大中型企业采用 Agent 的瓶颈：思维模式与自治信任 当谈及大中型企业对 AI Agent（智能体）的实际采纳节奏时，Matt Garman 指出，企业目前虽然已经从初代 Agent 中获取了实质业务价值，但绝大部分应用仍停留在相对初级、依赖“人机协同”（Human-in-the-loop）的非完全自主状态。阻碍企业进一步规模化落地 Agent 的主要障碍体现在两个核心维度： 第一，**业务流程的重构思维（Thinking from a Green Field）**。许多传统企业往往陷入“流程复刻”的误区——例如原本由员工鲍勃（Bob）按部就班执行步骤 1 到 5，企业便设计一个 Agent 去机械重复步骤 1 到 5，最后再让鲍勃审核。Garman 强调，企业必须向 AI 原生初创公司学习，彻底跳出人类解决问题的串行逻辑：Agent 的核心优势在于大规模并行探索，它可以同时尝试 50 种不同路径来寻求最优解。企业应当以“白板思维”从零构想计算机如何解决问题，而不是照搬旧的工作流。 第二，**从半自主走向全自主的“安全与信任屏障”**。像保险公司这类合规要求极高的企业，迫切希望借助 Agent 实现审批流程等核心业务的自动化，但要让 Agent 脱离人工审查、执行全自主操作，企业必须对底层系统的安全性、可控性和执行边界抱有绝对信任。AWS 当前正倾注大量研发资源，打造能让大中型企业放心交付自主权限的安全基础设施与平台级服务。 ### [43:06](https://www.youtube.com/watch?v=rn_afJaPldg&t=2586s) 企业落地 Agent 的安全顾虑与 45 天 FDE 赋能模式 企业当前在全面部署智能体（Agent）时表现得非常谨慎，而这种紧张情绪在 Matt Garman 看来完全是合情合理的。企业决策层最核心的担忧在于信任：如何确信一个 Agent 能够做出正确判断？如何为它设置正确的护栏（Guardrails）与数据访问权限？更重要的是，如何确保它不会误操作甚至在生产环境中铸成大错——比如意外删库。如果直接任由 Agent 在系统里“放飞自我”（"go nuts"）并不小心抹掉生产数据库，后果将不堪设想。为此，AWS 正在与客户紧密合作，一方面协助他们进行架构设计，另一方面也在研发底层的新技术与新功能，以彻底解决这一信任难题。 当被问及企业是否正在学会构建评估系统（Eval systems）来规范 Agent 时，Matt Garman 直言企业目前在这方面极其需要帮助。构建一个闭环的持续测试体系、以合理方式进行目标搜索（goal-seeking）、对数据进行合理标注以使评估能够真实映射生产场景，以及在生产中进行度量和回测以防止模型漂移（drift）——这些复杂的工程挑战，当前绝大多数企业根本不知道该如何应对，甚至可以说整个行业都还缺乏行之有效的方法。这也是为什么市场上涌现了大量前线部署工程师（FDE, Forward Deployed Engineer）团队。AWS 及其合作伙伴正全力加码 FDE 模式，但 AWS 的目标绝非建立传统咨询公司那种“按人头收费、永久绑定”的劳务生意。 AWS 推行 FDE 的核心理念是“授人以渔”。当进入一家准备好接盘的客户现场时，AWS 会展开为期 45 天的深入赋能：在这 45 天内，工程师与客户并肩作战，教会客户如何构建 Eval 系统、如何清洗和标注专属数据，并在项目完成时彻底离场交付。客户希望在 45 天后能够完全独立掌控系统，而不是在未来五年里始终受制于外部的外包顾问团队。 ```mermaid flowchart TD accTitle: AWS 45-Day FDE Enablement Lifecycle accDescr: 流程图展示了从企业痛点、45天驻场赋能到企业自主掌控智能体的全过程。 subgraph PainPoints["企业落地痛点"] A["生产安全顾虑<br/>(权限失控 / 误删数据库)"] B["缺乏评估能力<br/>(测试闭环 / 数据标注 / 漂移检测)"] end subgraph FDE["45 天 FDE 赋能周期"] C["与客户团队并肩作战"] D["构建 Eval 评估测试闭环"] E["规范数据标注体系"] end subgraph Goal["最终交付状态"] F["客户团队完全自主掌控"] G["摆脱外部咨询团队长期依赖"] end A --> C B --> C C --> D C --> E D --> F E --> F F --> G ``` --- ### [45:34](https://www.youtube.com/watch?v=rn_afJaPldg&t=2734s) 守护核心数据资产：Amazon Bedrock 与 SageMaker 的开源模型微调 业内曾有观点认为，企业不应将所有数据一股脑送进庞大的前沿基础模型中，而应采用开源权重模型并在企业私有数据、业务工作流与专有语料上进行后训练（Post-training）。Matt Garman 对此深表赞同，并强调企业数据是其“最具价值的资产”。这正是 AWS 最初设计 Amazon Bedrock 的根本逻辑：Bedrock 承诺客户的数据绝不会离开其私有网络（VPC），运行在 Bedrock 上的推理数据绝不会回传给基础模型提供商，模型厂商永远看不到客户的 Prompt。 Matt Garman 回忆道，大约三年前，AWS 因在生成式 AI 浪潮中行动较慢而饱受外界批评。但他强调，AWS 当时选择耐下心来打磨坚固的基础架构，而不是草率上线服务，目的是为了确保客户数据的绝对安全以及业务的长久可靠性。如今，随着客户项目从概念验证（PoC）阶段迈向正式生产，绝大多数工作负载最终都落在了 AWS 和 Bedrock 上，这也印证了当初技术路线的正确性。如今 Bedrock 业务正呈现爆发式增长，不仅支持开源权重模型与各类闭源前沿模型，甚至许多原本基于 OpenAI 的工作负载也在迁移至 Bedrock，Anthropic 模型的调用量同样在此快速攀升。 针对开源权重模型（Open weights models），Matt Garman 认为这也是一个令人兴奋的演进方向。许多企业坚信自身拥有极具价值的专有数据，如果能将这些数据通过后训练或微调（Fine-tuning）融入开源权重模型，并进行模型蒸馏（Distillation），就能以极低的成本获得表现更卓越的垂直模型。目前，大部分企业选择在 Amazon SageMaker 上完成这种自定义模型的构建、测试和推理托管。SageMaker 最初就是作为模型构建平台而生，如今在企业自建定制模型的浪潮中重新迎来了巨大的生命力。 - **VPC 级别数据隐私隔离**：在 Amazon Bedrock 中运行的全部数据与 Prompt 均受到隔离保护，绝不外流至模型供应商。 - **开放模型生态**：Bedrock 既支持封闭的前沿模型（如 Anthropic 的 Claude），也支持主流开源权重模型，同时提供灵活构建 Agent 的核心组件，客户甚至能在架构中接入外部模型（如 Gemini）。 - **SageMaker 承担定制重任**：企业利用专有数据对开源模型进行后训练、微调与蒸馏，目前大多依托 SageMaker 完成开发及后续的高性能推理托管。 --- ### [49:28](https://www.youtube.com/watch?v=rn_afJaPldg&t=2968s) 安全防线与用 AI 对抗 AI：Continuum 服务的安全创新 面对行业内关于 AI 潜在存在性风险（Existential risk）、软件供应链安全漏洞以及诸如 Hugging Face 安全事件的讨论，各家企业的 CEO 最关心的核心问题依然是：“当我部署这些 Agent 时，我如何确信它们只会执行我预期的动作？”为了保障 Agent 的安全受控，AWS 正在全方位构建企业级管控能力，涵盖了细粒度的权限分配、严格的沙箱运行环境（Sandboxing）、安全护栏机制，以及根据业务敏感度明确划定是否需要“人机协同”（Human-in-the-loop）。 与此同时，超大规模模型的强大能力也给安全防御带来了全新的维度。尽管强大模型可能被滥用为新型攻击面，但它同样能化身为极具破坏力的防御武器。AWS 近期推出了一项名为 Continuum 的全新安全服务，该服务直接调用顶尖的基础模型来协助客户保卫云上环境。 Continuum 能够深入分析客户的整个云端架构，利用前沿模型敏锐发掘此前未被察觉的安全漏洞。更关键的是，得益于 AWS 对客户环境拓扑、权限配置以及现有补偿性控制措施（Compensating controls）的上下文理解，Continuum 能够智能化评估攻击难度，并对漏洞修复的优先级进行精准排序。Matt Garman 表示，Continuum 自推出以来在客户群体中极受欢迎，AWS 对于利用 AI 反哺云安全的前景抱有极强的信心。 ### [51:33](https://www.youtube.com/watch?v=rn_afJaPldg&t=3093s) 机器级防御与 Amazon Q 的全员落地 在应对现代安全威胁时，传统的人工干预模式已经无法满足需求。Matt Garman 指出，客户迟早需要“机器速度”（machine speed）而非“人类速度”（human speed）的安全防御能力——过去那种系统触发告警、然后等待工程师手动排查的机制已经过时。为此，AWS 正在加速研发 AI 原生安全能力，以保护客户的云上环境，而内部的 Continuum 团队正是将 AWS 自身的实践向外输出的代表。AWS 内部早已在安全防御、软件开发以及日常运营中全方位重度使用 AI 和 Agent。 一个典型的例子是 Amazon Q（原转录误作 Amazon Quick）在亚马逊内部的全员普及。如今，亚马逊几乎将该工具推送给了每一位员工，这彻底改变了业务线员工的工作方式： - **人力资源（HR）团队**：以往需要整支团队耗时数周才能完成的团队规划与资源管理工作，现在单个 HR 借助自主构建的 Agent，仅需几个小时就能搞定。 - **财务团队**：利用 Agent 自动抓取并整合各地的税务法规，以确保不同业务板块的合规性。 - **业务自主创新**：过去严重依赖软件工程师排期、经常被技术资源卡脖子的业务线人员，现在能够通过 Agent 实现自我解绑（unblock themselves），直接推动业务创新。 这种赋能不仅在亚马逊内部蔓延，无论是小型初创企业还是全球超大型跨国机构，都在广泛推行 Amazon Q。企业只需将全量数据安全接入，即可通过 Agent 加速全员工作流。 ```mermaid flowchart LR accTitle: Amazon Q 赋能各业务部门 Agent 化 accDescr: 展示企业数据通过 Amazon Q 驱动 HR、财务与软件团队实现提速 subgraph DataLayer["企业核心底座"] DATA["企业级数据资产"] --> Q["Amazon Q 平台"] end subgraph BusinessTeams["业务赋能与 Agent 应用"] Q --> HR["HR 团队<br/>(规划/资源管理数周变数小时)"] Q --> FIN["财务团队<br/>(自动抓取税规/合规审查)"] Q --> DEV["研发团队<br/>(端到端 Agent 编码与发布)"] end ``` ### [53:26](https://www.youtube.com/watch?v=rn_afJaPldg&t=3206s) 软件工程变革：“管理 Agent 团队”而非代码补全 当 Raghu Raghuram 问及以严格度量运营指标著称的亚马逊在何处看到了最大回报时，Matt Garman 毫不犹豫地回答：“软件开发，这是最核心的答案。”他进一步强调，这种提速不仅体现在纯粹的编码阶段，更是贯穿了整个产品开发与上线生命周期。虽然 AWS 一向以功能交付神速著称，但在过去一年中，引入所谓“前沿团队”（frontier teams）后，产品迭代步伐更是迎来了“涡轮增压”（turbo boost）。 这种模式已经完全跨越了辅助性的代码补全阶段，演进为真正的“Agent 优先”（agent-first）： - 软件工程师不再逐行敲代码，代码几乎全部由 Agent 自主编写。 - 工程师的角色转变为“Agent 团队管理者”（managing a team of agents），专注于制定目标、拆解架构并统筹调度多个 Agent 协同作业。 - 研发效率呈数量级跃升，使 AWS 能够跟上外部客户对新功能“近乎贪婪的胃口”。 ### [54:36](https://www.youtube.com/watch?v=rn_afJaPldg&t=3276s) 敏捷 Pod 组织变革与播客收尾 随着 Agent 带来数十倍的效率飞跃，企业组织架构也面临着前所未有的重构压力。Garman 明确表示，在相当长的时间内人类依然至关重要，关于“人管 Agent 还是 Agent 管人”目前并没有标准答案，但 AWS 内部正在积极实验“轻量 Pod”运作模式。 以往在产品组织中，一项长期功能或模块往往需要设立一个大约 10 人的固定团队长期维护；而在 Agent 时代，仅需 3 到 4 个人就能以难以置信的速度完成同样的开发任务。随之而来的新挑战是：团队交付速度过快，管理层需要快速将他们调配到新的业务挑战上。如何在像 AWS 这样庞大的组织体量下，既做好存量系统的运营维护，又保持高度的灵活性和跨项目流动性，是他们正在深入探索的方向。一线员工对此反馈极度积极，因为开发瓶颈被打破后，他们能够以前所未有的速度把想法变为现实。 对话最后，Raghu 盛赞当下是一个激动人心的时代，感谢 Garman 的深度分享，并表示 a16z 会继续把被投的优质创业公司引荐到 AWS 生态中；Garman 也向 a16z 及其生态圈的创业企业客户表达了诚挚感谢，双方在融洽的气氛中结束了本次对话。 ## Notable quotes > [02:51](https://www.youtube.com/watch?v=rn_afJaPldg&t=171s) 初创公司是我们的命脉。从第一天起，我们就确立了这一点。 — Matt Garman > [03:20](https://www.youtube.com/watch?v=rn_afJaPldg&t=200s) 目前 AWS 约有 30% 到 40% 的收入来自在其生命周期中曾是初创企业的客户。 — Matt Garman > [04:00](https://www.youtube.com/watch?v=rn_afJaPldg&t=240s) 初创团队总在探索最激进的用例，其前瞻性需求通常领先银行与政府机构 5 年左右。 — Matt Garman > [17:27](https://www.youtube.com/watch?v=rn_afJaPldg&t=1047s) 到 2026 年，亚马逊的资本支出将高达 2200 亿美元。这可能是单家公司有史以来单年最大的资本开支，但面对庞大需求，我们完全没有放缓的打算。 — Matt Garman > [27:17](https://www.youtube.com/watch?v=rn_afJaPldg&t=1637s) 供应链中从来不存在单一的瓶颈，永远只有最新的瓶颈。每当解决了一个瓶颈，下一个限制因素就会浮出水面。 — Matt Garman > [35:00](https://www.youtube.com/watch?v=rn_afJaPldg&t=2100s) AWS 每年部署的 Graviton 芯片数量已超过任何其他类型的 CPU。 — Matt Garman > [35:30](https://www.youtube.com/watch?v=rn_afJaPldg&t=2130s) 在过去五到六年中，Graviton 持续保持比同代 x86 芯片‘性能高出 20%，成本降低 20%’的固定优势。 — Matt Garman > [44:40](https://www.youtube.com/watch?v=rn_afJaPldg&t=2680s) 客户希望在 45 天后能够完全独立掌控系统，而不是在未来五年里始终受制于外部的外包顾问团队。 — Matt Garman > [51:33](https://www.youtube.com/watch?v=rn_afJaPldg&t=3093s) 客户迟早需要‘机器速度’而非‘人类速度’的安全防御能力——过去那种系统触发告警、然后等待工程师手动排查的机制已经过时。 — Matt Garman > [53:26](https://www.youtube.com/watch?v=rn_afJaPldg&t=3206s) 软件工程师不再逐行敲代码，代码几乎全部由 Agent 自主编写。工程师的角色转变为‘Agent 团队管理者’。 — Matt Garman ## Mentioned Matt Garman, Raghu Raghuram, AWS, Amazon, a16z, EC2, Amazon S3, Amazon Aurora, AWS Context, Agent Core, Amazon Bedrock, Amazon SageMaker, AWS Nitro, Graviton, Trainium, Inferentia, Firecracker MicroVM, Continuum, Amazon Q, NVIDIA, Anthropic, OpenAI, Meta, Salesforce, JPMorgan Chase (JPMC), Cursor, Claude, Codex, Hugging Face, TSMC (台积电), Annapurna Labs, 《目标》（The Goal） ## Video description a16z’s Raghu Raghuram sits down with AWS CEO Matt Garman to discuss how AI is reshaping the cloud, from the needs of AI-native startups to infrastructure increasingly designed for agents. Matt explains how AWS is adapting as agents write code and manage infrastructure, why it’s reserving scarce GPU capacity for startups, and where custom chips like Trainium and Graviton fit into the AI stack. They also discuss Amazon's $220 billion capital investment, the shifting bottlenecks in the infrastructure buildout, what enterprises need to trust autonomous agents, and how AWS's own teams are building with agents. Timestamps: 00:00 - Intro 00:55 - $169B, growing 37% 02:51 - Why startups are the lifeblood 12:26 - Rethinking cloud for agents 16:24 - The GPU allocation problem 21:27 - Is the AI CapEx a bubble? 30:22 - Clearing up data center myths 33:07 - The Graviton and Trainium bet 40:06 - Where enterprises are stuck on agents 45:43 - AI risk, Hugging Face, and Continuum Resources: Follow Matt Garman on X: https://x.com/mattsgarman Follow Matt Garman on LinkedIn: https://www.linkedin.com/in/mattgarman Follow Raghu Raghuram on X: https://x.com/RaghuRaghuram Learn more about AWS: https://aws.amazon.com/ Stay Updated: If you enjoyed this episode, be sure to like, subscribe, and share with your friends! Find a16z on X: https://twitter.com/a16z Find a16z on LinkedIn: https://www.linkedin.com/company/a16z Listen to the a16z Show on Spotify: https://open.spotify.com/show/5bC65RDvs3oxnLyqqvkUYX Listen to the a16z Show on Apple Podcasts: https://podcasts.apple.com/us/podcast/a16z-podcast/id842818711 Follow our host: https://x.com/eriktorenberg Please note that the content here is for informational purposes only; should NOT be taken as legal, business, tax, or investment advice or be used to evaluate any investment or security; and is not directed at any investors or potential investors in any a16z fund. a16z and its affiliates may maintain investments in the companies discussed. For more details please see http://a16z.com/disclosures. [Source](https://www.youtube.com/watch?v=rn_afJaPldg)

[2:51] Matt Garman: 初创公司是我们的命脉。从第一天起，我们就确立了这一点。 [3:20] Matt Garman: 目前 AWS 约有 30% 到 40% 的收入来自在其生命周期中曾是初创企业的客户。 [4:00] Matt Garman: 初创团队总在探索最激进的用例，其前瞻性需求通常领先银行与政府机构 5 年左右。 [17:27] Matt Garman: 到 2026 年，亚马逊的资本支出将高达 2200 亿美元。这可能是单家公司有史以来单年最大的资本开支，但面对庞大需求，我们完全没有放缓的打算。 [27:17] Matt Garman: 供应链中从来不存在单一的瓶颈，永远只有最新的瓶颈。每当解决了一个瓶颈，下一个限制因素就会浮出水面。 [35:00] Matt Garman: AWS 每年部署的 Graviton 芯片数量已超过任何其他类型的 CPU。 [35:30] Matt Garman: 在过去五到六年中，Graviton 持续保持比同代 x86 芯片‘性能高出 20%，成本降低 20%’的固定优势。 [44:40] Matt Garman: 客户希望在 45 天后能够完全独立掌控系统，而不是在未来五年里始终受制于外部的外包顾问团队。 [51:33] Matt Garman: 客户迟早需要‘机器速度’而非‘人类速度’的安全防御能力——过去那种系统触发告警、然后等待工程师手动排查的机制已经过时。 [53:26] Matt Garman: 软件工程师不再逐行敲代码，代码几乎全部由 Agent 自主编写。工程师的角色转变为‘Agent 团队管理者’。

[2:51] Matt Garman: The startups are the ones that are pushing that envelope. And it really helps us to be better and make sure that we're ahead of that wave where the banks are going to want some capability 5 years down the road that startups want today. [4:53] Matt Garman: Now it's like from day one they're valued at a billion dollars, they have $200 million of funding... they just go from our offices to your offices. [8:49] Matt Garman: They don't always care about the P99.9 S3 latency, like agents do care and get blocked by that. [12:26] Matt Garman: Many agents want to create a database, do a little bit of work, and then have the database go away. Do you really need that database to have five 9s of durability? [12:26] Raghu Raghuram: virtualization is having its act two [21:04] Matt Garman: You go talk to the customers and you say at the capability today and the cost today are you seeing positive returns to your business and almost to a person they'll say like 'oh yeah' and so you're like well that's not going to go away there's no bubble in which they stop spending on that. [37:30] Matt Garman: terrible at naming [51:33] Matt Garman: machine speed, not at human speed [53:25] Matt Garman: turbo boost [53:25] Matt Garman: insatiable appetite for new capabilities.

[0:00] Agentic workflows tend to perform better [0:01] on AWS than anywhere else. Compute [0:03] sandboxes, gateways, agent permissions [0:06] versus people. A lot of those are things [0:08] that we have built and are building and [0:10] thinking actively about. [0:11] >> The top frontier labs gobble up every [0:13] available GPUs. At the same time, you [0:15] want to promote newer companies that are [0:17] going to become the enterprises of [0:18] tomorrow. How are you thinking about [0:20] balancing? [0:20] >> From the very beginning of when we [0:22] launched AWS, startups have been the [0:24] lifeblood of the core of what we do. [0:25] These are the innovators that are at the [0:27] edge of technology understanding what's [0:29] possible. We're very intentional about [0:30] keeping capacity available for the [0:32] startups. We recently announced we're [0:33] going to be buying 2 million NVIDIA GPUs [0:36] over the next couple of years. [0:37] >> Your capex is what 200 or [0:39] >> $220 billion uh for 26 and we don't [0:43] anticipate slowing down anytime soon [0:45] because the demand is just massive. [0:46] >> With all the debate around AI extension [0:49] risk and the hugging face attack, what [0:50] are CEOs asking you about all these [0:52] things? [0:55] Welcome to the podmat. What a time we're [0:58] living in. So I have a lot of topics to [1:00] talk to you about. [1:01] >> Awesome. Thanks for having me. I'm [1:02] excited. [1:03] >> Yeah. Yeah. Absolutely. So let's start [1:06] actually right from the beginning, [1:08] right? So you are the first GM for EC2. [1:13] >> Mhm. [1:14] >> And that was 2006, right? And today you [1:18] guys are what 160 170 billion in [1:20] revenue. [1:20] >> Yeah. About 169 170 billion. Yep. [1:23] >> Yeah. growing 30 [1:25] >> 37 37%. [1:26] >> That's 37% at 169. [1:29] >> Yeah, it's that's crazy. [1:30] >> There's a ton of o and it's Yeah, it's [1:32] it's it's interesting to think about it [1:33] from, you know, we're there in day day [1:35] day one when we had like, you know, the [1:37] first dollar of revenue, but um [1:39] >> yeah, and it's, you know, the [1:40] interesting thing is we're still at the [1:42] early stages of what the business can be [1:44] and what the opportunity is for [1:45] customers. um most workloads still, you [1:48] know, there's a huge amount of workloads [1:49] still that live on prem today and the [1:52] amount of compute um that people are [1:54] doing every single day is is more than [1:56] it was the day before. And so you see [1:58] the tailwind from AI, you see the [2:00] tailwind from migration into the cloud [2:02] and um you know the the business has [2:04] grown really fast and it's it's been a [2:06] super fun part to be a um thing to be a [2:08] part of. [2:09] >> Yeah, it is. It is. I mean they'll be [2:11] writing uh history books about this and [2:13] business books about this for a long [2:15] time to come. I want to touch on the on [2:18] prem that sort of boggles my mind. I [2:21] obviously did my best to keep them there [2:22] for a long time. [2:23] >> You built a lot of stuff on prem back in [2:24] the day of trying to now get all of that [2:27] to move into AWS. [2:28] >> Yeah. So we can talk about that later. [2:30] But uh so if you think about EC2 in the [2:33] early days and you got your start with [2:35] obviously selling to startups and and [2:38] today the AWS cloud service [2:41] I mean as you reflect on the evolution [2:44] what's what stands out. [2:45] >> Yeah. [2:46] >> Part one and then part two we'll talk [2:47] about how this nature of how you serve [2:50] startups has changed. [2:51] >> Sure. Well like you said actually it's [2:55] funny. So I actually interned for um AWS [2:58] in 2005 when we were first kind of was [3:00] an internal project. It was my business [3:02] school internship and my project was [3:03] actually to come up with uh an analysis [3:06] of who we thought AWS would be most [3:08] interesting to and uh the the answer was [3:10] startups like probably not surprisingly [3:13] and uh and so you know from the very [3:15] beginning of when we launched AWS [3:16] startups have been the lifeblood of of [3:19] the core of what we do for for a number [3:21] of reasons. One is the value proposition [3:22] is just so attractive what AWS provides [3:24] to startups. [3:26] >> Um and and we we spend a lot of time and [3:28] effort making sure that we're great [3:29] partners to the startups helping them [3:31] not just provide infrastructure but also [3:33] advice and how to get your company up [3:34] and running and how to think about your [3:35] architecture so it'll scale eventually [3:37] and and a whole bunch of things that we [3:38] do for the startups. But we also think [3:40] that for us it's just good business cuz [3:43] >> the startups today are the enterprises [3:44] of tomorrow and and you know it's it's [3:46] an imprecise number but [3:48] >> today we estimate that you know maybe 30 [3:50] 40% of of AWS revenue comes from [3:54] companies that well there's a one-time [3:56] you know startups in in AWS's lifetime. [3:58] So and it's uh you know and so it's fun [4:00] to see for us to see the companies grow [4:02] over time and and to get bigger and [4:04] become enterprises effectively. Um, and [4:07] so that's why we invest so much in [4:08] startups and why we pay so much [4:09] attention to the the brand new, you [4:12] know, two people in a garage type [4:13] startups. And um, and and not um, and [4:16] and not just because of the business [4:17] outcomes, but also because that's who we [4:19] learn from. These are the these are the [4:21] innovators that are at the edge of [4:23] technology, understanding what's [4:24] possible, uh, pushing our services to [4:27] say what they'd want more of, what could [4:28] help them go faster, what could help [4:30] them achieve their uh, outcomes. And a [4:33] lot of times they're pushing more than [4:35] the the banks or the healthcare [4:36] companies or the governments. The [4:37] startups are the ones that are pushing [4:38] that envelope. And it really helps us to [4:40] be better and make sure that we're ahead [4:42] of that wave where the banks are going [4:44] to want some tech some capability 5 [4:46] years down the road that startups want [4:47] today. [4:48] >> Yeah. Yeah. And uh compared from then to [4:53] now [4:55] what have the how have the startups [4:57] changed and what they want from you? [4:58] Obviously [4:59] >> they all want a lot of GPUs and we can [5:01] talk about that but besides that [5:03] >> well I will say uh there's a couple of [5:06] things that have changed. One is um you [5:08] know startups started at a much smaller [5:10] size than than when when when we first [5:12] started right they they might have [5:14] gotten $10 million of funding and they [5:16] had a app idea that they were kind of [5:18] slowly iterating on. Now it's like you [5:20] know from day one they're valued at a [5:22] billion dollars they have $200 million [5:24] of funding. [5:25] It's like it's a, you know, it's a a a [5:28] team and an idea and all of a sudden [5:30] they're worth a billion dollars which um [5:32] so it's you know I think the [5:33] >> they just go from our offices to your [5:34] offices. [5:35] >> That's right. That's right. Um uh and [5:38] you know like the the size and scale and [5:39] ambition of the ideas I think requires [5:41] more capital. They're they're bigger to [5:43] start with. Um they're obviously more [5:44] expensive too, right? To you know to um [5:47] uh to go after kind of a training a [5:49] model or doing something that that a lot [5:50] of the folks are doing today. Um, so [5:52] that's number one, which is just the [5:54] size that they're that that they start [5:55] from is is really big. Um, but I would [5:58] say number two is uh some things haven't [6:01] changed, right? They they actually are [6:03] still thinking about, okay, once I [6:05] scale, how do I think about an [6:07] architecture? Um, how do I think about [6:10] um [6:11] security? How do I think about [6:13] performance? How do I think about having [6:15] all the capabilities that I need? How do [6:16] I think about setting up my IM setup so [6:19] that when I have more than three [6:21] employees, this thing is going to work [6:22] and scale, which is a lot of times why [6:24] they like AWS as opposed to just, you [6:26] know, going to a Neocloud or something [6:28] like that. They actually need the all of [6:29] those other security and and um and [6:31] capabilities that that come around from [6:34] um from training. Um and so I think [6:36] that's that's you know that's something [6:38] that hasn't changed and and is exactly [6:39] the same. I think the the scale at which [6:41] the ramp up um is definitely different [6:43] today. I also think increasingly we're [6:45] seeing um teams that want a cloud that [6:50] is great to work with agents and not [6:53] just with people. Um and I think that's [6:54] where we've spent a lot of time how do [6:56] you think about you know exactly how do [6:59] you think about broad scale? How do you [7:01] think about performance? How do you [7:02] think about um you know an interface [7:05] that is you know a well- definfined API [7:07] interface that agents can actually [7:08] easily traverse and work across. Um, and [7:11] so that's also something that we both I [7:13] think we were naturally set up to do [7:14] well, but that we've actually doubled [7:16] down on to ensure things like, you know, [7:17] how can you start a database in 3 [7:19] seconds and and and and really get to um [7:22] some capabilities that agents are [7:23] excited about? [7:24] >> Um, I should have looked, but I haven't [7:27] lately. Have you introduced [7:29] any specific new services that are [7:31] explicitly targeted at agents or people [7:35] building agents? I I'd say what we've [7:36] done is we've optimized some existing [7:38] services that that so that they can both [7:41] work for people and agents and it it [7:43] because you know sometimes um and and so [7:45] the answer is there we definitely have [7:47] some services designed for building [7:49] agents. So we have things like agent [7:51] core and um and bedrock and pieces like [7:53] that. But when we look at just taking an [7:55] underlying component like S3, right, [7:57] which is where the vast majority of [7:59] companies store their data and have [8:00] their data links. Um it turns out like a [8:04] lot of the use cases for people and [8:05] agents are similar, but you want to have [8:08] um and one of the things that we have in [8:09] preview right now or in in beta. It's [8:12] called AWS context that allows you to [8:14] build a context layer so that agents can [8:16] actually more easily find all of the [8:18] data they want across your various data [8:20] links. Um and so whether you have your [8:21] data stored in um Aurora or you have it [8:24] in S3 or you have it in somewhere else [8:25] in AWS can kind of build this context [8:27] layer where when people aren't [8:29] necessarily going to access data in that [8:31] way but agents actually are happy to go [8:33] across lots of those different things. [8:34] And so there are some services that [8:36] we're building like that but for the [8:37] most part you also care about what does [8:39] latency look like, what does throughput [8:40] look like, how do you make sure that the [8:42] underlying engine is actually fast, [8:44] scalable, um that they actually care a [8:46] lot about tail latencies which is [8:47] interesting. um where people are not [8:49] they don't always care about the the [8:51] P999 S3 latency like agents do care and [8:54] get blocked by that and so [8:56] >> um that's the thing that we've cared [8:57] about for a long time and um from a [8:58] performance perspective it's one of the [9:00] things that um that really popped that [9:01] that's why um aentic workflows tend to [9:04] perform better on AWS than anywhere [9:06] else. Yeah, obviously we see um a lot of [9:10] companies starting out and the very [9:13] common refrain of course is that uh [9:15] agents are writing all the code for [9:17] them, right? [9:18] >> And agents are selecting the databases [9:20] and [9:21] >> the email servers and everything that [9:23] you can name it, right? So has there [9:25] been a lot of uh thinking that and [9:27] obviously they read the documentation uh [9:30] has there been a lot of thinking on the [9:32] AWS like your [9:35] feels funny to say quote unquote legacy [9:38] services that have been around for a [9:39] decade on how do you rearchitect them. [9:42] >> I think there so yes I think there are [9:44] some things that we've thought about [9:45] actually the core underlying building [9:46] blocks I think are in in really good [9:48] shape. I think there's a usability layer [9:50] um that we're thinking about of how we [9:51] make um easier to use for we'll call it [9:54] like the very simplest the the the use [9:56] case you call out where somebody's just [9:58] coding up an app really quickly and they [9:59] ask it to deploy. We we find the vast [10:02] majority of our customers will go and [10:03] tell their coding agent whether it's [10:05] Kira, whether it's Claude, whether it's [10:07] uh Codeex, they'll they'll say like, I [10:09] want to build on AWS, here's my [10:11] credentials, here's my stuff. This is [10:12] how I want to deploy it. And then the [10:14] agents are great and they go do it. [10:15] There are use cases though where you're [10:17] just you're already not on a cloud, [10:18] you're just trying something. You say [10:19] deploy. And frankly, a lot of times [10:21] that'll go to some of our partners that [10:22] have a an easier to use layer on top. [10:25] >> Um which we which we love, by the way, [10:27] too. and we love um our partners on on [10:29] those fronts too. Um but I do think that [10:32] there um there are some things that [10:34] we're doing where if you're brand new, [10:36] you don't already have an AWS, you [10:37] already haven't set up your IM. Um today [10:40] or we'll say a couple of months ago, it [10:42] was much harder to start up an account, [10:44] right? You had to it's been like this [10:45] for 20 years, but you have to define [10:47] your VPCs, you have to define your IM [10:49] roles, all these kind of things, which [10:51] are actually super important things once [10:53] you get to be large. Um, and what we [10:55] hear from customers is like it was a [10:57] hard trade-off because they know that [10:58] they're going to want those n months or [11:00] years down the line, but for now they [11:02] just kind of want to use the services, [11:03] not worry about that. [11:05] >> Um, and so what we've actually launched [11:06] is if you go create a new AWS account [11:08] today, [11:09] >> and we're slowly rolling this out. I [11:11] don't know if it's actually full all the [11:12] way out yet now, [11:13] >> but um, you don't have to do those [11:15] things. You don't have to give it a [11:16] credit card. You can sign up with your [11:17] Gmail account. um you get to just all of [11:19] those things are handled in default [11:21] behind the scenes and within less than [11:22] 30 seconds you're up and running and can [11:23] be and can be operating in AW full AWS [11:25] account which is you know for those type [11:27] of systems much more what the agents [11:30] want to be able to do because they don't [11:31] want to have to go through all that [11:32] setting up your VPCs and your [11:34] >> um uh and and pieces like that. So there [11:37] are some things where we're adding kind [11:38] of some ease of use to that which we're [11:40] we're quite excited about and I've seen [11:42] some really positive feedback from [11:43] customers on and and we'll keep doing [11:45] more things like that over time. [11:46] >> And I and just one more thing that which [11:49] is the the the great part about that [11:50] though is it's not like a a simplistic [11:52] account and then you have to migrate. If [11:54] you basically say okay now I actually do [11:56] want to scale into the or I want to [11:58] develop an organization. I want to go [12:00] and and kind of fine-tune some of the [12:02] things. you can easily come just you're [12:04] you're already in a real AWS account and [12:05] you can actually then go and do all of [12:07] those things later when you need them [12:08] and so there's no migration or move [12:10] later and so that's part of the hard [12:12] work that we really think about which is [12:13] how do we make it not a choice for the [12:15] customer but an easy on-ramp into the [12:17] depth of features that we know customers [12:19] um and startups are going to want when [12:20] they start scaling. [12:21] >> Yeah. Yeah. Got it. And um [12:26] what has been some of the hardest things [12:30] to accommodate as agents have taken [12:32] over? I mean you made a name. [12:34] >> This is the way you guys became the [12:37] phenomenon that you became was serving [12:39] developers, right? [12:41] >> Um and then uh infra teams u now [12:45] developers are substituted by agents and [12:47] pretty soon infra teams are being [12:49] substituted by agents. [12:50] >> Yeah. Are there what has been some of [12:53] the hardest things for you [12:55] as the largest service provider in the [12:57] world [12:58] >> to handle that transition? [13:00] >> Well, I you know look I think um like I [13:02] said much of our infrastructure was is [13:05] >> yeah pretty well set up to handle the [13:08] scale um which is good. I I think [13:10] there's been a couple of things which [13:11] are interesting which are I think [13:13] interesting paradigm shifts where um you [13:16] could argue that some of our systems are [13:19] um I wouldn't say overengineered but um [13:23] as an example many agents want to create [13:26] a database uh do a little bit of work [13:28] and then have the database go away. You [13:30] really need that database to have 59s of [13:32] durability. Exactly. Right. And so [13:34] there's some things that we rethink [13:35] there where when you're creating an [13:37] Aurora database like as your production [13:38] database like you do want five ends of [13:41] data, you know, you want you you need [13:42] durability, you want availability, you [13:44] want all of those things. And for the [13:46] agent use case, that's that's arguably [13:48] or maybe not arguably like [13:49] overengineered for for what we need. And [13:51] so, you know, it's hard. We don't um and [13:55] we kind of have this this uh [13:58] um a belief that we don't we don't [14:00] really want to have like a non-durable [14:01] option that's that's going to cause [14:03] problems either cuz you never really [14:05] quite know if the database that's [14:06] created is wants to stay around for a [14:07] long time or a short amount of time. And [14:08] so we're we're um trying to do the hard [14:11] work to think about how do you [14:12] accomplish both of those things where [14:13] you can create it quickly and throw it [14:15] away and you don't really waste a lot of [14:16] resources. But um but um but if you do [14:19] want it and it can be durable and stay [14:20] for a long time, it actually grow into a [14:22] big production database. So those are [14:24] some trade-offs that we think about [14:25] actively as we think about how does the [14:27] the the more traditional kind of this is [14:29] going to be my production system kind of [14:31] capabilities um match with uh with with [14:35] some of the more transient nature of the [14:37] infrastructure that agents uh want to [14:39] use. Um, so that that's one I think, but [14:41] there's there's there's a bunch. I think [14:43] the um scale and speed and latency of [14:46] creation of of durable resources is [14:48] another one that's interesting. Um, you [14:50] know, I think the other one that we [14:51] actively think about too is just are [14:53] there new building blocks that agents [14:55] are going to want that we just didn't [14:57] really need before. Exactly. And so [14:58] compute sandboxes, [15:00] um, uh, gateways, um, agent permissions [15:03] versus people or or or service role [15:06] permissions, um, a lot of those are [15:08] things that we have built and are [15:09] building and thinking actively about cuz [15:11] they are just brand new building blocks. [15:12] It's not using the existing building [15:14] blocks differently, but it's brand new [15:15] ones where pretty pretty clearly you [15:18] want a different permissions for agents. [15:20] You don't just want to give it Ragu's [15:21] permissions and let it go do whatever [15:23] you can do. you actually want um you [15:26] know very time box short-term [15:27] permissions to just go do a task. You [15:29] actually may not want to give [15:30] permissions to a whole tool at all. You [15:32] may want to get very fine grain [15:33] commissions what an agent's able to do [15:35] >> from a sandbox, right? You actually want [15:37] a sandbox that um uh you want to [15:41] >> virtualization is having its act too. [15:43] >> That's right. Exactly. That's and and [15:45] they're they're different. It's similar. [15:47] It's the same idea, but it's, you know, [15:48] how do you have that lightweight and and [15:49] think about um unfortunately we've done [15:51] a lot of work with um firecracker or our [15:54] kind of microVMs. [15:56] >> In fact, a lot of the sandbox company [15:57] startups use fire. [15:59] >> They all use fire which which we [16:00] invented 10 years ago maybe or something [16:02] like that. And it's it's it's really [16:04] purpose-built for I mean it's not wasn't [16:06] purpose-built for agents, but it's [16:07] actually quite good for agents because [16:09] you can spin them up really rapidly. [16:10] they have a great security boundary um [16:13] and you don't have a lot of that [16:14] virtualization overhead that you have [16:16] from a traditional large VM. Um, so you [16:18] know, I think those are some some new [16:19] building blocks that we're thinking [16:21] about and um and more emerge every [16:22] single day, you know. Yeah. And [16:24] >> yeah, [16:25] >> so I've rattled enough into agents. I'll [16:27] come back to it later, but it's a [16:28] fascinating topic. [16:29] >> Super cool. [16:30] >> But uh let me switch gears a little bit [16:32] and ask about something that uh every [16:36] one of our startups face and we get [16:38] asked most frequently [16:40] >> which is how can we get GPUs, right? [16:43] >> Yeah. I mean obviously you guys have [16:45] running massive GPU farms and increasing [16:49] it every day [16:51] but uh the top frontier labs gobble up [16:54] every available GPUs more power to them. [16:57] >> How do you deal with the internal at the [16:59] same time you want to promote newer [17:01] companies that are going to become the [17:02] enterprises of tomorrow like you said [17:04] >> um how are you thinking about balancing [17:06] >> yeah it's capacity needs and these small [17:09] companies that don't have a lot of [17:10] credit and whatnot. So, well, yeah, it's [17:13] a great question. Um, and and a couple [17:15] of these things make it more challenging [17:17] to one is um the the capex expense [17:20] needed to go deploy kind of all of the [17:23] compute that everyone needs right now um [17:25] is massive, right? And so we are uh I [17:27] think [17:27] >> your capex the same as what 200 or [17:29] something [17:30] >> $220 billion uh for 26. It's uh I I by [17:35] by at one point I saw that it's you know [17:37] it's it's a pretty I mean that is a [17:38] larger expense than we've ever had maybe [17:40] any company has ever had in a in a [17:42] single year. Um and um and we don't [17:45] anticipate slowing down anytime soon [17:46] because the demand is just massive. And [17:49] so at some point you're limited by how [17:50] fast can you build data centers, how [17:52] fast can you deploy capital, how how [17:54] fast can you get memory and chips and [17:55] all of those kind of things. Um and so [17:57] all of those are at different points [17:58] constraints that we're you know whether [18:00] it's power data centers capital memory [18:03] chips they're all kind of constraints at [18:05] various times construction people to [18:06] build buildings like you know [18:08] construction people are are at a premium [18:10] today. [18:10] >> Um and so all of those we you know we we [18:12] work really hard to make sure happen. Um [18:14] and then with the capacity that we are [18:16] able to deploy, which is still a huge [18:18] amount and and and not enough, we know, [18:20] um we really think intentionally about [18:22] what is that allocation strategy. And [18:23] so, um we're great partners with the the [18:26] large frontier labs, the Anthropics and [18:28] OpenAIs and and Meta and and other large [18:31] customers. And so those folks are are [18:32] really good customers of ours. [18:34] >> Yep. [18:34] >> And uh and we want to make sure that we [18:36] invest in them. we have large enterprise [18:38] customers whether it's uh sales forces [18:40] or or JPMC's or you know other large [18:43] companies that that have demand for [18:45] fewer numbers of GPUs but or or [18:47] accelerators sometimes they want tranium [18:49] sometimes they want um uh Nvidia GPUs um [18:52] but we want to make sure that we can [18:53] support them as well and we're very [18:55] intentional about how we make sure that [18:56] we have capacity for startups and and so [18:58] what we do is we actually do allocate [19:00] and we basically say okay we're going to [19:01] keep we could you're right we could sell [19:03] every single um uh you know GPU or or AI [19:07] accelerator we had to probably just the [19:09] lab the big frontier labs and call it a [19:12] day. [19:12] >> Um we choose not to do that because we [19:14] actually want to keep growing the the [19:15] full ecosystem. They get a large number [19:16] but but um we want to keep supporting [19:19] >> um a broader set of customers cuz we [19:21] actually think that both the whole [19:22] ecosystem be more healthy for us. [19:24] There's some diversification but it's [19:25] also just we know these are going to be [19:26] big companies over time. Um and so we [19:29] try to support them. Um I saw recently [19:31] that we say you know yes in some way [19:34] shape or form to something like 60% of [19:35] the the requests we eventually get. [19:38] Sometimes it's a little bit later [19:39] sometimes it's in a different region. [19:40] Sometimes it's a slightly different [19:41] configuration than the customers are [19:43] looking for. Um but we really try to [19:44] lean in and and and try to allocate as [19:47] much as we can and every single startup [19:49] that you have wants more [19:51] and so you know so we're working hard um [19:53] to try to make sure that we have all of [19:55] those. Um, but you know, it's it's hard. [19:57] Like that's that's it's you know, like [19:59] this is the as a lot of people say, it's [20:01] a good problem to have. Uh, but it's [20:03] it's a problem nonetheless. And um and [20:06] we're you know, we continue to look at [20:08] at um you know, we we recently announced [20:10] we're going to be buying um you know, 2 [20:13] million Nvidia GPUs over the next uh [20:15] couple of years. like we're we're [20:16] landing a massive amount of capacity [20:19] >> and 2 million [20:20] >> 2 million um so you know it's a lot um [20:22] and it's over the next couple years but [20:24] um and uh and who knows if that's enough [20:28] but that's at some point again we're [20:29] limited by other other components as [20:31] well um but it is we're we're very [20:33] intentional about keeping capacity [20:34] available for for the startups and I [20:36] know it's it's painful to not have [20:38] enough but we we keep pushing [20:40] >> and [20:43] when did uh your capex [20:46] cross [20:49] I mean pure AWS. I mean Amazon was a [20:51] bigger company. [20:52] >> Yeah. [20:53] >> Cross like let's call it even 1 billion [20:55] or 10 billion a year. [20:57] >> Oh, I don't know. I'd have to go back [20:58] and look. I'm not sure about that. But [20:59] it it's definitely scaled up over the [21:01] last couple of years. Um uh in a pretty [21:03] meaningful way. [21:04] >> The the yeah the AI buildout has has [21:07] definitely ramped our our capex [21:08] spending. And so I'd say over the last, [21:10] you know, call it 3 or 4 years, our our [21:12] capex has definitely accelerated um [21:14] pretty pretty meaningfully. Um I don't [21:15] know when we crossed a billion, but um [21:17] given we're 220 now is probably I mean [21:19] we we've been spending capex for a while [21:21] and the and the company has been really [21:22] good about funding that um and obviously [21:24] the AWS business is is a good one that [21:26] we like to invest in. [21:27] >> Yeah. Yeah, of course. And um uh and you [21:30] know I think we were for the longest [21:32] time actually um we you know we we were [21:35] investing ahead of where the demand was [21:37] and [21:38] >> um you know I think one of the one of [21:40] the most painful things is that with the [21:42] real ramp of of GPUs like a lot of the [21:44] elasticity has unfortunately you know [21:46] kind of gone away. Um and so hopefully [21:48] we'll get back to in our core compute [21:49] and and storage and things that [21:51] elasticity is still there and that but [21:52] um but you know that um but but so we've [21:56] been spending for for quite a bit of [21:57] time and and we feel really good about [21:59] the spend that we're making now. um [22:00] which is you know I think I get lots of [22:03] questions sometimes about how you feel [22:04] about that spend and like are you [22:05] nervous about bubble and other things [22:07] like that and I will say you know [22:09] >> we um because of the position we have [22:12] like one we do take this diversified [22:14] approach and so not all of our capacity [22:16] is bundled up in one customer and I [22:18] think you go to a some of these whether [22:20] they're neoclouds or some of the the [22:22] other providers out there and [22:23] >> you know you'll see sometimes [22:25] concentrations of 30 40 50 60% with one [22:28] or two customers [22:29] >> we're nowhere near that obviously we're [22:31] you know singledigit percentages at the [22:32] highest and and and usually it's less [22:34] than that for one I think we have a lot [22:36] less risk on on one particular customer [22:38] but also because we have that rich set [22:39] of services like AWS is where people [22:42] really are coming to launch their [22:44] production workloads and so the majority [22:46] of our usage today actually is either [22:49] core compute and storage and inference [22:51] which is part of that application and so [22:53] those are the workloads that I think [22:54] just aren't going to go away just cuz we [22:56] see enterprises getting positive ROI you [22:58] go talk to the customers and you say at [23:00] the capability today and the cost today [23:02] are you seeing positive returns to your [23:04] business and almost to a person they'll [23:06] say like oh yeah [23:07] >> and so you're like well that's not going [23:08] to go away there's no bubble in which [23:10] they they stop spending on that you know [23:12] and so [23:13] >> you know and you know this like the VC [23:15] model like is every billion dollar [23:16] startup going to make it no they won't [23:18] but you know that's that's kind of the [23:20] game and it's been that's been true for [23:21] 50 years they haven't always been [23:24] billion dollar [23:24] >> start numbers have changed but the [23:26] principles are the principles are the [23:27] same right you bet on 10 and one makes [23:29] it and pays for the other 10 or whatever [23:30] the whatever the percentage is. [23:31] Hopefully it's higher than one. Yeah. [23:33] Right. And so that that there you know [23:35] you saw that with the internet where [23:37] there was a bubble and a bunch of of [23:39] internet companies didn't make it and [23:40] the internet's still a thing [23:41] >> and and a lot of the companies that had [23:43] durable businesses [23:44] >> the Google, Amazon's that others like [23:47] that they did pretty well [23:49] >> and so for us we think we'll feel really [23:51] good about that investment and um and [23:52] and and the continued investment going. [23:54] >> You guys have a view of the demand [23:57] >> that's unparalleled, right? because [23:58] you're seeing across the globe, you're [24:01] seeing across every segment enterprise [24:02] and the big labs and the AI native [24:06] companies and so on and so forth. So, [24:08] >> if anybody should call it, you should be [24:10] able to call it first. [24:12] >> I would hope so. [24:12] >> Yeah, that's our that's our plan and and [24:14] honestly, we spend a lot of time [24:15] thinking about it. We're very [24:16] intentional [24:18] >> um about how we spend um you know, our [24:20] shareholder capital and and we think [24:21] that we're making great investments. We [24:23] have a lot of good protections of how we [24:24] intentionally invest that money. But um [24:26] but yeah, we're we're very bullish on [24:28] and you know, I think Andy's been public [24:30] about saying this, we the potential for [24:32] AWS is is really really large and over [24:34] the next decade, the potential is there [24:36] and anytime you have an opportunity [24:37] that's that big like you kind of want to [24:39] make you want to you want to invest to [24:41] go after it [24:43] >> and [24:46] as the scale of these numbers [24:49] go larger and larger, right? [24:50] >> Yeah. Has your planning and process [24:54] dramatically changed in terms of I mean [24:57] you're not writing [24:58] >> Yeah. [24:59] >> billion dollar checks, you're writing [25:00] like $50 billion checks or $20 million [25:03] checks or whatever it is. [25:04] >> Yeah. Um Yeah. Yes and no. I mean I [25:06] think look a lot of times we're the the [25:08] we're still very bullish about the [25:10] investments and and lean forward but [25:12] there there the process. So there's a [25:14] lot of things that have completely [25:15] changed. [25:15] >> Like how do you even estimate 2028 [25:17] demand? And there's things that we have [25:19] to think about now that we just never [25:20] had to think about. Um and so [25:22] >> if you go back 15 years, [25:25] >> um if we needed more power, we asked the [25:27] power company to give us another, [25:30] >> you know, couple of megawatts or [25:31] whatever it was, right? Tens of [25:32] megawatts like and they would just give [25:34] it to us cuz 10 megawatts wasn't that [25:35] much. And uh and that was plenty for us [25:37] to keep growing. Um now we have to bring [25:40] our own we bring our own power. And so [25:41] we we pay for power projects. We pay for [25:44] renewable projects. We're one of the [25:46] biggest uh renewable power purchasers uh [25:49] each year for the last 10 years. Um and [25:51] so it's you know we're regularly [25:53] bringing on new solar projects, new [25:55] nuclear projects, new [25:56] >> So you're talking about behind the meter [25:57] or are you talking about working with [25:59] the operator? [25:59] >> We'll do both. Um and so both of those [26:01] things and so often times with these [26:02] power projects that we bring on um we'll [26:05] pay the the capital and and pay for the [26:07] project and then it'll go into the grid [26:08] and then we'll get credit for that. So [26:10] we'll bring those on. Um sometimes we'll [26:12] do behind the meter too. like it's it's [26:13] a mix at the at the scale that we're [26:15] doing. You have to think about all of [26:16] those things. Um but um but you know [26:18] that's that's planning where you're [26:20] thinking you know 20 years out of how [26:23] you're going to think about um power, [26:25] how you're going to think about [26:26] transmission, how you're think going to [26:27] think about that um capital and and [26:30] that's stuff we'd never had to think [26:31] about before. That's planning we just [26:32] never had to do. Um but you know we [26:34] always had to it's you know the the [26:35] other things is when we used to think [26:37] about server demand that we needed we [26:39] you know we'd have you know multiple [26:41] quarter demand things and we'd talk with [26:43] our our suppliers and things. Now we we [26:45] work multiple years out um just because [26:47] the the size is so much that we have to [26:50] think about kind of what do we need for [26:51] 26 we need for 27 what do we need for [26:53] 28. Um, and so that's but you know, but [26:55] it's also one of the value that we bring [26:56] to customers, right? That's a thing that [26:58] legitimately customers can't do [27:00] themselves. Like they're not going to do [27:01] power. They're not going to plan their [27:03] memory footprint in 2028. Like they're [27:05] just that they can't do that. And so [27:07] that's one of the real values that we [27:09] bring to to our [27:11] >> broad set of customers is just that's [27:13] just a whole set of things that you [27:14] don't have to worry about and that that [27:15] we spend a huge amount of time thinking [27:17] about. [27:17] >> Yeah. Yeah. You guys are [27:21] generally, I think for the record, the [27:24] largest buyers of practically every [27:28] component of a server. Correct. [27:29] >> I I don't know that. I don't [27:31] >> I am sure that we're one of the the the [27:33] bigger um uh purchasers of of components [27:36] out there for sure. Um and uh who knows [27:39] about everyone but uh and it kind of [27:40] depends on how you think about them and [27:42] how you measure but um [27:44] >> so where I was leading to where do you [27:46] see the [27:48] the constraints being most severe let's [27:52] call it 2728 and where do you see the [27:54] constraints easing up? Yeah, it's funny. [27:56] It's um so uh I'll answer this in a [27:59] roundabout way, but um you know uh I [28:02] remember that um in undergrad we [28:05] actually this was this long time ago and [28:07] I never thought this would be like a [28:08] useful book that I read but we read we [28:10] read the goal and have read the goal [28:12] right and so it turns out there's never [28:14] one constraint there's always just the [28:15] latest constraint and so you have to [28:17] think about all of them and as soon as [28:18] you hit one there's another one right [28:20] and so you know what do you like what is [28:22] the constraint that's going to happen in [28:23] 20 and 28 like I actually don't I think [28:24] there will be one. I think it's like [28:26] every month for us it's do you have [28:28] enough power and then as soon as power [28:29] is no longer the constraint you know it [28:32] might be memory it might be TSMC [28:34] capacity it might be you know HBM it [28:36] might be um uh networking components it [28:40] could be you know there's a a blip [28:42] somewhere in the supply chain and like [28:44] you know connectors or whatever it is [28:46] right at some point you have to think [28:48] about all of those pieces um and it's um [28:52] you know it's it's not also the um uh [28:56] kind of where they happen matters too, [28:58] you know. So it's it may be like, hey, [29:00] we have a ton of power in Indonesia, but [29:03] we don't have enough in Germany, right? [29:05] And so you think about kind of where in [29:08] the world you want that capacity, too, [29:10] cuz it's turns out that not everything [29:11] is totally funible. Some is and some's [29:12] not. Um but might be disc drives, it [29:14] might be SSDs, it might like we we think [29:16] about every single component and we have [29:19] you know tens hundreds of thousands of [29:21] components all that we track and think [29:23] about and um and some we rely on our you [29:26] know our um suppliers to to manage some [29:28] we direct much of it we directly manage [29:31] and uh um and yeah that we have a whole [29:34] team that does that and they're [29:35] fantastic they're I think they're [29:36] industryleading and and we um we kind of [29:39] we we saw this problem coming um [29:41] probably a decade ago [29:43] and really started not just thinking [29:44] about okay how many servers do we need [29:46] to track but just thinking all the way [29:48] through the supply chain you know four [29:49] tiers five tiers down what is the [29:51] component that that could cause an issue [29:53] for us and making sure that we had kind [29:55] of guaranteed supply on that [29:57] >> um if you think if you remember [30:00] >> I don't remember when this was over a [30:01] decade ago when there was like the [30:02] floods in Thailand and and no one had [30:04] disc drives anymore um uh and so that [30:07] was [30:07] >> there was disc drive crisises and then [30:08] there was memory crisis [30:10] >> exactly and so you know it's like I [30:11] think we think through all of those [30:12] things and so we also think about [30:14] where's their diversification in [30:15] manufacturing like all of those kind of [30:16] pieces we try to work through and um and [30:18] we're we're never going to be perfect on [30:20] it but there's always a different supply [30:21] constraint. [30:22] >> Yeah. So um [30:26] obviously there's a lot of wide ranging [30:29] debate about data centers. [30:30] >> Mhm. [30:31] >> Right. And uh [30:34] it's clear that folks like us where we [30:36] stand. But do you think as an industry [30:38] we have not done a good job [30:39] >> of explaining [30:42] why data centers are good for America [30:44] and [30:45] >> generally the world? But uh [30:47] >> and how do you what's the internal talk [30:51] >> amongst Andy's team [30:53] >> on how do we deal with this? [30:54] >> Yeah. Well look I I think um and I think [30:57] you'll hear more from us over this and I [30:58] agree. I think we need to be more vocal [31:00] and be more upfront. Um cuz we actually [31:02] do a ton that's that's really beneficial [31:04] both for the communities we operate in [31:06] um for the you know we we think a ton [31:08] about how do we bring renewable energy [31:10] to these data centers. How do we think [31:11] about being water positive? [31:13] >> Um actually our our our data centers use [31:15] a really really small amount of water. [31:17] We mostly use free air cooling. How do [31:18] we think about being great participants [31:20] in the communities where we are and um [31:22] and how do we bring highpaying jobs to [31:24] the communities we operate in? Um and [31:26] not all data center operators do that. [31:28] And I think there are some well there [31:30] are some well chronicled examples of [31:31] others out there that are not great um [31:33] at that and they just [31:34] >> don't really pay attention to [31:35] regulations. They think that the rules [31:37] don't apply or they just you know launch [31:40] really quickly without thinking about [31:41] those. And I think that it causes [31:42] problem for the whole industry because [31:44] everybody kind of gets lumped into that. [31:45] And so [31:46] >> um so look I think we'll be we we I [31:48] think you're right. We um you know [31:49] vocally is self-critical. We need to be [31:50] more vocal about the benefits that we do [31:53] bring and think about additional ways [31:55] that we can help communities understand [31:57] the benefits that that we bring to them [32:00] both for the the services they use, [32:02] right? If if you usually go to a [32:04] community and say, "Well, do you not [32:05] want to use Netflix?" And they'll be [32:06] like, "No, no, like I I still want [32:07] Netflix." Like that's it. Um and um you [32:10] know like it's important for us to think [32:11] about and highlight the benefits that we [32:13] bring where I I recently saw a report [32:15] where one of the communities that we [32:17] operate in [32:18] >> the everybody in that county pays $5,000 [32:22] a year less in taxes because of the [32:25] taxes that we bring to that. And we [32:26] don't we don't tell them. They don't [32:27] even know it, right? It's just invisible [32:29] to them. And so I think we just need to [32:31] be more um um clear about those benefits [32:34] that we bring cuz I think if you told [32:35] the communities, by the way, your tax [32:37] bill is $5,000 less than it would [32:39] otherwise be if we weren't here, [32:41] >> they might have a little bit of [32:42] different thought about the building [32:43] that's over there. Um so and and but but [32:47] not everyone does that. Not everyone [32:48] kind of um [32:49] >> presumably there's more transparency [32:50] that's needed. [32:51] >> And look, I think much of the data [32:52] center um community, not just us, is [32:54] actually pretty good actors. And there's [32:55] just a few that aren't that um that [32:58] >> that kind of I think have have caused [33:00] some of the angst recently. And I think [33:02] we just need to do a better job of [33:03] highlighting, you know, who's who's [33:05] being good citizens and who's not. [33:07] >> Yeah. And uh before we leave the [33:09] hardware topic, uh um I want to touch [33:12] upon training. [33:13] >> Mhm. [33:14] >> And your whole history with building [33:16] your own uh chips, right? [33:20] >> Um we were one of your first partners [33:22] using Nitro a long time ago. Mhm. [33:24] >> Uh and since then uh Graviton and you [33:28] made tremendous progress. So what was [33:30] the thinking that led to saying look [33:32] we're going to do our own thing and then [33:34] how has that progress been and where are [33:37] you [33:38] >> it's actually a fascinating story and I [33:39] think it's a great example of where um [33:42] Amazon AWS will innovate and we'll [33:45] iterate over time and continue to think [33:47] bigger about what we can do but but um [33:50] but kind of prove our way there as [33:51] opposed to you know and so takes as an [33:53] example um this probably now I 10 it's [33:57] probably about 13 14 years ago [34:00] we were seeing that there was a pretty [34:02] significant um virtualization tax on the [34:05] overall number of resources and um and [34:09] we were kind of thinking about how do we [34:11] our customers were telling us I want [34:13] bare metal performance and they you know [34:15] they're comparing to having all the [34:16] resources of a of a server [34:18] >> and so the first thing that we did is [34:20] that um we took a a network offload card [34:23] and virtualized all of our network [34:25] virtualization and pulled it off onto an [34:26] offload card so that network [34:28] virtualization got closer to to bare [34:30] metal performance and back then it was [34:32] not quite bare metal but it was close it [34:33] was closer [34:34] >> and then we got really excited about [34:36] that and we said okay what if we could [34:38] move storage virtualization off as well [34:40] right and and um and none of the network [34:42] offload cards could do that and then we [34:44] we found this one company who had some [34:46] ARM cores on an offload card and they [34:48] were doing it for other reasons I can't [34:50] remember their original purpose but [34:51] we're like could you use those to do [34:52] storage virtualization and some of these [34:54] other functions and they're like maybe [34:56] and so we really iterated with them this [34:57] was the product Yeah, this is the team [34:59] >> and um and just loved that team like [35:02] really innovative, really missiondriven, [35:03] really wanting to solve problems. [35:05] >> Um and so we acquired them and we said, [35:08] look, could you build us a slightly [35:09] bigger card that actually could take all [35:10] the network virtualization off and [35:12] basically give us a bare metal server [35:15] that has no virtualization on it, no VM [35:17] virtualization, everything is through [35:18] APIs on the card. And because we had [35:20] this view that one performance would be [35:22] much better, resource resource [35:24] utilization would be better. Ruby be we [35:26] security isolation [35:27] >> and security isolation would be much [35:29] much better and we tell people you know [35:30] could then legitimately tell people we [35:32] have no access to any of your VMs that [35:34] are running there [35:35] >> and and um and this has been a huge [35:37] benefit for us for the last decade where [35:39] frankly like we've been leading and and [35:41] others have been kind of slow to do this [35:43] because they this is not a generalized [35:45] thing that people can do [35:46] >> but um so we got to that and we [35:49] basically said look we're we're making a [35:51] lot of progress here um what if we take [35:54] you know And there's a bunch of ARM [35:55] cores that were on this offload card. [35:57] And we said, "What if we turn that into [35:58] a server?" [35:59] >> Uh, and we did that first with Graviton. [36:01] It was a very underpowered um very small [36:04] server that we launched. [36:05] >> Um, and and customers were excited. [36:07] They're like, "I'd love to have an ARM [36:08] server. This is super interesting." And [36:09] so we went down the path and um and [36:12] Graviton um you know and part of what we [36:14] did is we looked and saw that there's [36:16] the the slope of you know ARM cores were [36:19] getting faster and where the you saw the [36:21] power utilization and and the graph [36:22] where they and you knew the intercept [36:24] was going to happen for where this [36:26] architecture was going to be really good [36:27] for for parts and they just needed [36:29] somebody to drive the ecosystem and and [36:30] get some of the pieces in place. So we [36:32] did that with Graviton. Um and [36:34] Graviton's been a a runaway hit at this [36:35] point. Um, [36:37] >> have you been public about what percent [36:38] of your fleet is? [36:39] >> We land more graviton ships uh uh every [36:42] year than um uh than than any other um [36:47] type. So it's it's it's very popular. Um [36:50] and it's um you know look we they're 20% [36:54] cheaper at a 20% better performance and [36:56] have been like that for the last kind of [36:58] five six years. So that's a it's an easy [37:00] value proposition that um and I think [37:03] the vast majority something like 90 [37:04] plus% of our top 100 customers all use [37:06] Graviton in some way shape or form [37:08] across their fleets. Um and so that's [37:11] been a huge win for us and for customers [37:12] it's been it's the single big single [37:14] easiest way that customers lower their [37:16] bill is to move to Graviton. [37:17] >> Um they can often we've we've have [37:19] examples where people have moved their [37:21] whole fleets and cut the number of [37:22] servers they had in half. [37:23] >> The performance is so much better. [37:25] >> It's amazing. And so half a number of [37:26] servers, each server costs less. Like [37:28] it's it's a it's a big win. And so then [37:30] about five, six years ago, we said, you [37:32] know, we saw the rise of of AI um [37:35] compute happening. Um not nearly [37:37] expecting what it was today, but still [37:39] saw it was going to be a big material [37:41] mover. And so we went in, built our [37:42] first chip in and Tranium, and uh we're [37:45] now um you know, in market with the [37:48] third generation in Tranium 3. And um [37:51] have seen fantastic results. So, it's, [37:52] you know, we're we're sold out um uh for [37:56] capacity through probably maybe towards [37:58] the end of next year or something like [37:59] that. And and and we we're trying to [38:01] again we're trying to figure out how we [38:02] can save some capacity and get startups [38:03] to be able to use some of the capacity [38:05] cuz it's uh we see great results. So, [38:07] most of you know the the the majority of [38:10] of traffic on Bedrock all runs on [38:12] Tranium. Um and we have um great deals [38:15] with both Anthropic and OpenAI to build [38:16] on top of Tranium. um as well as a a a [38:20] set of um of smaller startups and you [38:22] know I think we have half dozen to a [38:24] dozen startups that are building on top [38:25] of tranium now too [38:26] >> and uh [38:27] >> so now the name suggests it's a training [38:30] chip [38:30] >> yeah we're back [38:31] >> but everybody's using it for inference [38:33] too [38:33] >> so where is the lean architecturally and [38:37] where is it going [38:38] >> it's a good point um look the vocally [38:40] self-critical we're terrible at naming [38:42] and so it's not it's not our strength [38:43] originally we had a chip called [38:45] inferentia for inference and training [38:46] for training for training And then as [38:48] the models got bigger and bigger and it [38:50] turns out you actually want to run the [38:51] inference on these really large systems, [38:53] it turns out it turns out that tranium [38:56] is actually maybe the best inference [38:57] chip on the market right now. [38:59] >> Um from a a per absolute performance and [39:01] cost performance point of view. [39:02] >> Um and so um [39:04] >> is it better memory memory bandwidth? [39:07] Where is the [39:08] >> it's just it has it has um it's just [39:11] architecture is a little bit different [39:12] than than um uh than others and it's [39:15] much cheaper. Um, and so from a cost [39:16] performance perspective and absolute [39:18] performance perspective, tranium is [39:19] great. Um, [39:21] uh, and so we're, you know, we we use it [39:23] a ton for, um, for inference and, and, [39:25] and that's going to say, Bedrock, um, it [39:27] drives much of the Bedrock um, uh, [39:30] inference today. And, um, but it's also [39:32] a good training chip, too. And it's, you [39:34] know, I think we're we we, you know, a [39:36] lot of our broad set of customers usage [39:38] is not in training models, but is in [39:40] using it. And so that's where a lot of [39:41] people get to use it under the covers, [39:42] and that's where we're excited about it. [39:44] But um but a lot of the big customers [39:46] are interested in it for training [39:47] clusters as well. And particularly as [39:48] you get to tranium 3 and four um uh [39:52] which we've announced we haven't we [39:53] haven't launched trainium 4 yet but [39:54] announced it. Um folks have kind of [39:56] looked at that architecture and said [39:57] like yeah that's the future of where I [39:58] want my training clusters to be as well. [40:00] So we're we're quite excited about the [40:01] future where that goes for these really [40:02] broadscale training clusters also. [40:04] >> But um but yeah it's built. [40:06] >> Yeah. Now uh let's get back to uh [40:09] talking about agents but from a [40:11] perspective of uh large enterprises or [40:14] large medium enterprises. [40:15] >> Yeah. [40:16] >> Where are they in their adoption? Um [40:19] >> and uh have they what sort of benefits [40:22] are you seeing them [40:24] >> reap already and what is the roadmap for [40:27] them as far as you can tell from your [40:29] vantage point? [40:30] >> Yeah, it's it's a really good question. [40:31] And I think it's one that um that we've [40:35] spent a lot of time thinking about. And [40:36] when I talk to customers all out there [40:39] um today, they view, you know, they're [40:42] getting a lot of value out of what [40:44] they've done today. And I would say the [40:45] agents that most enterprises have built [40:47] are are relatively simple and [40:50] straightforward. Um and they're starting [40:51] to think about um and they're um mostly [40:55] >> non-aututonomous, right? They're still [40:57] kind of people in the loop, if you will. [40:59] And so I think we're and and by the way, [41:01] there's customers are still getting lots [41:02] of value out of that today. And so [41:04] they're really thinking about how do I [41:07] have these be autonomous but in a safe [41:09] way. And I think there's two things that [41:11] that I think hold customers back today [41:13] from just continuing to to scale. And [41:15] it's it's already a pretty big business [41:16] today, but I think it's it has a massive [41:18] opportunity to really change [41:21] every single customer out there and [41:23] every single workflow and and really [41:24] thinking about it. And so number one is [41:26] just how to think about it. I think what [41:28] we originally saw was that enterprises [41:31] had a workflow and they're saying great [41:33] I would have the enterprise I would have [41:34] an agent go do the same workflow. [41:35] >> Yeah. [41:36] >> And what we encourage them to really do [41:38] is think not just replicate you know Bob [41:41] does step 1 2 3 4 5 so agent is going to [41:43] do one step 1 2 3 4 5 and then Bob's [41:46] going to check it at the end. That's not [41:47] really the model you want. You want to [41:48] actually step back and say if I want to [41:50] accomplish something how can an agent do [41:52] it differently? It can do it in a [41:53] massively parallelized way. can try 50 [41:56] different things and get to that and and [41:57] how do you help it get to that right [41:59] outcome and rethink how a computer would [42:02] solve a problem versus a human solving a [42:04] problem. And so one of the things is us [42:06] just helping customers understand how to [42:08] think about that and really kind of have [42:09] that blank slate because that's where [42:11] you really get value is not just [42:13] replicating what you're doing today but [42:14] but thinking from a green field approach [42:16] about how you go solve a problem [42:18] completely differently and I'm sure [42:19] that's how many of your startups are [42:21] thinking about this too which is how do [42:22] you help customers green field solve a [42:24] problem not replicate the thing that [42:26] happens today. [42:27] >> So that that is number one [42:28] >> people running fleets of agents swarms [42:31] whatever you want to call them. Yeah, [42:32] >> very common these days [42:33] >> and and and you just want to think about [42:34] it, you know, and and so enterprises are [42:36] not as as again this is one where you [42:38] learn from the startups and you try to [42:40] how do you apply that to an enterprise [42:41] world where they're, you know, an [42:43] insurance company is not necessarily as [42:44] forwardleaning, but they would love to [42:46] figure out how they can have a better um [42:48] you know, approval workflow or something [42:50] like that. Um so that's number one, but [42:52] then the second one is this this how do [42:53] you turn those into fully autonomous [42:55] workflows and how do you actually trust [42:56] the agents? And so we're spending a lot [42:58] of time thinking about how do we build [43:00] services to help enterprises feel like [43:04] their systems are secure and that they [43:06] can trust an agent to make a decision [43:08] that they can have the right guard rails [43:10] that it can have the right permissions [43:11] on their data that it's not going to [43:13] delete production systems that it's not [43:15] going to make tragic mistakes. And right [43:16] now I think that nervousness is probably [43:19] holding people back maybe appropriately [43:21] by the way is holding enterprises back [43:23] from just saying okay go nuts. It's like [43:24] you don't actually want an agent to just [43:25] go crazy and accidentally delete a [43:27] production database. That's going to be [43:28] pretty bad. [43:29] >> Um and so you that's how we're we're [43:31] kind of actively working through this [43:33] with customers on how do we both help [43:36] them architect and frankly invent new [43:38] technologies and capabilities that are [43:39] going to help them solve that problem. [43:41] And so that that is one of the areas [43:42] where I think we'll continue to innovate [43:45] and um and and um and we'll get there. I [43:48] think we have some really good ideas um [43:50] and and some good technologies brewing [43:51] that I think can really help. So are [43:54] enterprises learning how to do eval [43:57] systems and so on and so forth to keep [43:58] the agents they need help honestly like [44:01] you like both like evals how do you have [44:04] a constant loop of testing? How do you [44:06] how do you think about um you know goal [44:08] seeking in a reasonable way? How do you [44:10] have your data labeled in such a way [44:12] that it actually even makes sense that [44:13] the eval can actually kind of um [44:16] approximate what you're going to be [44:18] doing in production? How do you measure [44:19] in production and and back test it so [44:20] you're not seeing drift? All of those [44:22] things are problems that that um [44:24] enterprises don't know how to solve [44:25] today. I shouldn't know if anyone really [44:26] is great at solving these today. Um it's [44:28] why you've seen so many FTE teams kind [44:31] of spin up and and AWS is um and our [44:34] partners are really leaning into the the [44:36] FDE motion to go and help and this is [44:38] the single biggest area where customers [44:39] need help and and when we think about [44:42] how you you you and [44:45] my view is we want to train our [44:48] customers to be able to go and do this [44:49] themselves, right? This is not the [44:51] traditional notion where I want to have [44:53] a people-driven business that goes on [44:55] forever where you just keep paying [44:57] consultants over and over and over [44:58] again. our our view on how FD should [45:01] work and and and is um we want to go [45:05] into a customer who's ready to accept [45:06] the you know to really kind of accept [45:09] owning this when we're done and in 45 [45:11] days do work where we can teach them how [45:13] to make an eval teach them how to get [45:15] their data in a labeled way do work [45:17] alongside with them and then at the end [45:19] of 40 to 5 days you leave and that [45:20] customer is is good and ready to go and [45:22] trained up and that's what our customers [45:24] tell us they want they don't want to be [45:25] beholden to a external workforce for the [45:27] next five Yes. [45:29] >> And um but they need help today. [45:31] >> Yeah. You made a massive investment in [45:33] >> FTEES. [45:34] >> Um so taking that even one step further, [45:38] right? Some of your industry peers have [45:40] said, look, you can't have all of your [45:42] data [45:44] going into a big frontier model. What [45:47] enterprises should really do is to take [45:50] an open source model and then post train [45:51] on your own data and workflows and [45:53] phrases and whatnot. [45:55] >> Where do you stand on that? Are you [45:56] seeing customers actually trying to do [45:58] that or do you guys [45:59] >> how do you how do you think about that? [46:00] >> It's it's a great the first point I I [46:02] wholeheartedly agree on that first point [46:04] like the customers and like enterprise [46:06] data is their most valuable asset. [46:08] >> And so from the very beginning it's why [46:10] we built Bedrock like we did. Um we have [46:12] a guarantee that your data never leaves [46:14] your VPC. And so your if you're running [46:17] inside of Bedrock um your data doesn't [46:20] go back to the model provider. They [46:21] never see your prompts. um that stays [46:24] inside of your own trusted environment. [46:26] Um and so that that is why um [46:29] enterprises kind of run they they prefer [46:31] to run on top of bedrock and it's why [46:32] you see that business growing massively [46:34] like hundreds and hundreds I mean it's [46:36] every um every month we see that just [46:39] business just every week we see that [46:40] business exploding and and it's why um [46:43] you see open AI workloads migrating to [46:45] bedrock. It's why you see Anthropic [46:47] really growing really rapidly. And so [46:49] whether you're using open models or um [46:52] uh or or um closed frontier models. Um I [46:55] think bedrock is a great solution that [46:57] our our customers told us by the way [46:59] like you know we if you remember 3 years [47:01] ago I got a lot of heat. [47:02] >> Speaking of bad names, that's a good [47:03] name though. [47:04] >> Yeah, Bedrock is a good name. That's [47:05] good. But we we got a lot of heat [47:07] actually for being slow to the AI world [47:08] because we actually built the [47:10] foundations of this where we said look [47:12] we're not just going to rush out of [47:14] service. We really want to think about [47:15] how do we make sure that we protect our [47:17] customers data and build a service that [47:19] we think is going to be durable for the [47:20] use cases that we knew about. And if you [47:22] remember we got a lot of heat and we [47:22] said look we're going to go build the [47:24] right thing and now as people move from [47:26] proof of concepts to production vast [47:28] majority of them are landing in AWS on [47:29] bedrock for for much one of the reasons [47:31] is because of this. It's also because of [47:33] the the set of services that we have. We [47:35] also offer open models. We offer [47:38] proprietary models. Um we offer um a [47:41] whole set of capabilities around those [47:43] agent core. We build these building [47:44] blocks so it's easier to build agents [47:46] with any of the models that you want. [47:47] >> Um whether they're in bedrock or out of [47:49] bedrock for that matter. You can use [47:50] Gemini or other things for it. But um [47:52] but I think that's a it's a it's a [47:54] differentiating piece for us and it's a [47:56] super important thing to think about [47:58] because [47:58] >> having that data go back into the the [48:01] model provider I think is a is a [48:02] dangerous thing. You talk about open [48:04] weights models though. I do think that [48:05] there's a and it's an area that I'm [48:07] excited about. um uh we're we're really [48:10] ramping up our support of open weights [48:11] models and and trying to build a good um [48:15] environment and and frankly this is [48:17] where today I think and I think it's [48:20] true a lot of customers believe that [48:22] they have meaningful proprietary data [48:25] that if they could mix in you know do [48:27] some post- training do some fine-tuning [48:29] um um to an open weights model that they [48:31] could distill down they could actually [48:32] get a better performing model at a lower [48:34] price. Um there's a bunch of pieces in [48:36] here that have to work out well. They [48:37] actually have a good eval to actually [48:38] prove that that's true. Most people are [48:40] doing that in SageMaker today. I think [48:42] there's more that we can do to make that [48:43] easier. But actually like if you go look [48:45] at where are people doing that, they [48:46] actually do it in SageMaker on AWS today [48:48] and they actually host the inference via [48:50] SageMaker. [48:51] >> SageMaker is getting a new lease of life [48:53] as a [48:53] >> uh I mean it is it's it was always kind [48:55] of a model building platform, right? And [48:57] now you know there's if if you think [49:00] about what enterprises are doing in this [49:01] world that's what they're doing is [49:02] they're basically effectively building [49:03] their own custom models. And so that is [49:05] SageMaker is is a great place of doing [49:07] that. Um and I think there's some things [49:09] that we need to keep building on to make [49:10] that easier and easier to do [49:12] >> um and to test across different open [49:14] weights models and things like that. But [49:15] that's a um it's a it's an evolving [49:18] space. I think it's a super interesting [49:19] one and it's one we want to make sure [49:20] that we have all the right things for um [49:22] for customers to be able to do if they [49:24] if they have the the right data and [49:25] expertise to actually go down that path [49:28] >> and with all the debate around AI [49:31] extension risk and this that and the [49:33] other and the security um uh [49:38] vulnerabilities and so on and so forth [49:40] and the hugging face attack. How are [49:42] enterprise what do what are CEOs asking [49:45] you about all these things? Yeah, that [49:47] there's a bunch and and they look they [49:48] they mostly want to say like and it goes [49:50] back to this like when I launch agents, [49:52] how can I trust that they're going to do [49:53] what I want them to do? And so we're in [49:55] increasingly [49:56] >> we have been for a while like we're [49:58] basically we're heavily investing in [50:00] building capabilities that allow people [50:02] to deploy agents safely into their [50:03] environment and think about those [50:04] controls. And some of those are how do [50:06] you make sure the agents have the right [50:07] permissions? How do they have the right [50:08] sandboxing? How do you make sure that [50:10] you have the right set of guardrails? [50:12] How do you how do you really [50:14] intentionally think about what you want [50:16] the agents to do and not do? Is there a [50:17] human in the loop or not? And so we we [50:19] spend a lot of time with our customers [50:21] thinking about how do you think about [50:22] safe agent deployment and get better [50:24] over time and um and what other [50:27] capabilities do we need to go build to [50:28] help people deploy agents safely into [50:30] their environment. Um so there there's a [50:32] lot there. Um the other a the other [50:34] angle on that which um a lot of people [50:37] are worried about which is just um are [50:40] some of these really powerful models [50:41] going to be um attack services and and [50:45] and kind of mythosphere um and so I I [50:48] kind of have a view on there they're yes [50:50] that is a real risk I think to to [50:52] customer environments but it's also um a [50:55] real opportunity and so we we recently [50:57] launched a service called continuum that [50:59] uses these powerful models to help [51:01] customers go secure their environment [51:02] and So, we'll look across our [51:04] environment, uh, look for [51:06] vulnerabilities with them. We'll use [51:07] some of these powerful models and and, [51:09] um, um, and help customers find [51:12] vulnerabilities they haven't found [51:13] before. And most importantly, by the [51:15] way, prioritize which ones cuz we know [51:17] context about their environment, how [51:18] it's set up, where their permissions [51:20] are, where they may have compensating [51:22] controls that that make it harder or [51:23] easier to do. Um, and so Continuum is [51:26] incredibly popular with customers. [51:27] Actually, we're um um um really bullish [51:31] about what's possible from AI to help [51:33] with AI powered security cuz look at at [51:35] some point customers are going to need [51:38] security at machine speed, not at at [51:40] human speed, not at like an alarm [51:41] someone goes in look at it. [51:43] >> And so that you know we're running fast [51:44] to go help build that for customers to [51:46] help them protect their environments and [51:48] and I'm very excited about the the [51:50] continuum team is building on that front [51:51] too. So within AWS itself [51:54] >> Mhm. [51:55] >> like how what's the state of adop usage [51:59] of [52:00] agents in the broad and [52:02] >> well continuum is basically us trying to [52:04] expose what we do internally and so we [52:06] we use uh AI extensively for our own [52:09] security. We use AI extensively for our [52:12] own software development. Uh we use uh [52:14] agents actually one of the things that's [52:17] really cool is we use agents across our [52:18] entire business. And so we we rolled out [52:21] um Amazon Quick to every single Amazon [52:24] employee. And now I see HR teams [52:26] building agents to to help drive what [52:28] what used to take teams of people weeks [52:30] to do that a single person can now do in [52:32] a couple of hours to think about kind of [52:35] team planning and and and resource [52:37] management. Um I have finance teams that [52:39] are building um agents to to go think [52:41] about how do they go pull tax rules from [52:44] everywhere and ensure that we have [52:45] compliance on a bunch of different [52:46] pieces. And um super cool to see that [52:49] things that used to be blocked by [52:50] software developers [52:51] >> actually the the the line of business [52:53] folks are able to go and and unblock [52:55] themselves and and innovate more [52:56] quickly. Um and so Quick has been an [52:58] enormous blow and and that has has grown [53:01] like wildfire. see um customers like [53:04] small startups using it all the way to [53:06] the the largest enterprises in the world [53:08] rolling it out to their entire customer [53:09] base to get the benefit of kind of being [53:12] able to access all of your enterprise [53:14] data and easily apply agents and and [53:16] capabilities to to help you accelerate [53:18] your jobs. And so I said we use it [53:20] across uh everything from software [53:21] development to security to um to to [53:24] driving HR policies. I mean you guys are [53:26] notorious for measuring every everything [53:29] about your operation. Where have you [53:31] seen the biggest gains? Yeah, it's I [53:33] mean obviously you know the answer [53:34] software development like that's the [53:36] real answer [53:36] >> the derivatives of that [53:38] >> but yeah I mean the software I mean the [53:39] speed of software development has been [53:41] uh and and and really product [53:43] development uh as a whole not just [53:45] coding [53:46] >> actual [53:46] >> absolutely the the case at which we're [53:50] deploying new products is is um is [53:53] massively different than it has been in [53:54] the past. I think you can see this where [53:56] you know AWS has always been known for [53:58] rolling out features really quickly and [54:00] uh and it's you know we've we've seen a [54:02] turbo boost on that in the last year or [54:04] so as as we've get we call them frontier [54:06] teams as they think about agentic [54:08] development as opposed to kind of [54:09] traditional development and it's you [54:11] know it's not code completion it really [54:12] is agent first the agents write all of [54:15] the code you're just managing a team of [54:17] agents and and driving that um and it's [54:19] it's been fun to see the the the pace at [54:22] which um innovations for customers has [54:24] has been massive and um and it has to be [54:27] cuz that's the that's the our customers [54:30] out there have a a almost insatable [54:33] appetite for new capabilities and and [54:35] that's what we got to do. [54:36] >> Yeah. So organizationally are you like [54:39] do you have any insights on how [54:41] organizations should change and how [54:44] >> I don't uh I'll say that [54:46] >> agents manage people manage agents [54:49] >> uh there's like there's going to be [54:50] there's going to be lots of people for a [54:52] long period of time. I do think [54:53] organizations will change. I don't know [54:55] the magic answer yet. Um but but we're [54:58] actively thinking [54:58] >> inside you're just trying various [55:00] experiments or what? [55:01] >> We're trying experiments. We're thinking [55:02] about pods. Um as you think about you [55:05] know here's one example is in a product [55:06] organization you used to have a team [55:08] that would own a particular kind of [55:10] capability for a long time and you might [55:12] have 10 people working on that thing. [55:14] Well today you can innovate so rapidly [55:16] that one doesn't have to be 10 people. [55:18] It can be three to four people [55:20] >> and they build something so fast, you [55:21] actually want to move them to different [55:22] projects and and problems. And so [55:24] thinking about how do you both operate [55:27] and and maintain the things that you [55:29] built while being agile and flexible to [55:31] move around on an organization that's as [55:33] big as AWS is as active things that [55:35] we're experimenting with and playing [55:36] with. But it's um it's fun and it's [55:38] enabling for our employees. They [55:40] actually love it because they can build [55:41] faster and do more. But um but there's [55:43] real work there. [55:43] >> Yeah, it's a fascinating time and uh so [55:46] thank you very much for your time. We [55:47] could be talking about this for hours [55:49] together, but uh thanks for all your [55:51] insights. [55:51] >> Yeah, thank you for having me and uh and [55:53] thank you. We we we love having uh all [55:55] your uh your companies as customers and [55:57] uh we love learning from them and uh I [55:59] appreciate having me here. [56:00] >> Yeah, we'll keep sending them your way. [56:02] >> Excellent. Thank you. [56:02] >> Thanks.