当团队希望让 Codex 使用 Amazon Bedrock 中托管的 OpenAI 模型时，直接给每位开发者分发 AWS 凭证并不是唯一方案。一个更便于集中治理的做法，是在 Amazon ECS 与 AWS Fargate 上运行自管 LiteLLM 网关，由它暴露兼容 OpenAI Responses API 的入口，并统一处理身份、预算、限流和遥测。
这套架构的关键不只是“转发请求”。LiteLLM 位于 Codex 和 Bedrock 之间，成为模型别名、虚拟密钥和消费策略的执行点；ECS 则负责容器运行、扩缩容和故障恢复。
请求是怎样流动的
典型调用链如下：
Codex CLI
-> HTTPS /v1/responses
-> LiteLLM on ECS/Fargate
-> AWS SDK credential chain / ECS task role
-> Amazon Bedrock
-> OpenAI model
这里需要分清两种身份：
- Codex 使用 LiteLLM 虚拟密钥访问网关。密钥可以绑定用户、团队、模型、预算以及 RPM/TPM 限额。
- LiteLLM 容器通过 ECS task role 调用 Bedrock。AWS 长期访问密钥不应写进镜像、任务定义或 Codex 配置。
因此，开发者不需要直接获得 Bedrock 权限，而平台团队仍然可以按人或按项目追踪成本。生产环境还应将网关置于负载均衡器之后，启用 TLS，并限制安全组入口；如果它只供公司网络使用，可以通过私有子网、内部 ALB、VPN 或其他私有连接暴露。
先在本地验证模型路由
下面是一个可改造的最小 LiteLLM 配置。示例假设当前 LiteLLM 版本支持 Responses API，并使用 openai.gpt-oss-120b-1:0 作为 Bedrock 模型 ID；部署前应在目标 AWS 区域确认模型可用性、准确 ID 和访问授权。
# litellm-config.yaml
model_list:
- model_name: codex-bedrock
litellm_params:
model: bedrock/openai.gpt-oss-120b-1:0
aws_region_name: us-west-2
litellm_settings:
success_callback:
- prometheus
failure_callback:
- prometheus
general_settings:
master_key: os.environ/LITELLM_MASTER_KEY
在已经配置 AWS 凭证的开发机上，可以这样启动网关：
export AWS_REGION=us-west-2
export LITELLM_MASTER_KEY='replace-with-a-long-random-secret'
docker run --rm \
-p 4000:4000 \
-e AWS_REGION \
-e AWS_ACCESS_KEY_ID \
-e AWS_SECRET_ACCESS_KEY \
-e AWS_SESSION_TOKEN \
-e LITELLM_MASTER_KEY \
-v "$PWD/litellm-config.yaml:/app/config.yaml:ro" \
ghcr.io/berriai/litellm:main-stable \
--config /app/config.yaml --port 4000
再用 Responses API 检查端到端链路：
curl --fail-with-body http://localhost:4000/v1/responses \
-H "Authorization: Bearer $LITELLM_MASTER_KEY" \
-H 'Content-Type: application/json' \
-d '{
"model": "codex-bedrock",
"input": "Return only the result of 19 * 23."
}'
本地测试中的 AWS 环境变量只用于快速验证。迁移到 Fargate 后，应删除这些变量，让 AWS SDK 自动取得 task role 的临时凭证。
把网关放进 ECS/Fargate
生产任务定义可以从下面的容器片段开始改造。镜像最好固定到经过验证的版本或 digest，而不是长期使用浮动标签；主密钥则从 AWS Secrets Manager 注入。
{
"family": "litellm-gateway",
"networkMode": "awsvpc",
"requiresCompatibilities": ["FARGATE"],
"cpu": "1024",
"memory": "2048",
"executionRoleArn": "arn:aws:iam::123456789012:role/litellm-execution-role",
"taskRoleArn": "arn:aws:iam::123456789012:role/litellm-bedrock-role",
"containerDefinitions": [
{
"name": "litellm",
"image": "ghcr.io/berriai/litellm:main-stable",
"essential": true,
"command": ["--config", "/app/config.yaml", "--port", "4000"],
"portMappings": [
{"containerPort": 4000, "protocol": "tcp"}
],
"environment": [
{"name": "AWS_REGION", "value": "us-west-2"}
],
"secrets": [
{
"name": "LITELLM_MASTER_KEY",
"valueFrom": "arn:aws:secretsmanager:us-west-2:123456789012:secret:litellm/master-key"
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/litellm",
"awslogs-region": "us-west-2",
"awslogs-stream-prefix": "gateway"
}
}
}
]
}
这个片段仍需补充配置文件的交付方式，例如构建进内部镜像，或在容器启动时从受控存储获取。不要把主密钥或数据库密码写入配置文件。
litellm-bedrock-role 应按实际模型和区域授予最小 Bedrock 推理权限。执行角色则只负责拉取镜像、读取 Secrets Manager 密钥和写入 CloudWatch Logs，两者不要混用。若启用 LiteLLM 虚拟密钥、预算和持久化消费记录，还需要为网关配置受支持的数据库，并将数据库连接串放入 Secrets Manager。
给 Codex 配置 Responses API
假设 ALB 地址是 https://llm.example.internal，可以在 Codex 配置中声明自定义模型提供方。不同 Codex 版本的字段可能变化，应用前应以当前版本的配置说明为准。
# ~/.codex/config.toml
model = "codex-bedrock"
model_provider = "litellm"
[model_providers.litellm]
name = "Company LiteLLM Gateway"
base_url = "https://llm.example.internal/v1"
env_key = "LITELLM_API_KEY"
wire_api = "responses"
然后只把分配给当前用户或自动化任务的虚拟密钥放入环境变量：
export LITELLM_API_KEY='replace-with-a-scoped-virtual-key'
codex
不要让普通 Codex 客户端使用 LiteLLM master key。主密钥用于网关管理，应由平台侧保管。实际的用户密钥可以限制为 codex-bedrock 模型，并配置预算周期、最大消费额、RPM、TPM 和失效时间。CI、个人开发机和共享服务账号也应使用不同密钥，避免审计记录混在一起。
遥测要覆盖网关与云端
网关至少需要记录请求数量、延迟、错误率、模型别名、调用身份和 token 使用量。Prometheus 回调可以提供 LiteLLM 侧指标，CloudWatch Logs 则负责收集 ECS 容器日志；Bedrock 和 AWS 审计数据用于回答“哪个 task role 在何时调用了什么资源”。
日志中不要记录完整提示词、生成结果或原始 Authorization 头。代码仓库可能通过 Codex 进入上下文，提示词遥测因此需要默认脱敏，并明确保留期限和访问范围。还应为 429、5xx、预算耗尽和 Bedrock 限流分别设置告警，因为这些故障的处理方式不同。
什么时候采用其他接入方式
直接通过 IAM Identity Center 访问适合 AWS 身份体系成熟、希望减少代理层，并且每位调用者都能获得受控 AWS 身份的团队。它缩短了请求链路，但跨模型预算、统一 API 密钥和网关级遥测需要在其他位置实现。
托管 Portkey 部署更适合希望减少网关运维工作、同时仍需策略和观测能力的团队。代价是引入额外供应商边界，需要评估数据路径、区域、合规、可用性和成本。
自管 LiteLLM 的优势是控制面掌握在自己手中，并能用一套兼容接口服务 Codex。相应地，团队必须负责升级、容量、数据库、密钥轮换、故障恢复和安全补丁。
上线前检查
- 确认目标 Bedrock 模型在部署区域可用，并完成所需的模型访问配置。
- 使用 ECS task role 调用 Bedrock，不在任务中保存长期 AWS 密钥。
- 通过 TLS 和网络边界保护 LiteLLM，只开放必要入口。
- 为个人、CI 和服务分别签发虚拟密钥，并配置模型范围、预算和限流。
- 固定 LiteLLM 镜像版本，测试
/v1/responses与当前 Codex 版本的兼容性。 - 验证日志脱敏、指标采集、费用归属以及 429/5xx 告警。
- 在扩容前做并发和长上下文压测，确认 ALB 超时、ECS 健康检查与 Bedrock 配额匹配。
这类网关的价值最终体现在治理，而不是多增加一跳 HTTP。只有当身份、成本限制和可观测性一起落地时，它才真正适合承载团队级 Codex 流量。