Disclaimer: Note that this information is NOT guaranteed, and should not be taken as an engagement from Microsoft, especially for various "young" Azure DataCenters for which we use Intel Xeon based servers to run all VM models. So to validate what processor is used for a given VM on a given DC, just instantiate a VM and list the hardware from the OS.

Two weeks ago, one of my customers told me that he saw a blog post on the net saying that Azure virtual machines are 3 to 4 times slower than their equivalent on Amazon Web Services. The blog post pretends that the tests were impartial and targeted on CPU performances.

Strange isn't it? Normally, the same CPU delivers the same performance if the test is really objective. There may be a small difference, due to the hypervisor overhead; but 4 times slower is really huge.

So I decided to do some investigations to validate the numbers.

Here is the blog post : https://www.pythian.com/blog/comparing-cpu-throughput-of-azure-and-aws-ec2/

The guy, Marc Fielding, said that he compared an Amazon M3.XLarge with an Azure A3 Standard. Both VMs were running Oracle Linux. The blob post has a couple of comments and those who commented asked Marc to run sysbench on the VMs to compare. Results are :

AWS M3.XLarge (E5-2670 @ 2.5GHz) : Sysbench results = 51.64sec

Azure A3 (E5-2660 @ 2.2GHz) : Sysbench results = 117.08sec

Wouaou ! That a huge difference. There should be a difference has this is not the same processor nor the same speed, but still, it's a lot.

My own tests

Let me do my own tests. I used Oracle Linux 7, instantiated on an Azure A3 VM on West Europe DataCenter:

Sysbench is not installed by default, so I did install sysbench in three steps :

yum install wget

wget https://dl.fedoraproject.org/pub/epel/7/x86_64/s/sysbench-0.4.12-12.el7.x86_64.rpm

yum install sysbench-0.4.12-10.el7.nux.x86_64.rpm

Then let's start the tests.

Tests on an Azure A3 virtual Machine (on Amsterdam DC)

First, is an A3 really hosted on an E5-2660 @ 2.2GHz ??

Just run cat /proc/cpuinfo

Surprise, an A3 is not hosted on an E5-2660, but on an AMD Opteron 4171 HE @ 2.1GHz So we should expect a less good score than the AWS M3.XLarge. Let 's see:

sysbench –-test=cpu –-cpu-max-prime=50000 –-num-threads=2 run

Indeed, we do have a less good score, but that is not 117sec as described in the blog post.

Let's do more tests on different Azure Virtual Machines Sizes

Resizing the VM to D3 (on Amsterdam DC)

So what is the CPU on a D3 ?

Good!! The CPU is not exactly the same than the AWS one, but the D series is hosted on an Intel proc.

Better now, we get 71.59sec on a bit older proc and lower frequency. But that would be great to have EXACTLY the same CPU.

Resizing the VM to A11 (on Amsterdam DC)

A10 and A11 and "compute intensive" virtual machines, without infiniband support. They should be fast.

cat /proc/cpuinfo

YYEESSS! Same CPU, same frequency. Normally, this VM should deliver exactly the same CPU performance than the AWS one. Suspense…

Yes! 51.21 sec. Demonstration is done. Same CPU, same results.

Just for fun, let's give try on our Godzilla Virtual Machines. The G-Series…

Test on a G2 Series (West US DataCenter)

The G-Series has the fastest CPUs on Azure:

The frequency is not high, but the architecture is a bit more performant. Here are the sysbench results:

As expected, faster proc = better results.

Conclusion

I honestly don't know how the performance tests have been done to produce the blog post mentioned at the beginning of this article. Different CPUs produces different performance tests results, and identical CPUs produce the same performance results. There is an overhead due to the Hypervisor, but tier 1 Hypervisors are equivalent and introduce a negligible overhead in such testing. In term is pure CPU performance, the same CPU at the same frequency will deliver the same performance whether it is an Azure VM, or and AWS or any other cloud provider, considering the fact that the hypervisor is performant.

In summary

Here are the results of my tests:

Oracle Linux 7.0 with Sysbench 4.12

