Réduire drastiquement les coûts de transfert de données sur AWS

• Sur AWS, le transfert entre zones de disponibilité d’une même région est facturé $0.01/Go à l’émission comme à la réception, soit environ $20 pour transférer directement 1 To, mais utiliser S3 comme relais temporaire peut faire tomber le coût à quelques centimes
• Un bucket S3 standard fonctionne à l’échelle de la région, et AWS le réplique sur au moins 3 zones de disponibilité de la région, ce qui le rend accessible de la même façon depuis plusieurs AZ d’une même région
• Si une instance EC2 téléverse vers S3 dans la même région et qu’une autre AZ télécharge ensuite, les frais de transfert de données sont nuls ; le coût réel se limite alors au stockage S3 sur une très courte durée et aux coûts des requêtes API
• Dans us-east-1, conserver 1 To moins d’une heure coûte environ $0.03 avec S3 Standard à $23/TB-month, soit 1/720 du tarif mensuel ; même 1 Po tombe à environ $32 au lieu de $20,000 en transfert direct
• Cette méthode n’est pas un remplacement drop-in d’un code de transfert réseau et peut augmenter la latence, mais pour les transferts cross-AZ massifs où le coût prime sur tout le reste, elle peut réduire la facture de plus de 99 %

---

Là où les coûts de transfert de données AWS explosent

• Sur AWS, déplacer des données sans précaution peut faire grimper très vite la facture de transfert
• À la date de rédaction, les principaux tarifs de transfert de données sont les suivants
  • Le trafic sortant d’AWS vers l’Internet public coûte $0.09/Go dans us-east-1, jusqu’à $0.154/Go dans af-south-1, soit $90 à $154 pour 1 To
  • Le trafic sortant d’une région AWS vers une autre coûte $0.02/Go dans us-east-1, jusqu’à $0.147/Go dans af-south-1 ; même sans quitter le réseau AWS, 1 To peut donc coûter $20 à $147
  • Le trafic entre zones de disponibilité différentes d’une même région est facturé $0.01/Go par sens ; envoyer 1 To de us-east-1a vers us-east-1b revient donc à $10 à l’envoi et $10 à la réception, soit $20 au total
• Le trafic Internet et le trafic inter-régions ne paient que les frais d’egress sur les données sortantes, alors que le trafic inter-AZ dans une même région est facturé dans les deux sens
• Déployer des ressources sur plusieurs zones de disponibilité améliore la résilience et la disponibilité, mais si ces ressources échangent des données entre AZ différentes, des coûts cross-AZ apparaissent

Points d’attention sur PrivateLink et les VPC endpoints

• Si une instance EC2 envoie 1 To vers un bucket S3 public situé dans une autre région, la facture peut être de $90 d’egress Internet au lieu des $20 attendus pour un transfert inter-régions
• AWS PrivateLink et les VPC endpoints sont utiles, côté coût et sécurité, car ils garantissent que les données inter-régions ne quittent pas le réseau AWS
• En revanche, ces fonctionnalités ne sont pas gratuites et ont leurs propres limites et détails tarifaires
• Ressources associées
  • AWS PrivateLink for volumetric data processing
  • Amazon VPC endpoints
  • Vantage: NAT Gateway and VPC Endpoint savings

Contourner les coûts de transfert cross-AZ avec S3

• La plupart des classes de stockage S3 stockent les buckets à l’échelle de la région, et non d’une zone de disponibilité
  • L’utilisateur téléverse dans un bucket us-east-1, pas dans un bucket us-east-1a ou us-east-1b
  • AWS réplique ensuite les données en interne sur au moins 3 zones de disponibilité de la région
• Les données d’un bucket S3 standard sont accessibles de manière identique depuis toutes les zones de disponibilité de la même région ; pour S3, qu’un téléchargement vienne de us-east-1a ou de us-east-1b ne change rien
• Avec S3 Standard, les téléchargements dans la même région sont gratuits ; les téléchargements vers une autre région ou vers l’Internet public restent soumis aux tarifs normaux de transfert de données
• Les téléversements vers S3 sont gratuits en frais de transfert de données, quelle que soit la classe de stockage
  • Les coûts des requêtes API S3 s’appliquent toutefois
  • Ces coûts de requêtes restent relativement faibles

Calcul des coûts pour 1 To et 1 Po

