Aller au contenu

AWS Mis à jour le 2026-07-04

S3 503 Slowdown : limites de débit de requêtes et conception des préfixes

Les erreurs S3 503 Slow Down signifient que vous avez dépassé le débit d'un préfixe — 3 500 écritures ou 5 500 lectures par seconde — avant que S3 ait fini de se mettre à l'échelle. Comment corriger avec les reprises, la conception des préfixes et la montée graduelle.

Un 503 Slow Down de S3 signifie que votre débit de requêtes a frappé une partition du bucket plus fort qu’elle ne pouvait servir à ce moment-là — la base est d’au moins 3 500 PUT/COPY/POST/DELETE et 5 500 GET/HEAD par seconde par préfixe, et S3 se met à l’échelle au-delà automatiquement, mais pas instantanément. Le correctif immédiat est la reprise exponentielle avec gigue (les SDK AWS le font déjà, si vous ne les avez pas contournés) ; le correctif durable est d’étaler la charge sur plus de préfixes et de monter graduellement au lieu de passer de zéro au maximum d’un coup.

Ce qui se passe

S3 range vos clés sur des partitions internes et chaque partition soutient un débit borné. Quand le trafic vers une plage de clés dépasse ce que sa partition sert, S3 retourne 503 SlowDown pendant qu’il repartitionne en arrière-plan — cette mise à l’échelle prend de quelques minutes à quelques dizaines de minutes, et pendant une pointe soudaine vous mangez des 503 jusqu’à ce qu’il rattrape. Il n’y a pas de plafond dur par bucket : des buckets servent couramment des millions de requêtes par seconde, mais seulement quand la charge est répartie sur beaucoup de préfixes et que S3 a déjà divisé l’espace de clés.

« Préfixe » désigne ici le chemin de nom de clé que S3 utilise pour partitionner, pas l’icône de dossier dans la console. Les clés qui partagent une longue chaîne initiale commune tendent à atterrir sur les mêmes partitions. La blessure auto-infligée classique est le nommage séquentiel — logs/2026-07-04-00-00-01.gz, -02.gz, -03.gz — où chaque écriture frappe le même bord de partition. Le S3 moderne gère le nommage par date bien mieux qu’avant (le hachage des clés n’est plus un conseil général), mais à des dizaines de milliers de requêtes par seconde contre une plage de clés étroite, la pression de partition reste réelle.

Deux limitations adjacentes se font diagnostiquer à tort comme la faute de S3. Si les objets utilisent SSE-KMS, chaque requête ajoute un appel KMS, et KMS a son propre quota de requêtes par seconde par région (variable selon la région ; vérifiez le vôtre dans Service Quotas) — la limitation KMS se manifeste comme des erreurs sur vos opérations S3. Et un éventail piloté par Lambda peut être limité côté Lambda, produisant des tempêtes de reprises qui déclenchent ensuite S3.

Quoi vérifier en premier

  • Votre client reprend-il avec recul exponentiel, tout court? Des appels HTTP bruts ou des SDK mal configurés transforment un événement de mise à l’échelle de 30 secondes en panne.
  • À quoi ressemble la distribution des clés pour la charge chaude — un préfixe étroit ou plusieurs?
  • La charge est-elle apparue soudainement? Une nouvelle tâche par lots, un rattrapage, une purge de cache — l’arrivée en pointe est le déclencheur ; une charge stable au même volume ne l’est habituellement pas.
  • Les objets sont-ils chiffrés SSE-KMS? Écartez ou confirmez la limitation KMS tôt.

Comment vérifier

Activez les métriques de requêtes si ce n’est pas fait (elles sont optionnelles et facturées) : S3 > Buckets > votre-bucket > Metrics > Request metrics. Puis regardez le portrait 5xx :

aws cloudwatch get-metric-statistics \
  --namespace AWS/S3 \
  --metric-name 5xxErrors \
  --dimensions Name=BucketName,Value=my-bucket Name=FilterId,Value=EntireBucket \
  --start-time 2026-07-03T00:00:00Z --end-time 2026-07-04T00:00:00Z \
  --period 300 --statistics Sum

Côté client, comptez les vraies chaînes d’erreur dans les journaux applicatifs — SlowDown et 503 — et notez sur quelles clés elles se regroupent. Si vous avez la journalisation d’accès serveur S3 ou les événements de données CloudTrail, agrégez par préfixe de clé pour trouver la plage chaude. Pour le côté KMS :

