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. GPT-5.4 and GPT-5.5 were there at launch, and OpenAI's Bedrock guide now documents openai.gpt-5.6-sol on the same surface.

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." AWS currently lists the endpoint in fourteen regions, three in the US, five in Europe, four in Asia Pacific, São Paulo, and GovCloud (US-West). Being in a listed region is necessary but not sufficient. The region has to carry the model you want, which is a separate check.

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 and AWS's own endpoint documentation, the config-only changes are small and specific. Your business logic doesn't move. A handful of 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.

Three 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. "On-demand only" means there's no reserved-capacity tier here yet, so if you were relying on OpenAI's service tiers to guarantee throughput or earn a priced discount, that lever isn't available. And the quota model changes shape: AWS applies separate input and output token-per-minute limits per model per region, does not enforce a requests-per-minute cap at all, and counts this traffic against an allocation completely independent of the older bedrock-runtime endpoint. Two teams calling the same model through the two endpoints do not share a budget.

One footgun sits in the paperwork itself. OpenAI's guide shows the SDK resolving a base URL ending in /openai/v1, while AWS's endpoint page tells you to set OPENAI_BASE_URL to a path ending in /v1. Both are current documentation from the two vendors involved. Don't hard-code either from a blog post. Let the SDK derive the URL where it can, and if you must set it by hand, confirm the exact path against your region and SDK version before you ship.

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.
• Pro mode: the higher-effort reasoning mode isn't offered here.
• Programmatic tool calling: the model can't write sandboxed code that runs your tools and returns only the answer. On data-heavy agent steps that feature is worth real money, as our GPT-5.6 token proof measured at roughly 92% fewer tokens on bulky tool outputs. Moving that workload to Bedrock means giving the saving back.

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.

The governance details that don't make the headline#

The reason a company moves to Bedrock is usually governance, so it's worth reading the governance fine print more carefully than the feature list. Three items in AWS's documentation deserve a decision, not a skim.

Your conversations are stored for 30 days unless you say otherwise. The Responses API keeps state so a follow-up request can reference an earlier turn. On Bedrock that storage is on by default: the request and the response are retained for 30 days in the region that handled the call, encrypted at rest and scoped to the calling account's project, then deleted. Set store to false on every request if your legal or privacy position is that model inputs are not retained anywhere. This is exactly the kind of default a security review is supposed to catch, and it is easy to miss because the behavior matches OpenAI's own specification rather than looking like an AWS-specific choice.

Your existing Bedrock dashboards will not see this traffic. Metrics land in a new namespace, AWS/BedrockMantle, and the names changed with it: Inferences instead of Invocations, TotalInputTokens and TotalOutputTokens instead of InputTokenCount and OutputTokenCount, InferenceClientErrors instead of InvocationClientErrors. An alarm built against AWS/Bedrock keeps reporting green while the new endpoint carries production load. There is a genuine upgrade in the package, though. A Project dimension that the older endpoint never had makes per-team chargeback possible without tagging gymnastics.

Latency is not yet measurable here. AWS states plainly that the equivalents of InvocationLatency and TimeToFirstToken are not published for this endpoint. If your SLA is written in response-time terms, you'll need your own client-side timing from day one, because the cloud provider isn't going to hand you the number.

Pre-flight checklist#

Run these seven checks before anyone opens a pull request. Each one is answerable from documentation or a five-minute test, and each has bitten somebody.

1. Does your target region carry the model you need? Being on the fourteen-region list is not the same as having GPT-5.5 available there. Confirm with a models.list() call against the region you actually plan to use.
2. Does your app touch any unsupported feature? Walk the list: audio input, WebSockets, Pro mode, hosted web search, hosted file search, computer use, shell tool, image generation, remote MCP, programmatic tool calling. One hit turns a config change into a rebuild.
3. Have you decided the store value explicitly? Leaving it unset means 30-day retention. That should be a written decision, not an accident.
4. Is your largest realistic prompt under 272,000 tokens? Measure the worst case, not the average. Over-cap requests are rejected outright.
5. Have you sized the new token-per-minute quotas? They're separate from your bedrock-runtime allocation, split between input and output, and increases go through a support case rather than the Service Quotas console. Start that request early if your volume is real.
6. Do your alarms point at the new namespace? Rebuild against AWS/BedrockMantle before cutover, not after the first incident.
7. Have you removed the assumption of cross-region failover? This endpoint is in-region only. If your resilience plan assumed the older endpoint's cross-region inference, it needs rewriting.

