按产品分类浏览文章 关于本站

Kiro 使用 AgentCore Web Search Tool 替代 EXA Search 的配置 - AgentCore Gateway 配置 CUSTOM_JWT 认证

本文介绍了 Kiro 通过 MCP 协议集成 Amazon Bedrock AgentCore Web Search Tool 作为联网搜索引擎的方法,由此可以替代 EXA Search 等第三方搜索服务 MCP。针对开发者本机没有 IAM User 密钥的场景,方案将 AgentCore Gateway 配置为 CUSTOM_JWT 认证,以 Amazon Cognito 为身份提供商,采用 OAuth 2.0 授权码加 PKCE 浏览器跳转认证的方式。本方案在开发者本机的 mcp.json 配置文件中不保存任何密钥,由此实现高安全性的认证。通过本文的配置,Bedrock AgentCore Web Search Tool 可替代 EXA Search 作为搜索方案。

一、背景

很多开发工具包括 Claude Code、Codex、Kiro、乃至 Amazon Quick 通常使用 EXA Search 等第三方搜索服务商作为 Agent 工具的搜索引擎,使用 MCP 协议将 EXA Search 挂载到常用 AI 开发工具。在 Bedrock AgentCore Web Search Tool 发布后,不再需要 AWS 之外的第三方搜索工具了,用户可为自己的 AI 开发工具集成 Bedrock AgentCore Web Search Tool 替换 EXA Search 等第三方搜索工具。这样做的好处是,整个数据流在 AWS 平台上完全闭环,数据不出 AWS,无须为引入别的供应商而重新评估数据安全边界。

本文介绍 AI 开发工具以 MCP 协议集成 Bedrock AgentCore Web Search Tool 的方法,主要操作配置复杂点在于 Bedrock AgentCore 上配置 MCP Server 的认证方案。本文的操作对象为 Kiro CLI/IDE,需要将其升级到 2026-07 之后最新版本;Kiro IDE 的 MCP 面板在 2026-07 年时候的 1.x 版本也可能正常工作。

二、Bedrock AgentCore Gateway 的认证方案选择

1、Bedrock AgentCore Gateway 支持的认证方式

Bedrock AgentCore Web Search Tool 搜索功能自身不是直接作为网络服务被调用的,而是集成在 Bedrock AgentCore Gateway 这个网关上,Agent 工具以 MCP 协议调用 AgentCore Gateway 网关后获得 Web Search Tool,这是唯一的调用方式。因此 AI 开发工具 Claude Code、Codex、Kiro、乃至 Amazon Quick,都需要以 MCP 协议连接到 AgentCore Gateway。

AgentCore Gateway 网关支持如下几种认证:

  • IAM 身份认证:即 AWS_IAM。调用方使用 AWS IAM 身份的凭证,请求需带 SigV4 签名。Gateway 会校验调用方是否具备 bedrock-agentcore:InvokeGateway 权限。
  • CUSTOM_JWT 令牌认证。使用 OIDC 认证方式,由外部身份提供商(如 Amazon Cognito、Okta、Auth0 等支持 OIDC 的提供商)签发 JWT,即 JSON Web Token,与 AgentCore Gateway 完成认证。
  • Offloaded(授权下放)类型,Gateway 本身不做鉴权决策,共两种子类型:
    • Authenticate only(AUTHENTICATE_ONLY):Gateway 仍会校验调用方的 SigV4 签名以确认身份,但不做任何授权判断,任何签名有效的 IAM 主体都会被转发到 Target,授权逻辑需要下游 Target 或附加的策略引擎(Policy Engine)来完成。
    • No Authorization(NONE):Gateway 对入站请求不做任何鉴权,请求可以是完全未认证的。

以上几种身份认证类型做小结:方式 1 适合在 AWS 云上服务之间调用,因为访问者具备 AWS IAM 身份;方式 2 适合第三方 SaaS 对接中的调用,OAuth 可扩展到各种规模的互联网应用;方式 3 适合网关托管的下级服务自己有认证机制的场景,此处不建议完全开放匿名访问方式。

