原章：AWS
AWS 的起點並不是「Amazon 想做雲端運算」這麼直接。2001 年 Colin 管理 Amazon Associates 聯盟行銷計畫，合作網站已從數萬家成長到接近一百萬家。這些網站想放 Amazon 商品，但愈來愈不滿足於 Amazon 提供的固定呈現方式；他們希望自己控制字型、顏色、圖片與版面。
團隊換了一個角度看問題：合作方真正需要的不是另一個 Amazon 小工具，而是直接取得資料與功能，自己決定怎麼使用。 這促成早期把 Amazon 資料以 Web Services 方式提供給外部開發者的實驗。
這個小問題逐步連到一個更大的觀察：開發商業軟體時，大家反覆處理同樣的底層工作——儲存、訊息佇列、通知、運算、伺服器、資料中心。這些「primitives」本身並不神祕，但每家公司都要自行購買軟體、硬體、建資料中心、維運並承擔尖峰容量。
Amazon 恰好已經為全球大型網站建立出很強的伺服器端能力。作者的核心洞見是：這些能力不必只服務 Amazon 自己，也可以被拆成可透過網路呼叫、按使用量付費的基礎服務。
| 故事節點 | 原始問題 | 重新定義後的問題 | 新事業機會 |
|---|---|---|---|
| Amazon Associates | 合作網站想更自由地呈現商品 | 他們真正需要的是資料與功能本身 | 把內部能力透過 Web Services 開放 |
| 軟體基礎設施 | 每家公司都在買伺服器、資料庫與基礎軟體 | 大量工作其實高度重複、缺乏差異化 | 把 primitives 服務化 |
| Amazon 的能力 | 大型伺服器端系統是內部優勢 | 其他公司也有同樣問題 | 把核心能力轉成外部產品 |
| 早期 AWS | 不知道哪些服務會真正成功 | 必須同時建立人才、規模與計價模型 | S3、EC2 成為早期突出成功者 |
最難的地方之一是：這不是既有零售客戶要求的新功能，而是一群全新的客戶——軟體開發者與企業——以及一個全新的購買方式。 Amazon 必須把自己習以為常的內部能力，看成別人願意付錢購買的產品。
團隊用 Working Backwards 的 PR／FAQ 反覆定義服務，也用 Bar Raiser 快速建立新團隊。作者說，最初規劃的約半打服務中，真正成為爆發性成功的只有部分，其中 S3 與 EC2 最突出。
定價也不是一次就對。早期 S3 原先主要依儲存量與頻寬計價，實際營運後才發現請求次數同樣大量消耗資源，因此必須調整。由於 Amazon 採取跟隨成本的定價邏輯，錯誤還有空間被修正。
AWS 後來發展得遠超過作者早期參與的版本，但本章刻意把鏡頭停在「它一開始怎麼被看見」：先從一個合作方資料問題開始，逐步發現一整類企業都承受相同的基礎設施負擔。
巨大的新事業不一定來自一個宏大的市場預言。有時它來自一句非常實務的問題：我們公司已經做得很熟、但其他人仍然很痛苦的事情，有沒有可能被重新包裝成服務？