OpenAI Models on Bedrock: A Responses API Readiness Check

A finance team tells you the AI feature has to bill through the company's existing AWS account, and the security team wants the model calls to sit inside the same identity and logging setup as everything else. Your product already runs on OpenAI's GPT-5.5. Do you rewrite it, or can you keep the code and just change where the request goes?

Since June 2026 there's a real answer. OpenAI's newest models run inside Amazon Bedrock through an endpoint that speaks the same language your app already uses. The pitch is that you keep almost all of your code and move the billing, identity, and monitoring under AWS. That's attractive to any company that already lives in AWS and would rather not manage a second vendor relationship for AI spend.

The catch is in the fine print. "OpenAI-compatible" does not mean "identical," and a handful of features you might depend on simply aren't there. This piece maps the exact changes and the exact gaps, so a migration decision takes an afternoon of reading instead of a week of trial and error in production.

What "OpenAI on Bedrock" actually means#

Think of it as the same engine wired to a different fuse box. Amazon Bedrock now exposes an endpoint that accepts OpenAI's Responses API calls (the modern request format OpenAI's own apps use) and returns them in the same shape. Amazon calls the endpoint bedrock-mantle. Two OpenAI models are available through it today: GPT-5.5 and GPT-5.4.

For a business, the appeal is not the model. GPT-5.5 is GPT-5.5 wherever it runs. The appeal is the plumbing around it. Requests authenticate with AWS credentials, spend shows up on the AWS bill, and usage can be watched through Amazon's own monitoring service (CloudWatch) alongside your other cloud costs. For a company with an AWS commitment or a procurement team that has already vetted AWS, that consolidation is the whole point.

OpenAI's changelog dated the availability to June 1, 2026, and adds one warning worth repeating early: "Supported models and features vary by AWS Region." So even a clean migration has to confirm the target region actually offers the model.

What we ran, and what it showed#

We did not want to hand-wave the "compatible" claim, so Effloow Lab ran a real check.

We sent one live request to the standard OpenAI Responses API (gpt-5.5, model build gpt-5.5-2026-04-23) asking it to name the smallest set of config changes needed to point an existing call at Bedrock. The point wasn't the model's answer. The point was to capture the exact request-and-response contract a team would carry over, and to read the real usage accounting that comes back.

The call completed cleanly. The billing meter (the usage object OpenAI returns) reported 193 input tokens and 737 output tokens, for 930 tokens total on this one small question. Tokens are the units OpenAI charges by, so that's the full cost footprint of the request. One detail matters for anyone porting a reasoning model: 516 of those 737 output tokens were "reasoning" tokens the model spent thinking before it wrote a visible answer. You pay for that thinking, and it counts against your output limit. On our first attempt we capped output at 400 tokens, the model used all of them reasoning, and the reply came back empty and marked "incomplete." That is a real, easy-to-hit trap, and it behaves the same whether the request goes to OpenAI directly or through Bedrock, because it's a property of the model, not the endpoint.

Here's the honest boundary. We ran the OpenAI endpoint. We did not run the Bedrock endpoint, because Effloow doesn't have an AWS account wired up for this test. So everything below about Bedrock's behavior is read from official documentation, not measured by us. We label that plainly rather than dress it up as hands-on proof. The full run, including the request id and raw numbers, is in the public lab note at /lab-runs/openai-models-amazon-bedrock-governed-responses-poc-2026.

The migration map: what changes, what stays#

From OpenAI's Bedrock guide, the config-only changes are small and specific. Your business logic doesn't move. Three settings do.

Read that in plain terms. You change the address, you add an openai. in front of the model name, and you swap an OpenAI key for AWS credentials. The body of the request stays the same. That's genuinely a small diff for a well-structured app.

Two rows deserve a business translation. The context cap of 272,000 tokens is roughly a few hundred pages of text in a single request; if your product stuffs huge documents into one call, confirm you stay under that ceiling, because Bedrock rejects anything over it. And "on-demand only" means there's no reserved-capacity tier here yet. If you were relying on OpenAI's service tiers to guarantee throughput or a priced discount, that lever isn't available on Bedrock today.

The features Bedrock drops#

This is the part that turns a one-line migration into a real decision. OpenAI's guide lists capabilities that the Bedrock endpoint does not support. If your product uses any of them, "just change the base URL" quietly becomes "rearchitect that feature."

The unsupported list, straight from the documentation:

• Audio input: you can't feed the model spoken audio directly.
• WebSocket connections: no persistent streaming socket, which affects certain real-time setups.
• Hosted web search: the model won't run OpenAI's built-in web search for you.
• Hosted file search: no built-in document retrieval over uploaded files.
• Computer use: the model can't drive a virtual computer.
• Shell tool: no built-in command-line execution.
• Image generation tool: no built-in image creation in the same call.
• Remote MCP servers: you can't attach external tool servers over the Model Context Protocol.

None of these break plain text or reasoning requests. A chatbot, a classifier, a summarizer, or an agent that calls your own tools (functions defined in your code, not hosted by OpenAI) all port fine. But a product built around OpenAI's hosted web search, its file search, or a voice pipeline that streams audio in will hit a wall. Better to find that wall in a planning doc than in an incident at 2am.

Can this survive your workflow?#

Before committing, walk your own use cases against the gaps. A few concrete scenarios:

• Support assistant that answers from a policy prompt: moves cleanly. It's text in, text out, and the 272K cap easily holds a large policy.
• Order or ticket processing agent that calls your internal APIs: moves cleanly, as long as those tools are your own functions rather than OpenAI hosted tools.
• Research feature that leans on OpenAI's hosted web search: does not move as-is. You'd need to bring your own search and feed results into the prompt.
• Voice product that streams microphone audio to the model: does not move. Audio input isn't supported on this endpoint.
• Anything wired to remote MCP tool servers: does not move without reworking how those tools connect.