2、AgentCore Gateway 不使用 IAM 认证的考量

在上一篇博客中介绍了使用 Strands Agents 开发一个 Agent,调用 AgentCore Web Search Tool,整个工作链条都是基于 AWS 云服务,因此选择 IAM 身份认证作为 AgentCore Gateway 的决策就非常合理。

针对开发者本机的 AI 开发工具,使用 IAM 认证方式有所不足。AI 开发工具运行在开发者本机,开发者不一定有 AWS IAM User 对应的 Access Key & Secret Key。通常在大型企业中有着严格的安全管理机制,且 DevOps 自动化部署和运维会限制云端特定环境才有 IAM User 和 Access Key & Secret Key,这在大量开发者桌面电脑上是不具备的。因此,如果一定要使用,那么需要定义特定权限的 IAM Policy、只提供最低用户权限,此外还要求 AI 开发工具客户端能支持 IAM 身份验证。

基于以上原因,在普通开发者本机的 AI 开发工具需要调用 Web Search Tool 时候,可以不选择 IAM 认证方式,而是将 AgentCore Gateway 配置为 JWT 认证,其认证过程不依赖于 AWS IAM User 账号体系。

3、为 AgentCore Gateway 选择 CUSTOM_JWT 认证方式

AgentCore Gateway 在使用 CUSTOM_JWT 认证场景时,根据 OAuth 2.0 协议的定义,Kiro 是 OAuth Client,AgentCore Gateway 是 Resource Server,此时还需要有身份认证提供商作为 Authorization Server。这里使用 AWS 云上的 Amazon Cognito 认证服务,或者第三方的 SSO 服务如 Okta 等支持 OIDC 认证的服务来承担这一角色。整套方案中,作为 MCP 调用客户端的 Kiro 的 mcp.json 配置文件中,是完全不写入任何认证密钥的,因此这是与 EXA Search 等 SaaS 形式搜索服务商配置逻辑完全不同的。

Kiro CLI 是运行在开发者本机的 CLI 工具,属于 OAuth 规范中的"公有客户端(Public Client)",Secret 写在本机配置文件里等同于没有保密性,所以是属于无法安全保存 Client Secret 的客户端类型。因此,在安全最佳实践上,使用 PKCE(Proof Key for Code Exchange)机制来提供一次性授权和密钥交换机制,防止认证过程中的密钥被截获。Kiro 原生支持 OAuth 认证方式中的 PKCE 认证。以 Amazon Cognito 作为认证服务为例,采用 OAuth 2.0 的 Authorization Code(授权码)+ PKCE 跳转认证,即 Kiro 客户端发起认证给出认证 URL,用户打开系统浏览器跳转到 Cognito 登录页,输入用户名、密码完成登录后换取短期 Token 通过 Gateway 的认证。

此方案中的 mcp.json 仅写入认证 URL 和 client_id 字段,第一次使用时候需要使用浏览器登录完成认证。认证通过后的 Token 过期时候,由 Refresh Token 自动静默续期,因此后续无需维护 mcp.json 配置文件。

4、不支持完全写死静态密钥的配置方式的说明

JWT 体系下还有一种面向机器对机器(M2M)的 Client Credentials 授权方式,可以用 Client ID 加 Client Secret 直接换取 Bearer Token 并硬编码到 mcp.json 配置文件中,这能省去浏览器登录环节。这种使用体验,非常接近在使用 EXA Search 等搜索服务商时候配置 mcp.json 的体验,在配置文件里边可以硬编码访问密钥。但是,在本方案下 Token 存在有效期限制,无法写“死”,也就是无法做到长期不更换。

这是因为 AgentCore Gateway 使用的 Bearer Access Token 不是永久凭据,而是 Cognito 签发出来的临时凭据,签发 Access Token 有效期限默认是 3600 秒(1小时),最长有效期为 24 小时。由于不能签发长期密钥,这意味着 MCP 客户端调用方需要频繁进行认证。

