S3で大量ファイルを削除する前に知っておきたいスロットリング（503 Slow Down）の話

はじめに

S3 にファイルを配置する Web アプリを運用していて、「特定ユーザーが大量に置いたファイルを S3 から直接消したい」という場面に遭遇しました。

このとき気になったのが、大量削除をしたら他のユーザーがアプリを使う上で影響が出ないか？ という点です。調べていく中で S3 のリクエストレート制限（スロットリング）とプレフィックスの仕組みを整理できたので、まとめておきます。

結論を先に書くと、

• S3 の性能上限は プレフィックス単位 で決まる
• 上限を超えるレートを出すと S3 が自動スケールし、その過程で 503 Slow Down が返ることがある
• 公式ドキュメント上、上限・スケーリングは プレフィックスごとに独立 しているので、別プレフィックスへの影響は出にくいと推測できる
• ただし、S3 のスロットリングより アプリDBとの整合性 のほうが実害が大きいことが多い

という内容です。

キーとプレフィックスとは

S3 の話をするうえで、まず「キー」と「プレフィックス」を押さえておきます。

キー（key）

キーは、バケット内でオブジェクトを一意に指す文字列全体 です。S3 には本当の意味でのフォルダは存在せず、あるのは「1本の長い文字列＝キー」だけです。

例えば次のようなものがキーです。

filing/sample/1/20260618130635934_f3e89b68-b665-4806-87a5-22f60835ca0a.dat
photos/2026/06/cat.jpg
invoice.pdf

最後の invoice.pdf のように、スラッシュを含まずバケット直下に置くこともできます。スラッシュ区切りの末尾を慣習的に「ファイル名」と呼びますが、S3 の仕組み上は ファイル名部分もキーの一部 です。

プレフィックス（prefix）

プレフィックスは、そのキー文字列の「先頭部分」 を指します。どこまでを先頭と見るかは決まっておらず、同じキーに対して複数のプレフィックスが考えられます。

キー:            filing/sample/1/2026..._....dat
プレフィックス例:  filing/
                filing/sample/
                filing/sample/1/

S3 コンソールでフォルダのように見えているのは、この共通プレフィックスを見た目上まとめて表示しているだけです。プレフィックスは「フォルダ」という意味ではなく、あくまで「先頭一致する文字列」である点に注意してください（ファイル名の途中で切ってもプレフィックスとして成立します）。

高レートになるとスロットリング（503 Slow Down）が起きる

S3 のリクエスト性能の上限は バケット単位ではなくプレフィックス単位 で決まります。公式の目安は次の通りです。

パーティション化された S3 プレフィックスごとに、毎秒少なくとも 3,500 PUT/COPY/POST/DELETE、または 5,500 GET/HEAD リクエストを達成できる。バケット内のプレフィックス数に上限はない。

このレートを超えると、S3 はより高いリクエストレートに対応するために 自動でスケーリング を始めます。そして、このスケーリングは瞬時ではなく 段階的に 行われるため、その過渡期に 503 Slow Down が返ることがあります。

流れの整理

レートが上限近くまで上がる（特に急なスパイク）
        ↓
S3 がバックグラウンドで自動スケーリングを開始
        ↓
スケーリングが追いつくまでの過渡期に 503 Slow Down が返ることがある
        ↓
スケーリング完了後はスロットリングなしで捌けるようになる

503 はあくまで 一時的 なもので、S3 が新しいリクエストパターンに最適化していることを示すサインです。SDK や aws CLI は 503 を受けると指数バックオフで自動リトライするため、体感としては「一時的に少し遅くなる」程度で吸収されることが多いです。

ここで重要なポイント

レートは「1秒あたりのリクエスト件数」

スロットリングの判定は「累計で何件消したか」ではなく「ある1秒間に何件のリクエストが来たか（RPS）」で行われます。同じ量を消すのでも、一気に叩けば上限に当たり、ゆっくり消せば当たりにくくなります。

レートは「合計」で見られる

レートはリクエストを出した主体ごとに別々に判定されるのではなく、同じプレフィックスに入ってくる全リクエストの合算 で見られます。誰か1人が単独で超えなくても、複数ユーザー（＋削除処理）のリクエストが重なって合計が上限を超えれば、スロットリングが起き得ます。

バッチ削除でも内部判定はオブジェクト単位

DeleteObjects API（1リクエストで最大1,000キー）を使うと HTTP リクエスト数は激減しますが、S3 は内部的にリクエスト内の各オブジェクトごとに DELETE を処理 します。そのため、スロットリングの判定で見るべきは HTTP リクエスト数ではなく 毎秒の削除オブジェクト数 です。バッチでまとめても、実質の削除レートが上限を超えれば 503 は出得ます。

