Comment optimiser vos coûts Amazon S3?

Vous payez en S3 S3 les frais de transfert de données.

Les services Web d'Amazon (AWS), et en particulier le service de stockage simple (S3), sont largement utilisés par de nombreuses personnes et entreprises pour gérer leurs données, leurs sites Web et leurs backends. Celles-ci vont des individus isolés et des petites startups aux sociétés d'évaluation de plusieurs milliards de dollars telles que Pinterest et (anciennement) Dropbox. Cette page n'est pas conçue comme un guide d'intégration de S3; vous pouvez trouver de nombreux autres guides de ce type en ligne. Il s'adresse plutôt aux particuliers et aux entreprises dont les coûts S3 attendus sont compris entre 7,50€ par mois et 7460€ par mois. D'autres listes de conseils similaires sont disponibles en ligne.

Cette page n'aborde pas non plus d'autres types d'optimisations S3, telles que l'optimisation des noms de compartiment, de dossier et de fichier et l'ordre des opérations, axées sur la maximisation du débit ou la minimisation de la latence. La plupart de ces optimisations n'affectent pas directement les coûts (positivement ou négativement). De plus, ils ne deviennent généralement pertinents qu'à une échelle nettement supérieure à celle à laquelle le public cible de cette page est susceptible d'être. Vous pouvez en savoir plus sur ces optimisations dans le guide officiel S3 et ailleurs.

Partie 1 sur 6: obtenir une compréhension globale de s3

