DynamoDBはいつリクエストを抑制しますか？
「 Amazon DynamoDBスループットはどのように計算され、制限されますか？ 」への回答では、1秒あたりのプロビジョニングされたスループットを超えるたびにDynamoDBがリクエストを調整することが提案されています。しかし、これは私の経験と矛盾しています。
複数の行を投稿するテーブルを作成しました。多くの場合、行数はプロビジョニングされた書き込み容量を超えています。これは短いバーストで発生します。ある時点で、プロビジョニングされた容量を平均して5分間も超えました。 OTOH、平均15分は容量を下回っています。私はその期間中に調整されたリクエストを受け取っていません。
プロビジョニングされた容量が6の8.053での5分間の平均ピーク： 
プロビジョニングされた容量を大きく下回る15分の平均ピーク：
では、DynamoDBはいつリクエストを抑制しますか？どのような平均を考慮していますか？バーストがスロットルされる前に、プロビジョニングされた容量をどれくらい超えることができますか？
DynamoDBは、プロビジョニングされた容量が1秒ごとに利用できるように設計されています。 1秒あたり10個の1kB読み取り用にテーブルをプロビジョニングすると、DynamoDBはそのスループットレートを処理するのに十分な容量を提供します。さらに、DynamoDBでは、プロビジョニングされたスループットを超える限られたバーストを短期間に達成できる場合があります。これは、顧客のワークロードの自然な変動を吸収することを目的としています。このバーストは保証されておらず、常に使用できるわけではありません（使用可能なバーストの性質は時間とともに変化する可能性があります）。現在、ベストプラクティスのドキュメントで説明されているように、最高のパフォーマンスを得るには、プロビジョニングされた容量を超えず、キースペースに均等に負荷を分散する均等に分散されたワークロードが必要です。ただし、アプリケーションの本番動作の現実が均等に分散されたワークロードと異なる場合、DynamoDBはバーストの一部を吸収する可能性があります。
テーブルをプロビジョニングする量については、ワークロードに大きく依存します。ピークの80％などのプロビジョニングから開始し、受信するスロットルの数（CloudWatchグラフで確認できます）および再試行によって引き起こされる遅延に対するアプリケーションの許容度に応じて、テーブル容量を調整できます。 DynamoDBでは、プロビジョニングされた容量を超える無制限のバーストが許可されないことに注意してください。短いバーストを吸収できる場合もありますが、プロビジョニングされた容量レベルを超えるスループットレートを長期間維持することはできません。提供できる一般的なガイダンスは、ピークに近いものを準備し、スロットルを監視しながらダイヤルダウンすることです。
免責事項：私はAmazon、DynamoDBチームで働いています。
DynamoDBドキュメントのヒント があり、バーストの仕組みを説明しています。
パーティションのスループットを完全に利用していない場合、DynamoDBは未使用の容量の一部を保持し、スループットの使用量を後から急増させます。 DynamoDBは現在、最大5分間（300秒）の未使用の読み取りおよび書き込み容量を保持しています。
しかし、この動作に頼ることはできないとも言っています：
ただし、常に利用可能なバースト容量に依存するようにアプリケーションを設計しないでください。DynamoDBは、事前の通知なしにバックグラウンド保守やその他のタスクにバースト容量を使用できます。
少なくとも、プロビジョニングされた容量を平均して5分間上回ることが可能であった理由は説明できます。上記の説明を使用すると、間隔の最初にスパイクがあり、開始の300秒前に使用量が少ない場合、15分間の平均（またはより長いタイムスパン）がプロビジョニングされた容量を超えることさえ可能です間隔。