3月4日上線Lightsail，45天后四線產(chǎn)品矩陣成型。亞馬遜對OpenClaw的押注速度，暴露了云廠商在AI Agent時代的真實焦慮——不是缺技術，是怕開發(fā)者跑錯門。

從"一鍵部署"到"企業(yè)級隔離"：四張牌怎么打

亞馬遜這次沒玩概念，直接甩出四張技術底牌。Lightsail、EC2、Bedrock AgentCore、EKS，覆蓋從個人開發(fā)者到大型企業(yè)的完整光譜。表面看是產(chǎn)品豐富，內核是一場關于"控制權"與"便利性"的精密計算。

Lightsail的定位最直白：讓一個人45分鐘跑通Demo。預置鏡像、設備配對、Bedrock預集成，三步點擊搞定。AWS社區(qū)領袖Jorge Rodriguez做的實驗手冊驗證了這個路徑——45分鐘，從空白到能語音對話、能聯(lián)網(wǎng)搜索的Agent。

但個人開發(fā)者的爽點，恰恰是企業(yè)用戶的痛點。Lightsail的架構決定了"一用戶一實例"，沒有原生多租戶隔離，空閑時段照樣計費。這對預算敏感的企業(yè)IT部門來說，是硬性否決項。

EC2的解法是把控制權交還用戶。Graviton處理器省20-40%算力成本，Systems Manager Session Manager關掉SSH暴露面，VPC端點把流量鎖在AWS內網(wǎng)，CloudTrail自動埋點審計。每一環(huán)都在回應企業(yè)合規(guī)部門的 checklist。

Bedrock AgentCore則是亞馬遜押注的"下一代范式"。Serverless架構，按調用付費，自動擴縮容，內置用戶隔離。開發(fā)者只寫Agent邏輯，底層運維全托管。這是亞馬遜對"AI Agent需要什么樣的基礎設施"給出的官方答案。

EKS站在最右側——當企業(yè)需要多租戶硬隔離、自定義編排策略、或者已有K8s資產(chǎn)時，這是唯一不打破現(xiàn)有技術棧的選擇。

成本結構拆解：四種賬單，四種生意邏輯

云產(chǎn)品的選擇本質是成本模型的選擇。四種部署方式對應四種完全不同的計費哲學。

Lightsail是固定成本思維。包月實例，預置配置，適合可預測的個人負載。風險在于資源閑置——你睡覺，服務器照轉，賬單照走。

EC2把成本拆成算力、存儲、網(wǎng)絡、安全服務四本賬。Graviton的20-40%節(jié)省是明牌，但隱性成本在于運維人力。你需要有人懂VPC路由、IAM策略、Session Manager配置。省的是機器錢，花的是工程師時間。

Bedrock AgentCore的計費顆粒度最細。按Agent調用次數(shù)、執(zhí)行時長、Bedrock模型Token消耗三層疊加。理論上最省，但實際賬單高度依賴應用架構設計。一個循環(huán)調用的Bug可能讓月度預算翻倍。

EKS的成本結構最復雜。控制平面固定費用、工作節(jié)點按需計費、存儲卷、負載均衡、外加可能的預留實例折扣。優(yōu)勢在于規(guī)模效應——當Agent數(shù)量過千，編排效率帶來的單位成本下降會抹平管理開銷。

亞馬遜沒有公布任何具體定價數(shù)字，但產(chǎn)品文檔的措辭暴露了優(yōu)先級。Bedrock AgentCore被描述為"purpose-built serverless runtime"，專屬定制的定位暗示這是長期主推方向。Lightsail和EC2是"getting started"選項，EKS留給"enterprise multi-tenant"場景。

技術鎖定與遷移成本：選錯門的代價

云廠商的產(chǎn)品矩陣設計，從來都有"溫柔陷阱"的成分。OpenClaw的四條路徑，表面自由，實際在關鍵節(jié)點埋下粘性設計。

Lightsail的預置鏡像最輕，但也最封閉。設備配對機制、Bedrock集成方式都是黑箱。從Lightsail遷出，等于重寫部署邏輯。

EC2的開放性最高，但深度整合AWS原生服務后，遷移同樣痛苦。CloudTrail日志格式、VPC端點架構、Systems Manager的會話歷史——這些都不是其他云廠商能直接對標的。

Bedrock AgentCore的鎖定最隱蔽。Serverless的便利建立在抽象層之上，你的Agent邏輯與AWS的擴展機制、安全模型、甚至Bedrock的特定API深度耦合。行業(yè)尚無AgentCore的同類競品，遷出意味著重構整個運行時。

EKS看似最中立，K8s是事實標準。但AWS的EKS發(fā)行版有專屬控制器、托管插件、IAM集成方式。真正的可移植性需要額外工程投入。

亞馬遜的文檔坦誠地承認了這些權衡。沒有"最佳選項"，只有"最適合你的workload requirements"。這句話的潛臺詞是：選之前想清楚，換起來很疼。

社區(qū)實驗的啟示：45分鐘能證明什么

