AWS 发布 OpenAI Codex 接入 Amazon Bedrock 的企业级指南

开发者越来越多地将 Codex 与 Amazon Bedrock 结合使用，以探索陌生的代码、进行修改并处理重复性的工程工作。对于平台团队而言，挑战在于如何在不另建一套模型访问、身份和运维体系的情况下，让这些工具可用。

Codex 可以使用 Amazon Bedrock 通过受支持的 OpenAI 模型进行推理。在本文中，我们将展示如何将这条路径融入贵组织已经在使用的 AWS 身份、AWS Identity and Access Management (IAM)、区域和可观测性实践中。Codex 仍然运行在开发者工作站上。主要的设计选择在于：其模型请求如何到达 Amazon Bedrock，以及贵组织在哪里实施策略和运维控制。

我们先从一个最小权限的小型试点开始，并逐步完成在扩大访问范围之前需要关注的关键检查。示例使用 GPT-5.6 Sol。在开始试点之前，请查阅 Amazon Bedrock 各 AWS 区域支持的模型，以确认 Sol、Terra 或 Luna 在你计划使用的 AWS 区域和推理路径中可用。

推荐的默认方案：从原生 AWS 访问开始，进行一个小型的最小权限试点。当你希望使用 AWS 托管的网关基础设施进行路由或使用 Amazon Bedrock Guardrails 时，可选择 AgentCore Gateway（Amazon Bedrock AgentCore 的一项功能）。当平台团队希望在请求路径中实施控制时，可选择 LLM 网关。自定义集成是 LLM 网关模式的高级版本，而非快速入门方案。

这些示例来自开源的 Guidance for Codex on AWS 仓库。其中包含原生 AWS 访问、AgentCore Gateway、ECS 上的 LiteLLM、Portkey、AWS Distro for OpenTelemetry (ADOT) 以及本文后面会用到的 Amazon CloudWatch 设置的快速入门。请选择与你的架构相匹配的快速入门，将其用于试点，并根据你的环境进行适配。

选择你的推出路径

身份验证只是企业级推出的其中一环。还需要决定谁可以使用该服务、哪些模型和区域获得批准，并定义配置存放在哪里、要收集哪些遥测数据、使用量如何分配，以及允许使用哪些技能或 Model Context Protocol (MCP) 服务器。下表将这些需求映射到访问路径和负责团队。

选择当前能够提供所需控制的访问路径。满足需求的最直接路径通常具有最低的运维开销。

决策规则

当 AWS 身份和 IAM 控制足以满足试点需求时，原生 AWS 访问通常是首选起点。
Amazon Bedrock AgentCore 是一个用于大规模构建、连接和优化智能体的平台，支持任何框架或模型。在该平台内，AgentCore Gateway 适合希望获得 AWS 托管网关基础设施以进行路由、使用 Amazon Bedrock Guardrails 或相关控制的团队。
大型语言模型（LLM）网关适合已经运营网关或希望在请求路径中实施控制的组织。构建自定义网关是此选项的高级版本。

下图比较了三种推出路径中身份、路由、策略、遥测和运维责任的归属位置。

图 1：每种场景中 Codex 都运行在开发者工作站上。原生 AWS 访问使用 AWS IAM Identity Center；经过配置的 AgentCore Gateway 可以应用托管路由和 Guardrails；经过配置的 LLM 网关可以应用请求路径控制

原生 AWS 访问

如果原生 AWS 访问适合试点，该代码仓库的原生 AWS 访问快速入门提供了完整的流程和支持文件。以下简化的演示重点介绍最关键的步骤和检查项。

使用员工身份提供商进行登录

员工继续通过他们已在使用的身份提供商登录。在本例中，Okta 通过安全断言标记语言（SAML）处理身份验证，并通过跨域身份管理系统（SCIM）将用户和组配置到 IAM Identity Center 中。IAM Identity Center 随后颁发 Codex 所使用的临时 AWS 凭证。身份提供商不在 Codex 中配置。

前提条件

