AWSを使用してデータ処理を実行しています。 EC2には400のスポットインスタンスがあり、それぞれに4つのプロセスがあり、それらのすべてがS3の単一のバケットに書き込まれます。Amazon Web Services S3リクエストの制限
503：
誰もが実際の要求制限がS3バケット何のためにあるのか知っていますがスローダウン私は言って（明らかに珍しい）のエラーを取得するために始めましたか？ AWSのドキュメントが見つかりません。
ありがとうございました！
私が読んだことから、スローダウンは非常にまれなエラーです。しかし、この質問を投稿した後、私はAWSからのメールを受け取りました.LISTリクエストは1秒あたり10回のリクエストに制限されていました。
私が作業しているプロジェクトのカスタムキューイングスクリプトを使用していました。これは、処理する次の項目を決定するLIST要求に依存していました。この問題に遭遇した後、私はAWS SQSに切り替えました。これは、私が思っていたよりも実装がずっと簡単でした。カスタムキューがなくなり、大量のLISTリクエストが不要になりました。
ありがとうございます！
一時的なエラーの結果、AWSドキュメント503。それは特定の制限を反映していません。
は、エラーを処理するには、「Amazon S3のを使用するためのベストプラクティス」（http://aws.amazon.com/articles/1904/）によると：
500シリーズのエラーは、要求が成功しなかったことを示しますが、再試行することができます。これらのエラーはまれではありますが、通常のサービスとの対話の一部として期待されるため、指数バックオフアルゴリズム（理想的にはジッタを使用するアルゴリズム）で明示的に処理する必要があります。そのようなアルゴリズムの1つはhttp://en.wikipedia.org/wiki/Truncated_binary_exponential_backoffです。
特に、何百ものPUTを1つのバケットに突然実行すると、サービスが負荷を再分割する際に、503回の「スローダウン」エラーが返されることがあります。すべての500シリーズエラーと同様に、これらは指数バックオフで処理する必要があります。
詳しくは説明しませんが、S3エラー応答のドキュメントには、503スローダウン（http://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html）が含まれています。
Jamesによると、指数バックオフが必要であるため、議論されたS3パーティショニングに関するいくつかの内部があり、今後これを軽減するために使用できます。
こちらをご覧ください：http://aws.typepad.com/aws/2012/03/amazon-s3-performance-tips-tricks-seattle-hiring-event.html
簡単に言うと、同じプレフィックスを持つすべてのものを保存したり、これらの接頭辞で非常に最初の文字は、ランダムなるようにするいくつかの方法をerrors.Findていますより高い可能性がありませんできるだけS3の内部パーティショニングにおけるホットスポットを避けるために。
ハードな制限があるとは思われません。そうでないと文書化されません。あなたはある程度の容量制約に抗して走っていなければなりません。 Amazonはサービスを監視しているため、ユーザーが高負荷になるのを見ると、より高い負荷を処理するように働いていれば私には驚かないだろう。 –