# How should I handle exceptions thrown by the AWS SDK when calling Bedrock (such as ServiceUnavailable errors or throttling exceptions)?

Source: https://zilliz.com/ai-faq/how-should-i-handle-exceptions-thrown-by-the-aws-sdk-when-calling-bedrock-such-as-serviceunavailable-errors-or-throttling-exceptions
Author: zilliz

To handle exceptions from the AWS SDK when calling Bedrock, start by identifying the specific error types and implementing structured retry logic. AWS SDKs (like the SDK for Java, Python, or JavaScript) throw service-specific exceptions (e.g., `ThrottlingException`, `ServiceUnavailableException`) that you can catch explicitly. For example, in Java, wrap your Bedrock API calls in `try-catch` blocks to handle `AwsServiceException` and check the error code (e.g., `errorCode()` or HTTP status code) to determine if it’s a retryable error like throttling (HTTP 429) or service unavailable (HTTP 503). This ensures you handle transient errors separately from permanent failures like invalid parameters.

Next, implement retries with exponential backoff. AWS SDKs include built-in retry mechanisms, but you can configure them for Bedrock use cases. For instance, in the AWS SDK for JavaScript v3, you can customize the `retryStrategy` in the client configuration to set `maxAttempts` and use a backoff function. For throttling, AWS recommends using jitter (randomized delays) to avoid retry storms. If the SDK’s default retries are insufficient, use a library like `aws-sdk-retry` (Python) or implement a custom retry loop. Always ensure your retries are idempotent—Bedrock operations like `InvokeModel` should be safe to retry if the request is unchanged.

Finally, log errors and monitor failures. Log exception details (error code, message, stack trace) and track retry attempts to identify recurring issues. Use CloudWatch Metrics or X-Ray to monitor Bedrock API latency, throttling rates, and availability. For critical failures (e.g., persistent `ServiceUnavailable` errors), trigger alerts or fallback mechanisms, such as switching to a backup model or queueing requests. Avoid silent failures by ensuring unhandled exceptions propagate to a global error handler or are surfaced in application metrics. This approach balances resilience with observability, allowing you to address issues proactively.