スロットリングを避けるには

• いきなり全開で叩かず、レートを 段階的に 上げる（急なスパイクが一番 503 を誘発する）
• そもそも上限より低いレートに抑える
• CloudWatch の 5xx メトリクスを監視して、上限に近づいていないか確認する
• 件数が極端に多いなら S3 Batch Operations やライフサイクルルールに任せる（S3 側がレート調整してくれる）

CLI で削除する場合、aws s3 rm には毎秒のレートを直接指定する機能はありませんが、同時実行数を絞ることで間接的にレートを抑えられます。

# 同時実行数を下げてレートを抑える（デフォルトは10）
aws configure set default.s3.max_concurrent_requests 5
aws s3 rm s3://your-bucket/filing/sample/1/ --recursive

他プレフィックスには影響しない可能性が高い

「特定プレフィックス配下を大量削除したら、他のプレフィックスを使っているユーザーに影響が出るのか？」という疑問について。

公式ドキュメントに「他プレフィックスには影響しない」とそのまま書かれた一文はありませんが、レート上限とスケーリングがプレフィックス単位で独立している という記述から推測できます。

• 上限は「プレフィックスごと」に毎秒3,500 / 5,500
• リクエストレートが増えると、S3 は 各プレフィックスごとに別々に スケールアップする
• その結果、バケット全体が処理できるレートは プレフィックス数の倍数 になる（例: 10プレフィックスで読み取り55,000 RPS）

各プレフィックスの性能枠が独立して積み上がる、ということは、あるプレフィックスを高レートで叩いて 503 が出ても、別プレフィックスは自分の枠を持っているので影響を受けにくい、と導けます。

注意点：プレフィックスの分割粒度は保証されない

ただし、filing/sample/1/ と filing/sample/2/ が 常に別の性能枠に分かれている保証 は、ドキュメント上は明示されていません。S3 が内部でどの粒度までパーティション分割しているかは可視化されておらず、プレフィックスを作っても自動的にリソースが割り当てられるわけではなく、アクセスされて初めて、その粒度で分割されていく 挙動だからです。

実際に独立しているかは、削除中に CloudWatch の 5xx メトリクスを見て、他プレフィックスのリクエストが 503 を受けていないかを確認するのが確実です。

余談：S3 のスロットリングより「DBの整合性」が大事

ここまで S3 のスロットリングの話をしてきましたが、実務的にはこちらのほうが実害が出やすいので強調しておきます。

多くの Web アプリは「どのユーザーがどのファイルを持っているか」を DB などのメタデータで管理しています。S3 から直接ファイルを消すとアプリを経由しないため、DB にはレコードが残ったまま実体だけ消える（いわゆる orphan / 宙ぶらりんレコード）状態になります。

これによって、

• ファイル一覧には存在するのに開くと 404
• ダウンロードリンクが死ぬ

といった不具合が他ユーザーにも波及し得ます。可能なら、削除はアプリの削除機能経由にするか、S3 削除と同時に DB レコードも消す運用にすべきです。

また、バケットで バージョニング が有効な場合、削除は実際にはオブジェクトを消さず「削除マーカー」を付けるだけで、旧バージョンは残り続けます（容量・課金も減りません）。完全に消すには各バージョンを明示的に削除する必要があります。

まとめ

• キーはオブジェクトを一意に指す文字列全体、プレフィックスはその先頭部分
• S3 の性能上限はプレフィックス単位で毎秒3,500 PUT/COPY/POST/DELETE、5,500 GET/HEAD
• 上限を超えるレート（特に急なスパイク）で自動スケーリングが起き、その過渡期に 503 Slow Down が返ることがある
• 上限・スケーリングはプレフィックスごとに独立しているので、別プレフィックスへの影響は出にくいと推測できる（ただし分割粒度は保証されないので監視で確認）
• S3 のスロットリングより、アプリDBとの整合性・バージョニングの挙動に注意すべき

大量削除をするときは、レートを抑えてゆっくり消しつつ、DB との整合性も合わせて対応するのが安全です。

参考リンク（AWS 公式ドキュメント）

• Best practices design patterns: optimizing Amazon S3 performance
• Performance design patterns for Amazon S3
• Troubleshoot HTTP 5xx errors from Amazon S3（AWS re:Post）
• Why you can get 503 errors when within the supported request rate per prefix（AWS re:Post）
• HTTP 503 status code (Service Unavailable) - Amazon CloudFront