Google Custom Search Shuts Down in 2027 — I Replaced It with Amazon Bedrock AgentCore Web Search

Google Custom Search JSON API is closed to new customers. Existing customers have until January 1, 2027 to move to another service. Google calls Vertex AI Search a favourable alternative for searches over up to 50 domains; for full-web search, it asks customers to contact it. Google’s overview is specific to the JSON API, not every Google Custom Search product.

I started implementing GenAI-enabled software from early 2023, back then developers have already recommended Google's CSE API as a great source for any AI agents to perform question and answer that requires up to date information. If Google were not making this deprecation, I would have been very happy to continue with my current setup.

For an existing paid Custom Search JSON API customer, the published rate is $5 per 1,000 queries after the 100-per-day free tier. Amazon Bedrock AgentCore Web Search is $7 per 1,000 queries. I chose the higher per-query price because the search tool could live behind an existing AWS account and its access controls, rather than introducing another vendor and review process.

I considered Brave and Exa too, but this is not a search-quality benchmark. I did not measure matched-query relevance, latency, or like-for-like total cost. This is a field report on using AgentCore Gateway as an AWS-native authorisation boundary.

The useful lessons were not the connector’s happy path. They were version pinning, validating security controls, and debugging each layer separately.

Amazon describes Web Search Tool as a managed, MCP-compliant connector for AgentCore Gateway. It is currently available in us-east-1, eu-west-1, and ap-northeast-1, and costs $7 per 1,000 queries. AWS pricing and the connector documentation are the source of those figures.

The connector removes third-party search API keys and provider-specific result parsing. It does not remove the need to configure IAM, a gateway, and an MCP client.

The tool accepts:

query: up to 200 characters maxResults: 1–25 results, default 10 filters: domain and publication-date filters when the target uses connector version 1.2.0 or later AWS says the index is Amazon-operated, spans tens of billions of documents, refreshes continuously, and keeps queries within AWS infrastructure. Those are service claims, not findings I independently verified. AWS’s acceptable-use terms also require you to retain and display source citations and links when surfacing search results to end users.

Keep two identities distinct:

For Web Search, the gateway service role needs these two actions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "InvokeGateway",
      "Effect": "Allow",
      "Action": "bedrock-agentcore:InvokeGateway",
      "Resource": "arn:aws:bedrock-agentcore:us-east-1:111122223333:gateway/*"
    },
    {
      "Sid": "InvokeWebSearch",
      "Effect": "Allow",
      "Action": "bedrock-agentcore:InvokeWebSearch",
      "Resource": "arn:aws:bedrock-agentcore:us-east-1:aws:tool/web-search.v1"
    }
  ]
}