将每个试点用户添加到员工身份系统中的一个专用组，并将该组配置到 IAM Identity Center。将分配范围仅限于试点。
选择一个试点身份可用的 Amazon Bedrock 区域和 OpenAI 模型，如果所选 API 需要推理配置文件，则一并选择。针对所选账户、区域和推理路径分别检查 Sol、Terra 和 Luna。
仅授予 Codex 所使用的 Amazon Bedrock 模型推理权限、任何直接验证命令以及所选的可观测性目标。
准备一个非生产环境代码仓库，并指定一名回滚负责人。

配置

该试点有三项检查。首先，使用为 AWS 命令行界面（AWS CLI）配置的 IAM Identity Center 配置文件登录，并直接调用 Amazon Bedrock Runtime。接下来，将 Codex 指向已批准的模型。最后，运行一个安全的 Codex 任务。直接调用可以隔离 AWS 访问问题。最后一步确认 Codex 配置。

步骤 1：登录并验证 Amazon Bedrock Runtime 访问。

aws sso login --profile codex-bedrock
export AWS_PROFILE=codex-bedrock
aws bedrock-runtime converse
--model-id us.openai.gpt-5.6-sol
--messages '[{"role":"user","content":[{"text":"Reply with OK"}]}]'
--region us-east-2

此命令创建一个短期 AWS 会话，并检查该配置文件能否在所选区域调用所选模型。如果失败，请在配置 Codex 之前解决配置文件、区域、模型或推理配置文件访问或 IAM 权限问题。

步骤 2：配置 Codex 提供商。

# ~/.codex/config.toml (or managed user configuration)
model_provider = "amazon-bedrock"
model = "openai.gpt-5.6-sol"

[model_providers.amazon-bedrock.aws]
profile = "codex-bedrock"
region = "us-east-2"

model 值是 Codex 模型 ID。profile 选择 AWS IAM Identity Center 会话，region 告诉 Codex 使用哪个 AWS 区域。将这些设置保留在用户级或托管配置中，以防止代码仓库更改提供商。

验证试点并确认回滚

在添加用户之前，请确保试点能够访问已批准的模型、产生预期记录，并且可以被干净地禁用。

身份：aws sts get-caller-identity 返回预期的 IAM Identity Center 担任角色会话。
模型访问：试点配置文件通过为测试所选的 API 和区域调用已批准的模型。
Codex 访问：用户在非生产环境代码仓库中完成一个安全的只读任务，并且可以获得预期的请求路径证据。
证据与回滚：身份、调用、审计和可选的遥测记录均已存在。移除配置或 IAM Identity Center 分配，按照你的流程处理任何活动会话或等待其过期，并验证新的调用被拒绝。

观看原生 AWS 访问演示

该演示展示了完整的试点流程：员工登录、直接验证 Amazon Bedrock Runtime、配置 Codex 提供商，以及一个安全的测试任务。

图 2：原生 AWS 访问演示，涵盖员工登录、Amazon Bedrock Runtime 验证、Codex 提供商配置以及一个安全的试点任务

使用视频来核实检查的顺序以及添加更多试点用户前需收集的证据。

运行双用户身份隔离检查

需要两名用户来测试身份隔离。单个用户只能证明登录正常工作。第二个用户则测试归因是否保持独立。让两名试点用户分别登录并运行相同的无害任务。他们的 assumed-role 会话、审计记录以及（如已配置的）遥测记录应保持彼此独立。

下图展示了不同的试点身份在使用相同的已批准 Codex 和 Amazon Bedrock 路径时，应如何生成各自独立的 AWS 会话、请求证据和可选遥测数据。

图 3：使用可信身份注册进行归因。本地采集器只有在作为托管注册流程的一部分被部署并配置时，才能添加已批准的身份上下文

用于请求路径控制的网关路径

当你希望使用 AWS 托管的网关基础设施来实现集中式路由或 Amazon Bedrock Guardrails 时，AgentCore Gateway 是一个选项。如果你的组织已经在运行 LLM 网关，或希望在请求路径中强制执行控制，请改用该网关。在向试点用户开放之前，先验证所选的网关。

LLM 网关：在试点前进行验证

检查网关是否接受 Codex 的请求格式。
使用网关团队定义的登录或令牌流程。
在邀请试点用户之前，测试模型路由、监控、故障处理和回滚。