• Envoyer directement 1 To depuis une instance EC2 de us-east-1a vers une instance EC2 de us-east-1b coûte $20
• Si les mêmes données sont téléversées vers S3 puis téléchargées par l’instance dans l’autre AZ, les frais de transfert de données à l’upload comme au download sont nuls
• Le coût restant est donc celui du stockage S3
  • Le stockage S3 Standard dans us-east-1 coûte $0.023/Go/mois, soit $23/TB-month
  • La facturation se fait à l’heure
  • Si l’architecture garantit que les données restent moins d’une heure dans S3, le coût tombe à environ $0.03, soit 1/720 de $23
  • Il faut supprimer l’objet S3 après le transfert
• Dans ce calcul, le coût de transfert tombe de $0.02/Go à $0.000032/Go, soit environ 0.15 % du tarif initial
• À l’extrême, un transfert de 1 Po revient à environ $32 avec cette méthode, au lieu de $20,000 en mode standard

Scalabilité et limites

• S3 est très scalable, ce qui convient aussi à un schéma où un objet téléversé depuis une AZ est téléchargé simultanément par de nombreuses instances dans une autre AZ
  • Des milliers d’instances dans une seconde AZ peuvent télécharger le même objet S3
  • Le coût de stockage S3 reste identique
  • Le coût de téléchargement reste lui aussi nul
• Il existe des limites sur la taille des objets S3
  • Un objet unique ne peut pas dépasser 5 To
  • Un fichier de plus de 5 To doit être découpé
  • Un upload simple ne peut pas dépasser 5 Go ; au-delà, un upload multipart est nécessaire
  • aws s3 cp gère l’upload multipart en interne
• S3 One Zone-Infrequent Access et S3 Express One Zone ne stockent les données que dans une seule zone de disponibilité
  • Le coût de stockage est plus faible, mais avec une contrepartie sur la disponibilité
  • Dans us-east-1, S3 One Zone-Infrequent Access coûte $0.01/Go, contre $0.0125/Go pour S3 Infrequent Access
  • S3 One Zone-Infrequent Access vise 99.5 % de disponibilité, contre 99.99 % pour S3 Infrequent Access

Configuration de l’expérience et coûts observés

• L’expérience a utilisé 2 nouveaux comptes AWS pour chaque partie afin de réduire le bruit sur les coûts
• Chaque compte contenait 2 instances EC2, l’une en us-east-1a et l’autre en us-east-1b, et l’instance de us-east-1a générait un fichier aléatoire de 1 To
• Deux approches ont été comparées
  • La première consistait à lancer un serveur netcat sur l’instance us-east-1b dans un VPC avec des sous-réseaux privés dans les deux AZ, puis à transférer directement le fichier de 1 To depuis l’instance us-east-1a
  • La seconde consistait à créer un bucket S3 dans un VPC avec un S3 Gateway endpoint, puis à faire téléverser le fichier de 1 To par l’instance us-east-1a, avant téléchargement et suppression par l’instance us-east-1b
• Le free tier AWS a pu légèrement influencer les résultats
  • Le free tier S3 offre 5 GB-months pendant 12 mois
  • 5 GB-months est inférieur à 1 TB-hours, mais l’écart reste limité
• Après mise à jour de Cost Explorer, l’expérience de transfert direct affichait $21.49, proche des $20 attendus
  • Le fait d’avoir interrompu puis relancé une fois le transfert explique une partie du surcoût
  • Le fichier généré faisait techniquement 1024 Go, ce qui porte le coût de base à $20.48
• L’expérience basée sur S3 a d’abord été observée à $0.08, sans apparition de frais de transfert de données
• Il a ensuite été confirmé que les coûts de stockage S3 sont remontés par bucket sur une base quotidienne et apparaissent dans Cost Explorer plus tard que les autres coûts
  • Comme prévu, le coût de stockage remonté n’était que de quelques centimes
  • Le free tier de stockage S3 a été entièrement consommé
  • Cette possibilité a été signalée par Dieter Matzion de la communauté FinOps

Quand cette approche vaut le coup

• AWS réplique en interne les données S3 entre zones de disponibilité, et ce coût est déjà inclus dans le coût de stockage S3 payé par l’utilisateur
• L’approche via S3 exploite donc le fait que le coût cross-AZ a déjà été payé indirectement au moment du téléversement
• Si les données restent longtemps dans S3, cette méthode peut devenir bien plus coûteuse qu’un transfert direct cross-AZ
• En supprimant l’objet immédiatement après le transfert, il devient possible d’atteindre la réduction de coût de 99 % recherchée
• Les inconvénients sont nets
  • Ce n’est pas un remplacement drop-in du code de transfert existant
  • La latence peut être bien plus élevée qu’avec une connexion réseau directe
• Quand le coût est la priorité absolue, cela peut devenir une méthode pratique pour réduire de plus de 99 % les coûts de transfert de données cross-AZ sur AWS

