AWS把Claude插件藏了3個月，開發者發現后省了47%的AP

AWS今年4月悄悄上線了一套Agent Plugins，能讓Claude Code直接操作Lambda、SageMaker、Amplify。但官方文檔里沒寫一件事：如果你有Kiro Pro訂閱，完全可以繞過Anthropic的API計費，把Claude Code的流量全走Kiro的通道。一位開發者實測后，月度API支出從$340降到$180。

這不是破解，是AWS和Anthropic都沒主動告訴你的配置組合。Claude Code 2.1.29版本之后支持ANTHROPIC_BASE_URL環境變量，理論上可以指向任何兼容Anthropic API格式的端點。Kiro Pro的用戶正好可以利用這個缺口——通過kiro-gateway本地代理，讓Claude Code"以為"自己在直連Anthropic，實際上所有請求都路由到Kiro的訂閱池。

我復現了這個流程。從npm安裝到跑通第一個serverless部署，總共踩了4個坑，其中2個在官方文檔里完全找不到。以下是完整的事件還原。

第一步：Claude Code的版本陷阱

很多人卡在第一步：Claude Code的版本號。AWS Agent Plugins要求2.1.29或更高，但npm默認安裝的可能不是最新版。建議先執行npm install -g @anthropic-ai/claude-code@latest，然后claude --version確認。

版本對了之后，真正的配置才開始。你需要同時操作三個東西：Claude Code的settings.json、kiro-gateway的.env、以及Kiro CLI的本地數據庫路徑。這三者的關系有點像"中間人攻擊"的合法版——kiro-gateway坐在Claude Code和Kiro Pro之間，做協議轉換和流量轉發。

Kiro CLI的數據庫路徑是整件事最容易出錯的地方。macOS上它藏在~/Library/Application Support/kiro-cli/data.sqlite3，但很多人直接復制文檔里的路徑，沒把替換成實際用戶名。結果kiro-gateway啟動時報"database not found"，排查半小時發現是路徑字符串里的波浪號沒展開。

正確的.env配置應該是這樣：

PROXY_API_KEY="kiro-local-proxy-key"
KIRO_CLI_DB_FILE="/Users/你的實際用戶名/Library/Application Support/kiro-cli/data.sqlite3"
SERVER_HOST="127.0.0.1"
SERVER_PORT="9000"

啟動命令建議用nohup或者tmux，因為kiro-gateway需要常駐后臺。直接python main.py的話，終端一關代理就斷了，Claude Code會突然報錯"connection refused"。

第二步：Claude Code的"欺騙"配置

~/.claude/settings.json這個文件，官方文檔只說可以配置API key，沒提它能重寫整個base URL。配置完成后，Claude Code的每次請求都會發往http://127.0.0.1:9000，而不是Anthropic的api.anthropic.com。

關鍵細節：ANTHROPIC_API_KEY的值必須和kiro-gateway的PROXY_API_KEY一致。這個key不會被發往Anthropic，只是kiro-gateway用來驗證本地請求的"口令"。第一次運行claude時彈出的"Do you want to use this API key?"，選Yes即可——Anthropic的服務器永遠不會看到這個key。

到這里，基礎設施層已經打通。但真正的價值在于AWS Agent Plugins能做什么，以及為什么值得折騰這一整套代理。

第三步：AWS Agent Plugins的七張牌

AWS目前上架了7個插件，覆蓋從Serverless到SageMaker的完整鏈路：

? deploy-on-aws：通用部署技能，五步工作流
? aws-serverless：Lambda + API Gateway + DynamoDB的完整技能組
? aws-amplify：全棧應用托管
? databases-on-aws：RDS、DynamoDB、ElastiCache
? amazon-location-service：地圖和位置服務
? migration-to-aws：遷移評估和執行
? sagemaker-ai：機器學習模型訓練和部署

安裝方式是在Claude Code里執行：

/plugin marketplace add awslabs/agent-plugins
/plugin install deploy-on-aws@agent-plugins-for-aws
/plugin install aws-serverless@agent-plugins-for-aws

裝完必須重啟Claude Code。這個"重啟"不是退出重進那么簡單——需要完全殺掉進程，因為插件的MCP（Model Context Protocol）服務器是在啟動時初始化的。只按Ctrl+C的話，后臺可能還掛著舊的MCP連接，導致新插件加載失敗。

aws-serverless插件內部包含三個具體技能：aws-serverless-mcp-server（實時數據查詢）、aws-serverless-skill（架構設計和代碼生成）、以及aws-serverless-templates（項目模板庫）。當你說"幫我搭一個serverless API"時，Claude會先調用skill做需求分析，再觸發mcp-server拉取你的實際AWS賬戶數據（比如現有VPC、IAM權限），最后用templates生成可部署的代碼。

這個流程的自動化程度，比手動寫CloudFormation模板快4-6倍。但前提是MCP服務器能正常連接AWS——而這就引出了kiro-gateway配置中最隱蔽的坑。

第四步：IAM權限的"最后一公里"

AWS Agent Plugins需要訪問你的AWS賬戶，但它們的認證方式和AWS CLI不完全一致。插件內部使用boto3，會讀取標準的~/.aws/credentials和~/.aws/config，但有個細節：如果kiro-gateway運行在本地虛擬環境里，它可能繼承不到宿主機的AWS_PROFILE環境變量。

表現癥狀是：Claude Code能正常對話，但一涉及AWS操作就報"Unable to locate credentials"。排查方法是先在kiro-gateway的終端里執行aws sts get-caller-identity，確認能拿到身份后再啟動代理。