自定义企业集成

自定义企业集成是 LLM 网关模式中最复杂的一种形式。只有当原生 AWS 访问、AgentCore Gateway 和现有网关都无法满足特定需求时，才考虑采用它。其结果是多出一个需要设计、安全加固、测试、支持和运维的服务，因此平台工程和安全团队必须从一开始就负责管理它。

观测、治理与成本分摊

Codex OpenTelemetry、Amazon Bedrock 服务记录、AWS 身份记录和账单数据回答的是不同的问题。Codex OpenTelemetry 描述客户端活动。Amazon Bedrock 服务指标和模型调用日志（启用后）显示服务端活动。AWS 身份记录和 AWS Cost and Usage Report（CUR）提供身份和计费用量证据。请针对你所部署的路径将它们关联起来，不要把令牌用量当作成本报告来呈现。

明确 Codex 可能通过所选模型路径发送哪些代码、提示词、文件和工具输出。除非组织已批准该数据流，否则应排除机密和受限数据。要求开发人员在合并前审查并测试生成的更改。遥测并不能证明正确性或安全性。

Codex 的 OpenTelemetry 指标

在可观测性方面，本文使用代码仓库中的 ADOT 采集器配置和 CloudWatch 控制面板，详见监控与运维指南。将该配置部署到每台受管的试点设备上，然后运行一个安全的 Codex 任务。

代码仓库提供了配置文件。按照其部署说明安装已批准的 ADOT 采集器，并配置其 AWS 身份验证。

# ~/.codex/config.toml or managed user configuration
[otel]
environment = "pilot"
log_user_prompt = false
metrics_exporter = { "otlp-http" = { endpoint = "http://127.0.0.1:4318/v1/metrics", protocol = "binary" } }

验证仓库路径：运行一个安全的 Codex 任务，并确认预期的运维指标出现在受管的 CloudWatch 控制面板上。

遥测平面	示例	归因边界
Codex OpenTelemetry 指标	令牌用量、轮次、API 请求数、请求时长、工具调用、会话来源。	只有在本地采集器添加了经过验证的身份属性之后，才能按用户和团队对仪表板进行分组。
Amazon Bedrock 服务指标	调用次数、延迟、输入 token 数、输出 token 数、客户端错误、服务器错误。	为你所选择的 Runtime、Mantle 或 AgentCore 路径使用文档中记录的命名空间、指标名称和维度。
AWS 身份证据、模型调用日志和 CUR	经扮演角色的单点登录（SSO）主体加上计费的 Bedrock 账单项。	对于原生 IAM Identity Center 访问，采用调用者身份分摊的 CUR 2.0 可以暴露 SSO 主体。网关路径需要网关遥测和支出记录才能进行最终用户分摊。

Amazon CloudWatch 仪表板与证据

Guidance for Codex on AWS 仓库中的 Amazon CloudWatch Coding Agent Insights 托管仪表板显示了通过 ADOT 采集的 Codex 运营指标。可以用它了解客户端活动；当需要归因或成本证据时，请单独使用 AWS 身份、审计和账单记录。

问题	决策	需保留的证据
是谁调用了模型？	使用与你所选路径对应的 AWS 身份/审计数据源。	试点身份记录和请求关联信息（如可用）。
费用是多少？	使用账单数据获得实际费用，并清晰标注任何推断出的分摊方式。	CUR 数据源、分摊方法以及已知的不确定性。
能否阻止不安全或高成本的行为？	使用告警进行检测。使用 IAM 和托管客户端控制各自的访问与操作边界。当需要请求路径层面的强制执行（如硬性预算或速率限制）时，使用网关策略。	控制测试结果和回滚流程。

观看 Codex OTel 与 CloudWalk 演练

该演练展示了如何查询 Codex OpenTelemetry 指标，并确认预期的 token 和请求数据出现在 Amazon CloudWatch 中。

图 4：Amazon CloudWatch 仪表板中显示的 Codex OpenTelemetry 指标

该示例在 Amazon CloudWatch Query Studio 中验证了别名指标结果，并展示仪表板如何呈现 Codex 客户端活动。

统一团队行为

