← 返回目录

成本管控与安全防护:帮助企业避免 AI 意外账单,保障业务连续性

摘要:随着企业大规模采用 Amazon Bedrock 上的大语言模型,Token 消耗带来的成本不可预测性和 API Key 被盗刷的安全风险成为两大核心挑战。本文提供一套完整的解决方案,涵盖成本监控、预算限额、安全防护三个维度,帮助企业实现 AI 投入可预测、AI 资产不被盗用。


背景与挑战

Amazon Bedrock 按 Token 计费(输入 Token + 输出 Token),企业在享受 AI 能力的同时面临两大风险:

风险类型 典型场景 后果
成本失控 开发者调试时大量调用、Prompt 设计不当导致 Token 爆炸 月底收到意外高额账单
资产被盗 API Key 泄露、内部人员滥用、凌晨异常调用 巨额费用 + 数据泄露风险

本文将从方案选型 → 快速接入 → 业务监控 → AWS 原生兜底 → 安全防护五个层面,提供一套可落地的完整方案。

整体架构

Bedrock 成本管控与安全防护架构

一、方案选型:Token 成本监控与限额的三种路径

方案一:开源 AI 代理(推荐)

通过 LiteLLM 等成熟开源代理,在代理层实现 Token 计量和限额。

代表方案:LiteLLM Proxy - 内置用户/团队/Key 级别的预算管理和速率限制 - 支持多模型统一接口(不仅限 Bedrock) - 提供 Dashboard、告警等开箱即用功能 - 实时拒绝超限请求

方案二:自建 Proxy

基于 Bedrock API Response 中的 usage 字段自行构建监控逻辑。

代表方案:API Gateway + DynamoDB + CloudWatch - 完全自主可控,灵活定制 - 全 AWS 原生服务,无第三方依赖 - 开发和维护成本较高

方案三:AWS 原生服务(兜底保护)

不引入代理层,直接利用 AWS Budgets + Budget Actions 实现监控和限制。这是 AWS 平台级别的安全网,即使应用层防护失效,也能确保费用不会无限增长。

代表方案:AWS Budgets + Budget Actions + IAM Deny Policy - 纯原生方案,无需代码,AWS 平台级保障 - 可实现超预算自动阻断,Deny 优先原则确保 100% 生效 - 支持按 IAM 用户维度设置独立预算 - 每月自动重置,无需人工干预

对比总结

维度 开源代理 (LiteLLM) 自建 Proxy AWS 原生 (Budgets)
实现难度 ⭐ 低 ⭐⭐⭐ 高 ⭐⭐ 中
能否实时拒绝 ⚠️ 有 4-8h 延迟
粒度 用户/团队/Key/Tag 自定义 服务/用户级别
维护成本 低(AWS 托管)
可靠性 依赖代理服务可用性 依赖自建组件 ✅ AWS 平台级保障
推荐场景 实时限额,多模型管理 深度定制需求 兜底保护,最后防线

推荐组合LiteLLM(实时限额)+ AWS Budgets(兜底保护),两者互补形成双保险。即使 LiteLLM 服务异常,AWS Budgets 仍能确保费用不超限。


二、快速接入:利用 Bedrock API Key 与 LiteLLM 5 分钟上手

2.1 创建 Bedrock API Key

Amazon Bedrock 现已支持 Bearer Token 认证方式,大幅降低接入门槛:

# 创建 IAM 用户并授权
aws iam create-user --user-name bedrock-api-user
aws iam attach-user-policy \
  --user-name bedrock-api-user \
  --policy-arn arn:aws:iam::aws:policy/AmazonBedrockLimitedAccess

# 生成 API Key(30 天有效期)
aws iam create-service-specific-credential \
  --user-name bedrock-api-user \
  --service-name bedrock.amazonaws.com \
  --credential-age-days 30

2.2 验证 API Key

export TOKEN="你的API Key"

curl -s -X POST \
  "https://bedrock-runtime.us-east-1.amazonaws.com/model/us.anthropic.claude-opus-4-6-v1/converse" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "messages": [{"role": "user", "content": [{"text": "Say hello"}]}]
  }'

2.3 通过 LiteLLM SDK 调用

from litellm import completion

response = completion(
    model="bedrock/us.anthropic.claude-opus-4-6-v1",
    messages=[{"role": "user", "content": "Hello"}],
    api_key="你的API Key"
)
print(response.choices[0].message.content)
# 输出: Hello, it's great to meet you!

2.4 API Key vs 传统凭证对比

