Web Search on Amazon Bedrock: Grounding OpenAI Models Without Building a RAG Pipeline

AWS shipped Web Search on Amazon Bedrock this month — a built-in tool that lets supported OpenAI models pull current information from the web mid-request and cite their sources, without you standing up a retrieval pipeline, a search API integration, or a tool-call loop. It's generally available now in three US regions. If you've been bolting Bing/Serper/Tavily calls onto an agent just to answer "what changed recently," this replaces that wiring with one parameter.

This post covers what the tool actually does, how to call it, the permission model that trips people up on day one, and where it stops being the right choice.

How it works

Web Search is two operations bundled behind a single tool type in the OpenAI-compatible Responses API: Search (returns titles, URLs, and snippets from a web index and knowledge graph that Amazon builds and maintains) and Fetch (retrieves cached page content for a specific URL). When you add the tool to a request, the model — not your application code — decides whether the question needs current information, issues one or more search queries if so, and can reformulate and search again within the same turn if the first pass doesn't answer the question. If nothing in the results supports an answer, the model says so instead of falling back to its training data.

By default, both operations are served entirely from Amazon's own web index and cache — a snapshot of web content hosted inside AWS — not a live fetch of the actual page at request time. That distinction matters for the permission model below.

Enabling it

Web Search only works through the bedrock-mantle endpoint using the Responses API, and only for a specific set of OpenAI models on Bedrock: openai.gpt-5.4, openai.gpt-5.5, and openai.gpt-5.6 (its sol, terra, and luna variants). It is not available for Anthropic or Amazon models, and not through the standard Bedrock Converse or InvokeModel APIs.

 1from openai import OpenAI
 2
 3client = OpenAI(
 4    base_url="https://bedrock-mantle.us-west-2.api.aws/openai/v1",
 5    api_key="your-amazon-bedrock-api-key",
 6)
 7
 8response = client.responses.create(
 9    model="openai.gpt-5.5",
10    input="What changed in the latest Kubernetes release?",
11    tools=[{"type": "web_search", "external_web_access": False}],
12)
13
14print(response.output_text)

That's the entire integration. No search API key, no orchestration layer, no writing the "call tool, feed results back to the model" loop yourself — Bedrock runs the whole cycle server-side and returns a grounded answer in one call.

Reading the citations

Every claim the model draws from search results comes back as a url_citation annotation with the source title, URL, and the exact character span in the answer it supports:

1for item in response.output:
2    if item.type == "message":
3        for block in item.content:
4            if block.type == "output_text":
5                for ann in block.annotations:
6                    if ann.type == "url_citation":
7                        print(f"- {ann.title}: {ann.url}")

If you're consuming raw JSON instead of the SDK, the same data is at output[].content[].annotations[]. AWS's acceptable-use terms require you to retain and display these citations in anything you surface to end users — this isn't optional if you're building a user-facing feature on top of it.

The permission gotcha: external_web_access

