Bedrock Web Search in GovCloud: an ADR on grounding under compliance

The problem that brought me here is old: LLM-assisted decision systems in regulated domains need provenance, not fluency. When an analyst asks "what is the current limit on that quota" or "is this product still authorized", an answer without an auditable link is a liability, not an asset.

Until now I solved it with one of two ugly options. First: my own index — crawler, normalization, embeddings, reindexing — which nobody wants to operate and which ages in days. Second: a third-party search API called from a Lambda, which means egress outside the account, a secret to rotate, an egress allowlist, and the tool-call loop written by hand. I ran exactly that design for months in my own content pipeline, with hand-rolled SigV4, and it broke for reasons that had nothing to do with the business problem.

The forces that weigh on this decision, hardest first: (1) query data must not leave the provider boundary without explicit control — in GovCloud that is a requirement, not a preference; (2) every claim shown to a user must carry a source; (3) cost is per query and is not negligible; (4) the team should operate neither index nor crawler; (5) authorization must be central, enforceable per Organization and per Region, with an audit trail. The tool landing in GovCloud addresses (1) and (4), but (2), (3) and (5) remain my work.

Before deciding, it is worth pinning down the object. Web Search is a server-side tool exposed only through the Responses API on the bedrock-mantle endpoint — it does not exist on bedrock-runtime, nor in Converse, nor in InvokeModel. You add {"type": "web_search"} to the tools array using OpenAI's own client library with a Bedrock API key, and the model decides whether to call it. That ties the decision to one model family: per the documentation, GovCloud (US-West) supports openai.gpt-5.6-terra, openai.gpt-5.6-luna and openai.gpt-5.4; commercial Regions add gpt-5.6-sol and gpt-5.5. There is no Claude, Nova or Mistral on this path.

Internally there are two operations, and that distinction is the heart of the ADR. Search returns title, URL and snippet from the web index and knowledge graph maintained by Amazon, and makes no outbound call. Fetch retrieves the content of a specific URL: with external_web_access=false it reads only the Bedrock cache; with true it checks the cache and reaches the external web only on a cache miss.

Retrieval is strictly regional — each Region runs its own search and fetch tier, and queries, fetches, index data and results are not routed across Regions. us-gov-west-1 is one of those Regions, alongside us-east-1, us-east-2 and us-west-2. Context volume per Search call is governed by search_context_size: low up to 5 observations, medium up to 11 (the default), high up to 25 — a budget shared across multiple queries in the same call. That parameter does not cap how many Search calls the model makes per turn.

Decision: adopt option A — native Web Search in cache-only mode — with the parameter set explicitly and the permission denied by SCP. The configuration is deliberately redundant, because the parameter and the permission fail in different ways.

In code, every caller sends tools=[{"type":"web_search","external_web_access":false,"search_context_size":"low"}]. low is my wrapper's default; medium is opt-in per research route; high requires justification, because 25 observations per call inflate input by something on the order of 10k tokens per turn.

At the perimeter, an SCP denies bedrock-websearch:ExternalWebAccess across the whole Organization. Note that IAM granularity here is short: the three actions (InvokeSearch, InvokeFetch, ExternalWebAccess) support only Resource: "*", and the sole condition key is the global aws:RequestedRegion. So the "restrict by Region" the announcement mentions is literally a StringEquals on aws:RequestedRegion — and I use it to pin us-gov-west-1 in the regulated perimeter, which is also the only way to stop a mis-routed call from being served by another regional tier.

On application roles I do not use AmazonBedrockFullAccess. I use a custom policy with InvokeSearch and InvokeFetch under the Region condition, because I want the absence of ExternalWebAccess to be a recorded decision, not a side effect of whichever managed policy somebody attached.

CloudTrail with data events enabled for bedrock-websearch is part of the decision, not a follow-up: without it, denials are reported nowhere.

Cost. Billing is per query — a query is one search request. The AgentCore page lists US$ 7 per 1,000 queries for its variant; independent analyses put the built-in tool near US$ 12 per 1,000 (confirm the current rate for your Region on the Bedrock pricing page before modelling). The budget-breaking detail is not the unit price: it is that search_context_size caps observations per call but does not cap how many Search calls the model makes in a turn. A multi-hop turn that reformulates the query twice costs three queries. At US$ 0.012 per query, 50k turns/month at 3 queries is US$ 1,800/month in search alone, before inference — and before the input inflated by observations. Model per turn, not per query, and put a daily token and query ceiling in your own wrapper, on the application side, because IAM does not count calls.

Idempotency. The call is not idempotent: a retry re-runs the searches and bills again. My retry is max_attempts=2 with jitter plus a result cache keyed on sha256(prompt + modelId + toolConfig), TTL in hours. Caller-side timeouts must accommodate serial hops inside a single call — in my article generator I operate with a 300 s ceiling.

Audit. By design, CloudTrail does not expose query text, URLs or raw results: query text is treated like an inference prompt. You get who called, when, from where, fetchMode, urlCount, failedUrlCount and fetchedSources. If your regulator wants to know what the agent consulted, that answer is not in CloudTrail — it is in the citation ledger you write from the url_citation annotations.

The ReadOnly illusion. AmazonBedrockExternalWebSearchReadOnly and AmazonBedrockExternalWebSearchFullAccess currently have identical effective permissions — the "ReadOnly" version does not restrict external retrieval. If your security review approves by policy name, it approved external web access believing it approved reads.

The illusion of restricting sources via IAM. Denying InvokeSearch while keeping InvokeFetch does not confine the model to your sources: Fetch applies to any URL the model produces, including one that came from the user's prompt or from its own parametric memory. Source control, if it is a requirement, must live in the application — validating each cited URL against an allowlist before display.

Prompt injection through retrieved content. Snippets and fetched pages are untrusted input entering the same context as the instruction. In regulated workloads I treat a Search observation as data, never as a command, and keep the injection filter on both sides of the turn — the same discipline I apply to any RAG.

Freshness that misleads. In cache-only mode, freshness is Amazon's index and cache, not the origin. For pricing, quotas and regulatory deadlines I do not trust what came back without checking the date in the answer itself — and I write around whatever I cannot confirm.

Model coupling. The tool exists only on the Responses API over bedrock-mantle, on GPT models. If tomorrow the model decision moves to Claude or Nova, the grounding path moves with it — which is why I kept option C alive in the record, not as a footnote.