To display the CPU architecture: cat /proc/cpuinfo

To launch the bench: sysbench –-test=cpu –-cpu-max-prime=50000 –-num-threads=2 run

Pour commencer, je vous recommande les cours de la Virtual Academy, très bien faits : https://www.microsoftvirtualacademy.com/product-training/microsoft-azure

Pour passer à la pratique,  deux options :

L’Azure Readiness Content: https://www.microsoft.com/en-us/download/details.aspx?id=8396

l’Azure Training Kit : https://azuretk.com/

Pour des infos au fil de l’eau sur les technos Azure qui sortent il faut aller sur Channel 9 qui dispose aussi d’une masse importante de vidéos d’information dont :

Le Cloud Cover : https://channel9.msdn.com/Shows/Cloud+Cover

Les Azure Friday : https://channel9.msdn.com/Shows/Azure-Friday

Il ya aussi le Blog Azure France, tenu par mes amis de la division Developper Experience : https://blogs.msdn.com/b/windowsazurefrance/

Pour aller plus loin dans les technos Azure, je sélectionne les vidéos Azure dans nos événements clients :

• TechEd : https://channel9.msdn.com/Events/TechEd#fbid=

• Build : https://channel9.msdn.com/Events/Build

Mes conseils sur les technos à connaître, par ordre de priorité :

1. Overview Azure IT

2. Overview Azure Developper

3. IaaS / Virtual Network / Express Route

4. Azure Storage

5. Sécurité et compliance

6. Le nouveau portail Azure

7. WebSites et Cloud Services (PaaS)

8. Azure Active Directory

9. Site Recovery + InMage

La plupart de ces modules se trouvent dans la Virtual Academy. Site Recovery et InMage sont traités dans TechEd

J'ai eu la chance de pouvoir rencontrer en personne Satya Nadella, le nouveau CEO de Microsoft. Je ne vous dirai pas comment j'ai réussi ce tour de magie, mais Lundi 4 Février 2013 à 14H30, heure de Seattle, j'entrais dans le bureau de Satya pour 15 min d'entretien avec lui. Il était à l'époque VP de la division Serveurs et Clouds.

Première évidence : L'homme dit qu'il est un dirigeant accessible de ses employés, et la preuve en est, car avec un petit peu de volonté, il est possible de prendre rendez-vous avec lui. C'est une fois le rendez-vous bloqué dans mon agenda (et le sien), que les choses se compliquent un tout petit peu. Car en effet, le temps de tous les dirigeants est précieux, et il s'agit de ne pas le lui faire perdre. Bon 15 min, c'est pas énorme, mais je peux vous assurer qu'il faut tout de même les préparer très sérieusement.

Nous avons discuté Azure, Cloud OS; nous avons parlé du déploiement d'Azure en France; nous avons parlé stratégie commerciale. L'homme est un fin technicien mais un businessman avant tout. La transformation qu'il a apporté à la division Serveurs & Cloud et la direction qu'il a imprimé au cloud Microsoft le prouvent, Satya a la bonne stratégie sur ce domaine qu'il a dirigé depuis quelques années.

Satya est à la tête de Microsoft depuis maintenant plusieurs mois; et on peut noter dès à présent une inflexion certaine de la stratégie et de la communication externe. L'ouverture est de mise, de même que les annonces multiples à la fois dans le monde grand public et le monde professionnel. Les prochains mois promettent d'être très intéressants... :-D 

Vous avez vu les annonces de Microsoft à TechEd ? Azure dispose de nombreuses nouvelles fonctionnalités sur les réseaux virtuels dans Azure. Entre autre :

• Nouveaux "Regional Networks" tirant parti de toutes les nouveautés réseau
• Possibilité d'avoir des adresses IP internes statiques (on savait déjà le faire depuis Build 2014)
• Possibilité de tirer plusieurs VPN à partir d'une même passerelle
• Possibilité de relier plusieurs VNET dans Azure par de multiples VPN
• Réservation d'adresses IP publiques
• Load Balancer internes (sans passer par les VIP)

