OpenAI models and Codex are now generally available on Amazon Bedrock

OpenAI announced general availability for its frontier models and Codex on AWS on June 1, 2026. The announcement says OpenAI capabilities can now sit inside AWS customers' existing security, compliance, procurement, billing, and governance workflows. AWS updated its own Bedrock OpenAI announcement the same day, saying GPT-5.5, GPT-5.4, and Codex are now generally available on Amazon Bedrock.

This is easy to under-read as one more model listing in a cloud catalog. For engineering teams, the more concrete change is the operating boundary. A model or coding agent that previously depended on OpenAI accounts and OpenAI API keys can now be purchased, governed, and audited through Amazon Bedrock, IAM, VPC isolation, CloudTrail-facing operations, and AWS commitments. That does not replace the direct OpenAI API. It gives organizations that already standardize on AWS a path that may reduce procurement and security review friction.

OpenAI's announcement puts a direct usage number on Codex. It describes Codex as a software engineering agent used by more than 5 million people each week. AWS had described Codex as having more than 4 million weekly users in the April preview announcement, then used the June update to emphasize general availability, pricing, and AWS commitment treatment. Read together, the documents show Codex being packaged less as a ChatGPT subscriber feature and more as enterprise development infrastructure that can be bought through a cloud contract.

The most procurement-relevant sentence is in the AWS update. AWS says GPT-5.5 and GPT-5.4 run on Bedrock's next-generation inference engine, that pricing matches OpenAI first-party rates with no additional fee, and that usage counts toward AWS cloud commitments. For a finance or platform team, that can matter more than another benchmark number. A company already committed to large AWS spend can reassess whether OpenAI usage should remain a separate vendor line item or move into existing cloud consumption planning.

There are two separate model-call paths to keep straight. General applications can call OpenAI models through Amazon Bedrock. AWS's OpenAI Bedrock page describes GPT-5.5 and GPT-5.4 as frontier models for reasoning, agents, coding, and complex analysis. The same AWS material positions Bedrock Managed Agents as a way to build production-ready agents with persistent memory and built-in security. Bedrock's OpenAI examples use the OpenAI SDK against an endpoint such as https://bedrock-runtime.us-west-2.amazonaws.com/openai/v1, with AWS_BEARER_TOKEN_BEDROCK passed as the bearer token.

Codex is the more unusual path. OpenAI's Codex on Amazon Bedrock documentation says Codex runs locally while sending model requests to Amazon Bedrock. In that setup, the OpenAI-hosted Responses API is not in the request path. Bedrock provides an OpenAI-compatible Responses API implementation for supported OpenAI models. The developer still sees the Codex CLI, desktop app, or VS Code extension, but inference and authentication move to AWS.

That distinction changes security review. OpenAI's documentation says the Bedrock provider does not use ChatGPT sign-in or OPENAI_API_KEY. Authentication uses either a Bedrock API key or the AWS SDK credential chain. Supported credential paths include the AWS shared config and credentials files, environment variables, AWS Management Console credentials, AWS SSO profiles, and credential_process-based federated identity. An enterprise team therefore has to reason about Codex access through AWS accounts, profiles, roles, regions, and model access instead of only OpenAI workspace membership.

The configuration is small, but the operational implication is not. Codex config can set model_provider = "amazon-bedrock" and optionally specify a model ID. OpenAI's current supported model IDs in the Bedrock Codex document are openai.gpt-5.5 and openai.gpt-5.4. If a team uses API-key authentication, it sets AWS_BEARER_TOKEN_BEDROCK and AWS_REGION. The documentation also notes that the desktop app and IDE extension may not inherit shell environment variables, so teams may need to place values in ~/.codex/.env and restart the app. That is less a developer convenience detail than a credential distribution decision.

model_provider = "amazon-bedrock"

export AWS_BEARER_TOKEN_BEDROCK=<your-bedrock-api-key>
export AWS_REGION=us-east-2

The supported-feature table makes the shape of the Bedrock path clearer. OpenAI lists local Codex workflows, desktop app local workflows, IDE extension local workflows, Bedrock-backed inference, and locally configured MCP servers and connectors as supported. It lists the hosted first-party plugin directory, Codex cloud agents, review agents, security agents, web agents, image generation, and voice transcription as unavailable. Fast Mode is also absent because Fast Mode uses priority processing, while the initial Bedrock offering supports on-demand inference.

Those missing features are not just a defect list. The Bedrock route is not OpenAI's entire hosted Codex product suite transplanted into AWS. It is local Codex connected to an enterprise-controlled Bedrock inference path. If a team depends on cloud review agents, web agents, or the hosted plugin directory, it should not assume that changing a URL and a key will preserve the same workflow. If the team mainly uses local Codex with centrally managed AWS credentials, the Bedrock provider may be easier to justify in procurement and security review.

Bedrock's OpenAI model API also should not be treated as perfect API identity. AWS documentation says OpenAI models on Bedrock support text input and text output. It also says OpenAI Chat Completions API usage requires an Amazon Bedrock API key, and OpenAI SDK usage requires specifying the Bedrock endpoint. When using the Converse API, OpenAI fields such as max_completion_tokens, temperature, and top_p map into Bedrock fields such as maxTokens, temperature, and topP. The model names may look familiar, but the API surface still inherits Bedrock constraints.

