Après avoir découvert ma première facture Azure et son montant assez… élevé, je me suis attaqué à la lecture des détails pour en comprendre le pourquoi.

La facture détail les heures pendant lesquelles les instances tournent (un mois étant composé de 750 heures) et je me suis aperçu que certaines instances avaient un nombre d’heures anormalement élevé : Certains projets sont arrêtés, leurs instances étant donc stoppées, cependant le problème était que les heures étaient tout de même comptées. Normal, anormal ?!

Après en avoir discuté autour de moi et posé la question sur le forum msdn, j’ai découvert dans les CGV d’Azure que les heures décomptées, sont décomptées pour un déploiement et non pour une instance. C’est à dire que tant que le package est en ligne, vous êtes facturé, que le projet soit démarré ou non. Donc le seul avantage à le stopper est que les instances ne génèrent plus de frais annexes telle que la bande passage ou un accès au storage par exemple.

Voilà ce que dit Microsoft dans le détail de l’offre « Compute Instance » :

Windows Azure compute hours are charged only when your application is deployed. When developing and testing your application, you will want to remove the compute instances that are not being used to minimize compute hour billing. Please note that suspending your deployment will still result in compute charges since the compute instances are still allocated to you and cannot be allocated to another customer. Compute hours are billed based on the number of clock hours your service was deployed multiplied by the number of compute instances. If you have two tenants deployed for a hosted service, one for staging and one for production, both will be charged as both are utilizing Windows Azure platform resources.

Il faut donc faire très attention et bien supprimer son package une fois testé. Ou alors l’intégrer dans une offre telle que l’offre découverte ou une offre spéciale msdn qui donne 750h d’extra-small ou de small suivant le cas. Cela permettra de laisser son déploiement en ligne.

Le cas est quand même peu pratique puisque l’on doit supprimer son déploiement à chaque fin de test. Puis, dès que l’on a envie de le re-tester, il faut redéployer avec ce que cela impose : au minimum 15 min de déploiement. C’est aussi un peu limite commercialement : Chez d’autres hébergeurs (amazon, ovh…), une fois que l’instance/VM est coupée, la facturation s’arrête. Au final, il n’y a que de l’espace disque qui est consommé une fois la VM éteinte, et de nos jours, l’espace disque ne coute pas grand-chose pour ne pas dire rien. C’est juste dommage. Peut-être que cela sera mis à jour prochainement, le service étant encore « jeune ».

Pour conclure, si on doit bien retenir une chose, c’est qu’il est important de faire une étude de coûts avant d’arriver sur le nuage. Le Cloud Computing est assez traitre de ce côté-là et on a vite fait d’exploser son budget. C’est ce qui peut poser problème lors d’une attaque sur un site web par exemple, Microsoft ne garantit rien vis à vis de ça et n’en parle d’ailleurs tout simplement pas. Sommes-nous protégé ? Que se passe-t-il lors d’une attaque ? Peux t’on les détecter nous-mêmes ? Finalement le premier « frein » à une attaque sera… les instances elles-mêmes qui tomberont. Mais si une VM tombe sous le coup d’une attaque, quid si Azure en relance une autre pour palier au down time ?

Bref, encore beaucoup de questions auxquelles je n’ai pas encore de réponses, mais le sujet est intéressant.

Edit : Il s’avère que depuis le 1er Juillet 2011, le cout de la bande passante entrante est offert, ce qui fait que même lors d’une attaque, le seul cout engendré sera le nombre d’accès au storage (si vous l’utilisez). Et le seul moyen de vous en protéger et de monitorer vos instances et/ou votre facture au jour le jour, si elle augmente trop, c’est qu’il y a un souci quelque part ! Ceci étant dit cela ne résout pas le problème des instances qui passeront leur temps à tomber et à être redémarrées ailleurs par Azure.