Can You Use Web Search with Claude on Bedrock? Why It's Not Supported and What to Do Instead

Claude on Bedrock Does Not Support Anthropic's Official Web Search Tool

Anthropic's web search is a server-side tool — you simply add {"type": "web_search_20260209", "name": "web_search"} to the tools array in your API call, and Claude proactively executes searches and returns result text along with citation fields (cited_text / url / title). The search execution, billing, and citation generation are all hosted on Anthropic's side.

The Anthropic Web Search Tool documentation explicitly lists the Claude API, Microsoft Foundry, and Google Vertex AI as supported platforms, but Amazon Bedrock is not included. In the AWS re:Post thread "Web Search for Anthropic Models in Bedrock", AWS has also stated outright that "web_search_20250305 is not currently supported on Bedrock." Passing this tool definition to a Claude call on Bedrock results in a ValidationException.

Bedrock itself does have a tool use feature that allows you to pass toolSpec definitions and have Claude call external functions. However, this is a client-side tool mechanism — it accepts function definitions but leaves execution to the client — and there is no pathway to relay requests to Anthropic's hosted web_search endpoint. On Bedrock, "web search that handles execution and result storage" must be designed as something entirely separate from Anthropic's direct web_search_20260209.

Why web_search Is Not Supported on Bedrock

Anthropic's server-side tools (web_search, code_execution, etc.) require subsystems that Anthropic operates independently outside the inference path — things like search engine crawlers and sandboxed VMs. Because these are tightly coupled to Anthropic's infrastructure, Bedrock's architecture — which only exposes the inference backend — makes it difficult to bring the full tool execution pipeline onto the Bedrock side.

The Claude in Amazon Bedrock documentation confirms that while Bedrock provides access to inference APIs and some tool-calling integrations, "Anthropic-hosted features" such as server-side web search, the Files API, Skills, and Managed Agents are being added incrementally. No concrete roadmap for when these will arrive has been publicly announced — it depends on agreements between Anthropic and AWS.

In other words, on Bedrock you must design who hosts the search engine and who pays for it. Every alternative in the following sections is essentially a different answer to the question: "who owns responsibility for executing the search?"

Alternative 1: Register a Search API as an Action Group in Bedrock Agents

The first option is to register a custom search tool as an action group in Bedrock Agents. Agents is Bedrock's orchestration feature — it lets you pass tool definitions to Claude models and call external APIs defined via Lambda functions or OpenAPI schemas.

The search engine itself lives outside AWS. Common options include:

1. Brave Search API: Free up to 2,000 queries/month; $3 / 1,000 queries beyond that.
2. Tavily: Free up to 1,000 queries/month; pay-as-you-go at $0.008 / query.
3. SerpAPI: Google SERP scraping; from $50/month for 5,000 queries.
4. Bing Search API (deprecated as of August 2025 — not recommended for new projects).

Write a thin Lambda wrapper that calls your chosen search API and returns results as JSON, then register that function ARN as an action group in your Bedrock Agent. Claude will call search(query) as needed, then incorporate the returned text into context in a RAG (Retrieval-Augmented Generation — a technique that improves answer quality by appending externally retrieved text into the prompt context) fashion to generate its response.

The advantages are full AWS-native governance (search queries and results stay within your AWS account logs and never flow to Anthropic) and the option to consolidate billing by purchasing search APIs through AWS Marketplace. The downsides are that you must design your own citation format, and Bedrock inference charges and search API charges are billed separately, stacking on top of each other.

Using OpenSearch Service's Agentic Search, you can also build a hybrid setup that handles both internal document search and web search under the same agent.

Alternative 2: Web Search via MCP Server with Claude Cowork on Bedrock

The second option is to inject a web search tool via an MCP (Model Context Protocol) server using Claude Cowork on Bedrock. This architecture was formalized in the AWS Machine Learning Blog post "Running Claude Cowork in Amazon Bedrock" — the inference backend stays on Bedrock while the tooling is offloaded to the MCP ecosystem.

MCP is a tool-connection standard proposed by Anthropic that lets you expose web search, internal databases, SaaS integrations, and more to clients through a unified interface. Connect Brave Search's MCP server or Tavily's MCP server via a claude_desktop_config.json-style configuration, and when a user asks "look that up on the web" in Cowork's chat UI, tool selection is automatically routed to the MCP server.

The strength of this approach is that the user experience closely mirrors the direct API's web search. Citations are rendered by Cowork using the metadata (URL, title) returned by the MCP server. The trade-off is that the caller is responsible for operating the MCP server — you'll need to decide whether to run it persistently on internal ECS/Fargate or use a public MCP endpoint like Brave's.

Cowork on Bedrock supports per-IAM-principal cost allocation and MDM distribution, making it a natural fit for organizational deployments where you want to roll out "Claude with web search" to all employees.