Génial non ?.La plupart de ces fonctions sont disponibles via PowerShell uniquement pour le moment. Reste donc à passer à la pratique. Je vous propose donc de découvrir ces fonctionnalités pas la pratique.

Les Regional Networks

Les nouveaux VNET Azure sont appelés des Régional Networks. Les "Locations" remplacent les "Affinity Groups" pour les nouveaux VNET. Ils permettent d'associer à un VNET l'ensemble des ressources d'un Datacenter Azure. Pour créer un VNET nouvelle génération, il faut suivre l’explication et la procédure décrite ici : https://azure.microsoft.com/blog/2014/05/14/regional-virtual-networks/

 La migration des anciens VNET vers les Regional Networks n’est pour le moment pas directe. Il faut exporter la configuration du VNET, la modifier pour passer en Regional Network, et créer un nouveau VNET à partir de la même config modifiée. En revance, un ancien VNET peut être connecté à un Regional Network, et deux anciens VNET peuvent être connectés par un tunnel VPN

Quelques précisions au sujet de l'article.

Le code XML décrivant le regional network contient des erreurs XML. Voici un exemple avec 2 regional networks qui fonctionne :

Attention à ne pas modifier la déclaration du subnet "GatewaySubnet" dans chaque VNET. C'est important pour la suite, si vous voulez créer une passerelle de VPN

<VirtualNetworkSite name="NGVnetEurope" Location="North Europe">

<AddressSpace>

<AddressPrefix>10.1.0.0/16</AddressPrefix>

</AddressSpace>

<Subnets>

<Subnet name="GatewaySubnet">

<AddressPrefix>10.1.0.0/29</AddressPrefix>

</Subnet>

<Subnet name="ProductionEUR">

<AddressPrefix>10.1.1.0/24</AddressPrefix>

</Subnet>

<Subnet name="DevTestEUR">

<AddressPrefix>10.1.2.0/24</AddressPrefix>

</Subnet>

</Subnets>

</VirtualNetworkSite>

<VirtualNetworkSite name="NGVnetUS" Location="East US">

<AddressSpace>

<AddressPrefix>10.2.0.0/16</AddressPrefix>

</AddressSpace>

<Subnets>

<Subnet name="GatewaySubnet">

<AddressPrefix>10.2.0.0/29</AddressPrefix>

</Subnet>

<Subnet name="ProductionUS">

<AddressPrefix>10.2.1.0/24</AddressPrefix>

</Subnet>

<Subnet name="DevTestUS">

<AddressPrefix>10.2.2.0/24</AddressPrefix>

</Subnet>

</Subnets>

</VirtualNetworkSite>

Si vous voulez spécifier d'autres DataCenters, voici la liste complète des noms de DC acceptés : asiaeast, East Asia, asiasoutheast, Southeast Asia, europenorth, North Europe, europewest, West Europe, useast, East US, uswest, West US, japaneast, Japan East, japanwest, Japan West, brazilsouth, Brazil South, usnorth, North Central US, ussouth, South Central US

Il est préférable d'utiliser une bonne commande powershell pour modifier les VNET d'une souscription. Voici comment faire :

1- Exporter la configuration dans un fichier XML. Exemple : Get-AzureVNETConfig -ExportToFile "C:\Users\swoillez\Desktop\netcfg.xml"

2- Modifier la configuration avec l'exemple que je vous ai donné plus haut

3- Réimporter la configuration en PowerShell. Exemple : Set-AzureVNETConfig -ConfigurationPath "C:\Users\swoillez\Desktop\netcfg.xml"

Et voici ce que ca donne dans la console Azure :

A noter qu'on peut identifier un Regional Network à la colonne "Location" qui contient juste le nom du DataCenter, alors qu'un VNET classique affiche dans cette colonne le nom du groupe d'affinité avec entre parenthèses le nom du datacenter

La connectivité entre VNET

Maintenant que j'ai mes VNET nouvelle génération, ca serait cool de les interconnecter de manière à créer un seul réseau. Si vous regardez avec attention ma config VNET ci dessus, vous verrez que j'en ai créé deux. Un VNET en Europe et un autre aux US.

