

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# Amazon Bedrock API 错误代码故障排除
<a name="troubleshooting-api-error-codes"></a>

本节提供有关您在使用 Amazon Bedrock API 时可能遇到的常见错误、导致错误出现的原因以及解决错误的解决方案的详细信息。

## AccessDeniedException
<a name="ts-access-denied"></a>

**HTTP 状态代码：**403

**原因：**您没有足够的权限来执行请求的操作。

**解决方案：**
+ 验证您的 IAM 用户或角色是否具有您尝试执行相关操作所需的许可。
+ 如果您使用的是临时安全凭证，请确保它们未过期。

## FTUFormNotFilled
<a name="ts-ftu-form"></a>

**HTTP 状态代码：**404

**原因：**未提交此账户的模型使用案例详细信息

**解决方案：**
+ 使用模型之前，请填写 Anthropic 使用案例详细信息表单

## IncompleteSignature
<a name="ts-incomplete-signature"></a>

**HTTP 状态代码：**400

**原因：**请求签名不符合 AWS 标准。

**解决方案：**
+ 确保您使用的是支持 Amazon Bedrock 的 AWS SDK 版本。
+ 确认您的 AWS 访问密钥 ID 和私有密钥配置正确。
+ 如果您要手动对请求进行签名，我们建议您仔细检查您的签名计算流程。

## InternalFailure
<a name="ts-internal-failure"></a>

**HTTP 状态代码：**500

**原因：**由于服务器错误，请求处理失败

