Guides Essentiels
Voir tous les articles de ce guide
Conseil
Cet article fait partie de notre guide: Cloud public : petit guide pour bien contrôler ses coûts

Coûts du cloud : quels rôles jouent les régions et les zones de disponibilité

Avec le cloud, l’imprévu est souvent le mot d’ordre lorsqu’on aborde la question des coûts. Pour rester dans les limites de votre budget, une bonne évaluation des coûts associés aux régions et aux zones de disponibilité est nécessaire.

Stephen J. Bigelow
par
Publié le: 10 mai 2022

Avec la volonté des fournisseurs de cloud de mettre l’accent sur la résilience de leurs services, les régions et des zones de disponibilité jouent un rôle de plus en plus important. Ces acteurs proposent de la redondance, cherchent à réduire la latence et à optimiser les capacités de basculement d’un datacenter à l’autre. Autant de possibilités qui font certes les spécificités du cloud, mais qui pourraient faire oublier que les coûts sont la priorité première des entreprises.

Aujourd’hui le nombre de régions ou sites, là où sont hébergés les traitements applicatifs des entreprises, ne dépend pas uniquement des capacités de résilience : c’est aussi une affaire de coûts. Cet article vise justement à identifier les problèmes liés à la sélection de régions et de zones de disponibilité.

Pourquoi les prix fluctuent ?

Les fournisseurs du marché utilisent différentes terminologies et architectures pour leur plateforme cloud. AWS déploie plusieurs datacenters au sein de zones géographiques – les régions –, chacun de ces centres est appelé zone de disponibilité. AWS relie chaque zone avec un lien dédié, haut débit, pour gérer le basculement d’une région à l’autre le plus rapidement possible.

Google et Microsoft ont, de leur côté, organisé leur cloud avec la multiplication de petites régions.

Afin de minimiser la latence et d’améliorer les performances, les entreprises choisissent généralement une région en fonction de la localisation de leurs utilisateurs. D’autres font ce choix selon le cadre juridique qui s’impose à eux, et qui limite physiquement la zone de localisation des données. L’architecture d’une application peut aussi être un critère de choix : on peut ajouter des VM et les placer dans des régions différentes pour gérer sa disponibilité – cela comprend souvent un load balancing pour orienter le trafic réseau de l’application.

Les coûts peuvent varier d’une région à l’autre dans le monde, à cause des coûts de l’énergie, des « pénalités carbone », des taxes immobilières ou des coûts opérationnels. À cela s’ajoutent les impôts et autres taxes gouvernementales. Chacune de ces composantes s’ajoute au prix du service de chaque région. La différence de prix vient de là. À date, seul Oracle revendique une homogénéisation mondiale de ses tarifs.

Des simulateurs de coût sont disponibles chez la plupart des hébergeurs de cloud public présents à l’international :

Au moment de l’écriture de ces lignes, une machine virtuelle avec 4 vCPU et 16 Go de RAM coûte par exemple chez AWS plus ou moins 0,15 $ par heure à Paris, Londres et Francfort, 0,21 $ à Boston (USA, côte ouest), ou encore 0,20 $ à Los Angeles (USA, côte est).

Quels sont les autres facteurs ?

Ces coûts ne sont que le commencement. Les administrateurs doivent ensuite répliquer une partie de leurs déploiements vers d’autres zones ou régions. Dans certains cas, la redondance est seulement affaire de réplication des données (on peut par exemple dupliquer une base RDS). Pour plus de performances, on peut également répliquer d’autres services pour pouvoir distribuer la workload entre plusieurs régions.

De combien de régions ai-je besoin ?

Les exigences en matière de performances et de disponibilité varient d’une application à l’autre. Certaines ne nécessitent pas plus d’une région ou zone de disponibilité – par exemple un déploiement pour test. Mais lorsqu’on a besoin de résilience, une seconde région est nécessaire. Si une région connaît une panne, l’application est basculée, ou continue d’opérer sur une autre région. Déployer une workload dans plus de 2 régions est plutôt rare et cela est généralement réservé aux applications les plus critiques.

Lorsque l’on souhaite développer des applications redondantes, il faut également évaluer les coûts de transfert entre régions. Généralement, les fournisseurs de cloud public ne facturent pas le chargement de donnée dans leur cloud. En revanche, ils facturent la migration de données. Si vous souhaitez migrer des données d’une région à l’autre pour des besoins de résilience, il faut donc s’attendre à des coûts supplémentaires.

AWS facture par exemple 0.010 $ par Go pour déplacer des données de la région US-East (Ohio) depuis S3 vers US-East (Virginie du nord), et 0.020 $ par Go pour déplacer des données depuis S3 vers une autre région AWS. Les coûts du transfert des données peuvent varier selon la localisation du site original. La synchronisation de données peut également faire gonfler la facture. Toutefois, déplacer les données dans la même région reste gratuit.

Pour résumer, la question des coûts n’a pas qu’une seule réponse. Les architectes doivent évaluer la bonne dose de services nécessaires à leurs applications, puis choisir le niveau adéquat de redondance. L’application doit enfin être conçue pour optimiser les usages – cela consiste par exemple à limiter le transfert sortant de données quand cela est possible.

[Article publié le 11 septembre 2017 et mis à jour le 10 mai 2022.]

Pour approfondir sur Administration et supervision du Cloud