Alternative 3: Migrate to Claude Platform on AWS

The third option is to migrate away from Bedrock entirely and use Claude Platform on AWS. This is a managed service launched by Anthropic in partnership with AWS in 2026, available through AWS Marketplace. Its API specification and feature set are said to be close to the direct API, though detailed official Anthropic documentation is not yet publicly available at the time of writing.

According to third-party summaries, all features available in the direct API — including Managed Agents, Skills, the code execution tool, web search, the Batch API, and Console — are available from day one (see: Claude Platform on AWS vs Bedrock vs Direct API comparison). You should be able to pass web_search_20260209 directly in the tools array and get the same behavior and citation format as the direct API.

Pricing matches the Anthropic direct API: web search costs $10 / 1,000 searches, with input tokens for the search result text billed separately. Billing goes through AWS Marketplace and rolls into your monthly AWS invoice, so from an internal accounting perspective you maintain the same "billed from AWS" setup as Bedrock.

The downsides are that data handling responsibility stays on Anthropic's side (inference and search run on Anthropic-hosted infrastructure, not within your AWS account), and options like Bedrock's Recurring Inference Profiles and PrivateLink integration are not yet fully available.

Feature Differences: Direct API vs. Claude Platform on AWS vs. Bedrock

Here is a side-by-side comparison of the three pathways focused on web search (as of May 2026):

1. Anthropic Direct API: Supports both web_search_20260209 and 20250305. Full support for dynamic filtering and all parameters: max_uses, allowed_domains, blocked_domains, user_location. Price: $10 / 1,000 searches.
2. Claude Platform on AWS: Per third-party summaries, equivalent to the direct API — same tool definitions, same pricing, same citation format. Billed via AWS Marketplace.
3. Microsoft Foundry: Supports web_search (see Foundry documentation).
4. Google Vertex AI: Supports web_search.
5. Amazon Bedrock: Not supported. Requires alternative implementation via Bedrock Agents action groups or Cowork on Bedrock + MCP.
6. Bedrock tool use: Accepts client-side tool definitions, but does not relay Anthropic-hosted web_search.

There is a possibility that Bedrock will eventually support web_search, but as of now no concrete announcement has been made from AWS. For new projects where "Bedrock + web search" is a requirement, migrating to Claude Platform on AWS or building out Alternative 1 or 2 is the realistic path forward.

Choosing the Right Approach by Use Case

Here is a summary of which option fits which requirement:

1. Just want to add web search to an existing Bedrock pipeline: Alternative 1 (Bedrock Agents + Brave / Tavily). Adding a single Lambda function keeps the implementation cost minimal.
2. Want to add web search to a company-wide Cowork deployment: Alternative 2 (Cowork on Bedrock + MCP). Running an MCP server persistently on internal ECS/Fargate lets you handle internal search engines (Confluence, Notion, SharePoint) through the same framework.
3. Need full feature parity with the direct API: Alternative 3 (Claude Platform on AWS). If you need web search, Skills, and Managed Agents all at once, migrating away from Bedrock is faster than trying to replicate everything.
4. Need data to stay entirely within AWS: Alternative 1. If you cannot send search queries to Anthropic, Bedrock Agents is the only option.
5. Want to minimize cost: Alternative 1 (Brave Search free tier + Bedrock inference pricing) is the cheapest. There is no way to use the direct API's search tool through Bedrock, so Platform on AWS should be treated as "the price of feature parity."

Summary

Claude on Amazon Bedrock does not support Anthropic's server-side web search tools (web_search_20260209 / 20250305). While Bedrock's tool use framework accepts client-side tool definitions, it has no mechanism to relay requests to Anthropic's hosted search endpoint — so passing the tool definition directly goes unrecognized.

The three alternatives are Bedrock Agents + external search API, Cowork on Bedrock + MCP server, and Claude Platform on AWS. The practical breakdown: Bedrock Agents for AWS-complete data residency, Cowork + MCP for organizational deployment, and Platform on AWS for direct API feature parity.

If "Bedrock + web search" is a requirement for a new project, the safest approach from both a cost and operational standpoint is to start with a lean Alternative 1 implementation using Bedrock Agents, then expand to Cowork or Platform as needs grow.

Sources

• Web Search Tool — Claude API Docs
• Claude in Amazon Bedrock — Claude API Docs
• Web Search for Anthropic Models in Bedrock — AWS re:Post
• Tool use — Amazon Bedrock User Guide
• Running Claude Cowork in Amazon Bedrock — AWS Machine Learning Blog
• Configuring Agentic Search with Bedrock Claude — Amazon OpenSearch Service
• Claude Platform on AWS vs Bedrock vs Direct API (2026)