For platform teams, the practical checklist narrows to three questions. First, is the required model available in the AWS Region where the application or Codex profile will run? OpenAI's Codex documentation explicitly says the selected model must be available in the configured AWS Region. Second, what Bedrock model access, quota, and billing guardrails apply to the AWS identity Codex uses? Third, does the team still have the workflow it needs without Fast Mode and cloud agents? Organizations already using review, security, or web agents should treat the Bedrock path as a separate profile, not a transparent replacement.

This announcement is also distinct from AWS's OpenAI-compatible SageMaker changes. SageMaker's OpenAI-compatible API is about exposing AWS-hosted open models or custom containers through a familiar SDK interface. The Bedrock announcement is about OpenAI-provided frontier models and Codex entering Bedrock's procurement and security model. One is an interface story for self-hosted model serving. The other is a distribution story for OpenAI product capability. Both can use OpenAI-style API syntax, but the resources and responsibilities under the operator's control differ.

For AWS, the move strengthens Bedrock's model-catalog position. AWS's OpenAI Bedrock page places OpenAI frontier models alongside providers such as Anthropic, Meta, Mistral, Cohere, and Amazon. Organizations already using Bedrock for model routing, guardrails, and cost controls can reduce the question of whether OpenAI usage has to sit outside their standard model platform. Azure AI Foundry and Google Vertex AI have both pushed model and agent integration as cloud-platform surfaces, and AWS now has OpenAI in the Bedrock catalog as well.

OpenAI also gets a clear distribution benefit. The direct OpenAI API and ChatGPT Enterprise cannot absorb every procurement, security-review, and data-boundary requirement in AWS-standard organizations. OpenAI's announcement repeatedly foregrounds procurement, billing, and governance for that reason. A developer may already know which OpenAI model they want, but production deployment can stall if the purchase path, audit model, or cloud boundary does not pass internal review. Bedrock changes that conversation from model quality alone to procurement and security bottlenecks.

Codex is more sensitive than a general chatbot in that review. A coding agent operates near repositories, dependencies, architecture notes, test logs, shell output, and sometimes security findings. AWS says Codex inference is routed through Bedrock and can use AWS protections such as IAM, VPC isolation, and encryption. That sentence is aimed directly at CISOs and platform teams. The buying question becomes not only whether Codex writes useful code, but which control plane handles its requests and credentials.

The AWS route does not erase operational responsibility. OpenAI's Codex documentation assigns AWS credentials, IAM permissions, Bedrock model access, quotas, billing, and regional availability to AWS administrators or AWS Support. Bedrock request failures, AWS service logs, and Bedrock behavior are also on that side of the boundary. OpenAI Support remains responsible for Codex client setup, local CLI behavior, desktop app behavior, IDE extension behavior, and the local Codex product experience. When something fails, the runbook needs to separate OpenAI client issues from AWS Bedrock service issues.

Developer reaction has been muted so far. The June 1 general-availability update did not produce a large Hacker News discussion during the research pass. Smaller Reddit threads around the earlier preview focused on OpenAI models entering AWS Bedrock after Microsoft exclusivity eased, and on the budget advantage of counting usage toward AWS commitments. Bedrock discussions in r/aws still show frustration around provider lag and provider-specific listing conditions. The June update answers one part of that conversation: the path is now generally available rather than a preview.

Teams that want to test this should split application inference and Codex usage into separate experiments. For application inference, verify the Bedrock OpenAI endpoint, model access, API key, region, and OpenAI SDK compatibility. For Codex, verify ~/.codex/config.toml, AWS_BEARER_TOKEN_BEDROCK or an AWS profile, region, model ID, and whether the desktop or IDE surface receives the intended environment variables. "OpenAI on AWS" is one headline, but an app calling a model and Codex editing a repository have different configuration files, authentication paths, and missing-feature risks.

The cost story also needs measurement rather than slogans. AWS says rates match OpenAI first-party pricing, there is no extra fee, and usage counts toward AWS commitments. Actual team cost will still depend on Bedrock quotas, regional availability, negotiated discounts, monitoring, retry behavior, agent loops, and the shape of Codex usage. A coding agent does not always behave like a single chat completion. It may inspect a repository, plan, patch, run tests, retry, and ask for more context. Moving the bill into AWS does not remove the need for work-unit-level measurement.

The practical conclusion is narrow: OpenAI's AWS availability is model-catalog news, but for engineering organizations it is more importantly a change in buying, authentication, and audit paths. GPT-5.5 and GPT-5.4 on Bedrock matter. Codex sending inference through an AWS credential chain may matter more for enterprise development teams. Any team putting AI agents into production engineering workflows should evaluate benchmarks alongside IAM roles, regions, AWS commitments, Fast Mode absence, cloud-agent absence, quotas, and support boundaries.

Sources

• OpenAI, OpenAI frontier models and Codex are now available on AWS.
• OpenAI Developers, Use Codex with Amazon Bedrock.
• AWS, OpenAI frontier models on Amazon Bedrock.
• AWS Docs, OpenAI models - Amazon Bedrock.
• Amazon News, OpenAI models GPT-5.5 and GPT-5.4, and Codex, now on Amazon Bedrock.