特性 API Key (Bearer Token) AWS Access Key
认证方式 Authorization: Bearer <key> SigV4 签名
配置复杂度 低,一个 Key 搞定 需要 Access Key + Secret Key + Region
适用场景 快速测试、开发环境 生产环境
安全性 有过期时间,自动失效 需手动管理轮换

三、业务花费监控:通过 Tag 实现多维度成本归因

3.1 架构设计

开发者/应用 → LiteLLM Proxy (Virtual Key + Tag) → Amazon Bedrock
                    ↓
              PostgreSQL (花费记录)
                    ↓
              Dashboard (按 Tag 查看花费)

3.2 部署 LiteLLM Proxy

创建配置文件 litellm_config.yaml

model_list:
  - model_name: bedrock-claude-opus-4-6
    litellm_params:
      model: bedrock/us.anthropic.claude-opus-4-6-v1
      api_key: os.environ/AWS_BEARER_TOKEN_BEDROCK

  - model_name: bedrock-claude-opus-4-7
    litellm_params:
      model: bedrock/us.anthropic.claude-opus-4-7
      api_key: os.environ/AWS_BEARER_TOKEN_BEDROCK

general_settings:
  master_key: sk-1234
  database_url: "postgresql://litellm:password@host:5432/litellm"

启动服务:

docker run \
  -v $(pwd)/litellm_config.yaml:/app/config.yaml \
  -e AWS_BEARER_TOKEN_BEDROCK="your-token" \
  -e LITELLM_MASTER_KEY="sk-1234" \
  -p 4000:4000 \
  ghcr.io/berriai/litellm-database:main-latest \
  --config /app/config.yaml

生产部署推荐使用 EKS 或 ECS,参考:EKS 部署方案 | ECS 部署方案

3.3 测试 Claude Opus 4.6 / 4.7

模型调用测试结果

两个模型均返回正常响应,Claude Opus 4.6 和 4.7 调用成功

3.4 创建带 Tag 的 Virtual Key

为不同业务线创建独立 Key,通过 Tag 实现花费归因:

# 游戏 QA 团队
curl -X POST 'http://localhost:4000/key/generate' \
  -H 'Authorization: Bearer sk-1234' \
  -d '{
    "models": ["bedrock-claude-opus-4-6", "bedrock-claude-opus-4-7"],
    "key_alias": "game1-qa",
    "metadata": {"tags": ["team:qa", "project:game1"]},
    "max_budget": 50
  }'

# 生产服务
curl -X POST 'http://localhost:4000/key/generate' \
  -H 'Authorization: Bearer sk-1234' \
  -d '{
    "models": ["bedrock-claude-opus-4-7"],
    "key_alias": "prod-service",
    "metadata": {"tags": ["team:prod", "env:production"]},
    "max_budget": 200,
    "rpm_limit": 60
  }'

3.5 LiteLLM Budget 多维度限额配置

LiteLLM 支持灵活的 Budget Window 机制,可同时设置多个时间窗口的预算限制:

LiteLLM Budget Window 配置

支持的限额维度:

配置项 说明 示例
Max Budget (USD) Key/User/Team 的总预算上限,超限立即拒绝 $50
Reset Budget 预算重置周期(n/a 表示不自动重置) n/a / monthly
Budget Windows - Daily 每日预算上限,每天 UTC 0 点自动重置 $5/天
Budget Windows - Monthly 每月预算上限,每月 1 日 UTC 0 点自动重置 $100/月
TPM Limit 每分钟 Token 数限制,防止瞬时大量消耗 100000

通过 API 配置 Budget Window:

curl -X POST 'http://localhost:4000/key/generate' \
  -H 'Authorization: Bearer sk-1234' \
  -H 'Content-Type: application/json' \
  -d '{
    "models": ["bedrock-claude-opus-4-7"],
    "key_alias": "game1-qa",
    "max_budget": 50,
    "budget_duration": "1mo",
    "metadata": {"tags": ["team:qa", "project:game1"]},
    "tpm_limit": 100000,
    "rpm_limit": 60
  }'

多窗口组合策略示例: - 日限 $5 — 防止单日异常消耗(如死循环调用) - 月限 $100 — 控制整体预算 - TPM 100K — 防止瞬时 Token 爆炸

超过任一窗口限额,LiteLLM 立即返回 429 Budget Exceeded,无需等待 AWS Billing 延迟。这是与 AWS Budgets 兜底方案的核心区别:LiteLLM 实时拦截,Budgets 延迟兜底,双保险。

