大手小売企業が Amazon Bedrock（オンデマンドモード）の Claude モデルを使ったリアルタイム商品説明生成システムを本番運用しています。毎週月曜日の9〜11時に限り ThrottlingException エラーが急増し、一部のリクエストがタイムアウトしています。このパターンを診断したうえで恒久的な解決策を実装したいと考えています。最も効果的なアプローチはどれですか？
Bedrock オンデマンドモードはリージョンごとのデフォルトクォータに基づくスループット制限があります。週次・特定時間帯で予測可能なピーク負荷に対しては、まず CloudWatch の InvocationThrottles と InvocationsPerRequest などのメトリクスでパターンを定量化し、その後 Provisioned Throughput を購入することが最適解です。Provisioned Throughput は購入した Model Units 分のスループットを確約するため、ピーク時間帯も安定したレイテンシでリクエストを処理できます。 選択肢AのX-Ray + リトライ強化は偶発的・一時的なスパイクには有効ですが、週次で再現するピーク負荷に対してリトライを増やしてもクォータ上限自体は解消されず、ユーザー体験への影響が継続する。 選択肢CのEventBridge Scheduler によるリクエスト遅延は、バッチ処理やオフライン生成には有効だが、リアルタイム商品説明生成という要件では月曜日に届いたリクエストの応答を遅延させること自体がビジネス要件に反する。 選択肢DのSQS バッファリングはリクエストレートの平準化に有効だが、本システムはリアルタイム応答が必要なためキューイングによる応答遅延は許容できない。