在基础设施路径跑通之后，接下来关注开发者体验。仓库指南、托管插件、hooks 以及经批准的 MCP 服务器可以让推广保持一致，而无需每个团队自行组装配置。

插件

由组织拥有的插件是分发共享技能、hooks 和经批准的 MCP 集成的实用方式。为每个插件指定负责人和版本，在发布前审查变更，并仅通过经批准的渠道发布。用试点小组测试更新，并保留有文档记录的移除路径。

一个插件可能包含 MCP 服务器配置，但这并不意味着所有捆绑的工具都经过批准。只允许组织已审查过的服务器和工具，并在需要时进行用户确认。

Hooks

Hooks 可以在 hooks.json 中声明，也可以直接在配置中声明。保持文档中记录的事件大小写形式，并通过经批准的端点工具部署组织拥有的策略命令。

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "/usr/local/bin/company-pre-tool-policy"
timeout = 30

在 PreToolUse、PostToolUse 或 SessionStart 能解决特定需求的地方使用它们。在更广泛部署之前，测试允许、拒绝、超时和端点断开时的行为。

MCP

MCP 服务器将 Codex 连接到另一个系统，因此每台服务器都会创建一个独立的信任边界。仅向需要的用户和工具授予访问权限，通过经批准的 OAuth 或密钥管理流程管理凭证，并要求对会更改外部系统的工具进行确认。不要将 MCP 凭证放在模型提供商的配置中。

分阶段推出

下图定义了从准备、试点、扩展到全组织标准化各阶段推进所需的范围和证据。

图 5：先从受控试点开始，在验证访问路径和运营证据后扩展，并在运营模式得到验证后标准化推广

管理员启动清单

在变更记录中记录所选路径、负责团队、区域和模型。
将试点身份的权限限制在所需范围内，并记录签发的凭证或令牌的处理方式。
运行一项非生产测试，涵盖登录、模型可用性和一个安全的 Codex 任务。
检查已部署版本的遥测和审计输出，而不是假设示例内容原样适用。
在成本报告中将实际计费金额与估算值分开。
演练恢复流程：移除配置或分配，按照经批准的程序处理任何活动会话或等待其过期，并验证新的调用会被拒绝。

清理

当试点结束或必须禁用访问时，移除不再需要的推出资源。

从受管设备中移除 Codex 模型提供商和遥测配置。移除 IAM Identity Center 试点分配或网关访问，撤销试点令牌和密钥，并按照经批准的程序处理活动会话。卸载或禁用 ADOT 收集器，如果试点 CloudWatch 控制面板和警报未与其他工作负载共享，则将其删除。通过确认新的模型调用被拒绝且已退役的遥测资源不再接收新数据来验证清理是否完成。

配置边界

将模型提供商、凭证和组织遥测设置保留在用户级或受管配置中。项目级的 .codex/config.toml 是仓库范围的配置：将其作为代码进行审查，但不要将其视为企业级强制边界。AGENTS.md 适用于持久的仓库级指导，例如测试命令和编码规范，但它也不是强制边界。

设置类型	推荐位置	原因
模型提供商、凭证、区域	用户级或受管配置	这些是端点和企业层面的选择，而非仓库默认设置。
OpenTelemetry 导出器	用户级或受管配置	遥测目标和数据处理是组织层面的控制。
仓库指令	AGENTS.md	提供持久的指导，但不是强制边界。
权限要求	组织管理的 `requirements.toml`	约束所支持的安全敏感客户端选择。

结论与后续步骤

Codex 可以使用 Amazon Bedrock 通过受支持的 OpenAI 模型进行推理。从满足需求的最简单的访问路径开始，通过小规模试点验证身份和模型路径，只有在网关或客户端控制能解决特定需求时才添加它们。

AgentCore Gateway 为路由或 Amazon Bedrock Guardrails 提供了 AWS 托管的网关选项。当平台团队希望在请求路径中实施控制时，选择 LLM 网关。只有在现有路径无法满足已记录的需求时，才构建自定义集成。

分阶段扩展，并利用每个阶段的证据来决定下一步。Codex on AWS 指南代码库包含了本文所使用的持续维护的配置和验证流程。