3.6 花费监控效果

在 LiteLLM Dashboard 中可按 Tag 维度查看花费:

Spend Per Tag

按 Tag 维度展示花费,可清晰看到不同业务线的花费分布

Tag 花费 成功请求 Token 消耗
team:prod $0.0019 2 96
team:qa $0.0059 6 312
project:game1 $0.0059 6 312

3.7 进阶:基于 Tag 的模型路由

不同业务线可路由到不同模型版本(QA 用标准版、生产用高配版):

model_list:
  - model_name: claude-opus
    litellm_params:
      model: bedrock/us.anthropic.claude-opus-4-6-v1
      tags: ["tier:standard"]
  - model_name: claude-opus
    litellm_params:
      model: bedrock/us.anthropic.claude-opus-4-7
      tags: ["tier:premium"]

router_settings:
  enable_tag_filtering: true

四、AWS 原生兜底保护:Budgets 自动阻断超预算调用

为什么需要兜底? LiteLLM 提供实时限额,但作为应用层组件,存在服务中断、配置错误等风险。AWS Budgets 是平台级服务,由 AWS 基础设施保障,即使所有应用层防护失效,它仍然是费用的最后一道防线。

4.1 方案架构

Bedrock Budget 架构图

4.2 工作原理

用户调用 Bedrock API
       ↓
AWS 自动记录:谁调用的 + 花了多少钱(IAM Principal Cost Allocation)
       ↓
花费数据汇入 AWS Billing(有几小时延迟)
       ↓
AWS Budgets 持续检查:当前花费 vs 预算阈值
       ↓
├── 达到 80% → 发送告警邮件
└── 达到 100% → 触发 Budget Action
                        ↓
              自动给用户附加 Deny Policy
                        ↓
              用户再调用 Bedrock → 被拒绝(403)
                        ↓
              下个月初自动移除 Deny Policy → 恢复访问

关键安全原理 — IAM Deny 优先原则:AWS 中 Deny 永远优先于 Allow。即使用户有 AmazonBedrockFullAccess,只要同时附加了一个 Deny Bedrock 的策略,就100% 无法访问。这是 AWS IAM 的底层机制,不可绕过。

4.3 三个核心 AWS 服务

服务 作用 类比
IAM Principal-Based Cost Allocation 自动记录每次调用是谁发起的,按用户拆分账单 手机详单按号码统计
AWS Budgets 设置预算上限,到达阈值时发送通知 手机套餐余量提醒
AWS Budgets Actions 超预算时自动执行操作(附加 Deny 策略) 费用用完自动停机

4.4 完整配置步骤

Step 1:配置 IAM Principal-Based Cost Allocation(按用户追踪花费)

在 Billing Console 中激活 IAM Principal Tag,让 AWS 自动记录每次 Bedrock 调用的发起者:

# 给 IAM 用户打上业务标签
aws iam tag-user --user-name brclient --tags Key=Department,Value=AI-Team
aws iam tag-user --user-name brclient --tags Key=Project,Value=ChatBot

激活后在 Cost Explorer 中即可按用户查看 Bedrock 花费:

Billing 支持按用户查看花费

Step 2:创建 Deny Policy(准备中断策略)

aws iam create-policy \
  --policy-name "DenyBedrockAccess" \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Deny",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream",
        "bedrock:Converse",
        "bedrock:ConverseStream"
      ],
      "Resource": "*"
    }]
  }'

只 Deny 推理 API,不影响 ListModels 等只读操作。策略创建后不会立即生效,只有被附加到用户时才起作用。

Step 3:创建 Budget Action Role(授权 Budgets 执行操作)

# 创建 Role,允许 Budgets 服务 Assume
aws iam create-role \
  --role-name "BudgetActionRole" \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"Service": "budgets.amazonaws.com"},
      "Action": "sts:AssumeRole"
    }]
  }'

# 授权 Role 可以附加/移除策略(最小权限,仅限目标用户)
aws iam put-role-policy \
  --role-name "BudgetActionRole" \
  --policy-name "BudgetActionPermissions" \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": ["iam:AttachUserPolicy", "iam:DetachUserPolicy"],
      "Resource": "arn:aws:iam::<YOUR_ACCOUNT_ID>:user/brclient"
    }]
  }'

Step 4:创建 Budget + 告警 + 自动阻断