aws cloudwatch get-metric-statistics \
  --namespace AWS/KMS --metric-name ThrottledCount \
  --dimensions Name=KeyId,Value=1234abcd-12ab-34cd-56ef-1234567890ab \
  --start-time 2026-07-03T00:00:00Z --end-time 2026-07-04T00:00:00Z \
  --period 300 --statistics Sum

Le correctif

  1. Confirmez les reprises avec recul exponentiel et gigue. Les SDK AWS le font par défaut (le mode de reprise adaptatif vaut la peine pour les charges à forte limitation) ; si vous avez désactivé les reprises pour la latence, réactivez-les spécifiquement pour les 503. Un client qui reprend correctement traverse souvent un événement de mise à l’échelle sans rien de pire qu’un p99 élevé.
  2. Étalez l’espace de clés. Introduisez des segments à haute cardinalité tôt dans la clé — ID de locataire, seau de hachage, ID de travailleur : data/7f/tenant-4211/2026-07-04/... plutôt que data/2026-07-04/... pour tout. Plus de préfixes distincts, c’est plus de parallélisme de partitionnement pour S3.
  3. Montez graduellement, ne cognez pas. Pour le travail en vrac planifié (rattrapages, migrations), démarrez à une fraction du débit cible et doublez toutes les quelques minutes. S3 s’adapte élégamment à une charge soutenue ; c’est la marche d’escalier de 0 à 50 000 requêtes par seconde sur un préfixe qui fait mal.
  4. Parallélisez délibérément à travers les préfixes. Les tâches par lots qui traitent les clés en ordre trié concentrent le tir sur une partition après l’autre. Mélangez la file de travail ou répartissez les travailleurs par hachage de la clé.
  5. Corrigez KMS si KMS est la limite. Activez les S3 Bucket Keys sur le bucket (Properties > Default encryption) — ça élimine la plupart des appels KMS par objet et coupe habituellement le volume de requêtes KMS de façon spectaculaire — ou demandez une hausse de quota KMS dans Service Quotas.
  6. Pour les pointes extrêmes, demandez de l’aide. Si un lancement exige un changement d’échelle connu du débit sur un espace de clés étroit, AWS peut pré-partitionner — ouvrez un dossier via https://aws.amazon.com/premiumsupport/ avec le bucket, les préfixes et les débits attendus.

Quand c’est la mauvaise approche

Ne redessinez pas votre schéma de clés pour une poignée de 503 pendant un rattrapage ponctuel — reprises plus montée graduelle suffisent, et les migrations de clés sont coûteuses et risquées. À l’inverse, si vous servez les mêmes objets à des milliers de lecteurs, la réponse n’est pas plus de préfixes S3 ; c’est CloudFront devant le bucket pour que la plupart des GET n’atteignent jamais S3.

Erreurs fréquentes

  • Traiter les 503 comme des erreurs fatales et faire échouer la tâche, alors que le comportement correct est la reprise documentée — S3 vous dit de ralentir, pas que vos données sont en danger.
  • Ajouter des reprises côté client sans gigue, si bien que tous les travailleurs reprennent en cadence et que le troupeau redéclenche la limite à heure fixe.
  • Faire un banc d’essai avec des clés nommées test-000001 à test-999999 et conclure que S3 est lent — le nom séquentiel a concentré tout le test sur une partition.
  • Blâmer S3 pour des limitations que CloudWatch montre comme des événements KMS ThrottledCount.

Prévention

  • Alertez sur la métrique de requêtes 5xxErrors du bucket pour que la limitation apparaisse comme un graphique, pas comme un rapport client — intégrez-la à votre base d’alarmes CloudWatch.
  • Placez des segments à haute cardinalité tôt dans les noms de clés pour toute charge appelée à dépasser quelques milliers de requêtes par seconde.
  • Activez les S3 Bucket Keys partout où SSE-KMS est utilisé ; c’est une assurance presque gratuite contre les limitations KMS.
  • Documentez une procédure de montée graduelle pour les tâches en vrac, et faites de la concurrence du cadre de traitement un cadran, pas une constante. Les lignes directrices de performance sur https://docs.aws.amazon.com/AmazonS3/ sont la référence canonique pour les chiffres par préfixe.

Les 503 sont le contrôle de flux de S3, pas une panne — respectés avec du recul et traités avec de la diversité de préfixes, ils disparaissent du budget d’erreurs. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.