AWS 与 Anthropic 发布了面向 AWS 的 Claude apps gateway。它把 Claude Code 和 Claude Desktop 的身份认证、策略、遥测、模型路由与费用上限集中到一个自托管控制平面中，并可将推理请求转发至 Amazon Bedrock 或 AWS 上的 Claude Platform。
这项变化解决的不是“怎样再接入一个模型 API”，而是企业在开发者大规模使用 AI 编程工具后遇到的治理问题：谁能访问、请求发往哪里、花费是否失控，以及审计记录能否统一留存。
单个网关统一两类客户端
Claude Code 运行在开发者终端中，Claude Desktop 则承载桌面交互与应用集成。过去，如果团队分别配置每个客户端，身份凭证、模型入口和预算限制很容易散落在个人机器、脚本与不同项目中。
Claude apps gateway 位于客户端和模型服务之间，形成统一请求路径：
Claude Code ───────┐
├── Claude apps gateway ── Amazon Bedrock
Claude Desktop ────┘ └── Claude Platform on AWS
网关集中处理五类能力：
- 身份：将客户端请求关联到受控用户或工作负载身份。
- 策略：在统一位置决定哪些用户、团队或应用可以访问哪些能力。
- 遥测：收集请求与使用情况，为审计、排障和容量评估提供数据。
- 路由：把推理流量送往 Amazon Bedrock 或 Claude Platform on AWS。
- 费用上限：为组织设置消费边界，降低单个客户端失控带来的风险。
它仍然只是控制与转发层。模型能力、区域可用性、数据处理约束和底层服务配额，仍取决于选用的推理后端。
无状态容器改变了运维方式
来源信息强调，网关以单个无状态容器运行。这意味着实例不应依赖本地磁盘保存关键会话或治理状态，扩缩容也可以围绕普通容器工作负载展开。
这一设计带来几个直接结果：
- 可以在容器平台上运行多个副本，并通过负载均衡器提供统一入口。
- 容器重启或替换时，不需要迁移本地业务数据。
- 策略、身份配置和遥测出口应由外部系统提供，不能把可变配置只写进容器文件系统。
- 高可用不等于“副本数设为 2”就结束了，还需要检查下游 Bedrock、Claude Platform、身份系统和遥测系统的故障行为。
由于网关会成为组织内 Claude 客户端的集中入口，它同时也是关键依赖。部署时应设置资源限制、健康检查、滚动升级策略，并避免让管理接口直接暴露在公网。
可以这样实践：在 Kubernetes 中部署无状态网关
下面是一个示意性部署模板，用于表达无状态网关的部署方式，并不代表项目公布的实际镜像地址、端口或环境变量名称。使用前需要根据正式发行包修改 image、监听端口、启动参数和配置项；不要直接把长期 AWS 密钥写入 YAML。
apiVersion: apps/v1
kind: Deployment
metadata:
name: claude-apps-gateway
namespace: ai-platform
spec:
replicas: 2
selector:
matchLabels:
app: claude-apps-gateway
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 0
maxSurge: 1
template:
metadata:
labels:
app: claude-apps-gateway
spec:
serviceAccountName: claude-apps-gateway
containers:
- name: gateway
image: REPLACE_WITH_OFFICIAL_GATEWAY_IMAGE
ports:
- name: http
containerPort: 8080
env:
- name: AWS_REGION
value: us-east-1
- name: INFERENCE_BACKEND
value: bedrock
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: ai-platform
spec:
selector:
app: claude-apps-gateway
ports:
- name: http
port: 80
targetPort: http
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: claude-apps-gateway
namespace: ai-platform
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: claude-apps-gateway
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 65
替换占位镜像并确认官方健康检查路径后，可以这样部署：
kubectl create namespace ai-platform
kubectl apply -f claude-apps-gateway.yaml
kubectl -n ai-platform rollout status deployment/claude-apps-gateway
kubectl -n ai-platform get deploy,pod,svc,hpa
在 AWS 上运行时，可以优先让 Pod、ECS Task 或其他运行环境通过工作负载身份获得最小权限，而不是挂载静态访问密钥。若选择 Amazon Bedrock，还应把可调用的模型、区域和相关操作限制在网关真正需要的范围内。
健康检查路径和端口必须以实际网关文档为准。如果正式镜像没有这些端点，应删除或调整探针，否则 Kubernetes 会不断重启原本正常的容器。
上线前先确定治理边界
网关能集中执行策略，但无法自动替组织定义策略。团队至少需要明确以下问题：
- Claude Code 与 Claude Desktop 是否使用相同的身份规则和模型范围？
- 费用上限按个人、团队、项目还是整个组织设置？达到上限时是拒绝请求、降级路由，还是触发告警？
- 遥测数据是否包含提示词、响应正文或代码片段？保留周期与访问权限是什么？
- Bedrock 与 Claude Platform on AWS 之间的路由由谁决定，切换是否会影响数据驻留、功能或成本？
- 网关不可用时是否允许客户端绕过它直连模型服务？如果允许，集中治理就可能失效。
建议先选择一个开发团队试点，验证身份映射、预算告警、日志脱敏和故障恢复，再逐步扩大客户端覆盖范围。自托管控制平面换来了更强的治理能力，也带来了补丁升级、容量规划、可用性和安全响应责任。真正值得关注的并不是“多了一层代理”，而是组织终于可以把 AI 编程客户端纳入现有的平台工程与安全管理体系。