Scope the trust policy to gateway ARNs, not every AgentCore resource in the account:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "bedrock-agentcore.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "111122223333"
        },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:bedrock-agentcore:us-east-1:111122223333:gateway/*"
        }
      }
    }
  ]
}

Create an MCP gateway with IAM authorisation:

aws bedrock-agentcore-control create-gateway \
  --name websearch-gw \
  --role-arn "$ROLE_ARN" \
  --protocol-type MCP \
  --authorizer-type AWS_IAM \
  --region us-east-1

Choose the inbound authorisation model deliberately. The gateway service role is not a substitute for the caller’s own identity policy: grant the Pi’s AWS principal bedrock-agentcore:InvokeGateway on this gateway ARN.

Then add the connector target. Pinning 1.2.0 makes the filters described above part of the configuration instead of depending on a future default:

client.create_gateway_target(
    gatewayIdentifier=gateway_id,
    name="web-search-tool",
    targetConfiguration={
        "mcp": {
            "connector": {
                "source": {
                    "connectorId": "web-search",
                    "version": "1.2.0",
                },
                "configurations": [
                    {"name": "WebSearch", "parameterValues": {}}
                ],
            }
        }
    },
    credentialProviderConfigurations=[
        {"credentialProviderType": "GATEWAY_IAM_ROLE"}
    ],
)

Wait for the target to reach READY before diagnosing tools/list. A target still being created can look like an empty tool list.

Before adding Claude Code or a proxy, I sent raw SigV4-signed MCP requests directly to the gateway:

initialize
notifications/initialized
tools/list
tools/call

This isolates the gateway, IAM, connector, and MCP transport from the editor integration. Three details matter:

Accept header that includes both application/json and text/event-stream. initialize returns Mcp-Session-Id, echo it on later requests; do not assume every server issues one. The Web Search result appears in an MCP content block, with the useful payload represented as JSON text. Parse the transport envelope first, then the search-result payload.

AWS currently says its index reflects new and changed content within minutes. My own same-day result was only a sanity check, not a measurement of refresh behaviour. If freshness matters, test the queries that matter to your application.

Claude Code does not natively sign the gateway’s SigV4 requests, so I used AWS’s MCP proxy as a local stdio bridge:

{
  "mcpServers": {
    "awswebsearch": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws-cli@latest",
        "${GATEWAY_URL}",
        "--service", "bedrock-agentcore",
        "--region", "us-east-1"
      ]
    }
  }
}

Use the CLI distribution, mcp-proxy-for-aws-cli, with uvx; the unsuffixed package is the library distribution. Claude Code expands ${VAR} syntax in .mcp.json, so GATEWAY_URL can stay outside version control. A client that does not support configuration expansion needs the literal gateway URL instead.

The final check should make a real search and return a source URL—not merely list the tool.

--read-only can hide Web Search The proxy’s --read-only option keeps only tools that declare readOnlyHint=true. Web Search did not advertise that annotation in my test, so the proxy hid it without a warning. If a tool disappears, compare tools/list with and without the flag before changing IAM.

connector locally I hit an older AWS CLI service model that did not know the connector member and rejected the request before it reached AWS. The symptom is an “Unknown parameter” validation error and no CloudTrail event. Upgrade the CLI or SDK before investigating IAM; current AWS documentation includes CLI support for this target type.

Do not change several layers at once. Test in this order:

That sequence makes a failure actionable: model access, gateway/IAM, proxy configuration, or end-to-end tool use.

AgentCore supports resource-based policies on gateways. I applied a temporary explicit Deny for my public egress IP, confirmed that the caller received HTTP 403, and then removed the policy. That was more useful than merely seeing an accepted policy document.

Keep these rules explicit:

Resource must be the exact ARN of the gateway; * is not valid here.Deny with IpAddress is a blocklist. A deny-based IP allowlist uses NotIpAddress."Principal": "*" and narrow access with conditions. Establish principal-based access first, add IP restrictions second, and automate rollback for deliberate-deny tests.

Web Search queries and Gateway operations are metered separately. AWS lists Web Search at $7 per 1,000 queries and Gateway operations—such as listing tools, invoking tools, and pings—at $0.005 per 1,000 invocations.

The second meter is worth recognising in Cost Explorer, but it is usually small. Even four Gateway operations per search add $0.02 per 1,000 searches beside the $7.00 search charge. Measure the traffic pattern, but do not mistake a chatty MCP client for a meaningful change in search cost.

Delete resources in this order:

targets -> resource policy -> gateway -> role policy -> role

Wait for deletion to complete, then remove the manually created IAM policy and role. That removes the AgentCore resources; audit records, retained logs, local MCP configuration, and package caches may still remain.

Choose AgentCore Web Search when the requirement is specifically an AWS-native search tool behind an AgentCore Gateway, with SigV4 or OAuth access control and resource-policy enforcement. In that situation, the higher query price buys an operational boundary, not demonstrated search-quality superiority.

Do not choose it solely because an application needs web search. I did not benchmark it against Brave or Exa on equivalent workloads. Without a concrete need for the AWS authorisation and governance model, the extra integration surface is hard to justify.