{"slug": "openai-codex-on-amazon-bedrock-sso-setup-gateways-and-telemetry", "title": "OpenAI Codex on Amazon Bedrock: SSO Setup, Gateways, and Telemetry", "summary": "AWS published a technical guide on November 11, 2026, by authors Shivi Bhatia, Sebastien Couturier and Sriharsha M S, showing how to run OpenAI Codex on a developer workstation while routing model inference to Amazon Bedrock under company-controlled AWS credentials, using models including GPT-5.6 Sol (openai.gpt-5.6-sol), Terra and Luna in the us-east-2 Region. The guide lays out four rollout paths — Native AWS Access via IAM Identity Center, AgentCore Gateway with Amazon Bedrock Guardrails, an LLM Gateway such as LiteLLM or Portkey, and a custom integration — backed by the openai-on-aws/guidance-codex reference repository, which had 12 stars, 8 forks and 39 commits on main, under MIT-0 code and CC-BY-SA 4.0 docs. AWS calls Native AWS Access the recommended starting point and describes the LiteLLM-on-ECS quick start as the most complete reference, while the guide does not state cost or rate limits.", "body_md": "AWS has published a practical guide for running OpenAI Codex against Amazon Bedrock. The short answer: Codex keeps running on the developer's machine, and its model calls go to Bedrock under AWS credentials that the company controls. The [AWS Machine Learning Blog post](https://aws.amazon.com/blogs/machine-learning/openai-codex-on-amazon-bedrock/?ref=explainx), dated November 11, 2026, is a technical how-to rather than a launch press release. It still matters, because it shows how a large AWS customer can adopt a coding agent without opening a new vendor billing and identity path.\n\nThis post explains the four rollout paths, the exact config AWS shows, what to verify in a pilot, and what the guide leaves out. If you buy ChatGPT seats through AWS already, read it next to our coverage of [ChatGPT Enterprise on AWS Marketplace](https://explainx.ai/blog/chatgpt-enterprise-aws-marketplace-november-2026).\n\n## TL;DR: the questions teams ask first\n\n| Question | Answer from the AWS guide | \n|---|---|\n| Where does Codex run? | On the developer workstation, as before. | \n| Where does inference run? | On Amazon Bedrock, with a supported OpenAI model. | \n| Which model does the example use? | GPT-5.6 Sol ( `openai.gpt-5.6-sol` ). Terra and Luna are also named. | \n| How do users authenticate? | Workforce identity provider, then IAM Identity Center, then temporary AWS credentials. | \n| What is the example Region? | us-east-2. Other Regions vary by account and inference path. | \n| Is there a reference repo? | Yes, `openai-on-aws/guidance-codex` . | \n| What does it cost? | Not stated. Check AWS pricing and the Bedrock docs. | \n| Are there rate limits? | Not stated in the visible post. Check the Bedrock quotas page. | \n\n## What did AWS actually announce?\n\nThe post is written by three AWS authors: Shivi Bhatia, Sebastien Couturier, and Sriharsha M S. It frames one design question. How do model requests from Codex reach Bedrock, and where do policy and operational controls apply?\n\nThe answer is a menu, not a single product switch. AWS describes four rollout paths and says availability \"varies by account, Region, and inference path.\" The post does not list every supported Region. It points readers to the AWS documentation page for supported models by Region in Amazon Bedrock.\n\nOne limit of this write-up: the AWS page was cut off for our fetch before its last section, which covers team standards such as repository guidance, managed plugins, hooks, and approved MCP servers. We describe only what we could read, and we mark the rest as unknown.\n\n## The four rollout paths\n\n| Path | What it is | Best for | \n|---|---|---|\n| Native AWS Access | IAM Identity Center and IAM controls, direct Bedrock calls | A small pilot; AWS calls it the recommended starting point | \n| AgentCore Gateway | AWS-managed routing with Amazon Bedrock Guardrails | Teams that want managed policy and guardrails | \n| LLM Gateway | A gateway you already run, or LiteLLM or Portkey | Teams that need request-path enforcement and budgets | \n| Custom integration | The advanced form of the gateway pattern | Special cases; AWS says it is not a quick start | \n\nThe reference repository, [openai-on-aws/guidance-codex](https://github.com/openai-on-aws/guidance-codex?ref=explainx), maps to these paths. Its quick starts cover IAM Identity Center, LiteLLM on ECS (a customer-operated gateway with scoped keys and optional OIDC mapping, described as the most complete reference), Portkey on EKS with a Portkey-managed control plane, and AgentCore Gateway. The post also lists ADOT and CloudWatch quick starts for observability.\n\nThe repo is small and young when we looked: 12 stars, 8 forks, 39 commits on `main`. Code is under MIT-0 and the docs are under CC-BY-SA 4.0. Treat it as reference guidance, not a supported product.\n\n## How does sign-in work?\n\nDevelopers do not paste API keys into Codex. The guide keeps identity at the company level:\n\n1. Users sign in through the existing workforce identity provider. The example uses Okta over SAML.\n2. SCIM provisions the pilot group into AWS IAM Identity Center.\n3. IAM Identity Center issues the temporary AWS credentials that Codex uses.\n4. The identity provider is not configured in Codex at all.\n\nThis matters for security review. A revoked employee loses access when the identity provider drops them, with no leaked long-lived key to hunt down. It also gives each developer a distinct AWS session, which makes audit records meaningful.\n\nFor teams building agent governance on top of identity, our post on [Okta cross-app access with AgentCore Gateway and Cedar policy](https://explainx.ai/blog/okta-cross-app-access-bedrock-agentcore-gateway-cedar-policy-agent-governance-part-2-2026) covers a related pattern.\n\n## Prerequisites AWS lists\n\nBefore the pilot, the guide asks for:\n\n- A dedicated pilot group, provisioned to IAM Identity Center.\n- A Region and model that the identity can use, plus an inference profile if the API requires one.\n- Least-privilege IAM permissions for the Bedrock calls, the validation commands, and the observability destination.\n- A non-production repository and a named rollback owner.\n\nThe last two items are worth copying even outside AWS. A coding agent pilot should start on a repo where a bad change costs nothing, and someone must own the off switch.\n\n## The setup, step by step\n\n### Step 1: sign in and test Bedrock Runtime\n\nThe guide validates access before touching Codex. This is the command from the post, with line continuations added:\n\n```\naws sso login --profile codex-bedrock\nexport AWS_PROFILE=codex-bedrock\naws bedrock-runtime converse \\\n  --model-id us.openai.gpt-5.6-sol \\\n  --messages '[{\"role\":\"user\",\"content\":[{\"text\":\"Reply with OK\"}]}]' \\\n  --region us-east-2\n```\n\nNote the model ID here carries a `us.` prefix, which marks a cross-Region inference profile. The Codex config below uses a different form. Keep both straight when you debug.\n\n### Step 2: point Codex at the Bedrock provider\n\nAdd this to `~/.codex/config.toml` or to managed user configuration:\n\n```\nmodel_provider = \"amazon-bedrock\"\nmodel = \"openai.gpt-5.6-sol\"\n\n[model_providers.amazon-bedrock.aws]\nprofile = \"codex-bedrock\"\nregion = \"us-east-2\"\n```\n\nAWS advises keeping this in user-level or managed configuration, so a repository cannot change the provider. That is a real risk: a project-level config could otherwise redirect traffic to a different endpoint. It echoes the supply-chain worries we covered in [Codex security cloud and agents API computer use](https://explainx.ai/blog/openai-codex-security-cloud-agents-api-computer-use-2026).\n\n### Step 3: verify the pilot\n\nAWS lists four checks:\n\n- Confirm identity with `aws sts get-caller-identity` .\n- Confirm the approved model runs in the chosen Region.\n- Run a safe, read-only Codex task in a non-production repo.\n- Confirm that identity, invocation, and audit records all exist.\n\nThen run the same harmless task as two separate pilot users. Their sessions, audit records, and telemetry must stay distinct. If they merge, your attribution is broken before you scale.\n\n### Rollback\n\nThe rollback is short. Remove the configuration or the IAM Identity Center assignment, handle active sessions per your own procedure, and verify that new invocations are denied. Test this before the pilot starts, not after.\n\n## What can you measure?\n\nCodex can export OpenTelemetry metrics, and the guide sends them through an ADOT collector:\n\n```\n[otel]\nenvironment = \"pilot\"\nlog_user_prompt = false\nmetrics_exporter = { \"otlp-http\" = { endpoint = \"http://127.0.0.1:4318/v1/metrics\", protocol = \"binary\" } }\n```\n\nNote `log_user_prompt = false`. Prompts stay out of telemetry by default in this example, which is the safer choice for source code.\n\nAWS splits telemetry into three sources:\n\n| Source | What it shows | \n|---|---|\n| Codex OTel metrics | Token usage, turns, API requests, request duration, tool calls, session source | \n| Bedrock service metrics | Invocations, latency, input and output tokens, client and server errors | \n| Identity and billing | The assumed-role SSO principal, and billed Bedrock line items in the Cost and Usage Report | \n\nOn the native IAM Identity Center path, CUR 2.0 with caller-identity allocation can expose the SSO principal, so you can charge spend to a person or team. On gateway paths you need gateway telemetry for per-user allocation instead.\n\nThe post also makes two honest caveats. Token volume is not a cost report. And telemetry does not establish that the code is correct or safe. Do not use \"tokens used\" as a productivity score. For the cost side, see our guide to [Amazon Bedrock tokenomics and FinOps](https://explainx.ai/blog/amazon-bedrock-tokenomics-data-lake-finops-2026).\n\n## Which path should you pick?\n\nOur reading, based on the AWS text:\n\n- **Fewer than a few dozen developers, one account:** Native AWS Access. No new servers, and identity already works.\n- **You need per-team budgets or hard stops:** LiteLLM on ECS or Portkey. These give scoped keys and budget enforcement that plain IAM does not.\n- **You want guardrails without running a gateway:** AgentCore Gateway. AWS describes it as managed routing with Bedrock Guardrails, and the repo adds AWS-private web search to this path. For the search piece, see our notes on[Web Answer on AgentCore](https://explainx.ai/blog/amazon-bedrock-agentcore-web-answer-ga-single-tool-call-cited-answers-gateway-setup-guide-2026) .\n- **Regulated or government work:** check Region and model approval first. OpenAI's cyber model on AWS GovCloud has its own rules, covered in[OpenAI Daybreak on AWS GovCloud](https://explainx.ai/blog/openai-daybreak-red-aws-govcloud-us-east-gpt-5-6-cyber-government-security-teams-approval-2026) .\n\n## Why would a company route Codex through Bedrock?\n\nThree reasons show up in the guide's structure.\n\n**Procurement.** If the company already holds AWS commitments, usage on Bedrock may be simpler to approve than a new vendor. Our post on the [OpenAI DevDay 2026 announcements](https://explainx.ai/blog/openai-dev-day-2026) shows how fast Codex grew as a product; large buyers now want it inside existing contracts. Whether Bedrock usage counts toward commitments depends on your AWS agreement, and the post does not say.\n\n**Identity and audit.** AWS credentials, CloudTrail, and IAM are already wired into security teams' tools. A Codex session that shows up as an assumed role is easier to govern than a shared API key.\n\n**Network and data path.** The guide's stated design keeps the agent local and the inference in AWS. What data leaves the laptop is still the prompt and the context Codex gathers, so scope the repository access and tool permissions as you would for any agent. Our [Claude Code remote sessions security sample](https://explainx.ai/blog/claude-code-remote-sessions-bedrock-agentcore-security-controls-sample-2026) walks through similar controls for a different agent.\n\n## What the post does not say\n\n- **No price.** There is no per-token price, no comparison with calling OpenAI directly, and no discount note.\n- **No quotas.** Rate limits and token limits are not in the visible text.\n- **No full Region list.** Only us-east-2 appears in the example.\n- **No performance comparison.** AWS does not claim Codex behaves identically on Bedrock and on OpenAI's own endpoint. Test your own workloads.\n- **No claim about code quality.** AWS says telemetry does not establish correctness.\n\nWhere a team needs one of these facts, treat it as unknown until you confirm it in the AWS pricing page, the Bedrock quotas page, or with your account manager.\n\n## A practical pilot plan\n\n1. Pick one non-production repository and one owner for rollback.\n2. Create a pilot group in your identity provider and provision it through SCIM.\n3. Run the `converse` test from step 1 for two users in us-east-2 (or your approved Region).\n4. Roll out the user-level `config.toml` through your device management tool.\n5. Turn on the OTel exporter with prompt logging off.\n6. Run the same read-only task as two users. Check that audit records are separate.\n7. After a week, compare Bedrock invocation metrics with CUR line items. Look for gaps in attribution.\n8. Only then decide whether to add a gateway for budgets or guardrails.\n\nThis sequence keeps the first step cheap and reversible, which is the main point of AWS's recommendation to start native.\n\n## Bottom line\n\nAWS did not announce a new model here. It published a deployment pattern: keep Codex local, authenticate through your identity provider, send inference to Bedrock, and add a gateway only when you need budgets or request-path policy. The strongest parts are the identity design, the two-user attribution test, and the rollback step. The weakest part is the missing cost and quota information, which buyers will need before scaling past a pilot.\n\n## Related reading\n\n*Details are accurate as of November 12, 2026. Model availability, Regions, and repository contents change often; check the AWS post and the repository before you deploy.*", "url": "https://wpnews.pro/news/openai-codex-on-amazon-bedrock-sso-setup-gateways-and-telemetry", "canonical_source": "https://explainx.ai/blog/openai-codex-amazon-bedrock-sso-agentcore-gateway-setup-guide-2026?utm_source=rss&utm_medium=feed&utm_campaign=blog", "published_at": "2026-11-12 00:00:00+00:00", "updated_at": "2026-11-12 00:51:08.210001+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-infrastructure", "developer-tools", "ai-products"], "entities": ["AWS", "OpenAI", "Codex", "Amazon Bedrock", "IAM Identity Center", "AgentCore Gateway", "LiteLLM", "Portkey"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/openai-codex-on-amazon-bedrock-sso-setup-gateways-and-telemetry", "markdown": "https://wpnews.pro/news/openai-codex-on-amazon-bedrock-sso-setup-gateways-and-telemetry.md", "text": "https://wpnews.pro/news/openai-codex-on-amazon-bedrock-sso-setup-gateways-and-telemetry.txt", "jsonld": "https://wpnews.pro/news/openai-codex-on-amazon-bedrock-sso-setup-gateways-and-telemetry.jsonld"}}