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服务的订阅"拼"在一起用？