此外,客户端和服务器端都不支持自动获取/刷新 Token:

  • 作为服务器端的 Amazon Cognito 的 Client Credentials 流程不发放 Refresh Token,因此没有自动更新机制用于 Token Renew。
  • 作为客户端的 Kiro 不会自动执行 Client Credentials Grant,无法自动获取新 Token。

所以除非是写一个 Shell 脚本,自动生成新 Token,自动修改 mcp.json 配置文件,否则没有办法实现把 Token 写“死”,也就是无法做到长期不更换。

5、最终方案推荐

综上所述,没有办法像 EXA Search 等第三方 MCP 一样在 mcp.json 配置文件中使用写死 Token 的方式。当然,在配置文件中硬编码长期 Token 也存在安全隐患。因此最终给出的使用场景建议是:

  • 如果是云上应用环境/生产环境嵌入 APP 中:使用 AWS IAM 认证,分配 Access Key & Secret Key。
  • 开发者客户端的 AI 开发工具:使用 JWT 认证,配置认证服务,用户跳转到浏览器完成认证,后续能自动 Renew。

本文即讲解后者场景下的配置。第三章和第四章是 AWS 管理员配置 Cognito 为 AgentCore 提供 JWT 认证,第五章讲解最终用户如何挂载 MCP。

三、配置 Amazon Cognito 认证服务(需要 AWS 管理员权限)

注意:本章节需要 AWS 管理员权限,并且安装 AWS CLI 工具,创建并设置好 Access Key/Secret Key,以便于快速部署。

1、设置脚本需要的所有环境变量

本章创建 Kiro 认证所需的全部 Cognito 资源:用户池、Hosted UI 域名、应用客户端与测试用户。如果之前创建过使用 IAM 认证方式的 Bedrock AgentCore Gateway,这里会重新创建一个新的。

以下管理员配置中均需要这些变量。区域固定为 us-east-1。注意:截止本文编写时候,Web Search Tool 目前仅在该区域可用。所以 Cognito 服务也需要创建在这一区域。

REGION="us-east-1"
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
ROLE_NAME="AgentCoreWebSearchKiroGatewayRole"
GATEWAY_NAME="websearch-kiro-jwt-gateway"
USER_POOL_NAME="websearch-kiro-pool"
COGNITO_DOMAIN_PREFIX="websearch-kiro-${ACCOUNT_ID}"

2、创建 Cognito 用户池

USER_POOL_ID=$(aws cognito-idp create-user-pool \
  --pool-name "$USER_POOL_NAME" \
  --region "$REGION" \
  --query 'UserPool.Id' --output text)
echo "USER_POOL_ID=$USER_POOL_ID"

返回结果类似如下(形如 us-east-1_xxxxxxxxx):

USER_POOL_ID=us-east-1_o2qx89QGH

3、创建 Cognito 认证服务入口

现在创建 Cognito 认证服务的入口。

Cognito 对外提供认证的门户网页有两个版本,版本 1 无需额外配置即可直接使用;若使用新版 Managed Login(版本 2),必须先为应用客户端创建 branding style,否则浏览器打开登录页时无法渲染。为简化测试过程,下文的命令中显式指定 --managed-login-version 1,即使用经典 Hosted UI 版本的登录页。

此外,域名前缀需要在 Cognito 命名空间内全局唯一,因此在前一章节处理环境变量的时候,这里用账号 ID 拼接实现唯一 ID,避免名称冲突。

aws cognito-idp create-user-pool-domain \
  --domain "$COGNITO_DOMAIN_PREFIX" \
  --user-pool-id "$USER_POOL_ID" \
  --managed-login-version 1 \
  --region "$REGION"

命令执行成功后回显所设置的托管登录版本:

{
    "ManagedLoginVersion": 1
}