If your critical path is in the first two buckets, this is a low-risk change. If it's in the last three, budget for real engineering, not a config edit.

Limitations of this readiness check#

Being direct about what we can and can't stand behind is the point of the exercise.

We verified the migration mechanics and the feature gaps against OpenAI's official Bedrock guide, OpenAI's changelog, and two AWS announcements. Those are primary sources, not blog hearsay. But we did not run a single request against the bedrock-mantle endpoint. So we cannot tell you, from measurement, how Bedrock's latency compares to calling OpenAI directly, whether a specific region carries GPT-5.5 today, or exactly how the CloudWatch token metrics look once they land in your dashboard. Those are [DATA NOT AVAILABLE] here, and anyone who quotes precise latency-versus-direct numbers without an AWS run is guessing. The OpenAI-side numbers we did report (193 input, 737 output, 930 total tokens) describe our one small test prompt, not your workload.

When to use it, when to skip it#

Use OpenAI on Bedrock when:

• Your organization already standardizes on AWS for billing, identity, and monitoring, and a second AI vendor bill is friction.
• Your product uses plain text, reasoning, or your-own-code tools, none of the hosted extras.
• You want model calls to inherit AWS identity and CloudWatch visibility without app rewrites.

Skip it (for now) when:

• You depend on hosted web search, hosted file search, audio input, image generation, computer use, or remote MCP servers.
• You need reserved-capacity service tiers rather than on-demand pricing.
• Your target AWS region doesn't yet list the model you need. Confirm before you plan the cutover.

What Effloow added#

Primary sources tell you the endpoint exists and list its limits. What they don't give you is a decision you can act on in an afternoon. We added three things: a live-verified baseline of the exact Responses request contract (with real usage numbers and a reproducible request id), a side-by-side migration matrix that separates what changes from what stays, and a buyer-scenario test that maps the unsupported-feature list onto concrete product workflows so you can tell in minutes whether your app is a config change or a rebuild. The honest boundary, that we exercised OpenAI's endpoint and not Bedrock's, is stated instead of hidden.

If you're weighing an AI vendor's endpoint move and want this kind of claim-bound readiness check done properly, that's exactly the work Effloow packages in Proof Studio. We also documented adjacent migrations worth reading first: our OpenAI Assistants API to Responses port PoC and our OpenAI Agents SDK sandbox provider readiness check.

For your engineers#

Everything below is the exact method and reproduction detail. It is intentionally separate from the business narrative above.

What ran. One call to POST https://api.openai.com/v1/responses, model gpt-5.5-2026-04-23, via scripts/openai-lab-run.py. Result: status: completed, request id 8f6b3c13-4dbd-43d5-bef1-cff9e453f6f1. Usage object:

{
  "input_tokens": 193,
  "input_tokens_details": { "cached_tokens": 0 },
  "output_tokens": 737,
  "output_tokens_details": { "reasoning_tokens": 516 },
  "total_tokens": 930
}

Note the reasoning-token trap: a first run capped at max_output_tokens: 400 returned status: incomplete with empty text because all 400 output tokens were spent on reasoning. Size max_output_tokens to cover reasoning plus the visible answer.

Bedrock request shape (from OpenAI's guide, not executed by us).

• Base URL: https://bedrock-mantle.{region}.api.aws/openai/v1
• Model IDs: openai.gpt-5.5, openai.gpt-5.4
• Auth options: static AWS_BEARER_TOKEN_BEDROCK bearer token; or a refreshable token provider (@aws/bedrock-token-generator for JavaScript, aws-bedrock-token-generator for Python); header form Authorization: Bearer $AWS_BEARER_TOKEN_BEDROCK.
• Context cap: 272,000 tokens for GPT-5.4 and GPT-5.5; over-cap requests are rejected.
• Inference: on-demand only; OpenAI service tiers are not supported.
• Compatible surfaces on bedrock-mantle: OpenAI Responses API, OpenAI Chat Completions API, Anthropic Messages API.
• Unsupported: audio input, WebSocket connections, hosted web search, hosted file search, computer use, shell tool, image generation tool, remote MCP servers.

Observability (AWS, documented). CloudWatch metrics publish under the AWS/BedrockMantle namespace: inference counts, input and output token totals, and client error counts, at account, project, model, and project-and-model granularity. Metric availability is region-scoped.

Reproduce the OpenAI baseline.

python3 scripts/openai-lab-run.py \
  --slug openai-models-amazon-bedrock-governed-responses-poc-2026 \
  --prompt-file /tmp/bedrock-poc-prompt.txt \
  --max-output-tokens 1500

Evidence. Full run artifact and source-derived matrix: /lab-runs/openai-models-amazon-bedrock-governed-responses-poc-2026.

Primary sources.

1. OpenAI, "OpenAI models on Amazon Bedrock" guide (endpoint, model IDs, auth, 272K cap, on-demand, unsupported features).
2. OpenAI API changelog, entry dated 2026-06-01 (availability; models; "features vary by AWS Region").
3. AWS What's New, "CloudWatch metrics for the bedrock-mantle endpoint," 2026-06-01 (AWS/BedrockMantle namespace, metric list, regions).
4. AWS What's New, "redesigned Bedrock console for OpenAI- and Anthropic-compatible APIs," 2026-06-04 (prefilled model ID, region, endpoint URL, key reference).