AWS 与 Anthropic 发布了面向 AWS 的 Claude Apps Gateway。它不是新的大模型，而是部署在企业环境中的自托管控制平面：Claude Code 和 Claude Desktop 的请求先进入网关，再由网关统一处理身份、策略、遥测、路由与支出上限，并将推理请求转发到 Amazon Bedrock 或 AWS 上的 Claude Platform。
对于已经开始大规模使用编码助手的团队，这一变化很实际。管理对象不再只是 API Key，而是“谁能使用哪个模型、请求走向哪里、花费是否越界，以及出了问题如何追踪”的完整治理链路。
单个无状态容器带来的部署变化
Claude Apps Gateway 以单个无状态容器运行。这意味着网关本身不应依赖某个实例的本地会话数据，可以放在负载均衡器后横向扩容，也更适合接入 ECS、EKS 或企业现有的容器平台。
典型请求路径可以概括为：
Claude Code / Claude Desktop
|
v
Claude Apps Gateway
| |
v v
Amazon Bedrock Claude Platform on AWS
这里的关键不是多了一层代理，而是治理能力集中到了稳定边界上：
- 身份信息在入口统一验证，客户端不必各自实现企业认证逻辑。
- 策略在模型调用前执行，可以按用户、团队或工作负载限制能力。
- 路由规则决定请求进入 Amazon Bedrock，还是 Claude Platform on AWS。
- 遥测从同一入口产生，便于关联调用者、模型、延迟和消费情况。
- 支出上限能够阻止失控调用继续扩大成本，而不只是事后生成账单报告。
无状态并不代表整个系统没有状态。身份目录、策略配置、预算数据以及遥测存储仍需要可靠的外部系统承载。部署时还应避免把长期凭证、审计记录或预算计数只保存在容器文件系统中。
控制平面解决的是团队级问题
直接让每位开发者连接模型服务，在小团队中简单有效；规模扩大后，问题会迅速从“能否调用”变成“能否治理”。例如，同一个组织可能同时存在交互式桌面用户、运行 Claude Code 的开发者，以及 CI 中的自动化任务。三类调用的风险和预算并不相同。
可以将策略拆成几个明确维度：
| 维度 | 示例决策 |
|---|---|
| 身份 | 只允许公司身份提供方认证的用户访问 |
| 工作负载 | 区分桌面交互、开发终端与 CI 服务账号 |
| 路由 | 受监管团队固定走指定 AWS 区域或推理后端 |
| 预算 | 为个人、团队和自动化任务设置不同支出上限 |
| 遥测 | 记录请求元数据，同时控制敏感提示词和代码的采集范围 |
需要注意的是，来源摘要只说明网关集中提供上述能力，并未给出具体策略语法、容器镜像地址或配置字段。下面的文件因此是一个可改造的部署骨架，用来展示如何在 Kubernetes 中运行无状态网关；镜像名称、监听端口、健康检查路径和参数必须按照正式发布文档替换。
可以这样实践：准备一个可扩展的 EKS 部署骨架
假设企业将网关部署到 EKS，并通过 AWS 身份机制给 Pod 授权访问 Amazon Bedrock，可以先建立如下清单。运行前需要替换 YOUR_GATEWAY_IMAGE、服务账号注解、端口和启动参数。
apiVersion: v1
kind: Namespace
metadata:
name: claude-gateway
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: claude-apps-gateway
namespace: claude-gateway
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/claude-gateway-role
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: claude-apps-gateway
namespace: claude-gateway
spec:
replicas: 2
selector:
matchLabels:
app: claude-apps-gateway
template:
metadata:
labels:
app: claude-apps-gateway
spec:
serviceAccountName: claude-apps-gateway
containers:
- name: gateway
image: YOUR_GATEWAY_IMAGE
ports:
- name: http
containerPort: 8080
env:
- name: AWS_REGION
value: us-east-1
resources:
requests:
cpu: 250m
memory: 256Mi
limits:
cpu: "1"
memory: 1Gi
readinessProbe:
httpGet:
path: /health/ready
port: http
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
httpGet:
path: /health/live
port: http
initialDelaySeconds: 15
periodSeconds: 20
---
apiVersion: v1
kind: Service
metadata:
name: claude-apps-gateway
namespace: claude-gateway
spec:
selector:
app: claude-apps-gateway
ports:
- name: http
port: 80
targetPort: http
替换占位值后，可以这样部署并检查副本状态：
kubectl apply -f claude-apps-gateway.yaml
kubectl -n claude-gateway rollout status deployment/claude-apps-gateway
kubectl -n claude-gateway get pods,service
如果正式镜像没有 /health/ready 和 /health/live，必须按产品实际暴露的端点修改探针；错误的健康检查会让 Kubernetes 不断重启正常实例。生产环境还应在 Service 前配置内部负载均衡器或 Ingress，并启用 TLS、网络策略和访问日志。
上线前先验证治理闭环
引入网关会增加一次网络转发，也会形成新的关键基础设施依赖。团队不应只验证“Claude Code 能收到响应”，还要验证控制面是否真的生效。
建议按以下清单推进：
- 用个人用户、团队账号和 CI 身份分别测试认证与授权。
- 为 Amazon Bedrock 和 Claude Platform on AWS 分别设计路由测试，确认失败时不会意外绕过策略。
- 人为触发较低的测试预算上限，检查拒绝行为、错误信息和告警。
- 确认遥测能关联身份、后端、延迟和消费，同时不会无边界保存源代码或敏感提示内容。
- 删除一个网关 Pod，验证现有请求和新请求在多副本环境中的表现。
- 评估网关不可用、上游限流和凭证失效时的降级方案。
Claude Apps Gateway 的价值在于把分散在客户端、云账号和账单系统中的控制集中起来。对少量试用用户，它可能增加运维成本；对需要统一身份、审计、路由和预算约束的组织，它提供了更清晰的治理入口。采用时应从一个团队和一个推理后端开始，先跑通策略、遥测与成本告警，再逐步扩大覆盖范围。