域名创建后需要 3-5 分钟才能生效,最终形成的 Hosted UI 根地址可用如下命令打印出来:

echo https://${COGNITO_DOMAIN_PREFIX}.auth.${REGION}.amazoncognito.com

4、创建应用客户端与用户

(1) 创建应用客户端

Kiro 在认证时会在本机 localhost 上启动回调监听服务,为了规避端口冲突,这里建议使用不常见的端口,例如这里修改为 38123 端口。

CLIENT_ID=$(aws cognito-idp create-user-pool-client \
  --user-pool-id "$USER_POOL_ID" \
  --client-name "kiro-websearch-authcode-client" \
  --no-generate-secret \
  --allowed-o-auth-flows code \
  --allowed-o-auth-scopes openid \
  --allowed-o-auth-flows-user-pool-client \
  --callback-urls "http://localhost:38123/oauth/callback" \
  --supported-identity-providers COGNITO \
  --prevent-user-existence-errors ENABLED \
  --region "$REGION" \
  --query 'UserPoolClient.ClientId' --output text)
echo "CLIENT_ID=$CLIENT_ID"

创建成功后返回 client_id 信息类似如下:

CLIENT_ID=xxxxxxxxxxxxxxxxxx

这个 client_id 不是针对某一个用户的,而是挂接在 Cognito 服务上的应用客户端的 ID,因此需要与用户登录时候的用户名/密码区分开。

(2) 创建用户

用管理员身份创建一个用户并设置永久密码:

TEST_USERNAME="user01"
TEST_PASSWORD="<自定义一个满足密码策略的强密码>"

aws cognito-idp admin-create-user \
  --user-pool-id "$USER_POOL_ID" \
  --username "$TEST_USERNAME" \
  --user-attributes Name=email,Value="kiro-tester@example.com" Name=email_verified,Value=true \
  --message-action SUPPRESS \
  --region "$REGION"

aws cognito-idp admin-set-user-password \
  --user-pool-id "$USER_POOL_ID" \
  --username "$TEST_USERNAME" \
  --password "$TEST_PASSWORD" \
  --permanent \
  --region "$REGION"

5、汇总创建好的资源名称以便于后续配置

以下信息在下一步以管理员身份配置 AgentCore 时候将会用到:

名称 用途
User Pool ID $USER_POOL_ID(形如 us-east-1_xxxxxxxxx 管理员配置 AgentCore Gateway 的 JWT Authorizer
Discovery URL https://cognito-idp.${REGION}.amazonaws.com/${USER_POOL_ID}/.well-known/openid-configuration 管理员配置 AgentCore Gateway 的 JWT Authorizer
Hosted UI 域名 https://${COGNITO_DOMAIN_PREFIX}.auth.${REGION}.amazoncognito.com 管理员配置 AgentCore 浏览器跳转登录与令牌兑换

以下信息在最终用户以 MCP 协议挂载时将会用到,注意保存:

名称 用途
Client ID $CLIENT_ID 最终用户以 MCP 协议挂载时使用的 oauth.clientId
测试用户 user01 及其密码 最终用户以 MCP 协议挂载时使用的浏览器登录验证
跳转 URL localhost:38123

至此 Cognito 配置完毕。下面开始 AgentCore Gateway 配置。

四、配置 AgentCore Gateway 与 Web Search Tool(需要 AWS 管理员权限)

注意:本章节的环境变量是继承了第三章的第 1 节的环境变量,继续配置。

1、创建 AgentCore 需要的 IAM Role

Gateway 出站调用 Web Search 后端时,需要代入一个 IAM 服务角色。信任关系仅允许 bedrock-agentcore.amazonaws.com 代入该角色,权限策略仅授予 bedrock-agentcore:InvokeWebSearch,用于调用 Web Search 后端。

补充说明:本文 Gateway 的入站认证采用 CUSTOM_JWT,Kiro 调用 Gateway 时由 JWT Authorizer 完成认证,因此 AgentCore 服务认证不依赖 IAM,所以 Gateway 服务角色中不需要授予 bedrock-agentcore:InvokeGateway

执行如下命令创建 IAM 角色,写入信任策略,允许 bedrock-agentcore 服务代入该角色:

aws iam create-role \
  --role-name "$ROLE_NAME" \
  --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"bedrock-agentcore.amazonaws.com"},"Action":"sts:AssumeRole"}]}' \
  --description "AgentCore Web Search demo gateway service role (for Kiro JWT auth)"