**解决方案：**
+ 我们建议采用 AWS 推荐的方法，即使用[指数退避和随机[抖动](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)的重试](https://docs.aws.amazon.com//prescriptive-guidance/latest/cloud-design-patterns/retry-backoff.html)，以提高可靠性。
+ 如果问题仍然存在，请联系 [AWS Support Center](https://aws.amazon.com/support)，并提供有关您的请求和遇到的错误的详细信息。

## InvalidAction
<a name="ts-invalid-action"></a>

**HTTP 状态代码：**400

**原因：**所请求的操作无效

**解决方案：**
+ 我们建议您仔细检查请求中操作名称的拼写和格式。
+ 验证 Amazon Bedrock 是否支持相关操作调用，以及相关操作调用是否如 [Amazon Bedrock API 参考](https://docs.aws.amazon.com//bedrock/latest/APIReference/API_Operations.html)中所示正确记录。
+ 确保您使用的是最新版本的 AWS SDK 或 CLI。

## InvalidClientTokenId
<a name="ts-invalid-client-token"></a>

**HTTP 状态代码：**403

**原因：**我们提供的 X.509 证书或 AWS 访问密钥 ID 不存在于我们的记录中。

**解决方案：**
+ 确认您使用的是正确的 AWS 访问密钥 ID。
+ 如果您最近创建了新的访问密钥，请确保您使用的是新凭证而不是旧凭证。

## AWS Marketplace 协议在 15 分钟内失败
<a name="ts-mp-agreement-failed"></a>

**HTTP 状态代码：**403

**原因：**由于潜在问题， AWS Marketplace 协议失败。

**解决方案：**
+ 查看错误消息并修复底层问题。常见的底层问题是无效付款错误和地理位置受限。
+ 对于无效的付款错误，请在[申请亚马逊 Bedrock 中的模特访问权限后，查看限制使用 AWS Marketplace 和 INVALID\_PAYMENT\_INSTRUMENT\_IN](https://repost.aws/questions/QU0UOsutrWSSS4nOqgHcIUJg/invalid-payment-instrument-after-requesting-model-access-in-amazon-bedrock) [STRUMENT 的 AISPL 买家使用信用卡和借记卡购物](https://aws.amazon.com/blogs/awsmarketplace/restriction-on-credit-and-debit-card-purchases-for-aispl-customers-using-aws-marketplace/)。 。

## AWS Marketplace 协议在 15 分钟后待定
<a name="ts-mp-agreement-pending"></a>

**HTTP 状态代码：**403

**原因：** AWS Marketplace 协议未成功，自提出请求以来已经 15 分钟了。

**解决方案：**
+ 每 15 分钟重试请求。如果问题仍然存在，请联系 [AWS Support Center](https://aws.amazon.com/support)，并提供有关您的请求和遇到的错误的详细信息。

## MPAgreementBeingCreated
<a name="ts-mp-agreement-created"></a>

**HTTP 状态代码：**403

**原因：**未授权您的账户访问此模型。您对该型号的 AWS Marketplace 订阅仍在处理中

**解决方案：**
+ 请在 15 分钟后重试

## NotAuthorized
<a name="ts-not-authorized"></a>

**HTTP 状态代码：**400

**原因：**您无权执行此操作。

**解决方案：**
+ 查看您的 IAM 权限，确保您拥有对 Amazon Bedrock 资源执行请求的操作所需的权限。
+ 如果您使用的是 IAM 角色，请验证该角色是否具有适当的权限和信任关系。
+ 检查是否存在任何可能限制您的访问的组织策略或服务控制策略。

## RequestExpired
<a name="ts-request-expired"></a>

**HTTP 状态代码：**400

**原因：**由于时间戳过期，请求已失效。

**解决方案：**
+ 确保您的系统时钟与可靠的时间源正确同步。
+ 如果您从不同的时区发出请求，请注意可能存在的时间戳差异。

## ServiceUnavailable
<a name="ts-service-unavailable"></a>

**HTTP 状态代码：**503

**原因：**服务暂时无法处理请求。503 错误表示服务面临高需求或临时容量限制。这与您的账户级别配额或费率限制（返回 4 ThrottlingException 29）无关。

**解决方案：**
+ 我们建议采用 AWS 推荐的方法，即使用[指数退避和随机[抖动](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)的重试](https://docs.aws.amazon.com//prescriptive-guidance/latest/cloud-design-patterns/retry-backoff.html)，以提高可靠性。
+  AWS 区域 如果问题在您当前的地区仍然存在，请考虑切换到其他区域。不同区域的负载水平和可用性可能有所不同。
+ [使用 Cross-Region 推理](https://docs.aws.amazon.com//bedrock/latest/userguide/cross-region-inference.html)，通过跨不同的计算来无缝管理计划外的流量爆发。 AWS 区域
+ 如果您的吞吐量要求很高，我们建议您探索适合您使用案例的[预调配吞吐量](https://docs.aws.amazon.com//bedrock/latest/userguide/prov-throughput.html)。

**最佳实践**
+ 确保您的应用程序能够在错误处理和重试逻辑中正确处理 503 状态代码。
+ 查看 S AWS ervice Health Dashboard，了解任何可能影响服务的已宣布问题或定期维护。

如果您经常遇到 503 错误，或者这些错误严重影响了您的操作，请联系 [AWS Support](https://aws.amazon.com/support) 获取针对您的特定使用案例量身定制的进一步帮助和指导。

## ThrottlingException
<a name="ts-throttling-exception"></a>

**HTTP 状态代码：**429

**原因：**由于超出了 Amazon Bedrock 的账户配额，请求被拒绝。

**解决方案：**
+ 在 [Amazon Bedrock 服务配额](https://docs.aws.amazon.com/general/latest/gr/bedrock.html#limits_bedrock)控制台中查看 Amazon Bedrock 服务配额，了解分配给您账户的限额。
+ 我们建议采用 AWS 推荐的方法，即使用[指数退避的重试](https://docs.aws.amazon.com//prescriptive-guidance/latest/cloud-design-patterns/retry-backoff.html)。 以及随机[抖动](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)以提高可靠性。
+ 如果您的吞吐量要求很高，我们建议您探索适合您使用案例的[预调配吞吐量](https://docs.aws.amazon.com//bedrock/latest/userguide/prov-throughput.html)。
+ 如果您的工作负载流量超过账户配额，请联系您的客户经理或 [AWS Support](https://aws.amazon.com/support) 申请提高配额。

## ValidationError
<a name="ts-validation-error"></a>

**HTTP 状态代码：**400

**原因：**输入未能满足 Amazon Bedrock 指定的约束条件。

**解决方案：**
+ 查看 API 文档，确保包含所有必需的参数并且这些参数的格式正确。
+ 检查您的输入值是否在允许的范围之内或符合预期的模式。
+ 我们建议您注意正在使用的操作的 API 参考中提及的任何特定验证规则。

## ResourceNotFound
<a name="ts-resource-not-found"></a>

**HTTP 状态代码：**404

**原因：**找不到请求的资源。

**解决方案：**
+ 验证请求中的模型 ID、端点名称或其他资源标识符的正确性。
+ 请实施回退机制，以便在找不到主要资源时使用替代模型或端点。

**最佳实践**
+ [ListFoundationModels](https://docs.aws.amazon.com//bedrock/latest/APIReference/API_ListFoundationModels.html)用于了解您可以使用的可用的 Amazon Bedrock 基础模型。
+ 我们建议您实施定期同步流程来更新您的本地资源目录。

如果您在尝试这些解决方案后仍然遇到问题，请联系 [AWS Support](https://aws.amazon.com/support) 获取针对您的特定使用案例量身定制的进一步帮助和指导。

## 长时间运行或空闲连接时连接超时或重置
<a name="ts-connection-timeout"></a>

**症状：**当流量通过 NAT 网关、接口 VPC 端点或网络负载均衡器时，API 调用因连接重置或超时而失败，尤其是对于长时间运行的请求，例如流式传输、扩展思维或大型推理响应。症状还可能表现为冷启动延迟时间过长（例如，在空闲时间段后的第一个呼叫需要 70 多秒，而不是通常的几秒），而在网络静默中断后重新使用空闲池连接时。

**原因：**NAT 网关、接口 VPC 终端节点和网络负载均衡器的固定空闲连接超时为 350 秒。如果 TCP 连接的空闲时间超过此时间，则会在不通知客户端的情况下断开连接。客户端可能要等到下一个请求才会检测到已断开的连接，此时它必须等待 OS-level TCP 重试或超时后才能重新建立连接。

**当这适用时：**
+ 在 Amazon EKS 或 Amazon ECS 上运行的应用程序，其中流向 Amazon Bedrock 的 pod 流量通过 NAT 网关或 VPC 接口终端节点传出。
+ 在 NAT 网关、Amazon Bedrock 的接口 VPC 终端节点或网络负载均衡器后面的 Amazon EC2 实例上运行的应用程序。
+ Long-running 或者是突发性工作负载，其中 Amazon Bedrock 客户端连接在两次通话之间的连接池中处于空闲状态。

**解决方案：**

在 Amazon Bedrock 客户端上启用 TCP keep-alive 需要同时使用*两个*设置。仅设置一个是不够的。

1. **在您的 AWS 开发工具包客户端中启用 TCP 保持活动状态。**boto3 `Config` 对象接受一个`tcp_keepalive`参数，默认为。`False`构建 Amazon Bedrock 客户端`True`时将其设置为：

   ```
   import boto3
   from botocore.config import Config
   
   config = Config(tcp_keepalive=True)
   client = boto3.client("bedrock-runtime", config=config)
   ```

   有关其他 AWS 开发工具包，请参阅相应的 HTTP 客户端配置文档。

1. **将 OS-level 保持连接间隔配置为在 350 秒空闲超时之前触发。**Linux 的默认值为`net.ipv4.tcp_keepalive_time = 7200`（2 小时），这比 NAT 或 VPC 终端节点的空闲超时长得多，因此仅 SDK-level 保持活动状态不起作用。将内核设置降低到安全低于 350 秒（例如 45 秒）的值：

   ```
   sysctl -w net.ipv4.tcp_keepalive_time=45
   ```

   在 Amazon EKS 和 Amazon ECS 上，在容器或任务`securityContext`、初始化容器或自定义节点 AMI 中应用 sysctl。在 Amazon EC2 上，将其设置为在`/etc/sysctl.d/`重启后该值保持不变。

有关在 VPC 网络中长时间运行的 TCP 连接的更深入讨论，请参阅网络和内容交付博客上的 [VPC 网络中实现长时间运行的 AWS TCP 连接](https://aws.amazon.com/blogs/networking-and-content-delivery/implementing-long-running-tcp-connections-within-vpc-networking/)。

如果在应用这两个设置后仍然遇到连接问题，请联系 Supp [AWS or](https://aws.amazon.com/support) t 寻求进一步帮助。