[GN⁺]

Avis sur Hacker News

• Pour partager mon astuce, on peut utiliser une instance Lightsail pour « proxyfier » les données d’autres ressources AWS, par exemple une instance EC2 ou un bucket S3.
  Chaque instance Lightsail inclut un volume de transfert de données dans son prix : l’instance à 3,50 $ offre 1 To, celle à 5 $ 2 To, celle à 10 $ 3 To, celle à 20 $ 4 To, et celle à 40 $ 5 To.
  En prix par volume transféré, l’instance à 10 $ avec 3 To est la plus intéressante.
  D’après les données de l’article, 3 To de trafic depuis EC2 coûtent 276,48 $ en us-east-1, et 69 $ depuis un bucket S3.
  L’inconvénient est que, dans Lightsail, le trafic entrant comme sortant est comptabilisé comme du « trafic ».

  • https://aws.amazon.com/service-terms/
    Selon la clause 51.3 des conditions AWS, il est interdit d’utiliser Amazon Lightsail d’une manière visant à éviter les frais de données d’autres services.
    Cela couvre par exemple le fait de proxyfier du trafic réseau depuis d’autres services vers l’Internet public ou d’autres destinations, ou de traiter des volumes excessifs de données via des services de load balancing/CDN ; en cas de violation, AWS peut limiter les services de données ou suspendre le compte.
  • Autre méthode : avec le free tier de CloudFront, on peut télécharger gratuitement 1 To par mois depuis AWS.
    Il suffit de définir S3, ou le serveur HTTP de son choix, comme origine.
    Auparavant, c’était 50 Go par mois pendant les 12 premiers mois, mais juste après la publication par Cloudflare de https://blog.cloudflare.com/aws-egregious-egress, c’est devenu 1 To gratuit de manière permanente.
  • Dans le détail, 2 To pour 5 $ est encore mieux que 3 To pour 10 $.
  • C’est une bonne astuce, mais à cause des conditions AWS, c’est un peu jouer avec le feu.

• GCP a aussi bouché une faille similaire en 2023, probablement parce que certains clients en abusaient.
  Si cette méthode se répand suffisamment, je pense qu’AWS fera la même chose.
  https://cloud.google.com/storage/pricing-announce#network

  • Ça me paraît peu probable.
    La « faille » que GCP a bouchée était la possibilité de faire gratuitement des transferts de données entre régions du même continent via GCS ; chez AWS, c’est déjà payant.
    Le billet d’origine explique que même les transferts entre zones de disponibilité au sein d’une même région coûtent 0,02 $ par Go, et qu’il est possible de les contourner.
  • Je connais une manière de sortir gratuitement des données de GCP, mais je ne l’ai jamais vraiment essayée.
    Je me demande si je pourrais trouver un acheteur pour cette information.
  • Ça ressemble moins à une faille qu’au fait qu’AWS a optimisé S3 et souhaite que les instances EC2 utilisent S3 comme stockage.
    En revanche, ce n’est peut-être pas censé servir de canal de transfert ; ils s’attendent plutôt à ce que vous y mettiez les données et les y laissiez.

• Il existe énormément d’astuces de ce genre pour réduire les coûts et obtenir des ressources gratuitement.
  C’est ingénieux, mais pas fiable.
  C’est du même ordre que les hacks consistant à faire du minage de cryptomonnaie dans GitHub Actions via des dépôts OSS.
  À traiter comme un exercice de hacking intéressant, mais mieux vaut ne pas déployer ce genre de solution en production.
  Il faudrait au minimum obtenir l’accord de son account manager ; sinon, on risque de se réveiller un matin avec son compte AWS résilié.

  • J’utilise cette méthode et d’autres techniques depuis des années, et je n’ai jamais été bloqué.
    Passer par S3 est aussi généralement plus efficace que de lancer un processus de synchronisation pour distribuer les données vers plusieurs destinations.

• Le coût de stockage S3 est facturé en Go-mois ; donc 1 To × 0,023 $ par Go ÷ 730 heures par mois devrait donner environ 3 cents si les données restent une heure dans le bucket.
  Cela dit, elles semblent avoir été supprimées presque immédiatement ; si les données sont restées environ une minute, on serait plutôt autour de 0,03 ÷ 60.
  En général, je m’attendrais à ce qu’AWS arrondisse cela à 0,01 $.
  La valeur TimedByteStorage dans le rapport de coûts et d’utilisation fait foi.
  https://handbook.vantage.sh/aws/services/s3-pricing/