为该角色写入权限策略,仅授予调用 Web Search 后端所需权限。其中 Web Search Tool 的资源 ARN 由 AWS 拥有,account 段固定为 aws

aws iam put-role-policy \
  --role-name "$ROLE_NAME" \
  --policy-name "WebSearchInvokePolicy" \
  --policy-document "{
    \"Version\": \"2012-10-17\",
    \"Statement\": [
      {
        \"Sid\": \"InvokeWebSearch\",
        \"Effect\": \"Allow\",
        \"Action\": \"bedrock-agentcore:InvokeWebSearch\",
        \"Resource\": \"arn:aws:bedrock-agentcore:${REGION}:aws:tool/web-search.v1\"
      }
    ]
  }"

新建的 IAM 角色需要数秒钟才能完全生效,建议等待 1 分钟左右后再创建 Gateway,以降低 PassRole 校验失败的概率。

2、创建认证为 CUSTOM_JWT 类型的 AgentCore Gateway

Gateway 的 JWT Authorizer 指向第三章用户池的 Discovery URL,并同时配置 allowedClientsallowedScopesallowedClients 填入第三章创建的 Cognito 应用客户端 ID,仅允许该应用客户端下的用户通过 Gateway 校验;即使同一个 Cognito User Pool 用户池日后新增其他应用客户端,其 Token 也不能访问本 Gateway。

ROLE_ARN=$(aws iam get-role --role-name "$ROLE_NAME" --query Role.Arn --output text)
DISCOVERY_URL="https://cognito-idp.${REGION}.amazonaws.com/${USER_POOL_ID}/.well-known/openid-configuration"

aws bedrock-agentcore-control create-gateway \
  --name "$GATEWAY_NAME" \
  --role-arn "$ROLE_ARN" \
  --protocol-type MCP \
  --authorizer-type CUSTOM_JWT \
  --authorizer-configuration "{
    \"customJWTAuthorizer\": {
      \"discoveryUrl\": \"${DISCOVERY_URL}\",
      \"allowedClients\": [\"${CLIENT_ID}\"],
      \"allowedScopes\": [\"openid\"]
    }
  }" \
  --description "Web Search demo gateway for Kiro integration (CUSTOM_JWT inbound auth)" \
  --region "$REGION"

获取 Gateway ID 与状态,等待 status 变为 READY

GATEWAY_ID=$(aws bedrock-agentcore-control list-gateways \
  --region "$REGION" \
  --query "items[?name=='${GATEWAY_NAME}'].gatewayId | [0]" \
  --output text)

aws bedrock-agentcore-control get-gateway \
  --gateway-identifier "$GATEWAY_ID" \
  --region "$REGION" \
  --query '{status:status, gatewayUrl:gatewayUrl}'

返回结果类似如下:

{
    "status": "READY",
    "gatewayUrl": "https://websearch-kiro-jwt-gateway-aechsb1ccn.gateway.bedrock-agentcore.us-east-1.amazonaws.com/mcp"
}

3、挂载 Web Search Tool

注意:本步骤要求 AWS CLI 版本不低于 2.35.19,否则不支持 Web Search 连接器参数。

Web Search Tool 创建时候可以写入 MCP Tool 的描述信息,便于 Agent 发现 Tool 的能力并在适当的场合使用这个 Tool。以下命令中写入了一段中文描述信息,可按需自行修改。