# 创建月度预算 $10,80% 和 100% 时告警
aws budgets create-budget \
  --account-id <YOUR_ACCOUNT_ID> \
  --budget '{
    "BudgetName": "Bedrock-Monthly-Budget",
    "BudgetLimit": {"Amount": "10", "Unit": "USD"},
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST",
    "CostFilters": {"Service": ["Amazon Bedrock"]}
  }' \
  --notifications-with-subscribers '[
    {"Notification": {"NotificationType": "ACTUAL", "ComparisonOperator": "GREATER_THAN", "Threshold": 80, "ThresholdType": "PERCENTAGE"},
     "Subscribers": [{"SubscriptionType": "EMAIL", "Address": "<YOUR_EMAIL>"}]},
    {"Notification": {"NotificationType": "ACTUAL", "ComparisonOperator": "GREATER_THAN", "Threshold": 100, "ThresholdType": "PERCENTAGE"},
     "Subscribers": [{"SubscriptionType": "EMAIL", "Address": "<YOUR_EMAIL>"}]}
  ]' --region us-east-1

# 创建 Budget Action:超 100% 自动附加 Deny Policy
aws budgets create-budget-action \
  --account-id <YOUR_ACCOUNT_ID> \
  --budget-name "Bedrock-Monthly-Budget" \
  --notification-type ACTUAL \
  --action-type APPLY_IAM_POLICY \
  --action-threshold '{"ActionThresholdValue": 100, "ActionThresholdType": "PERCENTAGE"}' \
  --definition '{"IamActionDefinition": {"PolicyArn": "arn:aws:iam::<YOUR_ACCOUNT_ID>:policy/DenyBedrockAccess", "Users": ["brclient"]}}' \
  --execution-role-arn "arn:aws:iam::<YOUR_ACCOUNT_ID>:role/BudgetActionRole" \
  --approval-model AUTOMATIC \
  --subscribers '[{"SubscriptionType": "EMAIL", "Address": "<YOUR_EMAIL>"}]' \
  --region us-east-1

4.5 按用户设置独立预算(IAM Principal Tag Filter)

AWS Budgets 已支持通过 Tag 维度按 iamPrincipal/user 过滤,可为单个用户创建独立预算:

Budget 支持 IAM Principal Tag Filter

通过 CLI 配置 Filter:

{
  "FilterExpression": {
    "And": [
      {"Dimensions": {"Key": "SERVICE", "Values": ["Amazon Bedrock"]}},
      {"Tags": {"Key": "iamPrincipal/user", "Values": ["brclient"]}},
      {"Not": {"Dimensions": {"Key": "RECORD_TYPE", "Values": ["Credit", "Refund"]}}}
    ]
  }
}

注意:IAM Principal Tag 需在 Billing Console → Cost Allocation Tags 中激活,约 24 小时后生效。

4.6 实测效果

当花费超过预算后,Budget Action 自动执行,DenyBedrockAccess 策略被附加到用户:

Budget Action 自动阻断测试结果

用户再次调用 Bedrock 时收到明确拒绝:

{
  "error": true,
  "message": "User: arn:aws:iam::****:user/brclient is not authorized to perform: bedrock:InvokeModelWithResponseStream on resource: arn:aws:bedrock:us-east-1:****:inference-profile/us.deepseek.r1-v1:0 with an explicit deny in an identity-based policy: arn:aws:iam::****:policy/DenyBedrockAccess"
}

4.7 Budget 兜底方案的核心优势

优势 说明
AWS 平台级保障 由 AWS 基础设施运行,不依赖任何第三方组件
Deny 不可绕过 IAM Deny 优先原则是 AWS 底层机制,任何 Allow 都无法覆盖
零运维 无需部署、监控额外服务,AWS 全托管
自动恢复 每月初自动重置,移除 Deny Policy,无需人工干预
审计可追溯 所有 Budget Action 执行记录可在 Console 中查看
成本极低 前 2 个 Action-enabled Budget 免费,之后 $0.10/天

4.8 注意事项


五、安全防护:防止 Token 盗刷与异常使用

AWS 上的安全性是共享责任模型:AWS 负责云基础设施的安全,客户负责云中工作负载的安全。以下方案充分利用 AWS 原生安全服务,构建多层纵深防御体系。

5.1 网络层防护:VPC Endpoint + Source IP 限制

通过 VPC Endpoint 确保 Bedrock 流量不经过公网,结合 IAM Condition 限制只能从指定 VPC 调用:

# 创建 Bedrock VPC Endpoint(流量走 AWS 内网)
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxxxxxxx \
  --service-name com.amazonaws.us-east-1.bedrock-runtime \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-xxx \
  --security-group-ids sg-xxx \
  --private-dns-enabled