• S3 est aussi une bonne astuce, et il y en a d’autres.
  Les gros clients AWS, par exemple ceux qui dépensent plus d’un million de dollars par an, peuvent demander des remises.
  À une époque, les remises sur les transferts entre zones de disponibilité étaient très importantes.
  Regrouper autant que possible dans une seule zone de disponibilité est aussi une option.
  Une configuration où la base de données est en zone « b » et l’unique serveur en zone « a » est même pire que de simplement standardiser sur une seule zone.
  Quand on utilise plusieurs zones de disponibilité, il faut faire de l’équilibrage par zone en tenant compte de la charge.

  • Il existe peut-être des cas où une configuration du type « la base de données en zone b, l’unique serveur en zone a » est utilisée, mais j’ai du mal à l’imaginer.
    Pour des raisons de coût ? Pourtant ça ne semble même pas réduire les coûts.
  • En quatrième point, on peut aussi activer la classe de stockage S3 Intelligent-Tiering.

• Ça ressemble à de l’optimisation fiscale version tech.
  Si trop de gens font ça, AWS va « simplement refermer la faille ».
  AWS n’est pas une entité unique : c’est plutôt des dizaines, voire des centaines d’AWS, chacun avec ses propres KPI.
  Certaines équipes veulent que vous réduisiez vos dépenses, mais elles n’iront pas jusqu’à vous expliquer concrètement comment le faire.
  Quand on construit quelque chose d’aussi complexe qu’AWS, tout finit par s’imbriquer, et il devient impossible pour un client d’optimiser un seul élément isolément.

  • Ce n’est pas une faille, c’est une conception intentionnelle.
    AWS veut que certains services soient utilisés d’une certaine manière, et les rend donc très bon marché quand on les utilise ainsi.
    Utiliser les endpoints S3 fait partie des façons dont AWS souhaite que l’on utilise le service S3.
    CloudFront en est un autre exemple.
    AWS veut que l’on utilise CloudFront ; il rend donc CloudFront moins cher que les autres sorties de données.

• L’alternative à un système complexe de minimisation des coûts cloud, c’est tout simplement de ne pas utiliser le cloud
  Il suffit de s’auto-héberger, ou d’utiliser Cloudflare, dont les frais de sortie sont de 0 centime par Go
  Ou alors de louer des serveurs cloud chez plusieurs hébergeurs VPS bien moins chers, et d’éviter les services cloud coûteux et compliqués qui aspirent 9, 12 ou 17 centimes par Go et encouragent le lock-in
  Sérieusement, si vous en êtes au point de devoir analyser finement vos coûts cloud, vous devriez envisager d’abandonner le cloud

  • Si vous faites une analyse fine des coûts cloud, c’est au contraire que vous utilisez correctement le cloud
    Parce qu’ailleurs, ce type d’analyse est tout simplement impossible
    Les gens qui recommandent de passer à l’on-premise semblent ignorer combien coûte le personnel nécessaire pour gérer un datacenter autrement que comme un homelab
    Même Apple iCloud utilise AWS et GCP parce que c’est économiquement rationnel
    C’est soit qu’on pense devoir revenir à l’on-premise parce qu’on ne sait pas utiliser le cloud, soit qu’on ne s’intéresse pas vraiment à la fiabilité
    Commencez par calculer le coût de la protection DDoS au-delà de 10G, puis dites que le cloud est plus cher
    Nous dépensons plus de 100 000 dollars en bande passante AWS, mais comme nous n’avons pas à payer des ingénieurs réseau pour gérer 3 zones de disponibilité, cela reste moins cher qu’une liaison Internet dédiée
  • Dire « si vous en êtes au point d’analyser finement les coûts cloud, abandonnez le cloud », c’est passer à côté d’une partie des raisons pour lesquelles on utilise le cloud au départ
    Beaucoup d’organisations migrent vers l’hébergement cloud parce que, parmi d’autres avantages, cela permet de faire du FinOps et du contrôle des coûts de manière beaucoup plus approfondie
    Selon l’infrastructure, si les besoins en stockage ou en calcul varient, une solution cloud peut être bien adaptée
    Au final, ce n’est qu’un outil
    J’ai travaillé dans des environnements où l’on se connectait en SSH à des serveurs bare metal de production pour mettre à jour les logiciels, gérer le pare-feu et vérifier le stockage, ainsi que dans des environnements où l’essentiel de l’hébergement passait par des fournisseurs cloud, et j’ai aussi participé à des migrations de l’un vers l’autre
    Le « cloud » n’est pas meilleur ni pire que des serveurs bare metal ou des VPS : cela dépend du cas d’usage
    Il suffit de faire une due diligence pour comprendre pourquoi l’un convient mieux que l’autre, puis de réévaluer à chaque changement d’environnement
    Cette attitude du type « le cloud, c’est mal » est puérile
  • La solution décrite dans l’article est relativement facile à appliquer
    Si vous êtes déjà lock-in chez AWS, en sortir peut coûter assez cher, et dans certains cas cette approche peut constituer un bon compromis
  • Pour s’auto-héberger, si l’on utilise réellement les fonctionnalités du cloud, c’est-à-dire des services managés, il faut mettre en place une équipe IT disposant de compétences que beaucoup d’entreprises n’ont pas
    Dans bien des cas, ce coût peut facilement annuler, voire dépasser, les économies réalisées
    C’est aussi l’une des grandes raisons pour lesquelles le choix du cloud est devenu une décision si évidente pour les entreprises
  • Dans ce cas précis, je ne pense pas que « l’auto-hébergement » aurait aidé
    AWS semble exploiter ce cas à perte
    L’auteur a trouvé une faille dans la tarification d’AWS, et c’est pour cela que c’est aussi bon marché
    Le faire soi-même aurait probablement coûté plus cher
    On ne peut que spéculer sur les raisons de cette tarification chez AWS, mais il est très probable que l’objectif soit d’inciter à utiliser un service plutôt qu’un autre