另一個坑是Region配置。aws-serverless插件默認用us-east-1，如果你的資源在ap-northeast-1，需要在對話里明確指定，或者在~/.aws/config里設置默認region。否則Claude會自信滿滿地在弗吉尼亞建資源，然后告訴你"部署成功"——你在東京的控制臺里什么都看不到。

deploy-on-aws插件的五步工作流值得單獨拆解：1）需求解析 2）架構選擇 3）代碼生成 4）本地驗證 5）遠程部署。其中第4步會用sam local或者docker-lambda做本地測試，這對網絡環境有要求——如果你在中國大陸，可能需要配置代理或者跳過本地驗證直接部署。

第五步：成本結構的實際對比

回到最開始的動機：省錢。Kiro Pro的訂閱模式是固定費用（具體金額因套餐而異），而Anthropic API是按token計費。對于一個每天使用Claude Code 4-6小時的開發者，典型場景下的成本結構如下：

Anthropic API直聯：輸入+輸出token約每月$280-400，取決于代碼庫大小和對話輪數
Kiro Pro訂閱：固定費用約$150-200/月（視具體套餐）
kiro-gateway方案：Kiro Pro費用 + 本地運行成本（可忽略）

節省比例在35%-50%之間，對話量越大越劃算。但有個前提：Kiro Pro的模型訪問權限要覆蓋你需要的Claude版本。目前Kiro支持Claude 3.5 Sonnet和Claude 3 Opus，如果AWS Agent Plugins后續要求Claude 4，可能需要等待Kiro更新。

另一個隱性成本是setup時間。第一次配置kiro-gateway大約需要45-60分鐘，包括排查路徑問題、IAM權限、MCP連接等。如果你只是偶爾用Claude Code，這個投入可能不劃算。但對于每天依賴AI編程的開發者，這是一筆一次性的時間投資。

第六步：實際運行中的三個故障模式

在兩周的實測中，我遇到了三種典型故障，供參考：

故障一：kiro-gateway的token過期。Kiro Pro的認證token有有效期，kiro-gateway不會自動刷新。表現是Claude Code突然開始報401 Unauthorized，重啟kiro-gateway解決。建議設置cron job或者systemd service，每天凌晨自動重啟代理。

故障二：MCP服務器的并發限制。aws-serverless-mcp-server在處理大型CloudFormation模板時，可能觸發Kiro的速率限制。癥狀是Claude Code"思考"很久后報"tool execution timeout"。解決方法是分批次請求，或者臨時切回Anthropic API直聯處理大文件。

故障三：插件版本沖突。AWS會更新Agent Plugins，但Claude Code不會自動升級已安裝的插件。如果 marketplace 里有新版本，舊版插件可能和新版Claude Code不兼容。建議每周運行一次/plugin update，并在更新后驗證核心工作流。

這些故障在官方文檔里都沒有系統性的說明，社區討論分散在GitHub issues和Discord頻道里。kiro-gateway本身是個個人開源項目，作者jwadow在README里寫了基礎用法，但邊緣場景的覆蓋有限。

第七步：這個方案的邊界在哪里

kiro-gateway不是AWS或Anthropic官方支持的路徑。這意味著：如果Claude Code的某個更新打破了ANTHROPIC_BASE_URL的兼容性，這個方案可能一夜之間失效。同樣，如果Kiro Pro調整了API格式，kiro-gateway需要同步更新。

目前的風險評估：Claude Code的base URL配置已經存在超過6個月，kiro-gateway項目有200+ stars，社區有一定維護動力。但對于生產環境的關鍵路徑，建議保留Anthropic API作為fallback——可以在settings.json里準備兩套配置，通過環境變量快速切換。

AWS Agent Plugins本身的演進也值得關注。目前的7個插件覆蓋的是"基礎設施即代碼"場景，但缺少對AWS CDK的深度支持。如果你重度使用CDK，可能需要結合deploy-on-aws插件和手動CDK命令，混合使用。

SageMaker插件是另一個值得深挖的方向。它支持從數據準備到模型部署的完整流程，但實測中發現對SageMaker Pipeline的集成還不夠順滑——Claude能生成pipeline定義，但執行階段的錯誤診斷能力較弱，經常需要切到AWS Console查看具體失敗原因。

最意外的發現：kiro-gateway的延遲表現。本地代理理論上會增加一跳，但實際體驗中延遲增加不明顯（<50ms）。原因是Kiro Pro的節點分布比Anthropic API更優化，對于亞太用戶，走Kiro可能比直連Anthropic的us-east-1更快。

這套配置跑通之后，我的工作流變成了：Claude Code負責代碼生成和架構設計，AWS Agent Plugins負責與實際云資源的交互，Kiro Pro負責模型調用成本。三者的邊界清晰，故障排查也相對獨立——出問題先檢查kiro-gateway日志，再看MCP服務器狀態，最后才是Claude Code本身。

有個細節可能決定這個方案能走多遠：AWS和Anthropic的合作關系。目前Agent Plugins是AWS主導的項目，但底層依賴Claude模型。如果兩家公司在商業條款上生變，ANTHROPIC_BASE_URL這個"后門"會不會被關閉？這是使用任何非官方集成方案都需要考慮的長期風險。

你現在的AI編程工作流里，模型調用成本占多大比例？有沒有試過把多個AI服務的訂閱"拼"在一起用？