IAM Policy 限制 Source VPC(附加到 Bedrock API Key 对应的 IAM User):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyBedrockOutsideVPC",
    "Effect": "Deny",
    "Action": "bedrock:*",
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {"aws:SourceVpc": "vpc-xxxxxxxx"}
    }
  }]
}

关键点:Bedrock API Key(Bearer Token)本质上绑定在 IAM User 上,因此该 User 的所有 IAM Policy Condition 对 API Key 同样生效。即使 API Key 泄露,从 VPC 外部调用会被 IAM Deny 拦截返回 403。

也可以用 aws:SourceIp 限制到具体 CIDR 范围:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyBedrockOutsideAllowedIPs",
    "Effect": "Deny",
    "Action": ["bedrock:InvokeModel", "bedrock:Converse",
               "bedrock:InvokeModelWithResponseStream", "bedrock:ConverseStream"],
    "Resource": "*",
    "Condition": {
      "NotIpAddress": {
        "aws:SourceIp": ["10.0.0.0/16", "172.31.0.0/16"]
      }
    }
  }]
}

VPC Endpoint Policy 限制只允许特定 Role 调用:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": ["arn:aws:iam::ACCOUNT:role/litellm-execution-role"]},
    "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
    "Resource": "arn:aws:bedrock:us-east-1::foundation-model/*"
  }]
}

Security Group 限制:

# Bedrock VPC Endpoint 的 SG 只允许来自 LiteLLM SG 的流量
aws ec2 authorize-security-group-ingress \
  --group-id sg-bedrock-endpoint \
  --protocol tcp --port 443 \
  --source-group sg-litellm

效果:即使 API Key 泄露,攻击者也无法从外部网络调用 Bedrock。三层防护(VPC Endpoint + IAM Condition + Security Group)确保只有 VPC 内的 LiteLLM 服务能访问 Bedrock。

5.2 利用 AWS 安全服务构建检测体系

AWS 服务 用途 安全价值
CloudTrail 记录所有 Bedrock API 调用 审计谁在什么时候从哪里调了什么模型
GuardDuty 检测异常 API 调用模式 发现异常地理位置、异常时间的调用
CloudWatch Anomaly Detection 对调用指标设置异常检测 自动发现用量突增
AWS Config 监控 IAM Policy 变更 防止权限被意外放大
Security Hub 集中查看安全发现 关联多个服务的告警,统一视图
Secrets Manager 存储 API Key 和密码 自动轮换,避免硬编码

CloudWatch 异常检测告警示例:

# 设置 Bedrock 调用量异常检测
aws cloudwatch put-anomaly-detector \
  --namespace AWS/Bedrock \
  --metric-name Invocations \
  --stat Sum \
  --dimensions Name=ModelId,Value=anthropic.claude-3-5-sonnet-20241022-v2:0

aws cloudwatch put-metric-alarm \
  --alarm-name "Bedrock-Invocation-Anomaly" \
  --metric-name Invocations \
  --namespace AWS/Bedrock \
  --threshold-metric-id ad1 \
  --comparison-operator GreaterThanUpperThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:us-east-1:ACCOUNT:security-alerts

CloudTrail 查询异常调用(在 CloudTrail Lake 中):

SELECT eventTime, userIdentity.arn, sourceIPAddress, eventName
FROM cloudtrail_logs
WHERE eventSource = 'bedrock-runtime.amazonaws.com'
  AND sourceIPAddress NOT LIKE '10.%'
  AND eventTime > '2024-01-01'
ORDER BY eventTime DESC

5.3 主动监控:Step Functions 定时扫描异常

EventBridge (每 5 分钟) → Step Functions → Lambda (扫描 LiteLLM API)
                                              ↓
                                         检测异常?
                                         ↓ 是
                                    自动禁用 Key + SNS 告警

检测维度:

检测项 判断逻辑 自动动作
单用户日用量突增 当日 > 过去 7 天均值 × 3 暂停 Key + 告警
非工作时间大量调用 凌晨 0-6 点请求量 > 阈值 告警
新 Key 突然大量使用 创建 < 24h 且用量 > 阈值 暂停 Key
短时间高频调用 1 分钟内 > N 次 触发 Rate Limit
单次请求 Token 异常 单次 output > 100K tokens 告警

自动响应 — 禁用异常 Key:

import requests

LITELLM_URL = "http://litellm-proxy:4000"
headers = {"Authorization": "Bearer sk-master-key"}

