I Checked the Egress IPs of Web Fetch and MCP Connector on Claude Platform on AWS

When Claude Platform on AWS's Web Fetch and MCP Connector access external sites, where do the requests originate from? I observed the egress IP from the access logs of a Lambda function URL and verified through actual measurement whether it stays within the AWS network.

Previous articles:

https://dev.classmethod.jp/articles/claude-platform-on-aws-ga-setup/

https://dev.classmethod.jp/articles/claude-platform-on-aws-bedrock-differences/

TL;DR

Observation results (as of May 13, 2026):

• Both are Columbus, Ohio (US) according to GeoIP
• No difference in egress IP was observed between inference_geo: us and global

Background

In the previous article, I presented a decision flowchart comparing it with Bedrock, and concluded "if data residency requirements are strict, choose Bedrock." Bedrock has a clear data boundary and management model as an AWS service.

On the other hand, for Claude Platform on AWS's Web Fetch / MCP Connector, the official documentation does not explicitly state where the egress is for external communication. In this article, I verify this through actual measurement.

inference_geo: A parameter of the Anthropic API that specifies the geographic routing of inference processing. As of May 2026, only "us" and "global" can be selected.

Verification Method

I created two Lambda function URLs in my own verification account in us-east-1, and invoked them from Claude Platform on AWS's Web Fetch / MCP Connector.

• echo-headers: Returns requestContext.http.sourceIp, the headers, and a timestamp
• mcp-echo-server: A minimal implementation that responds to MCP initialize / tools/list / tools/call

The egress IP in this article refers to the IP observed as requestContext.http.sourceIp contained in the Lambda function URL event.

Verification patterns: 3 models (Opus 4.7 = claude-opus-4-7, Sonnet 4.6 = claude-sonnet-4-6, Opus 4.6 = claude-opus-4-6) × 2 geo (us, global) = 6 patterns. All of them are models that support Web Fetch / MCP Connector.

import json, logging, time

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def handler(event, context):
    body = {
        "source_ip": event.get("requestContext", {}).get("http", {}).get("sourceIp"),
        "headers": event.get("headers", {}),
        "timestamp_ms": int(time.time() * 1000)
    }
    logger.info(json.dumps(body))
    return {
        "statusCode": 200,
        "headers": {"content-type": "application/json", "cache-control": "no-store, max-age=0"},
        "body": json.dumps(body, indent=2)
    }

import json, logging, time

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def handler(event, context):
    source_ip = event.get("requestContext", {}).get("http", {}).get("sourceIp")
    headers = event.get("headers", {})
    ts_ms = int(time.time() * 1000)

    logger.info(json.dumps({"source_ip": source_ip, "headers": headers, "timestamp_ms": ts_ms}))

    if event.get("requestContext", {}).get("http", {}).get("method") != "POST":
        return {"statusCode": 405, "body": "Method not allowed"}

    req = json.loads(event.get("body", "{}"))
    req_id = req.get("id")
    method = req.get("method", "")

    if method == "initialize":
        result = {"protocolVersion": "2025-11-25", "capabilities": {"tools": {}},
                  "serverInfo": {"name": "echo-mcp", "version": "1.0.0"}}
    elif method == "tools/list":
        result = {"tools": [{"name": "get_server_info", "description": "Returns caller IP and headers",
                             "inputSchema": {"type": "object", "properties": {}, "required": []}}]}
    elif method == "tools/call":
        result = {"content": [{"type": "text", "text": json.dumps(
            {"caller_ip": source_ip, "caller_headers": headers, "timestamp_ms": ts_ms})}]}
    elif method.startswith("notifications/"):
        return {"statusCode": 202, "body": ""}
    else:
        return {"statusCode": 200, "headers": {"content-type": "application/json"},
                "body": json.dumps({"jsonrpc": "2.0", "id": req_id,
                                    "error": {"code": -32601, "message": f"Unknown: {method}"}})}

    return {
        "statusCode": 200,
        "headers": {"content-type": "application/json", "cache-control": "no-store, max-age=0"},
        "body": json.dumps({"jsonrpc": "2.0", "id": req_id, "result": result})
    }

Web Fetch Observation Results

Request Example

curl -X POST "https://aws-external-anthropic.us-east-1.api.aws/v1/messages" \
  -H "x-api-key: ${ANTHROPIC_AWS_API_KEY}" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-workspace-id: ${ANTHROPIC_WORKSPACE_ID}" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-4-6",
    "max_tokens": 1024,
    "inference_geo": "us",
    "tools": [{"type": "web_fetch_20250910", "name": "web_fetch", "max_uses": 1}],
    "messages": [{"role": "user", "content": "Fetch https://xxxxx.lambda-url.us-east-1.on.aws/?t=<timestamp>"}]
  }'

Results of the 6 Patterns

The egress IP was the same even when changing the model or inference_geo.

IP details:

Note that behavior that appeared to be caching was seen with the same URL, so I avoided it by adding a timestamp to the query parameter.

MCP Connector Observation Results

Request Example

curl -X POST "https://aws-external-anthropic.us-east-1.api.aws/v1/messages" \
  -H "x-api-key: ${ANTHROPIC_AWS_API_KEY}" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: mcp-client-2025-11-20" \
  -H "anthropic-workspace-id: ${ANTHROPIC_WORKSPACE_ID}" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-4-6",
    "max_tokens": 1024,
    "inference_geo": "us",
    "mcp_servers": [{"type": "url", "url": "https://xxxxx.lambda-url.us-east-1.on.aws/", "name": "echo-mcp"}],
    "tools": [{"type": "mcp_toolset", "mcp_server_name": "echo-mcp"}],
    "messages": [{"role": "user", "content": "Call get_server_info"}]
  }'

Results of the 6 Patterns

Unlike Web Fetch, the last octet varied with each request. However, all of them fell within 160.79.106.0/24.

IP details:

Comparison Table

For reference, I also checked the case of accessing the same URL from Claude Code, which runs locally.

Summary

Based on the whois / PTR / Origin ASN results, the egress IPs used when Claude Platform on AWS's Web Fetch / MCP Connector access external sites were observed as IP ranges related to Google LLC / Anthropic, PBC, rather than AWS. However, this verification does not directly prove the execution platform or the physical placement of the inference processing itself.

The egress IP may change on the service side in the future. If data residency requirements are strict, it seems best to prioritize considering Amazon Bedrock, which has a clear data boundary and management model as an AWS service. On the other hand, if you value Claude Platform features such as Web Fetch and MCP Connector, it would be good to consider Claude Platform on AWS while taking the egress behavior found this time into account.

Reference Links

• Claude Platform on AWS - Official Documentation
• MCP Connector - Official Documentation