aws bedrock-agentcore-control create-gateway-target \
  --gateway-identifier "$GATEWAY_ID" \
  --name "web-search" \
  --target-configuration '{"mcp":{"connector":{"source":{"connectorId":"web-search"},"configurations":[{"name":"WebSearch","description":"在互联网上检索当前的公开网页信息,返回标题、URL、发布日期与摘要片段,适用于回答实时事件、最新版本号、价格等训练数据之外的问题。","parameterValues":{}}]}}}' \
  --credential-provider-configurations '[{"credentialProviderType":"GATEWAY_IAM_ROLE"}]' \
  --region "$REGION" \
  --query targetId --output text

配置完成后,Kiro 执行 /mcp 或调用工具时能看到这段描述文本。命令执行成功后返回目标 ID,形如:

VP1YHEVFU5

查询目标状态,等待其变为 READY

aws bedrock-agentcore-control list-gateway-targets \
  --gateway-identifier "$GATEWAY_ID" \
  --region "$REGION" \
  --query "items[?name=='web-search'].{targetId:targetId, status:status}"

返回结果如下:

[
    {
        "targetId": "VP1YHEVFU5",
        "status": "READY"
    }
]

当显示 READY 即表示 Web Search 目标已可用。

4、汇总本章需要记录的值

名称 Kiro mcp.json 字段
Cognito Client ID $CLIENT_ID oauth.clientId
Gateway URL get-gateway 返回的 gatewayUrl url

至此配置完成。AgentCore Gateway 本身处于空闲状态不产生额外费用,实际计费发生在调用 Web Search 目标检索时。

下面开始 Kiro 用户的 MCP 配置。

五、最终用户 Kiro 等 AI 开发工具的 MCP 配置(开发者本机无须 AWS IAM/Access Key & Secret Key)

1、以 Kiro 为例的 MCP 配置文件示例

~/.kiro/settings/mcp.json(本机用户全局配置,对所有项目生效)中新增一个远程 MCP Server 条目。

将本文第三章第 5 节和第四章第 4 节中有用的 URL 替换到以下配置中。

{
  "mcpServers": {
    "agentcore-gateway": {
      "type": "http",
      "url": "<第四章创建的 Gateway URL>",
      "oauth": {
        "clientId": "<第三章创建的 CLIENT_ID>",
        "redirectUri": "<第三章创建的跳转端口>",
        "oauthScopes": ["openid"]
      }
    }
  }
}

实际组合完成后类似如下:

{
  "mcpServers": {
    "agentcore-gateway": {
      "type": "http",
      "url": "https://websearch-kiro-jwt-gateway-aechsb1ccn.gateway.bedrock-agentcore.us-east-1.amazonaws.com/mcp",
      "oauth": {
        "clientId": "38d1ierl6pv39i2kv6f41eg8t9",
        "redirectUri": "localhost:38123",
        "oauthScopes": ["openid"]
      }
    }
  }
}

2、Kiro-CLI 验证测试

启动 Kiro CLI 并加载上述配置后,执行 /mcp 命令查看服务器状态:

/mcp

首次连接时,agentcore-gateway 会显示为需要认证的状态,可以按快捷键 CTRL + y 直接复制认证 URL 到系统剪贴板。如下截图。

或者执行 /mcp auth 主动触发认证。如下截图。

/mcp auth

此时需要输入要发起认证的 MCP 的完整名称,然后按回车键,即可将认证地址复制到剪贴板。如下截图。

打开系统默认浏览器,粘贴剪贴板中的地址,跳转到 Cognito 的 Hosted UI 登录页,实际打开的授权 URL 形如:

https://websearch-kiro-<ACCOUNT_ID>.auth.us-east-1.amazoncognito.com/oauth2/authorize?response_type=code&client_id=<CLIENT_ID>&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Foauth%2Fcallback&scope=openid&code_challenge=<PKCE_CHALLENGE>&code_challenge_method=S256&state=<随机状态值>

