Comprendre les classes de requêtes du stockage Cloud
Optimisez vos requêtes Cloud pour réduire votre facture
Pourquoi lire cet article ? Le stockage Cloud cache un piège financier redoutable qui n’a rien à voir avec le volume de vos données : découvrez comment l’architecture de vos requêtes API (Classes A et B) peut faire exploser votre budget, et les stratégies pour l’optimiser.
Lorsque les entreprises migrent vers le Cloud, elles modélisent généralement leurs coûts (FinOps) autour d’une seule métrique : le volume de données stockées (le prix au gigaoctet). Pourtant, lors de la réception de la première facture AWS, Google Cloud ou Azure, une surprise de taille les attend souvent. Une ligne de facturation, parfois plus onéreuse que le stockage lui-même, vient grever le budget : les requêtes API. Le stockage Objet n’est pas un disque dur physique, c’est un service web complet. Chaque interaction avec un fichier (lecture, écriture, listage) est un appel HTTP RESTful qui consomme des ressources de calcul chez le fournisseur Cloud. Pour facturer cette consommation, l’industrie a standardisé la division des requêtes en différentes catégories, principalement les Classes A et les Classes B. Comprendre cette mécanique est indispensable pour architecturer des applications rentables.
Que sont les requêtes de Classe A ?
Les requêtes de Classe A (ou requêtes de modification et d’énumération) sont les appels API les plus coûteux. Elles regroupent toutes les opérations qui modifient l’état de votre Bucket S3 ou qui exigent une forte puissance de calcul côté serveur.
• Les opérations d’écriture (PUT, POST, COPY, UPLOAD) : Chaque fois que vous ajoutez un nouveau fichier, que vous uploadez un fragment de fichier (Multipart Upload) ou que vous modifiez les métadonnées ou les tags d’un Objet existant.
• L’opération d’énumération (LIST) : C’est le piège numéro un. Demander à S3 de lister les Objets contenus dans un Bucket (ou sous un préfixe spécifique) est extrêmement gourmand en ressources, car S3 utilise un espace de noms plat (Flat Namespace) distribué sur des milliers de serveurs.
L’impact financier : Chez AWS, les requêtes de Classe A sont facturées environ 0,005 $ pour 1 000 requêtes. Cela semble dérisoire, mais imaginez une flotte de 10 000 capteurs IoT qui envoient un fichier de log toutes les secondes. Cela représente 864 millions de requêtes PUT par jour, soit plus de 4 300 $ de frais API quotidiens, pour un volume de données stockées pourtant minime.
Et les requêtes de Classe B ?
Les requêtes de Classe B concernent les opérations de lecture simple. Elles sollicitent beaucoup moins le plan de contrôle (Control Plane) de l’infrastructure de stockage.
• L’opération de lecture (GET) : Le téléchargement d’un Objet, la lecture de ses métadonnées ou la récupération de ses tags.
• Les requêtes analytiques (SELECT) : L’utilisation de S3 Select pour filtrer le contenu d’un fichier CSV ou JSON directement via une requête SQL, avant même de le télécharger.
L’impact financier : Elles sont généralement 10 fois moins chères que la Classe A (environ 0,0004 $ pour 1 000 requêtes chez AWS). Cependant, sur un site web très fréquenté où chaque image, script et feuille de style est appelé directement depuis le Bucket S3 via un GET, la volumétrie peut faire exploser la facture.
Mais certaines sont gratuites (Classe C / Autres)
Heureusement, certaines opérations critiques restent gratuites chez la majorité des fournisseurs. Il s’agit des requêtes de suppression (DELETE). Le modèle économique est clair : les fournisseurs ne vous factureront jamais pour libérer de l’espace sur leurs serveurs.
Il est donc toujours gratuit de nettoyer son infrastructure (sauf frais spécifiques liés aux classes de type Glacier en cas de suppression prématurée).
Comparatif des coûts selon les fournisseurs majeurs
Le marché du stockage Objet s’est scindé en deux philosophies tarifaires : le modèle historique (AWS) et le modèle disruptif (Cloudflare, Wasabi).
Amazon Web Services (AWS S3) et Google Cloud (GCS) : Ces géants appliquent le modèle complet : vous payez le stockage, les requêtes API (Classe A et B) et surtout le trafic sortant (Egress, qui est souvent le coût le plus massif). Leur API est facturée au prix fort, justifié par une résilience et un écosystème de services inégalés.
Cloudflare R2 : La fin de l’Egress, mais pas des API Cloudflare R2 a bouleversé le marché en supprimant totalement les frais de bande passante sortante (Zéro Egress Fee). Beaucoup ont cru que R2 était entièrement gratuit au-delà du stockage, ce qui est faux. Cloudflare facture bien les requêtes API : 4,50 $ par million pour la Classe A (Opérations de mutation) et 0,36 $ par million pour la Classe B (Opérations de lecture). Le coût des API y est donc très similaire à celui d’AWS, la véritable économie se situant sur le trafic réseau.
Wasabi et Backblaze B2 : Les alternatives agressives Wasabi pousse le modèle encore plus loin : ni frais d’Egress, ni frais de requêtes API. Vous ne payez que le stockage pur. La contrepartie ? Une politique stricte de « 90-day minimum storage ». Tout fichier uploadé chez Wasabi vous sera facturé pour 90 jours minimum, même si vous le supprimez au bout d’une heure.
Backblaze B2 facture très légèrement les API et propose l’Egress gratuit uniquement si vous passez par leurs partenaires CDN (Bandwidth Alliance).
Les stratégies architecturales d’optimisation
Mettre en cache les GET (Classe B) : Ne jamais exposer un Bucket S3 directement aux utilisateurs. Placez toujours un Content Delivery Network (CDN comme CloudFront ou Cloudflare) devant. Le CDN mettra le fichier en cache : seul le premier utilisateur générera un GET payant sur S3, les millions d’autres téléchargeront la copie depuis le CDN.
Bannir les LIST (Classe A) : Ne concevez jamais une application qui liste le contenu d’un Bucket pour savoir quels fichiers sont présents. Maintenez plutôt une base de données (PostgreSQL, DynamoDB) qui référence chaque fichier lors de son upload. Interroger la base de données est infiniment plus rapide et économique.
Agréger la donnée (Micro-batching) : Au lieu de faire un PUT par seconde pour des petits logs, stockez-les en mémoire tampon (Buffer) via des outils comme Amazon Kinesis ou Kafka, et uploadez un seul gros fichier Parquet ou JSON toutes les minutes. Vous diviserez vos coûts de Classe A par 60.
Conclusion
Le stockage Cloud S3 est un outil d’une puissance phénoménale, mais sa tarification à l’usage (Pay-as-you-go) punit sévèrement les architectures non optimisées. Traiter S3 comme un simple disque local est l’erreur la plus commune. Chaque appel API a un coût : le succès de votre migration Cloud réside dans votre capacité à les limiter tout en maximisant la valeur de vos données.