Codex now runs through Amazon Bedrock: AWS shows an IAM-based pilot with no new stack

When a company wants to hand developers an AI coding agent, the result is usually a second infrastructure: separate keys, separate bills, separate audit. For a platform team, that is needless headache. AWS has published a detailed guide on routing Codex through Amazon Bedrock without building a parallel stack.

Codex itself still runs on the developer's workstation. Only the route changes: requests to supported OpenAI models go through Bedrock. The examples use GPT-5.6 Sol, but before you start, check separately whether Sol, Terra or Luna is available in your account, region and inference path. Availability may differ between them.

Three paths, one default

AWS offers three options.

• Native AWS Access. Sign-in via IAM Identity Center, with no additional services. This is the recommended starting point.
• AgentCore Gateway. A managed AWS gateway for routing and Bedrock Guardrails.
• LLM Gateway, such as LiteLLM on ECS or Portkey. It fits if you already run such a gateway or need hard budgets and limits in the request path itself.

AWS explicitly calls a custom integration an advanced gateway option, not a quick start. It is one more service that you have to design, secure and maintain.

The rule is simple: take the lightest path that meets your requirements. For a pilot, native access is usually enough.

What a safe pilot looks like

Employees sign in through their usual identity provider, for example Okta over SAML. The provider pushes users and groups into IAM Identity Center via SCIM, and Identity Center issues temporary AWS credentials for Codex. No identity provider is configured in Codex itself.

Verification takes three steps.

1. Sign in with aws sso login and call bedrock-runtime converse directly with the target model. If something is broken, this exposes the problem right away as a profile, region or IAM-permission issue rather than a Codex issue.
2. Add the amazon-bedrock provider, the model, the profile and the region to ~/.codex/config.toml.
3. Run a safe task in a non-production repository.

It is better to keep the config in a user-level or managed file, so that a repository cannot override the provider. Before you start, also assign someone to be responsible for rollback.

AWS also asks you to verify identity isolation. One user only proves that sign-in works. Two people run the same harmless task, and their sessions, audit records and telemetry must stay separate. Rollback is tested too: remove the setting or the Identity Center assignment, wait for the session to expire, and confirm that a new call is rejected.

Observability and cost: don't mix up the sources

The most useful thing about the guide is that it does not blend different kinds of data.

• Codex telemetry via OpenTelemetry shows client activity: tokens, turns, tool calls. It can be tied to individual people only after a local collector adds verified identity attributes.
• Bedrock metrics and logs show what happened on the service side.
• Identity and money come from AWS audit and the CUR report. For native access, CUR 2.0 with allocation by caller identity can show the SSO principal.

Token volume cannot be passed off as a spending report. Take the actual price from billing, and label any estimated allocation as an estimate.

For the pilot, the repository includes a ready-made ADOT collector configuration and a CloudWatch dashboard.

Limitations and what to do

The guide was written by an AWS platform team for its own services, so it says nothing about alternatives outside the ecosystem. Telemetry does not prove that code is correct, so review and testing of generated changes remain mandatory. Secrets and restricted data must not be sent through the model unless that is explicitly approved.

Before rolling out to teams, standardize the environment. Organization plugins distribute skills and hooks, and each one should have an owner and a version. MCP servers open a separate trust boundary: let only the right people and tools reach them, and keep credentials out of the model provider's configuration. Test hooks such as PreToolUse against allow, deny, timeout and disabled-endpoint scenarios.

The practical takeaway for a platform team is this. Start with two people, native access and a clear rollback plan. Expand only after the evidence on identity, calls and costs lines up. Add a gateway when you need hard limits, not just because it exists.