本篇文章更新時間：2026/04/12
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
內容目錄
20 年與 AWS 共同成長：從一位 FreeBSD 工程師看到的雲端進化史
編輯前言：這篇文章源自 Colin Percival 的回顧文［20 Years on AWS and Never Not My Job］，從一個外部開發者的真實視角，完整呈現了 AWS 20 年來的技術演變、溝通文化，以及 FreeBSD 能在雲端生存並茁壯的背後故事。
核心觀點 (Key Takeaways)
- Colin 不是 Amazon 員工，卻在 20 年間深度影響 AWS 的基礎架構與安全設計。
- 這篇回顧揭露 AWS 早期的限制、疏漏、設計取捨，也展示開放社群如何推動大型雲平台改善。
- FreeBSD 能在 EC2 上成為正式受支援的 OS，背後是長年技術挑戰、溝通、甚至黑客式試驗累積的成果。
深入解析
這是一篇長達兩萬字的技術回憶錄，但若把它濃縮成一條主線，就是：
「一位外部工程師，如何在 20 年間不斷指出問題、提出改善、提交漏洞、驗證安全、開發工具，並實質改變 AWS 的技術方向。」
Colin 的故事並不是英雄式敘事，而是一個極具工程文化的案例：專業、固執、務實、敏銳。他無數次提前發現 AWS 可能踩雷的地方，也常在服務發布的第一時間指出設計缺陷。
以下分幾個角度整理：
- AWS 早期的「手動啟用服務」：2006 年，AWS 還要靠發信請求才能啟用服務，甚至 S3 都不是預設開放。
- 深入參與安全議題：從 API 回應未簽章、Xen hypervisor 漏洞、SimpleDB 簽名碰撞、NextToken 安全缺陷，到 2016 年批評 IMDS 設計不安全，很多議題後來都證明他說對了。
- FreeBSD on EC2 的漫長技術征途：光是 Xen 版本、頁表 bug、驅動程式、HVM 轉換等問題就足以寫一本書。
- AWS 的設計如何因一封信、一場討論而改變：像 SigV4 衍生金鑰模型、IMDSv2、UEFI boot mode 設計、OCI 行為調整，背後都有 Colin 的 push。
以下選取幾段特別具有啟發性的故事。
1. 從第一天就對 AWS 安全提出質疑
他注意到一個非常根本的問題：請求是簽名的，但回應不是。早期甚至還用 HTTP，而非 HTTPS。他的態度是典型安全工程師思維：
"end-to-end signing is always going to be better than transport-layer security"
這個觀點放在今天仍然成立。
2. 當 EC2 還不能跑 FreeBSD 時，他就開始找人
從 NDA、Fax 時代，到自行分析 Xen 版本與頁表 bug，他幾乎像是把 AWS 當作一個開源專案在參與。
而真正的突破點竟然是：
- t1.micro 採用 Xen 3.4.2，剛好沒有那個影響 FreeBSD 的 bug。
這是一個非常 engineering 的 moment。
3. SimpleDB 的設計漏洞與 AWS 的回應文化
SimpleDB 的簽名碰撞、NextToken 直接序列化 Java 物件等問題，都反映出早期 AWS 仍未建立成熟的安全回報流程。
尤其 NextToken 那段：
他回報後沒人理，六個月後換另一個工程師，他又重新回報一次。
這種「不是不重視，而是沒有流程」的現象，在大型新興雲平台非常真實。
4. 很多 AWS 設計後來都驗證了他的觀點
例如：
- IAM 服務推出（2010）使用規則模型，但 SigV4（2012）採用他當初提議的衍生金鑰。
- IMDS 在 2019 年 Capital One 事件後推出 v2，正中他 2016 年文章的警告。
這些都說明：外部的批評不會立刻產生影響，但會在適合的時機被採納。
5. 安全漏洞的侷限與溝通磨合
2023–2025 的 Seekable OCI 安全議題更是經典：
- 他提出問題
- AWS 說已修
- 他再看一次：沒有真正修正
- 一講明問題本質後，團隊立刻動起來
這是典型大型組織與深度安全思考者之間的溝通差異。
筆者心得與啟發
讀完這篇回顧，我腦中浮現了幾個觀察：
- 這不是一個工程師與雲服務的故事，而是一位工程師與一個巨型系統共進化的過程。
- 技術社群能在超大型商業平台上發揮實質影響力，是一種難得的、但真實存在的現象。
- 許多雲端設計的缺陷與改善都不是靠「內部規劃」誕生，而是靠外部指出盲點。
- FreeBSD 在 AWS 上能正式成立，是技術堅持的勝利。
而最有啟發性的一句話，是他在回顧 SimpleDB 漏洞時的自述：
“the best time to talk to me about a new service is before building it.”
對雲端服務的使用者、建設者、甚至產品經理來說，都非常值得反思：
很多時候最好的 feedback，從來不來自「產品推出後的使用者」，而是「設計階段願意深入思考的人」。
如果你在意 AWS、雲端安全、FreeBSD 或大型系統演化，原文絕對值得收藏。