Anthropic 宣布 Claude Platform on AWS 正式 GA。这意味着 AWS 用户不再需要绕到 Anthropic 官网注册账号、管理 API Key,而是直接在 AWS 体系内完成认证、计费和监控,调用 Anthropic 原生的 Claude 平台。对于已经在 AWS 上跑业务团队来说,这是一条更短的接入路径。
和 Amazon Bedrock 有什么不同?
Amazon Bedrock 是 AWS 自建的模型托管服务,里面包含 Claude 等多家模型,统一走 Bedrock 的 API 规范和定价体系。而 Claude Platform on AWS 则是 Anthropic 原生平台的 AWS 集成版本——你用的是 Anthropic 自己的 API 接口和模型版本,但认证、账单、日志全部挂在 AWS 账号上。
简单对比:
| 维度 | Amazon Bedrock | Claude Platform on AWS |
|---|---|---|
| API 规范 | Bedrock 统一格式 | Anthropic 原生 Messages API |
| 模型版本 | Bedrock 上线的版本 | 与 Anthropic 官网同步 |
| 认证方式 | AWS IAM(Bedrock 端点) | AWS IAM(Anthropic 端点) |
| 计费 | Bedrock 定价 | Anthropic 定价,AWS 账单出账 |
| 监控 | CloudWatch(Bedrock 指标) | CloudWatch(Anthropic 端点指标) |
如果你的应用已经按 Anthropic Messages API 写好了逻辑,迁移到 Claude Platform on AWS 只需要换端点和认证方式,不用重写请求体。
认证与接入:AWS IAM 替代 API Key
过去调用 Anthropic API 需要生成一个 x-api-key,手动轮换、小心别泄露。现在换成 AWS IAM 签名,好处是:
- 不再硬编码 API Key——用 IAM Role / IAM User 的临时凭证签名请求。
- 权限粒度可控——通过 IAM Policy 限制谁能调用、能调哪个模型。
- 审计天然集成——所有调用记录进入 CloudTrail。
下面是一个最小 IAM Policy,只允许调用 Claude 3.5 Sonnet:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"anthropic:InvokeModel"
],
"Resource": [
"arn:aws:anthropic:us-east-1::model/claude-3-5-sonnet-*"
]
}
]
}
把这个 Policy 绑到运行你应用的 IAM Role 上,EC2、Lambda、EKS 里的代码就能直接拿到临时凭证签名请求,不再需要环境变量里塞密钥。
实操示例:用 boto3 签名调用 Claude Messages API
以下示例假设你在 EC2 或 Lambda 上运行,实例已绑定上述 IAM Role。代码用 AWS SigV4 签名替代 x-api-key,直接请求 Anthropic 原生端点。
import boto3
import json
import requests
from botocore.auth import SigV4Auth
from botocore.awsrequest import AWSRequest
# --- 配置 ---
REGION = "us-east-1"
MODEL = "claude-3-5-sonnet-20241022"
ENDPOINT = f"https://api.anthropic.aws/v1/messages"
# --- 构造请求体(Anthropic 原生 Messages API 格式) ---
payload = {
"model": MODEL,
"max_tokens": 1024,
"messages": [
{"role": "user", "content": "用三句话解释什么是向量数据库"}
]
}
# --- 用 IAM 临时凭证做 SigV4 签名 ---
session = boto3.Session() # 自动从实例元数据/环境变量取凭证
credentials = session.get_credentials()
request = AWSRequest(
method="POST",
url=ENDPOINT,
data=json.dumps(payload),
headers={
"Content-Type": "application/json",
"anthropic-version": "2023-06-01"
}
)
SigV4Auth(credentials, "anthropic", REGION).sign(request)
# --- 发送请求 ---
response = requests.post(
ENDPOINT,
headers=dict(request.headers),
data=request.body
)
result = response.json()
print(result["content"][0]["text"])
运行前确认:
- 你的 IAM Role 已经绑了上文 Policy。
- 运行环境在 AWS 内(EC2 / Lambda / EKS),能自动获取临时凭证。如果在本地开发机,需要先
aws configure配置 profile 或设置AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY环境变量。 requests和boto3已安装:pip install boto3 requests。
计费与监控:一张 AWS 账单看全貌
Claude Platform on AWS 的计费走 AWS 账单体系——输入 token、输出 token 的费用直接出现在你的 AWS Cost Explorer 里,和 EC2、S3 费用并列。这意味着:
- 不需要单独管 Anthropic 的信用卡和账单。
- 可以用 AWS Budgets 设阈值告警,防止某个实验跑出天价。
- Cost Explorer 标签体系可用,按项目 / 环境拆分 LLM 费用。
监控方面,调用延迟、错误率、token 消耗会进入 CloudWatch Metrics,你可以直接配 Dashboard 和 Alarm:
# 查看最近 1 小时 Claude 调用的平均延迟
aws cloudwatch get-metric-statistics \
--namespace AWS/Anthropic \
--metric-name InvocationLatency \
--dimensions Name=Model,Value=claude-3-5-sonnet-20241022 \
--statistics Average \
--period 300 \
--start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
--end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
--region us-east-1
上面 CloudWatch namespace 和 metric 名称是基于合理推断的示例命名。实际指标名称以 AWS 文档为准,上线后建议先
aws cloudwatch list-metrics --namespace AWS/Anthropic确认。
选用建议与注意事项
适合走 Claude Platform on AWS 的场景:
- 应用已经跑在 AWS 上,不想多维护一套 Anthropic 账号体系。
- 团队有 IAM 权限管理流程,希望 LLM 调用也纳入这套流程。
- 需要把 LLM 费用和基础设施费用合并做预算管控。
- 代码已经按 Anthropic Messages API 写好,不想为了 Bedrock 再适配一层请求格式。
仍需斟酌的点:
- 定价差异——Anthropic 原生定价和 Bedrock 定价不完全一致,大批量使用前建议两边算一下月成本。
- 端点区域——目前仅
us-east-1可用,如果你的架构强依赖本地区域低延迟,需要评估跨区域调用的影响。 - 模型覆盖——Bedrock 上可能提供某些 Anthropic 还未在 AWS 端同步的模型版本,反之亦然,选模型前对照两边的模型列表。
- 合规与数据驻留——Claude Platform on AWS 的请求仍走 Anthropic 基础设施处理,数据驻留策略和 Bedrock 的"数据不离开 AWS 区域"承诺不同,合规团队需要确认。
快速上手清单:
- 在 AWS Console 搜索 Anthropic / Claude Platform,确认订阅状态。
- 创建 IAM Policy,限定模型和操作范围,绑到目标 Role。
- 用上文 Python 示例跑一次请求,验证认证和响应正常。
- 在 Cost Explorer 确认 LLM 费用单独可见,配 Budget 告警。
- CloudWatch 配 Dashboard 监控调用延迟和错误率。
一句话总结:Claude Platform on AWS 把 Anthropic 原生 API 的灵活性和 AWS 的认证/计费/监控基础设施缝合在一起,对 AWS 深度用户来说,接入成本显著降低,但定价和合规细节仍需逐项核对。