Donc pour créer une interconnexion entre VNET, il faut se référer à la doc pour bien comprendre. Elle se trouve ici : https://msdn.microsoft.com/en-us/library/azure/dn690122.aspx

Bon, en clair, cela se fait en 3 étapes :

1. Dans les deux VNET à connecter, Créer la déclaration de l'autre réseau (déclaration en Local Network) et un champ pour déclarer la Gateway
2. Dans la console Azure démarrer les deux passerelles VPN
   
3. Reconfigurer les deux passerelles avec leurs adresses IP (obtenues à l'étape 2) et leur injecter une clé d'encryption commune
   

Première étape donc, reconfigurer les deux réseaux pour qu'ils se connaissent l'un l'autre et puissent créer deux Gateway pour interconnecter les deux VNET. Il faut pour cela modifier la configuration des VNET avec la même procédure que décrite précédemment : Exporter la configuration du VNET en XML, la modifier, puis ré importer la configuration dans la souscription Azure. Les deux modifications à apporter sont :

- La déclaration de "Local Networks" qui permettent à la passerelle VPN de connaître l'adresse de la passerelle VPN distante et la plage d'adresses IP distante. Pour le moment on ne connaît pas l'adresse IP publique de la passerelle distante, il faudra donc la modifier dans un second temps. Pour nos deux réseaux, ca donne donc ca :

<LocalNetworkSites>

<LocalNetworkSite name="NGVnetEurope">

<AddressSpace>

<AddressPrefix>10.1.0.0/16</AddressPrefix>

</AddressSpace>

<VPNGatewayAddress>1.0.0.0</VPNGatewayAddress>

</LocalNetworkSite>

<LocalNetworkSite name="NGVnetUS">

<AddressSpace>

<AddressPrefix>10.2.0.0/16</AddressPrefix>

</AddressSpace>

<VPNGatewayAddress>2.0.0.0</VPNGatewayAddress>

</LocalNetworkSite>

</LocalNetworkSites>

Comme je le disais, les adresses IP publiques des passerelles VPN sont temporaires car les passerelles n'ont pas encore été créées

Ensuite il, faut modifier chaque VNET pour y ajouter la déclaration de la passerelle. Modifs en rouge dans le code XML suivant :

<VirtualNetworkSites>

<VirtualNetworkSite name="NGVnetEurope" Location="North Europe">

<AddressSpace>

<AddressPrefix>10.1.0.0/16</AddressPrefix>

</AddressSpace>

<Subnets>

<Subnet name="GatewaySubnet">

<AddressPrefix>10.1.0.0/29</AddressPrefix>

</Subnet>

<Subnet name="ProductionEUR">

<AddressPrefix>10.1.1.0/24</AddressPrefix>

</Subnet>

<Subnet name="DevTestEUR">

<AddressPrefix>10.1.2.0/24</AddressPrefix>

</Subnet>

</Subnets>

<Gateway>

<ConnectionsToLocalNetwork>

<LocalNetworkSiteRef name="NGVnetUS">

<Connection type="IPsec" />

</LocalNetworkSiteRef>

</ConnectionsToLocalNetwork>

</Gateway>

</VirtualNetworkSite>

<VirtualNetworkSite name="NGVnetUS" Location="East US">

<AddressSpace>

<AddressPrefix>10.2.0.0/16</AddressPrefix>

</AddressSpace>

<Subnets>

<Subnet name="GatewaySubnet">

<AddressPrefix>10.2.0.0/29</AddressPrefix>

</Subnet>

<Subnet name="ProductionUS">

<AddressPrefix>10.2.1.0/24</AddressPrefix>

</Subnet>

<Subnet name="DevTestUS">

<AddressPrefix>10.2.2.0/24</AddressPrefix>

</Subnet>

</Subnets>

<Gateway>

<ConnectionsToLocalNetwork>

<LocalNetworkSiteRef name="NGVnetEurope">

<Connection type="IPsec" />

</LocalNetworkSiteRef>

</ConnectionsToLocalNetwork>

</Gateway>

</VirtualNetworkSite>

Pensez bien à croiser les déclarations de réseaux. Dans mon exemple, la passerelle du VNET Europe pointe sur le Local Network US, et vice versa :

Deuxième étape, après la réimportation du fichier XML dans Azure, créer les deux passerelles VPN pour obtenir leur adresse IP publique de manière à pouvoir terminer leur configuration. Il faut le faire dans la console web Azure. Une fois fait, ca donne ca pour chaque résau:

Troisième étape; terminer la configuration des deux passerelles, en injectant dans la configuration des deux "Local Networks" les bonnes adresses IP publiques des passerelles (qu'on vient juste d'obtenir après leur création). Même principe, export XML, modif de la config, import XML. On obtient une configuration valide :

Dernière étape, injecter dans chaque passerelle la même clé de chiffrement IPSEC. Deux commandes Powershell pour faire ca :

Set-AzureVNetGatewayKey -VNetName VNet1 -LocalNetworkSiteName VNet2 -SharedKey <clé de chiffrement>

Set-AzureVNetGatewayKey -VNetName VNet2 -LocalNetworkSiteName VNet1 -SharedKey <clé de chiffrement>

Les deux commandes passent avec succès et on peut alors redémarrer les 2 passerelles VPN à partir de la console Azure :

Reste à créer une VM de chaque coté pour vérifier que la magie fonctionne vraiment...

Et ca marche !!! Et même plutôt bien. Les deux VM que j'ai créé dans chaque VNET peuvent se voir (attention aux firewalls des VM pendant vos tests, les pings sont bloqués par défaut)

Une petite question intéressant pour terminer. Et je vous laisse réfléchir à la réponse. Les deux VNET sont bien l'un en Europe et l'autre aux US, il n'y a pas de doute; et une liaison transatlantique sur le net délivre dans les 350ms de latence....

Alors comment se fait-il que mon ping délivre une latence beaucoup beaucoup plus faible, de l'ordre de 80ms.. ???

Voilà pour ce post. La suite de mes aventures réseau dans un prochain post.

Stéphane.

Et oui !!! C'est possible !! C'est possible grâce à un nouveau composant d'Azure : RemoteApp. Il s'agit grâce à ce composant de faire tourner des applications en "Remote App" sur Azure dans une ferme de serveurs RDS sans avoir à se soucier de la montée en charge, ni même pour Office, de sa mise à jour. Tout est là, et accessible depuis une session à distance, y compris sur l'iPad et sous Android. Bluffant !!! RemoteApp est aussi capable de virtualiser des applications privées via un tunnel VPN ouvert sur Azure Virtual Network, et il est aussi possible d'uploader sur Azure sa propre image de serveur RDS contenant les applications à virtualiser. Magique !!!

Le module est en preview pour le moment, mais connaît déjà un tel succès que l'attente est longue pour accéder à la preview.

Voici à quoi ressemble la console d'administration avec, Miracle, Office 2013 :

Et voilà l'application iPad qui permet de lancer ses applications en RemoteApp :

Pour en savoir plus, suivez en Replay la session de TechEd 2014 US dédiée à Azure RemoteApp : https://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/PCIT-B342

A vos clavier pour vous inscrire à la preview !

Enjoy.

Stéphane.

S’abonner au flux RSS du Blog Azure pour avoir les news : https://blogs.msdn.com/b/windowsazure/

Doc Azure : https://msdn.microsoft.com/en-us/library/windowsazure/dn578280.aspx

Doc Notification Hub : https://msdn.microsoft.com/en-us/library/windowsazure/jj891130.aspx

Performances des comptes de stockage : https://msdn.microsoft.com/en-us/library/windowsazure/dn249410.aspx

Adresses IP internes Fixes pour les VM : https://blogs.msdn.com/b/niallsblog/archive/2014/02/23/allocating-static-ip-addresses-within-a-vnet.aspx

Azure Scripts Center : https://www.windowsazure.com/en-us/documentation/scripts/?fb=fr-fr

High Available Applications sur Azure : https://msdn.microsoft.com/fr-fr/library/windowsazure/dn251004.aspx

Déployer l’authentification multi facteurs sur des serveurs : https://msdn.microsoft.com/en-us/library/windowsazure/dn249467.aspx

Installer un serveur FTP sur Azure : https://fabriccontroller.net/blog/posts/passive-ftp-and-dynamic-ports-in-iis8-and-windows-azure-virtual-machines/

Spécifications des VM dans Azure : https://msdn.microsoft.com/en-us/library/windowsazure/dn197896.aspx

Oracle Virtual Machines Images sur Azure : https://msdn.microsoft.com/en-us/library/dn439770.aspx

Virtual Networks FAQ : https://msdn.microsoft.com/en-us/library/windowsazure/dn133803.aspx

VPN Devices FAQ : https://msdn.microsoft.com/en-us/library/windowsazure/jj156075.aspx

Azure DataCenters IP Ranges : https://msdn.microsoft.com/en-us/library/windowsazure/dn175718.aspx

Mais bon, hey ! ho ! C'est mon premier post de la série des "Ca marche dans Azure" alors on va commencer doucement.

Facile donc. Une fois l'image créée, il suffit de se connecter dessus pour configurer WebLogic. Il ne faut pas oublier non plus de configurer les points de terminaison (Endpoints en anglais) de la machine virtuelle pour ouvrir les bons ports réseau, car comme vous le savez, les VMs IaaS sont créées par défaut avec le minimum d'ouverture sur la VIP internet. Pour les besoins de la démo, j'ai juste ouvert le port d'administration de WebLogic. Après, il suffit de se connecter sur la console :

Il reste ensuite installer ses applications J2EE. Simple non ?

Stéphane.

 Les nouvelles fonctions Powershell :

 o             Get-AzureStaticVNetIP

o             Set-AzureStaticVNetIP

o             Remove-AzureStaticVNetIP

o             Test-AzureStaticVNetIP

 Pour plus de détails, voir ce blog post, avec un script Powershell inclus : https://blogs.msdn.com/b/niallsblog/archive/2014/02/23/allocating-static-ip-addresses-within-a-vnet.aspx

Azure Web Sites est une infrastructure d'hébergement de sites web sur la plate forme de cloud computing Azure. Web Sites dispose de trois modèles d'usage permettant d'accéder au service avec des couts et des niveaux de service différents. Alors une question se pose tout de suite : Comment choisir le bon modèle d'hébergement WebSites en fonction de mes besoins ? et combien cela va-t-il me couter ?

Si vous ne connaissez pas encore Azure Web Sites, vous pouvez en consulter une description ici : https://www.windowsazure.com/fr-fr/home/scenarios/web-sites/

Pour comprendre comment créer un site Web avec Azure Web Sites, voici un tuto pas à pas : https://blogs.msdn.com/b/windowsazurefrance/archive/2012/10/03/h-233-bergez-10-jusqu-224-sites-asp-net-gratuitement.aspx

Première information sur les modèles d'hébergement Web Sites : Le choix du modèle n’est pas structurant puisqu’on peut passer à tout moment d’un modèle à l’autre, en faisant attention aux volumes de stockage utilisés en cas de basculement vers un modèle plus restrictif.

Voici donc en trois points de quoi :

• Comprendre les modèles d'ébergement Azure Web Sites
• Savoir choisir le bon modèle en fonction des besoins de son site web
• Comprendre la tarification pour savoir combien cela va couter

Les modèles d’usage d'Azure Web Sites

Modèle d’usage gratuit

• Utilisable pour 10 sites
• Pratique et pas cher pour les développements
• Pas de choix sur le nom de domaine, ce sera en azurewebsites.net
• 1Go de stockage et 20Mo de base de données MySQL à partager
• 165Mo de trafic sortant journalier
• Les ressources serveur sont partagées
• Les sites web peuvent utiliser 60 min de CPU du serveur par jour.

Modèle d’usage dans l'infrastructure partagée

• Instances payantes pour un maximum de 100 sites web par région Azure et par souscription
• Prise en charge de noms de domaine personnalisés
• 1Go de stockage et 20Mo de base de données MySQL à partager
• Pas de limite sur le trafic sortant qui est facturé au tarif classique de trafic sortant de l’abonnement
• Les sites web peuvent utiliser 240 min (soit 4h) de CPU par serveur et par jour, et peuvent utiliser de 1 à 3 serveurs
• Les serveurs sont facturés une fraction du tarif d’une VM small PaaS.

Modèle d’usage sur instances de VM réservées

• Instances payantes pour un maximum de 100 sites web par région Azure et par souscription
• Prise en charge de noms de domaine personnalisés
• 10Go de stockage et 20Mo de base de données MySQL à partager
• Pas de limite sur le trafic sortant qui est facturé au tarif classique de trafic sortant de l’abonnement
• Les sites web disposent de leur propre infrastructure technique, trois modèles de serveur sont disponibles : 1 cœur, 2 cœurs, 4 cœurs. Pour chaque modèle, il est possible d’utiliser 1, 2, ou 3 serveurs
• Les serveurs sont facturés sur la base des tarifs des VM PaaS.

 Pour les sites webs qui le permettent, on peut bien évidemment ajouter une ou plusieurs bases Azure SQL Database.

 Le choix du mode d’usage de Web Sites

Pour des développements basiques et des tests, il n’y a pas de débat, il faut utiliser les instances gratuites.

Pour faire de la production ou de la pré production, il faut écarter le modèle d’instances gratuites. Il faut ensuite estimer l’utilisation du site pour savoir si la limite de 240min de CPU par jour sera atteinte. On peut alors sereinement choisir entre le modèle d’instances partagées ou le modèle d’instances dédiées.

Les métriques de facturation d’Azure Web Sites

Pour estimer le tarif d’un site web il faut donc tenir compte des paramètres suivants :

 - Pour un site hébergé dans la zone gratuite, rien à payer. Attention à la limite d’usage CPU à 60min. On y arrive site avec un site web actif.

- Pour un site hébergé dans la zone partagée, il faut dénombrer :

• le nombre d’instances utilisées en fonction de ses besoins d’utilisation CPU : 4H, 8H ou 12H
• Le trafic sortant en Go
• Les éventuels besoins en base Azure SQL Database ou même en stockage Azure Blob si les 1Go de stockage inclus ne suffisent pas

- Pour un site hébergé dans la zone d’instances dédiées, il faut dénombrer :

• La taille des instances et leur nombre. Pour estimer ses besoins en nombre d’instances et en taille on compte le nombre de cœurs de VM dont à a besoin ; la métrique étant le nombre de requêtes par seconde à traiter. En moyenne, à grosses mailles, un cœur de VM délivre 300 à 400 requêtes par seconde. Ces chiffres sont bien sûr des estimations car il est difficile de donner une valeur précise au nombre de requêtes par seconde traitées par les cœurs, car cela dépend des éventuels traitements réalisés en arrière plan.
• Le trafic sortant en Go
• Les éventuels besoins en base Azure SQL Database ou même en stockage Azure Blob si les 1Go de stockage ne suffisent pas

Munis des estimations pour chacune de ces métriques, il reste à aller consulter, soit la description détaillée des tarifs, soit utiliser la calculatrice d'estimation tarifaire Azure, dont voici les liens :

La description des métriques de tarification de Web Sites est disponible ici : https://www.windowsazure.com/fr-fr/pricing/details/#header-1

La calculatrice d'estimation tarifaire pour Azure Web Sites est disponible ici : https://www.windowsazure.com/fr-fr/pricing/calculator/?scenario=web

Pour commencer à tester gratuitement Web Sites ainsi que les autres fonctionnalités d'Azure, il suffit de s'enregistrer ici : https://www.windowsazure.com/fr-fr/pricing/free-trial/?WT.mc_id=AEA18664C