{"slug": "openai-codex-on-amazon-bedrock", "title": "OpenAI Codex on Amazon Bedrock", "summary": "OpenAI and AWS published guidance for running OpenAI Codex on Amazon Bedrock, letting developers use Codex for inference with supported OpenAI models while keeping model access inside existing AWS identity, IAM, Regional and observability practices. The post recommends starting with a small, least-privilege pilot using Native AWS Access, with AgentCore Gateway as an option when AWS-managed routing or Amazon Bedrock Guardrails are needed and an LLM Gateway when a platform team must enforce controls in the request path; the examples use GPT-5.6 Sol, and the open source Guidance for Codex on AWS repository includes quick starts for Native AWS Access, AgentCore Gateway, LiteLLM on ECS, Portkey and the AWS Distro for OpenTelemetry (ADOT).", "body_md": "## [Artificial Intelligence](https://aws.amazon.com/blogs/machine-learning/)\n\n# OpenAI Codex on Amazon Bedrock\n\nDevelopers increasingly use Codex with Amazon Bedrock to explore unfamiliar code, make changes, and handle repetitive engineering work. For platform teams, the challenge is to make those tools available without creating a second model-access, identity, and operations stack.\n\nCodex can use Amazon Bedrock for inference with supported OpenAI models. In this post, we show how to fit that path into the AWS identity, AWS Identity and Access Management (IAM), Regional, and observability practices your organization already uses. Codex still runs on the developer workstation. The main design choice is how its model requests reach Amazon Bedrock and where your organization applies policy and operational controls.\n\nWe begin with a small, least-privilege pilot and work through the checks that matter before access expands. The examples use GPT-5.6 Sol. Before starting the pilot, review [Supported models by AWS Region in Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/models-regions.html) to confirm that Sol, Terra, or Luna is available in the AWS Region and inference path you plan to use.\n\n**Recommended default:** Start with Native AWS Access for a small, least-privilege pilot. Choose AgentCore Gateway, a capability of Amazon Bedrock AgentCore, when you want AWS managed gateway infrastructure for routing or Amazon Bedrock Guardrails. Choose an LLM Gateway when a platform team wants to enforce controls in the request path. A custom integration is the advanced version of the LLM Gateway pattern, not a quick start.\n\nThe examples come from the open source Guidance for Codex on AWS repository. It includes quick starts for Native AWS Access, AgentCore Gateway, LiteLLM on ECS, Portkey, the AWS Distro for OpenTelemetry (ADOT), and the Amazon CloudWatch setup used later in the post. Choose the quick start that matches your architecture, use it for the pilot, and adapt it to your environment.\n\n## Choose your rollout path\n\nAuthentication is only one part of an enterprise rollout. Decide who can use the service and which models and Regions are approved. Also define where configuration lives, what telemetry to collect, how usage is allocated, and which skills or Model Context Protocol (MCP) servers are allowed. The following table maps those needs to an access path and an owning team.\n\nChoose the access path that provides the controls you need now. The most straightforward path that meets the requirement usually has the lowest operational overhead.\n\n### Decision rules\n\n1. Native AWS Access is the usual starting point when AWS identity and IAM controls are enough for the pilot.\n2. Amazon Bedrock AgentCore is a platform to build, connect, and optimize agents at scale, with any framework or model. Within the platform, AgentCore Gateway fits teams that want AWS managed gateway infrastructure for routing, Amazon Bedrock Guardrails, or related controls.\n3. A large language model (LLM) Gateway fits organizations that already operate a gateway or want to enforce controls in the request path. Building a custom gateway is the advanced version of this option.\n\nThe following diagram compares where identity, routing, policy, telemetry, and operational ownership sit across the three rollout paths.\n\n## Native AWS Access\n\nIf Native AWS Access fits the pilot, the repository’s [Native AWS Access quick start](https://github.com/openai-on-aws/guidance-codex/blob/main/docs/QUICKSTART_NATIVE_AWS_ACCESS.md) provides the complete procedure and supporting files. The following abbreviated walkthrough focuses on the sequence and the checks that matter most.\n\n### Use your workforce identity provider for sign-in\n\nEmployees continue to sign in through the identity provider they already use. In this example, Okta handles authentication through Security Assertion Markup Language (SAML) and provisions users and groups into IAM Identity Center through System for Cross-domain Identity Management (SCIM). IAM Identity Center then issues the temporary AWS credentials used by Codex. The identity provider is not configured in Codex.\n\n### Prerequisites\n\n1. Add each pilot user to a dedicated group in the workforce identity system and provision that group to IAM Identity Center. Keep the assignment limited to the pilot.\n2. Choose an Amazon Bedrock Region and an OpenAI model available to the pilot identity, plus an inference profile if the selected API requires one. Check Sol, Terra, and Luna separately for the chosen account, Region, and inference path.\n3. Grant only the Amazon Bedrock model inference permissions used by Codex, any direct validation commands, and the selected observability destination.\n4. Prepare a non-production repository and name a rollback owner.\n\n### Configure\n\nThe pilot has three checks. First, sign in using the IAM Identity Center profile configured for the AWS Command Line Interface (AWS CLI) and call Amazon Bedrock Runtime directly. Next, point Codex to the approved model. Finally, run a safe Codex task. The direct call isolates AWS access problems. The final step confirms the Codex configuration.\n\n**Step 1: Sign in and validate Amazon Bedrock Runtime access.**\n\nThis command creates a short-lived AWS session and checks whether the profile can invoke the chosen model in the chosen Region. If it fails, resolve the profile, Region, model or inference-profile access, or IAM permissions before configuring Codex.\n\n**Step 2: Configure the Codex provider.**\n\nThe model value is the Codex model ID. The profile selects the AWS IAM Identity Center session, and region tells Codex which AWS Region to use. Keep these settings in user-level or managed configuration so a repository cannot change the provider.\n\n### Verify the pilot and confirm rollback\n\nBefore adding users, make sure the pilot reaches the approved model, produces the expected records, and can be disabled cleanly.\n\n1. Identity: `aws sts get-caller-identity` returns the expected IAM Identity Center assumed-role session.\n2. Model access: The pilot profile invokes the approved model through the API and Region selected for the test.\n3. Codex access: The user completes a safe, read-only task in a non-production repository, and the expected request-path evidence is available.\n4. Evidence and rollback: The identity, invocation, audit, and optional telemetry records are present. Remove the configuration or IAM Identity Center assignment, handle any active session according to your procedure or wait for it to expire, and verify that a new invocation is denied.\n\n### Watch the Native AWS Access walkthrough\n\nThe walkthrough shows the complete pilot sequence: workforce sign-in, direct Amazon Bedrock Runtime validation, Codex provider configuration, and a safe test task.\n\nFigure 2: Native AWS Access walkthrough covering workforce sign-in, Amazon Bedrock Runtime validation, Codex provider configuration, and a safe pilot task\n\nUse the video to verify the order of the checks and the evidence to collect before adding more pilot users.\n\n## Run a two-user identity-isolation check\n\nTwo users are required to test identity isolation. A single user shows that sign-in works. A second user tests whether attribution remains distinct. Have two pilot users sign in separately and run the same harmless task. Their assumed-role sessions and audit records, and telemetry records if configured, should remain distinct.\n\nThe following diagram shows how separate pilot identities should produce separate AWS sessions, request evidence, and optional telemetry while using the same approved Codex and Amazon Bedrock path.\n\n## Gateway paths for request-path controls\n\nAgentCore Gateway is an option when you want AWS managed gateway infrastructure for centralized routing or Amazon Bedrock Guardrails. If your organization already runs an LLM Gateway or wants to enforce controls in the request path, use that gateway instead. Validate the selected gateway before exposing it to pilot users.\n\n### LLM Gateway: Validate before a pilot\n\n1. Check that the gateway accepts the Codex request format.\n2. Use the sign-in or token flow defined by the gateway team.\n3. Before inviting pilot users, test model routing, monitoring, failure handling, and rollback.\n\n## Custom enterprise integration\n\nA custom enterprise integration is the most involved form of the LLM Gateway pattern. Consider it only when Native AWS Access, AgentCore Gateway, and an existing gateway cannot meet a specific requirement. The result is another service to design, secure, test, support, and operate, so platform engineering and security need to own it from the start.\n\n## Observe, govern, and allocate cost\n\nCodex OpenTelemetry, Amazon Bedrock service records, AWS identity records, and billing data answer different questions. Codex OpenTelemetry describes client activity. Amazon Bedrock service metrics and model invocation logs show service-side activity when enabled. AWS identity records and the AWS Cost and Usage Report (CUR) provide identity and billed-usage evidence. Correlate them for the path you deploy, and do not present token volume as a cost report.\n\nDefine what code, prompts, files, and tool output Codex might send through the selected model path. Exclude secrets and restricted data unless the organization has approved that data flow. Require developers to review and test generated changes before merge. Telemetry does not establish correctness or safety.\n\n### OpenTelemetry metrics from Codex\n\nFor observability, this post uses the ADOT collector configuration and CloudWatch dashboard from the repository’s [monitoring and operations guidance](https://github.com/openai-on-aws/guidance-codex/blob/main/docs/operate-monitoring.md). Deploy that configuration to each managed pilot device, then run a safe Codex task.\n\nThe repository provides the configuration files. Follow its deployment instructions to install the approved ADOT collector and configure its AWS authentication.\n\nValidate the repository path: run a safe Codex task and confirm that the expected operational metrics appear on the managed CloudWatch dashboard.\n\n| **Telemetry plane** | **Examples** | **Attribution boundary** | \n| Codex OpenTelemetry metrics | Token usage, turns, API requests, request duration, tool calls, session source. | Per-user and team dashboard grouping only after the local collector adds validated identity attributes. | \n| Amazon Bedrock service metrics | Invocations, latency, input tokens, output tokens, client errors, server errors. | Use the documented namespace, metric names, and dimensions for the selected Runtime, Mantle, or AgentCore path. | \n| AWS identity evidence, model invocation logs, and CUR | Assumed-role single sign-on (SSO) principal plus billed Bedrock line items. | For Native IAM Identity Center access, CUR 2.0 with caller-identity allocation can expose the SSO principal. Gateway paths require gateway telemetry and spend records for end-user allocation. | \n\n### Amazon CloudWatch dashboard and evidence\n\nThe Amazon CloudWatch Coding Agent Insights managed dashboard in the Guidance for Codex on AWS repository shows Codex operational metrics collected through ADOT. Use it to understand client activity, and use AWS identity, audit, and billing records separately when you need attribution or cost evidence.\n\n| **Question** | **Decision** | **Evidence to keep** | \n| Who invoked the model? | Use the AWS identity/audit source for the path you selected. | Pilot identity record and request correlation, where available. | \n| What did it cost? | Use billing data for actual charge and label any inferred allocation clearly. | CUR source, allocation method, and known uncertainty. | \n| Can we stop unsafe or expensive behavior? | Use alarms for detection. Use IAM and managed client controls for their respective access and action boundaries. Use gateway policy when request-path enforcement, such as hard budgets or rate limits, is required. | Control test results and rollback procedure. | \n\n### Watch the Codex OTel and CloudWatch walkthrough\n\nThe walkthrough shows how to query Codex OpenTelemetry metrics and confirm that the expected token and request data appears in Amazon CloudWatch.\n\nFigure 4: Codex OpenTelemetry metrics shown in an Amazon CloudWatch dashboard\n\nThe example validates the aliased metric result in Amazon CloudWatch Query Studio and shows how the dashboard represents Codex client activity.\n\n## Standardize team behavior\n\nAfter the infrastructure path is working, turn to the developer experience. Repository guidance, m", "url": "https://wpnews.pro/news/openai-codex-on-amazon-bedrock", "canonical_source": "https://aws.amazon.com/blogs/machine-learning/openai-codex-on-amazon-bedrock/", "published_at": "2026-11-11 23:35:47+00:00", "updated_at": "2026-11-11 23:51:10.234155+00:00", "lang": "en", "topics": ["ai-tools", "ai-agents", "ai-infrastructure", "developer-tools", "agent-protocols"], "entities": ["OpenAI", "Amazon Bedrock", "Codex", "AWS Identity and Access Management", "Amazon Bedrock AgentCore", "GPT-5.6 Sol", "LiteLLM", "Portkey"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/openai-codex-on-amazon-bedrock", "markdown": "https://wpnews.pro/news/openai-codex-on-amazon-bedrock.md", "text": "https://wpnews.pro/news/openai-codex-on-amazon-bedrock.txt", "jsonld": "https://wpnews.pro/news/openai-codex-on-amazon-bedrock.jsonld"}}