# 获取用量数据
spend_data = requests.get(f"{LITELLM_URL}/spend/keys", headers=headers).json()

# 发现异常后自动禁用 Key
requests.post(f"{LITELLM_URL}/key/block", headers=headers,
              json={"key": "sk-suspicious-key"})

5.4 LiteLLM 内置安全能力

功能 说明
Rate Limiting 按 Key/User/Team 设置 TPM/RPM 限制
Budget 硬限制 max_budget 超限自动拒绝,不会超支
IP 白名单 allowed_ips 限制 Key 使用来源
模型白名单 每个 Key 只能访问授权的模型
请求审计 所有请求记录到数据库,支持事后审计
Key 过期 所有 Key 设置 duration,到期自动失效
Guardrails 集成内容过滤,防止滥用

5.5 最小权限原则

层级 实践
IAM Role LiteLLM 的 IAM Role 仅授予 bedrock:InvokeModel,不给 bedrock:*
模型权限 按需开通模型,不要开通所有模型访问
LiteLLM Key 每个 Key 只授权需要的模型
用户预算 每个用户/团队设置合理的 budget 上限
Key 分离 按环境(dev/prod)、业务线、人员分离,禁止共享

5.6 安全最佳实践 Checklist


六、整体架构总结

┌─────────────────────────────────────────────────────────────────────┐
│                     多层纵深防御体系                                   │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  ┌──────────┐    ┌──────────────┐    ┌────────────────────────┐    │
│  │ 开发者    │───→│ LiteLLM Proxy │───→│ Amazon Bedrock         │    │
│  │ 应用服务  │    │              │    │ (VPC Endpoint 内网访问)  │    │
│  └──────────┘    │ • Virtual Key │    └────────────────────────┘    │
│                  │ • Tag 花费追踪 │                                  │
│                  │ • Rate Limit  │    ┌────────────────────────┐    │
│                  │ • Budget 限额  │───→│ PostgreSQL             │    │
│                  └──────────────┘    │ (花费 & 审计记录)        │    │
│                                      └────────────────────────┘    │
│                                                                     │
│  ┌───────────────────────────────────────────────────────────────┐ │
│  │              AWS 原生安全与监控层                                │ │
│  │                                                               │ │
│  │  🛡️ 网络层:VPC Endpoint + Source VPC 限制 + Security Group    │ │
│  │  🔑 身份层:IAM 最小权限 + Key 分离 + Secrets Manager          │ │
│  │  💰 成本层:AWS Budgets + Budget Action → 自动 Deny(兜底)    │ │
│  │  🔍 检测层:CloudTrail + GuardDuty + CloudWatch 异常检测       │ │
│  │  🤖 响应层:Step Functions → 异常检测 → 自动 Block Key + 告警  │ │
│  └───────────────────────────────────────────────────────────────┘ │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

七、总结

层次 方案 作用 AWS 安全保障
实时限额 LiteLLM Virtual Key + Budget 超限立即拒绝,精确到 Token
成本归因 LiteLLM Tag + Dashboard 按业务线/团队/环境追踪花费
兜底保护 AWS Budgets + Budget Actions 超预算自动阻断 IAM 用户 ✅ AWS 平台级,Deny 不可绕过
网络隔离 VPC Endpoint + IAM Condition Key 泄露也无法外部调用 ✅ AWS 网络层隔离
异常检测 CloudWatch + GuardDuty 主动发现异常调用模式 ✅ AWS 托管安全服务
自动响应 Step Functions + Lambda 发现异常自动禁用 Key ✅ Serverless,高可用
审计追溯 CloudTrail + LiteLLM 日志 事后追查,合规审计 ✅ 不可篡改的审计日志

通过以上多层防护,企业可以实现:

  1. AI 投入可预测 — 每个团队、每个项目的 AI 花费清晰可见,预算可控
  2. 意外账单可避免 — 实时限额(LiteLLM)+ 兜底保护(AWS Budgets)双保险,不会出现月底惊喜
  3. AI 资产不被盗 — 网络隔离 + 异常检测 + 自动响应,即使 Key 泄露也能快速止损
  4. 合规可审计 — CloudTrail 记录每一次调用,满足企业合规要求

AWS 安全承诺:通过 VPC Endpoint 确保数据不出 AWS 网络、IAM Deny 优先原则确保阻断不可绕过、CloudTrail 确保审计日志不可篡改。企业可以放心地在 AWS 上构建 AI 应用,安全性由 AWS 基础设施保障。


参考链接