This is where most first attempts fail. The Responses API has an external_web_access parameter that defaults to true (to match the vanilla OpenAI Responses API signature, so your existing code doesn't need to change syntactically). But the AmazonBedrockFullAccess managed policy only grants the baseline bedrock-websearch:InvokeSearch and bedrock-websearch:InvokeFetch actions — it does not grant bedrock-websearch:ExternalWebAccess.

Leave external_web_access at its default true without that extra IAM permission, and you get:

1403 AccessDeniedException — bedrock-websearch:ExternalWebAccess

But it fails soft, not hard: the model doesn't error out the whole request. It grounds the answer using Search and cached Fetch only, and reports in the response that it couldn't get external access. That's easy to miss in testing if you're only checking for a 200 status.

Two ways to fix it:

1. Explicitly set external_web_access: False on the tool. This stays within the AWS boundary (Amazon's index and cache only), doesn't need the extra IAM action, and is safe under the default managed policy — this is what you want for most use cases today.
2. Grant bedrock-websearch:ExternalWebAccess explicitly if you need it. As of this AWS's launch, retrieval is still served from Amazon's index even with this permission granted — live external fetch is called out as coming in a future release. Granting it now is forward-provisioning, not something that changes behavior yet.

Required IAM actions, summarized:

Regional availability and data handling

Web Search processes queries in-region in exactly three regions right now: us-east-1, us-east-2, and us-west-2. It's strictly regional — a query issued in one region never crosses into another region's index or infrastructure. If your workload runs in eu-west-1 or ap-southeast-2, this tool isn't available to it yet; you'd still need a third-party search integration there.

Data governance is the other headline: with external_web_access: false, your request data never leaves the AWS boundary — no external network egress at all for search or fetch. CloudTrail logs who invoked the tool, when, and from where as data events, but AWS deliberately excludes the actual query text and retrieved URLs from those logs for privacy.

Web Search vs. a Bedrock Knowledge Base

These solve different problems and teams often reach for the wrong one:

If the answer lives in your own S3 bucket or internal Confluence, Web Search can't help — you still need a Knowledge Base. If the answer depends on something that happened last week and you're not on an OpenAI model, Web Search isn't available to you yet either — check the model list above before you architect around it.

Best practices

• Default to external_web_access: False unless you have a specific reason to grant the broader permission — it's safe under the standard managed policy and avoids the silent-failure mode above.
• Always surface citations, not just the answer text. Beyond being an AWS acceptable-use requirement, it's the only way your users can verify a grounded claim.
• Check the model and region before committing an architecture to it. Three regions and three model families is a real constraint, not a footnote — confirm your workload's region matches before you design around this.
• Treat streaming responses' response.output_text.annotation.added events as first-class, not an afterthought, if you're building a streaming UI — citations arrive incrementally alongside the text they support.

Common mistakes to avoid

• Assuming external_web_access: true (the default) "just works." It silently degrades to boundary-only retrieval without the extra IAM permission, and the failure shows up as missing context, not an obvious error.
• Calling this through Converse or InvokeModel. Web Search only exists on the Responses API through the bedrock-mantle endpoint — it won't appear as an option on your existing Converse-based agent code.
• Bulk-scraping search results to build your own index. AWS's acceptable-use policy explicitly prohibits extracting or reproducing Search Results in bulk, or using them to build a competing index.
• Forgetting this is US-only for now. Don't wire it into a global multi-region deployment assuming it'll just work everywhere Bedrock does.

Troubleshooting

Getting 403 AccessDeniedException on bedrock-websearch:ExternalWebAccess. Either grant that IAM action to the calling identity, or set external_web_access: False on the tool call — the second option requires no extra permissions.

Model responses aren't citing anything even though Web Search is enabled. Check whether the query actually needed current information — the model only invokes the tool when it decides it's necessary. A question fully answerable from training data (e.g., basic syntax questions) may not trigger a search at all.

Calls fail entirely with an unsupported-model or unsupported-endpoint error. Confirm you're using one of openai.gpt-5.4, openai.gpt-5.5, or openai.gpt-5.6, hitting the bedrock-mantle.<region>.api.aws/openai/v1 endpoint, and in us-east-1, us-east-2, or us-west-2.

FAQ

Does Web Search on Bedrock work with Claude or Amazon Nova models? No. At launch it's exclusive to OpenAI GPT models (gpt-5.4, gpt-5.5, gpt-5.6) served through Bedrock's bedrock-mantle endpoint.

Is this the same as retrieving live web pages in real time? Not by default. Search and Fetch are served from Amazon's pre-built web index and cache, not a live crawl at request time. Live external retrieval is planned but not yet active even when ExternalWebAccess is granted.

What does it cost? AWS prices Web Search per query, separate from token-based model inference pricing — check the Amazon Bedrock pricing page for current rates before estimating cost at scale, since per-query pricing adds up fast on high-volume agents.

Can I use this alongside a Knowledge Base in the same agent? Nothing in the docs prevents combining Web Search with your own retrieval tools in the same request — they serve different data sources and are complementary rather than exclusive.

Do I need to write my own tool-call loop like a typical function-calling setup? No. That's the point of this being a built-in tool — Bedrock runs search, fetch, and reformulation server-side and returns the final grounded answer in one API call.

Key takeaways

Further Reading

• Amazon Bedrock AgentCore Runtime: Stateful MCP
• Amazon Bedrock Agents Classic Enters Maintenance Mode
• MCP Protocol Goes Stateless: July 28, 2026 Migration Guide
• Web Search on Amazon Bedrock — official AWS docs
• Introducing Web Search on Amazon Bedrock — AWS ML Blog