• Si vous êtes un gros consommateur de bande passante, cela vaut la peine de regarder du côté de Leaseweb, PhoenixNAP, Hetzner, OVH
  Les prix de la bande passante y sont ridiculement plus bas
  J’ai déjà vu une situation étrange où les commerciaux d’AWS refusaient totalement de baisser le prix de la bande passante, alors qu’aux tarifs standard l’entreprise n’aurait pas pu être viable

  • Cela me paraît assez inhabituel
    Les coûts de transfert semblent généralement négociables

• Une autre astuce consiste à utiliser ECR
  On peut transférer gratuitement 5 To par mois vers Internet
  Les images de conteneurs doivent être publiques, mais leur contenu peut être chiffré
  C’est utile pour stocker des archives média dans Glacier

• Je ne comprends pas comment AWS peut continuer à soutirer de l’argent aux gens avec ces frais de transfert de données absurdes
  Juste à côté, Cloudflare R2 propose des conditions 100 fois meilleures

  • Les données ont une « gravité »
    Elles vous attachent à l’endroit où elles se trouvent, et comme pour échapper à la gravité, déplacer des données coûte de l’argent
  • Quand toutes les VM et tous les conteneurs sont sur AWS, et que S3 est pris en charge de façon très robuste quels que soient le langage, le framework ou la configuration utilisés, il est vraiment difficile de demander à une équipe d’utiliser un autre fournisseur de stockage objet
    S’il y a une perte de données ou des transferts lents avec R2, on me le reprochera, ou à tout le moins on me demandera de l’aide
    En revanche, si S3 perd des données ou se montre lent dans certains cas, les gens penseront que nous l’utilisons mal et trouveront un moyen d’améliorer les choses
    Personne ne sera blâmé
    Honnêtement, si l’activité crée la moindre valeur, les frais de transfert de données sont négligeables et ne méritent pas forcément d’être optimisés
  • Nous avons développé sur R2 une nouvelle fonctionnalité SaaS qui consomme pas mal de bande passante, et cela fonctionne très bien
    Les économies sont vraiment importantes
    Nous utilisons tel quel AWS-SDK(Node.js), simplement avec l’endpoint R2
  • Je fais beaucoup moins confiance à Cloudflare qu’à AWS
    Une fois les données dans AWS, toutes les applications de la même région peuvent les utiliser sans frais de transfert
    De plus, les prix cités dans l’article sont les prix affichés, et lorsqu’un client préachète de la bande passante par contrat, cela devient beaucoup moins cher
  • R2 est encore assez récent
    Je ne sais pas vraiment quels sont ses niveaux de performance et de disponibilité en production réelle
    La durabilité, en particulier, est difficile, voire presque impossible, à évaluer
    S3 a l’avantage d’une histoire et d’un bilan beaucoup plus longs
    Si tout est déjà dans AWS, garder les données à proximité présente aussi des avantages
    Selon la manière dont les données sont utilisées, les coûts de sortie ne sont pas forcément toujours si importants
    En revanche, dès que l’on commence vraiment à générer un trafic sortant significatif, cela devient absurdement cher
    Si des concurrents comme R2 parviennent à offrir une fiabilité et des performances raisonnablement compétitives, je m’attends à ce qu’ils gagnent des parts de marché