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

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

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.

Alternative Search Options

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 Bedrock AgentCore Web Search

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.

Creating the Gateway and Connector

Keep two identities distinct:

  • The gateway service role is assumed by AgentCore to invoke the Web Search connector.
  • The caller identity-the AWS credentials on the Pi or another client-needs its own permission to invoke the specific gateway.

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

Configuring the Gateway and Connector

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:

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.

Verifying the Gateway

Before adding an editor, I sent raw SigV4-signed MCP requests directly to the gateway:

initialize notifications/initialized
tools/list
tools/call

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

  • Send an Accept header that includes both application/json and text/event-stream.
  • Handle either a JSON response or an SSE stream.
  • If 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.

Connecting Claude Code

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.

Teardown

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.

Verdict

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.

Read on DEV Community ↗ ← Back to News

Comments

No comments yet. Start the discussion.