1
Comprenez votre cas d'utilisation s3. S3 peut être utilisé pour de nombreux objectifs.
- En tant qu'emplacement pour stocker des fichiers pour une diffusion en direct sur des sites Web, y compris des fichiers image ou un site Web statique entier (généralement derrière un CDN tel qu'Amazon CloudFront ou CloudFlare).
- En tant que «lac de données», un endroit pour les données que vous consommez ou générez dans vos applications: essentiellement, S3 devient le stockage à long terme de vos données, vos données initiales générées étant enregistrées dans S3 et diverses applications lues à partir de S3., transformer les données et réécrire dans S3.
- En tant qu'"entrepôt de données", un endroit pour stocker des sauvegardes à long terme de données structurées et non structurées non destinées à une consommation active ultérieure.
- En tant qu'emplacement pour stocker les exécutables, les scripts et les configurations nécessaires pour lancer de nouvelles instances EC2 avec vos applications (ou mettre à jour vos applications sur des instances existantes).
2
Comprendre la manière principale dont s3 affecte les coûts. Les nombres ci-dessous sont pour le stockage standard, les mises en garde associées à d'autres formes de stockage sont discutées plus tard. Tous les coûts sont appliqués et déclarés séparément pour chaque tranche et chaque heure; en d'autres termes, si vous téléchargez votre rapport de facturation détaillé, vous verrez un élément de ligne chacun pour chaque combinaison de bucket, d'heure et de type de coût.
- Coûts de stockage: Le coût est mesuré en espace de stockage multiplié par le temps. Vous ne payez pas d'avance pour une quantité d'espace de stockage allouée. Au contraire, chaque fois que vous utilisez plus de stockage, vous payez un supplément pour ce stockage supplémentaire pour la durée d'utilisation. Les coûts peuvent donc fluctuer dans le temps à mesure que la quantité de données que vous avez stockées a changé. Les coûts de stockage sont signalés séparément pour chaque compartiment toutes les heures. Le prix varie selon la région mais est fixe dans chaque région. Depuis mars 2020, le coût varie de 2,3 cents par Go-mois aux États-Unis (Virginie du Nord) à 4,05 cents par Go-mois à Sao Paulo.
- Tarification des demandes: pour le stockage standard, le coût des demandes PUT, COPY, POST ou LIST varie de 0€ pour 1 000 requêtes dans les régions des États-Unis à 0€ pour 1 000 requêtes à Sao Paulo. Le coût de GET et de toutes les autres demandes est d'un ordre de grandeur inférieur, allant de 0€ pour 10000 demandes dans toutes les régions des États-Unis à 0€ pour 10000 demandes à Sao Paulo. Notez, cependant, que la plupart des coûts associés à une demande GET sont capturés dans les coûts de transfert de données (si la demande est faite de l'extérieur de la région). Notez également que pour les données stockées dans d'autres types de stockage, le prix des demandes est un peu plus élevé. Un autre type de demande qui devient pertinent lors de la discussion des politiques de cycle de vie est la demande de transition du cycle de vie (par exemple, la transition d'un élément du stockage standard vers IA ou Glacier).
- Coûts de transfert de données: les coûts sont nuls dans la même région AWS (à la fois S3 -> S3 et S3 -> instances EC2), environ 2 cents par Go pour le transfert de données entre les régions et environ 9 cents par Go pour le transfert de données vers l'extérieur d'AWS.
- Tarification de la récupération: Ceci ne s'applique pas au stockage standard, mais s'applique plutôt à deux des autres classes de stockage, à savoir IA et Glacier. Cette tarification est appliquée par Go pour les données récupérées.
3
Comprenez le rôle central joué par les compartiments dans l'organisation de vos fichiers s3 et l'utilisation de «objet» pour les fichiers s3.
- Vous pouvez créer des buckets sous votre compte. Un compartiment est identifié par une chaîne (le nom du compartiment). Il ne peut y avoir qu'un seul compartiment avec un nom de compartiment donné sur l'ensemble de S3, parmi les clients; par conséquent, vous ne pourrez peut-être pas utiliser un nom de compartiment si quelqu'un d'autre l'utilise déjà.
- Chaque compartiment est associé à une région AWS et est répliqué sur plusieurs zones de disponibilité au sein de cette région. Les informations sur la zone de disponibilité ne sont pas disponibles pour l'utilisateur final, mais constituent un détail d'implémentation interne qui aide S3 à maintenir une durabilité et une disponibilité élevées des données.
- Dans chaque compartiment, vous pouvez stocker vos fichiers directement sous le compartiment ou dans des dossiers. Les dossiers n'ont pas besoin d'être créés ou supprimés. Si vous enregistrez un fichier, il créera automatiquement des "dossiers" pour que le chemin du fichier ait un sens, s'ils n'existent pas déjà. Une fois qu'il n'y a plus de fichiers en dessous, le dossier cesse automatiquement d'exister.
- La façon dont S3 stocke les informations est comme un magasin clé-valeur: pour chaque préfixe qui n'est pas un nom de fichier, il stocke l'ensemble de fichiers et de dossiers avec ce préfixe. Pour chaque nom de fichier, il le mappe au fichier réel. En particulier, différents fichiers d'un compartiment peuvent être stockés dans des parties très différentes du centre de données.
- S3 appelle ses fichiers "objets", et vous pourriez rencontrer ce terme en lisant ailleurs sur S3.
4
Comprenez les différentes manières dont vous pouvez interagir avec les fichiers s3.
- Vous pouvez charger et télécharger des fichiers en ligne en vous connectant via un navigateur.
- Les outils de ligne de commande basés sur Python incluent l'interface de ligne de commande AWS,, l'ancien s3cmd et le plus récent s4cmd.
- Si vous utilisez Java ou un autre langage basé sur la JVM (tel que Scala), vous pouvez accéder aux objets S3 à l'aide du kit SDK AWS Java.
- Les outils de déploiement tels qu'Ansible et Chef proposent des modules pour gérer les ressources S3.
5
Comprenez les avantages et les inconvénients de l'utilisation de s3 et ses différences par rapport à un système de fichiers traditionnel.
- Avec S3, il faut un peu plus de gymnastique (et de temps d'exécution) pour obtenir une image globale de la quantité de données utilisées dans un compartiment ou dans des sous-dossiers de ce compartiment. En effet, ces données ne sont enregistrées nulle part directement, mais doivent plutôt être calculées via des recherches récursives de valeurs-clés.
- Trouver tous les fichiers qui correspondent à une expression régulière peut être une opération très coûteuse, en particulier lorsque cette expression régulière inclut des caractères génériques au milieu de l'expression plutôt qu'à la fin.
- Il n'est pas possible d'effectuer des opérations telles que l'ajout de données à un fichier: vous devez récupérer le fichier, le modifier, puis sauvegarder l'intégralité du fichier modifié (voir le point plus loin sur les capacités de synchronisation).
- Déplacer ou renommer des fichiers implique en fait de supprimer des objets et d'en créer de nouveaux. Le déplacement d'un dossier implique la suppression et la recréation de tous les objets qu'il contient. Chaque déplacement de fichier implique un appel GET et un appel PUT, ce qui entraîne une augmentation du prix des demandes. De plus, le déplacement d'objets peut être coûteux si les objets sont stockés dans des classes de stockage (Standard-IA et Glacier) où la récupération coûte de l'argent.
- S3 peut prendre en charge des tailles de fichier allant jusqu'à 5 To, mais le transfert de données entre régions peut commencer à être perturbé pour des tailles de fichier de plus de quelques centaines de mégaoctets. La CLI utilise le téléchargement en plusieurs parties pour les fichiers volumineux. Assurez-vous que si vos programmes traitent des fichiers volumineux, ils fonctionnent via le téléchargement en plusieurs parties ou divisent la sortie en fichiers plus petits.
- S3 ne fournit pas une prise en charge complète de rsync. Cependant, il existe une commande de synchronisation (aws s3 sync dans l'AWS CLI et s3cmd sync dans s3cmd) qui synchronise tout le contenu entre un dossier local et un dossier S3, ou entre deux dossiers S3. Pour les fichiers qui existent à la fois dans le dossier source et dans le dossier de destination, il peut détecter des fichiers identiques et éviter le transfert de données si les fichiers sont identiques; cependant, il n'est pas aussi efficace que rsync dans la mesure où il peut avoir besoin d'exécuter un transfert complet si les fichiers diffèrent un peu, alors que rsync n'envoie qu'un petit diff pour les fichiers très similaires. L'autre différence avec rsync est qu'il s'applique à un dossier entier et que les noms de fichiers ne peuvent pas être modifiés.

Vous ne payez qu'une seule fois les frais de transfert de données — Si vous répliquez le bucket dans la région USA Est, vous ne payez qu'une seule fois les frais de transfert de données.

Partie 2 sur 6: compresser/compresser les données

1
Assurez-vous que vous compressez les données là où les exigences de votre application le permettent avant de commencer.
- Découvrez quelles formes de compression et de compression sont compatibles avec les processus que vous utilisez pour générer des données et les processus que vous utilisez pour lire et traiter les données.
- Assurez-vous d'utiliser le zip et la compression pour vos plus gros dumps de données dans la mesure où cela n'interfère pas avec votre application. En particulier, les journaux d'utilisateurs bruts et les données structurées basées sur l'activité des utilisateurs sont des candidats de choix pour la compression.
- En règle générale, la compression permet d'économiser non seulement sur les coûts de stockage mais également sur les coûts de transfert (lors de la lecture/écriture des données) et peut même finir par rendre votre application plus rapide si le temps de chargement/téléchargement est un goulot d'étranglement plus important que le temps de compression/décompression local. C'est souvent le cas.
- Pour prendre un exemple, la conversion de gros fichiers de données structurées au format BZ2 peut entraîner une diminution de l'espace de stockage d'un facteur variant de 3 à 10; cependant, BZ2 est gourmand en calcul pour compresser et décompresser. Les autres algorithmes de compression à prendre en compte sont gzip, lz4 et zstd.
- D'autres moyens possibles de réduire l'espace incluent l'utilisation du stockage basé sur les colonnes plutôt que le stockage basé sur les lignes, et l'utilisation de formats binaires (tels que AVRO) plutôt que de formats lisibles par l'homme (tels que JSON) pour la conservation des données à long terme.
2

Si la compression des données n'est pas possible au moment où vous les écrivez pour la première fois, envisagez d'exécuter un processus alternatif pour ré-ingérer et compresser les données. Il s'agit généralement d'une solution sous-optimale et très rarement nécessaire, mais il peut y avoir des cas où elle est pertinente. Si vous envisagez une telle solution, vous devrez effectuer les calculs avec soin en fonction du coût de réingestion et de compression des données et de la durée totale pendant laquelle vous avez l'intention de conserver les données.

Partie 3 sur 6: optimisation des coûts de stockage

1
Comprenez les différences entre les quatre types de stockage s3.
- Le stockage standard est le plus cher pour le stockage, mais il est le moins cher et le plus rapide pour apporter des modifications aux données. Il est conçu pour une durabilité de 99,999999999% (sur un an, c'est-à-dire la fraction attendue d'objets S3 qui survivront sur un an) et une disponibilité de 99,99% (disponibilité se référant à la probabilité qu'un objet S3 donné soit accessible à un moment donné). Notez qu'en pratique, il est très rare de perdre des données dans S3 et qu'il existe des facteurs de risque de perte de données plus importants que les données qui disparaissent réellement de S3 (ces facteurs plus importants incluent la suppression accidentelle de données et le piratage malveillant de votre compte pour supprimer du contenu, ou même Amazon étant contraint de supprimer vos données à cause de la pression des gouvernements).
- Le stockage à redondance réduite (RRS) était auparavant 20% moins cher que le stockage standard et offre un peu moins de redondance. Vous souhaiterez peut-être l'utiliser pour une grande partie de vos données qui ne sont pas très critiques (telles que les journaux d'utilisateurs complets). Ceci est conçu pour une durabilité de 99,99% et une disponibilité de 99,99%. Cependant, à partir de décembre 2016, les réductions de prix apportées au stockage standard n'étaient pas accompagnées de réductions de prix correspondantes pour le RRS, de sorte que le RRS est actuellement aussi ou plus cher.
- Stockage standard - Infrequent Access (appelé S3 - IA) est une option introduite par Amazon en septembre 2015, qui combine la haute durabilité de S3 avec une faible disponibilité de seulement 99%. C'est une option pour stocker des archives à long terme qui n'ont pas besoin d'être consultées souvent mais qui, lorsqu'elles doivent être consultées, doivent être consultées rapidement. S3 - IA est facturé pour un minimum de 30 jours (même si les objets sont supprimés avant cela) et une taille d'objet minimale de 128 Ko. Il est environ deux fois moins cher que S3, bien que la remise précise varie selon les régions.
- Glacier est la forme de stockage la moins chère. Cependant, Glacier coûte de l'argent pour désarchiver et rendre à nouveau disponible pour la lecture et l'écriture, avec le montant que vous devez payer en fonction du nombre de demandes de récupération, de la vitesse à laquelle vous souhaitez récupérer les données et de la taille des données récupérées. De plus, les fichiers Glacier ont une période de stockage minimale de 90 jours: les fichiers supprimés avant cette date sont facturés pour le reste des 90 jours suivant la suppression.
2
Ayez une idée de la croissance de vos coûts.
- Dans un cas d'utilisation où vous disposez d'un ensemble fixe de fichiers que vous mettez à jour périodiquement (en supprimant efficacement les anciennes versions), vos coûts de stockage mensuels sont à peu près constants, avec une limite supérieure assez serrée. Vos dépenses de stockage cumulées augmentent de manière linéaire. Il s'agit d'un scénario typique pour un ensemble d'exécutables et de scripts.
- Dans un cas d'utilisation où vous générez continuellement de nouvelles données à un rythme constant, vos coûts de stockage mensuels augmentent de manière linéaire. Votre coût de stockage cumulé augmente de façon quadratique.
- Dans un cas d'utilisation où le taux de génération de données lui-même augmente de manière linéaire, vos coûts de stockage mensuels augmentent de manière quadratique et votre coût de stockage cumulé augmente régulièrement.
- Dans un cas d'utilisation où le taux de génération de données augmente de manière exponentielle, votre coût de stockage de données mensuel et votre coût de stockage de données cumulé augmentent également de manière exponentielle.
3
Découvrez si la gestion des versions d'objets est pertinente pour vos objectifs.
- La gestion des versions d'objets vous permet de conserver les anciennes versions d'un fichier. Un avantage est que vous pouvez revisiter une ancienne version.
- Lorsque vous utilisez la gestion des versions d'objets, vous pouvez la combiner avec des stratégies de cycle de vie pour retirer les versions antérieures à un certain âge (sinon la version actuelle).
- Si vous utilisez la gestion des versions d'objets, gardez à l'esprit que le simple fait de répertorier les fichiers (à l'aide d'aws s3 ls ou de l'interface en ligne) vous fera sous-estimer le stockage total utilisé, car vous êtes facturé pour les anciennes versions qui ne sont pas incluses dans la liste.
4
Explorez les politiques de cycle de vie de vos données.
- Vous pouvez définir des stratégies pour supprimer automatiquement les données dans des compartiments particuliers, ou même avec des préfixes particuliers dans des compartiments, datant de plus d'un certain nombre de jours. Cela peut vous aider à mieux contrôler vos coûts S3 et également à vous conformer à diverses politiques de confidentialité et de données. Notez que certaines lois et politiques de conservation des données peuvent vous obliger à conserver les données pendant une durée minimale; ceux-ci fixent une limite inférieure au délai après lequel vous pouvez supprimer des données dans votre politique de cycle de vie. D'autres politiques ou lois peuvent vous obliger à supprimer des données dans un certain délai; ceux-ci fixent une limite supérieure au délai après lequel vous devez supprimer les données dans votre politique de cycle de vie.
- Avec une politique de cycle de vie pour la suppression, la façon dont vos coûts augmentent change beaucoup. Désormais, avec un flux constant de données entrantes, vos coûts de stockage mensuels restent constants au lieu d'augmenter de manière linéaire, car vous ne stockez qu'une fenêtre mobile de données plutôt que toutes les données jusqu'à présent. Même si la taille des données entrantes augmente de manière linéaire, vos coûts de stockage mensuels n'augmentent que de manière linéaire plutôt que quadratique. Cela peut vous aider à lier vos coûts d'infrastructure à votre modèle de revenus: si vos revenus mensuels sont à peu près proportionnels au débit auquel vous recevez des données, votre modèle de stockage est évolutif.
- Une limitation technique: vous ne pouvez pas définir deux stratégies avec le même compartiment où un préfixe est un sous-ensemble de l'autre. Gardez cela à l'esprit lorsque vous réfléchissez à la manière de stocker vos données S3.
- En plus des politiques de cycle de vie pour la suppression, vous pouvez également définir des politiques pour archiver les données (c'est-à-dire les convertir du stockage standard vers Glacier), réduisant ainsi les coûts de stockage. Cependant, Glacier a une période de conservation minimale de 90 jours: vous êtes facturé pour 90 jours de stockage dans Glacier, même si vous choisissez de le supprimer avant cette date. Par conséquent, si vous avez l'intention de supprimer sous peu, ce n'est probablement pas une bonne idée de passer à Glacier.
- Vous pouvez également avoir une politique de cycle de vie pour convertir les données en S3 (stockage standard) en S3 - IA. Cette stratégie est idéale pour les données auxquelles vous vous attendez à accéder fréquemment immédiatement après leur création, mais peu fréquemment par la suite. Les fichiers dans IA ont une taille d'objet minimale (vous êtes facturé pour une taille de fichier de 128 Ko pour les fichiers plus petits que cela) et une période de conservation minimale de 30 jours.
- Notez que les transitions de cycle de vie elles-mêmes coûtent de l'argent et qu'il est souvent préférable de créer des objets directement dans la classe de stockage souhaitée plutôt que de les transférer. Vous devrez effectuer les calculs pour votre cas d'utilisation pour savoir si et quand la transition du cycle de vie est logique.
5
Utilisez les heuristiques suivantes pour déterminer la meilleure classe de stockage en fonction de votre cas d'utilisation. Alors que nous parlons comme si nous avions affaire à un seul fichier, nous pensons vraiment à une configuration où cela se passe séparément et indépendamment pour un grand nombre de fichiers.
- La première étape pour déterminer la bonne classe de stockage consiste à obtenir une estimation de la taille de votre fichier, de la période de rétention, du nombre d'accès attendu (ainsi que de la façon dont ce nombre varie dans le temps en fonction de l'âge) et du temps d'attente maximal. lorsque vous avez besoin d'accéder à quelque chose. Vous pouvez utiliser tous ces paramètres comme paramètres dans une formule qui calcule le coût attendu de l'utilisation de chaque classe de stockage. La formule devient assez compliquée.
- Notez que les seuils exacts pour ceux-ci peuvent varier en fonction des prix actuels dans votre région. Les prix varient selon les régions et changent au fil du temps. En particulier, les points suivants: tarification du stockage pour chaque classe de stockage, tarification de la demande pour chaque classe de stockage, tarification de la récupération pour chaque classe de stockage, et exigences de taille minimale et de période de conservation minimale. Avec ces mises en garde, les heuristiques sont ci-dessous.
- Si vous avez l'intention de conserver les données pendant deux semaines ou moins, le stockage standard est préférable à la fois au stockage IA et au stockage Glacier. La raison en est que les périodes de conservation minimales (30 jours pour IA, 90 jours pour Glacier) annulent les avantages en termes de coûts (au plus le double pour IA, environ six fois pour Glacier) à deux semaines ou moins.
- Si la taille de votre fichier est de 64 Ko ou moins, le stockage standard l'emporte toujours sur le stockage IA. C'est parce que l'exigence de taille minimale d'IA (128 Ko) annule l'avantage de coût (au plus le double).
- Si vous avez l'intention d'accéder à chaque fichier une fois par mois ou plus fréquemment, le stockage standard l'emporte à la fois sur IA et Glacier. C'est parce que le coût supplémentaire d'une seule récupération de données détruit l'économie de stockage mensuelle.
- Supposons que vous ayez des données que vous devez initialement conserver dans un stockage standard pendant un mois, après quoi vous pouvez les déplacer vers IA pendant un mois ou plus, car vous vous attendez à ne plus avoir besoin d'y accéder par la suite. Il est logique de le déplacer vers IA uniquement si le nombre total de mégaoctets-mois dans l'état IA par fichier est d'au moins 1. En effet, le coût de transition du cycle de vie du passage à IA doit être compensé par les économies de coûts. Par exemple, si vous souhaitez conserver les données pendant un mois supplémentaire, la taille du fichier doit être d'au moins 1 Mo pour que ce soit une dépense intéressante. Notez que la période minimale de 30 jours rend les transitions pour des durées plus courtes encore moins intéressantes.
- De même, pour la migration vers Glacier, le seuil de rentabilité est d'environ 2,5 mégaoctets-mois pour chaque fichier. Notez, cependant, que la période de conservation minimale de 90 jours dans Glacier complique les choses; si vous avez l'intention de bénéficier du transfert de données vers Glacier pendant un mois, la taille du fichier doit être de 7,5 Mo ou plus.
- Si vous prévoyez de ne pas avoir besoin d'accéder au contenu après l'avoir écrit sur S3, la stratégie optimale est généralement soit standard, soit Glacier, le compromis dépendant de la période de rétention. Cependant, il existe un point idéal entre les deux où IA est la meilleure option (par exemple, stocker 128 Ko pendant un mois). Pour illustrer cela, voici une image pour le cas simple où vous devez conserver un seul fichier d'un fichier fixe. taille pendant une durée fixe, avec zéro accès attendu après son stockage. Le temps en mois est sur l'axe horizontal et la taille du fichier en Go sur l'axe des y. Un point est coloré en bleu, rouge ou jaune selon que la classe de stockage optimale du point de vue des coûts est standard, IA ou Glacier. Nous utilisons les coûts comme dans la région US Standard en décembre 2016.
- Au fur et à mesure que vous augmentez le nombre attendu d'accès aux données, la norme devient optimale pour de plus en plus de cas d'utilisation (c'est-à-dire pour des tailles de données plus importantes et pour des périodes de conservation plus longues). IA commence également à devenir optimal dans les cas où Glacier aurait été optimal auparavant. En d'autres termes, standard prend le relais de IA et IA prend le relais de Glacier.
6
Utilisez les références de bon sens suivantes en fonction de votre cas d'utilisation du stockage. Cela vous aidera à avoir une idée des coûts de stockage auxquels vous pouvez vous attendre.
- Si vous diffusez en direct un site Web ou des images statiques: les coûts de stockage sont susceptibles d'être de quelques centimes, avec des détails dépendant de la taille de votre site. Les principaux coûts de service d'un site en direct sont la tarification de la demande et les coûts de transfert.
- Si vous stockez un lac de données avec le flux principal généré par l'utilisateur étant une activité Web ou d'application (c'est-à-dire des journaux de demande Web): une ligne de journal de demande Web individuelle peut varier en taille maximale de 1 Ko (si vous champs) à 10 Ko (si vous incluez également des informations périphériques sur l'utilisateur et le contexte). Si vous recevez un million de demandes Web par mois et que vous conservez les anciens journaux de demandes Web pendant un mois, cela se traduit par entre 1 Go et 10 Go de stockage, soit entre 2,3 et 40,5 cents de coût de stockage mensuel. Le coût évolue linéairement à la fois avec votre trafic et avec votre décision sur la durée de stockage. Par exemple, avec un milliard de requêtes Web par mois et un stockage de données pendant un an, vos coûts mensuels de stockage de données augmentent jusqu'à quelque part entre 210€ et 3630€ L'utilisation de formats binaires et la compression/la compression peuvent réduire encore les coûts.
- Si vous stockez des archives d'images et de séquences vidéo: par exemple, si vous êtes une chaîne de télévision qui filme régulièrement des séquences et souhaite conserver des archives d'anciennes séquences disponibles au cas où cela deviendrait pertinent plus tard. Il s'agit d'un cas d'utilisation où l'espace total de stockage peut être assez important. Par exemple, avec 10 heures de séquences vidéo quotidiennes, vous pourriez ajouter quelque chose de l'ordre de 100 Go (non compressé) chaque jour. Si vous placez ces séquences dans un stockage standard pendant la première année, puis archivez-les sur Glacier pendant neuf années supplémentaires, vos données totales atteindraient 365 To (36,5 To en stockage standard) et vos coûts de stockage S3 mensuels (avant compression) serait d'environ 1640€ (deux tiers pour Glacier, un tiers pour un stockage standard). La compression de diverses sortes peut réduire les coûts de stockage d'un facteur variant de 2 à 10.
- Il est instructif d'examiner les factures de certains utilisateurs de Power S3 pour avoir une idée de la variation d'une facture.
  - Dropbox aurait 500 pétaoctets de données dans S3 avant de les transférer sur ses propres serveurs. Aux prix actuels indiqués en ligne, cela coûterait environ 7,80 millions d'euros par mois. Bien que Dropbox ait probablement bénéficié d'une remise importante et obtenu des avantages de la déduplication et de la compression des données, sa facture était probablement encore d'au moins des centaines de milliers de dollars par mois.
  - Un autre exemple extrême d'un grand utilisateur est DigitalGlobe, qui transfère 100 Po d'images satellite haute résolution vers S3.
  - Pinterest a indiqué qu'il ajoute 20 téraoctets de données par jour, ce qui, dans un stockage standard, signifie que leur facture mensuelle augmenterait de 450€/mois chaque jour. Si ce rythme d'ajout de données se poursuit pendant dix ans, ils auraient un stockage total d'environ 75 Po et une facture mensuelle de l'ordre de centaines de milliers de dollars.
  - Au-delà de ces cas d'utilisation extrêmes, cependant, même certaines des plus grandes entreprises du monde ont des factures S3 assez faibles. Par exemple, à la fin de 2013, Airbnb a déclaré avoir 50 To de données photo à domicile haute résolution, un montant qui coûterait environ 860€ par mois aux prix d'aujourd'hui.

Comprenez le rôle central joué par les compartiments dans l'organisation de vos fichiers s3 et l'utilisation de «objet» pour les fichiers s3.

Partie 4 sur 6: optimisation des coûts de transfert de données

1
Si vous utilisez s3 pour diffuser du contenu en direct, placez-le derrière un CDN tel qu'amazon cloudfront, cloudflare ou maxcdn.
- Le CDN possède un grand nombre d'emplacements périphériques dans différentes parties du monde, allant généralement de dizaines à des centaines.
- La demande de l'utilisateur pour la page est acheminée vers l'emplacement périphérique CDN le plus proche. Cet emplacement périphérique vérifie ensuite s'il dispose d'une copie mise à jour de la ressource. Sinon, il le récupère à partir de S3. Sinon, il sert la copie dont il dispose.
- Le résultat: les utilisateurs finaux voient une disponibilité plus élevée et une latence plus faible (car les ressources sont servies à partir d'un emplacement physiquement proche d'eux) et le nombre de demandes et la quantité de transfert de données à partir de S3 sont maintenus bas. Explicitement, le nombre de requêtes est limité par (nombre d'emplacements périphériques) X (nombre de fichiers) si vous ne mettez jamais à jour les fichiers; si vous mettez à jour des fichiers, vous devez également multiplier par le nombre de mises à jour de fichiers.
2
Comprenez l'avantage clé de la colocation de ec2/s3. Si votre utilisation principale de S3 est de lire et d'écrire des données sur des instances EC2 (c'est-à-dire n'importe quel cas d'utilisation autre que l'instance de diffusion en direct), cet avantage est alors mieux exploité si votre compartiment S3 est situé dans la même région AWS que le Instances EC2 qui y lisent ou y écrivent. Cela aura plusieurs avantages:
- Faible latence (moins d'une seconde)
- Bande passante élevée (supérieure à 100 Mbit/seconde): Notez que la bande passante est en fait assez bonne entre les différentes régions des États-Unis, ce n'est donc pas un problème important si toutes vos régions se trouvent aux États-Unis, mais elle peut être importante entre les États-Unis et UE, UE et Asie-Pacifique, ou États-Unis et Asie-Pacifique.
- Pas de frais de transfert de données (cependant, vous payez toujours le prix de la demande)
3
Déterminez l'emplacement (région AWS) de vos compartiments s3.
- Si vous exécutez des instances EC2 qui lisent ou écrivent dans les compartiments S3: comme indiqué à l'étape 1, la colocation de S3 et EC2, dans la mesure du possible, aide à réduire les coûts de bande passante, de latence et de transfert de données. Par conséquent, une considération importante dans la localisation de votre compartiment S3 est: où pensez-vous avoir les instances EC2 qui interagiront avec ce compartiment S3? Si les instances EC2 sont principalement des instances backend, vous devez alors prendre en compte les coûts de ces instances. S'il s'agit d'instances frontales, réfléchissez aux régions dans lesquelles vous vous attendez à obtenir la plupart de votre trafic. Dans l'ensemble, vous devez vous attendre à ce que les considérations d'instance EC2 soient plus importantes que les considérations S3 dans la détermination de la région. Il est donc généralement logique de décider d'abord où vous vous attendez à ce que votre capacité d'instance EC2 soit, puis d'y placer vos compartiments S3. En général,Les coûts S3 sont inférieurs dans les mêmes régions que les instances EC2, donc cela ne crée heureusement pas de conflit.
- S'il existe d'autres services AWS dont vous devez disposer, mais qui ne sont pas disponibles dans toutes les régions, cela peut également restreindre votre choix de région.
- Si vous téléchargez fréquemment des fichiers de votre ordinateur personnel vers S3, vous pouvez envisager d'installer un compartiment dans une région plus proche de votre domicile, afin d'améliorer la latence de téléchargement. Cependant, cela devrait être une considération mineure par rapport aux autres.
- Si vous prévoyez d'utiliser S3 pour diffuser des images statiques en direct, décidez de l'emplacement en fonction de l'endroit d'où vous prévoyez obtenir votre trafic.
- Dans certains cas, les politiques que vous êtes obligé de suivre en fonction de la loi ou du contrat contraignent votre choix de région pour le stockage de données S3. Gardez également à l'esprit que l'emplacement physique de votre compartiment S3 pourrait affecter ce que les gouvernements sont en mesure d'obliger légalement Amazon à publier vos données (bien que de tels événements soient assez rares).
4
Déterminez si la réplication entre régions a du sens pour votre compartiment. La réplication interrégionale entre des compartiments de différentes régions synchronise automatiquement les mises à jour des données d'un compartiment avec les données d'autres compartiments. Le changement peut ne pas se produire immédiatement, et les modifications de fichiers volumineux en particulier sont limitées par les limitations de bande passante entre les régions. Gardez à l'esprit les avantages et les inconvénients suivants de la réplication entre régions.
- Vous payez plus en coûts de stockage S3, car les mêmes données sont mises en miroir dans plusieurs régions.
- Vous payez en S3 <-> S3 les frais de transfert de données. Cependant, si les données sont lues ou écrites par des instances EC2 dans plusieurs régions, cela peut être compensé par des économies sur les coûts de transfert de données S3 -> EC2. Cela peut aider principalement si vous chargez les mêmes données S3 dans des instances EC2 dans de nombreuses régions différentes. Par exemple, supposons que vous ayez 100 instances chacune dans USA Est et USA Ouest où vous devez charger les mêmes données à partir d'un compartiment S3 dans USA Ouest. Si vous ne répliquez pas ce compartiment dans USA Est, vous payez le coût de transfert des 100 transferts de données du compartiment S3 vers les machines USA Est. Si vous répliquez le bucket dans la région USA Est, vous ne payez qu'une seule fois les frais de transfert de données.
- La réplication interrégionale a donc beaucoup de sens pour les exécutables, les scripts et les données relativement statiques, où vous valorisez la redondance interrégionale, où les mises à jour des données sont peu fréquentes et où la majeure partie du transfert de données se fait dans le S3 -> EC2 direction. Un autre avantage est que si ces données sont répliquées dans toutes les régions, il est beaucoup plus rapide de créer de nouvelles instances, ce qui permet des architectures d'instances EC2 plus flexibles.
- Pour les applications de journalisation (où les données sont lues par de nombreuses instances frontales et doivent être enregistrées dans un emplacement central dans S3), il est préférable d'utiliser un service tel que Kinesis pour rassembler les flux de données entre les régions plutôt que d'utiliser des compartiments S3 répliqués entre régions..
- Si vous utilisez S3 pour la diffusion en direct d'images statiques sur un site Web, la réplication interrégionale peut avoir du sens si le trafic de votre site Web est mondial et si le chargement rapide des images est important.
5
Si vous synchronisez des mises à jour régulières avec des fichiers déjà existants, choisissez une structure de dossiers qui permet l'utilisation de la fonction de synchronisation de l'AWS cli.
- La commande "aws s3 sync" se comporte comme rsync, mais ne peut être exécutée qu'au niveau d'un dossier. Par conséquent, conservez votre structure de dossiers de manière à pouvoir utiliser cette commande.
6
Gardez à l'esprit les heuristiques suivantes pour estimer les coûts de transfert.
- Pour un site Web statique en direct, le transfert de données mensuel, sans CDN, est égal à la taille totale des temps de trafic de chaque page visitée (y compris les images et autres ressources chargées sur la page). Par exemple, pour un million de pages vues et une taille de page moyenne de 100 Ko, la sortie totale de données est de 100 Go, ce qui coûte 6,70€ par mois.
- Pour un site Web statique de diffusion en direct derrière un CDN, le CDN impose une limite supérieure au transfert total de données. Plus précisément, si vous ne mettez pas du tout à jour les données, de sorte que le CDN serve son propre cache, le transfert total de données sortant est limité par le produit de la taille totale de votre site Web et du nombre d'emplacements périphériques du CDN, quel que soit le trafic. le volume. Par exemple, si votre site a un total de 1000 pages de 100 Ko chacune, la taille totale est de 100 Mo. S'il y a 100 emplacements périphériques, cela donne une limite totale de transfert de données de 10 Go par mois, ou une limite de coût de 90 centimes par mois. Cependant, si vous mettez à jour certains fichiers, vous devez recompter chaque fichier après chaque mise à jour.
- La mesure dans laquelle les CDN économisent par rapport à l'absence de CDN dépend de la diversité d'accès à votre contenu et également de la répartition géographique de l'accès. Si votre contenu est accessible dans une région géographique, vous en économiserez davantage. Si les gens accèdent à un petit nombre de pages de votre site, vous économiserez davantage. Si, dans chaque région, les gens accèdent à un petit nombre de pages de votre site (même si les pages diffèrent selon les régions), vous économiserez davantage. Les économies de CDN peuvent aller de 50% à 99%.

Lisez aussi: Comment vendre des jeux sur Amazon?

Partie 5 sur 6: optimisation des coûts grâce à la tarification des demandes

1

Si la tarification des demandes est une préoccupation importante, conservez vos données dans un stockage standard. Voir la partie 3, étape 5 pour plus d'informations.
2

Si vous diffusez en direct un site statique ou des images ou vidéos statiques via s3, placez-le derrière un CDN. Ceci pour les mêmes raisons que celles discutées dans la partie 4, étape 1.
3
Si vous utilisez s3 comme magasin de données pour la recherche de valeurs-clés, vous devez faire un compromis entre le prix de la demande PUT et le prix du transfert de données lors de la détermination de la taille des fichiers dans lesquels vous devez partager vos données.
- Si vous partitionnez les données en un grand nombre de petits fichiers, vous avez besoin d'un grand nombre de PUT pour insérer les données, mais chaque recherche est plus rapide et utilise moins de transfert de données car vous devez lire un fichier plus petit à partir de S3.
- D'un autre côté, si vous partitionnez les données en un petit nombre de fichiers volumineux, vous avez besoin d'un petit nombre de PUT, mais chaque accès coûte cher en coût de transfert de données (car vous devez lire un gros fichier).
- Le compromis se produit généralement quelque part au milieu. Mathématiquement, le nombre de fichiers que vous devez utiliser est la racine carrée du rapport d'un terme de coût de transfert de données à un terme de coût PUT.
4

En général, il est préférable d'utiliser un plus petit nombre de fichiers de taille moyenne pour un lac de données.
5
Si vous subdivisez des données sur plusieurs fichiers, utilisez un petit nombre de fichiers de taille moyenne (entre 1 Mo et 100 Mo) pour minimiser la tarification et la surcharge des demandes.
- Un plus petit nombre de fichiers plus volumineux réduit le nombre de requêtes nécessaires pour récupérer et charger les données, ainsi que pour écrire les données.
- Étant donné qu'il y a une petite quantité de latence associée à chaque lecture de fichier, les processus informatiques distribués (tels que les processus basés sur Hadoop ou Apache Spark) qui lisent les fichiers se déroulent généralement plus rapidement avec un petit nombre de fichiers de taille moyenne qu'avec un grand nombre de petits fichiers.
- Moins le nombre total de fichiers est petit, moins il est coûteux d'exécuter des requêtes qui tentent de faire correspondre des expressions régulières arbitraires.
- Une mise en garde importante est que, dans de nombreux cas, le type de sortie naturel est un grand nombre de petits fichiers. Cela est vrai pour les sorties des charges de travail de calcul distribué, où chaque nœud du cluster calcule et génère un petit fichier. C'est également vrai si les données sont écrites en temps réel et que nous voulons écrire les données dans un court intervalle de temps. Si vous prévoyez de lire et de traiter ces données à plusieurs reprises, envisagez de fusionner les données dans des fichiers plus volumineux. De plus, pour les données entrantes en temps réel, envisagez d'utiliser des services de streaming tels que Kinesis pour rassembler les données avant de les écrire sur S3.
6

Si vous constatez des coûts de requête inattendus importants, recherchez les processus malveillants qui effectuent une correspondance d'expression régulière. Assurez-vous que toute correspondance d'expression régulière utilise des caractères génériques aussi près que possible de la fin du fichier.
7
Gardez à l'esprit les heuristiques suivantes pour les coûts de demande.
- Les coûts de demande doivent être compris entre 0% et 20% des coûts de stockage. S'ils sont plus élevés, déterminez si vous utilisez la bonne classe de stockage, si vous partitionnez les données dans les bonnes tailles ou si vous effectuez des opérations inutiles ou inefficaces. Vérifiez également les transitions de cycle de vie inutiles ainsi que les processus de correspondance des expressions régulières indésirables.
- Les coûts des demandes doivent être inférieurs aux coûts de transfert si vos données sont principalement expédiées vers l'extérieur d'AWS (si vos données sont expédiées dans la même région AWS, il ne devrait y avoir aucun coût de transfert de données, donc cela ne s'applique pas, car les coûts de demande seront positif alors que les frais de transfert seront nuls).

Vous souhaiterez peut-être signaler une ventilation de vos coûts entre le stockage — Au niveau supérieur, vous souhaiterez peut-être signaler une ventilation de vos coûts entre le stockage, le transfert et la tarification de la demande.

Partie 6 sur 6: surveillance et débogage

1
Configurez la surveillance de vos coûts s3.
- Votre compte AWS a accès aux données de facturation qui fournissent la ventilation complète des coûts. Configurez une alerte de facturation afin que les données commencent à être envoyées à Amazon CloudWatch. Vous pouvez ensuite configurer plus d'alertes à l'aide de CloudWatch. Les données CloudWatch arrivent sous forme de points de données toutes les quelques heures, mais n'incluent pas une ventilation détaillée de toutes les dimensions d'intérêt.
- À tout moment, vous pouvez télécharger la répartition détaillée par heure et par type de service depuis votre compte root. Ces données ont généralement un retard de 24 à 48 heures, c'est-à-dire que vous ne verrez pas d'informations pour les 24 à 48 heures les plus récentes. Pour S3, vous pouvez télécharger dans une feuille de calcul ou au format CSV les données avec une répartition par heure, compartiment, région et type d'opération (GET, POST, LIST, PUT, DELETE, HEADOBJECT ou quelles que soient vos opérations).
2
Rédigez des scripts pour fournir des rapports quotidiens faciles à lire sur vos coûts, ventilés de différentes manières.
- Au niveau supérieur, vous souhaiterez peut-être signaler une ventilation de vos coûts entre le stockage, le transfert et la tarification de la demande.
- Dans chacun d'entre eux, vous souhaiterez peut-être ventiler davantage les coûts en fonction de la classe de stockage (Standard, RRS, IA et Glacier).
- Dans la tarification des demandes, vous souhaiterez peut-être ventiler les coûts par type d'opération (GET, POST, LIST, PUT, DELETE, HEADOBJECT ou quelles que soient vos opérations).
- Vous pouvez également fournir une ventilation par seau.
- En règle générale, vous devez décider du nombre de dimensions à explorer en troquant la facilité d'une compréhension rapide contre une granularité suffisante. Un bon compromis en général consiste à inclure des explorations le long d'une dimension à la fois (par exemple, une exploration par compartiment, une exploration par stockage vs prix de transfert vs demande, une exploration par classe de stockage) dans votre rapport quotidien, et d'approfondir uniquement si quelque chose semble hors de l'ordinaire.
3
Créez un modèle de coût prévu et utilisez votre script pour identifier les écarts entre les coûts réels et votre modèle.
- Sans modèle de ce que devraient être les coûts, il est difficile d'examiner les coûts et de savoir s'ils sont erronés.
- Le processus de construction d'un modèle de coût est un bon exercice pour articuler clairement votre architecture et potentiellement penser à des améliorations même sans regarder le modèle des coûts réels.
4
Déboguer les coûts élevés.
- Si le coupable est les coûts de stockage, voir la partie 3.
- Si le coupable est des coûts énormes de transfert de données, voir la partie 4.
- Si le coupable est la demande de prix, voir la partie 5.

Les principaux coûts de service d'un site en direct sont la tarification des demandes et les coûts de transfert.

Conseils

Gardez une trace de vos coûts Amazon S3. Vous ne pouvez pas optimiser ce que vous ne mesurez pas. L'un des plus grands avantages de S3 est que vous n'avez pas à trop réfléchir au stockage de fichiers: vous disposez en fait d'un stockage de fichiers illimité qui n'est pas lié à une instance particulière. Cela offre beaucoup de flexibilité, mais d'un autre côté, cela signifie également que vous risquez de perdre la trace de la quantité de données que vous utilisez et de combien cela vous coûte. Vous devez revoir périodiquement vos coûts S3 et également configurer des alertes de facturation AWS dans Amazon CloudWatch pour vous alerter lorsque les coûts S3 pour un mois donné dépassent un seuil.
N'utilisez pas Amazon S3 pour des opérations nécessitant des latences inférieures à une seconde. Vous pouvez utiliser S3 pour lancer des instances qui exécutent de telles opérations, ou pour des actualisations périodiques des données et des configurations sur ces instances, mais ne comptez pas sur les fichiers GET S3 pour les opérations où vous devez répondre en quelques millisecondes. Si vous utilisez S3 pour la journalisation, mettez en mémoire tampon les activités localement sur votre instance frontale (ou écrivez-les dans un flux tel que Kinesis), puis enregistrez-les périodiquement sur S3.
N'utilisez pas S3 pour des applications qui impliquent de fréquentes lectures et écritures de données. Amazon S3 convient davantage à l'enregistrement de données à moyen et à long terme qu'à un endroit pour stocker, mettre à jour et rechercher rapidement des données. Envisagez d'utiliser des bases de données (et d'autres magasins de données) pour mettre à jour rapidement les données. Une chose importante à retenir avec S3 est que la cohérence de lecture/écriture immédiate n'est pas garantie: cela peut prendre quelques secondes après une écriture pour que la lecture récupère le fichier nouvellement écrit. De plus, vous verrez également une facture énorme si vous essayez de l'utiliser de cette façon, car le prix des demandes devient assez élevé si vous utilisez S3 de cette façon.