What breaks, and what to do about it#

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, the feature gaps, the retention default, the quota model, and the metric names against OpenAI's official Bedrock guide, OpenAI's changelog, and four pages of AWS documentation. 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, remote MCP servers, Pro mode, or programmatic tool calling.
• 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.
• Your resilience plan depends on cross-region failover, or your SLA is written in latency terms the endpoint doesn't yet report.

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, partly because the facts that matter are scattered across two vendors and six documents. We pulled them into one place and added four 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, a seven-item pre-flight checklist with a failure table for each way the migration goes wrong, and a buyer-scenario test that maps the unsupported-feature list onto concrete product workflows. The three findings we'd most want a migration lead to see are ones the marketing copy doesn't lead with: conversations are retained 30 days by default, existing CloudWatch alarms go blind because the namespace and metric names changed, and the two vendors' own docs currently show different base-URL paths. 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: OpenAI's guide shows the SDK deriving https://bedrock-mantle.{region}.api.aws/openai/v1; AWS's endpoint page instructs setting OPENAI_BASE_URL=https://bedrock-mantle.{region}.api.aws/v1. Verify against your SDK version rather than hard-coding from either doc.
• Model IDs: openai.gpt-5.4, openai.gpt-5.5, openai.gpt-5.6-sol.
• Auth options: Amazon Bedrock API key via OPENAI_API_KEY (required path for the OpenAI SDK); static AWS_BEARER_TOKEN_BEDROCK bearer token; a refreshable token provider (@aws/bedrock-token-generator for JavaScript, aws-bedrock-token-generator for Python); AWS credentials for raw HTTP.
• Context cap: 272,000 tokens for GPT-5.4, GPT-5.5, and GPT-5.6; 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, Pro mode, hosted web search, hosted file search, computer use, shell tool, image generation tool, remote MCP servers, programmatic tool calling.
• State: store defaults to true; responses (input and output) are retained 30 days in the source region, encrypted at rest, scoped to the calling account's Project, and reachable via previous_response_id or GET /v1/responses/{id}. store: false disables retention and previous_response_id.
• Quotas: per-model, per-region input TPM and output TPM, evaluated as (input tokens + max_tokens) on admission with the unused reservation replenished after completion; no RPM quota; throttling returns HTTP 429. Independent from bedrock-runtime quotas. Cached prompt-cache reads don't count against input TPM. Increases go through an AWS Support limit-increase case, not the Service Quotas console.

Observability (AWS, documented). Metrics publish under AWS/BedrockMantle: Inferences, InferenceClientErrors, TotalInputTokens, TotalOutputTokens (account, project, model levels), plus per-inference InputTokens and OutputTokens at the Project+Model level for percentile analysis. Dimensions are Project and Model. Renames from bedrock-runtime: Invocations → Inferences, InputTokenCount/OutputTokenCount → TotalInputTokens/TotalOutputTokens, InvocationClientErrors → InferenceClientErrors. Dashboards built on AWS/Bedrock will not pick up this traffic. Metrics are emitted in-region with no cross-region aggregation, and InvocationLatency/TimeToFirstToken equivalents are not published.

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 in Amazon Bedrock" (endpoint, model IDs, auth, 272K cap, on-demand, unsupported features).
2. AWS, "Inference using Responses API" (bedrock-mantle) (base URL, auth, supported regions, store retention semantics).
3. AWS, "Monitor bedrock-mantle inference using CloudWatch metrics" (namespace, metric names, dimensions, differences from bedrock-runtime).
4. AWS, "Quotas for the bedrock-mantle endpoint" (input/output TPM model, no RPM cap, quota-increase path).
5. AWS, "Endpoints supported by Amazon Bedrock" (endpoint inventory).
6. AWS What's New, "Amazon Bedrock adds CloudWatch metrics for OpenAI- and Anthropic-compatible APIs", 2026-06-01.
7. OpenAI API changelog, entry dated 2026-06-01 (availability; models; "features vary by AWS Region").