Jorge Rodriguez的45分鐘實驗值得細讀。這不是官方營銷素材，是社區(qū)貢獻者的真實路徑驗證。

實驗目標很明確：證明Lightsail路徑的"最小可行演示"價值。參與者從零開始，完成Instance啟動、OpenClaw部署、Bedrock模型接入、語音交互功能、網(wǎng)絡搜索能力五個里程碑。

45分鐘的完成度說明了兩件事。一是亞馬遜的預置鏡像確實做到了"開箱即用"，二是AI Agent的技術門檻正在快速平民化。半年前需要工程團隊兩周搭建的基礎設施，現(xiàn)在單人下午茶時間搞定。

但這個實驗的邊界同樣清晰。單用戶、單實例、無持久化狀態(tài)、無并發(fā)負載。任何生產(chǎn)環(huán)境的剛性需求——用戶認證、數(shù)據(jù)隔離、故障轉移、監(jiān)控告警——都不在45分鐘的射程內。

亞馬遜把實驗手冊放在官方文檔入口，是一個精心計算的信號。它降低試用門檻，但不夸大能力邊界。這種克制在當下的AI營銷中反而稀缺。

Bedrock AgentCore的野望：重新定義Agent基礎設施

四條路徑中，Bedrock AgentCore的信息密度最低，戰(zhàn)略權重最高。文檔只給了概念描述，沒有操作手冊，沒有定價細節(jié)，沒有性能基準。

這種"半遮面"的發(fā)布方式，在AWS歷史上通常意味著產(chǎn)品尚未GA（General Availability），但架構方向已經(jīng)確定。AgentCore被定義為"purpose-built serverless runtime specifically designed for AI agents"——三個定語層層遞進，每個都在劃清與傳統(tǒng)計算服務的界限。

"Purpose-built"針對的是通用Serverless（如Lambda）的局限。Lambda的啟動延遲、執(zhí)行時長限制、狀態(tài)管理機制，對長時間運行的Agent進程都不友好。

"Serverless"回應的是EC2和Lightsail的運維負擔。自動擴縮容、按使用付費、免補丁管理，這些承諾對Agent這種"間歇性高負載、長時間空閑"的工作負載模式尤其適配。

"Specifically designed for AI agents"是最關鍵的差異化。暗示AgentCore內置了Agent特有的抽象——記憶管理、工具調用編排、多輪對話狀態(tài)、人機協(xié)作中斷機制。這些不是通用計算平臺能提供的。

亞馬遜沒有透露AgentCore的底層技術。是Lambda的魔改版，還是全新運行時？與Bedrock模型的集成深度如何？是否支持第三方模型？這些空白留給re:Invent或后續(xù)博客填補。

企業(yè)決策框架：什么時候選哪張牌

基于現(xiàn)有信息，可以建立一個粗糙但實用的決策矩陣。

選Lightsail，當且僅當：你是獨立開發(fā)者；需要快速驗證概念；預算固定且可預測；無多用戶場景；能接受AWS生態(tài)綁定。

選EC2，當且僅當：你需要細粒度控制；有合規(guī)審計要求；已有AWS運維經(jīng)驗；工作負載模式穩(wěn)定；愿意承擔固定成本換取確定性。

選Bedrock AgentCore，當且僅當：用戶數(shù)量波動大；希望零運維；完全接受AWS技術棧；能容忍早期產(chǎn)品的功能邊界；對Serverless計費模型有認知。

選EKS，當且僅當：需要硬多租戶隔離；已有K8s基礎設施；需要自定義編排策略；Agent規(guī)模預期超過千級；有專職平臺工程團隊。

這個框架的漏洞很明顯——Bedrock AgentCore的關鍵參數(shù)缺失，EKS的具體優(yōu)勢描述不足。但亞馬遜的產(chǎn)品發(fā)布節(jié)奏向來如此：先框定方向，再填充細節(jié)，最后用客戶案例背書。

云廠商的Agent戰(zhàn)爭：亞馬遜的先手與隱患

OpenClaw的四路部署方案，需要放在更大的行業(yè)坐標中審視。

微軟的打法是"Copilot everywhere"——把Agent能力塞進Office、Windows、Azure的每個角落，用生態(tài)粘性換用戶習慣。谷歌的路線是"模型即服務"——Gemini的API滲透優(yōu)先，基礎設施層相對開放。亞馬遜的選擇是" Bedrock為中心"——模型推理、Agent運行時、部署選項全部圍繞自研服務構建。

三種策略沒有高下，只有適配場景的差異。亞馬遜的優(yōu)勢在于企業(yè)市場的信任積累和基礎設施的完整性。隱患在于Bedrock的模型豐富度仍落后于Azure OpenAI Service，AgentCore的成熟度尚未驗證。

四路并進的另一個風險是選擇疲勞。個人開發(fā)者可能卡在Lightsail和EC2的邊界，中小企業(yè)在Bedrock AgentCore和EKS之間搖擺。亞馬遜文檔反復強調"根據(jù)workload requirements選擇"，但缺乏清晰的決策樹工具。