用第三章创建的测试用户账号密码登录后,浏览器会跳转回本机的回调地址并显示认证成功页面:

http://localhost:8080/oauth/callback?code=<一次性授权码>&state=<随机状态值>

登录成功后,在 Kiro CLI 界面上按 Esc 键退出 MCP 清单,然后重新运行 /mcp 查看清单,可看到状态是验证成功。如下截图。

现在 Kiro-CLI 中直接提问触发联网搜索,验证完整链路是否可用。Token 过期后 Kiro 会自动使用 Refresh Token 静默刷新,无需重新走浏览器登录;如果刷新失败或需要切换测试账号,可用 /mcp logout 清除已保存的凭据后重新执行 /mcp auth

备注:本文在 AWS CLI 2.35.19、Kiro CLI 2.12.3 环境中验证通过。

3、Kiro IDE 验证测试

Kiro CLI 访问 MCP 验证登录成功后,会占用 OAuth 回调端口 38123,此时 Kiro IDE 如果也去登录这个 MCP 就会报错。

解决办法是:完全退出 Kiro CLI。然后等几秒后,在 Kiro IDE 的 MCP Server 清单下,对刚才配置的 AgentCore 点击鼠标右键,选择认证。此时不用重复输入密码,直接显示成功。

4、未来改进

Amazon Cognito 服务可对接外部 IdP,因此更优化的方案是,创建的 Cognito 作为认证服务后,不要在 Cognito 添加本地用户,而是再以外部 IdP 的方式挂载企业现有 SSO 统一认证平台。这样在调用这个 MCP 时候,身份认证跳转页面就是跳转到企业 SSO 认证界面,现有企业用户即可完成认证。

六、参考文档

Bedrock AgentCore Gateway 入站认证配置说明

Bedrock AgentCore CUSTOM_JWT Authorizer 字段说明

Amazon Cognito CreateUserPoolClient API 参考

Kiro CLI MCP 配置文档

Kiro CLI Agent 配置参考(OAuth 配置字段)

七、删除实验相关资源(不含 Kiro)

本章删除第三章和第四章创建的 AWS 云端资源,不修改或删除开发者本机的 Kiro 配置。删除操作不可逆,Cognito User Pool 删除后,其中的应用客户端和测试用户也会被永久删除。执行前需要确认这些资源没有被其他应用复用。

删除时必须遵循以下依赖顺序:

AgentCore Gateway Target
AgentCore Gateway
Gateway 专用 IAM Role

Cognito 托管域名
Cognito User Pool(同时删除 App Client 与测试用户)

1、设置资源名称

重新设置本文使用的区域和资源名称:

REGION="us-east-1"
ROLE_NAME="AgentCoreWebSearchKiroGatewayRole"
GATEWAY_NAME="websearch-kiro-jwt-gateway"
USER_POOL_NAME="websearch-kiro-pool"

2、删除 AgentCore Gateway Target 和 Gateway

先按名称查询 Gateway ID:

GATEWAY_ID=$(aws bedrock-agentcore-control list-gateways \
  --region "$REGION" \
  --query "items[?name=='${GATEWAY_NAME}'].gatewayId | [0]" \
  --output text)
echo "GATEWAY_ID=$GATEWAY_ID"

如果 Gateway 存在,删除该专用 Gateway 下的全部 Target,等待 Target 删除完成后再删除 Gateway:

if [[ -n "$GATEWAY_ID" && "$GATEWAY_ID" != "None" ]]; then
  TARGET_IDS=$(aws bedrock-agentcore-control list-gateway-targets \
    --gateway-identifier "$GATEWAY_ID" \
    --region "$REGION" \
    --query 'items[].targetId' \
    --output text)

  if [[ -n "$TARGET_IDS" && "$TARGET_IDS" != "None" ]]; then
    for TARGET_ID in $TARGET_IDS; do
      aws bedrock-agentcore-control delete-gateway-target \
        --gateway-identifier "$GATEWAY_ID" \
        --target-id "$TARGET_ID" \
        --region "$REGION"
    done

    while [[ "$(aws bedrock-agentcore-control list-gateway-targets \
      --gateway-identifier "$GATEWAY_ID" \
      --region "$REGION" \
      --query 'length(items)' \
      --output text)" != "0" ]]; do
      sleep 3
    done
  fi

  aws bedrock-agentcore-control delete-gateway \
    --gateway-identifier "$GATEWAY_ID" \
    --region "$REGION"

  while [[ "$(aws bedrock-agentcore-control list-gateways \
    --region "$REGION" \
    --query "length(items[?gatewayId=='${GATEWAY_ID}'])" \
    --output text)" != "0" ]]; do
    sleep 3
  done
fi

删除请求返回的状态通常为 DELETING。循环结束且按 ID 查询数量为 0 后,表示 Target 和 Gateway 已删除。

3、删除 Gateway 专用 IAM Role

本文创建的 IAM Role 仅供该 Gateway 使用。先删除内联策略,再删除角色:

if aws iam get-role --role-name "$ROLE_NAME" >/dev/null 2>&1; then
  if aws iam get-role-policy \
    --role-name "$ROLE_NAME" \
    --policy-name "WebSearchInvokePolicy" >/dev/null 2>&1; then
    aws iam delete-role-policy \
      --role-name "$ROLE_NAME" \
      --policy-name "WebSearchInvokePolicy"
  fi

  aws iam delete-role --role-name "$ROLE_NAME"
fi

注意:如果自行向该角色附加了其他内联策略或托管策略,必须先逐一删除内联策略并解除托管策略关联,否则 delete-role 会失败。不要删除已被其他工作负载复用的 IAM Role。

4、删除 Cognito 托管域名和 User Pool

按名称查询 User Pool ID。删除 User Pool 前,先读取并删除其 Cognito 托管域名:

USER_POOL_ID=$(aws cognito-idp list-user-pools \
  --max-results 60 \
  --region "$REGION" \
  --query "UserPools[?Name=='${USER_POOL_NAME}'].Id | [0]" \
  --output text)
echo "USER_POOL_ID=$USER_POOL_ID"

if [[ -n "$USER_POOL_ID" && "$USER_POOL_ID" != "None" ]]; then
  COGNITO_DOMAIN=$(aws cognito-idp describe-user-pool \
    --user-pool-id "$USER_POOL_ID" \
    --region "$REGION" \
    --query 'UserPool.Domain' \
    --output text)

  if [[ -n "$COGNITO_DOMAIN" && "$COGNITO_DOMAIN" != "None" ]]; then
    aws cognito-idp delete-user-pool-domain \
      --domain "$COGNITO_DOMAIN" \
      --user-pool-id "$USER_POOL_ID" \
      --region "$REGION"
  fi

  aws cognito-idp delete-user-pool \
    --user-pool-id "$USER_POOL_ID" \
    --region "$REGION"
fi

删除 User Pool 会同时删除其中的 kiro-websearch-authcode-client 应用客户端和 user01 测试用户,无须分别执行删除命令。

5、验证资源已删除

分别按名称查询 Gateway、User Pool 和 IAM Role:

aws bedrock-agentcore-control list-gateways \
  --region "$REGION" \
  --query "items[?name=='${GATEWAY_NAME}'].{name:name,gatewayId:gatewayId}" \
  --output json

aws cognito-idp list-user-pools \
  --max-results 60 \
  --region "$REGION" \
  --query "UserPools[?Name=='${USER_POOL_NAME}'].{Name:Name,Id:Id}" \
  --output json

aws iam list-roles \
  --query "Roles[?RoleName=='${ROLE_NAME}'].{RoleName:RoleName,Arn:Arn}" \
  --output json

三条命令均应返回空数组:

[]

至此,第三章和第四章创建的 AWS 云端实验资源已全部删除,本机 Kiro 配置不受影响。


最后修改于 2026-07-16