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.

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ées les workloads 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. A 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à.

Par exemple, une instance EC2 Windows de type m4.xlarge dans la zone US-East (Virginie) coûte 0.0404$ par heure (lors de l’écriture de cet article). La même instance, dans la région AWS US-West (Californie) coûte 0.44$ par heure, 0.446$ par heure en Europe (Francfort), et 0.455$ l’heure dans la région Asie-Pacifique (Singapour). Cela peut sembler anecdotique mais le différentiel peut être énorme (à la semaine, au mois ou à l’année) si l’on se base sur des douzaines, centaines voire milliers d’instances.

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é – comme 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 connait une panne, la workload est basculée vers, 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.

 

Dernièure mise à jour de cet article : septembre 2017

PRO+

Contenu premium

Accéder à plus de contenu PRO+ ainsi qu'à d'autres offres réservées aux membres.

Guides Essentiels

Cloud public : petit guide pour bien contrôler ses coûts

Soyez le premier à commenter

M'envoyer une notification dès qu'un autre membre commente.

En soumettant ces informations à LeMagIT.fr, vous acceptez de recevoir des emails de TechTarget et ses partenaires. Si vous résidez hors des Etats-Unis, vous consentez à ce que vos données personnelles soient transférées et traitées aux Etats-Unis. Politique de confidentialité

Merci de créer un identifiant pour pouvoir poster votre commentaire.

- ANNONCES GOOGLE

Close